Presentation Title Here

AWS Black Belt Online Seminar Amazon EC2 Container Service Ryosuke Iwanaga Amazon Web Services Japan Solutions Architect 2016.09 1

Agenda なぜコンテナなのか? Amazon EC2 Container Service 概要 デモ 動的ポートマッピング Service Auto Scaling Spot Fleet TIPS Appendix アップデート 事例 等 2

3 なぜコンテナなのか?

コンテナとは何か? App1 Bins/Libs App2 Bins/Libs OS 仮想化 プロセス隔離 イメージ 自動化 4

なぜコンテナなのか? コンテナは 真新しい技術ではない コンテナは リソース隔離が元々の由来 コンテナは 最近 DevOps のために再発見された 今や コンテナはスタートアップからエンタープライズまで支持を得ている 5

DevOps の実態 開発環境の構成のメンテナンスが必要 Source 開発 テスト 本番で環境に差異がある Build Test Production Provision Config Application Artifact なるほど 全てが必要なんですね テストの需要がバラバラで管理が大変 オートスケールやノード障害対応 6

コンテナを取り入れた DevOps Source Build Test Production Provision Config Application Image コードだけ書いていればいい! 7

コンテナ vs VM コンテナの長所 イミュータブルなイメージ ステートレス スピード ( 起動時間や開発速度 ) コンテナの短所 ステートフルなやり方はうまくいかない ファイルシステムは揮発性 ディスク IO が速くない 粒度を細かく利用率を上げられる リソースを無駄に使ってしまう ホスト毎じゃなくタスク毎 8

ベストプラクティス / アンチパターン ベストプラクティス アプリをコンテナに適応させる 12-Factor app 複雑さを避ける シンプルに保つ タスクに集中する タスク = ジョブの単位 ポータブルに アンチパターン VM ベースの処理やワークフロー コンテナを VM の様に考える " ペットと家畜 " 複雑さを上げてしまう 多すぎる技術が複雑さを増す " ヤクの毛を刈る " ホスト単位で何かを実行させる 出来る限りホストのことは忘れる 9

10 The Twelve-Factor App

Twelve-Factorの主義 I. コードベース VII.ポートバインディング バージョン管理される1つのコードベースと複数デプロイ II. 依存関係 VIII.並行性 依存関係を明示的に宣言し分離する プロセスモデルによってスケールアウトする III.設定 IX. 廃棄容易性 設定を環境変数に格納する 高速な起動とグレースフル停止で堅牢性を最大化する IV.バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う V. ビルド リリース 実行 ビルド リリース 実行の3つのステージを厳密に分離する VI.プロセス X. 開発/本番一致 開発 ステージング 本番環境をできるだけ一致させた状態を保つ XI. ログ ログをイベントストリームとして扱う XII.管理プロセス アプリを1つ又は複数のステートレスなプロセスとして実行 11 ポートバインディングを通してサービスを公開する 管理タスクを1回限りのプロセスとして実行する http://12factor.net/

Twelve-Factor app アーキテクチャ 12 http://12factor.net/

1 台のサーバ上で Docker を扱うのは簡単 App1 Bins/Libs App2 Bins/Libs 13

しかし 複数台のクラスタ上で管理するのは困難 AZ 1 AZ 2 AZ 3 14

コンテナを扱う上で 最も難しい部分 複数ホスト上でのコンテナの管理 配置 状態の追跡 監視 自動化等 想像している以上に たくさんのことを考慮しないといけない しかし これらは70 年代から続く分散システムでのよくある問題 多くのお客様はアプリケーション開発に集中したい 内製のコンテナ管理システムは まるで車輪の再発明 ビジネスの差別化にはつながらないこと あなたの時間の多くは ビジネスを成長させることに使われるべき 15

16 Amazon EC2 Container Service 概要

Amazon EC2 Container Service コンテナ管理をあらゆるスケールで 柔軟なコンテナの配置 AWS の基盤との連携 17

Cluster, Scheduler, Task Scheduler Task Agent Task Definition Cluster Manager 18

Amazon ECS コンポーネント Task Manager Task Definition Scheduler Cluster Agent Instance上で実行されて いる実際のContainer Taskで使うContainer 及び周辺設定の定義 Taskが実行されるEC2 Instance群 19 ClusterのリソースとTask の状態を管理 Clusterの状態をみて Taskを配置 EC2 InstanceとManager の連携を司る

Amazon ECS 機能 Service: ロングランニングアプリケーション Blue/Green デプロイ Auto Scaling 動的ポートマッピング Security: セキュアな環境でコンテナを動かす Task の IAM ロール PCI DSS Simple: インストール不要で AWS ネイティブ連携 AWS の標準 API/CLI/SDK/CloudFormation ECS-CLI 20

21 Amazon ECS: Service

Service とは? ロングランニングアプリケーションを希望する状態に保ち続ける 1. Task Definition 2. Taskの数 3. Load Balancerの登録 / 解除 (Optional) Application Load Balancer との動的ポートマッピング (Optional) コンテナはランダムなホストのポートを使って登録される Application Auto Scaling の Amazon ECS Service サポート (Optional) Alarm と Policy を使って 希望する Task 数を自動的に変更する 22

Service: 動的ポートマッピング Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:1 Desired Count = 4 32874 32879 32873 32880 23 Amazon ECS Cluster

Service: 追加リソース無しの更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:2 Desired Count = 4 Minimum Healthy Percent = 50 Maximum Percent = 100 24 Amazon ECS Cluster

Service: 追加リソース無しの更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:2 Desired Count = 4 Minimum Healthy Percent = 50 Maximum Percent = 100 25 Amazon ECS Cluster

Service: 追加リソース無しの更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:2 Desired Count = 4 Minimum Healthy Percent = 50 Maximum Percent = 100 26 Amazon ECS Cluster

Service: 追加リソース無しの更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:2 Desired Count = 4 Minimum Healthy Percent = 50 Maximum Percent = 100 27 Amazon ECS Cluster

Service: 追加リソース無しの更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:2 Desired Count = 4 Minimum Healthy Percent = 50 Maximum Percent = 100 28 Amazon ECS Cluster

Service: 2 倍のリソースを使った更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 4 Minimum Healthy Percent = 100 Maximum Percent = 200 29 Amazon ECS Cluster

Service: 2 倍のリソースを使った更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 4 Minimum Healthy Percent = 100 Maximum Percent = 200 30 Amazon ECS Cluster

Service: 2 倍のリソースを使った更新 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 4 Minimum Healthy Percent = 100 Maximum Percent = 200 31 Amazon ECS Cluster

Service: Task の追加 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 5 32 Amazon ECS Cluster

Service: ホスト障害時の自動対応 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 5 33 Amazon ECS Cluster

Service: Application Auto Scaling Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 4 ScaleOutAlarm: CPUUtilization > 50 ScaleOutPolicy: +30% when 50 <= CPUUtilization < 60 +50% when 60 <= CPUUtilization < 70 +80% when 70 <= CPUUtilization 34 Amazon ECS Cluster

Service: Application Auto Scaling Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 4 ScaleOutAlarm: CPUUtilization > 50 ScaleOutPolicy: +30% when 50 <= CPUUtilization < 60 +50% when 60 <= CPUUtilization < 70 +80% when 70 <= CPUUtilization 35 Amazon ECS Cluster

Service: Application Auto Scaling Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 5 ScaleOutAlarm: CPUUtilization > 50 ScaleOutPolicy: +30% when 50 <= CPUUtilization < 60 +50% when 60 <= CPUUtilization < 70 +80% when 70 <= CPUUtilization 36 Amazon ECS Cluster

37 Amazon ECS: Security

Task の IAM ロール 各 Task に IAM ロールを指定することができる Task Definition で指定したり run-task 時に指定したり 利点 同一の Container Instance 上で異なる IAM ロールの Task が動く Container Instance の IAM ロールは必要最低限にできる AWS CloudTrail に Task ARN が含まれるので監査もしやすい 前提条件 コンテナ内 : AWS SDK は 2016 年 7 月 13 日以降に公開されたもの Container Instance: ECS Agent 1.12.0+ ネットワークの設定 38

