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

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.comKubernetes で多くのことを自らの手で行った同じ人物です。

トピックス：

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

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

Kubernetes はすでに標準になっていますか、それとも優れたマーケティングですか?

「私たちは、まだ誰もそれについて知らなかったときに、これ (Kubernetes. - 編) にたどり着きました。 彼がいないときでも、私たちは彼のところに来ました。 前から欲しかったんです」 - ドミトリー・ストリャロフ

写真はReddit.comより

5 ～ 10 年前には膨大な数のツールが存在し、単一の標準はありませんでした。 半年ごとに、あるいは複数の新製品が登場します。 最初は Vagrant、次に Salt、Chef、Puppet...「そして、XNUMX か月ごとにインフラストラクチャを再構築します。 管理者が XNUMX 人いて、常に設定の書き換えに追われています」と Andrey Fedorovsky 氏は思い出します。 同氏は、Docker と Kubernetes が残りを「押し出してしまった」と考えています。 Docker は過去 XNUMX 年間で、Kubernetes は過去 XNUMX 年間で標準になりました。 そしてそれは業界にとって良いことだ。.

ドミトリー・ストリャロフと彼のチームは Kuber を愛しています。 彼らはそのようなツールが登場する前から欲しがっていて、誰もそれを知らなかったときにそれを思いつきました。 現在、便宜上の理由から、クライアントが Kubernetes を実装しないことを理解している場合はクライアントを引き受けません。 同時に、ドミトリー氏によれば、同社には「恐ろしい遺産を作り直すという巨大な成功例が数多くある」という。

Kubernetes は単なるコンテナ オーケストレーションではなく、開発された API、ネットワーキング コンポーネント、L3 バランシング、Ingress コントローラーを備えた構成管理システムであり、リソースの管理、拡張、インフラストラクチャの下位層からの抽象化を比較的容易にします。

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

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

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

による写真 Twitter: Unsplash の @jankolario

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

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

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

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

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

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

エフゲニー氏は、「クベラの基地はロシアに近い、あるいは企業に近い被害であり、ロシアではクラウド導入が進んでいないという事実と関係している」と反論した。 欧米の中小企業はクラウドです。 Amazon RDS データベースは、Kubernetes を自分でいじるよりも使いやすいです。 ロシアでは、動物園を撤去しようとするとき、「オンプレミス」で Kuber を使用し、そこに基地を移転します。

Dmitry 氏は、Kubernetes にデータベースを保持できないという意見にも反対しました。「Base は Base とは異なります。 そして、巨大なリレーショナル データベースをプッシュする場合は、いかなる状況であってもダメです。 小規模でクラウドネイティブなものを推進すれば、半永久的な人生に備えて心の準備ができていれば、すべてがうまくいくでしょう。」 Dmitry 氏は、データベース管理ツールが Docker にも Kuber にも対応していないため、大きな困難が生じているとも述べました。

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

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

開発されたサイバーセキュリティ システムの場合、コンテナとオーケストレーションの使用により、攻撃や侵入を撃退することが可能になります。 たとえば、ある巨大規制当局では、デニス氏と彼のチームは、リアルタイムでログを分析し、攻撃、ハッキング、障害のプロセスを判断する訓練された SIEM サービスとオーケストレーターの組み合わせを実装しました。 攻撃が発生した場合、何かを配置しようとした場合、またはランサムウェア ウイルスの侵入が発生した場合、オーケストレーターを通じて、感染するよりも早く、または攻撃者が攻撃するよりも早く、アプリケーションが含まれるコンテナーを取得します。

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

Booking.com では、メインのデータベースは非同期レプリケーションを備えた MySQL であり、マスターとスレーブの階層全体があります。 イワンが会社を去るまでに、一定のダメージを与えて「射殺」できる奴隷を移送するプロジェクトが開始されました。

メインベースに加えて、Kuber が主流になる前に書かれた、自作のオーケストレーションを備えた Cassandra インストールがあります。 これに関しては問題はありませんが、ローカル SSD 上では永続的に発生します。 リモート ストレージは、同じデータ センター内であっても、遅延が長いという問題があるため使用されません。

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

