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

Slide 1

Slide 1 text

© 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

Slide 2

Slide 2 text

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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

Slide 22

Slide 22 text

© 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. © 2025, Amazon Web Services, Inc. or its affiliates. All rights reserved. Stripe の活動をヒントとした Gray Failureの対応にむけた Amazon CloudWatch の活⽤ 22

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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なども提供されている

Slide 26

Slide 26 text

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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 に関する詳細なメトリクスを確認することで異常を検出可能

Slide 29

Slide 29 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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による⾃動異常検出

Slide 30

Slide 30 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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" ] } ルールの定義ピア分析︓ 同様のリソースやインスタンス間でのパフォーマンスや動作を⽐較することで異常を検出する⼿法

Slide 31

Slide 31 text

Slide 32

Slide 32 text

© 2025, Amazon Web Services, Inc. or its affiliates. All 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%

Slide 33

Slide 33 text

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text