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

今日もAWSについて書きます

Deep health chech

システムのヘルスチェック

課題　ロードバランサーがＷＥＢサーバーの前にある場合、ＷＥＢサーバーが不調かどうかは把握できるが、それ以降の３つのサーバーの状態を把握できない。

解決策　クラウドのロードバランサーが持つヘルスチェック機能を使い、ＰＨＰやＪＡＶＡservlet　などの動的なページをチェックするように設定する。

　　　　それと同じプログラムで他の３つのサーバーの動作をチェックし、結果をロードバランサーに返す。

実装　　ＡＷＳのロードバランサーＥＬＢのヘルスチェック機能は指定のＵＲＬへのＨＴＴＰアクセスの成否によりステータスを確認。　これを利用してヘルスチェック先を動的なページに設定する。

　ＥＬＢを起動してヘルスチェック機能を有効にする
ＡＰサーバー上で動作するプログラムを作成。このプログラムはＤＢサーバーアクセスを伴う
ＥＬＢのヘルスチェックＵＲＬは２のプログラムで、設定したリクエストに対してプログラムが動くようにする
ＥＬＢからヘルスチェックを行う

利点　

システムの動作に必要なすべてのサーバーをチェックすることが可能

作り方によってはリクエストを受け付けないようにしたり、障害内容によってはカスタマイズされたエラー情報を出力したりすることが可能になる

注意点

サーバー数が多いとき、ヘルスチェック自体が負担になるのでチェックの時間間隔を考慮する

ＤＢサーバーがＳＰＯＦになっている場合、そこがダウンすると過剰反応して、すべてのサーバーを停止させてしまうかも

ＤＢサーバー部分がＳＰＯＦにならないように、ＤＢ　replication パターンを併用することがいい

動的コンテンツの処理

Scale out

サーバー数の動的増減

課題　スケールアップ（高スペックのサーバーで処理能力を高めること）は処理単価が高くなる

　　　　サーバーのスペックには限界があ、無制限にあげられない。

解決

スケールアウト（同じようなスペックのサーバーを複数台並べる）

クラウドでは変動が激しいトラフィックの変化に柔軟に対応できる。

実装　　ＥＬＢとCloudwatch と　Auto scaling の３つのサービスを組み合わせることによって、負担に合わせて自動でスケールアウトできるシステム

ＥＬＢに（ＷＥＢ／ＡＰサーバーとして）ＥＣ２を複数並べる
ＥＣ２を新たに起動するときに利用するＡＭＩを作成
ＥＣ２を増減させる条件の定義をする　➡　ＥＣ２の平均ＣＰＵ使用率、ネットワーク流量、セッション数、ＥＢＳのレイテンシーなどがよく使われる
条件をcloudwatchを使って監視し、一定の条件を満たすとアラームが鳴るように設定
アラームを受けた際、Auto scaling　がＥＣ２数を増減するように設定する
例えば　ＣＰＵ使用率が７０％以上の状態が５分以上続いたらあらかじめ用意していたＡＭＩを使ってＥＣ２インスタンスを２つ起動する。など

利点

トラフィック数の増大に合わせて自動的にＥＣ２インスタンスを増やすことができるので、サービスの継続につながる

コスト削減

運用の手間が省ける

ＥＬＢの下に必要な数だけＥＣ２インスタンスを並べることができるので、スケールアップに比べると処理能力は極めて高い

注意点

数分間でトラフィックが数倍になるような急激なトラフィックの変動には対処できない➡　判断してから実際に増やすためには時間がかかるため

特定の時間帯になると増えるように設定しておく　　

あらかじめ余分なＥＣ２インスタンスを用意して負担に耐えられるようにしておき、その後、不要な分のＥＣ２インスタンスを減らす

ＨＴＴＰセッション管理やＳＳＬ処理などＥＬＢに任せるか、サーバーで処理するのか考慮する

ＥＬＢにはスペックに応じて分散量を変える仕組みは備わっていないので、インスタンスタイプは統一したほうがいい

WEB/APサーバーのレイヤーに比べ、ＤＢサーバーレイヤーのスケールアウトは一般に難しい

耐障害性を高めるためにも複数のＡＺに分散してスケールアウトさせたほうが良い。　増加させるインスタンス数はＡＺ数の倍数にしておくとよい。

Clone server

課題　　スケールアウト構成ではスモールスタートの時に複数のサーバーを提供できる構成になっていないことが多い。必要な時に時間がかかる

解決　　負担分散が考慮されていないシステムを簡単に負担分さん可能なシステムにする。　常にあるサーバーをマスターとして、追加するＡＭＩを用意する

　　　　コンテンツ同期やデータベース接続の調整を行っておく。ＡＭＩを起動しただけで、スケールアウトによる負担分散が可能になる

実装　　ＥＬＢ　と　ＡＭＩを利用　　

　　　　　コンテンツ同期の準備が整ったＡＭＩを作成し、負担が重くなれば、クローン用のＡＭＩからＥＣ２インスタンスを起動する。

ＥＬＢを立ち上げて、ＥＣ２を配下に置く
現在稼働しているＥＣ２からクローンＥＣ２を作成し、ＥＬＢの配下に加える
クローン用ＥＣ２は必要に応じて定期的にrsyncなどを用いてマスターＥＣ２のファイルを同期するようにしておく
負担に伴い、必要な数のクローン用のＥＣ２を稼働させ、ＥＬＢに追加する

利点

現状のシステムを変更することなく、容易にスケールアウトによる負担分散を行うことができる

注意点

マスターＥＣ２がＳＰＯＦになっていまう

マスターＥＣ２でデータベースが動作している場合、クローンＥＣ２をデータベースに接続せず、データベースはマスターＥＣ２に接続

ファイルのアップロードや書き込みは、処理をマスターＥＣ２で行う　（apache のmod-proxy を用いて、該当のＵＲＬだけクローン用の仮想サーバーからマスターにつなげる）

ＮＦＳ　sharing

共有コンテンツの利用

複数サーバーで負担分散した場合、コンテンツを同期させなければならない

マスターからスレーブに同期するときに遅れることがよく問題になる

もし、スレーブサーバーに書き込みが発生するとほかの者に反映されない

実装

ＮＦＳサーバーをＥＣ２上に構築
共有したいコンテンツをＮＦＳサーバーに配置
スケールアウトするサーバーたちからＮＦＳサーバーのコンテンツを参照するようにする

利点

共有コンテンツをＮＦＳに置くことでリアルタイムに共有できる

セットアップが楽

注意点

更新頻度の高いものはＮＦＳでの共有を用いるといい

ＮＦＳサーバーの管理が必要

ＥＣ２インスタンスが多くなるとＮＦＳアクセスのパフォーマンスの考慮がいる

ＮＦＳサーバーがＳＰＯＦになるのを防ぐためにGlusterFS などのソリューションを検討