[クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す!〜]

AWSでシステムの可用性を高める【第1回】

2017年3月13日(月)清野 剛史(クラスメソッドAWS事業部ソリューションアーキテクト)

AWS(Amazon Web Services)はパブリッククラウドサービスの先陣を走り、利用企業にとってAWSを使ってサービスを構築・運用することが大きな武器になる。しかし、その活用には、オンプレミスのシステムとは異なる視点や勘所がある。今回は、企業システムにおいて欠かせない非機能要件の1つである「可用性」を高めるための方法について説明する。

スコープ1:Auto Scalingによるサーバー単位の可用性

図2:サーバー台数を複数用意して可用性を確保する図2:サーバー台数を複数用意して可用性を確保する
拡大画像表示

 最初に考えるべきは「サーバー自体の台数を増やす」ということだ。同じデータを参照し、同じ処理が走るサーバーを複数用意して可用性を確保する(図2)。

 この場合に注意すべきポイントは以下である。

●リクエストの受け口として、ロードバランサーの「ELB」や「ALB」などを配置し、リクエストを適切にバランシングさせる

●セッション情報が正しく引き継がれる用にELBの「Sticky Session」機能を使用する

●個別のサーバー内に独自のデータを保存するような仕様にはしない。ファイル保存が必要な場合は、共有ストレージとして「EFS(Elastic File System)」や「S3」を利用する

 このようにしてサーバーを冗長化させておくと、個別のサーバーに障害が発生した時も自動で対応できるようになる。Auto ScalingとしてEC2を配置しておけば、障害が発生したEC2を自動的に破棄し、新しいEC2に交換してくれる。監視サービスである「CloudWatch」と連携させておけば障害時を知らせるメールを管理者に出せる。

スコープ2:Multi-AZによるデータセンター単位の可用性

図3:複数のAvailability Zoneにシステムを分散させて可用性を確保する図3:複数のAvailability Zoneにシステムを分散させて可用性を確保する
拡大画像表示

 何かしらのネットワーク障害や自然災害により「Availability Zone」と呼ばれるデータセンターへのアクセスが、まるごと寸断される可能性を考える。この場合に有効なのは「Multi-AZ(Availability Zone)」という複数のAvailability Zoneにシステムを分散させて配置することで、データセンター単位の可用性を確保するという方法だ(図3)。

 RDSにはMulti-AZというオプションが最初から用意されている。チェックボックスをオンにするだけでMaster-Slave構成にレプリケートされたデータベースが簡単に構築できる。RDSのMulti-AZは、RDSに障害が発生した時のみSlave側のデータベースに自動的に切り替えサービスを継続する機能だ。だが、多くのリクエストをさばくための参照用レプリカ「Read Replica」もワンクリックで作成できる。Read Replicaを併用すれば、より可用性の高いシステムを構築できる。

バックナンバー
クラウド活用パターン辞典〜Amazon Web Servicesを使い倒す!〜一覧へ
関連記事

AWSでシステムの可用性を高める【第1回】 [ 2/3 ] AWS(Amazon Web Services)はパブリッククラウドサービスの先陣を走り、利用企業にとってAWSを使ってサービスを構築・運用することが大きな武器になる。しかし、その活用には、オンプレミスのシステムとは異なる視点や勘所がある。今回は、企業システムにおいて欠かせない非機能要件の1つである「可用性」を高めるための方法について説明する。

PAGE TOP