IAM Role for Task AWS IAM DynamoDBRole Amazon DynamoDB AWS IAM S3Role Amazon S3 Amazon ECS AWS IAM ECSRole Container Instance 39

40 Amazon ECS: Simple

Amazon ECS is so simple マスターサーバ群が不要 クラスタ管理ソフト自体を管理する必要がなくなる Service や Run Task といった 便利なビルトインスケジューラ AWS SDK/CLI/CloudFormation で期待通りの動作 よく定義された標準的な AWS API が提供 他の AWS リソースの様にコンテナを操作することができる AWS とネイティブな連携 他の AWS サービスとの連携が 1 クリックで設定可能 例 : awslogs => Amazon CloudWatch Logs 41

42 デモ

デモ : Service Auto Scaling on Spot Fleet CloudWatch Scheduled Events Load Service <= 毎分の ab の数 (ab -c 1) * N AWS Lambda Application Load Balancer Application Auto Scaling App Service Amazon ECS CloudWatch Alarm Amazon CloudWatch (nginx) * M AWS CloudFormation 43

44

45 TIPS

TIPS フリート管理 モニタリング 複数のログ カナリア 秘匿情報 ドレイン Service discovery 共有ストレージ オーバーコミット GPU トラブルシューティング 46

TIPS: フリート管理 フリート(インスタンス群)をもっと効率よく管理したい ECSだとAuto Scaling Groupを使うしかない TIPS: 複数のインスタンスタイプや購入方法を混ぜる Container InstanceはどんなEC2インスタンスでも構わない Auto Scaling GroupとSpot Fleetは希望のキャパシティを維持してくれる 例 47 CPUとメモリはインスタンス上のものがフル活用される On-demand / RI / Scheduled RI / Spot / Spot Fleet / Spot Block 最小リソース: Reserved Instanceで Auto Scalingの固定台数 追加リソース: Spot Fleetで CPU単位のbid タイプの多様性 Auto Scaling

Spot フリートをコンテナインスタンスとして使う Amazon ECS + Amazon EC2 Spot Fleet c3.4xlarge c3.xlarge r3.8xlarge c3.8xlarge r3.2xlarge r3.2xlarge r3.8xlarge c3.xlarge c3.4xlarge c3.8xlarge c3.4xlarge c3.8xlarge r3.2xlarge r3.8xlarge c3.xlarge 48

TIPS: モニタリング コンテナのログやメトリクスを監視したい VMのモニタリングと違っていて どうやったらいいの TIPS: awslogsがログをamazon CloudWatch Logsに送ってくれる STDOUT/ERRがCloudWath Logsに転送される (12-Factor app式) TIPS: ECS AgentがメトリクスをAmazon CloudWatchに送る Cluster毎: CPU/Memory Utilization, Resorvation Service毎: CPU/Memory Utilization TIPS: サードパーティのソリューションを使う 49 Datadog, Sysdig, Mackerel, 等

Container のログを awslogs 経由で収集 保存 Amazon CloudWatch Logs Amazon S3 ストリーム Amazon CloudWatch Logs Amazon Kinesis 処理 Amazon ECS Amazon CloudWatch Logs AWS Lambda 検索 Amazon CloudWatch Logs Amazon Elasticsearch Service 50 http://docs.aws.amazon.com/amazonecs/latest/developerguide/using_awslogs.html

TIPS: 複数のログ コンテナから複数のログを異なる場所に送りたい アクセスログ アプリケーションログ アクティビティログ デバッグロ グ等 ただ Loggingでは1つの場所にしか送れない TIPS: 後処理で分割する ログが最初の目的地にたどり着いてから 異なる場所に配送する ログの内部の情報に基いて TIPS: Sidecarロガー (VM式のやり方) 51 アプリケーションコンテナはログを一時共有ボリュームに書き込む Sidecarコンテナがそのボリュームから異なる場所にログを転送する

TIPS: カナリア 新しいイメージを1つだけデプロイして 何が起こる かを見たい "カナリア"と呼ばれる方式 ただ Serviceは全てのTaskを自動的に更新してしまう TIPS: 複数Serviceを同じTarget Groupの下に入れる 同じTarget Group配下で: 52 本番用Service: ワークロードに十分なキャパシティ (例: 10 Tasks) カナリア用Service: カナリアに使うだけのリソース (例: 1 Task) カナリアが問題なければ 本番用Serviceを手動で更新する

