통합, 테스팅, 모니터링#
통합#
통합 규약
- 데이터베이스 통합은 최대한 피하자.
- REST와 RPC의 장단점을 이해하고 요청/응답을 통합하는 좋은 출발점으로 REST를 고려하자.
- 오케스트레이션보다는 코레오그래피를 우선하자.
- 구성 계층으로서의 사용자 인터페이스를 생각하자.
모놀리스 분해하기#
배포 파이프라인#
모놀리스 분해 시 주의할 점
- 한 서비스를 다른 서비스와 독립적을 릴리스할 수 있는 능력을 유지하는데 집중하고, 어떤 기술을 선택하든 이 능력을 지원하는지 확인하자.
- 마이크로서비스당 하나의 저장소를 추천한다
- 개별적인 마이크로서비스를 배포하고자 한다면 마이크로서비스당 하나의 CI 빌드가 필요하다.
- 호스트 및 컨테이너당 단일 서비스, single-service per host/container로 옮기자.
- LXC, Docker 추천한다.
패커, Packer
이미지를 훨씬 쉽게 만들기 위해 고안된 도구
ex) VMWare, AWS 등
자동화는 필수다#
빌드 파이프라인
컴파일&빠른테스트 -> 느린테스트 -> 사용자 인수테스트 (UAT) -> 성능테스트 -> 실환경
특정 서비스를 다양한 환경에 서비스 자체롤로 배포할 수 있는 도구는 중요하다.#
테스팅#
스모크 테스트, smoke test
배포 후 테스트하는 방법으로 2버전 배포 후, 부하를 변경, 혹은 DNS 엔트리 변경을 통한 테스트 방법
- 빠른 피드백을 위해 최적화하고, 테스트를 종류별로 적절히 분리하라.
- 소비자 주도 계약을 이용하여 가능하면 어디서든지 엔드 투 엔드 테스트의 필요성을 줄여라.
- 팀 간 대화의 초점을 맞추기 위해 소비자 주도 계약을 사용하라.
- 테스팅에 더 많은 공을 들이는 것과 실환경에서 빠른 문제의 발견 사이의 절충점을 이해하도록 노력하라.
- 평균 무고장 시간 (MTBF, mean time between failures)와 평균 수리 시간(MTTR, mean time to repair) 사이의 최적화도 고려하자
카나리아 릴리스
버전들을 더 오래 공존 시키는 방법. 실 트래픽을 유입시킴
모니터링#
서비스 기준의 모니터링#
- 최소한의 필수 사항ㅇ으로 응답시간을 추적하고 그다음에 에러율을 추적하자.
- 애플리케이션 라벨 측정 지표에 대해 작업하자.
- 모든 하위 응답 상태를 추적하자.
- 최소한 하위 호출의 응답시간을 포함하고, 할 수 있다면 에러율도 추적하자 ( 히스트릭스 )
- 측정지표가 수집될 방식과 저장소를 표준화하자.
- 가능하면 표준 저장소와 포맷으로 로깅하자.
- 모든 서비스가 다른 형시을 사용한다면 취합이 어렵다.
- 불량 프로세스를 추적하고 용량 계획을 수행할 수 있도록 하부 운영 체제를 모니터링하자.
시스템 기준의 모니터링#
- 애플리케이션 레벨 측정지표와 함께 CPU처럼 호스트 레벨 측정지표도 취합하자.
- 여러분의 측정지표 저장소 도구가 시스템 또는 서비스 레벨로 집계할 수 있는지 확인하고 개별 호스트 레벨까지 탐색해서 보여주자.
- 여러분의 측정지표 저장소 도구가 시스템의 추이를 이해할 정도로 오랜 기간 데이터를 유지할 수 있는지 확인하자.
- 로그를 취합하고 저장하는데 질의 가능한 단하나의 도구를 사용하자.
- 상관관계 ID를 사용하는데 있어 표준화를 반드시 고려하자.
- 대응 행동 요청이 필요한 것이 무엇인지 이해하자. 그리고 주의 경보와 대시보드를 적절히 구조화하자.
- 수로나 리만 같은 도구가 여러분에게 적합한지 검토하고 모든 다양한 측정지표를 취합하는 방식을 통합할 수 있는지 조사하자.
Reference : Build Microservice By Sam Newman, Publisher: O’Reilly
Last update: 2020년 5월 4일 12:56:46