👉이전글에서 Container환경과 Kubernetes와 같은 Container Ochestration툴이 뭔지 알아봤습니다.

그리고 이번글에서는 Container Ochestration툴 중 가장 대중적인 툴인 Kubernetes의 클러스터에 대해 알아보겠습니다.

Kubernetes 클러스터

Kubernetes 클러스터는 오토스케일링, 버전관리 등과 같은 Container Ochestration의 다양한 기능들을 제공하기 위해 배포된 Kubernetes 환경이라고 보면 될 것 같습니다.

위 사진과 같은 Kubernetes 클러스터의 구조를 통해 Kubernetes(k8s)기반의 애플리케이션을 안정성있고 확장성있게 운영할 수 있습니다.
k8s클러스터는 크게 Control Plane과 Application Node로 구분할 수 있습니다.

• Control Plane : k8s클러스터 내부에서 발생하는 이벤트는 실시간으로 감지하거나 배포관리 등과 같은 클러스터 전반의 관리를 수행하기 위한 컴포넌트
• Application Node : 실제 application이 배포되는 컴포넌트
  
  

위 두 개의 컴포넌트는 하나의 노드상에 같이 배포되거나 개별 노드로 배포될 수 있습니다. (한 개의 노드는 한 개의 VM이라고 생각하면 이해하기 쉬움)
이제 클러스터를 구성하는 컴포넌트들을 세부적으로 살펴보겠습니다.

Control Plane

kube-apiserver

kube-apiserver는 application node를 제어하기 위한 여러 동작을 호출하는 Control Plane의 프론트엔드 api server입니다. (application node 입장에서는 endpoint api server)

Control Plane의 CLI(Command Line Interface) 환경에서 사용자가 직접 kuber-apiserver를 호출할 수도 있습니다. (명령어 : kubectl)
해당 명령어는 실습을 진행할 때 자주 활용될 것입니다. (다음글)

etcd

k8s클러스터 내부에 application을 어떤 방식으로 배포할지? scaling은 어떻게 진행할지? 등과 같은 클러스터 정보들을 key-value 형태로 저장하는 저장소입니다. 해당 정보들은 사용자가 yaml파일 형태로 작성하여 적용될 수 있는데, 이 또한 실습에서 작성해볼 것입니다. (다음글)

kube-scheduler

application node가 배정되지 않아 미배포 상태인 pod를 실시간으로 감지하고, 해당 pod를 실행시키기 위해 application node를 선택하는 기능을 가진 컴포넌트입니다. pod가 배포될 application node는 컴퓨팅 리소스나 pod의 리소스 요구사항 등과 같은 기준에 따라 결정됩니다.

• pod : k8s에서의 배포 최소단위, application이 동작하는 여러개의 Container를 k8s에서의 최소단위로 묶어놓은 컴포넌트 (다음글에서 다룰 예정)
  
  

kube-controller-manager

k8s클러스터에서 실행되는 여러 개의 컨트롤러를 통합 관리하는 프로세스입니다. 해당 컨트롤러들은 복잡성을 낮추기 위해 모두 단일 바이너리로 컴파일되는데, 클러스터 내의 리소스를 감시하고 사용자가 정의한 상태로 클러스터를 유지하기 위해 조치를 취하는 역할을 수행합니다.

해당 컨트롤러들은 대표적으로 아래를 포함합니다.

• node controller : Node를 실시간으로 모니터링합니다. Node에 문제가 발생하였을 경우, 이상이 있는 pod를 종료시켜 node를 정상화합니다.
  
  

• replication controller : kube-apiserver를 통해 각 노드의 상태를 받아오고, 사용자가 설정한 Replica의 수에 일치하도록 노드상에 배포된 pod를 생성하거나 삭제하는 역할을 수행합니다.
• job controller : 일회성 작업을 수행하는 오브젝트를 실시간으로 모니터링하고, 수행이 필요한 작업이 있을 경우 해당 작업을 위한 일회성 pod를 생성합니다.
  
  

이외에도 아래 사진과 같은 다양한 컨트롤러가 포함됩니다.

cloud-controller-manager

k8s클러스터가 AWS와 같은 public cloud에 배포되어 있을 경우, application node를 제어하기 위한 controller-manager입니다. 해당 컴포넌트는 클라우트 플랫폼(ex. AWS, Azure 등)별 전용 cloud-controller-manager를 실행합니다.

Application Node

kubelet

