EC2インスタンス、EBSボリューム、およびすべてのスナップショットの永久的な損失

「Cloudmouseはすべての仮想サーバーを削除しました」を一度読んだ後、「信頼できるクラウドを信頼しなければならなかった」というスタイルのコメントを読んだ後 、私はAmazon（AWS）から非常に尊敬されているクラウドで恐怖の物語を語ることにしました。 ラジオポッドキャストでこれについて簡単に話しましたが、ここでは、発生した悪夢全体の詳細と印象が重要なようです。



私は比較的長い間（3年以上）仕事と個人のプロジェクトにAWSを使用していますが、自分はかなり上級のユーザーだと考えています。 AWSサービスの豊富なリストから、私は仕事をするか、少なくともこの豊富さのほとんどを試してみる必要がありましたが、いくつかの基本的なサービスが間違いなく最も頻繁に使用されています。 これらは、VPC（プライベートネットワーク）のEC2（インスタンス/仮想マシン）、関連するEBS（ボリューム）、ELB（ロードバランサー）、およびRoute53（DNS）です。 この5つから、ネットワークに接続された仮想マシンのさまざまな構成を組み立てることができます。データストレージ用にこのビジネスにS3が追加された場合、これは明らかに最も人気のあるAWSサービスの小さな紳士のセットになります。



これらのシステムの信頼性は異なり、異なるSLAがシステムに付与されますが、ほとんどが非常に印象的です。 実用的な観点から、AWSに重大な問題はありませんでした。 これは、すべてが完全に中断されないことを意味するものではありませんが、合理的なユーザーがすべての卵を1つのバスケットに入れず、少なくともAZ（アクセスゾーン）間でサービスを分配する適切に編成されたシステムで、彼はすべてのまれなクラッシュや問題から多くの損失なしに抜け出すことができました最小限の頭痛で。



実際の使用で遭遇したことから、計画された再起動（「必要なホストメンテナンスのためにAmazon EC2インスタンスが再起動される予定です」）および新しい機器への計画された移行（「EC2は基礎となるハードウェア」）。 どちらの場合も、障害は発生せず、再起動後にEBS上のすべてのデータでインスタンスが使用可能になりました。 IPアドレス（Elastic IP）で数回奇妙なことが起こり、突然インスタンスが削除され、仮想マシンの1つへのルーティングが完全に失われました。 これらのケースはすべて「はい、これは起こりますが、めったにないけがをしません」のカテゴリからのものであり、私は特定の恐怖/怒りを引き起こしませんでした。明確な説明。



そして、それは起こりました。 1月26日、午後5時頃に自動的に上昇するインスタンスの1つが起動を拒否しました。 AWSコンソールから開始しようとすると、初期化状態になり、数秒後に停止状態に戻りました。 ログは作成されませんでした、なぜなら OSをロードする前に、問題は明らかに到達しませんでした。 同時に、一目で正確に何が起こったかについての説明は見つかりませんでした。 よく調べてみると、ボリュームのリストの前に疑わしいメッセージ、「内部エラー」とエラーコードが表示されています。 すべてのEBSボリュームが表示されているセクションに入った後、「レッドステート」の簡潔なメッセージと「エラー」のある死亡したインスタンスの両方のボリュームを見つけました。



それは奇妙で、不快でしたが、致命的ではありませんでした。 結局、真の妄想として、毎日、各インスタンスから各ボリュームのスナップショットを保存し、1週間から6か月間保存します。 AWSでスナ​​ップショットからボリュームを復元するのは簡単な作業です。 しかし、それは本当に奇妙で非常に恐ろしいことが判明しました-これら2つのセクションのスナップショットもすべて「エラー」に変わり、それらを使用することは不可能でした。 「すべて」と言うときは、7日間すべてが保存されたストーリー全体を意味します。 あなたのことは知りませんが、私の目を信じるのは大変でした。 私は以前にそのようなものを見たことがなく、そのようなものを聞いたことがありませんでした。 非現実的な程度で、これはパニックを引き起こすことすらありませんでした-これはコンソールの障害であり、もちろん、EBSボリュームとスナップショットの両方が同時に失われることはあり得なかったと確信しています。 結局のところ、このすべてが近くに、または突然死んだ1つのディスクアレイにさえ格納されているという理論は、このファームがどのように機能するかについての彼らの説明と矛盾します。



