翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

SQL Server モダナイゼーションワークフロー

このセクションでは、 AWS Transform を使用した SQL Server のモダナイゼーションプロセス全体をstep-by-stepで説明します。

ステップ 1: SQL Server モダナイゼーションジョブを作成する

Transform AWS コンソールで新しい変換ジョブを作成して、モダナイゼーションジャーニーを開始します。

ステップ 2: SQL Server データベースに接続する

AWS 変換を SQL Server データベースに接続して、スキーマ分析と変換を有効にします。

データベースコネクタを作成する

ステップ 3: ソースコードリポジトリを接続する

AWS Transform は、SQL Server データベースとやり取りするコードを分析および変換するために、.NET アプリケーションのソースコードにアクセスする必要があります。 AWS Transform は、ソースコードを提供する 3 つの方法をサポートしています。

認証方法を選択する

PAT コネクタを設定する (推奨)

PAT コネクタを使用して、カスタムアクセス許可を持つ個人用アクセストークンをソースコードプロバイダーに作成し、安全に に保存し AWS Secrets Manager、必要に応じて AWS Transform が取得します。ローテーションや有効期限などのトークンライフサイクルを管理する責任があります。 AWS Transform は、シークレットにアクセスするためのアクセス許可を持つ必要な IAM ロールを自動的に作成します。

PAT コネクタは、セルフホスト型およびカスタム DNS/URL バージョンを含む次のプロバイダーをサポートしています。

個人用アクセストークンを作成する

ソースコードプロバイダーに PAT を作成します。必要なアクセス許可はプロバイダーによって異なります。プロバイダーのタブを選択します。

GitHub

設定、デベロッパー設定、個人用アクセストークン、きめ細かなトークンに移動します。変換するリポジトリを選択し、次のアクセス許可を付与します。

リポジトリのアクセス許可

組織のアクセス許可 (組織リポジトリに必要)

GitLab

プロファイルの編集、トークンへのアクセスに移動します。次のスコープを選択します。

Bitbucket

アカウント設定、セキュリティ、API トークンの作成と管理に移動します。必要なスコープはトークンタイプによって異なります。

Workspace/リポジトリトークン (ATCT — ベアラー認証、ユーザー名不要)

アカウント API トークン (ATAT — E メールによる基本的な認証) またはアプリパスワード (ATBB — ユーザー名による基本的な認証)

Azure DevOps

ユーザー設定、個人用アクセストークンに移動します。カスタム定義スコープを選択します。組織のスコープでは、アクセス可能なすべての組織 (推奨) を選択するか、単一の組織を指定します。

PAT を に保存する AWS Secrets Manager

