Building Scalable Application on the CloudKeisuke Nishitani (@Keisuke69)

Amazon Web Services Japan K.K.

ProfileKeisuke NishitaniSolutions Architect, Amazon Web Service Japan K.K

@Keisuke69 Keisuke69

✤ AWSのソリューションアーキテクト✤ Webサービス系✤ モバイル系

✤ クラウドを使ったアプリ開発とかモバイル開発の話しをよくしています✤ モバイルニンジャ1号機✤ RESTおじさん✤ Lambda Wizards

✤ 餃⼦の王将エヴァンジェリスト（⾃称）✤ ブログ: http://keisuke69.hatenablog.jp/

Keisuke69 Keisuke69Keisuke69

Every day is still Day One

「我々はこの先の⻑い道のりから⾒るとStill Day One(まだ1⽇⽬)です。まだ朝⾷も⾷べていません。」

今⽇のお話

スケーラブルなアプリケーション

クラウドネイティブ

クラウドネイティブ = スケーラブルbut

スケーラブル ≠ クラウドネイティブ

クラウドネイティブ？

Photo credit: Samer AlQaisi via VisualHunt / CC BY-SA

クラウドネイティブ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプリケーション

✤クラウドで提供されるサービスを利⽤して効率的にアプリケーションを実装

クラウドネイティブ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプリケーション

✤クラウドで提供されるサービスを利⽤して効率的にアプリケーションを実装

クラウドネイティブ✤クラウドの特性を踏まえ、利点を最⼤限に活かす形で構築されたアプリケーション

✤クラウドで提供されるサービスを利⽤して効率的にアプリケーションを実装

⼤事なのはこっち

クラウドの特性✤障害を前提としたデザイン（Design for failure）✤疎結合✤弾⼒性の実装✤全てのレイヤでセキュリティを担保✤制約を恐れない✤並列処理✤複数あるストレージのオプション

The 12 Factor App

The 12 Factor App✤モダンなWebアプリケーション開発のための⽅法論

✤直接的にクラウドと関連する話しではないが⼀読しておくべき

✤URLhttp://12factor.net/http://12factor.net/ja/（⽇本語訳）

The 12 Factor App✤Codebase - コードベース -

✤バージョン管理されている1つのコードベースと複数のデプロイ✤Dependencies - 依存関係 -

✤依存関係を明⽰的に宣⾔し分離する✤環境に依存しないこと

✤Config - 設定 -✤設定を環境変数に格納する✤設定などの環境によって異なる可能性があるものはOSレベルの環境変数によって注⼊

されるべきである✤Backing services - バックエンドサービス -

✤バックエンドサービスをアタッチされたリソースとして扱う✤データベースやメッセージブローカーといったものはアタッチされたリソースとして

扱う

The 12 Factor App✤Build, release, run - ビルド、リリース、実⾏ -

✤ビルド、リリース、実⾏の3つのステージを厳密に分離する✤Process - プロセス -

✤アプリケーションを1つもしくは複数のステートレスなプロセスとして実⾏する

✤プロセス間で何も共有はしない✤Port binding - ポートバインディング -

✤ポートバインディングを通してサービスを公開する✤Concurrency - 並⾏性 -

✤プロセスモデルによってスケールアウトする✤⽔平⽅向へのプロセスのスケールアウトによって並⾏性を担保する

The 12 Factor App✤Disposability - 廃棄容易性 -

✤⾼速な起動とグレースフルシャットダウンで堅牢性を最⼤化する✤Dev/prod parity - 開発/本番⼀致 -

✤開発、ステージング、本番環境をできるだけ⼀致させた状態を保つ✤CI/CDは各環境が揃っていることで実現される

✤Log - ログ -✤ログをイベントストリームとして扱う✤中央集権的なサービスによってイベントを集約、インデックス化し分析する環

境が実現される✤Admin processes - 管理プロセス -

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

Microservices

Photo credit: wildxplorer via Visual hunt / CC BY

Microservices ArchitectureThe microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storagetechnologies.

-- James Lewis and Martin Fowler

9つのポイント✤Componentization via Services✤Organized around Business Capabilities✤Products not Projects✤Smart endpoints and dumb pipes✤Decentralized Governance✤Decentralized Data Management✤Infrastructure Automation✤Design for failure✤Evolutionary Design

