モノリスからマイクロサービスまで: M.Video-Eldorado と MegaFon の経験

25 月 XNUMX 日、私たち Mail.ru グループはクラウドとその周辺に関するカンファレンスを開催しました。 メール先:クラウド。 いくつかのハイライト:

• メイン ロシアのプロバイダー — Mail.ru Cloud Solutions、#CloudMTS、SberCloud、Selectel、Rostelecom Data Center、Yandex.Cloud が、当社のクラウド市場とそのサービスの詳細について話しました。
• Bitrix24 の同僚がその様子を語った。 マルチクラウドに来ました;
• リロイ・マーリン、オトクリティ、バーガーキング、シュナイダーエレクトリックが興味深いものを提供した クラウド利用者からの視点 — 自社のビジネスが IT に対してどのようなタスクを設定しているか、クラウドを含むどのテクノロジーが最も有望であると考えているか。

mailto:CLOUD カンファレンスのすべてのビデオを視聴できます リンク、ここで、マイクロサービスに関する議論がどうなったかを読むことができます。 MegaFon ビジネス システム研究開発センター所長の Alexander Deulin 氏と、M.Video-Eldorado グループの情報技術ディレクターである Sergey Sergeev 氏が、モノリスを排除する成功事例を共有しました。 また、IT 戦略、プロセス、さらには人事に関する関連問題についても議論しました。

パネリスト

• セルゲイ・セルゲイフ、グループCIO 「M.ビデオ・エルドラド」;
• アレクサンダー・デューリン、業務システム研究開発センター長 メガフォン;
• モデレーター — ドミトリー・ラザレンコ、PaaS ディレクション責任者 Mail.ru クラウド ソリューション.

アレクサンダー・デューリン氏の講演後 「MegaFon がマイクロサービス プラットフォームを通じてビジネスをどのように拡大しているか」 彼は、M.Video-Eldorado の Sergey Sergeev とディスカッション モデレーターの Mail.ru Cloud Solutions の Dmitry Lazarenko がディスカッションに参加します。

以下にディスカッションの記録を用意しましたが、ビデオを見ることもできます。

マイクロサービスへの移行は市場のニーズへの対応です

ドミトリー：

マイクロサービスへの移行に成功した経験はありますか? そして一般的に、マイクロサービスの使用、またはモノリスからマイクロサービスへの移行によってビジネスに最大のメリットが得られるのはどこだと思いますか?

セルゲイ：

私たちはすでにマイクロサービスへの移行をある程度進めており、このアプローチを XNUMX 年以上使用しています。 マイクロサービスの必要性を正当化する最初のニーズは、さまざまなフロントエンド製品とバックオフィスとの終わりのない統合でした。 そしてそのたびに、追加の統合と開発を行って、特定のサービスの運用に関する独自のルールを実装する必要がありました。

ある時点で、私たちはシステムの動作と機能の出力を高速化する必要があることに気づきました。 その時点で、すでにマイクロサービスやマイクロサービスアプローチといった概念が市場に存在していたので、それを試してみることにしました。 これは 2016 年に始まりました。 その後、プラットフォームが構築され、最初の 10 のサービスは別のチームによって実装されました。

最初のサービスの XNUMX つで最も負荷が高かったのは、価格計算サービスでした。 Web サイトであろうと小売店であろうと、どのチャンネルや M.Video-Eldorado グループ企業にアクセスし、そこで製品を選択し、Web サイトまたは「バスケット」の価格を確認するたびに、コストは自動的に計算されます。 XNUMXつのサービスで計算されます。 これが必要な理由: 以前は、割引などのプロモーションを行うための独自の原則が各システムにありました。 当社のバックオフィスが価格設定を処理し、割引機能は別のシステムに実装されています。 これを一元化し、これを実装できるビジネス プロセスの形式で作成された独自の分離可能なサービスが必要でした。 それがまさに私たちが始めた方法です。

最初の結果の価値は非常に大きかった。 まず、分離可能なエンティティを作成することができ、これにより個別に作業することも、集合的に作業することも可能になります。 第 XNUMX に、より多くのシステムとの統合という点で所有コストを削減しました。

過去 XNUMX 年間で、私たちは XNUMX つのフロントライン システムを追加しました。 会社が余裕のあるリソースと同じ量でそれらを維持するのは困難でした。 したがって、スピード、内部コスト、効率の観点から市場に対応する新しい販路を探すという課題が生じました。

