[microservice-upLearning] Ⅲ. 마이크로서비스 설계: SEED(S) 프로세스

2021-09-05

MSA

Ⅲ. 마이크로서비스 설계: SEED(S) 프로세스

MSA를 도입해서 시스템 안정을 유지하면서 개발 속도를 높일 수 있다고 앞의 챕터에서 설명

상당히 복잡한 문제를 다루는 조직에게 매우 유용
이는 그냥 우연이 아닌 의식적인 설계의 결과로 발생한다
효과적이고 명시적인 end-to-end 시스템 설계없이는 성공적인 MSA 구축이 불가능하다

SEED

SEED(S) : Seven Essential Evolutions of Design for Services
서비스 설계를 위한 7가지 본질적 진화
헬스케어 스타트업 창립자 중 한명이 공식화, 이후 많은 프로젝트에서 성공적 구현
MSA를 설계하기 위한 점진적인 프로세스, 복잡한 문제를 해결하는 소규모 조직에도 효과적
하향식, 다단계 방법론, 재사용 가능한 프로세스 모음으로 계속적인 진화
아름다운 정원이 씨앗으로 시작하듯 SEED 프로세스는 Microservice 구현의 필수적 첫 단계
나중에 코딩하는 부분을 용이하게 한다

3.1 SEED 소개

마틴 파울러 가 말한 마이크로 아키텍처의 주요 특징 1번 : 서비스를 통한 시스템의 컴포넌트화

서비스 : 웹 서비스 요청, RPC등 표준 네트워크 프로토콜을 통해
독립적으로 배포되고 엑세스 가능한 소프트웨어 구성 요소 의미
시스템 구성요소는 명시적인 공개 인터페이스를 정의하여 서비스를 노출한다
좋은 설계로 인터페이스의 유연성/사용성을 높이면 시스템 아키텍처의 견고성과 개발자의 생산성 향상

SEED 프로세스

반복 가능, 안정적, 신뢰할 수 있는 방법론 제공 → 사용자 친화적, 견고한 서비스 인터페이스 설계를 돕는다
MSA를 넘어 FE를 위한 RESTful API, GraphQL API등 모든 서비스 유형의 설계에 효과적일 수 있음
이런 광범위한 적용 가능성은 놀랄일이 아님

∵ 기술적인 관점에서 마이크로서비스는 API의 일종으로 조정요구를 최소화하는 특정 유형의 경계를 염두에 두고 개발되었다

SEED Process Step

액터 식별
액터가 수행하는 작업 식별
시퀀스 다이어그램을 사용해서 상호작용 패턴 발견
JTBD(Jobs To Be Done)와 상호작용 패턴을 기반으로 높은 수준의 작업 및 쿼리 도축
개방형 표준(OpenAPI or GraphQL스키마)를 사용해 각 액션 및 쿼리를 스펙으러 설명
API 사양에 대한 피드백 받기
마이크로서비스 구현

3.2 액터 식별

필자는 수년동안 ‘API는 제품이다‘라고 강조해왔다
API와 서비스에 대한 제품 지향적 관점 → 비지니스 세계의 풍부한 기술을 재사용 가능케 함
많은 사람이 1930년대에 P&G의 닐 맥엘로이가
신규 브랜드인 Camay비누의 판매를 개선하려는 시도를 제품관리 분야 중 하나로 생각한다
제품관리는 이후 수십년간 크게 발전 → API/서비스 관리 분야에 재사용할 수 있다는 교훈을 얻음
API가 제품이라면 우리는 제품 관리에서 사용한 것과 유사한 기술을 활용하여 API를 설계할 수 있어야 한다

Actor

제품과 같은 API와 서비스 설계시 ‘고객’을 이해해야 한다
서비스는 누구를 위해 설계되었는가?
API와 서비스 관리 분야에서 이러한 페르소나를 ‘고객’이라고 하지 않는다
서비스 소비자와 공급자 사이에 존재하는 금전적 거래의 의미를 제거한
덜 상업적인 용어 → Actor
액터의 목적 : 실제 사용자 데이터가 일반적으로 제한되는 설계 프로세스 단계에서의 모델링 지원
상호 설계 도구로서의 페르소나 개념
- 1998년 Alan Cooper의 The inmates are running the asylum(정신병원에서 뛰쳐나온 디자인)
  에서 처음 소개 되었으며 그 이후로 큰 인기를 얻었다
