MSA, Docker, Kubernetes, Service Mesh, Istio에 대해 알아보자

졸업 프로젝트로 이 주제를 정하게 되었다. 그래서 MSA, 도커, k8s, 서비스 메시, Istio에 대해 정리해보고자 한다. 

 

 

MSA란?

• 지금까지 배포환경에서의 표준이였던 하나의 코드베이스로 이루어진 Monolythic Architecture은 여러가지 문제점이 있었다.
  • 부분 장애가 전체 서비스의 장애로 확대될 수 있다.
  • 전체 시스템 구조 파악이 어렵다.
  • 서비스 변경이 어렵고, 수정 시 영향도 파악이 힘들다.
  • 빌드 시간 및 테스트, 배포 시간의 급증
  • 서비스의 특정 부분만 Scale Out이 어렵다.
• 그래서 이런 문제점을 극복하고자 MicroService Architecture가 나오게 되었다.
• 하나의 비즈니스 당 하나의 서버를 사용하게 된다. 그래서 예전의 Monolythic Architecture처럼 하나의 코드베이스가 아니라 여러개의 서버로 구성되어있는 Back-End를 구성하게 된다.
• MSA의 장점은 다음과 같다.
  • 서비스별 개별 배포가 가능하게 된다.
  • 특정 요구사항을 반영하려면 특정 서비스만 수정, 배포만 하면 된다. (다른 서비스에 영향 X)
  • 특정 서비스에 대한 Scale Out이 쉽다.
  • 특정 서비스에서 장애가 일어났을 전체 시스템과의 격리가 용이하다.
  • 하나의 공통된 기술을 쓰지 않아도 된다. 서비스 별 적합한 프레임워크나 기술을 사용할 수 있다.
• 하지만 장점이 많은 만큼 단점도 있다.
  • 설계가 어렵다. 서비스가 모두 분산되어 있기 때문에 내부 시스템의 통신을 잘 설계해야 한다.
  • 서비스 간 호출 시 API를 호출하기 때문에 네트워크 비용이 많이 든다.
  • DB Transaction이 어렵다. Monolythic 구조에서는 트랜잭션 고민이 없지만 MSA에서는 서비스가 다 분산되어있기 때문에 트랜잭션이 어렵고 실패가 일어나게 되면 모두 롤백처리해야한다.

Docker & k8s & 컨테이너 운영환경

• Docker는 Linux 기반의 Container Runtime 오픈소스이다. VM과 유사하게 작동하고, 훨씬 가볍게 작동한다. VM에서는 Host OS, HyperVisor 위에 Guest OS가 설치되며, Guest OS 위에서 Application이 작동하는 반면, Docker는 Host OS 위에 Docker Engine을 설치하고, Docker Engine위에 각각의 컨테이너를 올려서 Application을 운영한다.
• k8s는 컨테이너화된 애플리케이션의 자동 배포, 스케일링 등을 제공하는 관리시스템이다.
• k8s는 node, pod, service 등으로 구성되어있다.
  • k8s cluster : Master Node, Worker Node로 구성된 컨테이너 운영환경을 뜻한다. 마스터 노드는 쿠버네티스 제어를 담당하고, API 서버, 스케줄러, 컨트롤 매니저 등이 마스터 노드에 있고, 워커 노드는 컨테이너가 실행되는 노드로, 애플리케이션 컨테이너가 실행되고 관리되는 노드이다. YAML 형식의 매니페스트 파일에 애플리케이션 배포와, 스케줄링 하는 설정이 들어 있다.
  • node : 쿠버네티스 클러스터에 속하는 개별적인 컴퓨터이다. 각 노드는 쿠버네티스 에이전트를 실행하여 마스터 노드와 통신하고 Pod를 실행한다.
  • pod : 쿠버네티스에서 가장 작은 배포 단위이고, 하나 이상의 컨테이너로 구성되어있다. 한 pod 내의 컨테이너들은 동일한 생명 주기를 가지기 때문에 서로 밀접한 관계를 가지는 컨테이너들이 한 pod 에 있고, 스케일링의 기본 단위가 된다. ex) 1 node → 2 pod (a pod : 결제, 배송, 주문/ b pod : 회원관리, 인증)
  • service : 클러스터 내의 서비스에 대한 안정적인 네트워크 엔드 포인트를 제공한다. pod의 집합에 대한 접근과 로드밸런싱을 수행한다.

Service mesh

• service mesh는 MSA를 적용한 시스템의 내부 통신이 Mesh 네트워크의 형태를 띄는 것에 빗대어 Service Mesh라고 한다.
• 서비스 간 통신을 추상화하여 안전하고 빠르고 신뢰할 수 있게 만드는 InfraStructure Layer이다. 추상화를 통해 복잡한 내부 네트워크를 제어하고, 추적하고, 내부 네트워크 관련 로직을 추가함으로써 안정성, 신뢰성을 확보한다.
• Service Mesh 의 구현체인 경량화 Proxy를 통해 다양한 Routing Rules, circuit breaker 등 공통기능을 설정할 수 있다.. 이는 서비스 간 통신에 연관된 기능 뿐만 아니라, 서비스의 배포 전략에도 도움을 준다.

Istio

• Istio는 Google, IBM, Lyft가 함께 기여하고 있는 오픈소스 Service Mesh 구현체이다. kubernetes를 기본으로 지원하고 Control Plane — Data Plane 구조로 동작한다

• Data plane은 envoy를 서비스 옆에 붙여서 사이드카 형식으로 배포를 해서 서비스로 들어오고 나가는 트래픽을 envoy를 통해 통제하게 된다.
• Control plane은 data plane에 배포된 envoy를 컨트롤 하는 부분으로 Pilot, Mixer, Citadel로 이루어져있다.
  • Pilot : Envoy에 대한 설정 관리를 한다. 서비스들의 EndPoint들의 주소를 얻을 수 있는 서비스 디스커버리 기능을 제공한다. 서비스의 안정성을 위한, 재시도, 장애 전파를 막는 Circuit Breaker, Timeout등의 기능을 제공한다.
  • Mixer : 액세스 컨트롤, 정책 통제, 각종 모니터링 지표의 수집이다. 서비스의 총 처리량을 정책으로 지정하여, 그 처리량 이상으로 못받게 하거나 특정 헤더값이 일치해야 요청을 받게한다.
  • Citadel : 보안에 관련된 기능을 한다. 사용자 인증, 인가 의 기능을 하고 TLS 암호화나 사용자 인증에 필요한 Certification을 관리한다.

출처 : 

https://istio.io/latest/

Istio

https://velog.io/@holicme7/K8s-%EC%BF%A0%EB%B2%84%EB%84%A4%ED%8B%B0%EC%8A%A4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

velog

https://bcho.tistory.com/1296?category=731548

Istio #3- Istio에 대한 소개

https://www.samsungsds.com/kr/insights/service_mesh.html

실무자를 위한 서비스 메시 - 지금 서비스 메시가 의미 있는 이유 | 인사이트리포트 | 삼성SDS