마이크로서비스를 위한 조건은 무엇인가
업무 기능 중심 팀
콘웨이 법칙: 업무 기능 중심 팀, you built it, you run it
점진 반복적인 모델, 제품 중심의 애자일(agile) 개발 방식을 채용한다. -> 고객의 고정된 요건을 받아 기능이 만족되면 제공 및 전달하는 개념으로 보지 않고 요건의 변화에 따라 지속적으로 개선되고 발전시킬 제품으로 바라본다.
즉, 마이크로서비스는 계속 피드백을 받아 지속적으로 변화, 개선되고 향상되는 존재다.
MSA는 인프라 자동화가 필수이다.
컴파일, 유닛테스트 => 기능 테스트 => 통합 테스트 => 인수 테스트 => 성능 테스트 => 배포
빌드 => 개발 환경 배포 => 테스트 환경 배포 => 스테이징 환경 배포 => 운영 환경 배포
infrastructure as Code == 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식
폴리글랏
polyglot: 특정 서비스를 구축하는데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식
각 저장소가 서비스별로 분산돼 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수 없고 API를 통해서만 접근해야 한다는 의미. 이러한 구조에서는 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요하다. 이로 인해 등장하는 문제가 있다. 각 마이크로서비스의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야 하는 "데이터 일관성" 문제다.
데이터 일관성 처리를 위해서는 보통 2단계 커밋(two-phase commit)같은 분산 트랜잭션 기능을 사용하는데, 각각 다른 서비스를 하나의 트랜잭션으로 묶다 보면 각서비스의 독립성도 침해되고 NoSQL 처럼 2단계 커밋을 지원하지 않는 경우도 있다. MS는 문제해결을 위해 비동기 이벤트 처리를 통한 협업을 강조한다. 이를 가리켜 결과적 일관성(Eventual Consistency)
각 트랜잭션을 분리하고 큐메커니즘을 이용해 보상 트랜잭션으르 활용하는 방법
ex) @nestjs/cqrs(?)
실패를 고려한 설계
다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고, 시스템의 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다. 서킷브레이커패턴을 예로 들수있다. 회로 차단기처럼 각 서비스를 모니터링하고 있다가 한 서비스가 다운되거나 실패하면 이를 호출하는 서비스의 연계를 차단하고 적절하게 대응하는 것을 말한다. 넷플릭스에서는 카오스 몽키라는, 장애를 일부러 발생시키는 도구를 만들어 이러한 탄력적인 아키텍처가 제대로 동작하는지 점검하기도 한다.
