ハイブリットクラウド環境におけるモダンアプリケーション開発

© 2020, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Amazon Web Services Japan K.K.
Partner Solutions Architect
Masao Kanamori
ハイブリットクラウド環境における
モダンアプリケーション開発
2020.05.29

⾃⼰紹介
⾦森政雄
Ø 所属/役職 :
パートナー技術本部/
パートナーソリューションアーキテクト
Ø 好きなサービス
Ø リモートワークの過ごし⽅
- 午後に20 分間の仮眠
- 定期的な⼩休憩
Amazon Elastic
Container Service
AWS Step Functions

モダンアプリケーション開発の効果を確認し、レガシーな
アプリケーションに対して、クラウドへ段階的な移⾏とモ
ダナイゼーションについて考察します
この中で重要な役割を果たすであろうコンテナについて、
その特性と本番ワークロードに導⼊するためのオーケスト
レーションツールについても解説します。
このセッションの⽬的

Agenda
1. モダンアプリケーション開発とは
2. レガシーなシステムへの取り組み⽅
3. モダナイゼーションのためのコンテナ活⽤法
4. まとめ

Secure Resilient Elastic
Modular Automated Interoperable
モダンアプリケーションの能⼒

モダンアプリケーション開発のベストプラクティス
⎕ アプリケーションのライフサイクル全体に渡ってコンプライアンスとセ
キュリティを構築する
⎕ アプリケーションの構造をマイクロサービスの集まりにする
⎕ 可能な限りサーバーレスの技術で構築する
⎕ アプリケーションのモデリングとインフラにコードを利用する
⎕ CI/CDを利用して高品質な機能を迅速にリリースする
⎕ モニタリングによってアプリケーションの振る舞いの洞察を得る

なぜモダンアプリケーションなのか

ニューノーマル: 企業は益々グローバル化し、
プロダクトは完全にデジタル化している
47%
のCEOは経営層がデ
ジタル・ビジネスを
推進することにチャ
レンジしていると
⾔っている
Source: Gartner
79%
のCIOは、デジタ
ル・ビジネスに
よって変化に対応
できる、より柔軟
なIT組織が出来る
と考えている
67%
のビジネスリー
ダーは競争⼒を維
持するためには、
デジタル化のス
ピードを加速させ
る必要があると考
えている

時代の要請 -ビッグバン・ディスラプション
商品開発の劇的な⾼速化
従来の顧客採⽤プロセスが極端に圧縮傾向に
瞬時に広まり瞬時に衰退
VoC (Voice of Customer)か
らアイデアをいち早く形に
して素早く市場に投⼊する
ためには IT が従来のような
オーバーヘッドがかかって
いては話しにならない
https://hbr.org/2013/03/big-bang-disruption

急速なイノベーションがビジネスを進化させる
新たなマーケット
新たな顧客価値New economics
新たなデジタル製品とサービス

Listen
Ideas
アイデア
Experiment
Innovation
Flywheel
実験がイノベーションを加速する
傾聴
実験

アマゾンはどうやってきたか

Amazonにおける開発を振り返る

モノリス型開発サイクル
リリーステスト構築
開発者
サービス配信パイプライン

モノリシックなアーキテクチャの問題点
密結合
メンテナンスと維持が難しい
• ソースコードが複雑に絡み合い、マージ⼀つでも⼀苦労
ビルドやテストがとにかく時間がかかる
デプロイがボトルネック
• デプロイが⼀⼤イベントとなる
1つのプロセスで提供される
スケールが難しい

単⼀⽬的のサービス
HTTPSのAPIのみによる通信
お互いをブラックボックスに
Microservices

Microservices Architecture
マイクロサービスアーキテクチャは1つのアプリケーションを⼩
さなサービスで、各々のプロセスで実⾏され、HTTPのAPIのよ
うなLightweightなメカニズムで通信するようにする開発スタイ
ルのアプローチです。これらのサービスはビジネスケイパビリ
ティから構築され、完全⾃動化された個別のデプロイができま
す。
サービスの集中型のマネジメントを最⼩化し、サービスは異な
るプログラミング⾔語で書かれ、異なるデータストレージが使
われます。
-- James Lewis and Martin Fowler