- 현 시점에서는 이 페르소나는 다른 방법론과 같이 마찬가지로 일부 비판 받기도 한다

액터정의로 모델링 시작하는 이유?

범위와 우선순위를 지정하기 위해서
API 및 서비스 설계 과정의 전형적 실수
- 사용자 요구사항에 대한 명확성 부족
- 지나친 추상화
- 많은 API가 단순히 HTTP를 통해 일부 DB Table을 노출하거나 rpc로 어플리케이션 내부에 직접 엑세스 포인트를 제공
고객의 요구를 해결할 수 있는 솔루션
- “누가 이 API를 사용할 것인가?”
- “고객이 필요한 것은 무엇인가?”
많은 API, 서비스들이 소비자의 목표가 아닌 서비스 공급자의 목표를 위해 설계됨
SEED는 액터를 먼저 식별 → 첫 단계부터 이 문제를 해결한다

목표에 적합한 액터를 식별하기 위한 기본 규칙

사용자 페르소나처럼 각 액터는 정확 하기보다는 구체적 이어야 한다

액터가 누구인지 세부사항 식별하는 것보다 다양한 액터를 구별하는 주요특성의 경계를 식별하는 것이 더 중요
우리는 모델링 과정에 있다는 사실을 항상 기억! → 모델링 과정에서 모든 것이 정확할 수 없음
모든 세부사항에 신경쓰지 말고 현실과 관련된 우선된 것들부터 파악해야 한다

액터는 문맥(context)에 따라 정의되어야 한다

겹치거나 너무 광범위한 액터 정의는 기본적으로 위험
각 어플리케이션 설계에서 재사용되는 액터가 포트폴리오가 생기는 것 : 프로세스가 잘못된 방향임을 의미

모델로써 액터 정의는 각 액터에 내재된 요구사항, 문제점, 행동을 나타낸다
액터 유형을 구분하는 요구사항, 행동은 관련성이 있으며 중복되는 부분이 매우 제한적이어야 한다
문제 영역 설명위해 가능한 적은 수의 액터를 사용해야 한다.
- ex) 서비스에 대해 5명 이상의 액터?
- 대부분의 경우 우선순위가 사라졌거나 서비스 경계가 너무 넓은 것

3.2.1 샘플 프로젝트의 액터 예제

ch1의 샘플인 항공사 예약 시스템에서, 항공편 예약 서브 시스템 관련 액터중 일부

비행기를 자주 타는 승객

엠마는 출장이 잦은 승객
항공사의 엘리트 로열티 등급 보유 → 많은 혜택을 받음
직장 예약 시스템을 통해 여행을 관리
다양한 앱을 사용해서 바쁜 일정 소화
가족과 함께 여행시 보통 로열티 마일리지 사용

가족 휴가객

라일리 부부는 대부분의 휴가를 자녀와 함께 보낸다
보통 미리 계획하여 여행하며, 여행을 자주 하지는 않는다

항공사 고객 서비스 상담원

션은 여행 관련 문제를 해결하거나 예약/재예약을 지원하는 숙련된 고객 서비스 상담원
전화와 온라인 챗을 업무에 사용

3.3 액터가 수행하는 작업 식별

액터(대상 고객) 유형 파악 후에는 액터가 할 일을 파악하는데 많은 시간을 투자하여 고객의 요구사항을 가장 잘 만족시킬 수 있는 솔루션을 만들어야 한다
왜 중요한가? : 종종 무시되거나 오해되는 부분이지만 매우 중요
- 앞서 배운 SEED를 포함한 API/서비스 설계 방법론은 다음과 같은 기본 전제를 기반으로 한다
  - API와 마이크로서비스는 제품 유형이다
  - 설계 과정에서 수십 년 동안 개발된 풍부한 일반적인 제품 관리 도구를 사용가능하다
  - 위의 도구를 모델링 프로세스에 적용 → 상호작용 설계에서 사용자 페르소나 방식으로 액터 식별
