마이크로서비스 아키텍처 구축 가이드 by 김용욱

 

[ 밑줄/연결 ]

 

마이크서비스 아키텍처는 Agile, DevOps, 테스트 자동화(Test Automation), 지속적인 통합(Continuous Integration), 지속적인 전달( Continuous Delivery)  같은 다양한 주제를 배경으로 하고 있다는 점을 명심하기 바란다.

 

(마이크로서비스 아키텍처의 장점)

 

(1) 시스템을 빠르게 변경할 수 있다.

각 서비스를 담당하는 티이 독립적으로 기획, 개발, 배포하여 다른 팀과 협업하거나 일정을 조율할 필요 없이 빠른 시스템 변경이 가능

 

(2) 독립적인 배포가 가능하다.

진정한 장점

 

(3) 업무 단위로 장애를 차단하고 확장할 수 있다.

업무 단위로 장애 차단 또는 시스템을 확장할 필요가 있는 시스템에 적합

 

(마이크로서비스 아키텍처의 장점을 살리는 특징)

 

(1) 각 서비스는 비즈니스 기능 단위로 나누어야 한다.다른 서비스가 임의로 코드를 참조할 수 없도록 소스 코드를 분리하고 정해진 인터페이스로만 접근하게 한다.

 

(2) 서비스는 독립적으로 실행하고 API로 통신한다.

REST API나 이벤트로 통신한다.

 

(3) 각 서비스는 독립적으로 개발하고 배포해야 한다.

독립적인 빌드 배포 파이프라인을 가지고 있어야 한다.

팀이 독립적으로 나아가는 데 필요한 모든 권한을 위임하고 배포할 때.....

DB를 분리하여 서로 Join하지 못하게 차단하는 것은 마이크로서비스 아키텍처를 제대로 적용했는가를 판단하는 데에 중효한 조건이 된다.

 

현재는 모놀로식 아키텍처든 마이크로서비스 아키텍처든 서버 단은 REST API를 제공하고 UI단은 SPA(Single-Page Application)로 개발하는 것이 사실상 표준이 되었다.

 

 

개발 난이도가 높아지거나 신규 개발이 필요한 부분....

여러 서비스에 걸쳐 구현되는 기능은 API나 이벤트 같은 네트워크 통신이 필요하므로 구현 난이도가 증가한다.

 

모놀리식 아키텍처로 기능을 구현하는 비용에 다른 서비스와 연계하는 코드의 개발 난도를 반영하는 것으로 마이크로 아키텍처의 개발 비용을 선정할 수 있다.

 

현장에서 마이크로 아키텍처를 적응할 때 가장 어려워하는 것 중 하나가 서비스별로 데이터베이스를 분리한다는 점이다.

직접 참조하지 못하고 제한된 API나 이벤트만 참조하게 하는 것으로 충족될 수 있다.....

서비스가 다른 서비스의 내부에 임의로 엑세스할 수 없어야 한다는 점이다.

 

마이크로서비스 아키텍처라고 할 수 있는 조건은 서비스가 업무 단위로 구성되고, 각 서비스는 코드부터 DB까지 분리되어야 하며, 운영계에 독립적으로 배포할 수 있어야 한다.

 

-------------------------------

각 서비스는 API통해 자신이 담당하는 데이터를 제공할 뿐이다. 따라서 서비스 간의 통신은 생각보다 적은 경우가 많다.

---------------------------

-

화면에서 데이터를 같이 표시하는 로직(1)과 서비스에 데이터를 호출하는 로직(2)은 SPA가 담당한다.

비즈니스 로직 간의 메소드를 호출(3)하던 것은 서비스 간의 REST API 호출로 구현해야 한다.

 

--------------------------

참조 관계는 크게 업무 내부의 참조(a), 업무 간의 참조(b), 업무 로직이 공통 데이터나 유틸리티 코드를 참조(c)하는 것으로 구분된다.

 

서로 다른 서비스에 배치된다면 서비스 간의 API나 이벤트 통신으로 구현한다.

(c)경우 유틸리티성 코드는 각 서비스가 복제하여 갖고, 그 외의 공통 기능이나 데이터는 공통 서비스에 배치하여 각 업무 서비스가 API로 참조하거나 복제하여 사용한다.

 

-------------------------------

시스템과 업무를 잘 알고 있는 사람들이 모여 1~ 2주 이내의 짧은 기간에 진행한다.

 

