コンテナ・サーバレスがもたらす世界と開発者がAWS上で取り組むべきこと / Containers and Serverless Technology for Developers

by iselegant

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

新井雅也 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 テックリード / インフラチームリーダー

Slide 3

Slide 3 text

本日のゴール uこれからAWS上でコンテナ・サーバレスを活用していくエンジニアの方々が、 AWS上のサーバレス・コンテナサービスの全体像や開発のポイントを学べること。 uコンテナ・サーバレスを利用するモチベーションを振り返り、自分達のシステムにおける技術活用の意味づけに役立てていただけること。

Slide 4

Slide 4 text

本日お話する前提とスコープ u アプリケーション開発者とインフラエンジニアに分かれてシステムを構築・運用している組織の皆様が対象です。 u アプリケーション開発に必要なトピックが中心です。 u インフラ構築に関するトピックは少なめ u 発表者自身が実プロジェクトで意識したポイントを交えながら、開発として取り組むべきことをお伝えします。

Slide 5

Slide 5 text

組織がコンテナ・サーバレスを活用するモチベーションはなんでしょうか？早速ですが、

Slide 6

Slide 6 text

簡単なコンテナとサーバレスのおさらいから。

Slide 7

Slide 7 text

アプリケーションコードと依存関係をパッケージとしてまとめた一つのファイルのことコンテナとはなにか？ 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

Slide 8

Slide 8 text

コンテナ化されていないアプリケーションでは、どのような課題が生じやすいのか？

Slide 9

Slide 9 text

ハードウェア OS ライブラリ/環境変数アプリケーション開発者Aのローカル開発環境ミドルウェア/ランタイムソースコードリポジトリ

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

コンテナ化されたアプリケーションでは、課題に対してどのような解決がなされるのか？

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

ハードウェア OS ライブラリ/環境変数アプリケーション開発者Aのローカル開発環境ミドルウェア/ランタイムコンテナエンジンコンテナレジストリハードウェア OS コンテナエンジンコンテナイメージハードウェア OS コンテナエンジン本番環境コンテナイメージビルド済のコンテナを配布コンテナエンジンが吸収コンテナエンジンが吸収環境毎にライブラリやミドルウェア、ランタイムのバージョン差異は気にしなくてよい →アプリケーションの同一動作が保証テスト環境

Slide 16

Slide 16 text

アプリケーションコードと依存関係をパッケージとしてまとめた一つのファイルのことコンテナとはなにか？アプリケーションを素早く提供できるアプリケーション単位で同一稼働が保証できる

Slide 17

Slide 17 text

簡単なコンテナとサーバレスのおさらいから。

Slide 18

Slide 18 text

サーバを意識することなく、アプリケーションを開発・実行できること（もしくはそれを実現するためのテクノロジー・アーキテクチャ）サーバレスとはなにか？ 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/

Slide 19

Slide 19 text

ハードウェア OS ライブラリ/環境変数アプリケーション開発者ミドルウェア/ランタイムクラウドベンダーサーバレスにより、開発者はアプリケーションの開発に注力できるシステムの維持に必要な管理はクラウド側が担ってくれる

Slide 20

Slide 20 text

組織がコンテナ・サーバレスを活用するモチベーションはなんでしょうか？改めて

Slide 21

Slide 21 text

コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジービジネス価値の向上 (利用者への価値提供) ※安定性と早さ e.g. ・Try & Errorの回数を増やす・デプロイをシンプルにしてリリース効率を高める・リリース自体のミスをへらす

Slide 22

Slide 22 text

コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジーアプリケーション開発へのリソース集中ビジネス価値の向上 (利用者への価値提供) ※安定性と早さ差別化につながらない負荷の削減 Undifferentiated Heavy Lifting コンテナ化による環境依存の軽減サーバレスやマネージド・サービスによる責任や運用の委譲 e.g. ・Try & Errorの回数を増やす・デプロイをシンプルにしてリリース効率を高める・リリース自体のミスをへらす

Slide 23

Slide 23 text

クラウド側への運用委譲は紙一重自分たちでコントロールする必要がない部分を任せる自分たちでコントロールできない部分を見極め受け入れる

Slide 24

Slide 24 text

技術者が自分たちのビジネスに対して、技術を適用することにより得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要サービス毎の特性サービスの組み合わせ方と開発プラクティス

Slide 25

Slide 25 text

技術者が自分たちのビジネスに対して、技術を適用することにより得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要サービス毎の特性サービスの組み合わせ方と開発プラクティスまずはこちら

Slide 26

Slide 26 text

AWSにおけるコンテナ・サーバレス関連のサービス特性を知る

Slide 27

Slide 27 text

Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate

Slide 28

Slide 28 text

Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate それぞれどのような特徴・ユースケースがあるか？