kubelet은 각 application node에서 실행되는 Agent 프로세스입니다. control plane으로부터 명령을 받아 수행하거나, node내 파드들의 상태를 실시간 감시하고 control plane으로 보고하는 application node내 중추적인 역할을 수행합니다.

주요기능은 아래와 같습니다.

1. 파드관리 : Control Plane으로부터 할당된 파드를 노드에 배치하고 실행합니다. 해당 파드에 문제가 발생한 경우, 파드를 재시작하거나 재스케줄링하여 안정성을 유지합니다.
2. 컨테이너 실행 : 컨테이너 런타임(ex. docker 등)을 사용하여 파드에 정의된 컨테이너를 실행하고 관리합니다.
3. 리소스 모니터링 : node의 리소스 사용량을 파악하여 Control Plane에 보고합니다.
4. 상태 보고 : node내 배포된 파드의 상태와 노드의 상태를 주기적으로 Control Plane에 보고합니다.
5. 노드의 자동복구 : 노드가 비정상적으로 종료되었을 때, 자동으로 복구를 시도합니다.
   
   

kube-proxy

kube-proxy는 각 application node에서 실행되고, node간 네트워크를 관리하고 클러스터 바깥에서 접근할 수 있도록 해주는 컴포넌트입니다.

해당 컴포넌트는 node나 pod의 교체가 쉬운 k8s클러스터 환경에서의 원활한 통신을 보장합니다.
문제가 생겨 node나 pod가 새로 교체되는 경우가 발생할 수도 있는데, 이 때 ip가 교체되어 통신이 안되는 상황을 방지하기 위해
pod가 새로 생성될 때 별도 node iptable에 신규 생성된 pod의 네트워크 정보를 현행화합니다.

reference

• kubernetes conponents : https://kubernetes.io/ko/docs/concepts/overview/components/
• kube scheduler : https://velog.io/@gun_123/Kubernetes-Scheduler
• kube controller manager : https://m.blog.naver.com/ijoos/222125981319
• kube proxy : https://velog.io/@squarebird/Worker-Node-Kube-Proxy
• kubelet : https://velog.io/@gun_123/Kubernetes-Kubelet

Kubernetes 개요

Kubernetes는 컨테이너를 쉽고 빠르게 배포/확장하고, 관리 또한 자동화해주는 오픈소스 플랫폼입니다. 대량의 컨테이너를 관리해주는 플랫폼을 통칭하는 말인 Container Ochestration중 하나죠. (약칭 : k8s)

Kubernetes를 처음 접하신 분들은 여기서 Container는 무엇이고, Container Ochestration가 뭔지도 궁금해하실 것 같습니다.
먼저, Container에 대해 짚고 넘어가겠습니다.

Container

Container는 애플리케이션 실행 시 필요한 모든 파일을 포함한 전체 실행(runtime) 환경에서 애플리케이션을 패키징하고 격리할 수 있는 기술입니다. 각 애플리케이션당 독립된 실행환경을 제공하기 때문에 애플리케이션간 영향도를 최소화하여 안정성을 확보할 수 있습니다.

또한, 하나의 application이 실행되는 각각의 Container들은 한 개의 VM내에서 서로 Host OS를 공유하기 때문에,
Container환경 배포 시에는 VM에 배포하는 것처럼 OS를 별도 배포하지 않아도 되고, alpine-linux 등과 같은 경량 OS를 활용하게 됩니다.
이를 통해 빠른 배포가 가능하여 확장성을 보장할 수 있습니다.

결론적으로 Container 기술을 활용하면,

1. 애플리케이션간 독립된 환경을 보장받기 때문에 애플리케이션간 영향도 최소화를 통한 안정성
2. 애플리케이션 배포 시, 별도 OS의 배포는 필요하지 않기 때문에 빠른 배포를 통한 확장성

위 두 가지 이점을 챙길 수가 있게 됩니다.

그렇다면... Container 기술의 원리가 무엇일까?

Container 기술은 아래 두 가지 linux 기능을 활용하게 됩니다.

1. namespaces : 프로세스마다 독립적인 공간을 제공하고, 서로가 충돌하지 않게끔 namespaces를 만들어 프로세스를 실행시킬 수 있습니다.
2. cgroups : 각 컨테이너가 공유 컴퓨팅자원에 대한 제어권을 가질 수 있도록 하는 리눅스 커널의 기능입니다.
   
   

