Embed Size (px)
Citation preview
1
【AWS Black Belt Online Seminar】Amazon EC2 Container Service
Ryosuke IwanagaAmazon Web Services Japan
Solutions Architect
2016.09
2
Agenda
• なぜコンテナなのか？
• Amazon EC2 Container Service概要
• デモ– 動的ポートマッピング、Service Auto Scaling、Spot Fleet
• TIPS
• Appendix– アップデート
– 事例、等
3
なぜコンテナなのか？
4
コンテナとは何か？
• OS仮想化
• プロセス隔離
• イメージ
• 自動化Server
Guest OS
Bins/Libs Bins/Libs
App2App1
5
なぜコンテナなのか？
• コンテナは、真新しい技術ではない
• コンテナは、リソース隔離が元々の由来
• コンテナは、最近DevOpsのために再発見された
• 今や、コンテナはスタートアップからエンタープライズまで支持を得ている
6
DevOpsの実態
Build Test ProductionSource
Application Artifact
Provision
Config
開発環境の構成のメンテナンスが必要
開発、テスト、本番で環境に差異がある。。。
テストの需要がバラバラで管理が大変。。。。
オートスケールやノード障害対応。。。
なるほど、全てが必要なんですね。。。
7
コンテナを取り入れたDevOps
Build Test ProductionSource
Application Image
Provision
Config
コードだけ書いていればいい！
8
コンテナの長所
• イミュータブルなイメージ、ステートレス
• スピード(起動時間や開発速度)
• 粒度を細かく利用率を上げられる
コンテナ vs VM
コンテナの短所
• ステートフルなやり方はうまくいかない
• ファイルシステムは揮発性
• ディスクIOが速くない
• リソースを無駄に使ってしまう
• ホスト毎じゃなくタスク毎
9
ベストプラクティス
• アプリをコンテナに適応させる• 12-Factor app
• 複雑さを避ける• シンプルに保つ
• タスクに集中する• タスク = ジョブの単位
• ポータブルに
ベストプラクティス / アンチパターン
アンチパターン
• VMベースの処理やワークフロー• コンテナをVMの様に考える• "ペットと家畜"
• 複雑さを上げてしまう• 多すぎる技術が複雑さを増す• "ヤクの毛を刈る"
• ホスト単位で何かを実行させる• 出来る限りホストのことは忘れる
10
The Twelve-Factor App
11
Twelve-Factorの主義
I. コードベースバージョン管理される1つのコードベースと複数デプロイ
II. 依存関係依存関係を明示的に宣言し分離する
III.設定設定を環境変数に格納する
IV.バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う
V. ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する
VI.プロセスアプリを1つ又は複数のステートレスなプロセスとして実行
VII.ポートバインディングポートバインディングを通してサービスを公開する
VIII.並行性プロセスモデルによってスケールアウトする
IX.廃棄容易性高速な起動とグレースフル停止で堅牢性を最大化する
X. 開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ
XI.ログログをイベントストリームとして扱う
XII.管理プロセス管理タスクを1回限りのプロセスとして実行する
http://12factor.net/
13
Server
Guest OS
Bins/Libs Bins/Libs
App2App1
1台のサーバ上でDockerを扱うのは簡単
14
しかし、複数台のクラスタ上で管理するのは困難
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
Server
Guest OS
AZ 1 AZ 2
AZ 3
15
コンテナを扱う上で、最も難しい部分
• 複数ホスト上でのコンテナの管理• 配置、状態の追跡、監視、自動化等
• 想像している以上に、たくさんのことを考慮しないといけない
• しかし、これらは70年代から続く分散システムでのよくある問題
• 多くのお客様はアプリケーション開発に集中したい• 内製のコンテナ管理システムは、まるで車輪の再発明
• ビジネスの差別化にはつながらないこと
• あなたの時間の多くは、ビジネスを成長させることに使われるべき
16
Amazon EC2 Container Service概要
17
Amazon EC2 Container Service
コンテナ管理をあらゆるスケールで
柔軟なコンテナの配置 AWSの基盤との連携
18
Cluster, Scheduler, Task Scheduler
ManagerCluster
Task Definition
Task
Agent
19
Amazon ECS コンポーネント
• Task– Instance上で実行されている実際のContainer
• Task Definition– Taskで使うContainer、及び周辺設定の定義
• Cluster– Taskが実行されるEC2
Instance群
• Manager– ClusterのリソースとTaskの状態を管理
• Scheduler– Clusterの状態をみて、
Taskを配置
• Agent– EC2 InstanceとManagerの連携を司る
20
Amazon ECS 機能
• Service: ロングランニングアプリケーション• Blue/Greenデプロイ、Auto Scaling、動的ポートマッピング
• Security: セキュアな環境でコンテナを動かす• TaskのIAMロール、PCI DSS
• Simple: インストール不要でAWSネイティブ連携• AWSの標準API/CLI/SDK/CloudFormation、ECS-CLI
21
Amazon ECS: Service
22
Serviceとは？
• ロングランニングアプリケーションを希望する状態に保ち続ける1. Task Definition2. Taskの数3. Load Balancerの登録/解除 (Optional)
• Application Load Balancerとの動的ポートマッピング(Optional)
• コンテナはランダムなホストのポートを使って登録される
• Application Auto ScalingのAmazon ECS Serviceサポート(Optional)
• AlarmとPolicyを使って、希望するTask数を自動的に変更する
23
Service: 動的ポートマッピング
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:1
Desired Count = 4
Amazon ECS
32874 32879 32873 32880
Cluster
24
Service: 追加リソース無しの更新
Service scheduler
Task Definition = app:2
Desired Count = 4
Minimum Healthy Percent = 50
Maximum Percent = 100
Elastic Load Balancing
Application Load Balancer
ClusterAmazon ECS
25
Service: 追加リソース無しの更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:2
Desired Count = 4
Minimum Healthy Percent = 50
Maximum Percent = 100
ClusterAmazon ECS
26
Service: 追加リソース無しの更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:2
Desired Count = 4
Minimum Healthy Percent = 50
Maximum Percent = 100
ClusterAmazon ECS
27
Service: 追加リソース無しの更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:2
Desired Count = 4
Minimum Healthy Percent = 50
Maximum Percent = 100
ClusterAmazon ECS
28
Service: 追加リソース無しの更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:2
Desired Count = 4
Minimum Healthy Percent = 50
Maximum Percent = 100
ClusterAmazon ECS
29
Service: 2倍のリソースを使った更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:3
Desired Count = 4
Minimum Healthy Percent = 100
Maximum Percent = 200
ClusterAmazon ECS
30
Service: 2倍のリソースを使った更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:3
Desired Count = 4
Minimum Healthy Percent = 100
Maximum Percent = 200
ClusterAmazon ECS
31
Service: 2倍のリソースを使った更新
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:3
Desired Count = 4
Minimum Healthy Percent = 100
Maximum Percent = 200
ClusterAmazon ECS
32
Service: Taskの追加
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:3
Desired Count = 5
ClusterAmazon ECS
33
Service: ホスト障害時の自動対応
Service scheduler
Elastic Load Balancing
Application Load Balancer
Task Definition = app:3
Desired Count = 5
ClusterAmazon ECS
34
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
ClusterAmazon ECS
35
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
ClusterAmazon ECS
36
Service: Application Auto Scaling
Service scheduler
Cluster
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
Amazon ECS
37
Amazon ECS: Security
38
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+、ネットワークの設定
39
IAM Role for Task
AWS IAM
Amazon
DynamoDB
Amazon S3
Amazon ECS
AWS IAM
AWS IAM
DynamoDBRole
S3Role
Container Instance
ECSRole
40
Amazon ECS: Simple
41
Amazon ECS is so simple
• マスターサーバ群が不要• クラスタ管理ソフト自体を管理する必要がなくなる• ServiceやRun Taskといった、便利なビルトインスケジューラ
• AWS SDK/CLI/CloudFormationで期待通りの動作• よく定義された標準的なAWS APIが提供• 他のAWSリソースの様にコンテナを操作することができる
• AWSとネイティブな連携• 他のAWSサービスとの連携が、1クリックで設定可能• 例: awslogs => Amazon CloudWatch Logs
42
デモ
43
デモ: Service Auto Scaling on Spot Fleet
(nginx) * M
(ab -c 1) * N
AWS
Lambda
Application
Auto Scaling
CloudWatch Alarm Amazon CloudWatch
Application
Load Balancer
AWS CloudFormation
Amazon ECS
Load Service
App Service
CloudWatch
Scheduled Events
<= 毎分のabの数
44
45
TIPS
46
TIPS
• フリート管理
• モニタリング
• 複数のログ
• カナリア
• 秘匿情報
• ドレイン
• Service discovery
• 共有ストレージ
• オーバーコミット
• GPU
• トラブルシューティング
47
TIPS: フリート管理
• フリート(インスタンス群)をもっと効率よく管理したい• ECSだとAuto Scaling Groupを使うしかない？
• TIPS: 複数のインスタンスタイプや購入方法を混ぜる• Container InstanceはどんなEC2インスタンスでも構わない
• CPUとメモリはインスタンス上のものがフル活用される
• On-demand / RI / Scheduled RI / Spot / Spot Fleet / Spot Block
• Auto Scaling GroupとSpot Fleetは希望のキャパシティを維持してくれる
• 例• 最小リソース: Reserved Instanceで、Auto Scalingの固定台数
• 追加リソース: Spot Fleetで、CPU単位のbid、タイプの多様性、Auto Scaling
48
Spotフリートをコンテナインスタンスとして使う
Amazon ECSAmazon EC2
Spot Fleet+
c3.xlarge
c3.xlarge
c3.xlarge
r3.8xlarge
r3.8xlarge
r3.8xlarge
c3.8xlarge
c3.8xlarge
c3.8xlarge
c3.4xlarge
c3.4xlarge
c3.4xlarge
r3.2xlarge
r3.2xlarge
r3.2xlarge
49
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: サードパーティのソリューションを使う• Datadog, Sysdig, Mackerel, 等
50
Containerのログをawslogs経由で収集
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon S3
Amazon Kinesis
AWS Lambda
Amazon Elasticsearch Service
Amazon ECS
保存
ストリーム
処理
検索
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/using_awslogs.html
51
TIPS: 複数のログ
• コンテナから複数のログを異なる場所に送りたい• アクセスログ、アプリケーションログ、アクティビティログ、デバッグログ等
• ただ、Loggingでは1つの場所にしか送れない
• TIPS: 後処理で分割する• ログが最初の目的地にたどり着いてから、異なる場所に配送する• ログの内部の情報に基いて
• TIPS: Sidecarロガー (VM式のやり方)• アプリケーションコンテナはログを一時共有ボリュームに書き込む• Sidecarコンテナがそのボリュームから異なる場所にログを転送する
52
TIPS: カナリア
• 新しいイメージを1つだけデプロイして、何が起こるかを見たい
• "カナリア"と呼ばれる方式
• ただ、Serviceは全てのTaskを自動的に更新してしまう
• TIPS: 複数Serviceを同じTarget Groupの下に入れる• 同じTarget Group配下で:
• 本番用Service: ワークロードに十分なキャパシティ (例: 10 Tasks)
• カナリア用Service: カナリアに使うだけのリソース (例: 1 Task)
• カナリアが問題なければ、本番用Serviceを手動で更新する
53
TIPS: 秘匿情報
• 実行時にコンテナに秘匿情報を渡したい• Task Definitionは環境変数をサポート(12-Factor app式)
• ただし、平文で定義される
• TIPS: AWS KMSと連携させる• Task用に、KMSの鍵にアクセスできるIAMロールを指定する
• コンテナ内(例: entrypoint)で、鍵を使って暗号文を復号する
• Task Definitionに暗号化したテキストを使用
• Amazon S3に暗号化したテキストを保存
54
TIPS: ドレイン (続く)
• Connection drainingしながらインスタンスを回収したい• インスタンスを削除すると、Serviceが自動でその上のTaskを再配置
• ただ、ELBからconnectionがdrainされるのを待って欲しい
• TIPS: まずインスタンスをClusterからderegisterする• インスタンスをderegisterすると、Serviceは自動でその上のTaskをELBからも解除してくれ、connection drainingされる• Task自体はClusterから消えても走りつづけている
• Connection drainingがタイムアウトしたら、もうトラフィックは無いので安全にインスタンスを削除できる
55
TIPS: ドレイン
• TIPS: Auto Scaling Lifecycle Hooksと連携• スケールイン時インスタンスはTerminating:Wait状態になれる
• そのフックイベントで、インスタンスをClusterからderegister
• TIPS: Spotインスタンスの削除通知• Spotの価格がBid価格を超えたら、そのインスタンスはメタデータ経由で削除が通知される
• インスタンスがそのイベントを受け取ったらderegister
56
TIPS: Service discovery
• Service discoveryをAmazon ECSでやりたい• アプリケーション内から、他のServiceにアクセスしたい
• ただ、各コンテナの場所を探すのが大変
• TIPS: ALBをエンドポイントとして使う• 各コンテナがServiceのコンテナの場所を知る必要はない
• ALBがServiceへのリクエストを自動的にバランスもしてくれる
• 動的ポートマッピングもALBが吸収してくれる
• Serviceの発見には命名規則が役立つ• example.local/auth => Target Group for Auth Service
57
TIPS: 共有ストレージ
• コンテナがインスタンスをまたがって共有データにアクセス• コンテナはインスタンスのボリュームにはアクセスできる• ただ、コンテナが再配置されると、それはアクセス不能になる
• TIPS: 共有データはAmazon Elastic File System (EFS)• EFSボリュームを全てのインスタンスで同じパスにマウントしておく• そのボリュームをTask Definitionで指定する
• TIPS: データの移動はAmazon Elastic Block Store (EBS)• Taskが配置されたら、EBSをインスタンスにアタッチし、マウントする• 再配置されたら、そのTask用のボリュームをデタッチし再アタッチする
58
TIPS: オーバーコミット
• 空きのリソースを可能な限り使う (オーバーコミット)• VM的なやり方で、特に開発環境のマシンで有効• ECSのcpu/memoryはハードリミット？
• TIPS: CPUはハードリミットではない• 各ホストのCPUの空きは、コンテナのCPUの設定を超えて使われる
• CPU = 2 (0.002コア)のTaskも、そのホストの複数CPUを全て使える• 競合してくると、CPUは割当をベースに制限される
• TIPS: Memory Reservationはソフトリミット• CPUと同じように、Memory Reservationはソフトリミットになる
59
TIPS: GPU
• GPUをECSのリソースとして使いたい• ただ、ECSはGPUをサポートしていない
• TIPS: 特権モードとGPU比例するリソースを使う• 特権フラグで、コンテナはGPUデバイスにアクセスできる• リソースのスケジュールには、CPUをGPUの代わりに使える
• G2インスタンスは、1 GPUを8 vCPU毎に持っている• 1 GPUをTaskに割り当てるには、8*1,024 CPUを指定する
60
TIPS: トラブルシューティング
• ECSを使っていて、うまく動かなかった• 何を調べたらいいの？
• TIPS: ドキュメントのトラブルシューティングへ• http://docs.aws.amazon.com/AmazonECS/latest/developerg
uide/troubleshooting.html• 止まったTaskのエラーメッセージ確認、Serviceのイベントメッセージ、ログの場所などなど
• FAQをもとに更新を続けているので、ぜひ参考に• AWSサポートも合わせてご活用を
61
まとめ
62
Amazon EC2 Container Service
• 機能• Service: ロングランニングアプリケーション
• Security: セキュアな環境でコンテナを動かす
• Simple: インストール不要でAWSネイティブ連携
• 事例• 沢山のAmazon ECSのお客様 (Appendix参照)
• 高速なアップデート• 全てがお客様のフィードバックに基づく(Appendix参照)
63
参考資料
• 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/
64
65
Appendix
66
Amazon ECS Updates
67
Amazon ECS: 2015年4月〜2016年3月
• GAリリース• CloudFormationでECSをサポート• コンソールやCLIからAgentのアップデートが可能に• Task Definitionの解除と、環境変数の上書き• UDPプロトコルのサポート• CloudWatchのメトリクスを追加• ECS CLIをリリース• Amazon EC2 Container Registryをリリース• デプロイのオプションを追加• リージョン拡張
68
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
69
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に送信可能
70
Containerのログをawslogs経由で収集
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon CloudWatch Logs
Amazon S3
Amazon Kinesis
AWS Lambda
Amazon Elasticsearch Service
Amazon ECS
保存
ストリーム
処理
検索
71
Amazon ES上のKibanaでログを検索
72
ServiceのAuto Scaling対応
• Auto Scaling PolicyでServiceのdesiredCountを変更可能に– CloudWatch Alarmと連携
• EC2 Instance側は今まで通りのAuto Scaling
• 全リージョンで利用可能
https://aws.amazon.com/jp/blogs/news/automatic-scaling-with-amazon-ecs/
73
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等で問題ない
http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html
74
Amazon ECR用のCredential Helper公開
• Credential Helper– Registryの認証時に呼び出され、認証処理を代行
• Docker 1.11から導入– osxkeychainなどと連携するHelperが存在
• Amazon ECR用のHelperを公開– docker loginが不要に
• AWS CLIも不要に
– ECRのリージョンに関係なく利用可能
• Go言語製– 簡単にMac/Windows用のバイナリ作成が可能
https://github.com/awslabs/amazon-ecr-credential-helper
https://aws.amazon.com/blogs/compute/authenticating-amazon-ecr-repositories-for-docker-cli-with-credential-helper/
75
ECS CLI v0.3,v0.4リリース
• v0.3– env_fileのサポート
– compose serviceでデプロイオプションを指定可能に
• v0.4– Compose v2フォーマット(services)対応
– 環境変数の代入をサポート
– 作業ディレクトリの.envをデフォルト値として利用
https://github.com/aws/amazon-ecs-cli
76
IAM RoleがTask毎に設定可能に
• 同じEC2インスタンス上でも異なるIAM権限を扱うことができるようになった– Task Definitionで設定、Task毎に上書きも可能
• 動作環境– ECS Agent 1.11.0以上
– Task内で使われるAWS SDKが、2016年7月13日以降のもの
– EC2側で、変数とiptablesの設定が必要• ECS Optimized AMIは設定済
https://aws.amazon.com/jp/blogs/news/help-secure-container-enabled-applications-with-iam-roles-for-ecs-tasks/
77
IAM RoleがTask毎に設定可能に
• 利点– EC2のIAM Roleはホスト側で必要な最低限のものにできるので、安全かつ管理コストも激減
– TaskにIAM Roleを設定しない限り、何の操作もできない
– CloudTrailのログにTaskArnの情報も入るので、どのTaskが発行したかが追跡できる
• ユースケース– アプリが使う秘匿情報をKMSで暗号化しS3に配置、Task毎に適切なIAM Roleを割り振ることで、安全に秘匿情報を管理可能
https://aws.amazon.com/jp/blogs/news/help-secure-container-enabled-applications-with-iam-roles-for-ecs-tasks/
78
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のコミットメントを例証しています。
https://aws.amazon.com/jp/blogs/news/aws-becomes-first-cloud-service-provider-to-adopt-new-pci-dss-3-2/
79
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を構築可能に
https://aws.amazon.com/jp/blogs/news/powerful-aws-platform-features-now-for-containers/
80
net=host対応、memoryReservation対応
• NetworkとしてBridge以外にHostも選択可能に– Taskが実行されるEC2のネットワークが、Containerから直接使うことができる
• Memoryの使用量としてSoft limitも設定可能に– EC2側に余力があれば、Soft limitを超えても稼働可能
– Soft limitのみ設定すれば、メモリ使用量をオーバーコミットしてTaskを稼働させることも可能
https://aws.amazon.com/about-aws/whats-new/2016/08/amazon-ec2-container-service-now-supports-networking-
modes-and-memory-reservation/
81
awslogsでTask IDをStream名に含められる様に
• awslogs-stream-prefixをTask Definitionnで指定すると、Stream名にTask IDが入る様に
• Task IDで検索したりフィルタするのが簡単に
• マネージメントコンソールにCloudWatch Logsへのリンク追加
https://aws.amazon.com/blogs/compute/centralized-container-logs-with-amazon-ecs-and-amazon-cloudwatch-logs/
82
Amazon ECS最近の事例
83
Segment顧客のデータを1つのハブに収集し、後から分析、マーケティング、その他の目的で利用する
"Amazon ECSに切替えたことで、プロビジョンや可用性を心配する必要なく、稼働中のサービスをとてもシンプルにできました。"
Calvin French-OwenCofounder and Chief Technology Officer
以前
• インスタンスが基本
• 手作業でのセットアップ
• 設定間違い / 同期できない
以後
• 管理が容易に / ステートレス
• CI/CDパイプラインが自動化
• 開発に専念できるようになった
https://aws.amazon.com/solutions/case-studies/segment/
84
Mytaxiヨーロッパ1,000万人のユーザに40都市/6カ国で45,000のタクシーを提供
"2015年11月にDockerコンテナアーキテクチャをAmazon ECSに移行し、史上初めて12月の新年直前を何の障害もなく大量リクエストを捌くことができました。この達成は本当に誇るべきものです。"
Sebastian HerzbergSystem Engineer
課題
• 新年直前にトラフィックが通常の350%になる
利点
• ECS 40インスタンスで、50マイクロサービス(500コンテナ)
• デプロイ速度は3倍に
• 全てSpotを使いコストは40%減
• 移行後の2015年、初めて新年直前のトラフィックを捌けた
https://aws.amazon.com/solutions/case-studies/mytaxi/
85
ShippableCI/CDを提供するプラットフォーム
"Amazon ECSによって、開発者の運用にかける時間をほぼ無くしました。以前はシニア開発者は80%の時間をバックエンドインフラの管理機能開発に費やしていましたが、今では80%の時間を顧客向け
機能開発に使っています"
Avi CavaleCEO & Cofounder
課題• 内製のクラスタ管理ツールでDockerをEC2上
で動かしていたが、管理に費やす時間が大きかった
• MesosやKubernetesも検討したが、やはり管理工数が大きかった
ソリューション
• ECSは何もインストールせずに利用することができた
• ECS ServiceとELBで35のmicroservicesを構成している
• ECRをレジストリに利用して、IAMでセキュアにイメージの権限管理
https://aws.amazon.com/solutions/case-studies/shippable/
86
Expedia世界最大級の旅行会社
• Primer - 内部のデプロイツール– 様々なアプリのテンプレートを提供
– サービス作成は、GitHubレポジトリ作成から、パイプライン、監視までワンクリックで可能
• ECS Optimized AMIをベースにCloudFormationを使って設定
• インスタンスの入替えを無停止で実施
http://www.slideshare.net/AmazonWebServices/deep-dive-on-microservices-and-amazon-ecs-64033400
Continuous Delivery to ECS with Primer
ECS Production Clusters – Serving 200 applications
14 instances: 56 apps (+ 19 canaries) 17 instances: 78 apps (+ 25 canaries)
35 instances: 107 apps (+ 23 canaries) 5 instances: 7 apps (+ 4 canaries)
Charts produced with c3vis: github.com/ExpediaDotCom/c3vis
87
Amazonのレコメンデーション複数GPUでの分散ニューラルネットワーク学習で、超大規模な製品レコメンド
• Apache Sparkから透過的にCPUタスクとGPUタスクを実行– CPU: Amazon EMR
– GPU: Amazon ECS
• Dockerを使うことで、自由なライブラリを簡単に差し替え可能
• DSSTNEを使って、モデル並列やデータ並列で実行
http://aws.typepad.com/sajp/2016/07/generating-recommendations-at-amazon-scale-with-apache-spark-and-amazon-dsstne.html
88
楽観的並行制御モデルによる複数のスケジューラ実行
89
Amazon ECS: スケジューリング
• 各スケジューラは定期的に現在のClusterの状態を取得する
Clusterの状態のコピーScheduler A Scheduler B
Cluster
90
Amazon ECS: スケジューリング
• 各スケジューラは取得した状態を元にClusterにTaskを配置する
Run a taskRun a task
91
Amazon ECS: スケジューリング
• もしリソースが既に使われていたら、リクエストは拒否される
同じリソースに大してRun a task=> トランザクション
92
Amazon ECS Under the Hood
IDN-1 IDN IDN+1 IDN+2 IDN+3 IDN+4 IDN+5
IDN+6
IDN+5
WRITE
READ
93
Amazon ECS Under the Hood
IDN-1 IDN IDN+1 IDN+2 IDN+3 IDN+4 IDN+5
IDN+6IDN+3
IDN+5IDN+2
WRITE WRITE
READREAD
94
Amazon ECS: スケジューリング
• 状態を共有して、楽観的なスケジューリング• 全てのスケジューラがClusterの現在の状態を全て見ることができる
95
Scalable
![[AWS Black Belt Online Seminar] · AWS Black Belt Online Seminar とは ... Amazon VPC / Amazon EC2 / Amazon S3 など ... Windows Server 2012R2, Windows Server 2016 •Windows Vista,](https://img.pdfslide.tips/doc/110x75/5ec3d2b3ffe5527afd0b41f2/aws-black-belt-online-seminar-aws-black-belt-online-seminar-amazon.jpg)
