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

(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.

(3)

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

…

Container

Docker, Rocket, RunC,

LXC, …

Application Platform

as a Service (aPaaS)

Heroku, Bluemix, Oracle

Application Container

(5)

(6)

• クラウド＝現状最もコストとアジリティに優れたプラットフォーム

• プラットフォームとしてのクラウドの特性

–

サーバーインスタンスの⼤きさに制約がある。地理的に分散して配備されている

→サービス分割が必要（巨⼤なシングルサービスは乗らない可能性）

–

性能拡張や可⽤性向上は複数サーバー利⽤が前提

→サービスの独⽴性が⾼く、スケールアウトや移動に耐える必要あり

–

サービス同士をAPIで連結できる

What is Cloud? What is Cloud Native App?

App

Multi region, country, datacenter

App

SaaS

Cloud

Native APP

(7)

(8)

Background of 12 factor app

• このドキュメントへの寄稿者は、Herokuプラットフォーム上での仕

事を通して、何百何千ものアプリケーションの開発・運⽤・スケー

ルに間接的に⽴ち会った。

• このドキュメントは、多種多様なクラウドアプリケーション開発現

場での私たちの経験と観察をすべてまとめたものである。

特に、アプリケーションが時間と共に有機的に成⻑する⼒学、アプ

リケーションのコードベースに取り組む開発者間のコラボレーショ

ンの⼒学、そしてソフトウェア腐敗によるコストの回避に注目して

いる。

(9)

12factor.net/ja/

The 12 factor app is



クラウドでスケールするアプリの作り方



移植性が⾼いアプリの作り方

=環境依存性のコントロール方法

(10)

The 12 Factors を通してDeployment targetを考える

クラウド時代のWebアプリケーション開発のベストプラクティス

(参考)http://12factor.net/

Ⅰ

. コードベース

Ⅱ

. 依存関係

Ⅲ

. 設定

Ⅳ

. バックエンドサービス

Ⅴ

. ビルド・リリース・実⾏

Ⅵ

. プロセス

Ⅶ

. ポートバインディング

Ⅷ

. 並⾏性

Ⅸ

. 廃棄容易性

Ⅹ

. 開発/本番一致

Ⅺ

. ログ

Ⅻ

. 管理プロセス

1つのコードベースと

複数環境へのデプロイ

依存関係の明示的な宣言と

分離

設定の環境への格納

リソースとしてのバックエ

ンドサービス利⽤

ビルド/リリース/実⾏の

フェーズの分離

ステートレスなプロセス実

⾏

プロセスモデルによる

スケールアウト

⾼速な起動と

グレースフルシャットダウ

ン

開発・テスト・本番におけ

る

実⾏環境の差異の最⼩化

イベントストリームとして

扱うログ情報

管理タスクのプロセス実⾏

ポートバインディングによ

る

サービスの外部公開

(11)

(12)

I. Codebase

• バージョン管理されたコードベース

とアプリは1対1の関係

• コードベースに対しデプロイは複数

存在する

–

コードベースは全てのデプロイを通し

て同一

1つのコードベースと複数環境へのデプロイ

(13)

II. Dependencies

依存関係の明⽰的な宣⾔と分離

• 必要パッケージが環境に暗黙的に存在することに依存しない

–

すべての依存関係を完全かつ厳密に宣言する

–

実⾏時には依存関係分離ツールを使って、取り囲んでいるシステムから暗黙

の依存関係が“漏れ出ない”ことを保証する

(14)

II. Dependencies

(15)

II. Dependencies

Application Libraries

Application

Jackson

Log4j

Apache Commons

lodash

…

(16)

II. Dependencies

Application

Application Container

Tomcat

Jetty

Grizzly/Jersey

Express

…

Application Libraries

(17)

II. Dependencies

Language Runtime

Application

Application Container

Application Libraries

(18)

II. Dependencies

Operating System

Language Runtime

Application

Application Container

Application Libraries

(19)

II. Dependencies

Operating System

Language Runtime

Application

Application Container

Application Libraries

Container

Function

AP

aaS

依存関係の明⽰的な宣⾔と分離

(20)

II. Dependencies

Application

Operating System

Language Runtime

Application Container

Application Libraries

VM

Container

Function

AP

aaS

依存関係の明⽰的な宣⾔と分離

(21)

III. Config

• Config(設定)の例:

–

データベース、Memcached、他のバックエンドサービスなどのリソースへのハンドル

–

Amazon S3やTwitterなどの外部サービスの認証情報

–

デプロイされたホストの正規化されたホスト名など、デプロイごとの値

• 設定はコードから厳密に分離する

–

設定はデプロイごとに⼤きく異なるが、コードはそうではない。

• 設定は環境変数に格納する

–

環境変数はコードを変更することなくデプロイごとに簡単に変更できる

設定ファイルとは異なり、誤ってリポジトリにチェックインされる可能性はほとんどない。

設定をコードから分離する

(22)

IV. Backing services

• バックエンドサービス: アプリケーションが通

常の動作の中でネットワーク越しに利⽤するす

べてのサービス

–

例）DB, MQ, SMTP, Cache, etc.

• ⾃社管理のサービス(オンプレミス)と他社管理

のサービス(クラウド)を区別しない

–

どちらもリソースであり、設定に格納されたURLやそ

の他の情報でアクセスする

–

サービスの切り替えにおいて、アプリケーションの

コードに変更を加える必要はない

バックエンドサービスをアタッチされたリソースとして扱う

Application

MySQL

Object

Storage

Twitter

(23)

Functions

(Serverless)

Container

III. Config / IV. Backing Services

Virtual Machine

設定をコードから分離する / サービスはリソースとして扱う

考慮ポイント:

(24)

V. Build, release, run

• ビルド、リリース、実⾏の3つのステージを厳密に分離する。

–

ビルド: コードベースを実⾏可能な塊に変換

–

リリース: ビルドと設定の両方が含まれ、実⾏環境ですぐ実⾏できるよう変換

–

実⾏: リリースを実⾏環境の中で実⾏する

• 各ステージで実施することは他ステージでは⾏わない

–

例: 実⾏ステージでコードを変更しビルドしなおす

ビルド/リリース/実⾏の

フェーズの分離

Build

Release

Run

Application

Config

Application

(25)

VI. Processes

• プロセスはステートレスかつシェアードナッシングであるべき

• メモリやディスクにキャッシュされたものが、将来のリクエストや

ジョブにおいて利⽤できることを決して仮定しない

–

セッションスティッキーを期待しない

–

将来のリクエストやジョブが別のプロセスで処理される可能性を考慮する

–

セッション状態のデータはそれ⽤のデータストアに格納すべき

アプリケーションは、1つもしくは

複数のステートレスなプロセスとして実⾏する

(26)

VIII. Concurrency

• スレッドモデルとプロセスモデル

–

スレッドモデル:プロセスがCPUやメモリを確保、複数スレッドで並⾏処理

–

プロセスモデル:リクエスト量に応じてプロセスを多数起動して処理

• スレッドモデルよりプロセスモデルを採る

–

個々のプロセスが内部で多重化することを禁止するわけではないが、

サーバーのスケールアップには限界がある→プロセス分割できることが重要

–

スケールアウトの操作は単純かつ確実なものであること

プロセスモデルによってスケールアウトする

(27)

Functions

(Serverless)

Container

VI. Processes / VIII. Concurrency

Virtual Machine

ステートレス, シェアードナッシングモデル / マルチプロセス

考慮ポイント



マルチプロセスのオーケストレーション

• プロセス配置, 管理/監視, スケーラビリティや可⽤性の確保, 負荷分散, etc.



アプリのスレートレス、シェアードナッシングの度合い

• デプロイの配置に対する依存性, セッションに対する依存性

(28)

IX. Disposability

高速な起動とグレースフルシャットダウンで堅牢性を最⼤化する

• Twelve-Factor Appのプロセスは即座に起動・終了することができる

–

リリース作業の迅速化, スケールアウトの迅速化

• グレースフル・シャットダウンを実装

–

Web: Listen中止→処理中のリクエストを処理しきる→シャットダウン

–

Worker: 処理中のジョブをキューに戻す→シャットダウン

• プロセスは突然の死に対しても堅牢であるべき

–

予期しないグレースフルでない停止もうまく処理できるよう設計すべき

(29)

X. Dev/prod parity

開発、ステージング、本番環境をできるだけ一致させた状態を保つ

• 開発環境と本番環境のギャップを⼩さく保つ

–

時間のギャップ: 開発者がリリースしたコードが本番に反映されるまで数日、

数週間、時には数ヶ月かかることがある。

–

人材のギャップ: 開発者が書いたコードをインフラエンジニアがデプロイする。

–

ツールのギャップ: 本番デプロイではApache、MySQL、Linuxを使うのに、開

発者がNginx、SQLite、OS Xのようなスタックを使う。

• 利⽤するバックエンドサービスも開発/本番一致とする

–

悪い例）開発環境ではSQLiteを使い、本番ではPostgreSQL

開発環境ではローカルメモリでキャッシュ、本番ではMemcached

(30)

Functions

(Serverless)

Container

X. Dev/prod parity

Virtual Machine

開発、ステージング、本番環境をできるだけ一致させた状態を保つ

Application Platform

as a Service

考慮ポイント



環境の可搬性



ローカル環境での開発は可能か



動的な設定切り替え

(31)

XI. Logs

ログをイベントストリームとして扱う

• Twelve-Factor Appはアプリケーションの出⼒ストリームの送り先や

ストレージについて一切関知しない

–

アプリで独⾃にログを出⼒したり管理したりしない

–

標準出⼒のみを使⽤

–

ログ管理も実⾏環境側で⾏う

(32)

XII. Admin processes

管理タスクを1回限りのプロセスとして実⾏する

• 1回限りの管理プロセスも、アプリケーションプロセスと全く同じ環

境で実⾏されるべきである

–

管理プロセス例: DB操作、管理シェル実⾏など

• 管理⽤のコードは、同期の問題を避けるためにアプリケーション

コードと一緒にデプロイされるべきである。

(33)

The 12 Factors

クラウド時代のWebアプリケーション開発のベストプラクティス