MSA 모니터링
- 중앙집중형 모니터링 서비스가 필요하다.
- MSA 내의 모든 로그 메세지 수집
- 트랜젝션 연결 추적
- MSA는 로그리파이너나 텔레메트리 DB로 로그를 전송
- 스트리밍 된 데이터를 NoSQL로 저장할 수도 있고, 상용제품을 사용해도 된다.
장애 대비
-
장애 시, 전파 차단이 가장 중요하다.
-
장애가 전파된다는 것이 MSA의 약한 고리이다.
-
서킷 브레이커 - 기본적 전략 (Hystrics)
-
콜백 메세징 (서버가 Down일 때, 기본값 설정 후 사용)까지 하이스트릭스가 처리해준다.
-
퍼블릭 클라우드를 사용할 시 여러개의 서비스 리전을 사용하자
-
카나리 배포전략 사용
- 배포 시 일부만 새로운 버전을 올려보고, 잘 돌아가면 점점 전체 배포
-
장애 시나리오를 대비해 가상의 장애 상황을 가정, 행동 대응해보자
-
Chaos Monkey
- 넷플릭스가 만든 인스턴스를 하나씩 꺼가면서 테스트해보는 툴
- 다양한 카오스 툴이 있다.
트랜젝션
모놀리식 -> MSA로 전환을 할 때에 라우터를 두고 대부분의 요청을 WAS로 보내고
나머지 조금만 새로운 MicroService로 요청을 보내보고 잘되면 확장하는 식으로 진행
전환 시에 DATA 이관 전략은 스키마로만 나눠져도 괜찮다.
- 다 죽이고 ETL (다운타임 감수 가능할 시에 가장 깔끔)
- 둘 다 사용하고 새 DB만 Update, 모놀리스 DB는 읽기전용으로 (동시 운영이 필요할 때)
- 새 DB에 쓰고 CDC(Change Data Capture)를 이용 (유료다)
MSA DB 설계 시 현실적으로 같은 엔티티를 동시에 CUD 안하도록 하기
CAP theorem
분할내성, 지속성, 가용성
DB는 이 중 2가지만 선택할 수 있다.
2PC
대표자가 설문조사하는 방법인데 요즘은 사용되지 않음
SAGA 패턴
다중 DB 및 MS 환경에서 각자가 자신의 Tx에만 관심을 가지는 것
보상 트랜젝션을 처리하고 삭제로직을 넣음으로서 정합성을 유지
코레오그래피 (이벤트 Pub/Sub)
실패했을 경우 fallback URL 제공
단점은 시스템 복잡도가 증가하게 된다.
CQRS
쓰는 놈과 읽는 놈 역할을 따로 두는 방식
- 수준 1 : Bounded context 시와 마찬가지로 한쪽만 CUD하기
- 수준 2 : Read-Replica 운영하기 / 지속적 동기화
- 수준 3 : CUD DB, R DB 분리하기
- 수준 4 : 이벤트 소싱
이벤트 소싱
- MS의 모든 TX를 이벤트로 스트리밍
- 그때그때 스냅샷이 쌓인다.
- 수준 2에서 수준 4로 넘어가는게 효율적이다.
Anti 패턴
마이크로리스 패턴
대부분 모놀리스를 분해하는데, 분해 실패 시에 발생하는 것이 마이크로리스
디커플링을 실패하고 복잡도만 높아지기 때문에, 차라리 모놀리스를 사용하는게 낫다
데드스타 패턴
DB를 제대로 안나눈다
서비스를 전부 다 분리했는데 모든 서비스가 같은 DB를 바라보고 있을 경우
별같이 생겨서 데드스타라고 부름
보완 설계 패턴
서비스 메시 (Service Mesh)
내부 트래픽이 많다보니 문제들이 생김 (로깅 등)
그래서, 잡스러운 것은 사이드카에 실어버리고 내가 만든 로직에만 집중하자는 패턴
사이드카를 통하여 서로를 호출하며, 프록시화 되어있다.
로직은 마이크로서비스에 나머지는 사이드카에 담는다
Istio가 서비스 메시 / 로깅 시큐리티 라우팅, 디스커버리 (마이크로서비스 주소) 등
각 마이크로서비스는 서로 프록시를 통해서 통신하게 된다.
