[이모티콘 서비스] 카카오는 왜 MSA를 선택했을까?

https://tech.kakao.com/2021/09/14/msa/

이모티콘 서비스는 왜 MSA를 선택했나?

안녕하세요! 오늘은 카카오의 모놀리식 시스템에서 MSA 시스템을 선택하게 된 이유에 대한 글을 정리해보려 합니다.

 

Why Micro Service Architecture(MSA)?

운영

• 배포 이슈
  과거 webistrano, ansible을 통해 배포를 진행
  -> 러닝 커브의 시간 비용 낭비
  -> 서버마다 배포 방식의 복잡성
  -> 배포 실수로 인한 장애 가능성(휴먼 에러)
  
  
• 코드 관리의 복잡도
  -> 하나의 서버에 여러 기능이 있기에 여러 브랜치를 만들어 작업하지만, 휴먼 에러로 인해 여전히 원치 않은 장애들이 발생
  
  
• Main DB의 트래픽 이슈
  -> 서비스가 거대해지면서 트래픽 과부하

기술

• 모놀리식 -> MSA 설계 변경의 어려움
  -> 기존 시스템 설계의 문제로, 한가지 기능을 변경하게 되면 사이드 이펙트 부담감 증가
  
  
• 레거시 프로그램들의 종속적인 문제
  -> 라이브러리가 신규 버전에서 호환이 되지 않음

결론(인용구)

그래서 저희는 배포 부담을 줄이기 위해 배포 단위를 작게 만들고 싶었고, 담당 영역을 분산하기 위해 서비스 크기를 작게 만들고 싶었습니다. 거기에다 기술 적용에 자유도를 높여서 다양한 기술을 사용하는 방향으로 서비스가 만들어졌으면 했습니다.

 

그렇다면 MSA의 특징은 무엇일까요?(위키피디아, 인용구)

• 서비스 간 네트워크 통신
• 서비스는 비지니스 기능을 중심으로 구성
• 서비스 간 최적화된 기술 사용
• 서비스 크기의 최적화, 자율적인 개발이 가능, 독립적 배포, 분산 처리, 자동화된 프로세스 구축 등이 가능합니다.

카카오는 이러한 MSA의 특징이 이모티콘 서비스의 운영과 기술적인 문제들에 대해 해결할 수 있을 뿐만 아니라, 더 많은 장점을 가지고 있기에 선택하였다고 합니다.

 

이모티콘 서비스, MSA를 통해 기대하는 것(인용구)

운영 이슈

배포 단위가 작아진다.
배포 영향 범위가 줄어든다.
배포 버전 관리가 독립적이 된다.
Branch 엉키는 일이 줄어든다.

기술 이슈

서비스가 작아져 역할이 명확해지고, 디버깅 포인트를 고립시킬 수 있다.
설계변경에 대한 부담이 낮아진다.
각 서비스별로 기술 선택의 의존성이 낮아져서 각 서비스에 맞는 최적 기술을 선택이 가능해진다.

 

그렇다면 MSA를 도입하게 됐을 때 카카오에서 겪을 것이라고 예측한 어려움은 무엇이 있을까요?

기술

• 함수 호출이 Network I/O 호출로 바꾸어야 함.(서비스 간 상태 동기화의 어려움)
  MSA 특징을 살펴보면, 서비스 간 네트워크 통신은 불가피하다는 것을 알 수 있습니다. 즉, 애플리케이션의 기능을 분리하게 되면 각 함수의 호출은 Network I/O 호출로 바꾸어야하는 것은 불가피합니다.
  
  
• DB를 분리할 때의 Join 하기 힘듦

운영

• 관리해야할 서비스의 복잡성 증가
  MSA를 도입하게 되면, 애플리케이션의 기능을 세분화시켜야 하기 때문에, 서비스들을 관리(운영)하기 힘들어질 것은 당연합니다.

결론(인용구)

이렇게 저희 팀이 기대하는 것과 우려하는 것을 종합해서 고민한 결과는 다음과 같습니다.

MSA가 우리의 목표에 맞는 설계라고 결정을 하게 되었고, 그 청사진에 맞는 시공 방식과 건축 자재로는 클라우드 환경을 지원하는 쿠버네티스(kubernetes)를 선택하였습니다. 그리고 서비스 단위가 아닌 더 작은 요청 단위의 리소스 활용에 더 효과적일 거라 기대하는 Kotlin을 개발 언어로 선택하였습니다.마지막으로 우리에게 친숙하고 비교 대상이 크게 없는 Spring을 개발 프레임워크로 선택하였습니다.

 

쿠버네티스의 문제점