- 이제 스텝2에서는 제품 설계에 더 깊이 파고들면 다음의 질문에 직면한다
왜 API를 제품으로 다루는가?

우리는 수요나 요구를 충족시킬 수 있는 관심, 획득, 사용, 소비를 시장에 제공할 수 있는 것을 제품으로 정의한다. 제품에는 자동차, 컴퓨터, 휴대폰과 같은 유형의 물건 이상의 것이 포함되어 있다. 광범위하게 정의된 ‘제품’은 서비스, 이벤트, 사람, 장소, 조직 아이디어 또는 이들의 조합을 포함한다

필립 코틀러Kotler의 마케팅 원리

웹API나 마이크로서비스 등의 서비스는 위의 정의를 만족시키므로 제품으로 볼 수 있다.
그럼 다나은 제품을 만들수 있는 방법은? 액터 식별 다음은?
▶ 제품은 고객의 문제를 해결해야 한다

사람들은 1/4 드릴을 사기를 원하지 않는다.
그들이 원하는 것은 1/4인치 구멍이다

테오도르 레빗하버드 경영대학원 마케팅 교수

즉 드릴을 파는 제품 회사라면 고객이 하려는 진짜 원하는 작업은 단순히 벽에 그림을 거는 것이지 가장 완벽한 범용 드릴을 쇼핑하는 것이 아니라는 것을 인식해야 한다
이를 깨닫지 못하고 완벽한 드릴을 완성하려는 노력을 계속한다면 결국 구멍을 더 간단히 뚫을 수 있는 대안을 생각해내는 발명가에게 뒤쳐지게 될 것이다
▶ 솔루션은 항상 변화하고 진화한다

고객은 그들의 문제를 해결하기 위해 제품을 구매한다.

할일 이론(Theory of jobs to be done)

클레이튼 크리스텐슨「The Innovator's Solution」(하버드 비지니스 리뷰)

고객이 아닌 작업이 분석의 기본 단위일때 제품 설계가 성공적이고 고객이 더 만족한다

클레이튼 크리스텐슨과 공동 저자「What Customers Want from Your Products」(고객이 제품에서 원하는 것)

▶ 작업을 분석 단위로 사용 ▶ 요구사항 수집을 위해 도메인에서 주요 액터가 할 일을 분석 단위로 사용

3.3.1 잡스토리 형식의 JTBD 기록

잡 스토리

Paul Adams가 정의
템플릿 : <상황>일때 나는 <동기>하기를 원하고 <목표>를 할 수 있다
Paul Adams의 잡스토리는 1인칭으로 작성된다
SEED에서는 실제 액터를 강조하기 위해 3인칭으로 잡스토리 작성을 선호한다
스크럼등의 애자일 방법론의 유저 스토리와 유사해 보일 수 있다
차이점 : 알란 클레멘트 - 유저 스토리를 잡 스토리로 바꾸기
유저 스토리는 사용자 페르소나를 중심으로 시작하고 전개 된다
잡 스토리는 페르소나를 무시하고 상황을 강조한다
이는 ‘고객이 아닌 작업을 분석의 기본 단위로 한다’와도 일치한다
- 특정 작업 설명 맥락에서 페르소나는 더 이상 중요하지 않는다
- 벽에 그림을 걸어야 한다면 시공 초보자나 전문가나 상관없이 벽에 구멍이 필요하다
- 이는 행위자가 어떤 사람이냐 보다 중요한 목표를 달성하려는 동기와 상황이 있는 맥락이다
정리해서 간단히 말하면
- 우리는 작업 목록을 정의하기 위해서 행위자를 식별하지만
- 행위자의 작업을 설명하는 관점에서 단순히 상황을 식별하는 것이 필요하다

3.3.2 샘플 프로젝트의 JTBD 예제

가족 휴가를 즐기는 Actor의 JTBD

라일리는 가족 휴가를 위한 항공편을 계획할 때 여러 기준에 따라 항공권을 필터링하길 원한다

