모놀리스에서 마이크로서비스로의 전환: 역사와 실제

이 기사에서는 제가 작업 중인 프로젝트가 어떻게 대규모 단일체에서 마이크로서비스 세트로 변환되었는지에 대해 설명하겠습니다.

이 프로젝트의 역사는 꽤 오래전인 2000년 초에 시작되었습니다. 첫 번째 버전은 Visual Basic 6으로 작성되었습니다. 시간이 지나면서 IDE가 언어 자체가 제대로 개발되지 않았습니다. 2000년대 말에는 더욱 유망한 C#으로 전환하기로 결정되었습니다. 새 버전은 이전 버전의 개정판과 병행하여 작성되었으며 점차적으로 .NET에서 점점 더 많은 코드가 작성되었습니다. C#의 백엔드는 처음에는 서비스 아키텍처에 중점을 두었지만 개발 중에는 로직이 포함된 공용 라이브러리를 사용하고 서비스가 단일 프로세스에서 시작되었습니다. 그 결과 우리가 "서비스 모놀리스"라고 부르는 애플리케이션이 탄생했습니다.

이 조합의 몇 가지 장점 중 하나는 서비스가 외부 API를 통해 서로 호출할 수 있다는 것입니다. 보다 정확한 서비스, 그리고 미래의 마이크로서비스 아키텍처로의 전환을 위해서는 명확한 전제 조건이 있었습니다.

우리는 2015년경에 분해 작업을 시작했습니다. 우리는 아직 이상적인 상태에 도달하지 못했습니다. 대규모 프로젝트에는 아직 모놀리스라고 할 수 없는 부분이 있지만 마이크로서비스처럼 보이지도 않습니다. 그럼에도 불구하고 진전은 상당합니다.
기사에서 이에 대해 이야기하겠습니다.

내용

• 기존 솔루션의 아키텍처와 문제점
• 마이크로서비스에 대한 기대
• 전환 문제
• 모놀리스에서 마이크로서비스로 이동하는 방법
  • 첫 번째 방법
  • 두 번째 방법
  • 세 번째 방법
  • 네 번째 방법
• 데이터베이스 작업
  • 기존 테이블 분할
  • 가공부
• 소스 코드 작업
• 인프라 문제
  • 환경에 수동 설치
  • 별도의 로깅
  • 관련 서비스 테스트 및 디버깅

기존 솔루션의 아키텍처와 문제점

처음에 아키텍처는 다음과 같았습니다. UI는 별도의 애플리케이션이고 모놀리식 부분은 Visual Basic 6으로 작성되었으며 .NET 애플리케이션은 상당히 큰 데이터베이스에서 작동하는 관련 서비스 세트입니다.

이전 솔루션의 단점

단일 실패 지점
단일 실패 지점이 있었습니다. .NET 애플리케이션이 단일 프로세스에서 실행되었습니다. 모듈 하나라도 실패하면 전체 애플리케이션이 실패하고 다시 시작해야 했습니다. 우리는 다양한 사용자를 위해 수많은 프로세스를 자동화하기 때문에 그 중 하나의 오류로 인해 모든 사람이 한동안 작업을 할 수 없었습니다. 소프트웨어 오류가 발생한 경우 백업도 도움이 되지 않았습니다.

개선 대기열
이 단점은 다소 조직적입니다. 우리 애플리케이션에는 많은 고객이 있으며, 그들은 모두 가능한 한 빨리 개선하기를 원합니다. 이전에는 병렬로 진행하는 것이 불가능했고, 모든 고객이 줄을 서 있었습니다. 이 프로세스는 자신의 업무가 가치 있다는 것을 입증해야 했기 때문에 기업에게는 부정적이었습니다. 그리고 개발팀은 이 대기열을 정리하는 데 시간을 보냈습니다. 이를 위해서는 많은 시간과 노력이 필요했고 결국 제품은 원하는 만큼 빠르게 변경되지 못했습니다.

최적이 아닌 리소스 사용
단일 프로세스에서 서비스를 호스팅할 때 우리는 항상 서버에서 서버로 구성을 완전히 복사했습니다. 우리는 리소스를 낭비하지 않고 배포 계획을 보다 유연하게 제어할 수 있도록 가장 부하가 높은 서비스를 별도로 배치하고 싶었습니다.

현대 기술을 구현하기가 어렵습니다.
모든 개발자에게 친숙한 문제입니다. 프로젝트에 최신 기술을 도입하고 싶지만 기회가 없습니다. 대규모 모놀리식 솔루션을 사용하면 새 라이브러리로의 전환은 말할 것도 없고 현재 라이브러리의 모든 업데이트가 다소 중요하지 않은 작업으로 변합니다. 이것이 낭비되는 신경보다 더 많은 보너스를 가져올 것이라는 것을 팀 리더에게 증명하는 데 오랜 시간이 걸립니다.

변경사항 발행의 어려움
이것이 가장 심각한 문제였습니다. 우리는 두 달에 한 번씩 릴리스를 출시했습니다.
개발자의 테스트와 노력에도 불구하고 각 릴리스는 은행에 큰 재앙이 되었습니다. 회사에서는 이번 주가 시작될 때 일부 기능이 작동하지 않을 것이라는 점을 이해했습니다. 그리고 개발자들은 일주일 동안 심각한 사건이 기다리고 있음을 이해했습니다.
모두가 상황을 바꾸고 싶어했습니다.

마이크로서비스에 대한 기대

준비되면 구성요소 발행. 솔루션을 분해하고 다양한 프로세스를 분리하여 준비가 완료되면 구성 요소를 제공합니다.

소규모 제품 팀. 오래된 단일체를 작업하는 대규모 팀은 관리하기 어려웠기 때문에 이는 중요합니다. 이러한 팀은 엄격한 프로세스에 따라 작업해야 했지만 더 많은 창의성과 독립성을 원했습니다. 소규모 팀만이 이를 감당할 수 있습니다.

별도의 프로세스로 서비스를 격리합니다. 이상적으로는 컨테이너에 격리하고 싶지만, .NET Framework로 작성된 많은 서비스는 특정 환경에서만 실행됩니다. Windows.NET Core 기반 서비스들이 등장하고 있지만, 아직은 그 수가 적습니다.

배포 유연성. 우리는 코드가 강제하는 방식이 아닌 필요한 방식으로 서비스를 결합하고 싶습니다.

새로운 기술의 사용. 이것은 모든 프로그래머에게 흥미로울 것입니다.

전환 문제

물론, 모놀리스를 마이크로서비스로 나누는 것이 쉽다면 컨퍼런스에서 이에 대해 이야기하거나 기사를 쓸 필요가 없을 것입니다. 이 과정에는 많은 함정이 있는데, 우리를 방해했던 주요 함정을 설명하겠습니다.

첫 번째 문제 대부분의 모놀리스에 일반적임: 비즈니스 로직의 일관성. 우리는 모노리스를 작성할 때 불필요한 코드를 작성하지 않기 위해 클래스를 재사용하고 싶습니다. 그리고 마이크로서비스로 전환할 때 이것이 문제가 됩니다. 모든 코드가 상당히 긴밀하게 결합되어 있고 서비스를 분리하기가 어렵습니다.

작업 시작 당시 저장소에는 500개 이상의 프로젝트와 700만 개 이상의 코드 라인이 있었습니다. 이건 꽤 큰 결정이고, 두 번째 문제. 단순히 가져와서 마이크로서비스로 나누는 것은 불가능했습니다.

세 번째 문제 — 필요한 인프라가 부족합니다. 사실 우리는 소스 코드를 서버에 수동으로 복사하고 있었습니다.

모놀리스에서 마이크로서비스로 이동하는 방법

마이크로서비스 프로비저닝

첫째, 우리는 마이크로서비스 분리가 반복적인 프로세스라는 것을 즉시 스스로 판단했습니다. 우리는 항상 비즈니스 문제를 동시에 개발해야 했습니다. 이것을 기술적으로 어떻게 구현할지는 이미 우리의 문제입니다. 그래서 우리는 반복적인 과정을 준비했습니다. 대규모 애플리케이션이 있고 처음에 다시 작성할 준비가 되어 있지 않은 경우에는 다른 방식으로 작동하지 않습니다.

마이크로서비스를 격리하기 위해 어떤 방법을 사용합니까?

첫 번째 방법 — 기존 모듈을 서비스로 이동합니다. 이 점에서 운이 좋았습니다. WCF 프로토콜을 사용하여 작동하는 서비스가 이미 등록되어 있었습니다. 그들은 별도의 어셈블리로 분리되었습니다. 우리는 각 빌드에 작은 실행 프로그램을 추가하여 별도로 포팅했습니다. 이는 애플리케이션을 서비스와 콘솔로 실행할 수 있는 멋진 Topshelf 라이브러리를 사용하여 작성되었습니다. 솔루션에 추가 프로젝트가 필요하지 않으므로 디버깅에 편리합니다.

서비스는 공통 어셈블리를 사용하고 공통 데이터베이스로 작업했기 때문에 비즈니스 논리에 따라 연결되었습니다. 순수한 형태로는 마이크로서비스라고 부를 수 없습니다. 그러나 이러한 서비스를 서로 다른 프로세스에서 별도로 제공할 수도 있습니다. 이것만으로도 서로에 대한 영향력을 줄일 수 있었고, 병렬 개발 문제와 단일 실패 지점 문제도 줄일 수 있었습니다.

