クラウド サービスが分散キャッシュ システム アーキテクチャに統合されると、どのような火花が散るでしょうか?

インターネット技術には 2 つの主要な支点があり、その 1 つはキャッシュです。分散キャッシュ システムは、大規模なインターネット アプリケーションにとって強力なツールです。増え続けるデータ量、予測不可能なトラフィック パターン、高速な応答時間の必要性に直面している中、これがクラウド コンピューティング サービスの動的な性質の主な利点です。

では、クラウド サービスが分散キャッシュ システム アーキテクチャに統合されると、どのような火花が散るのでしょうか?

大規模インターネットアプリケーションにおけるキャッシュ

[[223537]]

まず、大規模なインターネット アプリケーションのキャッシュのアーキテクチャを確認しましょう (図 1 を参照)。ウェブサイトの開発プロセスにおいて、ビジネス量の増加は嬉しい悩みであり、キャッシュ技術はその悩みを解消する万能薬です。これにより、キャッシュがなぜ重要なのかが改めて理解できるようになります。

図1 大規模ウェブサイトシステムにおけるキャッシュの応用

実際、この時点でのシステムは、無限の拡張性を持つ大規模ウェブサイトの段階に入っています。ウェブサイトのトラフィックが増加した場合の解決策としては、Web サーバー、データベース サーバー、キャッシュ サーバーを継続的に追加することです。サーバーを動的に追加または削減する方法は、まさにクラウド サービスが役立つところです。

クラウドサービスの利点

企業にとって、クラウド サービスには多くのビジネス上の利点があります。

まず、同社の先行インフラ投資はほぼゼロです。大規模なシステムを構築する場合、コンピュータ室、ハードウェア（ラック、サーバー、ルーター、バックアップ電源）、ハードウェア管理（電源管理、冷却）、運用・保守担当者に多額の投資が必要になる場合があります。初期費用が高額なため、プロジェクトを開始する前に、通常、複数回の規制当局の承認と正当化が必要になります。パブリッククラウドサービスでは、固定費や初期費用はほとんどかかりません。

第二に、クラウド サービスはインフラストラクチャの即時性を提供します。過去、インターネット アプリケーションが大規模化し始めたとき、インフラストラクチャが規模の成長に追いつけないと、アプリケーションの成功に大きな影響が出ました。しかし、多額の資金を先行投資してもアプリケーションが普及しなければ、インフラは失敗に終わるでしょう。クラウド サービスは柔軟性を高め、リスクと運用コストを削減し、成長の規模に応じてオンデマンドで支払うことができます。

*** クラウド サービスでは、リソースをより効率的に使用し、使用量に基づいてコストを計算し、製品の市場投入までの時間を短縮できます。

クラウド サービスの技術的な利点も明らかです。主な機能は次のとおりです。

自動化: インフラストラクチャ スクリプトを使用すると、API を最大限に活用してビルドとシステムの展開を完了することで、インフラストラクチャ プログラミングをより繰り返し実行できるようになります。

自動拡張: 手動による介入なしに、アプリケーションを需要に応じて双方向に拡張できます。自動スケーリングにより自動化が促進され、効率が向上します。

積極的な拡張: 需要予測とトラフィック パターンの合理的な計画に基づいて、アプリケーションを両方向に拡張し、低コストの運用を維持できます。

より効率的な開発サイクル: 開発環境とテスト環境を本番システムに簡単にコピーでき、さまざまな段階の環境を本番システムに簡単に昇格できます。

テスト可能性の向上: ハードウェアの過負荷テストを実行する必要がなく、開発プロセスのすべての段階でインジェクションと自動テストを継続できます。

災害復旧とビジネス継続性: クラウド サービスは、一連のアプリケーション サーバーとデータ ストアを維持するための低コストのオプションを提供します。クラウド サービスを使用すると、数分以内に、ある場所の環境を別のリージョンのクラウド環境に複製できます。

Alibaba Cloud、Baidu Cloud、Tencent Cloud など、クラウド サービスの選択肢は数多くありますが、クラウド サービスの商用化元である AWS には、多くの独自の機能と幅広い用途があります。 AWS クラウド サービスは、信頼性が高くスケーラブルなインフラストラクチャを通じて、サポートと管理のコストを最小限に抑えた Web アプリケーション展開ソリューションを提供します。このインフラストラクチャは、企業の内部環境に展開されるか、データ センター施設に展開されるかに関係なく、自社構築のインフラストラクチャよりもはるかに柔軟です。

