翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
データベースからアプリケーションレイヤーへのビジネスロジックの移行
データベースに保存されたプロシージャ、トリガー、関数からアプリケーションレイヤーサービスにビジネスロジックを移行することは、モノリシックデータベースを分解するための重要なステップです。この変換により、サービスの自律性が向上し、メンテナンスが簡素化され、スケーラビリティが向上します。このセクションでは、データベースロジックの分析、移行戦略の計画、ビジネス継続性を維持しながらの変革の実装に関するガイダンスを提供します。また、効果的なロールバック計画の策定についても説明します。
このセクションは、以下のトピックで構成されます。
フェーズ 1: ビジネスロジックの分析
モノリシックデータベースをモダナイズする場合は、まず既存のデータベースロジックの包括的な分析を行う必要があります。このフェーズでは、主に次の 3 つのカテゴリに焦点を当てます。
-
ストアドプロシージャには、多くの場合、データ操作ロジック、ビジネスルール、検証チェック、計算など、重要なビジネスオペレーションが含まれます。アプリケーションビジネスロジックのコアコンポーネントとして、慎重に分解する必要があります。たとえば、金融機関のストアドプロシージャは、関心の計算、アカウントの調整、コンプライアンスチェックを処理する場合があります。
-
トリガーは、監査証跡、データ検証、計算、およびクロステーブル整合性を処理する主要なデータベースコンポーネントです。たとえば、小売組織はトリガーを使用して注文処理システム全体のインベントリ更新を管理する場合があります。これは、自動データベースオペレーションの複雑さを示しています。
-
データベースの関数は、主にデータ変換、計算、ルックアップオペレーションを管理します。多くの場合、複数のプロシージャやアプリケーションに埋め込まれます。たとえば、医療組織は 関数を使用して患者データを正規化したり、医療コードを検索したりできます。
各カテゴリは、データベースレイヤー内に埋め込まれているビジネスロジックのさまざまな側面を表します。アプリケーションレイヤーに移行するには、各 を慎重に評価して計画する必要があります。
この分析フェーズでは、通常、お客様は 3 つの大きな課題に直面します。まず、複雑な依存関係は、ネストされたプロシージャ呼び出し、クロススキーマ参照、および暗黙的なデータ依存関係によって発生します。次に、トランザクション管理が重要になります。特に、複数ステップのトランザクションを処理し、分散システム全体でデータの一貫性を維持する場合です。第 3 に、パフォーマンスに関する考慮事項を慎重に評価する必要があります。特に、バッチ処理オペレーション、一括データ更新、およびデータに近づくことで現在メリットを得ているリアルタイム計算については注意が必要です。
これらの課題に効果的に対処するには、初期分析に AWS Schema Conversion Tool (AWS SCT) を使用し、詳細な依存関係マッピングツールを使用できます。このアプローチは、データベースロジックの全範囲を理解し、分解中のビジネス継続性を維持する包括的な移行戦略を作成するのに役立ちます。
これらのコンポーネントと課題を徹底的に理解することで、モダナイゼーションジャーニーをより的確に計画し、マイクロサービスベースのアーキテクチャへの移行中にどの要素を優先すべきかについて、十分な情報に基づいた意思決定を行うことができます。
データベースコードコンポーネントを分析するときは、ストアドプロシージャ、トリガー、および関数ごとに包括的なドキュメントを作成します。まず、実装するビジネスルールを含め、その目的とコア機能を明確に記述します。すべての入力パラメータと出力パラメータを詳しく説明し、それらのデータ型と有効な範囲を書き留めます。他のデータベースオブジェクト、外部システム、ダウンストリームプロセスへの依存関係をマッピングします。データの整合性を維持するために、トランザクションの境界と分離要件を明確に定義します。応答時間の要件やリソース使用率パターンなど、期待されるパフォーマンスを文書化します。最後に、使用状況パターンを分析して、ピーク時の負荷、実行頻度、重要なビジネス期間を把握します。
フェーズ 2: ビジネスロジックの分類
データベースを効果的に分解するには、複雑さ、ビジネスへの影響、依存関係、使用パターン、移行の難易度といった主要な側面にわたってデータベースロジックを体系的に分類する必要があります。この分類は、高リスクコンポーネントの特定、テスト要件の決定、移行の優先順位の確立に役立ちます。たとえば、ビジネスへの影響が大きく、頻繁に使用する複雑なストアドプロシージャには、慎重な計画と広範なテストが必要です。ただし、依存関係を最小限に抑えたシンプルでほとんど使用されない関数は、早期移行フェーズに適している場合があります。
この構造化されたアプローチは、システムの安定性を維持しながら、ビジネスの中断を最小限に抑えるバランスの取れた移行ロードマップを作成します。これらの相互関係を理解することで、分解作業のシーケンスを改善し、リソースを適切に割り当てることができます。
フェーズ 3: ビジネスロジックの移行
ビジネスロジックを分析して分類したら、それを移行します。モノリシックデータベースからビジネスロジックを移行するときは、データベースロジックをアプリケーションレイヤーに移動するか、ビジネスロジックをマイクロサービスの一部である別のデータベースに移動するという 2 つのアプローチがあります。
ビジネスロジックをアプリケーションに移行すると、データベーステーブルにはデータのみが保存され、データベースにはビジネスロジックは含まれません。これは推奨されるアプローチです。Ispirer
ビジネスロジックを別のデータベースに移行する場合は、 AWS Schema Conversion Tool (AWS SCT) を使用して既存のデータベーススキーマとコードオブジェクトをターゲットデータベースに変換できます。Amazon DynamoDB、Amazon Aurora、Amazon Redshift などの専用 AWS データベースサービスをサポートしています。包括的な評価レポートと自動変換機能を提供すること AWS SCT で、移行プロセスを合理化し、新しいデータベース構造の最適化に集中してパフォーマンスとスケーラビリティを向上させることができます。モダナイゼーションプロジェクトを進めるにつれて、 AWS SCT は段階的なアプローチをサポートするために増分変換を処理できるため、データベース変換の各ステップを検証して微調整できます。
ビジネスロジックのロールバック戦略
分解戦略の 2 つの重要な側面は、下位互換性を維持し、包括的なロールバック手順を実装することです。これらの要素は連携して、移行期間中のオペレーションを保護します。このセクションでは、分解プロセス中に互換性を管理し、潜在的な問題から保護する効果的な緊急ロールバック機能を確立する方法について説明します。
下位互換性を維持する
データベースの分解中、移行をスムーズにするには、下位互換性を維持することが不可欠です。新しい機能を徐々に実装しながら、既存のデータベース手順を一時的に実施してください。バージョン管理を使用して、すべての変更を追跡し、複数のデータベースバージョンを同時に管理します。ソースシステムとターゲットシステムの両方を確実に動作させる必要がある、長期間の共存期間を計画します。これにより、レガシーコンポーネントを廃止する前に、新しいシステムをテストおよび検証する時間を確保できます。このアプローチは、ビジネスの中断を最小限に抑え、必要に応じてロールバックのための安全ネットを提供します。
緊急ロールバック計画
包括的なロールバック戦略は、データベースを安全に分解するために不可欠です。コードに機能フラグを実装して、アクティブなビジネスロジックのバージョンを制御します。これにより、デプロイを変更することなく、新しい実装と元の実装を即座に切り替えることができます。このアプローチは、移行をきめ細かく制御し、問題が発生した場合に迅速にロールバックするのに役立ちます。元のロジックを検証済みのバックアップとして保持し、トリガー、責任、復旧ステップを指定する詳細なロールバック手順を維持します。
これらのロールバックシナリオは、さまざまな条件下で定期的にテストして有効性を検証し、チームが緊急手順に精通していることを確認します。機能フラグは、特定のユーザーグループまたはトランザクションの新機能を選択的に有効にすることで、段階的なロールアウトも有効にします。これにより、移行中のリスク軽減のための追加のレイヤーが提供されます。