サポート（これは別の有料サービスです）に電話して、私はインドのテクノロジーを利用しました。 これに先立ち、サポートサービスへの私の電話はすべて地元の有能な専門家にかかっていました。 これも役に立ちましたが、非常に時間がかかりました。 正確に何が間違っているのかを説明した後、彼は15分間姿を消し、チェックのために出発しました。 時々彼は戻って、彼と専門家チームが問題を調査していると報告しました。 このような深い調査がいくつかあり、電話で彼と約1時間過ごしました。 最終結果は期待はずれでした-すべてがなくなっていました。 もちろん、私は何が起こったのかという理由の説明と完全な分析を要求しましたが、彼は私に言うことができるのは「謝罪を受け入れますが、何もすることができず、あなたのデータは消えました」でした。 「すべてを正しくやったこと、スナップショットがあったこと、どうしてこうなったのか」という質問に、彼はこれらの失われたスナップショットを保存するためのお金を返すことを申し出ました。 しかし、私は明確化を要求し続け、彼は問題が新しいタイプのインスタ（C4）の失敗に関連しており、すでに修正されていることを渋々認めました。 彼はそれがどのように接続され、何が正確に修正されたかを正確に説明しませんでしたが、完全なレポートとすべての回答を含む電子メールを送信することを約束しました。



彼らは翌日送った報告書から：

最近の整合性チェック中に、1で回復不能な破損が発見されました。

ボリュームの。 ボリュームの状態を「エラー」に変更しました。

また、これらのボリュームから作成されたスナップショットも回復不能であるため、

ステータスを「完了」から「エラー」に変更しました。請求は行われなくなります

これらのボリュームとスナップショットのために、あなたの都合でそれらを削除するかもしれません。



AMIを使用してインスタンスを起動できなくなることに注意してください

これらのスナップショットを参照します。 AMIを削除する手順については、こちらをご覧ください

（http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/deregister-ami.html）。



EBSボリュームは、信頼性のために設計されていますが、

複数の物理ドライブ、我々はまだ耐久性のリスクにさらされているとき

複数のコンポーネントの障害が発生します。 耐久性に関する期待を公開します

EBS詳細ページはこちら（http://aws.amazon.com/ebs/details）。



ご不便をおかけしましたことをおmayび申し上げます。 もしあれば

この問題に関するその他の質問やコメントは、以下までお問い合わせください。

aws.amazon.com/support 。

ここの答えは臭いがしません。 実際のエラー（「2つのボリュームがある場合は1つのボリューム」）と標準のサブスクライブ解除に加えて、ここでは何も役に立ちません。 ただし、同様の答えに我慢できず、AWSのPM（Amazonが多かれ少なかれ重い顧客にアタッチするなど）を巻き込み、災害について彼に伝えました。 私はすでに深夜に電話して、メッセージを残しました。 同時に、彼は特に言葉を選ばず、ショックの程度を隠さず、私が考えていたことを非常に明確にしました。 30分後、彼は私に電話をかけ、午前中に私と、AWSから回答があるすべての人との会話を整理するよう提案しました。



ちなみに、失敗のすべての重大度について、彼は私たちの戦闘システムに痛みを伴う結果を引き起こしませんでした。 第一に、このノードは唯一のものではなく、第二に、完全にドッキングされ、ほぼ完全に不変でした。 復元し、実際に新しいものを構築するのに10分かかりました。コンテナの起動と管理に必要なすべてをロールバックし、必要なすべてのコンテナを配信して起動しました。 このインスタンスは1日の終わりのデータ処理システムの一部であるため、一意のデータはなく、外部の場所から作業するために必要なすべてのものが必要でした。 ただし、本当に重要で一意のデータがあるインスタンスでこれが発生し、独立したバックアップがまだ構築されていない場合、これは非常に大きな問題になる可能性があります。



アマゾンから電話会議に印象的なチームが到着しました。 PMと私たちに付随するソリューションアーキテクトに加えて、EBSグループの専門家数人、サポートエンジニア（私が話しかけたのは上司であると思われる）、名前だけで紹介された特定の人がいました。 会話は約1時間続き、設定した方向に進みました。 正確に何が起こったのか 、 これが二度と起こらないようにするために 何をするのか 、そして将来そのようなことからシステムを保護するためにできることの 3つの質問に対する答えに興味がありました。 アマゾンがそのような出来事からの恐怖感を共有しているかどうかも自分で理解しようとしました。



