オンプレミスで稼働していたシステムをパブリッククラウドに移行したいが、可用性やセキュリティが心配―。このように考えるユーザーは何に注意すべきか。Amazon Web Services(AWS)を例に、基幹系の基盤として活用する際に押さえておくべきポイントを、AWSの専門家が解説する。


 読者のみなさんはAmazon Web Services(AWS)が登場したきっかけを、ご存知だろうか。2003年、米Amazon.comのインフラ管理を担当していたChris Pinkham氏とBenjamin Black氏が社内向けに書いたショートペーパーがその1つと言われている。ショートペーパーはAmazon.comのインフラストラクチャーの未来について記し、その内容は「完全に標準化、自動化され、ストレージのようなものは広範囲にわたってWebサービスとして利用される」というものだった。

 Amazon.comのCEO(最高経営責任者)であるJeff Bezos氏はこのショートペーパーを気に入り、その実現に向けてインフラストラクチャーを拡充。その結果、後にAmazon社内だけでなく、世界中で利用されるAWSへと進化した。

 そして今ではAWSは、大企業の基幹系システムのインフラとしても利用されるようになった。ユーザー企業はAWSを利用することで、サーバーの調達コストを抑えられ、大切な時間を真に価値ある仕事に割り当てることができるようになっている。

 ITエンジニアにとって強力な道具となるAWSだが、上手に活用できなければ宝の持ち腐れになってしまう。初めてAWSにアクセスした人の中には、あまりのサービス数の多さに圧倒される人も少なくない。そのためか「AWSを使うのは難しい」というイメージもあるようだ。

 しかし基本的な考え方が分かればAWSを基幹系システムで使うことは難しくない。「責任共有モデル」や「Design for failure」いったクラウド独自の考え方が分かれば、エンジニアにとって面白い世界が広がる。以下では、AWSを基幹系システムで利用するうえで、欠かせない考え方を紹介していく。

99.99%は「努力目標」

 オンプレミスで稼働していた基幹系システムをAWSに移行する際に、可用性や信頼性の確保は重要なポイントの1つになる。

 AWSの仮想マシンサービス「Elastic Compute Cloud(EC2)」の場合、サービスレベルアグリーメント(SLA)では「月間使用可能時間の割合が99.99%以上(2017年11月に99.95%から変更)」というサービスコミットメントが明示してある。それを守れなかった場合には「次期の支払いに使える使用量の割引率」であるサービスクレジットも定義されている。

 しかしこのSLAはあくまでAWS側の「合理的な努力目標」であり、サービス品質を保証するものではない。そのため基幹系システムでのAWS利用に際して高い可用性を目指すには、利用者自身でシステム構成を工夫する必要が出てくる。構成で特に気を付けたいのが、基幹系システムでよく利用されるEC2と、AWSの利用には欠かせないネットワークだ。

「複数のAZ」で冗長化

 まずはAWSの基本的な構成をおさらいしよう。AWSはリソースを動かすリージョン(地域)を世界中から選択できる。各リージョンは、複数の「アベイラビリティーゾーン(AZ)」で構成されており、AZは1つ以上の独立したデータセンター(DC)から成っている。

 AWSを使ったシステムの信頼性を高めるには、「同じ役割を持つEC2を複数のAZに配置し、冗長構成にする」ことが基本的な考え方となる。加えて冗長構成を採った際に、クライアントから見て複数のAZに配置したEC2を「あたかも1つの接続先に見えるようにする」作業が必要になる。言い換えれば、複数のEC2インスタンスを何らかの方法で1つに束ねなければならない。代表的な方法がロードバランサーの利用と、ソフトウエアの利用だ。

 ロードバランサーを利用した冗長化は、複数のEC2の前段にロードバランサーを配置し、クライアントからロードバランサーの提供する接続先を指定する方法だ。AWSが提供する高可用性のロードバランサー「Elastic Load Balancing(ELB)」を利用できる。

ロードバランサーを使った冗長構成の例

この先は会員の登録が必要です。今なら有料会員(月額プラン)は12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら