마이크로서비스: 정의, 이유, 구현 시기

오랫동안 마이크로서비스 아키텍처에 대한 글을 쓰고 싶었지만, 두 가지 생각 때문에 망설였습니다. 첫째, 이 주제를 깊이 파고들수록 제가 아는 것은 당연하고, 둘째, 모르는 것은 여전히 ​​연구해야 할 필요가 있다는 생각이 들었습니다. 셋째, 더 넓은 독자층에서 논의할 만한 주제가 이미 존재한다고 생각합니다. 따라서 다른 의견도 환영합니다.

코네웨이의 법칙과 기업, 조직 및 정보 시스템의 관계

다시 인용해 보겠습니다.

"어떤 조직이 어떤 시스템(광의의 의미에서)을 설계하면 결국 그 조직 내 팀의 구조를 반영하는 구조를 갖춘 설계를 하게 될 것입니다."
— 멜빈 콘웨이, 1967

제 생각에 이 법칙은 정보 시스템보다는 사업 조직 가능성과 더 관련이 있습니다. 예를 들어 설명해 보겠습니다. 기업을 조직하는 것이 합리적일 만큼 긴 수명 주기를 가진 상당히 안정적인 사업 기회가 있다고 가정해 보겠습니다. (오타가 아닙니다. 제가 이 용어를 정말 좋아하는데, 도용했습니다.) 당연히 이 사업의 지원 시스템은 조직적, 절차적으로 이 사업과 일치할 것입니다.

정보 시스템의 사업적 지향성

예를 들어 설명해 보겠습니다. 피자 사업을 시작할 사업 기회가 있다고 가정해 보겠습니다. 버전 1(사전 정보화 시대라고 부르겠습니다)에서 이 회사는 피자 가게이자, 계산대이자, 배달 서비스였습니다. 이 버전은 주변 환경의 변동성이 낮은 환경에서 오랫동안 운영되었습니다. 그러다 버전 2가 등장했습니다. 버전 XNUMX는 더욱 발전된 형태였고, 모놀리식 아키텍처를 기반으로 비즈니스를 위한 정보 시스템을 핵심으로 활용할 수 있었습니다. 제 생각에는 모놀리식 기업에 대한 엄청난 불의가 바로 여기에 있습니다. 모놀리식 아키텍처가 비즈니스 도메인 모델과 일치하지 않습니다.만약 그렇다면 시스템은 전혀 작동하지 않을 것입니다. 콘웨이의 법칙과 상식에도 어긋나죠. 아니요, 모놀리식 아키텍처는 이 비즈니스 개발 단계, 즉 시스템이 이미 구축되어 운영되고 있는 단계의 비즈니스 모델과 완벽하게 일치합니다. 아키텍처 접근 방식에 관계없이 서비스 지향 아키텍처 버전 3과 마이크로서비스 아키텍처 버전 N 모두 동일하게 작동한다는 것은 정말 놀라운 사실입니다. 그렇다면 문제는 무엇일까요?

모든 것은 흐르고, 모든 것은 변합니다. 아니면 마이크로서비스는 복잡성을 극복하는 수단일까요?

계속하기 전에 마이크로서비스 아키텍처에 대한 몇 가지 오해를 살펴보겠습니다.

마이크로서비스 방식을 지지하는 사람들은 모놀리스를 마이크로서비스로 나누면 개별 서비스의 코드 베이스를 줄여 개발 방식이 간소화된다고 종종 이야기합니다. 제 생각에는 이 주장은 완전히 터무니없는 주장입니다. 솔직히, 모놀리스와 동종 코드 간의 상호 작용이 복잡해 보입니까? 만약 이것이 사실이라면 모든 프로젝트는 애초에 마이크로서비스로 구축되었을 것입니다. 하지만 실제로는 모놀리스에서 마이크로서비스로의 마이그레이션이 훨씬 더 흔합니다. 복잡성은 사라지지 않고, 개별 모듈에서 인터페이스(데이터 버스, RPC, API 및 기타 프로토콜)와 오케스트레이션 시스템으로 옮겨갈 뿐입니다. 그리고 이것이 얼마나 복잡한지!