Slide 29

Slide 29 text

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を組み合わせながら、マイクロサービスアーキテクチャを構築

Slide 30

Slide 30 text

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との組合せ可能

Slide 31

Slide 31 text

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上の各種サービスと組み合わせながら、マイクロサービスアーキテクチャを構築

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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との組合せ可能

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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側でマネージドに実現

Slide 36

Slide 36 text

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 バックアップや監視などの運用処理

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

組織・チーム・システム要件としての技術選定軸とプライオリティを定める u ビジネスのワークロード特性 u Webアプリ、バックエンド(API)、ミッションクリティカル、分析用途（GPU利用）、etc... u 運用・セキュリティ・パフォーマンス・スケーラビリティ・コスト等の非機能要件 u AWSによるサポートの有無 u ビジネス上要求されるガバナンス・コンプライアンスルール u ビジネスロードマップにおけるフェーズ u クラウドジャーニーにおけるLift段階 or 新規開発/構築 u 組織体制：システムリリース後の運用チーム組成有無・割当て可能なエンジニアチームの規模 u エンジニアリングチームが現在持ち合わせているスキルセット u 会社、システム、プロダクトとしての技術的プレゼンス戦略

Slide 41

Slide 41 text

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タスク定義データ、アプリケーション、コンテナイメージデータ、アプリケーション

Slide 42

Slide 42 text

自分たちのシステム・プロダクトとしての軸となるAWS サービスを定める u クラウドを利用すると、必然的に複数のサービスを利用することになる u AWSが掲げる「Building Block」な思想 u Computeサービスごとに開発プラクティスが異なる u リリース方式(CI/CD)、ロギング、監視、開発手法、etc u ある程度、ワークロード全体をカバーできるComputeサービスを決める u 安定した開発フローの維持とシステムをスケールさせていく観点から方向性を定めることは有効 u エンジニアリングチームが現在持ち合わせているプラクティスの共有 u コンプライアンス面での統一化

Slide 43

Slide 43 text

技術者が自分たちのビジネスに対して、技術を適用することにより得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要サービス毎の特性サービスの組み合わせ方と開発プラクティス Lambda App Runner ECS EKS 再掲

Slide 44

Slide 44 text

技術者が自分たちのビジネスに対して、技術を適用することにより得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要サービス毎の特性サービスの組み合わせ方と開発プラクティス Lambda App Runner ECS EKS つぎはこちら再掲

Slide 45

Slide 45 text

AWS Well-Architected Framework

Slide 46

Slide 46 text

AWS Well-Architected Frameworkは、 AWSでシステムを評価する際のベストプラクティスを提供するもの u 「柱」と呼ばれるカテゴリー（概念・設計原則・ベストプラクティス）から分類される運用の優秀性セキュリティ信頼性パフォーマンス効率コスト最適化持続可能性 Ref: https://aws.amazon.com/jp/architecture/well-architected/ AWS Well-Architected Framework

Slide 47

Slide 47 text

AWS Well-Architected Framework

Slide 48

Slide 48 text

u Herokuエンジニアがアプリケーション開発・運用から得られた知見をまとめたもの u コーディングで利用されるプログラミング言語やバックエンドサービス（DB、キュー、メモリキャッシュなど）によらず適用できる u ソフトウェアをサービスとして提供するすべての開発者・インフラエンジニアが対象 Ref: https://12factor.net/ AWS Well-Architected Framework 優れたソフトウェアを作り上げるための指針としての The Twelve-Factor App

Slide 49

Slide 49 text

I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス VII. ポートバインディング VIII. 並列性 IX. 廃棄容易性 X. 開発・本番一致 XI. ログ XII. 管理プロセス AWS Well-Architected Framework 優れたソフトウェアを作り上げるための指針としての The Twelve-Factor App

Slide 50

Slide 50 text

AWS Well-Architected Framework

Slide 51

Slide 51 text

AWS W-Aと12FAを組み合わせることで、 AWS上で開発者が取り組むべきポイントが俯瞰していく AWS Well-Architected Framework AWS設計に関するベストプラクティスや考慮ポイントソフトウェア開発に関するベストプラクティス

Slide 52

Slide 52 text

今回はAmazon ECS(コンテナ) + AWS Fargate(サーバレス)を中心的な技術として、開発者が考慮すべきことを整理していく AWS Well-Architected Framework Amazon ECS AWS Fargate コンテナ技術の1つサーバレス技術の 1つ

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

コンテナに関する開発〜リリースまでの基本的な流れ App ソースコードソースコードリポジトリ (e.g. GitHub) 開発者 buildspec.yml taskdef.json Dockerfile 開発〜リリースのあり方

Slide 56

Slide 56 text

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

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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 開発〜リリースのあり方

