次の方法で共有

Azure Service Fabric クラスターのスケーリング

  • [アーティクル]

Service Fabric クラスターは、ネットワークで接続された一連の仮想マシンまたは物理マシンで、マイクロサービスがデプロイおよび管理されます。 クラスターに属しているコンピューターまたは VM を "ノード" と呼びます。 クラスターには、場合によっては数千のノードを含めることができます。 Service Fabric クラスターの作成後は、クラスターを水平方向 (ノードの数を変更する) または垂直方向 (ノードのリソースを変更する) にスケーリングすることができます。 クラスターは、クラスターでワークロードを実行中であっても、いつでもスケーリングできます。 クラスターをスケーリングすると、アプリケーションも自動的にスケーリングされます。

クラスターをスケーリングする理由 アプリケーションの要求は、時間の経過と共に変化します。 増加したアプリケーション ワークロードやネットワーク トラフィックに対処するためにクラスター リソースを増やしたり、需要が低下したときにクラスター リソースを減らしたりする必要が生じる場合があります。

スケールインとスケールアウト (水平方向のスケーリング)

クラスター内のノードの数を変更します。 新しいノードがクラスターに参加すると、Cluster Resource Manager はサービスをそれらのノードに移動します。これにより、既存のノードの負荷が軽減されます。 クラスターのリソースが効率的に使用されていない場合は、ノードの数を削減することもできます。 ノードがクラスターから離れるときには、それらのノードからサービスが移動し、残っているノードで負荷が増加します。 Azure で実行されているクラスター内のノードの数を減らすと、クラスター内の VM のワークロードではなく使用している VM の数に対して支払いをするため、コストを節約できます。

  • 長所:理論上は無限のスケーリング。 スケーラビリティを考慮してアプリケーションが設計されている場合は、より多くのノードを追加することで無制限の拡張が可能になります。 クラウド環境のツールによってノードの追加や削除が容易になっているため、キャパシティの調整は容易で、支払いをするのは使用するリソースに対してのみです。
  • 短所:アプリケーションがスケーラビリティを考慮して設計されている必要があります。 アプリケーション データベースと永続化についても、スケーリングのために追加のアーキテクチャ関連作業が必要な場合があります。 ただし Service Fabric ステートフル サービスの信頼性の高いコレクションによって、アプリケーション データのスケーリングが大幅に容易になっています。

仮想マシン スケール セットは、セットとして仮想マシンのコレクションをデプロイおよび管理するために使用できる Azure コンピューティング リソースです。 Azure クラスターで定義されているすべてのノードの種類は、異なるスケール セットとしてセットアップされます。 各ノードの種類は、個別にスケールインまたはスケールアウトでき、さまざまなセットのポートを開き、異なる容量のメトリックスを持つことができます。

Azure クラスターをスケーリングするときには、次のガイドラインに留意してください。

  • 種類が、実稼働ワークロードを実行するプライマリ ノードの場合、必ず 5 つ以上のノードが必要です。
  • 種類が、ステートフルの実稼働ワークロードを実行する非プライマリ ノードの場合、必ず 5 つ以上のノードが必要です。
  • 種類が、ステートレスの実稼働ワークロードを実行する非プライマリ ノードの場合、必ず 2 つ以上のノードが必要です。
  • 耐久性レベルが Gold または Silver であるノードの場合、どの種類であっても必ず 5 つ以上のノードが必要です。
  • ノードの種類からは、ランダムな VM インスタンスやノードは削除せず、常に仮想マシン スケール セットのスケール イン機能を使用するようにします。 ランダムな VM インスタンスを削除すると、適切に負荷を分散するシステム機能に悪影響を及ぼす場合があります。
  • 自動スケーリング ルールを使用する場合は、スケールイン (VM インスタンスの削除) が一度に 1 ノードずつ行われるようにルールを設定してください。 一度に複数のインスタンスをスケールダウンすることは安全ではありません。

クラスター内の Service Fabric のノードの種類は、バックエンドの仮想マシン スケール セットで構成されるため、ノードの種類/仮想マシン スケール セットごとに、自動スケール ルールを設定するか、手動でスケーリングすることができます。

プログラムによるスケーリング

多くのシナリオでは、手動でのクラスターのスケーリングまたは自動スケール ルールを使用したスケーリングが適しています。 しかし、より高度なシナリオでは、これらの方法が適さない場合もあります。 このアプローチの潜在的な欠点は次のとおりです。

  • 手動でスケーリングを行うには、サインインし、スケーリング操作を明示的に要求する必要があります。 スケーリング操作が頻繁に必要になる場合または予期せず発生する場合は、このアプローチは適さない可能性があります。
  • 自動スケール ルールによって仮想マシン スケール セットからインスタンスが削除されても、そのノードのナレッジは、そのノードが Silver または Gold の耐久性レベルを持つ種類でない限り、関連付けられた Service Fabric クラスターからは自動的に削除されません。 自動スケール ルールは (Service Fabric レベルではなく) スケール セット レベルで適用されるため、自動スケール ルールを使用すると、Service Fabric ノードを整然とシャットダウンせずに、削除してしまうことがあります。 このような方法でノードの削除を行うと、スケールイン操作の後で、Service Fabric ノードが "ゴースト" 状態で背後に残ります。 ユーザー (またはサービス) は、Service Fabric クラスターから削除したノードの状態を定期的にクリーンアップする必要があります。
  • Gold または Silver の耐久性レベルを持つノード型では、削除したノードが自動的にクリーンアップされるため、追加のクリーンアップは必要ありません。
  • 自動スケール ルールでは多くのメトリックがサポートされていますが、これらは限定されたセットに過ぎません。 このセットでカバーされていないメトリックに基づくスケーリングが必要なシナリオでは、自動スケール ルールは適さない可能性があります。