Microservicesとは✤サービスを単⼀のアプリケーションではなく⼩さなサービスの組み合わせで構築する

✤各サービスは独⽴したサービスであり、単⼀でデプロイと実⾏が可能なものである

✤技術的な境界で分割するのではなくビジネスの遂⾏能⼒で分割する✤サービスをデプロイするのに必要な能⼒を持てるように分割する✤組織構造と密接に関連✤機能だけ別チーム・別サービスでDBは共通で持つというようなことはしない

✤サービス間のコミュニケーションは軽量な⼿段を利⽤する✤単⼀アプリにおけるインメモリのメソッド呼び出しではなくなる✤HTTPは最良の選択肢の1つであり、RESTful APIによる呼び出しがよく利⽤さ

れる

Microservicesの利点✤「モノリシック」なシステムからの解放✤単独でデプロイ・実⾏可能であるため、個々のサービスで⾃由にスケールすることが可能

✤各サービスで独⽴性の⾼い実装が可能✤⾔語、DBなど全てのサービスで同じものを使う必要がない✤各サービスごとに最適と思われるものを選択可能

✤サービス間は独⽴しているため、個々の可⽤性の問題が全体に影響しない

✤ビジネス上の境界とより密接にアラインされる✤パラレルな開発とデプロイ✤迅速なデプロイ

The Amazon Way

Photo credit: jurvetson via Visual Hunt / CC BY

Monolithicな開発サイクル

developers

releasetestbuild

delivery pipelineapp

2 Pizza Rule

AMAZON CONFIDENTIAL

Two Pizza Team✤作るものに対する全てを負う

✤プロダクト計画(ロードマップ)✤開発✤運⽤✤サポート

✤You build it, you run it✤DevOps

27

Microservicesな開発サイクル

developers delivery pipelinesservices

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

releasetestbuild

アプリケーションの実装パターン

アプリケーションの実装パターン✤いくつかの典型的なパターンがある

✤シンプルなものから複雑なものまで

✤どのやり⽅が許容できるかはチームで決めること✤短期的にはシンプルなアプローチを取ったほうがいい

✤最初に選んだやり⽅を最後まで貫く必要はない✤柔軟に変更する

Graceful Degradation✤500エラーは返さない✤⼀部に障害やエラーがあっても全体の停⽌を引き起こさず、その他の機能は有効に機能させる

✤最悪な例：

Throttling✤内部サービスによる偶発的なDoSが引き起こされることはよくある問題

✤リクエストに対するスロットリングが基本的な防御⽅法✤スロットリングにはユーザ単位であったり、ソースアドレス単位であったり、あるいはその組み合わせも

✤計測は常に⼤事✤API Gatewayを使えば簡単にできます

Fail Fast✤エラーを検知したらなるべく早く返す✤メモリ不⾜などの問題出会った場合、素早い回復が可能になることが多い

✤エラーの原因が軽減されれば、サービスは再び正常に動作する

Fail Silently✤エラーを内部的に処理した上で、ユーザには成功を⽰すレスポンスを返す✤Webサービスであれば内容がない200 OKを返す✤正常終了のコードを返す

✤当然、内部的にはエラーとなっているため、それを検知するためのロギングは⾏うこと

Static Fallback✤エラー時には何らかの静的なコンテンツもしくは値を返す✤返すコンテンツにはリクエストのコンテキストがわかるものを含めること

✤ハードコーディングせずに変更可能にすること

Retry✤失敗は⼀時的なものが多いのでシンプルにリトライすることで成功することが多い

✤スロットリングに対する対応も同様✤エラーが起きたら、少し待った上でリトライする✤Exponential back offもしくはフィボナッチ数列を利⽤したリトライ間隔の調整を⾏う✤Exponential back off ••• リトライ間隔を指数関数的に⻑くしていくアルゴリズ

ム✤無制限にリトライするのではなくどこかでエラーとして判断することが必要

Caching✤サービス呼び出しに対するレスポンスをキャッシュする✤リクエストを受け取ったら、最初にキャッシュをチェックし、キャッシュがない場合や期限切れの場合にだけバックエンドへとコールする✤レスポンス時にはキャッシュにも書き込みを⾏う✤キャッシュがあった場合はキャッシュを⽤いてレスポンスする

