AWS JAPAN APN ブログ

サイオステクノロジー株式会社: SIOS LifeKeeperとAWS Transit Gatewayによるシンプルなクラスター構成

本記事は、サイオステクノロジー株式会社 BC事業企画部 クラウドサービスグループ グループマネージャ 西下容史とアマゾンウェブ サービス ジャパン株式会社 技術統括本部 パートナー ソリューション アーキテクト 河原哲也による共著です。

AWSのグローバルインフラストラクチャは、耐障害性と高可用性を実現するために特殊な構成が組まれています。「リージョン」と呼ばれる地理的に離れた領域がそれぞれ接続され、リージョンは2つ以上の「アベイラビリティーゾーン」、アベイラビリティーゾーンは1つ以上の独立したデータセンターで構成されています。そしてアベイラビリティーゾーンは「トランジットセンター」を介してインターネットに接続されています。「リージョン」「アベイラビリティーゾーン」「トランジットセンター」はそれぞれは独立しており、一方の障害が他方へ影響することはなく、そのため耐障害性と高可用性を実現することができます。また、AWSの完全マネージド型サービスを利用すれば、ハードウェアのプロビジョニング、ソフトウェアのパッチ適用、セットアップ、可用性構成、バックアップといった管理タスクについて頭を悩ます必要がなくなります。しかし、自社開発したアプリケーションとの兼ね合いで、すべてをAWSの完全マネージド型サービスに乗せ換えることができないケースがあるのも事実です。そういった場合、オンプレミスで運用しているシステムをなるべく変えずに、まずは「Amazon EC2」上にそのまま移行 (リフト&シフト)するといった手法を取ることができます。

サイオステクノロジー株式会社は、AWS Partner Network (APN) セレクト テクノロジーパートナーであり、AWS上で主に2つのソリューションを提供しています。1つは、Amazon EC2上で稼働するOracle、SQL Serverなどのデータベースや、JP1、HULFT、SAPなどの基幹系アプリケーションの障害を検知し、待機系へ自動でフェイルオーバーする「SIOS LifeKeeper」というソフトウェアを使った高可用性ソリューションです。もう1つは、Amazon EC2およびAmazon EC2上のサービスをエージェントレスで外形監視するサービス「SIOS AppKeeper」です。異常検知時はサービスの再起動、インスタンスの再起動を自動で行い障害の影響を最小限に抑えます。

本記事では、SIOS LifeKeeperによるAmazon EC2上で稼働するシステムの高可用性パターンの拡充として、「AWS Transit Gateway」との組み合わせについて説明します。

責任共有モデル

AWSには、責任共有モデルという考え方があります。この共有モデルは、AWSがホストオペレーティングシステムと仮想化レイヤーから、サービスが運用されている施設の物理的なセキュリティに至るまでの要素をAWSが運用、管理、および制御することから、お客様の運用上の負担を軽減するために役立ちます。お客様には、ゲストオペレーティングシステム、その他の関連アプリケーションソフトウェア、およびAWSが提供するセキュリティグループ/ファイアウォールの設定に対する責任と管理を担っていただきます。この責任共有モデルの性質によって柔軟性が得られ、お客様がデプロイを統制できるようになっています。

図1. AWSの責任共有モデル

使用するサービス、それらのサービスの IT 環境への統合、および適用される法律と規制によって責任が異りますが、お客様がAmazon EC2インスタンスをデプロイした場合、お客様は、更新やセキュリティパッチ適用といったゲストオペレーティングシステムの管理、インスタンスにインストールしたアプリケーションソフトウェアまたはユーティリティの管理、AWSより各インスタンスに提供されるセキュリティグループの構成などに責任を負います。Amazon EC2上のシステムについてお客様自身が責任を負うことで忘れてはいけないのは、システムが停止することなくいつでも使うことが出来るようにするという可用性の観点です。では、お客様自身でAmazon EC2上のシステムを止めないためにはどのような工夫が必要でしょうか?

アベイラビリティーゾーンをまたいだHAクラスター構成

Amazon EC2インスタンスそのものの可用性を高める機能として、Amazon EC2 Auto Recoveryがあります。Amazon CloudWatch インスタンスをモニタリングし、基になるハードウェア障害またはAWSによる修復を必要とする問題によりインスタンスが正常に機能しなくなった場合に、自動的にインスタンスを復旧することができます。

それでは、Amazon EC2上のシステムの可用性を高めるにはどうしたらいいでしょうか。方式の1つとして、Amazon EC2上でのHAクラスター構成という選択肢があります。HAクラスターと言うとオンプレミスのイメージがあるかもしれませんが、Amazon EC2に対応したHAクラスター製品の実績は豊富です。

Amazon EC2上でのHAクラスター構成の特徴としては、オンプレミス以上のより高い可用性を実現するために、アベイラビリティーゾーン (AZ)を跨いだ構成が理想的と言えます。これにより万一の広域障害時にも、別のAZへ自動的に切り替えることで運用を継続し、障害のダメージを最小限に抑えることが可能になります。また、オンプレミスのHAクラスターでは、クラスターノード間のデータ共有に共有ストレージが使われることが一般的でした。物理的な共有ストレージが使えないクラウド環境では、Amazon Elastic Block Store (EBS)同士をブロックレベルでリアルタイムに同期することで、論理的な共有ストレージを作り出して、オンプレミスと同様の環境を作り出す対策が必要になるので、こういった機能に対応したHAクラスター製品が前提となります。

図2. AZを跨いだHAクラスター構成のハイレベルなアーキテクチャ