はい、もちろん、彼らはこれが異常なものであることを明確に理解していました。 事件に対する懸念と非常に深刻な態度があらゆる言葉で聞こえ、彼らはこれが平文で何度も言ったが、これは本当に重大な問題であり、これは起こってはならない。 インシデント分析の一部から、私は次のことを理解しました-この災害は26日ではなく、1週間前のインスタンスの最初の作成中に発生しました。 そして、1週間を通して、ボリュームは部分的に破壊されたか、少なくともその中に何かが発見された後、アクセス不能にすることに決めました。 そこに正確に何が壊れているかを明確にしようとしても、特定の成功には至りませんでした-彼らが言えるのは、整合性が論理レベルで破壊され、そのような問題を修正することは不可能だったということです。 ここで、失われたスナップショットとの接続が明らかになりました-それらはすべて問題のあるボリュームから削除されたため、失敗としてマークされました。



したがって、最初から何かがおかしかったボリュームを持つ仮想マシンを1週間使用したことがわかりました。 そして、1週間、彼らのシステムは何の問題も明らかにしなかったが、奇妙なことは何も観察しなかった。 もちろん、彼は妥当な質問をしました-なぜ彼らの検出システムはこれを一週間気づかなかったのですか、何が起こったのですか、彼らは何に気付きましたか？ それに加えて、もし私がこのような機能不全のサービスに一週間住んでいたのなら、なぜそんなに過酷で急いでいるのでしょうか？ 事前に警告して、データと仮想マシンが削除される前に対処する時間を与えてくれないのはなぜですか？



最初のサポートエンジニアが私に言ったように、検出に関する質問への答えは、これがすべての問題の根源であり、C4タイプの問題ではないという意味で与えられました。 私はこの声明はやや不確かに聞こえたと言わざるを得ません。おそらくそこにはC4に結び付けられた何かがありましたが、彼らは認めませんでした。 同時に、誰もがこれらの新しいC4が完全に信頼できることを暖かく保証し、安全に使用できます。 今後、CPUの要件が高い多くのタスクで、過去半年間にわたって非常に積極的に繰り返し使用してきました。これらのタイプのインスタンスは、これ以上奇妙な問題を引き起こすことはありませんでした。



しかし、「このラッシュはすべて何のためだったのか」という質問に対する答えはまったく受け取れませんでした。 私の意見では、彼らは私が推測することしかできない理由でこれを顧客と議論することを禁じられていました。 純粋な陰謀説の順序で、私は自分のボリュームに関する他の人のデータのいくらかの漏洩を想定することができます。そして、この過酷な物語全体が何らかの形で正当化されます。



「これが二度と起こらないように何をしているのか」という質問に対する答えの形で、彼らは可能な限りすべてをしていることを保証しましたが、私は秘密保持契約への署名を拒否したという事実を参照して、この場合はより詳細な答えは不可能です。 偶然にも、彼らがNDAに署名することを提案したのはこれが初めてではありませんでしたが、彼らが提案したNDAのまさに形式の不条理のために常に拒否しました。本やものを販売するアマゾンのウェブサイトで。 最後のセクション（「システムを保護するためにできること」）について。 ここでは、彼らは熱心に、そしてたいていはcor慢に多く話しました。 実際、ここでは何もできませんが、常に最悪の事態に備える必要があります。この専門家チームがいなければ理解できました。



要約すると、有益なことを述べるのが慣例となっている部分で、もう一度思い出させてください-世界のすべてが崩壊し、最高のクラウドプロバイダーでさえ失敗する可能性があります。 そして、このために毎日準備する必要があります。 私の場合、部分的な準備と幸運の組み合わせが救われましたが、この事件から、頭をスクロールしながら、「システムの別の部分が同時にいくつかの場所で故障した場合、どうすれば生き残ることができるか」といういくつかのレッスンを学びました。 インシデントの結果に基づいて、特定のデータを他のAmazon以外のクラウドに繰り返しバックアップし、すべての一意のノードを確認し、少なくとも複製を作成し、クラウドインフラストラクチャ全体を使い捨ての方向に強くシフトするなど、かなり偏執的なアクションをいくつか行いました。 全体的な機能を犠牲にすることなく、何でも削除して再構築できます。



この事件は、3つの実際のデータセンターからクラウドに移行するという私のイニシアチブにとって最も深刻な打撃になる可能性があります。 私がこの組織で働いていた1年半の間、私たちは火災（実際の煙、火災、ラック全体の損失）、近隣のラックの他のコンピューターからの攻撃、鉄の多数の誤動作、外部の理由によるたるみのたるみ、システム管理者が生き残りました週と他の素晴らしい冒険。 そのため、このような重大な事件でも、私たちを揺るがすことはできませんでした。むしろ、今年4月に完了した雲に完全に移行するという私の決意は揺るぎません。