MSA(MicroService Architecture)

Bzeromo·2023년 2월 23일

msa

MSA

목록 보기

4/10

⚡ Kubernetes & MSA 4일차

📌 MSA란?

⭐ MSA 개념

🔷 마이크로서비스는 애플리케이션을 느슨하게 결합된 서비스의 모임으로 구조화하는 서비스 지향 아키텍처(SOA) 스타일의 일종인 소프트웨어 개발 기법이다.

마이크로서비스 아키텍처에서 서비스들은 섬세하고 프로토콜은 가벼운 편이다.
애플리케이션의 확장을 용이하게 하고 개발 속도를 앞당겨 혁신을 실현하고 새로운 기능의 출시 시간을 단축할 수 있게 해준다.
애플리케이션을 더 조그마한 여러 서비스로 분해할 때의 장점은 모듈성을 개선하고 애플리케이션의 이해, 개발, 테스트를 더 쉽게 해주고 애플리케이션 침식에 더 탄력적으로 만들어준다.

⭐ 마이크로서비스를 사용하는 이유

🔷 코드가 너무 커져서 유지보수가 힘들어 졌을 때

기존 로직을 수정하면 무슨 일이 벌어질 지 모른다.
새로 입사한 직원이 코드를 분석하기 쉽지 않다.
문제가 발생한 부분이 어딘지 찾기 어렵다.

💡 Side Effect(부작용)
컴퓨터 과학에서 함수가 결과값 이외에 다른 상태를 변경시킬 때 부작용이 있다고 말한다. 예를 들어, 함수가 전역변수나 정적변수를 수정하거나, 인자로 넘어온 것들 중 하나를 변경하거나 화면이나 파일에 데이터를 쓰거나, 다른 부작용이 있는 함수에서 데이터를 읽어오는 경우가 있다. 부작용은 프로그램의 동작을 이해하기 어렵게 한다.

🔷 소소한 수정도 배포가 너무 오래 걸릴 때

🔷 연계 시스템에 장애날 때 장애에 대한 종속을 끊고 싶을 때

하나의 시스템이 안될 때 다른 연계 시스템도 작동하지 않는다.

🔷 신규 기술을 적용하고 싶을 때

규모가 크다보니 버전 업그레이드도 연례 행사
라이브러리 버전 업그레이드도 어려운 상황인데, 기술을 바꾸는건 더욱 큰 일

🔷 기술 격차가 점점 벌어질 때

⭐ 마이크로서비스 특징

🔷 자율성

마이크로서비스 아키텍처의 각 구성 요소 서비스는 다른 서비스의 기능에 영향을 주지 않으면서 개발, 배포, 운영하고 확장할 수 있다.

🔷 전문성

각 서비스는 일련의 기능을 위해 설계되며 특정 문제를 해결하는 데 중점을 둔다.

🔷 기술적 특징

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

⭐ 마이크로서비스 아키텍처 철학

🔷 필연적으로 "한 가지 일을 하되 잘하라" (Do one thing and do it well)는 유닉스 철학과 상응한다.

서비스의 크기는 작다 (하나의 기능을 수행하는데 섬세하다.)
조직 문화는 테스트 및 전개의 자동화를 받아들여야 한다. 이를 통해 관리 및 운용성의 부담을 완화하며 다른 개발팀들이 코드의 전개 가능한 단위를 독립적으로 작업할 수 있게 한다.
문화와 디자인 철학은 안티프래질 시스템과 비슷하게 실패와 고장을 받아들여야 한다.
각 서비스를 유연하고 회복력 있고 구성할 수 있으며 최소한이고 완전하다.

⭐ 마이크로서비스 이점

🔷 민첩성

마이크로서비스는 해당 서비스를 소유한 독립적인 소규모 팀 조직을 육성하는 역할을 한다.
팀은 충분한 이해를 바탕으로 하는 소규모 컨텍스트 내에서 활동하며 더 독립적이면서 신속하게 업무를 수행할 수 있다. 덕분에 개발 주기 시간이 단축되고, 조직의 집계 처리량 측면에서 큰 이점을 누리게 된다.

🔷 유연한 확장성

마이크로서비스의 경우 각 서비스가 지원하는 애플리케이션 기능의 수요를 충족하도록 해당 서비스를 독립적으로 확장할 수 있다.
따라서 팀은 필요한 인프라의 규모를 적절히 조절하고, 기능의 비용을 정확하게 측정하고, 서비스의 수요가 급증하는 경우에도 가용성을 유지할 수 있다.

🔷 손쉬운 배포

마이크로서비스는 지속적 통합 및 지속적 전달을 통해 새로운 아이디어를 손쉽게 시험하고 문제가 발생할 경우 간단히 롤백할 수 있게 해준다.
이처럼 저렴한 실패 비용 덕분에 실험을 진행할 수 있어 더 쉽게 코드를 업데이트하고 새로운 기능의 출시 시간을 앞당길 수 있다.

🔷 기술적 자유

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

🔷 재사용 가능한 코드

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

🔷 복원성

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

🔷 배포 관점

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

🔷 확장 관점

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

🔷 장애 관점

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

🔷 코드 / 유지 보수 관점

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

💡 polyglot 프로그래밍
다양한 프로그래밍 언어들이 새롭게 등장하거나 재조명 받고 있는 시대다.
폴리그랏 프로그래밍은, 한 가지 언어가 아닌 다양한 언어를 사용하여 프로그래밍 한다라는 뜻을 가지고 있다. 러닝커브가 적고, 내가 좋아하는 언어로 개발한다는 것은 개발자에게 큰 즐거움일 것이다.

⭐ 마이크로서비스 단점

🔷 성능 관점

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

🔷 데이터 관리 관점

데이터가 여러 서비스로 분산되므로 한 번에 조회하기 어렵고, 데이터의 정합성 또한 관리하기 어려움

🔷 테스트 / 트랜잭션 관점

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

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

🔷 프로젝트 규모가 작은 경우, 모놀리틱 아키텍처로 사용하고 점차 발전할 수록 아래 기준으로 MSA 아키텍처로 전환하는 것이 좋다.

1. 비용
- 마이크로서비스를 적용할 때의 비용이 얼마나 합리적인가?
2. 개발 생산성
- 마이크로서비스를 적용해야할만큼 서비스의 양이 방대한가?
3. 운영 인프라
- 마이크로서비스가 동시 진행이 가능할만큼 인프라가 갖추어져 있는가?
4. 배포 주기
- 배포가 자주 이루어지는가?

❗ 전반적인 운영에서, 특히 신생 기업은 모놀리틱 아키텍처가 더 유리할 수 있다.

⭐ MSA 사례

🔷 쿠팡 (2013년까지 모놀리틱 아키텍처 적용)

모놀리틱 문제 발생(관심사 분리 실패, 확장성 부족, 비효율적인 서비스 배포 등)
해결을 위해 MSA 적용

🔷 카카오

카카오페이(각 서비스 별 DB 구성)
카카오 이모티콘(실무자의 회고)
- 서비스 배포가 어렵고, 코드 버전관리 복잡도가 높은데 서비스가 커지면서 수정이 어려운 모놀리틱 문제점이 발생
- MSA를 적용한 뒤 업무 역할 분담이 명확해지고, 배포의 부담이 많이 낮아졌으며, 신규 서비스 기능 추가가 쉬워졌다.
- 대신 설계 제약 사항과 고민들이 늘었으며, 개인이 담당할 서비스가 늘어났다. 결정적으로 서비스의 도메인 지식 공유가 힘들어졌다.