Microservices
MSA
기술의 진화로 짚어보는 마이크로서비스 도입의 허와 실
『마이크로서비스 도입, 이렇게 한다』 책의 내용에서 한국어판 특별 부록의 내용을 일부 정리한다.
마이크로서비스는 SOAService Oriented Architecture를 여러 개 나눠서 분산 배치하는 구조 같다. 기술적인 성숙도가 떨어지고 복잡성만 부가. 하지만 마이크로서비스는 클라우드로 추진력을 얻게 됐다. VM과 컨테이너로 온프레미스 CI/CD 이상의 중립적인 패키징 배포 표준화의 길이 열림. 특히 K8s는 수천 개의 컨테이너도 어렵지 않게 관리할 수 있어 마이크로서비스의 확산에 기여.
XML기반 RPC에서 HTTP를 기반으로 하는 RESTful API의 등장. JSON 주도. 동기식 대신 비동기식 호출 일반화. 로깅과 모니터링의 어려움은 ELK와 Prometheus, Grafana 스택이 상당 부분 해소. 분산 환경에서 여러 소프트웨어 엔티티들 사이를 연결하는 데이터 파이프라인 구성은 Kafka.
마이크로서비스는 유닉스 스타일의 파이프라인 작업 방식인 유닉스 철학과도 유사. 정보은닉과 모듈화 프로그래밍과도 유사. 마이크로서비스 아키텍처는 필요에 따라 HTTP를 기반으로 하는 동기식 통신 방식(RESTful API)과 메시지 큐를 기반으로 하는 비동기식 통신 방식(이벤트 기반 통신 방식)을 조합하여 복잡도를 줄이기 위해 ‘똑똑한 종단점과 멍청한 파이프’라는 원칙을 장려한다.
컴파일을 자동화하는 autoconf가 나왔지만 복잡성은 줄어들지 않았다. 자바의 WORA는 패키지 배포라는 또 다른 악몽의 시작이었다. class → jar → war로 발전. 의존성 해결을 위해 POM기반 메이븐 프로젝트 결성. node에서도 npm의 등장 이후 deno에서는 node_modules의 단점을 극복. (golang처럼 url 기반 모듈 관리)
CI: 변경 내역이 있을 경우 자동으로 빌드하고 테스트, CD: 자동으로 릴리즈. 시스템 구축 자동화의 등장. Cloud Foundry, Heroku. 이후 K8s는 게임의 규칙을 바꾸고 있다. 물류 역사에서도 컨테이너의 등장으로 표준화가 이뤄졌고 이를 토대로 전세계 물동량의 60% 이상 소화.
상태형 서비스인 경우 데이터베이스가 가장 큰 문제. 백업 복구시 데이터베이스를 분해해서 여러 서버로 분산했다면 이를 원상복구해서 하나로 합치는 작업은 매우 까다로울 것. 마이크로서비스는 비지니스 로직이 여러 서버에 분산되어 있기 때문에 디버깅 또한 어려움. 따라서 미리 모니터링 시스템 구축을 권장. 자동화된 전 구간 테스트 방법이 마땅찮다.
Last Modified: 2022/01/28 12:29:00