본 글에서 Container 기술의 원리까지는 딥하게 다루지 않겠습니다.
자세한 내용은 아래 링크를 참고바랍니다.
https://tech.ssut.me/what-even-is-a-container/

Container Ochestration

Container Ochestration은 Container가 많아짐에 따라 발생하는 관리의 복잡성을 해소하기 위한 플랫폼들을 통칭하는 말입니다. 본 글에서 다룰 kubernetes와 Docker Swarm 등이 이에 해당합니다.

Container Ochestration은 기본적으로 아래와 같은 기능을 제공합니다.

1. cluster : 관리자가 컨테이너 서버들을 cluster 단위로 추상화시켜 놓고, master 서버를 통해 해당 cluster 내부를 관리합니다.
2. state : 특정 애플리케이션이 동일하게 실행되는 container의 갯수를 자동으로 유지시켜줍니다.
3. scheduling : 여러 노드, 여러 컨테이너 서버에 어떤 프로그램이 있는지 확인한 후에 특정 프로그램을 적절한 공간에 넣어줍니다.
4. Rollout Rollback : 자동 버전관리가 가능합니다.
5. Service Discovery : 특정 컨테이너 서버의 정보(ex. host name 등)가 바뀌면 자동으로 확인하고 등록해주는 proxy가 있습니다.
6. Volume : 데이터를 container 서버의 업/다운과 관계없이 영구히 관리하기 위해 별도 공간을 활용하여 container서버에 자동으로 연결시켜 줍니다.
   
   

kubernetes는 위 Container Ochestration의 특징을 모두 갖습니다.

이어서

다음 글에서 Kubernetes cluster에 대해 알아보겠습니다.

표준 MSA 아키텍처

위 사진에서 파란색 영역으로 구분된 부분을 Inner Architecture, 나머지 부분을 Outer Architecture라 부릅니다.

• Inner Architecture : 실제 구현하려는 서비스와 직접적으로 연관되어 있는 부분입니다. 해당 부분들은 Container 환경에 배포됩니다. (ex. 주문관리 API 서버, 고객관리 API 서버 등)
• Outer Architecture : 시스템이 원활히 돌아갈 수 있도록 시스템 전반적인 부분을 가리킵니다. 외부에서의 접근과 서버간의 연동을 일원화 시켜주는 External Gateway부터 MSA 환경의 데이터 동기화를 위해 사용되는 kafka와 DB서버와 같은 Backing Service 등이 이에 해당합니다.
  
  

본 글에서는 Outer Architecture를 구성하는 모듈을 하나씩 간략하게 알아보겠습니다.

A. External Gateway

External Gateway는 MSA환경의 내/외부에서 Micro 단위의 각 서버에 접근하는 것을 관리하는 모듈입니다.
Micro 서버의 가장 앞단에 위치하여 모든 API로의 호출을 받고, 인증처리를 진행한 후에 각 서비스에 알맞게 트래픽을 전달합니다.

B. Service Mesh

Service Mesh는 MSA환경에서 방대한 양의 인스턴스로 인해 야기되는 복잡성과 불안정성을 보완하기 위해 도입된 아키텍처입니다.
Service Mesh의 구현체인 경량화 Proxy를 통해 Load Balancing, Circuit Breaking 등과 같은 공통 기능들을 제공하여 복잡성과 불안정성을 해소합니다.

MSA 환경에서 야기되는 복잡성/불안정성

1. 방대한 양의 인스턴스로 인해 모니터링 및 로깅에 어려움이 발생합니다.
2. 내부 인스턴스간 통신이 기하급수적으로 증가함에 따라 내부 통신환경이 불안정할수록 MSA 시스템에 큰 타격을 줄 수 있습니다.
   
   

Service Mesh에서 제공하는 대표적 기능들