マイクロサービスへの移行の成功を測定する方法

ドミトリー：

マイクロサービスへの移行の成功はどのように決まるのでしょうか? それぞれの企業の「以前」は何だったのでしょうか？ 移行の成功を判断するためにどのような指標を使用しましたか?また、実際にそれを判断したのは誰ですか?

セルゲイ：

まず第一に、それは新しい機能を「ロック解除」するためのイネーブラーとして IT 内で生まれました。 私たちは、市場の課題に対応して、比較的同じ金額ですべてをより迅速に行う必要がありました。 現在、成功は、さまざまなシステムによって再利用されるサービスの数、システム間のプロセスの統合によって表現されます。 今はそうなんですが、その時はプラットフォームを作って「これをやれば効果が出る」という仮説を確認してビジネスケースを計算する機会でした。

アレクサンダー：

成功とはむしろ内面的な感情です。 ビジネスは常により多くのことを望んでおり、バックログの深さは成功の証拠です。 私にはそう思えます。

セルゲイ：

はい私は同意する。 30 年間で、すでに XNUMX を超えるサービスと未処理のサービスが存在します。 チーム内のリソースの必要性は毎年 XNUMX% ずつ増加するばかりです。 このようなことが起こっているのは、人々が「もっと速い、違う、さまざまなテクノロジーがあり、すべてが発展している」と感じたからです。

マイクロサービスは登場するが、コアは残る

ドミトリー：

それは開発に投資する終わりのないプロセスのようなものです。 ビジネスにおけるマイクロサービスへの移行はすでに終わっているのでしょうか?

セルゲイ：

答えるのはとても簡単です。 携帯電話の交換は終わりのないプロセスだと思いますか? 私たち自身も毎年携帯電話を購入しています。 そしてそれは次のとおりです。スピードが必要である限り、市場に適応するためには、いくつかの変更が必要になります。 だからといって、定番のものを捨てるわけではありません。

しかし、一度にすべてをカバーしてやり直すことはできません。 当社には、エンタープライズ バスなど、以前から存在していたレガシーな標準統合サービスがあります。 しかし、バックログもあり、ニーズもあります。 モバイル アプリケーションとその機能の数は増加しています。 同時に、30％多くのお金が与えられるとは誰も言いません。 つまり、一方では常にニーズがあり、他方では効率性の追求が存在します。

ドミトリー：

人生は順調です。 (笑)

アレクサンダー：

一般的にはそうです。 私たちは風景から核となる部分を取り除く革新的なアプローチを持っていません。 システムを分解してマイクロサービス アーキテクチャとの整合性を高め、システム相互の影響を軽減する体系的な作業が進行中です。

しかし、通信事業者の状況では、私たちが購入するいくつかのプラットフォームが常に存在するため、私たちはコア部分を維持するつもりです。 繰り返しますが、健全なバランスが必要です。急いでコアを切り取るべきではありません。 システムを並べて配置すると、すでに多くのコア パーツが配置されていることがわかります。 さらに、機能を開発することで、通信サービスと連動するすべてのチャネルに必要な表現を作成します。

マイクロサービスを企業に販売する方法

ドミトリー：

また、まだ切り替えていないが、切り替えを計画している人たちにも興味があります。このアイデアを企業に売り込むのはどれほど簡単でしたか、また、それは冒険でしたか、投資プロジェクトでしたか? それとも、それは意識的な戦略だったのでしょうか。これからマイクロサービスに移行するので、それだけです。私たちを止めるものは何もありません。 いかがでしたか？

セルゲイ：

私たちはアプローチを販売したのではなく、ビジネス上の利点を販売しました。 ビジネス上で問題が発生し、私たちはそれを解決しようとしました。 その時点では、チャネルごとに、プロモーション用、プロモーション用など、価格の計算に異なる原則が使用されているという事実で表現されました。 メンテナンスが難しく、エラーが発生し、お客様の苦情に耳を傾けました。 つまり、私たちは問題の解決策を販売していましたが、プラットフォームを作成するには資金が必要だという事実を抱えていました。 そして彼らは、投資の第 XNUMX 段階を例として、どのようにして投資を回収し続けるのか、そしてこれによって何が可能になるのかというビジネス ケースを示しました。

ドミトリー：

最初のステージのタイムをなんとか記録しましたか？

セルゲイ：

