アプリケーションのコンポーネントを追加／削除する際、ロードバランサーのトランクポートも追加／削除する必要がある。コンポーネントに問題が生じ交換する場合、そのコンポーネントのトランクポートアドレスの更新が必要だ。多くの企業にとっては、これが問題になる。それはロードバランサーがネットワークミドルウェアの一部になっていることが多いためだ。ハイブリッドクラウドアーキテクチャでは、データセンターとクラウドで異なるソフトウェアが使用される可能性が高いことを前提として、ロードバランサーを機能させる方法を考える必要がある。

　2つ目の疑問は、パフォーマンスとQoEをどのように管理するかだ。パブリッククラウドと自社のデータセンターのネットワーク接続とパフォーマンスが同じになる可能性は低い。恐らく、似てもいないだろう。パブリックインターネットを使用する企業も含めて、多くの企業のパブリッククラウドとの接続は比較的低速だ。ネットワークのレイテンシとパフォーマンスも異なっている。つまり、コンポーネントの新しいインスタンスがクラウドとデータセンターのどちらに存在するかによってパフォーマンスが異なる。この違いが問題になる可能性があり、キャパシティープランニングを複雑にする。

　3つ目の疑問は、状態管理の問題にどう対処するかだ。ほとんどのビジネスアプリケーションはトランザクションベースだ。つまり、このようなアプリケーションではユーザーとアプリケーションが特定の対話を繰り返す間に複数のメッセージを交換する。負荷分散により、特定のトランザクションに関連するメッセージが別のコンポーネントに送信される恐れがある。このコンポーネントがステートフルの場合、つまり全体としてトランザクション処理をすることを想定する場合、ソフトウェアで障害が発生したり、データベースが破損したりする可能性がある。

戦略の指針となる3つの原則

　このような課題に対処するため、ハイブリッドクラウドアーキテクチャにポリシーベースのスケーラビリティを導入する。特定のコンポーネントは、通常はできる限りネイティブホスト環境内でスケールを拡張する。障害の発生時やリソースが不足している場合にのみ、クラウドとデータセンターの間でスケールを拡張する。

　クラウドとデータセンターの間を行き来する全てのワークフローを処理するため、パブリッククラウドサービスとの接続の容量を慎重に計画する。さらに、パブリッククラウドとデータセンターが相互にバックアップする回数を制限する。そうすれば、両者の接続要件の評価が容易になり、データセンターの復旧戦略でクラウドの接続の問題が発生しなくなる。

　単一のデータセンター、緊密に接続されるデータセンター、単一のクラウドプロバイダーなど、限られた範囲のリソースプールの中でコンポーネントのスケールを拡張する。このアプローチにより、パフォーマンスの安定性が向上し、新しいコンポーネントのアドレスでロードバランサーを簡単に更新できる。

　2つ目は、クラウド内でフロントエンド処理をするようにアプリケーションを設計する。既に多くの企業がこのアプローチを取っているが、まだ一般的になっていない。クラウド内でフロントエンド処理をすることで、クラウドのスケーラビリティと負荷分散サービスを最も重要な部分（エンドユーザーの接続ポイント）に利用することができる。このモデルでは複数のメッセージが関係するトランザクションを1つのメッセージにまとめることができるため、状態管理の問題を回避できる。

　3つ目は、アクセシビリティと可用性を目的にロードバランサーを設計する。クラウドをフロントエンドにする場合、クラウド内でロードバランサーを動作させる。データセンターのコンポーネントを負荷分散する場合は、ロードバランサーをデータセンター内で動作させる。こうすることで、ロードバランサーの更新が容易になり、サポートする全てのコンポーネントとの接続を維持できるようになる。

　ロードバランサーの可用性は非常に重要だ。しかし、見過ごされることが少なくない。ほとんどのクラウドプロバイダーは高可用性を実現できるようにロードバランサーを設計している。自社のロードバランサーを使用する場合、古いインスタンスで問題が発生したら、ロードバランサーの新しいインスタンスへの接続を提供しなければならない。

　仮想化は、どのような形態であれ、スケーラビリティを向上する。「Kubernetes」などのコンテナオーケストレーターやその他のホスティングツールの機能が向上するにつれ、ロードバランサーのオプションが増えると予想される。同時に、ロードバランサー全てをハイブリッドクラウドアーキテクチャで正しく機能させるのが難しくなる。だが、ここで説明した原則を当てはめれば、今後の拡張の問題に対処できるだろう。