TIPS: 秘匿情報 実行時にコンテナに秘匿情報を渡したい Task Definitionは環境変数をサポート(12-Factor app式) ただし 平文で定義される TIPS: AWS KMSと連携させる Task用に KMSの鍵にアクセスできるIAMロールを指定する コンテナ内(例: entrypoint)で 鍵を使って暗号文を復号する 53 Task Definitionに暗号化したテキストを使用 Amazon S3に暗号化したテキストを保存

TIPS: ドレイン (続く) Connection drainingしながらインスタンスを回収したい インスタンスを削除すると Serviceが自動でその上のTaskを再配置 ただ ELBからconnectionがdrainされるのを待って欲しい TIPS: まずインスタンスをClusterからderegisterする インスタンスをderegisterすると Serviceは自動でその上のTaskをELBか らも解除してくれ connection drainingされる 54 Task自体はClusterから消えても走りつづけている Connection drainingがタイムアウトしたら もうトラフィックは無いの で安全にインスタンスを削除できる

TIPS: ドレイン TIPS: Auto Scaling Lifecycle Hooks と連携 スケールイン時インスタンスは Terminating:Wait 状態になれる そのフックイベントで インスタンスを Cluster から deregister TIPS: Spot インスタンスの削除通知 Spot の価格が Bid 価格を超えたら そのインスタンスはメタデータ経由で削除が通知される インスタンスがそのイベントを受け取ったら deregister 55

TIPS: Service discovery Service discovery を Amazon ECS でやりたい アプリケーション内から 他の Service にアクセスしたい ただ 各コンテナの場所を探すのが大変 TIPS: ALB をエンドポイントとして使う 各コンテナが Service のコンテナの場所を知る必要はない ALB が Service へのリクエストを自動的にバランスもしてくれる 動的ポートマッピングも ALB が吸収してくれる Service の発見には命名規則が役立つ example.local/auth => Target Group for Auth Service 56

TIPS: 共有ストレージ コンテナがインスタンスをまたがって共有データにアクセス コンテナはインスタンスのボリュームにはアクセスできる ただ コンテナが再配置されると それはアクセス不能になる TIPS: 共有データはAmazon Elastic File System (EFS) EFSボリュームを全てのインスタンスで同じパスにマウントしておく そのボリュームをTask Definitionで指定する TIPS: データの移動はAmazon Elastic Block Store (EBS) 57 Taskが配置されたら EBSをインスタンスにアタッチし マウントする 再配置されたら そのTask用のボリュームをデタッチし再アタッチする

TIPS: オーバーコミット 空きのリソースを可能な限り使う (オーバーコミット) VM的なやり方で 特に開発環境のマシンで有効 ECSのcpu/memoryはハードリミット TIPS: CPUはハードリミットではない 各ホストのCPUの空きは コンテナのCPUの設定を超えて使われる 競合してくると CPUは割当をベースに制限される CPU = 2 (0.002コア)のTaskも そのホストの複数CPUを全て使える TIPS: Memory Reservationはソフトリミット 58 CPUと同じように Memory Reservationはソフトリミットになる

TIPS: GPU GPU を ECS のリソースとして使いたい ただ ECS は GPU をサポートしていない TIPS: 特権モードと GPU 比例するリソースを使う 特権フラグで コンテナは GPU デバイスにアクセスできる リソースのスケジュールには CPU を GPU の代わりに使える G2 インスタンスは 1 GPU を 8 vcpu 毎に持っている 1 GPU を Task に割り当てるには 8*1,024 CPU を指定する 59

TIPS: トラブルシューティング ECSを使っていて うまく動かなかった 何を調べたらいいの TIPS: ドキュメントのトラブルシューティングへ http://docs.aws.amazon.com/amazonecs/latest/developerg uide/troubleshooting.html 止まったTaskのエラーメッセージ確認 Serviceのイベントメッ セージ ログの場所などなど FAQをもとに更新を続けているので ぜひ参考に AWSサポートも合わせてご活用を 60

