PowerPoint Presentation

Size: px

Start display at page:

Download "PowerPoint Presentation"

かずひろいしなみ
5 years ago
Views:

1 AWS Black Belt Online Seminar Amazon Container Services Ryosuke Iwanaga, Solutions Architect Amazon Web Services Japan K.K

自己紹介 Ryosuke Iwanaga ( 岩永亮介 ) Twitter/GitHub @riywo

2 自己紹介 Ryosuke Iwanaga ( 岩永亮介 ) Amazon Web Services Japan K. K. Solutions Architect Containers / DevOps / Serverless / Mobile / Developers Before Amazon Software Engineer / Ops Engineer / DBA / etc.

3 内容についての注意点本資料では 2018 年 2 月 14 日時点のサービス内容および価格についてご説明しています最新の情報は AWS 公式ウェブサイト ( にてご確認ください資料作成には十分注意しておりますが資料内の価格と AWS 公式ウェブサイト記載の価格に相違があった場合 AWS 公式ウェブサイトの価格を優先とさせていただきます価格は税抜表記となっています日本居住者のお客様が東京リージョンを使用する場合別途消費税をご請求させていただきます AWS does not offer binding price quotes. AWS pricing is publicly available and is subject to change in accordance with the AWS Customer Agreement available at Any pricing information included in this document is provided only as an estimate of usage charges for AWS services based on certain information that you have provided. Monthly charges will be based on your actual use of AWS services, and may vary from the estimates provided.

4 Agenda コンテナを利用した開発の実際 Amazon Container Services 解説 Amazon Elastic Container Registry (ECR) Amazon Elastic Container Service (ECS) Amazon Elastic Container Service for Kubernetes (EKS) AWS Fargate コンテナCI/CDパイプラインの構築コンテナのAuto Scaling

5 コンテナを利用した開発の実際

6 なぜコンテナが愛されているのか? パッケージング配布イミュータブルインフラストラクチャ

7 コンテナのユースケースマイクロサービスアーキテクチャ多数のマイクロサービスを同じ様に管理非同期ジョブ実行 ( バッチコンピューティング ) ジョブのリクエストに応じた柔軟なスケール継続的インテグレーション継続的デプロイ (CI/CD) 開発テスト本番まで一貫したイメージを利用

8 コンテナを利用した開発に必要な技術要素アプリのステートレス化レジストリコントロールプレーン / データプレーン CI/CDパイプライン

9 アプリのステートレス化コンテナの中に入れるのはステートレスなアプリにコンテナのメリットを最大限活かせるステートが必要なものはコンテナの外に置く例 : RDBMS が必要 Amazon RDS 例 : オブジェクトの保存 Amazon S3 参考 : Twelve-factor Application IV. Backing services

10 レジストリコンテナの起動元となるイメージの置き場所アプリ + 実行環境を push / 実行時に pull して起動高い可用性スケーラビリティが求められる落ちたらデプロイ不能同時に大量にpullされることも自前で持つとその管理コストがかかる Amazon ECR

11 コントロールプレーン / データプレーンコントロールプレーン = コンテナの管理をする場所どこでコンテナを動かす? 生死は? いつ止める? デプロイ時にどういう風に配置する? Amazon ECS / Amazon EKS データプレーン = 実際にコンテナが稼働する場所コントロールプレーンからの指示に従って起動各種状態をコントロールプレーンにフィードバック AWS Fargate / Amazon EC2

12 CI/CD パイプラインアプリのコード変更コンテナのデプロイを管理する自動化することで誰がやっても同じようにデプロイ可能ビルドはもちろん単体テストや統合テスト負荷テストもカナリアデプロイやリージョンデプロイなども途中にマニュアルでの承認を挟んでも良い AWS CodePipeline / AWS CodeBuild コントロールプレーンの違いを吸収することもできる例 : 同じコードから AWS は ECS / オンプレは Kubernetes へ

13 CI/CD pipeline Source Build Deploy AWS CodePipeline AWS CodeCommit AWS CodeBuild Control plane Registry Amazon EC2 Data plane Developer Amazon RDS Amazon S3 Backing service

14 Amazon Container Services 解説

15 Amazon Container Services レジストリ Amazon ECR コントロールプレーン Amazon ECS Amazon EKS データプレーン AWS Fargate

16 Amazon Elastic Container Registry (ECR) フルマネージドの高可用性スケーラブルなレジストリエンドポイントにアクセスできるなら AWS 外からでも利用可能 AWS IAM による強力な認証管理機構 pull のみの権限クロスアカウントアクセスも可能 NEW!! ライフサイクルポリシーでイメージの自動クリーンアップ何日以前や何個以上は自動削除といったルールを組み合わせて設定

17 AWS 上の本番環境のコンテナを支える NEW!! AWS VPC ネットワークモードグローバル展開タスク配置強力なスケジューラ Linux & Windows { } 他の AWS サービスとの深い連携 ECS CLI オートスケーリング CloudWatch メトリクスロードバランサ

18 Amazon Elastic Container Service 450+% 年間アクティブユーザの成長 (2016 年と比較 ) 数億コンテナが毎週起動数百万ものインスタンス上で

19 Task: コンテナ ( 群 ) の実行単位 Task Definition scorekeep:10 Task Definition の情報から起動される family:revision で指定 { "family": scorekeep", "containerdefinitions": [ { "name": scorekeep-frontend", 1 つ以上のコンテナを実行しているリソース Task 内のコンテナ群は同じホスト上で実行 CPU とメモリの上限を指定するそれを元にスケジュールされる } ] "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/fe" }, { "name": scorekeep-api", } "image":"xxx.dkr.ecr.us-east-1.amazonaws.com/api" Task scorekeep-frontend scorekeep-api

20 Service: ロングランニングアプリ用スケジューラ Task の数を希望数に保つ Elastic Load Balancing Task Definition を新しくすると Blue/Green デプロイ ELB と連携することも可能メトリクスに応じて Task 数の Auto Scaling も可能 ( 後述 ) app:1 app:2 Servic e desiredcount: 2 maximumpercent: 200 minimumhealthypercent: 100 Application Auto Scaling

21 IAM Role: Task 毎に異なる権限の AWS 認証が可能 IAM Role を Task 毎に設定可能 AWS SDK を利用していれば自動的に認証情報が得られるアクセス鍵等の埋め込み不要 DynamoDBRole AWS IAM Amazon DynamoDB 自分の Role にない権限は当然利用不可なのでセキュア S3Role AWS IAM Amazon S3

22 AWS VPC ネットワークモード Task 毎に ENI を自動割り当て Security Group を Task 毎に設定可能 NEW!! /16 us-east-1c us-east-1b us-east-1a Subnet /24 Task 内のコンテナは localhost を共有 Link 不要で互いにアクセス可能 VPC 内の他のリソースへ Private IP で通信が可能 Fargate では Public IP の割当も可能 Internet Elastic Network Interface (ENI) Public IP / Private IP / Other Entities in VPC EC2 ELB RDS etc.

23 その他の Amazon ECS の特徴 Amazon CloudWatch Logs と簡単に連携 Amazon CloudWatch Events に各種イベントが流れる [Coming soon] Service Discovery by Route 53 NEW!! EC2 への Task 配置を柔軟に設定可能

26 63% の Kubernetes 利用者が AWS を今日利用している CNCF アンケートより

27 Amazon Elastic Container Service for Kubernetes (EKS) NEW!! (Preview) Tenet 1 Tenet 2 EKS はエンタープライズ企業が本番のワークロードを実行するためのプラットフォームであること Tenet 3 EKS ユーザが他の AWS サービスを使う時シームレスな連携を実現し不要な作業を取り除くこと EKS はネイティブで最新の Kubernetes の体験を提供すること Tenet 4 EKS チームは積極的に Kubernetes プロジェクトに貢献していくこと

28 1) AWS アイデンティティを渡す 2) AWS アイデンティティを検証する kubectl 4) k8s のアクションが許可拒否される k8s API AWS Auth 3) AWS アイデンティティを RBAC で認可する