伝統的なシステムでは開発と運⽤の間に壁がある。
そんな壁はぶん投げてしまえ。
忘れてしまってもいい。Amazonでは不要だ。
you build it, you run it
開発者も⽇々の運⽤に参加しなさい。
そうすればカスタマーのフィードバックが得られる。
これが、サービスの質を⾼めるのだ。
-- Werner Vogels in May 2006 / Amazon.com CTO

Two-pizza teams
全ての所有権
全ての説明責任
良くしようとする動機
“DevOps”

Two Pizza Teamsの働き⽅
”サービスチーム”と呼ぶ
チームはサービスを所有し、構築:
• プロダクトプランニング(ロードマップ)
• 開発
• 運⽤/カスタマーサポート
“You build it, you run it”
⼤きな組織の⼀部分を構成する (Amazon.com, AWS,
Prime, etc)

Microservicesの開発ライフサイクル
開発者デリバリパイプラインサービス
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild
releasetestbuild

= 年間数百万回のデプロイ
数千のチーム
× マイクロサービスアーキテクチャ
× 継続的デリバリー
× 複数の環境
様々なタイプのデプロイ

Self-service Platforms
without Gatekeepers
何千⼈もの⼈々が⼤胆に実験や実⾏が可能な、
強⼒なセルフサービスプラットフォームを
作り出している
そして、Amazonでもそれが使われている

でも既存のアプリケーション
はどうする??

何から着⼿すれば良いのか？
移⾏と⾔うとオンプレを単純に AWS に乗せること（リホスト）を想像しがち
選択肢はそれだけではない
敢えて作り直す（リアーキテクチャ、リビルド）も⼗分あり得る
どんな選択肢があるのか、まず移⾏パスを知る必要がある
28
新規システム構築はクラウド前提とすることで、当初からクラウドの
メリットの享受は可能になるが、問題は既存システム

AWS アプリケーションのモダン化パターン
1つずつ調査し
優先順位付け
Re-platform (lift-tinker-
shift)
VMs à containers
Re-architecture
monolith à microservices
Re-invent (cloud-native)
new serverless microservices
モダン化のパス
を決定
Re-host (lift-and-shift)
data center à EC2

AWS アプリケーションのモダン化パターン
1つずつ調査し
優先順位付け
Re-host (lift-and-shift)
data center à EC2
Re-platform (lift-tinker-
shift)
VMs à containers
Re-architecture
monolith à microservices
Re-invent (cloud-native)
new serverless microservices
モダン化のパス
を決定
（例）ほとんど変更する必要の
ない社内アプリケーション
（例）並列処理が可能な
バッチアプリケーション
（例）機能追加要求が多い
⼤規模アプリケーション
（例）顧客が利⽤する迅速な
リリースとアップデートを繰り
返す新規アプリケーション

アプリケーションのモダン化と移⾏の例
オンプレミス環境 AWS Cloud
サービスA
変更:少
移行難度:高
サービスB
変更:少
移行難度:低
サービスC
変更:多
移行難度:高
サービスD
変更:多
移行難度:低

変更が少ないものはRe-host で対応
サービスA
変更:少
移行難度:高
サービスC
変更:多
移行難度:高
サービスD
変更:多
移行難度:低
サービスB
変更:少
移行難度:小
Re-host
AWS Direct Connect

変更が多いものはモダナイゼーション
サービスA
変更:少
移行難度:高
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低Re-platform
or
Re-architecture

変更が少なく移⾏が難しい場合、現状維持も選択肢
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低
Re-tain
or
Re-tire

移⾏期間中のハイブリットクラウド環境の課題
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低
新サービス
変更:多
モダンアプリケーション
サービスC の開発体験の改善が課題

