【ITニュース解説】Service Discovery: The Backbone of Modern Distributed Systems day 50 of system design

現代のアプリケーションは、単一のサーバー上で動作するシンプルな構造から大きく変化し、多くの独立した小さなサービス（マイクロサービス）が連携して動作する分散システムが主流となっている。これらのサービスは、必要に応じて数が増えたり減ったりと動的に変化するため、お互いの場所を効率的に見つけて通信することが難しくなっている。この複雑な課題を解決するために「サービスディスカバリ」という仕組みが不可欠となる。

サービスディスカバリとは、分散システム内でサービスがお互いを動的に見つけ出し、通信できるようにするメカニズムだ。この仕組みは、サービスが相手の正確なネットワークアドレス（IPアドレスやポート番号）を知らなくても通信できることを可能にする。サービスディスカバリの核となるのが「サービスレジストリ」と呼ばれる中央データベースだ。サービスレジストリは、システム内のすべてのサービスに関する情報を集中的に管理する「信頼できる唯一の情報源」として機能する。

サービスレジストリには、各サービスに関する重要な情報が記録される。これには、サービスの名前、IPアドレス、ポート番号、現在の状態といった基本的な詳細が含まれる。さらに、サービスのバージョン、稼働環境、地域、タグなどの追加情報（メタデータ）、サービスの正常性を示すヘルスチェックのステータスと最終実行時間、負荷分散のための重みや優先度、安全な通信のためのプロトコルや証明書なども保存されることがある。

サービスディスカバリがなぜ重要かというと、Netflixのような大規模なシステムでは何百ものマイクロサービスが協調して動作しているためだ。もしサービスがどこにあるかを一つ一つ手動で設定（ハードコーディング）すると、サービスが移動したり、増減したりするたびにシステム全体が機能しなくなる可能性がある。サービスディスカバリは、このような手動設定の必要性をなくし、サービスの位置を動的に見つけ、信頼性の高い通信を可能にする。

サービスディスカバリの主な利点として、手動設定の削減が挙げられる。サービスは自動的に他のサービスを見つけ、接続するため、ネットワークの位置を事前に決める必要がなくなる。次に、スケーラビリティが向上する。サービスが増減する動的な環境にもサービスディスカバリは柔軟に対応できる。また、統合されたヘルスチェックにより、障害が発生したインスタンスからトラフィックを自動的に迂回させる「耐障害性」も実現する。さらに、中央のレジストリがあることで、サービスの監視、管理、トラブルシューティングが容易になる。

サービス登録とは、サービスが自身の存在をサービスレジストリに知らせ、他のサービスから発見できるようにするプロセスだ。この登録方法にはいくつかの選択肢がある。 一つ目は「手動登録」で、開発者や運用担当者が手作業でレジストリにサービス情報を追加する。これはシンプルな方法だが、サービスが頻繁に増減する動的なシステムには現実的ではない。 二つ目は「自己登録」で、サービス自身が起動時にレジストリに自分のネットワーク詳細（IPアドレスやポート）を登録する。サービスは定期的に「ハートビート信号」を送り、自身の健全性を報告することもある。 三つ目は「サードパーティ登録（サイドカーパターン）」で、サービスとは別に動作する「サイドカー」と呼ばれる外部エージェントが、サービスの代わりにレジストリに登録を行う。このサイドカーは通常、サービスと同じコンテナ内で実行される。 四つ目は「オーケストレータによる自動登録」で、Kubernetesのようなコンテナオーケストレーションツールがサービスライフサイクル全体を管理し、サービス起動、停止、スケーリングに応じてIPアドレスやポートを割り当て、レジストリを自動的に更新する。Kubernetesは組み込みのDNSをサービスディスカバリに利用している。 最後に「構成管理システム」として、Chef、Puppet、Ansibleといったツールも、サービスの追加や削除時にレジストリを更新する役割を担うことがある。

