Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アプリケーション開発者は Amazon ECS あるいは Kubernetes をどこまで知る...

Tori Hara
September 29, 2021

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

Tori Hara

September 29, 2021
Tweet

More Decks by Tori Hara

Other Decks in Technology

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. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. 運⽤性を損なう実装8選
  20. 1. スケールアウトできない、しにくい 運 ⽤ 性 を 損 な う 実

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

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

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

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

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

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

    う 実 装 8 選 良くない実装例 • 接続を永続的に持つタイプのデータストアの利⽤において、⼀つの接続先しか想定していない 何が問題か︖ • 書込⽤データベースと読取⽤のデータベースに分けることによるパフォーマンス向上の テクニックが使えない • データベースをスケールアップすべき状況とスケールアウトすべき状況は異なる 改善策 • 少なくとも書込⽤と読取⽤の2つのデータベースを接続先として利⽤するケースを想定する
  28. 1. スケールアウトできない、しにくい 2. 依存パッケージ解決を⾃動化できない 3. 安全に停⽌できない 4. 起動処理時間が⻑い 5. ビルド/パッケージング時に⼿作業が必要

    6. 設定値を実⾏時に外部から注⼊できない 7. ログをファイルにしか出⼒できない 8. “Read レプリカ” を使えない etc., etc. 運⽤性を損なう実装8選
  29. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. なぜ Dockerfile や ECS タスク定義を 開発者が書いて運⽤すべきなのか
  30. なぜこの不思議な境界線を許容できるのか︖ AWS responsibility Customer responsibility Physical Server(s) Hypervisor EC2 Instance

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

    OS App Language Runtime Container Orchestration Agent Containers Container Orchestrator App Language Runtime 開発 運⽤ 開発 運⽤
  32. • Dockerfile を書く、オーケストレータ⽤定義ファイルを書く • コンテナから上のレイヤーに運⽤責務を持ち、オンコールも受け持つ • 運⽤担当者が実装レベルで会話ができるよう積極的に⽀援する 許容可能な組織内の責任共有モデルを定義する Container Orchestrator

    開発 … コンテナから上への責務 運⽤ … コンテナより下への責務 Physical Server(s) Hypervisor EC2 Instance OS App Language Runtime Container Orchestration Agent Containers App Language Runtime Customer responsibility AWS responsibility • コンテナから下のレイヤーに責務を持つ • 開発者が投⼊するコンテナが実⾏できる環境の維持に責務を持つ • 開発者が運⽤観点での設計とコード記述ができるよう積極的に⽀援する
  33. © 2021, Amazon Web Services, Inc. or its affiliates. All

    rights reserved. アプリケーション開発者は Amazon ECS あるいは Kubernetes を、 そして運⽤を、どこまで知ればいいのか
  34. • 運⽤性に優れたソフトウェアは運⽤を無視した開発からは⽣まれない § ソフトウェアの価値がユーザに提供されるのは運⽤フェーズ • 開発と運⽤に明確な責任分界点が必要な場合は、 § コンテナから上を開発チーム、コンテナより下を運⽤チームの責任範囲とする § 開発者は

    Dockerfile を書き、コンテナオーケストレータの定義ファイルを書く § 開発チームもオンコールを受け持ち、障害対応や運⽤改善を⾏う • 開発と運⽤が共通のゴールを持ち、責任を共有することが継続的 デリバリを前提とするソフトウェアの理想 § どうなれば運⽤しやすいか︖どうなれば開発しやすいか︖を相互に聞き合い、協⼒する まとめ
  35. Thank you! © 2021, Amazon Web Services, Inc. or its

    affiliates. All rights reserved. Tori Hara / toricls Sr. Product Developer Advocate Elastic Containers, AWS