Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless?

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. |
Safe Harbor Statement
The following is intended to outline our general product direction. It is intended
for information purposes only, and may not be incorporated into any contract. It is
not a commitment to deliver any material, code, or functionality, and should not
be relied upon in making purchasing decisions. The development, release, and
timing of any features or functionality described for Oracle’s products remains at
the sole discretion of Oracle.
2

Deploying Cloud Native
Applications:
VMs, Containers, or Functions?
新井庸介 | Yosuke Arai
Principal Cloud Architect
Cloud Technology Business Unit
May, 2017

What are the options for deploying a
Cloud Native application?
4

Deployment Target Types—Examples
Virtual Machine
AWS EC2
Azure VM
Oracle Compute Cloud
IBM Softlayer
…
Functions
(Serverless)
Amazon Lambda
OpenWhisk
Microsoft Functions
Oracle Functions
…
5
Container
Docker, Rocket, RunC,
LXC, …
Application Platform
as a Service (aPaaS)
Heroku, Bluemix, Oracle
Application Container

How to chose deployment target?
6

• クラウド＝現状最もコストとアジリティに優れたプラットフォーム
• プラットフォームとしてのクラウドの特性
–サーバーインスタンスの大きさに制約がある。地理的に分散して配備されている
→サービス分割が必要（巨大なシングルサービスは乗らない可能性）
–性能拡張や可用性向上は複数サーバー利用が前提
→サービスの独立性が高く、スケールアウトや移動に耐える必要あり
–サービス同士をAPIで連結できる
What is Cloud? What is Cloud Native App?
7
App App
Multi region, country, datacenter
App App
SaaS SaaS
Cloud
Native APP

Copyright © 2017, Oracle and/or its affiliates. All rights reserved. | 8
12factor.net/ja/
クラウドとの親和性が高いアプリケーション
を開発するための方法論

Background of 12 factor app
• このドキュメントへの寄稿者は、Herokuプラットフォーム上での仕
事を通して、何百何千ものアプリケーションの開発・運用・スケー
ルに間接的に立ち会った。
• このドキュメントは、多種多様なクラウドアプリケーション開発現
場での私たちの経験と観察をすべてまとめたものである。
特に、アプリケーションが時間と共に有機的に成長する力学、アプ
リケーションのコードベースに取り組む開発者間のコラボレーショ
ンの力学、そしてソフトウェア腐敗によるコストの回避に注目して
いる。
9

12factor.net/ja/
The 12 factor app is
クラウドでスケールするアプリの作り方
移植性が高いアプリの作り方
=環境依存性のコントロール方法
10+ deploys per a day できる開発方法
属人性の排除

The 12 Factors を通してDeployment targetを考える
クラウド時代のWebアプリケーション開発のベストプラクティス
(参考)http://12factor.net/
Ⅰ. コードベース
Ⅱ. 依存関係
Ⅲ. 設定
Ⅳ. バックエンドサービス
Ⅴ. ビルド・リリース・実行
Ⅵ. プロセス
Ⅶ. ポートバインディング
Ⅷ. 並行性
Ⅸ. 廃棄容易性
Ⅹ. 開発/本番一致
Ⅺ. ログ
Ⅻ. 管理プロセス
1つのコードベースと
複数環境へのデプロイ
依存関係の明示的な宣言と
分離
設定の環境への格納
リソースとしてのバックエ
ンドサービス利用
ビルド/リリース/実行の
フェーズの分離
ステートレスなプロセス実
行
プロセスモデルによる
スケールアウト
高速な起動と
グレースフルシャットダウ
ン
開発・テスト・本番におけ
る
実行環境の差異の最小化
イベントストリームとして
扱うログ情報
管理タスクのプロセス実行
ポートバインディングによ
る
サービスの外部公開

The 12 Factor App
12

I. Codebase
• バージョン管理されたコードベース
とアプリは1対1の関係
• コードベースに対しデプロイは複数
存在する
– コードベースは全てのデプロイを通し
て同一
13
1つのコードベースと複数環境へのデプロイ

