Just Keep Swimming

AWS CND CloudFront

今回はAWSのCDNサービスであるCloudFrontを勉強していきます。

AWSはリージョンとそのAZゾーンが世界各地にありますが、CDNとして全世界をカバーするには拠点が足りません。 そのためCDN専用の拠点としてエッジロケーションと呼ばれる場所があります。 この拠点は、AWSのリージョンにあるAZゾーンとは別にコンテンツの配布場所として全世界で50ヶ所以上用意されています。

さっそくCloudFrontを作ってみると、 最初に新規作成するとコンテンツタイプを2つの中から選ぶことになります。

  • Web
    Webサーバで使用するコンテンツ。通常のHTMLファイル等はこれを使用する。

  • RTMP
    Adobe flash等のストリーミングを配信する場合はこのRTMPを使用する。

CloudFront-Deliverymethod

コンテンツタイプを選んで次のページに行くと実際の設定ができます。

  • Origin Setting コンテンツのオリジナルとなるサーバ。AWSではS3バケット、EC2インスタンス、ElasticロードバランサーかRoute53が使用可能です。 カーソルをドメイン名に移動すると自動的にS3のバケット名が出てきて簡単に選ぶことができます。またAWS以外のサービスでももちろんAWSのCDNを使用することは可能です。
    Origin IDはデフォルトでバケット名が入力されますが、マルチオリジンの配布をする場合にはIDをわかるように設定する必要があります。

CloudFront-OriginSettings

  • Default Cache Behavior Settings パスパターンはデフォルトではワイルドカードですが、拡張子を選択しPDFのみを配布するだとか設定できます。
    CDNへのアクセスプロトコルとHTTPのメソッドを指定することが可能で、PUTやPOSTも受け付けるので、CDNへの変更も許可することが可能です。 また、カスタムでTTLの設定が可能です。デフォルトは24時となっていますが変更が可能です。
    CloudFrontはこのTTLが来ると自動的にコンテンツが削除され、再度アクセスが来るとオリジナルからコピーして配布する仕組みとなっています。
    Restrict viewer accessはログインしてアクセスが必要なサイト等で使用される機能で必要な場合には有効にする必要があります。

CloudFront-CacheBehaviorSettings

  • Distribution 設定 PriceクラスでCloudFrontのEdge Locationをカテゴリーで決められます。3つあって全世界とアメリカ、ヨーロッパとアメリカ、ヨーロッパとアジアから選べます。
    CDNのアドレスはランダムなURLがアサインされるので、CNAMEを指定することができます。
    またその際に必要なカスタム証明書を合わせて設定することができます。

CloudFront-DistributionSettings

作成するとディストリビューションに表示されます。配布の準備が整うまでしばらくIn Progress状態で待ちますが、

CloudFront-In-Progress

10-15分ほどすればDeployedになります。

CloudFront-Deployed

完了したら、CDN用のcroudfron.net Domain Nameでアクセスができます。

設定変更画面で作成したCDN配布設定を再度変更できます。 作成する際になかったRestrictionsとInvalidationsを見てみましょう。

CloudFront-SettingsChange

Restrictionsはジオリストリクションが設定でき編集ボタンからジオリストリクションを有効にすると、特定の地域をホワイトリストかブラックリストで指定することができ、指定した地域のみに配布または配布から除外する設定が可能です。

CloudFrontGeoRestriction

Invalidationsは配布したファイルをTTLの削除時間が来る前に手動で削除する際に使用します。 特定をファイルを指定すると、そのファイルが即座に削除対象になります。 手動での削除は別途料金がかかります。

CloudFront-Invalidations

最後に削除する場合には、一度DisableをクリックしてDisabled状態になってからでないと、削除ボタンが押せません。Disableにして再度設定が反映されてからようやく削除ボタンが押せるようになります。

CloudFront-Delete

以上、ちょっと急ぎ足ですがCloudFrontの概要と使い方がわかったかと思います。 時間があったらもうちょっとアップデートしたいと思います。

S3 のライフサイクルマネジメント

S3にどんどんファイルを保存すると料金がかさんで行きますので、削除するなりGlacierなどに、移動する必要が出てきます。 その作業をルールを使って自動で実行してくれるのがライフサイクル機能です。 バージョニングの有無でマネジメント方法も少し変わってきます。 まずは、バージョニング機能を向こうにした状態でライフサイクル管理機能を使って見までょう。 プロパティからライフマネジメントメニュで設定が可能です。

Lifecycle settings

バケットかフォルダ単位か指定してルールを設定します。 バージョン管理を無効にしていると3つのルールが表示されます。 - IAストレージへ移行 - Glacierへアーカイブ - ファイルの永久削除 下の画面ではIAストレージへ移行してからGlacierへアーカイブするオプションの2つにチェックを入れてみました。 アップロードしたファイルが30日後にIAストレージに移動され、60日後にGlacierにアーカイブされます。 注意する点としては、この60日はアップロードされた日から60日でIAストレージに移動してからではありません。 例としてアイコンがでて今日アップロードしたファイルがどのタイミングでIAストレージに移行しその後Glacierへアーカイブされるのかがひと目で分かるようになっています。

Lifecycle Example

