この記事は公開されてから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内を更新する方法もある。アプリケーション側から、キャッシュは更新しない。少しの遅延は発生するが、アプリケーション側の負担がへり、更新内容を統一的に処理できるので、こちらをオススメしておきたいです。
Amazon DyanmoDB Accelerator(DAX)の採用も検討しましょう。複数テーブルもDAX1クラスタで対応が可能です。
DAXのパフォーマンス例を示します。
ネガティブキャッシュも活用することで、キャッシュヒット率を向上させることが可能です。
データベース層の要約
- ネガティブキャッシュまでも活用しよう！
- キャッシュの自動更新方法に、Lambdaの利用を検討しよう！
- アプリケーション側とDB側のキャッシュを結合させよう！
- DAXを使おう
セッションのまとめ
- CloudFrontとAPI Gatewayの検討
- あらゆる項目のモニタリング
- 利用トップ20%のユーザーの特定
- Web層キャッシュの導入検討
- アプリケーション層キャッシュにElastiCacheの利用検討
- DAXの利用
- なんでもかんでもキャッシュせよ！！
聴講の感想（濱田目線）
4層にわたって、それぞれにおけるキャッシュ利用方法について、簡潔にまとめられたセッションで、非常にわかりやすく聞きやすいセッションでした。
個人的には、DB層でのキャッシュ方式、とくに、DB更新をトリガーに、ストアドプロシージャからLambdaをキックしてElastiCacheを更新するしくみなどは、全く新しい知見でした。
個々の技術要素としては、それぞれ詳細な検討が必要ですが、アプリケーション全体を通して、キャッシュによるパフォーマンス向上の戦略を俯瞰できたので良かったです。
それでは、今日はこのへんで。濱田でした。
0
