어플리케이션 아키텍처에는 크게 3가지 종류가 있다.
monolithic 앱은 모든 데이터에 대한 단일 데이터베이스를 사용해 단일 코드베이스로 모든 기능 구현하는 것이다.
반면 SOA는 monolithic architecture를 UI/DB/비즈니스 등 3티어 식의 가로로 나누는 것이고, 마이크로서비스는 수직적으로 자르는 것이다.
이 중 마이크로서비스 아키텍처가 다양한 장점으로 각광받고 있다.
마이크로서비스 아키텍처(MSA)란:
- 어플리케이션을 개발하기 위한 아키텍처 스타일 중 하나
- 거대 아키텍처를 가진 앱을 독립적인 단위로 쪼개 서로 느슨하게 연결함
- MSA는 탈중앙화와 관련이 있음, 전체 업무를 서비스로 그룹핑
- 신규 업무가 생기면 기존 업무들을 종합해서 대응(레고블럭과 비슷)
- 컴포넌트는 레고 블럭처럼 클래스 만들고 업무 발생하면 컴포넌트 조립해서 품질높은 서비스를 냄
- 다만 MSA는 새 업무에 대한 표준을 잡으려면 여러 비표준을 협의해서 정리해야하기 때문에 가변성이 큰 업무에는 표준 잡을 시간이 없다는 것이 약점
- 그래서 마이크로 서비스는 서비스를 작게 만들고 도메인(업무 바운더리)에서 표준을 잡되, 다른 도메인과는 디커플링 돼서 서비스가 구성
SOA에서는 용어가 다 표준화돼 있지만, MSA에서는 도메인 별로 분리돼 있음. 중앙에서 통제하려고 하면 결재 받는 등 시간이 너무 많이 걸리기 때문에 환경변화에 밀접하게 대응하라는 의미.
마이크로서비스는 공통서비스(웹 ui, 모바일 ui , 인증 ) 등은 별도 취급하고 여러 코드베이스가 있으며 각 서비스는 자체 데이터 관리한다.
마이크로 서비스 단위란? 독립적으로 배포가 돼야 한다. 그래야 민첩성이 확보된다. 각 서비스 유지 팀이 5명 정도 돼서 책임지기 때문에 각자 db를 갖게하는 것이 특징이다.
MSA 장단점?
장점
✔︎ 독립적으로 빠른 속도가 장점
✔︎ 서비스마다 다른 언어와 프레임 워크 사용 가능
⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻⎻
단점
✔︎ 복잡도가 증가하고, 서비스 시간이 지연
✔︎ 서비스 간 트래픽 보안 우려(그래서 복잡도에 대한 솔루션 사용)
최근엔 서비스 하나에 컨테이너 하나 이상 해서 배포한다고 한다. 그러나 컨테이너가 많아지면 컨테이너 관리도 문제가 된다. 결국 어플리케이션 설계의 핵심은 서비스 경계를 정의하는 것이다.
이중화
이중화란 한 쪽이 망가지면 바로 다른 쪽이 액티브한 상태가 되는 것이다. 비용 두배로 든다는 단점이 있지만, 서비스 장애를 염두에 둔다면 이중화는 기본이다.
클라우드의 경우 안정적인 이중화를 위해 Zone이라고 불리는 데이터 센터와 legion이라고 불리는 데이터 센터 2~3개로 구성돼 있다.
Hadoop의 경우 빅데이터 솔루션으로 하나를 복사하면 2~3개 카피본이 만들어진다. 지역별로 3개 데이터센터가 하나의 리전을 구성한다. 이를 3카피 방식이라고 한다.
SLI/SLA/SLO
SLI : 서비스 레벨 인디케이터라는 뜻으로 목표를 이루기 위해 측정하는 지표다.
SLO : 서비스의 목표를 말한다.
SLA : 실제 비즈니스 상 계약을 말한다.
스테이트풀 서비스 vs 스테이트리스 서비스
스테이트풀은 확장이 쉽지가 않음. 반면 스테이트리스는 확장이 쉬움. db로 관리
12 Factor App
소프트웨어를 서비스 형태로 제공하는 것을 웹앱 또는 SaaS(Software As A Service)라고 부르는데, 이를 개발하기 위한 방법론이 Twelve-Factor app이다. 다음과 같은 특징을 갖는다.
설정 자동화를 위한 절차(declarative) 를 체계화 하여 새로운 개발자가 프로젝트에 참여하는데 드는 시간과 비용을 최소화한다.
OS에 따라 달라지는 부분을 명확히하고, 실행 환경 사이의 이식성을 극대화 한다.
최근 등장한 클라우드 플랫폼 배포에 적합하고, 서버와 시스템의 관리가 필요없게 된다.
개발 환경과 운영 환경의 차이를 최소화하고 민첩성을 극대화하기 위해 지속적인 배포가 가능하다.
툴, 아키텍처, 개발 방식을 크게 바꾸지 않고 확장(scale up) 할 수 있다.
MSA 전체 구조
마이크로 서비스 예시
마이크로 서비스는 느슨하게 연결돼야 좋은 아키텍처다.
특히 REST기반의 아키텍처는 느슨한 연결의 아키텍처이며, HTTP를 기반으로 통신한다.
● REST stands for Representational State Transfer
● Protocol independent
● HTTP is most common
● Others possible like gRPC
● Service endpoints supporting REST are called RESTful
● Client and Server communicate with Request – Response processing
참고자료
:Google Reliable Google Cloud Infrastructure: Design and Process