ベストプラクティスで現実のオブザーバビリティの課題を解決する

Pulisher : Enterprise Managed Service Group ミン・ジホ
Description : AWSのモニタリング、可視化、分析能力について、お客様に使用したユースケースを紹介したChalk Talkセッション。

はじめに

Datadog、New Relicなど様々なモニタリングツールが提供する情報のうち、コア情報を抽出し、運用ダッシュボードを作成することに興味があり、他社ではどのように観察可能性能力を向上させ、運用の卓越性を生み出すようになったのか知りたいと思い、このセッションを申し込みました。

セッションの概要紹介

お客様が直面している一般的なユースケースと課題を聞くことができます。

実際のユースケースとデプロイメントの選択肢を見て、定義された目標を達成するためにどのような意思決定が行われたか、AWSのお客様がモニタリング、可視化、分析能力を向上させ、より高い稼働時間と運用の卓越性を確保した方法についての具体的なユースケースとベストプラクティスを知ることができるセッションです。

良好な観察可能性を持つことで、大きな可視性を得ることができます。

システムが正常か異常かを知らせるだけでなく、システムが異常でない理由も教えてくれます。エンジニアがリアルタイムで問題を解決するのに役立ち、ビジネスに素晴らしい結果をもたらします。

モニタリングは、システムが停止しているか動作しているかを知らせます。

観察可能性は、システムが動作しているかどうかだけでなく、その理由も教えてくれます。

状態を確認する3つの方法は以下の通りです。

・指標
・ログ
・追跡

複数の観測可能性に関連するサービスがあります。

・Cloudwatch servicelens
・Cloudwatch agent
・AWS Managed Grafana

Cloudwatch agentはメトリック、ログ、トラッキングを収集することができます。

AWSで最初はAWS Synthetics、real user monitoring、service map、dashboard機能や、最近では機能にクロスオーバーするツールも開発してきました。 このような新しい機能とツールを開発しており、最近では機能にクロスアカウントを可能にしました。
(全アカウントに対して単一のモニタリングアカウントを持つことができるように構築します)

また、コンテナワークロードを保有している多くの顧客がいます。通常、PrometheusとGrapanaを使用してモニタリングを行います。AWSはプロメテウス、Grapanaのマネージドサービスを提供しています。

Grapanaで事前構築された様々なワークロードに対するクオリティの高いダッシュボードを構成するため、新しいダッシュボードで実際に作業する必要がなく、既存のダッシュボードをインポートすることができ、ボタンを数回クリックするだけです。

最初の実際のユースケースを見てみましょう。

ここでは、銀行の顧客が、銀行のアプリケーションについて知っている重要なJava APIを監視したいと考えています。

この顧客はクラウドを初めて利用し、アプリケーション全体をクラウドに移行しました。

そして、彼らは3つの課題に直面しています。

1つ目は、JavaベースのAPIを監視したいということです。

2つ目は、同じマトリックスコレクションのセットをインポートする必要があります。

3つ目は、規模が拡大し、拡張するため、成長に適用できる観察可能な動的なソリューションが必要です。

上記3つに対応するために、

AWS移行時にAWS CloudWatchの基本指標を提供し、追加設定によりアプリケーション、システム、Windows、OSを運営するすべてのログを収集することができます。

ログ、指標、追跡データを収集してメトリックインサイト、ログインサイト、ダッシュボード作成、アカウント間観察のようなクラウド監視機能を使用すると、簡単に観察可能性を向上させることができます。 また、複数のサーバーを管理するためにログ設定収集と設定をいちいちしなければならない手間を減らすために、parameter storeとsystem managerを通じてagent配布を自動化します。

ビジネス成長を吸収するためにマイクロサービスを採用した後の迅速なインシデント対応事例です。マイクロサービスについてモニタリングを行いましたが、そのメトリックを確認するのに膨大な時間がかかり、顧客はトラブル時間を短縮したいと考えています。

このような時にトラッキングを使います。ログの全ての部分を確認して探すのではなく、トラッキングを通じて、どのログが問題なのかを確認し、トラブルシューティングに役立ちます。

さらに踏み込んで、コンテナ内のワークロードは停止しましたが、コンテナ内には多くの名前空間があります。

トラブルシューティングの時間で、コンテナ内のワークロードが何を実行しているのか、どの部分を実行しているのかを詳しく知ることができるように処理する可能性がないことを知っています。

これをAWSではAWS Cloudwatch、Container Insights、Lambda Insightで解消することができます。

上記のサービスは、より集計され、より詳細で、より改善された指標を提供します。また、AWSではプロメテウス、Grapanaなどのオープンソース管理サービスに多くの時間を投資しました。

3つ目の課題は、M&A後に既存のワークロードを一元化されたオブザーバビリティに統合するケースです。オンプレミスからAWSに移行する場合、既存の運用担当者にDevOpsのトレーニングを行う必要があります。 1つのオブザーバビリティプラットフォームを持つことで、企業はすべての情報を見つけたり、情報をつなぎ合わせる方法についてチームを接続したり、トレーニングを行う必要がないというメリットがあります。

セッションを終えて

モニタリングデータはたくさんありますが、観察する可能性があるかどうかは考えたことがありませんでした。 これからモニタリングを設定する際には、多くのデータをモニタリングすることも大切ですが、よりこのモニタリング設定をする際に、このモニタリングデータについて自分自身がどれだけ知っているのかを改めて考えながら作業しなければならないと感じました。