マイクロサービス アーキテクチャに移行するのはいつが適切でしょうか? これは、より俊敏性を高めるために既存のソフトウェア テクノロジ アーキテクチャを評価する多くの組織が抱える差し迫った問題です。

不動産業は地域密着型の産業です。各州で同じタイプのビジネスが行われていますが、やり方は異なります。 eXp不動産米国で 6 番目に大きな不動産仲介業者であり、世界初のクラウドベースの不動産会社である同社にとって、これはミッションクリティカルなビジネス アプリケーションである eXp Enterprise の更新を意味しました。

eXpのエージェント、請負業者、スタッフは、クラウドベースのアプリケーションであるeXp Enterpriseを使用します。 に基づいて開発された Mendix プラットフォーム、オンボーディングや取引登録などのコアビジネスアクティビティを実行します。eXp は当初、モノリシック アーキテクチャ上にアプリを構築しました。

しかし、競争力を維持するために、eXp Realty のエンジニアリング担当副社長である Steve Ledwith 氏は、アプリケーションをモノリシック アーキテクチャからマイクロサービスに再構築する必要があると認識しました。eXp は全 50 州で事業を展開しているため、この再構築は同社にとって大規模な取り組みとなりましたが、ビジョンを確立し、すべての関係者の賛同を得て、開発者を支援することで、eXp はこのビジネス クリティカルなアプリケーションをマイクロサービスに移行しました。

企業レベルの変革の必要性

eXpは長年にわたり、2,500人のエージェントから18,000人にまで事業を拡大してきました。それに伴い、eXp Enterpriseの機能、ユーザーベース、ホスティング要件も拡大し、 技術的負債 レドウィスが対​​処する必要があった問題。

正しい方法か、それとも今か?

リリース当時、eXp Enterprise には 30 の機能がありました。1,700 年足らずで、eXp は 2,000 の機能をアプリケーションに追加し、毎日 XNUMX 人のユーザーがアプリを使用しました。この規模のユーザーベースでこれらの機能を管理するには、Ledwith 氏が「今すぐ」アプローチと呼ぶもの、つまり、差し迫ったビジネス ニーズを満たすためのアプリのアドホック開発が必要でした。Ledwith 氏は、この問題を次のように要約しています。

「そのため、正しいやり方でやるのではなく、すぐにやってしまったため、多くのインプットが不足していました」とレドウィス氏は言う。

データベースドメインモデルの場合、 Mendix-way は、1 つまたは 2 つのエンティティとモジュールというクリーンなモデルを規定します。しかし、エージェントに関する情報を保持する eXp のエージェント データベース ドメイン モデルは、密に結合されていました。

いくつかの数字を見てみましょう:

• データベースの 6,000 つの領域では、eXp には XNUMX を超える接続がありました。
• エージェント エンティティには 140 を超える属性があります。ベスト プラクティスは 20 です。
• エンティティには 126,000 つの計算属性がありました。そのため、ユーザーがエージェント情報を読み込むたびに、アプリは 18,000 人のエージェントに対して約 XNUMX 個のフィールドを計算しました。
• 不動産取引に関わるプロセスは、文書や契約書への署名から、コンプライアンスの追跡、監査ファイルの生成など多岐にわたります。不動産取引の処理には 100 日あたり約 XNUMX 件の取引があり、XNUMX ～ XNUMX 分で処理する必要があるため、eXp ではこれらの取引の処理のためだけに月曜から日曜まで一日中作業員が働いていました。

ホスティングの課題: サノスがやってくる

eXp Enterpriseは重い クラウドリソースeXpは当初、利用可能な最大のコンテナでアプリケーションをホストしていました。 Mendix Cloud v3。2,000 日あたり XNUMX 人のユーザーと無数の機能により、すぐに容量を超えてしまいました。

この問題を解決するために、eXpはアプリを世界最大のコンテナであるMagnetoに移行しました。 Mendix Cloud v4。クラウドリソースの使用率が90%のとき、Magnetoはうまく機能しているように見えました。しかし、eXpもすぐにこのコンテナを使い果たしました。その後すぐに、 Mendix Ledwith は、eXp Enterprise とそのエンタープライズ マイクロサービス アーキテクチャをホストするために使用するクラウド コンテナーである Thanos を作成しました。

