翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # データベース分解のための結合と結合の分析 このセクションでは、モノリシックデータベースの結合パターンと結合パターンを分析して分解をガイドするのに役立ちます。データベースコンポーネントがどのように相互作用し、相互に依存するかを理解することは、自然なブレークポイントを特定し、複雑さを評価し、段階的な移行アプローチを計画するために不可欠です。この分析では、隠れた依存関係を明らかにし、即時の分離に適した領域を強調し、変換リスクを最小限に抑えながら分解作業を優先するのに役立ちます。結合と結合の両方を調べることで、変換プロセス全体でシステムの安定性を維持するために、コンポーネントの分離シーケンスについて情報に基づいた決定を行うことができます。 **Topics** + [結合と結合について](#cohesion-coupling-about) + [モノリシックデータベースの一般的な結合パターン](#coupling-patterns) + [モノリシックデータベースの一般的な結合パターン](#cohesion-patterns) + [低結合と高結合の実装](#cohesion-coupling-implementation) ## 結合と結合について *カップリング*は、データベースコンポーネント間の相互依存度を測定します。適切に設計されたシステムでは、1 つのコンポーネントへの変更が他のコンポーネントに与える影響を最小限に抑えながら、疎結合を実現したいと考えています。*結合*は、データベースコンポーネント内の要素が連携して、明確に定義された単一の目的を達成する能力を測定します。高い結合は、コンポーネントの要素が強く関連し、特定の関数に焦点を当てていることを示します。モノリシックデータベースを分解する場合は、個々のコンポーネント間の結合と結合の両方を分析する必要があります。この分析は、システムの整合性とパフォーマンスを維持しながらデータベースを分割する方法に関して、情報に基づいた意思決定を行うのに役立ちます。 次の図は、結合性が高い疎結合を示しています。データベース内のコンポーネントは連携して特定の関数を実行し、1 つのコンポーネントに対する変更の影響を最小限に抑えます。これは理想的な状態です。 ![コンポーネントには緩い結合と高い結合があります。](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-decomposition/images/loose-coupling-high-cohesion.png) 次の画像は、結合率が低く結合率が高いことを示しています。データベースコンポーネントは切断され、変更は他のコンポーネントに影響を与える可能性が高くなります。 ![コンポーネントは結合性が高く、結合性が低くなります。](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-decomposition/images/high-coupling-low-cohesion.png) ## モノリシックデータベースの一般的な結合パターン モノリシックデータベースをマイクロサービス固有のデータベースに分解するときによく見られる結合パターンがいくつかあります。これらのパターンを理解することは、データベースのモダナイゼーションイニシアチブを成功させるために不可欠です。このセクションでは、各パターン、その課題、および結合を減らすためのベストプラクティスについて説明します。 ### 実装結合パターン **定義**: コンポーネントはコードレベルとスキーマレベルで緊密に相互接続されています。たとえば、`customer`テーブルの構造を変更すると`order`、、`inventory`、および `billing`のサービスに影響します。 **モダナイゼーションの影響**: 各マイクロサービスには、独自の専用データベーススキーマとデータアクセスレイヤーが必要です。 **課題**: + 共有テーブルの変更は複数のサービスに影響します + 意図しない副作用のリスクが高い + テストの複雑さの増大 + 個々のコンポーネントの変更が困難 **結合を減らすためのベストプラクティス**: + コンポーネント間の明確なインターフェイスを定義する + 抽象化レイヤーを使用して実装の詳細を非表示にする + ドメイン固有のスキーマを実装する ### 一時的な結合パターン **定義**: オペレーションは特定の順序で実行する必要があります。たとえば、インベントリの更新が完了するまで、注文処理を続行することはできません。 **モダナイゼーションの影響**: 各マイクロサービスには自律的なデータ管理が必要です。 **課題**: + サービス間の同期依存関係の解除 + パフォーマンスのボトルネック + 最適化が困難 + 制限された並列処理 **結合を減らすためのベストプラクティス**: + 可能な場合は非同期処理を実装する + イベント駆動型アーキテクチャを使用する + 必要に応じて結果整合性を設計する ### デプロイ結合パターン **定義**: システムコンポーネントは 1 つのユニットとしてデプロイする必要があります。たとえば、支払い処理ロジックを少し変更するには、データベース全体を再デプロイする必要があります。 **モダナイゼーションの影響**: サービスあたりの独立したデータベースデプロイ **課題**: + 高リスクデプロイ + デプロイ頻度の制限 + 複雑なロールバック手順 **結合を減らすためのベストプラクティス**: + 個別にデプロイ可能なコンポーネントに分割する + データベースシャーディング戦略を実装する + Blue-Green デプロイパターンを使用する ### ドメイン結合パターン **定義**: ビジネスドメインはデータベース構造とロジックを共有します。たとえば、`customer`、、`order`および `inventory`ドメインはテーブルとストアドプロシージャを共有します。 **モダナイゼーションの影響**: ドメイン固有のデータ分離 **課題**: + 複雑なドメイン境界 + 個々のドメインのスケーリングが困難 + 複雑なビジネスルール **結合を減らすためのベストプラクティス**: + 明確なドメイン境界を特定する + ドメインコンテキストでデータを区切る + ドメイン固有のサービスの実装 ## モノリシックデータベースの一般的な結合パターン データベースコンポーネントの分解を評価する際によく見られる結合パターンがいくつかあります。これらのパターンを理解することは、適切に構造化されたデータベースコンポーネントを特定する上で不可欠です。このセクションでは、各パターン、その特性、および結合を強化するためのベストプラクティスについて説明します。 ### 機能結合パターン **定義**: すべての要素が 1 つの明確に定義された関数を直接サポートし、実行に貢献します。たとえば、支払い処理モジュール内のすべてのストアドプロシージャとテーブルは、支払い関連のオペレーションのみを処理します。 **モダナイゼーションの影響**: マイクロサービスデータベース設計に最適なパターン **課題**: + 明確な機能境界の特定 + 多目的コンポーネントの分離 + 単一責任の維持 **結合を強化するためのベストプラクティス:** + 関連する関数をグループ化する + 関連しない機能を削除する + コンポーネントの境界を明確に定義する ### 連続結合パターン **定義**: ある要素からの出力は、別の要素の入力になります。たとえば、注文フィードの注文処理の検証結果などです。 **モダナイゼーションの影響**: 慎重なワークフロー分析とデータフローマッピングが必要 **課題**: + ステップ間の依存関係の管理 + 失敗シナリオの処理 + プロセス順序の維持 **結合を強化するためのベストプラクティス:** + 明確なデータフローを文書化する + 適切なエラー処理を実装する + ステップ間の明確なインターフェイスを設計する ### コミュニケーションの結合パターン **定義**: 要素は同じデータで動作します。たとえば、顧客プロファイル管理関数はすべて顧客データを使用します。 **モダナイゼーションの影響**: サービス分離のデータ境界を特定し、モジュール間の結合を減らすのに役立ちます **課題**: + データ所有権の決定 + 共有データアクセスの管理 + データ整合性の維持 **結合を強化するためのベストプラクティス**: + 明確なデータの所有権を定義する + 適切なデータアクセスパターンを実装する + 効果的なデータパーティショニングを設計する ### 手続き型結合パターン **定義**: 要素は特定の順序で実行する必要があるため、グループ化されますが、機能的に関連しない場合があります。たとえば、順序処理では、順序の検証とユーザー通知の両方を処理するストアドプロシージャは、異なる目的を果たし、別々のサービスで処理できる場合でも、順番に行われるという理由だけでグループ化されます。 **モダナイゼーションの影響**: プロセスフローを維持しながら手順を慎重に分離する必要があります **課題**: + 分解後の正しいプロセスフローの維持 + 手続き型依存関係と比較した真の機能境界の特定 **結合を強化するためのベストプラクティス**: + 実行順序ではなく、機能的な目的に基づいて手順を分離する + オーケストレーションパターンを使用してプロセスフローを管理する + 複雑なシーケンスのワークフロー管理システムを実装する + プロセスステップを個別に処理するようにイベント駆動型アーキテクチャを設計する ### 一時的な結合パターン **定義**: 要素はタイミング要件に関連しています。たとえば、注文が行われると、複数のオペレーションを一緒に実行する必要があります。一貫した注文状態を維持するためには、在庫チェック、支払い処理、注文確認、配送通知がすべて特定の時間枠内に行われる必要があります。 **モダナイゼーションへの影響**: 分散システムでは特別な処理が必要になる場合があります **課題**: + 分散サービス間のタイミング依存関係の調整 + 分散トランザクションの管理 + 複数のコンポーネントにわたるプロセスの完了の確認 **結合を強化するためのベストプラクティス**: + 適切なスケジューリングメカニズムとタイムアウトを実装する + 明確なシーケンス処理でイベント駆動型アーキテクチャを使用する + 補償パターンとの最終的な一貫性を実現する設計 + 分散トランザクションの saga パターンを実装する ### 論理的または偶発的な結合パターン **定義**: 要素は、関係が弱い、または意味のある関係がない場合でも、同じことを行うように論理的に分類されます。たとえば、顧客注文データ、倉庫在庫数、マーケティング E メールテンプレートは、アクセスパターン、ライフサイクル管理、スケーリング要件が異なるにもかかわらず、すべて販売オペレーションに関連しているため、同じデータベーススキーマに格納します。もう 1 つの例は、注文支払い処理と製品カタログ管理を同じデータベースコンポーネント内で組み合わせることです。どちらも e コマースシステムの一部であり、運用ニーズが異なる個別のビジネス機能を提供します。 **モダナイゼーションの影響**: リファクタリングまたは再編成する必要があります **課題**: + より良い組織パターンの特定 + 不要な依存関係の解消 + 任意にグループ化されたコンポーネントの再構築 **結合を強化するためのベストプラクティス**: + 真の機能境界とビジネスドメインに基づいて再編成する + 表面的な関係に基づいて任意のグループ化を削除する + ビジネス能力に基づいて要素を適切に分離する + データベースコンポーネントを特定の運用要件に合わせる ## 低結合と高結合の実装 ### ベストプラクティス 以下のベストプラクティスは、低い結合を実現するのに役立ちます。 + データベースコンポーネント間の依存関係を最小限に抑える + コンポーネントインタラクションに明確に定義されたインターフェイスを使用する + 共有状態とグローバルデータ構造を避ける 以下のベストプラクティスは、高い一貫性を実現するのに役立ちます。 + 関連するデータとオペレーションをグループ化する + 各コンポーネントに 1 つの明確な責任があることを確認します。 + 異なるビジネスドメイン間の明確な境界を維持する ### フェーズ 1: データの依存関係をマッピングする データ関係をマッピングし、自然境界を特定します。などのツールを使用して[SchemaSpy](https://schemaspy.org/)、エンティティ関係 (ER) 図でテーブルを表示することで、データベースを視覚化できます。これにより、データベースの静的分析が提供され、データベース内の明確な境界と依存関係の一部が示されます。 データベーススキーマは、グラフデータベースまたはJupiterノートブックでエクスポートすることもできます。次に、クラスタリングまたは相互接続されたコンポーネントアルゴリズムを適用して、自然境界と依存関係を特定できます。などの他の AWS Partner ツールは[CAST Imaging](https://www.castsoftware.com/imaging)、データベースの依存関係を理解するのに役立ちます。 ### フェーズ 2: トランザクションの境界とアクセスパターンを分析する トランザクションパターンを分析して、アトミック性、一貫性、分離性、耐久性 (ACID) プロパティを維持し、データへのアクセス方法と変更方法を理解します。[Oracle Automatic Workload Repository (AWR)](https://docs.oracle.com/en-us/iaas/performance-hub/doc/awr-report-ui.html) や などのデータベース分析と診断ツールを使用できます[PostgreSQL pg\_stat\_statements](https://www.postgresql.org/docs/current/pgstatstatements.html)。この分析は、データベースにアクセスするユーザーとトランザクションの境界を理解するのに役立ちます。また、実行時にテーブル間の結合と結合を理解するのにも役立ちます。また、 などのコードとデータベース実行プロファイルをリンクできるモニタリングおよびプロファイリングツールを使用することもできます[Dynatrace AppEngine](https://www.dynatrace.com/platform/appengine/)。 などの AI ツールは、アプリケーションの機能およびドメインの境界を分析することで、ドメインの境界を特定する[vFunction](https://vfunction.com/)のに役立ちます。はvFunction主にアプリケーションレイヤーを分析しますが、そのインサイトはアプリケーションとデータベースの両方の分解を導き、ビジネスドメインとの整合性をサポートします。 ### フェーズ 3: 自己完結型テーブルを特定する 2 つの主要な特性を示すテーブルを探します。 + 高い結合 — テーブルの内容は相互に強く関連しています + 結合が少ない – 他のテーブルへの依存関係は最小限です。 次の結合結合マトリックスは、各テーブルのデカップリングの難しさを特定するのに役立ちます。このマトリックスの右上の四分円に表示されるテーブルは、分離が最も簡単なため、最初のデカップリング作業の候補として最適です。ER 図では、これらのテーブルには外部キー関係やその他の依存関係はほとんどありません。これらのテーブルを分離したら、より複雑な関係を持つテーブルに進みます。 ![右上の四分円は簡単で、左下の四分円はハードです。](https://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/database-decomposition/images/coupling-cohesion-matrix.png) **注記** データベース構造は、多くの場合、アプリケーションアーキテクチャをミラーリングします。データベースレベルで分離しやすいテーブルは、通常、アプリケーションレベルでマイクロサービスに変換しやすいコンポーネントに対応しています。