第10章: 運用

システムを構築することは仕事の半分に過ぎません。残りの半分は、それを動作させ続けることです。運用とは、本番環境でシステムをデプロイ、モニタリング、メンテナンス、進化させる実践です。運用が困難なシステムは、どんなに設計と実装が優れていても、最終的には障害を起こします。

サービスの起動

プラネタリスケールコンピュータは、特定の順序で起動する必要がある複数のサービスで構成されています。ディスカバリサービスは、他のサービスが登録できるようになる前に利用可能でなければなりません。コンフィギュレーションサービスは次に起動すべきです。他のサービスが設定を読み取る可能性があるからです。その後、残りのサービス——ストレージ、キャッシング、モニタリング、ルーティング、およびアプリケーションサービス——は任意の順序で起動できます。成功するまでディスカバリへの登録をリトライするからです。

start.shスクリプトがこの順序をエンコードしています。各サービスをバックグラウンドプロセスとして起動し、起動を少し待ってから次に進みます。これは開発には十分ですが、本番環境には不十分です。本番ではサービスは再起動、リソース制限、依存関係の順序付けを処理するプロセススーパーバイザによって管理されるべきです。

ヘルスチェック

サービスが稼働し始めたら、運用者はそれらが健全であるかどうかを知る必要があります。実行中のプロセスは必ずしも健全なプロセスではありません——デッドロックに陥っているかもしれず、トラフィックに圧倒されているかもしれず、依存先に到達できないかもしれません。ヘルスチェックは、サービスが現在の状態を報告するための標準的な方法を提供します。

私たちのサービスは、ヘルスレポーティングにモニタリングサービスのハートビートメカニズムを使用します。各サービスは定期的にステータス付きのハートビートを送信します。モニタリングサービスはハートビートウィンドウを逃したサービスを不健全としてマークします。この情報はダッシュボードに反映されて運用者に問題を通知し、ルーティングサービスに反映されて不健全なサーバーへのトラフィック送信を回避します。

オブザーバビリティ

ヘルスチェックは何かが間違っているかどうかを教えてくれます。オブザーバビリティは何が、なぜかを教えてくれます。オブザーバビリティの3つの柱は、メトリクス（時系列の数値測定）、ログ（離散的なイベント）、トレース（複数のサービスを通じたリクエストの経路）です。

モニタリングサービスがメトリクスを処理します。各サービスは任意のメトリクス値（リクエスト数、レイテンシー、エラー率）を報告でき、ローリングウィンドウに保存されます。ログについては、各サービスが標準出力に書き込み、ログ管理システムによって収集・集約できます。分散トレーシング——ディスカバリ、ルーティング、バックエンドサービスを横断する単一のリクエストの追跡——は、私たちのシステムを拡張できる領域です。

運用ランブック

午前3時に何かがうまくいかないとき、運用者は第一原理から推論する必要があってはなりません。運用ランブックは、一般的な障害シナリオとその修復手順を文書化します。私たちのシステムの主要なランブックには次のものが含まれます：ディスカバリサービスがダウンした場合（再起動する；他のサービスは自動的に再登録する）、ストレージが満杯の場合（コンパクションをトリガーするか容量を拡張する）、コンセンサスアンサンブルがクォーラムを失った場合（障害を起こしたメンバーを特定して再起動する）。

最良のランブックは、システムを構築した人々によって書かれ、運用する人々によって更新され、まだ機能することを確認するために定期的にテストされます。時間の経過とともに、最も一般的なランブックのステップは自動化され、人間の運用者の負担を軽減すべきです。