AWS環境で可用性の高いシステム構成を実現するには？～HAクラスター構成で実現するAWS環境の高信頼化～

オンプレミスからアマゾン ウェブ サービス（Amazon Web Services：以降、AWSと略す）の移行を検討する際、オンプレミスと同等の可用性の実現は重要な課題の一つです。
AWSは運用監視を自動化するサービスが充実していますが、AWSが責任を持つレイヤーとユーザーが責任を持つレイヤーが明確に分かれており、AWSのマネージドサービスを利用した構成でもユーザーが管理するレイヤーは残ります。

本記事では、筆者がお客様からお聞きしたオンプレミスからAWSへの移行時の課題をもとに、弊社が提供しているHAクラスタリングソフトウェアのFujitsu Software PRIMECLUSTER（以降、PRIMECLUSTERと略す）を利用するメリットをご紹介します。

本記事はこんな方にお勧めします

• オンプレミスで稼働しているシステムのAWS移行を検討している
• オンプレミスでは可用性設計をしていたが、AWSでの可用性設計の考え方を知りたい

オンプレミスで稼働している既存システムをAWSに移行する際、移行後もRTO（目標復旧時間）を既存システムと同等にしたいというご要望をいただくことがあります。ミッションクリティカルなシステムであれば、オンプレミスでもAWSでも、どんな環境でもシステム停止は最小限に抑える必要があります。

1.1 考慮すべきポイント

高いRTOを実現するには、障害を素早く検知し、待機系に切り替えることが重要です。パブリッククラウドの運用全てをクラウドベンダーにお任せできるのでは？と思われるかもしれません。
パブリッククラウドにはユーザーとクラウドベンダーの責任範囲を明確に分ける責任共有モデルという考え方があります。AWSでも責任共有モデルを採用しており、AWSで提供されるコンピュートサービス、マネージドサービス、どちらのサービスを利用してもユーザーが管理するレイヤーは残ります。

AWSでの可用性設計を行う際、まずはAWSが提供するサービスを使った監視を検討されるのではないでしょうか。しかし、パブリッククラウド環境においてクラウドベンダーが提供するサービスで全てのレイヤーを監視するのは簡単ではありません。AWSが提供する監視サービス、Amazon CloudWatch（以降、CloudWatchと略す）では無料の標準メトリクスは基本的にインフラが監視対象になります。アプリケーションやプロセスの稼働監視をCloudWatchで行いたい場合、有料のカスタムメトリクスをユーザーで定義して監視を行う必要があります。カスタムメトリクスを詳細に定義するには設定ファイルにJSON形式で設定内容を記述する必要があり、設定作業がとても面倒になります。

くわえて、パブリッククラウドではアベイラビリティゾーンやリージョン単位で障害が発生することがあります。2023年6月にはAWSの米国東部リージョンで大規模障害が起こり、AWS基盤のウェブサイトに接続できない、日本でもスマートホームデバイス製品が一時的に利用できなくなった、という影響がありました。
AWS環境でも高可用性を実現するためには、AWSのサービスに障害が発生する可能性を念頭に置き、障害時には即時復旧できるような構成を取る必要があります。

1.2 解決策：インフラレイヤーだけではなくOSからアプリケーションまで監視

前述したAWSの障害のようなケースに対してもPRIMECLUSTERが解決策になります。PRIMECLUSTERを利用したクラスター構成であれば、複数AZのインフラ基盤からアプリケーションまでの全レイヤーを監視でき、稼働中のサーバーやゲストOS、業務アプリケーションに障害が発生した際、待機系サーバーに自動で即時切替し、オンプレミスと同等のRTOを実現することができます。

システムの基本設計として、クラウド環境で最適なクラウドネイティブ構成にする方針は最初に立てられる目標です。それと同時に、できるだけ費用は抑えるという条件もしばしば指定されます。

2.1 考慮すべきポイント

