AWS AppConfig で低リスク・低ストレスなロールアウトを実現した話 / A story about low-risk, low-stress rollouts with AWS AppConfig
by
株式会社カミナシ
Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
AWS AppConfig で低リスク・低ストレスなロールアウトを 実現した話 株式会社カミナシ ソフトウェアエンジニア 佐藤 丈生
Slide 2
Slide 2 text
自己紹介 株式会社カミナシ ソフトウェアエンジニア 佐藤 丈生(Tomoki Sato) 経歴) パッケージソフト開発(Java, 普通のJS 中心) → 2022/12 株式会社カミナシ カミナシでは、React / React Native (iOS) / Golang / AWS
Slide 3
Slide 3 text
はじめに 会社 & プロダクトについて
Slide 4
Slide 4 text
会社 & プロダクト紹介 日常はITに溢れているのに、仕事場は紙ばかりで非効率。 今日も作業現場で働く人たちは、十分に才覚を発揮できていない。 そんな3,900万人の埋もれたエネルギーを、私たちが解き放つ。 誰もが享受するべき当たり前を、すべての現場の人たちに届けたい。 効率的な作業、見事な成果、腕のなる仕事、豊かな人生。 これらはきっとつながっているから。 ノンデスクワーカーの 才能を解き放つ Mission
Slide 5
Slide 5 text
会社 & プロダクト紹介 誰でも正しい手順で作業を実行 カミナシは、モバイルアプリを使って、 現場業務のムダを自動化するサービスです。 現場DXプラットフォーム「カミナシ」 管理者の代わりに作業をチェック データから自動で集計・報告書を作成 改善活動をサポート
Slide 6
Slide 6 text
会社 & プロダクト紹介
Slide 7
Slide 7 text
会社 & プロダクト紹介
Slide 8
Slide 8 text
はじめに ここから本題
Slide 9
Slide 9 text
セッション対象者 ➢ 実例を通じて、AWS AppConfig で Feature Flags を実装するイメージを持 ちたい方 ➢ Feature Flags を用いた低リスク・低ストレスなサービスのロールアウトを 実現したい方 ➢ AWS AppConfig の特徴やその使い所(使用例)について知りたい方 セッション対象者とゴール
Slide 10
Slide 10 text
ゴール ➢ 今後 Feature Flags などの仕組みを設計するときに AWS AppConfig を設計 の選択肢の1つにできること 話すこと ➢ Feature Flags の概要や、必要とされる理由 ➢ AWS AppConfig ならではの特徴や、その利用イメージ 話さないこと ➢ Feature Flags に関する網羅的な説明 ➢ AWS AppConfig の詳細な仕様や、使用する際の具体的な手順 セッション対象者とゴール
Slide 11
Slide 11 text
アジェンダ 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. 今後の課題
Slide 12
Slide 12 text
アジェンダ 1. Feature Flags はなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
Slide 13
Slide 13 text
アジェンダ 1. Feature Flags はなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
Slide 14
Slide 14 text
デプロイとロールアウトの分離の重要性 デプロイとロールアウトの分離とは? デプロイ ➢ 運用環境のソフトウェアのバージョンを変え、稼働させること ➢ 例) コンテナイメージをビルドし、ECR に push。それを元に、ECS タスク を(再)起動する ロールアウト ➢ 機能を、利用者の一部 or 全体に利用可能にすること ➢ 例) 新規開発した機能Xを、ユーザーが利用可能な状態にすること
Slide 15
Slide 15 text
デプロイとロールアウトの分離の重要性 デプロイとロールアウトの分離とは? 💡本セッションでは、デプロイとの区別を明確にするために、「機能を、利用者 の一部 or 全体に利用可能にすること」という意味合い対して、「リリース」で はなく「ロールアウト」という言葉を使用します。
Slide 16
Slide 16 text
デプロイとロールアウトの分離の重要性 デプロイとロールアウトの分離とは? ➢ デプロイとロールアウトが分離していない状態 ○ 例)コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再) 起動すると、新規開発した機能Xを、ユーザーが利用可能になる ➢ デプロイとロールアウトが分離した状態 ○ 例)コンテナイメージをビルドし ECR に push。それを元に、ECS タスクを(再) 起動しても、新規開発した機能Xは、ユーザーには公開されない ○ 例)コンテナイメージのビルド 〜 ECS タスクの(再)起動を行わなくても、機能X の、公開・非公開状態が切り替えられる
Slide 17
Slide 17 text
デプロイとロールアウトの分離の重要性 なぜ、デプロイとロールアウトの分離が重要なのか? 開発視点 (開発効率・作業負荷軽減・安定運用) ➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため ➢ ロールアウト時のリスクを低減させるため ビジネス視点(ビジネス上の施策・戦略) ➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため
Slide 18
Slide 18 text
デプロイとロールアウトの分離の重要性 なぜ、デプロイとロールアウトの分離が重要なのか? 👀開発視点 (開発効率・作業負荷軽減・安定運用) ➢ CD(継続的デリバリー)、継続的デプロイメントに、事実上不可欠であるため ○ コード変更を一日複数回メインブランチにマージしたい! ○ 高頻度でプロダクション環境にデプロイしたい! ○ その一方で、ある程度の期間を要する機能追加・変更は発生しうる... ➢ ロールアウト時のリスクを低減させるため ○ ロールアウト後に、トラブルが起きたら、即座にその機能をオフにしたい!
Slide 19
Slide 19 text
デプロイとロールアウトの分離の重要性 なぜ、デプロイとロールアウトの分離が重要なのか? 👀ビジネス視点(ビジネス上の施策・戦略) ➢ 開発を妨げずに、適切なタイミングでロールアウトできるようにするため ○ 開発チームがデプロイしたいタイミングと、ビジネス上、機能をユーザーに公開 したいタイミングは異なる ■ 例:ユーザーへの公開は、マーケティングキャンペーンと連動させたい
Slide 20
Slide 20 text
アジェンダ 1. Feature Flagsはなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
Slide 21
Slide 21 text
Feature Flags とは? ➢ コードを修正せずに、システムの振る舞いを変える技術 (参考: https://martinfowler.com/articles/feature-toggles.html)
Slide 22
Slide 22 text
Feature Flags とは? ➢ コード上の特定の箇所を、条件に応じて ON or OFF にできるイメージ
Slide 23
Slide 23 text
Feature Flags とは? ロールアウトされた状 態 ロールアウトされてい ない状態
Slide 24
Slide 24 text
Feature Flags とは? Feature Flags でデプロイとロールアウトの分離を実現できる さらにこんなこともできる......🎉 例:ユーザーの属性に応じて、機能の利用可否を切り替える ➢ 開発視点では、ロールアウト時のリスクをさらに低減できる ○ カナリアリリース ➢ ビジネス視点では、完全なロールアウトの前に、検証プロセスを回せる ○ A / B テスト ○ β リリース *一般的に「カナリアロールアウト」や「β ロールアウト」のような言い方はしないと感じ たのでここでは「リリース」という言葉を使っています
Slide 25
Slide 25 text
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)
Slide 26
Slide 26 text
アジェンダ 1. Feature Flagsはなぜ必要か? a. デプロイとロールアウトの分離の重要性 b. Feature Flags とは? c. カミナシにとっての Feature Flags 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び
Slide 27
Slide 27 text
カミナシにとっての Feature Flags Feature Flags のメリットを感じていること ➢ ステークホルダーへの影響などを考慮しながら、ロールアウトのタイミング を調整できる ○ フィールドワーカーの中には、Saas やアプリなどツールに不慣れな方も多い ➢ 一部のお客様へのβ版提供により、機能をブラッシュアップできる ○ 別環境を構築せずに、プロダクション環境を使用 ○ 本番データで、質の高いβテスト(データ壊れないよう注意だが...) ➢ 開発に数週間・数ヶ月かかるような機能も、メインブランチにマージ & プロ ダクションへデプロイできる ○ 開発の効率や、エンジニアの作業負荷の軽減
Slide 28
Slide 28 text
カミナシにとっての Feature Flags Feature Flags のメリットを感じていること (Pick up) ➢ プロダクション環境・実業務のデータで、β版を試していただく ● β版環境・お試しデータは、 ■ お客様が業務がイメージしづらい・実業務での使用はほぼ不可 ● プロダクション環境・実業務データは、 ■ お客様が実業務をイメージしやすい・実業務で使用可の場合も ■ (もちろん実業務データに悪影響がでないよう注意 & 期待値調整必須) → フィードバックがたくさん🎉 → Feature Flags で一部ユーザーのみに柔軟にロールアウトできるおかげ
Slide 29
Slide 29 text
「1. Feature Flagsはなぜ必要か?」まとめ ➢ 開発・ビジネスの両方の視点で、デプロイとロールアウトの分離は重要 ➢ Feature Flags により、デプロイとロールアウトの分離が実現できる ➢ カミナシでは、開発・ビジネス両面で、Feature Flags のメリットを享受し ている
Slide 30
Slide 30 text
次章以降の説明のための補足 (参考:https://martinfowler.com/articles/feature-toggles.html) Toggle Configuration (機能ONにするユーザー の属性値)
Slide 31
Slide 31 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
Slide 32
Slide 32 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
Slide 33
Slide 33 text
AWS AppConfig とは? 全体イメージ AWS AppConfig を使用することにより、「アプリケーションの設 定」を作成・管理し、素早く「デプロイ」できます (引用元:https://docs.aws.amazon.com/appconfig/latest/userguide/what-is-appconfig.html 佐藤 意訳)
Slide 34
Slide 34 text
AWS AppConfig とは? 全体イメージ
Slide 35
Slide 35 text
AWS AppConfig とは? 全体イメージ ● 「アプリケーションの設定」を作成・更新し、「デプロイ」(開始)する ○ 「アプリケーションの設定」: Feature Flags の文脈では、Toggle Configuration ● アプリケーションは、「デプロイ」された 「アプリケーションの設定」を参 照する ○ 「デプロイ」: 「アプリケーションの設定」 を、アプリケーションが参照でき る状態にすること
Slide 36
Slide 36 text
AWS AppConfig とは? 全体イメージ ➢ Feature Flags の文脈:Toggle Configuration が「アプリケーションの設 定」に相当する Toggle Configuration (機能ONにするユーザーの属性 値)
Slide 37
Slide 37 text
AWS AppConfig とは? 「デプロイ」(deployment) について
Slide 38
Slide 38 text
AWS AppConfig とは? 「デプロイ」(deployment) について ● イメージ: ローリングアップデートのようなことができる ○ Deployment strategy によって変更の反映をコントロールできる ■ 例えば、複数のアプリケーションに、徐々に新しい設定を参照させる、こと ができる ○ Deployment time + Bake time 内であれば、ロールバックが可能 ■ トラブル時にロールバック ■ システムメトリクスなどを観ながら、慎重にロールアウト
Slide 39
Slide 39 text
AWS AppConfig とは? AWS AppConfig を使うと何が嬉しいの? ● 👀「アプリケーションの設定」を更新する時のバリデーション ○ JSON スキーマ・AWS Lambda ● 「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ○ 「アプリケーションの設定」がAWS AppConfigにより一元管理 ● デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 ● 👀Deployment Strategy により、設定変更の反映のされ方をコントール ○ トラブル時にロールバック ○ システムメトリクスなどを観ながら、慎重にロールアウト
Slide 40
Slide 40 text
補足 典型的なアプリケーションからの参照方法 AWS AppConfig とは?
Slide 41
Slide 41 text
AWS AppConfig とは? 補足 典型的なアプリケーションからの参照方法 ● イメージ: Local Cacheを参照する。Local Cache 更新はバックグラウンドスレッド ● バックグラウンドスレッド ○ StartConfigurationSession(*API): セッション開始 ○ GetLatestConfiguration(*API): ポーリング ○ 「アプリケーションの設定」に変更があれば、Local Cache を更新する ● アプリケーション ○ 設定を参照する箇所では、Local Cache を参照する *API:AWS AppConfig のAPI
Slide 42
Slide 42 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 a. AWS AppConfig とは? b. カミナシでの AWS AppConfig 利用例 3. Feature Flags の仕組みを運用してみての学び
Slide 43
Slide 43 text
カミナシでの AWS AppConfig 利用例 弊社でどのように AWS AppConfig を利用したのかについて、より詳細は、弊社 テックブログもご確認ください。 → https://kaminashi-developer.hatenablog.jp/entry/2023/07/31/122831
Slide 44
Slide 44 text
カミナシでの AWS AppConfig 利用例 誰でも正しい手順で作業を実行 カミナシは、モバイルアプリを使って、 現場業務のムダを自動化するサービスです。 (再掲)現場DXプラットフォーム「カミナシ」 管理者の代わりに作業をチェック データから自動で集計・報告書を作成 改善活動をサポート Web 管理者向け画面 (React (SPA)) Mobile 記録者向け画面 (React Native)
Slide 45
Slide 45 text
カミナシでの AWS AppConfig 利用例 カミナシのアーキテクチャ概要
Slide 46
Slide 46 text
カミナシでの AWS AppConfig 利用例 カミナシのアーキテクチャ概要 ● ブラウザからアクセスする「Web」アプリケーション(React。SPA) ● 「Mobile」アプリケーション(React Native。iOSネイティブアプリ) ● フロントエンドからアクセスされる「API Server」 ● API サーバーは、AWS Fargate 上のコンテナで稼働する Go lang アプリケー ション
Slide 47
Slide 47 text
カミナシでの AWS AppConfig 利用例 AWS AppConfig 利用前の状態・課題
Slide 48
Slide 48 text
カミナシでの AWS AppConfig 利用例 AWS AppConfig 利用前の状態・課題 ● ソースコード上に Toggle Configuration をハードコーディング ● 課題 ○ ロールアウトのために、デプロイが必要 ○ 一元管理が難しい → 認知コスト・ロールアウト時の修正漏れ
Slide 49
Slide 49 text
カミナシでの AWS AppConfig 利用例 再掲(Toggle Configuration)
Slide 50
Slide 50 text
カミナシでの AWS AppConfig 利用例 アーキテクチャ(アプリケーション周り 全体)
Slide 51
Slide 51 text
カミナシでの 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」にアクセス
Slide 52
Slide 52 text
アーキテクチャ(アプリケーション周り フロントエンド) ● 各コンポーネントでは、カスタムフックを用いて、機能の利用可否を判定 ○ API コールのタイミングを意識したくない ○ コンポーネントのレンダリング毎に API コールされるのを避けたい ○ → Front End は Front End で Local Cache を管理 ● TanStack Query のキャッシュ機構を用いて実装 カミナシでの AWS AppConfig 利用例
Slide 53
Slide 53 text
カミナシでの AWS AppConfig 利用例 AWS AppConfigの設定を IaC で管理する
Slide 54
Slide 54 text
カミナシでの AWS AppConfig 利用例 AWS AppConfigの設定を IaC で管理する ● Toggle Configurationは Terrafrom で定義し、Github Repository で管理 ○ Toggle Configuration の変更履歴を残し、レビューのプロセスを通したい ○ ロールアウト、ロールバックしたい時は、PR を出す ● Terraform Cloud 上で、Plan実行 → Apply により、「デプロイ」開始 ○ main ブランチへのマージがトリガー ● Deployment time、Bake time ともに 0 のため、即時に全コンテナに反映
Slide 55
Slide 55 text
カミナシでの AWS AppConfig 利用例 他の選択肢について Toggle Configuration をどこに格納するか? ● RDS、DynamoDB、S3など何かしらの外部ストレージ ○ AWS AppConfig に比べ自由度が高いが、そのぶん設計・実装・管理が難しい ● Amazon CloudWatch Evidently を利用する ○ 自由度、エコシステムなどが、AWS AppConfig の方がふさわしかった ● 環境変数(AWS Systems Manager Parameter Storeなど) ○ タスク再起動が必要。構造化データを持たせる辛み
Slide 56
Slide 56 text
カミナシでの AWS AppConfig 利用例 他の選択肢について Front End からどうやって AWS AppConfig の設定を取得するか? ● Amazon Congito を活用し、Front End から直接 AWS AppConfig の API に アクセスする ○ API サーバーにエンドポイントを定義する方が、(現状では)シンプルかつ、実 装・運用しやすい
Slide 57
Slide 57 text
カミナシでの AWS AppConfig 利用例 活かせている AWS AppConfig の良さ ● ✅「アプリケーションの設定」を更新する時のバリデーション ○ ✅ JSON スキーマ・AWS Lambda ● ✅「アプリケーションの設定」の変更をアプリケーションに迅速に反映 ○ ✅「アプリケーションの設定」がAWS AppConfigにより一元管理 ● ✅ デプロイ・再起動なしで「アプリケーションの設定」の更新を反映 ● 🔴 Deployment Strategy により、設定変更の反映のされ方をコントール ○ トラブル時にロールバック ○ システムメトリクスなどを観ながら、慎重にロールアウト *AWS AppConfig の良さを全て活かしきれているわけではない
Slide 58
Slide 58 text
「2. AWS AppConfig で Feature Flags の仕組みを整備した話」まとめ ➢ AWS AppConfig 使うことにより、 ○ 設定の更新時、バリデーションによりエラーを低減 ○ 設定を一元管理 ○ 設定の更新時にアプリケーションの停止も不要 ○ Deployment Strategy により、設定更新の反映のされ方をコントロー ル ➢ カミナシでは、AWS AppConfig を利用した仕組みを整備し、以下を実現 ○ Toggle Configuration の一元管理 ○ デプロイに依存しないロールアウト
Slide 59
Slide 59 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
Slide 60
Slide 60 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
Slide 61
Slide 61 text
よかったこと 導入しやすさ ● 3-4 人で、1スプリント(1week) 程度の作業ボリュームで導入できた ● いい感じのエコシステムが揃っていた ○ AWS AppConfig agent ■ Local Cache の管理などを実装しなくてよかった ○ Terraform Cloud ○ TanStack Query ■ (AWS AppConfig とは直接関係ないが、Local Cache 管理の点で便利だっ たため、記載)
Slide 62
Slide 62 text
よかったこと 導入した効果(効果を感じている点) ● Toggle Configuration が一元管理されている ○ 認知コストが下がった ○ ロールアウト時の修正漏れ防止 ● ロールアウトのスケジュールが柔軟に設定できるようになった ○ (現状は、毎週火・木に定期デプロイ) ○ このタイミングとロールアウトのタイミングを合わせる必要が無くなっ た
Slide 63
Slide 63 text
アジェンダ 1. Feature Flagsはなぜ必要か? 2. AWS AppConfig で Feature Flags の仕組みを整備した話 3. Feature Flags の仕組みを運用してみての学び a. よかったこと b. 今後の課題
Slide 64
Slide 64 text
➢ Feature Flags のよさを活かし、よりデプロイの頻度を上げる ➢ AWS AppConfig のよさを活かし、サービスの変化・成長に適応する ➢ Feature Flags の濫用を防ぎ、技術負債を作らない仕組み 今後の課題
Slide 65
Slide 65 text
Feature Flags のよさを活かし、よりデプロイの頻度を上げる デプロイとロールアウトの分離が加速したので、デプロイの頻度を上げたい! ● Feature Flags 以外の整備も必要 ○ 派生元ブランチにマージ後の、手動の動作検証がブロッカー ● コードが複雑化している部分では、Feature Flags自体を定義しづらい。 ○ Feature Flags の仕組みがあっても制御しづらい ○ 要リファクタリング 今後の課題
Slide 66
Slide 66 text
今後の課題 AWS AppConfig のよさを活かし、サービスの変化・成長に適応する Deployment strategy について ● 現状は、即座に全コンテナに設定が反映 ○ Deployment time、Bake time が 0 min. ● Deployment strategy を見直したら、ロールバック時の Toggle Configuration の値の管理方法も再考 ○ Github Repository 上の値と、AWS AppConfig 上の値が乖離するため
Slide 67
Slide 67 text
今後の課題 AWS AppConfig のよさを活かし、サービスの変化・成長に適応する バリデーションについて ● 現状では、JSON スキーマによるバリデーションで十分 ● AWS Lambda によるバリデーションも検討? ○ 複雑または、不備があった際に業務影響が大きな Toggle Configuration を使用したいケースがあれば...
Slide 68
Slide 68 text
今後の課題 Feature Flags の濫用を防ぎ、技術負債を作らない仕組み ● Feature Flags を定義しすぎない・長い期間使わない仕組み ○ 定義する数・期間に制限を設ける
Slide 69
Slide 69 text
「3. Feature Flags の仕組みを運用してみての学び」まとめ ➢ AWS AppConfig を利用した Feature Flags の仕組みはエコシステムが充実 しており、妥当な期間で導入できた! ➢ 導入前目的としていた、Toggle Configuration の一元管理やデプロイに依存 しないロールアウトは実現できた! ➢ 一方で、Feature Flags の利点や、AWS AppConfig の長所は今後もっと生か す余地がある!
Slide 70
Slide 70 text
おわり We are hiring !! カミナシ Entrance book エンジニア
Slide 71
Slide 71 text
おわり ご清聴ありがとうございました!
Slide 72
Slide 72 text
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