[microservice-upLearning] Ⅱ. 마이크로서비스 운영 모델 설계

2021-08-30

MSA

Ⅱ. 마이크로서비스 운영 모델 설계

운영 모델

시스템의 기반이 되는 사람, 프로세스, 도구의 집합
sw 개발의 모든 의사 결정과 작업에 중요한 영향
상황에 따라 매우 큰 범위와 자세한 디테일을 가질 수 있음
책에서는 구축 중 가장 중요한 팀 설계와 협업 방식에 초점

2.1 팀과 사람이 중요한 이유

기술은 중요하나 전부가 아니다
- 좋은 기술을 선택하면 엄청나게 어려운 문제를 더 쉽게 해결할 수 있으며 새로운 기회를 가져다 준다
- 기술만으로는 필요한 가치를 얻을 수 없으며 성공을 보장할 수도 없다
모델의 목표: 좋은 기술을 독립적이고 우수한 팀(high functioning team)에 제공하는 것
MSA에서 문화와 팀 설계가 중요
- Microservice는 빠르게 변경 가능한 자율성 제공
- 변경은 의사 결정의 결과물 → 올바른 결정을 빠르게 내릴 수 없으면 Microservice 가치를 얻기 힘듬
- 엔진의 성능이 매우 형편없는 경주용 자동차와 같음
  
  콘웨이의 법칙 : 조직은 그 조직의 커뮤니케이션 구조를 닮은 시스템 구조를 설계한다
마이크로서비스에ㅔ서 가장 중요한것은 사람

2.1.1 팀 규모

Microservice의 Micro

크기가 중요하며 작은 것이 가장 좋다는 것을 의미 → 지나치게 단순화된 것
팀 규모가 크면 의사소통에 더 많은 시간, 너무 작으면 일손이 부족 → 적절한 규모가 시스템 설계에 중요
다양한 사례
- 던바의 숫자 : 뇌 크기와 침팬지 집단의 크기와 관련
  - 인간은 150명의 안정된 관계만 유지가능, 15명의 신뢰할 수 있는 친구, 5명의 친밀한 가족
- 아마존 제프 베조스의 피자 2판의 법칙
결과적으로 마이크로서비스 모델에서는 팀 규모를 5명에서 8명 정도로 유지한다
팀 규모를 줄이면 내부 상호작용을 제한하는데 도움이 되지만 이 경우 팀이 더 많아진다
최대한 독립적으로 자율적인 작업이 가능해야 한다
작은 규모 팀의 또다른 부작용 : 좋은 결과물을 만들 충분한 인재 확보가 힘들다

2.1.2 팀 역량

기술과 경험의 올바른 조합은? 회사마다도 생각이 다를 수 있음
일반적인 원칙 : 교차 기능 팀의 원칙(cross-functional team)
- 하나의 목표에 다른 유형의 사람들이 함께 일함
- 이미 팀 규모를 8명으로 제한했으므로 적절한 사람으로 구성된 적절한 규모의 팀이 되었다
적절한 사람 : 상황에 따라 다름
- 대규모 클라우드 : 4~5명의 도메인 전문가 + 테스트 전문가
- 컨설팅 회사 : 전문 엔지니어, 제품 소유자, 프로젝트 관리자, 테스팅 전문가 혼합
일반적인 원칙
- 팀은 교차 기능을 수행해야 한다 : 스스로 좋은 결정을 내릴 수 있을 때 더 잘 운영
- 팀이 결과물에 직접적으로 영향을 미치는 사람 : 관찰자, 업무/의사 결정에 관련없는 사람 제외

2.1.3 팀 간 조정

팀 간의 커뮤니테이션은 전체 Microservice 시스템을 지연시킬 수 있음
팀 간 조정 작업 줄이면 더 가치를 올릴 수 있음
팀 간 조정을 완전히 없애는 것은 불가능
- 조직의 성공을 위해 조정과 협업이 중요함
- Microservice는 독립적으로 해동하면서 고객, 사용자, 조직에게 가치를 줄 수 있는 서비스여야함
- 이를 위해 공통의 목표를 설정하고, 변경과 피드백을 전달하고 커뮤니케이션이 반드시 필요함
완전히 팀이 독립적으로 운영되면 공유할 기회가 줄어든다
- 이 경우 효율성이 팀에 국한되므로 각 팀의 서비스는 매우 효율적인 서비스를 구축할 수 있으나
  시스템 수준의 효율성은 떨어질 수 있다
