精読「マイクロサービスアーキテクチャ 第2版」(第二部 実装 - 第10章 監視から可観測性へ)
マイクロサービスアーキテクチャ 第2版
マイクロサービスの設計、実装、運用に必要なベストプラクティスや最新技術を解説した、実践的なガイドブックです。これを読めば、マイクロサービスに関してそれっぽい会話もできますよ。
関連記事
断絶、パニック、混乱
マイクロサービスは複数のサービス間で連携するため、問題発生時の原因特定がモノリシックアーキテクチャに比べて格段に難しくなる。複数の監視対象やログ、ネットワーク遅延などが絡み合う中、システム全体を理解するには次の手順が必要
- 各サービスを個別に監視し、全体像を集約する。
- データを分析できるツールを活用する。
- 本番環境でのテストを通じて、システムの正常性を学ぶ。
単一マイクロサービス、単一サーバ
単一のマイクロサービスを単一ホストで運用する場合、ホストのリソース情報（CPUやメモリの状態）、サービスのログ、アプリケーションの外部監視（応答時間や正常性チェック）を監視し、問題の検出・修正を行う
単一マイクロサービス、複数サーバ
複数サーバで単一のマイクロサービスを運用する場合、以下が重要
- 監視: 各ホストと全体のCPU使用率やメトリクスを追跡し、異常があればアラートを設定する。データを集約して分析可能にする。
- ログ管理: ログを一元管理し、異常を効率的に特定。初期段階ではSSHツールで対応可能だが、スケールするにつれ限界がある。
- 応答時間: ロードバランサとマイクロサービスの応答時間を追跡し、ボトルネックを特定。
- 正常性確認: 異常なノードを排除するロードバランサ設定と、正常なサービス基準の定義が必要。
段階的に管理を高度化し、スケーラビリティを確保することが求められる
複数マイクロサービス、複数サーバ
複数のマイクロサービスが複数サーバで連携するシステムでは、以下が重要
- 情報の集約: 各ホストやサービスのメトリクスやログを一元管理し、効率的にエラーを特定。
- エラーの追跡: 複数ホスト間の呼び出しチェーンを可視化し、深層の問題を特定する仕組みが必要。
- データ分析: 膨大なデータから必要な情報を調査・理解する方法の整備。
- 可観測性の導入: 静的な監視から動的な本番環境テストや可観測性へのシフトが必要。
これらにより、システムの全体像を把握し、複雑な問題の解決が可能になる
可観測性と監視の違い
-
可観測性
システムの外部出力から内部状態を把握できる度合いを指し、システム全体を理解するための特性。可観測性が高いと、未知の問題や新しい質問への対応が容易になる。 -
監視
システムの状態を把握するための活動。従来の監視は特定の問題に対するアラート設定が中心だったが、分散システムでは想定外の問題が発生するため限界がある。
監視は活動、可観測性はシステムの特性と位置づけられ、両者を組み合わせることで効率的な問題解決が可能になる。
可観測性の柱？あまり高速ではない
可観測性は「メトリック」「ロギング」「分散トレーシング」の3つの柱で説明されるが、この単純なモデルには限界がある。可観測性はシステムの特性であり、ツールや手法に依存しすぎず、システムの状態を深く理解することが重要。多様な方法で情報を収集し、状況に応じて最適なアプローチを選ぶべき
可観測性の構成要素
システムの可観測性を向上させるためには、ユーザの満足度や問題の早期発見、問題解決後の原因分析と再発防止策を把握することが必要。これを実現するために、システムアーキテクチャにおけるさまざまな構成要素を取り入れることが重要。
ログ集約
この部分は、マイクロサービスアーキテクチャにおけるログ集約の重要性と、その実装方法について主要なポイントは以下
-
ログ集約の必要性
マイクロサービスアーキテクチャでは、複数のサーバやインスタンスが存在し、それぞれがログを生成する。これを個別に管理するのは非効率的であり、専用のログ集約ツールを使用して、ログを一元管理する必要がある。ログ集約は、システムの問題を診断するための重要なメカニズムであり、問題が発生した場合に迅速に状況を把握するために不可欠。 -
ログ集約ツールの概要
ログは、マイクロサービスのプロセスがローカルファイルシステムに記録した後、定期的に収集され、運用担当者がクエリできるストアに転送される。このプロセスにおいて、コード変更なしでログを収集できることが理想的であり、ログの転送プロセスや障害モードに関して理解しておくことが重要。 -
ログのフォーマット
ログファイルの標準化された形式を選ぶことが重要。例えば、日付や時刻、マイクロサービス名、ログレベルなどを一貫性のある方法で記録し、後でクエリしやすい形式にする必要がある。JSON形式など、構造化されたログ形式が推奨され、これにより後で情報を抽出しやすくなる。 -
相関IDの利用
複数のサービスが連携して動作する場合、一つのリクエストが複数のサービス呼び出しを生成することがある。この場合、各サービス間のログを関連付けて追跡するための「相関ID」が重要。相関IDを用いることで、問題が発生した際にエラーの起源を特定しやすくなる。 -
ログ集約の実装の重要性:
ログ集約ツールの実装は、マイクロサービスアーキテクチャを成功させるための前提条件と考えられる。ログ集約が適切に行われていない場合、他のシステムの複雑さに対応するのは難しくなるため、まず最初にログ集約を実装し、その後のシステム構築を進めることが推奨される。
メトリック集約
システムのメトリック収集・分析には、「何を良いとするか」「いつ対処するか」を理解するため、システム動作のデータを継続的に収集する必要がある。複雑な環境では、新しいホストやサービスからも効率的にメトリックを収集する仕組みが求められる。
また、短期的な対応用の高解像度データと、長期的な分析用の集約データを併用し、コストと応答性を最適化する。ただし、集約データでは詳細情報が失われるため、保存時に注意が必要。
特に、高カーディナリティデータ（多様なタグや属性を持つデータ）は、多くの時系列データベースで課題となる。従来型の低カーディナリティシステム（例: Prometheus）はシンプルなクエリには適している一方、複雑な質問や高カーディナリティデータの扱いには制限がある。
複雑なシステムほど、可観測性向上のため、広範なデータ収集と分析可能なツールが必要。これにより、コスト効率や応答性を向上させ、システムの最適な運用が可能となる。
分散トレーシング
分散トレーシングは、マイクロサービス間の呼び出しや依存関係を可視化し、システムの動作や問題を分析する手法。各プロセスや操作（スパン）を追跡し、全体のトレースを構築する。OpenTelemetryなどのAPIを活用することで、効率的なデータ収集や分析が可能です。適切なサンプリングとツール（JaegerやHoneycombなど）の選択により、システムのパフォーマンス監視や障害解析を効果的に行える。
うまくいってるか
システム運用の判断基準として、単に「稼働しているか」ではなく、全体の健全性を評価する必要がある。分散システムでは、サービスの可用性や応答時間などを指標（SLI）として定義し、目標（SLO）を設定することで、サービスの正常性を測る。また、エラーバジェットを活用し、許容範囲内の不具合で変更のリスクを管理する方法も有効。これらの考え方は、SRE（Site Reliability Engineering）に基づく
アラート
-
アラートの目的
アラートは問題解決のための迅速な通知手段だが、運用者が対応すべき問題とタイミングを正確に伝える必要がある。 -
優先順位の明確化
- 全ての問題が同じではない。
- 「この問題で午前3時に誰かを起こすべきか？」を基準に重要度を評価する。
- 日常対応で済む問題と緊急対応が必要な問題を区別する。
-
アラート疲れの回避
- 不要なアラートの氾濫は、運用者を混乱させ、重大な問題の見落としにつながる。
- 優先度付けやアラート削減で集中力を維持する。
-
設計の教訓
- Googleはハードドライブの故障を想定した設計で日常対応を容易にした。
- セーフティクリティカルなシステムでは、アラートが運用者に適切な行動を促す設計が不可欠。
アラート設計は、運用者が適切な判断と行動を取れるよう、通知内容・タイミング・優先度を徹底的に吟味する必要がある
セマンティック監視
セマンティック監視では、システムが「期待通りに振る舞っているか」を問うアプローチが取られる。システムが正しく動作しているかどうかを判断するためには、まずセマンティックモデルを定義する。このモデルは、システムがどのような状態で正常であるとみなされるかを示すもので、たとえば新規顧客の登録や売上金額の基準などを設定する。次に、実際のシステムの振る舞いをこのモデルと比較して評価する。
実ユーザ監視（RUM）は、実際のユーザ行動を監視し、システムが期待通りに動作しているかを調べるが、タイムリーな情報取得やノイズが多いという課題がある。合成トランザクションは、問題をユーザが気づく前に検出できる利点がありますが、こちらも本番環境でのテストの一環として活用される。
本番環境でのテスト
本番環境でのテストは、実際のシステムが予期しない方法で動作する可能性があるため、慎重に実施する必要がある。しかし、適切な方法で本番環境テストを行うことは、システムの健全性を確保するために非常に重要。
テスト方法として以下のものがある
-
合成トランザクション
本番環境において、ユーザの動作を模倣することでシステムの動作を監視する。これにより、ユーザが気付く前に問題を検出することができる。合成トランザクションを実施することで、低レベルのメトリックだけでは見逃す可能性のあるシステムの問題を早期に発見できる。 -
A/Bテスト
異なるバージョンの機能を比較することで、どちらが効果的かを確認する。例えば、顧客登録フォームの2つのバージョンを比較して、どちらがより多くのユーザを登録させるかを調べる。 -
カナリアリリース
新機能を小規模なユーザーグループに対してリリースし、機能が問題なく動作するかを確認する。問題が発生した場合には、影響を最小限に抑えることができる。 -
並列実行
2つの異なる実装を並行して実行し、ユーザーのリクエストに対する反応を比較する。これにより、異なる実装のパフォーマンスや安定性を評価できる。 -
スモークテスト
本番環境にデプロイしたソフトウェアが基本的な機能を問題なく実行できるかを確認する。これは通常自動化され、システム全体が稼働していることを確認する基本的な手順です。 -
カオスエンジニアリング
システムに意図的に障害を発生させ、システムがその障害に適切に対応できるかを確認する。例えば、NetflixのChaos Monkeyのように、本番環境の一部を停止させ、システムがその影響を吸収できるかをテストする。
これらの方法を組み合わせて、システムが本番環境でも安定して動作することを確保できる。しかし、テストの実施においては、予期しない副作用を避けるために慎重な準備と監視が必要。
標準化
システム全体の標準化には、狭い範囲で判断を下す部分と全体を統一する部分のバランスを取ることが重要。特に、監視や可観測性の分野では標準化が重要であり、マイクロサービス間の連携や複数のインターフェースを管理するために、システム全体を俯瞰する必要がある。ログは標準形式で記録し、メトリックも統一された名前で管理すべき。これにより、異なるサービス間での整合性が保たれ、管理が容易になる。標準化をサポートするツールやプラットフォームも重要で、これらはプラットフォームチームの責任範囲となることが多い。
ツールの選択
可観測性向上には、さまざまなツールが必要ですが、急速に進化しているため、将来的には現在のツールとは異なるものが必要になる可能性がある。ツール選定の基準としては、使いやすさ、大衆性、統合のしやすさ、コンテキスト提供、リアルタイム情報取得、スケーラビリティが重要。また、ツールは自社の規模に合ったものを選び、コストパフォーマンスを考慮する必要がある
マシン内の専門家
システムの異常を自動で検出するために機械学習や人工知能の技術が注目されているが、完全な自動化には懐疑的。専門知識を完全に自動化する考え方にはリスクがあり、問題解決にはまだ人間の専門家が必要。
実際、データサイエンスや監視ツールにおいても、異常を検出するツールはあっても、何をするべきかの判断は依然として専門知識を持つ人に依存する。したがって、ツールは運用担当者の判断を支援するものであり、完全な自動化には限界があるという立場を取っている。
開始する
マイクロサービスアーキテクチャを効果的に監視・可観測化するための基本的な出発点について、以下のポイントが挙げられる
-
基本情報の収集
マイクロサービスが動作するホストの基本情報（CPU使用率、入出力など）を取得し、サービスインスタンスとホストを関連付ける。 -
応答時間とログ記録
各サービスインターフェースの応答時間を追跡し、下流呼び出しのログを記録する。相関IDをログに追加し、ビジネスプロセスの主要ステップも記録する。 -
ツールの選定
基本的なメトリック・ログ集約ツールを使用し、可能であればフルマネージドサービスを利用してマイクロサービスのインストルメント化を行う。 -
合成トランザクション
システムの重要な部分が適切に機能しているかを理解するために合成トランザクションを作成することを検討する。
さらに、システムの稼働状況を継続的に調査し、収集した情報を活用してシステムの可観測性を向上させる必要があると強調している。
まとめ
分散システムの理解とトラブルシューティングの重要性が強調されている。分散システムが複雑になるにつれて、本番環境での問題解決が難しくなり、システムの可観測性を高める必要性が増す。
-
能動的な可観測性の向上
受動的な監視から能動的なシステム分析へと移行し、静的なダッシュボードから動的な分析活動に切り替える必要がある。 -
基本的なログ収集と相関ID
シンプルなシステムでも、最初からログ集約を行い、相関IDを取得することで進歩が得られる。 -
微妙な違いを認識する
システムの状態を単純な「満足」や「残念」から、より複雑な理解に切り替えることが重要。 -
アラート疲れの軽減
SLO（Service Level Objectives）やアラートの導入を検討し、注意を絞り込むことでアラート疲れを防ぐ。 -
未知の事実を受け入れる
本番環境に進む前に、未知の問題が存在することを認識し、適切に対処する姿勢を持つ。
最後に、可観測性やSLOに関するさらに詳しい資料として、「Observability Engineering」や「Site Reliability Engineering」を推奨しているが、Googleの方法論に基づいているため、自分の環境に適用する際には注意が必要
参考
Discussion