마이크로서비스와 애자일 개발 프로세스

<도메인 주도 설계로 시작하는 마이크로서비스 개발> 중 4장. 마이크로서비스와 애자일 개발 프로세스를 읽고 정리한 글입니다

 

마이크로서비스를 구현하기 위한 필요조건

• 팀 구성:
  • 기술별로 팀이 분리되는 것이 아니라(UI팀, 서버개발팀, DB팀) 업무 기능을 중심으로 기술이 다양한 사람들이 하나의 팀(BE개발자, 기획자, 디자이너, FE개발자, 테스터)(Cross-Function Team)이 되어 서비스를 만들어나간다. 

 

• 문화: 
  • 자율적인 업무 기능 중심 팀과 자율적인 개발 문화가 필요.

 

• 관리체계: 
  • Cross-Function Team이 개발과 운영을 책임진다. (You built it. You run it).
  • 각 마이크로서비스를 맡은 Cross-Function Team이 그 서비스에 맞는 최적의 언어와 저장소를 자율적으로 선택한다.
  • 빠르게 서비스를 만드는 것을 최우선 목적으로 효율적인 방법론, 도구, 기술, 언어를 찾아야 한다. (폴리글랏)

 

• 일하는 방식: 
  • 점진, 반복적인 개발 프로세스

 

• 개발 생명주기: 
  • 폭포수 모델이 아닌 점진 반복적인 모델, 제품 중심의 애자일 개발 방식

 

• 개발 환경:
  • 인프라 자동화. 마이크로서비스팀이 단기간에 제품을 빨리 개발하고 피드백을 받기 위해서는 개발 지워 환경의 자동화가 갖추어져있어야 한다.
  • 빌드/배포 파이프라인: 소스코드 빌드 -> 개발 환경 배포 -> 스테이징 환경 배포 -> 운영 환경 배포. 그래서 인프라 구성과 자동화를 마치 소프트웨어처럼 코드로 처리하는 방식인 Infrastructure as Code가 각광 

 

마이크로서비스는 여러 개의 작은 서비스 집합으로 개발하는 접근방법이다. 각 서비스는 개별 프로세스에서 실행되고, HTTP자원 API 같은 가벼운 수단을 사용해서 통신한다. 또한 서비스는 비즈니스 기능 단위로 구성되고, 자동화된 배포 방식을 이용하여 독립적으로 배포된다. 또한 서비스에 대한 중앙 집중적인 고나리는 최소화하고, 각 서비스는 서로 다른 언어와 데이터, 저장 기술을 사용할 수 있다. 
https://martinflowler.com/articles/microservices.html

인간의 생활을 편리하게 만들고, 업무의 혁신을 가져오는 소프트웨어는 혼자서만 개발할 수는 없다. 다양한 사람들의 의견을 받아 나누는 논의 중에 진정 가치 있는 아이디어가 나오고, 협업을 통해 개발하며, 또 다른 사람들의 피드백을 통해 끊임없이 개선해야 하는 창의적인 활동이다. 

 

애자일에는 빨리, 그리고 자주 실패를 경험해 보는 것이 중요하기 때문에 단순한 설계를 통해 우선 최소한의 실제로 동작하는 제품(MVP; Minimum Viable Product)을 만들어 자주 배포하는 것이 중요하다. 또한 이러한 과정을 거치면서 각  개발팀에 맞는 최적의 개발 프로세스를 지속적으로 향상할 수 있다. 

 

그런데 개발 문화가 성숙하지 않은 팀에게 위와 같은 지침만 주고 '하라'고만 한다면 잘 수행되지 못하고 애자일을 오해하기  쉽다. 

 

이렇게 되지 않으려면 핵심 활동에 집중할 수 있는 마이크로서비스 설계 및 개발 방법이 필요하다. 

 

도메인 주도 설계와 마이크로서비스의 관계

도메인 주도 설계란? 

