Dodo IS 아키텍처의 역사: 초기 모놀리스

또는 모놀리스를 가진 모든 불행한 회사는 나름대로 불행합니다.

Dodo IS 시스템의 개발은 도도피자 사업처럼 2011년에 바로 시작되었습니다. 그것은 비즈니스 프로세스의 완전하고 총체적인 디지털화라는 아이디어를 기반으로했으며 그들 스스로, 2011년에도 많은 질문과 회의론을 불러일으켰습니다. 그러나 9년 동안 우리는 단일체에서 시작된 자체 개발을 통해 이 길을 따라왔습니다.

이 기사는 "아키텍처를 다시 작성하고 대규모 및 장기적 변경을 수행하는 이유는 무엇입니까?"라는 질문에 대한 "답변"입니다. 이전 기사로 돌아가기 "Dodo IS Architecture의 역사: 백오피스의 길". Dodo IS의 개발이 어떻게 시작되었는지, 원래 아키텍처가 어떻게 생겼는지, 새로운 모듈이 어떻게 등장했는지, 어떤 문제로 인해 대규모 변경이 이루어져야 했는지부터 시작하겠습니다.

일련의 기사 "Dodo IS는 무엇입니까?" 다음에 대해 알려줍니다.

1. Dodo IS의 초기 단일체(2011-2015). (당신은 여기)

2. 백오피스 경로: 베이스와 버스 분리.

3. 클라이언트 쪽 경로: 베이스 위의 정면(2016-2017). (진행중...)

4. 진정한 마이크로서비스의 역사. (2018-2019). (진행중...)

5. 모놀리스 톱질 완료 및 아키텍처 안정화. (진행중...)

초기 아키텍처

2011년 Dodo IS 아키텍처는 다음과 같았습니다.

아키텍처의 첫 번째 모듈은 주문 수락입니다. 비즈니스 프로세스는 다음과 같습니다.

• 고객이 피자 가게에 전화를 겁니다.

• 매니저가 전화를 받습니다.

• 전화로 주문을 수락합니다.

• 주문 수락 인터페이스에서 병렬로 입력합니다. 클라이언트에 대한 정보, 주문 세부 정보 데이터, 배송 주소를 고려합니다. 

정보 시스템의 인터페이스는 이렇게 생겼습니다 ...

2011년 XNUMX월의 첫 번째 버전:

2012년 XNUMX월에 약간 개선됨

도도피자 정보시스템 배달 피자 전문점

첫 번째 주문 접수 모듈 개발을 위한 리소스는 제한적이었습니다. 우리는 소규모 팀으로 많은 일을 신속하게 처리해야 했습니다. 소규모 팀은 전체 미래 시스템의 기반을 마련한 2명의 개발자입니다.

그들의 첫 번째 결정은 기술 스택의 운명을 결정했습니다.

• ASP.NET MVC, C# 언어의 백엔드. 개발자들은 dotnetchiki였고, 이 스택은 그들에게 친숙하고 즐거웠습니다.

• Bootstrap 및 JQuery의 프런트엔드: 자체 작성 스타일 및 스크립트의 사용자 인터페이스. 

• MySQL 데이터베이스: 라이선스 비용이 없고 사용하기 쉽습니다.

• Windows Server의 서버. .NET은 Windows에만 있을 수 있기 때문입니다(Mono에 대해서는 논의하지 않음).

물리적으로이 모든 것이 "호스터의 헌신"으로 표현되었습니다. 

주문 접수 애플리케이션 아키텍처

그런 다음 모두가 이미 마이크로 서비스에 대해 이야기하고 있었고 SOA는 5년 동안 대규모 프로젝트에 사용되었습니다. 예를 들어 WCF는 2006년에 출시되었습니다. 그러나 그들은 신뢰할 수 있고 검증된 솔루션을 선택했습니다.

여기 있습니다.

Asp.Net MVC는 양식 또는 클라이언트의 요청에 따라 서버 렌더링으로 HTML 페이지를 렌더링하는 Razor입니다. 클라이언트에서 CSS 및 JS 스크립트는 이미 정보를 표시하고 필요한 경우 JQuery를 통해 AJAX 요청을 수행합니다.

서버의 요청은 *Controller 클래스에서 끝나고 최종 HTML 페이지의 처리 및 생성은 메소드에서 발생합니다. 컨트롤러는 *Services라는 논리 계층에 요청합니다. 각 서비스는 비즈니스의 일부 측면에 해당합니다.

