Postgres Tuesday No. 5: 「PostgreSQL と Kubernetes。 CI/CD。 テスト自動化」

昨年末、ロシアの PostgreSQL コミュニティの別のライブ ブロードキャストが行われました。 #RuPostgresその中で、共同創設者のニコライ・サモクバロフ氏は、Flant テクニカル ディレクターのドミトリー・ストリャロフ氏と、Kubernetes のコンテキストにおけるこの DBMS について話しました。

私たちはこのディスカッションの主要部分のトランスクリプトを公開しています。 コミュニティ YouTube チャンネル 投稿された完全なビデオ:

データベースとKubernetes

NA: 今日は VACUUM と CHECKPOINT については話しません。 Kubernetes について話したいと思います。 あなたには長年の経験があると思います。 私はあなたのビデオを視聴し、一部を再視聴しました...早速本題に入りましょう。そもそも、なぜ Postgres や MySQL を K8s に使用するのでしょうか?

DS: この質問に対する明確な答えはありませんし、答えられません。 しかし、一般的に、これはシンプルさと便利さです...可能性があります。 誰もがマネージド サービスを望んでいます。

NA：どうやって RDS、家だけ？

DS: はい: RDS のように、どこでも。

NA：「どこでも」というのは良いですね。 大企業では、すべてが異なる場所にあります。 では、大企業であれば、なぜ既製のソリューションを採用しないのでしょうか? たとえば、Nutanix は独自の開発を行っており、他の企業 (VMware など) も同じ「RDS、自宅専用」を持っています。

DS: しかし、私たちは特定の条件下でのみ機能する別の実装について話しています。 そして、Kubernetes について話している場合、非常に多様なインフラストラクチャ (K8 に含まれる場合もあります) が存在します。 基本的に、これはクラウドへの API の標準です...

NA：それも無料です！

DS：それはそれほど重要ではありません。 自由度は、市場のそれほど大きなセグメントではないにとって重要です。 他に重要なことがある...おそらくレポートを覚えているでしょう。」データベースとKubernetes"？

NAはい。

DS：非常に曖昧に受け取られていることに気づきました。 私が「皆さん、すべてのデータベースを Kubernetes に入れましょう!」と言っていると思った人もいれば、これらはすべてひどい自転車だと判断した人もいます。 しかし、私はまったく別のことを言いたかったのです。「何が起こっているのか、どんな問題があるのか​​、そしてそれらはどのように解決できるのかを見てください。 今すぐ Kubernetes データベースを使用する必要がありますか? 生産？ まあ、あなたが好きな場合にのみ...特定のことをしてください。 しかし、開発者としては、これをお勧めすると言えます。 開発者にとって、環境の作成/削除のダイナミズムは非常に重要です。」

NS: 開発とは、本番環境ではないすべての環境を意味しますか? ステージング、QA…

DS: パフォーマンス スタンドについて話しているのであれば、おそらくそうではありません。要件が特殊だからです。 ステージングに非常に大規模なデータベースが必要な特殊なケースについて話しているのであれば、おそらくそうではありません...これが静的で長期間存続する環境である場合、データベースを K8s に配置する利点は何でしょうか?

NA： なし。 しかし、静的環境はどこにあるのでしょうか? 静的環境は明日には廃止されます。

DS: ステージングは​​静的に行うことができます。 私たちには顧客がいます...

NA：はい、私も持っています。 10 TB のデータベースと 200 GB のステージングがある場合、これは大きな問題です。

DS: とても素敵なケースがあります! ステージングでは、変更が加えられる製品データベースがあります。 そして、「本番環境にロールアウト」というボタンがあります。 これらの変更 (デルタ) は実稼働環境に追加されます (API 経由で同期されているだけのようです)。 これは非常にエキゾチックなオプションです。

