[책 정리] 마이크로서비스 개발 - 01

seul·2022년 11월 30일
0

책을 읽다가 내가 모르는 개념도 많고,
나중에 다시 보면 도움이 될 것 같은 내용이 많아 처음부터 다시 읽으며 정리하기로 했다.
첫 번째 책인 '도메인 주도 설계로 시작하는 마이크로서비스 개발'이다.
내용은 내가 이해할 수 있게 적기 때문에 다른 사람들이 보기에는 어려울 수 있다.
궁금한 사람은 책을 구매해보시길!

도메인 주도 설계로 시작하는 마이크로 서비스 개발
w. 한정헌, 유해식, 최은정, 이주영

🧙‍♂️ 아마존 비즈니스 민첩성의 비밀

🥟 클라우드 인프라의 등장

2019년 AWS 컨퍼런스에서 발표된 내용에 따르면 아마존 서비스의 배포 주기가 초당 1.5번이라고 한다. 비즈니스는 계속 변경되므로 이에 따라 개선된 시스템도 계속 배포되어야 한다.

아마존 쇼핑몰은 '기획, 분석, 설계, 구현 후 빌드 및 배포'까지의 과정을 '독립적'으로 완료한다.

전형적인 인프라 구축 과정

  1. 서버실 공사
  2. 서버 장비 구입, 네트워크 연결
  3. 운영체제 및 S/W 설치
    -> 시간이 진짜 많이 걸리고 비용이 적지 않다.

클라우드 인프라

  • 사용량에 따라 비용을 유연하게 조정할 수 있다.
  • 오랜 시간이 들지 않는다.

스케일 업, 스케일 아웃

  • 스케일 업: 기존 시스템 자체의 물리적 용량을 증가시켜 성능을 높이는 방법. 사용량이 많아진다는 것은 데이터 처리가 증가한다는 것이고, 시스템을 담을 그릇도 커져야 한다.
  • 스케일 아웃: 기존 시스템과 용량이 같은 다수의 장비를 병행 추가해서 가용성을 높이는 방법. 사용량을 분산시켜 전체적으로 장애 없이 운영되게 한다.

Q. 만약 어떤 이벤트 동안에만 밀려올 트래픽을 대비하려면?
A. 모든 시스템을 증설하거나 복제하는 것보다는, '이벤트를 담당하는 모듈'만 용량을 증설하고 트래픽에 반응해 복제되게 설정하면 된다.

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

  • 클라우드 친화 애플리케이션(Cloud Friendly Application): 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션 (특정 기능만 확장하거나 배포할 수 없음)
  • 클라우드 네이티브 애플리케이션(Cloud Native Application): 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션 (=클라우드 인프라에 가장 어울리고 효과적)

🥙 마이크로서비스란?

모노리스 구조

  • 하나의 단위로 개발되는 일체식 애플리케이션
    (3티어로 구성: 클라이언트, 모노리스, 데이터베이스)
  • 확장 시 모노리스 시스템 모두를 전부 다시 빌드하고 배포해야 함
  • 데이터베이스는 통합되어 탄력적 대응 불가능

마이크로서비스

  • 서버가 여러 조각, 서비스가 별개의 인스턴스로 로딩
  • 확장 시 특정 기능별로 독립적으로 확장 가능
  • API를 통해서만 느슨하게 연결됨
  • 다른 서비스와 연계된 API에 영향을 주지 않는다면 내부의 언어나 저장소는 자율적으로 선택 가능

폴리글랏(Polyglot)

특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식

마이크로서비스와 SOA 차이

  • SOA(Service Oriented Architecture): 컴포넌트를 모아 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화
  • MSA는 클라우드 인프라의 등장으로 하드웨어를 유연하게 다룰 수 있게 되면서 실현되었음
  • MSA에서는 모듈화 방식을 강화 (저장소 분리, 각 서비스가 느슨하게 연계)

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

조직의 변화: 업무 기능 중심 팀

업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만든다.
다양한 역할(기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자, 설계자, 테스터 등)로 구성된다.
개발과 운영을 동시에 수행한다.

관리체계의 변화: 자율적인 분권 거버넌스, 폴리글랏

마이크로서비스를 만드는 조직은 중앙의 강력한 거버넌스를 추구하지 않는다. 빠르게 서비스를 만드는 것을 최우선의 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다.

각 서비스 팀이 팀에 맞는 개발 언어 및 저장소를 선택하는 것을 각각 폴리글랏 프로그래밍, 폴리글랏 저장소라고 한다.

개발 생명주기의 변화: 프로젝트가 아니라 제품 중심으로

옛날: 장기간의 프로젝트를 통해 개발을 완료하고 -> 운영 조직에 넘기는 방식
마이크로서비스 개발: 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발뿐만 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 한다. -> 애자일 개발 방식

개발 환경의 변화: 인프라 자동화

개발 지원 환경 자동화: 소스코드를 빌드하는 도구, 빌드와 동시에 테스트하는 도구, 가상화된 인프라에 배포하는 도구 (=DevOps 개발 환경)

저장소의 변화: 통합 저장소가 아닌 분권 데이터 관리

마이크로서비스는 폴리글랏 저장소 접근법을 선택하며,
서비스 별로 데이터베이스를 갖도록 설계한다.
= 다른 서비스의 저장소를 직접 호출할 수 없고 API를 통해서만 접근해야 한다.

비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요하다.

마이크로서비스의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 데이터 일관성 문제
-> 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌, 비동기 이벤트 처리를 통한 협업 강조

결과적 일관성(Eventual Consistency)

두 서비스의 데이터가 일시적으로 불일치하는 시점에 있고 일관성이 없는 상태지만 결국에는 두 데이터가 같아진다.
여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 각각 수행하고 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성을 맞추는 개념이다.

위기 대응 방식의 변화: 실패를 고려한 설계

소프트웨어는 모두 실패한다.
다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고,
시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다.

profile
자존감은 일상의 성실함으로부터 온다

0개의 댓글