Service Fabric のスケーリングの方法は、シナリオによって異なります。 スケーリングが頻繁でなければ、ノードを手動で追加または削除する機能だけでおそらく十分です。 さらに複雑なシナリオの場合は、自動スケール ルールと、プログラムでスケーリングを行う機能を公開している SDK が強力な代替手段となります。

Azure API を使用すると、アプリケーションがプログラムで仮想マシン スケール セットと Service Fabric クラスターを使用できるようになります。 既存の自動スケール オプションが使用できないシナリオでは、これらの API を使用してカスタム スケーリング ロジックを実装できます。

この "自作" の自動スケール機能を実装する 1 つの方法は、新しいステートレス サービスを Service Fabric アプリケーションに追加して、スケーリング操作を管理することです。 独自のスケーリング サービスを作成すると、アプリケーションのスケーリング動作において最高レベルの制御とカスタマイズ性を実現できます。 これは、アプリケーションをいつ、どのようにスケールインまたはスケールアウトするかについて、細かい制御が必要なシナリオに役立てることができます。ただし、制御を細かくすると、代わりにコードが複雑になります。 このアプローチでは、スケーリング コードに責任を持つことを意味し、これは簡単なことではありません。 サービスの RunAsync メソッド内で、スケーリングが必要かどうかを一連のトリガーで判断できます (最大クラスター サイズやスケーリングのクールダウンなどのパラメーターのチェックを含みます)。

仮想マシン スケール セットの操作に使用する API (現在の仮想マシン インスタンスの数の確認と変更の両方) は、fluent Azure Management Compute ライブラリです。 fluent コンピューティング ライブラリは、仮想マシン スケール セットを操作するための使いやすい API です。 Service Fabric クラスター自体を操作するには、System.Fabric.FabricClient を使用します。

ただし、スケーリングのコードは、スケーリング対象クラスターのサービスとして実行する必要はありません。 IAzure と FabricClient は両方とも、関連する Azure リソースにリモートで接続できるので、スケーリング サービスは Service Fabric アプリケーション外で動作するコンソール アプリケーションまたは Windows サービスとして簡単に使用することができます。

これらの制限に基づいて、さらにカスタマイズされた自動スケーリング モデルの実装が必要になる可能性があります。

スケールアップとスケールダウン (垂直方向のスケーリング)

クラスター内のノードのリソース (CPU、メモリ、またはストレージ) を変更します。

  • 長所:ソフトウェアやアプリケーションのアーキテクチャは変わりません。
  • 短所:スケーリングには限度があります。個々のノード上でリソースをどれだけ増加できるかに制限があるためです。 リソースを追加または削除するために物理マシンまたは仮想マシンをオフラインにする必要があるため、ダウンタイムが生じます。

仮想マシン スケール セットは、セットとして仮想マシンのコレクションをデプロイおよび管理するために使用できる Azure コンピューティング リソースです。 Azure クラスターで定義されているすべてのノードの種類は、異なるスケール セットとしてセットアップされます。 その後は、ノードの種類ごとに個別に管理できます。 ノードの種類をスケールアップまたはスケールダウンするには、新しいノードの種類を (更新した VM SKU を使用して) 追加し、古いノードの種類を削除する必要があります。

Azure クラスターをスケーリングするときには、次のガイドラインに留意してください。

  • 種類がプライマリ ノードであるスケールダウンを行う場合は、信頼性レベルで許されるより多くスケールダウンしないでください。

あるノードの種類についてスケールアップまたはスケールダウンを行うプロセスは、ノードの種類がプライマリ以外であるかプライマリであるかによって異なります。

種類がプライマリ以外のノードのスケーリング

必要なリソースを持つ新しいノードの種類を作成します。 実行するサービスの配置に関する制約を、新しいノードの種類を含むように更新します。 クラスターの信頼性が影響を受けないように、古いノードの種類のインスタンス数を徐々に (一度に 1 つずつ) 0 まで減らします。 サービスは、古い種類のノードが使用停止されるのにつれ、しだいに新しい種類のノードに移行されます。

種類がプライマリのノードのスケーリング

更新した VM SKU を使用して新しいプライマリ ノードの種類をデプロイしてから、システム サービスが新しいスケール セットに移行するように、ノードの種類がプライマリである元のインスタンスを一度に 1 つずつ無効にします。 クラスターと新しいノードが正常であることを確認してから、削除したノードの元のスケール セットとノードの状態を削除します。

それが不可能な場合は、新しいクラスターを作成し、古いクラスターからアプリケーション状態を復元する ことができます (妥当な場合)。 システム サービスの状態を復元する必要はありません。それらは新しいクラスターにアプリケーションをデプロイしたときに再作成されます。 クラスターでステートレス アプリケーションだけを実行していた場合、実行するのはアプリケーションの新しいクラスターへのデプロイのみであり、復元するものはありません。

次のステップ