NA: 私はバレーで、RDS や Heroku を使用しているスタートアップ企業を見たことがあります。これらは 2 ～ 3 年前の話です。彼らはダンプをラップトップにダウンロードしています。 データベースはまだ 80 GB しかなく、ラップトップにはスペースがあるためです。 次に、全員に追加のディスクを購入して、さまざまな開発を実行するための 3 つのデータベースを用意します。 こんなことも起こります。 また、彼らは本番環境をステージングにコピーすることを恐れていないこともわかりました。それは会社次第です。 しかし、私はまた、彼らが非常に怖がっており、十分な時間と人手を持っていないことが多いことも見ました。 このトピックに進む前に、Kubernetes について聞きたいと思います。 まだ誰も本番環境にいないということを正しく理解していますか?

DS: 本番環境には小規模なデータベースがあります。 ここで話しているのは、数十ギガバイトのボリュームと、レプリカを作成するのが面倒だった (そしてそのような必要はない) 非クリティカルなサービスについてです。 Kubernetes の下に通常のストレージがあることが前提です。 このデータベースは、条件付きでストレージ システム上の VMware 内の仮想マシンで動作しました。 私たちはそれを置きました PV これで、マシンからマシンへ転送できるようになりました。

NA: このサイズ (最大 100 GB) のデータベースは、適切なディスクと適切なネットワークがあれば、数分で展開できますよね。 1 秒あたり XNUMX GB の速度は、もはや珍しいことではありません。

DS: はい、線形動作の場合、これは問題ありません。

NA: さて、あとは本番のことを考えればいいだけです。 また、非本番環境で Kubernetes を検討している場合は、どうすればよいでしょうか? ザランドにもそれが見える do 演算子、クランチーで のこぎり、他にもいくつかのオプションがあります。 そこには オングレス - これはスペイン出身の私たちの良き友人、アルバロです。彼らのやっていることは本質的に単なるものではありません。 オペレータ、および分布全体 (スタックグレ)、Postgres 自体に加えて、バックアップ、Envoy プロキシも詰め込むことにしました...

DS：何のための特使？ 特にPostgresトラフィックのバランスをとるには？

NA： はい。 つまり、Linux ディストリビューションとカーネルを使用する場合、通常の PostgreSQL がカーネルとなり、クラウドに適した Kubernetes 上で実行されるディストリビューションを作成したいと考えています。 コンポーネント (バックアップなど) をまとめて、それらが正常に動作するようにデバッグします。

DS： とてもかっこいい！ 基本的に、これは独自のマネージド Postgres を作成するためのソフトウェアです。

NA: Linux ディストリビューションには、すべてのハードウェアがサポートされるようにドライバーを作成する方法という永遠の課題があります。 そして彼らは、Kubernetes で動作するという考えを持っています。 最近、Zalando オペレーターで AWS への接続が確認されましたが、これはあまり良好ではなくなりました。 特定のインフラストラクチャとの結びつきがあってはなりませんが、それでは一体何の意味があるのでしょうか?

DS: Zalando がどのような状況に陥ったのか正確にはわかりませんが、Kubernetes ではストレージが一般的な方法でディスク バックアップを取得できないように作られています。 最近標準版 - 最新バージョンに CSI仕様 — スナップショットを可能にしましたが、それはどこに実装されていますか? 正直なところ、すべてがまだ未熟です...私たちは AWS、GCE、Azure、vSphere の上で CSI を試していますが、使い始めるとすぐに、まだ準備ができていないことがわかります。

NA：だからこそインフラに頼らなければいけないこともあります。 これはまだ初期段階、つまり成長痛だと思います。 質問: K8s で PgSQL を試してみたい初心者にアドバイスをお願いします。 どのオペレーターでしょうか？

DS: 問題は、Postgres が私たちにとって 3% であることです。 Kubernetes にはさまざまなソフトウェアの膨大なリストもありますが、すべてをリストすることはできません。 たとえば、エラスティックサーチ。 多くの演算子があり、積極的に開発を行っている演算子もあれば、そうでない演算子もあります。 私たちは、このことに真剣に取り組むためにオペレーターが持つべきものについて、独自の要件を作成しました。 Kubernetes 専用のオペレーター - 「Amazon の条件で何かを行うオペレーター」ではありません...実際、私たちは非常に広範囲 (= ほぼすべてのクライアント) で単一のオペレーターを使用しています - Redis用 (近々彼についての記事を公開する予定です).

