大規模サービスにおける カスケード障害

イベント詳細: https://mixi.connpass.com/event/347532/

Transcript

1. 2025年4⽉3⽇ 春のSREまつり 〜 ⼤規模サービス "あるある" との戦い事例 〜 ⼤規模サービスにおける カスケード障害
2. About Me ogady | Takumi Ogawa（@_ogady_） • 株式会社エウレカ ◦ 2021年にSREとして⼊社 ▪ 現在はSRE & Data Platform Team Manager
3. Agenda 1. ⼀般的なカスケード障害について 2. カスケード障害との付き合い⽅ 3. ペアーズで発⽣したカスケード障害事例
4. 1. カスケード障害とは
5. カスケード障害とは “カスケード障害は、ポジティブフィードバックの結果として、時間と共に拡 ⼤していく障害のことです。カスケード障害は、システムの⼀部に障害が発 ⽣したことによってシステムの他の部分にも障害が発⽣する確率が⾼まる場 合に⽣じます。例えば、あるサービスのレプリカの⼀つに過負荷による障害 が発⽣すると、残りのレプリカの負荷も⾼まり、その結果障害が発⽣する確 率が上がります。そしてドミノ効果が引き起こされ、サービスの全レプリカ がダウンすることになりうるのです。” 引⽤: Mike Ulrich (2017). 22章 カスケード障害への対応(). In B. Beyer, C. Jones, J. Petoff, & N. R. Murphy (編),SRE サイトリライアビリ ティエンジニアリング ― Googleの信頼性を⽀えるエンジニアリングチーム (澤⽥ 武男ほか訳). オライリー‧ジャパン. • 1つのコンポーネントの障害が他のコンポーネントに連鎖的に波及する障害 • よくマイクロサービス⽂脈で語られるが、複数のコンポーネントが組み合わさればモノリスなシ ステムでも起こりうる • 最初は⼩さな問題でも、連鎖的に⼤規模な障害につながる
6. カスケード障害が発⽣しやすい条件 • ⾼い相互依存性を持つシステム ◦ マイクロサービスアーキテクチャなど、複数のサービスが依存関係を持つ構成 ◦ 依存関係が複雑で可視化されていないとよりリスクが⾼まる • リソース上限に近い負荷状態 ◦ CPU、メモリ、ネットワークなどのリソースが逼迫している状態 ◦ 余裕がない状態では⼩さな変化でも⼤きな影響が出やすい • 単⼀障害点の存在 ◦ 複数のサービスが共通で利⽤するコンポーネントがボトルネックになりやすい ◦ キャッシュサーバー、データベース、認証サービスなど
7. カスケード障害のよくある原因 • リソース枯渇 • 依存先サービスの障害、不具合 • 過剰なリトライ • 予期しないフェールオーバー これらは、カスケード障害発⽣の起点となりうるが、複合することもある。 例：起点はリソース枯渇で、それにより過剰なリトライが発⽣して最終的には同じ事象の障害に発展 するケースなど
8. カスケード障害の⼀般的なパターン • リソース枯渇 ◦ メモリ、CPU、接続数、ネットワーク帯域などのリソースが枯渇して連鎖 ◦ 例：リクエスト数の増加 → DB接続数のlimit到達 → CPUスレッド数増加 → CPU負荷増
9. • 依存先サービスの障害、不具合 ◦ あるサービスのバグ、応答遅延などが他サービスのリソース占有などを引き起こし連鎖 ◦ 例：認証基盤の応答遅延→呼び出し元のスレッド数増加→システム全体がスローダウン カスケード障害の⼀般的なパターン
10. カスケード障害の⼀般的なパターン • 過剰なリトライ ◦ 障害発⽣時に⼤量のリトライが発⽣し、さらに負荷を⾼める ◦ 例：コンポーネントの瞬断→クライアントが⼤量に同時リトライ→サービスがさらに過負 荷状態に
11. カスケード障害の⼀般的なパターン • 意図しないフェイルオーバー ◦ フェールオーバーなどでトラフィックや負荷が別のノードなどに⼀気に切り替わること で、集中過負荷が発⽣ ◦ 例: データセンターA障害→トラフィックがデータセンターBへ→Bのサーバ群が過負荷→ 全体停⽌
12. 2. カスケード障害との付き合い方
13. 設計段階での対策 • サーキットブレーカーパターン ◦ 障害検知時にネットワークを切断して障害の連鎖を防ぐ仕組みの導⼊ • バルクヘッドパターン ◦ リソースを最初から分離する（顧客単位、展開地域単位など）設計。 障害の影響範囲を限定できる • グレースフルデグラデーション ◦ ⼀部の機能が利⽤できなくなっても、コアとなる機能は動作するような設計 • リトライ戦略とバックオフ ◦ 指数関数的バックオフ、ジッター追加など
14. インシデント発⽣時の対応 • トラフィックシェーピング ◦ 重要なトラフィックを優先し、不要なリクエストを制限 ◦ レート制限、優先度に基づくキューイングなど • ⼀部機能の⼀時的無効化 ◦ 負荷の⾼い機能やコンポーネントを⼀時的に無効化 • メンテナンスモードの活⽤ ◦ ユーザーへの適切な通知をもとに、サービスをメンテナンス状態にする
15. 3. ペアーズで発⽣したカスケード障害事例
16. ペアーズのざっくりアーキテクチャ • Hosting: Amazon EKS on EC2 • API/Batch: Go • DB ◦ Amazon Aurora MySQL ◦ Amazon DynamoDB • cache: Amazon Elasticache for Redis • monitoring：Datadog
17. ペアーズのカスケード障害事例 まずはじめに、⼤量のエラーlogが観測された。 この時点で、通常時とは全く異なる状況 level: error msg: sql - Error 1213 (40001): Deadlock found when trying to get lock; try restarting transaction level: error msg: sql - Error 1205 (HY000): Lock wait timeout exceeded; try restarting transaction level: error msg:　ERR max number of clients + cluster connections reached MySQL Deadlock MySQL Timeout go-redis max clients
18. ペアーズのカスケード障害事例 ⼤量のアラート通知
19. • Aurora（MySQL） ◦ Deadlock ▪ 増加 ◦ Timeout Exceeded ▪ 増加 ◦ コネクション数 ▪ masterが増加 • Pod（API container） ◦ CPU負荷増 ペアーズのカスケード障害事例: 各コンポーネントで発⽣していた現象 • ALB ◦ Request数は普段通り • Elasticache for Redis ◦ アプリケーションのRedisClientの max client error ◦ 特定シャードの負荷上昇 この時点で原因が全くわからず、⼀時的にサービスをメンテナンス状態に切り替え
20. ペアーズのカスケード障害事例 何が起きたのか
21. ペアーズのカスケード障害事例 発端
22. ペアーズのカスケード障害事例: 前提情報 • Elasticache for Redis（以降Redisと表記） ◦ クラスターモードで運⽤ ◦ インスタンスタイプ（障害発⽣当時）：cache.r5.xlarge i. ベースライン帯域幅：1.25 Gbps ii. バースト帯域幅：最⼤10 Gbps（ベストエフォート） • Redis Client接続の挙動 ◦ 読み取り操作(GET)：Shard内の全ノードに分散 ◦ 書き込み操作(SET)：プライマリノードのみ 参考：AWS Doc（https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/CacheNodes.SupportedTypes.html）
23. ペアーズのカスケード障害事例: メトリクスからの推察 特定のポップアップ配信処理で、配信対象のリストを1つのKey:ValueとしてRedisに保持していた。 ユーザーがアプリケーションを開くたびに配信対象かどうかをRedis問い合わせで判定する仕組み。 このような状況で障害時には下記の事象が発⽣したと考えられる。 1. ⼤量の配信対象情報が特定のシャードに保存された(数MBほどの⼤きなデータ) 2. Redisの当該シャードへのアクセス集中 ◦ アプリからのFirst ViewのAPIリクエストがこのキーを参照するため 3. Redisで当該シャードの各NodeがPrimary→Replicaの順でネットワーク帯域幅の制限に到達 ◦ この時、メトリクス上は最⼤帯域幅に達していなかったが、バーストはベストエフォート なので、常に保証されるわけではない 4. 当該シャードのパフォーマンスが著しく低下 Big Key問題 + Hot Key問題の合わせ技
24. ペアーズのカスケード障害事例: 障害時のメトリクス 事象発⽣時のElasticache for Redisのメトリクス Network In 緑: Average Gbps ⾚: NetworkBandwidthInAllowanceExceeded(集計帯域 幅がインスタンスの最⼤値を超えたためにキューまたは ドロップされたパケットの数) Network Out 緑: Average Gbps ⾚: NetworkBandwidthOutAllowanceExceeded(集計帯域 幅がインスタンスの最⼤値を超えたためにキューまたは ドロップされたパケットの数) Connections 緑: ConnectionCount ⾚: NetworkConntrackAllowanceExceeded(接続トラッキ ングがインスタンスの最⼤数を超え、新しい接続を確⽴ できなかったためにドロップされたパケットの数) 障害発⽣ Primary帯域逼迫 配信開始
25. 続けて下記のように障害が波及していったと考えられる。 1. Redisレイテンシー悪化 →Redisコネクション作成増加 2. APIが作成するRedisクライアントコネクション数の上限到達 3. コネクション作成待ちのためTimeoutが多発し、リトライ数増加 4. Redisを使⽤するエンドポイントの待ち時間が増加し、Transactionの⻑時間化→DB DeadLockや Timeoutの多発 5. Goのスレッド数が増加しサービス全体のCPU負荷がオートスケールが間に合わない速度で上昇 6. アプリケーション全体への障害波及 ペアーズのカスケード障害事例: 他コンポーネントへの波及
26. 恒久対応策 • 負荷分散の仕組み導⼊ ◦ リストではなくユーザー単位でキーを作成し、Big Key + Hot Keyとならないように修正 ◦ ⼀部データをRedisではなくインメモリに移⾏ • ⼀部機能の⼀時的無効化機能を整備 ◦ 配信機能のみをサービス停⽌する機能を作成 • 設計段階でのDesign Docレビューを強化 • ⼤規模配信の取り扱いルール整備 ◦ ⼤規模配信の運⽤ドキュメント整備 ◦ 配信のタイミングに関する注意喚起
27. ⼤規模だとちょっとした考慮不⾜が命取りに... データサイズ • ユーザーを多く抱えるサービスであるが故に、条件次第では配信対象リストのサイズが⼤きく なるケースがある ◦ 配信対象ユーザー数を絞った配信では特に問題は発⽣していなかった トラフィック量 • 通常トラフィックでは特に問題は発⽣せず、ピークタイムに近づくにつれ徐々に帯域幅が圧迫 されるため、配信開始時点では問題があることに気づきづらい ペアーズのピークタイム※のトラフィック量だと、cacheするデータサイズをケアしないと帯域幅を 容易に圧迫してしまうため、事前の設計時点でデータサイズとアクセス頻度を考慮したキャパシティ プランニングが重要 ※ ペアーズのピークタイムは⼣⽅から深夜にかけて。オフピークに⽐べ3~4倍ほどまでトラフィックが増加する
28. まとめ
29. まとめ カスケード障害は • 「⼩さな不具合」が「全体障害」へと連鎖して発⽣する障害 • 複数のコンポーネントが組み合わされたモノリスシステムでも起こりうる • 影響範囲が広いため、ミスリードされやすく原因特定が難しい ⼤規模サービスにおけるボトルネックの⾒落とし • ⾒落としがちなリソース制限の考慮 ◦ 特定キーへのアクセス集中を避ける & データサイズの考慮 • クラウドリソースの「バースト可能」の落とし⽳ ◦ ベストエフォート型のバーストなので常に保証されるわけではない
30. • SRE サイトリライアビリティエンジニアリング - O'Reilly Japan ◦ https://www.oreilly.co.jp/books/9784873117911/ • サポートされているノードの種類 - Amazon ElastiCache ◦ https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/CacheNodes.SupportedTypes.html • バルクヘッド パターン - Azure Architecture Center | Microsoft Learn ◦ https://learn.microsoft.com/ja-jp/azure/architecture/patterns/bulkhead • グレースフルデグラデーションを実装する - AWS Well-Architected フレームワーク ◦ https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/reliability-pillar/rel_mitigate_interaction_fail ure_graceful_degradation.html • ジッターを伴うタイムアウト、再試⾏、およびバックオフ ‐The Amazon Builders' Library ◦ https://aws.amazon.com/jp/builders-library/timeouts-retries-and-backoff-with-jitter/ • サーキットブレーカーパターン - AWS 規範ガイダンス ◦ https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker. html 参考資料
31. We’re hiring! ペアーズではエンジニアを積極採⽤中！ カジュアル⾯談もお待ちしております！ (X: @_ogady_)