この記事は機械翻訳されたものです。

予測: クラウド

Windows Azure のロール内キャッシュ (機械翻訳)

Joseph Fultz

運が、準備で支持する古い概念のアイデアをどのように幸運であっても、ラッキーの出現に活用するために準備する必要があることを伝えるものです。 私はしばしばこの声明は、かなり正確にキャッシュについて説明しますを考えてきました。 整列のような方法のあなたのサイトやサービスでドライブの高い使用する宇宙のために十分に幸運なら、良いコンテンツを迅速に提供する準備でしょう。

戦術的ではなくいくつかに焦点を当ててキャッシュに関するいくつかの概念をカバー 1 月コーディング アプローチ (msdn.microsoft.com/magazine/hh708748)。 加えて、Windows Azure は、単にキャッシュ プレビューとしてここに参照してくださいよ、キャッシュで (プレビュー) のキャッシング専用と共存の役割の全体的なソリューションのアーキテクチャの一部としてこれらのロールを使用する方法を検討する有用であると感じた。 これは、キャッシュ機能を包括カバーされません; 代わりに、それは何を大きなブロックをするは、デザイナーのビューに意図しました。

他の名前のキャッシュ.

... 同じではありません。 確かに、バック エンドの実装はかなり似ているし、その前身のような共有 Windows Azure キャッシュ、キャッシュのプレビューにローカル キャッシュ クライアントのフェッチ データに移動します。 プレビュー キャッシュ共有ので役割に基づいてキャッシュしないを切り替えキャッシュから欠落しているいくつかの機能を紹介しますより重要なだけ利用可能な機能セットを拡大、それはまたよりよい制御の展開アーキテクチャを与えます。 開始するには、専用と共存している役割の主な違いを明確にしてみましょう：構成です。

キャッシュ ノードを構成するときにキャッシュの役割全体を捧げ、または脇設定するだけの役割の割合のオプションがあります。 ちょうどすぐに RAM の同じ場所のキャッシュを予約した場合の影響を考慮する方法として、見て図 1、使用可能な RAM キャッシュ予約後残りを表わします。 (併置オプションは X-小型インスタンスで利用可能ではないことに注意してください)。

図 1 残りの RAM

しばしば最初の考えは、単にいくつかの中・小規模のサイズを選択し、いくつかの量のメモリ割り当てことです。 割り当てられたメモリの量がその使用目的と利用できる RAM の境界内に十分である限り、これは良いアプローチです。 しかし、オブジェクトの数が各マシン上のキャッシュ クライアントがそのオブジェクトの最大数を開催可能性があります合理的な期待がある場合は、その結果予期しないメモリの圧力かもしれない。 また、あまりにも少ないキャッシュ RAM キャッシュの全体的な効果を低減、不要なキャッシュの立ち退きに可能性があります。

図 2 仮想マシン (VM) サイズに基づいて RAM の使用量の割合を示します。 1 つに基づく、グラフ msdn.microsoft.com/­ライブラリ/hh914152、これはキャッシュ専用モードで利用可能な RAM の量を示しています。

図 2 専用のロールのキャッシュの使用