NA: MySQL もだめですか? Percona は、現在 MySQL、MongoDB、Postgres に取り組んでいるため、すべてのデータベース、すべてのクラウド プロバイダー向けに、ある種のユニバーサル ソリューションを作成する必要があることはわかっています。

DS: MySQL の演算子を調べる時間がありませんでした。 これは現時点では私たちの主な焦点ではありません。 MySQL はスタンドアロンで正常に動作します。 データベースを起動できるだけなら、なぜオペレーターを使用する必要があるのでしょうか... Postrges を使用して Docker コンテナを起動することも、簡単な方法で起動することもできます。

NA：これについても質問がありました。 オペレーターがいないのですか？

DS: はい、私たちの 100% はオペレーターなしで PostgreSQL を実行しています。 ここまではそうだ。 Prometheus と Redis にはオペレーターを積極的に使用しています。 私たちは、Elasticsearch のオペレーターを見つける計画を立てています。これは、100% のケースで Kubernetes にインストールしたいため、最も「注目を集めている」オペレーターです。 MongoDB も常に Kubernetes にインストールされるようにしたいのと同じように。 ここには特定の願いが現れます - このような場合には何かができるという感覚があります。 そして、私たちはPostgresさえ見ていませんでした。 もちろん、さまざまなオプションがあることは承知していますが、実際にはスタンドアロンもあります。

KubernetesでテストするためのDB

NA: テストの話に移りましょう。 DevOps の観点から、データベースへの変更をロールアウトする方法。 マイクロサービスや多くのデータベースがあり、常にどこかで何かが変化しています。 DBMS の観点からすべてが正常であるように、正常な CI/CD を保証する方法。 あなたのアプローチは何ですか？

DS：答えは一つではありません。 いくつかのオプションがあります。 XNUMX つ目は、ロールアウトするベースのサイズです。 あなた自身も、開発環境とステージ環境で製品データベースのコピーを保持することに対する企業の態度が異なると述べました。

NA: そして、GDPR の条件下では、彼らはますます慎重になっていると思います...ヨーロッパではすでに罰金を課し始めていると言えます。

DS: しかし、多くの場合、本番環境からダンプを取得して難読化するソフトウェアを作成できます。 Prod データは取得されますが (スナップショット、ダンプ、バイナリ コピーなど)、匿名化されます。 代わりに、生成スクリプトが存在する場合があります。これらは、フィクスチャである場合もあれば、大規模なデータベースを生成する単なるスクリプトである場合もあります。 問題は、ベースイメージの作成にどれくらい時間がかかるかということです。 また、目的の環境にデプロイするにはどのくらい時間がかかりますか?

私たちは、クライアントが固定データ セット (データベースの最小バージョン) を持っている場合、デフォルトでそれらを使用するというスキームに到達しました。 レビュー環境について話している場合、ブランチを作成したときにアプリケーションのインスタンスをデプロイし、そこに小さなデータベースを展開します。 でもうまくいきました вариант、50 日 XNUMX 回 (夜間) 本番環境からダンプを取得し、それに基づいてロードされたデータを使用して PostgreSQL と MySQL を使用して Docker コンテナーを構築します。 このイメージからデータベースを XNUMX 倍拡張する必要がある場合、これは非常に簡単かつ迅速に実行できます。

NA：単純なコピーで？

DS: データは Docker イメージに直接保存されます。 それらの。 100 GB ではありますが、既製のイメージがあります。 Docker のレイヤーのおかげで、このイメージを必要なだけ素早くデプロイできます。 この方法は愚かですが、うまく機能します。

