このサイトでは、サイトや広告を改善するために Cookie を使用します。サイトを利用することで、Cookie の使用に同意するものといたします。詳細はプライバシーについてをご覧ください。
インフラの複雑な設定は不要。ユーザー ID 単位の精密な制御と自動ロールバックで、
影響範囲を最小限に抑えながら安全に機能を公開します。
「カナリア リリース」は安全なリリースの定石ですが、ロード バランサーや Kubernetes (K8s) などのインフラ層で実装しようとすると、多くのエンジニアが壁に直面します。
本番環境を多重化する必要があり、ルーティング設定やセッション維持 (Sticky Session) の管理が非常に困難です。
「トラフィックの 5%」といった大雑把な振り分けしかできず、「社内ユーザーのみ」「β 版契約者のみ」といった細かい指定ができません。
バグ発覚時、インフラの設定変更や再デプロイが必要となり、完全なロールバックまでに数分〜数時間を要します。
| 比較項目 | 従来のインフラ ベース (AWS ALB, K8s Istio 等) |
LaunchDarkly アプリケーション ベース |
|---|---|---|
| 制御の粒度 |
リクエスト単位 どのユーザーかは識別せず、ランダムに振り分け。 |
ユーザー ID / 属性単位 「特定の顧客」「特定の地域」など文脈に応じた制御が可能。 |
| 実施コスト |
高い 並行稼働環境が必要なため、インフラ リソースが倍増することも。 |
低い 既存の環境内でフラグ判定を行うため、追加インフラは不要。 |
| ロールバック |
遅い (数分〜) ルーティング変更の伝播や再デプロイ待ちが発生。 |
即時 (数ミリ秒) キル スイッチを OFF にするだけで、全ユーザーが一瞬で旧版へ。 |
| 担当者 |
SRE / インフラ エンジニア インフラ設定変更の権限が必要。 |
開発者 / PM 管理画面から誰でも安全に操作可能。 |
コードは本番環境にデプロイ済みですが、一般ユーザーには OFF になっています。管理画面でターゲットを「社内ユーザー (自分たち)」だけに設定し、本番データを用いた最終確認を行います。
問題を早期発見するため、適用範囲を全ユーザーの 1% に設定します。インフラの再起動は不要です。スライダーを動かすだけで、即座にトラフィックが流れます。
Datadog や New Relic と連携し、エラーレートを監視します。もし閾値を超えた場合、LaunchDarkly の「Flag Trigger」が作動し、自動的にフラグを OFF にして影響を食い止めます（人間が寝ていても安全です）。
安全が確認されたら、段階的に 10% → 50% → 100% と公開範囲を広げます。全ユーザーへの適用が完了したら、Code References 機能を使ってコードからフラグを削除し、完了です。
LaunchDarkly なら、A/B テストやカナリア リリースといった高度な戦略も数クリックで完結します。
リスクを抑えながら、確実なデータに基づいてプロダクトを進化させましょう。