アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知るべきか #AWSDevDay / You build it, you run it

Talked at AWS Dev Day Online Japan 2021.

- 動画: https://youtu.be/I7mMQshlpcs
- イベントページ: https://aws.amazon.com/jp/about-aws/events/2021/devday
- Proposal: https://github.com/aws-events/aws-dev-day-online-japan-2021-cfp/issues/16

Transcript

1. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   アプリケーション開発者は
   Tori Hara / toricls
   Sr. Product Developer Advocate
   Elastic Containers, AWS
   F - 3
   Amazon ECS あるいは Kubernetes を
   どこまで知るべきか
   

   View Slide

2. Tori Hara / toricls
   Sr. Product Developer Advocate
   Elastic Containers, AWS
   ---
   ERP パッケージベンダー R&D Software Engineer
   ➡ クラウド利⽤の SI + MSP にて、コンテナやサーバーレスによる設計・開発・運⽤
   Web 技術利⽤のゲームやビジネスアプリケーション、ML/DL 環境など
   ➡ Sr. Containers Specialist SA, AWS Japan
   ➡ Sr. Product Developer Advocate for Containers, AWS
   ---
   AWS Fargate AWS App Runner AWS Lambda
   が好きです
   

   View Slide

3. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   想定聴講者
   • 『運⽤』が必要なアプリケーション(Web アプリとか)を書いている
   • コンテナ技術そのものは知っている、あるいは普段の開発に使っている
   • ⾃分のアプリの運⽤⽅法は知らないが、コンテナを使っていると街の噂を聞いたことが
   • コンテナワークロードでのアプリケーション開発者の責務の範囲にガイドラインが欲しい
   ゴール
   • 運⽤を難しくしてしまうアプリケーション実装例を学び、対処策を実践できるようになる
   • (少なくとも)Amazon ECS タスク/サービス定義や Kubernetes マニフェストを開発者⾃⾝
   が書けるようになる必要性を理解し、実践できるようになる
   • ソフトウェアライフサイクルのステークホルダがシステムに共同で責任を持つことの.
   重要性と妥当性を理解し、⾃社への適⽤に取り組む気持ちを持つ
   セッション対象者とゴール
   

   View Slide

4. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
   (初学者のための)
   コンテナワークロード超⼊⾨
   

   View Slide

5. コンテナとは (超概略)
   初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門
   ランタイム/エンジン
   アプリケーションコード
   依存ライブラリ/パッケージ + 設定
   

   View Slide

6. コンテナのデプロイメントモデル (超概略)
   初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門
   コントロールプレーン データプレーン
   Call API(s)
   ノード x N
   CD システム
   Call API(s)
   コンテナエージェント
   (e.g. ECS Agent, Kubelet)
   定義ファイル
   オーケストレータ
   (e.g. ECS, Kubernetes)
   コンテナイメージ置場
   (e.g. Amazon ECR, Docker Hub)
   Download
   コンテナランタイム
   (e.g. Dockerd)
   

   View Slide

7. コンテナのデプロイメントモデル (超概略)
   初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門
   コントロールプレーン データプレーン
   Call API(s)
   ノード x N
   CD システム
   Call API(s)
   コンテナエージェント
   (e.g. ECS Agent, Kubelet)
   定義ファイル
   オーケストレータ
   (e.g. ECS, Kubernetes)
   コンテナイメージ置場
   (e.g. Amazon ECR, Docker Hub)
   Download
   コンテナランタイム
   (e.g. Dockerd)
   1. コンテナの状態異常/クラッシュを検知︕
   

   View Slide

8. コンテナのデプロイメントモデル (超概略)
   初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門
   コントロールプレーン データプレーン
   Call API(s)
   ノード x N
   1. コンテナの状態異常/クラッシュを検知︕
   2. 置換/再実⾏︕
   CD システム
   Call API(s)
   コンテナエージェント
   (e.g. ECS Agent, Kubelet)
   定義ファイル
   オーケストレータ
   (e.g. ECS, Kubernetes)
   コンテナイメージ置場
   (e.g. Amazon ECR, Docker Hub)
   Download
   コンテナランタイム
   (e.g. Dockerd)
   

   View Slide

9. 複数の環境構成と理想の世界 (超概略)
   初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門
   いろんな
   AWS
   リソース
   いろんな
   AWS
   リソース
   いろんな
   AWS
   リソース
   アプリケーションがどう実装されているかが
   これらの実現可能性を決める重要な要素の⼀つ
   

   View Slide

10. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    アプリケーション開発者は
    Amazon ECS あるいは Kubernetes を
    どこまで知るべきか
    

    View Slide

