本記事は 2026 年 2 月 12 日 に公開された「 Achieve near-zero downtime database maintenance by using blue/green deployments with AWS JDBC Driver 」を翻訳したものです。 最新のアプリケーションは継続的な可用性を求めており、データベースのメンテナンス運用は開発チームにとって重要な課題となっています。データベース更新、パッチ適用、アップグレードに対する従来のアプローチでは、ダウンタイムや接続障害、手動介入が必要となり、ビジネスオペレーションの中断やユーザーエクスペリエンスに影響を与えることがあります。 Amazon Relational Database Service (Amazon RDS) の Blue/Green デプロイメントは、並列のデータベース環境を作成することで計画的なダウンタイムの課題に対処します。本番環境に適用する前にデータベースの変更をテストできるようにします。このアプローチによりメンテナンスウィンドウは大幅に短縮されますが、切り替えプロセス中に接続の切断、DNS 伝播の遅延、接続障害時の手動介入など、わずかな中断が発生する可能性があります。 AWS は 2023 年に AWS JDBC Driver をリリースし、標準の JDBC ドライバーに AWS 固有の機能を追加しました。PostgreSQL、MySQL、MariaDB の JDBC ドライバー上のレイヤーとして構築されたラッパーで、Amazon Aurora と Amazon RDS の機能をサポートします。Amazon Aurora の接続追跡、AWS Identity and Access Management (IAM) 認証、読み取り/書き込みトラフィック分割など、複数のプラグインが含まれています。フェイルオーバー管理、モニタリング、認証、負荷分散などの機能を AWS JDBC Wrapper Driver でアプリケーションに統合できます。 本記事では、AWS JDBC Driver の Blue/Green デプロイメントプラグイン を紹介します。 組み込みプラグイン で、Blue/Green デプロイメントの切り替え時に接続ルーティング、トラフィック管理、切り替え検出を自動的に処理します。プラグインの設定方法と使用方法を示し、切り替え時にダウンタイムを最小限に抑える方法を説明します。 AWS JDBC Driver Blue/Green デプロイメントプラグインの紹介 Blue/Green デプロイメントプラグインは、AWS JDBC Driver の組み込みコンポーネントで、Blue/Green デプロイメントと連携して以下を提供します。 切り替えの自動検出と準備 遷移中のトラフィック管理 古い DNS の問題を回避する DNS 非依存のルーティング 最小限の設定変更 — JDBC 接続設定のみ プラグインは以下のように動作します。 RDS メタデータテーブルを通じて Blue/Green デプロイメントのステータスを監視 Blue と Green 両環境の接続インベントリを維持 切り替えフェーズに基づいてトラフィックをルーティング 遷移中の接続障害をグレースフルに処理 主な機能 AWS JDBC Driver Blue/Green デプロイメントプラグインは、データベース切り替え時の中断を最小限に抑えるために連携して動作する 3 つのコア機能を提供します。Blue/Green デプロイメントのフェーズの自動検出、両環境の適切なインベントリ管理、および切り替え状況に基づく動的なトラフィックルーティングです。これらの機能はバックグラウンドで継続的に動作し、接続障害を軽減しますが、切り替えプロセス中に発生する可能性のある一時的な例外に対応するため、アプリケーション側でもリトライロジックを実装することが推奨されます。 自動切り替え検出 プラグインはバックグラウンド監視スレッドを使用し、約 1 秒ごとに Blue/Green デプロイメント API をポーリングしてデプロイメントのステータス変更やフェーズの遷移を継続的に検出します。フェーズの変更が検出されると、即座に接続ルーティング戦略を調整します。プロアクティブな監視により、切り替えイベントを予測して接続管理を準備できるため、Blue/Green 遷移全体を通じてアプリケーションの接続性を向上させます。 プラグインは Blue/Green デプロイメントのステータスを継続的に監視し、以下のようにフェーズ遷移を検出します。 フェーズ検出タイムライン : NOT_CREATED : Blue/Green デプロイメントプラグインのコンポーネントがまだ作成されていません。 CREATED : Blue/Green デプロイメントが存在し、プラグインコンポーネントが初期化されます。プラグインは Blue と Green 両環境のインベントリを作成し、クラスターエンドポイントを対応する IP アドレスにマッピングします。両環境のヘルスステータスを追跡する監視接続が確立されます。 PREPARATION : プラグインはトラフィックをリダイレクトする接続ルーティングルールを確立します。各ソースエンドポイント (Blue 環境) を特定の IP アドレスにマッピングする設定を作成し、新しい接続が適切なターゲットに向けられる一方で既存の接続はアクティブなまま維持されます。このフェーズでは、現在のデータベース操作を中断することなく、最終的なトラフィック切り替えに必要なインフラストラクチャをセットアップします。 IN_PROGRESS : アクティブな切り替えが進行中で、遷移中はソース (Blue) とターゲット (Green) 両環境でクエリ実行が一時停止されます。ソース (Blue) 環境への JDBC コールの一時停止によりデータベース負荷を軽減し、ターゲット (Green) 環境でのレプリケーションの追いつきを可能にします。プラグインは Blue 環境の IP アドレスに直接ソースエンドポイント (Blue) への新しい接続をリダイレクトして古い DNS エントリへの接続を排除し、ターゲットエンドポイント (Green) への新しい接続は一時停止します。 POST : プラグインは両環境のクラスタートポロジーと DNS エントリを更新します。プラグインは DNS 伝播を監視し、DNS エントリが安定するにつれて IP ベースのルーティングからホスト名ベースの接続に段階的に移行します。 COMPLETED : 切り替えが正常に完了しました。 プラグインは AWS Blue/Green デプロイメントのステータスを以下のフェーズにマッピングします。 Blue/Green デプロイメントのステータス Blue/Green デプロイメントプラグインのフェーズ プラグインのアクション AVAILABLE CREATED 監視を初期化する。 SWITCHOVER_INITIATED PREPARATION 新しい接続をリダイレクトする接続ルーティングインフラストラクチャを確立する。 SWITCHOVER_IN_PROGRESS IN_PROGRESS すべてのクエリ実行を一時停止し、新しい接続を Blue 環境の IP アドレスにルーティングする。 POST 最初は IP ベースのルーティングでトラフィックを処理し、段階的にホスト名ベースの接続に移行する。 SWITCHOVER_COMPLETED COMPLETED 監視を終了し、通常の操作を再開する。 接続インベントリ管理 プラグインは Blue と Green 両環境のインベントリをすべて維持し、自動切り替え操作を実現します。 Blue 環境の追跡 : CREATED フェーズ中に、プラグインは Blue 環境のすべてのコンポーネント (クラスターエンドポイント、リーダーエンドポイント、ライターエンドポイント、個別のインスタンスエンドポイント) を検出しカタログ化します。各エンドポイントについて、対応する IP アドレスを解決して保存し、現在の本番環境の完全なマッピングを作成します。このインベントリは切り替え操作時の比較のベースラインとなります。 Green 環境の追跡 : 同時に、プラグインは対応するすべての Green 環境のエンドポイントを特定しマッピングします。Blue/Green デプロイメントのメタデータを使用して、各 Blue エンドポイントに対応する Green の対応先を把握し、Blue と Green コンポーネント間の関係を確立します。すべての Green エンドポイントの IP アドレスを解決し、切り替え時に即座に使用できるよう維持します。 適切なトラフィック管理 切り替え時に、プラグインは接続の確立とクエリ実行の両方を対象としたトラフィック管理を実装します。 接続管理 : ルーティング戦略を使用して新しいデータベース接続の確立を制御 クエリ実行管理 : 重要なフェーズ中の既存接続での SQL ステートメントの実行を制御 フェーズごとのトラフィック管理: PREPARATION: Blue エンドポイントへの新しい接続は直接 IP アドレスを使用してルーティングされます。 既存の接続は通常どおり継続します。 DNS 解決をバイパスする IP ベースのルーティングが使用されます。 IN_PROGRESS: Green エンドポイントへの新しい接続は一時停止されます。 Blue エンドポイントへの新しい接続はデフォルトでダイレクト IP ルーティングを使用しますが、 bgSuspendNewBlueConnections が有効な場合は一時停止されます。 Blue と Green 両エンドポイントですべてのクエリ実行が一時停止されます。 アクティブな切り替え期間中、Blue と Green 両環境への既存の接続はドロップされます。 POST: Blue エンドポイントへの新しい接続は、IP ベースのルーティングを使用して Green エンドポイント (新しい Blue 環境) にルーティングされます。 Blue エンドポイントの DNS エントリが更新されると、ホスト名ベースのルーティングに移行します。 Green エンドポイント (古い Green 環境) への新しい接続は拒否されます。 COMPLETED: 新しいアクティブなエンドポイントへの通常のルーティングが再開されます。 前提条件 データベースエンジンの要件 データベースエンジン Blue 環境 Green 環境 Amazon Aurora PostgreSQL エンジンリリース 17.5、16.9、15.13、14.18、13.21 以降 エンジンリリース 17.5、16.9、15.13、14.18、13.21 以降 Amazon RDS for PostgreSQL rds_tools v1.7 以降 (17.1、16.5、15.9、14.14、13.17、12.21) rds_tools v1.7 以降 (17.1、16.5、15.9、14.14、13.17、12.21) Amazon Aurora MySQL 任意のデータベースエンジンバージョン エンジンリリース 3.07 以降 Amazon RDS for MySQL Blue/Green デプロイメント 対応バージョン Blue/Green デプロイメント 対応バージョン アプリケーションスタックの要件 AWS JDBC Driver バージョン 2.6.4 以降 データベースドライバー: PostgreSQL JDBC ドライバーまたは MySQL/MariaDB JDBC ドライバー ランタイム環境: Amazon Corretto 8 以上または Java 8 以上 クラスターのセットアップとトポロジー AWS JDBC Driver Blue/Green プラグインがデータベースのアップグレードやメンテナンス中にアプリケーションのダウンタイムをどのように最小化するかを示すため、テスト環境をセットアップしました。一般的な本番トポロジーを表す、1:1 のライター/リーダー構成の Aurora PostgreSQL クラスターで構成されています。 サンプル Java アプリケーションはクラスターのライターエンドポイントに対して一定の読み取りワークロードを生成し、Blue/Green デプロイメントの切り替え中にプラグインがアプリケーションの接続性を向上させることを実証します。 以下の図のように、Blue/Green デプロイメントを作成しました。 ソース (Blue) 環境には以下が含まれます。 1 つのプライマリライターインスタンス 1 つのリーダーインスタンス 関連するクラスターおよびインスタンスエンドポイント ターゲット (Green) 環境は以下のトポロジーを備えています。 対応するライターインスタンス 対応するリーダーインスタンス 同等のエンドポイント設定 この対称的なセットアップにより、プラグインが Blue/Green デプロイメントのステータスを監視し、切り替えの進行に合わせてアプリケーション接続を適切なエンドポイントに自動的にリダイレクトするため、ターゲット (Green) 環境が切り替えプロセス中にワークロードリクエストを処理できます。 Blue/Green デプロイメントプラグインを使用した Java アプリケーションのセットアップ AWS JDBC Driver をアプリケーションに統合するには、依存関係管理に Maven または Gradle ビルドシステムを使用します。サンプルアプリケーションでは Maven を使用したセットアップを示していますが、依存関係は Gradle プロジェクトでも動作します。 Maven の依存関係 pom.xml ファイルを更新して以下の依存関係を追加します。 <dependency>     <groupId>software.amazon.jdbc</groupId>     <artifactId>aws-advanced-jdbc-wrapper</artifactId>     <version>2.6.4</version> </dependency> <dependency>     <groupId>org.postgresql</groupId>     <artifactId>postgresql</artifactId>     <version>LATEST</version> </dependency> Gradle ユーザーは、同じ依存関係を Gradle の依存関係構文で build.gradle ファイルに追加できます。 主なプラグインパラメーター Blue/Green デプロイメントプラグインの以下のパラメーターを設定します。 wrapperPlugins : データベース接続用にロードしてアクティブ化する AWS JDBC Wrapper プラグインを指定します。Blue/Green デプロイメントプラグインを使用するには、以下の Java コードのように bg プラグインをロードする必要があります。 props.setProperty("wrapperPlugins", "bg"); bgdId : プラグイン内で特定の Blue/Green デプロイメント操作を追跡するためのユーザー定義の一意の識別子を指定します (デフォルト: 1)。このパラメーターは AWS コンソールの Blue/Green デプロイメント名やリソース ID とは関係なく、複数の Blue/Green デプロイメントを同時に監視する際にプラグインが区別するための内部ラベルです。例えば、AWS アカウントで 3 つの Blue/Green デプロイメントが同時に実行されている場合、各デプロイメントに一意の bgdId 値 (1、2、3 や bg1、bg2、bg3 など) を割り当て、プラグインが各デプロイメントのステータスと切り替えイベントを独立して追跡・監視できるようにする必要があります。 blue-green-monitoring-connectTimeout : Blue/Green デプロイメントのステータスを追跡する監視接続の接続タイムアウトをミリ秒で設定します (デフォルト: 30000)。プラグインはデプロイメントフェーズの変更を検出するために個別の監視接続を確立するため、このパラメーターは重要です。適切なタイムアウトにより、プラグインは無限に待機することなくデプロイメントの進行状況を確実に監視できます。 blue-green-monitoring-socketTimeout : デプロイメントステータスを追跡する監視接続のソケットタイムアウトをミリ秒で設定します (デフォルト: 30000)。デプロイメントフェーズの確認時に監視操作が無限にブロックされることを防ぎ、ネットワークの問題や応答の遅延時にもプラグインの応答性を維持するために不可欠です。 bgSwitchoverTimeoutMs : プラグインが Blue/Green デプロイメントのステータスを監視し続ける最大時間をミリ秒で定義します (デフォルト: 300000 — 5 分)。このパラメーターは、プラグインがデプロイメントの切り替えプロセスをタイムアウトするまでアクティブに追跡する期間を決定します。Blue/Green 切り替え操作を開始する前に定義した切り替えタイムアウトと同じかそれ以上の値に設定してください。切り替えがタイムアウト前に正常完了した場合、Blue/Green デプロイメントステータスの監視は自動的に停止します。プラグインが無期限に監視せず、Amazon RDS の切り替えプロセスが完了し検出されるのに十分な時間を確保するため、適切な値を設定してください。 bgSuspendNewBlueConnections : 切り替えフェーズ中に Blue クラスターへの新しい接続を一時停止するかどうかを制御します (デフォルト: false)。true に設定すると、プラグインはアクティブな切り替えフェーズ中に Blue ノードへの新しい接続の試行を一時的に停止します。 以下のコードは Blue/Green プラグインパラメーターの設定方法を示しています。 // Configure blue/green plugin parameters props.setProperty("wrapperPlugins", "bg,auroraConnectionTracker,failover2,efm2"); props.setProperty("bgdId","blue-green-demo-id"); props.setProperty("blue-green-monitoring-connectTimeout", "20000"); props.setProperty("blue-green-monitoring-socketTimeout", "20000"); props.setProperty("bgSwitchoverTimeoutMs","600000"); テストでは、Blue/Green プラグインの効果を測定するため、Blue/Green デプロイメントの切り替え中に Aurora PostgreSQL クラスターのライターエンドポイントに対して継続的な読み取り専用ワークロードを実行する 2 つの同一アプリケーションを評価しました。Blue/Green プラグインなしのベースラインアプリケーションは、切り替えフェーズ中に接続の中断が発生し、接続障害を処理するためにアプリケーションレベルのリトライロジックが必要でした。400 件のクエリ中 2 件の接続障害が発生し、切り替えプロセス中のアプリケーションダウンタイムは 30.21 秒で、新しいエンドポイントへの手動での接続再確立が必要でした。 Blue/Green プラグインを有効にし、Blue 接続の一時停止を有効にしたアプリケーションは、切り替えフェーズ中の耐障害性が向上しました。テストシナリオでは、プラグイン有効のアプリケーションは 400 件のクエリ中接続障害がゼロで、切り替えプロセス中のワークロード実行の一時停止は 11.77 秒、自動ルーティングの一時停止と回復で接続を管理しました。プラグインはアプリケーション起動直後に Blue/Green デプロイメントを検出し、デプロイメントプロセス全体を通じてソースとターゲット両環境を継続的に監視しました。POST フェーズと COMPLETED フェーズでは、プラグインがすべてのクエリをターゲット (Green) 環境に自動的にルーティングし、切り替えプロセス中の手動エンドポイント更新が不要になりました。ただし、ネットワーク遷移中に発生する可能性のある接続関連の例外に対応するため、アプリケーションにリトライロジックを実装することを推奨します。 Blue/Green デプロイメントのメタデータとライフサイクルのサマリー Blue/Green デプロイメントの切り替え中に、プラグインがデプロイメントの進行状況とステータスを追跡するメタデータを監視できます。Aurora PostgreSQL の場合は get_blue_green_fast_switchover_metadata() 関数で、デプロイメントフェーズ、トポロジーの変更、切り替えステータスに関するリアルタイム情報を取得します。RDS PostgreSQL の場合は rds_tools.show_topology() 関数が同様のメタデータを提供します。RDS/Aurora MySQL インスタンスは mysql.rds_topology テーブルを使用します。デプロイメントのステータスを確認し、Blue と Green 環境間の遷移が正常に完了したことを検証できます。以下の例はステータス変更のサンプルです。 -[ RECORD 1 ]--+----------------------------------------------- id | 1758432615 endpoint | apg-17.cluster.<aws-region>.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_SOURCE status | AVAILABLE version | 1.0 update_stamp | 1759801475 -[ RECORD 2 ]--+----------------------------------------------- id | 756345441 endpoint | apg-17-green-xxx.cluster.<aws-region>.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_TARGET status | AVAILABLE version | 1.0 update_stamp | 1759801475 postgres=> SELECT * FROM get_blue_green_fast_switchover_metadata('aws_jdbc_driver-" + DriverInfo.DRIVER_VERSION + "'); -[ RECORD 1 ]--+---------------------------------------------- id | 756345441 endpoint | apg-17.cluster.<aws-region>.rds.amazonaws.com port | 5432 role | BLUE_GREEN_DEPLOYMENT_TARGET status | SWITCHOVER_COMPLETED version | 1.0 update_stamp | 1759801921 詳細なパフォーマンスメトリクスと切り替えタイムラインはプラグインによりアプリケーションログに自動的に記録されます。 wrapperLoggerLevel を fine または finest に設定すると、 logSwitchoverFinalSummary やその他の診断情報を取得して分析とトラブルシューティングに利用できます。 Oct 14, 2025 12:11:39 AM software.amazon.jdbc.plugin.bluegreen.BlueGreenStatusProvider logSwitchoverFinalSummary FINE: [bgdId: 'blue-green-demo-id'] ---------------------------------------------------------------- timestamp                    time offset event (ms)   ---------------------------------------------------------------- 2025-10-14T00:10:08.4603764Z -44135 ms   NOT_CREATED 2025-10-14T00:10:08.5063897Z -44089 ms   CREATED 2025-10-14T00:10:49.7132486Z -2882 ms   PREPARATION 2025-10-14T00:10:52.5956307Z     0 ms   IN_PROGRESS 2025-10-14T00:11:04.2233952Z 11627 ms   POST 2025-10-14T00:11:09.3191489Z 16723 ms   Green topology changed 2025-10-14T00:11:38.7487807Z   46153 ms   Blue DNS updated 2025-10-14T00:11:39.0190950Z   46423 ms   Green DNS removed 2025-10-14T00:11:39.0193661Z   46423 ms   COMPLETED ---------------------------------------------------------------- logSwitchoverFinalSummary は、Blue/Green デプロイメントのライフサイクル全体の時系列ビューを提供します。 切り替え前フェーズ (負の時間) : -44.13 秒 : プラグインが初期化され、Blue/Green デプロイメントのステータスを最初に確認します (NOT_CREATED 状態)。 -44.08 秒 : プラグインが Blue/Green デプロイメントの存在を検出し (CREATED に遷移)、すぐに Blue と Green 両環境のインベントリの作成と監視接続の確立を開始します。 -44.08 〜 -2.88 秒 : プラグインは両環境への接続を継続的に監視・維持します。 -2.88 秒 : RDS Blue/Green デプロイメントが切り替えを開始します (プラグインが PREPARATION フェーズを検出)。準備フェーズが始まり、プラグインは差し迫った切り替えに備えます。 -2.88 〜 0 秒 : 最終準備ウィンドウが完了します。 アクティブおよび切り替え後フェーズ (0 ms 以降) : 0 秒 : IN_PROGRESS フェーズが開始し、アクティブな切り替えが実行されます。 0 〜 +11.62 秒 : IN_PROGRESS フェーズが進行中で、アクティブな切り替え時間です (接続障害が発生する可能性があります)。 +11.62 秒 : POST フェーズが開始します。プラグインはソース (Blue) とターゲット (Green) 両環境をアクティブに監視し、Green トポロジーの変更を検出して、新しい接続をターゲット (Green) 環境にルーティングし始めます。 +16.72 秒 : Green トポロジーが変更されます。プラグインは Green クラスターのトポロジーテーブルが新しいエンドポイント ( green- プレフィックスなし) で更新されたことを検出し、インフラストラクチャの切り替えが機能的に完了したことを示します。 +46.15 秒 : Blue DNS が更新されます。プラグインは元の Blue クラスターエンドポイントの DNS レコードが新しいインフラストラクチャ (新しい IP、以前の Green 環境) を指すように更新されたことを検出します。 +46.42 秒 : Green DNS が削除されます。プラグインは Green クラスターエンドポイント ( green- プレフィックス付き) の DNS レコードが削除され、IP アドレスに解決されなくなったことを検出します。 +46.42 秒 : COMPLETED — すべての操作が完了しました。 まとめ 本記事では、AWS JDBC Driver 内の Blue/Green デプロイメントプラグインが Blue/Green デプロイメントの切り替えを自動的に管理し、データベースメンテナンスのダウンタイムをほぼゼロに抑えることを実証しました。プラグインの適切な接続ルーティングとトラフィック管理機能により、RDS と Aurora で Blue/Green デプロイメントを実行しながらデータベースメンテナンス中のアプリケーションの可用性と耐障害性を向上できます。ぜひお客様のユースケースで Blue/Green デプロイメントプラグインを試し、フィードバックや質問を AWS Advanced JDBC Wrapper GitHub discussions で共有してください。 AWS Advanced JDBC Wrapper Driver の追加機能については、以下の関連ブログをご覧ください。 IAM 認証と AWS Secrets Manager の統合については、紹介ブログ「 Introducing the Advanced JDBC Wrapper Driver for Amazon Aurora 」をご覧ください。 RDS Multi-AZ アップグレード時の 1 秒以下のダウンタイム達成については「 Achieve One Second or Less Downtime with the Advanced JDBC Wrapper Driver when Upgrading Amazon RDS Multi-AZ DB Clusters 」をご覧ください。 Initial Connection Strategy プラグインと Failover2 プラグインを使用した接続管理の強化については「 Demystifying the AWS Advanced JDBC Wrapper Plugins 」をご覧ください。 Blue/Green デプロイメントプラグインを他の AWS JDBC Driver の機能と組み合わせることで、データベースメンテナンスプロセスを簡素化しながら、より耐障害性の高いアプリケーションを構築できます。 著者について Jason Pedreza Jason は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。ペタバイト規模の環境における大規模データ変換や移行を専門としています。リレーショナルデータベース、データウェアハウス、データ分析、クラウドネイティブテクノロジーの豊富な知識を活かし、お客様の高可用性データベースソリューションの設計を支援しています。 Chandra Pathivada Chandra は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのオープンソースデータベースエンジンに注力しています。AWS 上でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 この記事は Kiro が翻訳を担当し、Solutions Architect の Kenta Nagasue がレビューしました。

概要 新卒研修で初めてPHP+Laravelのコードを書いて以来、ずっとLaravel(稀にPython)で仕事をしてきた。しかし風の噂によると、社内でもTypeScriptを使ったプロジェクトが増えてきていて需要があるのはJavaやTypeScriptらしい。 せっかくClaudeでコードを書ける環境にいるので、勉強しながら記事を書くことにした。 AIにコードを書かせる過程で浮かんだ疑問も載せたので、似た境遇にある人は読んでみてほしい。

はじめに こんにちは！芝浦工業大学理工学研究科 修士1年の只野陽生と申します。2026年2月の3週間 ...