Circuit Breaker✤発⽣したエラー数を記録し、閾値を越えたときにフォールバックプランを実⾏する✤⼀般的にはFail fastと同じくエラーを素早く返す

✤故障箇所を部分的にかつ迅速に切り離すことでサービス全体への影響を防ぐ

✤機能を回復させるために定期的にヘルスチェックする

Think Parallel✤処理を並列化することでレイテンシを⼩さくする

Smooth Internal Traffic✤キューの利⽤

✤コンポーネント間にキューを置いて、内部トラフィックをなだらかにするバッファとして利⽤

✤スパイク的な負荷をハンドリング

Microservicesの考慮点✤分散した複数のコンポーネントを扱うことの難しさ

✤サービス単位で独⽴して実⾏可能な状態にするということはそれだけ⼩さいシステムが増えるということ

✤複数のコンポーネントを協調動作させることの難しさ✤コンポーネント間のコミュニケーションメッセージの増加によるレイテンシ増

✤トランザクションの取り扱いと結果整合性の検討✤サービスディスカバリ✤分散するシステムのテストにおける複雑さ✤分散するシステムの運⽤とデプロイの複雑さ

AWS上で構築する場合のパターン✤API Gateway + Lambda

✤EC2 + ECS

✤EC2 + Elastic Beanstalk

✤EC2 + ELB + ASG + Runtime

AWS上で構築する場合のパターン✤API Gateway + Lambda

✤EC2 + ECS

✤EC2 + Elastic BeanStalk

✤EC2 + ELB + ASG + Runtime

API Gateway + Lambda✤サーバレスアーキテクチャ

✤ELB/EC2を使わずAPI GatewayとLambdaで応答✤Lambdaファンクションから各AWSサー

ビスを利⽤✤EC2を利⽤した別システムへのアクセス

も当然可能

✤運⽤/構築/開発からの解放

✤コスト効率が⾼く、多くの場合コスト減に

Lambda

API Gateway

AWSサービス

S3

CloudFront

Amazon API Gateway

複数バージョンや複数環境へのデプロイを管理

APIの定義とホスティング

クラウド上のリソースへのアクセス認証におけるAWS IAMの活⽤

AWSのAuthを活⽤

バックエンド保護のためのDDoS対策やリクエス

トのスロットリング

ネットワークトラフィックの管理

開発者がAPIの運⽤を気にせずに作成、公開することを可能にするサービス

Amazon API Gateway複数バージョンとステージ

APIキーの作成と配布

リクエスト時におけるAWS SigV4の利⽤

リクエストのスロットリングとモニタリング

バックエンドとしてAWS Lambdaが利⽤可能

Amazon API Gateway

レスポンスをキャッシュ可能

CloudFrontを利⽤したレイテンシの軽減とDDoS対策

iOS、AndroidとJavaScript向けSDKの⾃動⽣成

Swaggerのサポート

Request / Responseにおけるデータ変換

Amazon API Gateway

レスポンスをキャッシュ可能

CloudFrontを利⽤したレイテンシの軽減とDDoS対策

iOS、AndroidとJavaScript向けSDKの⾃動⽣成

Swaggerのサポート

Request / Responseにおけるデータ変換

Lambdaファンクション: ステートレス、トリガーベースのコード実⾏

AWS Lambda

あらゆるスケールで⾼性能費⽤対効果が⾼く効率的

インフラ管理不要

使った分だけの⽀払いリクエスト量に応じて⾃動的に

キャパシティ調整100ms単位のコンピュート課⾦

⾃⾝のコードを持ち込み

標準的な⾔語でコードを実⾏スレッド、プロセス、ファイルやシェルスクリプトも利⽤可能

インフラではなくビジネスロジックに集中可能

コードをアップロードするだけで、Lambdaが全てをハンドリング

AWS Lambda✤インフラを⼀切気にすることなくアプリケーションコードを実⾏できるコンピュートサービス✤実⾏基盤は全てAWSが管理✤AWSサービスと連携させることで簡単にイベントドリブンなアプリケーション

を実装可能✤コード実⾏時間に対しての課⾦でありコスト効率が⾮常に⾼い✤VPC内のリソースへのアクセスも可能

✤Lambda function✤JavaScript（Node.js）およびJava、Pythonで記述✤サードパーティライブラリも利⽤可能

