eXp Realty, 엔터프라이즈 마이크로서비스 아키텍처로 전환

메인 컨텐츠로 가기

모든 고객 사례

eXp Realty, 엔터프라이즈 마이크로서비스 아키텍처로 전환

마이크로서비스 아키텍처로 전환하는 것이 언제 합리적일까요? 이는 많은 조직이 민첩해지기 위해 기존 소프트웨어 기술 아키텍처를 평가하면서 갖는 시급한 질문입니다.

부동산은 산업으로서 지역적입니다. 모든 주는 같은 유형의 사업을 하지만 다른 방식으로 합니다. eXp 부동산미국에서 6번째로 큰 부동산 중개업체이자 세계 최초의 클라우드 기반 부동산 회사인 이 회사는 미션 크리티컬 비즈니스 애플리케이션인 eXp Enterprise를 업데이트해야 했습니다.

eXp 에이전트, 계약자 및 직원은 클라우드 기반 애플리케이션인 eXp Enterprise를 사용합니다. 에 개발 Mendix 플랫폼, 온보딩 및 거래 등록과 같은 핵심 비즈니스 활동을 수행합니다. eXp는 처음에 모놀리식 아키텍처 기반으로 앱을 구축했습니다.

그러나 경쟁력을 유지하기 위해 eXp Realty의 엔지니어링 부사장인 Steve Ledwith는 모놀리식 아키텍처에서 마이크로서비스로 애플리케이션을 재구축해야 할 필요성을 파악했습니다. 이 재구축은 eXp가 50개 주에서 사업을 한다는 점을 고려할 때 회사에 엄청난 작업이었지만 비전을 수립하고 모든 이해 관계자의 지지를 얻고 개발자를 활성화함으로써 eXp는 이 비즈니스에 중요한 애플리케이션을 마이크로서비스로 전환했습니다.

기업 수준의 변화 필요성

수년에 걸쳐 eXp는 2,500명의 에이전트에서 18,000명으로 사업을 성장시켰습니다. 그에 따라 eXp Enterprise의 기능, 사용자 기반 및 호스팅 요구 사항도 커져서 많은 기술 부채 Ledwith가 해결해야 할 문제였습니다.

올바른 방법인가, 아니면 지금 당장인가?

출시 당시 eXp Enterprise에는 30개의 기능이 있었습니다. 1,700년도 채 안 되는 기간에 eXp는 2,000명의 사용자가 매일 앱을 사용하는 가운데 XNUMX개의 기능을 앱에 추가했습니다. 그 규모의 사용자 기반에서 이러한 기능을 관리하려면 Ledwith가 "지금 당장" 접근 방식 또는 즉각적인 비즈니스 요구 사항을 충족하기 위한 앱에 대한 임시 개발이라고 부르는 것이 필요했습니다. Ledwith는 이 문제를 가장 잘 요약하여 다음과 같이 말했습니다.

"그래서 올바른 방법으로 하는 대신, 우리는 지금 당장 했고, 많은 의견이 부족했습니다." Ledwith가 말합니다.

데이터베이스 도메인 모델의 경우 Mendix-way는 깨끗한 모델을 규정합니다. 하나 또는 두 개의 엔터티와 모듈. 하지만 에이전트에 대한 정보를 전달하는 eXp의 에이전트 데이터베이스 도메인 모델은 긴밀하게 결합되었습니다.

몇 가지 숫자를 살펴보겠습니다.

  • 데이터베이스의 한 영역에서 eXp는 6,000개가 넘는 연결을 보유했습니다.
  • 에이전트 엔터티는 140개 이상의 속성을 가졌습니다. 모범 사례는 20개입니다.
  • 엔터티에는 계산된 속성이 126,000개 있었습니다. 따라서 사용자가 에이전트 정보를 로드할 때마다 앱은 18,000명의 에이전트에 대해 약 XNUMX개의 필드를 계산했습니다.
  • 부동산 거래에 관련된 프로세스는 다양하며, 문서와 계약서에 서명하는 것부터 규정 준수 추적, 감사 파일 생성 등에 이르기까지 다양합니다. 하루에 약 100건의 거래에 걸쳐 부동산 거래를 처리하는 데 XNUMX~XNUMX분이 걸리므로, eXp는 월요일부터 일요일까지 하루 종일 일하여 이러한 거래를 처리했습니다.

호스팅 과제: 타노스가 온다

eXp Enterprise는 무거운 클라우드 리소스. eXp는 처음에 사용 가능한 가장 큰 컨테이너에 애플리케이션을 호스팅했습니다. Mendix 클라우드 v3. 하루 2,000명의 사용자와 수많은 기능과 기능을 갖추고 있어 곧 용량이 초과되었습니다.

이를 해결하기 위해 eXp는 앱을 가장 큰 컨테이너인 Magneto로 마이그레이션했습니다. Mendix 클라우드 v4. 클라우드 리소스 사용량이 90%일 때 Magneto는 작동하는 듯했습니다. 하지만 eXp도 이 컨테이너를 금세 고갈시켰습니다. 그 후 얼마 지나지 않아, Mendix Ledwith에서 eXp Enterprise와 해당 엔터프라이즈 마이크로서비스 아키텍처를 호스팅하는 데 사용하는 클라우드 컨테이너인 Thanos를 만들었습니다.

