Kubernetes Day04

Day04

MSA란 무엇인가?

기존 Monolithic 서비스의 단점

• 코드가 너무 커져서 유지보수가 힘들어졌을 때
• 소소한 수정도 배포가 너무 오래 걸린다.
• 신규 기술을 적용하고 싶다.(버전 업그레이드)
• 연계 시스템에 장애가 날 때 장애에 대한 종속을 끊고 싶을 때

Microservice란?

마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스는 지향 아키텍쳐(SOA) 스타일의 일종인 소프트웨어 개발 기법이다. 마이크로서비스 아키텍쳐에서 서비스들은 섬세하고 프로토콜은 가벼운 편이다.

마이크로서비스는 소프트웨어가 잘 정의된 API를 통해 통신하는 소규모의 독립적인 서비스로 구성되어 있는 경우의 소프트웨어 개발을 위한 아키텍쳐 및 조직적 접근 방식이다. 이러한 서비스는 독립적인 소규모 팀에서 보유한다. 마이크로서비스는 아키텍쳐는 애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 기간을 단축할 수 있게 해준다.

애플리케이션을 더 조그마한 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어준다. 규모가 작은 자율적인 팀들이 서비스를 독립적으로 개발, 전개, 규모 확장을 할 수 있게 함으로써 병렬로 개발할 수 있게 된다. 또, 지속적인 리펙토링을 통해 개개의 서비스 아키텍쳐가 하나로 병합될 수 있게 허용한다. 마이크로서비스 기반 아키텍처는 지속적 배포와 적용을 가능하게 한다.

Microservice의 특징

자율성

마이크로서비스 아키텍처의 각 구성 요소 서비스는 다른 서비스의 기능에 영향을 주지 않으면서 개발, 배포, 운영하고 확장할 수 있다. 서비스가 해당 코드 또는 구현을 다른 서비스와 공유할 필요는 없다. 개별 구성 요소 간의 통신은 잘 정의된 API를 통해 이루어진다.

전문성

각 서비스는 일련의 기능을 위해 설계되며 특정 문제를 해결하는데 중점을 둔다. 개발자가 시간이 지남에 따라 서비스에 더 많은 코드를 제공하여 서비스가 복잡해지면 더 작은 서비스로 분할할 수 있다.

Microservice의 기술적 특징

• 각각의 서비스는 그 크기가 작을 뿐, 서비스 자체는 하나의 Monolithic architecture와 유사한 구조를 갖는다.
• 각각의 서비스는 독립적으로 배포가 가능해야 한다.
• 각각의 서비스는 다른 서비스에 대한 의존성이 작아야 한다.
• 각 서비스는 개별 프로세스로 구동되며, REST API와 같은 가벼운 방식으로 통신되어야 한다.

Microservice 철학

마이크로서비스 아키텍쳐의 철학은 필연적으로 “한 가지 일을 하되 잘하라(Only do one thing but do it well as best as you can)”는 유닉스 철학과 상응한다.

Microservice의 이점

기술적 자유

마이크로서비스 아키텍쳐는 “모든 규모에 부합하는” 접근 방식을 추구하지 않는다. 팀은 특정한 문제를 해결하는 데에 가장 적합한 도구를 자유롭게 선택할 수 있어서, 마이크로서비스를 구축하는 팀은 작업별로 가장 적합한 도구를 선택할 수 있다.

재사용 가능한 코드

소프트웨어를 잘 정의된 소규모 모듈로 분할하면 팀이 기능을 여러 용도로 사용할 수 있게 된다. 특정 기능을 위해 구축된 서비스를 다른 기능의 빌딩 블록으로 사용할 수 있는 것이다. 이를 통해 개발자가 코드를 처음부터 작성하지 않고도 새 기능을 생성할 수 있어 애플리케이션이 자체적으로 부트스트랩 작업을 생성할 수 있다.

복원성

서비스가 독립적이므로 실패에 대한 애플리케이션의 저항성이 증가한다. Monolithic architecture에서는 단일 구성 요소가 실패하는 경우 전체 애플리케이션이 실패할 수 있게 된다. 마이크로서비스에서는 기능을 저하시키고 전체 애플리케이션을 충돌시키지 않는 방식으로 전체 서비스 실태를 처리한다.