なぜコンテナか

アプリケーションを構成するコンポーネント
ランタイム/エンジンアプリケーションコード
依存ライブラリ/パッケージ設定

ローカルでは動いたけど、本番で動かない︖
ローカルラップトップステージング / QA 本番
🔥
v6.0.0 v7.0.0 v4.0.0

「コンテナ」という解決策
ランタイム/エンジン
アプリケーションコード
依存ライブラリ/パッケージ

Docker - Build, Share and Run Any App, Anywhere
§ Docker 社が開発
§ Apache 2.0 ライセンス
§ 2013年3⽉ OSS リリース
§ 常駐型コンテナ実⾏エンジン
§ コンテナのライフサイクル管理・デプロイツール

Dockerの登場によってコンテナが再発⾒された
コンテナ⾃体は別に新しい技術ではない。が、Docker が
開発プロセスを整理したことで、主に DevOps の⽂脈でコ
ンテナが再発⾒され、昨今のブームを作っている。
その肝は CLI ツールと Dockerfile とレジストリ
• CLI ツール：直感的な操作
• Dockerfile：シンプルな Provisioning スクリプト
• レジストリ：スムーズにイメージを共有
→ 開発者でも簡単にコンテナイメージを作成・共有できる！

全ての環境で同じコンテナを動かす
ローカルラップトップステージング / QA 本番

なぜコンテナか
§ Docker コンテナの技術的特性
ü アプリケーションの依存物全てを⼀つにパッケージング可能
ü パッケージの統⼀的なデリバリ⽅法を実現するコマンド群
ü コンテナを実⾏するための統⼀的なコマンド群
§ 技術的特性を活かすことで次のような効果が期待できる
ü アプリケーション実⾏環境の再現容易性
ü アプリケーションの可搬性
ü ⾼速な開発とリリースサイクルの実現

サーバ上でのコンテナ実⾏(docker の場合)
$ ssh …
イメージレジストリ
Docker
Engine
EC2 インスタンス
# docker run ...
コンテナ
イメージのダウンロード
コンテナ
イメージ

⼿作業でのコンテナイメージダウンロードと実⾏は
⾮効率かつミスオペレーションを招く
このEC2インスタンス群
でコンテナを実⾏
このコンテナを3つのAZに
分散させて10個デプロイして、
ロードバランサーにつないで、、、

コンテナオーケストレーションの仕組み
API
イメージレジストリ
Container
Runtime
EC2 インスタンス
コンテナ
イメージのダウンロード
コンテナ
イメージ
Orchestrator Agent
API
(コンテナの作成 …)

コンテナオーケストレーションによるクラスター管理
API
Container
Runtime
Orchestrator
Agent
Container
Runtime
Agent
Container
Runtime
Agent
Container
Runtime
Agent
クラスター

54
Kubernetes (k8s)
コンテナオーケストレーション用のOSSプラットフォーム
• 複数のホスト間でコンテナ化された
アプリケーションを管理するオープン
ソースシステム
• デプロイ、メンテナンス、スケーリングといった
基本的な機能を提供
• Cloud Native Computing Foundation (CNCF)
によって管理、推進
• AWSはCNCFのPlatinum Member

Kubernetes でできること (1) 宣⾔的な構成管理の⾃動化
ここでいう「宣⾔的」とは？
• 命令的にコマンドでインフラ構成を指⽰するのではなく、構
成のあるべき状態を設定ファイルで定義すること
命令的な構築宣言的な構築
• アプリ version1 のコンテナをデプロイする
• 負荷が増えたのでサーバ台数を10台増やす
• アプリ version2 のコンテナデプロイする
• 負荷が減ったのでサーバ台数を3台減らす
• 特定のサーバで障害が発生したので、対象のサーバを
ロードバランサから切り離し新しいサーバを配置する
・
・
・
apiVersion: apps/
kind: Deployment
metadata: name: nginx-deployment
spec: selector:
matchLabels:
app: nginx
replicas: 8
template:
metadata:
labels: app: nginx
spec:
containers: - name: nginx image: nginx:1.7.9
ports: - containerPort: 80