- 예) 모든 팀이 자체 클라우드 기반 네트워크 아키텍처를 설계하고 구축하는 경우
  -> 팀 간에 네트워크 작업을 서로 공유할 수 있는 기회를 잃음
적절한 균형이 필요
- 조정없이 독립성 자율성을 지나치게 강조 : 시스템 수준의 비효율성, 조직의 목표와 불일치 발생
- 너무 많은 조정 : 전체 시스템 정체, 변경에 대한 Microservice의 이점이 사라질 위험
- 계속적으로 균형을 유지하기 위해 실험과 지속적인 조정이 필요

적극적인 설계 노력

가장 흔한 실수 : 기술 아키텍처에만 집중해서 기술 중심으로 팀구성
조정 모델의 문제가 발생해서 변경 사항을 적용하는데 많은 비용이 발생하거나 변경이 어려움

역 콘웨이 전략 - Inverse Conway Maneuver

위의 문제를 방지하고자 나온 전략
시스템 설계 프로세스의 첫 단계로 팀 조정 및 팀 설계 진행
설계한 커뮤니케이션 구조가 시스템 구조에 영향을 미치므로(콘웨이의 법칙)
시스템 설계에 맞는 커뮤니케이션 구조를 향한 팀 설계를 진행

2.2 팀 토폴로지

팀 설계를 문서화하는 방법은 다양
책에서는 팀 토폴로지라는 설계 도구중 3가지 요소를 작성해서 단순한 설계 구축 사용

2.2.1 팀 유형

스트림 정렬(stream-aligned)
- 비지니스 조직과 관련된 것을 지속적으로 전달
- You build it, you run it을 구체화
- 출시 이후에도 해체되지 않고 계속해서 제품을 개선하는 stream을 지속적으로 소유하고 구현
활성화(enabling)
- 활성화 팀은 컨설팅 참여 모델로 다른 팀의 작업을 지원
- 일반적으로 전문 지식이나 역량의 격차를 해소 가능한 전문가로 구성된다
- 각 팀이 조직이나 산업이 큰 그림을 이해하도록 도움을 준다
- ex) 활성화 아키텍처 팀은 MSA팀이 새로운 기술 표준과 규약을 이해하도록 돕는다
난해한 하위 시스템(complicated-subsystem)
- 이해하기 어렵거나 조직내 가용 리소스 부족으로 해결하기 어려운 도메인과 주제에 대해 작업
- 일부 문제 영역은 확장되지 않고 모든 팀에 포함되지 않는다
- ex) 암호화 보안을 위해 sw를 조정하려면 특별한 전문 지식과 경험이 필요
- 모든 팀에서 이러한 기술을 확장하는 것이 아닌 각 팀과 협력할 수 있는 하위 시스템 보안팀을 만듬
플랫폼(platform)
- 활성화 팀처럼 다른 조직을 지원
- 차이점 : 사용자에게 셀프서비스 사용자 경험 제공
- 쉽게 확장될 수 있는 지원 도구와 지원 프로세스를 구축하는데 투자
- 이를 위해 더 많은 사전 투자와 지속적인 유지 관리 및 지원이 필요
- 사용자 : 조직의 나머지 팀
- ex)운영 팀은 개발팀이 사용가능하도록 빌드와 릴리스 도구를 제공할 때 플랫폼 팀이 될 수 있음
해당 팀설계를 실제로 커뮤니케이션하려면 모델의 한 부분이 더 필요

2.2.2 상호작용 모드
조정 비용을 어디에서 얼마나 줄일 수 있는지 이해하기 위해서는? 팀이 서로 조정하는 방식을 명확히 해야함
- 협력 : 두 팀이 긴밀히 협력
  - 장점 : 팀이 배우고 발견하고 혁신할 수 있는 기회 제공
  - 단점 : 각 팀에 높은 수준의 조정 요구, 확장이 어려움
  - ex) 보안팀과 MSA팀이 협력해서 코드설계, 작성, 테스트를 함께 하는 것
- 촉진
  - 협력과 유사하지만 단방향적 상호작용
  - 함께 해결하는 대신 다른 팀이 원하는 결과를 전달할 수 있도록 지원
  - ex) 인프라팀이 네트워크 아키텍처 문제 해결을 위해 MSA팀 지원