1. Service Discovery : MSA 환경에서 동적으로 IP/PORT가 변하는 인스턴스를 효과적으로 호출하기 위해 사용되는 패턴입니다. Eureka와 같은 Service Registry가 사용가능한 인스턴스의 목록을 관리하고, 호출할 인스턴스의 IP/PORT를 반환해줍니다. 대표적인 방식으로 Client-Side Discovery, Server-Side Discovery, registration 방식이 있습니다.
2. Load Balancing : Service Mesh로 들어온 트래픽을 적절하게 분배하여 인스턴스에 전달합니다. MSA 환경에서 하나의 서버는 여러 개의 인스턴스를 생성하여 Scale-Out할 수 있는데, Eureka와 같은 Service Registry가 적절한 규칙을 통해 부하를 분산시켜줍니다.
3. Circuit Breaking : Circuit Breaking기능은 이러한 점을 보완하기 위한 기술입니다. 각 인스턴스는 Close, Open, Half-open 세 가지 상태로 Circuit Breaking 공통 기능을 사용하게 되고, 호출하는 서비스에 문제가 발생할 경우 상태를 Open상태로 전환하여 해당 서비스로의 호출에 대한 응답을 대기하지 않게 됩니다. Circuit Breaking은 회로차단기에서 차용한 개념입니다. 기존에는 하나의 서비스에 장애가 발생하면 해당 서비스를 호출하는 서비스가 대기상태가 되고, 대기상태를 또 호출하는 서비스도 대기상태로 되어 많은 컴퓨팅 리소스를 잡아먹게 됩니다. 이로 인해 장애가 확산되어 전체 시스템에 악영향을 초래할 수가 있는데, Circuit Breaking기능을 활용하면 이를 방지할 수 있습니다.
4. Retry and Timeout : 타 인스턴스로의 요청이 실패할 경우, 재요청 보내는 Retry 시간을 설정할 수 있고, Timeout 시간을 설정하여 일정시간이 지난 요청을 종료할 수 있습니다.
5. TLS : 보안을 위해 인스턴스간의 트래픽을 암호화할 수 있는 기능입니다.
6. Distributed Tracing : 분산 시스템의 성능을 디버깅하기 위해 트래픽을 추적할 수 있습니다. 이를 통해, 병목 현상을 식별하고 요청 및 응답 시 내부에서 소요되는 시간을 확인할 수 있습니다.
   
   

이 밖에도 Monitoring, Logging 등의 많은 기능을 수행할 수 있습니다.

Service Mesh 구현

각 Micro Service 앞단에 사이드카 형태로 경량화 Proxy를 배치하여 Retry and Timeout, Circuit Breaking 등과 같은 공통기능을 수행하게 함으로써 비즈니스 로직과 공통기능을 분리시키고, 공통기능을 통해 방대한 양의 인스턴스 환경을 안정적으로 운영할 수 있습니다.

대표적인 Service Mesh 툴로 Istio와 linkerd 등이 있습니다. 해당 툴은 Eureka와는 달리 Java에 종속적이지 않다는 장점이 있어 널리 활용되고 있습니다.

C. Backing Services

Backing Services모듈은 시스템의 데이터 관리를 담당하는 모듈입니다.

1. Persistence : RDBMS와 NoSQL 데이터를 영구히 저장할 수 있는 공간을 제공합니다. (ex. oracle, postgres 등) 이를 통해 DB 인스턴스가 예기치 못하게 종료되어도 데이터는 유지할 수 있습니다.
2. Cache: 데이터 캐쉬를 저장할 수 있는 공간을 제공합니다. (ex. redis) 마찬가지로 캐싱처리를 담당하는 인스턴스가 종료되어도 데이터를 유지할 수 있습니다.
3. Message Broker: Message Queue 등과 같은 기술을 활용하여 인스턴스간 데이터 정합성 유지를 도모할 수 있습니다. (ex. kafka)
   
   

D. Runtime Platform

관리해야하는 인스턴스의 양이 증가함에 따라 관리의 복잡성을 해결하기 위해 Container Orchestration이 해당 모듈에서 사용될 수 있습니다.
대표적인 툴로 Kubernetes가 있습니다.

방대한 인스턴스로 서비스를 운영하기 위해 Container기술을 도입하게 되었습니다.
해당 기술은 서비스간 독립적인 배포와 운영이 가능하고, 인스턴스의 빠른 생성과 제거가 가능하여 빠른 오토스케일링 기능과 배포를 도모할 수 있게 되었습니다. 그리고 Container환경으로 구성되어 있는 방대한 양의 인스턴스를 관리하기 위해 Container기술에 초점이 맞춰져 있는 Container Orchestration툴이 사용되기 시작했습니다.

위에서 언급된 Service Mesh와 Container Orchestration은 방대한 양의 인스턴스로 인해 야기되는 복잡성을 해소한다는 공통점이 있지만, Service Mesh는 MSA 환경의 안정성을 위해 공통기능을 제공한다는 데에 초점이 맞춰져있는 반면,
Container Orchestration은 Container기술에 초점을 맞추어 서비스 운영을 위한 경량화된 환경을 제공하여 운영효율성을 높이는 데에 초점이 맞춰져 있습니다.