• 전략적 설계 (Stategic design)
  • 도메인 전문가 및 기술팀이 함께 모여 유비쿼터스 언어를 토해 도메인 지식을 공유 및 이해하고, 이를 기준으로 개념과 경계를 식별해 바운디드 컨텍스트로 정의하고 경계의 관계를 컨텍스트맵으로 정의하는 활동이다. 
• 전술적 설계 (Tactical design)
  • 식별된 바운디드 컨텍스트 내의 도메인 개념인 도메인 모델을 구성하는 유용한 모델링 구성요소들을 설명한다. 

마이크로서비스를 도출하고 내부 구조를 설계하는 데 도메인 주도 설계 기법을 활용하는 것이 효과적이다. 왜?

 

 

기민한 설계/개발 프로세스

DDD를 활용한 애자일한 스크럼 기반의 마이크로 서비스 개발 프로세스

 

협업 

Sprint 

• 보통 1~4주간 실행
• backlog라는 일감 목록을 기반으로 각 sprint에 일감이 배분되어 진행
  • 스프린트 1~4주간 진행되는 일에는 아래의 것들이 있다.  
    • FE 설계: UI 설계
    • FE 구현: UI Test
    • BE 설계: 도메인 모델, 데이터 모델, API 설계 
    • BE 구현: API 테스트
    • CI/CD: 빌드 잡, 배포 스크립트
• 매 sprint마다 실제로 동작하는 소프트웨어를 시연하고 피드백을 얻는다. 

Scrum

• 스크럼 팀: 스프린트가 진행되는 팀을 스크럼 팀이라고 한다.
  • 스크럼 팀은 스크럼 마스터와 팀 멤버로 구성되며 Cross-Function Team이 되어 서비스를 만들어나간다.
• 스크럼 미팅: 매일 아침 각자의 자리에 서서 짧게 진행되는 스탠드업 미팅을 통해 각자의 일을 투명하게 공유한다. 
• 스프린트 계획 수립: 시스템의 모든 요구사항은 제품 backlog에 담긴다.
  • 스프린트의 횟수가 정해진명 백로그는 스크럼의 기한을 고려하여 적절히 배분한다. 
  • 속도: 스프린트가 종료되면 백로그 완료 일감을 기준으로 팀의 생산성이 결정된다. 이 속도에 따라 다음 스프린트의 계획이 세워지기 때문에 속도 측정이 중요하다.
  • 우선순위: 속도에 맞춰 스프린트가 적응적(adoptive)으로 진행되다보면 일정 내 완료해야 하는 우선순위가 높은 기능에 집중해야 한다. 그래서 우선순위를 정하는 게 중요하다.  
• 스프린트의 마지막: 스프린트의 마지막은 시연과 회고이다. 
  • 시연: 시연을 통해 백로그가 구현되고 그 요건을 만족하는지 다같이 확인하고 다음 스프린트에 반영할 요건들을 피드백, 확인할 수 있다. 
  • 회고: 팀원 각자 스스로를 되돌아보는 과정. 다음 스프린트에 반영.

 

엔지니어링

• 아키텍쳐 정의와 마이크로서비스 도출
• FE 설계: UI 설계
  • UI 레이아웃을 정의
  • 백엔드의 API를 호출해서 API가 보내준 데이터를 기반으로 UI에 어떻게 표현할 것인가를 정의하는 활동이다. 
• FE 구현: UI Test
• BE 설계: 도메인 모델, 데이터 모델, API 설계 
  • API 설계: 각 백엔드 마이크로서비스가 FE에 제공할 서비스 명세다. FE와 함께 협의 및 조정하며 API 설계를 진행한다. 
  • 도메인 모델링: DDD의 모델링은 코드 자체가 모델의 기본 표현 형식을 그대로 반영해서 코드로 표현된다. 
• BE 구현: API 테스트
• CI/CD: 빌드 잡, 배포 스크립트