分析木曜日の米国のインターネットサービスはウクライナやロシアのものよりはるかに安定していたが、それでも問題の報告が浮上した。
リアルタイムのデータ分析とともに個人によるサービス停止を追跡している DownDetector.com は、少なくとも一部のネットユーザーに対して、UTC 1700 頃に Amazon Web Services の接続問題を反映した急増を示したことを明らかにした。
しかし、今週の火曜日に数人が同様に DownDetector で AWS が一時的に利用できなくなったと苦情を述べたときと同様に、Amazon の広報担当者は今日、AWS は問題なく利用できていると主張した。
「AWSのサービスに問題はないことを確認できます」と、Amazonの広報担当者はThe Register紙に語った。インターネット大手の同社は、火曜日と木曜日に障害は発生していないと述べ、「今週はサービスに関する事象は1件も発生していません」と付け加えた。
AWS ステータス ページから、最近のイベントは記録されておらず、リストされているすべてのサービスに、通常の操作を示す緑色のチェック アイコンが表示されていることを確認できます。
木曜日、AWSの可用性に関するネットユーザーからのDownDetectorへの苦情が急増
では、問題発生の報告と、問題は存在しないという主張をどうすり合わせればいいのだろうか？AmazonはDownDetector.comのデータは信頼できないと考えている。DownDetector.comを所有するOoklaのCTO、ルーク・デリックス氏は、火曜日の障害は広範囲に及ばなかったものの、「一部のAWSユーザーがプラットフォームに問題を抱えているという信頼できる報告が少数あった」と述べたと報じられている。
一体何が起こっているのでしょうか？これは意味論の問題なのか、それとも規模の問題なのでしょうか？インターネットはあまりにも精巧なので、目に見えない根本的な原因による一時的な小さな障害については、説明も認識も不要なのでしょうか？
HTTP Toolkit を開発する Tim Perry 氏は最近、AWS、GitHub、Slack の公式ステータスがこれらのサービスのユーザーの体験と異なる場合に強調表示するステータス ページを作成しました。
この記事の投稿時点では、AWSのステータスページではすべて正常と報告されているにもかかわらず、このページでは「多くのユーザーから問題が報告されている」と表示されていました。stop.lying.cloudなど、同様の取り組みはこれまでにも行われてきました。
「もちろん、サービス停止は不便だが、どんな主要サービスでも避けられない。いずれどこかが壊れることになる。これらは、大量利用による圧力を受け、複雑かつ絶えず変化するシステムなのだ」とペリー氏はザ・レジスター紙に語った。
しかし、ステータスページの状況はさらに苛立たしいものです。ステータスページが現実と合致しないのはよくあることです。Slack、GitHub、AWSといった大手ITサービスでは、ステータスページの更新が遅れることが常套句になっているため、私はstatuspagestatuspage.comを作成しました。
- 英国の規制当局は、金融サービス部門のクラウドへの依存に対応して、クラウドの耐性を精査する。
- Facebookは、致命的なネットワーク構成エラーを見逃したバグのある監査コードによって意気消沈した
- IPv6が主流になるまでには5～10年かかるが、K8sネットワークとマルチクラウドは現実のものとなった。
ペリー氏は、downdector.com のような小規模なサイトは AWS に何らかの問題が発生していることをある程度は把握できるのに、AWS はそれができないというのは不合理だと述べた。
「公開されたステータスは、企業顧客との契約上のSLA（サービスレベル契約）と、サービスプロバイダーに対する契約上の金銭的ペナルティに結びついているのではないかと強く疑っています」とペリー氏は述べた。「これらのSLAは、もちろん積極的にステータスを更新する意欲を削ぐ要因となりますが、さらに悪いことに、問題検出のための多くの有益な改善策を阻害し、この問題を完全に解決することに繋がるのです。」
「ダウンタイムの兆候を公表することは、財務上、大きな直接的な影響を与えるため、自動異常検出とレポート、クラウドソーシングによるレポートは利用できず、すべてを社内で結果を承認できる上級の人物による手動確認のスピードで実行する必要があります。」
ペリー氏は GitHub のステータス ページを例に挙げ、以前はパフォーマンス、1 秒あたりの障害数、最近の閲覧回数などの他の指標に関する自動統計を表示していたと指摘しました。
「それは数年前に削除され、一連のサービスについては単純に手動で制御される赤、黄、緑のステータスに簡素化されましたが、これは確実に現実から遅れています」と彼は語った。
カーテンの裏側
AWSは現状の報告において、本来あるべきほど率直ではないというペリー氏の主張には、ある程度の裏付けがある。2017年のHacker Newsへの投稿で、インフラエンジニアのニック・ハムリッチ氏は、2015年にAWSのElastic Beanstalkチームでソフトウェアエンジニアとして働いていた時の経験を述べている。
「私がAWSチームにいた頃、ステータスページに『グリーンではない』ステータスを投稿するのは、実際にはマネージャーの判断でした」と彼は書いている。「つまり、それは決してリアルタイムではなく、マネージャーがそれほど大きな問題ではないと判断したために、実際にはそうではないのに『すべて正常』とステータスに表示されることもあり得るのです。」
「また、緑色のアイコンに小さな『i』の吹き出しが付いた『green-i』というステータスがあります。何か深刻な問題が発生した場合はほぼ必ず、ステータスは『green-i』でした。これは、警告の『レベル』は最終的にはマネージャーの判断に委ねられるためです。そのため、黄色や赤の表示は可能な限り避けています。そのため、ステータスはあまり正確ではありません。とはいえ、AWSで黄色や赤のステータスが表示された場合は、状況が本当に悪いと分かります。」
ハムリッチ氏は電子メールで、 The Registerへの投稿の正確性を主張した。
「SLA 回避が原因でしょうか? おそらくそうでしょうが、そうだとしても間接的です」と彼は言いました。
「実際、これは2つの側面から説明できます。まず、ページの作成は自動化されたものではなく、人間の判断によるものです。次に、マネージャーは良い印象を与えたいと考えています。AWSは巨大な組織であり、『停止回数』はチームを評価する上でおそらく最適な『指標』でしょう。」
さらに深い疑問は、なぜそのページが自動化されていないのか、ということだと彼は言う。
「Amazonはオンコールチームの対応が十分迅速だと想定しているからかもしれません。SLAが低いことを知ったからかもしれません。それは分かりませんし、証明するのも難しいです。とはいえ、SLA回避はそれほど大きな要因ではないと思います。なぜなら、大企業は返金を求めればほぼ確実に返金してもらえるからです。それほど多くの証明は必要ありません。」
クラウドサービスコンサルタント会社、ダックビル・グループのチーフクラウドエコノミスト、コーリー・クイン氏は、AWS ステータスページには 2 つの問題があると The Registerに語った。
「まず、これは何の役にも立たない『緑の点の海』で、何の役に立つ情報も提供してくれません。それが私が作った stop.lying.cloud です」と彼は述べ、このサービスは AWS のステータス ページから不要な情報を取り除き、深刻度を上げて現実をより正確に反映するものだと説明した。
それはただの「緑の点の海」であり、何の役に立つ情報も提供しない。
第二に、ハイパースケールクラウドプロバイダーの規模を理解するのは難しいです。バージニア州のUS-East-1は、複数の町にまたがる約100棟の建物で構成されていますが、6つのアベイラビリティゾーンとして表現されています。建物全体がインターネットから切断されると、一部の顧客はサービスが爆発的にダウンするのを目にしますが、他の顧客は全く異常に気づきません。問題は「AWSはダウンしているのか？」ではなく、「現時点でどの程度ダウンしているのか？」です。
大規模システムでは、必ず何かが壊れます。こうした故障にも耐えられる、耐久性と信頼性に優れたシステムを構築することが、まさにこのゲームの真髄です。コミュニケーション上の課題は、自分の環境で利用しているサービスがダウンした際に、緑色の点が山のように表示されることで、苛立ちを募らせることです。逆に、もし発生したすべての障害をステータスページに表示していたら、同じように役に立たないどころか、はるかに不安を掻き立てる赤色の点が山のように表示されるでしょう。
クイン氏は、Slack が以前は非常に詳細な障害データを提供していたことを指摘し、過剰な透明性の問題点を説明した。その後、ロイターは、そのデータを Slack の安定性を疑問視する記事の根拠として使用している。
彼はまた、SLAの遵守は、AWSのステータスページに反映されていない問題を人々が認識する理由としては妥当ではないと主張した。企業は自社の稼働率指標にアクセスでき、基本的にすべてがうまく機能することを望んでいると彼は述べた。
「SLAクレジットは企業にとって実質的に無意味だ」と彼は述べた。「ほとんどの企業にとって、失われたビジネス機会を埋め合わせるには十分な金額ではない」
クイン氏によると、AWSは顧客にとってステータスデータをより有意義なものにするために、アカウントごとに「パーソナルヘルスダッシュボード」を提供してきたという。このダッシュボードは、現在のサービス状況をより詳細に把握できる。しかし、ログインが必要で顧客ごとに異なるため、あまり知られていないという。
失われたビジネスチャンスを回復させるにはお金が足りない
パフォーマンス監視サービスの存在は、クラウドプロバイダーが常に現状を把握しているわけではないことを示唆しています。クラウド企業が全てを完全に正確に報告していれば、サービスの可用性とSLA遵守を検証するためにサードパーティのサービスを介する必要はなくなるでしょう。
たとえば、監視サービスの Ably は、ステータス ページで「Amazon AWS は完全に嘘をついている」と主張しています。
マネージドITサービスプロバイダーExterNetworksのマネージングディレクター、マリク・ザカリア氏は、この問題をより外交的な言葉で説明した。
The Registerとの電話インタビューで、同氏は「顧客と話をする際、SLA 契約が確実に満たされるようにするために、SLA 監視とコンプライアンス監視が必要です」と語った。
サービス停止が発生しても報告されない場合があり、契約に基づき当社がその解決を支援します。しかし、99.99%の確率で、合意した時間内にサービスを復旧できます、と彼は言いました。
ザカリア氏は、全体的にシステムは非常にうまく機能しており、クラウドプロバイダーのサポートスタッフは非常に優秀で24時間体制で働いていると述べた。
The Registerは、AWSステータスページに対する疑惑について、Amazonの広報担当者に長時間インタビューした。Amazonは、SLAに関する懸念がステータスレポートに影響を与えるという見解に異議を唱え、ISPやネットワーク層プロバイダーに関連するサービス中断を反映している可能性のあるクラウドソーシングによるレポートの正確性に疑問を呈した。
「AWS の可用性について推測するサードパーティは、ほとんどの場合、間違っています」と Amazon の広報担当者は語った。
今週、ダウンディテクターは「AWSプラットフォーム上で広範囲にわたるサービス障害が発生したとは考えていない」と述べ、自らの虚偽報告を撤回しました。AWSサービスヘルスダッシュボード（SHD）は、AWSの可用性データに関する唯一の信頼できる情報源であり、AWSのサービスとリージョンに関するタイムリーで正確な情報を顧客に提供しています。
「これは当社のサービスレベル契約（SLA）とは一切関係ありません。当社のSHDは、他のどのクラウドプロバイダーよりも詳細なサービス可用性情報と透明性を提供します。」®
ブートノート
AWSがホスティングするHerokuは、木曜日の17時（UTC）頃、部分的な障害に見舞われました。これは、DownDetectorでAWSに対する苦情が急増したのとほぼ同時刻です。HerokuとAmazonのクラウドを利用するRustプログラミング言語のCrates.ioも、インフラプロバイダーの問題を理由に、17時（UTC）に一時的にダウンしました。