Microservice의 기술적 이점

배포 관점

• 서비스 별 개별 배포가 가능하다.
• 독립 배포가 가능하므로 개발자의 자율성이 증가한다.
• 요구 사항을 신속하고 빠르게 반영하여 배포할 수 있다.

확장 관점

• 특정 서비스에 대한 확장성이 용이하다. 클라우드 사용에 적합하다.

장애 관점

• 장애가 전체 서비스로 확장될 가능성이 적다.
• 부분적 장애에 대한 격리가 수월하다.

유지보수 관점

• 팀 별로 프로젝트가 분리되어 있으므로 코드의 이해도가 증가하고, 그에 따라 유지 보수하기 쉽다.
• 신기술의 적용이 유연하고, 서비스를 polyglot하게 개발 및 운영할 수 있다.
• 여러 프로그래밍 언어, 패러다임 등을 사용할 수 있다.
• polyglot programming이란 한 가지 언어가 아닌 다양한 언어를 사용하여 프로그래밍 한다라는 뜻을 가지고 있다.

Microservice의 단점

성능 관점

• 서비스 간 호출 시 API를 사용하기 때문에 통신 비용 및 지연 시간이 증가한다.

데이터 관리 관점

• 데이터가 여러 서비스로 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또는 일관성을 유지하기 위한 동기화 작업이 어려움.

테스트 / 트랜잭션 관점

• 단위 테스트는 쉽지만 통합 테스트는 여러 서비스의 API를 검증해야 하므로 시간과 비용이 많이 든다.
• 각 서비스 별로 데이터베이스가 있으므로 트랜잭션을 구현하기가 까다롭다.
• 아키텍쳐가 다소 복잡하므로 개발 및 관리가 어렵고 비용이 많이 든다.

마이크로서비스를 위한 조건

1. 비용
   • MSA 아키텍쳐를 도입할 경우, 모놀리틱 아키텍쳐에 비해 비용을 얼마나 절감할 수 있는가?
2. 개발 생산성
   • 마이크로 서비스를 요구할만큼 시스템 복잡도가 높은가? 또는 복잡도를 지나치게 높인 마이크로 서비스가 생산성을 저해하고 있진 않은가?
3. 운영 인프라
   • 개발 팀에게 개발과 운영을 동시에 할만큼 인프라가 준비되어 있는가? 또는 개발 인력이 마이크로 서비스를 관리할 역량이 있는가?
4. 배포 주기
   • 배포를 충분히 자주 하고 있는가? MSA는 빠른 변화에 대응하기 위해 도입하는 것인데, 회사마다 배포일이 정해져 있고 배포가 가끔씩 일어난다면 효율이 떨어진다.

Monolithic vs SOA vs Microservice

Microservice 사례

쿠팡

모놀리틱 5가지 문제점

1. 확장성 리스크 및 낮은 신뢰성
2. 관심사 분리 실패
3. 확장성 부족
4. 효율적인 테스트를 위한 비용증가
5. 비효율적인 서비스 배포

카카오

모놀리틱 3가지 문제점

1. 서비스 배포가 어려움
2. 코드 버전관리 복잡도가 높음
3. 서비스가 너무 커지다보니 변경하기가 어려움.

MSA 적용 후 개선된 점

1. 업무 역할 분담이 명확해졌다.
2. 배포의 부담이 많이 낮아졌다.
3. 신규 서비스가 기능 추가가 쉽다.

MSA 적용 후 문제점

1. 설계 제약 사항과 고민들이 늘어난다.
2. 개인이 담당할 서비스가 늘어난다.
3. 서비스가 도메인 지식 공유가 힘들다.

결론

• 우리가 해결해야 할 문제가 정확하게 정의되어야 하며 그에 맞는 설계를 할 수 있는 현장조사가 제일 중요하다.

우아한 형제들

emart MSA 설계하기(예시)

카카오 선물하기 MSA 설계 실습