헤이 하브르!

코로나바이러스로 인한 현 상황을 고려하여 다수의 인터넷 서비스의 부하가 증가하기 시작했습니다. 예를 들어, 영국 소매 체인 중 하나가 온라인 주문 사이트를 중단했습니다., 용량이 부족했기 때문입니다. 그리고 단순히 더 강력한 장비를 추가한다고 해서 서버 속도를 높이는 것이 항상 가능한 것은 아니지만 클라이언트 요청을 처리해야 합니다(그렇지 않으면 경쟁업체로 이동하게 됩니다).

이 기사에서는 빠르고 내결함성이 있는 서비스를 만들 수 있는 널리 사용되는 방법에 대해 간략하게 설명하겠습니다. 하지만 가능한 개발 방안 중에서 현재 가능한 것만 선택했습니다. 사용하기 쉬운. 각 항목에 대해 기성 라이브러리가 있거나 클라우드 플랫폼을 사용하여 문제를 해결할 수 있는 기회가 있습니다.

수평적 확장

가장 간단하고 가장 잘 알려진 점입니다. 일반적으로 가장 일반적인 두 가지 부하 분산 방식은 수평 확장과 수직 확장입니다. 첫 번째 경우 서비스가 병렬로 실행되도록 허용하여 서비스 간에 로드를 분산시킵니다. 두 번째 더 강력한 서버를 주문하거나 코드를 최적화합니다.

예를 들어, OwnCloud, OneDrive 등과 유사한 추상 클라우드 파일 저장소를 사용하겠습니다.

이러한 회로의 표준 그림은 아래에 있지만 시스템의 복잡성만 보여줍니다. 결국 우리는 어떻게든 서비스를 동기화해야 합니다. 사용자가 태블릿에서 파일을 저장한 다음 휴대폰에서 이를 보려면 어떻게 됩니까?

접근 방식의 차이점은 수직적 확장에서는 노드의 성능을 높일 준비가 되어 있고, 수평적 확장에서는 부하를 분산하기 위해 새 노드를 추가할 준비가 되어 있다는 것입니다.

CQRS

명령 쿼리 책임 분리 상당히 중요한 패턴입니다. 다양한 클라이언트가 다양한 서비스에 연결할 수 있을 뿐만 아니라 동일한 이벤트 스트림을 수신할 수 있기 때문입니다. 간단한 애플리케이션의 경우 그 이점이 그다지 명확하지 않지만 바쁜 서비스의 경우 매우 중요하고 간단합니다. 그 본질은 들어오고 나가는 데이터 흐름이 교차해서는 안 된다는 것입니다. 즉, 요청을 보내고 응답을 기대할 수 없으며, 대신 서비스 A에 요청을 보내고 서비스 B로부터 응답을 받습니다.

이 접근 방식의 첫 번째 보너스는 긴 요청을 실행하는 동안 연결을 끊는 기능(넓은 의미에서)입니다. 예를 들어, 다소 표준적인 시퀀스를 살펴보겠습니다.

1. 클라이언트가 서버에 요청을 보냈습니다.
2. 서버가 긴 처리 시간을 시작했습니다.
3. 서버는 결과로 클라이언트에 응답했습니다.

지점 2에서 연결이 끊어졌다고 가정해 보겠습니다(또는 네트워크가 다시 연결되거나 사용자가 다른 페이지로 이동하여 연결이 끊어짐). 이 경우 서버에서 정확히 어떤 작업이 처리되었는지에 대한 정보가 포함된 응답을 사용자에게 보내기가 어렵습니다. CQRS를 사용하면 순서가 약간 다릅니다.

1. 클라이언트가 업데이트를 구독했습니다.
2. 클라이언트가 서버에 요청을 보냈습니다.
3. 서버가 "요청 수락됨"이라고 응답했습니다.
4. 서버는 "1" 지점의 채널을 통해 결과로 응답했습니다.

보시다시피, 계획은 조금 더 복잡합니다. 더욱이 여기에는 직관적인 요청-응답 접근 방식이 없습니다. 그러나 보시다시피 요청을 처리하는 동안 연결이 끊어져도 오류가 발생하지 않습니다. 또한 실제로 사용자가 여러 장치(예: 휴대폰 및 태블릿)에서 서비스에 연결된 경우 응답이 두 장치 모두에 제공되는지 확인할 수 있습니다.