• 예를 들어 DepartmentStructureService는 부서에 대한 피자 가게에 대한 정보를 제공했습니다. 부서는 단일 프랜차이즈가 운영하는 피자 가게 그룹입니다.

• ReceivingOrdersService는 주문 구성을 수락하고 계산했습니다.

• 그리고 SmsService는 SMS를 보내기 위해 API 서비스를 호출하여 SMS를 보냈습니다.

서비스는 데이터베이스에서 데이터를 처리하고 비즈니스 로직을 저장합니다. 각 서비스에는 적절한 이름을 가진 하나 이상의 *저장소가 있습니다. 여기에는 이미 데이터베이스의 저장 프로시저에 대한 쿼리와 매퍼 계층이 포함되어 있습니다. 저장소에는 비즈니스 논리가 있었고 특히 보고 데이터를 발행한 저장소에는 비즈니스 논리가 많았습니다. ORM은 사용되지 않았고 모두 손으로 작성한 SQL에 의존했습니다. 

예를 들어 주문을 저장하는 주문 클래스와 같은 도메인 모델 및 공통 도우미 클래스의 계층도 있었습니다. 같은 위치의 레이어에는 선택한 통화에 따라 표시 텍스트를 변환하는 도우미가 있습니다.

이 모든 것은 다음과 같은 모델로 나타낼 수 있습니다.

주문 방법

이러한 주문을 생성하는 간단한 초기 방법을 고려하십시오.

처음에 사이트는 정적이었습니다. 가격이 적혀 있었고 그 위에는 전화 번호와 "피자를 원하시면 전화를 걸어 주문하세요"라는 문구가 적혀있었습니다. 주문하려면 간단한 흐름을 구현해야 합니다. 

• 클라이언트는 가격이 있는 정적 사이트를 방문하여 제품을 선택하고 사이트에 나열된 번호로 전화를 겁니다.

• 고객은 주문에 추가하려는 제품의 이름을 지정합니다.

• 그의 주소와 이름을 알려줍니다.

• 교환원이 주문을 수락합니다.

• 주문은 승인된 주문 인터페이스에 표시됩니다.

모든 것은 메뉴를 표시하는 것으로 시작됩니다. 로그인한 사용자 운영자는 한 번에 하나의 주문만 수락합니다. 따라서 드래프트 카트는 자신의 세션에 저장할 수 있습니다(사용자 세션은 메모리에 저장됨). 제품 및 고객 정보를 포함하는 Cart 개체가 있습니다.

고객이 제품 이름을 지정하면 운영자가 클릭합니다. + 제품 옆에 있고 요청이 서버로 전송됩니다. 제품에 대한 정보가 데이터베이스에서 추출되고 제품에 대한 정보가 카트에 추가됩니다.

주의. 예, 여기에서는 데이터베이스에서 제품을 가져올 수 없지만 프런트엔드에서 전송할 수 있습니다. 그러나 명확성을 위해 데이터베이스의 경로를 정확히 보여주었습니다. 

그런 다음 클라이언트의 주소와 이름을 입력하십시오. 

"주문 생성"을 클릭하면:

• 요청은 OrderController.SaveOrder()로 전송됩니다.

• 세션에서 카트를 가져오고 필요한 수량의 제품이 있습니다.

• 클라이언트에 대한 정보로 Cart를 보완하고 ReceivingOrderService 클래스의 AddOrder 메서드로 전달하여 데이터베이스에 저장합니다. 

• 데이터베이스에는 주문, 주문 구성, 클라이언트가 있는 테이블이 있으며 모두 연결되어 있습니다.

• 주문 표시 인터페이스는 최신 주문을 꺼내서 표시합니다.

새 모듈

주문을 받는 것은 중요하고 필요했습니다. 판매 주문이 없으면 피자 장사를 할 수 없습니다. 따라서 시스템은 대략 2012년부터 2015년까지 기능을 획득하기 시작했습니다. 이 기간 동안 시스템의 다양한 블록이 나타났습니다. 모듈, 서비스 또는 제품의 개념과 반대입니다. 

모듈은 일부 공통 비즈니스 목표로 통합된 기능 세트입니다. 동시에 물리적으로 동일한 애플리케이션에 있습니다.

