4장 : 마이크로서비스와 애자일 개발 프로세스
- 애자일 프로세스 : 피드백을 통한 지속적인 개선을 추구
가장 효율적인 의사소통 구조와 협업 체계를 가진 다기능 팀을 필요로 하고, 그러한 다기능 팀이 만들어내는 결과물이 “마이크로서비스”다
애자일에서 설계/개발 공정에 대해 상세히 설명하지 않는 까닭은 애자일 자체가 성숙된 개발문화에서 가장 효과가 좋은 프랙티스들을 가속화하고 기존 공정의 군더더기나 낭비를 제거하는 방식에서 시작됐기 때문이다
프랙티스(지속적 통합, 데브옵스, 등)
이전의 개발 프로세스에서 강조했던 너무 세밀해서 과하고 무거운 설계 산출물의 무용함을 인식하고 실용적으로 접근해야 한다는 것을 강조한다
단순한 설계 : 어느 정도 개발을 시작할 수 있을 정도의 가벼운 설계
설계를 단순하고 간단하게 하고 바로 개발로 들어간 뒤에 실제로 동작하는 소프트웨어를 보면서 다시 지속적으로 리팩터링하는 방식이 더 효율적
4.1 : 도메인 주도 설계와 마이크로 서비스
DDD에는 전략적 설계, 전술적 설계라는 설계 영역이 있다
- 전략적 설계
도메인 전문각 및 기술팀이 함께 모여 유비쿼터스 언어를 통해 도메인 지식을 공유 및 이해하고,
이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트로 정의하고 경계의 관계를 컨택스트 맵으로 정의하는 활동
Ubiquitous Language(보편 언어) : 도메인 전문가, 아키텍트, 개발자 등 프로젝트 구성원 모두에게 공유된 언어를 뜻한다.
Bounded Context : 동일한 맥락의 경계 또는 범위를 표현하는 것
- 전술적 설계
식별된 바운디드 컨텍스트 내의 도메인 개념인 도메인 모델을 구성하는 유용한 모델링 구성요소
4.2 : 기민한 설계/개발 프로세스
4.2.1 : 점진/반복적인 스크럼 생명주기
- 스크럼 팀
스프린트가 진행되는 팀 (스크럼 마스터, 팀 멤버로 구성)
여러 직능을 가진 전문가들이 같은 팀에 모여 있으므로 의사결정이 빠르고 협업이 긴밀하다
스크럼 마스터는 협업을 촉진하고 팀의 장애물을 제거하는 역할을 수행한다
- 스크럼 미팅
스크럼 팀은 매일 아침 각자의 자리에 서서 짧게 진행되는 스탠드업 미팅을 통해 각자의 일을 투명하게 공유한다
- 스프린트 계획 수립
시스템의 모든 요구사항은 제품 백로그에 담긴다
일정에 맞게 스프린트를 몇번 수행할 것인가가 결정된다 (보통 1~4주 기간)
제품 백로그에 담긴 요구사항을 각 스프린트에 적절히 분배한다
스프린트가 종료되면 백로극 완료 일감을 기준으로 팀의 생산성이 결정되고, 이를 속도라 한다
이 속도를 기준으로 다음 스프린트 계획을 세운다
전통적인 관리는 범위가 고정되어 있고 일정, 비용, 품질이 그에 맞춰 유동적이었지만
애자일 관리는 일정, 비용, 품질이 고정되어 있고 그에 따라 범위가 조정된다
이에 따라 우선순위를 정하는 것이 매우 중요해지고, 우선순위가 높은 시스템의 핵심 기능에 집중할 수 있게 해준다
- 시연
스프린트 마지막 활동으로, 초기에 정의한 백로그가 모두 구현되고 그 요건을 만족하는지 확인하는 자리
피드백을 받고, 다음 스프린트에 반영할 요건들을 확인할 수 있다
- 회고
팀원들이 자기 스스로를 돌아보는 과정
마이크로 서비스 설계 및 개발하는 과정에서 좋았던 방식, 안좋았던 방식을 논의하고 개선점을 찾아 다음 스프린트에 적용할 수 있다
4.2.2 : 아키텍처 정의와 마이크로서비스 도출
- 아키텍처 정의, 마이크로서비스 도출
구현 스프린트를 본격적으로 진행하기 위해 준비하고 계획하는 활동
- 아키텍처 정의
기술 세부사항은 늦게 결정할 수 있어야 한다
순수 비즈니스 로직이 존재하는 내부 영역, 기술 영역을 표현하는 외부 영역으로 구분하면
외부 영역은 언제든지 교체될 수 있으므로 핵심인 내부 영역에 집중하고, 외부 영역은 천천히 결정해도 된다는 뜻이다
하지만, 이러한 유연성을 항상 유지해야 하지만 최소한의 개발 및 테스트 환경을 먼저 준비하는 것은 스프린트 진행에 효과적이다
예를 들어, 도커, 쿠버네티스, 스프링 부트 기반과 같이 마이크로서비스 개발 환경을 미리 결정해 둔다면 빠르게 개발 환경을 구축하고 곧바로 개발 과정으로 진입할 수 있다
물론 스프린트 과정을 통해 개선되고 정제될 것이다
- 마이크로서비스 도출
스크럼 팀이 개발할 전체 마이크로서비스들을 파악하는 작업
DDD의 “전략적 설계” 기법을 활용해 마이크로서비스를 도출하고 그것들 간의 대략적인 매핑 관계를 정의
마이크로서비스 개발 우선순위에 근거해 스크럼 팀에 배분해서 스프린트 진행
최종 결과물은 컨텍스트 맵이다
컨텍스트 맵 : 식별된 마이크로서비스와 그것들 간의 의존관계
4.2.3 : 스프린트 내 개발 공정
프런트엔드 개발자와 백엔드 개발자의 영역들은 “API 설계”를 통해 진행되고, 나머지 활동은 각각 내부적으로 진행한다
백엔드 설계 및 개발
백엔드 설계의 시작은 API 설계
API 설계는 각 백엔드 마이크로서비스가 프런트엔드에 제공할 서비스 명세
초기에 API 설계를 통해 프런트엔드 영역과 협의 및 조정해야 한다
다음으로는 정의된 내부 구조에 따라 “도메인 모델” “데이터 모델”을 설계하는 것이다
OOAD (Object Oriented Analysis Design) 방식에서는 UML 등을 활용해 설계 모델을 작성하고 소스코드로 변환하는 작업등을 진행했다
반면에 DDD를 적용하면 별도의 정형화된 모델을 만들지 않고, 간략히 도메인 모델 등을 화이트보드나 포스트잇 등의 단순한 도구로 작성해서 공유한 후 곧바로 소스코드로 도메인 모델을 개발한다
빌드 및 배포
기민한 개발을 위해서는 백엔드와 프런트엔드 개발이 진행되는 과정에서 지속적으로 빌드되고 자동으로 배포되도록 빌드 및 배포 환경을 자동화해야 한다
스크럼 팀원들은 언제라도 현재 진행된 만큼의 실제로 돌아가는 소프트웨어를 확인할 수 있어야 한다
-
소스코드 리포지토리 구성 : 프런트엔드, 백엔드 코드를 위한 소스코드 리포지토리 구성
-
통합 빌드 잡 구성 : 리포지토리에 존재하는 소스코드 통합한 후 컴파일 및 테스트해서 바이너리를 만드는 활동을 자동화
-
컨테이너 생성 파일 작성 : 운영체제와 WAS와 빌드된 애플리케이션을 묶어서 컨테이너 이미지를 생성하는 스크립트를 작성할 수 있다
-
배포 스크립트 작성 : 자동으로 배포하는 스크립트를 작성하는 활
