訳:ElastiCache : Netflixにおけるクラウドの揮発性キャッシュ
The Netflix Tech Blog: Ephemeral Volatile Caching in the cloud
===
多くのアプリケーションで、頻繁に使われるある程度の量のデータがある。それ以外の大部分のデータはデータベースやミドル層のサービスからフェッチされる必要がある一方、そのデータのいくつかは一時的(trainsient)であり、再計算可能である。Netflixクラウドアーキテクチャにおいて、これらの操作をオフセットするために、我々は広範囲にキャッシングを使っている。本稿は、内部でEVCacheと呼んでいる、高スケーラブルなmemcacheベースのキャッシングソリューションのNetflix実装について述べる。
なぜキャッシングが必要か?
クラウドの先進性の目的のいくつかは以下のこと。
- Netflixデータセンターより高速なレスポンスタイム
- データセンター内のセッションベースアプリケーションからステートレスなクラウドアプリケーションへ
- Cassandra/SimpleDB/S3のようなNoSQLベースの永続を使う
これらを解決するため、高速で共有できスケーラブルなキャッシュにデータを保持する機能が必要だった。計算されたデータやCassandraやその他のS3やSimpleDBといったAmazon AWSサービスのような永続ストアから取得したデータを保持するためにキャッシュを使用し、99percentileにおいて数100msecで取得可能である。このようにして多様なユーザ体験を起こしている。このデータをキャッシュに保持することで、アクセス時間はとても速く線形になり、データストアの負荷が大きく減った。キャッシングはまた、突然のリクエストのスパイクにもより効率的に対処可能とする。さらに、ある過負荷サービスがしばしばキャッシュされた応答を返す。これは、一般的な応答の替わりにパーソナライズされた応答を取得することを保証する。キャッシングを効率的に使うことで、TCOを削減している。
EVCacheとは何か?
EVCacheは、memcachedとspymemcachedベースで、NetflixとAWS EC2インフラをうまく統合したキャッシングソリューションである。
EVCacheは以下の省略形である。
- Ephemeral - 指定されたTTL(Time To Live)の短期間保持されるデータ
- Volatile - データはいつでも消える(Evicted)
- Cache - インメモリ Key Value Store
どう使うのか?
Netflixでは25以上の異なるEVCacheの事例がある。特殊な事例の一つはユーザのホームページである。例えば、特定のユーザに見せる行を決めるために、アルゴリズムはユーザの好み・動画閲覧履歴・待ち状況、レイティング等を知る必要がある。このデータは様々なサービスから並列にフェッチされ、これらのサービスによってEVCacheに保存される。
機能
- 概要
- 分散 Key-Value ストアで、複数インスタンスにわたってキャッシュされる。
- AWS ゾーンを意識して(Zone-Aware)、データはゾーン間で複製される
- 新しいノード/サービスを自動発見するために、Netflixの内部Naming Serviceが動作している。
- データを保持するために、キーは非nullの文字列が必須であり、非nullのバイト配列、プリミティブ型、シリアライズされたオブジェクトも値になる。値は1MB以下にすべきである。
- 一般的なキャッシュクラスターとして様々なアプリケーションから使用できるようにするために、キーの衝突が発生させずに名前空間を使えるよう 追加のCache Nameをサポートしている。
- キャッシュのヒット率は99%以上である。
- NetflixのPersister Frameworkと協調動作する。例えば、 インメモリ->バックを、EVCache->Cassandra/SimpleDB/S3で行うなど。
- 伸縮性(elasticity)と開発容易性:EVCacheは線形にスケールする。
- レイテンシ:典型的なレスポンスタイムは数msecである。EVCacheからの読み込みは典型的には同一のAWSゾーンから返される。ゾーンを意識することの副次効果として、読み込みに関してデータ転送量が不要になる。
- 非一貫性(Inconsistency):ベストエフォートキャッシュであり、データはinconsistentに取得できる。我々が選んだアーキテクチャは一貫性ではなく速度であり、EVCacheに依存するアプリケーションはいかなる非一貫性もハンドリングできる。短期間ストアされるデータ向けには、非一貫性データの有効期限切れをTTLが保証し、長期間保持されるデータ向けには、我々が構築した一貫性チェッカーが非一貫性の状態を修復する。
- 可用性(availability):典型的には、複数のAmazon アベイラビリティゾーンにわたって広がっているサーバクラスタは決してダウンしない。時折インスタンスがダウンした場合も、クラスタにわたってデータをconsistent hashingでシャードしているので、キャッシュミスは最小限である。
- 総費用(TCO: Total Cost of Operations) : とても低いEVCacheクラスタのTCO以上に、キャッシュミスは一般的に高コスト(costlier)であると気づく必要がある。AWS SimpleDB, AWS S3, EC2上のCassandra等のサービスにアクセスするコストがその大きな要素である。高い安定性で線形にスケールするEVCacheクラスタのTCO全体に満足している。
中身(Under the Hood)
サーバ:サーバは以下から構成される
- memcachedサーバ
- Java Sidecar - Discovery Service(Name Server)と通信をし、管理ページを提供する
- サービスの状態と統計情報をレポートする各種アプリケーション
クライアント:JavaクライアントはEVCacheサーバを発見し、全てのCRUD(Create,Read,Update,Delete)操作を管理する。サーバが追加された時や削除された時には、クライアントは自動的にハンドリングする。クライアントはCreate,Update,Delete操作時にデータを複製する(AWS Zoneベースで)。その一方、Read操作時は、クライアントは同じゾーンのサーバからデータを取得する。
このJavaクライアントは今年後半にオープンソース化する予定で、開発者コミュニティともっと学びを共有できる。
単一ゾーンデプロイ
以下の図は、AWS US-EASTリージョンとZone-Aで、3インスタンスのEVCacheクラスタがCRUD操作を行うウェブアプリケーションがあるシナリオを描いている。
- 起動時、EVCacheサーバインスタンスはNaming Service(Netflixの内部ネームサービスで、稼働中の全ホストを保持している)に登録する。
- Webアプリの開始中、EVCacheクライアントライブラリはNaming Serviceに登録された全EVCacheサーバインスタンスを見つけて、接続を確立する。
- WebアプリがCRUD操作を必要とする時、EVCacheクライアントは操作すべきインスタンスを選ぶ。クラスタにまたがってデータをシャーディングするためにConsistent Hashingを使っている。
複数ゾーンデプロイ
以下の図は、AWS US-EASTリージョンの複数ゾーンで複製するシナリオを描いている。3インスタンスのEVCacheクラスタとWebアプリがZone-AとZone-Bに存在している。
- 起動時、Zone-AのEVCacheサーバインスタンスはZone-AとZone-BのNaming Servcieに登録する。
- Zone-AのWebアプリの起動中、 EVCacheクライアントライブラリはNaming Serviceに登録された全EVCacheサーバインスタンスを見つけて、全ゾーンにわたって接続を確立する。
- Zone-AのWebアプリがあるキーでデータをReadする際、EVCacheクライアントはZone-Aにある、取得すべきデータを保持しているEVCacheサーバインスタンスを見つけ、そのインスタンスからデータを取得する。
- Zone-AのWebアプリがあるキーでデータをWrite/Deleteする際、EVCacheクライアントは、Zone-AとZone-BにあるEVCacheサーバインスタンスを見つけてWrite/Deleteを行う。
ケーススタディ:動画とTV番組の類似検索
キャッシュを使い込んでいるアプリケーションの一つとして、Similarsアプリがある。このアプリケーションは、動画とTV番組で、お互いに類似したものをサジェストする。一度類似性が計算されると、結果はSimpleDB/S3に永続化され、EVCacheに保持される。いかなるサービス、アプリケーション、アルゴリズムがこのデータを必要とした際は、EVCacheに問い合わせて結果を取得する。
- クライアントはページと類似度アルゴリズムのリクエストをWebアプリに送信する。
- 動画やTV番組の類似リストを必要とするWebアプリはこのデータのEVCacheを探す。キャッシュのヒット率は99%以上である。
- キャッシュミスの場合、WebアプリはSimilarsアプリに、このデータの計算を依頼する。
- データが以前に計算されていたのにキャッシュミスした場合、SimilarsアプリはSimpleDBからデータを読み出す。SimpleDBになかった場合、アプリは動画とTV番組から類似度を計算する。
- 計算された動画やTV番組のデータはEVCacheに書き込まれる
- Similarsアプリはクライアントから要求されたレスポンスを計算し、結果をクライアントに返す。
メトリクス、監視、管理
多様なクラスタの管理は集約され、クラスタとインスタンスのすべての管理と監視は以下のようなWeb経由で行う。
以下のサーバービューは、クラスタ内の各インスタンスの詳細を示しており、ゾーンの統計も集約(roll up)している。このツールで、memcachedのslabについても閲覧できる。
現在、EVCacheクラスタは 負荷ピーク時で200K request/sec以上をこなしている。以下のグラフは毎時のリクエスト数を示している。
レイテンシの平均は1msec~5msecである。99percentileは約20msecである。
キャッシュヒット率は99%以上である。