はい、確かに。 プラットフォームとしてのコアの作成とパイロットのテストに 6 か月を割り当てました。 この間、私たちはパイロットがスケートをするためのプラットフォームを作成しようとしました。 すると仮説が確認され、うまくいったので続けられるということになります。 彼らはチームを再現し、強化し始めました。まさにそれを行う別の部門にチームを移動しました。

次に、ビジネス ニーズ、機会、リソースの可用性、および現在進行中のすべてのものに基づいた体系的な作業が行われます。

ドミトリー：

わかりました。 アレクサンダー、何と言いますか？

アレクサンダー：

私たちのマイクロサービスは「海の泡」から生まれました。これは、サーバー容量の形で残ったリソースとチーム内の戦力の再配分によるリソースの節約によるものです。 当初、私たちはこのプロジェクトを企業に販売していませんでした。 これは私たち二人がそれに応じて研究し、開発したプロジェクトでした。 私たちは 2018 年の初めに着手し、ただ熱意を持ってこの方向性を開発しました。 販売はまだ始まったばかりで、現在進行中です。

ドミトリー：

週に XNUMX 日だけ、Google のようなことをできる企業がいるでしょうか? そういう方向性はありますか？

アレクサンダー：

私たちは研究と同時にビジネス上の問題にも取り組んでいました。そのため、私たちのマイクロサービスはすべてビジネス上の問題に対するソリューションです。 当初は加入者ベースのごく一部をカバーするマイクロサービスを構築していましたが、今ではほぼすべての主力製品に組み込まれています。

そして、重大な影響はすでに明らかです。私たちが古い道をたどっていた場合、製品の発売速度と収益の損失はすでに予測できます。 これが私たちが訴訟を構築しているものです。

マイクロサービス: 誇大広告か、それとも必要性か?

ドミトリー：

数字は数字です。 そして、収入や節約されたお金は非常に重要です。 反対側を見たらどうなるでしょうか？ マイクロサービスはトレンドであり、誇大広告であり、多くの企業がマイクロサービスを悪用しているようですか? マイクロサービスに変換するものと変換しないものをどの程度明確に区別していますか? 今レガシーだとしたら、5年後もレガシーは残っていますか？ M.Video-Eldorado と MegaFon で稼働する情報システムは 5 年後には何歳になるでしょうか? 情報システムは XNUMX 年後、XNUMX 年後も存在するのでしょうか、それとも新しい世代になるのでしょうか? これをどう思いますか?

セルゲイ：

あまり遠くのことを考えるのは難しいようです。 振り返ってみると、機械学習や顔によるユーザー識別など、テクノロジー市場がこのように発展するとは誰が想像したでしょうか。 しかし、今後数年間を見てみると、企業の基幹システム、エンタープライズ ERP クラスのシステムは、かなり長い間機能し続けているように思えます。

私たちの会社は合わせて 25 年前に設立され、従来の ERP がシステム環境の非常に深く浸透しています。 そこからいくつかの部分を取り出してマイクロサービスに集約しようとしているのは明らかですが、コアは残ります。 現在、そこにあるすべてのコア システムを置き換えて、新しいシステムの別の明るい面にすぐに移行することを想像するのは困難です。

私は、クライアントと消費者に近いすべての場所こそが最大のビジネス上のメリットと価値があり、そこには適応性があり、スピード、変化、「何か違うことを試す、キャンセルする、再利用する」ことに重点を置くという事実を支持しています。必要です」――そこで風景が変わります。 そして、箱入りの製品はそこにうまく収まりません。 少なくとも私たちにはそれが見えません。 そこでは最も簡単でシンプルな解決策が必要です。

次のような展開が見られます。

• 基幹情報システム (主にバックオフィス)。
• マイクロサービスの形式の中間層は、コアの接続、集約、キャッシュの作成などを行います。
• 最前線のシステムは消費者を対象としています。
• 通常、市場、他のシステム、エコシステムに統合される統合レイヤー。 このレイヤーは可能な限り軽量でシンプルで、最小限のビジネス ロジックが含まれています。

しかし同時に、私は古い原則が適切に使用されるのであれば、引き続き使用することを支持します。

従来のエンタープライズ システムがあるとします。 これは XNUMX つのベンダーのランドスケープ内に位置し、相互に連携する XNUMX つのモジュールで構成されます。 標準の統合インターフェイスもあります。 なぜやり直してそこにマイクロサービスを導入するのでしょうか?

