MEGAZONEブログ
![Observe and react:Correlating data to improve system reliability](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-26.png)
Observe and react:Correlating data to improve system reliability
観察し、対応する:システム信頼性向上のためのデータ相関
Pulisher : Managed & Support Center キム・ソンド
Description : AWSサービスに対するシステム信頼性を向上させることができるモニタリング案についてのセッション
はじめに
金融業界におけるシステムの動作、性能、運用コストに対するモニタリングシステムは非常に重要です。
ダッシュボードを使用してリアルタイムでモニタリングし、事前に問題を解決することができます。
EKSおよびEC2を含むAWSサービスに対するシステムの信頼性を向上させることができる方策について聞きたいと思い、セッションを申し込みました。
セッションの概要紹介
モニタリングを行う上で様々な段階を通じてデータ収集、可視化、相関関係を把握した後、セッションを開始しました。
課題
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-1-16-1024x768.png)
顧客がどのような問題があるかを把握し、これに基づいて問題を解決できるプラットフォームを構築することが非常に重要です。現在もモニタリングに対する大規模な構築が必要ですが、ここでは3つの主な理由により困難を抱えています。
1.複雑性(Complexity)
2.サイロ (Silos)
3.手動プロセス (Manual Processes)
一つ目は複雑性です。
ユーザーが多くなるにつれ、サービスが複雑になり、分散され、様々なシステムやコンポーネントの面で緩い結合(Loosely Coupled)で実行するのに多くの時間がかかります。
アプリケーションの側面について考えてみると、マイクロサービス、分散システム、コンテナ、信頼性及び伝達ネットワーク、各依存性に基づいたインフラストラクチャの流れ、そしてこの全てがうまく構成されなければなりません。
そのため、すべての顧客が悩んでいる内容の一つは、この拡張されたシステム全体で問題をどのように把握するかということです。
二つ目はサイロ(Silo)です。
顧客は、数多くの組織で数多くの異なるツールを使用することに苦労しています。
様々なチームそしてアプリケーションによって異なるデータを収集することになり、最終的にアプリケーション全体の観点から何が起こっているのか全体的に確認することができなくなります。
三つ目は手動プロセス(Manual Processes)です。
現在、一般的な顧客は細分化された分散アプリケーションでシステムを使用中であり、問題が発生した後にこれを警告する「対応的警告」に依存しています。
AWSのネイティブモニタリングとオープンソースマネジメントサービス
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-2-16-1024x768.png)
AWSは顧客の選択を尊重するとして、左側のAWSネイティブモニタリングとオープンソース管理サービスに大きく分けて説明してくれました。
CloudWatchの場合
1.AWSを使う場合、すでに全てのサービスと統合されており、幅広いサービスを利用することができます。
2.基本的に70以上のサービスで使用が可能で、別途設定をしなくても基本的に統合されており、Cloudwatchでメトリックが自動的に保存されるという大きなメリットがあります。
オープンソースの場合
1.Kubernetesを多く使う顧客が多く使用します。
2.ハイブリッドアーキテクチャで運営する顧客が使用できます。
3.必要なデータだけを収集し、カスタマイズして活用することができます。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-3-16-1024x768.png)
全てはデータから始まります。時間間隔に応じて測定されたデータポイントの時系列のメトリック、トラッキングなどを収集します。
一番良いログは、離散型メトリックのタイムスタンプが押された不変の記録(Time Stamp)です。
このようなデータを中心に意思決定ができるように、最も重要なデータを収集していることを確認する必要があります。
アラームと自動化
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-4-16-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-5-16-1024x768.png)
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-6-14.png)
ユーザーがアプリケーションが遅くなったことを確認した時、メトリックとTrace間の相互接続を通じて遅い箇所がどこなのか把握し、性能改善が必要な箇所を見つけることができます。
例えば、メトリックでCPUが急増することを発見した時、Traceを使わずに何があったのか確認してMetricを確認することができますが、多くの時間を消費することになります。
1.Collect + Centralizer
Traceはすぐに使えるわけではなく、アプリケーションに少しのエンジニアリングが必要です。
そうすると、追跡IDを使用することができ、アプリケーションの最初から最後まで相関関係を確認することができます。情報を収集するツールはCloudwatch Agent、ADOTがあり、ソースはEC2、EKS、ECS、Lambdaなどがあります。
2.Visualization + Correlate
CLoudwatch, X-Ray, AMP(Amazon Managed Prometheus), Open Searchでデータを一箇所に集めることができます。集めたデータをCloudwatch, AMG(Amazon Managed Grafana, Open SearchでVisualizationすることができます。
3.Alert + Automate
集めたデータをEvent BridgeとSNSを利用したり、Emailでユーザーに伝達することができます。
また、すべてのアラームを自動化することの重要性を強調しました。
![](https://www.hyperbilling.jp/wp-content/uploads/2024/01/pasted-image-0-7-11-1024x768.png)
セッションを終えて
Chalk Talkの最初のセッションでしたが、発表者と観客のコミュニケーションが多く、質問の時間が多く、一般的なセッションより参考になりました。