SRE導入において「モニタリング」は欠かせない要素のひとつです。モニタリングは、システムを可視化するために行うものであり、常にシステムの健康状態を把握し、問題が何か起こったときにサービスの健全性を判定・診断するうえで中核となる機能です。
本記事では、SREの中核を担うモニタリングの必要性とその戦略について解説していきます。どのようにモニタリングを行えばよいか悩んでいる担当者の方はぜひ最後までお付き合いください。
モニタリングの必要性と目的
システムをモニタリングする必要性や目的は多くありますが、以下がSRE担当者が活用する一般的なモニタリング項目になります。
- アラート
- それらの問題と調査と診断
- システムに関する情報を可視化
- 長期的なトレンド分析
- システムのふるまいの比較（軸は実験、変更前後、時間など）
モニタリングを行う流れは「収集→分析→可視化」というのが一般的な流れです。まずはアラートによりシステムの破損もしくは破損する可能性があることを検知し、通知を受けます。システムが自身で問題を自動解決できない場合は人間が受け取ったアラートをもとに、調査及び診断を行い、必要に応じて問題の解決に取り掛かります。
アラートを出す際、「何かがおかしい」「エラーが発生した」というような抽象的なアラートの発し方は避けるようにしましょう。抽象度の高いアラートが多量に発生すれば無駄な労力を割いてしまったり、アラートの重要性（価値）自体が下がってしまう恐れもあります。
システムに関する情報の可視化は次項に示す4大シグナルを基本とした情報をもとにダッシュボードを構築し管理します。
そのほか、長期的なトレンドの分析やシステムのふるまい比較をする際にモニタリングを活用するケースもあります。システムアップデート前後で「振る舞いが異なる」「一部の処理でエラーを吐いている」、テスト的に「どちらのクエリの方が早いか比較する」といったケースでもモニタリングは活用されます。
もちろん、上記で挙げている全てを必ずやらなければならないということは無く、システムの規模や運用体制におけるモニタリングの重要性などを考慮して取捨選択すると良いでしょう。
また、あくまで「ユーザー視点での監視」が重要であることは忘れないようにしましょう。アプリケーションの実装の詳細についてはユーザーは気にしません。ユーザーは「アプリケーションが動いているかどうか」という点のみ気にするということを忘れないという事も、モニタリングを設計するうえで重要な要素となります。
※『入門 監視』２章 監視のデザインパターン参照
モニタリング戦略における必要な4つのシグナル
モニタリングシステムの選択で重要なことは、「重要なことを理解し優先順位を付けること」です。ここからは、モニタリングにおける4大シグナルについて解説します。
レイテンシ
レイテンシは分かりやすく言うと「応答速度」です。リクエスト処理をしてからレスポンスが返ってくるまでに要する時間のことを指し、ユーザーの満足度に繋がる要因のひとつとなります。注意すべき点は、リクエストに対して「成功したレイテンシ」と「失敗したレイテンシ」を分けて考えるべきであるという点です。成功したレイテンシに比べ、HTTP500などの失敗したレイテンシは、きわめて早いレスポンスで返されるためです。成功と失敗のレイテンシを分けてモニタリングすることではじめて正しいレイテンシの管理ができると言えます。
トラフィック
トラフィックはシステムに対するリクエストの量を表します。Webサービスを扱う場合は基本的に毎秒のHTTPリクエスト数で計測します。トラフィック数を監視する際は、「静的コンテンツのトラフィック数」「動的コンテンツのトラフィック数」といったように、トラフィックの内訳ごとに分けて管理するのが望ましいです。
エラー
エラーは、処理に失敗したリクエストレートを指します。失敗にはHTTP500などの「明示的な失敗」とHTTP200などの「暗黙的な失敗」、そして約束したレスポンスタイムを超えてしまうといった「ポリシーに関する失敗」が存在します。エラーを検知する際のプロトコルコードは内容の判別を行うには不十分なため、より詳細な状況を把握するためにはより深い内部のプロトコルを必要とする場合もあります。
サチュレーション
サービスの飽和状態を表すのがサチュレーションです。システムは利用率が100%に近づくにつれてパフォーマンスが低下するため、許容とする利用率を予め決めて監視する必要があります。サチュレーションの具体的な対象は、システム的に制約のあるものが対象になるため、「必ずコレ」といったものはありません。メモリに制約があれば「メモリの利用率」、I/Oに制約があるのであれば「I/Oの利用率」といったように判断するようにしましょう。
モニタリングのデータソース
モニタリングには、メトリクス、ログ、トレース、イントロスペクションなど多くの種類が存在します。本章ではGoogleがSREの最も基礎的かつ最適なモニタリングの要求だと述べる「ログ」と「メトリクス」の2つについて触れていきます。
メトリクス
メトリクスは、様々なデータポイントから定期的に集約されたイベントや属性を示す数値の情報を示します。モニタリングのアラートやダッシュボードにメトリクスの情報を利用することで、リアルタイム性の高いアラートの通知を可能にします。
ログ
ログはイベント記録のことを指します。単純な「テキストのログ」やクエリや集計ツールに利用できる「構造化ログ」が存在します。イベントの発生からログが現れるまでに多少の遅延が発生するため、リアルタイムを追求したアラートにはあまり適していません。問題の根本解決をする際は、メトリクスだけでは情報が不十分であることが多いため、より詳細な情報を見れるログを使います。
メトリクスとログはそれぞれ上記のような特徴を持つため、お互いの利点を組み合わせ「モニタリング→問題の解決」のフローを構築すると良いでしょう。
モニタリングシステムの管理
モニタリングシステムを管理する場合、いくつか注意すべきポイントがあります。以下、3つ解説していきます。
システムの設定をコードで管理（IaC）
システムの設定をコードで管理することには明確なメリットがあります。
- 変更履歴の管理
- 変更情報から追跡システムへのリンク
- 容易なロールバック
- Lintチェック
- コードレビューの強制
システムの設定をコードで管理していなければ、上記の取り組みに相当な労力を割くことになります。コード管理をしていないがために、変更履歴が追えず、ブラックボックス化してしまうという可能性もあります。
また、コードレビューやLintチェックといったシステムの信頼性を担保する作業箇所で漏れが発生するケースもあります。
統合されたダッシュボードを準備する
モニタリングを複数のチーム単位で行うような大企業の場合、統合されたダッシュボードを準備することをおすすめします。統合されたダッシュボードを用意することで、エンジニアがチーム間を移動した際でも、違和感もなくスムーズに業務に取り掛かることができますし、チーム間での問題共有やデバッグの受け渡しも迅速に対応できるようになります。
また、エンジニアを含む企業全てのメンバーがモニタリングデータを活用することができるのは業務上、大きなメリットとなるはずです。
疎結合の優先（設定の柔軟な変更性を担保する）
柔軟な設定変更を担保するため、モニタリングシステムのコンポーネント同士の結合は緩くすることをおすすめします。数年の間で技術やサービスの成長に伴ってシステムも大きく変化を遂げることがほとんどのため、モニタリングシステム自体も柔軟に対応していく必要があるからです。ひとつのコンポーネントで全てを管理するのではなく、個々のコンポーネントへ機能を分割し管理する必要があります。
SRE導入及び戦略的なモニタリングは弊社「3shake」にお任せください
本記事ではSRE導入のモニタリング戦略の部分に注力して解説しました。ひと口にモニタリングと言っても何をどのようにモニタリングすればよいのか、難しく感じる企業様もいらっしゃるかと思います。
弊社3Shakeは企業の規模問わず多くの企業様のSRE導入のお手伝いをさせていたいております。自社のサービスの成長に際してSREの導入を検討しているという企業様がいらっしゃいましたら、ぜひ一度お気軽にお問い合わせください。
東京在住のソフトウェア開発者、Motouchi Shuyaです。
システムの開発・運用・最適化が好きです。