しかし、バックオフィスに 5 つのモジュールがあり、そこから情報がビジネス プロセスに収集され、8 ～ 10 のフロントライン システムで使用される場合、その利点はすぐに目に見えます。 XNUMX つのバックオフィス システムを利用して、ビジネス プロセスに焦点を当てた独立したサービスを作成します。 サービスを技術的に高度なものにし、情報をキャッシュし、耐障害性を備え、ドキュメントやビジネス エンティティとも連携できるようにします。 そして、単一の原則に従って、それをすべての最前線の製品に統合します。 彼らは最前線の製品をキャンセルしました。単に統合を無効にしただけです。 明日は、モバイル アプリケーションを作成するか、小さな Web サイトを作成し、XNUMX つの部分だけを機能に組み込む必要があります。すべてが単純です。コンストラクターのように組み立てるだけです。 少なくとも我が国では、この方向でさらなる発展が見られると思います。

アレクサンダー：

セルゲイは私たちのアプローチを完全に説明してくれました、ありがとう。 絶対に避けたい部分、つまり核心部分、つまりオンライン請求の話題についてだけ言っておきます。 つまり、レーティングと課金は、事実上、確実にお金を取り消す「大きな」脱穀物であり続けるのです。 そして、このシステムは今後も規制当局によって認定され続けます。 もちろん、クライアントを対象とするその他のものはすべてマイクロサービスです。

ドミトリー：

ここでの認証は XNUMX つのストーリーです。 おそらくより多くのサポートが得られるでしょう。 サポートにあまりお金をかけない場合、またはシステムがサポートや変更を必要としない場合は、触らないほうがよいでしょう。 合理的な妥協案です。

信頼性の高いマイクロサービスを開発する方法

ドミトリー：

大丈夫。 しかし、私はまだ興味があります。 今、あなたは成功物語を語っています。すべてがうまくいき、マイクロサービスに切り替え、アイデアをビジネスに守り、すべてがうまくいきました。 しかし、他の話も聞いたことがあります。

数年前、銀行向けの新しいマイクロサービス プラットフォームの開発に XNUMX 年間投資していたスイスの企業が、最終的にプロジェクトを終了しました。 完全に崩壊した。 何百万スイスフランも費やされ、最終的にチームは解散しましたが、うまくいきませんでした。

同様の話をしたことがありますか? 何か困難はありましたか？ たとえば、マイクロサービスの維持と監視も、企業の運用活動における頭の痛い問題です。 結局のところ、部品の数は数十倍になります。 どうですか、ここでの投資で失敗した例はありますか？ そして、そのような問題に遭遇しないように人々に何をアドバイスできますか?

アレクサンダー：

失敗した例としては、企業が優先順位を変更したり、プロジェクトをキャンセルしたりしたことが挙げられます。 準備が整った段階 (実際には MVP の準備ができている) で、企業は「新しい優先事項があり、別のプロジェクトに移行し、このプロジェクトを終了します。」と言いました。

マイクロサービスに関しては世界的な障害は発生しませんでした。 私たちは安らかに眠り、BSS [ビジネス サポート システム] 全体にサービスを提供する 24 時間年中無休の勤務体制をとっています。

そしてもう 40 つ、ボックス製品に適用されるルールに従ってマイクロサービスをレンタルします。 成功の鍵は、まず、実稼働用にマイクロサービスを完全に準備するチームを編成する必要があることです。 開発自体は条件付きでXNUMX％です。 残りは分析、DevSecOps 方法論、適切な統合、適切なアーキテクチャです。 私たちは安全なアプリケーションを構築する原則に特に注意を払っています。 情報セキュリティ担当者は、アーキテクチャ計画段階と実装プロセスの両方で各プロジェクトに参加します。 また、コードの脆弱性を分析するシステムも管理します。

ステートレス サービスを Kubernetes にデプロイするとします。 これにより、サービスの自動スケーリングと自動引き上げにより、誰もが安心して眠ることができ、勤務交代によってインシデントが検出されます。

私たちのマイクロサービスが存在する全体の中で、私たちのラインに到達したインシデントは 200 つまたは 50 つだけです。 現在、動作に問題はございません。 もちろん、XNUMX ではなく約 XNUMX のマイクロサービスがありますが、それらは主力製品で使用されています。 彼らが失敗した場合、私たちはそれを最初に知ることになるでしょう。

マイクロサービスと人事

セルゲイ：

