2단계: 올바른 방식으로 팀 구성

지금까지는 마이크로서비스를 구축하는 것이 대부분 기술적인 일인 것처럼 보일 수 있습니다. 코드베이스를 여러 서비스로 나누고, 적절한 패턴을 구현하여 네트워크 문제에서 안정적으로 종료 및 복구하고, 데이터 일관성을 다루며, 서비스 부하를 모니터링하는 등의 작업이 필요합니다. 파악해야 할 새로운 개념이 많을 것입니다. 하지만 간과해서는 안 되는 가장 중요한 점은 팀의 구성 방식을 다시 구성해야 한다는 것입니다.

콘웨이의 법칙은 실제로 작용되며 모든 유형의 팀에서 볼 수 있습니다. 소프트웨어 팀이 백엔드 팀, 프런트엔드 팀 및 독립적으로 작업하는 운영 팀으로 구성된 경우, 프로덕션에 제공하기 위해 부서 외부로 전달하는 별도의 프런트엔드 및 백엔드 모놀리스를 제공할 것입니다. 각 서비스는 다른 서비스와 독립적으로 제공하는 자체 제품처럼 다뤄야 하기 때문에, 이러한 유형의 팀 구조는 마이크로서비스에 적합하지 않습니다.

대신에 담당하는 서비스를 개발하고 유지 관리하는 데 필요한 모든 역량을 갖춘 소규모 DevOps 팀을 만들어야 합니다. 이렇게 팀을 구성하면 큰 장점이 있습니다. 우선 개발자는 코드가 프로덕션에 미치는 영향을 더 잘 이해할 수 있으므로 더 나은 릴리스를 만들고 고객에게 문제가 릴리스되는 위험을 줄일 수 있습니다. 두 번째로, 배포 파이프라인의 자동화뿐만 아니라 코드 개선을 위해서도 함께 작업하기 때문에 각 팀에서 배포가 손쉽게 이루어집니다.

3단계: 모놀리스를 분할하여 마이크로서비스 아키텍처 구축

서비스의 경계를 파악하고 팀을 다시 구성하는 방법을 파악했다면 모놀리스를 분할하여 마이크로서비스를 구축할 수 있습니다. 이 시점에 고려해야 할 핵심 사항은 다음과 같습니다.

RESTful API를 사용하여 서비스 간 통신을 단순하게 유지

아직 RESTful API를 사용하고 있지 않은 경우 지금이 채택하기에 좋은 시점입니다. Martin Fowler의 설명과 같이, "스마트 엔드포인트와 덤 파이프"가 있어야 합니다. 즉, 서비스 간의 통신 프로토콜은 가능한 한 단순해야 하며 데이터를 변환하지 않고 데이터 전송만 담당해야 합니다. 실제 작업은 엔드포인트 자체에서 일어납니다. 즉, 요청을 수신하고 처리한 다음 그에 대한 응답을 내보냅니다.

마이크로서비스 아키텍처에서는 구성 요소의 긴밀한 결합을 피하기 위해 최대한 간단하게 유지하려고 노력합니다. 경우에 따라 비동기식 메시지 기반 통신과 함께 이벤트 중심의 아키텍처를 사용할 수 있습니다. 하지만 다시 한 번 말하지만 RabbitMQ와 같은 기본 메시지 큐 서비스를 살펴보고 네트워크를 통해 전송되는 메시지를 더 복잡하게 만들지 않아야 합니다.

데이터를 제한된 컨텍스트 또는 데이터 도메인으로 분할

모놀리스 애플리케이션은 애플리케이션의 모든 비즈니스 기능에 대해 단일 데이터베이스를 사용합니다. 모놀리스가 마이크로서비스로 분할됨에 따라 이 단일 데이터베이스는 더 이상 효과적이지 않을 수 있습니다. 중앙 집중식 데이터베이스는 트래픽 확장에서 병목 현상을 유발할 수 있습니다. 특정 서비스가 높은 부하로 데이터베이스에 액세스하면 다른 서비스의 데이터베이스 액세스가 중단될 수 있습니다. 또한 단일 데이터베이스는 스키마를 동시에 수정하려는 여러 팀에 공동 작업 병목 현상을 일으킬 수 있습니다. 마이크로서비스 데이터 요구 사항을 지원하기 위해 데이터베이스를 분할하거나 더 많은 데이터 스토리지 도구를 추가해야 할 수 있습니다.