29 アプリケーションの開発に集中したいアプリ開発してデプロイコンテナの Auto Scale コンテナのセキュリティ管理 Amazon EC2 OS のプロビジョン OS のセキュリティ管理インスタンスの Auto Scale

30 計算リソースの使い方を根本的に変える NEW!! = インスタンス管理不要タスクネイティブ API リソースベースの価格簡素で使いやすく強力な新しいリソース利用モデル

31 Scheduling and Orchestration Cluster Manager Placement Engine EC2 Instance EC2 Instance EC2 Instance ECS agent Docker agent ECS AMI ECS agent Docker agent ECS AMI ECS agent Docker agent ECS AMI

32 タスクに割り当てる CPU とメモリの設定柔軟な設定の選択肢 50 の CPU/ メモリ設定から 1 vcpu = $ / 秒 1 GB Mem = $ / 秒 CPU Memory 256 (.25 vcpu) 512MB, 1GB, 2GB 512 (.5 vcpu) 1GB to 4GB (1GB 刻み ) 1024 (1 vcpu) 2GB to 8GB (1GB 刻み ) 2048 (2 vcpu) 4GB to 16GB (1GB 刻み ) 4096 (4 vcpu) 8GB to 30GB (1GB 刻み )

00001406 x 3600 x 30 = $3.80 30 日分の Memory 料金 10 x 1 x 0.

