インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド3
今日もAWSについて書きます
ＮＦＳ Replica
共有コンテンツの複製
課題 ＮＦＳを用いて複数サーバー間でファイルを共有している場合、サーバーのアクセス数が増えてくるとＮＦＳのパフォーマンス劣化がある
解決 共有ファイルを保管するＮＦＳのパフォーマンス劣化に対し、参照性能を改善する
各サーバーに仮想ディスクを個別に用意し、ＮＦＳサーバーの共有ファイルをコピーしておく ➡ 仮想ディスクがＮＦＳの参照専用レプリカになる
実装
- ＥＣ２インスタンスの仮想ディスクであるＥＢＳに、ＮＦＳサーバーのファイルをコピー
- ＥＣ２はＥＢＳのファイルを読み取ることでＮＦＳサーバーにアクセスするよりも高いパフォーマンス。
- ＥＣ２上にＮＦＳサーバーを構築し、共有ファイルを配置
- Auto scaling で起動するEC2(webserver) は起動時にまずＮＦＳサーバーをマウントし、ＥＢＳに内容をコピー
- 各EC2上のアプリケーションはＥＢＳを参照先にしておく
利点
ＮＦＳサーバー上の共有ファイルを更新すれば、それ以降に起動したＥＣ２ではそのファイルが使われることになる
各ＥＣ２のＥＢＳに共有ファイルが存在するので、ＮＦＳサーバーにアクセスする必要がないのでパフォーマンスが気にならない
ＮＦＳサーバーがＳＰＯＦにならない
注意点
共有ファイルを更新する際、ＮＦＳサーバー上のファイルを更新するだけでは各ＥＣ２に反映されない
rsync などを用いて同期させる必要がある
その他
ローカルディスクとしてＥＢＳを用いる代わりに、インスタンスストレージ（ＥＣ２のローカルディスク）を利用するとパフォーマンスが上がる
State sharing
ステート情報の共有
課題 動的なコンテンツを生成するとき、ユーザー固有の情報（ＨＴＴＰ）を利用することが多い
ＥＬＢの配下で複数のサーバーを動作させているときに、各サーバーでステート情報を持ちようにすると、サーバー障害時や数を減らすときに消滅してしまう
解決 スケールアウト構成でステート情報を保持するためのもの
ステート情報を耐久性の高いデータストア（メモリー・ディスク）において、複数のサーバーからその情報を参照する
するとサーバーがステートレスになる
実装
ＡＷＳのデータストアには Elastic chache , Simple DB(KVS), DynamoDB (KVS)
- それぞれの要件にステート情報を格納するためのデータストアを準備する
- データストアにはユーザーを特定するＩＤ（セッションＩＤやユーザーＩＤ）をキーにして、ユーザー情報を値として格納
- ＷＥＢ／ＡＰサーバーに情報を保管せず、データストアに保管して参照・更新を行う
利点
ステート情報を気にせずにスケールアウトできる
注意
複数のサーバーからステート情報が１か所に集まるため、データストアがネックにならないようにする 一番いいのはＤynamicDB
要件によってはＲＤＳやＳ３も利用できる
URL rewriting
静的コンテンツの退避
課題 webサービスをＥＣ２で提供するとき、スケールアウトかスケールアップをするが、大半は、静的コンテンツのリクエストであることが多く、それをどう
分散するかは重要
解決 静的コンテンツ分散はＳ３を使う ➡ ①静的コンテンツのＵＲＬをＳ３のＵＲＬに変える必要がある
②webサーバーのフィルター機能を利用して配信時にＵＲＬを変える
③Ｓ３から配信する代わりにコンテンツ配信サーバーからの配信
実装
- ＥＣ２上の静的コンテンツ（ＪＳ／ＣＳＳ・画像）の一部をＳ３にアップロード（同期）する
- 必要に応じて、静的コンテンツが同期されるＳ３をオリジナルとしたCloudfrontを作成
- ＨＴＭＬタグ上の静的コンテンツのＵＲＬをＳ３、もしくはCloudfront のものに書き換える
- Apacheのフィルターモジュールやプロキシとして用意したNginxなどで動的に書き換えることも可能
利点
静的コンテンツのアクセスをＳ３かcloudfrontに分散することにより、負担に強くなり、またＥＣ２のコスト削減にも
Cloudfrontは 全世界配信で距離のレイテンシーを解決できる
Nginxを利用している場合はフィルターに入れることで、元のＨＴＭＬファイルに手を付けづにパターンを適用できる
フィルターをオフにすることでcloudfrontを使わないこともできる
注意点
cloudfrontを使う場合はコンテンツがキャッシュされてしまうため、削除や更新に時間がかかる
rewrite proxy
ＵＲＬ書き換えプロキシの設置
課題 静的コンテンツをＳ３に配置するとき、ＵＲＬをＳ３に変更する必要があり、 コンテンツ内のフィルター設定など既存のシステムを設定し直す必要がある
解決 プロキシサーバをコンテンツを格納したサーバーの前に設定し、ＵＲＬをＳ３やCloudfrontに変更する
実装
- apache や Nginx などでプロキシサーバーを構築し、既存システムの前に設置
- ＥＬＢとＳ３の間にプロキシサーバーを設置
- プロキシサーバーにコンテンツ内のＵＲＬ書き換えルールを追加
- 必要に応じて、Auto scaling を適用する
利点
プロキシサーバーでＵＲＬを書き換えることで既存のシステムを修正せずに静的コンテンツの負担分散が可能になる
注意
ＳＰＯＦを作らないようにするため、プロキシサーバーも冗長化しておく必要がある
WEB/APサーバーはＥＬＢに間接的に配置されるのでAuto scaling によってサーバー（ＥＣ２）が増減しても、ＥＬＢに自動的にアタッチできない
Cache proxy
キャッシュの設置
課題 サーバーを複数利用するとコストがかかる
解決 パフォーマンスを上げる方法でコンテンツをキャッシュ化する方法がある
変化のない動的、静的コンテンツをサーバーの上流でキャッシュし、 キャッシュの期限が切れるまで配信パフォーマンスの高い上流のキャッシュサーバーでコンテンツ配信を行う方法である。
クラウドは仮想サーバーを簡単に導入できるのでキャッシュサーバーがないシステムに対しても可能
実装
- ＥＣ２上に、 Varnishなどのキャッシュサーバーソフトをインストールして、利用
- サーバーの前に配置
- キャッシュサーバーにオリジナルデータのサーバーやキャッシュ期限を設定
利点
サーバーに触れずにキャッシュを用いたコンテンツ配信が可能
特に動的コンテンツの場合、コンテンツの生成の負担を削減
ＨＴＴＰのヘッダーやＵＲＬ、ＣＯＯＫＩＥなどでキャッシュ化の対象にしたり、しなかったりの設定が柔軟
注意点
ＳＰＯＦを作らないためにはキャッシュサーバーも冗長化する必要がある
サーバーとして利用しているＥＣ２はＥＬＢに間接的に配置されるのでキャッシュサーバーのアタッチには工夫が必要
Scheduled Scale out パターン
スケジュールに合わせたサーバー増減
解決 瞬間的にアクセスが増えるタイミングがわかっているときには スケジュール されたスケールアウトが有効 ➡ 時間帯を指定して実行
実装
- スケールアウトパターンでAuto scaling を設定する
- ＥＣ２インスタンスを増加させたい時間帯を指定し、インスタンスの最小台数で変更する
- 指定した時刻になると、起動する
- 設定したトリガーに従い、負担が落ち着いたら、スケールインする
利点
自動的に増減する
ＥＬＢ配下に必要な数のＥＣ２インスタンスを並べることができるので、スケールアップと並べると処理能力の限界は極めて高い
注意
指定する時間はＵＴＣ時間
ＥＣ２だけでなく、ＥＬＢもスケールアウトする必要がある。この場合、 プレウォーミングを申請