흥미롭게도 들어오는 메시지를 처리하는 코드는 클라이언트 자체의 영향을 받은 이벤트와 다른 클라이언트의 이벤트를 포함한 다른 이벤트 모두에 대해 동일합니다(100% 아님).

그러나 실제로는 단방향 흐름이 기능적 스타일(RX 등을 사용하여)로 처리될 수 있다는 사실로 인해 추가 보너스를 얻습니다. 본질적으로 응용 프로그램을 완전히 반응적으로 만들 수 있고 기능적 접근 방식을 사용할 수 있기 때문에 이것은 이미 심각한 장점입니다. 규모가 큰 프로그램의 경우 개발 및 지원 리소스를 크게 절약할 수 있습니다.

이 접근 방식을 수평 확장과 결합하면 보너스로 한 서버에 요청을 보내고 다른 서버에서 응답을 받을 수 있습니다. 따라서 클라이언트는 자신에게 편리한 서비스를 선택할 수 있으며 내부 시스템은 여전히 ​​이벤트를 올바르게 처리할 수 있습니다.

이벤트 소싱

아시다시피 분산 시스템의 주요 특징 중 하나는 공통 시간, 즉 공통 임계 섹션이 없다는 것입니다. 한 프로세스에 대해 (동일한 뮤텍스에서) 동기화를 수행할 수 있으며, 그 안에서 다른 누구도 이 코드를 실행하지 않는다는 것을 확신할 수 있습니다. 그러나 이는 오버헤드가 필요하고 확장의 모든 아름다움을 없애기 때문에 분산 시스템에는 위험합니다. 모든 구성 요소는 여전히 하나를 기다리게 됩니다.

여기에서 우리는 중요한 사실을 얻습니다. 빠른 분산 시스템은 동기화할 수 없습니다. 동기화하면 성능이 저하되기 때문입니다. 반면에 구성요소 간에 일정한 일관성이 필요한 경우가 많습니다. 이를 위해 다음과 같은 접근 방식을 사용할 수 있습니다. 최종 일관성, 여기서는 마지막 업데이트 후 일정 기간(“결국”) 동안 데이터 변경이 없으면 모든 쿼리가 마지막으로 업데이트된 값을 반환하도록 보장됩니다.

클래식 데이터베이스의 경우 꽤 자주 사용된다는 점을 이해하는 것이 중요합니다. 강력한 일관성, 각 노드는 동일한 정보를 가지고 있습니다(이는 두 번째 서버가 응답한 후에만 트랜잭션이 설정된 것으로 간주되는 경우에 종종 달성됩니다). 여기에는 격리 수준으로 인해 약간의 완화가 있지만 일반적인 아이디어는 동일하게 유지됩니다. 완전히 조화된 세상에서 살 수 있습니다.

그러나 원래 작업으로 돌아가 보겠습니다. 시스템의 일부를 다음과 같이 구축할 수 있는 경우 최종 일관성, 그러면 다음 다이어그램을 구성할 수 있습니다.

이 접근 방식의 중요한 특징은 다음과 같습니다.

• 들어오는 각 요청은 하나의 대기열에 배치됩니다.
• 요청을 처리하는 동안 서비스는 작업을 다른 대기열에 배치할 수도 있습니다.
• 각 수신 이벤트에는 식별자(중복 제거에 필요함)가 있습니다.
• 대기열은 "추가 전용" 구성표에 따라 이념적으로 작동합니다. 요소를 제거하거나 재배열할 수 없습니다.
• 대기열은 FIFO 방식에 따라 작동합니다. 병렬 실행을 수행해야 하는 경우 한 단계에서 개체를 다른 대기열로 이동해야 합니다.

우리가 온라인 파일 저장의 경우를 고려하고 있음을 상기시켜 드리겠습니다. 이 경우 시스템은 다음과 같습니다.

다이어그램의 서비스가 반드시 별도의 서버를 의미하는 것은 아니라는 점이 중요합니다. 심지어 그 과정도 같을 수도 있다. 또 다른 중요한 점은 이념적으로 이러한 것들이 수평적 확장을 쉽게 적용할 수 있도록 분리되어 있다는 것입니다.

두 명의 사용자에 대한 다이어그램은 다음과 같습니다(다른 사용자를 대상으로 하는 서비스는 다른 색상으로 표시됨).

이러한 조합으로 인한 보너스:

