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

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

AWS最終章です
静的コンテンツの処理
 
可用性の高いS3活用
 
課題  動画や高画質の画像やZIPなどの容量の大きいファイルを1台のサーバーから配信するためには負担が大きいので複数のサーバーで負担を
    分散するのだが、コストが気になる
 
解決  大容量のファイルをS3に配信し、そこから直接ファイルを配信することで、ネットワークの負担とS3の容量の問題を解決する
     S3に保存したオブジェクトは公開設定にすることでユーザーに直接アクせすされる
     配信ファイルを同期するためにEC2間でファイルのコピーも不必要になる
 
実装 
 
  1. 配信したいコンテンツをS3に配置➡ ユーザーが直接ダウンロードできるようになる
  2. S3にパケットを作成し、公開するコンテンツを入れる
  3. 公開設定でコンテンツごとのURLが発行される
  4. 発行されるURLをユーザに提供するか、リンクを張る
 
利点
S3を使えば、ネットワーク負担やデータ容量を気にする必要がない
S3は3か所以上のデータセンターでバックアップをしているので耐久性がたかい
各コンテンツにURLがあるので、ファイルをS3に置くだけでファイルの共有など広範囲なことにOK
 
ちゅういてん
 
S3のコンテンツは独自のDNS名を付ける必要がある
 

Direct hosting
S3で直接ホスティング
 
課題   短期間の急激アクセス数増加に対して見積もっておく必要があるが、無駄にサーバーを増やすとコストがかかる
 
解決 S3をサーバーとして活用し、動画や静的ファイルをホスティングする  ➡ S3には負担の限界がないので、対策がいらない
 
実装 
  1. S3にバケットを入れコンテンツを公開するように設定
  2. S3のwebサイトホスティング機能をオンにして、インデックスページや、エラーページを設定することでS3単体でwebサイト単体でホストできる
利点
 
静的コンテンツへのアクセスをS3に任せることでwebシステムの可溶性と耐久性を簡単に高めることができる。
 
注意
 
S3ではサーバーサイドのプログラムを動かすことはできないので、ログインユーザーごとに異なるページを出せない
S3から配信したコンテンツにJSを埋め込み、非同期通信で別のサーバーからデータを取得したい場合、データ取得先のサーバーとDNSが異なるため
JSONPで通信
 

Private distribution
特定のユーザーへのデータ配布
 
課題  S3は可用性や耐久性に問題ないが、特定のユーザーにのみ配布するときに制限するのは難しい
 
解決 S3で提供される制限付きURL発行機能を使うと、アクセス元のIPアドレスに対してアクセス可能期間を設定できる。
    期限が切れたものや異なるIPアドレスを持つ人はダウンロードできない
 
実装
 
  1. S3のapitool や AWS SDKを準備する
  2. 自らのシステムでユーザー認証を実施後、ユーザーに公開するコンテンツに対して、APIで制限つきURLを生成
  3. 生成したURL一覧で動的にwebページを生成  制限付きのURLをリンク先として利用する
利点
 
特定のユーザーだけが使えるので、プライベートコンテンツの配信に便利
実際のコンテンツダウンロードは、EC2を通さず、直接S3からなので、S3の特性を活用できる
 

cache distribution 
ユーザーの物理的に近い位置へのデータ配置
 
課題 ユーザーエクスペリエンスの観点でいえば、距離が生じると、通信遅延が発生する
   
解決 コンテンツのキャッシュデータを利用する➡物理的に利用者に近いロケーションからコンテンツを配信できる
 
実装
 
AWSのCloudfront で世界中のキャッシュサーバーを利用
 
  1. オリジンサーバーを使用するようにcloudfrontを設定する➡DNS名が発行される
  2. 独自のドメイン名を使ってよい➡ オリジンサーバーのDNS名のレコードに発行されるDNS名
利点
 
地理的に離れたユーザーにより良いユーザーエクスペリエンスを提供できる
ファイル負担分散効果がある  (ファイルダウンロード処理を分散)
既存サーバー(オンプレやホスティングなどEC2以外のサーバー)をオリジンサーバーにすることで、既存サーバーを生かしながら、パターンを適用可能
S3をオリジンサーバーにできる
 
注意
 
キャッシュサーバーではオリジンサーバー(配信限)のキャッシュタイムアウト設定に基づいてキャッシングを行うのでキャッシュタイムアウト前に
更新してもキャッシュサーバーは変更されないかも、
 

Rename distribution
 
課題 cache  distribution を使用してコンテンツ配信する場合、オリジンサーバーを変更しても、エッジサーバー(cloudfront)のデータはタイムアウトになるまで更新されない
 
解決 URLがカギになる   更新したいファイルを違うファイル名で配置して、アクセスURL自体を変更することで常に新しいコンテンツを配信できる
 
実装   
 
  1. コンテンツとは別にベースコンテンツ(URLを含むHTMLファイル)を作成
  2. ベースコンテンツはキャッシュタイムを短くするか、常にオリジンサーバーから配信
  3. cloudfrontのときは、別名のURLでオリジンサーバーにも配備
  4. ベースコンテンツ内のURLを新しいコンテンツのURLへ変更する
利点
   キャッシュタイムアウトを待たずに新しいコンテンツを配信できる
 
注意点
 
ベースコンテンツのキャッシュタイムアウトを短く設定する必要があるが、キャッシュ効果が薄くなる
古いファイルはキャッシュタイムアウトまでエッジサーバーに残るので必要ならば消す
 

Private cache distribution
CDN を用いたプライベート配信
 
課題  特定のユーザーに配信する場合、利用者を認証する必要がある
 
解決 署名付きURL認証機能  ( アクセス元IPアドレス、 ダウンロード可能期間 アクセス元地域) などで分別
  ➡より高い精度で特定のユーザーへの配信が可能になる
 
実装
  1. cloudfront  apitool  or AWS SDK
  2. EC2 のサーバーに秘密鍵登録して、署名付きURLの発行準備
  3. ユーザー認証をして、cloudfrontでAPIを用いて署名付きURL制作機能を利用
  4. URLをリンク先として利用
利点
IPアドレスと地域で特定されるユーザーのみ利用できる
実際のコンテンツダウンロードは直接cloudfrontから行うので負担と障害に強い
 
注意
 
認証システムや期限付きURLを発行するサーバーが必要になる
ユーザー認証が切れていなくても、URLの有効期限が切れるとダウンロードできなくなる