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

image1
Pocket

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

さて、当ブログではこれまで「クラウド環境の可用性(=システムの継続稼動能力)の現実」「なぜクラウド環境でHAクラスターが必要なのか?」といった記事を複数公開してきました。
>>クラウドと可用性 – クラウド環境の可用性を信じていいのか?

当社では長年クラウドの可用性に取り組んでおり、お陰様で多くのお客様に当社のHAソリューションが認知され、数多くのクラウド案件の導入実績があります。
>>導入事例

今回はクラウド案件の中でも人気を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の仮想インスタンスを別の物理サーバー上で自動復旧してくれます。
>>EC2の”Auto Recovery”を有効にする。

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 LifeKeeper DataKeeper Linux
2 LifeKeeper DataKeeper Windows
3 WSFC DataKeeper Windows

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

ご参考

なお、最近の傾向としてWindows環境でHAクラスターを構築されるケースが非常に増えています。特に上記3.のWSFCとDataKeeperの組み合わせは、非常に廉価かつWSFCの知識があれば容易にHAクラスターを構築できるため、多くの導入実績があります。
(関連記事:https://bcblog.sios.jp/tag/sanless-clusters/

ご案内

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

SNSでもご購読できます。