◆ 마이크로서비스 상세설계
▶ 프런트엔드 모델링
● 웹과 모바일 기술의 발전에 따라 사용자 경험에 민감하게 반응할 수 있는 ui 기술과 개념이 등장했고 이를 잘 지원할 수 있는 다양한 프런트엔드 프레임워크가 등장
● 대표적인 프레임워크로 앵귤러(Angular), 리액트(React -> next), 뷰(Vue.js) 등이 있고 모두 사용자 경험을 잘 지원하는 SPA(Single-Page Application)를 지원
● 이러한 경향은 프런트엔드에서 수행해야 할 일들이 점점 많아지고 중요해졌음을 의미
● 프런트엔드 영역의 모노리스 구조를 분리하기 위한 마이크로 프런트엔드 등의 패턴이 등장하고 있으며 갖가지 유연한 아키텍처 등이 소개되고 있음
● 최소한의 설계 영역
⊙ 프런트 아키텍쳐 정의
⊙ 표준 레이아웃 정의
⊙ UI 레이아웃 설계
⊙ UI 디자인 및 UI 레이아웃 반영
⊙ 이벤트 설계
▶ 백엔드 모델링
● 벡엔드 마이크로서비스를 위한 설계는 헥사고날 아키텍처를 적용해 외부 영역과 내부 영역으로 구분되어 진행
● 이벤트 스토밍 결과를 반영해서 백엔드 마이크로서비스의 내부를 헥사고날 구조로 정의하고 매핑할 수 있으며 이를 기반으로 발전시켜 나갈 수 있는데 이벤트 스토밍의 커맨드는 헥사고날의 인바운드 어댑터의 하나인 REST API가 되고 애그리거트는 헥사고날의 내부 영역인 도메인 모델이 되며 도메인 이벤트는 헥사고날 외부 영역의 아웃바운드 메시지 처리 어댑터의 처리 대상이 되고 외부 시스템은 마찬가지로 아웃바운드 어댑터가 호출해야 할 외부 연계 시스템으로 매핑
● 이벤트 스토밍을 통해 도출한 구매 마이크로서비스를 헥사고날 아키텍처의 구성 요소에 매핑해 보면 커맨드로 식별했던 [주문아이템검색], [주문아이템주문], [상품주문취소]는 클라이언트나 다른 마이크로서비스에서 접근할 수 있는 REST API로 매핑되고 회원 서비스와 상품 서비스는 REST API로 연계하고 정책으로 식별했던 [재고 변경]은 비동기 연계를 위해 메시지 브로커로 매핑되고 애그리거트로 식별했던 [상품]과 [결제]는 도메인 모델에 매핑되어 데이터베이스에서 관리
● 그렇지만 이러한 요소는 백엔드 모델링의 출발점이 될 뿐이며 구현을 위해서는 좀 더 구체적인 설계가 필요하기 때문에 외부 영역 설계는 프런트엔드 와 연계되는 API 설계로 내부 영역은 비즈니스 로직을 구현하는 도메인 모델링, 데이터 모델링으로 구체화되어 진행
● API 설계
⊙ 마이크로서비스 팀은 서비스가 제공하는 기능에 대한 프런트엔드와 백엔드의 구현을 모두 책임지며 프런트엔드, 백엔드 엔지니어가 하나의 팀에서 긴밀하게 협업해야 하는데 이러한 협력을 위해서는 프런트엔드 와 백엔드의 연계를 위한 계약이 필요한데 이것이 API 설계
⊙ API는 백엔드 서비스에 존재하지만 프런트엔드의 요구사항을 충족하도록 정의해야 함
⊙ API 영역은 헥사고날의 외부 영역이며 인바운드 어댑터로써 어떠한 호출 방식도 허용되는 유연한 공간이지만 최근의 추세는 HTTP 프로토콜과 JSON 포맷을 사용하는 REST API가 표준처럼 사용되고 있음
⊙ 이는 REST API 방식이 대중적인 HTTP 프로토콜과 취급하기 쉬운 JSON 포맷, 간단한 HTTP 메서드 형식 등의 특징 덕분에 쉽고 명확 해서 누구나 이해할 수 있기 때문
⊙ 레오나르도 리처드슨(Leonard Richardson)의 REST API 성숙도
→ 레벨 0은 REST Al기의 메커니즘을 전혀 사용하지 않고 전통적인 원격 프로시저 호출(Remote Procedure Call) 방식으로 HTTP 프로토콜만 사용한 것으로 상품 서비스를 예로 들자면 예전에 많이 사용했던 /productService?Flag=create처럼 하나의 URI 주소에 GET 방식의 URI 매개변수인 Flag를 통해 입력 수정, 삭제를 처리하는 방식으로 개발자가 백엔드 내부에서 비즈니스 로직을 통해 어떠한 결정을 하는지 사용자는 API를 보고는 알 수 없기 때문에 API 사용을 위한 명세가 필요
→ 레벨 1은 URI에 개별적인 자원을 표현하는 것으로 여러 기능을 사용하기 위해 하나의 URI에 요청하지 않고 요청이 필요한 대상을 특정하는데 상품 중 사과 정보를 제공하는 URI는 /products/apple로서 사용자는 이처럼 특정 리소스가 어떠한 정보를 제공하는지 인지할 수 있음
→ 레벨 2는 서비스의 기능을 처리하기 위해 약속된 HTTP 메서드들을 사용하는 것으로 레벨 0,1 에서도 HTTP 메서드를 사용했지만 GET, POST로 모든 것을 처리하는 식으로 어떤 방식을 사용할지는 개발자에 따라 다르지만 레벨 2에서는 가능한 한 약속된 HTTP 사용법에 가깝게 사용하는데 조회, 추가, 수정, 삭제 기능을 HTTP 메서드인 GET, POST, PUT, DELETE로 각각 처리해서 API 사용자는 리소스에 어떠한 메서드를 사용했을 때 어떠한 행위가 발생할지 인지할 수 있음
→ 레벨 3은 HATEOAS(Hypertext As The Engine Of Application State)라는 어려워 보이는 약자로 정의되는데 이 방식은 특정 요청을 하게 되면 반환값에 기대했던 결과에 덧붙여 추가로 사용자가 그 다음에 무엇을 할 수 있는지 와 그것을 하기 위해 다룰 수 있는 URI 값을 보내주는데 사용자에게 좀 더 리소스를 탐색해서 활용할 수 있는 가능성을 제공
⊙ API 설계 문서화
→ 애자일 모델링 방식을 추구할 때 가급적이면 불필요한 설계물을 남기는 것은 바람직하지 않음
→ 산출물의 필요성은 항상 공유와 협업 측면에서 고려
→ API 설계는 프런트엔드 엔지니어와 백엔드 엔지니어의 협업 차원에서 중요
→ API 설계는 다른 프런트엔드나 백엔드의 상세 설계에 앞서 진행될 필요도 있기 때문에 다른 설계 요소에 비해 공유가 중요
→ 협업 시스템이 있다면 간단히 위키(wiki) 형태의 문서로 작성할 수도 있음
→ 어떤 형태든 최소한 다음 항목은 포함
∴ 서비스명
∴ API명
∴ 리소스(URI) 요청 매개변수
∴ 요청 샘플 응답 매개변수
∴ 응답 샘플
댓글