[Cloud] 마이크로서비스 개요

*본 포스트는 성신여자대학교 [클라우드 컴퓨팅] 강의 기반으로 작성됨을 알립니다.

 

 

목차

1. 마이크로서비스란 무엇인가?

2. 마이크로서비스의 장단점

3. 마이크로서비스의 앱의 설계

4. 확장성

---

 

1️⃣ 마이크로서비스란 무엇인가?

 

1개의 application에서 여러 개의 작은 단위의 소프트웨어들이다.

→ "개별적"으로 업데이트가 가능하며, "외부 접근"이 불가능하며, 전형적으로는 "한 가지 기능"(적은 기능) 잘 수행한다.

즉, 개별적으로 배포일정을 갖고 업데이트 운영이 가능한 작고 독립적인 소프트웨어 프로세스이다. 개별적이기 때문에 각 마이크로서비스마다 개발 주기가 상이하고 독립적으로 해결이 가능하다.

 

또한 마이크로 서비스는 개발과정 측면과 성능 측면 2가지에서 장점이 존재한다. (독립적 배포, 유연성 / 앱의 확장성, 느슨하게 연결되어 전체 서비스에 영향 X, 자신만의 DB)

마이크로서비스

 

마이크로서비스의 정의를 기반으로 마이크로서비스 앱이란, application의 주요 기능들을 수행하기 위해 서로 협업하는 작은 서비스들로 구성된 분산 프로그램이다. 클러스터 내에서 여러 개의 작고 독립적인 서비스로 구성되어 있다.

마이크로서비스 앱

 

2️⃣ 마이크로서비스의 장단점

 

마이크로서비스를 사용하기 전에는 "모놀리스" 방법을 사용하였는데, 모놀리스는 흔히 단일 프로세서에서 application이 동작하는 것이다. 단순하고 복잡성이 낮아서 난이도가 낮고 실험적 개발이 가능하지만, 시간이 지남에 따라 규모가 커지면 실험적 모델을 새로 추가하기 어려우며, 스파게티 코드의 가능성이 있어서 코드 변경이 어렵다. (코드 1줄 바꾸는데 전체가 영향)

 

또한, 분산 애플리케이션은 매우 복잡하고 구현에 많은 비용이 발생했다. "클라우드 & 가상화" 및 "가상 인프라 관리 자동화 도구"의 등장으로 비용이 감소하고 접근성 변화로 마이크로서비스를 많이 사용하게 되었다.

 

장점 → 세밀한 확장성 (독립적으로 성능 확장) / 배포 위험 감소 (전체 시스템에 영향 X) / 기술적 유연성 (기술 스택에 구애 X)

단점 → 어렵다. 단기적으로 복잡하다.

 

(좌) 모놀리스 (우) 마이크로서비스

 

 

3️⃣ 마이크로서비스의 앱의 설계

 

마이크로서비스 최신 도구 : 도커(서비스 배포) / 도커 컴포즈(마이크로서비스 앱 테스트) / 쿠버네티스(클라우드 앱 호스트)

 

설계 규칙

1. 지나친 미리 설계X → 단순한 설계부터
2. 최대한 단순하게 유지 → 지속적인 리팩토링
3. 좋은 설계를 자연스럽게 완성으로 유도 (커다란 앱을 단정적으로 설계가 불가능하니까)

마이크로서비스의 원칙

1. 단일 책임 원칙 (1서비스 1업무)
2. 느슨한 연결 (서비스 간 연결 최소화, 문제 확산 최소화 → 유연한 대처 가능)
3. 강한 응집력 (하나의 마이크로서비스 안에서 코드가 서로 기능적으로 연결)

 

도메인 기반 설계 (DDD, Domain Driven Design)

비즈니스 도메인을 중심으로 설계를 해나가는 방법이다.

아래 그림과 같이, 추천을 하는 영역과 비디오를 재생하는 영역으로 나눠서 의미적 구분을 한다.

 

DDD

 

4️⃣ 확장성

• 개발 팀 규모가 커지면 어떻게 확장?
• 트래픽이 많아지면 어떻게 확장?

개별 프로세스 확장

• 마이크로서비스 앱 소규모 개발 : 새로운 마이크로서비스 앱의 초기 단계에서는 전체 앱을 하나의 팀에서 작업
• 여러 팀 : 마이크로서비스 앱을 분할해서 서로 겹치지 않게 구분된 영역을 각 팀이 책임진다. 하지만 규모가 커지면서 테스트 환경이 필요하고 개발자 간 관리 실패 및 확장성 부족하다는 문제 발생.

(좌) 소규모 (우) 팀 분할

 

• 독립적인 마이크로서비스 
  • 단일보다는 분리된  코드 repository와 여러 CD 파이프라인
  • 전체 앱의 관리는 복잡하지만 세부적으로 배포 제어 가능. 규모가 어느 정도 커졌을 때 해야지 cost 감소
  • 코드 repository 분리 : 마이크로서비스마다 분리된 repository
  • CD 파이프라인 분리 : 마이크로서비스마다 구분된 배포 파이프라인

CD 파이프라인 분리

• 메타리포 : 분리된 repository들을 하나의 코드 repository로 묶어주는 가상 코드 repository
  • meta is a tool for managing multi-project systems and libraries
  • https://github.com/mateodelnorte/meta?tab=readme-ov-file
• 다중 환경 만들기 : 각자 개발 워크스테이션에서 코드 작성 및 테스트 → 개발 환경(merge 및 테스트)  → 테스트 환경 (변경 사항 통합 & 테스트 완료) → 운영 환경 (변경 사항 통합 & 고객에게)
• 운영 워크플로 : repository 안에서 branch로 구분해서 사용

운영 워크플로

 

성능 확장성

성능에 대한 섬세한 제어 가능 (모니터링)

• 클러스터 수직 확장 : 부족한 자원(CPU, RAM ,,,) → 클러스터에 가용한 자원 증가
• 클러스터 수평 확장 : 같은 크기로 개수 늘리기 (수직확장보다 lower cost)
• 개별 마이크로서비스의 수평 확장 : 부하를 나누어서 load balancer. 하나의 마이크로서비스를 여러 개로 복제
• 탄력적인 확장
  • 클러스터 : 자동으로&동적으로 필요없는 자원은 해제하고 더 필요하면 맞게 할당
  • 개별 마이크로서비스 : 마이크로서비스 복제 수를 동적으로 조정
• 데이터베이스 확장 : 1마이크로서비스 1DB → 공유 DB로 발생하는 bottleneck 해결! / 앱이 커지면 DB 서버 구축 및 분리 / 거대한 DB는 샤드(shards)란 이름의 여러 VM으로 분산 = Sharding
• 인프라 변경 관리 : 블루-그린 배포 (두 개의 운영환경으로 개발자와 고객 환경을 나누어 안전하게 인프라 관리)

 

모놀리스 → 마이크로서비스 전환

1. 모놀리스에서 기능 추출 & 쿠버네티스 클러스터 생성
2. 자연스러운 경계로 분할하기 (e.g., DDD)
3. 자주 변경하는 부분을 추출 (적은 비용으로 마이크로서비스 누리기)