いまならこう作りたい AWSコンテナ[本格]⼊⾨ハンズオン 2024年版 ハンズオンの構想 「コンテナ設計‧構築本格⼊⾨」の出版から3年経った今聞きたい！コンテナあれこれ

⾺勝 淳史 株式会社ヘンリー所属 @HorseVictory ● Senior Web Engineer ● 書籍の執筆に積極的 ● 猫と戯れるのが好き

今回の発表が刺さる⼈ ● AWSを触っている⽅、触りたい⽅ ● AWSコンテナ[本格]⼊⾨本を持っている⽅ ● AWSコンテナ[本格]⼊⾨本の⾏く末が気になる⽅

当時のハンズオンアーキテクチャ構成図をみる 図：「AWSコンテナ[本格]設計‧構築⼊⾨」より抜粋

当時のハンズオンアーキテクチャ構成図をみる AWSサービスの進化により 変わる部分がたくさんある

ハンズオンアーキテクチャ構成図への⾚ペン先⽣ 図：「AWSコンテナ[本格]設計‧構築⼊⾨」より抜粋

今回の発表のゴール AWSコンテナ[本格]⼊⾨ハンズオンを アップデートされたAWSサービスと組み合わせて ⾃分たちにフィットさせて作れるようにする

今回の発表のゴール AWSコンテナ[本格]⼊⾨ハンズオンを アップデートされたAWSサービスと組み合わせて ⾃分たちにフィットさせて作れるようにする ここが⼤事    ⾃分たちにフィットさせて           

アーキテクチャを⾃分たちにフィットさせるためには？ 取りうる選択肢の把握 × ビジネスゴールを理解

アーキテクチャを⾃分たちにフィットさせるためには？ 取りうる選択肢の把握 × ビジネスゴールを理解 こちらから

ECSに関わるコンテナ周りのアップデートについて 「Amazon ECS & AWS Fargate 今昔物語」より抜粋 https://speakerdeck.com/iselegant/past-and-present-stories-of-amazon-ecs-and-aws-fargate?slide=41

構成に関係がありそうな箇所をピックアップ 「Amazon ECS & AWS Fargate 今昔物語」より抜粋 https://speakerdeck.com/iselegant/past-and-present-stories-of-amazon-ecs-and-aws-fargate?slide=41

構成に関係がありそうな箇所をピックアップ 「Amazon ECS & AWS Fargate 今昔物語」より抜粋 https://speakerdeck.com/iselegant/past-and-present-stories-of-amazon-ecs-and-aws-fargate?slide=41

FargateのGraviton2サポート https://aws.amazon.com/jp/blogs/news/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better-price-performance-for-your-serverless-containers/ ● コスト削減に⼤きく寄与 ● 2024年にはFargate Spotも Gravitonに対応 ● リアーキテクチャの必要もなく適 ⽤できて⼯数⾯でも⾮常に嬉しい

ECS Service Connect ● ECSサービス間の新たな接続⽅法 ● ECS Service Connect Proxy コンテナをタスク内で起動する ● 2024年9⽉にAWS App Meshの 代替としても推奨されている https://aws.amazon.com/jp/blogs/news/announcing-aws-graviton2-support-for-aws-fargate-get-up-to-40-better-price-performance-for-your-serverless-containers/

ECSに直接関連がないサービスのアップデートも ● ECRの脆弱性スキャンのアップデート ● ECRがイメージ署名へ対応 ● Seekable OCI（SOCI）利⽤によるコンテナ起動速度改善 ● CloudshellからのVPCアクセスが可能 ● Cloud9/CodeCommitの新規利⽤受付終了

● 旧来のClair[*1]とは異なる 「AWS_NATIVE」エンジンによる スキャン ● プッシュ時 or ⼿動による実⾏[*2] ● 継続実⾏やアプリレベルまでのス キャンが可能であるため書籍では 引き続きTrivy[*3]を利⽤想定 ECRの脆弱性スキャンのアップデート *1: https://github.com/quay/clair *2: https://aws.amazon.com/inspector/faqs/ *3: https://github.com/aquasecurity/trivy https://aws.amazon.com/jp/about-aws/whats-new/2024/08/new-version-amazon-ecr-basic-scanning/