NA: そうすると、テストすると、Docker 内で変更されますよね。 Docker 内でのコピーオンライト - それを捨てて再度実行すれば、すべて問題ありません。 クラス！ そして、あなたはすでにそれを最大限に活用していますか？

DS： 長い間。

NA：私たちはよく似たようなことをやっています。 ただし、Docker のコピーオンライトを使用せず、他のものを使用します。

DS：それは一般的ではありません。 そして、Docker はどこでも機能します。

NA: 理論的にはそうです。 しかし、そこにはモジュールもあるので、さまざまなモジュールを作成し、さまざまなファイル システムで作業することができます。 ここでなんて瞬間でしょう。 Postgres 側からは、これらすべてを異なる見方で見ます。 Docker 側から見てみると、すべてがうまく機能していることがわかりました。 しかし、データベースが巨大な場合 (たとえば、1 TB)、これには長い時間がかかります。夜間の操作とすべてを Docker に詰め込む必要があります...そして、5 TB を Docker に詰め込んだ場合...それともすべて問題ありませんか?

DS: 違いは何ですか: これらは BLOB であり、単なるビットとバイトです。

NA: 違いは次のとおりです: ダンプと復元を通じて実行しますか?

DS：全く必要ありません。 このイメージを生成する方法は異なる場合があります。

NA: 一部のクライアントに対しては、基本イメージを定期的に生成する代わりに、常に最新の状態に保つようにしました。 これは本質的にはレプリカですが、マスターから直接データを受け取るのではなく、アーカイブを通じてデータを受け取ります。 WAL が毎日ダウンロードされ、バックアップが作成されるバイナリ アーカイブ...これらの WAL は、わずかな遅延 (文字通り 1 ～ 2 秒) を伴ってベース イメージに到達します。 何らかの方法でそこからクローンを作成します。現在はデフォルトで ZFS を使用しています。

DS: ただし、ZFS ではノードが XNUMX つに制限されます。

NA： はい。 しかし、ZFS には魔法のような機能もあります。 送信: これを使用すると、スナップショットを送信したり、(まだ実際にはテストしていませんが...) XNUMX つの間のデルタを送信したりすることもできます。 PGDATA。 実際、このようなタスクについては、あまり考慮していなかった別のツールがあります。 PostgreSQL には pg_rewindこれは「スマートな」rsync のように機能し、何も変わっていないため、見る必要のないものの多くをスキップします。 XNUMX つのサーバー間で迅速な同期を実行し、同じ方法で巻き戻すことができます。

そこで、より DBA 側から、あなたが言ったのと同じことを実行できるツールを作成しようとしています。データベースは 50 つありますが、何かを XNUMX 回、ほぼ同時にテストしたいと考えています。

DS: 50 回とは、50 個のスポット インスタンスを注文する必要があることを意味します。

NA: いいえ、すべてを XNUMX 台のマシン上で行います。

DS: しかし、この 50 つのデータベースがたとえばテラバイトの場合、どうやって 256 倍に拡張するのでしょうか。 おそらく条件付きで XNUMX GB の RAM が必要なのでしょうか?

NA: はい、大量のメモリが必要になることがありますが、これは正常です。 しかし、これは人生の一例です。 実稼働マシンには 96 コアと 600 GB があります。 同時に、データベースには 32 コア (現在は 16 コアの場合もあります) と 100 ～ 120 GB のメモリが使用されます。

DS：それで50部も入るんですか？

NA: つまり、コピーが XNUMX つしかない場合、コピーオンライト (ZFS) が機能します...詳しく説明します。

たとえば、10 TB のデータベースがあります。 彼らはそのためにディスクを作成し、ZFS はそのサイズも 30 ～ 40 パーセント圧縮しました。 私たちは負荷テストを行っていないため、正確な応答時間は重要ではありません。最大 2 倍遅くなっても問題ありません。

