Amazon 障害発生時の回復ストラテジー

Amazon Web Services の Simple Storage Service（S3）の停止は時折発生します。これは避けられないことなので、組織にとっては、回復のためのストラテジーが重要になります。

ビジネスで利用するデータは、必要なときに必要な場所で使用可能であるのが前提です。では、AWSなどのクラウドサービスが停止してしまった場合はどうすればいいか、ビジネス上の方策は整えられていますか？Amazon では、ユーザーが必要なときにいつでもデータにアクセスできるように最大限の努力を払っています。停電中もデータにアクセスする方法も考慮されています。最近、Amazon は、データセンター全体が完全にダウンしたことは一度もないと主張 しました。データセンター全体のダウンというのは、あったとしても極めて稀なことでしょうが、大規模なデータセンター全体がダウンした場合に備えてフェイルセーフ対策は行っているようです。

データセンター全体の完全なダウンではないとしても、AWSのダウンがユーザーのサイトに打撃を与えた直近の例 は、2017年2月28日に、AWSエンジニアのコマンドのタイプミスによって起こりました。Amazon Web ServicesのSimple Storage Service（S3）の機能停止がインターネット全体にわたって様々なサイトに悪影響を及ぼしたことで、多くの企業が「クラウドは他の誰かのコンピュータにすぎない」ことを改めて思い知らされました。クラウドサービスを利用している企業に、回復のためのストラテジーが必要なのはこのためです。

クラウドサービスのダウンによってサイトが利用できなくなると、その期間の売上げを損失することになります。まったく利用できない最悪の事態は回避できても、機能が回復するまで生産性は大きく損なわれるでしょう。影響を受けなかった会社でも、IT管理者なら、「もし、これが自分たちのサイトならどうなっていたか？クラウドサービスがダウンしたとき、事業継続ができるよう十分な準備ができているか？」と自問しているのではないでしょうか？

クラウド移行は万能薬にあらず

クラウドサービスのプロバイダは、SLA（サービスレベルアグリーメント）として「99.999…％」のアップタイムなどと宣伝（そうするとたとえわずか数分の停止でもSLAを満たしていないことになる可能性があるのですが）することがあります。ハードウェア、オフィスのスペース、ITスタッフの人件費などのコスト削減策につながることもあって、そのSLAの宣伝文句は魅力的に響き、クラウドへの移行を促進します。ですが、過去の例からもわかるように、単にシステムやデータをオフサイトに移動しただけでは、必ずしも100％の無停止時間が保証されるわけではありません。万一の場合に備えて適切なビジネス回復のプランニングが必要になります。そのためには、データがどこにあるのか、冗長性は必要か、そしてサービスプロバイダに問題が発生した場合の潜在的な影響を軽減するにはどうすればいいか、といったことを綿密に検討する必要があります。

投資回収率（Return on Investment、ROI）

どの程度のプロテクションがあれば十分と言えますか？いくらに達したら限度を超えていることになりますか？投資回収率はメトリクスと統計値を組み合わせて測定します。システムが使用可能な場合の価値（使用不可になった場合の損失）を明確に把握して、回復のためにどの程度までのコストをかける価値があるのかを判断してください。

ブログサイトは、一般には回復ストラテジーに組み込んで一刻も早く回復させる手立てを講じる必要はないかもしれませんが、広告が貼り付けてあって広告収入が見込まれるブログサイトは、機能停止によって収入の機会を失うことになります。収入機会損失によって失われるコストを、高レベルの事業回復ストラテジーへの投資コストと比較しながら、最適なバランスを検討することが重要です。

事業回復ストラテジー策定のための分析には、目標復旧時間と目標復旧時点（それぞれ recovery time objective、RTO と recovery point objective、RPO）を把握することも含まれるべきです。RTO分析でビジネスが停止に耐えられる期間を決定し、RPO分析でビジネスがデータ損失を許容できる最大期間を定義します。

ブログサイトの例では、広告収入の損失により復旧時間のしきい値が低くなる可能性がありますが、サイトのデータが1週間に1回しか変更されなければ、バックアップからリストアする復旧時点のしきい値が高くなります。両方の要因を考慮して分析し、どれだけのプロテクションが十分であるかを判断します。

複数リージョンの冗長性

2017年2月のAWS S3障害は US-EAST-1というリージョンに限定されており、リージョンは互いに分離されています。リージョン固有のエンドポイントを使用するオプションもありますが、デフォルトのエンドポイントが使用されてリダイレクトされていた場合、この問題はより広範囲に及んだ可能性があります。

リージョンは互いに分離されているので、S3バケットにクロスリージョン・レプリケーション が設定されており、すべてのオブジェクトがレプリケートされており、アプリケーションを異なるAWSリージョンにある別のS3バケットにリダイレクトすることができる場合は、サービスを復旧することができます。クラウド内のものであっても、システムとレイアウトを熟知していれば、いろいろな方策があるはずです。

プロアクティブ・テスト

クロスリージョン・レプリケーションについての上記説明には、多くの「もし」が含まれています。

• 「もし」クロスリージョン・レプリケーションが設定されていたら  
• 「もし」すべてのオブジェクトがレプリケートされていたら
• 「もし」アプリケーションをリダイレクトすることができたら

IT部門で策定した回復ストラテジーが本当に機能するかどうかを確認する唯一の方法は、回復の手順を実際にテストしてみることです。回復が必要になったとき、ストラテジーに沿った手順を初めて実行するというような状況は避けるべきでしょう。

ビジネス回復ストラテジーの冗長部分

「卵を全部1つのかごに入れないように」という戒めの言葉があります。データの重要性によっては、すべてのデータを1つのクラウドプロバイダに委ねることに不安を払拭しきれない場合があります。ですが、複数プロバイダを使うオプションはコストがかかり複雑である可能性が高いので、ROIをできる限り正確に計算して、データを複数のプロバイダに保存することのメリットとコストを比較算定してください。

AWS、Microsoft Azure、Rackspace などが、エンタープライズクラスのストレージオプションを提供しています。もう1つの選択肢は、クラウドとオンプレミスのハイブリッド・ソリューションを使用することです。オンプレミスからの脱却を目指してクラウドに移行したのかもしれませんが、ROIメトリクスによっては、ハイブリッド回復ソリューションの方が複数のクラウドプロバイダを使うより経済的な場合もあります。

システム回復ストラテジーの見直し

システムのダウンタイムは、ビジネス機会損失や生産性悪化を招く可能性が高く、すべて経済的な損失につながります。実際に起きたAWS S3の機能停止を、これまでの障害発生時のための回復ストラテジーを見直して、障害発生時の被害を最小限に抑えるにはどうすればいいのかを再検討するきっかけにしてください。何もしないと手遅れになってしまいます。