サポートへの異動については、仕事を正しく組織する必要があるという同僚の意見に私も同意します。 しかし、もちろん存在する問題についてお話します。

まず、技術が新しいです。 これは良い意味で誇大広告であり、これを理解して作成できる専門家を見つけるのは大きな課題です。 リソースを巡る競争は熾烈を極めており、専門家には金に相当する価値があります。

第二に、特定のランドスケープの作成とサービスの数の増加に伴い、再利用の問題は常に解決されなければなりません。 開発者がやりたがるのは、「ここに興味深いものをたくさん書いてみましょう...」ということです。このため、システムは成長し、金銭や所有コストなどの観点から有効性を失います。 つまり、システムアーキテクチャに再利用を組み込み、サービス導入やレガシーを新しいアーキテクチャに移行するためのロードマップに組み込む必要がある。

もう XNUMX つの問題は、それはそれで良いことですが、内部競争です。 「ああ、新しいファッショナブルな男たちがここに現れました。彼らは新しい言語を話します。」 もちろん、人は異なります。 Java で書くことに慣れている人もいれば、Docker や Kubernetes を書いて使う人もいます。 これらはまったく異なる人々であり、話し方も言葉も異なり、時にはお互いを理解できないこともあります。 この意味で実践の共有、知識の共有ができるかできないかも問題です。

さて、リソースのスケーリングです。 「よかった、行きましょう！ そして今、私たちはより速く、より多くを求めています。 え、できないの？ XNUMX年でXNUMX倍の量を届けることは可能ではないでしょうか？ なぜ？" このような成長痛はおそらく多くの物事やアプローチの標準的なものであり、あなたもそれを感じることができます。

モニタリングについて。 サービスや産業用監視ツールはすでに学習しているか、別の非標準モードで Docker と Kubernetes の両方を操作できるようになっているように思えます。 たとえば、これらすべてが実行される、つまり集約される 500 台の Java マシンが存在することになることはありません。 しかし、これらの製品はまだ成熟していないため、これを通過する必要があります。 このトピックは本当に新しいものであり、今後も発展していくでしょう。

ドミトリー：

はい、とても興味深いです。 そしてこれは人事にも当てはまります。 おそらく、あなたの人事プロセスと人事ブランドは、この 3 年間で少し変わったのではないでしょうか。 あなたは、さまざまな能力を持つ他の人材を採用し始めました。 そして、おそらくメリットとデメリットの両方があるでしょう。 以前は、ブロックチェーンとデータサイエンスが誇大広告であり、その専門家には数百万の価値がありました。 現在、コストは低下し、市場は飽和しつつあり、マイクロサービスでも同様の傾向が見られます。

セルゲイ：

そのとおり。

アレクサンダー：

人事部は「ピンクのユニコーンはバックエンドとフロントエンドの間のどこにありますか?」と質問します。 人事部はマイクロサービスが何なのかを理解していません。 私たちは彼らにその秘密を伝え、バックエンドがすべてを行っており、ユニコーンなど存在しないと伝えました。 しかし、人事部門は変化しており、学習が早く、IT の基本知識を持つ人材を採用しています。

マイクロサービスの進化

ドミトリー：

ターゲットのアーキテクチャを見ると、マイクロサービスは非常にモンスターのように見えます。 あなたの旅には数年かかりました。 XNUMX 年の人もいれば、XNUMX 年の人もいます。 すべての問題やターゲット アーキテクチャを予見していましたか?何か変更はありましたか? たとえば、マイクロサービスの場合、ゲートウェイやサービス メッシュが再び登場し始めています。 最初にそれらを使用しましたか、それともアーキテクチャ自体を変更しましたか? そんな課題はありませんか？

セルゲイ：

私たちはすでにいくつかの通信プロトコルを書き直しました。 最初は XNUMX つのプロトコルがありましたが、現在は別のプロトコルに切り替えられています。 安全性と信頼性を高めます。 私たちはエンタープライズ テクノロジ、つまり Oracle、Web Logic から始めました。 現在、私たちはマイクロサービスのテクノロジーエンタープライズ製品から離れ、オープンソースまたは完全にオープンなテクノロジーに移行しています。 私たちはデータベースを放棄し、このモデルでより効果的に機能するものに移行します。 Oracle テクノロジーはもう必要ありません。