기준 : 인접한 4자리, 환승 수 , 아이가 편하게 이용 가능한 시설등
다양한 기준으로 가족이 최대한 편히 여행할 수 있는 항공편을 찾기를 원한다

주말 가족 휴가를 갑자기 계획할 때, 짧은 비행이 가능한 흥미로운 여행지 목록을 추천받기를 원한다

비행기를 자주 타는 Actor의 JTBD

엠마는 계획이 변경되어 이전에 예약한 항공편으로 여행할 수 없게 되었다. 새로운 여행 계획에 맞춰서 간편하게 항공편 일정을 재조정 할 수 있기를 원한다.
엠마는 현재 배정된 좌석보다 다른 좌석이 더 맘에 든다. 그녀는 더 즐겁게 비행하기 위해 좌석을 변경하기를 원한다

고객서비스 상담원 Actor의 JTBD

고객이 션에게 전화를 걸면 그는 고객의 정보가 미리 채워진 서비스 티켓을 열고 고객의 요구사항을 해결하기 위한 진행 상황을 추적하기를 원한다
고객이 션에게 여행에 적합한 항공편을 찾아달라고 부탁할 때 그는 유연한 필터링 기준을 사용하여 고객의 요구사항을 만족시키는 항공편을 찾고 예약할 수 있기를 원한다.

가능하면 항상 사용자 조사부터 잡스토리를 도출하는 것이 좋다
잡스토리의 단순/비기술적 템플릿은 일관된 방식으로 연구를 기록하는데 매우 유용하다
잡스토리는 주제별 전문가와 실제 고객과의 대화를 위한 훌륭한 형식을 제공하지만 기술적인 요구사항을 도출하는 데는 편리하지 않다. 더 개발자 친화적인 형식으로 이를 변환해야 한다

3.4 시퀀스 다이어그램을 사용한 상호작용 패턴 발견

잡스토리는 일반적으로 비지니스 가치 관점에서 제품 관리자가 작성한다
따라서 직접적으로 대상 서비스와 거의 일치하지 않는다
좋은 서비스를 설계하기 위해서는 서비스가 속한 하위 도메인의 서비스 상호작용 패턴을 이해해야 한다
복잡한 상호작용의 경우 잡 스토리 리스트는 설계작업을 충분히 지원할 수 없다
대신 모댈 내에서 이벤트 순서를 설명하는 상호작용 다이어그램을 그릴 수 있다
마이크로서비스 모델링은 팀 활동이므로 다이어그램 활용시 다양한 이점
SEED 권장 : UML 시퀀스 다이어그램 권장
PlantUML - 마크다운 기반 다이어그램 형식
텍스트 기반 형식의 장점
- 각자 익숙한 편집기 사용해서 모델링 가능
- 다이어 그램 소스의 버전을 쉽고 효율적으로 관리가 가능하며 비교, 병합, 검토가 가능하다
- 모델링을 릴리스 프로세스에 쉽게 통합 가능하다
현시점에서의 상호작용 다이어그램의 역할
- 현시점에서 우리는 현실에서 수집한 요구사항에 맞춰 기술 모델을 만드는 단계에 있다
- 여기서 잡 스토리, 액터는 실제 고객의 요구사항을 나타내며 일반적으로 기술적 상호작용과 1:1로 매핑되지 않는다
- 따라서 상호작용 모델에서 이벤트는 행위자간 반드시 발생하지 않아도 되며 작업에 직접적으로 대응하지 않아도 된다
- 오히려 상호작용 다이어그램은 한 단계 더 깊이 들어가 사용자 중심 요구사항이 기술 수준의 서비스 간 상호작용으로 어떻게 전환되는지 보여줄 수 있다
앞서 소개한 샘플 프로젝트의 JTBD와 관련된 상호작용을 설명하는 간단한 다이어그램

마침 hexo blog 플러그인이 있어서 설치 했다
hexo-plantuml은 2021년 플러그인인데도 에러가 나서
hexo-tag-plantuml 플러그인을 설치했다

