こんにちは、MSPの田所です。
AWS re:Invent 2024 が始まりました！
現場からイベント模様をお届けします。
セッション情報
Best practices for observability
オブザーバビリティのベストプラクティスを説明します！
Achieving comprehensive observability by ensuring optimal performance, reliability, and user experience is crucial for businesses. In this interactive chalk talk, explore best practices for collecting and analyzing metrics, traces, and logs across your AWS environments. Discover techniques for streamlining agent management, optimizing alerting, and enabling cross-account observability. Learn how to reduce operational overhead while gaining deeper visibility into your applications’ performance and health—all in a cost-optimized manner.
オブザーバビリティの実装でよくあるトラブルの相談に乗ります！
Session types: Chalk talk
1時間のチョークトーク
今回のまとめ
ベストプラクティスやよくある悩みについて様々な議論が交わされましたが、重要なポイントを 3つ選ぶなら以下であると感じました。
- ビジネスに必要な情報を集める
- 自動化に寄せる
- 改善し続ける
セッションの詳細
1. オブザーバビリティのベストプラクティス
まずは AWS のオブザーバビリティについてです。
一言でまとめるとオブザーバビリティとは、
「テレメトリーを使ってシステムの状態をフルスタックで理解する能力」
と表現できます。
また、システムもオブザーバビリティもビジネス要件に基づいていることが重要であるという説明もありました。
このことはセッション中に何度も強調されていました。
顧客目線、アプリ、インフラと、多方面からシステム状況を理解する「フルスタック」であることも、オブザーバビリティの大事な要素です。
AWS のオブザーバビリティのベストプラクティスでは、主に以下の要素を掲げています。
- ビジネス要件に沿ったデータを収集する
- メトリクス、ログ、トレースを集約、関連付けする
- 設定と監視を自動化する
- フルスタックで実装する
- リアルタイムのアラートとダッシュボードを設定する
- 継続的改善の文化を醸成する
こちらに詳しい説明が載っています。
2. 顧客目線のオブザーバビリティ
顧客目線でのオブザーバビリティについて考えます。
「ラスベガスなので、オンラインカジノのアプリを作るとしましょう」
と始まり、何が必要か意見を出していきます。
例えば、カジノは非合法の国もあるため地理的に絞る必要があり、年齢など個人情報に基づいた制御も必要になる、と認証システムの話になりました。
「この場合、カジノのアプリだけではなく認証システムもビジネスに必要です。オブザーバビリティもそれに沿って設定する必要があります」
とビジネス要件に基づく重要性が語られました。
また、CloudWatch Synthetics の機能紹介もありました。
単純な URL アクセスのレスポンスコード、ブラウザでの動作をスクリプトで検証、などの機能がありますが、API リクエストにも対応しています。
ユーザーからのリクエストはもはや大抵模倣できるようになっているようです。
3. アプリケーションのオブザーバビリティ
次にアプリのオブザーバビリティの話です。
X-Ray や RUM (Real User Monitoring), Application Signals を利用してアプリのパフォーマンスを監視することができます。
アプリに限らずですが、トラフィックが外に出た時のデータの関連付けが難しいという話があがりました。
セキュリティツールなど外部サービスを使用すると、外部で行われた処理のトレースを取ることは難しく、ラベルや分類情報の付与もハードルが上がります。
トラフィックがサービスを行き来するごとに、オブザーバビリティの実装の難易度が上がるという実例でした。
4. インフラのオブザーバビリティ
個人的には理解しやすいインフラのオブザーバビリティについてです。
主にメトリクス情報からリソース状況を把握します。
ここではクロスアカウントオブザーバビリティについての話がありました。
ベストプラクティス的には、役割の異なる機能はアカウントを分離する方が望ましいです。
例えば、アプリ実行のアカウント、データベースのアカウント、そしてモニタリング情報を集約するためのアカウントなどが考えられます。
それらを実現するために CloudWatch には、アカウントを跨いで CloudWatch の情報を共有するクロスアカウントオブザーバビリティの機能があります。
ただし、全てのデータを共有することが正ではなく、あくまでビジネス要件に基づいて必要な情報のみを共有すること、と補足がありました。
また自動化に関して、便利というよりは、当然進めていくこと、という位置付けでした。
システムが大規模になるほど、設定や管理を手作業で行う労力とリスクは増え、もはや自動化は必須になるということなのでしょう。
5. AWS の改善プロセス
最後に、運用は継続的な改善が大事であり、AWS では改善を促すような文化、プロセスがあると紹介がありました。
運用フローは定期的に見直しをかけ、もし問題が起こった場合には改善した上で学びに繋げることが大事だと言います。
MSPとして
1. そのデータはビジネスに必要か
今回、データの収集はビジネス要件に基づいて行うこと、運用は継続的に改善することを学びました。
この点、MSPとしてお客様環境を運用する際にさらに強化できる部分ではないかと思いました。
お客様環境の何のメトリクス、ログ、はたまたトレースを取るか、またその運用を定期的に改善できないか。
動きの早いこの業界でこれらを十分に達成できたら、それもまた価値になるのではないかと感じます。
2. 監視ツールで補完できる点もある
アラートの最適化やクロスアカウントオブザーバビリティの話にも触れられました。
これらを使いこなすことで、よりスマートな運用を実現できそうです。
AWS のセッション内容からは外れてしまいますが、MSPからするとサードパーティー製の監視ツールを活用することでも達成できると感じました。
マルチアカウントやマルチクラウドの運用、アラートの設定、変更、抑止などは監視ツールの得意分野。
目指す姿を実現する手段として、SaaS や OSS の活用も有効なシーンがありそうです。
おわりに
MSP部隊を抱える弊社としてはオブザーバビリティは非常にホットな話題であり、改めて重要性を思い知りました。
運用に必要な具体的なサービスを押さえることも大事ですが、オブザーバビリティを軽視しない組織の文化醸成や、運用を考慮した設計も同じくらい大事で、すなわち DevOps が昨今のテーマになっている理由を実感するのでした。
おしまい