• 서비스 만큼의 yaml 파일 생성
• 중복된 yaml 파일이 많아져 복사 붙여넣기의 반복작업

쿠버네티스의 문제점 해결방법

• Kustomize(yaml의 간편화)
  yaml 설정을 directory를 이용해서 구조화하고 각 설정을 재사용할 수 있게 되어 설정의 관리가 간편하다는 장점이 있습니다.
  
• GitOps
  쿠버네티스의 구성요소들을 관리하고 배포하기 위해서는 Manifest 파일을 구성하여 실행하게 됩니다. 이때 지속적인 관리를 위해 Git으로 관리하는 방식을 말합니다.
• ArgoCD
  쿠버네티스를 위한 CD(Continuous Delivery) 툴입니다. 더 세부적으로 말씀드리면 GitOps를 이용하여 쿠버네티스에 배포까지 도와주는 도구라고 생각하시면 됩니다.
  
  즉, GitOps방식으로 관리되는 Manifest 파일의 변경사항을 감시하고, 현재 배포된 환경의 상태(사용자가 원하는 상태)와 Git에 정의된 상태를 동일하게 유지하는 역할을 수행합니다. 이러한 기능은 쿠버네티스의 동작 구조인 Control Loop 특징과 매우 유사합니다.
  

그러나, 이모티콘 서비스들을 쿠버네티스에 올렸을 때 인프라만 교체되는 정도였기에, 서비스의 흐름을 제어하지는 못했다고 합니다.

 

서비스의 흐름을 제어하기 위한 방법

• Istio(인용구)

이스티오는 쿠버네티스에 올려진 서비스들 간의 연결 구조를 볼 수 있는 서비스 매쉬 계층을 두고 그것을 관리할 수 있는 기능을 제공합니다.

VirtualService, ServiceEntry, Proxy 등 다양한 기능을 제공하여 연결 관리를 좀 더 유연하게 해주고, 이스티오에서 제공하는 서비스 메쉬 설정 정보들을 통해 서비스들의 상태나 연결 흐름을 kiali를 설치하시면 눈으로 확인하실 수 있습니다.

 

카카오 이모티콘 서비스 나누기(인용구)

• API Gateway(Spring Cloud Gateway) -> 레거시 고립

카카오 이모티콘 서비스 분리 과정

의문점

• 단순 라우팅인 ingress 만으로 해결이 가능하지 않을까?

ingress 라우팅을 사용하게 된다면,

인증 등 특정 비즈로직을 서비스별로 처리해야하는 상황에서, 인증 관련 로직을 수정하게 됐을 때 인증이 들어간 서비스 모두 변경되어 각각의 서비스를 독립 배포 및 유지가 어렵다는 문제가 발생했을 것입니다.

API gateway가 있을 때와 없을 때의 인증 과정(좌측 없을 때, 우측 있을 때)

카카오 이모티콘 팀의 MSA 단위 정의(인용구)

여기에서 서비스를 하나둘씩 분리할 때 가장 큰 고민거리 중에 하나가 바로 마이크로 서비스의 기준이 무엇인지 결정하는 것이었습니다.사실 아직도 팀 구성원들 사이에서 완전히 합의된 마이크로 서비스에 대한 단위를 정의하지는 못했지만 최소한의 합의된 기준들은 이렇습니다.

- 기능 목적이 2개 이상이 되지 않도록 한다. 
- 여러 기능에서 사용하는 단위 리소스라면 서비스로 분리하여 공동 사용한다.
- 사내 통제 대상인 Admin인 경우, 최소한으로 통제 Cluster에 넣도록 서비스를 분리한다.
- 개인 정보 대상으로 분류된 데이터를 관리하는 서비스는 해당 데이터 관리에 필요한 기능을 최소화하여 분리한다.

이건 경험상 이렇게 해두지 않으면 개인 정보 대상의 db가 아닌데도 같이 묶여, db 확인을 위해 매번 망분리 환경에 들어가야 하는 불편을 겪게 됩니다.

- 마지막으로 서버 렌더링을 배제하기 위해 Front서비스와 Backend 서비스는 서로 분리한다.

구성원들이 나누어질 서비스의 기준에 대한 합의 없이 서비스를 나누게 되면 중구난방의 설계가 되어 불필요한 분리가 되거나 다시 덩치 큰 서비스를 만들 수 있게 되어 서비스 단위의 기준에 대한 논의는 꼭 하시는 게 좋습니다.

이렇게 서비스를 나누는 과정까지 해서 MSA 적용을 위해 저희 팀이 한 일들을 모두 알아봤습니다.