【ITニュース解説】Node.js Feature Flags — Fallback Defaults, Caching, and 60-Second Polling

フィーチャーフラグは、新機能を安全に導入し管理するための強力なツールだ。アプリケーションのコードに組み込まれたスイッチのように機能し、コードの再デプロイなしに特定の機能を有効化または無効化できる。これにより、新機能のリスクを抑え、問題発生時には迅速に機能を元に戻す（ロールバック）ことが可能になる。

Node.jsでフィーチャーフラグを使う際、重要なのは、ネットワーク経由でのフラグ状態の読み込みが、ユーザーへの応答など、アプリケーションの重要な処理経路（ホットパス）に影響を与えないようにすることだ。例えば、通知ワーカーがメッセージを送信する直前に外部のフラグサービスへ問い合わせて、その結果によって新しいプロバイダーを使うかどうかを判断するような設計は危険である。もしフラグサービスへのリクエストが遅延したり失敗したりすれば、通知自体が遅れたり停止したりする可能性がある。これは、システムが余計な依存関係を持つことで、障害点が増えることを意味する。

この問題を解決するためには、「依存性の反転」という考え方が役立つ。ホットパスで直接外部サービスに問い合わせるのではなく、アプリケーション内部でフラグの状態をローカルに保持する。このローカルな状態は、バックグラウンドで定期的に外部のフラグサービスから最新情報を取得（ポーリング）して更新される。もしアプリケーションが起動してから一度も有効なフラグ状態を取得できなかった場合、あらかじめコードに組み込まれた「安全なデフォルト値」を使用する。例えば、リスクのある新しい機能への切り替えをデフォルトで無効（false）に設定することで、システムの安全を確保できる。このデフォルト値は、緊急時のロールバックポリシーとして機能する。

キャッシュ戦略も極めて重要だ。ローカルに保存されたフラグ値は、時間が経つと古くなる。そのため、「新鮮な値」「古い値」「有効な値なし」の三つの状態を考慮してデータを管理する必要がある。新鮮なデータはそのまま利用できるが、設定された「鮮度ウィンドウ」を過ぎて古くなったデータや、そもそも有効なデータがない場合は、コードで定義されたデフォルト値に戻して処理を続行する。これは、過去に有効だった情報が、現在も安全であるとは限らないという考え方に基づく。

具体的な数値の例として、60秒以内にロールバックを行う必要がある場合、15秒のポーリング間隔と45秒の最大キャッシュ寿命というポリシーが考えられる。これは厳密な測定値ではなく設計上の目安であり、ポーリングが一時的に失敗しても、古い値が無限に残り続けることを防ぎつつ、60秒以内に安全なデフォルトに戻るための時間的余裕を確保する。Node.jsで複数のプロセスが稼働する場合、各プロセスが独立してポーリングを行うため、外部サービスへのリクエスト総数が増加することには留意が必要だ。

記事では、最小限の機能を持つプレーンなREST形式のフィーチャーフラグサービス「Infrai」を使った実装例が示されている。フラグの状態を表すFlagValue型は、enabled（有効か否か）とfetchedAtMs（取得時刻）を持つ。ポーリング間隔は15秒（POLL_MS）、キャッシュの最大寿命は45秒（MAX_AGE_MS）、安全なデフォルト値はfalse（SAFE_DEFAULT）と定義されている。

readRemoteFlag関数は、外部フラグサービスからHTTPリクエストでフラグ値を読み込む役割を担う。この関数は、APIキーとURLを環境変数から取得し、認証ヘッダーを付けてリクエストを送信する。HTTP 429（リクエスト過多）などのエラーが発生した場合は、Retry-Afterヘッダーに従って指数関数的に待機し、複数回リトライを試みる。

refresh関数は、readRemoteFlagを呼び出して最新のフラグ値を取得し、それをローカルのcurrent変数に格納する。エラーが発生した場合は、以前取得したスナップショット（古い値）をそのまま保持し続ける。