E. Telemetry

Telemetry는 MSA환경에 배포되어있는 인스턴스들의 로그와 지표들을 한데 모아 관리하는 모듈입니다.
이를 통해 서비스 호출 트래픽을 추적할 수 있고, 로깅기능과 모니터링 기능을 제공할 수 있습니다.

대표적인 툴로 Elastic Search와 Prometheus, Grafana 등이 있습니다.

F. CI/CD Automation

• CI : Continuous Integration, 지속적 통합, 새로운 코드의 변경사항이 지속적으로 빌드 및 테스트 되어 공유 레포지토리에 통합되는 것을 의미합니다. 이를 위해 필요한 대표적 형상관리 툴로 Git이 있습니다.
• CD : Continuous Deployment, 지속적 배포, 새로운 코드의 변경사항이 CI 과정을 거쳐 공유 레포지토리에 통합되면 이를 Production환경까지 자동배포하는 것을 의미합니다. 이를 위해 필요한 대표적인 툴로 Jenkins가 있습니다.
  
  

이어서

다음 글에서는 간단한 MSA 서비스 구현 실습을 진행해보겠습니다.

본 글은 "MSA 이해와 구현"이라는 사내 강의 수강 후,
여러 MSA 관련 글을 참고하여 작성한 글입니다.

1. MSA란?

MSA는 Micro Services Architecture의 약자로 이름에서 유추할 수 있듯이 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처를 의미합니다.

커머스 서비스를 예로 들면, 커머스라는 도메인 아래 하나의 서비스로 개발되고 운영되고 있었던 모놀리스(Monolith)형태가 아닌
주문, 정상, 회원, 상품 등 커머스 도메인 아래 여러 서비스로 추가 분리 및 개발하여 분리한 각 서비스를 각각의 서버에 배포하여 관리하는 MicroServices형태가 있을 수 있습니다.

위 사진은 가트너에서 제시한 표준 Micro Services Architecture 입니다.
MSA로의 구현 및 전환을 시도하는 많은 기업들에서 위 사진에서 제시된 표준 아키텍처를 따르고 있다고 합니다.
해당 아키텍처에 대해서는 다음글에서 다뤄보도록 하겠습니다.

2. Why? MSA

한눈에 보기에도 복잡한 이 MSA를 저희가 왜 써야할까요?
MSA를 쓰는 궁극적인 이유는 Loose Coupling, 느슨한 결합 특성때문이라고 볼 수 있습니다.
즉, 하나의 통합된 형태로 관리되던 서비스(ex. 커머스)를 여러 나눌 수 있는 최소한의 단위인 micro 단위의 서비스(ex. 주문, 정산, 회원 등)로 나눔으로써 각 서비스 간의 영향을 최소화할 수 있고(낮은 의존성), 이로 인해 모놀리스의 High Cohesion, 높은 응집력 특성으로 야기되는 다양한 문제(ex. 기능 단위 장애의 전체 확산 등)를 보완할 수 있게됩니다.

MSA의 이러한 Loose Coupling 특성은 다양한 기대효과를 낳을 수 있습니다.

장점

장애의 확산 차단

특정 Micro 서비스에서 장애가 발생하면, 전체 서비스로 확산되지 않습니다.

기존 모놀리스 구조에서는 특정 기능의 장애가 발생하면 전체 서비스가 마비되는 일이 흔했는데,
MSA에서는 Micro단위로 서비스를 세분화하여 각 기능을 독립시켰기 때문에
하나의 Micro 서비스가 타 서비스에 영향을 주지 않아 장애의 전체 확산을 막을 수 있습니다.

각 서비스의 개별 배포

각 Micro 서비스별로 개별 배포가 가능합니다.

기존 모놀리스 구조에서는 특정 기능에 대한 변경사항이 적용되려면, 서비스가 하나의 서버로 관리되었기 때문에 전체 서비스 배포가 불가피하였습니다.
MSA에서는 이러한 서비스를 여러 Micro 서비스로 나누어 별도의 서버로 각각 배포하는 구조이기 때문에
각 Micro 서비스별로 개별 배포가 가능합니다.

신속한 기능 수정 및 요구사항 반영

긴급하게 특정 기능에 대한 요구사항이 발생했을 때, 신속하게 반영할 수 있습니다.