샘플 프로젝트의 JTBD와 관련된 상호작용을 설명하는 간단한 다이어그램

{% plantuml %}

title 샘플 프로젝트의 JTBD와 관련된 상호작용

actor 에이전트
participant "에이전트 서비스" as AS
participant "예약 API" as rAPI
participant "예약 CRUD" as rCRUD

AS -> rAPI: checkRes(reservationId)
rAPI -> rCRUD: reserve(data)
rAPI -> rCRUD: cancel(reservationId)

{% endplantuml %}

플러그인의 결과는 다음과 같다

상호작용 시퀀스 다이어그램 작성 후엔?

표준 구문을 사용하여 설명된 액션과 쿼리형식으로 마이크로서비스나 API에 대한 기술 요구사항을 작성할 수 있다

3.5 JTBD에서 액션 및 쿼리 도출

잡스토리는 주제별 전문가와 원할한 대화를 나누고 고객의 요구사항에 대한 통찰력을 얻을 수 있는 훌륭한 형식을 제공한다
하지만 API 스펙을 실제로 설계를 하기 위해서는 서비스 상호작용 패턴을 이해하고 시각화해야 한다
작업을 더 기술 지향적인 인터페이스 계약으로 전환하여 설계 프로세스를 단순화 할 수 있다
Bertrand Meyer의 CQS 패턴에 따르면 시스템 계약은 액션(CQS의 command)과 쿼리의 집합으로 모델링
CQS 패턴
- Bertrand Meyer가 제안
- 레퍼런스 : OOSC(Object-Oriented Software Construction)
- Goal : 커맨드와 쿼리를 분리하는 것
  - Command : 결과를 반환하지 않는다. 시스템의 상태를 변경한다(사이드 이펙트)
  - query : 결과를 반환한다. 시스템의 관찰 가능한 상태를 변경하지 않는다
- 데이터 변경 관련 이슈가 발생하면 변경이 일어나는 커맨드 메서드만 찾아보면 된다
- 변경 메서드도 변경만 집중하면 되기 때문에 유지보수가 좋아진다
- JPA에서 insert는 id만 반환, update는 반환없고, 조회는 변경없는 메서드 설계
SEED의 쿼리와 액션
- 쿼리 : 입력과 출력이 정의된 조회 작업
  - 쿼리는 클라이언트/서버 사이에서 입력과 예상 응답이 명확하게 공식화된 계약이어야 한다
  - 시스템 상태를 수정하지 않는 면에서 액션과 확연히 다르다
- 액션 : 상태 수정을 유발하는 요청
  - 액션은 사이드 이펙트가 있을 뿐만 아니라 사이드 이펙트(변화)를 일으키는 것이 목적
  - 쿼리와 마찬가지로 입력, 예상된 결과, 응답에 대해 잘 정의된 계약이 있다

쿼리 템플릿 : 잡스토리와 마찬가지로 쿼리/액션을 기록하기 위해 표준 형식을 사용한다

쿼리
- 쿼리에 대한 설명
  - 입력 : 입력 변수 목록
  - 응답 : 출력 데이터 요소 목록

액션
- 액션에 대한 설명
  - 입력 : 입력 변수 목록
  - 예상 결과 : 유발된 사이드 이펙트에 대한 설명
  - 응답 : 응답 데이터 요소 목록

잡스토리는 하나가 아닌 여러 쿼리와 여러 액션으로 변환될 수도 있다
쿼리와 액션의 결과는 여러개의 잡 스토리의 소스로도 결합될 수 있다
SEED는 모델링/설계/발견의 프로세스이며 인간의 판단요소를 자동으로 제거하는 만능 프로세스가 아니다

3.5.1 샘플 프로젝트에 대한 액션 및 쿼리 예제

기존의 잡 스토리를 여러 액션과 쿼리로 전환한 예제

쿼리

잡스토리 1

인접 좌석 수, 최대 환승 수 등과 같은 세부 선호 사항을 표시하여 가족의 여행에 적합한 항공편을 찾는 가족 휴가 여행객
이러한 작업의 요구사항을 충족시키기 위해서는 검색 쿼리에 대해 선호도를 입력할 수 있는 쿼리 계약이 필요하다