AWSのサービスと連携可能✤Amazon S3✤Amazon Kinesis✤Amazon DynamoDB✤Amazon Cognito✤Amazon SNS✤Alexa AppKit✤Amazon SWF✤Amazon SES inbound mail

✤Amazon CloudWatch Events✤Amazon CloudWatch Logs✤Amazon Connected Home✤AWS IoT✤AWS CodePipeline✤AWS CodeDeploy✤AWS CloudFormation

サーバレスアーキテクチャのメリット✤アプリの開発に多くのメリット

✤バックエンド側のコードが減るため開発コストを最⼩化✤バックエンド側のサーバが減るため運⽤コストを最⼩化✤AWSによってマネージされるため、スケーラビリティやキャパシティ、セキュ

リティの⼼配不要✤⾮常にコスト効率が⾼く、多くの場合コスト減が⾒込める

✤必要に応じてEC2も導⼊できる安⼼感✤汎⽤的なサービスでは実現の難しい、ビジネス固有の要件に関してはEC2を利

⽤して実装✤EC2を利⽤する部分についてもCodeDeployやElastic Beanstalk、OpsWorks等

で⾃動化

よくある課題✤インフラ構築 → 不要✤インフラの運⽤管理

✤キャパシティ✤スケール✤デプロイ✤耐障害性✤モニタリング✤ロギング✤セキュリティパッチの適⽤

✤ビジネスの差別化には直接繋がらない機能のアプリ実装✤認証✤スロットリング✤スケーラビリティの確保

よくある課題✤インフラ構築 → 不要✤インフラの運⽤管理

✤キャパシティ✤スケール✤デプロイ✤耐障害性✤モニタリング✤ロギング✤セキュリティパッチの適⽤

✤ビジネスの差別化には直接繋がらない機能のアプリ実装✤認証✤スロットリング✤スケーラビリティの確保

不要（各サービスが適切にハンドリング）

不要

付加価値を⽣まない重労働からの解放

「何をするか」を書くだけでいい

「何をするか」を書くだけでいいAll you need is code.

However

You need more flexibility?

Use container.

You need longer timeout?

Use container.

AWS上で構築する場合のパターン✤API Gateway + Lambda

✤EC2 + ECS

✤EC2 + Elastic BeanStalk

✤EC2 + ELB + ASG + Runtime

What are containers?

✤プロセスの隔離✤イメージ✤⾃動化

Server

Guest OS

Bins/Libs Bins/Libs

App2App1

Containerのメリット

✤Portable✤Flexible✤Fast✤EfficientServer

Guest OS

Bins/Libs Bins/Libs

App2App1

Containerのメリット

⼀貫性のある環境 ⾼い⽣産性 バージョン管理 効率的なオペレーション

FROM ubuntu:14.04

MAINTAINER John Doe <jdoe@example.com>RUN apt-get update && apt-get install -y curl wget default-jre gitRUN adduser --home /home/sinatra --disabled-password --gecos '' sinatraRUN adduser sinatra sudoRUN echo '%sudo ALL=(ALL) NOPASSWD:ALL' >> /etc/sudoers

USER sinatraRUN curl -sSL https://get.rvm.io | bash -s stable

RUN /bin/bash -l -c "source /home/sinatra/.rvm/scripts/rvm"RUN /bin/bash -l -c "rvm install 2.1.2"RUN /bin/bash -l -c "gem install sinatra"

RUN /bin/bash -l -c "gem install thin"

Package

docker push

docker pullShip

docker runRun

Cluster Management

$ docker run myimage

Server

Guest OS

Bins/Libs Bins/Libs

App2App1

Amazon EC2 Container Service (ECS)

✤Dockerコンテナを複数のEC2インスタンスに分散配置できる

✤⼀時的な計算処理にも、ロングランニングな処理にも対応

✤ELB連携など各種AWSサービスとの親和性

✤Amazon ECS⾃体の利⽤は無料

複数のコンテナをEC2のクラスタ上で⼀元管理できるサービス

Cluster Management Engine

Agent Communication Service API

Key/Value Store

Amazon ECS

AZ

ECS Agent

Container Instance

Task

Container

Task

Container

Docker

AZ

ECS Agent

Container Instance

Task

Container

Task

Container

Docker

ECS Agent

Container Instance

Task

Container

Task

Container

Docker

ELB ELB

User/Scheduler