- 엑스 애즈 어 서비스
  - 소비자 - 공급자 형태
  - 최소한의 조정 수준으로 다른 팀에 서비스를 제공
  - 일반적으로 공통 프로세스 , 라이브러리, API, 플랫폼 릴리즈시 발생
  - XaaS는 플랫폼 팀에 적합하며 다른팀도 가능하긴 하다
  - ex) 활성화 아키텍처 팀은 추천 디자인 패턴의 리스트를 작성하고 Pattern as a Service로 모든 팀에 제공

2.3 팀 토폴로지 설계

팀이 의사소통하고 함께 일하는 방법을 정의하며 팀 설계
step

시스템 설계 팀 구성
Microservice 팀 템플릿 생성
플랫폼 팀 정의
활성화 팀, 난해한 하위 시스템 팀 생성
주요 소비자 팀 추가

step을 진행하며 팀 설계 문서화, 팀 토폴로지 작성
각 단계마다 하나 이상의 팀을 식별, 설계 문서 작성, 주요 상호작용 도출

2.3.1 시스템 설계 팀 구성

시스템 설계 팀 : 시스템 비전과 행동을 구체화 할 수 있는 사람을 그룹으로 구성해야 한다

팀 구조 설계
- 가장 먼저 구성되는 팀이 시스템 설계팀, 시스템 구축 작업을 수행
표준, 인센티브, ‘가드레일’ 설정
- 시스템 설계 팀은 자신의 팀을 구성하는 것 외에 개별 팀이 내릴 수 있는 결정을 구체화 해야 한다
- 이를 통해 팀은 시스템 목표에 맞는 결과를 얻을 수 있음
- 너무 많은 표준화는 유지가 어려우며, 건강한 시스템에는 너무 제한적
- 각 팀이 할수 있는 것과 할 수 없는 것을 지시하는 기준을 정하는 것이 좋은 표준
- 훌륭한 설계자는 원하는 행동을 더 많이 얻을 수 있는 인센티브와
  완전한 규칙보다는 가벼운 권장사항 내지 참조 역할을 하는 ‘가드레일’을 도입한다
지속적인 시스템 개선
- 시스템 설계팀은 모든 팀의 설계, 표준, 인센티브, 가드레일을 지속적으로 개선해야 한다
- 시스템 전체 모니터링, 측정방법을 수립하고 이를 통해서
  시스템을 변경/개선할 수 있도록 관리해야 한다
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  # 시스템 설계 팀
  
  ## 팀 유형
  활성화
  
  ## 팀 규모
  3~5명
  
  ## 책임
  - 팀 구조 설계
  - 표준과 '가드레일 설정'
  - 지속적 시스템 개선

팀 책임은 문서화

각 팀의 역할을 명확히 전달할 수 있도록 문서화가 유용
시스템이 발전함에 따라 팀을 더 쉽게 이해 및 개선 가능토록 팀의 모든 주요 속성을 문서화 해야한다
최소한 팀 토폴로지 유형, 팀 규모, 팀의 역할, 팀의 책임을 포함해야 한다

시스템 설계 팀의 규모

작은 규모 : 일반적인 팀의 규모보다 작은 팀 규모(3-5)
시스템 전체에 대하여 신속히 결정을 내릴 수있는 소수의 시니어 리더, 아키텍트, 시스템 설계자로 구성

2.3.2 Microservice 팀 템플릿 구축

단일 팀은 여러 Microservice 소유 가능
Microservice 소유권은 단일 팀 소유 : 해당 Microservice의 책임이 다른 팀에 공유되지 않도록
Microservice 팀은 여러 개가 운영되므로 각 팀을 개별적으로 설계하지 않고 템플릿을 정의해서 적용
step : 시스템 설계 팀에서 했던 것 처럼 진행
팀 유형, 규모 , 책임 문서화
- Microservice 팀은 하나 이상의 독립적인 Microservice를 소유할 것으로 예상
- 소유권은 서비스 운영과 지속적으로 개선, 수정, 변경하는 것을 포함
- Microservice팀을 스트림 정렬로 분류 하고 5-8명 규모로 유지
- 템플릿 정의를 문서화하면 팀 상호작용 모델을 다이어 그램을 작성할 수 있음
두 팀 간의 상호 작용
- 시스템 설계 팀은 마이크로서비스 팀을 촉진
- 상호 작용의 세부사항을 모델링하지 않는다 : 상호작용 강조로 충분
- 시스템이 발전함에 따라 실제 팀의 이름과 작업중인 서비스로 갱신해야 한다
- 시간이 흐름에 따라 마이크로서비스 팀간 상호작용을 기록해야 한다
- 팀 설계에 따라 다이어그램을 업데이트 해야한다 - 그리기 도구에 익숙해져야 한다