쿼리 정의

1
2
3

# 쿼리 1: 항공편 검색
- 입력 : departure_date, return_date, origin_airport, baby_friendly_connections....
- 응답 : 조건을 만족하는 항공편 목록

잡스토리 2

여행 계획이 갑자기 변경되어 예약된 항공편으로 여행할 수 없는 상황
행위자는 기존의 예약을 변경해야한다
이를 위해 최소한 다음 사항이 필요
- 기존 예약의 고유한 식별자가 필요
  - 식별자를 활용해 출발지/목적지/선호도 파악
  - 이를 이용해 여행자가 다시 정보를 입력하지 않고 자동으로 새로운 검색 정보 설정
- 새로운 출발일자/귀국일자
검색 실행후 새로운 일자와 일치하는 리스트를 고객에 제시 → 고객은 원하는 조건에 맞는 새 항공편 예약

'재예약' 쿼리

1
2
3

#  쿼리2: 일자 변경을 위한 대체 항공편 조회
- 입력 : reservation_id, new_departure_date, new_return_Date
- 응답 : 대체 항공편 목록

액션

쿼리 도출과 유사한 분석을 사용해서 액션 생성 가능

여행 재예약

# 여행 재예약
- 입력: original_reservation_id, new_flight_id, seat_ids[]
- 예상 결과 : 새 항공편 예약 또는 오류 반환. 새 항공편 예약 성공시 이전 항공편 취소
- 응답 : 성공코드 또는 자세한 오류 객체

좌석 변경

# 좌석 변경
- 입력 : reservation_id, customer_id, requested_seat_ids[]
- 예상 결과: 좌석이 사용 가능하고 여행자가 자격이 있는 경우 새로운 좌석이 예약된다. 새 좌석 예약을 성공하면 이전 좌석은 취소된다
- 응답: 성공코드 또는 자세한 오류 객체

Microservice Design Canvas

SEED 프로세스의 ‘액션 및 쿼리 분석’을 대체할 수 있는 방법
요구사항이 복잡한 경우, 인터페이스 계약을 정의하는 액션 및 쿼리 접근 방식이 충분하지 않을 수 있음
더 복잡한 요구사항을 도출하기 위한 방법으로 Microservice Design Canvas 사용 가능
Matt McLarty 제안
책에서 살펴볼 가치가 있는 강력한 도구라고 일컽고 있음

일련의 액션 및 쿼리 또는 Microservice Design Canvas가 준비되었다면 이를 인터페이스 스펙으로 변환할 수 있다

3.6 개방형 표준을 사용하여 각 액션 및 쿼리를 스펙으로 설명

API나 마이크로 서비스를 코드로 작성하기 전에 인터페이스 계약을 공식적으로 설명하는 것이 중요
서비스 생산자와 소비자, API 클라이언트 개발자간 이해를 돕는다
OpenAPI Spec과 GraphQL과 같은 개방형 표준을 사용하여 구현된 계약은 다양한 도구를 사용하여 문서를 쉽게 렌더링하고 개발자 포털을 간편히 생성할 수 있다
OAS - OpenAPI Specification를 사용하여 이전 단계에서 설명한 액션에 대한 RESTful 엔드포인트를 설계한다

마이크로서비스간 통신 방식

꼭 RESTful API일 필요는 없음
인기 있는 대안
- GraphQL
- gRPC
- 비동기 이벤트 통신
- 최근 인기 있는 방식
  - Kafka 스트림에서 JSON-, ProtoBuf-, Avro-encoded메시지 사용
어떤 통신 방식을 선택하든 상관없음
메시지를 서로 교환하며 메시지 형식은 문서화된 ‘계약’의 일부여야 한다
각 방식은 특정 스타일에 적합한 방식으로 SEED 방법론 적용 가능하다
OAS
리눅스 재단 협동 프로젝트인 OpenAPI Initiative에서 관리
기술 스택에 구애받지 않는 표준 방식으로 RESTful API 설명
최신 버전 : https://spec.openapis.org/oas/latest.html
추천 방식 : vscode의 openapi-designer 플러그인