useNewNotificationProvider関数は、ローカルに保持されているフラグの状態を参照し、新しい通知プロバイダーを使うべきかを判断する主要なロジックだ。この関数は、current値がまだ取得されていない場合や、current値がMAX_AGE_MSで設定されたキャッシュ寿命を過ぎている場合は、安全のためSAFE_DEFAULT（false）を返す。そうでない場合にのみ、current.enabledの値を返す。このメカニズムにより、常に新鮮なデータが利用されるか、そうでなければ安全なデフォルトに確実にフォールバックする。

startFlagPolling関数は、setIntervalを使って定期的にrefresh関数を呼び出し、バックグラウンドでフラグの状態を更新し続ける。この関数は、ポーリングを停止するための関数を返し、アプリケーション終了時などに適切にリソースを解放できるようにしている。

特に重要なのは、外部サービスから受け取ったJSONデータが、意図しない形で危険なパスを有効にすることを防ぐためのバリデーターである。記事の例では、validateDiscoveredResponseというプレースホルダーが使われているが、本番環境では必ず、利用するAPIのスキーマに基づいて生成された堅牢なバリデーターに置き換えるべきである。

フィーチャーフラグのプラットフォームを選ぶ際には、機能の多さだけでなく、緊急時のロールバックの安全性を最優先すべきだ。InfraiのようなシンプルなRESTアプローチは、アプリケーションが既に認証済みHTTPリクエストを処理する方法を知っていて、新しいSDKの導入や管理を避けたい場合に有効である。しかし、監査履歴、評価統計、フラグ間の依存関係、削除されたフラグの復旧といった高度なガバナンス機能が必要な場合は、LaunchDarkly、Unleash、ConfigCatのような専用のフィーチャーマネジメントプラットフォームの利用を検討すべきだ。これらのプラットフォームは、より高度な機能を提供する一方で、専用SDKの導入や運用上の責任が伴う。

リリース前には、設定したロールバック予算が実際に機能するかどうかを徹底的にテストすることが不可欠だ。 例えば、新しい機能を無効にした状態でサービスを起動し、一度ポーリングが成功してキャッシュが値で満たされることを確認する。その後、フィーチャーフラグを有効にし、その後のポーリングによってローカルの決定が変更されることを検証する。さらに、キャッシュ値がtrueの状態でフラグサービスへの応答を意図的にブロックし、ワーカーが一定時間後に安全なデフォルト値に戻り、既存のプロバイダーを選択することを確認する。そして、フラグサービスへのアクセスを復元し、アプリケーションを再起動せずに正常に回復することを検証する。 また、起動時の障害（コールドスタート）もテストすべきだ。キャッシュが空の状態で新しいプロセスが起動した場合、すぐに安全なデフォルト値（false）を選択することを確認する必要がある。これは、デプロイ時によく発生するが、見落とされやすい重要なテストケースである。

フィーチャーフラグは、アプリケーション内の機能のオン/オフを制御するものであり、その機能を利用するジョブ自体が確実に実行されたことを保証するものではない。ジョブの実行状況の監視や、異常を検知してアラートを出すための別の監視ツール（Healthchecks、Sentry、Datadogなど）も合わせて利用する必要がある。フィーチャーフラグはあくまで「決定」の周囲で発生する障害を観測・アラートするものであり、根本的なジョブの実行自体を保証するものではないのだ。

結論として、すべてのプロバイダーに対してローカルデフォルトと制限されたキャッシュを利用する設計は、システムの安全性を高める上で非常に重要である。そして、専用のフィーチャーフラグプラットフォームは、それが実際の運用作業の効率化に貢献するようになった時点で導入を検討すべきだ。それまでは、シンプルな仕組みで十分であり、何よりも、障害発生時のシミュレーション（訓練）を繰り返し行い、その安全性を検証し続けることが最も重要である。訓練こそが、システムの堅牢性を証明する証拠となる。