インフラエンジニアへの道 Amazon web services クラウドデザインパターン 設計ガイド4
AWS最終章です
静的コンテンツの処理
可用性の高いＳ３活用
課題 動画や高画質の画像やＺＩＰなどの容量の大きいファイルを１台のサーバーから配信するためには負担が大きいので複数のサーバーで負担を
分散するのだが、コストが気になる
解決 大容量のファイルをＳ３に配信し、そこから直接ファイルを配信することで、ネットワークの負担とＳ３の容量の問題を解決する
Ｓ３に保存したオブジェクトは公開設定にすることでユーザーに直接アクせすされる
配信ファイルを同期するためにＥＣ２間でファイルのコピーも不必要になる
実装
- 配信したいコンテンツをＳ３に配置➡ ユーザーが直接ダウンロードできるようになる
- Ｓ３にパケットを作成し、公開するコンテンツを入れる
- 公開設定でコンテンツごとのＵＲＬが発行される
- 発行されるＵＲＬをユーザに提供するか、リンクを張る
利点
Ｓ３を使えば、ネットワーク負担やデータ容量を気にする必要がない
Ｓ３は３か所以上のデータセンターでバックアップをしているので耐久性がたかい
各コンテンツにＵＲＬがあるので、ファイルをＳ３に置くだけでファイルの共有など広範囲なことにＯＫ
ちゅういてん
Ｓ３のコンテンツは独自のＤＮＳ名を付ける必要がある
Direct hosting
Ｓ３で直接ホスティング
課題 短期間の急激アクセス数増加に対して見積もっておく必要があるが、無駄にサーバーを増やすとコストがかかる
解決 Ｓ３をサーバーとして活用し、動画や静的ファイルをホスティングする ➡ Ｓ３には負担の限界がないので、対策がいらない
実装
- Ｓ３にバケットを入れコンテンツを公開するように設定
- Ｓ３のwebサイトホスティング機能をオンにして、インデックスページや、エラーページを設定することでＳ３単体でwebサイト単体でホストできる
利点
静的コンテンツへのアクセスをＳ３に任せることでwebシステムの可溶性と耐久性を簡単に高めることができる。
注意
Ｓ３ではサーバーサイドのプログラムを動かすことはできないので、ログインユーザーごとに異なるページを出せない
Ｓ３から配信したコンテンツにＪＳを埋め込み、非同期通信で別のサーバーからデータを取得したい場合、データ取得先のサーバーとＤＮＳが異なるため
ＪＳＯＮＰで通信
Private distribution
特定のユーザーへのデータ配布
課題 Ｓ３は可用性や耐久性に問題ないが、特定のユーザーにのみ配布するときに制限するのは難しい
解決 Ｓ３で提供される制限付きＵＲＬ発行機能を使うと、アクセス元のＩＰアドレスに対してアクセス可能期間を設定できる。
期限が切れたものや異なるＩＰアドレスを持つ人はダウンロードできない
実装
- Ｓ３のapitool や ＡＷＳ ＳＤＫを準備する
- 自らのシステムでユーザー認証を実施後、ユーザーに公開するコンテンツに対して、ＡＰＩで制限つきＵＲＬを生成
- 生成したＵＲＬ一覧で動的にwebページを生成 制限付きのＵＲＬをリンク先として利用する
利点
特定のユーザーだけが使えるので、プライベートコンテンツの配信に便利
実際のコンテンツダウンロードは、ＥＣ２を通さず、直接Ｓ３からなので、Ｓ３の特性を活用できる
cache distribution
ユーザーの物理的に近い位置へのデータ配置
課題 ユーザーエクスペリエンスの観点でいえば、距離が生じると、通信遅延が発生する
解決 コンテンツのキャッシュデータを利用する➡物理的に利用者に近いロケーションからコンテンツを配信できる
実装
ＡＷＳのCloudfront で世界中のキャッシュサーバーを利用
- オリジンサーバーを使用するようにcloudfrontを設定する➡ＤＮＳ名が発行される
- 独自のドメイン名を使ってよい➡ オリジンサーバーのＤＮＳ名のレコードに発行されるＤＮＳ名
利点
地理的に離れたユーザーにより良いユーザーエクスペリエンスを提供できる
ファイル負担分散効果がある （ファイルダウンロード処理を分散）
既存サーバー（オンプレやホスティングなどＥＣ２以外のサーバー）をオリジンサーバーにすることで、既存サーバーを生かしながら、パターンを適用可能
Ｓ３をオリジンサーバーにできる
注意
更新してもキャッシュサーバーは変更されないかも、
Rename distribution
課題 cache distribution を使用してコンテンツ配信する場合、オリジンサーバーを変更しても、エッジサーバー（cloudfront)のデータはタイムアウトになるまで更新されない
解決 ＵＲＬがカギになる 更新したいファイルを違うファイル名で配置して、アクセスＵＲＬ自体を変更することで常に新しいコンテンツを配信できる
実装
- コンテンツとは別にベースコンテンツ（ＵＲＬを含むＨＴＭＬファイル）を作成
- ベースコンテンツはキャッシュタイムを短くするか、常にオリジンサーバーから配信
- cloudfrontのときは、別名のＵＲＬでオリジンサーバーにも配備
- ベースコンテンツ内のＵＲＬを新しいコンテンツのＵＲＬへ変更する
利点
キャッシュタイムアウトを待たずに新しいコンテンツを配信できる
注意点
ベースコンテンツのキャッシュタイムアウトを短く設定する必要があるが、キャッシュ効果が薄くなる
古いファイルはキャッシュタイムアウトまでエッジサーバーに残るので必要ならば消す
Private cache distribution
CDN を用いたプライベート配信
課題 特定のユーザーに配信する場合、利用者を認証する必要がある
解決 署名付きＵＲＬ認証機能 （ アクセス元ＩＰアドレス、 ダウンロード可能期間 アクセス元地域） などで分別
➡より高い精度で特定のユーザーへの配信が可能になる
実装
- cloudfront apitool or AWS SDK
- EC2 のサーバーに秘密鍵登録して、署名付きＵＲＬの発行準備
- ユーザー認証をして、cloudfrontでＡＰＩを用いて署名付きＵＲＬ制作機能を利用
- ＵＲＬをリンク先として利用
利点
ＩＰアドレスと地域で特定されるユーザーのみ利用できる
実際のコンテンツダウンロードは直接cloudfrontから行うので負担と障害に強い
注意
認証システムや期限付きＵＲＬを発行するサーバーが必要になる
ユーザー認証が切れていなくても、ＵＲＬの有効期限が切れるとダウンロードできなくなる
