最新のインフラストラクチャ: 問題と展望

5月末 我々 このテーマに関するオンライン会議を開催した 「現代のインフラストラクチャとコンテナ：問題と展望」。コンテナ、Kubernetes、オーケストレーション全般、インフラストラクチャを選択する基準などについて話し合いました。参加者は自身の実践からの事例を共有しました。

参加者：

• 「ITSumma」CEO、エフゲニー・ポタポフ氏。同社の顧客の半数以上がすでに Kubernetes に移行しているか、移行したいと考えています。
• ドミトリー・ストリアロフ、CTO「Flant」。コンテナ システムでの作業経験が 10 年以上あります。
• Denis Remchukov（別名Eric Oldmann）、argotech.ioのCOO、元RAO UES。彼は「血まみれの」事業における事件について話すと約束した。
• News360.comのCTO、アンドレイ・フェドロフスキー氏同社が別の企業に買収された後、彼は数多くの ML および AI プロジェクトとインフラストラクチャを担当しています。
• Ivan Kruglov、システム エンジニア、元 Booking.com 氏。Kubernetes を自らの手で多くのことを実現した人物です。

トピックス：

• コンテナとオーケストレーション (Docker、Kubernetes など) に関する参加者の洞察。実際に試されたことや分析されたこと。
• 事例: 企業は今後数年間のインフラ開発計画を構築しています。インフラストラクチャをコンテナと Kuber に構築 (または現在のインフラストラクチャを移行) するかどうかは、どのように決定されますか?
• クラウドネイティブの世界の問題点、何が欠けているのか、明日何が起こるのか想像してみましょう。

興味深い議論が続き、参加者の意見は非常に異なっており、非常に多くのコメントが寄せられたので、皆さんと共有したいと思います。食べる 3時間のビデオ以下は議論の要約です。

Kubernetes は標準ですか、それとも優れたマーケティングですか?

「Kubernetes について、まだ誰も知らなかった頃から、私たちはそれを思いつきました。彼がそこにいなかった時でさえ、私たちは彼に相談しました。私たちはもっと前からそれを望んだのです。」 - ドミトリー・ストリアロフ

Reddit.comからの写真

約 5 〜 10 年前は、ツールの数は膨大で、単一の標準はありませんでした。 XNUMX か月ごとに、新しい製品が XNUMX つ、あるいは複数登場しました。最初はVagrant、次にSalt、Chef、Puppet…と、XNUMXヶ月ごとにインフラを再構築する必要がありました。「XNUMX人の管理者が常に設定の書き換えに追われていました」とAndrey Fedorovsky氏は振り返ります。彼は、DockerとKubernetesが他のものを「圧倒した」と考えています。 Docker は過去 5 年間で標準となり、Kubernetes は過去 2 年間で標準となりました。そしてそれは業界にとって良いことです。.

Dmitry Stolyarov 氏と彼のチームは Kuber を気に入っています。彼らは、そのようなツールが存在する前からそれを欲しがっており、まだ誰もそのことを知らなかったときにそれを手に入れました。現時点では、利便性上の理由から、Kubernetes を実装しないことがわかっているクライアントは引き受けません。同時に、ドミトリー氏によれば、同社は「ひどい遺産を作り変える上での数多くの巨大な成功物語」を持っているという。

Kubernetes はコンテナ オーケストレーション システムであるだけでなく、高度な API、ネットワーク コンポーネント、L3 バランシング、Ingress コントローラーを備えた構成管理システムでもあり、インフラストラクチャの下位層からの比較的簡単なリソース管理、スケーリング、抽象化を可能にします。

残念なことに、私たちの人生ではあらゆるものにお金を払わなければなりません。そして、この税金は、特に、Ivan Kruglov 氏が考えているように、開発されたインフラストラクチャを備えた企業の Kubernetes への移行について話す場合、大きなものになります。彼は、従来のインフラストラクチャを備えた企業でも、Kuber を使用した企業でも簡単に働くことができます。重要なのは、企業と市場の詳細を理解することです。しかし、たとえば、Kubernetes をあらゆるコンテナ オーケストレーション ツールに一般化しようとする Evgeny Potapov にとっては、そのような疑問は生じません。

