読者です 読者をやめる 読者になる 読者になる

2012.10.22AWS米東部リージョンで発生した障害から考えたまとめ、メモ

2012/11/3クラウド東京で話した内容です。

はじめに

クラウド事業者の提供するサービス数・機能数の増加が、単位あたりの障害率の低減以上である場合(多くの場合は上回るはずと考える)、増加するコード量・運用工数から、障害の全体数は増えると考えるのが妥当です。発生する障害の71%が保守・運用工程であるという調査結果(※重要インフラ情報システム信頼性研究会報告書p.45)もあり、今回のAWSの障害が保守工程の作業を起因にして(顕在化した原因は複数ある。後述)いることから、今後クラウドサービスを利用するうえで重要な参考となると考えました。重要なことは障害が発生した回数ではなく、発生した際に自分が運用するアプリケーションにおよぶ影響を最小化する方法であり、その点でも今回発生した内容とその対策がオープンにされていることは非常に有用であると考えます。当日発生した内容を考慮したうえで「事前にすべきこと」「障害時にすべきこと」の2点を考えたいと思います。

参照文献

※情報の精査には必ず原文にあたること

前提

  • 障害報告でチェックするポイント(一般的な品質管理が分かっている方はその範囲で)
    • 直接原因・間接原因
    • 暫定対応内容
    • 根本的な問題の調査完了までのリードタイム
    • 本格対策内容
    • 強化対策内容
    • 影響範囲
    • 上記各工程で利用者ができたこと★★★

報告内容

2012/10/14-20の週

  • 内部管理用のデータ収集サーバ、個々のEBSサーバ
    • データ収集サーバをリプレースしたが、内部DNSに対する新サーバのアドレス設定を間違えてしまった。
    • この時点から障害発覚時まで、内部DNS設定作業の間違いに気づかなかった。
    • この時点から障害発覚時まで、データ収集エージェントプロセスがメモリリークしていた。
    • この時点から障害発覚時まで、データ収集エージェントプロセスがメモリリークしていたことに気づかなかった。