위에서 언급했던 것처럼 MSA는 Micro 서비스 단위로 개별 서버에 배포되기 때문에, 서버의 크기가 비교적 작습니다.
이로 인해 배포 시간이 줄어들고 기능 수정이 신속하게 진행될 수 있습니다.

용이한 유지보수

용이한 유지보수가 가능합니다.

특정 서비스에 대한 장애나 이상징후 발생 시, 해당하는 서비스만 점검하면되기 때문에 대처할 영역이 좁아지므로
유지보수가 용이합니다.

Loose Coupling과는 별개로 다양한 기술 수용 등과 같은 장점이 존재합니다.

하지만 MSA의 Loose Coupling, 느슨한 결합 특성으로 인한 단점도 존재합니다.

단점

높은 복잡성

MSA를 활용하면 복잡성이 커집니다.

기존 모놀리스 기반 시스템은 하나의 서비스를 하나의 UI, 하나의 서버, 하나의 DB로 개발하고 관리해왔기 때문에,
타 모듈간 연동도 간단한 함수 호출로 이루어졌고, 데이터 동기화에 관한 부분도 단일 트랜잭션 처리로 간단하게 관리될 수 있었습니다.

하지만 MSA로 구현이 되는 서비스는 Micro 단위의 서비스마다 별개의 서버와 DB로 관리되고 있고,
이로 인해 타 모듈간 연동에 Rest나 gRPC 등과 같은 기술이 활용되어야 하고
데이터 동기화에 있어서도 분산 트랜잭션 환경의 메세지큐 기술이 도입되어 활용되어야하기 때문에,
개발 및 운영에 대한 복잡성이 커지게 되었습니다.

통신 비용 증가

MSA를 활용하면 통신비용 또한 증가됩니다.

여기서 말하는 통신비용은 latency에 따른 통신효율을 의미합니다.
위에서 언급한 것처럼 모놀리스 방식에서는 단순 메소드/함수 호출로 끝나는 연동이
MSA에서는 Rest나 gRPC와 같은 통신 기술이 활용되어야 합니다.
이로 인해 서비스 성능상의 비효율이 발생할 수 있습니다.

데이터 동기화의 어려움

MSA 기반 환경에서는 데이터 동기화를 위한 다양한 기술이 도입되어야 합니다.

서비스의 데이터가 하나의 DB로 관리되는 것이 아닌 Micro 단위의 서비스로 분리되어 각각 별도의 DB로 관리되는 형태이기 때문에,
데이터 일관성 또한 MSA환경에서 주요하게 다뤄야할 이슈라고 볼 수 있습니다.
이를 위한 기술도입 사례로 kafka 메세지큐 기술 도입 사례가 있는데,
특정 Micro 서비스에서 데이터 변경이 발생하여 kafka 메세지 큐에 이벤트를 발행하면,
kafka의 해당 이벤트를 구독하고 있는 Micro 서비스들이 이에 맞게 데이터 변경을 진행하는 방식이 있을 수 있습니다.

분산 트랜잭션 처리 필요

먼저 분산 트랜잭션 환경이란?
2개 이상의 네트워크 시스템간 트랜잭션 환경이라고 보면 됩니다.
모놀리스 환경에서 데이터베이스의 특성 ACID(원자성, 일관성, 고립성, 지속성)를 보장하기 위해 단일 서버/DB내 트랜잭션 처리를 하는 것처럼
MSA 환경의 여러 서버/DB 간에 ACID를 보장하기 위해 단일 트랜잭션이 처리되는 것처럼 여러 기술과 패턴이 도입되어 트랜잭션이 처리되어야 합니다.

이를 위한 대표적인 패턴으로 Saga패턴이 있습니다.

Monolith vs MSA

위와 같은 단점들이 있기 때문에 무조건적으로 모놀리스 방식이 아닌 MSA가 활용되어야 한다고 말할 수 없습니다.
MSA를 활용해야 하는지에 대해서는 구현해야 하는 도메인이나 비즈니스 환경, 사용기술, 해당 서비스를 관리해야하는 조직 등 특성에 따라 선택되어야 합니다.

1. 모놀리스

• 단일 코드베이스
• 쉬운 디버깅
• 쉬운 배포
• 상대적으로 좋은 성능
• 시스템 업데이트 시, 전체 시스템 배포 필요
• 코드 재사용의 어려움 (다른 시스템 모듈에서의 재사용)
• 변경 필요사항에 대한 유연한 대처 어려움
• 다양한 기술 사용에 제약
• 스케일링이 어려움

