ベンダーロックインは、データベーステクノロジーでよく知られている概念です。クラウドの使用が増えるにつれ、このロックインもクラウドプロバイダーを含むように拡張されました。ベンダーロックインは、顧客が製品やサービスをベンダーに依存するようにする独自のロックインとして定義できます。このロックインは、ベンダー/プロバイダーを変更できないことを意味しない場合もありますが、費用または時間のかかる作業になる可能性があります。
オープンソースのデータベーステクノロジーであるPostgreSQL自体にはベンダーロックインの問題はありませんが、システムをクラウドで実行している場合は、対処する必要がある可能性があります。いつかその問題になります。
このブログでは、PostgreSQLクラウドのロックインを回避する方法に関するヒントをいくつか紹介し、ClusterControlがそれを回避するのにどのように役立つかについても見ていきます。
ヒント＃1：クラウドプロバイダーの制限または制限を確認する
クラウドプロバイダーは通常、データをクラウドに移行するためのシンプルで使いやすい方法（またはツール）を提供します。問題は、それらを残したいときに、データを別のプロバイダーまたはオンプレミスのセットアップに移行する簡単な方法を見つけるのが難しい場合があることです。このタスクは通常、コストが高くなります（多くの場合、トラフィックの量に基づきます）。
この問題を回避するには、常に最初にクラウドプロバイダーのドキュメントと制限を確認して、離れるときに避けられない可能性のある制限を知る必要があります。
ヒント＃2：クラウドプロバイダー出口の事前計画
私たちが提供できる最善の推奨事項は、クラウドプロバイダーを離れる方法を知るために土壇場まで待たないことです。出口を作るための最良の、最速の、そして最も安価な方法を知ることができるように、それをかなり前もって計画する必要があります。、
このプランは特定のビジネス要件に依存する可能性が高いため、メンテナンスウィンドウをスケジュールできるかどうか、および会社がダウンタイム期間を受け入れるかどうかによって、プランは異なります。事前に計画しておくと、一日の終わりに頭痛がするのを確実に回避できます。
ヒント＃3：専用のクラウドプロバイダー製品の使用を避ける
クラウドプロバイダーの製品は、ほとんどの場合、オープンソース製品よりも優れたパフォーマンスを発揮します。これは、クラウドプロバイダーのインフラストラクチャで実行するように設計およびテストされているためです。多くの場合、パフォーマンスは2番目のパフォーマンスよりも大幅に向上します。
データベースを別のプロバイダーに移行する必要がある場合、クラウドプロバイダー製品は現在のクラウドプロバイダー環境でのみ利用可能であるため、テクノロジーのロックインの問題が発生します。これは、簡単に移行できないことを意味します。おそらく、ダンプファイル（または別のバックアップ方法）を生成することでそれを行う方法を見つけることができますが、おそらく長いダウンタイムが発生します（使用するデータとテクノロジーの量によって異なります）。
>Amazon RDSまたはAurora、Azure SQLデータベース、またはGoogle Cloud SQLを使用している場合（現在最も使用されているクラウドプロバイダーに焦点を当てるため）、代替案を確認してオープンソースに移行することを検討する必要がありますデータベース。これにより、移行する必要があると言っているわけではありませんが、必要に応じて移行するオプションがあるはずです。
ヒント＃4：バックアップを別のクラウドプロバイダーに保存する
移行の場合でもディザスタリカバリの場合でも、ダウンタイムを短縮するための良い方法は、バックアップを同じ場所に保存するだけでなく（リカバリの理由をより速くするため）、バックアップを次の場所に保存することです。別のクラウドプロバイダーまたはオンプレミスですら。
データを復元または移行する必要がある場合は、この方法に従うことで、バックアップが取り戻された後に最新のデータをコピーするだけで済みます。トラフィックと時間の量は、移行または障害イベント中に圧縮せずにすべてのデータをコピーするよりも大幅に少なくなります。
ヒント＃5：マルチクラウドまたはハイブリッドモデルを使用する
クラウドのロックインを回避したい場合は、これがおそらく最良のオプションです。 。データを2つ以上の場所にリアルタイムで（または可能な限りリアルタイムに近い形で）保存すると、迅速に移行でき、ダウンタイムを最小限に抑えることができます。あるクラウドプロバイダーにPostgreSQLクラスターがあり、別のクラウドプロバイダーにPostgreSQLスタンバイノードがある場合、プロバイダーを変更する必要がある場合は、スタンバイノードをプロモートして、この新しいプライマリPostgreSQLノードにトラフィックを送信できます。
この場合、おそらくクラウドプロバイダーがアウトバウンドトラフィックに対して料金を請求することに注意してください。したがって、トラフィックが多い場合は、この方法を機能させ続けると、会社に過剰なコストが発生する可能性があります。
ClusterControlがPostgreSQLのロックインを回避するのにどのように役立つか
PostgreSQLのロックインを回避するために、ClusterControlを使用してデータベースクラスターをデプロイ（またはインポート）、管理、および監視することもできます。これにより、システムの稼働を維持するために特定のテクノロジーやプロバイダーに依存することがなくなります。
ClusterControlには使いやすいUIが備わっているため、データベースを管理するためにクラウドプロバイダー管理コンソールを使用する必要はありません。ログインするだけで、同じシステム内のすべてのデータベースクラスターの概要。
3つの異なるバージョンがあります（コミュニティフリーバージョンを含む）。ライセンスの有効期限が切れていて、データベースのパフォーマンスに影響を与えない場合でも、ClusterControlを（一部の有料機能なしで）引き続き使用できます。
同じシステムから、異なるオープンソースデータベースエンジンをデプロイできます。 SSHアクセスと特権ユーザーが使用する必要があります。
ClusterControlは、バックアップシステムの管理にも役立ちます。ここから、（データベースエンジンに応じて）さまざまなバックアップ方法を使用して新しいバックアップをスケジュールし、別のノードに復元してバックアップを圧縮、暗号化、検証できます。同時に複数の異なる場所（クラウドを含む）に保存することもできます。
マルチクラウドまたはハイブリッドの実装は、ClusterControlを使用して簡単に実行できます。クラスター間レプリケーションまたはレプリケーションスレーブの追加機能。簡単なウィザードに従うだけで、新しいデータベースノードまたはクラスターを別の場所に展開できます。
データはおそらく会社にとって最も重要な資産であるため、データを可能な限り管理したいと思うでしょう。クラウドロックインを使用しても、これには役立ちません。クラウドロックインシナリオを使用している場合は、データを希望どおりに管理できないことを意味し、それが問題になる可能性があります。
ただし、クラウドのロックインが常に問題になるとは限りません。プロバイダー製品（Amazon RDSまたはAurora、Azure SQLデータベース、またはGoogle Cloud SQL）を使用して、すべてのシステム（データベース、アプリケーションなど）を同じクラウドプロバイダーで実行していて、探していない可能性があります。何かを移行する代わりに、クラウドプロバイダーのすべての利点を活用している可能性があります。クラウドのロックインを回避することは、それぞれの場合に依存するため、必ずしも必須ではありません。
PostgreSQLクラウドのロックインを回避するための最も一般的な方法とClusterControlがどのように役立つかを共有するブログを楽しんでいただけたでしょうか。