$30 off During Our Annual Pro Sale. View Details »

コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと / Cont...

コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと / Containers and Serverless Technology for Developers

iselegant

March 08, 2022
Tweet

More Decks by iselegant

Other Decks in Technology

Transcript

  1. 新井 雅也 M a s a y a A R

    A I msy78 2012年、野村総合研究所に入社。金融業界のお客様に向けたビジネス提案やシステム設計、 開発、運用を担当。UI/UXデザインやスマホApp、バックエンドAPIなど、フルスタック領域な 守備範囲を持ちつつ、クラウドを活用した全体のアーキテクチャ設計・開発が得意。 好きな技術は、Amazon ECS, AWS Fargate, Google Cloud, Kubernetes, Golang, Pulumi。 2021AWS Partner Ambassador 2021 APN ALL AWS Certifications Engineer テックリード / インフラチームリーダー
  2. アプリケーションコードと依存関係を パッケージとしてまとめた一つのファイルのこと コンテナとはなにか? A container is a standard unit of

    software that packages up code and all its dependencies so the application runs quickly and reliably from one computing environment to another. A Docker container image is a lightweight, standalone, executable package of software that includes everything needed to run an application: code, runtime, system tools, system libraries and settings. Ref: https://www.docker.com/resources/what-container
  3. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム ソースコードリポジトリ ハードウェア OS

    ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム テスト環境 ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 本番環境 環境毎のバージョンに合わせてビルドされる
  4. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム ソースコードリポジトリ ハードウェア OS

    ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 開発環境 ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 本番環境 環境毎のバージョンに合わせてビルドされる 環境毎にライブラリやミドルウェア、 ランタイムのバージョンを揃えないといけない →アプリケーションの動作保証(品質)が必要
  5. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム コンテナエンジン コンテナレジストリ コンテナイメージ

    ハードウェア OS コンテナエンジン コンテナイメージ ハードウェア OS コンテナエンジン 本番環境 ビルド済のコンテナを配布 テスト環境
  6. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム コンテナエンジン コンテナレジストリ ハードウェア

    OS コンテナエンジン コンテナイメージ ハードウェア OS コンテナエンジン 本番環境 コンテナイメージ ビルド済のコンテナを配布 コンテナエンジンが 吸収 コンテナエンジンが 吸収 環境毎にライブラリやミドルウェア、 ランタイムのバージョン差異は気にしなくてよい →アプリケーションの同一動作が保証 テスト環境
  7. サーバを意識することなく、 アプリケーションを開発・実行できること (もしくはそれを実現するためのテクノロジー・アーキテクチャ) サーバレスとはなにか? Build and run applications without thinking

    about servers Serverless technologies feature automatic scaling, built-in high availability, and a pay-for-use billing model to increase agility and optimize costs. These technologies also eliminate infrastructure management tasks like capacity provisioning and patching, so you can focus on writing code that serves your customers. Ref: https://aws.amazon.com/serverless/
  8. コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジー アプリケーション開発 へのリソース集中 ビジネス価値の向上 (利用者への価値提供) ※安定性と早さ 差別化につながらない 負荷の削減 Undifferentiated Heavy

    Lifting コンテナ化による 環境依存の軽減 サーバレスや マネージド・サービス による責任や運用の委譲 e.g. ・Try & Errorの回数を増やす ・デプロイをシンプルにして リリース効率を高める ・リリース自体のミスをへらす
  9. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate

    EKS on EC2 EKS on Fargate それぞれどのような特徴・ユースケースがあるか?
  10. Lambda App Runner Amazon EKS (on Amazon EC2 or AWS

    Fargate) ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate u フルマネージド型のKubernetesサービス u Kubernetesはコンテナオーケストレーションツールとしてデファクトスタンダード u コンテナ配置スケジューリングや自動復旧、負荷分散など u コンテナの実行基盤として、EC2 or Fargate u Fargateはサーバレスな実行基盤 u 大規模Webアプリケーション、ML基盤、データ処理基盤などを運用したいケースに最適 u CNCF管轄のOSSを組み合わせながら、マイクロサービスアーキテクチャを構築
  11. Lambda App Runner Amazon EKS on AWS Fargateによるアーキテクチャ例 ECS on

    EC2 ECS on Fargate EKS on EC2 EKS on Fargate u VPC上の構築が前提 u コンテナレジストリと合わせて利用 u Kubernetes上の管理はユーザ責務 u マニフェストを作成して適用 u API GatewayやWAFとの組合せ可能
  12. Lambda App Runner Amazon ECS (on Amazon EC2 or AWS

    Fargate) ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate u フルマネージド型のAWS独自のコンテナオーケストレーションサービス u アップグレード運用などAWS側で対応 u コンテナの実行基盤として、EC2 or Fargate u Fargateはサーバレスな実行基盤 u 小〜中規模Webアプリケーション、ML基盤、データ処理基盤などを運用したいケースに最適 u AWS上の各種サービスと組み合わせながら、マイクロサービスアーキテクチャを構築
  13. Lambda App Runner Amazon ECS (on Amazon EC2 or AWS

    Fargate) ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate
  14. Lambda App Runner Amazon ECS (on Amazon EC2 or AWS

    Fargate) ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate u VPC上の構築が前提 u コンテナレジストリと合わせて利用 u ECSタスク(コンテナの集合)の定義は ユーザ側の責務 u ECSタスク定義を作成して適用 u API GatewayやWAFとの組合せ可能
  15. Lambda App Runner Amazon App Runner ECS on EC2 ECS

    on Fargate EKS on EC2 EKS on Fargate u フルマネージド型のコンテナWebアプリケーションサービス u 単体のコンテナでシンプルなWebアプリケーションを構築したいケースに最適
  16. Lambda App Runner Amazon App Runner ECS on EC2 ECS

    on Fargate EKS on EC2 EKS on Fargate u VPCの管理は不要 u App RunnerとVPCサービスの接続は可能 u コンテナレジストリと合わせて利用 u 負荷分散やオートスケール、証明書管理等は すべてAWS側でマネージドに実現
  17. Lambda App Runner AWS Lambda ECS on EC2 ECS on

    Fargate EKS on EC2 EKS on Fargate u フルマネージド型のサーバレスコンピューティングサービス u 開発者がコードをデプロイできるFaaSとしての位置付け u イベント駆動な仕組みやシンプルなWebアプリケーションを構築したいケースに最適 e.g. u APIのバックエンド処理 u イベントのトリガによるリアルタイム処理 u ストリーミング処理 u バックアップや監視などの運用処理
  18. Lambda App Runner AWS Lambda ECS on EC2 ECS on

    Fargate EKS on EC2 EKS on Fargate u VPCの管理は不要 u VPC内での起動も可能 u アプリケーション開発者で完結する形で活用が可能 u AWSサービス間のイベントをつなぐ役割として重宝
  19. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate

    EKS on EC2 EKS on Fargate Kubernetesベースの コンテナオーケストレーション AWS独自の コンテナオーケストレーション システム 規模 抽象度 大 小 高 低 ケース バイケース Function as a Service Platform as a Service
  20. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate

    EKS on EC2 EKS on Fargate Kubernetesベースの コンテナオーケストレーション AWS独自の コンテナオーケストレーション システム 規模 抽象度 大 小 高 低 ケース バイケース Function as a Service Platform as a Service 選定はどう進めればよいか?
  21. 組織・チーム・システム要件としての技術選定軸とプライオリティを定める u ビジネスのワークロード特性 u Webアプリ、バックエンド(API)、ミッションクリティカル、分析用途(GPU利用)、etc... u 運用・セキュリティ・パフォーマンス・スケーラビリティ・コスト等の非機能要件 u AWSによるサポートの有無 u

    ビジネス上要求されるガバナンス・コンプライアンスルール u ビジネスロードマップにおけるフェーズ u クラウドジャーニーにおけるLift段階 or 新規開発/構築 u 組織体制:システムリリース後の運用チーム組成有無・割当て可能なエンジニアチームの規模 u エンジニアリングチームが現在持ち合わせているスキルセット u 会社、システム、プロダクトとしての技術的プレゼンス戦略
  22. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate

    EKS on EC2 EKS on Fargate Kubernetesベースの コンテナオーケストレーション AWS独自の コンテナオーケストレーション システム 規模 抽象度 大 小 高 低 ケース バイケース Function as a Service Platform as a Service 必要な 体制/スキル 大 小 ケース バイケース 利用者の 責務 柔軟性 大 小 ※大体の目安として参考にしてください データ、アプリケーション、 コンテナイメージ、VPC全般、 Kubernetes上の運用全般 データ、アプリケーション、 コンテナイメージ、VPC全般、 ECSタスク定義 データ、アプリ ケーション、 コンテナイメージ データ、アプリ ケーション
  23. 自分たちのシステム・プロダクトとしての軸となるAWS サービスを定める u クラウドを利用すると、必然的に複数のサービスを利用することになる u AWSが掲げる「Building Block」な思想 u Computeサービスごとに開発プラクティスが異なる u

    リリース方式(CI/CD)、ロギング、監視、開発手法、etc u ある程度、ワークロード全体をカバーできるComputeサービスを決める u 安定した開発フローの維持とシステムをスケールさせていく観点から方向性を定めることは有効 u エンジニアリングチームが現在持ち合わせているプラクティスの共有 u コンプライアンス面での統一化
  24. I. コードベース II. 依存関係 III. 設定 IV. バックエンド サービス V.

    ビルド、リリース、実行 VI. プロセス VII. ポート バインディング VIII. 並列性 IX. 廃棄容易性 X. 開発・本番一致 XI. ログ XII. 管理プロセス AWS Well-Architected Framework 優れたソフトウェアを作り上げるための指針としての The Twelve-Factor App
  25. AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 運用の優秀性 セキュリティ 信頼性 n 開発〜リリースのあり方 n

    ログの扱い方 n 機密情報に対する扱い n コンテナ脆弱性のチェック n 需要変化に対する対応 n 障害検知 n コンテナイメージの不備 u設計ポイントごとに12FAの要素を織り交ぜていく
  26. 運用の優秀性 セキュリティ 信頼性 n 開発〜リリースのあり方 n ログの扱い方 n 機密情報に対する扱い n

    コンテナ脆弱性のチェック n 需要変化に対する対応 n 障害検知 n コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく
  27. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR アプリビルド &コンテナビルド 生成された コンテナイメージを保管 buildspec.yml ビルド用の定義 Dockerfile taskdef.json 開発者 コンテナ イメージを作成 開発〜リリースのあり方
  28. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App AWS CodePipeline AWS

    CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate コンテナイメージ をデプロイ指示 アプリデプロイ buildspec.yml taskdef.json ECSタスク定義 を規定 Dockerfile 開発者 開発〜リリースのあり方
  29. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App ステージング環境 AWS CodePipeline

    AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate buildspec.yml taskdef.json Dockerfile 本番環境 開発者 開発〜リリースのあり方
  30. 開発〜リリースのあり方 コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App ステージング環境 AWS

    CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate buildspec.yml taskdef.json Dockerfile 本番環境 ステージング環境で 必要な品質を確認後、 本番環境にリリース 開発者 ここまでがコンテナに関する 開発〜リリースまでの基本的な流れ
  31. AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS コンテナは単体でポートをリッスンすることでローカルでWebサーバとして機能する

    本番環境 開発者 App Fargate taskdef.json App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml Dockerfile u ローカル環境でサーバ機能まで確認できることで、開発後の動作確認や検証が効率的になる u Webサーバー側のポート番号に依存させない port 80と port 3000をバインド 12FAの「VII. ポートバインディング」の プラクティスに該当 :3000 port 3000 でリスン :3000 :80 開発〜リリースのあり方
  32. 開発者 ポイント:1つのアプリケーションは同一のリポジトリに格納する App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild

    Amazon ECR ECS Fargate 本番環境 App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile u リポジトリをアプリケーションに対する唯一信頼できる情報源 (SSOT: Single Source of Truth)と位置づけ、 環境毎に同一のコードを保つことで、システムの明確性やリリース後の稼働安定性につながる。 12FAの「I. コードベース」の プラクティスに該当 u 環境毎に別バージョンのコードを管理してしまうと、運用管理上の複雑性が増し、 デグレードによる稼働品質低下の原因となる。 開発〜リリースのあり方
  33. 開発者 ポイント:各環境の差分は最小限になるようにする App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile

    u 言い換えれば、アプリケーションのソースコードには、極力環境で動作の異なるロジックを仕込まない。 App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate 本番環境 12FAの「X. 開発/本番一致」 プラクティスに該当 同じ構成を保つ 開発〜リリースのあり方
  34. 開発〜リリースのあり方 開発者 ポイント:各環境の差分は最小限になるようにする App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json

    Dockerfile u 言い換えれば、アプリケーションのソースコードには、極力環境で動作の異なるロジックを仕込まない。 App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate 本番環境 12FAの「X. 開発/本番一致」 プラクティスに該当 同じ構成を保つ どうやって?
  35. ポイント:人材・時間・リソースの観点から同一構成を目指す App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile u

    とはいえ、本番との差分は発生するものであり、差分をへらす努力をする(e.g. 外部システムのスタブAPI用意) App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate 本番環境 同じ構成を保つ 開発→本番の時間をへらす (自動化による時間削減) AWSサービス構成を同じにする 開発環境でビルド済のコンテナイメージを再利用する(理想) 開発者 開発者が 本番リリースまで見届ける 開発〜リリースのあり方
  36. ポイント:アプリケーションの依存関係は厳密に定義する u 依存ライブラリはバージョン含めて暗黙的に扱わない (e.g. npm ciによるpackage-lock.json利用)。 u コンテナイメージのバージョン(タグ)を明示することで、稼働コンテナの対象を明らかにする。 App AWS

    CodePipeline AWS CodeDeploy AWS CodeBuild ECS Fargate App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile ステージング環境 本番環境 Amazon ECR ライブラリの バージョン ベースイメージ のバージョン ビルドの ランタイム 実行するコンテナ イメージのタグ 12FAの「II. 依存関係」 プラクティスに該当 コンテナ イメージのタグ 開発者 開発〜リリースのあり方
  37. ポイント:コンテナ・サーバレスではログを標準出力でストリーム処理する App ECS ECS Task log CloudWatch Logs taskdef.json ログを

    CloudWatchに出力 ログを標準出力することで CloudWatch Logsに配送される 反映 12FAの「XI. ログ」 プラクティスに該当 u 仮にファイルとして出力してしまうと、スケールダウンや内部障害等による ECSタスク(コンテナ)停止時にログが消失する要因となる。 ログの扱い方
  38. ポイント:ログ出力は監査要件と合わせて考慮すべきである App ECS ECS Task u 監査要件等によるログの長期保管はS3バケットを検討すべき。 u CloudWatch Logsのログ保管に関する料金は決して安くない。

    u Firelensコンテナを活用することで、CloudWatch Logs/S3への同時出力が可能。 CloudWatch Logs taskdef.json ログを Firelensに出力 ログを標準出力することで Firelensに配送される 反映 Firelens S3 障害時におけるログ解析や、 業務データ分析用途 監査証跡要件として長期保管 ログの扱い方
  39. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u

    コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
  40. ポイント:機密情報は暗号化されたサービス上で管理して環境変数で渡す App ECS ECS Task u Secrets Managerなどを活用することで、機密情報自体はAWS側で安全に保存する形が望ましい。 Aurora コンテナ内

    taskdef.json Secrets Managerの定義と 環境変数名をマッピングして指定 db_user → DB_USER db_pass → DB_PASS 反映 環境変数 DB_USER DB_PASS Secrets Manager db_user: aurora db_pass: P@ssw0rd! 取得 KMSと連携して 機密情報が安全に保存されている IAM Role 適切なパーミッションが定義された IAMロールを持つECSタスクのみ 機密情報の取得が可能。 機密情報に対する扱い
  41. 環境変数を利用することで、環境間で同じコードの状態を維持できる App ECS ECS Task Aurora taskdef.json 反映 Secrets Manager

    db_user: aurora db_pass: P@ssw0rd! 酒盗k IAM Role ステージング環境 App ECS ECS Task Aurora taskdef.json 反映 Secrets Manager db_user: aurora db_pass: y6EBwH9pae 取得 IAM Role 本番環境 環境変数 DB_USER DB_PASS Secrets Manager側で 差分が吸収される アプリケーションの ソースコード自体は同一で良い ※同じコンテナイメージで動作する 12FAの「III. 設定」 プラクティスに該当 機密情報に対する扱い
  42. 補足:Amazon ECSでは、環境変数の格納手段として複数の方法がある Secrets Manager Systems Manager Parameter Store S3 u

    ⾃動ローテーションが可能 u 機密情報をグループ単位で管理可能 u タスク定義の指定⽅法によって、環境変数値のパースが必要 u 機密情報として扱わないその他の設定値と管理形態を統⼀化可能 u ⾃動ローテーションは不可 u 機密情報が多くなると管理が煩雑になりがち u KMSと連携して機密情報をオブジェクトとして管理 u ⾃動ローテーションはで負荷 u オペミス等でバケットが外部公開されないように統制配慮が必要 u 業務要件・特性に合わせて、利用するAWSサービスを選定する 機密情報に対する扱い
  43. コンテナのイメージ不備に関する考慮 App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR buildspec.yml コンテナイメージを 作成したものの、 記述に不備あり Dockerfile u チームとしてコンテナスキルが成熟していないフェーズでは、 Dockerfileの記述不備によりセキュリティイシューを埋め込んでしまうリスクも。 開発者 App ECS Fargate AWS CodeDeploy 不備がある状態で コンテナが 実行されてしまう 不備がある状態で コンテナが 保持されてしまう taskdef.json コンテナイメージの不備
  44. ポイント:OSSを活用することでDockerfileの不備を取り除いていく App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR buildspec.yml Dockerfile u HadolintやDockleを活用することで、CISが提供するコンテナベストプラクティスに従った コンテナイメージを生成することが可能。 開発者 App ECS Fargate AWS CodeDeploy hadolint taskdef.json IDE (ローカル開発環境) DockerfileのLintで 記述を事前にチェック dockerfileチェック ビルド済イメージチェック ECR保存前にコンテナイメージが ベストプラクティスに従って ビルドされたかチェック コンテナイメージの不備
  45. コンテナのセキュリティ脆弱性に関する考慮 App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR buildspec.yml Dockerfile u 時間の経過とともに、利用しているOSパッケージやアプリケーションライブラリに脆弱性が見つかり、 潜在的に該当するようになる。 App ECS Fargate AWS CodeDeploy taskdef.json 潜在的な 脆弱性に該当する 開発者 検知する仕組みを設けておかないと、 そもそも気づけない 潜在的な 脆弱性に該当する コンテナ脆弱性のチェック
  46. ポイント:ECRのイメージスキャンやTrivyなどのOSSを活用して脆弱性を検知する App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR buildspec.yml Dockerfile u ビルド時のスキャンだけでなく、定期的なスキャンとセットで対応することが重要 u CIが活発でないタイミングで潜在的な脆弱性の該当に気づくために必要 App ECS Fargate AWS CodeDeploy taskdef.json 脆弱性が見つかる ※CI失敗 ビルドのタイミングで イメージスキャン 開発者 脆弱性を検知 ※上記はTrivyをCodeBuildに組み込んでイメージスキャンを実施している例 潜在的な 脆弱性に該当する 潜在的な 脆弱性に該当する コンテナ脆弱性のチェック
  47. ポイント:ECRのイメージスキャンやTrivyなどのOSSを活用して脆弱性を検知する App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild

    Amazon ECR buildspec.yml Dockerfile u ビルド時のスキャンだけでなく、定期的なスキャンとセットで対応することが重要 u CIが活発でないタイミングで潜在的な脆弱性の該当に気づくために必要 App ECS Fargate AWS CodeDeploy taskdef.json 脆弱性なし ※CI成功 ビルドのタイミングで イメージスキャン 開発者 OSパッケージやアプリライブラリの バージョンアップにより対処 脆弱性なし ※上記はTrivyをCodeBuildに組み込んでイメージスキャンを実施している例 脆弱性なし コンテナ脆弱性のチェック
  48. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u

    コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
  49. ポイント:コンテナアプリケーションはいつ落ちても良いようにハンドリングする u 以下のようなSIGTERM (終了シグナル)に対して、安全にアプリケーションが終了するようコーディングする u スケールイン時におけるコンテナ停止 u Blue/Greenデプロイメントやローリングアップデート後のコンテナ停止 u AWS側インフラ障害やセキュリティ問題によるコンテナ停止

    需要変化に対する対応 App ECS Fargate SIGTERM App ECS Fargate SIGKILL SIGTERMハンドリング されていないと・・・ SIGTERM受信後、安全に停止されるべき。 ※DB書き込み中であれば、正常終了後に停止する等 SIGKILLにより、アプリケーションが強制終了される。 ※データ不整合等が発生する原因となる 12FAの「IX. 廃棄容易性」プラクティスに該当
  50. 運用・セキュリティ・スケーラビリティ・コストの観点から、 コンテナイメージサイズはなるべく小さく・シンプルに。 u 巨大なイメージ=セキュリティ脆弱性にさらされるリスクが多くなる u セキュリティ対策に関連する運用コストが増える u コンテナイメージの転送料金が増える(=起動に時間がかかる) u マルチステージビルドを活用することで、コンテナサイズを小さく保つ。

    u アプリケーションビルドに必要なライブラリを実行用のコンテナに含めない。 Dockerfile ビルド済アプリ ビルド済アプリ Dockerfile (マルチステージビルド) アプリビルドと実⾏環境が 混在する巨⼤なコンテナ アプリビルド⽤のコンテナ 実⾏⽤のコンテナ Build Library Build Library Build Library 実行用 Library Build Library Build Library Build Library 実行用 Library 最終的に実行される コンテナはこれだけ。
  51. ポイント:障害を検知するためのログフォーマットを意識する u どのような文字列でエラー判定をするか決め、CloudWatch Logsのサブスリプションフィルターを活用する。 u 昨今では、JSONなど構造体形式でログを出力をすることが一般的(ログ容量が大きくなりがちな点に注意) 障害検知 App ECS Task

    log CloudWatch Logs ログのサンプル例 { "apiID": "API123456", "TransactionID": "12345678-90ab-cdef-1234-567890abcdef", "logType": ”ErrorLog", : } サブスクリプションフィルターで エラー対象を抽出 e.g. {$logType=ErrorLog} 障害通知
  52. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u

    コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
  53. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u

    コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲 I. コードベース II. 依存関係 VII. ポートバインディング X. 開発/本番⼀致 XI. ログ III. 設定 VIII. 並⾏性 IX. 廃棄容易性