aws memo

AWS関連の備忘録 (※本ブログの内容は個人的見解であり、所属組織及び企業の意見を代弁するものではありません。１年以上古いエントリは疑ってかかってください)

訳：ElastiCache : Netflixにおけるクラウドの揮発性キャッシュ

訳 Architecture AWS

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で、３インスタンスのEVCacheクラスタがCRUD操作を行うウェブアプリケーションがあるシナリオを描いている。

  1. 起動時、EVCacheサーバインスタンスはNaming Service(Netflixの内部ネームサービスで、稼働中の全ホストを保持している）に登録する。
  2. Webアプリの開始中、EVCacheクライアントライブラリはNaming Serviceに登録された全EVCacheサーバインスタンスを見つけて、接続を確立する。
  3. WebアプリがCRUD操作を必要とする時、EVCacheクライアントは操作すべきインスタンスを選ぶ。クラスタにまたがってデータをシャーディングするためにConsistent Hashingを使っている。

複数ゾーンデプロイ

 以下の図は、AWS US-EASTリージョンの複数ゾーンで複製するシナリオを描いている。3インスタンスのEVCacheクラスタとWebアプリがZone-AとZone-Bに存在している。

  1. 起動時、Zone-AのEVCacheサーバインスタンスはZone-AとZone-BのNaming Servcieに登録する。
  2. Zone-AのWebアプリの起動中、 EVCacheクライアントライブラリはNaming Serviceに登録された全EVCacheサーバインスタンスを見つけて、全ゾーンにわたって接続を確立する。
  3. Zone-AのWebアプリがあるキーでデータをReadする際、EVCacheクライアントはZone-Aにある、取得すべきデータを保持しているEVCacheサーバインスタンスを見つけ、そのインスタンスからデータを取得する。
  4. Zone-AのWebアプリがあるキーでデータをWrite/Deleteする際、EVCacheクライアントは、Zone-AとZone-BにあるEVCacheサーバインスタンスを見つけてWrite/Deleteを行う。

ケーススタディ：動画とTV番組の類似検索

キャッシュを使い込んでいるアプリケーションの一つとして、Similarsアプリがある。このアプリケーションは、動画とTV番組で、お互いに類似したものをサジェストする。一度類似性が計算されると、結果はSimpleDB/S3に永続化され、EVCacheに保持される。いかなるサービス、アプリケーション、アルゴリズムがこのデータを必要とした際は、EVCacheに問い合わせて結果を取得する。

  1. クライアントはページと類似度アルゴリズムのリクエストをWebアプリに送信する。
  2. 動画やTV番組の類似リストを必要とするWebアプリはこのデータのEVCacheを探す。キャッシュのヒット率は99%以上である。
  3. キャッシュミスの場合、WebアプリはSimilarsアプリに、このデータの計算を依頼する。
  4. データが以前に計算されていたのにキャッシュミスした場合、SimilarsアプリはSimpleDBからデータを読み出す。SimpleDBになかった場合、アプリは動画とTV番組から類似度を計算する。
  5. 計算された動画やTV番組のデータはEVCacheに書き込まれる
  6. Similarsアプリはクライアントから要求されたレスポンスを計算し、結果をクライアントに返す。

メトリクス、監視、管理

多様なクラスタの管理は集約され、クラスタとインスタンスのすべての管理と監視は以下のようなWeb経由で行う。

以下のサーバービューは、クラスタ内の各インスタンスの詳細を示しており、ゾーンの統計も集約(roll up)している。このツールで、memcachedのslabについても閲覧できる。

現在、EVCacheクラスタは 負荷ピーク時で200K request/sec以上をこなしている。以下のグラフは毎時のリクエスト数を示している。

レイテンシの平均は1msec～5msecである。99percentileは約20msecである。

キャッシュヒット率は99%以上である。