アプリケーション開発者は 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 を どこまで知るべきか
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 が好きです
3. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. 想定聴講者 • 『運⽤』が必要なアプリケーション(Web アプリとか)を書いている • コンテナ技術そのものは知っている、あるいは普段の開発に使っている • ⾃分のアプリの運⽤⽅法は知らないが、コンテナを使っていると街の噂を聞いたことが • コンテナワークロードでのアプリケーション開発者の責務の範囲にガイドラインが欲しい ゴール • 運⽤を難しくしてしまうアプリケーション実装例を学び、対処策を実践できるようになる • (少なくとも)Amazon ECS タスク/サービス定義や Kubernetes マニフェストを開発者⾃⾝ が書けるようになる必要性を理解し、実践できるようになる • ソフトウェアライフサイクルのステークホルダがシステムに共同で責任を持つことの. 重要性と妥当性を理解し、⾃社への適⽤に取り組む気持ちを持つ セッション対象者とゴール
4. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. (初学者のための) コンテナワークロード超⼊⾨
5. コンテナとは (超概略) 初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門 ランタイム/エンジン アプリケーションコード 依存ライブラリ/パッケージ + 設定
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)
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. コンテナの状態異常/クラッシュを検知︕
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)
9. 複数の環境構成と理想の世界 (超概略) 初 学 者 の た め の コ ン テ ナ ワ ー ク ロ ー ド 超 入 門 いろんな AWS リソース いろんな AWS リソース いろんな AWS リソース アプリケーションがどう実装されているかが これらの実現可能性を決める重要な要素の⼀つ
10. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション開発者は Amazon ECS あるいは Kubernetes を どこまで知るべきか
11. 理想 • 理想はもちろん「⾃⾝ですべてを管理、運⽤できるレベル」 開発と運⽤が分断された世界での開発者の現実的なゴール • ⾃⾝のアプリケーションの動作に必要な各種定義を書き、運⽤できるレベル § Dockerfile の記述 § Amazon ECS タスク/サービス定義、あるいは Kubernetes マニフェスト § (⾃分で書かないとしても)書く⼈とディスカッションできるレベルの知識が必須 • アプリケーションからコンテナのレベルまでの障害調査ができるレベル § 運⽤経験がないアプリケーション開発者には特に初期段階で難易度が⾼いことも § 運⽤知⾒のメンバーによる協⼒が重要 結論から ア プ リ ケ ー シ ョ ン 開 発 者 は A M A Z O N E C S あ る い は K U B E R N E T E S を ど こ ま で 知 れ ば い い の か
12. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション開発者は Amazon ECS あるいは Kubernetes を どこまで知るべきか
13. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション開発者は 運⽤を どこまで知るべきか
14. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. You build it, you run it
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
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
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
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
19. • とはいえ運⽤に知⾒ある⼈やチームに運⽤業務を集めるのは⾃然な流れ § 開発や運⽤に限らずマーケティング、⼈事など、業務の細分化と専業化は組織の必然 • 『コード書きました、あとはよろしくさようなら👋』が問題 § 組織図上のチームが開発と運⽤に分かれていること⾃体は問題ではない § 開発/運⽤の両者が、共通のゴールと運⽤上の責任を共同で持つことが⼤事 • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない “You build it, you run it”
20. • ソフトウェアは運⽤フェーズに到達してはじめて価値を提供できる • 開発段階で⾒て⾒ぬふりをした複雑性は運⽤フェーズに押し込まれる • 開発から押し込まれた複雑性は、運⽤にワークアラウンドを⽣む • 運⽤のワークアラウンドは将来の開発に予期しない制約を作り出す なぜ運⽤性に優れたソフトウェアが重要か Code Build Test Deploy Monitor Rollout/Rollback 本質的な機能開発に集中するために、開発者が運⽤に、運⽤者が開発に 参加することで包括的なソフトウェア品質向上させる
21. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. 運⽤性を損なう実装8選
22. 1. スケールアウトできない、しにくい 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • 「アプリケーションの状態」をローカルディスクに/から読み書きしている fs.writeFile(`./sess-${userid}`, sess, function (err) { if (err) return console.log(err); }); 何が問題か︖ • マシン台数の追加によるスケールアウトができない • マシンをスケールアップする必要が⽣まれ、そのマシン故障時の影響が⼤きくなる • スケールアップ限界はスケールアウトより早い (e.g. アプリがリソースを使いきれない) 改善策 • 「アプリケーションの状態」は外部 (e.g. RDS, S3, ElastiCache …) に永続化する
23. 2. 依存パッケージ解決を⾃動化できない 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • ︖「そのライブラリは https://xxx から落としてきて lib ディレクトリに置いてください」 • ︖「バージョンはよく分かんないけどとりあえず最新とかでいいんじゃないですかね」 • ︖「社内共通ライブラリ︖あれは共有ファイルサーバに置いてありますね」 何が問題か︖ • 新バージョンのデプロイのたびに開発・運⽤間でのやり取りと⼿作業が発⽣する • チーム間の依存関係によるデリバリ速度の低下 • ⼿作業によるミスオペレーションの誘発 (e.g. 意図しないライブラリバージョンの混⼊など) 改善策 • 利⽤している⾔語やフレームワークでサポートされている依存解決ツールを利⽤する • 依存解決ツール未サポートの「社内共通ライブラリ」はアプリケーションリポジトリにバンドル する⽅がマシ
24. 3. 安全に停⽌できない 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • 処理中に SIGTERM (= アプリケーション終了指⽰) が送られてくる可能性の未考慮 • SIGTERM や SIGKILL を受け取ると異常終了する 何が問題か︖ • 異常終了によりデータが不正な形でデータベースなどに記録されてしまう可能性 • デプロイ(= 新 ver の起動と旧 ver の停⽌)のたびにエンドユーザに 5xx エラーが返る可能性 • ワークアラウンドとしてデプロイ時のサービス提供中断 → ユーザ体験悪化 改善策 • SIGTERM を受け取ったら終了処理を⾏う実装を追加する • 処理中データの取り扱いまで含めて設計で考慮する • Web アプリケーションフレームワークなどで⼀定程度の 終了処理が実装済みであることも process.on('SIGTERM', () => { // TODO: Do something here process.exit(0); });
25. 4. 起動処理時間が⻑い 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • 起動時の初期処理に⻑⼤な時間を要する処理が含まれている (e.g. 重たいデータのダウンロード) 何が問題か︖ • 起動がタイムアウト範囲内に収まらずデプロイが失敗する → 運⽤でのワークアラウンド検討 • デプロイ処理の⻑時間化 → 必要以上の⻑時間メトリクス監視など、運⽤業務の⾮効率化 • サービスが不安定になりうるタイミングの⻑時間化 改善策 • 起動時の初期処理からそのような処理を外す⽅法を検討する • e.g. 起動時のダウンロードではなく、コンテナイメージ作成時点で同梱するなど
26. 5. ビルド/パッケージング前に⼿作業が必要 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • コードに設定値や環境依存のパラメータが 直接記述してある 何が問題か︖ • そもそも→の例はとても安全とは⾔えない • ビルドやデプロイ前に⼿作業での設定値書き換えが必要になる • 環境別にコンテナイメージの作り直しが必要になる可能性を⾼める 改善策 • 環境変数から設定値や環境依存のパラメータを読み取るように実装を変更する let connection = mysql.createConnection({ host: 'localhost’, user: 'root’, password: 'strong-password’, database: 'my-awesome-database' });
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 }
28. 7. ログをファイルにしか出⼒できない 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • ログの出⼒先がファイルに固定されており、変更できない 何が問題か︖ • ログを⾒るためにコンテナの中に⼊りますか︖ • ⼊ろうとしたコンテナが直前で異常終了して消えてしまったらどうしますか︖ • NFS マウントのような不要に複雑化したアーキテクチャにしてお茶を濁していませんか︖ 改善策 • 設定次第でアプリケーションログを標準出⼒/標準エラー出⼒に送れるようにする • コンテナの世界では標準出⼒/標準エラー出⼒にログを送ったほうが後続の取り回しがしやすい
29. 8. ”Read レプリカ” を使えない 運 ⽤ 性 を 損 な う 実 装 8 選 良くない実装例 • 接続を永続的に持つタイプのデータストアの利⽤において、⼀つの接続先しか想定していない 何が問題か︖ • 書込⽤データベースと読取⽤のデータベースに分けることによるパフォーマンス向上の テクニックが使えない • データベースをスケールアップすべき状況とスケールアウトすべき状況は異なる 改善策 • 少なくとも書込⽤と読取⽤の2つのデータベースを接続先として利⽤するケースを想定する
30. 1. スケールアウトできない、しにくい 2. 依存パッケージ解決を⾃動化できない 3. 安全に停⽌できない 4. 起動処理時間が⻑い 5. ビルド/パッケージング時に⼿作業が必要 6. 設定値を実⾏時に外部から注⼊できない 7. ログをファイルにしか出⼒できない 8. “Read レプリカ” を使えない etc., etc. 運⽤性を損なう実装8選
31. • ⾃⾝が運⽤を意識したコードを 書けているか評価するのに最適 • 運⽤観点での最良の実装や設計が そのアプリケーションにとって 最良の実装になりえないケースは 往々にしてある § そのような場合にも開発者と運⽤担当者が 積極的に打開策をディスカッションする The Twelve-Factor App H T T P S : / / 1 2 F A C T O R . N E T / J A /
32. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. なぜ Dockerfile や ECS タスク定義を 開発者が書いて運⽤すべきなのか
33. AWS 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/
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
35. もし AWS 責任共有モデルがこうだったなら︖ AWS responsibility Customer responsibility Physical Server(s) Hypervisor EC2 Instances App Language Runtime OS
36. なぜこの不思議な境界線を許容できるのか︖ AWS responsibility Customer responsibility Physical Server(s) Hypervisor EC2 Instance OS App Language Runtime Container Orchestration Agent Containers Container Orchestrator App Language Runtime 開発 運⽤
37. 許容可能な境界はどこか AWS responsibility Customer responsibility Physical Server(s) Hypervisor EC2 Instance OS App Language Runtime Container Orchestration Agent Containers Container Orchestrator App Language Runtime 開発 運⽤ 開発 運⽤
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 • コンテナから下のレイヤーに責務を持つ • 開発者が投⼊するコンテナが実⾏できる環境の維持に責務を持つ • 開発者が運⽤観点での設計とコード記述ができるよう積極的に⽀援する
39. © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. アプリケーション開発者は Amazon ECS あるいは Kubernetes を、 そして運⽤を、どこまで知ればいいのか
40. • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない § ソフトウェアの価値がユーザに提供されるのは運⽤フェーズ • 開発と運⽤に明確な責任分界点が必要な場合は、 § コンテナから上を開発チーム、コンテナより下を運⽤チームの責任範囲とする § 開発者は Dockerfile を書き、コンテナオーケストレータの定義ファイルを書く § 開発チームもオンコールを受け持ち、障害対応や運⽤改善を⾏う • 開発と運⽤が共通のゴールを持ち、責任を共有することが継続的 デリバリを前提とするソフトウェアの理想 § どうなれば運⽤しやすいか︖どうなれば開発しやすいか︖を相互に聞き合い、協⼒する まとめ
41. Thank you! © 2021, Amazon Web Services, Inc. or its affiliates. All rights reserved. Tori Hara / toricls Sr. Product Developer Advocate Elastic Containers, AWS