Microservice Architecture란?

Microservice

위 사진은 아마존과 넷플리스의 마이크로 서비스에 대한 구성도이다.
두 회사는 클라우드 서비스를 가장 잘 사용하고 있고, 활발히 서비스하고 있으며, 외부로 공개하고 있는 회사로 알려져 있다.

아마존의 마이크로 서비스 구성도를 보면,
회색의 점들은 마이크로 서비스들의 단위라고 보면 되고, 검은색으로 각각의 서비스들이 다른 서비스들과 복잡하게 연결되어있는 형태로,
하나의 amazon.com 이라는 서비스를 유지하고 있다.

넷플릭스의 마이크로 서비스 구성도를 보면,
마찬가지로 초록색 점들이 마이크로 서비스라고 볼 수 있고, 파란색으로 복잡하게 보이는게 서비스들 간의 호출 작업이다.

Jeff Bezos의 이메일

Jeff Bezos는 아마존 설립자로, 2002년도에 그의 직원들에게 보낸 메일의 내용을 같이 살펴보자.

1. 모든 팀은 “서비스 인터페이스”를 통해서만 데이터 기능을 공개해야 한다.
2. 각각의 팀들은 이러한 인터페이스를 통해서만 통신을 해야한다.
3. 다른 형태(직접 연결, 다른 팀의 데이터 저장소 직접 읽기, 공유 메모리 모델, 백도어)의 프로세스 간 통신은 허용하지 않는다.
   ex. 일반적으로 데이터 베이스에 접속할 때, 해당 db의 ip adress, host name, 포트번호, id, password를 입력한다.
   그런데, 이러한 직접적인 접근을 허용하지 않고 오직 “서비스 인터페이스”를 통해서만 접근할 수 있다는 것이다.
4. 사용하고 있는 기술(프로그래밍 언어, 데이터베이스, 프로토콜, 통신 방식)은 중요하지 않다.
5. 예외 없이, 모든 서비스 인터페이스는 초기 설계부터 외부에 공개될 수 있도록 해야한다.
6. 누구든 이를 지키지 않는다면 해고할 것이다.
7. 좋은 하루 보내!

Microservice의 특징

1. Challenges

마이크로 서비스 아키텍쳐는 기존의 개발 방식이라던가 패러다임을 상당 수 바꿔야만 하기 때문에 chanllenging 하다.

2. Small Well Chosen Deployable Units

독립적으로 배포 가능한 형태의 작은 서비스로 이루어져 있다.

3. Bounded Context

각각의 서비스들은 어플리케이션을 구성하고 있는 전체 도메인의 지식의 따라서, 서비스의 경계를 잘 구분해야 한다.
이런 서비스 경계에 의해서 하나의 서비스가 두 개가 되기도 하고,
여러개의 서비스가 단일화 될 수도 있다.

4. RESTful

각각의 서비스들은 서로 상태에 대해서 REST API 방식으로 통신할 것을 권장한다. (서비스 인터페이스)
REST API는 http 프로토콜을 기반으로해서 json 포맷을 이용한다.
josn은 경량 데이터 포맷이기 때문에 서버의 리소스 혹은 서버가 가지고 있는 상태를 표시하기에 최적화 된 포맷이다.

-> 서비스와 서비스 사이에 호출할 때에는 REST한 방식으로 호출한다.

5. Configuration Management

마이크로 서비스들이 가지고 있는 어떠한 환경에 대한 정보나 설정 정보는 코드 내에 가지고 있지 않고,
외부에 있는 시스템을 통해 관리한다.
다시말해, 우리가 프로그래밍을 하며 하드코딩 된 몇 가지 정보들이 있는데, (ex. IP Address, 특정 값 등…)
이러한 정보를 하드코딩하게 되면 그 정보가 같이 패키징되어 배포되어야 하는데,
이러한 내용을 수정하기 위해서는 내용 수정 후에 다시 배포해야 하는 번거로움이 발생한다.

하지만 설정 정보가 변경되었을 때, 예를 들면 어떨 경우에는 A라는 IP를 사용하고, 어떨 경우에는 B라는 IP를 사용할 때,
굳이 서버가 다시 배포될 필요 없이 단순하게 설정 정보만 바꾸어 운영하는게 좋을 것이다.

