システムの設計レビューで、ベンダーから提示された構成図に「Service Discovery」あるいは「サービスレジストリ」というブロックが描かれていた。説明は受けたものの、それが機器なのか、ソフトウェアなのか、単なる設定の呼び名なのかが判然としない。そんな状態のまま、稼働後の運用フロー図と保守契約の草案を作らなければならない、という場面は珍しくありません。
サービスディスカバリという言葉を検索すると、多くの記事はクライアントサイドとサーバーサイドという2つの実装パターンの解説に進みます。しかし発注する側が本当に知りたいのは、パターンの名前ではありません。「稼働後、この部分は誰が何を見続けるのか」「障害の連絡を受けたとき、自社は何を確認すればいいのか」という、運用と契約に直結する問いのはずです。ところが、この観点で書かれた解説はほとんど見当たりません。
結論を先に述べます。サービスディスカバリは、サービス同士の接続先を人手で管理する作業を自動化する仕組みです。ただし自動化と引き換えに、「接続先の台帳」そのものを保守するという新しい仕事が発生します。ここを理解しておくと、障害時の切り分け手順も、保守契約に書くべき責任分界も、自分の言葉で組み立てられるようになります。
本記事では、サービスディスカバリの定義とマイクロサービスで必要になる理由から始め、サービスレジストリとヘルスチェックの動作、2つの実装方式の違い、Kubernetes と Consul の使い分けを整理します。そのうえで、導入後に保守対象へ新しく加わるもの、「つながらない」を切り分ける確認順序、保守契約で決めておくべき責任分界の項目まで解説します。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
サービスディスカバリとは？マイクロサービス連携でIPアドレスが固定できない理由
サービスディスカバリ（サービスディスカバリー、Service Discovery）とは、呼び出したいサービスの「名前」から、そのとき実際に稼働している接続先（IP アドレスとポート番号）を自動的に解決する仕組みです。クラウドネイティブ技術の用語を整理している CNCF の用語集でも、サービスディスカバリは「サービスを構成する個々のインスタンスを見つけるプロセス」であり、「サービスを構成するさまざまなノードやエンドポイントを追跡」するものと定義されています（CNCF クラウドネイティブ用語集）。
ポイントは「そのとき実際に稼働している」という部分です。従来のシステムでは接続先のアドレスは固定であり、設定ファイルに書いておけば済みました。マイクロサービス構成では、この前提が崩れます。
サービスディスカバリが解決している問題（接続先が動き続ける前提）
コンテナを使ったシステムでは、サービスの実体（インスタンス）は頻繁に入れ替わります。デプロイのたびに古いインスタンスが停止して新しいインスタンスが起動しますし、アクセスが増えれば自動的にインスタンスが増え、落ち着けば減ります。障害が起きたインスタンスは自動的に破棄され、別の場所で再作成されます。
このとき、新しく起動したインスタンスには、前とは違う IP アドレスが割り当てられるのが普通です。前掲の CNCF 用語集も、コンテナ化されたアプリケーションが頻繁に起動と停止を繰り返し、毎回新しいアドレスが割り当てられる点を、サービスディスカバリが解決すべき問題として挙げています。
つまり「注文サービスは 10.0.1.24 にいる」という前提が、数分後には成立しなくなります。サービスディスカバリは、この「動き続ける接続先」を追跡し、呼び出す側が名前だけを指定すれば済むようにする仕組みです。
運用の観点で言い換えると、これまで人が手で行っていた「サーバーを増やしたら設定ファイルに追記し、減らしたら削除する」という作業を、システム側が自動で行うようになる、ということです。
モノリスとマイクロサービスで接続先の管理がどう変わるか
1つのアプリケーションとして構築されたモノリシックな構成では、機能同士のやり取りはアプリケーション内部の関数呼び出しで完結します。ネットワークをまたがないため、接続先という概念自体がほとんど存在しません。
これをマイクロサービスとして分割すると、機能同士のやり取りはネットワーク越しの通信になります。10 個のサービスに分割すれば、サービス間の呼び出し経路は数十本規模になり、それぞれに「どこへつなぐか」の情報が必要になります。しかも各サービスのインスタンス数は運用中に変動します。
管理すべき情報の量が、分割によって一気に増えるわけです。分割そのものをどう判断するかについては、マイクロサービスとモノリスの違いを整理した記事で解説していますので、アーキテクチャ選択の段階にある場合はそちらもあわせてご覧ください。本記事は「分割したあと、サービス同士がどうつながるか」に絞って扱います。
DNS・ロードバランサーの固定設定では追いつかない状況
「名前からアドレスを引くなら DNS でよいのでは」「振り分けならロードバランサーがあるのでは」という疑問は自然なものです。実際、サービスディスカバリは DNS やロードバランサーを排除する技術ではなく、多くの場合はそれらを内側で利用しています。
違いは、更新の頻度と自動化の度合いにあります。従来型の運用では、サーバーを追加したときに DNS レコードやロードバランサーの振り分け先リストを人が更新します。日単位・週単位の変更であれば、これで十分に回ります。
一方、コンテナのオートスケーリングでは、インスタンスの増減が分単位・秒単位で発生します。人が申請書を書いて設定変更する運用では追いつきません。また、キャッシュの効いた DNS レコードは、すでに停止したインスタンスのアドレスをしばらく返し続けることがあります。
そこでサービスディスカバリは、インスタンスの起動・停止を検知して接続先の一覧を自動更新する仕組みを組み込みます。ここで自動更新される一覧が、次に説明するサービスレジストリです。そして冒頭で触れたとおり、この台帳が新しい保守対象になります。
サービスディスカバリの仕組み｜サービスレジストリとヘルスチェック
サービスディスカバリの中核にあるのがサービスレジストリです。仕組みを構成要素に分けると、「台帳（サービスレジストリ）」「台帳に載せる作業（登録）」「台帳を最新に保つ作業（ヘルスチェックと登録解除）」の3つになります。
サービスレジストリが持つ情報と更新のタイミング
サービスレジストリは、「いま、どのサービスの、どのインスタンスが、どのアドレスで生きているか」を保持する台帳です。おおむね次のような情報を持ちます。
項目 | 内容の例 |
|---|---|
サービス名 |
|
インスタンスのアドレス |
|
状態 | 正常／異常（ヘルスチェックの結果） |
メタ情報 | バージョン、稼働リージョン、環境の区分など |
台帳が更新されるタイミングは主に3つです。1つ目は、新しいインスタンスが起動したときの登録。2つ目は、インスタンスが正常に停止したときの登録解除。3つ目は、インスタンスが異常と判定されたときの状態変更または削除です。
重要なのは、この台帳が「実際の稼働状況を写した鏡」であって、実態そのものではないという点です。鏡が曇れば、つまり台帳の更新が遅れれば、呼び出す側は存在しない接続先を教えられます。この性質が、後述する障害の見え方に直結します。
自己登録型と第三者登録型の違い
台帳に情報を載せる方法には、大きく2つの型があります。
自己登録型は、サービス自身が起動時にレジストリへ「私はここにいます」と名乗り出る方式です。以後は定期的に生存信号を送り続け、停止時には自分で登録解除を行います。アプリケーション側に登録処理を組み込む必要がありますが、サービス自身が持つ情報（バージョンや対応機能など）を細かく登録できます。
第三者登録型は、サービス自身は何もせず、基盤側の別の仕組みがインスタンスの起動・停止を検知して代わりに登録・削除する方式です。アプリケーションのコードに手を入れずに済む代わりに、検知役の仕組みが1つ増えます。Kubernetes のように基盤がインスタンスの生死を把握しているプラットフォームでは、こちらの形が自然になります。
発注する側が押さえておくべきなのは、「どちらの型か」によって、登録の不具合が起きたときに疑う場所が変わるという点です。自己登録型ならアプリケーション側の登録処理、第三者登録型なら基盤側の検知の仕組みが第一の確認先になります。
ヘルスチェックの遅れが生む「停止済みインスタンスへの転送」
台帳を最新に保つ役割を担うのがヘルスチェックです。一定間隔で各インスタンスに問い合わせを行い、応答がなければ「異常」と判定して振り分け先から外します。Kubernetes でも、コンテナが正常に稼働しているかを確認する Liveness、リクエストを受け付けられる状態かを確認する Readiness といった仕組みが用意されています（Kubernetes 公式ドキュメント）。
問題は、判定には必ず時間差が生じることです。「5秒間隔でチェックし、3回連続で失敗したら異常とみなす」という設定であれば、実際に停止してから振り分け先を外れるまで最大で15秒以上かかります。その間、呼び出し側はすでに落ちているインスタンスへリクエストを送り続けます。
さらに、呼び出し側がアドレスを一定時間キャッシュしている場合、台帳から消えたあとも古いアドレスを使い続けることがあります。運用の現場では、Kubernetes を用いた構成であっても、DNS のキャッシュや、更新の反映待ちによって、切り替え作業中に断続的な失敗が起きるケースが知られています。
本記事ではこの状態を「幽霊インスタンス」と呼びます。台帳の上には存在するが、実体はすでにいない接続先です。この幽霊インスタンスこそが、発注者側が体感する「常に落ちているわけではないが、たまにエラーになる」という、もっとも切り分けにくい障害の正体になります。
デプロイの直後だけエラー率が上がる、という現象を報告されたときは、アプリケーションの不具合を疑う前に、ヘルスチェックの間隔と、インスタンス停止時の待機処理が適切かを確認する価値があります。
サービスディスカバリの2つの方式｜クライアントサイドとサーバーサイド
台帳をどう引くかによって、サービスディスカバリは大きく2つの方式に分かれます。この選択は、単なる技術的な好みではなく、「どこに手を入れる必要があるか」、つまり保守の担当範囲の形を決めます。
クライアントサイドディスカバリの流れと向き・不向き
クライアントサイドディスカバリは、呼び出す側のサービスが自らレジストリに問い合わせ、返ってきた接続先の一覧から自分で1つを選んで通信する方式です。処理の流れは次のようになります。
- 呼び出す側がレジストリに「注文サービスのアドレスを教えてほしい」と問い合わせる
- レジストリが正常なインスタンスの一覧を返す
- 呼び出す側が一覧の中から1つを選ぶ（振り分けの判断を自分で行う）
- 選んだアドレスへ直接リクエストを送る
利点は、通信経路に中継役が入らないため経路が短く、呼び出す側の事情に応じた細かい振り分けができることです。
一方で、レジストリへの問い合わせと振り分けのロジックを、呼び出す側のすべてのサービスに組み込む必要があります。通常は言語ごとのライブラリを使いますが、システム内で使われている言語が Java・Python・Go と複数にわたる場合、その数だけ実装と保守が必要になります。ライブラリのバージョンアップも、各サービスの改修として実施することになります。
つまり、利用言語が少なくアプリケーション側の改修が容易な場合には適し、言語が多い場合や既存アプリケーションに手を入れにくい場合には負担が大きい方式です。
サーバーサイドディスカバリの流れと向き・不向き
サーバーサイドディスカバリは、呼び出す側は決まった宛先（ロードバランサーやプロキシなど）にリクエストを投げるだけで、その宛先がレジストリを参照して実際のインスタンスへ振り分ける方式です。
- 呼び出す側が「注文サービス」という名前の宛先へリクエストを送る
- 中継役がレジストリを参照し、正常なインスタンスを選ぶ
- 中継役が選んだインスタンスへリクエストを転送する
利点は、呼び出す側のアプリケーションに一切手を入れずに済むことです。どの言語で書かれていても、通常のリクエストを送るだけで動きます。既存システムを含む構成や、複数言語が混在する構成では、この点が大きく効きます。
一方で、中継役に負荷とリスクが集中します。中継役が停止すればサービス間の通信全体が止まりますし、性能上のボトルネックにもなり得ます。そのため中継役を冗長化する設計が前提となり、その冗長構成自体も保守対象になります。
どちらを選ぶかの判断軸（利用言語の数・アプリ改修範囲・障害の集中点）
発注する側が確認しておくべき判断軸を整理すると、次の3点になります。
判断軸 | クライアントサイド | サーバーサイド |
|---|---|---|
利用言語の数 | 言語が増えるほど実装・保守の負担が増える | 言語の数に影響されない |
アプリケーションの改修範囲 | 全サービスにライブラリの組み込みが必要 | 原則としてアプリケーションの改修は不要 |
障害の集中点 | 分散するが、各サービスに障害の芽が残る | 中継役に集中するため冗長化が必須 |
保守の主担当 | アプリケーション側の担当（ライブラリ更新を含む） | インフラ側の担当（中継役の運用） |
最後の行が、本記事で強調したい点です。クライアントサイドを選ぶと、サービスディスカバリの不具合はアプリケーションの改修として扱われる可能性が高くなります。サーバーサイドを選ぶと、インフラ保守の範囲に寄ります。方式の選択は、そのまま保守契約の切り方に影響します。設計レビューの場では、「この方式では、接続先まわりの問題は誰の作業になりますか」と確認しておくと、後の契約協議がスムーズになります。
サービスディスカバリの実現手段｜Kubernetes・Consul・サービスメッシュの使い分け
製品名を並べる前に、判断の順序を確認します。まず既存の構成でどこまで賄えるかを確定させ、賄えない条件が明確になった場合にのみ、追加の製品を検討する。この順序を守ると、不要な追加コストを避けられます。
Kubernetes の Service と DNS で完結する範囲
すでに Kubernetes を採用している、あるいは採用する予定であれば、サービスディスカバリの基本機能は標準で備わっています。追加の製品を導入しなくても、Service という機能と、クラスタ内部の DNS によって名前からアドレスを解決できます。
Kubernetes では、Service に対して <サービス名>.<名前空間>.svc.cluster.local という形式の DNS 名が自動的に割り当てられます（Kubernetes 公式ドキュメント）。呼び出す側はこの名前を指定するだけでよく、実際にどのインスタンスへ振り分けられるかは Kubernetes が管理します。インスタンスが増減しても、名前は変わりません。
台帳の更新も自動です。クラスタ内の DNS サーバーは Kubernetes の状態を監視し、サービスやインスタンスの変化に合わせてレコードを同期します。登録という作業を人が行う場面は、通常ありません。
Kubernetes そのものの役割については、Kubernetes とはを解説した記事で基本的な考え方を整理しています。構成図の中で Kubernetes がどこまでを担っているかを把握したい場合は、あわせてご覧ください。
発注する側としては、まず「今回の構成は Kubernetes 上で完結するのか」を確認してください。完結するのであれば、サービスディスカバリのために別製品を購入する必要は基本的にありません。見積に専用製品のライセンス費が計上されている場合は、その必要性を説明してもらう根拠になります。
Consul など専用レジストリが必要になるケース
一方で、Kubernetes の標準機能だけでは足りない状況もあります。代表的なのが、Kubernetes の外側に管理対象がある場合です。
HashiCorp の Consul は、サービスを登録する中央のカタログを提供し、コンテナ以外のワークロード（仮想マシンなど）も含めて横断的にサービスを追跡できることを特徴として掲げています（Consul 公式ドキュメント）。専用レジストリの導入を検討すべき条件は、おおむね次のいずれかに該当する場合です。
- Kubernetes の外に資産がある: 仮想マシン上で動く既存システムや、オンプレミスのサーバーが連携先に含まれる
- 複数の環境をまたぐ: 複数のクラスタ、複数のクラウド、オンプレミスとクラウドの併存といった構成で、環境をまたいだ名前解決が必要
- 段階的な移行の途中である: 既存システムを残しながら少しずつマイクロサービスへ移していく計画で、新旧が並走する期間が長い
逆に、これらに該当せず単一の Kubernetes クラスタで完結するのであれば、専用レジストリの追加は管理対象を1つ増やすだけになりかねません。
なお、Java の Spring 環境では Eureka という選択肢の名前を見かけることがあります。Eureka 自体は、Spring Cloud Netflix の多くのモジュールがメンテナンスモードへ移行した際にも対象から除外されており、サポートが継続されてきた経緯があります（Spring 公式ブログ）。ただし周辺の Netflix 系モジュールは整理が進んでいるため、新規に採用する場合は、対象バージョンの最新のサポート状況をベンダーに確認したうえで判断することをおすすめします。
サービスメッシュ・APIゲートウェイとの役割の違いと重なり
構成図には、サービスディスカバリのブロックと並んで「サービスメッシュ」や「API ゲートウェイ」が描かれていることがあります。役割の違いを整理しておくと、図の読み解きが楽になります。
仕組み | 主な役割 | サービスディスカバリとの関係 |
|---|---|---|
サービスディスカバリ | サービス名から稼働中の接続先を解決する | 本記事の主題 |
サービスメッシュ | サービス間通信の制御全般（暗号化・再試行・流量制御・可視化） | ディスカバリの機能を内包したうえで、通信制御まで担う |
API ゲートウェイ | 外部からの入口として、認証・流量制限・振り分けを行う | 外部との境界を担当。サービス間通信とは別のレイヤ |
もっとも混同しやすいのがサービスメッシュとの関係です。サービスメッシュはサービスディスカバリを含む、より広い範囲の仕組みだと捉えると整理できます。メッシュを導入するのであれば、ディスカバリのために別途製品を足す必要は通常ありません。サービスメッシュとはを解説した記事も公開していますので、構成図にメッシュが含まれている場合はそちらもご確認ください。
API ゲートウェイは、利用者のブラウザやアプリからシステムへ入ってくる通信を扱うもので、システム内部のサービス同士の通信とは担当領域が異なります。API ゲートウェイの役割を整理した記事もあわせてご覧いただくと、構成図のどのブロックが外向きでどのブロックが内向きかを区別しやすくなります。
サービスディスカバリが保守・運用に与える影響｜増える管理対象と障害の見え方
ここからが本記事の中心です。サービスディスカバリを導入すると、接続先を人が管理する作業はなくなります。しかしその代わり、保守対象に新しい項目が加わり、障害の見え方も変わります。
保守対象に新しく加わる4つのもの
導入後、運用チームが継続的に面倒を見ることになるのは、主に次の4つです。
1. サービスレジストリ本体の可用性
台帳が引けなくなると、サービス同士がお互いを見つけられなくなります。Kubernetes の標準機能を使う場合はクラスタ内 DNS が、専用製品を使う場合はその製品自体が、可用性の管理対象になります。冗長化されているか、監視対象に含まれているか、障害時に誰が対応するかを確認しておく必要があります。
2. ヘルスチェックの定義と閾値
「何をもって正常とみなすか」の定義と、判定間隔・失敗回数の閾値です。厳しすぎれば正常なインスタンスまで切り離され、緩すぎれば幽霊インスタンスが長く残ります。この値は初期設定のまま放置されがちですが、サービスの特性が変われば見直しが必要になります。
3. 呼び出し側のタイムアウトとリトライ方針
接続先が動的に変わる前提では、一時的な失敗が起きることを織り込んだ設計になります。何秒待つか、何回やり直すかという方針は、障害時の挙動を大きく左右します。リトライ回数が多すぎると、一部の不調が全体の高負荷につながることもあります。
4. 名前解決に関わるキャッシュの設定
DNS のキャッシュ時間や、アプリケーション側で接続先を保持する時間の設定です。長くすれば問い合わせの負荷は下がりますが、切り替えの反映が遅れます。短くすれば反映は速くなりますが、問い合わせが増えます。このトレードオフの調整先が、新しく1つ増えることになります。
これら4つは、いずれも「動いているうちは誰も触らない」項目です。だからこそ、保守体制を決める段階で担当者を明示しておかないと、必要になったときに誰も手を出せない状態になります。
「つながらない」を3層に切り分ける確認順序
サービスが「つながらない」と報告されたとき、原因は大きく3つの層に分かれます。上から順に確認していくと、切り分けが効率的に進みます。
第1層: 呼び出し先のサービス自体の不具合
まず、呼び出される側のサービスが正常に動いているかを確認します。個別のインスタンスに直接アクセスして応答が返るか、エラーログが出ていないか、というレベルの確認です。ここに問題があれば、通常のアプリケーション障害として扱います。
第2層: 台帳の遅れ・残留
サービス自体は正常なのに通信が失敗する場合、台帳の内容を疑います。確認するのは2方向です。「起動しているインスタンスが台帳に載っていない（登録されない）」のか、「停止したインスタンスが台帳に残っている（消えない）」のか。前者なら登録の仕組み、後者ならヘルスチェックの設定が疑わしくなります。デプロイ直後だけ発生する、あるいは断続的に失敗するという症状は、この層である可能性が高くなります。
第3層: レジストリや振り分け役そのものの障害
台帳が引けない、あるいは中継役が停止している場合です。この層に問題があると、特定のサービスではなく広範囲で通信が失敗するため、影響範囲の広さが判断材料になります。
この順序は、ベンダーへの問い合わせの仕方にも使えます。「つながりません」ではなく、「呼び出し先のインスタンス単体には応答があるが、名前経由だと失敗する」と伝えられれば、第2層以降の調査から始められます。
なお、どのサービスのどの区間で時間がかかっているか、どこで失敗しているかをサービスをまたいで追跡するには、分散トレーシングの仕組みが有効です。マイクロサービス構成で調査に時間がかかっている場合は、可視化の手段が足りているかもあわせて検討する価値があります。
設定の分散が招く属人化と引き継ぎリスク
サービスディスカバリに関わる設定は、1か所にまとまりません。ヘルスチェックの定義は基盤側の定義ファイルに、タイムアウトとリトライの方針はアプリケーションのコードや設定に、キャッシュの設定はさらに別の場所に、というように分散します。
この分散が、担当者の交代時に問題になります。全体像を把握しているのが構築を担当した1人だけ、という状態は珍しくありません。その人が離任すると、値を変える必要が生じたときに、どこを触ればよいかを誰も判断できなくなります。
対策として、受け入れの段階で次の3点をドキュメントとして受領しておくことをおすすめします。
- 設定の所在一覧: 前掲の4つの管理対象について、それぞれ設定がどのファイル・どの管理画面にあるかの一覧
- 現在の設定値とその理由: なぜその間隔・その回数にしたのかという判断の根拠
- 変更時の影響範囲: その値を変えると何が起きるか、変更後に何を確認すべきか
いずれも構築時にベンダー側が持っている情報であり、稼働後にゼロから調査すると相応の工数がかかります。受け入れ条件に含めておく価値のある項目です。
サービスディスカバリを保守契約と運用体制に落とし込む進め方
最後に、設計レビューのあとベンダーと詰めるべきことを、順を追って整理します。
既存構成で賄える範囲を先に確定させる
最初に確認するのは、追加の製品が本当に必要かどうかです。次の質問を順に投げると、判断材料が揃います。
- 今回の構成は、単一の Kubernetes クラスタ内で完結しますか
- クラスタの外側に連携先（仮想マシン上の既存システムなど）はありますか
- 将来的に、複数のクラスタや複数のクラウドにまたがる計画はありますか
- 上記を踏まえて、標準機能ではなく専用製品が必要な理由は何ですか
1つ目が「はい」で2つ目・3つ目が「いいえ」であれば、標準機能で足りる可能性が高くなります。この確認を先に済ませておくと、後続の責任分界の議論も対象が絞られて進めやすくなります。
保守契約で決めておく責任分界の4項目
契約の文面に落とすべき論点は、前掲の管理対象と対応します。次の4項目について、担当と手続きを明文化しておきます。
決めるべきこと | 確認する内容 |
|---|---|
レジストリの可用性 | 誰が監視し、停止したときに誰が復旧するか。復旧の目標時間は定めるか |
ヘルスチェックの定義変更 | 判定間隔・失敗回数を変更したい場合、誰の作業になるか。保守範囲内か、追加見積の対象か |
タイムアウト・リトライ方針の変更 | アプリケーション側の設定変更として扱われるか、運用調整として扱われるか |
名前解決に関わる管理 | DNS の設定や、通信の暗号化に用いる証明書の更新は誰の担当か |
特に2つ目と3つ目は、保守範囲の解釈が分かれやすい項目です。「設定変更なので保守範囲内」と考える発注側と、「アプリケーションの改修なので追加費用」と考えるベンダー側で認識がずれると、障害対応の場で調整が必要になります。稼働前に文面として合意しておくことをおすすめします。
なお、前述のとおり、クライアントサイドとサーバーサイドのどちらの方式を採るかによって、これらの項目がアプリケーション側とインフラ側のどちらに寄るかが変わります。方式が確定してから責任分界を詰めると、議論が具体的になります。
レジストリ障害時の切り戻し手順を受け入れ前に確認する
「台帳が引けなくなったら全部止まるのではないか」という懸念は、実際に検討すべき論点です。多くの構成では冗長化によってこのリスクを下げていますが、冗長化されていることと、障害時に想定どおり動くことは別の話です。
受け入れの前に、次の2点を確認しておくと安心材料になります。
- レジストリが停止した場合の挙動: 通信が即座に全断するのか、呼び出し側が保持しているキャッシュで一定時間は継続できるのか。継続できる場合、その猶予は何分程度か
- 復旧の手順: 誰が、何を見て、どの手順で復旧するのか。手順書は用意されているか
可能であれば、受け入れテストの一環として、レジストリを意図的に停止させたときの挙動を一度確認しておくことをおすすめします。挙動を把握できていれば、稼働後に同じ事象が起きたときの初動が大きく変わります。
サービスディスカバリは、接続先の管理という作業を人の手から取り上げる仕組みです。その分だけ運用は軽くなりますが、代わりに「台帳を保守する」という新しい仕事が生まれます。この仕事の担い手を、稼働前に決めておく。それが、構成図に描かれたブロックを自社の運用体制へ落とし込むということです。設計レビューで質問しきれなかった箇所があれば、本記事で挙げた確認項目をそのまま持ち込んでみてください。
稼働後の保守体制や責任分界の整理を進めている方に向けて、保守の引き継ぎ時に確認すべき項目をまとめた「失敗しないためのシステム保守の引継ぎチェックリスト」をご用意しています。ベンダーとの体制協議の前に、確認漏れがないかの点検にお使いいただけます。
失敗しないためのシステム保守の引継ぎチェックリスト
この資料でわかること
システム保守会社の変更を検討中の方が、引継ぎ作業で見落としがちなポイントを網羅した実践的なチェックリストです。
こんな方におすすめです
- 現在の保守会社のサービスに不満を感じている方
- 保守会社の変更を検討しているが、何から始めればよいか分からない方
- 引継ぎ作業でトラブルを避けたい方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 見積書にConsulなどの専用レジストリ導入費が計上されていましたが、ベンダーの説明に納得できません。どう指摘すればよいですか？
「単一クラスタで完結するか」「クラスタ外の資産と連携するか」「複数クラウド・複数環境をまたぐか」のどれに該当するのかを、構成図上の具体的な箇所を指して説明してもらうよう求めてください。該当箇所を明確に指せない場合は、標準機能への切り替えでコストを見直せる余地があります。
- 保守契約に責任分界の4項目を明記しましたが、実際の障害が複数の項目にまたがって起きた場合はどう対応すればよいですか？
ヘルスチェックの閾値とタイムアウト・リトライ方針は連動して調整が必要になることが多く、1つの障害が複数項目にまたがるのは珍しくありません。契約には項目ごとの担当に加えて、複数項目にまたがる場合の一次窓口（多くは構築を担当したベンダー）を定めておくと、障害対応時に担当のなすり合いが起きにくくなります。
- ベンダーから「アプリケーション側の問題です」と説明された場合、発注側はその説明の妥当性をどう確認すればよいですか？
第1層（呼び出し先自体）・第2層（台帳の遅れ・残留）・第3層（レジストリ本体）のうち、どの層まで確認した上での結論かを尋ねてください。第2層・第3層を確認せずに第1層だけで「アプリケーションの問題」と結論づけている場合は、切り分けが不十分な可能性があります。
- デプロイ直後だけ一時的にエラーが増える現象が繰り返し起きる場合、ヘルスチェックの間隔設定を疑うべき目安はありますか？
毎回のデプロイ直後、数十秒程度の短い時間帯に集中してエラーが発生し、それ以外の時間帯では再現しないというパターンが続く場合は、ヘルスチェックの判定間隔・失敗回数の閾値が実態に対して緩い可能性があります。閾値そのものより先に、直近でデプロイ頻度やインスタンスの起動時間が変わっていないかもあわせて確認すると、原因の切り分けが早まります。
- 受け入れ時に設定の所在一覧などのドキュメントを求めても、ベンダーから「そのような資料はない」と言われた場合はどうすればよいですか？
フォーマット化された資料がなくても、情報自体は構築担当者の記憶やメモに残っていることが多いため、ヒアリング形式で聞き取りながら発注側で一覧化する方法があります。受け入れ完了の条件にこの聞き取りセッションの実施を明記しておくと、担当者の離任後に情報が失われるリスクを下げられます。
