AWS環境の可用性の現実と解決策について

    みなさんこんにちは。東日本担当のプリセールスの西下(にしした)です。
    (「西の國政(くにまさ)・東の西下」と覚えてくださいね。)
    近頃日が落ちるのも早くなり、寒さも真冬っぽくなってきましたね。皆様もどうぞ体調にご留意下さいませ。

    今回はクラウド案件の中でも人気をAzureと二分するAWSに焦点を当てて、2回に分けてお話させていただきます。


    1. AWS環境の可用性の現実とHAクラスタによる高可用性の実現方法
    2. AWS環境上の具体的なHAクラスタ構成例 + 実際の構築手順

    なお今回は、当社のHAソリューションやAWSの環境に詳しくない方でもスムーズにお読みいただけるように、各構成や手順については省略せず細かく記した上で「なぜその手順が必要なのか?」「バックでどのように動いているのか?」「やってしまいがちな失敗」を多く記載しました。

    実際に構築されない方にとっても、当記事をご覧いただくことで、当社HAソリューションによるAWSの可用性向上を短時間でご理解いただけるかと思います。

    HAクラスタの構築はそれなりに多くの工程を要しますが、本ブログ記事ではできるだけ本質を捉えていただきたい思いから、幹となる最小限の構成と手順を前提に進めています。
    このブログを読み終えましたら、ぜひAWSのフリーアカウントを作って手順をお試しください。

    AWS(EC2)の可用性の現実

    AWSは非常に多くのサービスで構成されています。
    我々のソリューションはその中でもIaaSのEC2を対象としています。(なぜIaaSを対象にしているかについては、この後ご説明致します。)

    普段お話を伺っていて気づくのは、「クラウドにシステムを構築すれば、可用性については全てクラウドベンダーが担保してくれる」と誤解されている方が意外と多い実情です。

    実はこの認識は正しくありません。
    クラウドのサービスには「SaaS」「PaaS」「IaaS」などといった形態のサービスが提供されています。
    この中でSaaSとPaaSについては、確かにクラウドベンダーの方でサービスが止まっても自動復旧する仕組みを提供しています。

    IaaSについてはどうでしょうか?
    IaaSは「Infrastructure as a Service」の略称である通り、サービスの本質は基盤側にあります。

    つまり、基盤側についてはクラウドベンダー側で責任も持ってくれますが、基盤の上で動くOSより上位のミドルウェアやアプリケーションのレイヤについては、利用者の方で責任持つ必要があります。
    我々はこの構成を利用者とクラウドベンダーの間で責任を共有する「責任共有モデル」と呼んでいます。

    利用者とベンダーの「責任共有モデル」図

    ここでもう1つ大事なポイントがあります。それは、システムの障害原因の内訳です。

    従来システムの障害原因といえば、「ハードウェア」に起因するものを指すことが一般的でした。
    しかし最近は「ソフトウェア」に起因する障害がハードウェアに起因する障害を逆転する統計も出ています。
    この背景としては、ハードウェアの信頼性は年々向上しているのに対し、ソフトウェアは人が作るものなのでそれ程昔と状況が変わらない。結果として相対的にソフトウェア起因の障害が目立つようになってきたと考えられます。

    つまり、現在は「ハードウェアを気にするのであれば、同じくらいソフトウェアにも気を遣う必要がある」と言えます。

    それではソフトウェア=上記のオレンジ色の箇所を守るにはどうすればよいのでしょうか?
    まずすぐに思いつくのが、AWSのAuto RecoveryのようなIaaSに提供されている自動復旧機能を使うことです。
    Auto Recoveryは物理ホスト等の障害を検知したら、EC2の仮想インスタンスを別の物理サーバー上で自動復旧してくれます。

    Auto Recoveryはとても便利な機能ですが、見ている対象はあくまでハードウェアの障害であり、ソフトウェアの障害は検知してくれません。
    IaaSで提供される自動復旧の仕組みはこのようなハードウェアの障害を見ているものが一般的です。
    IaaS環境ではソフトウェアの障害は検知できないのでしょうか?

    Iaas上でのHAクラスター構成図

    その答えが、IaaS上でのHAクラスタ構成です。
    IaaSで対応できない領域をHAクラスタで対応することで、基盤側からアプリケーションまでをフルに「相互補完」が可能となります。

    IaasとHAクラスターによる相互補完図

    ここでAWSに詳しい方だと

    「AWSでは便利な『マネージドサービス』が提供されている。例えばDBのマネージドサービスであるRDS(Relational Database Service)を使うと構築や運用は楽だし、マルチAZオプションのような冗長構成もあるので、わざわざIaaSに構築する必要性は無いのでは?」

    と疑問に思われるかもしれません。

    確かにRDSは構築や運用をAWSの方でやってくれるので非常に楽です。また冗長構成もできます。
    しかしRDSは容易に構築できる代わりに、機能的な自由度が制限されている特徴があります。
    例えば、DBのバージョンが決まっている、カスタマイズ対応が難しい、メンテナンススケジュールはAWSに従うなどといったものです。

    「既存の環境を極力そのままクラウドに移行したい」「現行の仕様をRDSに合わせたくない」というニーズは根強く、このようなケースの場合はIaaSのEC2上に個別にDBなどの環境を構築する必要があります。

    クラウド上での構築スタイル

     

    PaaSとIaaSの比較表

    当社はいち早くHAクラスタのクラウド対応に取り組んでおり、特にAWS(EC2)については既に多くの導入実績があります。

    しかしHAクラスタソフトに詳しい方だと、このような疑問をお持ちになるかもしれません。

    「HAクラスタは通常稼動系と待機系のサーバーの間で共有ストレージを使ってデータを共有する。AWSのように共有ストレージが使えない環境ではどうやってHAクラスタを構築するのだ?」

    当社ではデータレプリケーション製品のDataKeeper(データキーパー)をリリースしています。
    DataKeeperはブロックレベルでリアルタイムに稼動系と待機系のローカルディスク同士を同期し、その同期している領域を共有ストレージとしてHAクラスタソフトに使わせることができます。

    HAクラスタソフトは、当社で開発販売しているLifeKeeper(ライフキーパー、Linux版およびWindows版あり)、もしくはWindowsServer標準のHAクラスタ機能のWSFC(Windows Server Failover Clustering)が対応します。

    DateKeeperによるHAクラスター概念図

    これを実際にAmazon EC2に適用すると次のような概念図になります。
    AZ(Availability Zone)をまたいだ仮想インスタンス間でHAクラスタを構成し、EBS(Elastic Block Store)を各仮想位スタンスにローカルティスクとして割り当て、その間をDataKeeperでレプリケーションして共有ストレージの代わりとします。

    AmazonEC2上の構成の概念図

    なお、当社ではAmazon EC2環境において既に下記の構成をサポートしています。

    No.HAクラスタソフトレプリケーションソフトOS
    1 LifeKeeperDataKeeperLinux
    2 LifeKeeperDataKeeperWindows
    3WSFCDataKeeperWindows

    今回のシリーズでは、この中で実績の多いNo1.のLinux版のLifeKeeper+DataKeeperの構成を前提に深掘りしてご紹介致します。
    次回は具体的にどのような構成に対応しており、どのようにクライアントを稼動系のノードにルーティングさせるのかその仕組をご紹介します。お楽しみに。

    資料ダウンロード

    LifeKeeperやDataKeeperによるAmazon EC2上でのクラスタ構成やSQL Serverの冗長化手順を説明した資料をダウンロードいただけます。

    AWS向け資料ダウンロードはこちら

    関連情報

    SANLess Clusters

    最近の傾向としてWindows環境でHAクラスタを構築されるケースが非常に増えています。特に上記3.のWSFCとDataKeeperの組み合わせ(SANLess Clusters)は、非常に廉価かつWSFCの知識があれば容易にHAクラスタを構築できるため、多くの導入実績があります。

    Amazon EC2上での可用性向上について

    LifeKeeperやDataKeeperによるAmazon EC2上でのクラスタ構成についてご紹介しています。

    お問い合わせ

    「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか?」といった場合は、下記までお気軽にお問い合わせください。
    >>お問い合わせはこちら
     

    SNSでもご購読できます。