CDP:Multi-Serverパターン

提供:AWS-CloudDesignPattern
移動: 案内, 検索
寄贈したアーキテクト

サーバーの冗長化

目次

解決したい課題

 可用性を高める方法はさまざまで、レイヤーごとに多様な方法がある。例えば、ディスクレイヤーではRAIDを構築したり、ネットワークレイヤーでは予備回線を用意したりする。

 サーバーも同様に、冗長化のために複数の物理サーバーを用意する方法がある。しかしながら、単にサーバーを増やすだけで冗長化構成が構築できるわけではない。また、サーバー機器やロードバランサーなど、冗長化に必要な機材を用意するのはかなりの費用がかかるので、費用対効果を鑑みると手が出せない場合もある。

クラウドでの解決/パターンの説明

 仮想サーバーを複数台並べ、クラウドサービスとして提供されるロードバランサーを用いて適宜負荷を振り分ける。これを「Multi-Server」と呼ぶ。オンプレミスでも実現できるが、クラウドではオンプレミスより格段に環境を整えやすい。

 以前はロードバランサー自体が高価なアプライアンスで、購入費用や保守費用が必要であった。クラウドではロードバランサーも従量課金で利用できる。また、単一の処理性能の高いサーバーから、冗長性を考慮して処理能力が少し低いサーバーを複数配置する構成に切り替えることも容易である。

実装

 AWSのロードバランサ―サービス「ELB」を利用する。EC2への処理要求をELBが一旦受け取り、ELBにひも付けられたEC2に適宜処理を振り分ける。ELBにはヘルスチェック機能(EC2が正常に稼働しているかどうかを確認する機能)があり、正常に稼働していないEC2には処理を振り分けない。従って、一つのEC2に障害が起きても、残りのEC2を使って処理を続行できる。

(手順)

  • EC2インスタンスを立ち上げてOSなどを設定する。
  • Stampパターンを適用し、EC2インスタンスを複数起動する。
  • ELBを起動し、複数のEC2インスタンスをひも付ける。
  • ヘルスチェック機能を利用し、ひも付けたEC2インスタンスのステータス確認を行うように設定する。

構造

6wNg0ISJczU5Pz1m-CC059.png

利点

  • あるEC2インスタンスに障害が起きたとしても、システム全体としては稼働を続けることができる。
  • ELBとAuto Scalingを組み合わせて使えば、障害が起こってもある一定数の仮想サーバー(EC2インスタンス)を稼働させることができる。例えば最低3台は稼働する設定としておけば、1つの仮想サーバーに障害が起きても、自動的に1台追加されて常に3台を保つようになる。その場合は、事前に適切なAMIを指定し、そのAMIからEC2を起動するように指定しておく必要がある。[関連ブログ 1]

注意点

  • ELBと複数のEC2を利用するので、単一構成よりコストがかかる。
  • ミドルウエアレベルやアプリケーションレベルで共有すべきデータがある場合は注意する。例えば、セッション情報は複数のEC2間で共有する必要があるので、セッションDBを使ったセッション共有やStickeySessionを使用する必要がある。「StateSharing」パターンを参照する。
  • 常にN+1(1台の予備を用意する)構成とする。例えば、処理能力として仮想サーバーが3台必要であれば、1台ダウンしてもいいように(1台の予備を入れて)4台構成にする。
  • データベースを冗長化する場合は、データの同期の問題がある。DB Replicationパターンを参照する。
  • VPCの中でも、インターナルなELBを用いることができるので、VPC内のトラフィックを複数のサーバーに分散して可用性を高めることができる。

その他

  • Multi-Serverパターンは常に冗長構成を保つことで可用性を高めているが、Floating IPパターンを用いることで、障害時の復旧を早くする方法もある。
  • 可用性を高めるパターンとしてMulti-Datacenterパターンも参照すること。

関連ブログ

  1. suz-lab - blog の「"Auto Scaling"でEC2を自動復旧」( http://blog.suz-lab.com/2012/04/auto-scalingec2.html )
個人用ツール
名前空間
変種
操作
CDPメニュー
ツールボックス