AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
66 likes54,383 views
2016/9/14 AWS Black Belt Online Seminar Amazon EC2 Container Service
![[Aurora事例祭り]Amazon Aurora を使いこなすためのベストプラクティス](https://cdn.slidesharecdn.com/ss_thumbnails/amazonauroratips-170307140000-thumbnail.jpg?width=560&fit=bounds)
More Related Content
What's hot (20)
Viewers also liked (19)
Similar to AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service (20)
![[AWS Start-up ゼミ] よくある課題を一気に解説！〜御社の技術レベルがアップする 2017 夏期講習〜](https://cdn.slidesharecdn.com/ss_thumbnails/awsstartupzemi-2017summer-170816032526-thumbnail.jpg?width=560&fit=bounds)
More from Amazon Web Services Japan (20)
![[20220126] JAWS-UG 2022初頭までに葬ったAWSアンチパターン大紹介](https://cdn.slidesharecdn.com/ss_thumbnails/20220126-anti-220126190603-thumbnail.jpg?width=560&fit=bounds)
Recently uploaded (6)
AWS Black Belt Online Seminar 2016 Amazon EC2 Container Service
- 1. 1 【AWS Black Belt Online Seminar】 Amazon EC2 Container Service Ryosuke Iwanaga Amazon Web Services Japan Solutions Architect 2016.09 2017.04 更新
- 2. 2 Agenda • なぜコンテナなのか？ • Amazon EC2 Container Service概要 • デモ • TIPS • Appendix – アップデート – 事例、等
- 3. 3 なぜコンテナなのか？
- 4. 4 コンテナとは何か？ • OS仮想化 • プロセス隔離 • イメージ • 自動化Server Guest OS Bins/Libs Bins/Libs App2App1
- 5. 5 なぜコンテナなのか？ • コンテナは、真新しい技術ではない • コンテナは、リソース隔離が元々の由来 • コンテナは、最近DevOpsのために再発見された • 今や、コンテナはスタートアップからエンタープラ イズまで支持を得ている
- 6. 6 DevOpsの実態 Build Test ProductionSource Application Artifact Provision Config 開発環境の構成の メンテナンスが必要 開発、テスト、本番で 環境に差異がある。。。 テストの需要がバラバラ で管理が大変。。。。 オートスケールや ノード障害対応。。。 なるほど、 全てが必要なんですね。。。
- 7. 7 コンテナを取り入れたDevOps Build Test ProductionSource Application Image Provision Config コードだけ書いて いればいい！
- 8. 8 コンテナの長所 • イミュータブルなイメージ、ス テートレス • スピード(起動時間や開発速度) • 粒度を細かく利用率を上げられ る コンテナ vs VM コンテナの短所 • ステートフルなやり方はうまく いかない • ファイルシステムは揮発性 • ディスクIOが速くない • リソースを無駄に使ってしまう • ホスト毎じゃなくタスク毎
- 9. 9 ベストプラクティス • アプリをコンテナに適応させる • 12-Factor app • 複雑さを避ける • シンプルに保つ • タスクに集中する • タスク = ジョブの単位 • ポータブルに ベストプラクティス / アンチパターン アンチパターン • VMベースの処理やワークフロー • コンテナをVMの様に考える • "ペットと家畜" • 複雑さを上げてしまう • 多すぎる技術が複雑さを増す • "ヤクの毛を刈る" • ホスト単位で何かを実行させる • 出来る限りホストのことは忘れる
- 11. 11 Twelve-Factorの主義 I. コードベース バージョン管理される1つのコードベースと複数デプロイ II. 依存関係 依存関係を明示的に宣言し分離する III.設定 設定を環境変数に格納する IV.バックエンドサービス バックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行 ビルド、リリース、実行の3つのステージを厳密に分離する VI.プロセス アプリを1つ又は複数のステートレスなプロセスとして実行 VII.ポートバインディング ポートバインディングを通してサービスを公開する VIII.並行性 プロセスモデルによってスケールアウトする IX. 廃棄容易性 高速な起動とグレースフル停止で堅牢性を最大化する X. 開発/本番一致 開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログ ログをイベントストリームとして扱う XII.管理プロセス 管理タスクを1回限りのプロセスとして実行する http://12factor.net/
- 14. 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. 15 コンテナを扱う上で、最も難しい部分 • 複数ホスト上でのコンテナの管理 • 配置、状態の追跡、監視、自動化等 • 想像している以上に、たくさんのことを考慮しないといけない • しかし、これらは70年代から続く分散システムでのよくある問題 • 多くのお客様はアプリケーション開発に集中したい • 内製のコンテナ管理システムは、まるで車輪の再発明 • ビジネスの差別化にはつながらないこと • あなたの時間の多くは、ビジネスを成長させることに使われるべき
- 16. 16 Amazon EC2 Container Service概要
- 17. 17 Amazon EC2 Container Service コンテナ管理を あらゆるスケールで 柔軟なコンテナの配置 AWSの基盤との連携
- 18. 18 Cluster, Scheduler, Task Scheduler ManagerCluster Task Definition Task Agent
- 19. 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. 20 Amazon ECS 機能 • Service: ロングランニングアプリケーション • Blue/Greenデプロイ、Auto Scaling、動的ポートマッピング • Security: セキュアな環境でコンテナを動かす • TaskのIAMロール、PCI DSS • Simple: インストール不要でAWSネイティブ連携 • AWSの標準API/CLI/SDK/CloudFormation、ECS-CLI
- 22. 22 Serviceとは？ • ロングランニングアプリケーションを希望する状態に保ち続ける 1. Task Definition 2. Taskの数 3. Load Balancerの登録/解除 (Optional) • Application Load Balancerとの動的ポートマッピング (Optional) • コンテナはランダムなホストのポートを使って登録される • Application Auto ScalingのAmazon ECS Serviceサポート (Optional) • AlarmとPolicyを使って、希望するTask数を自動的に変更する
- 23. 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. 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. 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. 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. 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. 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. 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. 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. 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. 32 Service: Taskの追加 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 5 ClusterAmazon ECS
- 33. 33 Service: ホスト障害時の自動対応 Service scheduler Elastic Load Balancing Application Load Balancer Task Definition = app:3 Desired Count = 5 ClusterAmazon ECS
- 34. 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. 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. 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
- 38. 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. 39 IAM Role for Task AWS IAM Amazon DynamoDB Amazon S3 Amazon ECS AWS IAM AWS IAM DynamoDBRole S3Role Container Instance ECSRole
- 41. 41 Amazon ECS is so simple • マスターサーバ群が不要 • クラスタ管理ソフト自体を管理する必要がなくなる • ServiceやRun Taskといった、便利なビルトインスケジューラ • AWS SDK/CLI/CloudFormationで期待通りの動作 • よく定義された標準的なAWS APIが提供 • 他のAWSリソースの様にコンテナを操作することができる • AWSとネイティブな連携 • 他のAWSサービスとの連携が、1クリックで設定可能 • 例: awslogs => Amazon CloudWatch Logs
- 42. 42 Amazon EC2 Container Registry (ECR) • 特徴(https://aws.amazon.com/ecr/) – 高可用性、スケーラブル、IAM連携、暗号化 – Dockerコマンドからシームレスに利用可能 – Amazon ECSなども連携済で簡単にデプロイ – 多くのパートナーが既に連携済のレジストリ • 価格体系 (https://aws.amazon.com/ecr/pricing/） – イメージの容量に対して課金 ($0.1/GB/月) – 転送量課金(他のAWSサービス同様) • 無料: 全てのINと同一リージョンへのOUT • 他リージョン、オンプレ等へのOUTは転送量に応じて フルマネージドで使えるDockerレジストリサービス Amazon ECS AWS Elastic Beanstalk
- 43. 43 デモ
- 44. 44 デモ: 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の数
- 45. 45
- 46. 46 PRO TIPS
- 47. 47 PRO TIPS • フリート管理 • モニタリング • 複数のログ • カナリア • 秘匿情報 • ドレイン • Service discovery • 共有ストレージ • オーバーコミット • GPU • CI/CD • トラブルシューティング
- 48. 48 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
- 49. 49 Spotフリートをコンテナインスタンスとして使う Amazon ECS Amazon 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
- 50. 50 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, 等
- 51. 51 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
- 52. 52 TIPS: 複数のログ • コンテナから複数のログを異なる場所に送りたい • アクセスログ、アプリケーションログ、アクティビティログ、デバッグログ等 • ただ、Loggingでは1種類を1箇所にしか送れない • TIPS: 後処理で分割する • ログが最初の目的地にたどり着いてから、ログ内の情報に基いて異なる場所に 配送する • TIPS: Sidecarロガー (VM式のやり方) • アプリケーションコンテナはログを一時共有ボリュームに書き込む • Sidecarコンテナがそのボリュームから異なる場所にログを転送する
- 53. 53 TIPS: カナリア • 新しいイメージを1つだけデプロイして、何が起こる かを見たい • "カナリア"と呼ばれる方式 • ただ、Serviceは全てのTaskを自動的に更新してしまう • TIPS: 複数Serviceを同じTarget Groupの下に入れ • 同じTarget Group配下で: • 本番用Service: ワークロードに十分なキャパシティ (例: 10 Tasks) • カナリア用Service: カナリアに使うだけのリソース (例: 1 Task) • カナリアが問題なければ、本番用Serviceを手動で更新する
- 54. 54 TIPS: 秘匿情報 • 実行時にコンテナに秘匿情報を渡したい • Task Definitionは環境変数をサポート(12-Factor app式) • ただし、平文で定義される • TIPS: Parameter Storeと連携させる • KMSとParameter StoreにアクセスできるIAMロールをTaskに指定 • コンテナ内(例: entrypoint)で、Parameter Storeから取得 • SecureStringではKMSへアクセス出来ないと復号できない https://aws.amazon.com/jp/blogs/news/managing-secrets-for-amazon-ecs-applications-using-parameter-store-and-iam-roles-for-tasks/
- 55. 55 TIPS: ドレイン (続く) • Connection drainingしながらインスタンスを回収し たい • インスタンスを削除すると、Serviceが自動でその上のTaskを再配置 • ただ、ELBからconnectionがdrainされるのを待って欲しい • TIPS: インスタンスをDRAININGにする • 新規Taskは配置されなくなる • インスタンス上のTaskがServiceの場合、不足分をデプロイ設定に 従って補充しつつ、最終的にはTaskを安全に停止してくれる • ELBからDeregisterして、Connection drainingがタイムアウトしてから 停止なのでトラフィックに影響は出ない
- 56. 56 TIPS: ドレイン • TIPS: Auto Scaling Lifecycle Hooksと連携 • スケールイン時インスタンスはTerminating:Wait状態になれる • そのフックイベントで、インスタンスをDRAININGへ • TIPS: Spotインスタンスの削除通知 • 削除の2分前に、そのインスタンスのメタデータ経由で通知される • インスタンスがそのイベントを受け取ったらDRAININGへ https://aws.amazon.com/jp/blogs/news/how-to-automate-container-instance-draining-in-amazon-ecs/
- 57. 57 TIPS: Service discovery • Service discoveryをAmazon ECSでやりたい • アプリケーション内から、他のServiceにアクセスしたい • ただ、各コンテナの場所を探すのが大変 • TIPS: ALBをエンドポイントとして使う • 各コンテナがServiceのコンテナの場所を知る必要はない • ALBがServiceへのリクエストを自動的にバランスもしてくれる • 動的ポートマッピングもALBが吸収してくれる • Serviceの発見には命名規則が役立つ • example.local/auth => Target Group for Auth Service
- 58. 58 TIPS: 共有ストレージ • コンテナがインスタンスをまたがって共有データにアクセス • コンテナはインスタンスのボリュームにはアクセスできる • ただ、コンテナが再配置されると、それはアクセス不能になる • TIPS: 共有データはAmazon Elastic File System (EFS) • EFSボリュームを全てのインスタンスで同じパスにマウントしておく • そのボリュームをTask Definitionで指定する • TIPS: データの移動はAmazon Elastic Block Store (EBS) • Taskが配置されたら、EBSをインスタンスにアタッチし、マウントする • 再配置されたら、そのTask用のボリュームをデタッチし再アタッチする
- 59. 59 TIPS: オーバーコミット • 空きのリソースを可能な限り使う (オーバーコミット) • VM的なやり方で、特に開発環境のマシンで有効 • ECSのcpu/memoryはハードリミット？ • TIPS: CPUはハードリミットではない • 各ホストのCPUの空きは、コンテナのCPUの設定を超えて使われる • CPU = 2 (0.002コア)のTaskも、そのホストの複数CPUを全て使える • 競合してくると、CPUは割当をベースに制限される • TIPS: Memory Reservationはソフトリミット • CPUと同じように、Memory Reservationはソフトリミットになる
- 60. 60 TIPS: GPU • GPUをECSのリソースとして使いたい • ただ、ECSはGPUをサポートしていない • TIPS: 特権モードとGPU比例するリソースを使う • 特権フラグで、コンテナはGPUデバイスにアクセスできる • リソースのスケジュールには、vCPUをGPUの代わりに使える • P2インスタンスは、1 GPU毎に4 vCPUを持っている • 1 GPUをTaskに割り当てるには、4*1,024 CPUを指定する • 複数GPUがある場合の割当は、ファイルロック等を活用
- 61. 61 TIPS: CI/CD • コンテナのCI/CDをやりたい • ECSやECRだけでは実現できない • TIPS: AWS CodePipelineを中心に構成可能 • 全体パイプライン: AWS CodePipeline • イメージビルド: AWS CodeBuild • ECSへのデプロイ: AWS CloudFormation • リファレンスアーキテクチャ https://aws.amazon.com/jp/blogs/news/continuous-deployment-to-amazon-ecs-using-aws-codepipeline-aws-codebuild-amazon-ecr-and-aws-cloudformation/
- 62. 62 TIPS: トラブルシューティング • ECSを使っていて、うまく動かなかった • 何を調べたらいいの？ • TIPS: ドキュメントのトラブルシューティングへ • http://docs.aws.amazon.com/AmazonECS/latest/developerg uide/troubleshooting.html • 止まったTaskのエラーメッセージ確認、Serviceのイベントメッ セージ、ログの場所などなど • FAQをもとに更新を続けているので、ぜひ参考に • AWSサポートも合わせてご活用を
- 63. 63 まとめ
- 64. 64 Amazon EC2 Container Service • 機能 • Service: ロングランニングアプリケーション • Security: セキュアな環境でコンテナを動かす • Simple: インストール不要でAWSネイティブ連携 • 事例 • 沢山のAmazon ECSのお客様 (Appendix参照) • 高速なアップデート • 全てがお客様のフィードバックに基づく(Appendix参照)
- 65. 65 参考資料 • 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/
- 66. 66
- 67. 67 Appendix
- 69. 69 Amazon ECS: 2015年4月〜2016年3月 • GAリリース • CloudFormationでECSをサポート • コンソールやCLIからAgentのアップデートが可能に • Task Definitionの解除と、環境変数の上書き • UDPプロトコルのサポート • CloudWatchのメトリクスを追加 • ECS CLIをリリース • Amazon EC2 Container Registryをリリース • デプロイのオプションを追加 • リージョン拡張
- 70. 70 Amazon ECS: 2016年4月〜2016年7月 • 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も対象に
- 71. 71 Amazon ECS: 2016年8月〜2016年12月 • Application Load Balancer連携で動的ポート対応 • net=host対応、memoryReservation対応 • awslogsでTask IDをStream名に含められる様に • ECS AgentがTaskとImageの自動クリーンアップに対応 • Amazon LinuxのDocker Imageが公開 • イベントストリームがAmazon CloudWatch Eventsへ • OSSとしてBloxをリリース • Windows Serverコンテナ対応開始(β) • Task placement policy導入 • マネージメントコンソールの日本語化
- 72. 72 Amazon ECS: 2017年1月〜2017年4月 • ドキュメントの日本語化 • ECRでDocker Image Manifest V2, Schema 2サポート • コンテナインスタンスのドレインをサポート • Amazon ECS-optimized AMI update for Docker 1.12 • ECS-optimized AMIの更新通知がAmazon SNSで受信可能に • ECS CLI Version 0.5.0でALB, ECR, R4インスタンスをサポート
- 74. 74 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に送信可能
- 75. 75 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 保存 ストリーム 処理 検索
- 77. 77 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/
- 78. 78 ECS optimized AMIがDocker 1.12に • Amazon Linuxベースの ECS optimized AMI • 最新は2016.09.g (2017年03月現在) – Docker 1.12.6 ※ – ECS Agent 1.14.1 • 最新のDockerに追従し たい場合は？ – Instanceに自分でイン ストールすれば良い – OSはAmazon Linuxの 必要はなく、Ubuntuや CoreOS等で問題ない http://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized_AMI.html ※セキュリティアップデートを含むので、デフォルトだと以前のAMIでもDockerのアップデートが実施されます。回避したい場合はこちらを参照下さい。 https://aws.amazon.com/jp/amazon-linux-ami/faqs/?nc1=h_ls#auto_update
- 79. 79 Amazon ECR用のCredential Helper公開 • Credential Helper – Registryの認証時に呼び出され、認証処理を代行 – Docker 1.11から導入 • osxkeychainなどと連携するHelperが存在 • Amazon ECR用のHelperを公開 – AWS CLI不要、docker loginも実行不要 – ECRのリージョンに関係なく利用可能 – Go言語製 • 簡単にLinux/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/
- 80. 80 ECS CLI v0.3, v0.4, v0.5リリース • v0.3 – env_fileのサポート – compose serviceでデプロイオプションを指定可能に • v0.4 – Compose v2フォーマット(services)対応 – 環境変数の代入をサポート – 作業ディレクトリの.envをデフォルト値として利用 • v0.5 – ALBとECRと連携、R4が利用可能に https://github.com/aws/amazon-ecs-cli
- 81. 81 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/
- 82. 82 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/
- 83. 83 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/
- 84. 84 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/
- 85. 85 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/
- 86. 86 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/
- 87. 87 ECS AgentがTaskとImageの自動クリーンアップに対応 • 停止したTaskの情報や、使用されていないImageを自動削除する ことでディスク領域を解放 – ECS Agent 1.13.0以上が必要 • 設定値 – ECS_IMAGE_CLEANUP_INTERVAL • この変数は、イメージの自動クリーンアッププロセスが削除するイメージをチェックする頻 度を指定します。デフォルトでは 30 分ごとですが、より頻繁にイメージを削除するには最 短で 10 分まで短くできます。 – ECS_IMAGE_MINIMUM_CLEANUP_AGE • この変数は、イメージが取得されてから、削除の対象になるまでの期間の最短時間を指定し ます。これは、取得されたばかりのイメージがクリーンアップされるのを防ぐために使用さ れます。デフォルトは 1 時間です。 – ECS_NUM_IMAGES_DELETE_PER_CYCLE • この変数は、1 つのクリーンアップサイクルで削除するイメージの数を指定します。デフォ ルトは 5 で、最小は 1 です。 https://aws.amazon.com/about-aws/whats-new/2016/10/amazon-ec2-container-service-supports-automated-task-and-image-cleanup/
- 88. 88 Amazon LinuxのDocker Imageが公開 • ECRおよびDockerHubで公開中 – Amazon EC2以外でもAmazon Linuxを利用可能に • DockerHubの例 – $ docker run -it amazonlinux bash • TIPS – YUMレポジトリのリージョンがus-east-1なので変更したい場合 • # echo ap-northeast-1 > /etc/yum/vars/awsregion https://aws.amazon.com/about-aws/whats-new/2016/11/introducing-new-amazon-linux-container-image-for-cloud-and-on-premises-workloads/
- 89. 89 イベントストリームがAmazon CloudWatch Eventsへ • ECSで発生したイベントがCloudWatch Eventsに • Lambda, SQS, SNS, Kinesis Streamにイベント通知が可能に • 送られてくるイベント ※2017年1月時点 • コンテナインスタンス状態変化 • タスク状態変化 https://aws.amazon.com/jp/blogs/news/monitor-cluster-state-with-amazon-ecs-event-stream/ Amazon CloudWatch EventsAmazon ECS AWS Lambda Amazon SQS Amazon SNS Amazon Kinesis
- 90. 90 イベントを使ったService Discovery app1-tst 10.1.0.11 db1-tst 10.1.0.14 app2 10.1.0.16 db2 10.1.0.18 my-app 10.1.0.20 websrv1 10.1.0.1 websrv2 10.1.0.2 websrv3 10.1.0.4 app-dev1 10.1.0.9 app-dev2 10.1.0.5 app-dev3 10.1.0.8 db-dev 10.1.0.19 Amazon CloudWatch Events AWS Lambda Amazon Route 53
- 91. 91 OSSとしてBloxリリース • ECSをカスタマイズしたい人向けのツール • 例: カスタムスケジューラを作りたい • プロジェクト • Cluster State Service (CSS): ECSのクラスタの状態のクローン • イベントストリームを受け、継続的に内部KVSを更新 • Daemon Scheduler: スケジューラの例。1タスク-1インスタンス • CSSを使って、インスタンスの追加・削除を検出 https://aws.amazon.com/jp/blogs/news/blox-new-open-source-scheduler-for-amazon-ec2-container-service/ https://blox.github.io/
- 92. 92 Bloxの構成 scheduler cluster state service
- 93. 93 Windows Serverコンテナ対応開始(β) • コンテナインスタンスとしてWindows利用可能に • Windows Server 2016 with Containers AMI利用 • タスク定義のいくつかに利用制限あり • Linux用コンテナを動かしたり、その逆は不可 https://aws.amazon.com/jp/blogs/news/amazon-ecs-support-for-windows-containers-beta/
- 94. 94 Task Placement Policy導入 • タスクの配置をより柔軟にカスタマイズできる • Task Placement Strategy • Random、BinPack、Spread • Task Placement Constraints • DistinctInstance、MemberOf attributes (属性) • 属性: インスタンスタイプ、AZ、または任意の情報 • Task Group • グループ化することで、グループを元に条件制御可能 https://aws.amazon.com/jp/blogs/news/introducing-amazon-ecs-task-placement-policies/
- 95. 95 Task Placement Strategy BinPack Spread
- 96. 96 g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Placement: Spread across Zone and Binpack
- 97. 97 g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small t2.small t2.medium us-east-1aus-east-1d Placement: Targeting Instance Type & Zone
- 98. 98 t2.medium g2.2xlarge t2.micro t2.small t2.small t2.small g2.2xlarge t2.small t2.small t2.small g2.2xlarge t2.small Placement: Services – Distinct Instances
- 99. 99 g2.2xlarge t2.small t2.micro t2.medium t2.medium t2.small g2.2xlarge t2.small us-east-1aus-east-1d g2.2xlarge t2.medium t2.micro t2.small us-east-1c Placement: Affinity and Anti-Affinity
- 100. 100 ECRでDocker Image Manifest V2, Schema 2サポート • イメージに対して複数のtagを付与する事が可能に • Windowsコンテナイメージの保存をサポート • Open Container Initiative (OCI) imageも利用可能 https://aws.amazon.com/jp/about-aws/whats-new/2017/01/amazon-ecr-supports-docker-image-manifest-v2-schema-2/
- 101. 101 コンテナインスタンスのドレインをサポート • 他のタスクに影響を与えずにクラスタからコンテナイン スタンスを削除可能に • 「DRAINING」 に設定されたコンテナインスタンスに は新規タスクが配置されなくなる • Auto Scalingのライフサイクルフックや CloudFormation、CodePipelineを利用して、ローリン グデプロイメントの環境を構築可能 https://aws.amazon.com/jp/about-aws/whats-new/2017/01/amazon-ecs-supports-container-instance-draining/
- 102. 102 コンテナインスタンスのドレイン自動化例 https://aws.amazon.com/jp/blogs/news/how-to-automate-container-instance-draining-in-amazon-ecs/ • ライフサイクルフックにより、インス タンスのterminate:waitを検知して SNS経由でlambdaファンクションを invoke。 • lambdaファンクションによりコンテ ナインスタンスの状態を[Draining」 状態に変更し、SNS経由で別Lambda ファンクションをinvoke。 • Lambdaファンクションによりタスク の状態チェック。動作しているタスク が無い場合にライフサイクルフックを 終了。 • インスタンスがterminateされる。
- 103. 103 ECS-optimized AMIの更新通知がAmazon SNSで受信可能 • 新しいECS-optimized AMIが利用可能になるとSNS経 由で通知を受ける事が可能に • リージョン単位でSNS Topicsをsubscribeする https://aws.amazon.com/jp/about-aws/whats-new/2017/03/introducing-notifications-for-new-amazon-ecs-optimized-ami-releases/
- 104. 104 Amazon ECS 最近の事例
- 105. 105
- 106. 106 C4 R3 M4R3 R3 R3 R3 R3 M4 M4 M4 M4 M4 C4 C4 C4 C4 C4 Map Service Search Service Directions Service
- 107. 107 C4 ECS Cluster R3 M4R3 R3 R3 R3 R3 M4 M4 M4 M4 M4 C4 C4 C4 C4 C4 Map Service Search ServiceDirections Service
- 108. 108
- 109. 109 C4 ECS Cluster R3 R3 R3 R3 R3 R3 M4 M4 M4 M4 M4 M4 C4 C4 C4 C4 C4 Map Service Search ServiceDirections Service Spot Fleet C4 C4 R3 R3
- 110. 110 25% Fewer instances 80-90% Savings per month on EC2
- 112. 112 Segment 顧客のデータを1つのハブに収集し、後から分析、マーケティング、その他の目的で利用する "Amazon ECSに切替えたこ とで、プロビジョンや可用 性を心配する必要なく、稼 働中のサービスをとてもシ ンプルにできました。" Calvin French-Owen Cofounder and Chief Technology Officer 以前 • インスタンスが基本 • 手作業でのセットアップ • 設定間違い / 同期できない 以後 • 管理が容易に / ステートレス • CI/CDパイプラインが自動化 • 開発に専念できるようになった https://aws.amazon.com/solutions/case-studies/segment/
- 113. 113 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年、初めて新年直 前のトラフィックを捌けた https://aws.amazon.com/solutions/case-studies/mytaxi/
- 114. 114 Shippable CI/CDを提供するプラットフォーム "Amazon ECSによって、開発者の 運用にかける時間をほぼ無くしま した。以前はシニア開発者は80% の時間をバックエンドインフラの 管理機能開発に費やしていました が、今では80%の時間を顧客向け 機能開発に使っています" Avi Cavale CEO & Cofounder 課題 • 内製のクラスタ管理ツールでDockerをEC2上 で動かしていたが、管理に費やす時間が大き かった • MesosやKubernetesも検討したが、やはり管 理工数が大きかった ソリューション • ECSは何もインストールせずに利用す ることができた • ECS ServiceとELBで35の microservicesを構成している • ECRをレジストリに利用して、IAMで セキュアにイメージの権限管理 https://aws.amazon.com/solutions/case-studies/shippable/
- 115. 115 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
- 116. 116 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
- 118. 118 Amazon ECS: スケジューリング • 各スケジューラは定期的に現在のClusterの状態を取得する Clusterの状態のコピー Scheduler A Scheduler B Cluster
- 119. 119 Amazon ECS: スケジューリング • 各スケジューラは取得した状態を元にClusterにTaskを配置する Run a task Run a task
- 120. 120 Amazon ECS: スケジューリング • もしリソースが既に使われていたら、リクエストは拒否される 同じリソースに大してRun a task => トランザクション
- 121. 121 Amazon ECS: スケジューリング • 状態を共有して、楽観的なスケジューリング • 全てのスケジューラがClusterの現在の状態を全て見ることができる
- 122. 122 Amazon ECS Under the Hood IDN-1 IDN IDN+1 IDN+2 IDN+3 IDN+4 IDN+5 IDN+6 IDN+5 WRITE READ
- 123. 123 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
- 124. 124 Scalable