サービスディスカバリには、大きく分けて「クライアントサイドディスカバリ」と「サーバーサイドディスカバリ」の2つのモデルがある。

「クライアントサイドディスカバリ」では、サービスを利用する側（クライアント、例えば別のマイクロサービスやAPIゲートウェイ）が、サービスレジストリに直接問い合わせて、目的のサービスインスタンスの場所を特定し、そのインスタンスに直接リクエストを送信する。この仕組みでは、まずサービスが自身のネットワーク詳細とメタデータをサービスレジストリに登録する。次にクライアントがレジストリに問い合わせて、対象サービスの利用可能なインスタンスのリストを取得する。最後にクライアントは、そのリストから適切なインスタンスを一つ選び（例えば、負荷分散アルゴリズムを使って）、直接そのインスタンスに接続してリクエストを送る。この方式の利点は実装が比較的シンプルであることと、中央のインフラ（レジストリ）への負荷を軽減できることだ。しかし、クライアント側にディスカバリのロジックを実装する必要があり、レジストリのプロトコルが変更されると、クライアント側も更新が必要になるという欠点がある。

一方、「サーバーサイドディスカバリ」では、クライアントは直接サービスレジストリに問い合わせるのではなく、間に「ロードバランサー」などの仲介役を挟む。クライアントはロードバランサーにリクエストを送り、ロードバランサーがサービスレジストリに問い合わせて、適切なサービスインスタンスを見つけ、そのインスタンスにリクエストを転送する。この仕組みでは、サービスはクライアントサイドディスカバリと同様にレジストリに登録を行う。クライアントは、ロードバランサーに対して目的のサービスを指定してリクエストを送信する。ロードバランサーはレジストリを照会し、利用可能なサービスインスタンスを一つ選択し、クライアントからのリクエストをそのインスタンスにルーティングする。サービスはリクエストを処理し、ロードバランサーを介してクライアントに応答を返す。この方式の利点は、ディスカバリのロジックが中央のロードバランサーに集約されるため、クライアントの複雑さが軽減されることと、ディスカバリプロトコルの管理や更新が容易になることだ。しかし、ロードバランサーという追加のネットワークホップが発生し、そのロードバランサーが単一障害点となる可能性があるという欠点がある。AWSのElastic Load Balancer（ELB）は、AWSのサービスレジストリと連携してサーバーサイドディスカバリを提供する代表的な例だ。

サービスディスカバリシステムを堅牢にするためには、いくつかのベストプラクティスがある。まず、カスタムな負荷分散が必要ならクライアントサイド、集中的なルーティングが必要ならサーバーサイドというように、適切なモデルを選択することが重要だ。次に、サービスのダウンタイムを防ぐため、複数のレジストリインスタンスを展開し、フェイルオーバーシナリオをテストして高可用性を確保する必要がある。動的な環境では、自己登録、サイドカー、オーケストレーションツールを使って登録を自動化し、使われなくなったサービスは確実に登録解除されるようにする。また、ヘルスチェックを導入し、サービスの健全性を監視して、問題のあるインスタンスを自動的にシステムから除外することも重要だ。サービス名の衝突を避け、管理を容易にするために、明確でユニークな命名規則（例: payment-service-v1）とバージョン管理を徹底する。最後に、レジストリへの負荷を軽減しパフォーマンスを向上させるためにキャッシュを実装し、将来的なサービス増加に対応できるよう、ディスカバリシステム自体がスケーラブルであることを確認する。

サービスディスカバリは、分散システムにおいて目立たない部分かもしれないが、その機能は極めて重要だ。これは、マイクロサービスアーキテクチャにおけるサービスの「住所録」として機能し、これなくしては、分散システムの拡張と維持は混乱を極めるだろう。サービスディスカバリは、シームレスな通信と調整を可能にすることで、複雑なアプリケーションが信頼性高く効率的に動作することを保証する。