私の同じ場所に配置グリッド (図 1）、私のアプリケーションは RAM の大部分を必要を想定ための同じ場所に配置のタイプの 40 ％ の割り当てを超えて行かなかった。 比較では、専用のバージョンは通常より多くの RAM を提供しますが、大きな VM サイズの RAM 割り当ての最大効率をヒットに表示されます。 その意味で、2 つの中型の Vm は 1 つの大きなよりより少なく有用です。 もちろん、1 つの大規模なインスタンス キャッシュ インフラストラクチャで必要があります、データ、複製高可用性 (HA) などのオプションを助けることができません。 それでも、それは計量空間に対する冗長性の必要性のニーズと技術的ニーズを満たすだけではなく、またコストを最適化する構成を選択する価値です。

キャッシュ意図的に、RAM の干ばつ通常行われるとき、問題ではないです。 ただし、共有キャッシュ セッション オブジェクトおよび/または出力キャッシュ バックされる場合は、状況傾向をすべて、正確な負荷予測の難しさのためのセッションを使用するため、もう少し挑戦的です。 たとえば、深いモデルを持つモデル-ビュー-コント ローラーのアプリケーションを実行している場合のセッションを配置しているとキャッシュ クライアントのオブジェクトの最大数を増やす、中型または大きい負荷の下で、予期しない結果が発生する可能性があります。 これは、サイトのパフォーマンスを低下による共有キャッシュからの立ち退き数から期待していなかったメモリ圧力として表面に現れるだろう; 忘れてはいけない、キャッシュ クライアントは、可能性がより多くの RAM、増加最大オブジェクト数と深いグラフの組み合わせにより、予想よりも保持しています。 フレームワークあなたは少しをシリアル化されたオブジェクトを圧縮が RAM としてこのような貴重なと有限リソースの助け、会計デューデリジェンス ベストプラクティスは、特にアプリケーション、出力キャッシュ、セッション オブジェクト、データ キャッシュ、およびキャッシュ クライアントの間で RAM を共有しようとしたときです。 あなたのキャッシュのサイズ変更で支援するため、マイクロソフトで見つけることができます、キャパシティ プランニング ガイド スプレッドシートを公開しています msdn.microsoft.com/library/hh914129。

地域

領域は、いくつかの素晴らしい機能を追加するが、コスト。 コストは地域によるそのキャッシュ ホストのボトルネックになっているキャッシュ クライアントで格納されていないときに、領域内のオブジェクトに対するすべての要求を強制的に 1 つのサーバーに固定されていることです。 逆さまに領域を使用するタグ付け機能を提供することです。 地域の私のお気に入りの使用は、プリフェッチの参照データを保持するためにです。 これは、ボトルネックの問題のため最初の愚かさを思えるかもしれないが、見てみましょう。

キャッシュの使用を考慮するには、私は 10,000 の製品で最大 8 つのバリエーションの各製品のカタログは潜在的に 80,000 のアイテムのカタログがある公準します。 1 K の平均が各オブジェクトのアイテムを表す場合は、その周りに要求ごとにシャッフルするキャッシュ クライアントのスペースを取る約 82 MB です。 また、あるいくつかのいずれかの完全なコピーの仮想カタログまたは、元のサブセットについて、シャッフルして参照データの爆発を終わることができるように 1 つの地域のホストすべてで提供 (を参照してください図 3)。

図 3 キャッシュのレイアウトを 1 つの領域

ただし、簡単な作業ではデータのサブセクションを保持するためにより多くの領域を作成できます。 たとえば、部門またはセグメントに私のカタログを破損可能性があります。 消費者製品とプロフェッショナル製品、何かの結果の 1 つで示されているもののよう私はたとえば、1 つの領域を作成できませんでした、 図 4。

図 4 キャッシュ レイアウトを 2 つの領域

これは、キャッシュにはもう少しの粒度を提供します、使用が可能のすべての私のキャッシュ オブジェクトを保持するために小さいロールのキャッシュ更新を容易、役割ごとに、クエリを削減、タグのクエリを使用してフィルター処理トラフィックを減少します。

タグのコンテンツを機能領域の使用を運転の主要な機能です。 したがって、私のカタログのコンテンツをマークできます。 コンピューターでは、たとえば、私はタグよう必要があります。「ノート パソコン、」"4 GB""8 GB"「15 インチ」、「HD オーディオ」「デスクトップ」と。 この方法ではナビゲーションのためのファセットの製品検索などの UI 要素に GetObjectsByTag の方法のいずれかの呼び出しを使用して有効にできます。 また、データ アクセスのリエンジニア リングを意味層し、, いくつかの点では、詳細をプライマリ データとしてソース ファセット (タグ) のデータに対するクエリは満足しているによってキャッシュを扱います。

この機能を利用する興味深い方法は、Windows Azure ストレージ テーブルは、バックエンドのデータストアとして使用するは、データのプリフェッチそれをタグ、キャッシュに置くことです。 これはいくつかのコストを最小限に抑えながらストレージ テーブルの現在の化身から欠落してフィルタ リングを提供します。

領域を使用する多くのキャッシュされたデータを取得する柔軟性を提供しますが、展開インフラストラクチャにそれを置くひずみの特定の種類に注意してください。 それでも、領域は、プリフェッチし、参照データにアクセスする手段として便利です。

高可用性

HA キャッシュを考慮するは面白いです — HA キャッシュを使用して、注意するが HA を使用するときに注意する必要があります。 少なくとも、本当に高可用性を必要なものについて適切に思慮する必要があります。

すべての役割のための複製が有効に実際のオブジェクトに必要な領域の量を 2 倍にするため、はるかに高速 RAM が不足を実行します。 したがって、設計の問題としては、HA は実際にそれを必要とまたはが大幅に任意のドライブのコストをあるいは人工的にキャッシュ evictions 多食重複キャッシュから生じるメモリ不足のためをトリガーするように UX を改善する機能のみを使用するが最善です。

照会できますのでセッション オブジェクト HA キャッシュにユーザー間で特定のタグの値に基づいてアクティブなセッションで置く示唆しているいくつかのガイダンスを見てきました。 それに不公平にセッション オブジェクトをキャッシュから取得するときの負荷の分散にほとんどのインスタンスでは、これに役立つ方法がではない; そのロード パターンより密接に、サイトの負荷分散に従う必要があります。 また、あなたも多くの空の匿名プロファイルに加えて登録済みユーザーの下で識別があるため、タグ ベースの検索をユーザー プロファイルのようなエンティティが役立つよりも実際に詳細を制限します。

ユーザー オブジェクト、セッション、出力キャッシュ、およびように独自の名前付きキャッシュを置くが、それらのための複製を有効にしないをお勧めします。 場合は編集データをセッションに関連付けられて、アプリケーションのライフ サイクルでは場所によって HA キャッシュを持つセッションをバックアップを検討する可能性があります。 App はまだされている場合は、設計、作成、その場状態オブジェクトを分離し、HA キャッシュはセッション外でそれらを配置する方が良いです。 これは、セッションの範囲外のユーザーに関連するデータの編集を管理することができます、キャッシュ、セッションであまりをより均等に保つために 。 ただし、あなたのアプリがに沿ってさらにしたくないを失うの法的、財政やセッション オブジェクトとがバインドされているちょうど使いやすさの理由のためのデータがある場合は、それだけセッション HA キャッシュに配線することは-だけ具体的には、ロード テストでストレスし、実装の限界を知っているにしてください。 そのコンテンツまたはそのプロセス内のポイントのために重要であるデータを超えて­— ようなインターフェイスのバックアップ、編集データ — 大規模な基準セット、プリフェッチ データ、計算済みデータ HA の即時ターゲット データの種類します。

これらのすべての間で共通性は、そのデータを再びプリフェッチするコストです。 プリフェッチ、または事前に計算された参照データの場合キャッシュを首相にコスト スタートアップは非常に重要なすることができます、実行時に、データを失うこと重度も壊滅的な影響は上のサイトの実行があります。 図 5キャッシュ オブジェクトを割り当て可能性がありますオンに HA と方法を示しています。 重複断層の異なるドメインにある必要がありますので、全体的な RAM キャッシュに使用できる、重複を減らす方法を見ることができます。 これは常にそれ必要なものだと言うにはそんなに悪いだと言うのではないです。 私は単に HA の潜在的な影響の意識を示唆しています。

図 5 高可用性と障害ドメイン

レゴの家

開発者は、しばしばレゴ ブロックの建物としての開発を考えてみたいと; 基本ブロックを作成してそれらを一緒に有用なアプリケーションをスナップします。 このアイデアは我々 オブジェクトをアプリケーション スタックに関数からさらにインフラストラクチャのコンポーネントに移動されていても変わりません。 そのためには、いくつかのデザイン指導を残してたいと思います。

最初に、すべてのあなたの利点にツールを使用します。 1 つの方法が簡単なので HA のみ、またはなしの HA を解決しないでください。 リージョン ベースのキャッシュだけは、それらを検索することができますので使用しないでください。 または彼らはインスタンスに固定されて得るためにそれらを見送る。 むしろ、あなたのニーズに合わせてキャッシュ インフラストラクチャを構築します。

図 6 を使用して私の重複のキャッシュとより豊かな検索のキャッシュを使用領域を収容する専用のロールを示しています。 ユーザー トラフィックのすべてのキャッシュ フェッチの特定領域に関連のトラフィックを提供している役割をロードしたくない一般的なルールとしては、私は住宅地域専用のキャッシュの役割を支持します。 最下行の図 6 セッション、出力、私のアプリケーションの実行中にキャッシュ可能性がありますその他の各種のデータを保持するキャッシュの共存のスタイルが使用されています。 これは、主キャッシュの役割をする項目の RAM 要件が異なりますので私専用こだわっているまたは併置されたロールとして描かれている、わけではないためです。 確かに、多くの実装では、一番下の行だけでトリックを HA、地域または専用のロールによって与えられる RAM の大量の必要はありませんを行います。

図 6 キャッシュの展開の可能性

最後に、 図 7 私の開始を識別するグリッド ポイントの異なる種類のデータ私は私のキャッシュの展開を設計する方法を検討しているときです。

図 7 の構成の設定

これでない方法の使用を指示するか役割を示唆するものですか私が識別したスロットだけの便利な機能です。 それはちょうど私の出発点です。 プリフェッチ データのタグで検索できるようにしたいの大規模なセットを持っていた場合は、地域と HA を使用して専用のキャッシュの役割で終わるマーク項目を組み合わせると思います。 セッションを使用してユーザー データを編集している間、そのモデルをキャッシュに配置されたアプリケーションを有すればのとき私の出発点からを振れる可能性がある例としては、私は最も可能性の高いセッション、併置されたキャッシュに配置し専用のロールにそれを置くだけでなくも HA を有効にする私の傾向を投げるでしょう。

だから、あなたがビジー状態のサイトが十分に幸運なら、キャッシュ インフラストラクチャを正しく準備することによってあなたの運を続けることを確認します。

Joseph Fultz はヒューレット ・ パッカード株式会社作業グッドエイチピードットコム グローバル IT グループの一部としてのソフトウェア アーキテクトです。 以前、彼はマイクロソフト、作業その一流企業と ISV の顧客のアーキテクチャと設計ソリューションを定義するためのソフトウェアアーキテクトだった。

この記事のレビュー、次技術専門家のおかげで。Rohit Sharma とハンツ張