21 世紀に SQL データベースを生き残る方法: クラウド、Kubernetes、PostgreSQL マルチマスター

ハブロフスク在住の皆さん、こんにちは。 今日からコースの最初のグループの授業が始まります 「ポストグレSQL」。 これに関連して、このコースの公開ウェビナーがどのように開催されたかについてお話ししたいと思います。

В 次回の公開レッスン クラウドと Kubernetes の時代に SQL データベースが直面する課題について話しました。 同時に、これらの課題の影響下で SQL データベースがどのように適応し、変化するかを調べました。

ウェビナーが開催されました ヴァレリー・ベズルコフ, EPAM Systems の Google Cloud Practice Delivery マネージャー。

木が小さかった頃…

まず、DBMS の選択が前世紀末にどのように始まったかを思い出してみましょう。 ただし、当時の DBMS の選択は始まりと終わりであったため、これは難しいことではありません。 オラクル.

90 年代後半から 2 年代初頭にかけて、産業用のスケーラブルなデータベースに関しては基本的に選択肢がありませんでした。 はい、IBM DBXNUMX、Sybase、およびその他のデータベースが登場しては消えていきましたが、一般に、それらは Oracle の背景に対してそれほど目立つものではありませんでした。 したがって、当時の技術者のスキルは何らかの形で唯一の選択肢に結びついていました。

Oracle DBA は次のことができる必要がありました。

• 配布キットから Oracle Server をインストールします。
• Oracle サーバーを構成します。

• init.ora;
• リスナー.ora;

- 作成する：

• テーブルスペース。
• 図式;
• ユーザー;

— バックアップと復元を実行します。
— モニタリングを実施する。
— 最適ではないリクエストに対処します。

同時に、Oracle DBA からは特別な要件はありませんでした。

• データの保存と処理に最適な DBMS またはその他のテクノロジを選択できる。
• 高可用性と水平スケーラビリティを提供します (これは常に DBA の問題ではありませんでした)。
• 主題分野、インフラストラクチャ、アプリケーション アーキテクチャ、OS に関する十分な知識。
• データのロードとアンロード、異なる DBMS 間でのデータの移行。

一般的に、当時の選択について言えば、それは 80 年代後半のソ連の店での選択に似ています。

私たちの時間

それ以来、もちろん木々は成長し、世界は変化し、次のようになりました。

Gartner の最新レポートから明らかなように、DBMS 市場も変化しました。

そしてここで、人気が高まっているクラウドがそのニッチを占めていることに注意する必要があります。 同じ Gartner レポートを読むと、次の結論が得られます。

1. 多くの顧客がアプリケーションをクラウドに移行しようとしています。
2. 新しいテクノロジーは最初にクラウドに登場しますが、それらが非クラウド インフラストラクチャに移行するということは事実ではありません。
3. 従量課金制の料金モデルは一般的になってきました。 誰もが自分が使った分だけ支払いたいと考えていますが、これはトレンドですらなく、単に事実を述べているだけです。

今何？

今日、私たちは皆クラウドの中にいるのです。 そして、私たちに生じる質問は、選択する質問です。 オンプレミス形式での DBMS テクノロジの選択についてのみ話したとしても、それは膨大です。 マネージドサービスやSaaSもございます。 したがって、選択は年々難しくなるばかりです。

選択可能な質問のほかに、 制限要因:

• 価格。 多くのテクノロジーには依然として費用がかかります。
• スキル。 フリー ソフトウェアについて話している場合、スキルの問題が生じます。フリー ソフトウェアは、それを展開して運用する人々に十分な能力を必要とするからです。
• 機能的。 クラウドで利用でき、同じ Postgres 上に構築されたすべてのサービスが、オンプレミスの Postgres と同じ機能を備えているわけではありません。 これは、知って理解する必要がある重要な要素です。 さらに、この要素は、単一の DBMS の隠れた機能に関する知識よりも重要になります。

現在 DA/DE に期待されていること:

• 主題領域とアプリケーション アーキテクチャについての十分な理解。
• 当面のタスクを考慮して、適切な DBMS テクノロジを正しく選択する能力。
• 既存の制限の中で、選択したテクノロジーを実装するための最適な方法を選択する能力。
• データの転送と移行を実行する機能。
• 選択されたソリューションを実装および運用する能力。

以下の例 GCPに基づく データを操作するためのテクノロジの選択が、データの構造に応じてどのように機能するかを示しています。

PostgreSQL はスキーマに含まれていないことに注意してください。これは、用語の下に隠されているためです。 クラウドSQL。 Cloud SQL に到達したら、もう一度選択する必要があります。

この選択は必ずしも明確ではないため、アプリケーション開発者は直感に頼ることが多いことに注意してください。

合計：

1. さらに進めば進むほど、選択の問題はより差し迫ったものになります。 また、GCP、マネージド サービス、SaaS だけを見ても、RDBMS に関する言及は 4 番目のステップでのみ表示されます (Spanner は近くにあります)。 さらに、PostgreSQL の選択は 5 番目のステップで表示され、その隣には MySQL と SQL Server もあります。 何もかもたくさんあるけど、選ばなければいけない.
2. 誘惑を背景とした制限を忘れてはなりません。 基本的に誰もがスパナを欲しがりますが、高価です。 その結果、一般的なリクエストは次のようになります。 「私たちを Spanner にしてください。ただし、Cloud SQL の料金を支払えば、あなたたちはプロフェッショナルです。」

何をすべきか？

究極の真実であるとは主張しませんが、次のように言ってみましょう。

私たちは学習へのアプローチを変える必要があります。

• DBA が以前に教えられていた方法を教えることには意味がありません。
• XNUMX つの製品に関する知識だけではもはや十分ではありません。
• しかし、XNUMX 人のレベルで何十ものことを知ることは不可能です。

製品の価格だけでなく、次のことも知る必要があります。

• そのアプリケーションの使用例。
• さまざまな展開方法。
• 各方法の長所と短所。
• 常に使い慣れた製品を支持するわけではなく、十分な情報に基づいた最適な選択を行うために、類似製品や代替製品を利用する必要があります。

また、データを移行し、ETL との統合の基本原則を理解できる必要もあります。

実際のケース

最近では、モバイル アプリケーションのバックエンドを作成する必要がありました。 作業が開始されるまでに、バックエンドはすでに開発され、実装の準備ができていました。開発チームはこのプロジェクトに約 XNUMX 年を費やしました。 次のタスクが設定されました。

• CI/CD を構築します。
• アーキテクチャをレビューします。
• すべてを実行に移します。

アプリケーション自体はマイクロサービスであり、Python/Django コードは GCP で直接スクラッチから開発されました。 対象者としては米国と欧州の XNUMX つのリージョンを想定し、グローバル ロード バランサを通じてトラフィックを分散しました。 すべてのワークロードとコンピューティング ワークロードは Google Kubernetes Engine 上で実行されました。

データに関しては、次の 3 つの構造がありました。

• クラウドストレージ;
• データストア。
• クラウド SQL (PostgreSQL)。

なぜ Cloud SQL が選ばれたのか不思議に思う人もいるかもしれません。 実を言うと、このような質問は近年、ある種の気まずい一時停止を引き起こしています。人々はリレーショナル データベースに対して恥ずかしがり屋になっているように感じられますが、それでもなお、積極的に使用し続けています ;-)。

私たちのケースでは、次の理由から Cloud SQL が選択されました。

1. 前述したように、このアプリケーションは Django を使用して開発されており、SQL データベースの永続データを Python オブジェクト (Django ORM) にマッピングするモデルを備えています。
2. フレームワーク自体は、かなり限定された DBMS リストをサポートしていました。

• PostgreSQL;
• マリアDB;
• MySQL;
• オラクル
• SQLiteの。

したがって、PostgreSQL はこのリストからかなり直感的に選択されました (まあ、実際に選択するのは Oracle ではありません)。

欠けていたもの:

• アプリケーションは 2 つのリージョンにのみデプロイされ、3 番目のリージョンが計画に登場しました (アジア)。
• データベースは北米地域 (アイオワ州) にありました。
• 顧客側では、次のような可能性があると懸念していました。 アクセスの遅延 ヨーロッパやアジアからも、 中断 サービス中 DBMS ダウンタイムの場合。

Django 自体は複数のデータベースを並行して操作し、読み取りと書き込みに分割できるにもかかわらず、アプリケーション内での書き込みはそれほど多くありませんでした (90% 以上が読み取り)。 そして、一般的に、そして一般的に、それが可能であれば ヨーロッパとアジアの主要拠点のリードレプリカ、これは妥協的な解決策になります。 さて、何がそんなに複雑なのでしょうか？

問題は、お客様がマネージド サービスと Cloud SQL の使用を諦めたくなかったことです。 また、Cloud SQL の機能は現時点では制限されています。 Cloud SQL は高可用性（HA）とリードレプリカ（RR）をサポートしますが、同じ RR は XNUMX つのリージョンでのみサポートされます。 アメリカ リージョンでデータベースを作成した場合、Cloud SQL を使用してヨーロッパ リージョンでリードレプリカを作成することはできません。ただし、Postgres 自体はこれを妨げるものではありません。 Google 従業員とのやり取りは何の成果もなく、「私たちは問題を認識しており、取り組んでいます。いつか問題は解決されるでしょう」というスタイルの約束で終わりました。

Cloud SQL の機能を簡単にリストすると、次のようになります。

1. 高可用性 (HA):

• XNUMXつの地域内。
• ディスクレプリケーション経由。
• PostgreSQL エンジンは使用されません。
• 自動および手動制御が可能 - フェイルオーバー/フェイルバック。
• 切り替えると、DBMS は数分間使用できなくなります。

2. リードレプリカ (RR):

• XNUMXつの地域内。
• ホットスタンバイ。
• PostgreSQL ストリーミング レプリケーション。

さらに、通常のことですが、テクノロジーを選択するときは常にいくつかの問題に直面します。 制限:

• お客様は、GKE を使用する場合を除き、エンティティを作成して IaaS を使用することを希望していませんでした。
• 顧客はセルフサービスの PostgreSQL/MySQL の導入を望んでいません。
• まあ、一般的に、価格がなければ Google Spanner は非常に適していますが、Django ORM は動作しませんが、それは良いことです。

この状況を考慮して、お客様は次のような追加の質問を受けました。 「Google Spanner のように、Django ORM でも動作するような同様のことはできませんか?」

解決策の選択肢 No.0

最初に思いついたのは:

• CloudSQL 内にとどまります。
• どのような形式であっても、リージョン間には組み込みのレプリケーションは存在しません。
• PostgreSQL によって既存の Cloud SQL にレプリカをアタッチしてみます。
• どこかで何らかの方法で PostgreSQL インスタンスを起動しますが、少なくともマスターには触れないでください。

残念ながら、ホスト (まったく別のプロジェクトにある) - pg_hba などへのアクセスがなく、スーパーユーザーの下でのアクセスもないため、これは実行できないことが判明しました。

解決策の選択肢 No.1

さらに熟考し、以前の状況を考慮した結果、思考の流れが若干変わりました。

• 私たちは依然として Cloud SQL 内に留まろうとしていますが、MySQL に切り替えています。これは、Cloud SQL by MySQL には次のような外部マスターがあるためです。

— 外部 MySQL のプロキシです。
- MySQL インスタンスのように見えます。
- 他のクラウドまたはオンプレミスからデータを移行するために考案されました。

MySQL レプリケーションのセットアップにはホストへのアクセスが必要ないため、原理的にはすべてうまくいきましたが、非常に不安定で不便でした。 さらに先に進むと、構造全体を terraform でデプロイしたところ、外部マスターが terraform でサポートされていないことが突然判明したため、完全に恐ろしくなりました。 はい、Google には CLI がありますが、何らかの理由で、ここですべてが機能することがありました。作成される場合もあれば、作成されない場合もあります。 おそらく、CLI はレプリカのためではなく、外部データ移行のために発明されたからでしょう。