デフォルトで30日と60日が設定されていますがこれには訳があり、IAストレージはアップロード後すぐに移動することはできません。 最低30日経過しないとIAストレージに移動できない決まりになっていますので、例えば1日と入力すると30日以上を設定しなさいとエラーメッセージがかえってきます。

Lifecycle to IA Storage

また、IAストレージからGlacierへのアーカイブもIAストレージへ移行してから30日経過しないと移動できない決まりになっていますので注意が必要です。 IAストレージへのライフサイクル設定は前後30日期間を開けておく必要があるとと覚えておきましょう。 また、IAストレージのみ128KB以上のファイルでないと移行することができないのも注意が必要です。

Lifecycle from IA Storage to Glaceir

IAストレージへ移動せずに、直接Glaceirにアーカイブをする設定であれば、アップロードの次の日にはアーカイブが開始できます。GlaceirへのアーカイブはIAストレージと違って日数の制限はありません。 ただし、Glaceirは長期アーカイブすることを目的にシステムが設計されていますので、自動的に最低90日データを保管します。 そのため例えばライフサイクルでGlacierへアーカイブ後のファイルの削除を60日に設定すると削除設定は60日だけれども実際には90日後に削除されますとメッセージがでますので心に止めておく必要があります。

Lifecycle delete on Glaceir

バージニングを有効にした場合のライフサイクルのメニュもちょっとだけ見ておきます。 設定が有効ですと現在のバージョンと古いバージョンの2つのファイルに対してライフサイクルを実行できます。

Lifecycle with versioning

IAストレージへの移行やGlacierへのアーカイブの設定はバージョニング有り無しで特に変わりませんが、ファイルの削除はバージョニングされた複数のファイルがあるのでちょっと違います。 現在のファイルにExpireを設定しても、S3 バージョニング設定で勉強したとおり実際には削除されずにDelete Markerがつくだけで削除はされません。 永久的に削除する場合には、古いバージョンのファイルでも同じようにルールを設定して削除してあげる必要があります。

Lifecycle delete versioning

S3 バージョニングとクロスリージョンレプリケーション

前回に続きS3の機能を見ていきますが、 今回はS3のバージョニング機能の使い方とライフサイクルを中心に勉強していきます。

###S3バージョニング機能

バージョニング機能を有効にすると変更を保存してくれてどのバージョンのファイルでもアクセスできるようになります。 バージョニング機能を使うのは至って簡単で、バケットのプロパティのバージョニング項目からバージョニングを有効にするボタンをクリックするだけです。ただし注意なければいけないのは、一度有効にすると無効にできないので必要か考慮してから有効にしましょう。

Enable versioning

さて、バージョニングを有効にしたら、バージョン管理を実際に試してみます。 1つファイルをアップロードしてみるとバージョンのタブでバージョン作成時、バージョンID、サイズが確認できます。

Show versioning

同じファイルを編集して再度アップロードすると、変更したファイルとオリジナルファイルが並んで確認できます。 バージョン作成時、IDとサイズが違うのが確認できます。ちゃんとバージョン管理ができていますね。

versioning detail

試しにバージョンタブを隠してファイルを削除してみます。そうするとバケットからはindex.htmlファイルは削除されますが 、バージョンを表示するとバージン管理されたファイルが残っているのが分かります。ファイルを見るとわかりますが実際には削除されていなくて削除マークが付いているだけです。

Delete Marker

削除したファイルを戻したい場合には、削除マークが付いているファイルをアクションメニューから削除すれば、もとに戻すことができます。 また、バージョン詳細の画面で、ファイルを削除するとそのバージョンのファイルを削除したことになり、1つ前のバージョンのファイルにリバートすることになります。削除マークはつかずに永久的にに削除されますので注意が必要です。

バージョニングは間違って削除してしまったり変更管理に大変便利ですが、全てのバージョンファイルのサイズが使用料として課金ます。 ですので、例えば上のバージョンファイルの例ですと、546バイトと614バイトの2つのファイルを保存している事になります。これが1GBのファイルとなると2GB使用していることになりますので、ファイルサイズが大きい場合には注意する必要があります。

###クロスリージョンレプリケーション クロスリージョンレプリケーションを有効にすると、S3に保存んしたファイルが別の任意のリージョンにコピーされるようになります。 使用するにはバージョニングを有効にしておく必要があります。 複製先のリージョンとバケットを選び、セキュリティアクセスロールを選びます。 ロールはIAMで勉強しましたが、リソースにアクセス権を付与できるセキュリティポリシーです。

Cross-Region-Replication

ロールが何もない場合には、新規作成して設定することができます。IAMロールは新しく作成すると自動的に、複製元と複製先のみアクセスが許可されたロールが作成されるので毎回個別に作成すると良いでしょう。

AM role for replication

設定が完了するとバックアップ用のバケットが作成されて、新規にアップロードされたファイルから複製されていきます。

New bucket on destination region

有効後のファイルからのみ自動でコピーされるので、すでに保存されているファイルに関しては手動でコピーする必要があります。(Copy APIを使用可能。) 2つのバケットにファイルを保存するので、その分の料金が発生します、また転送した分のデータ通信も費用が発生します。費用を抑えるために、複製先はストレージタイプを、RRSにすることも可能です。またライフサイクルを有効にしてGlacierに移動することも可能です。