호스트와의 어셈블리는 Program 클래스의 코드 한 줄에 불과합니다. 우리는 보조 수업에서 Topshelf 작업을 숨겼습니다.

namespace RBA.Services.Accounts.Host
{
   internal class Program
   {
      private static void Main(string[] args)
      {
        HostRunner<Accounts>.Run("RBA.Services.Accounts.Host");

       }
    }
}

마이크로서비스를 할당하는 두 번째 방법은 다음과 같습니다. 새로운 문제를 해결하기 위해 그것들을 만듭니다. 동시에 모놀리스가 성장하지 않는다면 이것은 이미 훌륭한 것이며 이는 우리가 올바른 방향으로 움직이고 있음을 의미합니다. 새로운 문제를 해결하기 위해 별도의 서비스를 만들려고 노력했습니다. 그러한 기회가 있다면 우리는 자체 데이터 모델, 즉 별도의 데이터베이스를 완전히 관리하는 더 많은 "표준" 서비스를 만들었습니다.

많은 사람들과 마찬가지로 우리도 인증 및 권한 부여 서비스로 시작했습니다. 그들은 이것에 완벽합니다. 그들은 독립적이며 원칙적으로 별도의 데이터 모델을 가지고 있습니다. 그들 자신은 단일체와 상호 작용하지 않으며 단지 몇 가지 문제를 해결하기 위해 노력합니다. 이러한 서비스를 사용하면 새로운 아키텍처로의 전환을 시작하고, 인프라를 디버깅하고, 네트워크 라이브러리와 관련된 몇 가지 접근 방식을 시도해 볼 수 있습니다. 우리 조직에는 인증 서비스를 만들 수 없는 팀이 없습니다.

마이크로서비스를 할당하는 세 번째 방법우리가 사용하는 것은 우리에게 조금 구체적입니다. 이는 UI 레이어에서 비즈니스 로직을 제거하는 것입니다. 우리의 기본 UI 애플리케이션은 데스크톱이며 백엔드와 마찬가지로 C#으로 작성되었습니다. 개발자는 주기적으로 실수를 저지르고 백엔드에 존재하고 재사용되어야 하는 로직의 일부를 UI로 전송했습니다.

UI 부분의 코드에서 실제 예제를 살펴보면 이 솔루션의 대부분에는 단순히 UI 양식을 작성하는 것이 아니라 다른 프로세스에서 유용한 실제 비즈니스 로직이 포함되어 있음을 알 수 있습니다.

실제 UI 로직은 마지막 몇 줄에만 있습니다. 재사용이 가능하도록 서버로 전송하여 UI를 줄이고 올바른 아키텍처를 구현했습니다.

마이크로서비스를 분리하는 네 번째이자 가장 중요한 방법모놀리스를 줄일 수 있는 방법은 처리를 통해 기존 서비스를 제거하는 것입니다. 기존 모듈을 있는 그대로 꺼내면 결과가 항상 개발자의 마음에 들지 않을 수도 있고, 기능이 만들어진 이후 비즈니스 프로세스가 구식이 될 수도 있습니다. 비즈니스 요구 사항이 끊임없이 변화하기 때문에 리팩토링을 통해 새로운 비즈니스 프로세스를 지원할 수 있습니다. 소스 코드를 개선하고, 알려진 결함을 제거하고, 더 나은 데이터 모델을 만들 수 있습니다. 많은 혜택이 발생하고 있습니다.

서비스와 처리를 분리하는 것은 제한된 컨텍스트의 개념과 불가분의 관계가 있습니다. 이것은 Domain Driven Design의 개념입니다. 단일 언어의 모든 용어가 고유하게 정의되어 있는 도메인 모델의 한 부분을 의미합니다. 보험과 청구서의 맥락을 예로 들어 살펴보겠습니다. 우리는 모놀리식 애플리케이션을 갖고 있으며 보험 계정을 사용하여 작업해야 합니다. 개발자가 다른 어셈블리에서 기존 Account 클래스를 찾아 이를 Insurance 클래스에서 참조하면 작업 코드가 생성될 것으로 예상합니다. DRY 원칙이 존중되며 기존 코드를 사용하면 작업이 더 빠르게 완료됩니다.

결과적으로 계정과 보험의 맥락이 연결되어 있음이 밝혀졌습니다. 새로운 요구 사항이 나타나면 이러한 결합은 개발을 방해하여 이미 복잡한 비즈니스 논리의 복잡성을 증가시킵니다. 이 문제를 해결하려면 코드에서 컨텍스트 간의 경계를 찾아 위반 사항을 제거해야 합니다. 예를 들어, 보험의 경우 20자리 중앙은행 계좌번호와 계좌 개설 날짜만으로 충분할 가능성이 높습니다.