모듈은 시스템 블록이라고 할 수 있습니다. 예를 들어 이것은 보고 모듈, 관리 인터페이스, 부엌에서 음식 추적기, 승인. 이들은 모두 다른 사용자 인터페이스이며 일부는 시각적 스타일도 다릅니다. 동시에 모든 것이 하나의 애플리케이션, 하나의 실행 중인 프로세스의 프레임워크 내에 있습니다. 

기술적으로 모듈은 Area로 설계되었습니다(이러한 아이디어는 asp.net 코어). 프런트엔드, 모델 및 자체 컨트롤러 클래스에 대한 별도의 파일이 있습니다. 결과적으로 시스템이 이것에서 변형되었습니다 ...

...이것으로:

일부 모듈은 완전히 분리된 기능과 부분적으로는 약간 분리되고 더 집중된 개발로 인해 별도의 사이트(실행 가능한 프로젝트)에서 구현됩니다. 이것:

• 사이트 - 첫 번째 버전 사이트 dodopizza.ru.

• 수출: Dodo IS에서 1C에 대한 보고서 업로드. 

• 개인 - 직원의 개인 계정. 별도로 개발되어 자체 진입점과 별도의 디자인이 있습니다.

• fs — 정적 호스팅을 위한 프로젝트. 나중에 우리는 모든 스태틱을 Akamai CDN으로 옮기면서 그것에서 멀어졌습니다. 

나머지 블록은 BackOffice 애플리케이션에 있었습니다. 

이름 설명:

• 출납원 - 식당 출납원.

• ShiftManager - "Shift Manager" 역할을 위한 인터페이스: 피자 가게 판매에 대한 운영 통계, 중지 목록에 제품을 넣는 기능, 주문 변경.

• OfficeManager - "Pizzeria Manager" 및 "Franchisee" 역할을 위한 인터페이스. 다음은 피자 가게 설정, 보너스 프로모션, 직원 수신 및 작업, 보고서에 대한 수집된 기능입니다.

• PublicScreens - 피자 가게에 걸려 있는 TV 및 태블릿용 인터페이스. TV는 배달 시 메뉴, 광고 정보, 주문 상태를 표시합니다. 

공통 서비스 계층, 공통 Dodo.Core 도메인 클래스 블록 및 공통 기반을 사용했습니다. 때때로 그들은 여전히 ​​서로의 전환을 따라갈 수 있습니다. dodopizza.ru 또는 personal.dodopizza.ru와 같은 개별 사이트를 포함하여 일반 서비스로 이동했습니다.

새로운 모듈이 등장했을 때 우리는 이미 생성된 서비스 코드, 저장 프로시저 및 테이블을 데이터베이스에 최대한 재사용하려고 했습니다. 

시스템에서 만들어진 모듈의 규모를 더 잘 이해하기 위해 다음은 개발 계획이 있는 2012년 다이어그램입니다.

2015년까지 모든 것이 지도에 표시되었고 더 많은 것이 생산되었습니다.

• 주문 수락은 운영자가 주문을 수락하는 별도의 Contact Center 블록으로 성장했습니다.

• 피자가게에는 메뉴와 정보가 걸려 있는 공개 스크린이 있었습니다.

• 주방에는 새 주문이 도착하면 "New Pizza"라는 음성 메시지를 자동으로 재생하고 택배 송장도 인쇄하는 모듈이 있습니다. 이것은 주방의 프로세스를 크게 단순화하고 직원이 많은 간단한 작업으로 인해 산만해지지 않도록 합니다.

• 배송 단위는 별도의 배송 체크아웃이 되어 이전에 교대 근무를 맡은 택배사에게 주문이 발행되었습니다. 그의 근무 시간은 급여 계산에 고려되었습니다. 

병행하여 2012년부터 2015년까지 10명 이상의 개발자가 등장하고 35개의 피자 가게가 문을 열었으며 시스템을 루마니아에 배포하고 미국의 매장 오픈을 준비했습니다. 개발자는 더 이상 모든 작업을 처리하지 않고 팀으로 나뉩니다. 각각은 시스템의 자체 부분에 특화되어 있습니다. 

문제

아키텍처 때문에 포함됩니다(뿐만 아니라).

기지의 혼돈

하나의 기반이 편리합니다. 일관성은 관계형 데이터베이스에 내장된 도구를 희생하여 달성할 수 있습니다. 특히 테이블이 적고 데이터가 적은 경우 작업이 익숙하고 편리합니다.