Cluster管理を簡単に✤クラスタ管理ソフトの導⼊不要✤クラスタの状態管理✤コンテナの管理✤コントロールとモニタリング✤1コンテナから数万コンテナまでスケール

フレキシブルなコンテナ配置✤アプリケーション✤バッチジョブ✤複数のスケジューラ

AWSサービスとの連携✤Elastic Load Balancing✤Amazon Elastic Block Store✤Amazon Virtual Private Cloud✤AWS Identity and Access

Management✤AWS CloudTrail

Service Discovery/Registry?Hashicorp Consul✤DNSもしくはHTTP経由でのエンドポイントの登録と探索

✤エンドポイントへのヘルスチェック✤動的コンフィグレーションなどのための

Key/Valueストア

AWS上で構築する場合のパターン✤API Gateway + Lambda

✤EC2 + ECS

✤EC2 + Elastic BeanStalk

✤EC2 + ELB + ASG + Runtime

普通の話なんで割愛

おまけ

Photo credit: marcopako via VisualHunt.com / CC BY-SA

忘れちゃいけないDevOpsPhoto credit: www.pierrelognoul.be via Visualhunt.com / CC BY-ND

11.6秒 1,079 10,000 30,000

Amazon.comにおけるデプロイ

Amazon.comにおけるデプロイ

1時間あたりの最⾼デプロイ回数

1回のデプロイで同時に変更をうける平均ホスト数

1回のデプロイで同時に変更をうける最⾼ホスト数

平⽇のデプロイ間隔

11.6秒 1,079 10,000 30,000

MonitorProvisionDeployTestBuildCode

Elastic Beanstalk

OpsWorks

CloudWatch

CloudFormation

CodeDeploy

CodeCommit

CodePipeline

AWS DevOps Services

AWS Code services

CodeCommitソースコード管理

CodePipeline継続的デリバリ

CodeDeploy⾃動化されたデプロイ

AWS CodePipeline

✤リリースプロセスの定義✤⾃社システムとのインテグレーション✤パイプラインステータスの可視化✤各リリースの⼀貫した検証

Amazonと同様の継続的デリバリとリリース⾃動化

Build1) Build2) Unit test

1) Deploy2) UI test

Source Beta Production1) Deploy2) Perf test

Gamma1) Deploy canary2) Deploy region 13) Deploy region 2

1) Pull

AWS CodeDeploy

✤簡単で信頼性の⾼いデプロイを実現✤簡単にスケール✤あらゆるサーバにデプロイ可能

TestCodeDeployv1, v2, v3

Production

Dev

リビジョンdeployment groups

AWS CodeCommit

✤S3上に⽤意されたGitプライベートリポジトリ✤⼀般的なGitのツールを利⽤可能✤Amazon S3とDynamoDBを利⽤したスケーラビリティ、可⽤性と信頼性✤ユーザ固有のキーで全リポジトリを⾃動的に暗号化

git pull/push CodeCommit

Git objects inAmazon S3

Git index inAmazon DynamoDB

Encryption keyin AWS KMS

SSH or HTTPS

参考資料✤ Martin Fowlerのブログ

✤ Microserviceshttp://martinfowler.com/articles/microservices.html

✤ Microservices Premiumhttp://martinfowler.com/bliki/MicroservicePremium.html

✤ THE TWELVE-FACTOR APPhttp://12factor.net/http://12factor.net/jp/ (⽇本語)

✤ AWS関連✤ Amazon API Gateway

http://docs.aws.amazon.com/ja_jp/apigateway/latest/developerguide/welcome.html✤ AWS Lambda

http://docs.aws.amazon.com/ja_jp/lambda/latest/dg/welcome.html✤ Amazon ECS

http://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html✤ AWS CodePipeline

http://docs.aws.amazon.com/en_us/codepipeline/latest/userguide/welcome.html✤ AWS CodeDeploy

http://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html✤ AWS CodeCommit

http://docs.aws.amazon.com/codecommit/latest/userguide/welcome.html✤ AWSクラウドサービス活⽤資料集

https://aws.amazon.com/jp/aws-jp-introduction/✤ AWS re:Invent 2015 スライド

http://www.slideshare.net/AmazonWebServices/tag/reinvent2015✤ Exponential Backoff and Jitter

https://www.awsarchitectureblog.com/2015/03/backoff.html