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