クラウドネイティブとは、クラウド技術を利用し、「より素早く簡単」に、「スケーラブルで柔軟」で「障害が発生しても継続利用できる」システムやサービスを構築・リリースするための「ベストプラクティス」とされている考え方です。
クラウドネイティブな構成では、クラウドベンダーが提供するコンテナサービスやサーバーレスサービスを利用し、スケーラブルなアプリケーションを構築します。
しかし、オンプレミスの構成から一気にクラウドネイティブな構成を目指すとアプリケーション設計や運用設計の大幅な見直しが必要であり、移行までの期間が長引く、移行コストが増大する、といったことがあります。
例えば、オンプレミスにおけるクラスター構成では運用系と待機系のデータ引継ぎに共用ディスクを使用することが一般的ですが、クラウドではAZをまたいだストレージの共用は難しく、設計の見直しが必要です。

2.2 解決策：オンプレミスの構成をそのままクラウドへ移行する

クラウド移行の1つの戦略として、いったんオンプレミスの構成をそのままクラウド環境へリフトし、将来的にクラウドネイティブな構成を目指す方法があります。クラウドリフトでは柔軟な設計ができるコンピュートサービスを利用し、オンプレミスの構成を可能な限り踏襲することで、運用負荷を軽減しながら移行が可能です。
オンプレミスでPRIMECLUSTERを利用してクラスター構成を組んでいる場合、PRIMECLUSTERを含めてAWSへ移行することで、移行の期間やコストを抑えることができます。上述のAZをまたいだストレージの共有ができないという制約に対しては、PRIMECLUSTERではネットワーク経由でローカルディスクを複製することでデータ同期を実現します。

また、PRIMECLUSTERではAWSのネットワーク設計においても柔軟に構成パターンを選択できます。
例えば、① クライアントをオンプレミスに配置したい場合と、② Amazon Virtual Private Cloud（以降、Amazon VPCと略す）に配置したい場合ではクラスターシステムへの接続方式が異なりますが、PRIMECLUSTERを使ったクラスター構成ではどちらの接続方式も取ることができます。

① クライアントをオンプレミスに配置する場合の構成例

• 仮想ホスト名でクラスターシステムにアクセス可能。
• 異常発生時はPRIMECLUSTERがDNSサービスのレコードを待機系のプライベートIPアドレスに付け替えることでネットワークを引き継ぎ。

② クライアントをAmazon VPCに配置する場合の構成例

• 仮想IPアドレスでクラスターシステムにアクセス。
  異常発生時はPRIMECLUSTERがルートテーブルを書き換えることでネットワークを引き継ぎ。
• パブリックサイトからのアクセスを遮断し、セキュアなクラスターシステムを実現。

リソースやスクリプトなどもそのままAWS上で利用できるため、運用変更も不要です。

PRIMECLUSTERは、ミッションクリティカル市場で培った技術とノウハウをベースに、富士通の高信頼技術と仮想化技術を結集したHAクラスタリングソフトウェアです。PRIMECLUSTERを利用すると、AZをまたいだデータ同期やネットワークの柔軟な設計を実現し、オンプレミスの構成をそのまま移行することができます。
また、オンプレミスからAWSへの移行後は業務アプリケーションからサーバー、ディスク、ネットワークまでのシステム全体を監視し、高可用性を実現します。

AWSで障害が発生してもシステムが止まらない様子をリアルタイムで体験してみませんか？無料でお申し込みいただけるオンラインデモを用意していますのでご活用ください。

• 【無料オンラインデモ】
  人々の暮らしを豊かにするために！AWSでの業務継続をリアルタイムで体験

• 備考
  Amazon Web Services、AWS、Amazon CloudWatch、Amazon Virtual Private Cloud(Amazon VPC)、Amazon Direct Connect、Amazon Route 53は、Amazon.com, Inc. またはその関連会社の商標です。
  記載されている会社名、システム名、製品名、サービス名などの固有名詞は一般に各社の登録商標または商標です。
  また、本文および図表中に記載されている会社名、システム名、製品名、サービス名などには必ずしも「TM」、「®」を付記しておりません。