[レポート] 可観測性を構築して復元力を高める #AWSreInvent #COP343

re:Invent 2023 で行われた BreakOut セッション Building observability to increase resiliency (COP343) に参加したのでレポートいたします。

ざっくり概要

可観測性を効果的に使用することは、回復力のあるシステムが計画どおりに動作することを証明するために不可欠。適切に適用された可観測性は、顧客に影響を与える前に問題の初期の兆候を発見し、影響を軽減するために迅速に対応するのに役立ちます。

このセッションでは、可観測性のベストプラクティスを使用して AWS の復元体制を改善する方法が学ぶことができ、実際の障害状況を深く掘り下げ、インスツルメンテーションと可観測性ツールの適切な組み合わせを使用して障害を迅速に解決する方法を確認します。

observability （可観測性）とは？

• システムの動作状況を把握できている状態
• システム運用において、判断に必要な情報が取得できている状態

オンデマンド動画

印象的だったセッション内容

可観測性を活用して、水面下で問題が発生していることを知る方法を考えるパートがありました。
シチュエーションは、お客様が商品をカートに入れて注文したりする Web サイトでショッピングカートの Web ページで問題が起こっているとして、お客様から注文ができないと言われる前に気が付くにはどの様な可観測性データが必要か説明してくれました。

Web サイトでショッピングカートの Web ページで問題が発生

例えば Web サイトのエラーレートを確認するメトリクスを使用して、閾値を設定していた場合、ショッピングカートの Web ページで問題が発生していても警告してくれないでしょう。

特定の Web ページ異常に気が付けない

では、 Web サイト内をドリルダウンしてエラーがサイトの一部だけで発生していることを確認するにはどうすれば良いでしょうか？それには、次元性を考慮（Considering dimensionality）した可観測性を使用します。

"Show me [metric] per [dimension]”

metric には観測内容 レイテンシー リクエスト エラー
dimension には観測次元 Web サイト Web ページ

Web サイトを測定、アラームを設定しても特定の Web ページ の問題に気が付くことができませんが

Web ページを測定、アラームを設定するこで

特定の Web ページ異常に気が付ける

しかし、このような設定で Web サイト全体で問題が発生した場合、多くの Web ページからアラームが届くことになるので、それはそれで不快になります。

このアラームの疲労を軽減するために使用できるツールとして CloudWatch Composite alarms があります。
各 Web ページを測定したアラーム設定を全て取り込み、条件を設定することで騒がしくないアラームを作成することができます。

CloudWatch Composite alarms とは？

すでに作成されているアラーム（子アラーム）の状態を監視対象にできるアラームです。その監視対象のアラームは複数指定でき、様々なルール式を設定できます。

更に原因を特定するにはどうすれば良いのか？

ショッピングカートの Web ページで問題があることが分かったとして、その理由はまだわかりません。
これを追跡する方法はどうしたらよいか？ Web サイトの特定の部分に問題があることを確認する方法が必要です。その答えは AWS X-Ray でトレースすることです。

AWS X-Ray とは？

アプリケーションへのリクエストに関するデータを収集するマネージドサービス、アプリケーションレイヤを対象としてレスポンスタイムやレスポンスステータスなどの情報を収集可能

トレースの仕組み

フロントドアにあたるシステム（ALB）にリクエストが入るたびにトレース ID と呼ばれるランダムな一意の識別子がスタンプされます。

トレース ID は次のシステムにバトンの様に渡されながらログが記録され AWS X-Ray に集約されます。

それらをつなぎ合わせてアーキテクチャ全体を視覚化することができます。 AWS X-Ray トレースを使用する CloudWatch ServiceLens map です。

CloudWatch ServiceLens とは？

X-Ray、CloudWatch Logs、CloudWatch Metrics などの各種サービスに散っていた情報（トレース、ログ、メトリクスなど）を、1 か所に統合して表示してくれるサービス

更にドリルダウンして問題の原因を調べる方法

このサービスにどのような問題が発生したのか調べる方法について考えてみましょう。
ALB 配下に 3 AZ 全体で 9 台の EC2 インスタンス上で稼働する Web サーバ群が存在するとします。
例えば 1 台の EC2 インスタンス上の Web サーバプロセスがメモリー不足でクラッシュがした場合、ALB のヘルスチェックが設定されていればヘルスチェックが実行され他の Web サーバにリクエストを送信し始めます。そのため、一瞬エラーレートが上昇するかもしれませんがほんの一瞬で誰も気にしません。

しかし、1 台のホストがクラッシュするのでは無く、一部の製品サービスとの通信で障害があり、他の製品サービスとの通信が可能な奇妙な状態 Gray failure ではどうなるでしょうか。

ヘルスチェックでは全ての障害状態を列挙することはできない

では、どこに障害があるかを理解するには、どうすればよいか？ここでも可観測性を使用できます。

インスタンス ID 毎に測定

問題があるインスタンスを特定できそうだが...

しかし、インスタンス ID 毎に測定、アラームを設定すると多くのアラームが届くことになる。では CloudWatch Composite alarms で全てのインスタンスに個別のアラームを纏めるれば良いのか？
いいえ、インスタンスが増える毎にアラームを設定する必要があったり、もう少し良い方法があります。
それは、CloudWatch Metrics Insights を使用して 最も失敗したインスタンスをクエリする方法です。

CloudWatch Metrics Insights とは？

CloudWatch Metrics に対して実行可能な SQL ベースのクエリエンジン

クエリの内容は、最も失敗したトップ 10 を教えて下さい。そして、最も失敗しているインスタンスが 2 分間に 1 %以上失敗している場合はアラームするものです。

スマートに問題のあるインスタンスを特定できた

CloudWatch Metrics Insights query and alarm がどの様な見えるか

まとめ

Observability と聞いて可観測性？という状態でしたが、実際に発生しそうな障害状況を聞きながら、どの様な次元で測定していけば問題箇所の特定、原因を迅速に把握することが可能なのかイメージが湧きました。
Observabilityについてもとても興味が湧く内容でしたのでセッション内で出てきたサービスについて深堀していきます。