データベースは Kubernetes 内に存在しますか?

どういうわけか、歴史的に IT 業界は、何らかの理由で「賛成」派と「反対」派の XNUMX つの条件付き陣営に分かれてきました。 さらに、紛争の主題は完全に任意である可能性があります。 Win と Linux ではどちらの OS が優れていますか? Android または iOS スマートフォンを使用していますか? すべてをクラウドに保存するべきですか、それともコールド RAID ストレージにアップロードしてネジを金庫に保管するべきですか? PHPの人にはプログラマーと呼ばれる権利があるのでしょうか？ これらの論争は、場合によっては専ら実存的な性質のものであり、スポーツ上の利益以外の根拠はありません。

偶然にも、コンテナーと、docker と条件付き k8 を使用したこのすべての人気料理の出現により、バックエンドのさまざまな領域で新しい機能の使用に「賛成」と「反対」の議論が始まりました。 (事前に予約しておきますが、この議論では Kubernetes がオーケストレーターとして示されることがほとんどですが、この特定のツールの選択は基本的に重要ではありません。代わりに、最も便利で使い慣れていると思われる他のツールで置き換えることができます。 。）

そして、これはコインの表裏間の単純な論争になるように思われるでしょう。 Win 対 Linux の永遠の対立と同じくらい愚かで無慈悲ですが、その中間には適切な人材が存在します。 しかし、コンテナ化の場合、すべてがそれほど単純であるわけではありません。 通常、このような論争にはどちらが正しいということはありませんが、データベースを格納するコンテナを「使用する」または「使用しない」の場合は、すべてがひっくり返ります。 なぜなら、このアプローチの支持者も反対者も、ある意味では正しいからです。

明るい面

ライトサイドの主張は一言で簡潔に説明できます：「こんにちは、2k19は窓の外です！」 もちろんポピュリズムのように聞こえますが、状況を詳しく掘り下げてみると、利点もあります。 では、それらを整理してみましょう。

大規模な Web プロジェクトがあるとします。 最初はマイクロサービス アプローチに基づいて構築された可能性もあれば、ある時点で進化の過程を経てマイクロサービス アプローチに到達した可能性もありますが、これは実際にはそれほど重要ではありません。 私たちのプロジェクトを個別のマイクロサービスに分散し、オーケストレーション、負荷分散、およびスケーリングをセットアップしました。 そして今、あなたは明確な良心を持って、ハブラ効果の間、倒れたサーバーを引き上げるのではなく、ハンモックでモヒートを飲みます。 しかし、すべての行動において一貫性を保たなければなりません。 多くの場合、アプリケーション自体 (コード) のみがコンテナ化されます。 コード以外に何があるでしょうか?

そうです、データです。 あらゆるプロジェクトの中心となるのはデータです。これは、典型的な DBMS (MySQL、Postgre、MongoDB)、または検索に使用されるストレージ (ElasticSearch)、キャッシュ用のキーと値のストレージ (たとえば、redis など) のいずれかになります。ここでは、不適切に作成されたクエリが原因でデータベースがクラッシュした場合の、不正なバックエンド実装オプションについて説明します。代わりに、クライアントの負荷がかかっているまさにこのデータベースのフォールト トレランスを確保することについて説明します。 結局のところ、アプリケーションをコンテナ化し、任意の数の受信リクエストを処理できるように自由に拡張できるようにすると、当然データベースの負荷が増加します。

実際、データベースにアクセスするためのチャネルとそれが実行されるサーバーが、美しいコンテナ化されたバックエンドの中心となります。 同時に、コンテナ仮想化の主な目的は、構造の可動性と柔軟性であり、これにより、利用可能なインフラストラクチャ全体にわたるピーク負荷の分散を可能な限り効率的に組織化できます。 つまり、システムの既存の要素をすべてコンテナ化してクラスター全体にロールアウトしない場合、非常に重大な間違いを犯すことになります。

アプリケーション自体だけでなく、データの保存を担当するサービスもクラスター化する方がはるかに論理的です。 k8s では、独立して動作し相互に負荷を分散する Web サーバーをクラスタリングして展開することで、データの同期の問題、つまりメディアやブログ プラットフォームを例にとると、投稿に対する同じコメントの問題がすでに解決されています。 いずれの場合も、クラスター内 (仮想であっても) にデータベースを ExternalService として表現します。 問題は、データベース自体がまだクラスタ化されていないことです。キューブ内に展開された Web サーバーは、個別にローテーションする静的な戦闘データベースから変更に関する情報を取得します。

引っかかりを感じますか？ k8s または Swarm を使用して負荷を分散し、メイン Web サーバーのクラッシュを回避しますが、データベースに対してはこれを行いません。 しかし、データベースがクラッシュした場合、クラスター化されたインフラストラクチャ全体が無意味になります。データベース アクセス エラーを返す空の Web ページに何の意味があるでしょうか。

そのため、通常行われているように Web サーバーだけでなく、データベース インフラストラクチャもクラスタ化する必要があります。 この方法によってのみ、XNUMX つのチーム内で完全に機能し、同時に相互に独立した構造を確保することができます。 さらに、負荷によりバックエンドの半分が「崩壊」したとしても、残りは存続し、クラスター内でデータベースを相互に同期するシステムと、新しいクラスターを無限に拡張およびデプロイする機能により、必要な容量に迅速に到達することができます。 - データセンターにラックがあれば。

さらに、クラスターに分散されたデータベース モデルを使用すると、このデータベースそのものを必要な場所に移動できます。 グローバル サービスについて話している場合、サンフランシスコ地域のどこかで Web クラスターを起動し、同時にモスクワ地域のデータベースにアクセスするときにパケットを送信して戻すのはまったく非論理的です。

また、データベースのコンテナ化により、システムのすべての要素を同じ抽象化レベルで構築できます。 これにより、管理者の積極的な関与なしに、開発者がコードから直接このシステムを管理できるようになります。 開発者は、新しいサブプロジェクトには別の DBMS が必要であると考えましたが、それは簡単でした。 yaml ファイルを作成し、クラスターにアップロードすれば完了です。

もちろん、内部操作も大幅に簡素化されています。 教えてください、新しいチームメンバーが仕事のために戦闘データベースに手を入れたとき、何度目を閉じたことがありますか? 実際のところ、あなたが持っていて現在回転しているのはどれだけですか? もちろん、ここにいる私たちは全員大人であり、どこかに新しいバックアップがあり、さらに離れたところには、おばあちゃんのキュウリや古いスキー板が置かれた棚の後ろに、別のバックアップがあり、おそらく冷蔵倉庫にもあります。オフィスはすでに一度火災に見舞われているためです。 しかしそれでも、戦闘インフラストラクチャ、そしてもちろん戦闘データベースにアクセスできる新しいチーム メンバーが登場するたびに、周囲の全員にとってはバケツのような有効性が得られます。 そうですね、初心者の彼を誰が知っていますか? 彼はクロスハンドかもしれません? 恐ろしいですね、あなたも同意するでしょう。

コンテナ化、そして実際には、プロジェクトのデータベースの分散物理トポロジは、このような検証の瞬間を回避するのに役立ちます。 初心者を信用しないのですか？ わかりました！ 彼に作業用の独自のクラスターを与え、データベースを他のクラスターから切断しましょう。同期は、手動プッシュと XNUMX つのキー (XNUMX つはチーム リーダー用、もう XNUMX つは管理者用) の同期ローテーションによってのみ行われます。 そして誰もが幸せです。

そして今、データベース クラスタリングの反対者に変わる時が来ました。

暗黒面

データベースをコンテナ化して XNUMX つの中央サーバーで実行し続けることがなぜ価値がないのかを議論する際、私たちは、「祖父たちはハードウェアでデータベースを実行していたので、私たちもそうします!」のような正統派のレトリックやステートメントに屈するつもりはありません。 代わりに、コンテナ化が実際に目に見える利益をもたらす状況を考え出してみましょう。

同意します。実際にコンテナ内のベースが必要なプロジェクトは、優れたフライス盤オペレーターでなくても片手の指で数えられるほどです。 ほとんどの場合、k8s や Docker Swarm の使用自体は冗長です。これらのツールは、テクノロジーの一般的な誇大宣伝と、すべてを社会に押し込もうとする男女の「全能者」の態度のために頼られることがよくあります。雲とコンテナ。 まあ、今はそれが流行っていて誰もがやっているからです。

少なくとも半分のケースでは、プロジェクトで Kubernetis または Docker のみを使用することは冗長です。 問題は、クライアントのインフラストラクチャを維持するために雇用されたすべてのチームやアウトソーシング会社がこのことを認識しているわけではないことです。 コンテナーが課されると、クライアントに一定量のコインがかかるため、状況はさらに悪くなります。

一般に、ドッカー/キューブマフィアが、これらのインフラストラクチャ問題をアウトソーシングしているクライアントを愚かにも潰しているという意見があります。 結局のところ、クラスターを操作するには、これが可能で、実装されたソリューションのアーキテクチャを一般的に理解しているエンジニアが必要です。 私たちはかつて、Republic の出版物で私たちの事例を説明しました。そこで私たちは、クライアントのチームが Kubernetis の現実で作業できるようにトレーニングしました。そして全員が満足していました。 そしてそれはまともだった。 多くの場合、k8 の「実装者」はクライアントのインフラストラクチャを人質に取っています。なぜなら、そこですべてがどのように機能するかを理解しているのは彼らだけであり、クライアント側には専門家がいないからです。

このようにして、Web サーバー部分だけでなく、データベースのメンテナンスもアウトソーシングすると想像してください。 BD は心臓であり、心臓の喪失はあらゆる生物にとって致命的であると言いました。 要するに、見通しは最良ではないということだ。 したがって、多くのプロジェクトは、Kubernetis を誇大宣伝するのではなく、AWS の通常の料金を気にする必要はありません。これにより、サイト/プロジェクトの負荷に関するすべての問題が解決されます。 しかし、AWS はもはやファッショナブルではなく、誇示はお金以上の価値があります。残念なことに、IT 環境でも同様です。

わかりました。 おそらくプロジェクトには本当にクラスタリングが必要ですが、ステートレス アプリケーションですべてが明確である場合、クラスタ化されたデータベースに対して適切なネットワーク接続をどのように構成できるでしょうか?

シームレスなエンジニアリング ソリューション (k8s への移行とは何ですか) について話している場合、主な悩みはクラスター化されたデータベースでのデータ レプリケーションです。 一部の DBMS は、最初は個々のインスタンス間のデータの分散に非常に忠実です。 他の多くの人はそれほど歓迎的ではありません。 そして、多くの場合、プロジェクトに DBMS を選択する際の主な議論は、リソースとエンジニアリングのコストを最小限に抑えて複製できるかどうかではありません。 特に、プロジェクトが当初マイクロサービスとして計画されていたのではなく、単にこの方向に進化しただけの場合は特にそうです。

ネットワーク ドライブの速度について話す必要はないと考えています。ネットワーク ドライブは遅いのです。 それらの。 何かが起こった場合、プロセッサ能力や空き RAM など、より余裕のある場所で DBMS インスタンスを再起動する実際の機会はまだありません。 仮想化ディスク サブシステムのパフォーマンスはすぐにわかります。 したがって、DBMS は、近接して配置された独自のマシンのセットに固定する必要があります。 あるいは、想定される予備量に対して十分に高速なデータ同期を何らかの方法で個別に冷却する必要があります。

仮想ファイル システムの話題の続きです。残念ながら、Docker ボリュームには問題がありません。 一般に、長期にわたって信頼性の高いデータ保存などの場合には、技術的に最も単純な方式で済ませたいと考えています。 また、コンテナの FS から親ホストの FS に新しい抽象化レイヤーを追加すること自体がリスクです。 しかし、コンテナ化サポート システムの運用でも、これらのレイヤー間のデータ送信で問題が発生した場合、それは本当に大惨事になります。 現時点では、進歩的な人類に知られている問題のほとんどは根絶されたようです。 しかし、ご存知のように、機構が複雑になればなるほど、壊れやすくなります。

これらすべての「冒険」を考慮すると、データベースを XNUMX か所に保持する方がはるかに収益性が高く、簡単です。また、アプリケーションをコンテナ化する必要がある場合でも、アプリケーションを単独で実行し、ディストリビューション ゲートウェイを介して、アプリケーションとの同時通信を受信できるようにします。データベースは、XNUMX か所で XNUMX 回だけ読み書きされます。 このアプローチにより、エラーと非同期の可能性が最小限に抑えられます。

私たちは何を導いているのでしょうか？ さらに、データベースのコンテナ化は、実際に必要な場合に適しています。 フルアプリのデータベースを詰め込んで、あたかも XNUMX 個のマイクロサービスがあるかのように回転させることはできません。そのようには機能しません。 そして、これは明確に理解されなければなりません。

出力の代わりに

「データベースを仮想化するか否か」という明確な結論を待っているのであれば、がっかりするでしょう。それはここにはありません。 なぜなら、インフラストラクチャ ソリューションを作成するときは、流行や進歩ではなく、まず常識に従う必要があるからです。

Kubernetis に付属する原則とツールが完全に適合するプロジェクトがあり、そのようなプロジェクトでは少なくともバックエンド領域では平和が保たれます。 また、コンテナ化を必要とせず、通常のサーバー インフラストラクチャを必要とするプロジェクトもあります。これは、基本的にマイクロサービス クラスター モデルに再スケールできず、失敗するためです。

出所： habr.com