Observability による高可用性最後の難関Gray Failureの突破と実践

© 2025, Amazon Web Services, Inc. or its affiliates. All
rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. AWS re:Invent 2024 re:Cap Observability による⾼可⽤性最後の難関 Gray Failureの突破と実践 Mitsuaki Tsugo J A W S-U G SRE 支部 # 1 1 Amazon Web Service Japan G.K. Solutions Architect

rights reserved. 2 ⾃⼰紹介津郷光明 Mitsuaki Tsugo アマゾンウェブサービスジャパンソリューションアーキテクト • 製造業のお客様を中⼼にご⽀援しています。 • Observability / IaC x GenAI が最近のテーマ

rights reserved. AWS re:Invent 2024 イベント概要 • AWSによるクラウドコンピューティングに関する世界最⼤規模の「学習型」カンファレンス • 2024/12/2 ~ 6 の 5 ⽇間 • 基調講演、AWSエキスパートによる特定トピックのInnovation Talks、多数のブレイクアウトセッションなど、様々なコンテンツを提供 • re:Play Party などの ”Fun”イベントも各種開催参加者: 6 万⼈ (40 万⼈がオンラインで参加）

rights reserved.

rights reserved. 6 Gray Failureの定義と特徴 Gray Failure（グレー障害）とは、 • 完全な障害ではなく、部分的または断続的に発⽣する微妙な問題 • 通常の障害と異なり、検出が難しく、システムの信頼性に⼤きな影響を与える

rights reserved. Gray Failureの具体例（セッションから） • ⾼いディスクレイテンシ • ⾼いネットワークレイテンシ • ノイジーネイバー問題障害とは判断されないが、ユーザー体験に影響を与える可能性が⾼い Gray Failureをいかに早く検知・対処するかがサービスの信頼性に直結する

rights reserved. 8 ⾼い可⽤性がもとめられたら︖

rights reserved. アーキテクチャ⾼可⽤性の実現に向けたアプローチ観測対処予防

rights reserved.

rights reserved. Stripeが取り組んだアプローチ • セルベースアーキテクチャ • カオステストとフォールトインジェクション • 継続的デリバリーとリトライメカニズム • グレー障害（Gray Failure）への対応

rights reserved. 14 ⾼可⽤性へのアプローチ（Stripeの例）⾼い可⽤性を実現するために必要な2つのサイクルアーキテクチャ観測対処予防カオステスト・フォールトインジェクション Gray Failureへの対応セルベースアーキテクチャリトライメカニズム

rights reserved. アーキテクチャオブザーバビリティが可⽤性向上の基本まずはここから取り組む観測対処予防

rights reserved. Stripeが取り組んだアプローチ • セルベースアーキテクチャ • カオステストとフォールトインジェクション • 継続的デリバリーとリトライメカニズム • グレー障害（Gray Failure）への対応

rights reserved. Stripeが実施したGray Failure対策 1. EBSの詳細なメトリクス収集 • データベースストレージをシンプル化・⾼速化のためAmazon EBSに移⾏ • CloudWatchを利⽤した詳細なメトリクスの収集・監視 • IOPS/スループット制限到達を⽰すメトリクス • ボリューム故障の可能性を通知するメトリクスなど 2. 異常検知システムの構築 • リクエストレイテンシーを指標として異常検知を実施 • 他のノードと⽐較して異常なレイテンシーを⽰すノードをトラフィックから除外 3. ⾃動修復システムの構築 • 「機械にやらせるべき仕事を⼈にさせない」という原則 • データベースのプライマリノード⾃動切り替え

rights reserved. アーキテクチャどう実装するか︖ 観測対処予防

rights reserved. Auto-scaling and serverless 監視の集約分析・トラブルシュート Amazon CloudWatch A W S のリソース、アプリケーション、オンプレミスのモニタリングサービス⽣成 AI を利⽤した状況把握・運⽤改善⾃動アクション

rights reserved. CloudWatch Application Signals によるスパンの可視化 • 従来の X-Ray だと • ベストエフォートでのトレース取得 • リクエスト全ての調査を⾏う場合コストが⾼額になる • 実現すること • すべてのトランザクションスパンを構造化されたログとして⼤規模に取り込み、ログとして分析可能 § Lambda で構築されたサーバーレスアプリケーションのパフォーマンスも簡単に監視可能 § 新しい料⾦体系も発表済み全てのスパンを利⽤してサービス間の通信に関する詳細な調査が可能に re:Invent 2024 update

rights reserved. 21 CloudWatch Logs と OpenSearch が Zero-ETL 統合 CloudWatch へのインサイト集約と分析ツールの統⼀で分析の⼿間を削減 • 課題 • CloudWatch のログを慣れた OpenSearch で分析するためには ETL パイプラインの構築が必要 • 実現できること • CloudWatch Logs Insights で、OpenSearch SQL と PPL (パイプ処理⾔語) が利⽤可能に • Zero-ETL 統合によりデータをコピーせずに CloudWatch のログを OpenSearch 上で分析可能 https://docs.aws.amazon.com/ja_jp/opensearch-service/latest/developerguide/direct-query.html#direct-query-cloudwatch-logs-regions-table • 追加料⾦なし • OpenSearch から CW Logs へのダイレクトクエリをサポートしているリージョンで利⽤可能 (東京リージョン含む） re:Invent 2024 update

rights reserved. オブザーバビリティのプロセス収集実装データ加⼯保管設定⽬的別ダッシュボード原因分析相関分析事象連絡⾏動へ Gray Failureに対する取り組みでも基本的な流れに変わりはない計装収集/保管可視化分析通知

rights reserved. オブザーバビリティのプロセス Gray Failureに対する取り組みでも基本的な流れに変わりはない計装収集/保管可視化分析通知

rights reserved. 25 まずはテレメトリデータの収集から Observability Collectors and SDKs Container insights Lambda insights Contributor insights Application insights Synthetics Dashboards Alarms AWS Services Amazon CloudWatch Open source managed services Amazon Managed Grafana Third-party solutions Metrics CloudWatch agent AWS Distro for OpenTelemetry Internet monitor Logs Amazon OpenSearch Service Amazon Managed Service for Prometheus Fluent Bit RUM AWS X-Ray Amazon CloudWatch Application Signals テレメトリデータの収集無くして現状把握、分析、障害対応は不可能 • 全てのTierでログ、メトリクス、トレースを取得する • CloudWatch Agentも進化し OpenTelemetryをサポート • CloudWatch Application Signalsなど、テレメトリの収集からビルドインダッシュボードでの可視化、詳細分析がAWSに閉じて可能 • 簡単に導⼊可能なEKS add-onなども提供されている

rights reserved. CloudWatch Application Signals でレイテンシ傾向を簡単に確認 Trace Map Service 詳細サービス単位でのレイテンシ増加やリクエスト数の傾向分析が簡単に開始可能 • ビルドインダッシュボードで傾向分析やトレースの詳細確認が可能 • SLOモニタリングも具備

rights reserved. 28 EBSメトリクスによるGray Failure検出 https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-io-characteristics.html#ebs-io-metrics EBSに関して重要な2つのメトリクス 1. VolumeStalledIOCheck - 名前空間：EBS - 過去 1 分間にボリュームの IO チェックに合格したか失敗したかを 0 (合格) または 1 (不合格)で返す - 値が1である場合、ボリュームのI/O操作に問題が発⽣している可能性が⾼い 2. StatusCheckFailed_AttachedEBS - 名前空間：EC2 - 直近 1 分間でインスタンスがアタッチ済みの EBS ステータスチェックに成功したかどうかを 0 (合格) または 1 (失敗) で返す - 値が1である場合、インスタンスとボリューム間の接続に問題がある可能性が⾼い EBS に関する詳細なメトリクスを確認することで異常を検出可能

rights reserved. • メトリクスの過去のデータに機械学習アルゴリズムを適⽤して、メトリクスの期待値を作成。 • モデルは、メトリクスのトレンドと時間単位、⽇単位、週単位のパターンの両⽅を評価。 • アルゴリズムは最⼤ 2 週間のメトリクスデータを対象にするが、メトリクスに 2 週間のデータが含まれていない場合でも、異常検出を有効にできる。 https://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch_Anomaly_Detection.html EBS VolumeTotalReadTimeでの Anomaly Detection活⽤例通常の利⽤から逸脱していることがわかる CloudWatch Anomaly Detectionによる⾃動異常検出

rights reserved. 30 CloudWatch Contributor Insightsによる異常検出 CloudWatch Contributor Insights ruleを利⽤することでピア分析も可能 CloudWatch Alarmと連携し、⾃動的な対応アクションに繋げる { "AggregateOn": "Count", Contribution": { "Filters": [ { "Match": "$.stream", "In": [ "stderr" ] } ], "Keys": [ "$.kubernetes.pod_name ", "$. kubernetes.namespace_name", "$.kubernetes.host" ] }, "LogFormat": "JSON", "Schema": { "Name": "CloudWatchLogRule", "Version": 1 }, "LogGroupARNs": [ "arn:aws:logs:region:accountid:log-group:/group" ] } ルールの定義ピア分析︓ 同様のリソースやインスタンス間でのパフォーマンスや動作を⽐較することで異常を検出する⼿法

rights reserved. 32 複合アラームの利⽤複数のアラームを 1 つの複合アラームにまとめて、アプリケーション全体でのヘルスインジケーターを作成可能 EBSでのGray Failure検知に向けた複合アラームの例（閾値は仮値） ALARM ( EBSレイテンシ ) AND ( ALARM ( I/Oキュー⻑ ) OR ALARM ( スループット低下 ) EBSレイテンシ OR演算 AND EBSレイテンシアラーム VolumeTotalReadTime / VolumeReadOps > 20s VolumeTotalWriteTime / VolumeWriteOps > 20s I/Oキュー⻑スループット低下 OR I/Oキュー⻑アラーム VolumeQueueLength > 5 スループット低下アラーム VolumeReadBytes < 期待値の70% VolumeWriteBytes < 期待値の70%

rights reserved. ⼤切なこと最初から全てをやろうとしない（不可能）⼩さな取り組みを1つ1つ積み上げることが⼤事

rights reserved. 本セッションのまとめと提案押さえていただきたいポイント • 優れたアーキテクチャや優れた習慣だけでは不十分で、優れたオペレーションが必要（今回はObservabilityを中⼼に説明） • Gray Failureはユーザー体験に影響するが検出が難しい（⾼可⽤性への最後の壁） • 必要なメトリクスを取得し分析する • ⼩さく始め、継続的かつ段階的な改善に取り組む次のステップへの提案 • 明⽇から始められること︓テレメトリデータの収集と重要なメトリクスの特定

Observability による高可用性最後の難関Gray Failureの突破と実践

Observability による高可用性最後の難関Gray Failureの突破と実践

More Decks by Mitsuaki Tsugo

Featured

Transcript