どれくらいキャッシュが必要なのか、マイクロサービスと連携していないけどデータが必要になった場合はどうするのかなどは考えず、単純にサービスとしてスタートしました。現在はアーキテクチャを記述できるようにプラットフォームを開発中です。サービス言語ではなく、ビジネス言語で、言葉で話し始めると、ビジネス ロジックを次のレベルに引き上げることができます。 さて、私たちは文字で話すことを学びました。次のレベルは、サービスが何らかの集合体に集められるときです。これはすでに単語になっています。たとえば、製品カード全体です。 マイクロサービスから組み立てられていますが、その上に構築された API です。

安全性は非常に重要です。 アクセスできるようになり、多くの興味深いものを非常に迅速に、瞬時に入手できるサービスが提供されるとすぐに、最も安全ではない方法でそれを入手したいという欲求が生まれます。 これを回避するには、テストとモニタリングのアプローチを変更する必要がありました。 チーム、納品管理構造、CI/CD を変更する必要がありました。

これは進化です。電話と同様に、はるかに速くなりました。最初はプッシュボタン式の電話があり、次にスマートフォンが登場しました。 市場には異なるニーズがあったため、彼らは製品を書き直して再設計しました。 これが私たちが進化する方法です。XNUMX年生、XNUMX年生、そして仕事です。

繰り返し、テクノロジーの観点から毎年何かが策定され、バックログとニーズの観点から何かが策定されます。 私たちはあるものを別のものと結び付けます。 チームは 20% をチームへの技術的負債と技術サポートに費やし、80% を事業体に費やします。 そして私たちは、なぜそれを行うのか、なぜこれらの技術的改善を行うのか、それが何につながるのかを理解しながら行動します。 そのように。

ドミトリー：

いいね。 メガフォンには何が入っているの？

アレクサンダー：

私たちがマイクロサービスに到達したときの主な課題は、混乱に陥らないようにすることでした。 MegaFon の建築事務所がすぐに私たちに加わり、イニシエーター兼推進者にもなりました。今、私たちは非常に強力なアーキテクチャを持っています。 彼の任務は、私たちがどのようなターゲットモデルを目指すのか、そしてどのようなテクノロジーを試験的に導入する必要があるのか​​を理解することでした。 アーキテクチャに関しては、私たちはこれらのパイロットを自分たちで実施しました。

次の質問は、「では、これらすべてをどうやって活用するのでしょうか?」というものでした。 そしてもう XNUMX つは、「マイクロサービス間の透過的な相互作用を確保するにはどうすればよいでしょうか?」 サービス メッシュは、最後の質問に答えるのに役立ちました。 私たちは Istio を試験運用し、結果を気に入りました。 現在、私たちは生産ゾーンに展開する段階にあります。 私たちはすべての課題に対して前向きな姿勢を持っています。つまり、常にスタックを変更し、何か新しいことを学ぶ必要があるという事実です。 私たちは古いソリューションを活用するのではなく、開発することに興味があります。

ドミトリー：

黄金の言葉！ このような課題により、チームとビジネスが常に前進し、未来が創造されます。 GDPR により最高データ保護責任者が創設され、現在の課題により最高マイクロサービス責任者と最高アーキテクチャ責任者が創設されました。 そしてそれは喜ばしいことです。

私たちはたくさん話し合いました。 重要なことは、マイクロサービスとアーキテクチャ自体を適切に設計することで、多くの間違いを回避できるということです。 もちろん、このプロセスは反復的で進化的ですが、それは未来の話です。

参加者全員、セルゲイとアレクサンダーに感謝します。

視聴者からの質問

会場からの質問(1)：

Sergey、あなたの会社の IT 管理はどう変わりましたか? 複数のシステムからなる大規模なスタックがある場合、それをどのように管理するかはかなり明確で論理的なプロセスであることを私は理解しています。 非常に多くのマイクロサービスが短期間に統合された後、IT コンポーネントの管理をどのように再構築しましたか?

セルゲイ：

アーキテクチャは変化の推進力として非常に重要であるという点で、私も同僚の考えに同意します。 私たちは建築部門を持つことから始めました。 建築家は同時に、機能の配分と、それが景観の中でどのように表示されるかという要件の所有者でもあります。 したがって、彼らはこれらの変化の調整役としても機能します。 その結果、CI/CD プラットフォームを作成したときに、特定の配信プロセスに特定の変更が加えられました。

しかし、規格、開発の基本原則、ビジネス分析、テスト、開発はキャンセルされていません。 スピードを加えただけです。 以前は、このサイクルに非常に時間がかかり、テスト環境へのインストールにはさらに多くの時間がかかりました。 現在、企業はそのメリットを認識し、「なぜ他の場所でも同じことができないのか?」と考えています。