EVCache: クラウドサービスに基づく分散キャッシュシステム

クラウド サービスは、ソフトウェア システムの開発と展開の俊敏性を高めるだけでなく、イノベーションの可能性も広げます。 AWS クラウド サービスと分散キャッシュ サービス システムを組み合わせることで、優れた技術ソリューションが生まれました。典型的な例は Netflix の EVCache です。

EVCache は、Memcached メモリ ストレージと Spymemcached クライアント実装に基づくオープン ソースの高速分散キャッシュ ソリューションです。これは主に Amazon Elastic Compute Cloud Service (AWS EC2) のインフラストラクチャで使用されます。クラウド コンピューティングに最適化されており、データ層サービスをスムーズかつ効率的に提供できます。

EVCache は次の内容を含む頭字語です。

• 一時的: データ ストレージは一時的であり、独自の有効期間があります。
• 揮発性: データはいつでも消えてしまう可能性があります。
• キャッシュ: メモリ内のキー値ストレージ システム。

EVCache によって実装される主な機能には、分散キー値ペアのストレージ、AWS のクロスリージョンデータレプリケーション、新しいノードまたは新しいサービスの登録と自動検出などがあります。 EVCache は通常、コンテキストの一貫性がそれほど要求されないシナリオで使用されます。堅牢な API を提供しながら、非常に大量のトラフィックを処理するのに十分なスケーラビリティを備えています。

Netflix はマイクロサービス アーキテクチャの分野を実践しています。システムには数百のマイクロサービスがデプロイされており、各マイクロサービスは 1 つの処理のみを実行することに重点を置いています。これにより、Netflix が提供するソフトウェア システムは、高度にバランスが取れ、疎結合になります。状態はキャッシュまたは永続ストレージに保存されるため、これらのマイクロサービスのほとんどはステートレスであり、自動的にスケーリングすることが容易です。

EVCache は、Netflix 内で広く使用されているデータ キャッシュ サービスです。低レイテンシで高可用性のキャッシュ ソリューションは、Netflix のマイクロサービス アーキテクチャのニーズを十分に満たし、一般的なデータ ストレージにも使用されます。 EVCache により、エンドユーザー アプリケーション、パーソナライズされたアルゴリズム、さまざまなマイクロサービスが優れたパフォーマンスを発揮できるようになります。

EVCache には次の機能があります。

• 分散キーバリューストレージ、キャッシュは複数のインスタンスにまたがることができる
• データはAmazon Web Servicesのアベイラビリティゾーン間で複製可能
• Netflix の内部命名サービスに登録して、新しいノードとサービスを自動的に検出します
• データを保存するには、キーは空でない文字列であり、値は空でないバイト配列、プリミティブ型、またはシリアル化されたオブジェクトにすることができ、1 MB 未満である必要があります。
• さまざまなアプリケーションで使用される一般的なキャッシュ クラスターとして、名前空間との主キーの競合を回避するためにオプションのキャッシュ名をサポートします。
• 一般的なキャッシュヒット率は99%以上
• Netflix 常駐データ フレームワークと連携して動作します。一般的なアクセス順序は、メモリ -> EVCache -> Cassandra/SimpleDB/S3 です。

1EVCacheのCSアーキテクチャ

EVCache クライアントは、EVCache サーバーを検出し、すべての CRUD 操作を管理する Java クライアントです。クライアントは、クラスターへのサーバーの追加/削除を処理します。クライアントは、Amazon Web Services のアベイラビリティーゾーンに基づいて、作成、更新、削除操作を実行するときにデータを複製します。

一方、クライアントの読み取り操作では、同じ可用性ゾーン内のサーバーから直接データを読み取ります。図 2 は、EVCache の一般的な展開構造と、単一ノードのクライアント インスタンスとサーバーの関係を示しています。

図2 EVCacheシングルノードクライアントインスタンスとサーバーの関係