그러나 4년이 넘는 개발 기간 동안 데이터베이스에는 약 600개의 테이블과 1500개의 저장 프로시저가 있는 것으로 밝혀졌으며 그 중 다수는 논리도 포함했습니다. 아아, 저장 프로시저는 MySQL로 작업할 때 많은 이점을 제공하지 않습니다. 베이스에 의해 캐시되지 않으며 논리를 저장하면 개발 및 디버깅이 복잡해집니다. 코드 재사용도 어렵습니다.

많은 테이블에 적절한 인덱스가 없습니다., 반대로 어딘가에 색인이 많아서 삽입하기 어려웠습니다. 약 20개의 테이블을 수정해야 했습니다. 주문을 생성하는 트랜잭션은 약 3-5초가 소요될 수 있습니다. 

테이블의 데이터가 항상 가장 적절한 형식은 아니었습니다.. 어딘가에 비정규화가 필요했습니다. 정기적으로 수신되는 데이터 중 일부가 XML 구조 형태의 컬럼에 있어 실행 시간이 늘어나고 쿼리가 길어지며 개발이 복잡해졌습니다.

같은 테이블에 매우 생산되었습니다 이기종 요청. 인기 있는 테이블은 위에서 언급한 테이블과 같이 특히 어려움을 겪었습니다. 명령 또는 테이블 피자집. 주방, 분석에 운영 인터페이스를 표시하는 데 사용되었습니다. 다른 사이트에서 그들에게 연락했습니다(dodopizza.ru), 주어진 시간에 갑자기 많은 요청이 올 수 있습니다. 

데이터가 집계되지 않았습니다. 베이스를 사용하여 많은 계산이 즉석에서 이루어졌습니다. 이로 인해 불필요한 계산과 추가 부하가 발생했습니다. 

그렇게 할 수 없을 때 종종 코드가 데이터베이스로 이동했습니다. 대량 작업이 충분하지 않은 곳, 속도를 높이고 안정성을 높이기 위해 코드를 통해 하나의 요청을 여러 요청으로 분산해야 하는 곳이 있습니다. 

코드의 결합 및 난독화

비즈니스의 일부를 담당해야 하는 모듈이 정직하게 수행하지 않았습니다.. 그들 중 일부는 역할에 대한 기능이 중복되었습니다. 예를 들어, 그의 도시에서 네트워크의 마케팅 활동을 담당하는 지역 마케터는 "관리자" 인터페이스(프로모션 생성)와 "사무실 관리자" 인터페이스(프로모션이 비즈니스에 미치는 영향 보기)를 모두 사용해야 했습니다. 물론 두 모듈 내부에는 보너스 프로모션과 함께 작동하는 동일한 서비스가 사용되었습니다.

서비스(하나의 모놀리식 대형 프로젝트 내의 클래스)는 데이터를 보강하기 위해 서로를 호출할 수 있습니다.

데이터를 저장하는 모델 클래스 자체로 코드 작업이 다르게 수행되었습니다.. 어딘가에 필수 필드를 지정할 수 있는 생성자가 있었습니다. 어딘가에서 이것은 공공 재산을 통해 이루어졌습니다. 물론 데이터베이스에서 데이터를 가져오고 변환하는 것은 다양했습니다. 

논리는 컨트롤러나 서비스 클래스에 있었습니다. 

사소한 문제인 것 같지만 개발 속도가 크게 느려지고 품질이 저하되어 불안정성과 버그가 발생했습니다. 

대규모 개발의 복잡성

개발 자체에 어려움이 생겼습니다.. 시스템의 다른 블록을 병렬로 만드는 것이 필요했습니다. 각 구성 요소의 요구 사항을 단일 코드에 맞추는 것이 점점 더 어려워졌습니다. 동의하고 동시에 모든 구성 요소를 기쁘게하는 것은 쉽지 않았습니다. 여기에는 특히 베이스 및 프런트엔드와 관련하여 기술의 한계가 추가되었습니다. 특히 클라이언트 서비스(웹 사이트) 측면에서 jQuery를 고수준 프레임워크 쪽으로 포기해야 했습니다.

시스템의 일부에서는 이에 더 적합한 데이터베이스를 사용할 수 있습니다.. 예를 들어 나중에 주문 바구니를 저장하기 위해 Redis에서 CosmosDB로 이동하는 사용 사례가 있었습니다. 

