BizTalk Server 層のスケール アウト
BizTalk Server 層をスケール アウトするには、追加のハードウェアを既存のトポロジに追加します。 次のシナリオでは、ハードウェアを追加することをお勧めします。
BizTalk Server がボトルネックになります。 ボトルネックは、次のいずれかの問題によって引き起こされる可能性があります。
CPU: CPU を集中的に使用するパイプライン、マップ、またはオーケストレーションをシナリオで使用する場合に、BizTalk Server に余分な CPU ヘッドルームがない。
メモリと I/O: 既存のコンピューターのメモリおよび I/O が上限に達した場合に、リソースを追加する方法として、別の物理的なコンピューターを追加するしかない。
スケール アップは、非常に高コストです。 たとえば、BizTalk の CPU が最大容量に達しているシングル BizTalk Server トポロジについて考えてみます。 デュアル プロセッサをクワド プロセッサにアップグレードするよりもデュアル プロセッサを搭載したコンピューターを追加する方がコストがかからない場合は、システムをスケール アウトする必要があります。
スケール アップは、ボトルネックを解消しません。 次のシナリオでは、スケール アップが機能しない場合があります。
I/O が BizTalk コンピューターの最大値に達したので、I/O を調整するために別のコンピューターが必要である。
メモリがオペレーティング システムの最大値に達している。 このシナリオで、システムを拡張する方法は、BizTalk コンピューターをトポロジに追加する方法だけです。
一部のシナリオでは、メッセージの受信、メッセージの送信、およびその処理を行う専用サーバーが必要になる場合があります。 専用サーバーがあれば、問題を切り離して、他のコンピューターに影響を与えることなく 1 台のコンピューターの保守を行うことが容易です。 BizTalk 層を拡張して、これらのコンピューターを追加できます。
BizTalk 層をスケール アウトできない場合
メッセージ ボックス データベースがボトルネックの場合。
アダプターがボトルネックになる場合。 たとえば、SQL アダプターを使用している場合、BizTalk の受信者数を増やすと、BizTalk SQL アダプターがデータを抽出する SQL データベースでロックの競合が増えます。 このため、SQL アダプターのスケール アウトが制限されます。
次の図は、BizTalk 層のスケール アウト方法の例を示しています。
この図は、スケール アウトされた BizTalk トポロジを示しています。シングル BizTalk Server からダブル BizTalk Server に拡張されています。 シングル BizTalk Server トポロジでは、3 つのホスト インスタンスが BizTalk コンピューター リソースを共有しています。 ダブル BizTalk Server トポロジでは、送信ホストが別のサーバーに分離され、スループットが向上します。
BizTalk 層をスケール アウトする際の注意
別の BizTalk Server コンピューターを追加する前に、次の質問を考慮する必要があります。
BizTalk 層をスケール アウトする際、負荷分散およびフォールト トレランスを考慮するとシステムをどのように構成すればよいか
負荷分散およびフォールト トレランスを使用するかどうかは、シナリオで使用されているアダプターによって異なります。 SOAP アダプターおよび HTTP アダプターを使用する場合、NLB を使用することをお勧めします。 詳細については、NLB のドキュメントを参照してください。
ホスト インスタンスをリファクタリングするにはどうすればよいか
BizTalk 層をスケール アウトする際にホスト インスタンスをリファクタリングする方法を規定している規則はありません。 ホスト インスタンスをファクタリングする時期は、シナリオの複雑さによって異なります。 ホスト インスタンスをファクタリングする方法の例をいくつか次に示します。
シナリオ 1
シングル BizTalk Server 構成で、受信用と送信用のホスト インスタンスが同じコンピューター上にあります。
CPU にボトルネックがあると仮定します。 スケール アウトするために別の同等の BizTalk コンピューターをグループに追加する場合、ホスト インスタンスをファクタリングする方法は 2 つあります。
この問題の 2 つの解決方法を次に示します。
解決策 1: このシナリオで考慮する最も簡単な方法は、ホスト インスタンスのファクタリングを最初のコンピューターから 2 台目のコンピューターに複製することです。 したがって、2 番目のコンピューターは、機能性の面で 1 番目のコンピューターと完全に同等になります。また、受信ホストおよび送信ホストの両方を使用できます。 他のボトルネックがないと仮定した場合、CPU リソースが 2 倍になるため、スケール ファクターは 2 となります。
解決策 2: ホスト インスタンスを考慮するもう 1 つの方法は、受信機能と送信機能を異なるコンピューターに分離することです。 したがって、1 つの BizTalk Server を受信用に使用し、他の BizTalk Server を送信用に使用します。
解決方法 1 と解決方法 2 の比較
解決方法 1 のホスト インスタンス数は、シングル BTS 構成の 2 倍になります。 つまり、SQL Server 上のロックの競合が増加することを示しています。 ロックの競合がどれだけ増えるかによって、スケール ファクターが決まります。 ロックの競合がボトルネックとなる制限の範囲内の場合、スケール ファクターは 2 になります。
ソリューション 2 の利点は、ホスト インスタンスが 2 つしかないため、SQL サーバーのロック競合がソリューション 1 と比較して少なくなる必要がある点です。 ただし、スケーリング係数は、受信および送信ホスト インスタンスの複雑さに完全に依存します。 解決方法 2 での次のような事例を考えてみます。
受信ホスト インスタンスと送信ホスト インスタンスに同じ負荷がかかり、シングル BizTalk Server トポロジでそれぞれが CPU の 50% を使用していると仮定します。 ダブル BizTalk Server トポロジでは、送信ホスト インスタンスを別のコンピューターに移動するため、受信と送信の両方でリソースを 2 倍消費します。 このため、他のボトルネックがないと仮定した場合、スケール ファクターは 2 になります。 ホスト インスタンスが 2 つだけでロックの競合が少ないため、この事例では解決方法 1 よりも適しています。
受信よりも送信に多くの負荷がかかり、シングル BizTalk Server トポロジで 80% の CPU リソースを消費していると仮定します。 送信ホスト インスタンスを別のコンピューターに移動しても、使用できる CPU リソースは 20% しか増えません。このため、スケール ファクターの最大値は、1.2 になります。 さらに、受信ホスト インスタンスのコンピューターは、CPU リソースを 20 ～ 30% しか使用しません。このため、スケールアウトの利点はさらに少なくなります。
4 つの BizTalk Server のある次の図を見てください。 各コンピューターは受信側と送信側の両方であり、各種類 (受信と送信) の合計 4 つのホスト インスタンスを提供します。
ファクターこのトポロジは、最適ではありません。 また、シナリオの複雑さに応じて、他のファクタリングの配置をテストする必要があります。 次に例を示します。
受信用の 2 台のコンピューターと送信用の 2 台のコンピューターを専用にします。 これによって、受信と送信で同じ負荷がかかった場合に、最適な拡張を行うことができます。
送信よりも受信に負荷がかかっている場合、受信用に 3 台のコンピューター、送信用に 1 台のコンピューターを使用します。
受信よりも送信に負荷がかかっている場合、受信用に 1 台のコンピューター、送信用に 3 台のコンピューターを使用します。
すべてのシナリオにおいて、メッセージ ボックス データベースの競合を減らすと共にコンピューター リソースを最大限に利用するため、各ホストのホスト インスタンスの数を最小限にすることをお勧めします。 最適なファクタリングの配置は、シナリオの複雑さとボトルネックの種類によって異なります。 配置を決める前にファクタリングを必ずテストしてください。
参照
BizTalk Server 層のスケール アップ
SQL Server 層のスケール アップ
SQL Server 層のスケール アウト
受信ホストのスケールアウト
スケールアウトした処理ホスト
スケールアウトした送信ホスト
Windows Server クラスターを使用したBizTalk Server ホストの高可用性の提供2
スケールアウト データベース
BizTalk Server データベースのクラスタリング