ソニーにおける App Runner 導入事例と生の体験談の紹介 / Case study and real experience of using App Runner in Sony products

３年ほど前に登場した比較的新しいサービスであるApp Runnerを商用環境で導入した事例を紹介します。
インフラの運用の手間を軽量化できる一方で、利用して初めて気づく課題もありました。
本日は実際の導入事例に基づいて、ECS Fargateとの比較、CI/CD・監視の工夫から障害発生時の運用方法といった生の体験を紹介することで、これから導入を考えている方へ向けて、技術選定のポイントとなる"肌感"を共有できればと思います。
登壇アーカイブ：https://www.youtube.com/watch?v=YiE3n06tfCA

Transcript

1. ソニーにおける App Runner 導入事例と 生の体験談の紹介 ソニー株式会社 クラウドサービス・アプリケーション技術部門 クラウドソリューション開発部 米山兼治 2024/2/21
2. 2 自己紹介 ◆ 氏名： ◆ 経歴： ◆ 好きな物： 米山 兼治 2017- ソニー入社 主にTVやヘッドホンなどのホームエンター テインメント製品をサポートするクラウド サービスの設計・開発・運用を担当 ペンギン ニュージーランドにあるペンギン横断注意の標識
3. 3 今日のテーマ 生の体験談を紹介することで公式ドキュメントからは読み取れない App Runner を利用したインフラ構築・運用の “肌感” の共有
4. 4 Agenda ⚫ 事例の背景 ⚫ 運用面で遭遇した課題や工夫を４つ紹介 – デプロイ戦略について – アクセスログに残らないエラー – 突然のコンテナ入れ替え – オートスケーリングのチューニングに苦戦 ⚫ 技術選定観点でのまとめ
5. 5 事例の背景
6. 6 HES 製品向けプラットフォーム SEEDS Cloud SEEDS Cloud • HES製品向けのサービスプラットフォーム • ユーザー認証、IoT基盤、データ配信、データ分析・ML基盤など クラウドを利用する際に必要な機能を提供 • WWで1000万以上のアカウントを支えるプラットフォーム SEEDS Cloud HES製品 • HES：Home Entertainment and Sound products • テレビやヘッドホン、サウンドバーなど 主に動画や音楽を楽しむためのデバイス 詳細）今から予測する2024年のPlatform Engineering (2023/12) https://forkwell.connpass.com/event/303922/
7. 7 データ配信プラットフォーム 新規にデータ配信プラットフォームを立ち上げた データ配信 プラットフォーム Products Data Sources 詳細）2024年こそ使いこなす！GraphQL最前線 (2024/1) https://forkwell.connpass.com/event/307232/
8. 8 要件をかいつまんで紹介 Server Server client database GraphQL Gateway GraphQL API ・ ・ ・ • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性
9. 9 要件をかいつまんで紹介 • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 VPC AZ1 AZ2 Public subnet Public subnet Private subnet Private subnet client App Runner が無ければ例えばこんな構成 CI/CD
10. 10 要件をかいつまんで紹介 • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう VPC AZ1 AZ2 Public subnet Public subnet Private subnet Private subnet client App Runner が無ければ例えばこんな構成 CI/CD
11. 11 要件をかいつまんで紹介 • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう client App Runner 使うとこんなにシンプルに！
12. 12 要件をかいつまんで紹介 運用負荷の軽減に期待して採用することに • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう client App Runner 使うとこんなにシンプルに！
13. 13 要件をかいつまんで紹介 運用負荷の軽減に期待して採用することに • 複数の GraphQL API および REST API からデータ取得する 統合エンドポイントとなる GraphQL API • 初期のアクセス規模は 2M req/day 想定 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 client App Runner 使うとこんなにシンプルに！ 補足：裏の目論見 • 当時 App Runner は VPC 連携に対応しておらず使い所に悩んでいたが、 新規サービスで尚且つ接続先がもともと public な本案件は試すのにおあつらえ向けだった • パフォーマンステストして非機能要件満たせなかったら ECS に乗り換えれば良いので試しやすかった
14. 14 開発期間中はアプリケーション部分に集中できた • 開発チームとして、GraphQL API を開発するのも初めての試みだったため アプリケーション部分に集中できた効果が大きかった 2ヶ月 サーバ 開発チーム 3ヶ月 初物技術の フィージビリティスタディ 開発 クライアント 開発チーム 新規案件の MVP 開発でさっそく利用開始 staging 提供開始 運用設計、テスト、社内プロセス etc… 2021.10 2021.12 2022.3
15. 15 別システムでも臨時環境の構築が気軽に行えるように staging 環境 新featureを試す 臨時環境 product A の開発チーム product B の開発チーム サーバ開発チーム もともとECS App Runner を使えば すぐ提供できる ECR にある image を そのまま使えるため 追加開発不要
16. 16 別システムでも臨時環境の構築が気軽に行えるように staging 環境 新featureを試す 臨時環境 product A の開発チーム product B の開発チーム サーバ開発チーム もともとECS App Runner を使えば すぐ提供できる ECR にある image を そのまま使えるため 追加開発不要 ばたばたと急に必要になることもあるため地味ながら効率化に貢献
17. 17 では運用は軽量化したのかというと・・・
18. 18 では運用は軽量化したのかというと・・・ 使い始めてから遭遇した課題があるので共有したいと思います
19. 19 では運用は軽量化したのかというと・・・ 使い始めてから遭遇した課題があるので共有したいと思います （※ App Runner が悪いという話ではないのでご留意ください）
20. 20 １ デプロイ戦略について
21. 21 デプロイ戦略について • バックエンドとの疎通確認のため、 新バージョンリリース時は Blue/Green Deployment を行いたいと考えた インテグテスト成功したら切り替え v1 v2
22. 22 デプロイ戦略について • バックエンドとの疎通確認のため、 新バージョンリリース時は Blue/Green Deployment を行いたいと考えた • しかし、App Runner のサービス同士で カスタムドメインが重複できず、ダウンタイムなしで トラフィックをスイッチすることが出来ないことが判明 インテグテスト成功したら切り替え v1 v2
23. 23 デプロイ戦略について • バックエンドとの疎通確認のため、 新バージョンリリース時は Blue/Green Deployment を行いたいと考えた • しかし、App Runner のサービス同士で カスタムドメインが重複できず、ダウンタイムなしで トラフィックをスイッチすることが出来ないことが判明 • 実は App Runner 自体、内部的には 「新規コンテナ建てて Blue/Green Deployment してますよー」と書かれているのだが、 health check しか確認できず、複数テストシナリオを流す等は 出来ない v1 v2 health check 成功したら切り替え
24. 24 デプロイ戦略について • バックエンドとの疎通確認のため、 新バージョンリリース時は Blue/Green Deployment を行いたいと考えた • しかし、App Runner のサービス同士で カスタムドメインが重複できず、ダウンタイムなしで トラフィックをスイッチすることが出来ないことが判明 • 実は App Runner 自体、内部的には 「新規コンテナ建てて Blue/Green Deployment してますよー」と書かれているのだが、 health check しか確認できず、複数テストシナリオを流す等は 出来ない v1 v2 health check 成功したら切り替え マネージドサービスの思想から外れると途端に複雑化するため 1. staging 環境でアプリケーションの挙動を保証 2. health check でインフラとの疎通を保証 3. デプロイ後にテストを流してバックエンドとの疎通をテスト 4. ダメだったら切り戻し として代替することに 結局どうした？
25. 25 デプロイ戦略について • バックエンドとの疎通確認のため、 新バージョンリリース時は Blue/Green Deployment を行いたいと考えた • しかし、App Runner のサービス同士で カスタムドメインが重複できず、ダウンタイムなしで トラフィックをスイッチすることが出来ないことが判明 • 実は App Runner 自体、内部的には 「新規コンテナ建てて Blue/Green Deployment してますよー」と書かれているのだが、 health check しか確認できず、複数テストシナリオを流す等は 出来ない v1 v2 health check 成功したら切り替え マネージドサービスの思想から外れると途端に複雑化するため 1. staging 環境でアプリケーションの挙動を保証 2. health check でインフラとの疎通を保証 3. デプロイ後にテストを流してバックエンドとの疎通をテスト 4. ダメだったら切り戻し として代替することに 結局どうした？ 補足 「とりあえず Blue/Green」というのは課題の本質を見失っている という厳しい見方も・・・
26. 26 ２ アプリログに残らないエラー
27. 27 アプリログに残らないエラー • App Runner は ELB のように アクセスログを有効化するオプションが無い • アプリに到達せずに App Runner の界面で返している 429 Too Many Requests や 504 Gateway Timeout 等は 4xx、5xx のメトリクスに丸まってしまい生ログが確認できない App Runner Request Router App Runner の中身 参考) https://aws.amazon.com/jp/blogs/news/ deep-dive-on-aws-app-runner-vpc-networking/ ここのログは 取れるけど ここで遮断される と分からない
28. 28 アプリログに残らないエラー • App Runner は ELB のように アクセスログを有効化するオプションが無い • アプリに到達せずに App Runner の界面で返している 429 Too Many Requests や 504 Gateway Timeout 等は 4xx、5xx のメトリクスに丸まってしまい生ログが確認できない • そのため、何か起きた際のトラブルシューティングは 想像で補う要素が多くそれなりに苦労する App Runner Request Router App Runner の中身 参考) https://aws.amazon.com/jp/blogs/news/ deep-dive-on-aws-app-runner-vpc-networking/ ここのログは 取れるけど ここで遮断される と分からない
29. 29 アプリログに残らないエラー • App Runner は ELB のように アクセスログを有効化するオプションが無い • アプリに到達せずに App Runner の界面で返している 429 Too Many Requests や 504 Gateway Timeout 等は 4xx、5xx のメトリクスに丸まってしまい生ログが確認できない • そのため、何か起きた際のトラブルシューティングは 想像で補う要素が多くそれなりに苦労する • 現状はマネージドサービスに任せる部分はある程度任せて、 アプリ部分に集中するという割り切りも必要 App Runner Request Router App Runner の中身 参考) https://aws.amazon.com/jp/blogs/news/ deep-dive-on-aws-app-runner-vpc-networking/ ここのログは 取れるけど ここで遮断される と分からない
30. 30 アプリログに残らないエラー • App Runner は ELB のように アクセスログを有効化するオプションが無い • アプリに到達せずに App Runner の界面で返している 429 Too Many Requests や 504 Gateway Timeout 等は 4xx、5xx のメトリクスに丸まってしまい生ログが確認できない • そのため、何か起きた際のトラブルシューティングは 想像で補う要素が多くそれなりに苦労する • 現状はマネージドサービスに任せる部分はある程度任せて、 アプリ部分に集中するという割り切りも必要 App Runner Request Router App Runner の中身 参考) https://aws.amazon.com/jp/blogs/news/ deep-dive-on-aws-app-runner-vpc-networking/ ここのログは 取れるけど ここで遮断される と分からない App Runner 界面のログが取れない問題は未解決 一方で、アプリ界面の監視を詳細化する余地があるため、 併用することでサービス品質と問題の切り分け手段を確保 • X-Ray 連携の有効化によるトレースログの取得 • アプリケーションログを CloudWatch Logs Insights で集計する ことでアプリ界面のメトリクス監視 結局どうした？
31. 31 アプリログに残らないエラー • App Runner は ELB のように アクセスログを有効化するオプションが無い • アプリに到達せずに App Runner の界面で返している 429 Too Many Requests や 504 Gateway Timeout 等は 4xx、5xx のメトリクスに丸まってしまい生ログが確認できない • そのため、何か起きた際のトラブルシューティングは 想像で補う要素が多くそれなりに苦労する • 現状はマネージドサービスに任せる部分はある程度任せて、 アプリ部分に集中するという割り切りも必要 App Runner Request Router App Runner の中身 参考) https://aws.amazon.com/jp/blogs/news/ deep-dive-on-aws-app-runner-vpc-networking/ ここのログは 取れるけど ここで遮断される と分からない 補足 因みに Roadmap に issue が挙がっているのでいずれ アクセスログに対応するかもしれません https://github.com/aws/apprunner-roadmap/issues/123 App Runner 界面のログが取れない問題は未解決 一方で、アプリ界面の監視を詳細化する余地があるため、 併用することでサービス品質と問題の切り分け手段を確保 • X-Ray 連携の有効化によるトレースログの取得 • アプリケーションログを CloudWatch Logs Insights で集計する ことでアプリ界面のメトリクス監視 結局どうした？
32. 32 ３ 突然のコンテナ入れ替え
33. 33 突然のコンテナ入れ替え • 監視ダッシュボードをチェックしていると時折 前触れなくインスタンス id が切り替わっている • その際に 5xx エラーも発生している模様
34. 34 突然のコンテナ入れ替え • 監視ダッシュボードをチェックしていると時折 前触れなくインスタンス id が切り替わっている • その際に 5xx エラーも発生している模様 • アプリケーションログもシステムログも残っていない
35. 35 突然のコンテナ入れ替え • 監視ダッシュボードをチェックしていると時折 前触れなくインスタンス id が切り替わっている • その際に 5xx エラーも発生している模様 • アプリケーションログもシステムログも残っていない • AWS のプロダクトマネージャーとお話しする機会があり相談してみたところ、 • health check に失敗して自動で新規インスタンスが建ったのではないか？ • その際、draining は行われないため切り離し対象のインスタンスに向いていた リクエストにはまとめて 503 エラーが返るとのこと
36. 36 突然のコンテナ入れ替え • 監視ダッシュボードをチェックしていると時折 前触れなくインスタンス id が切り替わっている • その際に 5xx エラーも発生している模様 • アプリケーションログもシステムログも残っていない • AWS のプロダクトマネージャーとお話しする機会があり相談してみたところ、 • health check に失敗して自動で新規インスタンスが建ったのではないか？ • その際、draining は行われないため切り離し対象のインスタンスに向いていた リクエストにはまとめて 503 エラーが返るとのこと 根本的には health check に失敗した原因を修正すればよいが・・・ App Runner 界面のログが見れないため、同じことが起きても 毎回 health check による切り離しなのかどうかは分からず未だ苦戦中 結局どうした？
37. 37 突然のコンテナ入れ替え • 監視ダッシュボードをチェックしていると時折 前触れなくインスタンス id が切り替わっている • その際に 5xx エラーも発生している模様 • アプリケーションログもシステムログも残っていない • AWS のプロダクトマネージャーとお話しする機会があり相談してみたところ、 • health check に失敗して自動で新規インスタンスが建ったのではないか？ • その際、draining は行われないため切り離し対象のインスタンスに向いていた リクエストにはまとめて 503 エラーが返るとのこと 根本的には health check に失敗した原因を修正すればよいが・・・ App Runner 界面のログが見れないため、同じことが起きても 毎回 health check による切り離しなのかどうかは分からず未だ苦戦中 結局どうした？ 補足 こちらに関しても、health check でインスタンスを落とす前に ログを残して欲しいという issue が Roadmap に上がっています https://github.com/aws/apprunner-roadmap/issues/100
38. 38 ４ オートスケーリングのチューニングに悪戦苦闘
39. 39 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに https://docs.aws.amazon.com/apprunner/ latest/dg/manage-autoscaling.html
40. 40 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに • しかし実リクエストは CPU 負荷の高いリクエストと 低いリクエストが混在するため、同時実行数ベースでは答えのな い問いに悩まされることに・・・ https://docs.aws.amazon.com/apprunner/ latest/dg/manage-autoscaling.html
41. 41 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに • しかし実リクエストは CPU 負荷の高いリクエストと 低いリクエストが混在するため、同時実行数ベースでは答えのな い問いに悩まされることに・・・ • また、スケールアウト時や、最小台数を provisioning した場合で も、直ちに負荷分散されず、駆け付けたインスタンスが連鎖的に 落ちることが多発
42. 42 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに • しかし実リクエストは CPU 負荷の高いリクエストと 低いリクエストが混在するため、同時実行数ベースでは答えのな い問いに悩まされることに・・・ • また、スケールアウト時や、最小台数を provisioning した場合で も、直ちに負荷分散されず、駆け付けたインスタンスが連鎖的に 落ちることが多発 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう ここを満たすには より細かい制御が必要に・・・
43. 43 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに • しかし実リクエストは CPU 負荷の高いリクエストと 低いリクエストが混在するため、同時実行数ベースでは答えのな い問いに悩まされることに・・・ • また、スケールアウト時や、最小台数を provisioning した場合で も、直ちに負荷分散されず、駆け付けたインスタンスが連鎖的に 落ちることが多発 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう ここを満たすには より細かい制御が必要に・・・ 残念ながら最終的に今回の案件では ECS への乗り換えを決断 結局どうした？
44. 44 オートスケーリングのチューニングに悪戦苦闘 • App Runner では auto scaling の指標として、 リクエストの同時実行数上限を指定する • サービスリリース前に”お行儀の良い”パフォーマンステストを 行ったが実リクエストに晒されると過負荷になることがあったた めスケーリング設定を見直すことに • しかし実リクエストは CPU 負荷の高いリクエストと 低いリクエストが混在するため、同時実行数ベースでは答えのな い問いに悩まされることに・・・ • また、スケールアウト時や、最小台数を provisioning した場合で も、直ちに負荷分散されず、駆け付けたインスタンスが連鎖的に 落ちることが多発 • 非機能要件 • リクエスト成功率 SLO 99.5 % • Multi-AZ で冗長化 • スケールアウトによる拡張性 ↑ App Runner でも満たせそう ここを満たすには より細かい制御が必要に・・・ 残念ながら最終的に今回の案件では ECS への乗り換えを決断 結局どうした？ 補足 こちらも Roadmap に issue が挙がっているのでいずれ CPU・メモリベースのオートスケーリングに対応するかもしれません https://github.com/aws/apprunner-roadmap/issues/15
45. 45 技術選定観点で再考 改めてフェアに
46. 46 技術選定観点で再考 • 運用を始めると意外と苦労を伴ったが、簡単ですぐにデプロイできるのはやはり何といっても魅力 • マネージドサービス全般に言えることだが、現時点ではカスタマイズ性と開発の迅速さのトレードオフと、 マネージドサービスに任せると割り切って良いか、非機能要件の厳格さのバランス感覚で比較する必要がある • 市場投入の迅速さが優先されるサービス初期、 非機能要件が緩い社内サービス・臨時環境・デモ環境等では大活躍 ◎ App Runner の出番 ECSの出番 カスタマイズが必要 非機能要件が厳格 市場投入の迅速さが最優先
47. 47 技術選定観点で再考 • 運用を始めると意外と苦労を伴ったが、簡単ですぐにデプロイできるのはやはり何といっても魅力 • マネージドサービス全般に言えることだが、現時点ではカスタマイズ性と開発の迅速さのトレードオフと、 マネージドサービスに任せると割り切って良いか、非機能要件の厳格さのバランス感覚で比較する必要がある • 市場投入の迅速さが優先されるサービス初期、 非機能要件が緩い社内サービス・臨時環境・デモ環境等では大活躍 ◎ • ECR からイメージをデプロイするのは同じなため、App Runner から ECS への乗り換えも最小限の開発で可能 • 今日紹介した案件でも最終的に乗り換えに踏み切りましたが、開発は1ヶ月そこらで完了しました • 素早い立ち上げの後、難しい品質特性が求められ次第乗り換えられるという変更容易性が担保できているのも魅力 App Runner の出番 ECSの出番 カスタマイズが必要 非機能要件が厳格 市場投入の迅速さが最優先 リリース テスト 本開発 PoC・プロト開発 App Runner で素早く価値検証 要件定義後も行けそう？ テストはパスした？ その後不具合はない？ ダメなら ECS に乗り換え × × ×
48. 48 技術選定観点で再考 • 運用を始めると意外と苦労を伴ったが、簡単ですぐにデプロイできるのはやはり何といっても魅力 • マネージドサービス全般に言えることだが、現時点ではカスタマイズ性と開発の迅速さのトレードオフと、 マネージドサービスに任せると割り切って良いか、非機能要件の厳格さのバランス感覚で比較する必要がある • 市場投入の迅速さが優先されるサービス初期、 非機能要件が緩い社内サービス・臨時環境・デモ環境等では大活躍 ◎ • ECR からイメージをデプロイするのは同じなため、App Runner から ECS への乗り換えも最小限の開発で可能 • 今日紹介した案件でも最終的に乗り換えに踏み切りましたが、開発は1ヶ月そこらで完了しました • 素早い立ち上げの後、難しい品質特性が求められ次第乗り換えられるという変更容易性が担保できているのも魅力 • 逆に、運用軽減を目的に市場投入済みの既存サービスを乗り換えるのはもう少し様子見でいいかなという感触です App Runner の出番 ECSの出番 カスタマイズが必要 非機能要件が厳格 市場投入の迅速さが最優先 リリース テスト 本開発 PoC・プロト開発 App Runner で素早く価値検証 要件定義後も行けそう？ テストはパスした？ その後不具合はない？ ダメなら ECS に乗り換え × × ×
49. SONY is a registered trademark of Sony Group Corporation. Names of Sony products and services are the registered trademarks and/or trademarks of Sony Group Corporation or its Group companies. Other company names and product names are registered trademarks and/or trademarks of the respective companies.