앞서, 서비스 메시

서비스 메시란?

• 프로세스 외부에서 MSA 간의 네트워크 트래픽을 투명하게 관리
• 보안 및 관찰 가능성을 제공하는 인프라 계층

면접용
-----
서비스 메시는 MSA에서 서비스 간 호출이 많아지면서 타임아웃/리트라이/서킷브레이커, 인증 및 암호화, 모니터링 및 트레이싱 같은 공통 요구가 생깁니다.
서비스 메시는 이를 각 서비스 코드에 넣지 않고 사이드카 프록시(데이터 플레인)가 처리하고, 컨트롤 플레인이 정책을 중앙에서 배포해서 일관성과 운영성을 높이는 구조입니다.

등장 배경

1. 기존 모놀리식 아키텍처 → MSA 전환

   시스템이 분산됨에 따라 통신 복잡성이 증가하여, 다음과 같은 문제가 대두
   1. 복잡한 서비스 관계
   	 - 서비스 간 상호작용 증가로 장애 전파 위험도 증가
   
   2. 관찰 가능성 부족
   	 - 분산 시스템에서 무슨 일이 일어나고 있는지 파악하기 어려움
   
   3. 일관된 보안 정책 부재
   	 - 다양한 팀이 서로 다른 보안 접근 방식 사용
   

2. 내부망 진입점의 역할의 문제

   내부망의 진입점의 역할을 하는 GW의 경우 모든 동작 처리가 무거워지고, 내부망 내부 통신이 어려웠음
   

3. 신뢰성 문제

   클라우드 인프라 신뢰성은 100%가 아니므로(일시적이거나 간혹 사용 불가능, SLA 99.99%), 이를 염두에 둔 앱을 설계할 필요성 증가
   

기존 시도

• 서비스 상호작용 복원력/로드밸런싱을 높이기 위한 몇 가지 패턴이 발전

  - Client-site load balancing
  	* 클라이언트에게 엔드포인트 목록을 제공하고 어떤 엔드포인트를 호출할지를 클라이언트가 결정
  
  - Service Discovery
  	* 특정 논리적 서비스의 주기적으로 갱신되는 정상 엔드포인트 목록을 찾는 알고리즘
  
  - Circuit braking
  	* 오작동하는 것으로 보이는 서비스에 일정 시간 부하 차단
  	
  - Bulkheading
  	* 서비스 호출 시 클라이언트 리소스 사용량을 명시적 임계값으로 제한(커넥션, 세션 등)
  
  - Timeouts
  	* 서비스 호출 시 요청, 소켓 활성, Iiveness 등에 시간 제한을 적용
  
  - Retries
  	* 실패한 요청을 재시도
  
  - Retry budgets
  	* 재시도에 제한을 적용
  	* 즉, 일정 기간의 재시도 횟수를 제한ㅎ는 것
  
  - Deadlines
  	* 요청에 응답 유효 기간을 지정
  

• 서비스 메시는 MSA 환경의 대응 개발에 투입된 개발자들에게, 위와 같은 추가 업무 부담을 줄여주기 위해 등장한 것으로도 볼 수 있음

⇒ 즉, MSA에서 통신 품질 + 보안 + 관측 같은 공통 기능을 서비스마다 라이브러리로 구현하던 부담을, 인프라(프록시/정책)로 내려서 표준화하기 위함

인프라에 전가하기 위한 노력

• 프록시 사용으로 관심사를 인프라로 옮기려는 시도를 진행

  • 필요한 것은 전통적 인프라 프록시가 아님

    

  • 애플리케이션을 인식할 수 있고 서비스를 대신해 애플리케이션 네트워킹을 수행할 수 있는 7계층 프록시가 필요

    

  • 프록시는 결국 DatePlane이니, 이를 중앙에서 관리하는 ControlPlane을 두고 중앙에서 관리 가능하도록 설계 가 서비스 메시의 핵심 구조

    

서비스 메시 구조