Service Fabric アプリケーションの容量計画
このドキュメントでは、Azure Service Fabric アプリケーションを実行するために必要なリソース (CPU、RAM、ディスク ストレージ) の量を見積もる方法について説明します。 リソース要件は、通常、時の経過と共に変化します。 一般的に、サービスの開発およびテスト中はリソースをあまり必要とせず、運用を開始したりアプリケーションが多くのユーザーに使用され始めたりすると、より多くのリソースが必要になります。 アプリケーションを設計するときは、長期的な要件を考慮し、高い顧客要求を満たすためにサービスを拡張できるようにしてください。
Service Fabric クラスターを作成するときは、どのような種類の仮想マシン (VM) でクラスターを構成するかを判断します。 各 VM は、CPU (コア数と速度)、ネットワーク帯域幅、RAM、ディスク ストレージなどの面で、リソースの量が制限されます。 サービスが成長すると共に、より多くのリソースを提供する VM にアップグレードしたり、より多くの VM をクラスターに追加したりすることができます。 後者の場合は、クラスターに動的に追加される新しい VM を活用できるように、サービスを設計しておく必要があります。
一部のサービスは、VM 自体にあるデータをほとんどまたはまったく管理しません。 そのため、容量計画は主にパフォーマンスに重点を置きます。つまり、VM の適切な CPU (コア数と速度) を選択します。 また、ネットワーク帯域幅と、ネットワーク転送の頻度や転送されるデータの量も検討する必要があります。 サービスの使用量が増加してもサービスのパフォーマンスを良好に保つには、クラスターに VM を追加し、ネットワーク要求の負荷をすべての VM に分散します。
VM で大量のデータを管理するサービスの場合は、容量計画で主にサイズに重点を置きます。 このため、VM の RAM とディスク ストレージの容量を慎重に検討する必要があります。 Windows の仮想メモリ管理システムにより、アプリケーション コードからはディスク領域が RAM のように見えます。 さらに、Service Fabric ランタイムではスマート ページングにより、ホット データのみをメモリに保持し、コールド データはディスクに移動できます。 そのため、アプリケーションは VM で物理的に利用可能なメモリより多いメモリを利用できます。 RAM を増やすと、VM がより多くのディスク ストレージを RAM に保持できるため、パフォーマンスが向上します。 選択する VM には、その VM に保存するデータに対応できるだけのディスク領域が必要です。 また、必要なパフォーマンスを提供できるだけの RAM も必要です。 サービスのデータがしだいに増加する場合は、クラスターに VM を追加し、すべての VM 間でデータをパーティション分割できます。
必要なノード数を決定する
サービスをパーティション分割すると、サービスのデータをスケールアウトできます。 パーティション分割の詳細については、 Service Fabric のパーティション分割に関するページをご覧ください。 各パーティションは、1 つの VM 内に収まる必要がありますが、複数の (小さい) パーティションを 1 つの VM に配置することができます。 そのため、小さなパーティションが多数存在する方が、大きなパーティションを少なくするよりも柔軟性が高くなります。 トレードオフは、多数のパーティションがあると Service Fabric オーバーヘッドが増えることと、パーティション間のトランザクション操作ができないことです。 異なるパーティションにあるデータにサービス コードが頻繁にアクセスする必要がある場合は、潜在的なネットワーク トラフィックも多くなります。 サービスを設計するときは、効果的なパーティション分割戦略を立てるために、これらの長所と短所を慎重に検討する必要があります。
アプリケーションに 1 つのステートフル サービスがあり、そのサービスのストア サイズが 1 年間に DB_Size GB に増えると予想されているとします。 また、翌年以降も成長する場合はアプリケーション (およびパーティション) を増やすつもりがあります。 合計 DB サイズは、レプリケーション係数 (RF) の影響を受けます。サービスのレプリカ数は、この係数によって決まります。 すべてのレプリカにわたる合計 DB サイズは、レプリケーション係数と DB_size の積です。 Node_Size は、サービスのために使用するノードごとのディスク領域/RAM を表します。 最適なパフォーマンスを得るには、DB_Size がクラスター全体のメモリに収まるようにして、VM の RAM 容量程度の Node_Size を選択する必要があります。 RAM 容量よりも大きな Node_Size を割り当てると、Service Fabric ランタイムが提供するページングが利用されます。 このため、データ全体がホットと見なされる場合は、パフォーマンスが最適ではない可能性があります (それ以降、データはページイン/アウトされます)。 ただし、ホットなデータが一部のみの多くのサービスについては、もっとコスト効率に優れています。
パフォーマンスを最大にするために必要なノードの数は、次のようにして計算できます。
Number of Nodes = (DB_Size * RF)/Node_Size
増加への対応
最初の DB_Size に加え、サービスの成長を予測した DB_Size に基づいてノード数を計算できます。 次に、ノード数を過剰にプロビジョニングしないように、サービスの成長に合わせてノード数を増やします。 しかし、パーティションの数は、最大に成長した状態のサービスを実行するときに必要なノードの数に基づく必要があります。
また、予期しないスパイクや障害 (VM がいくつかダウンするなど) に対処できるように、いつでも利用できる予備のコンピューターを用意しておくことをお勧めします。 予備の容量は、予期されるスパイクに基づいて判断する必要がありますが、まずは予備の VM を数台 (5 ～ 10% 多く) 予約しておきます。
ここで前提としているのは、単一のステートフル サービスです。 複数のステートフル サービスがある場合は、他のサービスに関連する DB_Size を式に追加する必要があります。 また、ステートフル サービスごとにノード数を個別に計算することもできます。 サービスに、バランスが取れていないレプリカやパーティションがある場合があります。 あるパーティションのデータが、他のパーティションよりも多い可能性もあります。 パーティション分割の詳細については、パーティション分割のベスト プラクティスに関するページをご覧ください。 ただし、前述した式は、パーティションやレプリカに依存しません。Service Fabric では、最適化された方法でレプリカが複数のノードに分散されるためです。
コスト計算用のスプレッドシートを使用する
ここで、具体的な数を式に当てはめてみましょう。 スプレッドシート例 は、3 種類のデータ オブジェクトを含むアプリケーションの容量を計画する方法を示しています。 各オブジェクトで、サイズと、予期されるオブジェクトの数を概算します。 オブジェクトの種類ごとに、必要なレプリカの数も選択しました。 スプレッドシートは、クラスターに格納されるメモリ量の合計を計算します。
次に、VM サイズと毎月のコストを入力します。 スプレッドシートは、VM サイズに基づいて、物理的にノードに収めるためにデータを使用して分割する場合のパーティションの最小数を示します。 アプリケーションの固有の計算とネットワーク トラフィックのニーズに対応するために、多数のパーティションが必要な場合があります。 スプレッドシートは、ユーザー プロファイル オブジェクトを管理しているパーティション数が 1 から 6 に増えたことを示しています。
ここでスプレッドシートは、このすべての情報に基づき、26 のノード クラスター上の希望するパーティションとレプリカで、物理的にすべてのデータを取得できることを示しています。 ただし、このクラスターは高密度になっているので、ノードの障害やアップグレードに対応するために、ノードをいくつか追加した方がよい場合もあります。 また、スプレッドシートは、57 個を超えるノードを用意しても、空のノードができるだけで意味がないことも示しています。 この場合も、ノードの障害やアップグレードに対応するために、57 個を超えるノードを用意した方がよいこともあります。 アプリケーションの固有のニーズに合わせて、スプレッドシートを調整できます。
次のステップ
サービスのパーティション分割の詳細については、Service Fabric サービスのパーティション分割に関するページを参照してください。