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

Transcript

1. コンテナ・サーバレスがもたらす世界と 開発者がAWS上で取り組むべきこと
2. 新井 雅也 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 テックリード / インフラチームリーダー
3. 本日のゴール uこれからAWS上でコンテナ・サーバレスを活用していくエンジニアの方々が、 AWS上のサーバレス・コンテナサービスの全体像や開発のポイントを学べること。 uコンテナ・サーバレスを利用するモチベーションを振り返り、 自分達のシステムにおける技術活用の意味づけに役立てていただけること。
4. 本日お話する前提とスコープ u アプリケーション開発者とインフラエンジニアに分かれて システムを構築・運用している組織の皆様が対象です。 u アプリケーション開発に必要なトピックが中心です。 u インフラ構築に関するトピックは少なめ u 発表者自身が実プロジェクトで意識したポイントを交えながら、 開発として取り組むべきことをお伝えします。
5. 組織がコンテナ・サーバレスを活用する モチベーションはなんでしょうか？ 早速ですが、
6. 簡単なコンテナとサーバレスのおさらいから。
7. アプリケーションコードと依存関係を パッケージとしてまとめた一つのファイルのこと コンテナとはなにか？ 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
8. コンテナ化されていないアプリケーションでは、 どのような課題が生じやすいのか？
9. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム ソースコードリポジトリ
10. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム ソースコードリポジトリ ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム テスト環境 ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 本番環境 環境毎のバージョンに合わせてビルドされる
11. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム ソースコードリポジトリ ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 開発環境 ハードウェア OS ライブラリ/環境変数 アプリケーション ミドルウェア/ランタイム 本番環境 環境毎のバージョンに合わせてビルドされる 環境毎にライブラリやミドルウェア、 ランタイムのバージョンを揃えないといけない →アプリケーションの動作保証（品質）が必要
12. コンテナ化されたアプリケーションでは、 課題に対してどのような解決がなされるのか？
13. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム コンテナエンジン コンテナレジストリ
14. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム コンテナエンジン コンテナレジストリ コンテナイメージ ハードウェア OS コンテナエンジン コンテナイメージ ハードウェア OS コンテナエンジン 本番環境 ビルド済のコンテナを配布 テスト環境
15. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者Aの ローカル開発環境 ミドルウェア/ランタイム コンテナエンジン コンテナレジストリ ハードウェア OS コンテナエンジン コンテナイメージ ハードウェア OS コンテナエンジン 本番環境 コンテナイメージ ビルド済のコンテナを配布 コンテナエンジンが 吸収 コンテナエンジンが 吸収 環境毎にライブラリやミドルウェア、 ランタイムのバージョン差異は気にしなくてよい →アプリケーションの同一動作が保証 テスト環境
16. アプリケーションコードと依存関係を パッケージとしてまとめた一つのファイルのこと コンテナとはなにか？ アプリケーションを 素早く提供できる アプリケーション単位で 同一稼働が保証できる
17. 簡単なコンテナとサーバレスのおさらいから。
18. サーバを意識することなく、 アプリケーションを開発・実行できること （もしくはそれを実現するためのテクノロジー・アーキテクチャ） サーバレスとはなにか？ 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/
19. ハードウェア OS ライブラリ/環境変数 アプリケーション 開発者 ミドルウェア/ランタイム クラウドベンダー サーバレスにより、 開発者はアプリケーションの開発に注力できる システムの維持に必要な管理は クラウド側が担ってくれる
20. 組織がコンテナ・サーバレスを活用する モチベーションはなんでしょうか？ 改めて
21. コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジー ビジネス価値の向上 (利用者への価値提供) ※安定性と早さ e.g. ・Try & Errorの回数を増やす ・デプロイをシンプルにして リリース効率を高める ・リリース自体のミスをへらす
22. コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジー アプリケーション開発 へのリソース集中 ビジネス価値の向上 (利用者への価値提供) ※安定性と早さ 差別化につながらない 負荷の削減 Undifferentiated Heavy Lifting コンテナ化による 環境依存の軽減 サーバレスや マネージド・サービス による責任や運用の委譲 e.g. ・Try & Errorの回数を増やす ・デプロイをシンプルにして リリース効率を高める ・リリース自体のミスをへらす
23. クラウド側への運用委譲は紙一重 自分たちでコントロールする 必要がない部分を任せる 自分たちでコントロール できない部分を見極め受け入れる
24. 技術者が自分たちのビジネスに対して、技術を適用することにより 得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要 サービス毎の特性 サービスの組み合わせ方と 開発プラクティス
25. 技術者が自分たちのビジネスに対して、技術を適用することにより 得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要 サービス毎の特性 サービスの組み合わせ方と 開発プラクティス まずは こちら
26. AWSにおけるコンテナ・サーバレス関連のサービス特性を知る
27. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate
28. Lambda App Runner 代表的なAWSコンテナ・サーバレス関連のサービス達 ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate それぞれどのような特徴・ユースケースがあるか？
29. 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を組み合わせながら、マイクロサービスアーキテクチャを構築
30. 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との組合せ可能
31. 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上の各種サービスと組み合わせながら、マイクロサービスアーキテクチャを構築
32. Lambda App Runner Amazon ECS (on Amazon EC2 or AWS Fargate) ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate
33. 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との組合せ可能
34. Lambda App Runner Amazon App Runner ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate u フルマネージド型のコンテナWebアプリケーションサービス u 単体のコンテナでシンプルなWebアプリケーションを構築したいケースに最適
35. 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側でマネージドに実現
36. 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 バックアップや監視などの運用処理
37. Lambda App Runner AWS Lambda ECS on EC2 ECS on Fargate EKS on EC2 EKS on Fargate u VPCの管理は不要 u VPC内での起動も可能 u アプリケーション開発者で完結する形で活用が可能 u AWSサービス間のイベントをつなぐ役割として重宝
38. 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
39. 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 選定はどう進めればよいか？
40. 組織・チーム・システム要件としての技術選定軸とプライオリティを定める u ビジネスのワークロード特性 u Webアプリ、バックエンド(API)、ミッションクリティカル、分析用途（GPU利用）、etc... u 運用・セキュリティ・パフォーマンス・スケーラビリティ・コスト等の非機能要件 u AWSによるサポートの有無 u ビジネス上要求されるガバナンス・コンプライアンスルール u ビジネスロードマップにおけるフェーズ u クラウドジャーニーにおけるLift段階 or 新規開発/構築 u 組織体制：システムリリース後の運用チーム組成有無・割当て可能なエンジニアチームの規模 u エンジニアリングチームが現在持ち合わせているスキルセット u 会社、システム、プロダクトとしての技術的プレゼンス戦略
41. 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タスク定義 データ、アプリ ケーション、 コンテナイメージ データ、アプリ ケーション
42. 自分たちのシステム・プロダクトとしての軸となるAWS サービスを定める u クラウドを利用すると、必然的に複数のサービスを利用することになる u AWSが掲げる「Building Block」な思想 u Computeサービスごとに開発プラクティスが異なる u リリース方式(CI/CD)、ロギング、監視、開発手法、etc u ある程度、ワークロード全体をカバーできるComputeサービスを決める u 安定した開発フローの維持とシステムをスケールさせていく観点から方向性を定めることは有効 u エンジニアリングチームが現在持ち合わせているプラクティスの共有 u コンプライアンス面での統一化
43. 技術者が自分たちのビジネスに対して、技術を適用することにより 得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要 サービス毎の特性 サービスの組み合わせ方と 開発プラクティス Lambda App Runner ECS EKS 再掲
44. 技術者が自分たちのビジネスに対して、技術を適用することにより 得られる「価値」と「制約」を見極める必要がある u 「価値」と「制約」を知る（=開発者がAWSと向き合う）ためには以下の2つが重要 サービス毎の特性 サービスの組み合わせ方と 開発プラクティス Lambda App Runner ECS EKS つぎは こちら 再掲
45. AWS Well-Architected Framework
46. AWS Well-Architected Frameworkは、 AWSでシステムを評価する際のベストプラクティスを提供するもの u 「柱」と呼ばれるカテゴリー （概念・設計原則・ベストプラクティス）から分類される 運用の優秀性 セキュリティ 信頼性 パフォーマンス効率 コスト最適化 持続可能性 Ref: https://aws.amazon.com/jp/architecture/well-architected/ AWS Well-Architected Framework
47. AWS Well-Architected Framework
48. u Herokuエンジニアがアプリケーション開発・運用から得られた知見をまとめたもの u コーディングで利用されるプログラミング言語や バックエンドサービス（DB、キュー、メモリキャッシュなど）によらず適用できる u ソフトウェアをサービスとして提供するすべての開発者・インフラエンジニアが対象 Ref: https://12factor.net/ AWS Well-Architected Framework 優れたソフトウェアを作り上げるための指針としての The Twelve-Factor App
49. I. コードベース II. 依存関係 III. 設定 IV. バックエンド サービス V. ビルド、リリース、実行 VI. プロセス VII. ポート バインディング VIII. 並列性 IX. 廃棄容易性 X. 開発・本番一致 XI. ログ XII. 管理プロセス AWS Well-Architected Framework 優れたソフトウェアを作り上げるための指針としての The Twelve-Factor App
50. AWS Well-Architected Framework
51. AWS W-Aと12FAを組み合わせることで、 AWS上で開発者が取り組むべきポイントが俯瞰していく AWS Well-Architected Framework AWS設計に関する ベストプラクティスや 考慮ポイント ソフトウェア開発に関する ベストプラクティス
52. 今回はAmazon ECS(コンテナ) + AWS Fargate(サーバレス)を 中心的な技術として、開発者が考慮すべきことを整理していく AWS Well-Architected Framework Amazon ECS AWS Fargate コンテナ技術 の1つ サーバレス技術の 1つ
53. AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 運用の優秀性 セキュリティ 信頼性 n 開発〜リリースのあり方 n ログの扱い方 n 機密情報に対する扱い n コンテナ脆弱性のチェック n 需要変化に対する対応 n 障害検知 n コンテナイメージの不備 u設計ポイントごとに12FAの要素を織り交ぜていく
54. 運用の優秀性 セキュリティ 信頼性 n 開発〜リリースのあり方 n ログの扱い方 n 機密情報に対する扱い n コンテナ脆弱性のチェック n 需要変化に対する対応 n 障害検知 n コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく
55. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) 開発者 buildspec.yml taskdef.json Dockerfile 開発〜リリースのあり方
56. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild Amazon ECR アプリビルド &コンテナビルド 生成された コンテナイメージを保管 buildspec.yml ビルド用の定義 Dockerfile taskdef.json 開発者 コンテナ イメージを作成 開発〜リリースのあり方
57. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate コンテナイメージ をデプロイ指示 アプリデプロイ buildspec.yml taskdef.json ECSタスク定義 を規定 Dockerfile 開発者 開発〜リリースのあり方
58. コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate buildspec.yml taskdef.json Dockerfile 本番環境 開発者 開発〜リリースのあり方
59. 開発〜リリースのあり方 コンテナに関する開発〜リリースまでの基本的な流れ App ソースコード ソースコードリポジトリ (e.g. GitHub) App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate buildspec.yml taskdef.json Dockerfile 本番環境 ステージング環境で 必要な品質を確認後、 本番環境にリリース 開発者 ここまでがコンテナに関する 開発〜リリースまでの基本的な流れ
60. 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 開発〜リリースのあり方
61. 開発者 ポイント：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 環境毎に別バージョンのコードを管理してしまうと、運用管理上の複雑性が増し、 デグレードによる稼働品質低下の原因となる。 開発〜リリースのあり方
62. 開発者 ポイント：各環境の差分は最小限になるようにする App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile u 言い換えれば、アプリケーションのソースコードには、極力環境で動作の異なるロジックを仕込まない。 App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate 本番環境 12FAの「X. 開発/本番一致」 プラクティスに該当 同じ構成を保つ 開発〜リリースのあり方
63. 開発〜リリースのあり方 開発者 ポイント：各環境の差分は最小限になるようにする App ソースコード ソースコードリポジトリ (e.g. GitHub) buildspec.yml taskdef.json Dockerfile u 言い換えれば、アプリケーションのソースコードには、極力環境で動作の異なるロジックを仕込まない。 App ステージング環境 AWS CodePipeline AWS CodeDeploy AWS CodeBuild Amazon ECR ECS Fargate 本番環境 12FAの「X. 開発/本番一致」 プラクティスに該当 同じ構成を保つ どうやって？
64. ポイント：人材・時間・リソースの観点から同一構成を目指す 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サービス構成を同じにする 開発環境でビルド済のコンテナイメージを再利用する(理想) 開発者 開発者が 本番リリースまで見届ける 開発〜リリースのあり方
65. ポイント：アプリケーションの依存関係は厳密に定義する 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. 依存関係」 プラクティスに該当 コンテナ イメージのタグ 開発者 開発〜リリースのあり方
66. コンテナアプリケーションにおけるログの扱い方に関する基本的な流れ App ECS ECS Task log u コンテナ・サーバレス上であっても、従来のアプリケーションと同じようにログ出力は可能。 u コンテナ内部のログファイルに出力できる。 ログの扱い方
67. ポイント：コンテナ・サーバレスではログを標準出力でストリーム処理する App ECS ECS Task log u 仮にファイルとして出力してしまうと、スケールダウンや内部障害等による ECSタスク(コンテナ)停止時にログが消失する要因となる。 taskdef.json 反映 ファイル システム 1.ECSタスク停止 2. ECSタスク停止とともに ログファイルが消失する ログの扱い方
68. ポイント：コンテナ・サーバレスではログを標準出力でストリーム処理する App ECS ECS Task log CloudWatch Logs taskdef.json ログを CloudWatchに出力 ログを標準出力することで CloudWatch Logsに配送される 反映 12FAの「XI. ログ」 プラクティスに該当 u 仮にファイルとして出力してしまうと、スケールダウンや内部障害等による ECSタスク(コンテナ)停止時にログが消失する要因となる。 ログの扱い方
69. ポイント：ログ出力は監査要件と合わせて考慮すべきである App ECS ECS Task u 監査要件等によるログの長期保管はS3バケットを検討すべき。 u CloudWatch Logsのログ保管に関する料金は決して安くない。 u Firelensコンテナを活用することで、CloudWatch Logs/S3への同時出力が可能。 CloudWatch Logs taskdef.json ログを Firelensに出力 ログを標準出力することで Firelensに配送される 反映 Firelens S3 障害時におけるログ解析や、 業務データ分析用途 監査証跡要件として長期保管 ログの扱い方
70. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
71. 機密情報に関する基本的な戦略 App ECS ECS Task u ソースコード上のハードコーディングや暗号化されていない状態での設定ファイル保持は避けるべき。 u コンテナ起動時に環境変数として注入し、アプリケーション上から参照する流れが安全。（メモリ上の展開のみで済む） Aurora 設定ファイル コンテナ内 : db_user: aurora db_pass: P@ssw0rd! : 平文保存されており、機密情報が安全に保管されているとは言えない。 機密情報に対する扱い
72. ポイント：機密情報は暗号化されたサービス上で管理して環境変数で渡す 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タスクのみ 機密情報の取得が可能。 機密情報に対する扱い
73. 環境変数を利用することで、環境間で同じコードの状態を維持できる 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. 設定」 プラクティスに該当 機密情報に対する扱い
74. 補足：Amazon ECSでは、環境変数の格納手段として複数の方法がある Secrets Manager Systems Manager Parameter Store S3 u ⾃動ローテーションが可能 u 機密情報をグループ単位で管理可能 u タスク定義の指定⽅法によって、環境変数値のパースが必要 u 機密情報として扱わないその他の設定値と管理形態を統⼀化可能 u ⾃動ローテーションは不可 u 機密情報が多くなると管理が煩雑になりがち u KMSと連携して機密情報をオブジェクトとして管理 u ⾃動ローテーションはで負荷 u オペミス等でバケットが外部公開されないように統制配慮が必要 u 業務要件・特性に合わせて、利用するAWSサービスを選定する 機密情報に対する扱い
75. コンテナのイメージ不備に関する考慮 App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild Amazon ECR buildspec.yml コンテナイメージを 作成したものの、 記述に不備あり Dockerfile u チームとしてコンテナスキルが成熟していないフェーズでは、 Dockerfileの記述不備によりセキュリティイシューを埋め込んでしまうリスクも。 開発者 App ECS Fargate AWS CodeDeploy 不備がある状態で コンテナが 実行されてしまう 不備がある状態で コンテナが 保持されてしまう taskdef.json コンテナイメージの不備
76. ポイント：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保存前にコンテナイメージが ベストプラクティスに従って ビルドされたかチェック コンテナイメージの不備
77. コンテナのセキュリティ脆弱性に関する考慮 App ソースコード ソースコードリポジトリ (e.g. GitHub) AWS CodePipeline AWS CodeBuild Amazon ECR buildspec.yml Dockerfile u 時間の経過とともに、利用しているOSパッケージやアプリケーションライブラリに脆弱性が見つかり、 潜在的に該当するようになる。 App ECS Fargate AWS CodeDeploy taskdef.json 潜在的な 脆弱性に該当する 開発者 検知する仕組みを設けておかないと、 そもそも気づけない 潜在的な 脆弱性に該当する コンテナ脆弱性のチェック
78. ポイント：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に組み込んでイメージスキャンを実施している例 潜在的な 脆弱性に該当する 潜在的な 脆弱性に該当する コンテナ脆弱性のチェック
79. ポイント：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に組み込んでイメージスキャンを実施している例 脆弱性なし コンテナ脆弱性のチェック
80. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
81. ポイント：コンテナアプリケーションはいつ落ちても良いようにハンドリングする u 以下のようなSIGTERM (終了シグナル)に対して、安全にアプリケーションが終了するようコーディングする u スケールイン時におけるコンテナ停止 u Blue/Greenデプロイメントやローリングアップデート後のコンテナ停止 u AWS側インフラ障害やセキュリティ問題によるコンテナ停止 App ECS Fargate SIGTERM SIGTERM受信後、安全に停止されるべき。 ※DB書き込み中であれば、正常終了後に停止する等 需要変化に対する対応
82. ポイント：コンテナアプリケーションはいつ落ちても良いようにハンドリングする u 以下のようなSIGTERM (終了シグナル)に対して、安全にアプリケーションが終了するようコーディングする u スケールイン時におけるコンテナ停止 u Blue/Greenデプロイメントやローリングアップデート後のコンテナ停止 u AWS側インフラ障害やセキュリティ問題によるコンテナ停止 需要変化に対する対応 App ECS Fargate SIGTERM App ECS Fargate SIGKILL SIGTERMハンドリング されていないと・・・ SIGTERM受信後、安全に停止されるべき。 ※DB書き込み中であれば、正常終了後に停止する等 SIGKILLにより、アプリケーションが強制終了される。 ※データ不整合等が発生する原因となる 12FAの「IX. 廃棄容易性」プラクティスに該当
83. ポイント：水平スケールを基本的な需要変化への戦略とする u コンテナはプロセス単位で高速に起動するため、迅速なスケーラビリティに寄与する u アプリケーションが単体で安定稼働するCPU/メモリリソースを定め、ベースラインとしてスケールアウトさせる 需要変化に対する対応 App ALB App App 垂直スケールではなく、 水平スケールを基本 12FAの「VIII. 並行性」プラクティスに該当
84. ポイント：水平スケールを基本的な需要変化への戦略とする u コンテナはプロセス単位で高速に起動するため、迅速なスケーラビリティに寄与する u アプリケーションが単体で安定稼働するCPU/メモリリソースを定め、ベースラインとしてスケールアウトさせる App ALB App App 垂直スケールではなく、 水平スケールを基本 廃棄容易性が 考慮されていると・・・ App ALB App App スケールイン時の コンテナは安全に停止される 12FAの「VIII. 並行性」プラクティスに該当 需要変化に対する対応
85. 運用・セキュリティ・スケーラビリティ・コストの観点から、 コンテナイメージサイズはなるべく小さく・シンプルに。 u 巨大なイメージ＝セキュリティ脆弱性にさらされるリスクが多くなる u セキュリティ対策に関連する運用コストが増える u コンテナイメージの転送料金が増える（=起動に時間がかかる） u マルチステージビルドを活用することで、コンテナサイズを小さく保つ。 u アプリケーションビルドに必要なライブラリを実行用のコンテナに含めない。 Dockerfile ビルド済アプリ アプリビルドと実⾏環境が 混在する巨⼤なコンテナ Build Library Build Library Build Library 実行用 Library
86. 運用・セキュリティ・スケーラビリティ・コストの観点から、 コンテナイメージサイズはなるべく小さく・シンプルに。 u 巨大なイメージ＝セキュリティ脆弱性にさらされるリスクが多くなる u セキュリティ対策に関連する運用コストが増える u コンテナイメージの転送料金が増える（=起動に時間がかかる） u マルチステージビルドを活用することで、コンテナサイズを小さく保つ。 u アプリケーションビルドに必要なライブラリを実行用のコンテナに含めない。 Dockerfile ビルド済アプリ ビルド済アプリ Dockerfile (マルチステージビルド) アプリビルドと実⾏環境が 混在する巨⼤なコンテナ アプリビルド⽤のコンテナ 実⾏⽤のコンテナ Build Library Build Library Build Library 実行用 Library Build Library Build Library Build Library 実行用 Library 最終的に実行される コンテナはこれだけ。
87. ポイント：障害を検知するためのログフォーマットを意識する 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} 障害通知
88. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲
89. 運用の優秀性 セキュリティ 信頼性 u 開発〜リリースのあり方 u ログの扱い方 u 機密情報に対する扱い u コンテナ脆弱性のチェック u 需要変化に対する対応 u 障害検知 u コンテナイメージの不備 AWS Well-Architected Frameworkをコンテナ・サーバレスを軸にした アプリケーション開発で求められる設計ポイントを整理 u設計ポイントごとに12FAの要素を織り交ぜていく 再掲 I. コードベース II. 依存関係 VII. ポートバインディング X. 開発/本番⼀致 XI. ログ III. 設定 VIII. 並⾏性 IX. 廃棄容易性
90. まとめ
91. まとめ u コンテナ・サーバレスは、いずれもビジネス価値を高めるための中心的なテクノロジー u テクノロジーの適用により、得られる「価値」と「制約」を見定める u AWSサービス毎の特性を押さえる u サービスの組合わせ方と開発プラクティスを知る u AWS上のアプリケーション開発者が知るべきプラクティスとしての AWS Well-Architected Framework と The Twelve-Factor App
92. ご清聴いただき、ありがとうございました。