Evgeniy 氏は、複雑なアプリケーションをプログラミングする方法としてオブジェクト指向プログラミングが登場した 1990 年代の状況との類似点を指摘しました。当時、議論は継続され、OOP をサポートする新しいツールが登場しました。その後、モノリシックな概念から脱却する方法としてマイクロサービスが登場しました。その結果、コンテナとそれを管理するためのツールが登場しました。 「小さなアプリケーションをマイクロサービスとして記述する価値があるかどうかについて疑問の余地がなくなり、デフォルトでマイクロサービスとして記述されるようになる時代がもうすぐ来ると思います」と彼は考えています。同様に、Docker と Kubernetes は、最終的には選択する必要のない標準ソリューションになるでしょう。

ステートレスなデータベースの問題

による写真 Twitter: Unsplash の @jankolario

現在、Kubernetes でデータベースを実行するためのレシピは数多くあります。たとえば、ディスク I/O を操作する部分を、データベースのアプリケーション部分から分離する方法などです。 将来、データベースが大きく変化し、ボックスで配信され、その一部が Docker と Kubernetes を介してオーケストレーションされ、インフラストラクチャの別の部分では別のソフトウェアを介してストレージ部分が提供されるようになる可能性はありますか? 製品としてデータベースは変更されますか?

この説明はキュー管理に似ていますが、従来のデータベースにおける情報の信頼性と同期性に対する要件ははるかに高いと Andrey 氏は考えています。通常のデータベースのキャッシュヒット率は 99% のままです。ワーカーがダウンした場合は、新しいワーカーが起動され、キャッシュが最初から「ウォームアップ」されます。キャッシュがウォームアップされるまで、ワーカーの動作は遅くなり、ユーザー負荷をキャッシュに送信できなくなります。ユーザーの負荷がない限り、キャッシュはウォームアップされません。それは悪循環です。

Dmitry は根本的に反対です。クォーラムとシャーディングが問題を解決します。しかしアンドレイ氏は、この解決策がすべての人に適しているわけではないと主張している。状況によってはクォーラムが機能しますが、ネットワークに追加の負荷がかかります。 NoSQL データベースはすべてのケースに適しているわけではありません。

ミートアップの参加者は2つの陣営に分かれました。

Denis 氏と Andrey 氏は、ディスクに書き込まれるすべてのもの (データベースなど) は、現在の Kubernetes エコシステムでは実行不可能であると主張しています。 Kubernetes では本番データの整合性と一貫性を維持することはできません。これは基本的な機能です。 ソリューション: ハイブリッド インフラストラクチャ。

MongoDB や Cassandra などの最新のクラウド ネイティブ データベースや、Kafka や RabbitMQ などのメッセージ キューでも、Kubernetes の外部に永続的なデータ ストアが必要です。

エフゲニーは次のように反論する。「クベラの基地はロシア、あるいは企業にとってのトラウマであり、ロシアではクラウドが普及していないという事実と関係している。」欧米の中小企業はクラウドです。 Amazon RDS データベースは、Kubernetes を自分で操作するよりも簡単に使用できます。ロシアでは、Kuber を「オンプレミス」で使用し、動物園を撤去しようとするときにデータベースをそこに転送します。

Dmitry氏は、Kubernetesにデータベースを保管することはできないという意見にも異議を唱えました。「同じデータベースは2つとして存在しません。巨大なリレーショナルデータベースをプッシュするなら、それは不可能です。しかし、ある程度一時的なものとして想定される、小さくてクラウドネイティブなものをプッシュすれば、すべてうまくいきます。」 Dmitry 氏はまた、データベース管理ツールが Docker や Kuber のどちらにも対応していないため、大きな困難があると述べました。

一方、Ivan 氏は、ステートフルとステートレスの概念を抽象化したとしても、Kubernetes のエンタープライズ ソリューションのエコシステムはまだ準備ができていないと確信しています。 Kubernetes は、法律や規制の要件に従って維持することが困難です。たとえば、サーバーに挿入されるハードウェアに至るまで、サーバーの ID を厳密に保証する必要がある ID プロビジョニング ソリューションを作成することは不可能です。この分野は発展途上ですが、解決策はまだありません。
参加者は合意に達することができなかったため、このセクションでは結論は出ません。実際の例をいくつか挙げてみましょう。

ケース1. Kubernetesの外部に拠点を置く「巨大規制当局」のサイバーセキュリティ

開発されたサイバーセキュリティシステムの場合、コンテナとオーケストレーションを使用することで、攻撃や侵入を撃退できます。たとえば、ある大手規制当局では、Denis 氏と彼のチームは、オーケストレーターと、ログをリアルタイムで分析し、攻撃、ハッキング、または障害のプロセスを判断するトレーニング済みの SIEM サービス間の接続を実装しました。攻撃、何かのインストールの試み、またはランサムウェアウイルスの侵入があった場合、オーケストレーターを介して、感染するよりも速く、または攻撃者が攻撃するよりも速く、アプリケーションを含むコンテナーを起動します。

