あらゆる層でのキャッシュ利用を検討せよ！各層でのキャッシュ利用戦略まとめ #reinvent #ATC303

チャットボット特集

#AWS

濱田孝治

2017.11.28

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

Cache Me If You Can: Minimizing Latency While Optimizing Cost Through Advanced Caching Strategies

上記セッションを受講したので、その様子をおとどけします。全体的にはインフラというよりはアプリケーションよりの話なのですが、4つの層にわたって、キャッシュ利用の戦略をコンパクトに纏めてくれていて、非常に有用なセッションでした。

From CloudFront to ElastiCache to DynamoDB Accelerator (DAX), this is your one-stop shop for learning how to apply caching methods to your AdTech workload: What data to cache and why? What are common side effects and pitfalls when caching? What is negative caching and how can it help you maximize your cache hit rate? How to use DynamoDB Accelerator in practice? How can you ensure that data always stays current in your cache? These and many more topics will be discussed in depth during this talk and we’ll share lessons learned from Team Internet, the leading provider in domain monetization.

　__
（祭） ∧ ∧
　Y　 ( ﾟДﾟ)
　Φ[_ｿ__ｙ_l〉     Cacheﾀﾞ ﾜｯｼｮｲ
　　　 |_|＿|
　　　 し'´Ｊ

イントロダクション

セッション内容

このセッションでは、以下の内容について説明する。みんな、ついてきてくれよ！

Speed
Best Practice
Architecture patterns
Real-world examples from Team Internet
Lower Cost

全てはスピードのため。いかにアプリケーションを高速化するかに我々は尽力してきた。

アプリケーションを高速化する方法

Increase rate
Parallelize
Do Less

アプリケーション高速化手法には複数あるが、ここでは、一番実施が簡単で効果の高い、キャッシュを使った高速化手法を紹介。

キャッシュとは、一度取り込んでおいたものを何回も使いまわすこと。CPUよりも安くて早いメモリーを効率良く使いまわすことにより実現する。

本セッションでは、4つの層に分かれて、キャッシュを利用した高速化手法について説明していく。

Edge
Web tier
App tier
Database

Edge（エッジ層）

Edge層で一番利用されるのは、CloudFront。静的ファイルの配信が主だと思われがちだが、動的コンテンツの配信にも対応している。

上記要件のアプリケーションがある。世界中にクライアントがある場合に、マルチリージョンでアプリケーションを構築するか？もしくは、代替手段があるか？

マルチリージョンでの構成例。この場合だと、リージョン間で同期をとるリソースが必ず必要となる。

クラウドフロントを前段に配置した場合の例。マルチリージョン部分は、世界中にエッジロケーションがあるCloudFrontを利用し、アプリケーション部分は、1リージョンで対応することにより、無駄を省くことができる。

Lambda@Edgeも利用が可能。

Lambda@Edge Functionは、CloudFrontをトリガーとして、エンドユーザーとオリジンリソースの双方向の通信をトリガーに起動が可能。

ユースケースとして、コンテンツのカスタマイズや認証、A/Bテストなどにも利用できる。

Edge層のまとめ

CloudFrontを利用して、ラストマイルのレイテンシを高速化
コストを抑えての導入が可能
アプリケーションカスタマイズについては、Lambda@Edgeの利用も検討にいれてみる

Web tier（Web層）

AWSに依存しない、一般的なアプリケーションによるWeb層におけるキャッシング方法は様々ある。まずは、これらを検討しておく。

Amazon API Gatewayを利用してのキャッシュも可能。API Gatewayには、レスポンスキャッシュ機能があり、実行結果をキャッシュすることが可能。バックエンド側は、Lambda Functionsを利用したり、Amazon EC2のエンドポイントを指定したり、その他、パブリックな接続可能な任意のエンドポイントを利用可能。

全ての静的コンテンツのキャッシュ化
ログアウトユーザーのキャッシュ有効化
アクセス頻度が高いコンテンツのキャッシュ検討
キャッシュヒット率、ミス率のモニタリング
賢明なTTLの選択
- アプリケーションデプロイを妨げない
- 60秒TTLも役に立つ場合もある

Web層のまとめ

既にCloudFrontを利用しているのであれば、Web層でのキャッシュは役立つ
Amazon API Gatewayに付属するキャッシュは簡単に利用できる
TTLを賢く設定しよう

App tier（アプリケーション層）

アプリケーション層でのキャッシュとは、以下を対象とすること。

セッション
結果
認証
テンプレート
環境
コンフィグ

要するに全部。全部を検討対象とすること。

あらゆるものが監視対象になりうる。考えうる限りのメトリクスをモニタリングし、そこからキャッシュ戦略を検討。

ここで基本的な考え方になるのが、「8対2の法則」。皆さん、聞いたこと有りますよね？これは、アプリケーションのトラフィックにも当てはまります。負荷の8割は処理のうち2割に集中するので、それらのリソースを全てキャッシュさせる覚悟でいきましょう。

RAMをフル活用しましょう！

さらにRAMを活用するなら、Amazon ElastiCacheを利用しましょう。

さらに、memcachedやRedisも検討対象になります。

アプリケーション層のまとめ

全てをモニタリングせよ！
80％のトラフィックを持つ20%のアクセス元を見つけよ
高頻度アクセスを全て、メモリ上にキャッシングせよ
ElastiCachの利用を検討せよ

Database（データベース層）

データベース層のキャッシングの話をしよう。

伝統的な手法では、データベースの前に、キャッシュ機構を設置します。

キャッシュの無効化には2種類あります。

TTLの無効化
常にキャッシュを同期化する

DB更新後、アプリケーション側でその返り値を判定し、キャッシュに書き込む方法もあります。が、これはアプリケーション側の処理が重たくなりがちで、あまり推奨はできません。

DB更新後、DDBストリームか、ストアドプロシージャを利用して、AWS Lambdaを起動。そこから、ElastiCache内を更新する方法もある。アプリケーション側から、キャッシュは更新しない。少しの遅延は発生するが、アプリケーション側の負担がへり、更新内容を統一的に処理できるので、こちらをオススメしておきたいです。