ECRがイメージ署名へ対応 *1: https://github.com/notaryproject/notation https://aws.amazon.com/jp/about-aws/whats-new/2023/06/aws-container-image-signing/ ● AWS Signerを利⽤したイメージ 署名と検証が可能 ● CNCFのNotary[*1]のNotationを 利⽤ ● 署名済イメージのみデプロイのよ うなプロセス構築が可能となった

Seekable OCI（SOCI）利⽤によるコンテナ起動速度改善 *1: https://github.com/awslabs/soci-snapshotter https://aws.amazon.com/jp/about-aws/whats-new/2022/09/introducing-seekable-oci-lazy-loading-container-images ● コンテナイメージPull速度改善の 1つであるLazy Pullのアプローチ ● コンテナ起動の76%を占めるイ メージPullだが実際に有効に使わ れるデータは6.4%のみ [*1] ● 必要なレイヤーのみを部分的に Pull して準備ができ次第コンテナ の起動を開始するアプローチ

CloudshellからのVPCアクセスが可能 https://aws.amazon.com/about-aws/whats-new/2024/06/aws-cloudshell-amazon-virtual-private-cloud/ https://docs.aws.amazon.com/cloudshell/latest/userguide/using-cshell-in-vpc.html ● 待望のアップデート！ ● 永続ディスクは利⽤不可なので データを保持する場合はS3へ ○ 通常のCloudshellは1GBの永続ディス クを持つ ● データ投⼊やDBへの踏み台として の簡易利⽤を想定

Cloud9/CodeCommitの新規利⽤受付終了 *1: https://docs.google.com/spreadsheets/d/1r4j5q1j4UiaCYhanHWqKf0LAkW0nrDCFZWnXRATCzL8/edit?gid=0#gid=0 https://aws.amazon.com/jp/blogs/devops/how-to-migrate-your-aws-codecommit-repository-to-another-git-provider/ https://aws.amazon.com/jp/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/ ● グローバルからは利⽤が少なかっ たからかサービス停⽌予定 ○ ハンズオンの味⽅（個⼈の⾒解） ● 新井さんリスト[*1] より、最近停 ⽌予定のサービス増えていること がわかる

今回はなした、AWSコンテナ本に関係があるアップデート ● FargateのGraviton2サポート ● ECS Service Connect ● ECRの脆弱性スキャンのアップデート ● ECRがイメージ署名へ対応 ● Seekable OCI（SOCI）利⽤によるコンテナ起動速度改善 ● CloudshellからのVPCアクセスが可能 ● Cloud9/CodeCommitの新規利⽤受付終了

アーキテクチャを⾃分たちにフィットさせるためには？ 取りうる選択肢の把握 × ビジネスゴールを理解 次はこちら

ビジネスゴールを理解 ● アーキテクチャはあくまで達成すべきビジネスゴールのツールである ● ビジネスで達成したい⽬標に応じて取りうる選択肢の取捨選択をする ○ 今回はプロダクションを意識して「コストとセキュリティを最重要」とする

どれを適⽤すべきかは達成したい⽬標に応じて変えるべき ⽬標：コストとセキュリティを最重要とする ● 例１：ECSサービス間通信に何を選ぶか？ ○ ECS Service Connect ○ 内部Application Load Balancer（ALB）接続 ○ ECS Service検出（Cloud Map）を利⽤

それぞれの通信⽅式の特徴 ECS Service Connect 内部ALB ECS Service検出 Pros ・トラフィックのメトリクスを取得可 能 ・ECSネイティブな通信 ・Blue/Greenデプロイ可能 ・リスナールールの活用 ・シンプルな構成 ・コストが安価 Cons ・Proxyサイドカーのキャパシティ の考慮が必要 ・ALBのコストがかかる ・トラフィックの詳細メトリク スが取得できない ● ⽬標：コストとセキュリティを最重要とする 懸念）Service ConnectではCloud Mapの料⾦は無料だがService検出ではRoute53とCloud Mapのコストを考える必要あり

