The Doppler Quarterly (日本語) 冬 2016 | Page 23

3) アプリケーションコンポーネント間の通信を考慮する
アプリケーションを、データとサービスの両方について分離しても、すべてのアプリケー
ションがクラウドで適切に構造化されるとは限りません。互いに絶えず通信するアプリ
ケーションコンポーネントが通常、ネットワークまたはインターネット全体に分散されて
いると仮定すると、そうしたコンポーネントにより、アプリケーション全体のパフォーマン
スが低下します。その状況で望ましいのは深刻なレイテンシに対する耐性です。
アプリケーションコンポーネント間の通信を最適化するアプリケーションの設計を重視
しましょう。たとえば、アプリケーションコンポーネントを単一のプラットフォームに常
駐させるかのように常に通信するのではなく、通信を単一のデータストリームまたはメッ
セージグループ内に統合します。
4) パフォーマンスと拡張を考慮したモデルと設計
アプリケーションコンポーネントの通信方法を、パフォーマンス全体も含めてさらに考
慮します。その際に、負荷が増加する環境下でのアプリケーションの拡張方法につい
ても理解します。
パフォーマンスを考えた設計とは、負荷が増大した時のアプリ
ケーションの動作を示すモデルを最初に構築することです。
1,000 またはそれ以上のユーザーが同時にログオンする場合、ネットワークトラフィック
の増加、アプリケーションサーバー上の負荷の増大、バックエンドデータベースへの負
荷の配置を、アプリケーションはどのように処理するでしょうか。ユーザーが 1,000 ま
たはそれ以上に増加すると、アプリケーションコンポーネントがどのようにその負荷を
処理するかを理解する必要があります。
この例では、アプリケーションサーバー上の負荷が 80%、ネットワーク負荷が 10%、
データベースへの負荷が 40%、
それぞれ上昇する可能性があります。1,000 以上のユー
ザー追加により、プロビジョニングしたアプリケーションサーバーへの負荷が限界に近
づくと仮定すれば、
アプリケーションサーバーインスタンスを増やす必要があります。
ネッ
トワークの機能はおそらく変化しません。しかし、増大する負荷をすべて処理するため
にデータベースインスタンスの数を増やす必要があるかもしれません。
このモデルを使用して対処すれば、リソースインスタンスの数を必要に応じて自動的に
増やすことで、アプリケーションの最適な拡張方法を把握できます。いくつかの事例で、
クラウドサービスプロバイダーが自動スケール機能を提供し、自動的にプロビジョニン
グできるようにしています。しかし、最も効果的な道筋は、アプリケーションワークロー
ドプロファイルを理解し、アプリケーション拡張までの道筋を定義し、アプリケーション
を確実に拡張できるメカニズムを適切に展開することです。
最後に、アプリケーション対応型のパフォーマンス監視ツールを使用して、アプリケー
ションパフォーマンス全体を監視します。また、アプリケーション内部にインターフェイス
を作成してパフォーマンス監視の有効性を高めます。アプリケーションがリソースのプロ
ビジョニングとデプロビジョニングをどのように実行するかを本質として捉えるべきです。
2016年冬号 | THE DOPPLER | 21