요약
- 마이크로서비스를 위한 조건을 이해함.
- 조직의 변화 → 업무 기능 중심 팀
- 관리체계의 변화 → 자율적인 분권 거버넌스, 폴리글랏
- 개발 생명주기의 변화 → 프로젝트가 아니라 제품 중심
- 개발 환경의 변화 → 인프라 자동화
- 저장소의 변화 → 통합 저장소가 아닌 분권 데이터 관리
- 위기 대응 방식의 변화 → 실패를 고려한 설계
- MSA의 성공을 위해서는 아키텍처 및 개인 역량에만 집중할 것이 아니라 조직 문화, 일하는 절차 등을 고려해야 함.
메모
1.3 마이크로서비스를 위한 조건은 무엇인가?
- MSA의 주요 특징을 살펴본다.
- 마이크로서비스를 잘 구현하고 있는 조직의 사례
- 기술에만 의존한 아키텍처 스타일을 추구하는데 그치지 않고, 개발 환경, 문화, 일하는 방식과도 연계돼 있음.
1.3.1 조직의 변화: 업무 기능 중심 팀
- 콘웨이 법칙은 멜빈 콘웨이가 정의한 조직과 조직이 개발한 소프트웨어의 관계를 정의한 법칙임.
- 시스템을 개발할 때 항상 시스템의 모양이 팀의 의사소통 구조를 반영함.
- 예전에 일하는 방식
- 하나의 애플리케이션을 만드는데
- 기술별로 팀이 나눠져 있음.
- 하나의 애플리케이션을 만드는 데 세 팀간의 의사소통이 필요함.
- 이러한 팀 구조에서는 팀 간의 의사결정도 느리고 의사소통도 어려움.
- 마이크로서비스팀의 구조는 어떻게 돼야 하는가?
- 업무 기능 중심의 팀이어야 함.
- 역할 또는 기술별로 팀이 분리되는 것이 아니라 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀이 되어 서비스를 만드는 것을 의미함.
- 다양한 역할로 구성되기에 이 팀은 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 모두 갖춤.
- 의사소통도 원활하고 의사결정도 빠르게 진행됨.
- 이러한 팀을 다기능 팀(Cross-Functional Team)이라고도 함.
- 개발 이후에 운영할 책임까지 짐.
- 아마존에서는 이런 팀을 “two pizza team” 이라고 표현함.
- 피자 두판을 서로 빈번히 의사소통하며 함께 식사할 수 있는 정도의 팀원 수를 의미함.
- 이러한 팀은 마이크로 서비스를 만드는 데 필요한 기능과 기술을 팀 내부에 모두 가지고 있으므로 다른 마이크로서비스팀과 협력할 일이 적을 수밖에 없음.
1.3.2 관리체계의 변화: 자율적인 분권 거버넌스, 폴리글랏
- 마이크로서비스를 만드는 조직은 중앙의 강력한 거버넌스를 추구하지 않음.
- 마이크로서비스팀은 빠르게 서비스를 만드는 것을 최우선 목적으로 둠.
- 스스로 효율적인 방법론과 도구, 기술을 찾아 적용함.
- 현실 세계에 비유하면 작은 정부, 지방자치제도와 유사함.
- ex) 상품팀은 상품 검색 서비스를 위해 빠른 검색에 특화된 NoSQL인 몽고 디비와 Node.js를 선택함.
- ex) 계약팀은 계약 서비스를 위해 자바언어와 오라클, 레디스를 선택함.
- 이처럼 각 서비스 팀이 팀에 맞는 개발 언어 및 저장소를 선택하는 것을 각각 폴리글랏 프로그래밍, 폴리글랏 저장소라고 함.
1.3.3 개발 생명주기의 변화: 프로젝트가 아니라 제품 중심
- 기존의 대부분의 애플리케이션은 개발 모델이 프로젝트 단위였음.
- 개발완료 후 이를 운영 조직에 넘기는 방식으로 진행함.
- 초기에 모든 일정을 계획함.
- 프로젝트 기간 중에 발생한 변경이나 새로운 아이디어를 포용하지 못함.
- 마이크로서비스팀의 개발은 비즈니스의 갑작스런 트렌드 변화에 유연하게 대처해야함.
- 개발과 운영을 포함한 소프트웨어의 전체 생명주기를 책임져야 함.
- 소프트웨어를 완성해야할 기능들의 집합으로 보지 않음.
- 비즈니스를 제공하는 제품으로 바라보고 우선 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어를 개발함
- 프로젝트 형태의 폭포수 모델이 아니라 점진 반복적인 모델인 제품 중심의 애자일 개발 방식을 채용함.
- 2~3주 단위의 스프린트를 통해 소프트웨어를 개발 및 배포해서 바로 피드백을 받아 소프트웨어에 반영할 수 있게 함.
- 즉, 단순히 소프트웨어를 한시적 프로젝트로 보지않고 요건의 변화에 따라 지속적으로 개선되고 발전시킬 제품으로 바라봄.
1.3.4 개발 환경의 변화: 인프라 자동화
- 마이크로서비스는 독립적으로 배포됨.
- 마이크로서비스처럼 여러 개로 쪼개진 상태에서는 수동 배포 방식은 바람직하지 않음.
- 여러개의 바이크로서비스를 빠르게 배포하기 위한 방법이 필요함.
- 전체 소프트웨어 구현 과정은 다음과 같음.
- 개발 환경 준비(인프라)
- 개발(분석/설계/개발)
- 개발 지원 과정(빌드/테스트/배포)
- 개발 환경 준비에서 클라우드 인프라를 활용하면 쉽고 빠르게 개발환경을 준비할 수 있어서 팀의 개발속도가 높아짐.
- 개발 완료 후 필요한 빌드, 테스트 배포의 속도는 어떻게 높일 수 있는가?
- 자동화임.
- 소스코드 빌드 도구, 빌드와 동시에 테스트 하는 도구, 가상화 인프라에 배포하는 도구가 모두 필요함.
- 이 같은 환경은 개발과 운영을 동시에 수행하는 데브옵스(DevOps)를 궁극적으로 가능하게 함.
- 이를 인프라 자동화라고함.
- 인프라 자동화는 마이크로서비스 개발 과정의 필수조건임.
- 최근에는 배포 환경이 마이크로서비스 개수에 따라 급격하게 늘어나고 있음.
- 이를 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식임 “Infrastructure as Code” 가 각광받고 있음.
- 코드를 이용해 인프라 구성부터 애플리케이션 빌드, 배포를 정의함.
- 수많은 하드웨어 리소스 설정을 동일하게 통제할 수 있음.
- 상황에 따른 검증되고 적절한 설정을 쉽게 복제하고 누구한테나 공유할 수 있게 됨.
1.3.5 저장소의 변화: 통합 저장소가 아닌 분권 데이터 관리
- 이전의 모노리스 시스템은 단일 통합 데이터베이스를 사용함.
- 과거 스토리지 가격 및 네트워크 속도에 따른 데이터의 안전성과 효율성을 추구한 결과임.
- 그래서 이때는 데이터를 잘 정리하는 정규화가 반드시 추구해야하는 가치였음.
- 하지만 지금은 스토리지 가격이 저렴하고 네트워크 대역폭이 매우 커짐.
- 데이터를 억지로 작은 공간에 넣을 필요가 없음.
- 마이크로서비스는 폴리글랏 저장소 접근법을 선택함.
- 즉 각 저장소가 서비스별로 분산돼 있어야하고, 다른 서비스의 저장소를 직접 호출할 수 없고, API를 통해서만 접근해야 함.
- 그런데, 이 구조에서 비즈니스 처리를 위해 일부 데이터의 복제와 중복 허용이 필요함.
- 이때 항상 등장하는 문제로 각 마이크로서비스의 저장소에 담긴 데이터의 비즈니스 정합성을 맞춰야함.
- 즉, 데이터 일관성의 문제가 생김
- 데이터 일관성 처리를 위해 2단계 커밋과 같은 분산 트랜잭션 기법을 사용함.
- 하지만 다른 서비스를 하나의 트랜잭션으로 묶으면 각 서비스의 독립성에 침해됨.
- 또, NoSQL 저장소 같은 경우, 2단계 커밋을 지원하지 않는 경우가 있음.
- 따라서 마이크로 서비스는 두 서비스를 단일 트랜잭션으로 묶는 방법이 아닌 비동기 이벤트 처리를 통한 협업을 강조함.
- 이를 결과적 일관성(Eventual Consistency)라는 개념으로 표현하기도 함.
- 두 서비스의 데이터가 일시적으로 불일치하는 시점이 있지만 결국 두 데이터는 같아진다는 개념임.
- 즉, 하나의 트랜잭션으로 묶지 않고 개별 트랜잭션을 수행 후, 보상 트랜잭션으로 일관성을 맞추는 방식임.
- p19 주문 배송 예시 참고
1.3.6 위기 대응 방식의 변화: 실패를 고려한 설계
- 예전의 시스템 아키텍처는 무결함이나 실패 무결성을 추구함.
- 시스템이 다운되지 않기 위해 완벽을 추구해야 하며 강건해야 했음.
- 하지만 어떤 시스템도 실패하지 않을 수 없음.
- 실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는게 더 쉽고 효율적임.
- 다양한 실패에 대비하기 위해 완벽히 테스트할 수 있는 환경을 마련해야 함.
- 시스템의 실패를 감지하고 대응하기 위한 실시간 모니터링 체계도 갖춰야함.
- 넷플릭스의 카오스 몽키는 장애를 일부로 발생시키는 도구를 만들어서 탄력적인 아키텍처가 제대로 동작하는지 점검하기도함.
1.4 정리
- MSA라는 용어를 문자 그대로 아키텍처로나 기술로만 생각하는 경향이 있음.
- 이는 바람직하지 못함.
- 소프트웨어 개발활동은 홀로 진행하는 것이 아님.
- 다양한 사람들의 의견을 받아 나누는 논의 중에 진정 가치 있는 아이디어가 나옴.
- 협업을 통해 개발하며, 다른 사람들의 피드백을 통해 끊임없이 개선해야 하는 창의적인 활동임.
- MSA의 성공을 위해서는 아키텍처 및 개인 역량에만 집중할 것이 아니라 조직 문화, 일하는 절차 등을 고려해야 함.
댓글