読者です 読者をやめる 読者になる 読者になる

インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド2

今日もAWSについて書きます
Deep health chech 
システムのヘルスチェック
 
課題 ロードバランサーがWEBサーバーの前にある場合、WEBサーバーが不調かどうかは把握できるが、それ以降の3つのサーバーの状態を把握できない。
 
解決策 クラウドロードバランサーが持つヘルスチェック機能を使い、PHPやJAVAservlet などの動的なページをチェックするように設定する。
    それと同じプログラムで他の3つのサーバーの動作をチェックし、結果をロードバランサーに返す。
 
実装  AWSのロードバランサーELBのヘルスチェック機能は指定のURLへのHTTPアクセスの成否によりステータスを確認。 これを利用してヘルスチェック先を動的なページに設定する。
 
  1.  ELBを起動してヘルスチェック機能を有効にする
  2. APサーバー上で動作するプログラムを作成。このプログラムはDBサーバーアクセスを伴う
  3. ELBのヘルスチェックURLは2のプログラムで、設定したリクエストに対してプログラムが動くようにする
  4. ELBからヘルスチェックを行う
利点 
システムの動作に必要なすべてのサーバーをチェックすることが可能
作り方によってはリクエストを受け付けないようにしたり、障害内容によってはカスタマイズされたエラー情報を出力したりすることが可能になる
 
注意点
 
サーバー数が多いとき、ヘルスチェック自体が負担になるのでチェックの時間間隔を考慮する
DBサーバーがSPOFになっている場合、そこがダウンすると過剰反応して、すべてのサーバーを停止させてしまうかも
DBサーバー部分がSPOFにならないように、DB replication パターンを併用することがいい
 

動的コンテンツの処理
 
Scale out 
サーバー数の動的増減
 
課題 スケールアップ(高スペックのサーバーで処理能力を高めること)は処理単価が高くなる
    サーバーのスペックには限界があ、無制限にあげられない。
 
解決
スケールアウト(同じようなスペックのサーバーを複数台並べる)
クラウドでは変動が激しいトラフィックの変化に柔軟に対応できる。
 
実装  ELBとCloudwatch と Auto scaling の3つのサービスを組み合わせることによって、負担に合わせて自動でスケールアウトできるシステム
 
  1. ELBに(WEB/APサーバーとして)EC2を複数並べる
  2. EC2を新たに起動するときに利用するAMIを作成
  3. EC2を増減させる条件の定義をする ➡ EC2の平均CPU使用率、ネットワーク流量、セッション数、EBSのレイテンシーなどがよく使われる
  4. 条件をcloudwatchを使って監視し、一定の条件を満たすとアラームが鳴るように設定
  5. アラームを受けた際、Auto scaling がEC2数を増減するように設定する
  6. 例えば CPU使用率が70%以上の状態が5分以上続いたらあらかじめ用意していたAMIを使ってEC2インスタンスを2つ起動する。など
利点
トラフィック数の増大に合わせて自動的にEC2インスタンスを増やすことができるので、サービスの継続につながる
コスト削減
運用の手間が省ける
ELBの下に必要な数だけEC2インスタンスを並べることができるので、スケールアップに比べると処理能力は極めて高い
 
注意点
 
数分間でトラフィックが数倍になるような急激なトラフィックの変動には対処できない➡ 判断してから実際に増やすためには時間がかかるため
特定の時間帯になると増えるように設定しておく  
あらかじめ余分なEC2インスタンスを用意して負担に耐えられるようにしておき、その後、不要な分のEC2インスタンスを減らす
HTTPセッション管理やSSL処理などELBに任せるか、サーバーで処理するのか考慮する
ELBにはスペックに応じて分散量を変える仕組みは備わっていないので、インスタンスタイプは統一したほうがいい
WEB/APサーバーのレイヤーに比べ、DBサーバーレイヤーのスケールアウトは一般に難しい
耐障害性を高めるためにも複数のAZに分散してスケールアウトさせたほうが良い。 増加させるインスタンス数はAZ数の倍数にしておくとよい。
 

Clone server

 
課題  スケールアウト構成ではスモールスタートの時に複数のサーバーを提供できる構成になっていないことが多い。必要な時に時間がかかる
 
解決  負担分散が考慮されていないシステムを簡単に負担分さん可能なシステムにする。 常にあるサーバーをマスターとして、追加するAMIを用意する
    コンテンツ同期やデータベース接続の調整を行っておく。AMIを起動しただけで、スケールアウトによる負担分散が可能になる
 
実装  ELB と AMIを利用  
     コンテンツ同期の準備が整ったAMIを作成し、負担が重くなれば、クローン用のAMIからEC2インスタンスを起動する。
 
  1. ELBを立ち上げて、EC2を配下に置く
  2. 現在稼働しているEC2からクローンEC2を作成し、ELBの配下に加える
  3. クローン用EC2は必要に応じて定期的にrsyncなどを用いてマスターEC2のファイルを同期するようにしておく
  4. 負担に伴い、必要な数のクローン用のEC2を稼働させ、ELBに追加する
利点
現状のシステムを変更することなく、容易にスケールアウトによる負担分散を行うことができる
 
 
注意点
マスターEC2がSPOFになっていまう
マスターEC2でデータベースが動作している場合、クローンEC2をデータベースに接続せず、データベースはマスターEC2に接続
ファイルのアップロードや書き込みは、処理をマスターEC2で行う (apache のmod-proxy を用いて、該当のURLだけクローン用の仮想サーバーからマスターにつなげる)
 

NFS sharing 
共有コンテンツの利用
 
複数サーバーで負担分散した場合、コンテンツを同期させなければならない
マスターからスレーブに同期するときに遅れることがよく問題になる
もし、スレーブサーバーに書き込みが発生するとほかの者に反映されない
 
実装
  1. NFSサーバーをEC2上に構築
  2. 共有したいコンテンツをNFSサーバーに配置
  3. スケールアウトするサーバーたちからNFSサーバーのコンテンツを参照するようにする
利点
共有コンテンツをNFSに置くことでリアルタイムに共有できる
セットアップが楽
 
注意点
更新頻度の高いものはNFSでの共有を用いるといい
NFSサーバーの管理が必要
EC2インスタンスが多くなるとNFSアクセスのパフォーマンスの考慮がいる
NFSサーバーがSPOFになるのを防ぐためにGlusterFS などのソリューションを検討