Google Cloud Well-Architected Framework のパフォーマンス最適化の柱におけるこの原則では、モジュラー設計を促進するうえで役に立つ推奨事項が示されています。モジュラー コンポーネントと明確なインターフェースにより、柔軟なスケーリング、独立した更新、将来のコンポーネント分離が可能になります。
原則の概要
アプリケーション コンポーネントとシステム コンポーネントの依存関係を理解して、スケーラブルなシステムを設計します。
モジュラー設計を採用すると、最初にモノリシック アーキテクチャとマイクロサービス アーキテクチャのどちらがデプロイされたかにかかわらず、柔軟性と復元力が実現されます。明確なインターフェースを備え、明確に定義された独立したモジュールにシステムを分解することで、特定の需要に合わせて個々のコンポーネントをスケーリングできます。
対象を絞ったスケーリングを使用すると、以下のような方法でリソース使用率を最適化し、費用を削減できます。
- 各コンポーネントに必要なリソースのみをプロビジョニングし、需要の少ないコンポーネントには少ないリソースを割り当てます。
- トラフィックの増加時にはリソースを追加して、ユーザー エクスペリエンスを維持します。
- パフォーマンスを損なうことなく、使用率の低いリソースを削除します。
モジュール化により、メンテナンス性も向上します。小規模で自己完結型のユニットは、理解、デバッグ、更新が容易であるため、開発サイクルの短縮とリスクの低減につながります。
モジュール化には大きなメリットがありますが、潜在的なパフォーマンスのトレードオフを評価する必要があります。モジュール間の通信が増えると、レイテンシとオーバーヘッドが発生する可能性があります。モジュール化とパフォーマンスのバランスをとるよう努力します。高度なモジュラー設計が、例外なく適しているわけではありません。パフォーマンスが重要である場合は、より緊密に結合されたアプローチが適している場合があります。システム設計は反復的なプロセスであり、モジュラー設計を継続的に見直して改良します。
推奨事項
モジュラー設計を推進するには、以下のセクションの推奨事項を検討してください。
疎結合となるように設計する
疎結合アーキテクチャを設計します。依存関係を最小限に抑えた独立したコンポーネントを使用すると、スケーラブルで復元力のあるアプリケーションを構築するうえで役立ちます。サービスの境界を計画する際は、可用性とスケーラビリティの要件を考慮する必要があります。たとえば、1 つのコンポーネントの要件が他のコンポーネントと異なる場合は、そのコンポーネントをスタンドアロン サービスとして設計できます。プライマリ サービスの応答時間に影響しない、重要度の低いサブプロセスやサービスの正常な障害の計画を実装します。
同時実行と並列処理を考慮した設計
複数のタスクを同時にサポートするようにアプリケーションを設計します。たとえば、複数のユーザー リクエストの処理や、ユーザーがシステムを操作している間のバックグラウンド ジョブの実行などです。大きなタスクを、複数のサービス インスタンスで同時に処理できる小さなチャンクに分割します。タスクの同時実行を使用すると、自動スケーリングなどの機能を使用して、以下のようなプロダクトのリソース割り当てを増やすことができます。
モジュール化をバランスよく配置して柔軟なリソース割り当てを実現する
可能であれば、各コンポーネントが特定のオペレーションに必要なリソース（メモリ、ストレージ、処理能力など）のみを使用するようにします。リソース割り当てが過剰になると不必要な費用が発生する可能性がある一方で、リソース割り当てが不足するとパフォーマンスが低下する可能性があります。
明確に定義されたインターフェースを使用する
モジュール式のコンポーネントは明確で標準化されたインターフェース（API やメッセージ キューなど）を介して効率的に通信し、変換レイヤや余計なトラフィックによるオーバーヘッドを削減します。
ステートレス モデルを使用する
ステートレス モデルを使用すると、各リクエストやサービスとのやり取りをこれまでのリクエストとは独立して処理できるようになります。このモデルでは、進行中のリクエストやプロセスに必要なデータを失うことなく、サービスを拡大、縮小、再起動できるため、スケーラビリティと復元性が向上します。
補完的なテクノロジーを選択する
モジュラー設計を補完するテクノロジーを選択します。モジュール化のサポートについて、プログラミング言語、フレームワーク、データベースを評価します。
詳しくは、次のリソースをご覧ください。