Oracle Code Tokyo 2017 ダウンロード資料

Size: px

Start display at page:

Download "Oracle Code Tokyo 2017 ダウンロード資料"

れれのじま
4 years ago
Views:

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

2 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

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

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

5 How to chose deployment target? 5

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

7 12factor.net/ja/ クラウドとの親和性が高いアプリケーションを開発するための法論 7

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

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

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

11 The 12 Factor App 11

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

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

14 II. Dependencies Application 14

15 II. Dependencies Jackson Log4j Apache Commons lodash Application Application Libraries 15

16 II. Dependencies Application Tomcat Jetty Grizzly/Jersey Express Application Libraries Application Container 16

17 II. Dependencies Application Application Libraries Application Container Language Runtime 17

18 II. Dependencies Application Application Libraries Application Container Language Runtime Operating System 18

19 II. Dependencies 依存関係の明的な宣と分離 Application Application Libraries Application Container VM Container APaaS Function Language Runtime Operating System 19

20 II. Dependencies 依存関係の明的な宣と分離 Application Application Libraries Application Container VM Container APaaS Function Language Runtime Operating System 20

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

36 37

37 38

Oracle パブリック・クラウド・サービス無料トライアル申込手順書

Oracle パブリック・クラウド・サービス無料トライアル申込手順書 Oracle パブリッククラウドサービス無料トライアル申込手順書日本オラクル Oracle Digital Safe Harbor Statement The following is intended to outline our general product direction. It is intended for information purposes only, and may