클라우드 파운드리 한계를 뛰어넘다

인셀덤 공식 판매점인 Mendix Cloud Foundry를 업그레이드했습니다. Mendix 플랫폼은 모든 면에서 순조롭게 진행되었습니다. Mendix eXp Realty를 제외한 모든 사용자는 Cloud Foundry를 중단했습니다.

eXp는 애플리케이션을 시작하며 기능 수가 많기 때문에 연결, 그리고 사용자 앱이 실패했습니다. Ledwith가 말했듯이, "우리 앱은 스핀업되고, 모든 사용자를 불러들인 다음 크래시되었습니다. 그리고 우리는 앱을 다시 시작했고 그들은 약 2시간마다 다시 했습니다."

Ledwith에 따르면 그가 받은 근본 원인 분석은 Mendix 클라우드 팀은 1,000개의 스레드가 합리적인 것으로 간주되는 수준을 훨씬 넘어섰다고 밝혔습니다. Mendix 플랫폼이므로 테스트에서 걸리지 않았습니다. eXp Enterprise는 최고조에 매일 1,250개의 스레드를 실행했습니다. Ledwith는 스레드 수를 줄이기 위해 애플리케이션 리팩토링을 재고해야 했습니다.

"지금"에서 "올바른 길"로 - 마이크로서비스

약 80명의 개발자로 구성된 엔지니어링 팀(그 중 30명은 정규직 전문가) Mendix 개발자들은 eXp Enterprise의 엄청난 성장을 지원했습니다. eXp는 애플리케이션을 지원하기 위해 팀을 계속 구축할 수 있었지만, 이 프로세스가 확장성과 함께 eXp는 또한 더 많은 클라우드 컨테이너 구매, 리팩토링, 허브 앤 스포크 아키텍처 시도 등 다른 옵션을 시도해 상황을 개선했지만, 어느 것도 장기적인 솔루션이 되지 못했습니다.

경영진은 Ledwith 팀에 2주 동안 연구하고 실행 가능한 솔루션을 제시할 시간을 주었습니다. 그들은 마이크로서비스에 정착했습니다.

올바른 방법 #1 | 참여를 얻으세요

Ledwith와 그의 팀이 기술 인프라를 변경하면서 비즈니스 문제점을 이해하고 이를 해결하는 것이 중요했습니다. 바이인을 얻다 기술 팀이나 경영진뿐만 아니라 엔지니어링, 제품, 해당 분야 전문가를 포함한 팀으로부터도 의견을 구했습니다.

실제로 Ledwith와 그의 팀은 마이크로서비스 아이디어를 다른 사업팀과 교류하는 데 거의 두 달을 보냈습니다. 사업팀의 의견은 Ledwith가 변화가 사업에 진정으로 필요한 것에 집중하고 가치를 제공하는지 확인하는 데 필수적이었습니다.

올바른 길 #2 | XNUMX가지 접근 방식

Ledwith는 마이크로서비스를 구현하기 위해 3가지 전략을 내놓았습니다.

전략적 목표

  • 사업의 규모를 100,000만 명의 에이전트로 확장하고 혁신을 실현하도록 돕습니다.
  • 수천명을 지원하세요 타사 통합 부동산 회사가 중개인에게 판매를 돕기 위해 필요한 고객, 목록 및 재무 데이터를 제공합니다.

건축 원리

  • 건축에 대한 도움말 가이드 통치 복잡성을 줄이고 신속한 개발 및 피드백을 위해 적절한 목적에 적합한 도구를 사용합니다.

디자인 및 배송

  • 공유 코드를 제한하여 다른 팀이 다른 팀에 영향을 미치지 않고 앱의 해당 부분을 변경할 수 있도록 합니다. 다른 팀에 공통적인 것이 있으면 내부 앱 스토어를 사용하여 공통 모듈을 공유합니다.
  • CI/CD 프레임워크를 따르세요.

Right Way #3 | The Innovations Team

eXp는 제품 관리자, 개발자, QA 전문가로 구성된 애자일 기능 팀을 강화하여 비즈니스 구성원을 포함한 혁신 팀을 만들었습니다. 비즈니스 팀은 더 큰 그림을 살펴보기 위해 거기에 있었습니다. 가치를 제공하고, 수익을 늘리고, 이탈을 줄이고, 자동화할 기회를 찾는 방법입니다.

혁신 팀은 개발한 서비스를 소유했습니다. 이제 팀이 프로덕션에 들어갈 때 운영 팀이나 유지 관리 팀에 넘기지 않고 프로덕션과 유지 관리 전반에 걸쳐 소유합니다.

Right Way #4 | 엔터프라이즈 마이크로서비스 마인드셋

Ledwith에 따르면, 올바른 사고방식을 설정하는 것이 재구조화 프로세스 전반에 걸쳐 성공을 위한 가장 중요한 요소였습니다. 실제 비즈니스 가치가 있는 엔터프라이즈급 소프트웨어를 제공하려면 계획, 인재, 입력, 논리가 필요합니다. 피드백그리고 기업이 정말로 필요로 하는 것이 무엇인지에 끊임없이 집중하여 신중하게 실행합니다.

이상의 주제

언어를 선택하세요