Cloud Foundry の限界を押し上げる

日時 Mendix Cloud Foundryをアップグレードしました Mendix プラットフォームは、すべての Mendix ただし、アプリケーションが Cloud Foundry を破壊した eXp Realty を除くすべてのユーザーが対象です。

eXpはアプリケーションを立ち上げ、機能の数が多いため、 の構築、そしてユーザーにとって、アプリは失敗します。Ledwith 氏は次のように語っています。「アプリケーションが起動し、すべてのユーザーがそれを使用するようになりますが、その後クラッシュします。そして、約 2 時間ごとに再起動し、それを繰り返します。」

レドウィス氏によると、彼が受け取った根本原因分析は Mendix クラウドチームは、1,000スレッドは、 Mendix プラットフォームであるため、テストでは検出されませんでした。eXp Enterprise では、ピーク時には毎日 1,250 スレッドが稼働していました。Ledwith は、スレッド数を減らすためにアプリケーションのリファクタリングを再検討する必要がありました。

「今すぐ」から「正しい方法」へ — マイクロサービス

約80名の開発者からなるエンジニアリングチーム（うち30名はフルタイムのプロフェッショナル） Mendix 開発者は、eXp Enterpriseの急成長を支えました。eXpはアプリケーションをサポートするためにチームを構築し続けることもできましたが、すぐにこのプロセスは適切ではないことに気付きました。 ド電源のデeXp は、状況を改善するために、クラウド コンテナの追加購入、リファクタリング、ハブ アンド スポーク アーキテクチャの試行などの他のオプションも試しましたが、いずれも長期的な解決策とはなりませんでした。

経営陣は、Ledwith 氏のチームに 2 週間の調査期間を与え、実行可能なソリューションを提案しました。彼らはマイクロサービスを選択しました。

正しい方法 #1 | 賛同を得る

レドウィスと彼のチームが技術インフラを変更する際、ビジネスの問題点を理解し、 賛同を得る 技術チームや経営陣だけでなく、エンジニアリング、製品、各分野の専門家を含むチームからも協力を得ています。

実際、Ledwith 氏と彼のチームは、マイクロサービスのアイデアをさまざまなビジネス チームに広めるのにほぼ 2 か月を費やしました。ビジネス チームの意見は、Ledwith 氏にとって、変更がビジネスに本当に必要なものと価値をもたらすものに重点を置くようにするために不可欠でした。

正しい方法 #2 | XNUMXつのアプローチ

Ledwith 氏は、マイクロサービスを実装するための 3 つの戦略を考案しました。

戦略目標

• ビジネスを 100,000 エージェントまで拡大し、イノベーションを実現できるよう支援します。
• 何千もの サードパーティの統合 不動産会社がエージェントの販売を支援するために必要な顧客、物件情報、財務データ。

アーキテクチャの原則

• 建築に関するヘルプガイド ガバナンス 複雑さを軽減し、適切なツールを適切な目的に使用して迅速な開発とフィードバックを実現します。

設計と納品

• 共有コードを制限することで、異なるチームが他のチームに影響を与えることなくアプリの担当部分を変更できるようにします。他のチームに共通する部分がある場合は、社内アプリ ストアを使用して共通モジュールを共有します。
• CI/CD フレームワークに従います。

正しい方法 #3 | イノベーションチーム

eXp は、製品マネージャー、開発者、QA スペシャリストで構成されるアジャイル機能チームを強化し、ビジネス部門のメンバーを含むイノベーション チームを作成しました。ビジネス チームは、価値の提供方法、収益の増加、解約の削減、自動化の機会の模索など、全体像を把握するために存在しました。

イノベーション チームは、自分たちが開発したサービスを所有していました。現在、チームが本番環境に移行すると、運用チームや保守チームに引き継ぐ必要はなく、むしろ本番環境と保守環境全体を通じてサービスを所有することになります。

正しい方法 #4 | エンタープライズ マイクロサービスの考え方

レドウィス氏によると、正しい考え方を設定することが、再構築プロセス全体を通じて成功するための最も重要な要素でした。真のビジネス価値を持つエンタープライズクラスのソフトウェアの提供には、計画、才能、入力、論理、 フィードバックビジネスに本当に必要なものに常に焦点を当てて、慎重に実行します。