その結果、検索エンジンは Kubernetes に移行されず、近い将来新たな試みが行われることはないと Ivan 氏は考えています。 MySQL データベースは半分に転送され、「撃たれる」ことを恐れないスレーブのみが転送されました。 カサンドラは完全に定着しました。

一般的な解決策のないタスクとしてのインフラストラクチャの選択

による写真 Pexels のマヌエル・ガイシンガー

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

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

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

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

いずれにせよ税金は支払わなければならず、イワンは将来的には支払額が少なくて済む方を支払うことになる。 」なぜなら、他の人が移動している電車に乗っているという事実だけで、自分で燃料を入れなければならない別の電車に座っている場合よりも、はるかに遠くまで移動できるからです。」とイワンは言います。 会社が新しく、レイテンシー要件が数十ミリ秒である場合、Ivan は、今日の古典的なデータベースが「ラップ」されている「オペレーター」に注目するでしょう。 これらは、フェイルオーバーなどの場合に自動的に切り替わるレプリケーション チェーンを構築します。

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

デニス氏は XNUMX つの主な基準を概説しました。 拡張性と動作の安定性。 彼はその作業に最適なツールを選択します。 「それはあなたの膝の上で組み立てられたノーネームかもしれません、そしてそれにはNutanix Community Editionが含まれています。 これは、バックエンドにデータベースを備えた Kuber 上のアプリケーションの形式の XNUMX 行目になる可能性があります。データベースはレプリケートされ、RTO および RPO パラメーターが指定されています。」 (復旧時間/目標ポイント - およそ).

エフゲニー氏は人事に問題がある可能性があることを指摘した。 現時点では、市場には「根性」を理解している高度な専門家は多くありません。 確かに、選択した技術が古い場合は、人生に飽き飽きした中年の人以外を雇用するのは困難です。 他の参加者はこれは人材育成の問題だと信じていますが。
Amazon RDS のデータベースを使用してパブリック クラウドで中小企業を立ち上げるか、Kubernetes のデータベースを使用して「オンプレミス」で中小企業を立ち上げるかという選択の問題を立てた場合、いくつかの欠点はあるものの、Amazon RDS が参加者の選択肢となりました。

ミートアップのリスナーの大多数は「血なまぐさい」企業の出身者ではないため、 分散ソリューションは私たちが目指すべきものです。 データ ストレージ システムは分散型で信頼性が高く、ミリ秒、最大でも数十秒の単位で測定される遅延が発生する必要があります。」とアンドレイは要約しました。

Kubernetes の使用状況の評価

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

による写真 タチアナ・エレミナがUnsplashに登場

ドミトリーとイワンがそれに答えた。 どちらの場合も、試行錯誤を経て一連の決定が行われ、その結果、両方の参加者が Kubernetes に到達しました。 現在、企業は Kuber への移行に合理的なソフトウェアを独自に開発し始めています。 1C などの古典的なサードパーティ システムについて話しているのではありません。 Kubernetes は、開発者が迅速にリリースを作成する必要がある場合に役立ち、ノンストップの継続的な改善を実現します。

Andrey のチームは、仮想マシンに基づいてスケーラブルなクラスターを作成しようとしました。 ノードがドミノ倒しのように倒れ、クラスターの崩壊につながることもありました。 「理論的には、完成させて手で支えることもできますが、面倒です。 すぐに使えるソリューションが市場にあるのであれば、喜んでそれを利用します。 その結果、私たちは切り替えました」とアンドレイは言います。

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

私たちを待っているもの

による写真 ドリュー・ビーマーがUnsplashについて語る

テクノロジーが進化するにつれて、ますます多くの異なる部品が登場し、その後、相転移が起こり、すべてを XNUMX つのツールにまとめるのに十分な量の生地を生産したベンダーが現れます。

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

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

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

ドミトリー氏は、「痛み」の軽減と減税が改善が期待できるXNUMXつの分野であるとの意見を共有した。

議論を要約すると、現代のインフラストラクチャの次の問題に焦点を当てます。

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

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

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

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

出所： habr.com