The Twelve-Factor App とクラウドアプリケーションのコスト

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 吉竹直樹 Technical Project Manager Japan Digital Design • 2022 APN AWS Top Engineer • 『AWS認定資格試験テキスト AWS認定SysOpsアドミニストレーター – アソシエイト』の執筆に参加プロフィールこの写真は犬カフェのもので飼い犬ではありません。かわいいけど資格等 • 2023/11〜 JDD • Tech PM としてプロジェクトマネジメントをしつつ、技術検証やアーキテクチャ検討も担当 • クラウドで動くアプリケーションの最適化を考えるのが好き

Slide 3

Slide 3 text

Slide 4

Slide 4 text

4 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 今回のテーマ re:Invent 2023 Dr. Werner Vogels の “The Frugal Architect”を見て、コストについて考える機会が増えたこのテーマにしたきっかけコンテナアプリケーション × コスト出典：https://www.youtube.com/watch?v=UTRBVPvzt9w&t

Slide 5

Slide 5 text

5 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 今回のテーマ • コンテナアプリケーションの開発プラクティスと言えば、 “The Twelve-Factor App” が有名 • 自身が担当していた業務でもこのプラクティスに沿っていたが、クラウドで思わぬコストが発生することがあった • コンテナアプリケーションのコストに関するLTをしますアプリケーション観点でコストを考えるコンテナアプリケーション × コスト

Slide 6

Slide 6 text

6 CONFIDENTIAL © 2024 Japan Digital Design, Inc. • “The Twelve-Factor App” はコンテナアプリケーションにとって有効なプラクティスだが、クラウドの使い方を誤ると思わぬコストが発生する • アプリケーション開発者を含む全員がクラウドのコストを意識するべきお伝えしたいこと対象の方 • コンテナアプリケーション開発に関わる人 • 特にアプリケーション開発者発表の対象者とお伝えたいこと

Slide 7

Slide 7 text

Slide 8

Slide 8 text

8 CONFIDENTIAL © 2024 Japan Digital Design, Inc. • Heroku のエンジニアが提唱したソフトウェア開発のための方法論 • 2011年頃に提供されて10年以上経つが、現在でも広く知られている • クラウド/コンテナのメリットを最大限活かしたアプリケーションの開発に有効なプラクティス • 「実行環境間での移植性を最大化」 • 「開発環境と本番環境の差異を最小限」 • 「アジリティを最大化する継続的デプロイ」 • AWS以外のクラウドでも同様に有効 The Twelve-Factor App (12FA) とは The Twelve-Factor App とは https://12factor.net/ja/

Slide 9

Slide 9 text

9 CONFIDENTIAL © 2024 Japan Digital Design, Inc. The Twelve-Factor App の一覧 I. コードベースバージョン管理されている1つのコードベースと複数のデプロイ II. 依存関係依存関係を明示的に宣言し分離する III. 設定設定を環境変数に格納する IV. バックエンドサービスバックエンドサービスをアタッチされたリソースとして扱う V. ビルド、リリース、実行ビルド、リリース、実行の3つのステージを厳密に分離する VI. プロセスアプリケーションを1つもしくは複数のステートレスなプロセスとして実行する VII. ポートバインディングポートバインディングを通してサービスを公開する VIII. 並行性プロセスモデルによってスケールアウトする IX. 廃棄容易性高速な起動とグレースフルシャットダウンで堅牢性を最大化する X. 開発/本番一致開発、ステージング、本番環境をできるだけ一致させた状態を保つ XI. ログログをイベントストリームとして扱う XII. 管理プロセス管理タスクを1回限りのプロセスとして実行する出典：https://12factor.net/ja/

Slide 10

Slide 10 text

10 CONFIDENTIAL © 2024 Japan Digital Design, Inc. The Twelve-Factor App × AWS I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス出典：https://12factor.net/ja/ CloudWatch Logs Auto Scaling Code Commit Code Artifact Parameter Store Secrets Manager Code Build / Deploy / Pipeline

Slide 11