ケース2. Booking.comデータベースのKubernetesへの部分的な移行

Booking.com では、メイン データベースは非同期レプリケーションを備えた MySQL です。マスターとスレーブの階層全体が存在します。イワンが会社を辞める頃には、ある程度のダメージを与えると「撃ち落とされる」奴隷を移送するプロジェクトが立ち上げられていた。

メイン ベースに加えて、Kuber が主流になる前に作成された、自作のオーケストレーションを備えた Cassandra インストールがあります。この点に関しては問題はありませんが、ローカル SSD に永続化されます。リモート ストレージは、同じデータ センター内であっても、高レイテンシの問題があるため使用されません。

60 番目のデータベース クラスは Booking.com 検索サービスであり、サービスの各ノードはデータベースです。検索サービスを Kuber に移行する試みは、各ノードが 80 ～ XNUMX GB のローカル ストレージであり、「立ち上げ」や「ウォームアップ」が困難であるため失敗しました。

結局、検索エンジンは Kubernetes に移植されず、Ivan 氏は近い将来に新たな試みが行われることはないと考えています。 MySQL データベースは半分転送されました。「撃ち落とす」のが怖くないスレーブだけです。カサンドラはしっかり根付きました。

共通の解決策のない問題としてのインフラ選択

による写真 PexelsのManuel Geissinger

新しい会社、あるいはインフラストラクチャの一部が古い方法で構築されている会社があるとします。数年にわたるインフラ開発計画を作成するために使用されます。コンテナと Kuber 上にインフラストラクチャを構築するかどうかはどのように決定されますか?

ナノ秒を争う企業は議論から除外されます。健全な保守主義は信頼性の面で効果を発揮しますが、新しいアプローチを検討する必要がある企業はまだあります。

Ivan: 「私は間違いなく今すぐクラウドで会社を立ち上げます。単純にクラウドの方が速いからです。」ただし、必ずしも安く済むとは限りません。ベンチャーキャピタリズムの発展により、スタートアップ企業は資金面で大きな問題を抱えることはなくなり、主な任務は市場を征服することになりました。

イヴァンは、 現在のインフラの発展が選択基準となる。過去に本格的な投資が行われ、それがうまくいったのであれば、やり直す意味はありません。インフラストラクチャが開発されておらず、ツール、セキュリティ、監視に問題がある場合は、分散インフラストラクチャを検討するのが合理的です。

いずれにせよ税金は支払わなければならないので、イワンは将来支払う税金が少なくなる方を支払うことになるだろう。 「なぜなら、他の人が牽引する列車に乗るだけで、自分で燃料を補給しなければならない別の列車に乗るよりもはるかに遠くまで移動できるからです。とイヴァンは言います。会社がまだ新しく、レイテンシー要件が数十ミリ秒だった頃、イヴァンは今日、従来のデータベースを「ラップ」するために使用されている「オペレーター」に目を向けました。オペレーターはレプリケーションチェーンを構築し、フェイルオーバーなどの際に自動的に切り替えます。

サーバーが数台しかない小さな会社では、Kubera は意味がない、と Andrey 氏は言います。しかし、数百台以上のサーバーに拡張する予定の場合は、自動化とリソース管理システムが必要になります。 90% のケースではコストに見合う価値があります。さらに、負荷とリソースのレベルに関係なく。スタートアップ企業から、何百万人ものユーザーを抱える大企業まで、誰もがコンテナ オーケストレーション製品に徐々に目を向けていくのは理にかなっています。 「そうです、これがまさに未来です」とアンドレイは自信を持っています。

デニスは 2 つの主な基準を特定しました。 スケーラビリティと操作の安定性。 彼はその仕事に最適なツールを選択します。 「無名の製品を即席で組み立て、Nutanix Community Editionを搭載している場合もあります。これは、バックエンドにレプリケーションされ、RTOとRPO（目標復旧時間/目標復旧時点）が定義されたデータベースを備えたKuber上のアプリケーションという形で、セカンドラインとなる可能性があります。」 およそ).

エフゲニーは人事に関する問題がある可能性があると認識しました。現時点では、市場には「本質」を理解している高度な資格を持つ専門家は多くありません。実際、選択したテクノロジーが古い場合、年配で退屈で疲れている人以外を雇うのは困難です。しかし、他の参加者は、これは人材育成の問題だと考えています。
Amazon RDS のデータベースを使用してパブリック クラウドで小規模な会社を立ち上げるか、Kubernetes のデータベースを使用して「オンプレミス」で立ち上げるかを自問自答した場合、いくつかの欠点があるにもかかわらず、参加者の選択は Amazon RDS でした。