11. 理想
    • 理想はもちろん「⾃⾝ですべてを管理、運⽤できるレベル」
    開発と運⽤が分断された世界での開発者の現実的なゴール
    • ⾃⾝のアプリケーションの動作に必要な各種定義を書き、運⽤できるレベル
    § Dockerfile の記述
    § Amazon ECS タスク/サービス定義、あるいは Kubernetes マニフェスト
    § (⾃分で書かないとしても)書く⼈とディスカッションできるレベルの知識が必須
    • アプリケーションからコンテナのレベルまでの障害調査ができるレベル
    § 運⽤経験がないアプリケーション開発者には特に初期段階で難易度が⾼いことも
    § 運⽤知⾒のメンバーによる協⼒が重要
    結論から
    ア プ リ ケ ー シ ョ ン 開 発 者 は A M A Z O N E C S あ る い は K U B E R N E T E S を ど こ ま で 知 れ ば い い の か
    

    View Slide

12. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    アプリケーション開発者は
    Amazon ECS あるいは Kubernetes を
    どこまで知るべきか
    

    View Slide

13. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    アプリケーション開発者は
    運⽤を
    どこまで知るべきか
    

    View Slide

14. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    You build it, you run it
    

    View Slide

15. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    “Giving developers operational
    responsibilities has greatly enhanced the
    quality of the services, both from a
    customer and a technology point of
    view.”
    Werner Vogels
    VP & CTO of Amazon ACM / June 30, 2006 - “A Conversation with Werner Vogels”
    https://queue.acm.org/detail.cfm?id=1142065
    

    View Slide

16. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    “The traditional model is that you take
    your software to the wall that separates
    development and operations, and throw
    it over and then forget about it.
    Not at Amazon.”
    Werner Vogels
    VP & CTO of Amazon ACM / June 30, 2006 - “A Conversation with Werner Vogels”
    https://queue.acm.org/detail.cfm?id=1142065
    

    View Slide

17. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    “You build it, you run it.”
    Werner Vogels
    VP & CTO of Amazon ACM / June 30, 2006 - “A Conversation with Werner Vogels”
    https://queue.acm.org/detail.cfm?id=1142065
    

    View Slide

18. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    “This brings developers into contact with
    the day-to-day operation of their
    software. It also brings them into day-to-
    day contact with the customer.
    This customer feedback loop is essential
    for improving the quality of the service.”
    Werner Vogels
    VP & CTO of Amazon ACM / June 30, 2006 - “A Conversation with Werner Vogels”
    https://queue.acm.org/detail.cfm?id=1142065
    

    View Slide

19. • とはいえ運⽤に知⾒ある⼈やチームに運⽤業務を集めるのは⾃然な流れ
    § 開発や運⽤に限らずマーケティング、⼈事など、業務の細分化と専業化は組織の必然
    • 『コード書きました、あとはよろしくさようなら👋』が問題
    § 組織図上のチームが開発と運⽤に分かれていること⾃体は問題ではない
    § 開発/運⽤の両者が、共通のゴールと運⽤上の責任を共同で持つことが⼤事
    • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない
    “You build it, you run it”
    

    View Slide

20. • ソフトウェアは運⽤フェーズに到達してはじめて価値を提供できる
    • 開発段階で⾒て⾒ぬふりをした複雑性は運⽤フェーズに押し込まれる
    • 開発から押し込まれた複雑性は、運⽤にワークアラウンドを⽣む
    • 運⽤のワークアラウンドは将来の開発に予期しない制約を作り出す
    なぜ運⽤性に優れたソフトウェアが重要か
    Code Build Test Deploy Monitor
    Rollout/Rollback
    本質的な機能開発に集中するために、開発者が運⽤に、運⽤者が開発に
    参加することで包括的なソフトウェア品質向上させる
    

    View Slide

21. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    運⽤性を損なう実装8選
    

    View Slide

22. 1. スケールアウトできない、しにくい
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • 「アプリケーションの状態」をローカルディスクに/から読み書きしている
    fs.writeFile(`./sess-${userid}`, sess, function (err) {
    if (err) return console.log(err);
    });
    何が問題か︖
    • マシン台数の追加によるスケールアウトができない
    • マシンをスケールアップする必要が⽣まれ、そのマシン故障時の影響が⼤きくなる
    • スケールアップ限界はスケールアウトより早い (e.g. アプリがリソースを使いきれない)
    改善策
    • 「アプリケーションの状態」は外部 (e.g. RDS, S3, ElastiCache …) に永続化する
    

    View Slide