61 まとめ

Amazon EC2 Container Service 機能 Service: ロングランニングアプリケーション Security: セキュアな環境でコンテナを動かす Simple: インストール不要で AWS ネイティブ連携 事例 沢山の Amazon ECS のお客様 (Appendix 参照 ) 高速なアップデート 全てがお客様のフィードバックに基づく (Appendix 参照 ) 62

参考資料 Amazon EC2 Container Service https://aws.amazon.com/ecs/ Amazon EC2 Container Service Documents http://docs.aws.amazon.com/amazonecs/latest/developerguide/welcome.html AWS Compute Blog https://aws.amazon.com/blogs/compute/ 63

64

65 Appendix

66 Amazon ECS Updates

Amazon ECS: 2015 年 4 月 2016 年 3 月 GA リリース CloudFormation で ECS をサポート コンソールや CLI から Agent のアップデートが可能に Task Definition の解除と 環境変数の上書き UDP プロトコルのサポート CloudWatch のメトリクスを追加 ECS CLI をリリース Amazon EC2 Container Registry をリリース デプロイのオプションを追加 リージョン拡張 67

Amazon ECS: 2016 年 4 月 2016 年 9 月 Log の設定で awslogs と splunk に対応 Service の Auto Scaling 対応 ECS optimized AMI が Docker 1.11 に Amazon ECR 用の Credential Helper 公開 ECS CLI の v0.3,v0.4 リリース IAM Role が Task 毎に設定可能に PCI DSS 3.2 で ECS も対象に Application Load Balancer 連携で動的ポート対応 net=host 対応 memoryreservation 対応 awslogs で Task ID を Stream 名に含められる様に リージョン拡張 : Service Auto Scaling Amazon ECR 68

Log の設定で awslogs と splunk に対応 サポートしている Logging Driver json-file syslog jornald gelf fluentd awslogs splunk awslogs: CloudWatch Logs Group のみ指定 Stream は Container ID 他の AWS サービス連携 Amazon S3, Amazon Kinesis, AWS Lambda, Amazon ES splunk: Splunk に送信可能 69

Container のログを awslogs 経由で収集 保存 Amazon CloudWatch Logs Amazon S3 ストリーム Amazon CloudWatch Logs Amazon Kinesis 処理 Amazon ECS Amazon CloudWatch Logs AWS Lambda 検索 Amazon CloudWatch Logs Amazon Elasticsearch Service 70

71 Amazon ES 上の Kibana でログを検索

ServiceのAuto Scaling対応 Auto Scaling Policyで ServiceのdesiredCountを 変更可能に CloudWatch Alarmと連携 EC2 Instance側は今まで 通りのAuto Scaling 全リージョンで利用可能 72 https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/

ECS optimized AMI が Docker 1.11 に Amazon Linux ベースの ECS optimized AMI 最新は 2016.03.h (2016 年 09 月現在 ) Docker 1.11.2 ECS Agent 1.12.1 最新の Docker に追従したい場合は? Instance に自分でインストールすれば良い OS は Amazon Linux の必要はなく Ubuntu や CoreOS 等で問題ない 73 http://docs.aws.amazon.com/amazonecs/latest/developerguide/ecs-optimized_ami.html

Amazon ECR 用の Credential Helper 公開 https://github.com/awslabs/amazon-ecr-credential-helper Credential Helper Registry の認証時に呼び出され 認証処理を代行 Docker 1.11 から導入 osxkeychain などと連携する Helper が存在 Amazon ECR 用の Helper を公開 docker login が不要に AWS CLI も不要に ECR のリージョンに関係なく利用可能 Go 言語製 簡単に Mac/Windows 用のバイナリ作成が可能 74 https://aws.amazon.com/blogs/compute/authenticating-amazon-ecr-repositories-for-docker-cli-with-credential-helper/

ECS CLI v0.3,v0.4 リリース v0.3 env_fileのサポート compose serviceでデプロイオプションを指定可能に v0.4 Compose v2フォーマット (services) 対応 環境変数の代入をサポート 作業ディレクトリの.envをデフォルト値として利用 75 https://github.com/aws/amazon-ecs-cli