이러한 제한된 컨텍스트를 서로 분리하고 모놀리식 솔루션에서 마이크로서비스를 분리하는 프로세스를 시작하기 위해 우리는 애플리케이션 내에서 외부 API를 생성하는 등의 접근 방식을 사용했습니다. 일부 모듈이 마이크로서비스가 되어야 하고 프로세스 내에서 어떻게든 수정되어야 한다는 것을 알고 있다면 외부 호출을 통해 다른 제한된 컨텍스트에 속하는 로직을 즉시 호출했습니다. 예를 들어 REST 또는 WCF를 통해.

우리는 분산 트랜잭션이 필요한 코드를 피하지 않겠다고 굳게 결심했습니다. 우리의 경우 이 규칙을 따르는 것이 매우 쉬운 것으로 나타났습니다. 엄격한 분산 트랜잭션이 실제로 필요한 상황은 아직까지 발생하지 않았습니다. 모듈 간의 최종 일관성은 상당히 충분합니다.

구체적인 예를 살펴 보겠습니다. 우리는 "애플리케이션"의 엔터티를 처리하는 파이프라인인 오케스트레이터라는 개념을 가지고 있습니다. 그는 고객, 계좌 및 은행 카드를 차례로 만듭니다. 클라이언트와 계정이 성공적으로 생성되었으나 카드 생성에 실패한 경우, 애플리케이션은 '성공' 상태로 이동하지 않고 '카드 생성 안 됨' 상태로 유지됩니다. 앞으로는 백그라운드 활동이 이를 선택하여 완료할 것입니다. 한동안 시스템이 일관성이 없는 상태였지만, 우리는 대체로 이에 만족하고 있습니다.

데이터의 일부를 지속적으로 저장해야 하는 상황이 발생하면 이를 하나의 프로세스로 처리하기 위해 서비스 통합을 진행할 가능성이 높습니다.

마이크로서비스 할당의 예를 살펴보겠습니다. 어떻게 비교적 안전하게 생산에 투입할 수 있나요? 이 예에는 시스템의 별도 부분인 급여 서비스 모듈이 있으며, 이 모듈의 코드 섹션 중 하나는 마이크로서비스를 만들고자 합니다.

우선, 코드를 다시 작성하여 마이크로서비스를 만듭니다. 만족스럽지 못한 부분을 개선하고 있습니다. 우리는 고객의 새로운 비즈니스 요구 사항을 구현합니다. UI와 백엔드 간의 연결에 API 게이트웨이를 추가하여 통화 전달을 제공합니다.

다음으로 이 구성을 작동하도록 출시하지만 파일럿 상태입니다. 대부분의 사용자는 여전히 오래된 비즈니스 프로세스를 사용하고 있습니다. 신규 사용자를 위해 우리는 더 이상 이 프로세스를 포함하지 않는 새로운 버전의 모놀리식 애플리케이션을 개발하고 있습니다. 본질적으로 우리는 파일럿으로 작동하는 모놀리스와 마이크로서비스의 조합을 가지고 있습니다.

성공적인 파일럿을 통해 우리는 새로운 구성이 실제로 실행 가능하다는 것을 이해하고 방정식에서 기존 모놀리스를 제거하고 기존 솔루션 대신 새 구성을 남겨 둘 수 있습니다.

전체적으로 우리는 모놀리스의 소스 코드를 분할하기 위해 거의 모든 기존 방법을 사용합니다. 이들 모두를 통해 우리는 애플리케이션 부분의 크기를 줄이고 이를 새로운 라이브러리로 변환하여 더 나은 소스 코드를 만들 수 있습니다.

데이터베이스 작업

데이터베이스에는 현재 스키마뿐만 아니라 누적된 기록 데이터도 포함되어 있기 때문에 소스 코드보다 더 나쁘게 분할될 수 있습니다.

다른 많은 데이터베이스와 마찬가지로 우리 데이터베이스에는 또 다른 중요한 단점이 있었습니다. 바로 크기가 엄청났습니다. 이 데이터베이스는 모놀리스의 복잡한 비즈니스 로직과 다양한 경계 컨텍스트의 테이블 사이에 축적된 관계에 따라 설계되었습니다.

우리의 경우 모든 문제(대규모 데이터베이스, 많은 연결, 때로는 테이블 간 경계가 불분명함) 외에도 많은 대규모 프로젝트에서 발생하는 문제인 공유 데이터베이스 템플릿 사용이 발생했습니다. 데이터는 보기와 복제를 통해 테이블에서 가져온 후 이 복제가 필요한 다른 시스템으로 전달되었습니다. 결과적으로 테이블이 활발히 사용되었기 때문에 별도의 스키마로 이동할 수 없었습니다.