• 命令的にコマンドでインフラ構成を指⽰するのではなく、構成のあるべき状態を
設定ファイルで定義すること
命令的な構築のデメリット
？
現状の把握が困難
$ sudo yum update -y
$ yum -y install httpd
$ yum install php
$ yum install php-mysql
$ sudo service httpd start
$ sudo chkconfig httpd on
$ cd /etc/httpd/conf/
$ vi httpd.conf
・
・
Client
開発環境ステージング環境本番環境
コマンド反映
Client
$ yum install php
$ vi httpd.conf
・
・
$ yum install php
$ vi httpd.conf
・
・
環境の複製が困難

• 命令的にコマンドでインフラ構成を指⽰するのではなく、構
成のあるべき状態を設定ファイルで定義すること
宣言的な構築のメリット
Client
開発環境ステージング環境本番環境
反映反映反映
Client
現状の把握が容易
環境の複製が容易設定ファイル

Kubernetes は設定ファイルからクラスタ全体をあるべき状態に収束させる
設定ファイル
設定を適⽤
Kubernetes
クラスタ
反映
• 起動するコンテナの数
• アプリケーションのバー
ジョン
• ロードバランサの設定
• オートスケールの設定
・
・
・
障害などで宣言された
状態が崩れた場合、自
動であるべき状態に復
旧させる
Client
コンテナを3つ起動す
る設定

Kubernetes でできること (2) 多種多様な OSS との連携
各種コミュニティにより開発された多種多様なエコシステムとの連携
• Kubernetes のパッケージマネージャ
• 各 OSS のインストールやパッケージの展開が可能
Prometheus
モニタリング CI/CD
サービスメッシュネットワーキング
CNI CoreDNS

60
Amazon Elastic Kubernetes Service(Amazon EKS)
k8sの「コントロールプレーン」をフルマネージドで提供する
プロビジョニング型のサービス (有料:クラスタあたり0.10 USD/時)
• k8s のリリース(=Upstream)を改変なく利用
• k8s & 関連部分のソフトウェアはあくまでOSS
• CNCFによるk8s準拠の認定を取得
• 既存のk8sエコシステムが完全に動作
→ つまり、ほぼ “素のk8s”
• AWSサービスとの連携もOSSで実装されている
• データプレーン(Workerノード=EC2インスタン
ス)はユーザーが管理
• SLA 99.9 %
(*) 2020/1/21に50%値下げ

移⾏期間中のハイブリットクラウド環境の課題
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低
新サービス
変更:多
コンテナ+k8sの導入によりハイブリット環境でも(ほぼ)一貫した開発体験
(※k8sについて全く同じものが同じように動くわけではありません)

62
ここまでのまとめ
• モダンアプリケーション開発により、現代のビジネスに
求められる⾼速なイノベーションを実現
• 既存のアプリケーションも特性に応じた移⾏パスでモダ
ナイゼーションできる
• 移⾏中のハイブリットクラウド環境におけるコンテナ活
⽤により、⼀貫した開発体験を実現

次の課題: 複数環境のk8sクラスタの管理は??
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低
新サービス
変更:多
複数の環境で稼働するクラスタの管理をどうする??

ここからはRancher Labs 様よろしくお願いします
サービスC
変更:多
移行難度:高
サービスB
変更:少
移行難度:低
AWS Direct Connect
サービスD
変更:多
移行難度:低
新サービス
変更:多

ハイブリットクラウド環境におけるモダンアプリケーション開発

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à ハイブリットクラウド環境におけるモダンアプリケーション開発

Similaire à ハイブリットクラウド環境におけるモダンアプリケーション開発 (20)

Plus de 政雄金森

Plus de 政雄金森 (7)

Dernier

Dernier (9)