IAM Role が Task 毎に設定可能に 同じ EC2 インスタンス上でも異なる IAM 権限を扱うことができるようになった Task Definition で設定 Task 毎に上書きも可能 動作環境 ECS Agent 1.11.0 以上 Task 内で使われる AWS SDK が 2016 年 7 月 13 日以降のもの EC2 側で 変数と iptables の設定が必要 ECS Optimized AMI は設定済 76 https://aws.amazon.com/jp/blogs/news/help-secure-container-enabled-applications-with-iam-roles-for-ecs-tasks/

IAM Role が Task 毎に設定可能に 利点 EC2 の IAM Role はホスト側で必要な最低限のものにできるので 安全かつ管理コストも激減 Task に IAM Role を設定しない限り 何の操作もできない CloudTrail のログに TaskArn の情報も入るので どの Task が発行したかが追跡できる ユースケース アプリが使う秘匿情報を KMS で暗号化し S3 に配置 Task 毎に適切な IAM Role を割り振ることで 安全に秘匿情報を管理可能 77 https://aws.amazon.com/jp/blogs/news/help-secure-container-enabled-applications-with-iam-roles-for-ecs-tasks/

PCI DSS 3.2 で ECS も対象に 2016/2017 サイクルのアマゾンウェブサービス PCI DSS 3.2 コンプライアンスパッケージがご利用可能になったことを発表できることを嬉しく思います リクエストによってご利用可能な AWS Attestation of Compliance (AOC) には 最も最近追加された Amazon EC2 Container Service (ECS), AWS Config, および AWS WAF ( ウェブアプリケーションファイやーウォール ) を含む 26 の PCI DSS 認定サービスが掲載されています AWS は この国際的な情報セキュリティおよびコンプライアンスプログラムにコミットしています 新しい基準に対して可能な限り早く再び対応することは 情報セキュリティを最優先としてしている AWS のコミットメントを例証しています 78 https://aws.amazon.com/jp/blogs/news/aws-becomes-first-cloud-service-provider-to-adopt-new-pci-dss-3-2/

Application Load Balancer 連携で動的ポート対応 Service が Target group へ動的ポートマッピング Task Definition で hostport を 0 にしておく Task 起動時に エフェメラルポートから動的に割り当てられる 割り当てらたポート番号で Target group へ登録 1 つの EC2 上に 同一 Task を複数個稼働させられる様に CPU/Memory をより効率良く使うことができる Rule に応じて別の Target group へのルーティング 1 つの ALB で 複数の Service を受けることが可能に より効率の良い Microservice を構築可能に 79 https://aws.amazon.com/jp/blogs/news/powerful-aws-platform-features-now-for-containers/

net=host 対応 memoryreservation 対応 Network として Bridge 以外に Host も選択可能に Task が実行される EC2 のネットワークが Container から直接使うことができる Memory の使用量として Soft limit も設定可能に EC2 側に余力があれば Soft limit を超えても稼働可能 Soft limit のみ設定すれば メモリ使用量をオーバーコミットして Task を稼働させることも可能 80 https://aws.amazon.com/about-aws/whats-new/2016/08/amazon-ec2-container-service-now-supports-networkingmodes-and-memory-reservation/

awslogsでtask IDをStream名に含められる様に awslogs-stream-prefixをtask Definitionnで指定 すると Stream名にTask IDが入る様に Task IDで検索したりフィルタするのが簡単に マネージメントコンソールにCloudWatch Logsへのリンク追加 81 https://aws.amazon.com/blogs/compute/centralized-container-logs-with-amazon-ecs-and-amazon-cloudwatch-logs/

82 Amazon ECS 最近の事例

Segment 顧客のデータを 1 つのハブに収集し 後から分析 マーケティング その他の目的で利用する "Amazon ECS に切替えたことで プロビジョンや可用性を心配する必要なく 稼働中のサービスをとてもシンプルにできました " Calvin French-Owen Cofounder and Chief Technology Officer 以前 インスタンスが基本 手作業でのセットアップ 設定間違い / 同期できない以後 管理が容易に / ステートレス CI/CDパイプラインが自動化 開発に専念できるようになった 83 https://aws.amazon.com/solutions/case-studies/segment/