どれを適⽤すべきかは達成したい⽬標に応じて変えるべき ⽬標：コストとセキュリティを最重要とする ● 例１：ECSサービス間通信に何を選ぶか？ ○ ECS Service Connect ○ 内部Application Load Balancer（ALB）接続 ○ ECS Service検出（Cloud Map）を利⽤

どれを適⽤すべきかは達成したい⽬標に応じて変えるべき ⽬標：コストとセキュリティを最重要とする ● 例２：Fargate起動設定に変更を加えるべきか？ ○ Graviton2の利⽤ ○ SOCIインデックスの利⽤ ○ 署名されたコンテナイメージしか利⽤しない

どれを適⽤すべきかは達成したい⽬標に応じて変えるべき ⽬標：コストとセキュリティを最重要とする ● 例２：Fargate起動設定に変更を加えるべきか？ ○ Graviton2の利⽤ ○ SOCIインデックスの利⽤ ○ 署名されたコンテナイメージしか利⽤しない Graviton で起動

それ以外の観点 ● 変更による⼯数が⼩さい箇所（⽬標を毀損しない範囲で） ● アップデートにより変更を余儀なくされた箇所

それ以外の観点 ● 変更による⼯数が⼩さい箇所（⽬標を毀損しない範囲で） ● アップデートにより変更を余儀なくされた箇所

それ以外の観点 ● 変更による⼯数が⼩さい箇所（⽬標を毀損しない範囲で） ● アップデートにより変更を余儀なくされた箇所 CodeCommit Cloud9

Cloud9の代替策を考える ● AWSコンテナ[本格]⼊⾨ハンズオンにおける⽤途 ○ 開発管理サーバ ● 開発管理サーバとして利⽤したユースケース ○ DBメンテナンス作業 ○ コンテナイメージのビルドとプッシュ

Cloud9の代替策を考える ● DBメンテナンス作業 ○ CloudshellからのVPCアクセスが可能となり代替可能？ ■ NAT Gatewayが必要となり追加コストがかかる ○ PublicなCloudshellとRDS Data APIの⽅向で検討 ● コンテナイメージのビルドとプッシュ ○ Cloudshellの永続ストレージが1GBのためビルドが困難 ○ ローカル、SageMaker StudioまたはEC2で代替が考えら れるが本質からズレる。。。 https://docs.aws.amazon.com/ja_jp/cloudshell/latest/userguide/limits.html https://aws.amazon.com/jp/about-aws/whats-new/2024/09/amazon-aurora-mysql-rds-data-api/ めちゃくちゃ 悩んでます

● こちらのほうはエスケープハッチが少ない :-( ● 外部のリポジトリサービスの利⽤が主流となる （GitHub / GitLab) ○ エンタープライズ向けの場合は⾃社で中央管理する コード管理システムやEC2上にGitLabサーバを⽴て るなどもある ● AWSコンテナ本では、CodeStar（AWS Connector for GitHub）を利⽤したGitHub 接続を⾏う CodeCommitの代替策を考える

ビジネスゴールを理解 ● アーキテクチャはあくまで達成すべきビジネスゴールのツールである ● ビジネスで達成したい⽬標に応じて取りうる選択肢の取捨選択をする ○ 今回はプロダクションを意識して「コストとセキュリティを最重要」とする 再掲

アーキテクチャを⾃分たちにフィットさせるためには？ 取りうる選択肢の把握 × ビジネスゴールを理解

アーキテクチャを選定

アーキテクチャを選定 CodeCommit代替で GitHubを利⽤ コスト削減で Cloud Mapで接続 DB作業に Cloudshellを利⽤ デプロイ時に イメージ署名を利⽤ スキャン⽅法 は更新しない Graviton活⽤

まとめ ● AWSコンテナ[本格]⼊⾨ハンズオンを2024年版として検討し直す ● ⽇々のアップデートを理解し取りうる選択肢を増やすことを意識 ● ハンズオンの構成を⾃分たちのビジネスニーズにマッチする形で 作り変え ● 執筆し直しを楽しみにお待ち下さい！

Fin.