• 정보처리 서비스가 분리되어 있습니다. 대기열도 분리되어 있습니다. 시스템 처리량을 늘려야 한다면 더 많은 서버에서 더 많은 서비스를 시작하면 됩니다.
• 우리는 사용자로부터 정보를 받을 때 데이터가 완전히 저장될 때까지 기다릴 필요가 없습니다. 반대로, "ok"라고 대답하고 점차적으로 작업을 시작하면 됩니다. 동시에 새 개체 추가가 빠르게 발생하고 사용자가 전체 주기를 통해 완전한 통과를 기다릴 필요가 없기 때문에 대기열은 최고점을 평활화합니다.
• 예를 들어, 동일한 파일을 병합하려고 시도하는 중복 제거 서비스를 추가했습니다. 1%의 경우 오랫동안 작동한다면 클라이언트는 이를 거의 알아차리지 못할 것입니다(위 참조). 이는 더 이상 XNUMX% 속도와 신뢰성을 요구하지 않기 때문에 큰 장점입니다.

그러나 단점은 즉시 드러납니다.

• 우리 시스템은 엄격한 일관성을 잃었습니다. 이는 예를 들어 다른 서비스를 구독하는 경우 이론적으로 다른 상태를 얻을 수 있음을 의미합니다(서비스 중 하나가 내부 대기열에서 알림을 받을 시간이 없을 수 있으므로). 또 다른 결과로 시스템에는 이제 공통 시간이 없습니다. 즉, 예를 들어 서버 간의 시계가 동기화되지 않을 수 있으므로 모든 이벤트를 단순히 도착 시간별로 정렬하는 것은 불가능합니다(게다가 두 서버의 동일한 시간은 유토피아입니다).
• 이제 어떤 이벤트도 간단히 롤백할 수 없습니다(데이터베이스에서처럼). 대신, 새로운 이벤트를 추가해야 합니다. 보상 이벤트, 그러면 마지막 상태가 필요한 상태로 변경됩니다. 비슷한 분야의 예를 들자면, 히스토리를 다시 쓰지 않으면(어떤 경우에는 좋지 않음) git에서 커밋을 롤백할 수는 없지만 특별한 커밋을 만들 수는 있습니다. 롤백 커밋, 이는 기본적으로 이전 상태를 반환합니다. 그러나 잘못된 커밋과 롤백은 모두 기록에 남습니다.
• 데이터 스키마는 릴리스마다 변경될 수 있지만, 이전 이벤트는 더 이상 새로운 표준으로 업데이트될 수 없습니다(이벤트는 원칙적으로 변경될 수 없으므로).

보시다시피 이벤트 소싱은 CQRS와 잘 작동합니다. 더욱이 효율적이고 편리한 대기열을 사용하지만 데이터 흐름을 분리하지 않고 시스템을 구현하는 것 자체가 이미 어렵습니다. 대기열의 긍정적인 효과 전체를 무력화할 동기화 지점을 추가해야 하기 때문입니다. 두 가지 접근 방식을 동시에 적용하려면 프로그램 코드를 약간 조정해야 합니다. 우리의 경우 서버에 파일을 보낼 때 "ok"라는 응답만 나오며 이는 "파일 추가 작업이 저장되었습니다"라는 의미만 입니다. 공식적으로 이는 데이터가 이미 다른 장치에서 사용 가능하다는 것을 의미하지는 않습니다(예: 중복 제거 서비스가 인덱스를 재구축할 수 있음). 그러나 일정 시간이 지나면 클라이언트는 "파일 X가 저장되었습니다."라는 형식의 알림을 받게 됩니다.

결과적으로 :

• 파일 전송 상태 수가 증가하고 있습니다. 기존의 "파일 전송됨" 대신 "파일이 서버의 대기열에 추가되었습니다."와 "파일이 저장소에 저장되었습니다."라는 두 가지 상태가 표시됩니다. 후자는 다른 장치가 이미 파일 수신을 시작할 수 있음을 의미합니다(대기열이 다른 속도로 작동한다는 사실에 맞게 조정됨).
• 이제 제출 정보가 다양한 채널을 통해 제공되므로 파일 처리 상태를 수신할 수 있는 솔루션을 찾아야 합니다. 결과적으로 기존 요청-응답과 달리 파일을 처리하는 동안 클라이언트를 다시 시작할 수 있지만 이 처리 자체의 상태는 정확합니다. 게다가 이 항목은 기본적으로 기본적으로 작동합니다. 결과적으로 우리는 이제 실패에 더 관대해졌습니다.