プログラマー、QA、DBA などに機会を与えます。 1 ～ 2 スレッドでテストを実行します。 たとえば、ある種の移行を実行する場合があります。 一度に 10 コアは必要ありません。1 つの Postgres バックエンド、1 つのコアが必要です。 移行が開始されます - おそらく 自動バキューム それでも起動する場合は、16 番目のコアが使用されます。 32 ～ 10 コアが割り当てられているため、XNUMX 人が同時に作業しても問題ありません。

なぜなら物理的に PGDATA 同様に、実際には Postgres を騙していることがわかります。 コツは次のとおりです。たとえば、10 個の Postgres が同時に起動されます。 通常、問題は何ですか? 彼らは置く 共有バッファ、25%としましょう。 したがって、これは 200 GB です。 メモリが不足するため、これらを XNUMX つ以上起動することはできません。

しかし、ある時点でこれは必要ではないことに気づき、shared_buffers を 2 GB に設定しました。 PostgreSQL には 効果的なキャッシュサイズそして実際に影響を与えるのはそれだけです 予定。 0,5TBに設定しました。 そして、それらが実際に存在しないことさえ問題ではありません。彼は、それらが存在するかのように計画を立てます。

したがって、ある種の移行をテストするときに、すべての計画を収集することができ、本番環境でそれがどのように起こるかを確認できます。 秒数は異なります (遅くなります) が、実際に読み取ったデータと計画自体 (どのような JOIN があるかなど) は実稼働環境とまったく同じであることがわかります。 そして、このようなチェックを XNUMX 台のマシン上で並行して多数実行できます。

DS: ここにはいくつか問題があると思いませんか? XNUMX つ目は、PostgreSQL でのみ動作するソリューションです。 このアプローチは非常にプライベートなものであり、一般的なものではありません。 XNUMX つ目は、Kubernetes (およびクラウド テクノロジが現在導入しようとしているすべてのもの) には多くのノードが含まれており、これらのノードは一時的なものであるということです。 そしてあなたの場合、それはステートフルで永続的なノードです。 これらのことが私に矛盾を生じさせます。

NA: まず、これは純粋に Postgres の話であることに同意します。 何らかの直接 IO とほぼすべてのメモリにバッファ プールがある場合、このアプローチは機能しないと思います。計画は異なるものになるでしょう。 しかし今のところ、私たちは Postgres だけを使って作業しており、他のことは考えていません。

Kubernetes について。 あなた自身が、私たちが永続的なデータベースを持っていることをどこでも私たちに話しています。 インスタンスが失敗した場合、主なことはディスクを保存することです。 ここでもプラットフォーム全体が Kubernetes にあり、Postgres のコンポーネントは分離されています (ただし、いつかはそこに存在するでしょう)。 したがって、すべては次のようになります。インスタンスは落ちましたが、その PV を保存し、何も起こらなかったかのように、単に別の (新しい) インスタンスに接続しました。