EVCache クライアントは複数の EVCache サーバー クラスターに接続します。 Netflix は、Amazon Web Services のアベイラビリティゾーンによって分離されたリージョン内にデータセット全体の複数のコピーを保持しています。破線のボックスはリージョン内のレプリカを表し、各レプリカにはデータの完全なイメージが含まれ、AWS オートスケーリング グループとして管理されます。一部のキャッシュにはリージョン内に 2 つのミラーがあり、一部のキャッシュにはそれ以上のミラーがあります。この高レベルのアーキテクチャは長期的には効果的であり、変更されることはありません。各クライアントは、自身のリージョン内のすべての可用性ゾーンにあるすべてのサーバーに接続します。書き込み操作はすべてのインスタンスに送信され、読み取り操作では読み取り要求に近いサーバーが優先されます。

2EVCache クロスリージョンレプリケーション

Netflix のグローバル クラウド サービスは、バージニア州北部、オレゴン、アイルランドなどの AWS サービス地域に分散しており、これらの地域のメンバーに、よりローカルなサービスを提供しています。ただし、重要なインフラストラクチャの問題やリージョン間の障害回復演習など、さまざまな理由によりネットワーク トラフィックが変化する可能性があります。そのため、Netflix はステートレス アプリケーション サーバーを使用して、あらゆる地域のメンバーにサービスを提供しています。

このデータを永続レイヤーストレージから取得するには、非常にコストがかかります (データベースへのアクセスが頻繁に発生します)。 Netflix は、各リージョンのユーザー要求に応えるために、このデータをローカル キャッシュに書き込み、すべてのリージョンのキャッシュにコピーする必要があります。

マイクロサービスはキャッシュに依存しており、メンバーの映画視聴履歴、ランキング、パーソナライズされた推奨事項など、複数の種類のデータに迅速かつ確実にアクセスする必要があります。このデータの更新と変更は、世界中のすべての地域に複製され、これらの地域のユーザーが迅速かつ確実にアクセスできるようにする必要があります。

図3 EVCache クロスリージョンデータレプリケーション

この図は、SET 操作の後にコピー操作が実装されていることを示しています。アプリケーションは、EVCache クライアント ライブラリの set メソッドを呼び出します。その後、コピー パスは呼び出し元に対して透過的になります。

EVCache クライアント ライブラリは、キャッシュ システムのローカル領域にあるインスタンス サーバーに SET を送信します。

EVCacheクライアントライブラリは、メタデータ（キーを含みますが、キャッシュされるデータ自体は含みません）をレプリケーションメッセージキュー（Kafka）に書き込みます。

ローカルリージョンのレプリケーションリレーサービスは、このメッセージキューからメッセージを読み取ります。

リレー サービスは、ローカル キャッシュからキーに一致するデータを取得します。

リレー サービスは、別のリージョンのレプリカ リレー サービスに SET 要求を送信します。

他のリージョンでは、レプリケーション リレー サービスが要求を受け入れ、ローカル キャッシュに対して SET 操作を実行してレプリケーションを完了します。

受信領域のローカル アプリケーションは、GET 操作後にローカル キャッシュ内の更新されたデータ値を確認します。

これは簡単な説明です。これは SET 操作に対してのみ有効であることに注意してください。 DELETE TOUCH やバッチミューテーションなどの他の操作ではコピーされません。 DELETE と TOUCH は非常に似ていますが、唯一の違いは、ローカル キャッシュから既存の値を読み取らないことです。

リージョン間のレプリケーションは主にメッセージ キューを通じて実行されます。あるリージョンの EVCache クライアントは、他のリージョンのレプリケーション ステータスを認識しません。読み取りと書き込みの両方でこの領域のキャッシュのみが使用され、他の領域のキャッシュとは結合されません。これらはメッセージ システムを通じて分離されます。

3EVCache 高可用性

通常、各 AWS リージョンは複数のアベイラビリティーゾーン (AZ) で構成され、アベイラビリティーゾーンは通常、複数のデータセンターで構成されます。 AWS は、主にユーザーアプリケーションの高可用性を向上させるために、アベイラビリティーゾーン設計を導入しました。アベイラビリティゾーンは互いに独立して設計されているため、つまり独立した電源、独立したネットワークなどを備えているため、1 つのアベイラビリティゾーンで問題が発生しても、他のアベイラビリティゾーンには影響しません。リージョン内では、可用性ゾーンは高速ネットワークを介して接続され、非常に低いレイテンシが確保されます。