23. 2. 依存パッケージ解決を⾃動化できない
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • ︖「そのライブラリは https://xxx から落としてきて lib ディレクトリに置いてください」
    • ︖「バージョンはよく分かんないけどとりあえず最新とかでいいんじゃないですかね」
    • ︖「社内共通ライブラリ︖あれは共有ファイルサーバに置いてありますね」
    何が問題か︖
    • 新バージョンのデプロイのたびに開発・運⽤間でのやり取りと⼿作業が発⽣する
    • チーム間の依存関係によるデリバリ速度の低下
    • ⼿作業によるミスオペレーションの誘発 (e.g. 意図しないライブラリバージョンの混⼊など)
    改善策
    • 利⽤している⾔語やフレームワークでサポートされている依存解決ツールを利⽤する
    • 依存解決ツール未サポートの「社内共通ライブラリ」はアプリケーションリポジトリにバンドル
    する⽅がマシ
    

    View Slide

24. 3. 安全に停⽌できない
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • 処理中に SIGTERM (= アプリケーション終了指⽰) が送られてくる可能性の未考慮
    • SIGTERM や SIGKILL を受け取ると異常終了する
    何が問題か︖
    • 異常終了によりデータが不正な形でデータベースなどに記録されてしまう可能性
    • デプロイ(= 新 ver の起動と旧 ver の停⽌)のたびにエンドユーザに 5xx エラーが返る可能性
    • ワークアラウンドとしてデプロイ時のサービス提供中断 → ユーザ体験悪化
    改善策
    • SIGTERM を受け取ったら終了処理を⾏う実装を追加する
    • 処理中データの取り扱いまで含めて設計で考慮する
    • Web アプリケーションフレームワークなどで⼀定程度の
    終了処理が実装済みであることも
    process.on('SIGTERM', () => {
    // TODO: Do something here
    process.exit(0);
    });
    

    View Slide

25. 4. 起動処理時間が⻑い
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • 起動時の初期処理に⻑⼤な時間を要する処理が含まれている (e.g. 重たいデータのダウンロード)
    何が問題か︖
    • 起動がタイムアウト範囲内に収まらずデプロイが失敗する → 運⽤でのワークアラウンド検討
    • デプロイ処理の⻑時間化 → 必要以上の⻑時間メトリクス監視など、運⽤業務の⾮効率化
    • サービスが不安定になりうるタイミングの⻑時間化
    改善策
    • 起動時の初期処理からそのような処理を外す⽅法を検討する
    • e.g. 起動時のダウンロードではなく、コンテナイメージ作成時点で同梱するなど
    

    View Slide

26. 5. ビルド/パッケージング前に⼿作業が必要
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • コードに設定値や環境依存のパラメータが
    直接記述してある
    何が問題か︖
    • そもそも→の例はとても安全とは⾔えない
    • ビルドやデプロイ前に⼿作業での設定値書き換えが必要になる
    • 環境別にコンテナイメージの作り直しが必要になる可能性を⾼める
    改善策
    • 環境変数から設定値や環境依存のパラメータを読み取るように実装を変更する
    let connection = mysql.createConnection({
    host: 'localhost’,
    user: 'root’,
    password: 'strong-password’,
    database: 'my-awesome-database'
    });
    

    View Slide

27. 6. 設定値を実⾏時に外部から注⼊できない
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • 設定値や環境依存パラメータを直接記述
    • 設定値は「設定ファイル」からのみ
    • 実装が実⾏環境の環境名などに依存
    何が問題か︖
    • 環境を増やすためにコード改変が必要
    • ビルドやデプロイ前に⼿作業での設定値書き換えが必要になる可能性
    • 環境別にコンテナイメージの作り直しが必要になる可能性
    改善策
    • 環境変数から設定値や環境依存のパラメータを読み取るように実装を変更する
    • 環境名 (e.g. production, staging) は単なるラベルであり処理の挙動を変更するものであってはならない
    var dbHost = 'localhost'; // default
    switch (env) {
    case 'production’:
    dbHost = 'really-prod.db’;
    break;
    case 'staging’:
    dbHost = 'somewhat-staging.db’;
    break;
    // continued
    }
    

    View Slide

28. 7. ログをファイルにしか出⼒できない
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • ログの出⼒先がファイルに固定されており、変更できない
    何が問題か︖
    • ログを⾒るためにコンテナの中に⼊りますか︖
    • ⼊ろうとしたコンテナが直前で異常終了して消えてしまったらどうしますか︖
    • NFS マウントのような不要に複雑化したアーキテクチャにしてお茶を濁していませんか︖
    改善策
    • 設定次第でアプリケーションログを標準出⼒/標準エラー出⼒に送れるようにする
    • コンテナの世界では標準出⼒/標準エラー出⼒にログを送ったほうが後続の取り回しがしやすい
    

    View Slide