DS: 私の観点からすると、ポッドは Kubernetes で作成されます。 K8s - 伸縮性: ノットは必要に応じて注文されます。 タスクは単にポッドを作成し、X 量のリソースが必要であることを通知することです。その後、K8s がそれを独自に計算します。 ただし、Kubernetes でのストレージのサポートはまだ不安定です。 1.16で 1.17 (このリリースはリリースされました недели 前）これらの機能はベータ版のみになります。

半年から XNUMX 年が経過すると、多かれ少なかれ安定するか、少なくともそのように宣言されるでしょう。 次に、スナップショットとサイズ変更の可能性により、問題が完全に解決されます。 拠点があるからね。 はい、それほど高速ではないかもしれませんが、一部の実装ではディスク サブシステム レベルでコピーとコピーオンライトができるため、速度は「内部」に依存します。

NA: すべてのエンジン (Amazon、Google など) がこのバージョンのサポートを開始する必要もあります。これにも時間がかかります。

DS：まだ使っていません。 私たちは私たちのものを使用しています。

Kubernetes のローカル開発

NA: すべてのポッドを XNUMX 台のマシンにインストールして、そのような小規模なテストを実行する必要があるとき、そのような願望に遭遇したことがありますか。 概念実証をすぐに行うには、専用の多数のマシンを用意せずに、アプリケーションが Kubernetes で実行されることを確認してください。 ミニクベってあるじゃないですか。

DS: このケース (XNUMX つのノードにデプロイ) はもっぱらローカル開発に関するものであるように思えます。 あるいは、そのようなパターンのいくつかの兆候。 食べる Minikubeそこに k3s, 種類。 私たちは、Kubernetes IN Docker の使用に向けて取り組んでいます。 今、私たちはテストのためにそれを使い始めました。

NA: これはすべてのポッドを XNUMX つの Docker イメージにラップする試みだと思っていました。 しかし、これはまったく異なるものであることが判明しました。 とにかく、Docker 内に個別のコンテナ、個別のポッドがあります。

DS： はい。 そして、かなり面白い模造品が作られていますが、意味は次のとおりです...展開用のユーティリティがあります - ワーフ。 条件付きモードにしたい werf up: 「ローカルの Kubernetes を取得してください。」 そして、そこで条件を実行します werf follow。 その後、開発者は IDE を編集できるようになり、変更を確認してイメージを再構築し、ローカルの K8 に再デプロイするプロセスがシステム内で起動されます。 私たちはこのようにして地域発展の問題を解決していきたいと考えています。

K8s Reality でのスナップショットとデータベースのクローン作成

NA：コピーオンライトに戻った場合。 雲にもスナップショットがあることに気づきました。 それらは動作が異なります。 たとえば、GCP では、米国の東海岸に数テラバイトのインスタンスがあります。 定期的にスナップショットを取得します。 西海岸にあるディスクのコピーをスナップショットから取得します。数分ですべての準備が整い、非常に迅速に動作し、メモリにキャッシュを書き込むだけで済みます。 ただし、これらのクローン (スナップショット) は、新しいボリュームを「プロビジョニング」するためのものです。 これは、多数のインスタンスを作成する必要がある場合に便利です。

しかし、テストの場合は、スナップショット (あなたが Docker について話している、または私が ZFS、btrfs、さらには LVM について話している...) を使用すると、XNUMX 台のマシン上で実際に新しいデータを作成しなくても済むようになります。 クラウドでは、料金を毎回支払うことになり、数秒ではなく数分待つことになります (そして、 遅延ロード、おそらく時計）。

代わりに、このデータを XNUMX ～ XNUMX 秒で取得し、テストを実行して破棄することができます。 これらのスナップショットはさまざまな問題を解決します。 最初のケースではスケールアップして新しいレプリカを取得するため、XNUMX 番目のケースではテスト用です。

DS：同意しません。 ボリュームのクローン作成を適切に機能させるのはクラウドのタスクです。 実装については見ていませんが、ハードウェア上でどのように実行するかは知っています。 Ceph があり、あらゆる物理ボリュームを許可します (RBD） 言う 同じ特性を持つ XNUMX 番目のボリュームを数十ミリ秒で取得します。 IOPS「アミなど」 内部にはトリッキーなコピーオンライトがあることを理解する必要があります。 なぜクラウドでも同じことをすべきではないのでしょうか? 彼らは何らかの方法でこれをやろうとしていると確信しています。

NA: しかし、インスタンスを起動したり、そこに Docker を導入したりするには、やはり数秒、数十秒かかります。

DS: インスタンス全体を起動する必要があるのはなぜですか? 32 個のコア (16 個) を持つインスタンスがあり、たとえば XNUMX 個のコアに適合します。 XNUMX 番目のものを注文すると、インスタンスはすでに起動されており、その後削除されます。

NA: はい、興味深いですね、Kubernetes は別の話であることが判明しました。 私たちのデータベースは K8s にはなく、インスタンスは XNUMX つあります。 ただし、数テラバイトのデータベースのクローン作成には XNUMX 秒もかかりません。

DS： これは素晴らしい。 しかし、私が最初に言いたいのは、これは一般的な解決策ではないということです。 はい、それは素晴らしいですが、Postgres にのみ適しており、XNUMX つのノードにのみ適しています。

NA: これは Postgres にだけ適しているわけではありません。前述したように、これらのプランは Postgres でのみ機能します。 ただし、計画を気にせず、機能テスト用にすべてのデータが必要なだけであれば、これはどの DBMS にも適しています。

DS: 何年も前に、LVM スナップショットで同様のことを行いました。 これは古典的です。 このアプローチは非常に積極的に使用されました。 ステートフル ノードは面倒なだけです。 落としてはいけないので、常に覚えておく必要があります...

NA：ここでハイブリッドの可能性はあると思いますか？ ステートフルはある種のポッドであり、複数の人 (多くのテスター) に対して機能するとします。 ボリュームは XNUMX つありますが、ファイル システムのおかげで、クローンはローカルにあります。 ポッドが落ちてもディスクが残っている場合、ポッドは立ち上がり、すべてのクローンに関する情報を数え、すべてを再び取得して、「これらのポートでクローンが実行されています。引き続き作業を続けてください。」と言います。

DS: 技術的には、これは Kubernetes 内で多数の Postgres を実行する XNUMX つのポッドであることを意味します。

NA： はい。 彼には制限があります。たとえば、同時に一緒に作業できるのは 10 人までだとします。 20 個必要な場合は、10 番目のポッドを起動します。 XNUMX 番目のフル ボリュームを受け取った後、それを完全にクローンします。同じ XNUMX 個の「シン」クローンが含まれます。 この機会を見てみませんか？

DS: ここにセキュリティの問題を追加する必要があります。 このタイプの組織は、このポッドがファイル システム上で非標準の操作を実行できるため、高い特権 (機能) を持っていることを意味します... しかし、繰り返しますが、中期的には Kubernetes のストレージが修正されると信じています。雲、彼らは物語全体をボリュームで修正します - すべてが「うまくいく」でしょう。 サイズ変更、クローン作成などが行われます... ボリュームがあります。「それに基づいて新しいボリュームを作成してください」と言うと、XNUMX 秒半後に必要なものが得られます。

NA: 何テラバイトも 2 秒半なんて信じられません。 Ceph では自分でやりますが、クラウドについて話します。 クラウドに移動し、ECXNUMX 上にマルチテラバイトの EBS ボリュームのクローンを作成し、パフォーマンスがどのようになるかを確認します。 数秒もかかりません。 彼らがいつこのレベルに到達するのか非常に興味があります。 あなたの言っていることは理解できますが、私は違うと思います。

DS：わかりましたが、短期ではなく中期と言いました。 数年間。

Zalando の PostgreSQL 用オペレーターについて

このミーティングの途中で、Zalando の元開発者である Alexey Klyukin 氏も参加し、PostgreSQL オペレーターの歴史について話しました。

Postgres と Kubernetes の両方について、このトピックが一般的に取り上げられていることは素晴らしいことです。 2017年にZalandoでこれをやり始めたとき、誰もがやりたいと思っていたテーマだったのですが、誰もやりませんでした。 誰もがすでに Kubernetes を持っていましたが、データベースをどうするか尋ねると、 ケルシー・ハイタワーK8sを説いた彼はこんなことを言っています。

「マネージド サービスにアクセスして使用してください。Kubernetes でデータベースを実行しないでください。 そうしないと、たとえば、K8 がアップグレードを決定してすべてのノードをオフにし、データがはるか遠くに飛んでしまうことになります。」

私たちは、このアドバイスに反して、Kubernetes で Postgres データベースを起動するオペレーターを作成することにしました。 それには十分な理由がありました - パトローニ。 これは PostgreSQL の自動フェイルオーバーであり、正しく実行されます。 etcd、consul、または ZooKeeper をクラスターに関する情報のストレージとして使用します。 このようなリポジトリは、すべてが分散されているにもかかわらず、たとえば現在のリーダーが誰であるかを尋ねるすべての人に同じ情報を提供するため、スプリットブレインが発生しません。 さらに、私たちは持っていました Dockerイメージ 彼のために。

一般に、企業の自動フェイルオーバーの必要性は、社内のハードウェア データ センターからクラウドに移行した後に現れました。 クラウドは独自の PaaS (Platform-as-a-Service) ソリューションに基づいていました。 オープンソースですが、立ち上げて実行するには多大な労力がかかりました。 それが呼び出されました スタップ.

当初、Kubernetes は存在しませんでした。 より正確に言うと、当社独自のソリューションが導入された時点では、K8 はすでに存在していましたが、あまりにも未加工なので実稼働には適していませんでした。 私の考えでは、それは2015年か2016年でした。 2017 年までに、Kubernetes は多かれ少なかれ成熟しており、そこに移行する必要がありました。

そして、すでに Docker コンテナがありました。 Dockerを使ったPaaSがありました。 K8sを試してみてはいかがでしょうか？ 独自の演算子を作成してみませんか? アヴィトから私たちのところに来たムラト・カビロフは、「遊ぶため」という自らの意志でこれをプロジェクトとして始め、そしてプロジェクトは「軌道に乗った」のです。

しかし、全体として、私は AWS について話したかったのです。 過去に AWS 関連のコードがあったのはなぜですか...

Kubernetes で何かを実行するときは、K8s が進行中の作業であることを理解する必要があります。 それは常に開発、改善されており、時には壊れることさえあります。 Kubernetes のすべての変更を注意深く監視する必要があり、何かが起こった場合にそれに飛び込み、それがどのように機能するかを詳細に学ぶ準備ができている必要があります。おそらく、それはあなたが望んでいる以上のものです。 これは原則として、データベースを実行するすべてのプラットフォームに当てはまります。

したがって、ステートメントを実行したとき、外部ボリューム (この場合は AWS で作業していたので EBS) 上で Postgres を実行していました。 データベースが大きくなり、ある時点でサイズを変更する必要がありました。たとえば、EBS の初期サイズは 100 TB でしたが、データベースもそれに合わせて大きくなったので、今度は EBS を 200 TB にしたいと考えています。 どうやって？ 新しいインスタンスでダンプ/復元を実行できるとしますが、これには長い時間がかかり、ダウンタイムが発生します。

したがって、EBS パーティションを拡大し、ファイル システムに新しい領域を使用するように指示するサイズ変更が必要でした。 そしてそれを実行しましたが、当時の Kubernetes にはサイズ変更操作用の API がありませんでした。 私たちは AWS で作業していたので、その API 用のコードを書きました。

他のプラットフォームでも同じことをするのを誰も止めません。 この記述には、AWS でのみ実行可能であり、他のすべてでは機能しないというヒントはありません。 一般に、これはオープン ソース プロジェクトです。新しい API の使用を促進したいと考えている人は、大歓迎です。 食べる GitHubの、プル リクエスト - Zalando チームはそれらに迅速に対応し、オペレーターを昇格させようとします。 私の知る限り、このプロジェクトは 参加しました Google Summer of Code やその他の同様の取り組みで。 Zalando はこれに非常に積極的に取り組んでいます。

PSボーナス！

PostgreSQL と Kubernetes のトピックに興味がある場合は、次の Postgres Tuesday が先週開催され、そこで私が Nikolai と話をしたことにも注目してください。 ザランドのアレクサンダー・ククシュキン。 そのビデオが利用可能です ここで.

PPS

私たちのブログもお読みください:

• «データベースと Kubernetes (レビューとビデオ レポート)";
• «Cassandra の Kubernetes への移行: 機能とソリューション";
• «MongoDB から Kubernetes へのシームレスな移行";
• «RabbitMQ から Kubernetes へのシームレスな移行'。

出所： habr.com