The Doppler Quarterly (日本語) 冬 2016

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

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