こんにちは、ハブル！ 私はあなたの注意を喚起します 著者による記事の翻訳 .
IT の世界が徐々にマイクロサービスや Kubernetes などのツールに移行しつつある現在、XNUMX つだけ問題がますます顕著になってきています。 この問題 - マイクロサービスのバージョン。 それでも、IT コミュニティは、現在の状況は以前よりもはるかに良いと信じています。 前世代のテクノロジー。 ただし、マイクロサービスのバージョン管理は非常に複雑な問題です。 この証拠の XNUMX つは、次のような記事です。 .
この文章を読んでも問題が理解できない場合は、説明しましょう。 製品が 10 個のマイクロサービスで構成されているとします。 ここで、これらのマイクロサービスごとに 1 つの新しいバージョンがリリースされたと仮定します。 バージョンは 1 つだけ - これは非常に些細で取るに足らない事実であるということに皆さんが同意していただければ幸いです。 しかしここで、私たちの製品をもう一度見てみましょう。 各コンポーネントの新しいバージョンが 2 つだけあるため、製品の構成方法について 10^1024、つまり XNUMX 通りの順列が得られます。
まだ誤解がある場合は、計算を分解しましょう。 したがって、10 個のマイクロサービスがあり、それぞれが 2 つの更新を受け取ります。 つまり、マイクロサービスごとに 10 つの可能なバージョン (古いか新しいか) が取得されます。 これで、製品コンポーネントごとに、これら 1 つのバージョンのいずれかを使用できるようになります。 数学的には、0 桁の 1001000000 進数があるのと同じです。 たとえば、1 が新しいバージョン、4 が古いバージョンであるとします。その場合、考えられる順列の 10 つは 2 と表すことができます。この場合、10 番目と 1024 番目のコンポーネントが更新され、その他はすべて更新されません。 数学から、XNUMX 桁の XNUMX 進数は XNUMX^XNUMX、つまり XNUMX 個の値を持つことができることがわかっています。 つまり、扱っている数字の規模を確認したということです。
さらに推論を続けてみましょう。100 個のマイクロサービスがあり、それぞれに 10 個の可能なバージョンがある場合はどうなるでしょうか? 全体の状況は非常に不快なものになります。現在、10^100 の順列があり、これは膨大な数です。 しかし、私はこの状況をこのように分類することを好みます。なぜなら、私たちはもはや「kubernetes」などの言葉の背後に隠れているのではなく、問題をそのまま直面しているからです。
なぜ私はこの問題にこれほど惹かれるのでしょうか? その理由の 5 つは、私たちが以前 NLP と AI の世界で働いていたことがあり、約 6 ～ XNUMX 年前に組み合わせ爆発の問題についてよく議論したからです。 バージョンの代わりに個々の単語があり、製品の代わりに文と段落があっただけです。 NLP と AI の問題はほとんど未解決のままですが、過去数年間で大幅な進歩があったことは認められます。 (私の意見では、進歩する可能性があると思います)о業界の人々が機械学習にもう少し注意を払い、他の技術にもう少し注意を払ってくれれば良いのですが、これはすでに本題から外れています)。
DevOps とマイクロサービスの世界に戻りましょう。 私たちは、クンストカメラの象のふりをするという大きな問題に直面しています。なぜなら、私がよく聞くのは、「Kubernetes と Helm を手に入れるだけで、すべてがうまくいくでしょう!」だからです。 しかし、いいえ、すべてをこのままにしておいてはうまくいきません。 さらに、この問題の分析的解決策は、その複雑さのために受け入れられないようです。 NLP と同様に、まず検索範囲を狭めることによって、この問題にアプローチする必要があります。この場合は、古い順列を削除します。
役立つかもしれないものの XNUMX つは、私が昨年書いたものです 。 適切に設計された CI/CD プロセスは、変動を減らすのに非常に役立つことに注意することも重要です。 ただし、CI/CD の現状では、コンポーネントのアカウンティングと追跡のための追加ツールがなければ、順列の問題を解決するには不十分です。
私たちに必要なのは、統合段階での実験システムです。そこでは、各コンポーネントのリスク要因を判断でき、また、さまざまなコンポーネントを更新し、オペレーターの介入なしでテストして、何が機能し、何が機能しないのかを確認するための自動プロセスも備えています。
このような実験システムは次のようになります。
- 開発者はテストを作成します (これは重要な段階です。そうしないと評価基準がありません。これは機械学習でデータにラベルを付けるようなものです)。
- 各コンポーネント (プロジェクト) は独自の CI システムを受け取ります。このプロセスは現在十分に開発されており、単一コンポーネントの CI システムを作成する問題は大幅に解決されています。
- 「スマート統合システム」は、さまざまな CI システムの結果を収集し、コンポーネント プロジェクトを最終製品に組み立て、テストを実行し、最終的に既存のコンポーネントとリスク要因に基づいて、目的の製品機能を取得するための最短経路を計算します。 更新が不可能な場合、このシステムは開発者に既存のコンポーネントとそのコンポーネントがエラーの原因であることを通知します。 もう一度言いますが、統合システムは評価基準としてテストを使用するため、ここではテスト システムが非常に重要です。
- CD システムは、Smart Integration System からデータを受信し、更新を直接実行します。 この段階でサイクルが終了します。
要約すると、私にとって今の最大の問題の XNUMX つは、さまざまなコンポーネントを製品にリンクし、製品全体がどのように組み立てられているかを追跡できるような「スマート統合システム」が存在しないことです。 これに関するコミュニティの意見に興味があります (ネタバレ - 現在プロジェクトに取り組んでいます) 、このようなスマートな統合システムになる可能性があります)。
最後にもう XNUMX つ言及しておきたいのは、私にとって、モノリスは中規模のプロジェクトであっても受け入れられないということです。 私にとって、モノリスに戻すことで実装時間と開発の質を向上させようとする試みは、大きな疑念を引き起こします。 まず、モノリスには、それを構成するさまざまなライブラリの中でコンポーネントを管理するという同様の問題がありますが、これはすべてそれほど目立たず、主に開発者が費やす時間に現れます。 モノリス問題の結果、コードに変更を加えることが事実上不可能になり、開発速度が非常に遅くなります。
マイクロサービスによって状況は改善されますが、マイクロサービス アーキテクチャは統合段階で組み合わせ爆発の問題に直面します。 はい、一般的に、同じ問題を開発段階から統合段階に移行しました。 しかし、私の意見では、マイクロサービスのアプローチは依然としてより良い結果につながり、チームはより早く結果を達成します (おそらく主に開発ユニットのサイズが縮小したためです - または バッチサイズ）。 ただし、モノリスからマイクロサービスへの移行は、プロセスにまだ十分な改善をもたらしていません。マイクロサービスのバージョンの組み合わせの爆発的な増加は大きな問題であり、それを解決することで状況を改善できる可能性がたくさんあります。
出所： habr.com