AWSの障害対策における4つのポイント【後編】

AWS障害からの復旧計画時に意識したい「RPO」「RTO」とは？

「Amazon Web Services」（AWS）に障害が起きたときのために、どのように復旧計画を立てればよいのだろうか。「復旧対象のデータの評価」「復旧計画に使う指標」「復旧の訓練」の観点から説明する。

公開 2020年03月25日 05時00分

[TechTarget]

印刷する連載新着通知を受け取る Googleで優先するソースとして追加

　パブリッククラウドでは天変地異やハードウェアの障害、サイバー攻撃が原因のサービス停止がいつか必ず起こる。Amazon Web Services（AWS）の同名パブリッククラウドも例外ではない。AWSをはじめとするクラウドベンダーは、ITインフラ停止の被害を最小限に抑えるための機能やサービスを幾つか提供している。

　本稿は前編「AWSの可用性を確保する方法とは？」に引き続き、AWSをはじめとするパブリッククラウドを利用するときの、障害対策の方法を説明する。

併せて読みたいお薦め記事

クラウドの障害対策

それでもクラウドを使う理由

データの種類と重要度を評価する

　パブリッククラウドの障害に備えるには、企業の業務に関する要件と技術に関する要件の足並みをそろえる必要がある。ITコンサルティング企業のUptime InstituteでIT戦略部門の最高責任者を務めるトッド・トラバー氏は、パブリッククラウドに配置されているデータの種類ごとに、データ保護と可用性確保の方法や保管期間について評価し、分類しなければならないと話す。この分類に基づいて、利用するデータセンターの種類や地域に加え、複数のハードウェア間でデータを同時に書き込むミラーリングの手法を決定する。

　トラバー氏は、データを処理するための要件をルール化してドキュメントにすることも勧める。これはパブリッククラウド障害の影響を受ける恐れがある自社の事業部門のさまざまなエンドユーザーと協力して実施する。

　AWSのユーザー企業であれば、メッセージキューイングサービス「Amazon Simple Queue Service」を利用することで、キュー（メッセージ待機列）の長さに基づいて仮想マシン（VM）を個別にスケーリングできる。万が一障害が発生しても、キューに入れられた要求はアプリケーションが復旧したときに新しいVMに引き継がれる。

「RPO」「RTO」など復旧計画に適用する指標を確立させる

　パブリッククラウドで障害が発生する可能性のある全ての状況を特定することは不可能だ。だが大規模な障害は、アプリケーションで部分的な障害が発生した結果として起きることが少なくない。そのため「AWSで障害が起きたときに直ちに実行する項目と手順を明記したロードマップを作成する必要がある」と、クラウドコンサルティング会社Atlantic.NetでCEOを務めるマーティ・プラニク氏は話す。「全ての企業は、障害とそれに対処するための業務プロセスについて、事前に熟慮しておくべきだ」（プラニク氏）

　クラウド管理者は、災害復旧のバックアップ計画や障害の発生時にすぐ使えるサービスを用意しておく必要があるとプラニク氏は言う。システムの復旧計画には、目標復旧時点（RPO）と目標復旧時間（RTO）などの指標を含めることが欠かせない。RPOはアプリケーションが許容するダウンタイム（停止時間）の長さを定義する。RPOが長くなるほど必要な更新が減り、保守もそれだけ簡単かつ低コストになる。ただしアプリケーションの広範囲に影響が及ぶ障害では、ダウンタイムが長くなることでより多くのデータが失われる恐れがある。RTOは、障害が発生したときにどれだけ迅速にバックアップを復旧できるかを示す。災害復旧計画ではRPOとRTOの目標を満たす必要がある。これはホストしているアプリケーションによって変わる。

障害からの復旧の訓練をする

　障害に対して脆弱なデータは、データベース管理システム（DBMS）に格納しているデータだけではない。アプリケーションの状態や各種クラウドサービスの設定、アプリケーションログも障害で失う恐れがある。企業にとってはこれらの種類のデータを復旧可能にしておくことも重要だ。

　「パブリッククラウドで稼働するアプリケーションは、何も手を加えなくてもバックアップされていると誤解しているユーザー企業は少なくないが、それは間違いだ」。そう語るのは、ITコンサルティング会社Sparkhoundでインフラエンジニアコンサルタントを務めるブライアン・ブロック氏だ。

　IT部門は高可用性を確保する計画を立てる必要はある。ただしそれだけでランサムウェア（身代金要求型マルウェア）をはじめとするサイバー攻撃によるデータの削除からデータを完全に保護できるわけではない。ブロック氏によると、企業はパブリッククラウド障害やランサムウェア攻撃、自然災害など、複数の障害シナリオからの復旧を訓練しておく必要がある。

　障害に備えてパブリッククラウドとプライベートクラウド、オンプレミスを組み合わせるハイブリッドクラウドの手法を導入する企業は少なくない。ハイブリッドクラウドを構築していないなら、複数のリージョンやパブリッククラウドを利用するマルチリージョン戦略やマルチクラウド戦略を選ぶとよい。オンプレミスのハードウェアを扱う際には、スケーリングや柔軟性が問題になることがあるためだ。

印刷する

AWSの障害対策における4つのポイント

連載新着通知を受け取る

この連載の記事をもっと見る

この記事の著者

George Lawton

ロンドンに拠点を置くフリーランスのジャーナリスト。テクノロジーやビジネス分野を中心に30年以上の執筆経験を持つ。DevOps、人工知能（AI）技術、感情知性（Emotional Intelligence）、変革的リーダーシップ理論などの分野に関心を持つ。

AWS障害からの復旧計画時に意識したい「RPO」「RTO」とは？

目次

併せて読みたいお薦め記事

クラウドの障害対策

それでもクラウドを使う理由

データの種類と重要度を評価する

「RPO」「RTO」など復旧計画に適用する指標を確立させる

障害からの復旧の訓練をする

AWSの障害対策における4つのポイント

この記事の著者

関連記事

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓

AWS障害からの復旧計画時に意識したい「RPO」「RTO」とは？

目次

併せて読みたいお薦め記事

クラウドの障害対策

それでもクラウドを使う理由

データの種類と重要度を評価する

「RPO」「RTO」など復旧計画に適用する指標を確立させる

障害からの復旧の訓練をする

AWSの障害対策における4つのポイント

この記事の著者

関連記事

AWS障害やデータ漏えい事件があっても、米国防総省がクラウドを信頼する訳

「Google Cloud Platform」（GCP）の障害を引き起こしたエンジニアの行動とは？

新着ホワイトペーパー PR

瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