29. 8. ”Read レプリカ” を使えない
    運 ⽤ 性 を 損 な う 実 装 8 選
    良くない実装例
    • 接続を永続的に持つタイプのデータストアの利⽤において、⼀つの接続先しか想定していない
    何が問題か︖
    • 書込⽤データベースと読取⽤のデータベースに分けることによるパフォーマンス向上の
    テクニックが使えない
    • データベースをスケールアップすべき状況とスケールアウトすべき状況は異なる
    改善策
    • 少なくとも書込⽤と読取⽤の2つのデータベースを接続先として利⽤するケースを想定する
    

    View Slide

30. 1. スケールアウトできない、しにくい
    2. 依存パッケージ解決を⾃動化できない
    3. 安全に停⽌できない
    4. 起動処理時間が⻑い
    5. ビルド/パッケージング時に⼿作業が必要
    6. 設定値を実⾏時に外部から注⼊できない
    7. ログをファイルにしか出⼒できない
    8. “Read レプリカ” を使えない
    etc., etc.
    運⽤性を損なう実装8選
    

    View Slide

31. • ⾃⾝が運⽤を意識したコードを
    書けているか評価するのに最適
    • 運⽤観点での最良の実装や設計が
    そのアプリケーションにとって
    最良の実装になりえないケースは
    往々にしてある
    § そのような場合にも開発者と運⽤担当者が
    積極的に打開策をディスカッションする
    The Twelve-Factor App
    H T T P S : / / 1 2 F A C T O R . N E T / J A /
    

    View Slide

32. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    なぜ Dockerfile や ECS タスク定義を
    開発者が書いて運⽤すべきなのか
    

    View Slide

33. AWS 責任共有モデル
    https://aws.amazon.com/jp/compliance/shared-responsibility-model/
    

    View Slide

34. AWS 責任共有モデル – Amazon EC2
    https://aws.amazon.com/jp/compliance/shared-responsibility-model/
    AWS responsibility
    Customer responsibility
    Physical Server(s)
    Hypervisor
    EC2 Instances
    App
    Language
    Runtime
    OS
    

    View Slide

35. もし AWS 責任共有モデルがこうだったなら︖
    AWS responsibility
    Customer responsibility
    Physical Server(s)
    Hypervisor
    EC2 Instances
    App
    Language
    Runtime
    OS
    

    View Slide

36. なぜこの不思議な境界線を許容できるのか︖
    AWS responsibility
    Customer responsibility
    Physical Server(s)
    Hypervisor
    EC2 Instance
    OS
    App
    Language
    Runtime
    Container Orchestration Agent
    Containers
    Container
    Orchestrator
    App
    Language
    Runtime
    開発
    運⽤
    

    View Slide

37. 許容可能な境界はどこか
    AWS responsibility
    Customer responsibility
    Physical Server(s)
    Hypervisor
    EC2 Instance
    OS
    App
    Language
    Runtime
    Container Orchestration Agent
    Containers
    Container
    Orchestrator
    App
    Language
    Runtime
    開発
    運⽤
    開発
    運⽤
    

    View Slide

38. • Dockerfile を書く、オーケストレータ⽤定義ファイルを書く
    • コンテナから上のレイヤーに運⽤責務を持ち、オンコールも受け持つ
    • 運⽤担当者が実装レベルで会話ができるよう積極的に⽀援する
    許容可能な組織内の責任共有モデルを定義する
    Container
    Orchestrator
    開発 … コンテナから上への責務
    運⽤ … コンテナより下への責務
    Physical Server(s)
    Hypervisor
    EC2 Instance
    OS
    App
    Language
    Runtime
    Container Orchestration Agent
    Containers
    App
    Language
    Runtime
    Customer
    responsibility
    AWS
    responsibility
    • コンテナから下のレイヤーに責務を持つ
    • 開発者が投⼊するコンテナが実⾏できる環境の維持に責務を持つ
    • 開発者が運⽤観点での設計とコード記述ができるよう積極的に⽀援する
    

    View Slide

39. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    アプリケーション開発者は
    Amazon ECS あるいは Kubernetes を、
    そして運⽤を、どこまで知ればいいのか
    

    View Slide

40. • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない
    § ソフトウェアの価値がユーザに提供されるのは運⽤フェーズ
    • 開発と運⽤に明確な責任分界点が必要な場合は、
    § コンテナから上を開発チーム、コンテナより下を運⽤チームの責任範囲とする
    § 開発者は Dockerfile を書き、コンテナオーケストレータの定義ファイルを書く
    § 開発チームもオンコールを受け持ち、障害対応や運⽤改善を⾏う
    • 開発と運⽤が共通のゴールを持ち、責任を共有することが継続的
    デリバリを前提とするソフトウェアの理想
    § どうなれば運⽤しやすいか︖どうなれば開発しやすいか︖を相互に聞き合い、協⼒する
    まとめ
    

    View Slide

41. Thank you!
    © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved.
    Tori Hara / toricls
    Sr. Product Developer Advocate
    Elastic Containers, AWS
    

    View Slide