33 Fargate の料金計算例 0.25 vcpu + 1 GB Mem の Task 10 個の Task が毎日 1 時間実行 30 日分の CPU 料金 10 x 0.25 x x 3600 x 30 = $ 日分の Memory 料金 10 x 1 x x 3600 x 30 = $ 日分のトータル料金 $ $3.81 = $7.61 実際に Task を起動していた vcpu と Memory に対する秒単位の計算ストレージ料金は不要データ転送料は標準その他に利用するサービスは追加料金が発生例 : CloudWatch Logs

34 サービスレベルアグリーメント NEW!! 99.99

35 コンテナ CI/CD パイプラインの構築

36 なぜ CI/CD パイプラインが重要なのか? 誰がやっても同じ様にデプロイできることイメージがどうやって作られどこで使われてるか把握アプリ毎に統一された手法を利用するしかし CI/CD パイプラインの実装や構築自体は典型的な差別化を産まない重労働 AWS CodePipeline / AWS CodeBuild

37 AWS CodePipeline 柔軟な CI/CD パイプラインをフルマネージド Source, Build, Test, Deployを複雑に組合せ並列実行や手動承認も設定可能 Deploy TargetにECS Serviceも対応 NEW!! ユースケーステスト環境にデプロイ後各種テスト実行カナリアリージョンデプロイ

AWS CodeBuild マネージドの実行環境ビルドやテスト等が主な目的実行環境は Docker イメージ各種言語対応の環境 Dockerイメージのビルドも可能 CodePipeline とも連携可能もちろん単体でも利用可能 buildspec.yaml version: 0.

38 AWS CodeBuild マネージドの実行環境ビルドやテスト等が主な目的実行環境は Docker イメージ各種言語対応の環境 Dockerイメージのビルドも可能 CodePipeline とも連携可能もちろん単体でも利用可能 buildspec.yaml version: 0.2 phases: pre_build: commands: - $(aws ecr get-login --region $AWS_DEFAULT_REGION --no-include- ) - REPOSITORY_URI= dkr.ecr.us-east-1.amazonaws.com/fargate-demo - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION cut -c 1-7) build: commands: - docker build -t $REPOSITORY_URI:latest. - docker tag $REPOSITORY_URI:latest $REPOSITORY_URI:$IMAGE_TAG post_build: commands: - docker push $REPOSITORY_URI:latest - docker push $REPOSITORY_URI:$IMAGE_TAG - printf '[{"name":"app","imageuri":"%s"}]' $REPOSITORY_URI:$IMAGE_TAG > imagedefinition.json artifacts: files: imagedefinition.json