実はこの時点で、Cloud SQL はまったく適していないことが明らかになりました。 彼らが言うように、私たちはできる限りのことをしました。

解決策の選択肢 No.2

Cloud SQL フレームワーク内にとどまることは不可能だったため、妥協的な解決策の要件を策定しようとしました。 要件は次のとおりであることが判明しました。

• Kubernetes で作業し、Kubernetes (DCS など) と GCP (LB など) のリソースと機能を最大限に活用します。
• HA プロキシなど、クラウド内の多数の不必要なものによるバラストの不足。
• メイン HA リージョンで PostgreSQL または MySQL を実行する機能。 他のリージョン - メインリージョンの RR とそのコピーからの HA (信頼性のため)。
• マルチマスター (連絡したくなかったが、それほど重要ではなかった)

.
これらの要求の結果、p適切な DBMS とバインド オプション:

• MySQL ガレラ。
• ゴキブリDB;
• PostgreSQL ツール

:
- pgpool-II;
— パトローニ。

MySQL ガレラ

MySQL Galera テクノロジーは Codership によって開発され、InnoDB のプラグインです。 特徴:

• マルチマスター。
• 同期レプリケーション。
• 任意のノードからの読み取り。
• 任意のノードに記録します。
• 組み込みの HA メカニズム。
• Bitnami の Helm チャートがあります。

ゴキブリDB

説明によると、これはまさに爆弾であり、Go で書かれたオープンソース プロジェクトです。 主な参加者は Cockroach Labs (Google 出身者によって設立) です。 このリレーショナル DBMS は、もともと分散型 (すぐに使える水平スケーリング) とフォールト トレラントを目的として設計されました。 同社の作成者は、「SQL 機能の豊富さと、NoSQL ソリューションでおなじみの水平方向のアクセシビリティを組み合わせる」という目標を概説しました。

素晴らしいボーナスは、post-gress 接続プロトコルのサポートです。

pgプール

これは PostgreSQL へのアドオンであり、実際にはすべての接続を引き継いで処理する新しいエンティティです。 BSD ライセンスに基づいてライセンスされた独自のロード バランサーとパーサーを備えています。 それは十分な機会を提供しますが、新しい存在の存在が追加の冒険の源になる可能性があるため、やや恐ろしいように見えます。

パトローニ

これは私が最後に目を留めたものでしたが、結果的には無駄ではありませんでした。 Patroni はオープン ソース ユーティリティであり、本質的には Python デーモンであり、さまざまな種類のレプリケーションと自動ロール切り替えを使用して PostgreSQL クラスターを自動的に保守できるようになります。 これは cuber とうまく統合されており、新しいエンティティを導入しないため、非常に興味深いことがわかりました。

あなたは最終的に何を選びましたか？

選択は簡単ではありませんでした。

1. ゴキブリDB - 火だが暗い。
2. MySQL ガレラ - これも悪くありません。多くの場所で使用されていますが、MySQL;
3. pgプール — 多くの不要なエンティティ、クラウドと K8 との統合はまあまあ。
4. パトローニ - K8 との優れた統合。不要なエンティティがなく、GCP LB とうまく統合されます。

したがって、選択はパトローニに委ねられました。

所見

簡単にまとめてみましょう。 はい、IT インフラストラクチャの世界は大きく変化しましたが、これはほんの始まりにすぎません。 そして、以前はクラウドが単なるインフラストラクチャの一種であったとしても、今ではすべてが異なります。 さらに、クラウドにおけるイノベーションは絶えず出現しており、今後も出現しますが、おそらくクラウド上でのみ出現し、スタートアップの努力によって初めてオンプレミスに移行されることになります。

SQL に関しては、SQL は生きます。 これは、PostgreSQL と MySQL について理解し、それらを操作できる必要があることを意味しますが、さらに重要なのは、それらを正しく使用できることです。

出所： habr.com