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

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

今日もAWSについて書きます
NFS Replica
共有コンテンツの複製
 
課題  NFSを用いて複数サーバー間でファイルを共有している場合、サーバーのアクセス数が増えてくるとNFSのパフォーマンス劣化がある
 
解決  共有ファイルを保管するNFSのパフォーマンス劣化に対し、参照性能を改善する
    各サーバーに仮想ディスクを個別に用意し、NFSサーバーの共有ファイルをコピーしておく ➡ 仮想ディスクがNFSの参照専用レプリカになる
 
実装 
  1. EC2インスタンスの仮想ディスクであるEBSに、NFSサーバーのファイルをコピー
  2.    EC2はEBSのファイルを読み取ることでNFSサーバーにアクセスするよりも高いパフォーマンス。
  3.    EC2上にNFSサーバーを構築し、共有ファイルを配置
  4.    Auto scaling で起動するEC2(webserver) は起動時にまずNFSサーバーをマウントし、EBSに内容をコピー
  5.    各EC2上のアプリケーションはEBSを参照先にしておく
利点
 
NFSサーバー上の共有ファイルを更新すれば、それ以降に起動したEC2ではそのファイルが使われることになる
各EC2のEBSに共有ファイルが存在するので、NFSサーバーにアクセスする必要がないのでパフォーマンスが気にならない
NFSサーバーがSPOFにならない
 
注意点
 
共有ファイルを更新する際、NFSサーバー上のファイルを更新するだけでは各EC2に反映されない
rsync などを用いて同期させる必要がある
 
その他
 
ローカルディスクとしてEBSを用いる代わりに、インスタンスストレージ(EC2のローカルディスク)を利用するとパフォーマンスが上がる
 
 
 

State sharing 
ステート情報の共有
 
課題  動的なコンテンツを生成するとき、ユーザー固有の情報(HTTP)を利用することが多い
    ELBの配下で複数のサーバーを動作させているときに、各サーバーでステート情報を持ちようにすると、サーバー障害時や数を減らすときに消滅してしまう
 
解決  スケールアウト構成でステート情報を保持するためのもの
    ステート情報を耐久性の高いデータストア(メモリー・ディスク)において、複数のサーバーからその情報を参照する
    するとサーバーがステートレスになる
 
実装
    AWSのデータストアには Elastic chache , Simple DB(KVS), DynamoDB (KVS)
  1.     それぞれの要件にステート情報を格納するためのデータストアを準備する
  2. データストアにはユーザーを特定するID(セッションIDやユーザーID)をキーにして、ユーザー情報を値として格納
  3. WEB/APサーバーに情報を保管せず、データストアに保管して参照・更新を行う
利点
ステート情報を気にせずにスケールアウトできる
 
注意
 
複数のサーバーからステート情報が1か所に集まるため、データストアがネックにならないようにする 一番いいのはDynamicDB
要件によってはRDSやS3も利用できる
                                                          
URL rewriting 
静的コンテンツの退避
 
課題  webサービスをEC2で提供するとき、スケールアウトかスケールアップをするが、大半は、静的コンテンツのリクエストであることが多く、それをどう
    分散するかは重要
 
解決  静的コンテンツ分散はS3を使う ➡ ①静的コンテンツのURLをS3のURLに変える必要がある
                      ②webサーバーのフィルター機能を利用して配信時にURLを変える
                      ③S3から配信する代わりにコンテンツ配信サーバーからの配信
実装 
  1. EC2上の静的コンテンツ(JS/CSS・画像)の一部をS3にアップロード(同期)する
  2. 必要に応じて、静的コンテンツが同期されるS3をオリジナルとしたCloudfrontを作成
  3. HTMLタグ上の静的コンテンツのURLをS3、もしくはCloudfront のものに書き換える
  4. Apacheのフィルターモジュールやプロキシとして用意したNginxなどで動的に書き換えることも可能