II. Dependencies
依存関係の明示的な宣言と分離
• 必要パッケージが環境に暗黙的に存在することに依存しない
– すべての依存関係を完全かつ厳密に宣言する
– 実行時には依存関係分離ツールを使って、取り囲んでいるシステムから暗黙
の依存関係が“漏れ出ない”ことを保証する
14

II. Dependencies
15
Application

II. Dependencies
16
Application Libraries
Application
Jackson
Log4j
Apache Commons
lodash
…

II. Dependencies
17
Application
Tomcat
Jetty
Grizzly/Jersey
Express
…

II. Dependencies
18
Language Runtime
Application

II. Dependencies
19
Operating System
Language Runtime
Application

II. Dependencies
Operating System
Language Runtime
Application
VM
Container
Function
APaaS

II. Dependencies
Application
Operating System
Language Runtime
VM
Container
Function
APaaS

III. Config
• Config(設定)の例:
– データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル
– Amazon S3やTwitterなどの外部サービスの認証情報
– デプロイされたホストの正規化されたホスト名など、デプロイごとの値
• 設定はコードから厳密に分離する
– 設定はデプロイごとに大きく異なるが、コードはそうではない。
• 設定は環境変数に格納する
– 環境変数はコードを変更することなくデプロイごとに簡単に変更できる
– 設定ファイルとは異なり、誤ってリポジトリにチェックインされる可能性はほとんどない。
– 環境変数は言語やOSに依存しない標準である。
22
設定をコードから分離する

IV. Backing services
• バックエンドサービス: アプリケーションが通
常の動作の中でネットワーク越しに利用するす
べてのサービス
– 例）DB, MQ, SMTP, Cache, etc.
• 自社管理のサービス(オンプレミス)と他社管理
のサービス(クラウド)を区別しない
– どちらもリソースであり、設定に格納されたURLやそ
の他の情報でアクセスする
– サービスの切り替えにおいて、アプリケーションの
コードに変更を加える必要はない
23
バックエンドサービスをアタッチされたリソースとして扱う
Application
MySQL
Object
Storage
Twitter

Functions
(Serverless)
Container
III. Config / IV. Backing Services
24
Virtual Machine
設定をコードから分離する / サービスはリソースとして扱う
as a Service
考慮ポイント:
動的設定をどう実現するか

V. Build, release, run
• ビルド、リリース、実行の3つのステージを厳密に分離する。
– ビルド: コードベースを実行可能な塊に変換
– リリース: ビルドと設定の両方が含まれ、実行環境ですぐ実行できるよう変換
– 実行: リリースを実行環境の中で実行する
• 各ステージで実施することは他ステージでは行わない
– 例: 実行ステージでコードを変更しビルドしなおす
25
Build RunRelease
Application
Config Application
Config

VI. Processes
• プロセスはステートレスかつシェアードナッシングであるべき
• メモリやディスクにキャッシュされたものが、将来のリクエストや
ジョブにおいて利用できることを決して仮定しない
– セッションスティッキーを期待しない
– 将来のリクエストやジョブが別のプロセスで処理される可能性を考慮する
– セッション状態のデータはそれ用のデータストアに格納すべき
26
アプリケーションは、1つもしくは
複数のステートレスなプロセスとして実行する

VIII. Concurrency
• スレッドモデルとプロセスモデル
– スレッドモデル:プロセスがCPUやメモリを確保、複数スレッドで並行処理
– プロセスモデル:リクエスト量に応じてプロセスを多数起動して処理
• スレッドモデルよりプロセスモデルを採る
– 個々のプロセスが内部で多重化することを禁止するわけではないが、
サーバーのスケールアップには限界がある→プロセス分割できることが重要
– スケールアウトの操作は単純かつ確実なものであること
27
プロセスモデルによってスケールアウトする

Functions
(Serverless)
Container
VI. Processes / VIII. Concurrency
28
Virtual Machine
ステートレス, シェアードナッシングモデル / マルチプロセス
as a Service
考慮ポイント
マルチプロセスのオーケストレーション
• プロセス配置, 管理/監視, スケーラビリティや可用性の確保, 負荷分散, etc.
アプリのスレートレス、シェアードナッシングの度合い
• デプロイの配置に対する依存性, セッションに対する依存性