HAクラスター構成で制御が難しいのは、クラスターノードから見た「クライアント」が、正しくActiveノードへ接続できるようにする方法です。オンプレミスであれば仮想IPアドレスを使うことで、クライアントはどのクラスターノードがActiveノードかを意識する必要がありません。しかし上図のようなAZを跨いだHAクラスター構成では、サブネットを跨いだ形になり、仮想IPアドレスだけではクライアントを正しくルーティングさせる制御ができないため、別途対策が必要になります。

この制御を実現するためには、ルートテーブルやAmazon Route 53との連携などがあり、クライアントの位置によって下図の構成パターンが考えられます。

図3. クライアント接続方式ごとのHAクラスター構成のパターン

これらの構成を手動で実装しようとすると、本来はAWS Command Line Interface (AWS CLI)を駆使した大掛かりな作り込みが必要になります。標準機能で対応しているHAクラスター製品を使うことで、クラスター構築の手数を大幅に減らし、メーカーサポートの受けられる構成で安心した構築が可能になります。

また、HAクラスターで冗長化する対象のソフトウェアの監視や切り替えについても、本来は「監視」や「切り替え」などの制御に対してスクリプトを作成して対応する必要がありますが、ここもHAクラスター側で制御スクリプトが用意されていれば、クラスター構築の手数を大幅に減らし、メーカーサポートの受けられる構成で安心した構築が可能になります。特に最近はSAP (HANA Databaseを含む)を中心に、JP1、HULFTといった基幹系アプリケーションをAmazon EC2上に移行するケースが増えています。この場合、移行元のHAクラスター構成のオンプレミス環境と同等の可用性レベルを要求されるお客様も多いです。

サイオステクノロジーのLifeKeeper はこのような条件に対応したHAクラスター製品です。標準機能でAmazon EC2上での一般的なHAクラスター構成を網羅しており、各ソフトウェアメーカーの認定を受けた制御スクリプトがオプション・リカバリキットとして製品サポート付きで販売されています。これらのオプション・リカバリキットを使うことで制御スクリプトを作成せずに、GUI操作のみで効率的にHAクラスターを構築することができます。

AWS Transit Gatewayでシンプルにクラスターを構築

これまでAmazon EC2上でHAクラスターを構築する場合は、上記の概念図に記載されているように、クライアントの位置関係や接続方式に合わせて構成を使い分ける必要がありました。特にAWS Direct ConnectやAmazon VPC ピア接続といったクラスター構成のシステムが稼働するVPC外部からの接続要件の場合は、VPC外部からダミーの仮想IPにアクセスできないためルートテーブルによる制御が行えず、Amazon Route 53による制御が必要になります。しかし、お客様要件によって、Amazon Route 53による制御では、いくつかの課題がありました。

  • クライアントがホスト名アクセスできない場合は使えない
  • TTLなどDNSの設計を考慮する必要がある
  • Amazon Route 53をAWS CLIで制御するには、インターネットに出られることが前提になる

AWS Transit Gatewayは、お客様がAmazon Virtual Private Cloud (VPC)とオンプレミスネットワークを単一のゲートウェイに接続できるようにするサービスです。AWS Transit Gatewayを使用すれば、中央のゲートウェイからネットワーク上にあるAmazon VPC、オンプレミスのデータセンター、リモートオフィスそれぞれに単一の接続を構築して管理するだけでよいのです。AWS Transit Gatewayがハブの役割を果たし、トラフィックがスポークのように接続されたネットワーク間をどのようにルーティングするかをすべて制御します。このようなハブアンドスポーク型では、各ネットワークをTransit Gatewayにのみ接続すればよく、他のすべてのネットワークに接続する必要がないため、大幅に管理を簡略化して運用コストを削減できます。

SIOS LifeKeeperは、このAWS Transit Gatewayとの連携を正式サポートします。AWS Transit Gatewayのルーティング設定により、クラスター構成のシステムが稼働するVPC外部からの通信であっても「ダミーの仮想IP」にアクセスできます。これにより、上記概念図の「ルートテーブルによる制御」で、あらゆる構成に対応でき、シンプルかつ効率的な構築作業が可能になります。

図4. AWS Transit Gatewayによるシンプルなクラスター構成

AWS専用線アクセス体験ラボで正式サポートに向けた連携検証を実施済み

今回、この正式サポートに向けて、サイオステクノロジーでは、AWS Japanが提供するAWS専用線アクセス体験ラボを活用して、SIOS LifeKeeperとAWS Transit Gatewayの組合せによる動作検証を実施しました。AWS Japanの体験ラボを管轄するネットワーク ソリューション アーキテクトと連携し、効率的に複数の構成の検証を行うことができました。この検証結果をもって、まずは2020年1月14日にリリースした最新版のSIOS LifeKeeper for Linux v9.4.1で正式サポートを開始しています。Windows版も順次サポート開始予定です。

本記事の内容を短期間で習得可能なハンズオンセミナー

サイオステクノロジーでは、既にSIOS LifeKeeperとAWS Transit Gateway、さらにJP1やHULFTを組み合わせた、以下の環境でのハンズオンセミナーも開催していますので、興味のある方はこちらのお問い合わせからご連絡下さい。

図5. AWS Transit GatewayとJP1を組み合わせたハンズオンセミナー環境

基幹系アプリケーションのAmazon EC2への移行をご検討中の方は、本記事でご紹介したAmazon EC2上のシステムの可用性を高めるHAソリューションも合わせてご検討いただければ幸いです。

Tetsuya Kawahara

Tetsuya Kawahara

Senior Manager, Partner Solutions Architecture, AWS Technology Partnerships, Amazon Web Services Japan G.K.