設定値の変更がコード変更よりもリスクが高い場合
設定値を更新したとします。構文は正しく、スキーマ検証も通り、ファイルはエラーなくデプロイされました。ところが5分後、ユーザーがタイムアウトし始めます。データベースは悲鳴を上げ、応答時間は3倍に跳ね上がりました。
何が悪かったのでしょうか？設定は構造的に完璧でした。問題は、それがシステムに与えた影響でした。
このシナリオは、ほとんどのチームが認識しているよりも頻繁に発生します。私たちは設定変更を低リスクの操作として扱いがちです。フォーマットを検証し、タイプミスをチェックし、設定ファイルが有効であれば安全だと決めつけます。しかし、構文的に正しい設定値でも、コード変更では滅多に起こらない方法で本番システムを壊す可能性があります。
設定変更の静かなる危険
コード変更は多層的な保護を経ます。レビューされ、CIパイプラインでテストされ、ステージング環境にデプロイされ、本番に到達する前に再テストされることもよくあります。対照的に、設定変更はこれらのステップのほとんどをスキップすることが多いです。本番設定ファイルの値を1つ変更するだけで、コードを保護するすべての安全策をすり抜けてしまう可能性があります。
レート制限を毎秒100リクエストから1000に変更した場合を考えてみてください。設定は有効です。タイプミスはありません。スキーマチェッカーはすべて問題ないと表示します。しかし、バックエンドサービスはそれほど多くの同時リクエストを処理するように設計されていません。データベース接続プールは枯渇し、キャッシュ層は圧倒され、ユーザーはエラーを目にし始めます。
問題は設定フォーマットではありません。問題は、実際の影響を理解せずにシステムパラメータを変更したことです。そして、設定変更はしばしば全インスタンスに即座に適用されるため、被害は一斉に発生します。
段階的ロールアウトが設定にとって重要な理由
コードのカナリアデプロイを安全にするのと同じ原則が、設定にも当てはまります。アプリケーションの新しいバージョンを全ユーザーに一度にデプロイすることは決してないでしょう。まずは小さなサブセットに送り、結果を監視し、その後徐々にロールアウトを拡大します。
設定変更も同じ扱いに値します。
設定変更を段階的にロールアウトすると、観測のための時間枠が生まれます。古い設定で動作しているインスタンスと新しい設定で動作しているインスタンスの振る舞いを比較できます。何か問題が発生しても、影響を受けるユーザーはごく一部です。被害が広がる前にロールバックできます。
このアプローチは、設定に対する考え方を変えます。「値を変更するだけ」の操作ではなくなり、制御された実験になります。
段階的設定ロールアウトの実践的アプローチ
フィーチャーフラグ
フィーチャーフラグは、段階的設定ロールアウトの最も一般的なメカニズムです。設定値をグローバルに変更する代わりに、新しい振る舞いをフラグの背後にラップし、ユーザー、セッション、またはインスタンスごとにトグルできるようにします。
以下のフローチャートは、状況に応じた段階的ロールアウトのアプローチを選択するのに役立ちます。
実際の運用は次のようになります。チームが新しいレコメンデーションアルゴリズムに切り替えたいとします。全員に適用される設定ファイルを更新する代わりに、デフォルト値がfalseのnew_recommendation_algoというフィーチャーフラグを作成します。フィーチャーフラグダッシュボードから、ユーザーの5%に対してフラグを有効化します。それらのユーザーのエラー率、応答時間、ユーザーエンゲージメントを監視します。すべてが良好であれば、25%、50%、そして100%へと増やしていきます。
どの段階でも問題が発生した場合、フラグを全員に対してfalseに戻します。コードのデプロイは不要です。設定ファイルのロールバックも不要です。単一のトグル操作だけです。
設定サービスにおけるパーセンテージベースのロールアウト
一部の設定サービスは、パーセンテージベースのロールアウトをネイティブにサポートしています。ConsulやAWS AppConfigのようなツールは、新しい設定値を受け取るインスタンスの割合を指定できます。
例えば、10台の本番サーバーがあるとします。新しいレート制限値をそのうちの2台だけに送信するように設定サービスを構成します。その2台のサーバーを注意深く監視します。エラー率は他の8台と異なりますか？CPU使用率は高いですか？応答が遅くなっていますか？
このアプローチは、インフラが均一で、ロードバランサーがトラフィックを均等に分散している場合に効果的です。新しい設定を持つ2台のサーバーが、事実上のカナリアグループになります。
環境ベースのステージング
段階的ロールアウトは本番環境だけのものではありません。ステージング環境やテスト環境でも同じ考え方を適用できます。違いは、ステージングではユーザーベースが小さいため、通常はパーセンテージベースの分割は必要ないことです。しかし、原則は同じです。設定変更を適用し、影響を観察し、本番に昇格する前に振る舞いを確認します。
設定ロールアウト中に監視すべきこと
一見無害に見える設定変更でも、影響が遅れて現れることがあります。影響が可視化されるまでに数分から数時間かかることもあります。ロールアウト期間中は、適切なシグナルを監視する必要があります。
追跡すべき重要なメトリクスは次のとおりです。
- エラー率: 設定変更後、より多くのリクエストが失敗していませんか？
- 応答時間: システムの応答が遅くなっていませんか？
- スループット: システムは同じ量のリクエストを処理できていますか？
- リソース使用率: CPU、メモリ、データベース接続が急増していませんか？
これらのメトリクスを設定変更の前後で比較します。異常が見られたら、すぐにロールバックしてください。調査する前に待ってはいけません。まずロールバックし、その後で調査します。
設定ロールアウトのためのクイックチェックリスト
本番の設定値を変更する前に、以下のチェックを実行してください。
- この変更は非本番環境で最初にテストできますか？
- インスタンスやユーザーのサブセットにロールアウトできますか？
- この変更が安全かどうかを教えてくれるメトリクスは何ですか？
- 問題が発生した場合のロールバック計画は何ですか？
- ロールバックがトリガーされた場合、誰に通知する必要がありますか？
このチェックリストは30秒で完了しますが、何時間もの火消し作業を防ぐことができます。
設定変更はコード変更である
設定をプロフェッショナルに管理するチームは、すべての設定変更をコード変更と同様に扱います。プロセスがあり、観察があり、ロールバックメカニズムがあります。設定は本番サーバー上で直接編集するものではありません。アプリケーションコードと同じ厳格さを経るデリバリアーティファクトです。
次に設定値を変更しようとするときは、立ち止まってください。自問してみてください：コード変更をこの方法でデプロイするだろうか？答えが「いいえ」なら、設定もその方法で変更すべきではありません。段階的にロールアウトし、何が起こるかを観察し、システムが処理できると確信できたときにのみ完全にコミットしてください。