IX. Disposability
高速な起動とグレースフルシャットダウンで堅牢性を最大化する
• Twelve-Factor Appのプロセスは即座に起動・終了することができる
– リリース作業の迅速化, スケールアウトの迅速化
• グレースフル・シャットダウンを実装
– Web: Listen中止→処理中のリクエストを処理しきる→シャットダウン
– Worker: 処理中のジョブをキューに戻す→シャットダウン
• プロセスは突然の死に対しても堅牢であるべき
– 予期しないグレースフルでない停止もうまく処理できるよう設計すべき
29

X. Dev/prod parity
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
• 開発環境と本番環境のギャップを小さく保つ
– 時間のギャップ: 開発者がリリースしたコードが本番に反映されるまで数日、
数週間、時には数ヶ月かかることがある。
– 人材のギャップ: 開発者が書いたコードをインフラエンジニアがデプロイする。
– ツールのギャップ: 本番デプロイではApache、MySQL、Linuxを使うのに、開
発者がNginx、SQLite、OS Xのようなスタックを使う。
• 利用するバックエンドサービスも開発/本番一致とする
– 悪い例）開発環境ではSQLiteを使い、本番ではPostgreSQL
開発環境ではローカルメモリでキャッシュ、本番ではMemcached
31

Functions
(Serverless)
Container
X. Dev/prod parity
32
Virtual Machine
開発、ステージング、本番環境をできるだけ一致させた状態を保つ
as a Service
考慮ポイント
環境の可搬性
ローカル環境での開発は可能か
動的な設定切り替え

XI. Logs
ログをイベントストリームとして扱う
• Twelve-Factor Appはアプリケーションの出力ストリームの送り先や
ストレージについて一切関知しない
– アプリで独自にログを出力したり管理したりしない
– 標準出力のみを使用
– ログ管理も実行環境側で行う
33

XII. Admin processes
管理タスクを1回限りのプロセスとして実行する
• 1回限りの管理プロセスも、アプリケーションプロセスと全く同じ環
境で実行されるべきである
– 管理プロセス例: DB操作、管理シェル実行など
• 管理用のコードは、同期の問題を避けるためにアプリケーション
コードと一緒にデプロイされるべきである。
34

The 12 Factors
クラウド時代のWebアプリケーション開発のベストプラクティス
(参考)http://12factor.net/
Ⅰ. コードベース
Ⅱ. 依存関係
Ⅲ. 設定
Ⅳ. バックエンドサービス
Ⅴ. ビルド・リリース・実行
Ⅵ. プロセス
Ⅶ. ポートバインディング
Ⅷ. 並行性
Ⅸ. 廃棄容易性
Ⅹ. 開発/本番一致
Ⅺ. ログ
Ⅻ. 管理プロセス
1つのコードベースと
複数環境へのデプロイ
依存関係の明示的な宣言と
分離
設定の環境への格納
リソースとしてのバックエ
ンドサービス利用
ステートレスなプロセス実
行
プロセスモデルによる
スケールアウト
高速な起動と
グレースフルシャットダウ
ン
開発・テスト・本番におけ
る
実行環境の差異の最小化
イベントストリームとして
扱うログ情報
管理タスクのプロセス実行
ポートバインディングによ
る
サービスの外部公開

自由度か、生産性か
• There’s nothing you can’t do with
enough time and investment
• The essential tradeoff is level of
control vs. productivity
• You have to decide what’s more
important/necesssary when
choosing a deployment type
36
Productivity
Control
Virtual
Machine
Container
Function
APaaS

Cloud Native Deployment Target?
Application
37
Operating System
Language Runtime
VM
Container
Function
APaaS
考慮すべきポイント
自由度 or 生産性
依存関係の管理
マルチプロセスの
オーケストレーション
アプリのスレートレス,
シェアードナッシング化
環境の可搬性, ローカル
環境での開発

Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless?

Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless?

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless?

Semelhante a Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless? (20)

Último

Último (10)

Cloud Native Appのデプロイ先に関する考察：VM? コンテナ? aPaaS? or Serverless?

Notas do Editor