<책 정리>도메인 주도 설계로 시작하는 마이크로서비스 설계 (1)

오늘부터 이 책의 내용을 정리하며 공부할 것이다.

이미 책은 1독을 했고 다시 읽으며 정리하는 이유는 머리 속으로만 기억하면 잊어버리기 쉽기 때문에 추후에 책 전체를 보지 않아도 이 글을 읽으면 책을 읽은 것 같은 느낌을 주기 위해서다. 일종의 작은 책이자 메모장인 것이다.

책으로 이런 개념을 공부하는 것들이 다소 부족할 수 있기 때문에 일단 개념을 익히고 추후 실제로 적용해 볼 생각이다

 

이 책을 읽은 이유

3년 차 이상 개발자 공고를 쭉 살펴보니 마이크로서비스 아키텍쳐에 대한 이해를 필요로 하는 자격요건, 우대사항이 많았다.

 

클라우드 인프라와 민첩성

 

클라우드 인프라의 등장

클라우드 인프라는 왜 등장했는가? 전형적인 시스템 인프라 구축 과정은 물리적인 서버실 및 서버 장비를 구축하는 등 완료하기 전까지 시간이 굉장히 오래 걸린다는 문제가 있다. 이 업무를 개발자가 아닌 인프라 조직이 담당한다면 의사소통이 필요해 더 걸린다. 또한 스타트업의 경우 사업이 망한다면 초기 인프라 비용을 건질 수 없다. 이로 인해 클라우드만 전담하는 AWS, GCP, AZURE 같은 클라우드 벤더들이 등장했다

 

클라우드 인프라에 어울리는 애플리케이션의 조건

클라우드 인프라를 사용하면 사용량에 따라 비용을 유연하게 조정할 수 있다. 이런 민첩성을 지원하기 위해 애플리케이션 인프라와 마찬가지로 필요한 시점에 필요한 만큼만 애플리케이션을 변경해서 배포하고 싶다면 구조가 클라우드 인프라를 닮으면 되지 않을까? 마치 레고 블럭처럼 조각으로 분리될 수 있다면 어떨까?

애플리케이션도 이러한 형태라면 효율성이 극대화 될 수 있다.

 

스케일업 , 스케일 아웃

스케일 업 : 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법이다.

스케일 아웃 : 기존 시스템과 용량이 같은 다수의 장비를 병행 추가하여 성능을 높이는 방법이다.

 

특정 서비스만 탄력성 있게 확장(스케일 아웃)

쇼핑몰 세일 기간이라고 생각해보자. 쇼핑몰 세일 기간에 트래픽이 몰리는 부분은 세일 이벤트를 수행하는 부분이다. 나머지 부분은 비슷할 것이다. 그런데 모든 서비스의 시스템 용량을 증설하고 복제할 필요가 있을까? 당연히 낭비다

세일 이벤트를 담당하는 부분만 용량을 증설하고 복제되면 된다.

이런 이유로 인해 시스템 역시 작은 단위의 독립적인 서비스 조각들로 분해되어야 한다.

 

클라우드 프렌들리, 클라우드 네이티브

클라우드 프렌들리 애플리케이션: 전체 시스템을 하나의 큰 덩어리로 만들어 클라우드 환경에 올라가는 애플리케이션

클라우드 네이티브 애플리케이션: 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션

궁극적인 방향 : 클라우드 프렌들리 -> 클라우드 네이티브 가 되어야 한다

 

마이크로서비스란 무엇인가

 

모노리스와 마이크로서비스 비교

모노리스는 전통적인 시스템 구조로서 하나의 단위로 개발되는 일체식 애플리케이션. 보통 사용자 인터페이스, 데이터베이스, 서버쪽 애플리케이션 3개 부분으로 구성된다

모노리스는 아무리 작은 변화에도 새로운 버전으로 전체를 빌드하고 배포해야하는데 보통 로드 밸런서를 앞에 두고 여러 인스턴스 위에 큰 덩어리를 복제해 수평으로 확장한다.

이런 상황에서 변경이 발생되면 여러개의 시스템 모두를 전부 다시 빌드하고 배포해야한다. 또한 데이터 베이스는 하나이므로 탄력적으로 대응할 수 없다.

 

마이크로서비스는 서버 측이 여러개의 조각으로 구성되어 각 서비스가 별개의 인스턴스로 로딩된다. 또한 각기 데이터베이스가 다르다. 서비스를 변경해야 한다면 특정 서비스만 변경해 빌드하고 배포하면 된다

 

SOA와 마이크로서비스

소프트웨어 공학에서 말하는 모듈화 개념의 발전 흐름

구조적 방법론 -> 객체지향 방법론 -> CBD(Component Based Development) -> SOA(Service Oriented Architecture)

SOA와 마이크로서비스아키텍쳐 즉 MSA는 유사

마이크로서비스는 각 서비스와 저장소가 독립적이며 다른 서비스와는 API를 통해서만 느슨하게 연계한다

이처럼 특정 서비스를 구축하는데 언어와 저장소를 자율적으로 선택할 수 있는 방식을 '폴리글랏(Polyglot)'하다고 한다.

MSA는 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화한다. 접근 방식은 오직 API이다.

 

마이크로서비스를 위한 조건

업무기능을 중심으로 다양한 사람들이 한팀이 되어야 한다

독립적인 개발 권리

소프트웨어를 기능이 만족되면 제공 및 전달하는 개념이 아니라 지속적인 개선과 발전을 시킬 제품으로 바라보기

빌드/배포 라인의 자동화

다양한 저장소의 분리

-> 그러나 이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요한데 이로 인해 데이터 일관성 문제가 일어날 수 있다

이런 문제는 비동기 이벤트 처리로 해결이 가능하다. 각 트랜잭션을 분리하고 큐 메커니즘을 이용해 보상 트랜잭션을 활용한다.