코드에서 제한된 컨텍스트로 동일한 분할이 분리에 도움이 됩니다. 이는 일반적으로 데이터베이스 수준에서 데이터를 어떻게 분류하는지에 대한 꽤 좋은 아이디어를 제공합니다. 우리는 어떤 테이블이 하나의 제한된 컨텍스트에 속하고 어떤 테이블이 다른 컨텍스트에 속하는지 이해합니다.

우리는 데이터베이스 파티셔닝에 두 가지 글로벌 방법, 즉 기존 테이블 파티셔닝과 처리를 통한 파티셔닝을 사용했습니다.

기존 테이블을 분할하는 것은 데이터 구조가 양호하고 비즈니스 요구 사항을 충족하며 모두가 만족할 경우 사용하는 좋은 방법입니다. 이 경우 기존 테이블을 별도의 스키마로 분리할 수 있습니다.

비즈니스 모델이 크게 바뀌고 테이블이 더 이상 우리를 전혀 만족시키지 못하는 경우 처리 부서가 필요합니다.

기존 테이블 분할. 우리는 무엇을 분리할지 결정해야 합니다. 이 지식이 없으면 아무것도 작동하지 않으며 여기서는 코드에서 제한된 컨텍스트를 분리하는 것이 도움이 될 것입니다. 일반적으로 소스 코드에서 컨텍스트의 경계를 이해할 수 있으면 부서 목록에 어떤 테이블을 포함해야 하는지 명확해집니다.

두 개의 모놀리스 모듈이 하나의 데이터베이스와 상호 작용하는 솔루션이 있다고 가정해 보겠습니다. 하나의 모듈만 분리된 테이블 섹션과 상호 작용하고 다른 모듈은 API를 통해 상호 작용을 시작하는지 확인해야 합니다. 우선, API를 통해서만 녹음만 하면 충분합니다. 이는 마이크로서비스의 독립성을 논하기 위한 필수 조건입니다. 큰 문제가 없는 한 독서 연결은 유지될 수 있습니다.

다음 단계는 처리 여부에 관계없이 분리된 테이블을 사용하여 작동하는 코드 섹션을 별도의 마이크로서비스로 분리하고 이를 별도의 프로세스인 컨테이너에서 실행할 수 있다는 것입니다. 이는 모놀리식 데이터베이스 및 이와 직접 관련되지 않은 테이블에 연결된 별도의 서비스입니다. 모놀리스는 여전히 분리 가능한 부분과 읽기를 위해 상호 작용합니다.

나중에 이 연결을 제거할 것입니다. 즉, 분리된 테이블의 모놀리식 애플리케이션에서 데이터를 읽는 것도 API로 전송됩니다.

다음으로, 새로운 마이크로서비스만 작동하는 테이블을 일반 데이터베이스에서 선택합니다. 테이블을 별도의 스키마로 이동하거나 별도의 물리적 데이터베이스로 이동할 수도 있습니다. 마이크로서비스와 모놀리식 데이터베이스 사이에는 여전히 읽기 연결이 있지만 걱정할 필요가 없습니다. 이 구성에서는 상당히 오랫동안 지속될 수 있습니다.

마지막 단계는 모든 연결을 완전히 제거하는 것입니다. 이 경우 기본 데이터베이스에서 데이터를 마이그레이션해야 할 수도 있습니다. 때로는 외부 시스템에서 복제된 일부 데이터나 디렉터리를 여러 데이터베이스에 재사용하고 싶을 때가 있습니다. 이것은 우리에게 주기적으로 발생합니다.

가공부. 이 방법은 첫 번째 방법과 매우 유사하지만 순서가 반대입니다. 우리는 API를 통해 모놀리스와 상호 작용하는 새로운 데이터베이스와 새로운 마이크로서비스를 즉시 할당합니다. 그러나 동시에 나중에 삭제하려는 데이터베이스 테이블 세트도 남아 있습니다. 더 이상 필요하지 않으며 새 모델로 교체했습니다.

이 계획이 작동하려면 전환 기간이 필요할 것입니다.

그러면 두 가지 가능한 접근 방식이 있습니다.

처음으로: 새 데이터베이스와 기존 데이터베이스의 모든 데이터를 복제합니다. 이 경우 데이터 중복성과 동기화 문제가 발생할 수 있습니다. 하지만 우리는 두 명의 다른 클라이언트를 가질 수 있습니다. 하나는 새 버전에서 작동하고 다른 하나는 이전 버전에서 작동합니다.