良い意味で、これは、「この方法でもできるが、別の方法でもできる」ということを示したワクチンの形の注射のようなものです。 もちろん、人材、能力、知識、抵抗力に問題があります。

会場からの質問(2)：

マイクロサービス アーキテクチャの批評家は、テストと開発が難しいと言います。 物事が複雑になる場合、これは論理的です。 あなたのチームはどのような課題に直面し、どのようにそれらを克服しましたか? 皆さんに質問です。

アレクサンダー：

マイクロサービスからプラットフォームに移行する際には問題がありますが、それらは解決できます。

たとえば、5 ～ 7 個のマイクロサービスで構成される製品を作成しています。 マスター ブランチへの移行にゴーサインを出すには、マイクロサービス スタック全体にわたって統合テストを行う必要があります。 この作業は私たちにとって新しいものではありませんでした。ベンダーがすでに出荷済みのソリューションを提供していたとき、BSS では長い間この作業を行っていました。

そして私たちの問題は小規模なチームにのみ存在します。 5 つの条件付き製品に対して 7 人の QA エンジニアが必要です。 したがって、当社は 2 ～ 3 個のマイクロサービスからなる製品を出荷しており、そのうち XNUMX ～ XNUMX 個はサードパーティによって開発できます。 たとえば、当社の請求システムベンダーである Mail.ru Group と MegaFon R&D が開発中の製品があります。 これを本番環境に出荷する前にテストでカバーする必要があります。 QA エンジニアはこの製品の開発に XNUMX か月半取り組んできましたが、チームの残りのメンバーは彼のサポートを受けられなくなりました。

この複雑さはスケーリングによってのみ引き起こされます。 私たちは、マイクロサービスが孤立した状態では存在できず、完全な分離は存在しないことを理解しています。 2 つのサービスを変更する場合、私たちは常に API コントラクトを維持するよう努めます。 ボンネットの下で何かが変わっても、フロントサービスは残ります。 変更が致命的である場合、ある種のアーキテクチャ変換が行われ、完全に互換性のない完全に異なるデータ メタモデルに移行します。その場合にのみ、vXNUMX サービス API 仕様の登場について話します。 当社は最初のバージョンと XNUMX 番目のバージョンを同時にサポートしており、すべての消費者が XNUMX 番目のバージョンに切り替えた後は、最初のバージョンを閉じるだけです。

セルゲイ：

付け加えたいと思います。 合併症については私も全く同感です。合併症は起こるものです。 状況はますます複雑化しており、諸経費、特にテストにかかる諸経費が増加しています。 これに対処する方法: 自動テストに切り替えます。 はい、自動テストと単体テストの作成に追加投資する必要があります。 そのため、開発者はテストに合格しなければコミットできず、コードを変更することもできませんでした。 そのため、自動テスト、単体テストがなければ、プッシュボタンさえも機能しません。

以前の機能を維持することが重要ですが、これにより追加のオーバーヘッドが発生します。 テクノロジーを別のプロトコルに書き換える場合は、すべてを完全に閉じるまで書き換えることになります。

次から次へと開発を進めているにもかかわらず、開発を止めたくないため、意図的にエンドツーエンドのテストを行わないことがあります。 地形は非常に大きく、複雑で、多くのシステムがあります。 場合によっては、それは単なるスタブです - はい、安全マージンを下げると、より多くのリスクが現れます。 しかし同時に供給を解放します。

アレクサンダー：

はい、自動テストと単体テストを使用すると、高品質のサービスを作成できます。 私たちは、単体テストと統合テストなしでは合格できないパイプラインを支持しています。 すべてのシステムをテスト ゾーンに配置できるわけではないため、エミュレータや商用システムをテスト ゾーンや開発環境にドラッグしなければならないことがよくあります。 さらに、単に濡れるだけではなく、システムから本格的な応答を生成します。 これはマイクロサービスを扱う上で重要な部分であり、私たちもそれに投資しています。 これがなければ混乱が生じます。

会場からの質問(3)：

私の理解する限り、マイクロサービスは当初は別のチームから成長し、現在はこのモデルに存在しています。 その長所と短所は何ですか?