Slide 11 text

11 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 12FA × AWS の資料やブログはたくさんあります The Twelve-Factor App × AWS https://speakerdeck.com/keisuke69/the-twelve-factor-app-on-aws https://speakerdeck.com/toricls/you-build-it-you-run-it https://aws.amazon.com/jp/builders-flash/202208/introductions- twelve-factors-app/ https://aws.amazon.com/jp/blogs/news/developing-twelve-factor-apps- using-amazon-ecs-and-aws-fargate/ https://www.slideshare.net/AmazonWebServicesJapan/the- twelvefactor-appaws https://www.youtube.com/watch?v=hVJ-IGy1SRw

Slide 12

Slide 12 text

12 CONFIDENTIAL © 2024 Japan Digital Design, Inc. e.g. セッションデータがファイル保存（VI.プロセス） 12FAが無いアプリケーションの例 e.g. 設定を環境変数にしていない（Ⅲ.設定） The Twelve-Factor App の例 • スケールアウトしたインスタンスにはデータが無く、クライアントはログアウト状態やエラーに • スティッキーセッションに頼っている • 接続先が変わる度にコードの修正が必要 • 変更できるメンバーが属人化 • 開発スピードの低下 • APIキーはセキュリティリスクもあり “id”: “ID01”, “data”: {… } Session ID Session ID Session ID Client Instance A Instance B app file app file IdをKeyにデータ取得 IdをKeyにデータ取得 Scale out

Slide 13

Slide 13 text

13 CONFIDENTIAL © 2024 Japan Digital Design, Inc. e.g. セッションデータを外部データベースに保存 12FAがあるアプリケーションの例 e.g. 設定を外部のパラメータ管理から環境変数で取得 The Twelve-Factor App の例 • スケールアウトしたインスタンスからもセッションデータを取得可能。スケールアウトが容易に • スティッキーセッションが不要 • 接続先が変わってもアプリのコードは修正不要 • 環境の設定値を一カ所で管理 • シークレット値（APIキー等）もセキュアに保存可能 Session ID Session ID Session ID Client Instance A Instance B app app IdをKeyにデータ取得 Secrets Manager Parameter Store *1 ElastiCache DynamoDB IdをKeyにデータ取得環境変数 (*1) 正式にはSystems Managerですが省略しています or or

Slide 14

Slide 14 text

14 CONFIDENTIAL © 2024 Japan Digital Design, Inc. • ポータビリティを高める • 開発も本番も同じコードベース • 環境変数を活用 • ステートレスな設計にする • 容易にスケールアウト/スケールインを実現 • プロセスの自動化 • パイプラインの構築 • アジリティとビルド/デプロイ作業の信頼性を高める 12FAの要点 The Twelve-Factor App の要点

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

17 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 今回紹介するケースと関連する要素 I. コードベース II. 依存関係 III. 設定 IV. バックエンドサービス V. ビルド、リリース、実行 VI. プロセス VII. ポートバインディング VIII. 並行性 IX. 廃棄容易性 X. 開発/本番一致 XI. ログ XII. 管理プロセス出典：https://12factor.net/ja/ 1 2 3 CloudWatch Logs Auto Scaling Code Commit Code Artifact Parameter Store Secrets Manager Code Build / Deploy / Pipeline

Slide 18

Slide 18 text

18 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『CloudWatch Logsが高い』 Case1. XI. ログ • 標準出力したログをLoggingDriver, Fluentbitを使って CloudWatch Logsに転送 • CloudWatch Logsは取込（収集）が高コストであるため、デバッグログ等を含めた大量のログを出力していると思わぬ高コストに繋がる • 開発環境で負荷テストを行う場合は更に注意が必要 • 通常のAccessLogだけでも相当なログが出力される • 大規模システムなら、負荷テスト1回で万単位の課金が発生する可能性あり Cluster ECS CloudWatch Logs e.g. ECSからログを標準出力標準出力負荷テスト AccessLog ErrorLog DebugLog 取込のコストに注意

Slide 19