利点
静的コンテンツのアクセスをS3かcloudfrontに分散することにより、負担に強くなり、またEC2のコスト削減にも
Cloudfrontは 全世界配信で距離のレイテンシーを解決できる
Nginxを利用している場合はフィルターに入れることで、元のHTMLファイルに手を付けづにパターンを適用できる
フィルターをオフにすることでcloudfrontを使わないこともできる
 
注意点
cloudfrontを使う場合はコンテンツがキャッシュされてしまうため、削除や更新に時間がかかる
 

rewrite proxy 
URL書き換えプロキシの設置
 
課題  静的コンテンツをS3に配置するとき、URLをS3に変更する必要があり、 コンテンツ内のフィルター設定など既存のシステムを設定し直す必要がある
 
解決   プロキシサーバをコンテンツを格納したサーバーの前に設定し、URLをS3やCloudfrontに変更する
 
実装  
  1. apache や Nginx などでプロキシサーバーを構築し、既存システムの前に設置
  2. ELBとS3の間にプロキシサーバーを設置
  3. プロキシサーバーにコンテンツ内のURL書き換えルールを追加
  4. 必要に応じて、Auto scaling を適用する
利点
プロキシサーバーでURLを書き換えることで既存のシステムを修正せずに静的コンテンツの負担分散が可能になる
 
注意
 
SPOFを作らないようにするため、プロキシサーバーも冗長化しておく必要がある
WEB/APサーバーはELBに間接的に配置されるのでAuto scaling によってサーバー(EC2)が増減しても、ELBに自動的にアタッチできない
 

Cache proxy 
キャッシュの設置
 
課題  サーバーを複数利用するとコストがかかる
 
解決  パフォーマンスを上げる方法でコンテンツをキャッシュ化する方法がある
    変化のない動的、静的コンテンツをサーバーの上流でキャッシュし、 キャッシュの期限が切れるまで配信パフォーマンスの高い上流のキャッシュサーバーでコンテンツ配信を行う方法である。
  クラウドは仮想サーバーを簡単に導入できるのでキャッシュサーバーがないシステムに対しても可能
 
実装 
  1. EC2上に、 Varnishなどのキャッシュサーバーソフトをインストールして、利用
  2. サーバーの前に配置
  3. キャッシュサーバーにオリジナルデータのサーバーやキャッシュ期限を設定
利点
 
サーバーに触れずにキャッシュを用いたコンテンツ配信が可能
特に動的コンテンツの場合、コンテンツの生成の負担を削減
HTTPのヘッダーやURL、COOKIEなどでキャッシュ化の対象にしたり、しなかったりの設定が柔軟
 
注意点
 
SPOFを作らないためにはキャッシュサーバーも冗長化する必要がある
サーバーとして利用しているEC2はELBに間接的に配置されるのでキャッシュサーバーのアタッチには工夫が必要
 

Scheduled Scale out パターン
 
スケジュールに合わせたサーバー増減
 
課題   クラウド環境で構築された中で、高いトラフィックを処理する場合、スケールアウトが効果的
    急激(5分以内にトラフィックが倍増するようなケース)アクセス増の時にインスタンスの起動が追いつかない
 
解決  瞬間的にアクセスが増えるタイミングがわかっているときには スケジュール されたスケールアウトが有効  ➡ 時間帯を指定して実行
 
実装  
 
  1. スケールアウトパターンでAuto scaling を設定する
  2. EC2インスタンスを増加させたい時間帯を指定し、インスタンスの最小台数で変更する
  3. 指定した時刻になると、起動する
  4. 設定したトリガーに従い、負担が落ち着いたら、スケールインする
利点
自動的に増減する
ELB配下に必要な数のEC2インスタンスを並べることができるので、スケールアップと並べると処理能力の限界は極めて高い
 
注意
 
指定する時間はUTC時間
EC2だけでなく、ELBもスケールアウトする必要がある。この場合、 プレウォーミングを申請