해당 분야에 관련된 팀과 개발자는 개발 및 롤아웃 측면에서 서비스에 대한 더 많은 자율성을 분명히 원했습니다. 충돌을 병합하고 문제를 해제합니다. 5 명의 개발자에게이 문제가 중요하지 않다면 10 명, 계획된 성장으로 인해 모든 것이 더 심각해질 것입니다. 그리고 앞으로는 모바일 애플리케이션의 개발이었습니다(2017년에 시작하여 2018년에 큰 가을). 

시스템의 다른 부분에는 다른 수준의 안정성이 필요했습니다.하지만 시스템의 강력한 연결성으로 인해 이를 제공할 수 없었습니다. 코드가 일반적이고 재사용 가능하고 데이터베이스와 데이터도 동일하기 때문에 관리자 패널에서 새 기능을 개발할 때 오류가 사이트에서 주문을 수락할 때 발생할 수 있습니다.

이러한 모놀리식 모듈식 아키텍처의 프레임워크 내에서 이러한 실수와 문제를 피할 수 있을 것입니다. 책임을 나누고, 코드와 데이터베이스를 모두 리팩토링하고, 레이어를 서로 명확하게 분리하고, 매일 품질을 모니터링합니다. 그러나 선택한 아키텍처 솔루션과 시스템 기능의 급속한 확장에 대한 집중은 안정성 측면에서 문제를 야기했습니다.

Power of the Mind 블로그가 식당에 금전 등록기를 설치한 방법

피자 가게 네트워크(및 부하)의 성장이 같은 속도로 계속된다면 잠시 후 시스템이 상승하지 않을 정도로 하락할 것입니다. 2015년까지 우리가 직면하기 시작한 문제를 잘 보여줍니다. 여기에 그러한 이야기가 있습니다. 

블로그에서 "마인드 파워”는 전체 네트워크의 연간 수익 데이터를 보여주는 위젯이었습니다. 위젯은 이 데이터를 제공하는 Dodo 공개 API에 액세스했습니다. 이 통계는 현재 http://dodopizzastory.com/. 위젯은 모든 페이지에 표시되었으며 20초마다 타이머에 요청을 했습니다. 요청은 api.dodopizza.ru로 이동하여 다음을 요청했습니다.

• 네트워크에 있는 피자 가게의 수;

• 연초 이후 총 네트워크 수익

• 오늘의 수익.

수익에 대한 통계 요청은 바로 데이터베이스로 이동하여 주문에 대한 데이터를 요청하고 즉시 데이터를 집계하여 금액을 제공하기 시작했습니다. 

레스토랑의 현금 데스크는 동일한 주문 테이블로 이동하여 오늘 받은 주문 목록을 언로드하고 새 주문을 추가했습니다. 금전 등록기는 5초마다 또는 페이지를 새로 고칠 때마다 요청을 했습니다.

다이어그램은 다음과 같습니다.

어느 가을, Fyodor Ovchinnikov는 자신의 블로그에 길고 인기 있는 기사를 썼습니다. 많은 사람들이 블로그에 와서 모든 것을주의 깊게 읽기 시작했습니다. 찾아온 사람들이 각자 글을 읽는 동안 수익 위젯이 제대로 작동했고 20초마다 API를 요청했다.

API는 체인의 모든 피자 가게에 대한 연초 이후의 모든 주문 합계를 계산하기 위해 저장 프로시저를 호출했습니다. 집계는 매우 인기 있는 주문 테이블을 기반으로 했습니다. 당시 열려있는 모든 레스토랑의 모든 현금 데스크가 여기에 있습니다. 현금 데스크가 응답을 멈추고 주문이 수락되지 않았습니다. 그들은 또한 사이트에서 승인되지 않았고 추적기에 나타나지 않았으며 교대 근무 관리자는 인터페이스에서 볼 수 없었습니다. 

이것은 유일한 이야기가 아닙니다. 2015년 가을까지 매주 금요일 시스템의 부하가 심각했습니다. 여러 번 공개 API를 껐고 한 번은 도움이 되지 않았기 때문에 사이트를 꺼야 했습니다. 과부하 상태에서 종료 명령이 있는 서비스 목록도 있었습니다.

이제부터 부하와 시스템 안정화를 위한 투쟁이 시작됩니다(2015년 가을부터 2018년 가을까지). 그때 일이 생겼어"큰 가을". 또한 때때로 고장이 발생했고 일부는 매우 민감했지만 이제 일반적인 불안정 기간은 지난 것으로 간주할 수 있습니다.

빠른 비즈니스 성장