ミートアップの聴衆のほとんどは「血まみれの」企業関係者ではないので、 分散型ソリューションこそ私たちが目指すべきものです。データ ストレージ システムは分散され、信頼性が高く、ミリ秒単位、最大でも数十秒の遅延を生成する必要があります。、とアンドレイはまとめた。

Kubernetesの使用状況の評価

リスナーの Anton Zhbankov 氏は、Kubernetes 擁護者たちに罠となる質問をしました。彼らはどのようにして実現可能性調査を選択し、実施したのでしょうか?たとえば、なぜ Kubernetes なのか、なぜ仮想マシンではないのか?

による写真 UnsplashのTatyana Eremina

ドミトリーとイワンがそれに答えた。どちらのケースも、試行錯誤を繰り返しながら一連の決定がなされ、最終的に両者は Kubernetes にたどり着きました。現在、企業は Kuber に移行するのが理にかなったソフトウェアを独自に開発し始めています。ここでは、1C などの従来のサードパーティ システムについて話しているわけではありません。 Kubernetes は、開発者が継続的な改善を継続的に行いながら、迅速にリリースする必要がある場合に役立ちます。

Andrey のチームは、仮想マシンに基づくスケーラブルなクラスターを作成しようとしました。ノードがドミノ倒しのように倒れ、クラスターがクラッシュすることもありました。 「理論上は手作業で仕上げて維持することも可能ですが、面倒です。もし市場に、既成概念にとらわれずに作業できるソリューションがあれば、喜んでそれを選びます。そして、その結果、私たちはそれに切り替えました」とアンドレイは言います。

こうした分析や計算には標準がありますが、実際のハードウェアで動作しているときにどれほど正確であるかは誰にもわかりません。計算には各ツールとエコシステムを理解することも重要ですが、これは不可能です。

私たちを待っているもの

による写真 ドリュー・ビーマー（Unsplash）

テクノロジーが進化するにつれて、より多くの要素が登場し、その後相転移が起こり、すべてを 1 つのツールに統合するほどの「バブル」を解消したベンダーが登場します。

こういう楽器が登場する時代が来ると思いませんか？ Ubuntu 世界のために Linux? おそらく、単一のコンテナ化およびオーケストレーション ツールに Kuber が含まれることになります。オンプレミスのクラウドの構築が容易になります。

Ivan 氏は次のように答えました。「Google は現在、Anthos を構築しています。これはクラウドを展開し、Kuber、Service Mesh、モニタリングなど、オンプレミスのマイクロサービスに必要なすべてのハードウェアを含むパッケージ化されたサービスです。」私たちはほぼ未来にいるのです。」

Denis 氏はまた、コンテナ化なしで同様のタスクを処理できる vRealize Suite 製品を備えた Nutanix と VMWare についても言及しました。

ドミトリー氏は、「痛み」を軽減することと税金を減らすことは改善が期待できる2つの分野であるという意見を述べました。

議論を要約すると、現代のインフラの次のような問題点が浮き彫りになる。

• 3 人の参加者が同時にステートフルの問題を特定しました。
• Docker が Python、アプリケーション サーバー、コンポーネントの複数のバージョンを使用する可能性など、さまざまなセキュリティ サポートの問題。
  過剰な支出については、別のミーティングで議論したほうがよいでしょう。
  オーケストレーションは複雑なエコシステムであるため、問題は学習にあります。
  業界でよくある問題はツールの誤用です。

  残りの結論を導き出すのはあなた次第です。 Docker + Kubernetes バンドルがシステムの「中心」部分となるのにまだ苦労しているという印象が残っています。たとえば、オペレーティング システムは最初にハードウェアにインストールされますが、コンテナーとオーケストレーションについてはそうは言えません。おそらく将来的には、オペレーティング システムとコンテナーがクラウド管理ソフトウェアと統合されるでしょう。

  
  による写真 Pexels のガブリエル サントス 写真

  この機会に母にご挨拶をしたいと思います。 Facebook グループがあることを思い出してください。 「大規模ITプロジェクトの管理と開発」、チャネル @フィードメト さまざまな技術ブログからの興味深い出版物。そして私のチャンネル @rybakalexeyでは、製品会社における開発管理についてお話します。

出所： habr.com