マイクロサービスアーキテクチャへの移行





紹介する代わりに



最初のマイクロサービスの開始から数ヶ月が経過しました。そして今、私たちの意見では、得られた経験について話す時が来ました。



この記事に何が含まれ、何が含まれないかについては、すぐに予約する価値があります。この記事では、アーキテクチャのソリューションと、これらの決定の根拠を説明しません。マイクロサービスを作成したテクノロジースタックには焦点を当てません。



この記事の主な焦点は、私たちのチームがプロジェクト全体で直面したグローバルな問題にあります。



この記事は多くの最初のものになります。そして、その目標は、まず第一に、マイクロサービスアーキテクチャへの移行のコンテキストで問題を紹介し、移行の特定の側面を詳細に明らかにする次のトピックにスムーズにつながることです。



すべてが始まった経緯



マイクロサービスアーキテクチャへの切り替えの決定は、約1年半前に行われました。私たちの課題は、当社の急速な成長に備えることでした。技術的なソリューションに関してより柔軟になり、変更を加える速度を上げ、そしてもちろん、システムの復元力を高める必要がありました。 



マイクロサービスアーキテクチャへの切り替えが決定された後、経験豊富で積極的な人たちから別のユニットが作成されました。新しい部門への異動の候補を検討するための決定要因は、1つまたは複数の既存の情報システムに関する高度な専門知識でした。







当時はワークフロントの明確な理解がなかったため、チームはやや自発的に結成されました。しかし同時に、自給自足の原則はすでに確立されていました。チームの開発者、アナリスト、テスターは独自のものを持っている必要があります。



マイクロサービスに切り替えるための戦略として、2つのパスが同時に選択されました。



  1. 私たちはマイクロサービスに(私たちが思っていたように)最も簡単に取り出せるものを取り出します。
  2. マイクロサービスへの移行により、ビジネスとITの両方のほとんどの問題が解決されるマイクロサービスを導入します。


最初の方法は、その過程でチームが必要な専門知識を習得して手を埋めることで、その後の作業の効率が上がるため、良かったです。2番目のパスは、チームに一種の迅速な勝利を提供することでした。これは、会社のマイクロサービスに切り替えるという選択された決定の正しさを示し、チームに新しい偉業をもたらす動機を与えます。



チームは旅の始まりでした。それは幸せな時間でした。未来は明るく雲ひとつないように見え、私たちには計画があるように見えました。



最初の難しさ



そしてもちろん、私たちはマイクロサービスについて話しているので、モノリスについて話さざるを得ません。これらは私たちの主な情報システムです。







私たちの個々のシステムのアーキテクチャは、StefanTilkovによる記事「モノリスから始めないでください」から取られたこの写真によって最もよく示されています。ご覧のとおり、モノリスの機能ブロックは互いに非常に密接に関連しています。これは、個別の機能をマイクロサービスに転送するプロセスにとって深刻な障害です。 



参考までに、私たちのモノリスは約13年前のものであり、平均的なモノリスのコードベースは約120万行です。



言い換えれば、チームは次の問題に何度も直面しました。



  • 既存の機能を分析する非常に時間のかかるプロセス。
  • 多くの場合、マイクロサービスに何をもたらしているのかを正確に理解していない。
  • モノリスを新しいマイクロサービスと統合することの複雑さ。


これらの問題を解決することに加えて、チームは新しいスタックと新しい設計アプローチの専門知識を増やす必要があることを考えると、進歩はそれほど速くは進みませんでした。



それにもかかわらず、数か月後、チームは最初の結果を示し始めました。最初のマイクロサービスは、すべての人にAPIを友好的に提供しました。チームは自分たちを信じ、すべてが正しく行われていることを確信していました。まあ、私たちの生活の中で多くのことはかなり幻想的です。



最初の成功と新たな困難







最初の困難にもかかわらず、チームは新しい経験と最初の結果の両方を受け取りました。しかし、マイクロサービスの開始を妨げるいくつかの説明されていないリスクが発生しました。



  • モノリスは新しいスタックで動作する準備ができておらず、統合が遅れていることが判明しました。
  • - .
  • , , , , .


最初の2つの問題は、モノリスとマイクロサービスを統合する個別のクライアントを作成し、それに応じてモノリス機能を調整することで、非常に簡単に解決されました。しかし、3番目の問題は今日まで完全には解決されていません。