10.22当日(以下全てPDT:太平洋夏時間)

  • EBSサーバ
    • 時系列
      • AM10:00 EBSサーバにおけるスタック(要求が処理できない、固まった状態)の発生を検知、スタック状態のEBSサーバがフェイルオーバーを開始した。
      • AM11:00 フェイルオーバー先の健全なEBSがなくなり、多数のEBSがスタック状態のままに陥った。
      • AM11:10 フェイルオーバー率を調整することで、サービスの負荷が軽減された。 ←なぜ軽減したかは未記載
      • AM11:35 多数のボリュームが復旧をはじめた。
      • PM 1:40 復旧完了
      • PM 3:10 根本原因(メモリリーク)を特定、エージェントのメモリを解放した。 ←どうやったかは未記載
      • PM 4:15 ほぼ全てのEBSサーバが回復した。
    • 暫定対応および本格対策、強化対策
      • (本格)データ収集エージェントのメモリリークバグの修正
      • (本格)EBSサーバーのシステムメモリの監視プログラムの修正
      • (強化)優先度の低いプロセスのリソース制限プログラムのリリース
      • (強化)内部DNSの変更伝播の信頼性向上のための設定変更(変更失敗の際の検知が早まる)
      • (強化)EBSサーバーのフェイルオーバーロジックの修正
      • (強化)EBSサーバーのメモリリーク検出プログラムのリリース
  • EC2とEBSのAPI
    • 時系列
      • 事象発生直後から、APIの使用に数時間かかってるとカスタマーから報告が多数上がった。
      • スロットル(攻撃者に対して制限をかける)ポリシーが積極的な設定であり、同時間帯にAPIを使用したカスタマーを攻撃者と判定して制限がかかった。
      • PM 2:33 制限レベルを大幅に緩和した。
    • 暫定対応および本格対策、強化対策
      • (本格)過度なスロットルポリシーの緩和
      • (強化)スロットルポリシーの適用手順の変更
  • RDS(シングルAZ構成の場合)
    • 時系列
      • 事象発生直後からアクセスしづらくなり、最終的にはデータベースが動作しなくなった。
      • PM 1:30 EBSの復旧とともに多くのインスタンスの処理性能が回復した。
      • PM 3:30 大多数の処理性能が回復した。
      • PM 6:35 ほぼ全てのインスタンスの処理性能が回復した。
    • 暫定対応および本格対策、強化対策
      • なし
  • RDS(マルチAZ構成の場合)
    • 時系列
      • 事象発生直後、プライマリが該当AZにあったものはスタンバイ側にフェイルオーバーした。ただし数%が2つのバグによりフェイルオーバーしなかった
      • AM11:30 数%のうち、不整合が起きてないものは手動でフェイルオーバーした※数%の残りはどうだったか未記載だが、Single-AZ同様にEBSの回復に合わせて復旧したと思われる。
    • 暫定対応および本格対策、強化対策
      • (本格)I/Oスタック状態でフェイルオーバーがされない障害の修正。
      • (本格)マスター側に障害がある際に、スタンバイ側が即時マスターに昇格するように修正。※「非同期レプリケーションにおいて、プライマリ側がスタンバイ側に未適用な更新ログがある状態でスタック状態になった場合が問題であり、「同期レプリケーションに変更する=全体性能的に不可能」「トランザクションのコミット時から、スタンバイ側へのログの転送までの時間にスタック状態になることを100%回避できるか」という点でかなり難しい問題であり、本当にこの対策で大丈夫かどうか判断しかねます。
  • ELB(シングルAZ構成の場合)
    • 時系列
      • 事象発生直後からアクセスしづらくなり、最終的にはロードバランサー機能が完全に失われた。
      • 追加のEBSボリュームの準備ができたものは早めに回復し、それ以外はEBSの復旧とともに回復した。
      • PM 1:10 大半が復旧完了。
      • PM 3:30 大多数が回復 ※ただしEIPの枯渇により一部の復旧が遅延。
      • PM9:50 EIP不足が解消された。
    • 暫定対応および本格対策、強化対策
      • (強化)EIPキャパシティの確保
      • (強化)EBSとELBの依存性低減のための修正
  • ELB(マルチAZ構成の場合)
    • 時系列
      • 事象発生直後、障害AZのスタック状態になっているEBSを利用しているロードバランサーインスタンスやEC2にトラフィックを流れたトラフィックはエラーになったはずである。
      • AM11:49 ほとんどのELBから障害AZが切り離された。ただしトラフィック切替プログラムにバグがあり、一部障害AZにトラフィックをルートし続けた
      • PM12:45 修正を完了した。
    • 暫定対応および本格対策、強化対策
      • (強化)ELBの回復時間短縮のためのリカバリーワークフロー修正
      • (本格)ELBトラフィック切替プログラムのバグ修正、トラフィック切替プロセスの感度向上。※将来的にはトラフィック切替プログラムのAPIを公開予定

ユーザがすべきこと

  • 事前にすべきこと
    • Amazon CloudWatchや、それをラップした運用管理システム、あるいはDeep Healthチェックパターンなどによるアプリケーションの状態監視プログラムの設計・実装、およびアラート運用(アラートの実装、発生時の運用マニュアル)の構築。
    • AWS Service Health Dashboard (http://status.aws.amazon.com/) の監視・アラート運用プログラム
    • マルチAZ構成を考慮する。
    • 回答時間などを考慮した適切なレベルのAWSサポート(http://aws.amazon.com/jp/premiumsupport/)の締結。
  • 発生時にすべきこと
    • 影響範囲の特定・切り分け
    • AWSサポートとの連携
    • AWSサポート、その他TIPSに基づくワークアラウンドの適用


サービス品質に対する根本的なアプローチについては、オンプレミス環境であってもクラウド環境であっても特に違いはないですが、ディテールについては、事業者によってどのように情報が公開されるか、どのようなサポートが用意されているか、コミュニティはどこにあるか、障害対応のTIPSはあるか、身近な有識者は誰か、などを収集しておくとイザというときに素早く対応ができると思います。また、情報収集を能動的に行うことで、影響範囲を最小化できることが期待されますが、インフラが事業者の管理化にある以上、本質的な対策について利用者側が施すことはできません。障害が発生しても可能な限り影響範囲が最小化されるような設計をすることが現状でのベストプラクティスかと思われます。

上記内容については現状の私の認識ですが、考慮不足な点が多々あることと思われます。うちではこんなこともしているよというお話があれば、Twitter(@yoshidashingo)やFacebook(吉田真吾)ないしクラウド東京のメール(cloudken.tokyo at gmail.com)までご連絡いただければ幸いです。