EVCache インスタンスは、Amazon EC2 インスタンスを複数のアベイラビリティーゾーンに配置することで、アプリケーションの単一障害点を防ぐことができます。同じ物理エリア内または異なる物理エリア間の複数の AZ で独立したアプリケーションを実行することは非常に重要です。 1 つのアベイラビリティ ゾーンに障害が発生した場合でも、他のアベイラビリティ ゾーンのアプリケーションは引き続き実行できるため、高可用性が実現されます。

EVCache クラスターは複数の Amazon Web Services アベイラビリティーゾーンにまたがっているため、障害は発生しません。インスタンスの 1 つが誤って失敗した場合、キャッシュの影響を最小限に抑えるために、クラスター シャード全体で一貫性のあるハッシュが使用されます。

キャッシュがアクティブでないときに Amazon Cloud Services にアクセスするコストは、SimpleDB、AWS S3、EC2 上の Cassandra などへのアクセスなど高いため、EVCache クラスターを運用する全体的なコストは低く抑えられ、高可用性が維持されます。EVCache クラスターの全体的なコストは、高い安定性と線形拡張の条件下では依然として満足のいくものです。

この要件の背後には、要求された各サービスに必要なデータまたは状態が複数のリージョンにわたって利用可能でなければならないという点が隠れています。高信頼性データベースと高性能キャッシュは、分散アーキテクチャをサポートするインフラストラクチャです。典型的なシナリオは、データベースまたはその他の永続ストレージの前にキャッシュを構築することです。キャッシュのグローバル レプリケーションがない場合、あるリージョンのメンバーが別のリージョンに切り替えても、新しいリージョンのキャッシュには元のリージョンのデータは含まれません。この状況をコールド キャッシュと呼びます。このようなキャッシュ データの損失に対処する唯一の方法は、データベースからデータをリロードすることですが、この方法では応答時間が長くなり、データベースに大きな影響を与えます。 EVCache は、クロスアベイラビリティゾーンレプリケーションに加えて、クロスリージョンレプリケーションも提供し、AWS ベースの高可用性を強化します。

EVCacheの典型的な適用シナリオ4つ

Netflix のユーザー エクスペリエンスは、大容量、低レイテンシ、グローバルに利用可能なキャッシュ データ レイヤーに大きく依存しています。たとえば、ユーザーがソファに座って映画やテレビ番組を視聴しているとき、セッションの保存からビデオ履歴、ユーザーのステータスまで、すべてのユーザー操作にキャッシュが存在します。これはすべて、EVCache の安定性と高いフォールト トレランスのおかげです。

典型的な使用例として、ユーザーの視聴履歴に類似した映画やテレビ番組を推奨します。図4は類似コンテンツを推奨するサービスプロセスとその中でのEVCacheの役割を紹介しています。

図4. EVCacheを使用して類似コンテンツを推奨する典型的な使用例

コンテンツ類似性推奨サービスでは、視聴履歴内の番組に類似する映画やテレビ番組の類似リストを提供します。類似度が計算されると、SimpleDB/S3 に保存され、フロントエンドは EVCache を使用します。アプリケーションまたはアルゴリズムがこのデータを必要とする場合、EVCache からデータを抽出し、結果を返すことができます。具体的なプロセスは以下のとおりです。

クライアントは Web アプリケーションにページ要求を送信します。このリクエストを処理するには、映画またはテレビ番組の類似リストを取得する必要があります。

Web アプリケーションは EVCache にクエリを実行してこのデータを取得します。このシナリオでの典型的なキャッシュヒット率は 99.9% を超えます。

キャッシュに***が含まれていない場合、Webアプリケーションは類似度計算サービスを呼び出してこれらのデータを計算します。

計算されたデータに一致するものがない場合、類似度計算サービスは SimpleDB からデータを読み取ります。 SimpleDBにない場合は、類似度計算サービスが指定された映画またはテレビ番組に基づいて類似度を再計算します。

類似度計算サービスは、映画やテレビ番組のデータを計算した後、そのデータを EVCache に書き込みます。

***、類似度計算サービスはクライアントが必要とする応答を生成し、クライアントに返します。

EVCache は線形に拡張可能です。容量監視により、1 分以内に容量を拡張し、数分以内に再バランス調整とデータ予熱を完了できます。