내가 해본 시점에서는 openapi-designer 플러그인은 잘 되지 않는다
대안으로 OpenAPI Preview를 사용했다

openapi: 3.0.0
info:
  title: Airline
  description: |
    API for Airline
  version: 1.0.1
servers:
  - url:  http://api.example.com/v1
    description: 운영서버
paths:
  /reservations/{reservation_id}:

    put:
      # see https://swagger.io/docs/specification/describing-parameters
      summary: Book or re-book a reservation, 예약/재예약
      description : |
        request sample: PUT http://api.example.com/v1/reservations/d2783fc5-0fee
      parameters:
        - name: reservation_id
          in: path
          required: true
          description: 생성되거나 업데이트된 예약의 유니크 식별자
          schema:
            type: string
            example: d2783fc5-0fee

      requestBody:
        content:
          application/json:
            schema:
              properties:
                outbound:
                  type: object
                  properties:
                    flight_num:
                      type: string
                      example: "AA 253"
                    flight_date:
                      type: string
                      example: "2021-08-31T08:01:00"
                    seats:
                      type: array
                      items:
                        type: string
                      
                returning:
                  type: object
                  properties:
                    flight_num:
                      type: string
                      example: "AA 254"
                    flight_date:
                      type: string
                      example: "2021-09-02T15:31:00"
                    seats:
                      type: array
                      items:
                        type: string
      responses:
        '200': # 응답 성공
          description: 예약 성공
          content:
           application/json:
             schema:
               type: object
               properties:
                 reservation_id:
                   type: string
                   description: 신규 예약 식별자
        '403':
          description: setat unavilable. 예약 실패
          content:
            application/json:
              schema:
                type: string
                description: 상세한 애러 객체 정보

API 계약 작성 완료
마이크로서비스와 API 설계에 중요한 단계 중 하나가 완료되었다
사전 준비가 완료되었다고 생각할 수 있지만 추가적인 활동이 더 존재함
SEED 프로세스의 다음 프로세스에서 이러한 활동 수행

3.7 API 사양에 대한 피드백

서비스 설계에 대한 피드백 수집

API와 서비스를 사용할 클라언트 개발자에게 엔드 포인트의 초안 설계를 보여주고 피드백을 수집하는 단계
이전의 단계는 ‘적극적인 브레인 스토밍’이라고 한다면, 이 단계는 주의 깊게 듣고 반영하는 단계
클라이언트가 진정으로 원하는 API/마이크로서비스 설계를 위해 매우 중요함
피드백은 초기설계에 수집하여 적용한다
서비스 설계는 서비스 대상에게 제공될때까지 계속 발전한다

2 타입의 고객 그룹 고려

시스템의 최종사용자 : API는 UX를 가능케 한다
→ 올바른 서비스를 구축하게 함
API/마이크로서비스에 대해 코딩할 클라이언트 개발자 : web/Mobile등의 최종 UX 구현
→ 서비스를 올바른 방식으로 구축하게 함

각 그룹과 SEED step의 연관

SEED 프로세스 시작 단계에서 최종 사용자를 인터뷰하여 관련 잡스토리를 수집하고 이해하며
프로세스 후반에는 클라이언트 개발자로부터 피드백을 받는다
- 상호작용 설계 단계 초기에 발생할 수 있으며 OAS생성되면 코딩전 다시 발생할 수 있다
2번째 그룹 인터뷰는 낮은 사용성 때문에 클라이언트 개발자가 기피하는 서비스를 작성하지 않기 위해 진행

3.8 마이크로서비스 구현

SEED의 마지막 단계
코딩: sw엔지니어링 팀에서 수행활동중 가장 높은 비용 → 마지막 단계에서 진행
초기에 잘못된 가정을 기잔으로 한 설계한 기능을 재코딩하는 것은 시간과 비용이 많이 든다
SEED등과 같이 신중히 고려된 프로세스 수행하는 이유 → 전반적으로 시간을 절약, 더 나은 결과 제공

3.9 마이크로서비스 vs api