似たような話があります。一種のマイクロサービス ファクトリーが誕生しました。 現在、概念的には、このアプローチをストリームおよびシステムによる生産に拡張するという点に到達しました。 つまり、マイクロサービス、マイクロサービスモデルの集中開発から離れ、システムに近づいてきています。

したがって、私たちの業務はシステムにも及んでいます。つまり、このトピックを分散化しています。 どのようなアプローチで、どのようなストーリーをターゲットにしていますか?

アレクサンダー：

あなたはすぐに「マイクロサービス ファクトリー」という名前を口から出しましたが、私たちもスケールしたいと考えています。 まず、私たちは今、実際に XNUMX つのチームを持っています。 私たちは、MegaFon が持つすべての開発チームに共通のエコシステムで作業する機会を提供したいと考えています。 私たちは、現在ある開発機能をすべて完全に引き継ぎたくはありません。 ローカルなタスクはスケールすることであり、グローバルなタスクはマイクロサービス層のすべてのチームに開発を導くことです。

セルゲイ：

私たちが歩んできた道をお話します。 私たちは本当に XNUMX つのチームとして働き始めましたが、今では私たちは一人ではありません。 私は次のことを支持しています。プロセスの所有者が存在する必要があります。 誰かがマイクロサービス開発プロセスを理解し、管理、制御し、構築する必要があります。 彼はリソースを所有し、リソース管理に従事する必要があります。

テクノロジーや詳細を知り、マイクロサービスの構築方法を理解しているこれらのリソースは、製品チームに配置できます。 当社では、モバイル アプリケーションを作成する製品チームにマイクロサービス プラットフォームの担当者が所属する構成になっています。 彼らはそこにいますが、開発マネージャーとともにマイクロサービス プラットフォーム管理部門のプロセスに従って作業します。 この部門内には、テクノロジーを扱う別のチームがあります。 つまり、共通のリソースプールを私たち自身で混ぜ合わせて分割し、チームに与えます。

同時に、プロセスは一般的で制御されたままであり、単体テストなど、すべてがその上に構築される一般的な技術原則に従って進行します。 製品アプローチのさまざまな部門から収集されたリソースの形式の列が存在する場合があります。

アレクサンダー：

Sergey、あなたは実際にはプロセスの所有者ですよね? タスクのバックログは共有されていますか? その配布の責任は誰にありますか?

セルゲイ：

見てください、これがまたミックスです。 技術的な改善に基づいて形成された未処理の案件があります。これは XNUMX つの話です。 プロジェクトから策定されるバックログと、製品からのバックログがあります。 ただし、各サービス製品への導入順序やこのサービスの作成は、製品の専門家によって開発されます。 彼は IT 部門の一員ではなく、特別にそこから外されました。 しかし、私の部下は間違いなく同じプロセスに従って働いています。

さまざまな方向のバックログ、つまり変更のバックログの所有者は、別の人になります。 技術サービスの接続、その組織原則、これらすべてが IT に組み込まれます。 プラットフォームとリソースも私が所有しています。 一番上にあるのは、バックログと機能変更、そしてこの意味でのアーキテクチャに関するものです。

ある企業が「この機能が欲しいので、新しい商品を作りたい、ローンを作り直したい」と言ったとします。 私たちは「はい、やり直します」と答えます。 アーキテクトはこう言います。「ローンのどこにマイクロサービスを書き、どのように実行するかを考えてみましょう。」 次に、それをプロジェクト、製品、またはテクノロジースタックに分割し、チームに入れて実装します。 社内で製品を作成し、この製品でマイクロサービスを使用することにしましたか? 私たちはこう言います。「これまでのレガシー システム、つまり最前線のシステムは、これらのマイクロサービスに切り替える必要があります。」 アーキテクトは次のように述べています。「つまり、最前線の製品内の技術的なバックログでは、マイクロサービスへの移行が必要です。 行く"。 また、製品スペシャリストやビジネスオーナーは、どれだけの容量が割り当てられるのか、いつ、そしてなぜ割り当てられるのかを理解しています。

議論は終わりましたが、すべてではありません

mailto:CLOUDカンファレンスが開催されました Mail.ru クラウド ソリューション.

その他のイベントも行っております。 @Kubernetes ミートアップ、私たちは常に優れた講演者を探しています:

• Telegram チャンネルで @Kubernetes やその他の @Meetup ニュースをフォローしてください t.me/k8s_mail
• @Meetups で話すことに興味がありますか? リクエストを残す mcs.mail.ru/speak

出所： habr.com