샤딩

위에서 설명한 것처럼 이벤트 소싱 시스템에는 엄격한 일관성이 부족합니다. 이는 서로 동기화하지 않고도 여러 저장소를 사용할 수 있음을 의미합니다. 문제에 접근하면 다음과 같이 할 수 있습니다.

• 파일을 유형별로 구분하세요. 예를 들어, 사진/비디오를 디코딩하고 보다 효율적인 형식을 선택할 수 있습니다.
• 국가별로 별도의 계정을 제공합니다. 많은 법률로 인해 이것이 필요할 수 있지만 이 아키텍처 체계는 자동으로 그러한 기회를 제공합니다.

한 저장소에서 다른 저장소로 데이터를 전송하려는 경우 표준 수단으로는 더 이상 충분하지 않습니다. 안타깝게도 이 경우 대기열을 중지하고 마이그레이션을 수행한 다음 시작해야 합니다. 일반적인 경우 데이터는 "즉시" 전송될 수 없습니다. 그러나 이벤트 큐가 완전히 저장되고 이전 저장 상태의 스냅샷이 있는 경우 다음과 같이 이벤트를 재생할 수 있습니다.

• 이벤트 소스에서 각 이벤트에는 고유한 식별자(이상적으로는 감소하지 않음)가 있습니다. 이는 마지막으로 처리된 요소의 ID인 필드를 저장소에 추가할 수 있음을 의미합니다.
• 모든 이벤트가 여러 독립 저장소에 대해 처리될 수 있도록 대기열을 복제합니다(첫 번째 저장소는 데이터가 이미 저장되어 있고 두 번째 저장소는 새로운 것이지만 여전히 비어 있음). 물론 두 번째 대기열은 아직 처리되지 않습니다.
• 두 번째 대기열을 시작합니다(즉, 이벤트 재생을 시작합니다).
• 새 대기열이 상대적으로 비어 있으면(즉, 요소 ​​추가와 검색 사이의 평균 시간 차이가 허용 가능함) 리더를 새 저장소로 전환하기 시작할 수 있습니다.

보시다시피, 우리 시스템에는 엄격한 일관성이 없었고 지금도 없습니다. 즉, 이벤트가 동일한 순서로 처리된다는 보장(그러나 지연 시간은 다를 수 있음)만 있습니다. 그리고 이를 이용하면 지구 반대편으로 시스템을 멈추지 않고도 비교적 쉽게 데이터를 전송할 수 있다.

따라서 파일의 온라인 저장소에 대한 예를 계속하면 이러한 아키텍처는 이미 많은 보너스를 제공합니다.

• 우리는 동적인 방식으로 객체를 사용자에게 더 가까이 이동할 수 있습니다. 이를 통해 서비스 품질을 향상시킬 수 있습니다.
• 당사는 일부 데이터를 회사 내에 저장할 수 있습니다. 예를 들어 기업 사용자는 데이터 유출을 방지하기 위해 통제된 데이터 센터에 데이터를 저장해야 하는 경우가 많습니다. 샤딩을 통해 우리는 이를 쉽게 지원할 수 있습니다. 고객이 호환되는 클라우드를 보유하고 있으면 작업이 더욱 쉬워집니다(예: Azure 자체 호스팅).
• 그리고 가장 중요한 것은 우리가 이것을 할 필요가 없다는 것입니다. 결국, 우리는 신속하게 작업을 시작하기 위해 모든 계정에 대해 하나의 스토리지를 제공하는 것에 매우 만족할 것입니다. 그리고 이 시스템의 주요 특징은 확장이 가능하지만 초기 단계에서는 매우 간단하다는 것입니다. 백만 개의 별도 독립 대기열 등에서 작동하는 코드를 즉시 작성할 필요는 없습니다. 필요한 경우 나중에 이 작업을 수행할 수 있습니다.

정적 콘텐츠 호스팅

이 점은 매우 명백해 보일 수 있지만 어느 정도 표준이 로드된 애플리케이션에는 여전히 필요합니다. 그 본질은 간단합니다. 모든 정적 콘텐츠는 애플리케이션이 있는 동일한 서버가 아니라 이 작업에 특별히 전념하는 특수 서버에서 배포됩니다. 결과적으로 이러한 작업은 더 빠르게 수행됩니다(조건부 nginx는 Java 서버보다 더 빠르고 저렴하게 파일을 제공합니다). 게다가 CDN 아키텍처(콘텐츠 전송 네트워크)를 통해 최종 사용자에게 더 가까운 위치에서 파일을 찾을 수 있으며, 이는 서비스 작업의 편의성에 긍정적인 영향을 미칩니다.

정적 콘텐츠의 가장 간단하고 표준적인 예는 웹사이트의 스크립트와 이미지 세트입니다. 모든 것이 간단합니다. 사전에 알려진 다음 아카이브가 CDN 서버에 업로드되어 최종 사용자에게 배포됩니다.

그러나 실제로는 정적 콘텐츠의 경우 람다 아키텍처와 다소 유사한 접근 방식을 사용할 수 있습니다. 사용자에게 파일을 배포해야 하는 작업(온라인 파일 저장소)으로 돌아가 보겠습니다. 가장 간단한 해결책은 각 사용자 요청에 대해 필요한 모든 확인(인증 등)을 수행한 다음 저장소에서 직접 파일을 다운로드하는 서비스를 만드는 것입니다. 이 접근 방식의 가장 큰 단점은 정적 콘텐츠(그리고 특정 개정이 포함된 파일은 실제로 정적 콘텐츠임)가 비즈니스 로직을 포함하는 동일한 서버에 의해 배포된다는 것입니다. 대신 다음 다이어그램을 만들 수 있습니다.

• 서버는 다운로드 URL을 제공합니다. file_id + key 형식일 수 있습니다. 여기서 key는 다음 24시간 동안 리소스에 액세스할 수 있는 권한을 부여하는 미니 디지털 서명입니다.
• 파일은 다음 옵션을 사용하여 간단한 nginx로 배포됩니다.
  • 콘텐츠 캐싱. 이 서비스는 별도의 서버에 위치할 수 있으므로 최신 다운로드 파일을 모두 디스크에 저장할 수 있는 기능을 미래에 대비해 남겨두었습니다.
  • 연결 생성 시 키 확인
• 선택 사항: 스트리밍 콘텐츠 처리. 예를 들어 서비스의 모든 파일을 압축하는 경우 이 모듈에서 직접 압축 풀기를 수행할 수 있습니다. 결과적으로 IO 작업은 해당 위치에서 수행됩니다. Java의 아카이버는 많은 추가 메모리를 쉽게 할당하지만 비즈니스 로직이 포함된 서비스를 Rust/C++ 조건문으로 다시 작성하는 것도 효과적이지 않을 수 있습니다. 우리의 경우에는 다양한 프로세스(또는 서비스)가 사용되므로 비즈니스 로직과 IO 작업을 매우 효과적으로 분리할 수 있습니다.

이 방식은 정적 콘텐츠 배포와 별로 유사하지 않습니다(전체 정적 패키지를 어딘가에 업로드하지 않기 때문에). 그러나 실제로 이 접근 방식은 불변 데이터 배포와 정확하게 관련되어 있습니다. 더욱이 이 방식은 콘텐츠가 단순히 정적인 것이 아니라 불변 및 삭제 불가능한 블록의 집합으로 표현될 수 있는 다른 경우에도 일반화될 수 있습니다(추가될 수는 있음).

(강화를 위한) 또 다른 예: Jenkins/TeamCity로 작업한 경우 두 솔루션 모두 Java로 작성되었음을 알 수 있습니다. 둘 다 빌드 오케스트레이션과 콘텐츠 관리를 모두 처리하는 Java 프로세스입니다. 특히, 둘 다 "서버에서 파일/폴더 전송"과 같은 작업을 수행합니다. 예를 들어, 아티팩트 발행, 소스 코드 전송(에이전트가 저장소에서 직접 코드를 다운로드하지 않고 서버가 대신 수행하는 경우), 로그에 액세스합니다. 이러한 모든 작업은 IO 로드가 다릅니다. 즉, 복잡한 비즈니스 로직을 담당하는 서버는 동시에 대량의 데이터 흐름을 자체적으로 효과적으로 처리할 수 있어야 한다는 것이 밝혀졌습니다. 그리고 가장 흥미로운 점은 이러한 작업이 정확히 동일한 체계에 따라 동일한 nginx에 위임될 수 있다는 것입니다(요청에 데이터 키를 추가해야 한다는 점만 제외).

그러나 시스템으로 돌아가면 비슷한 다이어그램이 표시됩니다.

