etcd によるアジア太平洋地域のビデオトラフィック・ルーティング

アジア太平洋地域の8つの市場にサービスを提供するビデオストリーミングプラットフォームは、リージョン固有の設定を etcd に移行することで、繰り返し発生していたルーティングのミスを解消しました。ルーティング変更の伝播時間は約1秒に短縮されました。エディターはコードに触れることなく、数時間だけミュージックプールをブーストできるようになり、プラットフォームは韓国の視聴者に東京のフィードを送信してしまう問題を解決しました。

旧来のアプローチが失敗した理由

各ルーターは、リクエストごとに3つの値（トレンドプール、言語固有のトークナイザー、フォールバックチェーン）を読み取っていました。これらの値は、コードの変更ではなく、新しいアーティストのプロモーション、リージョン障害への対応、レコメンデーション・アルゴリズムのテストといったビジネス上の決定によって制御されていました。

当初、すべてのデプロイメントにはルーティングテーブルを含むJSONファイルが同梱されていました。障害発生時、オンコールエンジニアが1つのノード上のファイルを編集してトラフィックをバックアッププールに向けるようにしましたが、他の7つのノードを更新し忘れてしまいました。これにより「設定のドリフト（Config drift）」が発生しました。8つの国で異なるテーブルが実行され、「真実」を検証できる単一のソースが存在しなくなりました。コード自体は変わっていなかったため、韓国の視聴者を東京に送ってしまうバグが解消されませんでした。隠れた設定だけが異なっていたのです。

「信頼できる唯一の情報源」として etcd を選択

チームは3つの選択肢を比較しました。

  • SQLite/MySQL – 各ルーターがデータベースにポーリングを行う必要があり、レイテンシの増加やクエリの氾濫を招く。
  • Consul – 優れたサービスディスカバリ・ツールだが、プラットフォームにはそのフルメッシュ機能までは必要なかった。
  • etcd – 強整合性を持つキーバリュー・ストアであり、キーが変更された瞬間にクライアントに通知する watch プリミティブを備えている。

watch 機能が決め手となりました。各ルーターが繰り返し「何か変更されたか？」と尋ねる代わりに、etcd がアップデートをプッシュするまでルーターは待機状態になります。不要なネットワークトラフィックは消失し、すべてのインスタンスが同時に変更を把握できるようになりました。

システムの安全性を維持するパターン

etcd だけではすべてのリスクを解決できません。エンジニアは、3つの補完的なパターンを追加しました。

  1. Leases（リース） – エディターは一時的なブースト（例：韓国ポップスのプールのウェイトを6時間増やす）を設定できます。リースは自動的に期限切れになるため、手動でのロールバックなしにブーストが解除されます。
  2. Compare-and-swap (CAS) – 2人が同時に同じ設定を編集した場合、CAS は一方に対して明確にエラーを返し、サイレントな上書きを防ぎます。
  3. Sidecar process（サイドカープロセス） – PHP は長時間接続の維持が苦手です。各サーバー上の小さな Go 製サイドカーが etcd を watch し、ルーティングテーブルのスナップショットを共有メモリファイル (/dev/shm) に書き込みます。PHP はそのローカルファイルを読み取るため、リクエスト処理中のネットワーク・ラウンドトリップを回避できます。

アーキテクチャに組み込まれたレジリエンス

新しい設計には、いくつかのセーフティネットが組み込まれています。

  • ゼロレイテンシの読み取り – PHP のホットパスはローカルメモリから読み取るため、リモートストアの応答待ちでリクエストが停止することはありません。
  • 緩やかな劣化 (Graceful degradation) – etcd がダウンした場合でも、ルーターは最後に確認された正常な設定を保持し続け、突然の停止を防ぎます。
  • 信頼性の高いアップデート – サイドカーが再接続ロジックを処理し、etcd への接続が一時的に切断された場合でも、変更を見逃さないことを保証します。

現場で起きた変化

移行後、古い、あるいは不一致なルーティングデータに起因するインシデントは劇的に減少しました。単一のコンソールで現在の設定が表示され、編集内容は1秒以内に全8リージョンに伝播します。一時的なブーストはリースが切れると自動的にクリーンアップされるため、以前はヒューマンエラーの原因となっていた手動のクリーンアップ作業が不要になりました。

反論：サイドカーのコスト

サイドカーを追加するということは、サーバーごとに2つ目のプロセスが必要になり、PHP 中心的なスタックに Go のランタイムが加わることを意味します。運用担当者の中には、メモリ使用量の増加や、別のバイナリを監視する必要性を懸念する人もいます。実際には、サイドカーのフットプリントは控えめであり、信頼性の向上（特に PHP がネットワークコールでブロックしないという保証）は、運用オーバーヘッドを上回ります。

次に注視すべき点

マルチリージョン・サービスを管理するチームは、以下の点に注意すべきです。

  • etcd のヘルスメトリクス – ルーティング層は単一のストアに依存しているため、クォーラム（合意）の状態とレイテンシを監視してください。
  • リースの期限切れ処理 – リースの時間をビジネス上の時間枠に合わせます。リースが長すぎると、古いブーストが残り続けてしまいます。
  • watch 負荷のスケーリング – ルーターが増えると watch 接続も増加します。それに応じて etcd サーバーのキャパシティを計画してください。

まとめ

多くのリージョンにわたって、高速かつ調整された設定変更を必要とするあらゆるサービスにとって、etcdのwatch、lease、およびtransactionプリミティブは、ファイルベースの設定や重量級のメッシュに代わる、軽量で強力な一貫性を持つ代替手段を提供します。設定をプッシュ駆動型で自己クリーンアップ機能を持つストアへと転換したことで、特定の種類のインシデントが根絶され、プラットフォームはルーティングロジックをリアルタイムで制御できるようになりました。