アプリケーションをクラウドに移行することは、単にマシンイメージを生成するだけの問題ではありません。クラウドへの移行は、アプリケーションの整合性、パフォーマンス、セキュリティ、コンプライアンスを支えるデータセンター設備を危険にさらす可能性があります。これらの要素はすべて重要ですが、どのようなアプリケーションでも、ビジネスのニーズを満たす能力が第一の鍵であり、これを決定する上で運用パフォーマンスが最も重要です。
アプリケーション・パフォーマンス管理は、単なる対策のセットではなく、ツールキットでもあり、ユーザー・エクスペリエンスの品質において最も重要な要素の 1 つです。現在の APM のプラクティスをクラウドに移行するか、現在のプラクティスをクラウドに適した同等のものに置き換えることが重要です。
従来のAPMはアプリケーションに重点を置き、以下の方法の1つ以上によってパフォーマンスを向上させます：
- 実効スループットを向上させるトラフィック圧縮；
- アクセス・アクセス側で、時間やパフォーマンスが重要なトラフィックを優先します；
- 伝送制御プロトコル（TCP）をパケットロスに対応できるように特別に置き換えたもの；
- ネットワークを経由する複数の並列パスにより、実効帯域幅を拡大；
- 複数のサーバーにまたがるトラフィックの負荷分散。
一般的に、これらのアプローチはすべて、設備やソフトウェア・エージェントを使用することで、ユーザー側とサーバー側の接続の両端で実装することができます。しかし、サーバー側がクラウドに移行する場合、このような実装は、特にネットワーク設備に関わる場合、問題となる可能性があります。クラウド事業者は、ユーザーがデータセンター内に設備を設置することを許可することはほとんどありません。また、許可することがあったとしても、クラウドVMにアプリケーションを分散させることで、アプリケーションをアクセラレーション設備から遠ざけてしまう可能性があります。
この問題の解決策は、ハードウェアの代わりに APM ソフトウェアツールを使用することです。より効果的に対処するためには、APMツールはアプリケーションのマシンイメージにネットワークミドルウェアの形で存在する必要があります。サーバ側のソフトウェアベースのエージェントは、必要に応じてデバイスとペアリングすることができ、そのような組み合わせは、現在の APM イニシアチブの機能の少なくとも一部をサポートすることができます。
クラウドアプリケーションのパフォーマンスにおける頑固なボトルネック
クラウドプロバイダーのネットワークが外部施設を受け付けなくなっただけでなく、クラウド上のアプリケーションの複数のインスタンスが同じデータセンターに存在するとは限らないため、ロードバランシングにも特有の問題が生じます。DNS用に利用可能なソフトウェアベースの分散ロードバランシングメカニズムがありますが、アプリケーションが適切に機能するようにするには、アプリケーションに合わせて若干調整する必要があるかもしれません。
次のステップは、クラウド・コンピューティング以外で発生するネットワーク・パフォーマンスの問題に対処することです。クラウド・プロバイダーは通常、インターネット経由でユーザーと接続し、可能な限り最高のサービスを提供します。組織がより高いパフォーマンスを必要とする場合は、仮想プライベート・ネットワークを使用する必要がありますが、すべてのクラウド・プロバイダーが、ユーザーがVPN接続を介して自社のクラウドにアクセスできるわけではありません。また、プロバイダーがVPNアクセス・アクセスをサポートしている場合でも、ネットワーク・オペレーターが提供するVPNサービスには制限がある場合があり、VPNの使用は、ホスティング・ポイントから地理的エリアへの分散など、クラウド・コンピューティングの機能にも影響を及ぼす可能性があります。クラウド・プランナーは、クラウド・コンピューティング・サービス・プロバイダーの候補が提供するすべてのVPNオプションをよく認識し、そのプロトコルの寿命について調べるようにしなければなりません。
クラウドのパフォーマンス管理では、データセンターでは常に利用できないオプションを提供する必要もあります。クラウドプランナーの約3分の1が、例外的なワークロードの急増に対処するために、データセンターからクラウドにワークロードを移動する「クラウド・バースト・アプローチ」の使用を希望しています。多くのローカル・クラウド・アプリケーションは、ユーザー数やサービス・トランザクションを増加させるために、アプリケーションの新しいコピーを自動的にインスタンス化する「スケールアウト」機能をすでに備えています。現実的な課題は、このようなスケーリングにはプランナーによる慎重な計画が必要であり、アプリケーション自体の変更が必要になる場合があることです。
水平スケーリングの利点と要件をさらに理解するために、アプリケーションが特定のユーザーやトランザクションにどのようにサービスを提供するかを説明する簡単なワークフロー図を作成することから始めることができます。多くの場合、アプリケーションはウェブサーバ、アプリケーションサーバ、データベースサーバを経由する必要があります。現在のパフォーマンスを分析した後、これらのリンクのどれが本当のパフォーマンスのボトルネックであるかを正確に知ることができます。特定のアプリケーションが処理リソースの 80% をウェブサーバーで使用しており、ユーザーが製品カタログを解析している場合、ウェブサーバーを複製する方がアプリケーションのパフォーマンスに顕著な影響を与えます。もし、ここで使用されている時間が 20%に過ぎず、ウェブサーバのコピーを増やしてもパフォーマンスが大幅に 改善される見込みがないのであれば、パフォーマンスのボトルネックは他の要因に起因しているはずです。
データベースへのアクセスは、新たなクラウドのボトルネックになることがよくあります。ビジネス・ユーザーは、ネットワーク・アクセス・アクセスやクラウド・ストレージにお金を払いたがらないことが多く、また、重要なアプリケーション・データをクラウドに移行することに伴うセキュリティやコンプライアンス上のリスクを取りたがらないからです。この場合、一部のクラウド・アプリケーションは、組織内からネットワーク経由でデータを外部に引き出さなければなりません。クラウド・バーストの場合、企業の重要なデータはアプリケーションが稼働しているデータセンター内に保管されているため、これはほとんどの場合必要になります。
効率的なデータ経路を作ることは非常に重要で、これはクラウドとデータセンター間のデータベース接続にAPM対策を追加することも意味します。問題は、圧縮は常に待ち時間を増加させるということです。データ・アクセス・ポリシーによっては、これは低容量問題と同じくらい深刻です。最善のアプローチは、ブロックレベルのI/Oコマンドではなく、サービスリクエストを受け取るデータサーバーの実際の使用量に基づいて計画を立てることです。そうすることで、データ量を減らし、インターフェイス間で個々のレコードを移動させることによる累積待ち時間を減らすことができます。また、リクエスト/結果の交換は待ち時間の影響を受けないため、アプリケーションとデータベースの接続に圧縮やその他のAPM機能を追加してパフォーマンスを向上させることができます。
