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

AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話 / A stor...

AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話 / A story about low-risk, low-stress rollouts with AWS AppConfig

2023/09/02 AWS Startup Day 2023
https://aws-startup-community.connpass.com/event/289498/

AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話

佐藤 丈生
Software Engineer

株式会社カミナシ

September 02, 2023
Tweet

More Decks by 株式会社カミナシ

Other Decks in Technology

Transcript

  1. セッション対象者 ➢ 実例を通じて、AWS AppConfig で Feature Flags を実装するイメージを持 ちたい方 ➢

    Feature Flags を用いた低リスク・低ストレスなサービスのロールアウトを 実現したい方 ➢ AWS AppConfig の特徴やその使い所(使用例)について知りたい方 セッション対象者とゴール
  2. ゴール ➢ 今後 Feature Flags などの仕組みを設計するときに AWS AppConfig を設計 の選択肢の1つにできること

    話すこと ➢ Feature Flags の概要や、必要とされる理由 ➢ AWS AppConfig ならではの特徴や、その利用イメージ 話さないこと ➢ Feature Flags に関する網羅的な説明 ➢ AWS AppConfig の詳細な仕様や、使用する際の具体的な手順 セッション対象者とゴール
  3. アジェンダ 1. Feature Flags はなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags

    とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AWS AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
  4. アジェンダ 1. Feature Flags はなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags

    とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
  5. アジェンダ 1. Feature Flags はなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags

    とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
  6. デプロイとロールアウトの分離の重要性 デプロイとロールアウトの分離とは? デプロイ ➢ 運用環境のソフトウェアのバージョンを変え、稼働させること ➢ 例) コンテナイメージをビルドし、ECR に push。それを元に、ECS

    タスク を(再)起動する ロールアウト ➢ 機能を、利用者の一部 or 全体に利用可能にすること ➢ 例) 新規開発した機能Xを、ユーザーが利用可能な状態にすること
  7. デプロイとロールアウトの分離の重要性 デプロイとロールアウトの分離とは? ➢ デプロイとロールアウトが分離していない状態 ◦ 例)コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再)

    起動すると、新規開発した機能Xを、ユーザーが利用可能になる ➢ デプロイとロールアウトが分離した状態 ◦ 例)コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再) 起動しても、新規開発した機能Xは、ユーザーには公開されない ◦ 例)コンテナイメージのビルド 〜 ECS タスクの(再)起動を行わなくても、機能X の、公開・非公開状態が切り替えられる
  8. アジェンダ 1. Feature Flagsはなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは?

    c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
  9. Feature Flags とは? Feature Flags でデプロイとロールアウトの分離を実現できる さらにこんなこともできる......🎉 例:ユーザーの属性に応じて、機能の利用可否を切り替える ➢ 開発視点では、ロールアウト時のリスクをさらに低減できる

    ◦ カナリアリリース ➢ ビジネス視点では、完全なロールアウトの前に、検証プロセスを回せる ◦ A / B テスト ◦ β リリース *一般的に「カナリアロールアウト」や「β ロールアウト」のような言い方はしないと感じ たのでここでは「リリース」という言葉を使っています
  10. Feature Flags とは? Feature Flags の種類について補足 - Release Toggles -

    Experiment Toggles - Ops Toggles - Permission Toggles - ….. 💡本セッションでは、新しい機能を追加するときに、柔軟にロールアウトしてい くために利用するFeature Flags を念頭においています。 上記では、Release Toggles や Experiment Toggles が近いイメージです。 (参考: https://martinfowler.com/articles/feature-toggles.html)
  11. アジェンダ 1. Feature Flagsはなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは?

    c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
  12. カミナシにとっての Feature Flags Feature Flags のメリットを感じていること ➢ ステークホルダーへの影響などを考慮しながら、ロールアウトのタイミング を調整できる ◦

    フィールドワーカーの中には、Saas やアプリなどツールに不慣れな方も多い ➢ 一部のお客様へのβ版提供により、機能をブラッシュアップできる ◦ 別環境を構築せずに、プロダクション環境を使用 ◦ 本番データで、質の高いβテスト(データ壊れないよう注意だが...) ➢ 開発に数週間・数ヶ月かかるような機能も、メインブランチにマージ & プロ ダクションへデプロイできる ◦ 開発の効率や、エンジニアの作業負荷の軽減
  13. カミナシにとっての Feature Flags Feature Flags のメリットを感じていること (Pick up) ➢ プロダクション環境・実業務のデータで、β版を試していただく

    • β版環境・お試しデータは、 ▪ お客様が業務がイメージしづらい・実業務での使用はほぼ不可 • プロダクション環境・実業務データは、 ▪ お客様が実業務をイメージしやすい・実業務で使用可の場合も ▪ (もちろん実業務データに悪影響がでないよう注意 & 期待値調整必須) → フィードバックがたくさん🎉 → Feature Flags で一部ユーザーのみに柔軟にロールアウトできるおかげ
  14. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
  15. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
  16. AWS AppConfig とは? 全体イメージ • 「アプリケーションの設定」を作成・更新し、「デプロイ」(開始)する ◦ 「アプリケーションの設定」: Feature Flags の文脈では、Toggle

    Configuration • アプリケーションは、「デプロイ」された 「アプリケーションの設定」を参 照する ◦ 「デプロイ」: 「アプリケーションの設定」 を、アプリケーションが参照でき る状態にすること
  17. AWS AppConfig とは? 全体イメージ ➢ Feature Flags の文脈:Toggle Configuration が「アプリケーションの設

    定」に相当する Toggle Configuration (機能ONにするユーザーの属性 値)
  18. AWS AppConfig とは? 「デプロイ」(deployment) について • イメージ: ローリングアップデートのようなことができる ◦ Deployment strategy

    によって変更の反映をコントロールできる ▪ 例えば、複数のアプリケーションに、徐々に新しい設定を参照させる、こと ができる ◦ Deployment time + Bake time 内であれば、ロールバックが可能 ▪ トラブル時にロールバック ▪ システムメトリクスなどを観ながら、慎重にロールアウト
  19. AWS AppConfig とは? AWS AppConfig を使うと何が嬉しいの? • 👀「アプリケーションの設定」を更新する時のバリデーション ◦ JSON

    スキーマ・AWS Lambda • 「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ◦ 「アプリケーションの設定」がAWS AppConfigにより一元管理 • デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 • 👀Deployment Strategy により、設定変更の反映のされ方をコントール ◦ トラブル時にロールバック ◦ システムメトリクスなどを観ながら、慎重にロールアウト
  20. AWS AppConfig とは? 補足 典型的なアプリケーションからの参照方法 • イメージ: Local Cacheを参照する。Local Cache 更新はバックグラウンドスレッド

    • バックグラウンドスレッド ◦ StartConfigurationSession(*API): セッション開始 ◦ GetLatestConfiguration(*API): ポーリング ◦ 「アプリケーションの設定」に変更があれば、Local Cache を更新する • アプリケーション ◦ 設定を参照する箇所では、Local Cache を参照する *API:AWS AppConfig のAPI
  21. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AWS AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
  22. カミナシでの AWS AppConfig 利用例 カミナシのアーキテクチャ概要 • ブラウザからアクセスする「Web」アプリケーション(React。SPA) • 「Mobile」アプリケーション(React Native。iOSネイティブアプリ)

    • フロントエンドからアクセスされる「API Server」 • API サーバーは、AWS Fargate 上のコンテナで稼働する Go lang アプリケー ション
  23. カミナシでの AWS AppConfig 利用例 AWS AppConfig 利用前の状態・課題 • ソースコード上に Toggle

    Configuration をハードコーディング • 課題 ◦ ロールアウトのために、デプロイが必要 ◦ 一元管理が難しい → 認知コスト・ロールアウト時の修正漏れ
  24. カミナシでの AWS AppConfig 利用例 アーキテクチャ(アプリケーション周り 全体) • Toggle Configuration を

    AWS AppConfig で管理 ◦ Configuration Profile の type == Feature Flag ◦ (JSON スキーマによるバリデーション) • AWS AppConfig へのアクセスは、AWS AppConfig agent が担う ◦ AWS が提供するサイドカーコンテナイメージ ◦ https://gallery.ecr.aws/aws-appconfig/aws-appconfig-agent • アプリケーションは、AWS AppConfig agent にアクセス • Front End は、「GET /enabledFeatures」にアクセス
  25. アーキテクチャ(アプリケーション周り フロントエンド) • 各コンポーネントでは、カスタムフックを用いて、機能の利用可否を判定 ◦ API コールのタイミングを意識したくない ◦ コンポーネントのレンダリング毎に API

    コールされるのを避けたい ◦ → Front End は Front End で Local Cache を管理 • TanStack Query のキャッシュ機構を用いて実装 カミナシでの AWS AppConfig 利用例
  26. カミナシでの AWS AppConfig 利用例 AWS AppConfigの設定を IaC で管理する • Toggle

    Configurationは Terrafrom で定義し、Github Repository で管理 ◦ Toggle Configuration の変更履歴を残し、レビューのプロセスを通したい ◦ ロールアウト、ロールバックしたい時は、PR を出す • Terraform Cloud 上で、Plan実行 → Apply により、「デプロイ」開始 ◦ main ブランチへのマージがトリガー • Deployment time、Bake time ともに 0 のため、即時に全コンテナに反映
  27. カミナシでの AWS AppConfig 利用例 他の選択肢について Toggle Configuration をどこに格納するか? • RDS、DynamoDB、S3など何かしらの外部ストレージ

    ◦ AWS AppConfig に比べ自由度が高いが、そのぶん設計・実装・管理が難しい • Amazon CloudWatch Evidently を利用する ◦ 自由度、エコシステムなどが、AWS AppConfig の方がふさわしかった • 環境変数(AWS Systems Manager Parameter Storeなど) ◦ タスク再起動が必要。構造化データを持たせる辛み
  28. カミナシでの AWS AppConfig 利用例 他の選択肢について Front End からどうやって AWS AppConfig

    の設定を取得するか? • Amazon Congito を活用し、Front End から直接 AWS AppConfig の API に アクセスする ◦ API サーバーにエンドポイントを定義する方が、(現状では)シンプルかつ、実 装・運用しやすい
  29. カミナシでの AWS AppConfig 利用例 活かせている AWS AppConfig の良さ • ✅「アプリケーションの設定」を更新する時のバリデーション

    ◦ ✅ JSON スキーマ・AWS Lambda • ✅「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ◦ ✅「アプリケーションの設定」がAWS AppConfigにより一元管理 • ✅ デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 • 🔴 Deployment Strategy により、設定変更の反映のされ方をコントール ◦ トラブル時にロールバック ◦ システムメトリクスなどを観ながら、慎重にロールアウト *AWS AppConfig の良さを全て活かしきれているわけではない
  30. 「2. AWS AppConfig で Feature Flags の仕組みを整備した話」まとめ ➢ AWS AppConfig

    使うことにより、 ◦ 設定の更新時、バリデーションによりエラーを低減 ◦ 設定を一元管理 ◦ 設定の更新時にアプリケーションの停止も不要 ◦ Deployment Strategy により、設定更新の反映のされ方をコントロー ル ➢ カミナシでは、AWS AppConfig を利用した仕組みを整備し、以下を実現 ◦ Toggle Configuration の一元管理 ◦ デプロイに依存しないロールアウト
  31. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
  32. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
  33. よかったこと 導入しやすさ • 3-4 人で、1スプリント(1week) 程度の作業ボリュームで導入できた • いい感じのエコシステムが揃っていた ◦ AWS

    AppConfig agent ▪ Local Cache の管理などを実装しなくてよかった ◦ Terraform Cloud ◦ TanStack Query ▪ (AWS AppConfig とは直接関係ないが、Local Cache 管理の点で便利だっ たため、記載)
  34. よかったこと 導入した効果(効果を感じている点) • Toggle Configuration が一元管理されている ◦ 認知コストが下がった ◦ ロールアウト時の修正漏れ防止

    • ロールアウトのスケジュールが柔軟に設定できるようになった ◦ (現状は、毎週火・木に定期デプロイ) ◦ このタイミングとロールアウトのタイミングを合わせる必要が無くなっ た
  35. アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags

    の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
  36. Feature Flags のよさを活かし、よりデプロイの頻度を上げる デプロイとロールアウトの分離が加速したので、デプロイの頻度を上げたい! • Feature Flags 以外の整備も必要 ◦ 派生元ブランチにマージ後の、手動の動作検証がブロッカー

    • コードが複雑化している部分では、Feature Flags自体を定義しづらい。 ◦ Feature Flags の仕組みがあっても制御しづらい ◦ 要リファクタリング 今後の課題
  37. 今後の課題 AWS AppConfig のよさを活かし、サービスの変化・成長に適応する Deployment strategy について • 現状は、即座に全コンテナに設定が反映 ◦

    Deployment time、Bake time が 0 min. • Deployment strategy を見直したら、ロールバック時の Toggle Configuration の値の管理方法も再考 ◦ Github Repository 上の値と、AWS AppConfig 上の値が乖離するため
  38. 今後の課題 AWS AppConfig のよさを活かし、サービスの変化・成長に適応する バリデーションについて • 現状では、JSON スキーマによるバリデーションで十分 • AWS

    Lambda によるバリデーションも検討? ◦ 複雑または、不備があった際に業務影響が大きな Toggle Configuration を使用したいケースがあれば...
  39. 「3. Feature Flags の仕組みを運用してみての学び」まとめ ➢ AWS AppConfig を利用した Feature Flags

    の仕組みはエコシステムが充実 しており、妥当な期間で導入できた! ➢ 導入前目的としていた、Toggle Configuration の一元管理やデプロイに依存 しないロールアウトは実現できた! ➢ 一方で、Feature Flags の利点や、AWS AppConfig の長所は今後もっと生か す余地がある!
  40. Further reading Feature Flags 関係 - https://martinfowler.com/articles/feature-toggles.html - https://semaphoreci.com/blog/feature-flags -

    https://codezine.jp/article/detail/14114 - https://www.harness.io/blog/what-are-feature-flags CI/CD 関係 - https://semaphoreci.com/blog/2017/07/27/what-is-the-difference-between-continuous-integration-conti nuous-deployment-and-continuous-delivery.html - https://trunkbaseddevelopment.com/ AWS AppConfig 関係 - https://kaminashi-developer.hatenablog.jp/entry/2023/07/31/122831 - https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html