カスタマー管理の KMS キーを使用してシークレットを暗号化する場合は (デフォルト AWS管理のキーではなく）、 AWS トランスフォームがシークレットを復号できるように KMS キーポリシーを更新する必要があります。カスタマー管理の KMS キーポリシーに次のステートメントを追加します。

{
  "Sid": "Allow AWS Transform to decrypt secrets",
  "Effect": "Allow",
  "Principal": {
    "Service": "transform.amazonaws.com"
  },
  "Action": [
    "kms:Decrypt",
    "kms:DescribeKey"
  ],
  "Resource": "*",
  "Condition": {
    "StringEquals": {
      "kms:ViaService": "secretsmanager.REGION.amazonaws.com",
      "kms:EncryptionContext:SecretARN": "YOUR-SECRET-ARN"
    }
  }
}

REGION を自分の AWS リージョン ( などus-east-1) に置き換え、YOUR-SECRET-ARN をシークレットの ARN に置き換えます。このkms:ViaService条件により、KMS キーは AWS Secrets Manager サービスを介してのみ使用できます。このkms:EncryptionContext:SecretARN条件は、復号を特定のシークレットに制限します。

KMS キーポリシーを更新するには:

AWS 変換ジョブを設定する

AWS Transform は、シークレットへのアクセスに必要なアクセス許可を持つ IAM ロールを自動的に作成します。

トークンのローテーションとメンテナンス

有効期限が切れる前に PAT トークンをローテーションする責任があります。トークンをローテーションするには:

PAT コネクタの問題のトラブルシューティング

セットアップ AWS CodeConnections

AWS CodeConnections は、OAuth 2.0 認可フローを通じて一時的な OAuth 認証情報を自動的に取得するマネージドプロバイダー統合を使用します。アクセス許可はプロバイダーアプリで設定され、 によって完全に管理されます AWS。アプリを一度承認すると、 はすべての認証情報管理 AWS を処理します。

リポジトリとブランチを選択する

リポジトリアクセスの承認

GitHub およびその他のプラットフォームの場合、リポジトリ管理者は接続リクエストを承認する必要があります。

ステップ 4: デプロイコネクタを作成する (オプション)

変換されたアプリケーションを AWS アカウントにデプロイする場合は、デプロイコネクタを選択するオプションがあります。

デプロイコネクタをセットアップする

デプロイコネクタの承認

AWS アカウント管理者は、デプロイコネクタの接続リクエストを承認する必要があります。

ステップ 5: リソースを確認する

データベースとリポジトリに接続すると、 AWS Transform は必要なすべてのリソースにアクセスでき、変換の準備が整っていることを確認します。

AWS 変換の検証内容

プリフライトチェックリストを確認する

ステップ 6: 検出と評価

AWS Transform は SQL Server データベースと .NET アプリケーションを分析して、モダナイゼーションの範囲と複雑さを理解します。

検出された内容

検出プロセス

検出結果を確認する

検出が完了したら、検出と評価に移動して確認します。

データベース分析:

アプリケーション分析:

依存関係マップ:

複雑さ評価について

AWS 変換はモダナイゼーションを 3 つのカテゴリに分類します。

評価レポート

AWS Transform は、以下を含む詳細な評価レポートを生成します。

評価レポートはオフラインレビュー用にダウンロードし、ステークホルダーと共有できます。

ステップ 7: ウェーブプランを生成して確認する

複数のデータベースとアプリケーションを持つ大規模な資産の場合、 AWS Transform は論理グループでモダナイゼーションをシーケンスするウェーブプランを生成します。

ウェーブプランとは

ウェーブプランは、以下に基づいてモダナイゼーションをフェーズ (ウェーブ) に整理します。

各ウェーブには、依存関係を損なうことなく一緒にモダナイズできるデータベースとアプリケーションのグループが含まれています。

ウェーブプランを確認する

ウェーブプランをカスタマイズする

次の 2 つの方法で、ビジネスニーズに合わせてウェーブプランをカスタマイズできます。

JSON の使用:

チャットの使用:

エージェントとチャットし、リポジトリとデータベースを特定のウェーブに移動するように依頼することで、ウェーブプランを変更できます。このアプローチは、ウェーブに小さな編集を加える必要がある場合に適しています。

単一データベースのモダナイゼーション

単一のデータベースとアプリケーションをモダナイズする場合、 AWS Transform は 1 つのウェーブでシンプルな計画を作成します。ウェーブプランニングなしで直接変換に進むことができます。

ウェーブプランを承認する

ステップ 8: スキーマ変換

AWS Transform は、テーブル、ビュー、ストアドプロシージャ、関数、トリガーなど、SQL Server データベーススキーマを Aurora PostgreSQL に変換します。

スキーマ変換の仕組み

AWS Transform AWS は、生成 AI で拡張された DMS Schema Conversion を使用して以下を行います。

サポートされている変換

自動変換:

人間によるレビューが必要になる場合があります。

自動的に変換されません。

スキーマ変換を開始する

変換結果を確認する

変換が完了したら、スキーマ変換の確認に移動します。

変換の概要:

オブジェクトタイプによるレビュー:

アクション項目を確認する

例: ストアドプロシージャ変換

SQL Server T-SQL:

CREATE PROCEDURE GetProductsByCategory
    @CategoryId INT,
    @PageSize INT = 10
AS
BEGIN
    SET NOCOUNT ON;
    
    SELECT TOP (@PageSize)
        ProductId,
        Name,
        Price,
        DATEDIFF(DAY, CreatedDate, GETUTCDATE()) AS DaysOld
    FROM Products
    WHERE CategoryId = @CategoryId
    ORDER BY Name
END

変換された PostgreSQL PL/pgSQL:

CREATE OR REPLACE FUNCTION get_products_by_category(
    p_category_id INTEGER,
    p_page_size INTEGER DEFAULT 10
)
RETURNS TABLE (
    product_id INTEGER,
    name VARCHAR(255),
    price NUMERIC(18,2),
    days_old INTEGER
) AS $$
BEGIN
    RETURN QUERY
    SELECT 
        p.product_id,
        p.name,
        p.price,
        EXTRACT(DAY FROM (NOW() - p.created_date))::INTEGER AS days_old
    FROM products p
    WHERE p.category_id = p_category_id
    ORDER BY p.name
    LIMIT p_page_size;
END;
$$ LANGUAGE plpgsql;

変更点:

スキーマ変換を承認する

ステップ 9: データ移行 (オプション)

AWS Transform には、SQL Server から Aurora PostgreSQL にデータを移行するためのオプションが用意されています。データ移行はオプションであり、スキーマとコード変換のみが必要な場合はスキップできます。

データ移行オプション

オプション 1: 本番稼働用データ移行

DMS AWS を使用して実際の本番稼働データを移行します。

オプション 2: データ移行をスキップする

スキーマとコードのみを変換します。

データ移行を設定する

本番稼働用データ移行プロセス

本番データを移行することを選択した場合:

移行タイムライン:

データ検証

AWS 変換は、移行されたデータを次のチェックで検証します。

ステップ 10: アプリケーションコード変換

AWS Transform は、.NET アプリケーションコードを SQL Server ではなく Aurora PostgreSQL と連携するように変換します。リポジトリ内のターゲットブランチ名に、変換されたソースコードをコミットするように要求します。ブランチ名を入力すると、 AWS Transform は新しいブランチを作成し、PostgreSQL データベースと一致するように変換を開始します。

変換される内容

エンティティフレームワークの変更:

ADO.NET 変更:

設定の変更:

コード変換を開始する

ステップ 11: 変換結果を確認する

デプロイに進む前に、完全な変換結果を確認して、すべてテストの準備が整っていることを確認します。

変換されたコードは、リポジトリブランチからダウンロードできます。

変換の概要をダウンロードして、変換の一部として AWS 変換によって行われた自然言語の変更を確認することもできます。

変換の概要

変換レポートの生成

AWS Transform は包括的な変換レポートを生成します。

レポートには以下が含まれます。

ステップ 12: 検証とテスト

本番環境にデプロイする前に、変換されたアプリケーションが Aurora PostgreSQL で正しく動作することを確認します。

検証タイプ

自動検証: AWS Transform は自動チェックを実行します。

人間による検証: 追加のテストを実行する必要があります。

自動検証を実行する

テストチェックリスト

データベース機能:

アプリケーション機能:

データ整合性:

パフォーマンス:

ステップ 13: デプロイ

検証が成功したら、モダナイズされたアプリケーションとデータベースを本番環境にデプロイします。

デプロイオプション

デプロイ前チェックリスト

本番環境にデプロイする前に:

Amazon ECS へのデプロイ

デプロイのモニタリング

AWS Transform はアプリケーションをデプロイします。

デプロイの進行状況をモニタリングし、以下を確認します。

デプロイ後の検証

デプロイ後:

煙テスト:

パフォーマンスモニタリング:

ユーザー検証:

ロールバック手順

デプロイ後に問題が発生した場合:

即時ロールバック:

部分ロールバック:

フォワード修正:

デプロイ後の最適化

デプロイが成功した後:

パフォーマンスチューニング:

コスト最適化:

モニタリングのセットアップ:

ドキュメント: