ステージング クラスタを使用して AlloyDB メンテナンス更新を管理する

AlloyDB for PostgreSQL の本番環境ワークロードのリスクを最小限に抑えるには、ステージング クラスタを使用して、本番環境システムに更新を適用する前に、新機能、パフォーマンス、機能をテストします。ステージング クラスタは、メンテナンス アップデート プロセスに制御レイヤを追加する本番環境クラスタのコピーです。ステージング クラスタを使用してメンテナンス アップデートをテストすると、非本番環境で潜在的な問題を特定して解決できます。このアプローチにより、本番環境システムのダウンタイムとパフォーマンスの低下のリスクを軽減できます。

AlloyDB のメンテナンス アップデートは定期的に（通常は毎月）行われます。アップデートには、新機能、バグの修正、データベースの互換性のアップグレード、セキュリティ関連の修正が含まれます。AlloyDB のリリースは前方互換性がありますが、本番環境クラスタの重要なアプリケーションのデータベースの安定性と予測可能性を確保するために、ステージング環境で新しいリリースをテストすることをおすすめします。

ステージング クラスタを使用する手順の概要は次のとおりです。

1. ステージング クラスタを設定します。
2. 本番環境クラスタのメンテナンスの時間枠を構成します。
3. ステージング クラスタの更新を管理する。
4. 本番環境クラスタの更新を管理します。

AlloyDB メンテナンスに対するこのステージング検証アプローチにより、本番環境の安定性、パフォーマンス、セキュリティが維持され、最新の AlloyDB 機能とパッチのメリットを享受できます。

次の図は、ステージング クラスタと本番環境クラスタの関係と、更新プロセスの運用フローを示しています。

メンテナンス更新が AlloyDB クラスタでどのように機能するかについては、メンテナンスの概要をご覧ください。メンテナンスの時間枠の管理の詳細については、AlloyDB for PostgreSQL クラスタのメンテナンスの時間枠を管理するをご覧ください。

始める前に

使用する Google Cloud プロジェクトで AlloyDB へのアクセスが有効になっている必要があります。

ステージング クラスタを設定するには、AlloyDB 本番環境クラスタを作成するか、既存の AlloyDB 本番環境クラスタが必要です。詳細については、クラスタとそのプライマリ インスタンスを作成するをご覧ください。

使用している Google Cloudプロジェクトに、次のいずれかの IAM ロールが必要です。

• roles/alloydb.admin: AlloyDB 管理者の IAM 事前定義ロール
• roles/owner: オーナーの IAM 基本ロール
• roles/editor: 編集者の IAM 基本ロール

これらのロールのいずれも付与されていない場合は、組織管理者に連絡してアクセス権をリクエストしてください。

ステージング クラスタを設定する

ステージング優先戦略を成功させるには、ステージング クラスタが本番環境と類似しており、本番環境の前に更新を受け取るようにする必要があります。ステージング クラスタにメンテナンスの時間枠を設定しない場合は、ステージング優先戦略を構成します。AlloyDB は、まずメンテナンスの時間枠のないクラスタを更新します。

本番環境のバックアップからステージング クラスタを作成する

本番環境をミラーリングするステージング クラスタをデプロイし、ステージング クラスタが本番環境クラスタと同じ AlloyDB バージョン、構成、データであることを確認します。

ステージング クラスタが本番環境と同一であることを確認するには、restore コマンドを使用して本番環境のデータベースをステージング クラスタに複製し、データの類似性と構成の一致を確認します。また、ステージング環境と本番環境を異なるプロジェクトに分離することをおすすめします。

本番環境のバックアップを作成するには、次の 2 つの方法があります。

• 既存の本番環境クラスタのバックアップを完全に復元して、新しいステージング クラスタを作成します。この方法では、データベースの復元は行いません。ただし、バックアップ スケジュールによっては、データが最大 24 時間前のものになることがあります。この方法を使用するには、保存されたバックアップからクラスタを復元するをご覧ください。
• 既存の本番環境データベース バックアップの特定の時点（最新の時点を含む）にポイントインタイム リカバリ（PITR）を実行して、新しいステージング クラスタを作成します。このオプションでは、最新のデータを取得でき、方法も簡単です。ただし、最後の PITR バックアップ時間によっては、指定した時間までデータの復元または復旧に時間がかかることがあります。この方法を使用するには、ポイントインタイム リカバリ（PITR）を使用するをご覧ください。

ステージング クラスタにメンテナンスの時間枠が設定されていないことを確認する

ステージング クラスタのメンテナンスの時間枠を設定しないでください。デフォルトでは、新しく作成された AlloyDB クラスタ（バックアップから復元されたクラスタも含む）にはメンテナンスの時間枠が設定されていません。これは、ステージング環境の正しい状態です。AlloyDB は、定期メンテナンスの時間枠がないクラスタを更新してから、定期メンテナンスの時間枠があるクラスタを更新します。

メンテナンスの時間枠が設定されていないことを確認するには、次の操作を行います。

コンソール

1. [クラスタ] ページに移動します。

   クラスタに移動

2. [リソース名] 列でクラスタをクリックします。[概要] ページが開きます。

3. [概要] ページの [メンテナンス] セクションで、クラスタのメンテナンスの時間枠の詳細を確認します。

   注: Google Cloud コンソールに AlloyDB の [メンテナンス] セクションの詳細が表示されるまでに時間がかかることがあります。

4. 省略可: [システム分析情報] ページで、[イベント タイムライン] などのメンテナンス オペレーションのステータスの詳細を確認できます。

5. 統合メンテナンスの管理を表示するには、検索バーに「Cloud Hub maintenance」と入力し、[メンテナンス] を選択します。このページでは、メンテナンスの概要、Google が管理するメンテナンス、計画されたメンテナンスの詳細を確認できます。

gcloud

1. gcloud CLI を使用するには、Google Cloud CLI をインストールして初期化するか、Cloud Shell を使用します。

   gcloud alloydb clusters describe STAGING_CLUSTER_ID \
       --region=LOCATION_ID \
       --project=PROJECT_ID

2. 出力で maintenanceSchedule フィールドを探します。メンテナンス ウィンドウが設定されていない場合、このフィールドは存在しないか空です。何らかの理由でメンテナンスの時間枠が設定されている場合は、クリアします。

   gcloud alloydb clusters update STAGING_CLUSTER_ID \
       --region=LOCATION_ID \
       --clear-maintenance-window \
       --project=PROJECT_ID

本番環境クラスタのメンテナンスの時間枠を構成する

本番環境クラスタでは、メンテナンスの時間枠をスケジュールすることが重要です。これにより、更新のタイミングを制御し、ビジネスのトラフィックの少ない期間に合わせて更新できます。

本番環境クラスタのメンテナンスの時間枠を設定する

本番環境クラスタのメンテナンスの時間枠をスケジュールします。本番環境システムの負荷が最も低い日時を選択します。1 回のメンテナンス イベントに必要な合計時間は異なる場合があります。

AlloyDB は、ステージング クラスタの更新後、少なくとも 1 週間は本番環境クラスタの更新を自動的に遅延させます。ステージング クラスタの更新後に問題が見つかった場合は、本番環境のメンテナンス更新を最大 30 日間拒否し、Google Cloud サポートと協力して問題を解決できます。

本番環境クラスタのメンテナンスの時間枠を次のように設定します。

コンソール

1. [クラスタ] ページに移動します。

   [クラスタ] に移動

2. [リソース名] 列でクラスタをクリックします。

3. [概要] ページの [メンテナンス] セクションで、[編集] をクリックします。構成ウィンドウが開きます。

4. [優先メンテナンスの時間枠] セクションで、このメンテナンスの時間枠の曜日を選択します。デフォルトのオプションは [おまかせ] です。

   クラスタを作成すると、AlloyDB はこのデフォルトのメンテナンスの時間枠をクラスタに割り当てます。

5. メンテナンス更新の曜日を選択した場合は、メンテナンスの時間枠の時間を選択します。

6. [更新] をクリックして、変更を保存します。

gcloud

gcloud CLI を使用するには、Google Cloud CLI をインストールして初期化するか、Cloud Shell を使用します。

AlloyDB クラスタの構成の詳細を取得するには、gcloud alloydb clusters update コマンドを使用して次のコマンドを実行します。

gcloud alloydb clusters update PRODUCTION_CLUSTER_ID \
    --region=LOCATION_ID \
    --maintenance-window-day=DAY_OF_WEEK \
    --maintenance-window-hour=HOUR_OF_DAY \
    --project=PROJECT_ID

次のように置き換えます。

• PRODUCTION_CLUSTER_ID: 本番環境クラスタの ID。
• LOCATION_ID: Google Cloud のリージョン。
• DAY_OF_WEEK: メンテナンスの優先曜日（SUNDAY など）。

• HOUR_OF_DAY: メンテナンスの優先時間（UTC）（0 ～ 23）。

  次の例は、日曜日の午前 2 時（UTC）にメンテナンスの時間枠を設定する方法を示しています。

  gcloud alloydb clusters update my-prod-cluster \
      --region=us-central1 \
      --maintenance-window-day=SUNDAY \
      --maintenance-window-hour=2 \
      --project=my-production-project

本番環境クラスタのメンテナンスの時間枠を確認する

本番環境クラスタにメンテナンスの時間枠が設定されていることを確認するには、gcloud alloydb clusters describe コマンドを実行します。

gcloud alloydb clusters describe PRODUCTION_CLUSTER_ID \
--region=LOCATION_ID \
--project=PROJECT_ID

出力には、指定されたメンテナンスの日時を含む maintenanceSchedule フィールドが返されます。

メンテナンス通知をオプトインする

本番環境クラスタの定期メンテナンス イベントに関する通知を受け取るようにオプトインすることをおすすめします。通知は、テストを開始するタイミングを計画するのに役立ちます。

メンテナンス通知を受け取るには、次の手順を行います。

1. [クラスタ] ページに移動します。

   クラスタに移動

2. [リソース名] 列でクラスタをクリックします。[概要] ページが開きます。

3. [概要] ページの [メンテナンス] セクションで、[詳細を表示] をクリックしてセクションを開きます。[通知] 行の [編集] をクリックします。[通信] ページが開きます。

4. [コミュニケーション] ページで、[プロダクトに関するコミュニケーション] タブを選択します。

5. [AlloyDB] の行の [メール] 列で、通知ボタンを [オン] に切り替えます。

本番環境クラスタのメンテナンスの時間枠を構成すると、AlloyDB はステージング クラスタの更新から 7 日以上経過してから更新します。通知を受け取るように選択すると、本番環境クラスタのメンテナンス更新がスケジュールされていることを知らせるメール通知が届きます。

ステージング クラスタの更新

ステージング環境を使用して、今後の本番環境の更新を検証します。

更新前のステータスを確認する

ステージング クラスタにはメンテナンスの時間枠がないため、更新が最初に適用されるクラスタの 1 つになります。ただし、メンテナンスの時間枠が構成されていないクラスタについては、AlloyDB は通知を送信しません。ただし、 Google Cloud コンソールのログ エクスプローラを使用して、メンテナンス アップデートの発生時期をモニタリングできます。

1. Google Cloud コンソールで、[ログ エクスプローラ] ページに移動します。

   [ログ エクスプローラ] に移動

   検索バーを使用してこのページを検索する場合は、小見出しが [ロギング] の結果を選択します。

2. [すべてのリソース] を選択し、ステージング クラスタを選択して、[適用] をクリックします。

3. [すべてのログ名] を選択し、[maintenance_events] を選択して、[適用] をクリックします。

4. [タイムライン] ペインで、ステージング クラスタが更新を受け取る期間を選択します。

更新後の機能検証を実施する

AlloyDB がステージング クラスタを更新したら、機能テストを実施して、更新が安全で、本番環境に適用するのに適していることを確認します。

更新後のパフォーマンス検証を実施する

メンテナンス更新が完了したら、ステージング クラスタを確認します。ステージング クラスタの更新後に、データベースのパフォーマンスに影響がないか評価します。包括的な機能テストとパフォーマンス テストを実施して、アプリケーションが期待どおりに動作し、パフォーマンス SLA を満たしていることを確認します。

安定性と最適な動作を確保するには、次の操作を行います。

• 更新前のベースラインと主要な指標を比較します。
• 負荷テストを実行して、回帰を特定します。
• クエリ パフォーマンスを分析します。
• リソース使用率をモニタリングします。

確認結果に基づいて対応する

検証結果を確認し、結果に基づいて次の操作を行います。

• 検証が成功した場合: ステージング クラスタでの機能テストとパフォーマンス テストが成功した場合、ステージング環境にエラーがないため、本番環境のメンテナンスを予定どおりに実行できます。本番環境の更新に備え、関係者に通知します。
• 検証に失敗した場合: ステージング クラスタでの機能テストとパフォーマンス テストが失敗し、メンテナンス アップデート後にステージング環境で機能エラー、パフォーマンスの低下、予期しない動作が発生した場合は、本番環境のメンテナンスを拒否する必要があります。

スケジュールされたメンテナンス イベントを拒否する

本番環境クラスタのスケジュールされたメンテナンス イベントを拒否するには、開始日、終了日、期間の開始と終了の時刻を設定する必要があります。

開始日と終了日は、YYYY-MM-DD の形式にする必要があります。開始日、終了日、時刻はすべて UTC タイムゾーンです。