リソースの不整合は、協調的なリソーススケジューリングによって部分的に対処されました。チームはすべての間違いを考慮に入れているようで、何をどのように正しく行うかについて理解があり、2020年の初めまでに、統合と本番環境へのリリースを待って、約12のマイクロサービスが作成されました(一部はまったくマイクロではないことが判明しました)。コストと納期の計算、新しい地域やオフィスの販売サイトへの導入、商品の検索と選択など、ビジネスに不可欠なプロセスのほとんど。



私たちは自信を持って前進し、すでに確かな経験を持ち、多くのバンプを埋めました。私たちはすべての落とし穴に直面しているように見えましたが、今では計画を実行するために、段階的に意図的にしか残っていません。 



上手…



検疫、労働搾取そして最終的に成功



今年の初めに私たちの計画に大幅な調整が加えられました。これは、当時広まった新しいコロナウイルスの影響によるものです。明らかに、何が問題になっているのかを説明する必要はありません。誰もがこのトピックについてすでに多くのことを知っています。



パンデミックの発生とそれに伴う経済危機により、当社は開発の優先順位をわずかに再考することを余儀なくされました。その結果、ITの優先順位が変更されました。新しいタスクが設定され、新しい現実に合わせてビジネスプロセスをすばやく作り直すように設計されました。



この変更は、マイクロサービスの計画にも影響を及ぼしました。リソースの再割り当てにより、マイクロサービスとモノリスの統合、およびその結果、マイクロサービス自体のリリースは再び延期されました。



ここで、最後に、チームで何が起こっていたか、そしてチームがどのように感じたかについて、より詳細に検討する必要があります。







まず、デモティベーション。長い間確固たる結果が得られず、ほぼ1年間、完全に既製の統合されたマイクロサービスが生産されていなかったため、チームは非常に道徳的に燃え尽きました(今期に対してですが、それにもかかわらず)。効率が大幅に低下しました。珍しいことではありませんが、鮮やかな感情的な崩壊。





第二に、検疫とリモートコントロールへの完全な移行。もちろん、私たちはリモートベースでの作業に豊富な経験を持っています。開発者のほぼ2/3はリモートワーカーです。しかし、マイクロサービスに携わったすべての人が同じオフィスで一緒に働いたため、リモート作業への移行はチームの有効性に最善の影響を与えませんでした。一方で、再構築と新しい形式の作業への移行に時間がかかったという事実。一方、チーム内でのより個人的なコミュニケーションと相互支援が必要とされたのは、チームのモチベーションが低下した時期でした。



第三に、チームは結果を示す必要がありました。実際、チーム全体は、内部および外部の問題にもかかわらず、明確に理解していました。企業全体のさらなる運命は、目標をどれだけ迅速に絞り込んで確実な結果を得ることができるかにかかっています。私たちの会社の多くは、マイクロサービスへの切り替えの実験を時期尚早で失敗したものとして認め、部門を解散する準備ができていました。



ほぼ2か月間、チームは12〜15時間、多くの場合週7日働きました。そして、彼女は望ましい目標を達成することができました。完全に機能し、モノリシックシステムと完全に統合された4つのマイクロサービスが、一度に完全に生産されました。 



チームを動機付けるためにトリッキーなテクニックを使用しなかったことに注意することが重要です。共有するノウハウがありません。チームが翌日毎日行っただけです。



  • 仕事の現在のステータスを更新し、新たな問題を迅速に解決するための頻繁なSkype通話。
  • それぞれのリソースの状態を常にチェックしながら、チーム内で前向きな姿勢を維持します。


結果として



結論の代わりに、私たちが自分たちのために作った結論にこだわるつもりです...



  • クロスチーム。このような野心的なプロジェクトを成功させるには、問題を解決するのに十分なリソースを備えた、完全に献身的で自律的なチームが必要です。私たちの場合、これは、新しいスタックでマイクロサービスを作成するチームには、モノリス開発チームのメンバーが必要であることを意味します。これを以前に理解し、このアイデアを最後まで推し進めることができれば、ビジネスプロセスの専門知識が不十分であり、マイクロサービスとモノリスを統合するためのリソースの不整合に関連するミスを回避できたはずです。


image1

  • . , , . . , , , , . .
  • . , . .


間違いの作業を終えた今、私たちは自信を持って言うことができます:ほぼ1年半前に始まった実験は成功したと見なすことができます。そして今、単なる実験のカテゴリーから、マイクロサービスアーキテクチャへの移行プロジェクトは、当社の主要なIT戦略の1つになりつつあります。



将来的には、このトピックに戻り、テクノロジースタック、個々のソリューションなどについて詳しく説明します。十分な資料と経験を蓄積してきました。



All Articles