모놀리식 데이터베이스 스키마를 리팩터링하는 것은 정교한 작업이 될 수 있습니다. 각 서비스에 어떤 데이터 세트가 필요한지, 그리고 중복되는 데이터 세트가 있는지 명확하게 식별하는 것이 중요합니다. 이 스키마 계획은 도메인 중심 설계의 한 패턴인 제한된 컨텍스트를 사용하여 할 수 있습니다. 제한된 컨텍스트는 해당 시스템에 들어가고 나갈 수 있는 항목을 포함하여 자립적인 시스템을 정의합니다.

이 시스템에서는 사용자가 주문에 액세스할 때 테이블에서 고객 정보를 볼 수 있으며, 이것을 사용하여 청구 시스템에서 관리하는 인보이스를 채울 수도 있습니다. 논리적이고 단순해 보일 수 있지만 마이크로서비스에서는 주문 시스템이 중지되더라도 인보이스에 액세스할 수 있도록 서비스를 분리해야 합니다. 또한 이 방법을 사용하면 다른 테이블과 독립적으로 인보이스 테이블을 최적화하거나 발전시킬 수 있습니다. 결과적으로 각 서비스에는 필요한 데이터에 액세스할 수 있는 자체 데이터 스토리지가 생길 수 있습니다.

그러면 일부 데이터가 다른 데이터베이스에서 복제되므로 새로운 문제가 발생합니다. 제한된 컨텍스트는 공유 또는 중복 데이터를 처리하기 위한 최상의 전략을 식별할 수 있습니다. 여러 서비스 간에 데이터를 동기화하는 데 도움이 되는 이벤트 중심의 아키텍처를 채택할 수 있습니다. 예를 들어, 청구 및 배달 추적 서비스는 고객이 개인 정보를 업데이트할 때 계정 서비스에서 송신하는 이벤트를 수신할 수 있습니다. 이벤트를 수신하면 서비스는 그에 따라 데이터 저장소를 업데이트합니다. 이벤트 기반 아키텍처를 사용하면 다른 종속 서비스를 알 필요가 없기 때문에 계정 서비스 로직을 단순하게 유지할 수 있습니다. 단순히 시스템에 수행한 작업을 알려주고 다른 서비스는 이것에 따라 수신 및 작동합니다.

또한 모든 고객 정보를 계정 서비스에 보관하고 청구 및 배달 서비스에 외래 키 참조만 유지하도록 선택할 수도 있습니다. 그러면 서비스는 기존 레코드를 복제하는 대신 계정 서비스와 상호 작용하여 관련 고객 데이터를 가져옵니다. 이러한 문제에 대한 보편적인 해결책은 없으므로 각 특정 사례를 살펴보고 가장 좋은 접근 방식을 결정해야 합니다.

장애에 대비하여 마이크로서비스 아키텍처 구축

마이크로서비스가 모놀리식 아키텍처에 비해 얼마나 큰 이점을 제공할 수 있는지 살펴봤습니다. 마이크로서비스는 크기가 작고 특화되어 있으므로 이해하기 쉽습니다. 분리되어 있으므로 시스템의 다른 구성 요소를 손상시키거나 다른 팀의 개발 속도를 늦출 걱정 없이 서비스를 리팩토링할 수 있습니다. 또한 다른 서비스의 요구 사항에 제약을 받지 않고 필요 시 다른 기술을 선택할 수 있으므로 개발자에게 더 높은 유연성을 제공합니다.