왜 바로 할 수 없었습니까? 다음 차트를 보십시오.

또한 2014-2015년에는 루마니아에서 오프닝이 있었고 미국에서 오프닝이 준비 중이었습니다.

네트워크는 매우 빠르게 성장하고 새로운 국가가 열렸으며 새로운 형식의 피자 가게가 나타났습니다. 예를 들어 푸드 코트에 피자 가게가 열렸습니다. 이 모든 것은 특히 Dodo IS 기능의 확장에 상당한 주의를 요했습니다. 이러한 모든 기능이 없다면, 주방에서의 추적, 시스템의 제품 및 손실 계산, 푸드 코트 홀의 주문 발행 표시 없이는 "올바른" 아키텍처와 "올바른" 접근 방식에 대해 거의 이야기하지 않을 것입니다. 지금 개발.

적시에 아키텍처를 수정하고 기술적 문제에 대한 일반적인 관심을 가로막는 또 다른 장애물은 2014년의 위기였습니다. 이와 같은 상황은 팀이 성장할 수 있는 기회, 특히 Dodo Pizza와 같은 젊은 비즈니스에 큰 타격을 주었습니다.

도움이 되는 빠른 솔루션

문제는 해결책이 필요했습니다. 일반적으로 솔루션은 두 그룹으로 나눌 수 있습니다.

• 화재를 진압하고 약간의 안전 여유를 제공하며 변화할 시간을 벌어주는 빠른 것.

• 체계적이고 따라서 길다. 여러 모듈의 리엔지니어링, 모 놀리 식 아키텍처를 별도의 서비스로 분할 (대부분은 마이크로가 아니라 매크로 서비스이며 그것에 대해 뭔가가 있습니다. Andrey Morevskiy의 보고서). 

빠른 변경 목록은 다음과 같습니다.

베이스 마스터 확장

물론 부하를 처리하기 위해 가장 먼저 하는 일은 서버의 용량을 늘리는 것이다. 이것은 마스터 데이터베이스와 웹 서버에 대해 수행되었습니다. 아아, 이것은 특정 한도까지만 가능하며 너무 비쌉니다.

2014년부터 Azure로 전환했으며 당시 "Dodo Pizza가 Microsoft Azure 클라우드를 사용하여 피자를 배달하는 방법". 하지만 거점용 서버를 연달아 증설한 뒤 비용과 맞닥뜨렸다. 

읽기용 기본 복제본

베이스용으로 두 개의 복제본이 만들어졌습니다.

읽기복제본 참조 요청. 디렉토리, 유형, 도시, 거리, 피자 가게, 제품(천천히 변경된 도메인) 및 약간의 지연이 허용되는 인터페이스를 읽는 데 사용됩니다. 이 복제본 중 2개가 있었고 마스터와 동일한 방식으로 가용성을 보장했습니다.

보고서 요청을 위한 ReadReplica. 이 데이터베이스는 가용성이 낮았지만 모든 보고서가 이 데이터베이스로 이동했습니다. 대규모 데이터 재계산에 대한 과도한 요청을 허용하되 기본 데이터베이스 및 운영 인터페이스에는 영향을 미치지 않습니다. 

코드의 캐시

코드 어디에도 캐시가 없었습니다. 이로 인해 항상 필요한 것은 아니지만 로드된 데이터베이스에 대한 추가 요청이 발생했습니다. 캐시는 먼저 인 메모리와 Redis라는 외부 캐시 서비스에 있었습니다. 시간이 지남에 따라 모든 것이 무효화되고 설정이 코드에 지정되었습니다.

여러 백엔드 서버

증가된 워크로드를 처리하기 위해 애플리케이션의 백엔드도 확장해야 했습니다. 하나의 iis-server에서 클러스터를 만드는 것이 필요했습니다. 우리는 일정을 변경했습니다 신청 세션 메모리에서 RedisCache로 전환하여 라운드 로빈으로 간단한 로드 밸런서 뒤에 여러 서버를 만들 수 있었습니다. 처음에는 동일한 Redis를 캐시로 사용하다가 여러 개로 분할했습니다. 

결과적으로 아키텍처가 더 복잡해졌습니다 ...

...하지만 긴장의 일부가 제거되었습니다.

그런 다음 우리가 수행한 로드된 구성 요소를 다시 실행해야 했습니다. 다음 부분에서 이에 대해 이야기하겠습니다.

출처 : habr.com