Mytaxi ヨーロッパ 1,000 万人のユーザに 40 都市 /6 カ国で 45,000 のタクシーを提供 "2015 年 11 月に Docker コンテナアーキテクチャを Amazon ECS に移行し 史上初めて 12 月の新年直前を何の障害もなく大量リクエストを捌くことができました この達成は本当に誇るべきものです " Sebastian Herzberg System Engineer 課題 新年直前にトラフィックが通常の 350% になる 利点 ECS 40 インスタンスで 50 マイクロサービス (500 コンテナ ) デプロイ速度は 3 倍に 全て Spot を使いコストは 40% 減 移行後の 2015 年 初めて新年直前のトラフィックを捌けた 84 https://aws.amazon.com/solutions/case-studies/mytaxi/

Shippable CI/CD を提供するプラットフォーム "Amazon ECS によって 開発者の運用にかける時間をほぼ無くしました 以前はシニア開発者は 80% の時間をバックエンドインフラの管理機能開発に費やしていましたが 今では 80% の時間を顧客向け機能開発に使っています " Avi Cavale CEO & Cofounder 課題 内製のクラスタ管理ツールで Docker を EC2 上で動かしていたが 管理に費やす時間が大きかった Mesos や Kubernetes も検討したが やはり管理工数が大きかった ソリューション ECS は何もインストールせずに利用することができた ECS Service と ELB で 35 の microservices を構成している ECR をレジストリに利用して IAM でセキュアにイメージの権限管理 85 https://aws.amazon.com/solutions/case-studies/shippable/

Expedia 世界最大級の旅行会社 ECS Production Clusters Serving 200 applications 14 instances: 56 apps (+ 19 canaries) 35 instances: 107 apps (+ 23 canaries) 17 instances: 78 apps (+ 25 canaries) Primer - 内部のデプロイツール 様々なアプリのテンプレートを提供 サービス作成は GitHubレポジトリ 作成から パイプライン 監視まで ワンクリックで可能 5 instances: 7 apps (+ 4 canaries) Continuous Delivery to github.com/expediadotcom/c3vis ECS with Primer Charts produced with c3vis: ECS Optimized AMIをベースに CloudFormationを使って設定 インスタンスの入替えを無停止 で実施 86 http://www.slideshare.net/amazonwebservices/deep-dive-on-microservices-and-amazon-ecs-64033400

Amazonのレコメンデーション 複数GPUでの分散ニューラルネットワーク学習で 超大規模な製品レコメンド Apache Sparkから透過的にCPU タスクとGPUタスクを実行 CPU: Amazon EMR GPU: Amazon ECS Dockerを使うことで 自由なラ イブラリを簡単に差し替え可能 DSSTNEを使って モデル並列 やデータ並列で実行 87 http://aws.typepad.com/sajp/2016/07/generating-recommendations-at-amazon-scale-with-apache-spark-and-amazon-dsstne.html

楽観的並行制御モデルによる 複数のスケジューラ実行 88

Amazon ECS: スケジューリング 各スケジューラは定期的に現在の Cluster の状態を取得する Scheduler A Scheduler B Cluster の状態のコピー Cluster 89

Amazon ECS: スケジューリング 各スケジューラは取得した状態を元に Cluster に Task を配置する Run a task Run a task 90

Amazon ECS: スケジューリング もしリソースが既に使われていたら リクエストは拒否される 同じリソースに大して Run a task => トランザクション 91

Amazon ECS Under the Hood WRITE ID N+6 ID N-1 ID N ID N+1 ID N+2 ID N+3 ID N+4 ID N+5 READ ID N+5 92

Amazon ECS Under the Hood WRITE WRITE ID N+3 ID N+6 ID N-1 ID N ID N+1 ID N+2 ID N+3 ID N+4 ID N+5 READ ID N+2 READ ID N+5 93

Amazon ECS: スケジューリング 状態を共有して 楽観的なスケジューリング 全てのスケジューラが Cluster の現在の状態を全て見ることができる 94

95 Scalable