運用における監視・トラブルシューティング

これまで見てきたように、Azure Monitor の監視機能を階層化すると、何を確認するためにどの機能を利用するかを簡単に理解できます。一方で、実際の運用において障害が発生している場合、プラットフォームやOS、Pod単位のように個々のコンポーネントを順番に見ていく方法では、障害の検知や障害状態からの復旧に時間を要すことがあります。

例えば、OSのCPU使用率を監視し、80％を超えた場合にアラートを発報する方法では、CPU の使用率が低いもののアプリケーションに何らかの問題が起きていた場合に異常に気付くことはできません。また、アプリケーションに問題が起きていなくても、CPUの使用率が一時的に高くなっているだけでアラートが発報されてしまうと、本当にアクションの必要なアラートを見逃す可能性もあります。

AKSを効率的に運用・監視さらにトラブルシューティングを行うには、必要なアラートを必要な時に発報し、トラブルシューティングを行う際の情報を確実に取得しておくとよいでしょう。以下に、監視やトラブルシューティングのポイントをまとめます。

自己回復力を持たせる

Kubernetes には、Readiness Probe や Liveness Probe といったプローブの仕組みがあり、障害状態となっているコンテナの自動的なサービスからの切り離しや再起動が可能です。このような仕組みを利用することで、アプリケーションに問題が発生してもアラートを飛ばさずに自動的に回復させる力を持たせることができます。

迅速な障害からの復旧を可能とするために回復力を持っているアプリケーション設計、Pod の設定をします。いかに問題を起こさないか、いかに早く問題に気付くかということはもちろん重要ですが、問題が起きたときに自動的にすばやく回復する力を組み込むことも重要です。

外形監視(サービス監視)を行う

先に述べたように、CPUの使用率やメモリの使用量など、原始的なメトリックはトラブルシューティング時の手がかりや傾向を知り未然の障害防止につながる可能性はありますが、障害そのものを検知することにはあまり向いていません。システムとして見たときに正常な状態が維持できているかどうかを監視することで、異常にいち早く気付くことが可能になります。

また、この時、「正常な状態」を十分検討することが重要です。そのシステムがビジネスとして稼働している状態を維持するために、何を監視すればよいのかを考えます。

例えば、ECサイトでは商品をカートに追加できない状態は致命的な問題です。またゲーミングでは、長いロード時間はユーザー体験を損なうことになります。このような場合、メトリックとして、カート追加時の 5xx エラーの発生率やロード時間の平均値を取るとよいかもしれません。

このメトリックを決めるポイントとして「正常な状態」はそのビジネスの内容によって決まるためビジネスオーナーと合意を取ったサービスレベルをもとにして決定する必要があります。

ログの出力内容や出力先、利用方法を検討する

ログ設計を行う際、あとでログの取りこぼしを防ぐため、とりあえず取り得るすべてのログを出力・取得することを検討されるケースがあります。障害時やインシデント発生時においてログが確認できていないことにより調査ができないことは防がなければなりませんが、一方でログを管理・運用するコストも考える必要があります。

リソースのコストという観点においては、Azure Monitor(Log Analtyics)は、ログの取り込み量とデータの保存に対して課金が発生します。アプリケーションから大量のログが出力するとその取り込みの容量が増加し、Log Analytics に膨大な課金が発生することになります。

収集したログを利用して監視やトラブルシューティングをする場合においては、その大量のログから特定のイベントを見つけ出す必要があります。Log Analytics は高機能なクエリ言語持っていますが、大量のログの検索には複雑なクエリが必要になることも考えられます。

また、同じストレージにすべてのログを保存すると、運用において本来必要のないログを作業者が確認できてしまうことにもなりセキュリティ上好ましくないことも起こり得ます。

ログ設計においては、蓄積したログをどのように利用するかを定義したうえで出力するログの内容やログ出力の制御方法を検討し、必要なログを適切な方法(ストレージの種類、保存期間)で収集できるように設計する必要があります。

参考

Azure のクラウド導入フレームワークでは、監視戦略に関するドキュメントを提供しています。

クラウド監視ガイド: 監視戦略を策定する

コンテナログに関しては、v2を利用すると Basic ログへの切り替えができるためコストを抑えられる可能性があります。

ContainerLogV2 スキーマ (プレビュー) を有効にする

著者プロフィール


野村総合研究所 湯川勇太（ゆかわ ゆうた）


前職で大手家電量販店のECモールの立ち上げとECサイトの刷新プロジェクトを経験。NRI入社後は製造業の商品検索システムを担当した。現在は大手物流企業向けの基幹システムの方式設計や技術検証、トラブル対応を行っている。

Microsoft 乃村 翼 （のむら つばさ）


前職はコールセンターシステムを展開するスタートアップ企業で、Asterisk を用いたPBXシステムの構築、RailsやPHP等のOSSスタックを用いたWeb アプリケーションの開発を経験。アプリケーション基盤でLXCを使用していたことがきっかけで、コンテナ技術に興味を持つ。現在は、Microsoft CorporationのFastTrack for Azure のカスタマーエンジニアとして、Azureインフラを中心に設計・導入の支援を行っている。