はじめに
両方とも主にキャッシュを利用することで様々な恩恵をサービスに齎すために利用するサービス。
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設定した時間を置いて確認してみるとキャッシュも変わっているのが確認できる。