# Microservice 팀 템플릿

## 팀 유형
스트림 정렬

## 팀 규모
5~8명

## 책임
- Microservice 설계 및 개발
- Microservice 테스트, 구축, 전달
- 문제 해결

2.3.3 플랫폼 팀

# 클라우드 플랫폼 팀

## 팀 유형
플랫폼

## 팀 규모
5~8명

## 책임
- 네트워크 인프라 설계 및 개발
- 어플리케이션 인프라 설계 및 개발
- 새로운 환경을 빌드하기 위한 도구 제공
- 필요에 따라 네트워크 및 어플리케이션 인프라를 업데이트

상호 작용
- 작은 화살표의 의미 : XaaS 구현
책에서는 단일 인스턴스로 플랫폼 팀 구성
실무에서는 관리 가능한 규모로 여러 플랫폼 팀 구성 가능
이 경우 여러 플랫폼 팀이 너머지에 서비스를 제공하기 위해 함께 협력하는 방법 고려 필요

2.3.4 활성화, 난해한 하위 시스템 팀

책의 예제에서는 전문 릴리즈 팀을 구성
- 대부분의 경우 서비스 배포전 추가 테스트 및 인수 검사 단계 존재
- 직접 배포 대신 마이크로서비스 팀은 빌드와 테스트를 마친 컨테이너를 전달
- 컨테이너는 변경된 사항의 테스트, 승인, 배포 작업을 조정하는 릴리즈 팀에 의해 자동 배포
릴리스 팀
- 릴리스, 승인, 배포 프로세스에 대한 전문 지식을 가짐
- 스트림 정렬 팀과 협력하여 해당 작업 수행

release-team.md

# 릴리스 팀

## 팀 유형
난해한 하위 시스템

## 팀 규모
5~8명

## 책임
- 프로덕션 환경에 마이크로서비스를 릴리스
- 릴리스에 대한 승인 조정

상호 작용
- 작은 사각형 형태
- 해당 접근 방식의 트레이드 오프 : 조정 비용
- 규모 면에서 큰 문제 소지
  - 예)여러 마이크로서비스에서 매일 릴리스를 수행 한다면 릴리스팀은?
  - 모든 배포 조정시 어려움
  - 이런 경우 팀 설계 변경 → 배포 책임을 개별 마이크로서비스 팀으로 전환해야 한다
마이크로서비스 모델의 핵심에 있는 최종적인 팀
설계를 마치려면? 마이크로서비스를 사용할 팀 고려해야 한다

2.3.5 소비자 팀

api-team.md

# API 팀

## 팀 유형
스트림 정렬

## 팀 규모
5~8명

## 책임
- 시스템 경계에서 API를 설계, 개발, 관리
- 마이크로서비스를 API로 다른 개발 팀에 노출하는 책임

API 팀은 스트림 정렬 팀 : 비지니스 요구와 소비스 요구를 반영하는 API를 지속적으로 변경해야 하므로
API가 작동하기 위해서는 마이크로서비스 호출해야 → API팀은 마이크로서비스 팀에 의존
상호 작용
현재 정의된 팀은 팀 토폴로지의 팀 유형과 상호작용 모드를 모두 포함
해당 모델은 상당히 독립적이고 자율적인 작업 방식을 가능케 함
모델이 작동하려면 서비스형의 클라우드 플랫폼 구축하는데 약간의 시간과 노력이 필요
기본 팀 토폴로지를 정의하면 운영 모델 구축과 이렇게 연계됨을 확인

그밖에

어디까지 예제로 모델을 깊게 들어간게 아님
예)여러 팀이 제공하는 결과물을 변경하는데 필요한 상호작용을 다이어그램에 작성 안함
모델 설계는 초기 설계 후에도 지속적으로 개선되어야 한다 - Model As Code

devArchitectureMicroservice