이러한 정보를 환경 설정 정보라고 하고, 따라서 환경 설정 정보를 외부에 두어 관리하는 것을 권장한다.

6. Cloud Enabled

Cloud Native 기술을 최대한 활용해서 서비스를 제공할 것이다.
마이크로 서비스들을 지원할 수 있는 Backing 서비스라던가 서비스 매시어 같은 기능들, configuration과 gateway와 같은 모든 것들은
클라우드 상태에서 운영할 것이다.

7. Dynamic Scale Up And Scale Down

서비스를 제공하는 인스턴스들은 부하 분산 처리나 scale-up 혹은 scale-down 등을 동적으로 처리할 수 있도록 구성되어야 한다.

하나의 서비스가 다른 서비스의 형태를 조작하고 사용함으로써 전체 어플리케이션을 구성할 수도 있고,
하나의 서비스에서 하나의 시스팀 혹은 인스턴스만 직접 서비스 되는 것이 아니라, 여러 개의 분산된 형태로 서비스 될 수 있다.

예를 들어 위 사진의 하단을 보면, Microservice1 은 두 개의 호스트(인스턴스)에서,
Microservice2 는 네 개의 호스트(인스턴스)에서,
Microservice3 는 한 개의 호스트(인스턴스)에서 서비스가 될 수 있다.

8. CI/CD

이러한 서비스가 여러개 묶여 하나의 어플리케이션을 구성하다 보니 CI/CD가 중요하다.

9. Visibility

마이크로 서비스들은 시각화 할 수 있는 관리 도구들을 같이 가지고 있어야 한다.

그렇다면 기업에서는 기존 프로젝트를 무조건 MSA로 변경하거나 혹은 신규 프로젝트를 MSA로 개발해야할까?

그렇지 않다.
MSA를 도입하기 전에, 다음 질문에 대해 고려해보자.

1. Multiple Rates of Change: 어느 정도 변화가 생길 것인가?
   분명히 기존 개발 대비 비용이나 시간이 더 들어가는데, 도입한다면 어느 정도의 공수를 받아들일 수 있을지

2. Independent Life Cycles: 독립 라이프 사이클
   어플리케이션을 구성하고 있는 각각의 서비스들이 독립적으로 개발되고 운영될 수 있도록 서비스 경계가 잘 만들어 질 수 있는가?

3. Independent Scalability: 독립적인 확장성
   각각의 서비스를 운영함에 있어서 서비스 유지 보수 및 확장이 쉽게 가능한가?

4. Isolated Failure: 격리된 오류
   발생한 오류 사항이 독립적인가?
   즉, 마이크로 서비스에 부분적인 오류가 발생한다고 하더라도, 오류가 발생한 서비스만 영향을 받도록 설계되었는지
   다른 마이크로 서비스들은 오류에 최소한의 영향을 받으면서 해당 서비스를 우회할 수 있는 대체 서비스가 준비되어있는지

5. Simplify Interactions with External Dependencies: 외부 종속성과의 상호작용을 단순화시켜야 한다
   서비스 간의 종속성을 최소화 하고 응집력을 높일 수 있도록 서비스 경계가 잘 구분되어 있는가?

6. Polyglot Technology: 각각의 서비스에 맞는 여러가지 프로그램 언어와 데이터베이스를 자유롭게 선택할 수 있는가?
   

위 6가지 사항들이 충분히 고려되어있다면, MSA로의 전환 혹은 도입을 고려해볼 수 있다.

비유

지금까지 설명한 마이크로 서비스들은 그 서비스를 구성하는 서비스의 경계, 업무의 범위, 용도와 사용 시나리오 등에 따라서
하나의 비즈니스 로직이 하나의 서비스일 수도 있고, 더 작은 서비스일 수도 있다.
분리된 두 서비스를 조합해서 새로운 영역의 서비스를 생성할 수도 있을 것이다.

이러한 기능은 마치 장난감 레고와 같다.
다양한 형태의 모양과 크기를 가지고 있지만 기본적인 구조는 동일하고, 필요에 따라 자유롭게 조립해 하나의 서비스를 생성할 수 있다.

---

💛 개인 공부 기록용 블로그입니다. 👻

맨 위로 이동하기