-----------------------------

소스 코드를 분리하고 서비스 간의 인터페이스 접근을 차단하여 API나 이벤트로만 인터페이스 하게 한다.

아키텍처 관점을 기준으로 한 목표 수립의 예시..

ㅇ 서비스별 소스 코드와 빌드 배포 파이프라인을 분리한다.

ㅇ 서비스는 정해진 API나 이벤트로만 통신할 수 있다.

ㅇ 서비스는 다른 서비스의 데이터베이스에 접근할 수 없다.(조인 불가)

 

-------------------

 

예를 들어 시스템의 전체 담당자가 50명이고 적절한 팀원의 수를 6명에서 12명으로 정의한다면, 서비스의 최대 개수는 9개에서 최소 5개가 된다.

 

-------------------------

 

서비스 내부의 참조는 하나의 프로세스로 동작하므로 속도가 빠르고, 같은 데이터베이스를 사용하기 때문에 ACID 트랜잭션이 보장된다. 반대로 서비스 간의 참조는 네트워크 통신을 사용하고 AICD 트랜잭션 보장이 안 되므로 난도가 상승한다.

 

민감한 트랜잭션이 많은 시스템은 서비스로 분리하는 것이 부담될 수 있다. 금융 거래처럼 중요한 트랜잭션이 서비스 간의 네트워크 통신으로 처리되는 경우 부담될 수 있다. 이런 경우 중요한 트랜잭션이 한 서비스 안에서 처리될 수 있도록 서비스의 수를 조금 줄이는 것도 좋은 선택이 될 수 있다.

 

SPA는 하나의 웹 페이지에서 자바스크립트가 모든 화면을 동적으로 작성하는 웹 애플리케이션을 말한다.

하나의 페이지가 모든 화면의 코드를 로딩한 후에 브라우저에서 동적으로 화면을 작성한다.  따라서 화면을 전환할 때 데스크톱 애플리케이션이나 모바일 애플리케이션처럼 자연스럽게 느껴진다.

대표적인 SPA 프레임워크로는 Angular, React, Vjue가 있다.

 

 

MVC 아키텍처 시스템은 각 레이어에 걸쳐 API 관련 기능을 추가로 개발해야 한다.

JSP와 같은 MVC 아키텍처는 사용자가 페이지를 전환할 때마다 매번 서버에서 새로운 페이지를 로딩한다...

브라우저는 애플리케이션 상태를 저장하기 어려우므로 브라우저에서 쿠키로 저장하거나 서버의 세션에 저장한다..

 

SPA 구조의 프런트엔드는 항상 로딩되어 있어 마치 네이티브 애플리케이션처럼 상태 정보를 들고 있을 수 있다.

그리고 브라어주의 로컬 스토리지를 활용하면 페이지를 벗어나거나 브라우저가 종료되더라도 데이터를 보존할 수 있다.

 

-----------------------

 

클라우드 네이티브 애플리케이션 =  REST API + 마이크로서비스 아키텍처 + 지속적인 전달을 적용하는 것을 포함

 

클라우드 인프라는 스케일 아웃이 용이하지만 스케일 업에는 한계가 있다. 따라서 애플리케이션은 스케일 아웃이 용이하도록 무상태로 개발해야 한다. 무상태는 애플리케이션 인스턴스가 애플리케이션이나 사용자의 상태값을 가지고 있지 않다는 의미이다.

 

서비스가 자유롭게 스케일 인/아웃할 수 있으려면 먼저 서비스가 무상태여야 한다.

 

서비스가 사용자의 요청을 처리하는 데에 꼭 필요한 정보를 독점적으로 가지지 않는 것을 무상태 구조라고 한다.

가장 대표적인 상태 정보 중 하나는 사용자의 로그인 상태 정보이다. 따라서 기본적으로 서비스를 무상태로 만드려면 로그인 상태 정보를 서비스 외부에 배치하면 된다.

 

AICD

일관성과 지속성은 데이터 저장소의 기본 특성이기도 하다. 네트워크를 통한 통신이라고 해서 특별히 달라질 것은 없다.

따라서 서비스 간의 트랜잭션에서 유의해야 하는 것은 원자성과 독립성이다.

 

 

[ 자평 ] 한국 개발자가 제대로 경험하고 이해하고 쉽게 쓴 책.....

 

ㅇ