2. MSA

• 업데이트가 필요한 모듈만 배포 가능
• 코드 재사용이 쉬움 (다른 시스템에서의 코드 재사용)
• 변경 필요사항에 대한 유연한 대처 가능
• 특정 서비스의 장애로부터 독립 가능
• 다양한 기술 적용 가능
• 스케일링이 쉬움
• 개발난이도 증가
• 상대적으로 복잡한 배포
• 네트워크 지연으로 인해 상대적으로 떨어지는 성능
• 데이터 부정합에 취약
  
  

3. Cloud Native

MSA와 함께 많이 언급되는 개념인 Cloud Native에 대해 간략히 짚고 넘어가겠습니다.

Cloud Native란? 클라우드 환경에 맞게 서비스를 구축하여 클라우드의 이점을 최대한 활용한 환경이라고 보면 됩니다.
CNCF(Cloud Native Computing Foundation)에서 정의한 내용에서는 Cloud Native를 클라우드 네이티브 기술은 조직이 퍼블릭, 프라이빗, 그리고 하이브리드 클라우드와 같은 현대적이고 동적인 환경에서 확장 가능한 애플리케이션을 개발하고 실행할 수 있게 해준다. 컨테이너, 서비스 메쉬, 마이크로서비스, 불변(Immutable) 인프라, 그리고 선언형(Declarative) API가 이러한 접근 방식의 예시들이다. 이 기술은 회복성, 관리 편의성, 가시성을 갖춘 느슨하게 결합된 시스템을 가능하게 한다. 견고한 자동화 기능을 함께 사용하면 엔지니어는 영향이 큰 변경을 최소한의 노력으로 자주, 예측 가능하게 수행할 수 있다. 라고 정의하고 있습니다.
쉽게 말해서 Cloud 환경의 컨테이너, 서비스메쉬 등과 같은 기술들을 활용하면 관리편의성, 느슨하게 결합된 시스템 등과 같은 효과를 볼 수 있는 것이라고 보면 됩니다.

Cloud Native는 MSA로 구현되는 서비스에 적용되어야 하는 환경이라서 해당 개념을 더 자세하게 알고가면 좋을 것 같습니다.

아래 나열한 기술들은 Cloud Native의 4가지 핵심기술입니다.

1. CI/CD : Continuous Integration and Continuous Delivery(또는 Deployment), 각자가 작업한 코드를 하나의 결과물로 통합하여 테스트 빌드 지속적 수행(CI), 빌드된 결과물을 최종 배포하여 최종 사용자가 이용가능하도록 지속적 수행(CD), 이러한 과정을 지속적 자동 수행
2. DevOps : Development and Operation, 소프트웨어의 개발과 운영의 스피드와 품질을 향상하기 위한 새로운 조직 문화이자 접근방식. 개발계획 수립부터 비즈니스 타당성 검토, 개발, Build, Release, 서버 쪽에 Deploy , Operation, Monitoring까지 일련의 과정을 뫼비우스 띠처럼 반복
3. MicroServices : 하나의 서비스를 Micro 단위로 쪼개서 관리하는 아키텍처
4. Containers : 애플리케이션 구동을 위해 필요한 라이브러리나 구성파일들을 이미지라는 패키지 형태로 묶어서 구동시키는 환경. 해당 기술을 활용하면 서비스별 독립적인 구동이 가능하고, 효율적인 배포 및 Autoscale 가능
   
   

각 기술에 대한 설명을 간단하게 커멘트 남겼지만,
각 기술 하나하나 다룰내용이 많은 기술들입니다. 해당 기술들은 앞으로 작성될 글에서 더 자세하게 다뤄보겠습니다.

이어서

본 글에서 다양한 키워드가 소개되었습니다.
MSA, 모놀리스, Rest, gRPC, kafka, Saga, Cloud Native...
해당 키워드는 이어지는 글에서 MSA에 대해 상세히 다뤄보며 더 알아보겠습니다.

Reference

• MSA 이해와 구현방법 (사내강의)
• KT Enterprise - https://enterprise.kt.com/bt/dxstory/1007.do
• #2. 마이크로서비스 아키텍처, MSA가 주목 받고있는 이유 (tistory) - https://medium.com/twolinecode/2-마이크로서비스-아키텍처-msa가-주목-받고있는-이유-59092da625cd