도메인 주도 설계로 시작하는 마이크로서비스 개발

아마존 비지니스 민첩성의 비밀

성공한 인터넷 기업들과 비즈니스 민첩성

성공 사례: 아마존의 배포 속도

클라우드 인프라의 등장

11.6초마다 배포되고 있다. 11.6초마다 다른 어플리케이션인 것이다. 이럴 수 있는 배경으로 마이크로서비스 아키텍쳐와 클라우드 환경이 있다. 이것은 비지니스 민첨성의 차이로 이어지고 서비스 성공과 직결된다.

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

• 스케일업(수직확장): 시스템 자체의 물리적 용량을 증가시켜 성능을 증가
• 스케일아웃(수평확장): 기존 시스템과 같은 다수의 장비를 병행 추가하여 가용성 증가
• 특정 서비스만 탄력성 있게 확장
  • 타임세일 서비스시 타임세일 서비스만 스케일업/스케일아웃
• 클라우드 친화 애플리케이션(Cloud Friendly Application) : 큰 덩어리로 클라우드 환경에 올라갈 수 있게만 한 애플리케이션
• 클라우드 네이티브 애플리케이션(Cloud Native Application) : 독립적으로분리되어 배포될 수 있는 조각으로 구성된 애플리케이션 - 클라우드 인프라에 가장 어울리고 효과적 => 궁극적으로 클라우드 네이티브로 전이해야한다.

이렇게 정리하다가 가끔 이런식으로 내생각달고 이러면 될듯

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

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

• 각 서비스가 독립적이어서 서로 다른 언어로 개발하는 것도 가능하므로 각 서비스의 소유권을 분리해 서로 다른 팀이 개발 및 운영할 수 있다.
• 각기 저장소가 다르므로 업무 단위로 모듈 경계가 명확하게 구분된다.

SOA와 마이크로서비스

• 특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 가리켜 폴리글랏(Polyglot)하다고 표현한다.
• 과거 CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리했으나 데이터 저장소까지는 분리하지 못했다.

• 이론적으로 SOA와 MSA는 거의 동일할수도 있지만 전자가 이론으로만 남게된 이유는 각종 인프라(AWS와 같은)의 부재와 디테일(저장소의 분리) 때문이다.

• MSA에서는 두 가지 개념으로 모듈화 방식을 강화해서 실현하였다.
  • 서비스별 저장소를 분리해서 다른 서비스가 저장소를 직접 호출하지 못하도록 캡슐화한다. 즉, 다른 서비스의 저장소에 접근하는 수단은 API 밖에 없다.
  • REST API와 같은 가벼운 개방형 표준을 사용해 각 서비스가 느슨하게 연계되고 누구나 쉽게 사용할 수 있다.

    요즘은 gRPC를 통해 서비스간 API를 구현하는 것 같다.

마이크로서비스를 위한 조건은 무엇인가?

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

• 멜빈 콘웨이의 콘웨이 법칙
• 업무 기능 중심 팀은 다양한 역할(기획자, 디자이너, 프론트엔드 개발자, 백엔드 개발자, 설계자, 테스터)로 구성된다.
• 다기능 팀(Cross-Functional Team)이나 two pizza team이라고도 부른다. 피자 두 판으로 서로 빈번히 의사소통하며 함께 식사할 수 있는 정도의 팀원 수를 의미한다.

애자일에 용이한 구성임을 알 수 있다. 뒤에도 나오겠지만 MSA는 단순히 아키텍쳐만을 의미하지는 않는다.

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

• 아마존에서는 다기능 팀이 개발과 운영을 책임진다.
• “you build it. you run it.”

즉, DevOps 개념 또한 마이크로서비스와 뗄 수 없는 것이다.

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

• 기존에는 대부분의 애플리케이션 개발 모델이 프로젝트 단위였다. 개발을 완료하고 나면 이를 운영조직에 넘기는 방식으로 진행됐다.
• 또한 초기에 모든 일정을 계획했다.
• 마이크로서비스팀의 개발은 비지니스의 갑작스런 트렌드 변화에 유연하게 대처해야하고 개발 뿐만 아니라 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 한다.
• 간단히 말해 애자일 개발방식이다.

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

• 최근에는 배포 환경이 마이크로서비스 개수에 따라 급격하게 늘어나기 때문에 이를 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식인 Intrastructure as Code가 각광받고 있다.

역시나 DevOps 이야기

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

• 단일 저장소 방식은 과거 스토리지 가격 및 네트워크 속도에 따른 데이터의 안정성과 효율성을 추구한 결과이다.
• 폴리글랏 저장소(polyglot persistence) 접근법을 위해서는 비지니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요하다
• 이를 위해 비지니스 정합성을 맞춰야하는 데이터 일관성 문제가 발생한다.
• 보통은 2단계 커밋(two-phase commit) 같은 분산 트랙잭션 기법을 사용하지만 저장소에 따라(NoSQL) 지원하지 않을수도 있다.
• 이런 경우에는 두 서비스를 단일 트랙잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조한다. 이를 결과적 일관성(Eventual Consistency)라고 부른다.
• 여러 트랜잭션을 하나로 묶지 않고 별도의 로컬 트랜잭션을 수행한 뒤, 일관성이 달라진 부분은 체크해서 보상 트랜잭션으로 일관성을 맞추는 개념이다.
• todo: 19page 그림그리기

말은 그럴듯하지만 결국 아름다운 구조를 위해 발밑으로는 열심히 노를 저어야 한다는 이야기이다. 그래도 가치는 있다.

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

• 아마존의 부사장인 버너 보겔스는 소프트웨어는 모두 실패한다라고 말했다.
• 실패해서 더는 진행할 수 없을 때에도 자연스럽게 대응할 수 있도록 설계해야 한다는 이야기이다. 이를 내결함성(Fault Tolerance)라고 한다.
• 예전의 시스템 아키텍쳐는 결함이나 실패 무결성을 추구했다.
• 내결함성을 위해 완벽히 테스트할 수 있는 환경과 실시간 모니터링 체계를 갖춰야 한다. 넷플릭스에서는 카오스 몽키라는 장애를 일부러 발생시키는 도구를 쓰기도 한다.

정리

• MSA라는 용어를 문자 그대로 아키텍쳐나 기술로만 생각하는 경향이 있는데 이는 바람직하지 못하다.
• MSA는 다양한 사람들이 만나서 협업하는 방식, 조직 문화의 진화된 결과물로 생각해야 한다.

• 서비스 라우터에서 서비스 디스커버리한테 서비스가 어디있는지 물어본다.
• 로드밸런서에 의해 그 서비스의 어느 인스턴스가 서비스할지를 정한다.
• 하드코딩되어야했을 값들은 configuration store에 별도로 저장된다.