旧バージョンのドキュメントを参照しています。最新のドキュメントはこちらをご参照ください。

カサンドラから PostgreSQL への移行ガイドライン

このガイドでは、Kong GatewayをCassandra DBベースの従来のデプロイメントからPostgreSQLベースのハイブリッドデプロイメントに移行する手順を説明します。

このガイドでは、ブルーグリーン移行アプローチを採用しています。このアプローチでは、DNS スイッチングにより、トラフィックをブルー環境からグリーン環境に切り替えることができます。これにより、問題が検出された場合に、より速くロールバックできるようになります。

Kongでは、宣言型コンフィギュレーション管理ツールのdecKを推奨しています。

移行手順：

PostgreSQLを使用してターゲットKong Gatewayハイブリッド環境を構築します。これは空白のキャンバスとして機能します。
decK を使用して、従来の Cassandraベースのデプロイメントから（ dump）構成をエクスポートします。
decKを使用して、PostgreSQLを活用する新しいハイブリッド型デプロイメントに構成をインポート（sync）します。
Admin APIまたはKong Managerを使用して、基本認証情報とローカルRBACユーザーを作成します。
Kong Gateway構成がグリーン環境に移行されたら、カナリア経由でトラフィックをグリーン環境に徐々にリダイレクトします。これにより、迅速なロールバックメカニズムが確立され、リリースのリスクが軽減されます。

考慮事項

このドキュメントには大まかなガイドラインが記載されていますが、実際の移行手順は次の要因によって異なる場合があります。

Kongデプロイ環境の複雑さ
Kongプラグイン
カスタムプラグイン
ゲートウェイへの外部タッチポイント（外部IdPを備えたOIDCなど）
構成エンティティの数 (サービスやルートなど)
Kong Gatewayの古いバージョンを実行している場合は、データベースの移行前にKong Gatewayバージョンへのアップグレードを実行することをお勧めします。これにより、アップグレード手順の移行部分が軽減されます。
Cassandra を使用している場合は、従来のデプロイメントを使用している可能性があります。この機会に Kong Gateway のデプロイメントトポロジーのオプションを確認し、可能であればハイブリッドモードのデプロイメントに変換することをお勧めします。

次の図は、ハイブリッドモードデプロイメントのアーキテクチャを示しています。つまり、Kong Gateway コントロールプレーン（CP）とデータプレーン（DP）が分割されていることを意味します。従来のモードでデプロイされた Kong Gateway インスタンスでも、同じデータベース移行アプローチを使用できます。

 
flowchart LR
A[api.customer.com]
B[(Cassandra)]
C( Kong Gateway VM)
D( Kong Gateway DP)
E( Kong Gateway CP)
F[(Postgres)]

H[[decK]]

A --> C & D

subgraph id1 ["`**On premise**`"]
C --> B
end

subgraph id2 ["`**Kubernetes**`"]
D --> E --> F
end

C --export config via yaml--> H --sync config to CP--> E

style id1 stroke-dasharray:3,rx:10,ry:10
style id2 stroke-dasharray:3,rx:10,ry:10

前提条件

Kong Gatewayブルー環境 (Cassandra を使用) とグリーン環境 (PostgreSQL を使用) は、同じゲートウェイバージョンを実行しています。
次の例では、ブルーは従来モードでデプロイされ、グリーンはハイブリッドモードでデプロイされます。従来のデプロイメントに移行したい場合でも、手順に従うことはできますが、コントロールプレーンとデータプレーンのタスクを別々に実行する必要はありません。

移行アプローチ

次の手順は、非本番環境でテストする必要があります。ターゲット状態のギャップは、本番環境で実行する前に特定して修正する必要があります。

手順	名前	説明
1	プラットフォーム構築	ブルー環境と同じバージョンを使用して、Kong Gatewayでグリーン環境を構築します
2	データベースのセットアップ	新しいPostgres DBを構築し、グリーン環境に接続します
3	回帰テスト	セットアップを新しいシステムに展開し、回帰テストを実行します。テストが完了したら、デプロイメントをクリーンアップします。

準備

手順	名前	説明
1	禁輸措置の変更	古い環境に変更禁止措置を課し、新しい展開や構成の変更を防止します。
2	ブルー環境のバックアップ	ブルー環境の Cassandra データベースのバックアップを作成し、冗長ストレージに配置します。
3	監視のセットアップ	新しい環境の正常性を追跡するためのダッシュボードを作成する
4	Go/No Goチェックポイント	移行実行の Go/No Go 決定ポイント

実行

このフェーズの目標は、ブルー環境でKong Gateway構成を再現し、ライブトラフィックの切り替え前に回帰テストとスモークテストを実行することです。

手順	名前	説明
1	構成ダンプ	- 各ワークスペースのブルー環境に対して`deck gateway dump`コマンドを実行し、Kong エステートの YAML 表現を構築します。 - 各ワークスペースのブルー環境に対して`deck gateway dump --rbac-resources-only`を実行し、作成されたRBACリソースのYAML表現を構築します。 - Kong Dev Portal を使用している場合は、Portal CLI 経由で`portal fetch`コマンドを実行して、ワークスペースの Dev Portal アセットの表現を構築します。
2	構成の同期	- decK をグリーン環境で動作するように変更し、 `deck gateway sync`を実行して構成をグリーン環境にプッシュします。 - ポータル CLI をグリーン環境に対して動作するように変更し、 `portal deploy`を実行して、Dev Portal 構成を新しい環境にプッシュします。
3	回帰テスト	PostgreSQLを基盤としたグリーン環境に対して回帰テストを実行します
4	Go/No Goチェックポイント	すべてのテストに合格したら、トラフィックの切り替えを実施します。

トラフィックのカットオーバー

このフェーズの目的は、問題が検出された場合の迅速なフォールバックメカニズムを使用して、制御された方法でトラフィックを移行することです。リスク許容度に応じて、カナリア分割を増やす前に待機時間を増減できます。

手順	名前	説明
1	トラフィックの1%の新しいグリーン環境へのカナリアデプロイメント	トラフィックの1%を新しいグリーン環境にカナリアデプロイし、トラフィックヘルスを監視します。
2	トラフィックの5%の新しいグリーン環境へのカナリアデプロイメント	分割トラフィックを5%に引き上げ、監視します。
3	トラフィックの10%の新しいグリーン環境へのカナリアデプロイメント	分割トラフィックを10%に引き上げ、監視します。
4	トラフィックの50%の新しいグリーン環境へのカナリアデプロイメント	分割トラフィックを50%に日陰、監視します。
5	トラフィックの100%の新しいグリーン環境への切り替え	新しいグリーン環境を指すように完全なDNSの切り替えを実行します。
6	旧プラットフォームの撤去	信頼性が高くなる24時間後に、旧プラットフォームを撤去します。

次の手順

基本認証プラグインを使用している場合、パスワードはデータベースでハッシュ化および暗号化されます。 decKダンプはこれらの資格情報をエクスポートしないので、平文でデータベースからパスワードを取り出すことはできません。これらの資格情報は、Admin Api または Kong Manager を使用して移行する必要があります。
Kong Gatewayコントロールプレーン上の管理者ユーザーは、decK を使用して伝播されません。 Kong Admin APIを使用して移行します。

移行後、ベーシック認証情報はdecKで管理できます。decKでシークレットを管理する方法については、以下のトピックを参照してください。