초: 일부 비즈니스 기준에 따라 데이터를 나눕니다. 예를 들어, 시스템에는 이전 데이터베이스에 저장된 5개의 제품이 있었습니다. 우리는 새 데이터베이스의 새 비즈니스 작업 내에 여섯 번째 항목을 배치합니다. 하지만 우리는 이 데이터를 동기화하고 클라이언트에게 어디서 무엇을 얻을지 보여줄 API 게이트웨이가 필요합니다.

두 접근 방식 모두 작동하므로 상황에 따라 선택하세요.

모든 것이 작동한다고 확인한 후에는 이전 데이터베이스 구조에서 작동하는 모놀리스 부분을 비활성화할 수 있습니다.

마지막 단계는 이전 데이터 구조를 제거하는 것입니다.

요약하자면, 데이터베이스에 문제가 있다고 말할 수 있습니다. 소스 코드에 비해 작업하기가 어렵고 공유하기가 더 어렵지만 수행할 수 있고 수행해야 합니다. 우리는 이를 매우 안전하게 수행할 수 있는 몇 가지 방법을 찾았지만 여전히 소스 코드보다 데이터로 실수하기가 더 쉽습니다.

소스 코드 작업

이것이 모놀리식 프로젝트 분석을 시작했을 때의 소스 코드 다이어그램의 모습입니다.

대략 10개의 층으로 나눌 수 있습니다. 이는 실행된 모듈, 플러그인, 서비스 및 개별 활동의 계층입니다. 실제로 이는 모놀리식 솔루션 내의 진입점이었습니다. 모두 Common 레이어로 단단히 밀봉되어 있었습니다. 서비스가 공유하는 비즈니스 로직과 많은 연결이 있었습니다. 각 서비스와 플러그인은 규모와 개발자의 양심에 따라 최대 XNUMX개 이상의 공통 어셈블리를 사용했습니다.

별도로 사용할 수 있는 인프라 라이브러리가 있다는 것은 행운이었습니다.

일부 공통 개체가 실제로 이 계층에 속하지 않고 인프라 라이브러리인 상황이 발생하는 경우도 있습니다. 이름을 바꾸면 해결되었습니다.

가장 큰 관심사는 제한된 컨텍스트였습니다. 3~4개의 컨텍스트가 하나의 공통 어셈블리에 혼합되어 동일한 비즈니스 기능 내에서 서로 사용되는 일이 발생했습니다. 이것이 어디에서 어떤 경계를 따라 분할될 수 있는지, 그리고 이 분할을 소스 코드 어셈블리에 매핑하여 다음에 수행할 작업을 이해하는 것이 필요했습니다.

우리는 코드 분할 프로세스에 대한 몇 가지 규칙을 공식화했습니다.

첫 번째: 우리는 더 이상 서비스, 활동 및 플러그인 간에 비즈니스 로직을 공유하고 싶지 않았습니다. 우리는 마이크로서비스 내에서 비즈니스 로직을 독립적으로 만들고 싶었습니다. 반면에 마이크로서비스는 이상적으로는 완전히 독립적으로 존재하는 서비스로 간주됩니다. 나는 이 접근 방식이 다소 낭비적이며 달성하기 어렵다고 생각합니다. 예를 들어 C#의 서비스는 어떤 경우에도 표준 라이브러리에 의해 연결되기 때문입니다. 우리 시스템은 C#으로 작성되었으며 아직 다른 기술을 사용하지 않았습니다. 따라서 우리는 공통 기술 어셈블리를 사용할 여유가 있다고 결정했습니다. 가장 중요한 것은 비즈니스 로직의 일부가 포함되어 있지 않다는 것입니다. 사용 중인 ORM에 대한 편리한 래퍼가 있는 경우 이를 서비스 간에 복사하는 데 비용이 많이 듭니다.

우리 팀은 도메인 중심 디자인의 팬이므로 어니언 아키텍처는 우리에게 매우 적합했습니다. 우리 서비스의 기본은 데이터 액세스 계층이 아니라 비즈니스 로직만 포함하고 인프라와 연결되지 않는 도메인 로직이 포함된 어셈블리입니다. 동시에 도메인 어셈블리를 독립적으로 수정하여 프레임워크와 관련된 문제를 해결할 수 있습니다.

