AWSアソシエイト試験に向けて11( ElastiCacheとCloudFront） #AWS

はじめに

両方とも主にキャッシュを利用することで様々な恩恵をサービスに齎すために利用するサービス。

ElastiCache

ベストプラクティスではキャッシュの利用と最適なデータベース選択の分野に入る
Well-Architected Frameworkではパフォーマンス効率の分野に入る
S3と連携することが基本的な使い方になる
インメモリ型DB、つまりメモリにキャッシュを保存する仕組みなのでディスク型DBに比べて処理は早くなる
分散型インメモリキャッシュサービスでフルマネージド型である
キャッシュクラスタを手軽に起動できる
フルマネージドで自動障害検出、復旧、拡張、パッチ適用、バックアップに対応と高可用性が期待できる
DBエンジンとしてはmemocachedかredisが選択できる

ユースケースとしては以下のことが考えられる。

セッション管理
IoT処理とストリーム分析
メタデータ蓄積
ソーシャルメディアのデータ処理・分析
Pub/Sub処理
DBキャッシュ処理

また以下のようなデータを即時反映させる必要があるような処理にも有効である。

ユーザーのマッチング処理
レコメンデーションの結果処理
画像データの高速表示
ゲームイベント終了時のランキング表示

キャッシュすべきデータを特定して、他のDBと連携して活用することでDBへのアクセス負荷を抑制し、可用性の低下を防ぐ。

Redis

高速に値を読み書きできるインメモリキャッシュ型DB
シングルスレッドで動作するインメモリキャッシュDBですべてのデータ操作が排他的である
Snapshot可
データの永続化が可能
Luaスクリプト……移植性が高く、高速な実行速度などの特徴を持っているスクリプト言語が利用可能
位置情報クエリ……緯度経度などの位置情報をクエリ処理することが可能、検索距離や検索範囲の指定もできる
pub/subモデル……イベントを起こす側(pub)、イベント処理を行う側(sub)を分離するという思想のモデルで、メッセージ処理・イベント処理で活用する

こちらを利用するケースとして考えられるのは以下の通り。

複雑なデータ型が必要である
インメモリデータセットをソートまたはランク付けする必要がある
読み込み処理の負荷に応じて、リードレプリカにレプリケートをする必要がある
pub/sub機能が必要
自動的なフェイルオーバーが必要である
キーストアの永続性が必要である
バックアップと復元の機能が必要である
複数のDBをサポートする必要性がある

Memcached

高速に値を読み書きできるインメモリキャッシュ型DB
マルチスレッドで動作するインメモリキャッシュDB
Snapshot不可
データ永続化も不可
フェイルオーバーや復元も不可

こちらを利用するケースとして考えられるのは以下の通り。

シンプルなデータ型が必要である
複数のコアまたはスレッドを持つ大きなノードを実行する必要がある
システムでの需要増減に応じてノードを追加または削除するスケールアウト及びスケールイン機能が必要である
DBなどのオブジェクトをキャッシュする必要がある
キーストアの永続性は必要ない
バックアップと復元の機能が必要でない
複数のDBを利用できない要件である

つまり、一時的な処理や簡便に利用したい場合の選択肢がこちらになる。

CloudFront

AWS提供のCDN(Content Delivery Network)サービス。
CDNはWebコンテンツ配信処理を高速化するためのサービスであり、もう少し踏み込んで言うとサーバーでキャッシュを利用することで負荷を軽減させつつ処理を高速化させるという仕組みのものである。
どういうことかというと、https://www.example.comというWebページへアクセスした場合CDNの仕組みがあるとDNSサーバーはhttps://www.example.comのIPアドレスを返すのではなく、CDNサーバーのCNAMEを返す。
そうすると、アクセスはCDNサーバーへと迂回され、そちらにキャッシュがあればそこからWebページを送信し、キャッシュがなければそこではじめてオリジンサーバーへとアクセスをパスするということらしい。

参考: ネットの大規模障害が起きた「CDN」って何？実際にアクセスして確かめてみた

で、CloudFrontの場合はIoTや末端デバイスに置かれることでリアルタイムでそれらの端末からデータの収集・処理・分析を行い、クラウドサーバーと連携するエッジサーバーとしての役割も持つことでその特性がより際立つ……ということになるのだと思う。

参考: エッジコンピューティングとは？

210以上のエッジロケーションによる高性能な分散配信を行う
AWS WAF、AWS Certificate Managerとの連携やDDoS対策によるセキュリティ機能を持つ
オリジンに対してHeader、Cookie、Query Stringsによるフォワード指定で、動的なページ配信が可能である
エッジサーバー(エッジロケーション)とオリジンサーバの間にさらにリージョナルエッジキャッシュと呼ばれるものをかませることでより効率的に配信を行う
AWSがAmazonの特性を生かしてグローバルにエッジロケーションを持っているので、配信ネットワークもまたグローバルに展開できる
独自ドメインを指定可能
エッジ側でGzip処理をオリジンからの配信されたコンテンツに対して行うことでより高速に配信が可能

使い方としては

各配信先となるドメインにCloudFrontを個々に設定して割り当てる
作成はマネコンやAPIから
Web Distributionのみ可能(RTMPは廃止)
使用量が最大40Gbps/10万RPS超になるときは上限緩和申請をする
コンテンツ利用データ分析を実施し、結果から判断して静的・動的コンテンツへのキャッシュ対象URLを設定する
変更が反映されるまでの時間も考慮して、TTLを設定する(キャッシュ時間のこと)
セキュリティ対応等の非機能要件の要否を検討する(SSL認証の有無、HTTPSの有無等)

具体的には

コンテンツオリジン設定……CloudFrontの配信ファイルの取得先の設定をする
アクセス設定……ファイルアクセスの許可設定
セキュリティ設定……アクセスにHTTPSを利用するかの設定
Cookieまたはクエリ文字列転送の設定……オリジンへのCookieまたはクエリ文字列転送の要否の設定をする
地域制限……特定の国のユーザーからのアクセス拒否設定
アクセスログ設定……アクセスログを作成要否の設定をする

ということになる。

WEB Distribution

CloudFrontで設定できるもの。
RTMPという主にAdobe Flashの配信を行うために利用されていたメディアファイルのストリーミングのための設定もあったが2021年に廃止。
WEBの方は以下のような仕様となる。

通常のHTTPプロトコルを利用したWEB配信をする際に利用する
HTTP1.0、HTTP1.1、HTTP2に対応する
オリジンはS3バケット、MediaPackageチャネル、HTTPサーバーを設定
HTTPやHTTPSを使用した静的および動的なダウンロードコンテンツ配信を行う
Apple HTTP Live StreamingやMicrosoft Smooth Streamingなど様々なビデオオンデマンドに対応

キャッシュコントロール機能

キャッシュヒット率を上昇させて効果的にキャッシュ活用を行う。

URLとフォワードオプション機能(header、Cookie、Query Strings)のパラメーター値の完全一致でキャッシュが指定される仕組み
単一ファイルのキャッシュは最大20GB
GET、HEAD、OPTIONリクエストに対して利用できる
キャッシュの期限切れを待たずに無効化することが可能
必要のないキャッシュを無効化することで効果的な利用を可能にする
コンテンツごとに最大3000個まで無効化パスを指定できる
ワイルドカードを利用して最大15個まで無効化パスリクエストが指定可能

セキュリティ機能

様々なセキュリティ設定によるセキュアなコンテンツ配信を行う。

SSL証明書を設定して、コンテンツ配信時のHTTPS対応を行うことでビューワーアクセスとオリジン配信の暗号化通信が可能
オリジンカスタムヘッダーによる通信制御が可能
AWS WAFによるファイアウォールと連携して、これらのDistributionに対するWebリクエスト許可やブロックが可能
Referer制限によるリンク参照禁止も可能
S3バケットからの配信の際にOAIとCloudFrontを指すカスタムドメインによってアクセス制限を行う
AWS ShieldによるDDoSに対応
署名付きURL/Cookieによる有効期限指定
GEOリストリクションによる地域情報でアクセス判定を行う

ハンズオン

ElasticCache

ウィザードに従って進めていく。
RedisとMemocachedとで設定する項目は大幅に変わる(Memのができないことが多い)。

できるとこんな感じで設定した通りシャードが3つできているのが確認できる。

作ったElastiCacheのプロパティ。
アクセスするには指定エンドポイントの値が必要になる。
最後の下4桁がポート番号になるのでウィザードで指定したセキュリティグループでトラフィックを許可するように設定しておく(もしくは許可してから設定する)

各種設定画面。

実際にEC2インスタンスからアクセスして使ってみる。

予めEC2インスタンスにredisを入れておく(sudo amazon-linux install redis4.0)。
下記のようにデータのセットと取得ができていることが確認できる。

CloudFront

同じようにウィザードで設定していく。
ODNにはELBとかドメインなどを指定する、今回はELB。

TTLでキャッシュの時間を設定する。
Use legacy cache settingsにチェックを入れないと出てこない。

作成すると以下のように出来上がる。

プロパティは以下の通り。
Domain Nameの部分を後で使う。

各種設定部分。
オリジンを追加したり、オリジンのグループを設定したりできる。

パスを設定して、キャッシュの動作を設定できる。

エラーページの設定

制限を設定できる。

キャッシュの無効化に関する設定。

タグ。

各種メトリクス。
まず、統計的なレポートはこの項目。

次にMonitoring and Alarmsの部分。
ここはudemyの講座とは変更されて下記のように変更になっていた。

Popular Objects Reportではどのコンテンツが配信でよく使われるのかを確認できる。
要はここでよく表示されるコンテンツに対してキャッシュを設定しようということ。

今度はこちらから参照されやすいコンテンツを確認することができる。

利用状況のレポートはこちらから。

どんなデバイスやブラウザ、及び場所からコンテンツが見られているのかを確認できる。

S3からのコンテンツ配信の際に、アクセスを設定するための設定を行える。

こちらはフィールドレベルのEncryption(暗号化)を設定するためのPublic Keyを作る場所。

作ったキーはこちらで使う。

実際の動作を確認してみる。

まずはこちらのドメイン名を直接URLに叩き込む。

キャッシュがある場合は、とりあえずEC2Webサーバーからindex.htmlの内容が返ってくる。
ちなみに構成はマルチAZでELBで2つのAZのPインスタンス(Webサーバー)をロードバランシングしているというものになっていて、先程設定したようにCloudFrontはこの場合ELBに置かれている。

では、index.htmlの内容を変えてみる。

TTL設定した時間を置いて確認してみるとキャッシュも変わっているのが確認できる。