SEED 방범론은 마이크로서비스/api 둘다 성공적으로 적용 가능 → 유사점이 같다는 사실

마이크로서비스 vs api

마이크로서비스는 표준 네트워크 프로토콜(일반적으로 HTTP)을 통해 기능을 제공
이러한 HTTP 엔드 포인트로 제공되는 기능은 ‘마이크로서비스’ 용어가 있기 전부터 웹API로 널리 알려졌다

잘못된 접근 : 소규모의 집중형 API를 마이크로서비스라고 여기는 것

이러한 접근에서는 마이크로서비스는 이전의 API와 동일한 역할 → 실제로 이전의 API 대체
마이크로서비스를 위한 이상적인 접근 방식이 아님
마이크로서비스를 레거시 API와 구분하는 접근 방식이 필요

마이크로서비스는 단순히 소형 API가 아니다

마이크로서비스는 단순히 예전의 API를 대체하는 것이 아니다

마이크로서비스는 시스템 구현을 제공하는 반면에 API는 시스템의 외부 인터페이스여야 한다

마이크로서비스가 대체한 것 : 시스템을 구축하는데 사용한 모듈식 구성 요소

이전 방식 : 다양한 하위 모듈을 (정적or동적으로)서로 연결해서 대규모 시스템 구축
msa의 빌딩 블록 : 마이크로서비스라고 하는 네트워크 서비스

왼쪽 접근 방식 - BFF패턴(Backend for Frontend pattern)

Phil Calcado가 SoundCloud 근무할 당시 BFF 패턴으로 소개(2015)
2가지로 구분
- 내부에서 사용하는 것
- FE같은 외부에서 사용하기 위해 최적화 한 것

우측 접근 방식

Daniel Jacobson이 Netflix 근무할 당시 소개 - ephemeral API
넷플릭스 API를 Experience(FE)와 Ephemeral(BE)로 분리하는 방법

웹 API는 마이크로서비스 위에 계층화

하위시스템의 공개 인터페이스를 나타내는 웹 API와 시스템 구현을 나타내는 마이크로서비스를 구분한다

마이크로서비스는 ‘작은 API’가 아니다

정답은 없음

마이크로서비스를 구성하고 FE API로 연결하는 방법에 정답은 없음
이상적인 분리
- 모든 비지니스 로직(기능)이 마이크로서비스에서 구현
- API는 마이크로서비스 앞단의 오케스트레이션 레이어 역할
- 팀에서는 마이크로서비스가 서로를 직접 ‘호출’하는 것을 지양해야 한다
- 느슨한 결합을 위해 마이크로서비스가 서로 모르는 상태로 윗단의 API 레이어에서 워크 플로우 구성이 이상적

마이크로 서비스와 유닉스 철학은 유사하다

마이크로서비스 : 서로에 대해 알지 못하고 외부에서 조정되어야 한다
유닉스 : 복합적인 도구 모음으로 시스템을 구축
- 셸 스크립트나 명령 줄에서 입출력 파이프라인을 통해 다양한 방법의 유닉스 도구 결합 가능
- 이를 위해서 다양한 유닉스 도구가 모든 입력과 출력에 대해 동일한 방식으로 작동하는 것이 중요
- 누가 ‘호출’하거나 어디로 출력되는지 신경 쓰지 않아도 된다
- 구성 요소는 명시적으로 서로에 대해 알 수 없다
마이크로서비스는 서로를 인식하지 않아야 한다
- 서로에 대해 직접 ‘알고’ 동기 인터페이스를 통해 직접 호출하지 않아야 한다
- API계층에서 여러 마이크로서비스를 오케스트레이션 한다
  불가능하다면, 마이크로서비스 간의 비동기 인터페이스 사용을 고려한다
- 비동기 인터페이스
  - 업스트림 마이크로서비스는 이벤트 로그(kafka등)에 데이터를 발행
  - 다운스트림 마이크로서비스는 이벤트 로그를 구독
  - 업스트림 마이크로 서비스는 구독자와 긴밀한 결합을 갖지 않게 된다

devArchitectureMicroservice