Key Management Service:ステップ 2: 移行の実行

1. 移行するリソースがあるかどうかを判断する

1. 以前の Key Management Service コンソールにログインします。左側のナビゲーションウィンドウで、[移行ツール] をクリックします。

2. [移行] ボタンが利用可能な場合、現在のリージョンに移行するキーまたは認証情報があることを示します。

   重要

   データはリージョンごとに表示されます。リソースを見落とさないように、すべてのリージョンのデータを確認してください。

   

3. [未移行のキー]、[移行済みのキー]、[未移行の認証情報]、および [移行済みの認証情報] の各列の数字をクリックして、特定のキー ID と認証情報名を表示します。

2. 移行手順

3. 移行後の操作

1. 新しいコンソールにログインして、移行されたリソースを表示および確認します。

   • サービスキー

     1. [キー管理] ページに移動し、上部のメニューバーからリージョンを選択します。

     2. [デフォルトキー] タブをクリックします。サービスキーがリストされていること、および [キーの用途] 列が [サービスキー] に設定されていることを確認します。

   • カスタマーマスターキー

     1. [キー管理] ページに移動し、上部のメニューバーからリージョンを選択します。

     2. [カスタマーマスターキー] タブをクリックし、移行されたカスタマーマスターキーが表示されていることを確認します。

   • 認証情報

     1. [認証情報管理] ページに移動し、上部のメニューバーからリージョンを選択します。

     2. KMS インスタンスを選択し、移行された認証情報がリストされていることを確認します。

2. Terraform を使用して KMS リソースを管理する場合は、Terraform の構成を変更する必要があります。詳細については、「Terraform シナリオでの移行後の構成の変更」をご参照ください。

4. 移行のモニタリング

スムーズで、監視可能で、追跡可能なキー移行を確実にするために、移行前、移行中、移行後に共有ゲートウェイと専用ゲートウェイを監視する必要があります。CloudMonitor、Simple Log Service (SLS)、および ActionTrail を使用して、包括的なモニタリングを行うことができます。以下のセクションでは、主要な監視ポイントと推奨されるアクションについて説明します。

1. 移行前: 共有ゲートウェイのダッシュボードを監視する

   キーの移行が完了し、クライアントのエンドポイントを切り替える前は、すべての KMS リクエストは引き続き共有ゲートウェイによって処理されます。この段階では、共有ゲートウェイの安定性とパフォーマンスに焦点を当てる必要があります。

   • 監視目標: 移行によって共有ゲートウェイに異常な負荷やエラーが発生しないことを確認します。

   • 監視するメトリック:

     • リクエストレイテンシ: 大幅な増加がないか確認します。

     • エラーコードの分布 (4xx や 5xx など): 異常なエラーが急増していないことを確認します。

     • QPS/TPS の傾向: 移行前後のトラフィックを比較して、一貫性を確保します。これにより、不正な操作によるリクエストの急増や中断を防ぐことができます。

   • 表示方法:

     • 方法 1: 新しいコンソールにログインします。概要ページで、[共有ゲートウェイ] ダッシュボードのリクエストレイテンシやエラーコードなどのメトリックを確認します。

     • 方法 2: CloudMonitor コンソールにログインします。[製品モニタリング] セクションで [Key Management Service (KMS)] を検索して、[共有ゲートウェイ] ダッシュボードを表示します。

   説明

   比較の参照として使用するために、移行前にベースラインメトリックを記録します。

2. 移行後: 共有ゲートウェイと専用ゲートウェイのダッシュボードを同時に監視する

   • エンドポイントの切り替え前: 共有ゲートウェイの監視を継続します。キーは専用インスタンスに移行されていますが、クライアントのエンドポイントを切り替えるまで、リクエストは引き続き共有ゲートウェイ経由でルーティングされます。共有ゲートウェイは、これらのリクエストをバックエンドの専用インスタンスに透過的に転送します。

   • エンドポイントの切り替え後: 共有ゲートウェイと専用ゲートウェイを同時に監視します。クライアントがエンドポイントの切り替えを完了すると、リクエストは専用ゲートウェイを介して専用インスタンスに直接アクセスします。この時点で、両方のゲートウェイを監視する必要があります:

     ゲートウェイタイプ	主要な監視ポイント	表示方法
     専用ゲートウェイ	エラーコード リクエストレイテンシの変化 QPS が期待どおりか	CloudMonitor: KMS 専用ゲートウェイダッシュボード
     共有ゲートウェイ	元のサービスからのリクエストが完全に切り替えられたか 残りのリクエストや異常な呼び出しがないか	対応するリージョンの共有ゲートウェイダッシュボードを監視する

     説明

     異常を特定するための基準:

     • 専用ゲートウェイが多数のスロットリングエラーを報告する場合、インスタンスタイプまたはスロットリングポリシーを調整する必要がある場合があります。

     • 共有ゲートウェイが依然として高頻度のリクエストを受信している場合、一部のクライアントがエンドポイントの切り替えを完了していないことを示します。問題を調査する必要があります。

3. ログレベルの監視: SLS を使用して詳細なアクセスログを分析する

   より詳細なリクエスト追跡と問題診断を実現するには、次のログ収集機能を有効にします:

   • 専用ゲートウェイのアクセスログ:

     • 専用ゲートウェイのログ分析付加価値サービス (VAS) を購入して、ログを Simple Log Service (SLS) に自動的に配信できます。

     • キー ID、Alibaba Cloud アカウント、API 操作、応答ステータスコードなどのフィールドでログをクエリおよび分析できます。

   • 共有ゲートウェイの詳細なアクセスログ:

     • ActionTrail を有効にし、イベントトレースを指定された SLS Logstore に配信します。

     • EventName = "Decrypt" や ResourceType = "KMS" などの条件でクエリを実行して、特定のリクエストの動作を分析します。

     • ErrorCode フィールドを使用して、権限の不足やキーが存在しないなどの障害の原因を特定します。

4. 推奨されるモニタリング戦略

   フェーズ	モニタリングの焦点	ツール
   移行前	共有ゲートウェイの安定性	CloudMonitor ダッシュボード
   スイッチオーバー中	リクエスト成功率、レイテンシの急激な変化	リアルタイムモニタリング + SLS アラート
   移行後	専用ゲートウェイのヘルスステータス	専用ゲートウェイダッシュボード + SLS ログ
   プロセス全体	異常なエラーコードの傾向	ActionTrail + SLS 集約分析