Slide 61

Slide 61 text

開発者ポイント：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 環境毎に別バージョンのコードを管理してしまうと、運用管理上の複雑性が増し、デグレードによる稼働品質低下の原因となる。開発〜リリースのあり方

Slide 62

Slide 62 text

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

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

ポイント：人材・時間・リソースの観点から同一構成を目指す 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サービス構成を同じにする開発環境でビルド済のコンテナイメージを再利用する(理想) 開発者開発者が本番リリースまで見届ける開発〜リリースのあり方

Slide 65

Slide 65 text

ポイント：アプリケーションの依存関係は厳密に定義する 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. 依存関係」プラクティスに該当コンテナイメージのタグ開発者開発〜リリースのあり方

Slide 66

Slide 66 text

コンテナアプリケーションにおけるログの扱い方に関する基本的な流れ App ECS ECS Task log u コンテナ・サーバレス上であっても、従来のアプリケーションと同じようにログ出力は可能。 u コンテナ内部のログファイルに出力できる。ログの扱い方

Slide 67

Slide 67 text

ポイント：コンテナ・サーバレスではログを標準出力でストリーム処理する App ECS ECS Task log u 仮にファイルとして出力してしまうと、スケールダウンや内部障害等による ECSタスク(コンテナ)停止時にログが消失する要因となる。 taskdef.json 反映ファイルシステム 1.ECSタスク停止 2. ECSタスク停止とともにログファイルが消失するログの扱い方

Slide 68

Slide 68 text

ポイント：コンテナ・サーバレスではログを標準出力でストリーム処理する App ECS ECS Task log CloudWatch Logs taskdef.json ログを CloudWatchに出力ログを標準出力することで CloudWatch Logsに配送される反映 12FAの「XI. ログ」プラクティスに該当 u 仮にファイルとして出力してしまうと、スケールダウンや内部障害等による ECSタスク(コンテナ)停止時にログが消失する要因となる。ログの扱い方

Slide 69

Slide 69 text

ポイント：ログ出力は監査要件と合わせて考慮すべきである App ECS ECS Task u 監査要件等によるログの長期保管はS3バケットを検討すべき。 u CloudWatch Logsのログ保管に関する料金は決して安くない。 u Firelensコンテナを活用することで、CloudWatch Logs/S3への同時出力が可能。 CloudWatch Logs taskdef.json ログを Firelensに出力ログを標準出力することで Firelensに配送される反映 Firelens S3 障害時におけるログ解析や、業務データ分析用途監査証跡要件として長期保管ログの扱い方

Slide 70

Slide 70 text

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

Slide 71

Slide 71 text

機密情報に関する基本的な戦略 App ECS ECS Task u ソースコード上のハードコーディングや暗号化されていない状態での設定ファイル保持は避けるべき。 u コンテナ起動時に環境変数として注入し、アプリケーション上から参照する流れが安全。（メモリ上の展開のみで済む） Aurora 設定ファイルコンテナ内 : db_user: aurora db_pass: P@ssw0rd! : 平文保存されており、機密情報が安全に保管されているとは言えない。機密情報に対する扱い

Slide 72

Slide 72 text

ポイント：機密情報は暗号化されたサービス上で管理して環境変数で渡す 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タスクのみ機密情報の取得が可能。機密情報に対する扱い

Slide 73

Slide 73 text

環境変数を利用することで、環境間で同じコードの状態を維持できる 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. 設定」プラクティスに該当機密情報に対する扱い

Slide 74

Slide 74 text

補足：Amazon ECSでは、環境変数の格納手段として複数の方法がある Secrets Manager Systems Manager Parameter Store S3 u ⾃動ローテーションが可能 u 機密情報をグループ単位で管理可能 u タスク定義の指定⽅法によって、環境変数値のパースが必要 u 機密情報として扱わないその他の設定値と管理形態を統⼀化可能 u ⾃動ローテーションは不可 u 機密情報が多くなると管理が煩雑になりがち u KMSと連携して機密情報をオブジェクトとして管理 u ⾃動ローテーションはで負荷 u オペミス等でバケットが外部公開されないように統制配慮が必要 u 業務要件・特性に合わせて、利用するAWSサービスを選定する機密情報に対する扱い

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

ポイント：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保存前にコンテナイメージがベストプラクティスに従ってビルドされたかチェックコンテナイメージの不備

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

ポイント：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に組み込んでイメージスキャンを実施している例潜在的な脆弱性に該当する潜在的な脆弱性に該当するコンテナ脆弱性のチェック

Slide 79

Slide 79 text

ポイント：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に組み込んでイメージスキャンを実施している例脆弱性なしコンテナ脆弱性のチェック

Slide 80

Slide 80 text

Slide 81

Slide 81 text

ポイント：コンテナアプリケーションはいつ落ちても良いようにハンドリングする u 以下のようなSIGTERM (終了シグナル)に対して、安全にアプリケーションが終了するようコーディングする u スケールイン時におけるコンテナ停止 u Blue/Greenデプロイメントやローリングアップデート後のコンテナ停止 u AWS側インフラ障害やセキュリティ問題によるコンテナ停止 App ECS Fargate SIGTERM SIGTERM受信後、安全に停止されるべき。 ※DB書き込み中であれば、正常終了後に停止する等需要変化に対する対応

Slide 82

Slide 82 text

ポイント：コンテナアプリケーションはいつ落ちても良いようにハンドリングする u 以下のようなSIGTERM (終了シグナル)に対して、安全にアプリケーションが終了するようコーディングする u スケールイン時におけるコンテナ停止 u Blue/Greenデプロイメントやローリングアップデート後のコンテナ停止 u AWS側インフラ障害やセキュリティ問題によるコンテナ停止需要変化に対する対応 App ECS Fargate SIGTERM App ECS Fargate SIGKILL SIGTERMハンドリングされていないと・・・ SIGTERM受信後、安全に停止されるべき。 ※DB書き込み中であれば、正常終了後に停止する等 SIGKILLにより、アプリケーションが強制終了される。 ※データ不整合等が発生する原因となる 12FAの「IX. 廃棄容易性」プラクティスに該当

Slide 83

Slide 83 text

ポイント：水平スケールを基本的な需要変化への戦略とする u コンテナはプロセス単位で高速に起動するため、迅速なスケーラビリティに寄与する u アプリケーションが単体で安定稼働するCPU/メモリリソースを定め、ベースラインとしてスケールアウトさせる需要変化に対する対応 App ALB App App 垂直スケールではなく、水平スケールを基本 12FAの「VIII. 並行性」プラクティスに該当

Slide 84

Slide 84 text

ポイント：水平スケールを基本的な需要変化への戦略とする u コンテナはプロセス単位で高速に起動するため、迅速なスケーラビリティに寄与する u アプリケーションが単体で安定稼働するCPU/メモリリソースを定め、ベースラインとしてスケールアウトさせる App ALB App App 垂直スケールではなく、水平スケールを基本廃棄容易性が考慮されていると・・・ App ALB App App スケールイン時のコンテナは安全に停止される 12FAの「VIII. 並行性」プラクティスに該当需要変化に対する対応

Slide 85

Slide 85 text

運用・セキュリティ・スケーラビリティ・コストの観点から、コンテナイメージサイズはなるべく小さく・シンプルに。 u 巨大なイメージ＝セキュリティ脆弱性にさらされるリスクが多くなる u セキュリティ対策に関連する運用コストが増える u コンテナイメージの転送料金が増える（=起動に時間がかかる） u マルチステージビルドを活用することで、コンテナサイズを小さく保つ。 u アプリケーションビルドに必要なライブラリを実行用のコンテナに含めない。 Dockerfile ビルド済アプリアプリビルドと実⾏環境が混在する巨⼤なコンテナ Build Library Build Library Build Library 実行用 Library

Slide 86

Slide 86 text

運用・セキュリティ・スケーラビリティ・コストの観点から、コンテナイメージサイズはなるべく小さく・シンプルに。 u 巨大なイメージ＝セキュリティ脆弱性にさらされるリスクが多くなる u セキュリティ対策に関連する運用コストが増える u コンテナイメージの転送料金が増える（=起動に時間がかかる） u マルチステージビルドを活用することで、コンテナサイズを小さく保つ。 u アプリケーションビルドに必要なライブラリを実行用のコンテナに含めない。 Dockerfile ビルド済アプリビルド済アプリ Dockerfile (マルチステージビルド) アプリビルドと実⾏環境が混在する巨⼤なコンテナアプリビルド⽤のコンテナ実⾏⽤のコンテナ Build Library Build Library Build Library 実行用 Library Build Library Build Library Build Library 実行用 Library 最終的に実行されるコンテナはこれだけ。

Slide 87

Slide 87 text

ポイント：障害を検知するためのログフォーマットを意識する 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} 障害通知

Slide 88

Slide 88 text

Slide 89

Slide 89 text

Slide 90

Slide 90 text

まとめ

Slide 91

Slide 91 text

まとめ u コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジー u テクノロジーの適用により、得られる「価値」と「制約」を見定める u AWSサービス毎の特性を押さえる u サービスの組合わせ方と開発プラクティスを知る u AWS上のアプリケーション開発者が知るべきプラクティスとしての AWS Well-Architected Framework と The Twelve-Factor App

Slide 92

Slide 92 text

ご清聴いただき、ありがとうございました。