gcloud CLI を使用するには、Google Cloud CLI をインストールして初期化するか、Cloud Shell を使用します。

AlloyDB クラスタにメンテナンス拒否期間を追加する手順は次のとおりです。

1. deny-maintenance-period-start-date フラグ、deny-maintenance-period-end-date フラグ、deny-maintenance-period-time フラグを指定して、gcloud alloydb clusters update コマンドを実行します。

   gcloud alloydb clusters update CLUSTER_ID \
       --region LOCATION_ID \
       --deny-maintenance-period-start-date START_DATE \
       --deny-maintenance-period-end-date END_DATE \
       --deny-maintenance-period-time TIME

2. 次のように置き換えます。

   • CLUSTER_ID: メンテナンス期間を構成するクラスタ。
   • LOCATION_ID: このクラスタが配置されている Google Cloud リージョン。例: us-central1
   • START_DATE: メンテナンス拒否期間の開始日（YYYY-MM-DD UTC 形式）。
   • END_DATE: メンテナンス拒否期間の終了日（YYYY-MM-DD UTC 形式）。
   • TIME: メンテナンス拒否期間の時刻（HH:MM UTC 形式）。時刻は 24 時間形式で表示されます。値の範囲は 00:00～23:59 です（例: 16:45）。

3. エラー メッセージ、パフォーマンス指標、問題を再現する手順など、すべての問題を文書化します。

4. Google Cloud で優先度の高いサポートケースを開き、文書化されたすべての問題を提供します。 Google Cloud は、お客様と協力して問題を分析し、解決します。

本番環境クラスタの更新

ステージングの検証が成功し、本番環境のメンテナンスの続行を許可すると、スケジュールされたメンテナンスの時間枠で更新が行われます。

メンテナンスの時間枠を確認する

本番環境クラスタで今後のメンテナンス イベントをモニタリングする手順は次のとおりです。

コンソール

1. [クラスタ] ページに移動します。

   クラスタに移動

2. [リソース名] 列でクラスタをクリックします。[概要] ページが開きます。

3. [概要] ページの [メンテナンス] セクションで、クラスタのメンテナンスの時間枠の詳細を確認します。

   注: Google Cloud コンソールに AlloyDB の [メンテナンス] セクションの詳細が表示されるまでに時間がかかることがあります。

4. 省略可: [システム分析情報] ページで、[イベント タイムライン] などのメンテナンス オペレーションのステータスの詳細を確認できます。

5. 統合メンテナンスの管理を表示するには、検索バーに「Cloud Hub maintenance」と入力し、[メンテナンス] を選択します。このページでは、メンテナンスの概要、Google が管理するメンテナンス、計画されたメンテナンスの詳細を確認できます。

gcloud

gcloud CLI を使用するには、Google Cloud CLI をインストールして初期化するか、Cloud Shell を使用します。

gcloud alloydb clusters describe を使用して、次のコマンドを実行します。

gcloud alloydb clusters describe PRODUCTION_CLUSTER_ID \
    --region=LOCATION_ID \
    --project=PROJECT_ID

メンテナンス イベントが計画されている場合、出力には maintenanceSchedule と startTime が含まれます。通知を受け取るように選択した場合は、メール通知も届きます。

メンテナンスの時間枠中に本番環境をモニタリングする

Google Cloud はメンテナンス プロセスを自動化しますが、スケジュールされたメンテナンスの時間枠中に、本番環境で次のことをモニタリングすることをおすすめします。

• アプリケーションの健全性: アプリケーション ログとヘルスチェックをモニタリングして、中断の兆候がないか確認します。
• データベース接続: 中断後にアプリケーションがデータベースに再接続できることを確認します。
• AlloyDB 指標: Google Cloud Monitoring を使用して、AlloyDB 指標（CPU、メモリ、接続、レプリケーションの遅延）をモニタリングし、更新後にこれらの指標が想定レベルに戻ることを確認します。

メンテナンス更新後の検証

メンテナンス アップデートが完了したら、本番環境で重要な機能とパフォーマンス指標を確認します。

• 主要なアプリケーション機能: 最も重要なアプリケーション機能のスモークテストを実行します。
• 基本的なパフォーマンス チェック: ダッシュボードでレイテンシやリソース消費量の急増を確認します。

注: ステージング中に検出されなかった本番環境の問題が発生した場合は、標準のサポート プロトコルに沿って対応してください。問題の原因を特定するための調査を開始するには、Google カスタマー サポートにお問い合わせください。