이 단계에서 우리는 첫 번째 심각한 문제에 직면했습니다. 서비스는 하나의 도메인 어셈블리를 참조해야 했고, 우리는 논리를 독립적으로 만들고 싶었고, 여기서는 DRY 원칙이 우리를 크게 방해했습니다. 개발자들은 중복을 피하기 위해 인접한 어셈블리의 클래스를 재사용하기를 원했고 그 결과 도메인이 다시 연결되기 시작했습니다. 결과를 분석한 결과 아마도 소스코드 저장장치 영역에도 문제가 있는 것으로 판단되었습니다. 우리는 모든 소스 코드를 포함하는 대규모 저장소를 갖고 있었습니다. 전체 프로젝트에 대한 솔루션을 로컬 컴퓨터에서 조립하기가 매우 어려웠습니다. 따라서 프로젝트의 일부에 대해 별도의 소규모 솔루션이 생성되었으며 여기에 공통 또는 도메인 어셈블리를 추가하고 재사용하는 것을 금지하는 사람은 아무도 없었습니다. 이를 허용하지 않는 유일한 도구는 코드 검토였습니다. 그러나 때로는 실패하기도 했습니다.

그런 다음 별도의 리포지토리가 있는 모델로 이동하기 시작했습니다. 비즈니스 로직은 더 이상 서비스에서 서비스로 흐르지 않으며, 도메인은 진정으로 독립적이 되었습니다. 제한된 컨텍스트가 더 명확하게 지원됩니다. 인프라 라이브러리를 어떻게 재사용합니까? 우리는 이를 별도의 저장소로 분리한 다음 Nuget 패키지에 넣었고 이를 Artifactory에 넣었습니다. 변경 사항이 있으면 어셈블리 및 게시가 자동으로 수행됩니다.

우리 서비스는 외부 인프라 패키지와 동일한 방식으로 내부 인프라 패키지를 참조하기 시작했습니다. Nuget에서 외부 라이브러리를 다운로드합니다. 이러한 패키지를 배치한 Artifactory를 사용하기 위해 두 개의 패키지 관리자를 사용했습니다. 소규모 저장소에서는 Nuget도 사용했습니다. 여러 서비스가 있는 리포지토리에서는 모듈 간에 더 많은 버전 일관성을 제공하는 Paket을 사용했습니다.

따라서 소스 코드 작업, 아키텍처 약간 변경 및 저장소 분리를 통해 서비스를 더욱 독립적으로 만듭니다.

인프라 문제

마이크로서비스로 전환할 때 발생하는 대부분의 단점은 인프라와 관련되어 있습니다. 자동화된 배포가 필요하고 인프라를 실행하려면 새로운 라이브러리가 필요합니다.

환경에 수동 설치

처음에는 환경용 솔루션을 수동으로 설치했습니다. 이 프로세스를 자동화하기 위해 우리는 CI/CD 파이프라인을 만들었습니다. 우리는 비즈니스 프로세스 관점에서 지속적인 배포가 아직 허용되지 않기 때문에 지속적인 제공 프로세스를 선택했습니다. 따라서 작업 전송은 버튼을 사용하여 자동으로 테스트를 위해 수행됩니다.

우리는 소스 코드 저장을 위해 Atlassian, Bitbucket을 사용하고 빌드를 위해 Bamboo를 사용합니다. 우리는 C#과 동일하기 때문에 Cake로 빌드 스크립트를 작성하는 것을 좋아합니다. 기성품 패키지는 Artifactory로 제공되며 Ansible은 자동으로 테스트 서버에 도달한 후 즉시 테스트할 수 있습니다.

별도의 로깅

한때 모놀리스의 아이디어 중 하나는 공유 로깅을 제공하는 것이었습니다. 또한 디스크에 있는 개별 로그를 어떻게 처리할지 이해해야 했습니다. 우리의 로그는 텍스트 파일로 기록됩니다. 우리는 표준 ELK 스택을 사용하기로 결정했습니다. 우리는 공급자를 통해 ELK에 직접 기록하지 않았지만 텍스트 로그를 수정하고 추적 ID를 식별자로 기록하여 나중에 이러한 로그를 구문 분석할 수 있도록 서비스 이름을 추가하기로 결정했습니다.

Filebeat를 사용하면 다음 위치에서 로그를 수집할 수 있습니다. 서버그런 다음 해당 데이터를 변환하고, Kibana를 사용하여 UI에서 쿼리를 구성하고, 서비스 간 호출이 어떻게 라우팅되었는지 확인합니다. 추적 ID는 이 작업에 매우 유용합니다.

관련 서비스 테스트 및 디버깅

처음에는 개발 중인 서비스를 디버깅하는 방법을 완전히 이해하지 못했습니다. 모놀리스를 사용하면 모든 것이 간단해 로컬 머신에서 실행했습니다. 처음에는 마이크로서비스를 사용해 동일한 작업을 수행하려고 했지만 때로는 하나의 마이크로서비스를 완전히 시작하려면 여러 다른 마이크로서비스를 시작해야 하는데 이는 불편합니다. 우리는 디버깅하려는 서비스만 로컬 시스템에 남겨두는 모델로 이동해야 한다는 것을 깨달았습니다. 나머지 서비스는 prod와 구성이 일치하는 서버에서 사용됩니다. 디버깅 후, 테스트하는 동안 각 작업에 대해 변경된 서비스만 테스트 서버에 발급됩니다. 따라서 솔루션은 향후 프로덕션에 나타날 형태로 테스트됩니다.