Slide 19 text

19 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『CloudWatch Logsが高い』への対処 Case1. XI. ログ • 出力するログを環境の設定で切り替えられるようアプリを設計 • 設定の例 • Dev環境：DEBUG • Stg環境：INFO / WARNING / ERROR • 負荷テスト時には設定を変えてデバッグログは出さない Cluster ECS CloudWatch Logs e.g. ECSからログを標準出力標準出力 ErrorLog S3 AccessLog DebugLog 適切なログレベルの設計 1 ログルーターの利用 2 適切なログレベルの設計 1 • Fluent Bitを使い、ログごとに出力先を切り替え • ログ量が多い場合、コストが低いサービスへルーティング • 設定の例：負荷テスト時 • Error Log：CloudWatch Logs • Debug Log / Access Log：S3 ログルーターの利用 2

Slide 20

Slide 20 text

20 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『Secrets Manager/KMSが高い』 Case2. III. 設定 • コンテナ起動時に環境変数を設定する場合は基本的に問題無し • 大量のシークレットがある場合は注意 • アプリケーション内で明示的にSecrets MangerのAPIを利用することがあればコストに注意 • 実行ごとにAPI利用のコストが発生 • カスタマー管理キーを利用している場合、 KMSのコストも発生する Cluster ECS e.g. Secrets Managerからシークレットを取得環境変数を設定 Secrets Manager KMS APIコールによる料金 API利用キーによる暗号化カスタマー管理キーによる料金 ※Parameter Storeもアドバンスドパラメータを利用する場合は注意

Slide 21

Slide 21 text

21 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『Secrets Manager/KMSが高い』への対処 Case2. III. 設定 • タスク定義からSecrets Managerのシークレットを取得可能 • コンテナ起動時に環境変数として設定される • アプリケーションからAPI利用しない • タスクロールにSecrets Managerの許可を与えないのも手 e.g. Secrets Managerからシークレットを取得起動時のみシークレット取得 1 • 「アプリケーション内部の設定は含まない」と12FAでは明記されている（e.g. Railsのconfig/routes.rb） • これらは環境変数にせず、コードとして扱う • 環境変数が増えればSecrets Managerのコストも増える • 管理負荷も増加むやみに環境変数にしない 2 Cluster ECS 環境変数を設定 Secrets Manager KMS キーによる暗号化むやみに環境変数にしない 2 起動時のみシークレット取得 1

Slide 22

Slide 22 text

22 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『データベースが高い』 Case3. VIII. 並行性 • 構成は12FAに則ったアプリケーション • 一見すると何も問題無い（むしろ良い）ように見えるが… • 例えば、内部ユーザー向けアプリケーションだったとしたら少し違った見方ができる e.g. セッションデータを外部DBに保存 Session ID Session ID Session ID Client Instance A Instance B app app IdをKeyにデータ取得 ElastiCache DynamoDB IdをKeyにデータ取得 or

Slide 23

Slide 23 text

23 CONFIDENTIAL © 2024 Japan Digital Design, Inc. アプリケーションの比較観点外部ユーザー向け内部ユーザー向け例 ECサイト, スマホアプリ, SaaS 管理コンソール, 業務アプリ利用者数多い少ない利用者の変動大きい小さいバックログ優先度高い低い変更頻度多い少ないバグへの許容度低い高い（※影響度次第）リリース頻度多い少ない停止の許容度低い高い変更が少ないアプリケーションに、クラウド/コンテナが向いているとは言えない

Slide 24

Slide 24 text

24 CONFIDENTIAL © 2024 Japan Digital Design, Inc. 『データベースが高い』への示唆 Case3. VIII. 並行性 • DBのインスタンスを置くことはオーバースペックかもしれない • 利用ユーザー数が予測可能 • スケールイン/スケールアウトも無い • Blue/Greenデプロイも nice-to-have • アーキテクチャはトレードオフ。コスト次第ではステートフルな設計も検討 • 他のデータベースに相乗り • ディスク（ファイル）の利用 • アーキテクチャ決定の経緯を文書化することが重要 • ADR（Architecture Decision Records） • 「このアーキテクチャになった理由は？」とならないために e.g. セッションデータを外部DBに保存 Session ID Session ID Session ID Client Instance A Instance B app app IdをKeyにデータ取得 ElastiCache DynamoDB IdをKeyにデータ取得 or 必要性を議論

Slide 25

Slide 25 text

25 CONFIDENTIAL © 2024 Japan Digital Design, Inc. コストはいずれ放置できない金額になることもクラウドのコストに対する考察 • コストの大半をコンピューティング/DBが占めるケースは多い • ECS / EKS / AppRunner etc. • RDS / Aurora RDS / ElastiCache etc. • CloudWatch LogsやSecrets Manager含む他サービスは相対的に金額も小さい。が、それゆえに • サービスのコストが高いことに気付きにくい • 気付いても対応が後回しにされやすい • リソース量（e.g.転送量, ログ量など）の見積りは難しい • アプリケーションによるコスト増に気付くのは運用が始まってからのケースが多い金額その他サービス見積実績コンピューティング /DB コンピューティング /DB その他サービスクラウドコストの内訳

Slide 26

Slide 26 text

Slide 27

Slide 27 text

27 CONFIDENTIAL © 2024 Japan Digital Design, Inc. アプリケーション開発者がコスト増加を防ぐ無駄なコストを減らすには • 運用でのコスト増加を開発の段階で予防するには、アプリケーション開発者もクラウドのコストを意識する必要がある。開発者もオーナーシップを持つ • JAWSへの参加 / チーム内での勉強会 etc. 金額オンプレクラウド固定費・ハードウェア・ライセンス・DC費用・電力/冷却 etc. 変動費・クラウド利用料・SaaS利用料・ライセンス etc. コストが上がるか下がるかは利用者次第オンプレとクラウドのコスト比較オンプレクラウド特徴 • サイジング時にコストがほぼ決定 • 決められたマシンリソース内でアプリケーションが稼働 • リソースを使った分だけ課金 • 柔軟なリソースの変更が可能 • リソースをどれだけ使うかはインフラ/アプリケーション次第

Slide 28

Slide 28 text

Slide 29

Slide 29 text

29 CONFIDENTIAL © 2024 Japan Digital Design, Inc. • クラウド/コンテナアプリケーションでの12FAの有効性 • 思わぬコストに繋がるケースがあるが、アプリケーションの設計で回避できる • 標準出力での大量のログ出力 • パラメータを取得するAPIの大量利用 • 特性を考慮したアーキテクチャ • 開発時にコスト増加を予防できるのは、アプリケーション開発者発表のサマリサマリ

Slide 30

Slide 30 text

30 CONFIDENTIAL © 2024 Japan Digital Design, Inc. • “The Twelve-Factor App” はコンテナアプリケーションにとって有効なプラクティスだが、クラウドの使い方を誤ると思わぬコストが発生する • アプリケーション開発者を含む全員がクラウドのコストを意識するべき • 楽しいクラウド/コンテナ生活を送りましょう改めて、お伝えしたいこと対象の方 • コンテナアプリケーション開発に関わる人 • 特にアプリケーション開発者発表の対象者とお伝えたいこと

Slide 31

Slide 31 text

Slide 32

Slide 32 text

32 CONFIDENTIAL © 2024 Japan Digital Design, Inc. ● AWS re:Invent 2023参加報告（前編）ーAWS re:Invent 2023で感じた生成系AIの盛り上がり ● AWS re:Inforce現地参加で体感した金融×クラウドセキュリティの新しい当たり前公開記事のテーマ JDDについて JDDコーポレートサイト https://japan-d2.com/ 公式ブログ（note） https://note.com/japan_d2 Facebook https://www.facebook.com/japand2 クラウドのエンジニアを募集しています！ JDDの最新情報はブログ、コーポレートサイト、 SNSにて情報発信中です。 X（Twitter） https://twitter.com/Japan_D2