クラウドの障害対策4つの方法と最も信頼性のある構成とは?

    皆さんこんにちは。東の西下です。
    今日はクラウドの障害対策の4つの方法と最も信頼性のある構成についてご一緒に考えたいと思います。

    先日当ブログ、【AWS重大障害発生!!】持続するビジネスに必要なことでお知らせ致しましたとおり、8月23日にAWSの東京リージョンで大規模な障害が発生しました。この障害のため、東京リージョンに配置される一部のEC2インスタンス(IaaS)、RDS(データベースのサービス)が使用不可となりました。

    最近は多くの重要なシステムがクラウドのIaaSに移行されています。今回の障害を受けて、IaaSの運用や検討されているお客様から、多くのお問合せを頂いており、不安を感じられている方が多くいらっしゃることが伺われます。

    なお、今回の障害では、当社の高可用性ソリューションである「AZを跨いだHAクラスター構成」は被害を受けずサービス提供を継続できました。
    今一度お客様のシステムの障害対策が十分なのか、ご一緒に考えてみませんか?

    クラウド上で一般によく使われる障害対策

    クラウド上では次の4つの対策が良く使われています。

    1. クラウドの標準機能による対策(Auto Recovery)
    2. 監視ツールと手動操作による対策
    3. バックアップによる対策
    4. HAクラスターによる対策

    1. クラウドの標準機能による対策(Auto Recovery)

    クラウドの標準機能で障害対策を取られているケースは多いと思います。例えばAWSの場合は EC2の「Auto Recovery」機能が有名です。

    Auto Recoveryは、物理ホスト側の問題を検知してEC2インスタンスを自動復旧してくれるサービスです。EC2インスタンス上で動いているアプリケーションの障害までは検知してくれませんが、基板側の障害については一定の信頼ができると言えます。

    <概念図:Auto Recovery>

    autorecovery

    しかし今回の大規模障害では、Auto Recoveryでも自動復旧に失敗するケースがあったようです。原因としては、Auto Recoveryは作動したが、肝心の物理ホスト側が障害から回復しておらずに自動復旧が失敗したのではないかと考えられます。

    多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、ECサイトや銀行ATMなど止められないシステムの対策としては、確実に別のAZ(Availability Zone)での復旧が対策になると考えられます。AZを跨いで復旧することで、別のAZで起こった障害から隔離できる確率が上がるといえます。

    2. 監視ツールと手動操作による対策

    EC2上でZabbixなどの監視ツールを使って障害対策をされるケースもあるでしょう。監視ツールが障害を検知したら手動で再起動させる運用もよく聞きます。この方式の長所は、Auto Recoveryでは検知できないアプリケーションの障害も監視ツールが検知してくれる点にあります。

    反面、手動操作を前提としているので、人的な負担や復旧時間の長さ、操作ミスのリスクが短所になります。また、今回のような大規模障害の場合は、そもそも仮想マシンの再起動の操作ができない可能性もあります。

    <概念図:監視ツールと手動再起動>

    monitoringtool

    多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、止められないシステムの対策としては、自動的に障害を検知して別のAZで復旧できる仕組みが必要になります。

    3. バックアップによる対策

    バックアップはどのシステムでも使われていますが、障害対策の観点では次の点に注意が必要です。

    まずバックアップは、バックアップを取った時点の状態に確実に戻すことができます。この点はメリットでもありますが、障害が起きた時点のできるだけ近くの状態に戻すことはあまり得意ではありません。(RPO(目標復旧時点)の観点)

    <概念図:バックアップからの復旧>

    backup

    またバックアップからのリストアにはそれなりに時間がかかるので、大事なシステムをすぐに復旧させたい場合は注意が必要です。(RTO(目標復旧時間)の観点)

    さらに今回のような障害時にバックアップを取ったデータを別のAZで復旧させたい場合には、ネットワークなどの環境の相違点の対応が必要になる場合もあります。
    多少止まっても影響が小さいシステムであればこの方式でも問題ないと言えますが、基幹系など止められないシステムの対策としては、RTOとRPOが短くかつ他のAZでも修正不要で復旧できる仕組みとの併用が必要です。

    これらから基幹系など止められないシステムに対しては、下記の要素が必要になります。

    • 障害を自動的に検知して復旧できること
    • 別のAZで復旧して障害から隔離できること
    • RPOとRTOの短縮

    4. HAクラスターによる対策

    HAクラスターとは稼働系と待機系でサーバーを2台用意し、稼働系システムに障害が発生した際に自動的に待機系システムに切り替える仕組みです。
    HAクラスターソリューションは、これまで説明した「障害の自動検知と自動復旧」「別のAZでの復旧」「RPOとPTOの短縮」すべてを実現するソリューションです。

    クラウド障害表

    代表的なHAクラスターソリューションとしては、サイオステクノロジーのHAクラスターソフトLifeKeeperとデータレプリケーションソフトDataKeeperがあります。

    LifeKeeperは当社のHAクラスター製品で、グローバルで25年・6万ライセンス以上使われている実績のある製品です。AWSやAzureなどのパブリッククラウドにもいち早く対応しており、既に多くの導入実績があります。

    DataKeeperは当社のデータレプリケーション製品で、ブロックレベルのリアルタイム・レプリケーションにより、LifeKeeperに論理的な共有ストレージとして認識されます。これにより、物理的な共有ストレージが使えないクラウド環境でも、オンプレと同じ感覚でHAクラスターの構築が可能です。

    <AWS上での構成例のイメージ>

    lkonaws

    下記ページでは導入事例や詳細な構築手順ガイドを公開しております。ぜひこれらをご覧いただいて、今後のクラウド環境の障害対策にお役立てください。

    cloudha

    まとめ

    クラウドの障害から止められないシステムを守るためには、システム停止の許容時間やコスト負担に応じて様々な選択肢があります。自社の要件に応じて適切な方法を選び、対策を取ることが重要です。

    季節の変わり目ですので、お体にご留意ください。それではまた。

    オンラインウェビナー

    当社ソリューションアーキテクトが、本内容を詳しく解説したウェビナーを10/17(木)16:00から30分間でオンライン配信いたします。


    上記バナーより、ぜひお申し込みください。

    お問い合わせ

    また、「こういった要件はやれるか?」などの疑問点がございましたら、お気軽に下記からお問合せください。皆様からの問い合わせをお待ちしております。

    お問合せボタン②

    SNSでもご購読できます。