즉, 마이크로서비스 아키텍처를 사용하면 각 비즈니스 기능을 더 쉽게 개발하고 유지 관리할 수 있습니다. 그러나 모든 서비스 및 작업을 완료하기 위해 상호 작용해야 하는 방식을 살펴보면 상황이 더 복잡해집니다. 이제 시스템이 여러 장애 지점과 함께 분산되었으므로 이에 대처해야 합니다. 서비스가 응답하지 않는 경우를 고려해야 할 뿐 아니라 느린 네트워크 응답도 처리해야 합니다. 서비스가 다시 온라인 상태가 될 때 보류 중인 메시지가 밀려들어오지 않도록 해야 하므로, 장애로부터 복구하는 것도 경우에 따라 까다로울 수 있습니다.

모놀리식 시스템에서 기능을 추출하기 시작할 때는 처음부터 장애에 대비하여 설계해야 합니다.

마이크로서비스 테스트가 간편하도록 모니터링을 강조

모놀리식 시스템과 비교하여 마이크로서비스의 또 다른 단점은 바로 테스트입니다. 단일 코드베이스로 구축한 애플리케이션은 테스트 환경을 가동하고 실행하는 데 많은 것이 필요하지 않습니다. 대부분의 경우 테스트 모음을 실행하려면 데이터베이스와 결합된 백엔드 서버를 시작해야 합니다.

마이크로서비스 환경에서는 일이 그렇게 쉽지 않습니다. 단위 테스트의 경우 아직 모놀리스와 매우 비슷하므로 이 수준에서는 크게 어렵지 않을 것입니다. 하지만 통합 및 시스템 테스트의 경우 훨씬 어렵습니다. 여러 서비스를 함께 시작하고 서로 다른 데이터 스토리지를 가동 및 실행하고 모놀리스에서는 필요하지 않았던 메시지 큐를 설정에 포함해야 할 수 있습니다. 이 상황에서는 기능 테스트를 실행하는 데 훨씬 더 많은 비용이 들며 변동 사항의 수가 많아지면서 발생 가능한 다양한 유형의 장애를 예측하기가 매우 어렵습니다.

모니터링을 통해 문제를 조기에 식별하고 대응할 수 있습니다. 다양한 서비스의 기준치를 이해하고 서비스가 중단될 때뿐만 아니라 예기치 않게 작동할 때도 대응해야 합니다. 마이크로서비스 아키텍처를 채택하는 것의 장점은 시스템이 부분적인 장애에 대해 복원력이 있다는 것입니다. 따라서 Pizzup 애플리케이션의 배달 추적 서비스에서 이상이 발생하기 시작하면 모놀리식 시스템의 경우보다 상황이 나을 것입니다. 실시간 추적을 복원하는 동안 다른 모든 서비스가 올바르게 응답하고 고객이 피자를 주문할 수 있도록 애플리케이션을 설계해야 합니다.

지속적 배포를 도입하여 배포 마찰 줄이기

모놀리식 시스템을 프로덕션에 수동으로 릴리스하는 것은 지루하고 위험하지만 가능한 작업입니다. 물론 추천하는 접근 방식은 아니며 모든 소프트웨어 팀이 모든 유형의 개발에 지속적 배포를 도입하도록 권장하지만, 프로젝트를 시작할 때 명령줄을 통해 첫 번째 배포를 수행할 수도 있습니다.

하루에 여러 번 배포해야 하는 서비스의 개수가 늘어나는 경우 이 접근 방식은 지속 가능하지 않습니다. 따라서 마이크로서비스로의 전환의 일부로, 릴리스 장애의 위험을 줄이기 위해 지속적 배포를 도입하고, 팀이 애플리케이션 배포에 얽매이지 않고 구축 및 실행에 집중할 수 있도록 하는 것이 중요합니다. 지속적 배포를 실천한다는 것은 서비스가 프로덕션 단계로 이동하기 전에 승인 테스트를 통과했음을 의미합니다. 물론 버그가 발생하지만 시간이 지남에 따라 릴리스 품질에 대한 팀의 자신감을 높여주는 강력한 테스트 모음을 만들 것입니다.