Developer デプロイ後の状態確認 Application Load Balancer

39 AWS CodePipeline パイプライン確認手動承認 AWS CodeCommit source code AWS CodeBuild コードのチェックイン docker build & push ビルド済イメージの確認 Developer デプロイ後の状態確認 Application Load Balancer imagedefinition.json registertaskdefinition & updateservice Servic e

40 コンテナの Auto Scaling

41 コンテナの数を Auto Scaling させる何らかのメトリクスに応じてコンテナの数を自動スケールさせたいコンテナの CPU やメモリ使用率リクエスト数コントロールプレーンの課題メトリクスの変化に対してコンテナ数をどの程度変化させれば良い? データプレーンの課題コンテナのスケールに応じてインスタンス数もスケールが必要 ECS の Target Tracking と Fargate の組合せがオススメ

42 Traffic CPU DesiredCount ECS の特徴 : Target Tracking との連携 100% 30 メトリクスに対してターゲットの値を設定するだけ ( 例 : CPU 使用率 50%) 90% 80% 70% 60% 50% その値に近づく様に Application Auto Scaling が自動的に Service の DesiredCount を調整 40% 30% 20% 10% 0% NEW!! ECSではコンソールからも設定可能 ECSServiceAverageCPUUtilization ECSServiceAverageMemoryUtilization ALBRequestCountPerTarget Target CPU Utilization DesiredCount Time

43 Fargate を利用したコンテナ Auto Scaling の優位性 Fargate の場合 Service のスケールに応じて自然にコンテナが起動終了するコンテナの起動時間に対してのみ課金 Servic e EC2 の場合インスタンスのリソースも上手くスケールさせる必要があり煩雑余分に持っているバッファ分もインスタンスの課金が必要 Servic e Amazon EC2 Resource buffer (+~15%)

44 まとめコンテナ開発の要素 Amazon Container Services CI/CD パイプライン Auto Scaling

45 参考資料 Amazon Container Services Page Containers on AWS - State of the Union - CON201 - re:invent 2017 Slides / Video Introducing Amazon EKS - CON215 - re:invent 2017 Slides / Video Deep Dive into Amazon EKS - CON409 - re:invent 2017 Slides / Video Introducing AWS Fargate - CON214 - re:invent 2017 Slides / Video Deep Dive into AWS Fargate - CON333 - re:invent 2017 Slides / Video

46 Q&A

オンラインセミナー資料の配置場所 AWS クラウドサービス活用資料集 https://aws.amazon.

47 オンラインセミナー資料の配置場所 AWS クラウドサービス活用資料集 AWS Solutions Architect ブログ最新の情報セミナー中の Q&A 等が掲載されています

48 公式 Twitter/Facebook AWS 検索もしくは最新技術情報イベント情報お役立ち情報お得なキャンペーン情報などを日々更新しています!

49 AWS の導入お問い合わせのご相談 AWS クラウド導入に関するご質問お見積資料請求をご希望のお客様は以下のリンクよりお気軽にご相談下さい AWS 問い合わせで検索して下さい

50 AWS Well Architected 個別技術相談会お知らせ Well Architected フレームワークに基づく数十個の質問項目を元にお客様が AWS 上で構築するシステムに潜むリスクやその回避方法をお伝えする個別相談会です参加無料毎週火曜木曜開催

51 ご参加ありがとうございました

Presentation Title Here

Presentation Title Here AWS Black Belt Online Seminar Amazon Pinpoint 2017.04.26 アマゾンウェブサービスジャパン株式会社ソリューションアーキテクト清水崇之 0 自己紹介清水崇之ソリューションアーキテクト ( 西日本担当 ) 大阪から沖縄まで西日本のお客様にもプライム対応で参上します AWS 芸人 ( 詳しくは https://www.slideshare.net/shimy_net/)