보시다시피 시스템은 근본적으로 더 복잡해졌습니다. 이제는 파일을 로컬에 저장하는 단순한 미니 프로세스가 아닙니다. 이제 필요한 것은 가장 간단한 지원, API 버전 제어 등이 아닙니다. 따라서 모든 다이어그램을 그린 후에는 확장성이 비용 대비 가치가 있는지 자세히 평가하는 것이 가장 좋습니다. 그러나 시스템을 확장하려면(더 많은 수의 사용자와 작업하는 것을 포함하여) 유사한 솔루션을 선택해야 합니다. 그러나 결과적으로 시스템은 구조적으로 부하 증가에 대비할 수 있습니다(수평 확장을 위해 거의 모든 구성 요소를 복제할 수 있음). 시스템을 중지하지 않고도 업데이트할 수 있습니다(간단히 일부 작업이 약간 느려질 수 있음).

처음에 말했듯이 이제 많은 인터넷 서비스의 부하가 증가하기 시작했습니다. 그리고 그들 중 일부는 제대로 작동하지 않기 시작했습니다. 사실, 사업이 돈을 벌어야 하는 순간에 시스템은 정확히 실패했습니다. 즉, 배송을 연기하는 대신 고객에게 "앞으로 몇 달 동안 배송을 계획하세요"라고 제안하는 대신 시스템은 단순히 "경쟁업체로 가십시오"라고 말했습니다. 사실 이는 낮은 생산성의 대가입니다. 이익이 가장 높을 때 손실이 발생합니다.

결론

이러한 모든 접근 방식은 이전에 알려져 있었습니다. 동일한 VK는 오랫동안 정적 콘텐츠 호스팅 아이디어를 사용하여 이미지를 표시해 왔습니다. 많은 온라인 게임에서는 샤딩 체계를 사용하여 플레이어를 지역으로 나누거나 게임 위치를 분리합니다(세계 자체가 하나인 경우). 이벤트 소싱 접근 방식은 이메일에서 적극적으로 사용됩니다. 데이터가 지속적으로 수신되는 대부분의 거래 애플리케이션은 실제로 수신된 데이터를 필터링할 수 있도록 CQRS 접근 방식을 기반으로 구축되었습니다. 음, 수평적 확장은 꽤 오랫동안 많은 서비스에서 사용되어 왔습니다.

그러나 가장 중요한 것은 이러한 모든 패턴이 최신 애플리케이션에 적용하기가 매우 쉬워졌다는 것입니다(물론 적절한 경우). 클라우드는 샤딩과 수평적 확장을 즉시 제공하는데, 이는 다양한 데이터 센터에 있는 다양한 전용 서버를 직접 주문하는 것보다 훨씬 쉽습니다. CQRS는 RX와 같은 라이브러리의 개발 덕분에 훨씬 쉬워졌습니다. 약 10년 전에는 보기 드문 웹사이트가 이를 지원할 수 있었습니다. Event Sourcing은 Apache Kafka가 포함된 기성 컨테이너 덕분에 설정하기도 매우 쉽습니다. 10년 전에는 이것이 혁신이었을 것입니다. 이제는 흔한 일입니다. 정적 콘텐츠 호스팅도 마찬가지입니다. 보다 편리한 기술(자세한 문서와 대규모 답변 데이터베이스가 있다는 사실 포함)로 인해 이 접근 방식은 더욱 단순해졌습니다.

결과적으로, 다소 복잡한 여러 아키텍처 패턴의 구현이 이제 훨씬 단순해졌습니다. 즉, 미리 자세히 살펴보는 것이 더 좋습니다. 10년 된 애플리케이션에서 높은 구현 및 운영 비용으로 인해 위 솔루션 중 하나가 포기된 경우, 이제 새 애플리케이션에서 또는 리팩토링 후에 이미 구조적으로 확장 가능한 서비스를 생성할 수 있습니다( 성능 측면에서) 고객의 새로운 요청(예: 개인 데이터 현지화)에 즉시 대응할 수 있습니다.

그리고 가장 중요한 것은 간단한 애플리케이션이 있는 경우 이러한 접근 방식을 사용하지 마십시오. 예, 아름답고 흥미롭습니다. 하지만 최대 방문자 수가 100명인 사이트의 경우 고전적인 단일체를 사용하여 수행할 수 있는 경우가 많습니다(적어도 외부에서는 내부의 모든 것을 모듈로 나눌 수 있습니다 등).

출처 : habr.com