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

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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/
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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サービス間のイベントをつなぐ役割として重宝
    

    View Slide

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
    

    View Slide

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
    選定はどう進めればよいか？
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

45. AWS Well-Architected
    Framework
    

    View Slide

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

    View Slide

47. AWS Well-Architected
    Framework
    

    View Slide

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

    View Slide

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

    View Slide

50. AWS Well-Architected
    Framework
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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サービス構成を同じにする
    開発環境でビルド済のコンテナイメージを再利用する(理想)
    開発者
    開発者が
    本番リリースまで見届ける
    開発〜リリースのあり方
    

    View Slide

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. 依存関係」
    プラクティスに該当
    コンテナ
    イメージのタグ
    開発者
    開発〜リリースのあり方
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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タスクのみ
    機密情報の取得が可能。
    機密情報に対する扱い
    

    View Slide

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. 設定」
    プラクティスに該当
    機密情報に対する扱い
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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}
    障害通知
    

    View Slide

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

    View Slide

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

    View Slide

90. まとめ
    

    View Slide

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

    View Slide

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

    View Slide