이기종 스택을 사용하는 것의 이점 또한 의문스럽습니다. 가능하다고 주장하지는 않겠지만, 실제로는 거의 발생하지 않습니다. (앞으로 나아가는 것은 당연하지만, 이점이라기보다는 결과로서 발생하는 경우가 더 많습니다.)

제품 수명 주기 및 서비스 수명 주기

위 다이어그램을 다시 한번 살펴보세요. 제가 개별 버전의 사업이 수명 주기가 짧아지는 현상을 발견한 것은 우연이 아닙니다. 현대 사회에서 사업의 성공은 버전 간 전환이 가속화되는 데 달려 있습니다. 제품의 성공은 제품 내에서 비즈니스 가설을 테스트하는 속도에 따라 결정됩니다.제 생각에는 바로 여기에 마이크로서비스 아키텍처의 핵심 장점이 숨겨져 있습니다. 순서대로 살펴보겠습니다.

정보 시스템 진화의 다음 단계, 서비스 지향 아키텍처(SOA)로 넘어가 보겠습니다. 어느 시점에 우리 제품에서 장수 서비스 — 제품 버전을 전환할 때 서비스 수명 주기가 다음 제품 버전의 수명 주기보다 길어질 가능성이 있다는 점에서 장기적이라는 의미입니다. 따라서 이러한 수명 주기를 전혀 변경하지 않는 것이 합리적입니다. — 다음 버전으로의 전환 속도가 중요합니다.하지만 아쉽게도 우리는 서비스를 끊임없이 바꿔야 합니다. DevOps 방식, 컨테이너화 등 우리에게는 모든 것이 좋습니다. 하지만 이것들은 여전히 ​​마이크로서비스가 아닙니다!

구성 관리의 복잡성을 해결하는 수단으로서의 마이크로서비스

이제 마침내 마이크로서비스의 역할 정의에 대해 이야기해 보겠습니다. 마이크로서비스는 제품 구성 관리를 간소화하는 접근 방식입니다. 더 자세히 설명하자면, 각 마이크로서비스의 기능은 도메인 모델에 따라 제품 내의 비즈니스 기능을 설명합니다. 이러한 기능은 단기적인 버전이 아닌 장기적인 비즈니스 기회로 이어집니다. 제품의 다음 버전으로의 전환은 말 그대로 눈에 띄지 않게 이루어집니다. 마이크로서비스 하나를 변경하거나 추가하거나, 어쩌면 상호 작용 체계만 변경하고 나면 갑자기 미래에 있는 자신을 발견하게 되고, 모놀리스 버전 사이를 끊임없이 오가는 경쟁자들을 내버려 두게 됩니다. 이제 미리 정의된 인터페이스와 비즈니스 기능을 갖춘 상당히 많은 양의 마이크로서비스가 있다고 상상해 보세요. 그리고 기성 마이크로서비스에서 제품 구조를 구축합니다. 예를 들어 다이어그램을 그리는 것만으로도 가능합니다. 축하합니다. 플랫폼을 구축했고, 이제 비즈니스를 구축할 수 있습니다. 꿈만 같습니다.

조사 결과

• 시스템 아키텍처는 구성 요소의 수명 주기에 따라 정의되어야 합니다. 구성 요소가 제품 버전 내에 존재한다면, 마이크로서비스 방식을 사용하여 시스템의 복잡성을 증가시키는 것은 의미가 없습니다.
• 마이크로서비스 아키텍처는 도메인 모델을 기반으로 해야 합니다. 비즈니스 기회는 가장 오래 지속되는 영역이기 때문입니다.
• 마이크로서비스 아키텍처에 있어서 전달 관행(DevOps 관행)과 오케스트레이션은 매우 중요합니다. 구성 요소의 변경 속도가 증가함에 따라 전달 속도와 품질에 대한 요구도 높아지기 때문입니다.

출처 : habr.com