프로덕션 버전의 서비스만 실행하는 서버가 있습니다. 이러한 서버는 사고 발생 시 배포 전 배송 확인 및 내부 교육을 위해 필요합니다.

널리 사용되는 Specflow 라이브러리를 사용하여 자동화된 테스트 프로세스를 추가했습니다. Ansible에서 배포한 후 즉시 NUnit을 사용하여 테스트가 자동으로 실행됩니다. 작업 범위가 완전 자동이면 수동 테스트가 필요하지 않습니다. 때로는 추가 수동 테스트가 여전히 필요하지만. 우리는 Jira의 태그를 사용하여 특정 문제에 대해 실행할 테스트를 결정합니다.

또한 부하 테스트에 대한 필요성이 증가했으며 이전에는 드문 경우에만 수행되었습니다. JMeter를 사용하여 테스트를 실행하고, InfluxDB를 사용하여 이를 저장하고, Grafana를 사용하여 프로세스 그래프를 작성합니다.

우리는 무엇을 달성했나요?

첫째, '릴리스'라는 개념을 없앴습니다. 이 거대 기업이 프로덕션 환경에 배포되어 일시적으로 비즈니스 프로세스를 중단시켰을 때 1,5개월에 걸친 엄청난 릴리스가 사라졌습니다. 이제는 승인 후 운영되기 때문에 평균 XNUMX일마다 서비스를 배포하고 그룹화합니다.

우리 시스템에는 치명적인 오류가 없습니다. 버그가 있는 마이크로서비스를 출시하면 이와 관련된 기능이 중단되고 다른 모든 기능은 영향을 받지 않습니다. 이는 사용자 경험을 크게 향상시킵니다.

배포 패턴을 제어할 수 있습니다. 필요한 경우 솔루션의 나머지 부분과 별도로 서비스 그룹을 선택할 수 있습니다.

또한 대규모 개선 대기열을 통해 문제를 크게 줄였습니다. 이제 일부 서비스를 독립적으로 작업하는 별도의 제품 팀이 있습니다. 스크럼 프로세스는 이미 여기에 적합합니다. 특정 팀에는 작업을 할당하는 별도의 제품 소유자가 있을 수 있습니다.

개요

• 마이크로서비스는 복잡한 시스템을 분해하는 데 매우 적합합니다. 그 과정에서 우리는 시스템에 무엇이 있는지, 제한된 컨텍스트가 무엇인지, 경계가 어디에 있는지 이해하기 시작합니다. 이를 통해 모듈 간에 개선 사항을 올바르게 배포하고 코드 혼동을 방지할 수 있습니다.
• 마이크로서비스는 조직에 이점을 제공합니다. 종종 아키텍처로만 언급되지만 모든 아키텍처는 비즈니스 요구 사항을 해결하는 데 필요하며 그 자체로는 필요하지 않습니다. 따라서 현재 스크럼이 매우 인기가 있다는 점을 고려하면 마이크로서비스는 소규모 팀의 문제를 해결하는 데 매우 적합하다고 말할 수 있습니다.
• 분리는 반복적인 과정입니다. 애플리케이션을 가져와서 단순히 마이크로서비스로 나눌 수는 없습니다. 결과 제품은 기능할 가능성이 없습니다. 마이크로서비스를 전용으로 사용하는 경우 기존 레거시를 다시 작성하는 것이 좋습니다. 즉, 기능과 속도 측면에서 비즈니스 요구 사항을 더 잘 충족하고 원하는 코드로 바꾸는 것이 좋습니다.

  작은 주의사항: 마이크로서비스로 전환하는 데 드는 비용은 상당히 큽니다. 인프라 문제를 혼자서 해결하는데 오랜 시간이 걸렸습니다. 따라서 특정 확장이 필요하지 않은 소규모 애플리케이션이 있고 팀의 관심과 시간을 끌기 위해 경쟁하는 고객이 많지 않다면 마이크로서비스가 현재 필요한 것이 아닐 수도 있습니다. 꽤 비싸요. 마이크로서비스로 프로세스를 시작하면 처음에는 모놀리스 개발로 동일한 프로젝트를 시작하는 것보다 비용이 더 높아집니다.

  PS 좀 더 감성적인 이야기(개인적으로는) - 에 따르면 링크.
  보고서의 전체 버전은 다음과 같습니다.

출처 : habr.com