🏷 MSA 도입 조건
MSA의 도입 조건은 사업/조직적 측면과 기술적 측면 두 가지로 나누어 볼 수 있다.
조건 1. 사업 조직적 측면
-
MSA가 중장기적 Business benefit을 올릴 수 있다는 합의
➡️ 말 그대로 MSA의 도입이 중장기적 Business benefit을 올릴 수 있어야 한다.
MSA 도입 자체가 시간과 비용적으로 오래 걸리는 작업이기 때문에,
기업에 실질적 합의가 있지 않으면 조금 어려울 수 있다. -
고위 경영진의 강력한 Commitment 및 용기
➡️ 잘 동작하는 시스템을 건드리기 싫은 두려움도 있겠지만, 더 훌륭한 서비스를 만들기 위해서는 용기가 필요하다. -
MSA 도입은 단순 기술 도입이 아닌 조직과 프로세스의 개선 작업 필요
➡️ 조직과 프로세스의 개선 작업 없이 코드 레벨에서만 수정하는 것은 반쪽짜리 도입이다.
프로세스나 방법론의 개선 또한 필요한데, 조직의 구성이 해당 아키텍처에 반영되기 때문이다. -
DevOps 문화 정착되어야 함
➡️ DevOps와 MSA는 뗄 수 없는 관계로, 빼른 개발/빌드/배포를 위해 정착되어야 한다. -
사내 교육, 학습을 위한 자원 투자
➡️ MSA의 도입 과정에서는 여러가지 문제가 발생할 수 있기 때문에, 사내교육과 학습을 위한 자원 투자를 꾸준히 해야 한다.
조건 2. 기술적 측면
-
Rapid Provisigning
➡️ MSA의 장점을 극대화하기위해서는 Rapid Provisign 환경이 구축되어 있어야 한다. ex)클라우드 환경, 인프라 자동화 환경 -
정교한 모니터링 및 장애관리
➡️ 인스턴스 개수가 많아지고 서비스간의 커뮤니케이션도 복잡해지면, 문제가 발생했을때 바로 인지하고 파악하는것이 어려워 질 수 있다.
따라서 다양한 레벨의 모니터링과 모든 서비스에 대한 실시간 모니터링이 필요하다. -
자동화된 배포
➡️ MSA처럼 서비스가 많아지고 기술이 다변화되면 수동 배포가 힘들수있다.
End to end 배포 파이프라인을 구축해야 한다.
MSA를 언제 시작하는 것이 좋을까🤷🏻♀️?
Monolithic 기술의 단점들이 Business에 미치는 부정적인 영향이 클 때,
혹은 MSA로 얻을 수 있는 Business benefit이 MSA의 단점보다 크다고 판단 되었을 때 적용해야 한다.
이 때 MSA 도입 비용이 크다는 점을 인식해야 한다.
던져봐야 할 질문🤔
Q1. SW와 관련 된 현재 조직의 문제 및 목표는 무엇인가?
- 시스템에 아무 문제가 없는데 단지 신기술이 좋아서 도입한다는 것은 비효율적이다.
Q2. MSA가 조직의 문제 및 목표를 어떻게 해결해줄 수 있는가?
- MSA가 현재 가지고 있는 문제점을 정말 해결해줄 수 있는 시스템인지를 고려해야 한다.
Q3. 추가적인 리소스(비용/인력)를 투입할 수 있는 여력이 있는가?
Q4. 조직의 Engineering 역량이 MSA 도입할 만큼 충분한가?
어떻게 시작하는 것이 좋을까🤨?
처음부터 전부 MSA로 전환하려고 시도하는 것은 매우 위험하다!
가장 중요한 것은 작게 시작하는 것이다.
작게 시작한 뒤, 조직내에서 첫 성공을 경험하는 것이 중요하다.
분리하는 과정에서 경험을 쌓고 그 이후에 중요한 기능들을 서비스로 분리해야 한다.
어떤 부분부터 분리해야 할까🧐?
-
비즈니스 변화에 민첩하게 대응해야 하는 기능
-
요구사항이 변경이 빈번하여 빌드/배포를 자주 해야하는 기능
-
이벤트 때문에 주기적으로 트래픽이 몰려 빈번한 확장이 필요한 기능
-
처음에는 중요도가 낮고, 작은 모듈부터 분리
여기서 잠깐🤚🏻 MSA는 필수일까❓
이전 포스팅에서도 다뤘지만 정답은 당연히 NO!!!
많은 상황에서 Monolithic도 충분히 좋다.
"은탄환은 없다!" ➡️ MSA도 하나의 대안일 뿐 모든 문제를 해결해 주진 않는다.
Architecture Trade Offs
모든 SW 아키텍쳐에는 장/단점이 존재한다는 의미로, 마찬가지로 MSA와 Monolithic도 명확한 장/단점이 존재한다.
즉, Monolithic의 모든 장점을 그대로 살리면서 MSA를 도입하는 것은 불
가능하고, 모든 것을 다 만족시키는 Super Architecture는 없다는 것을 인지해야 한다.
결론
"Microservice are not the goal"
Microservice는 선택 가능한 대안이며, 그 자체가 목적이 아니다!.
Microservice를 통해 이루고자 하는 목적을 확실하게 이해하고 있어야 한다.
"MSA가 Netflix에서도 잘 맞았으니, 우리 시스템에도 좋겠지!" 라는 생각은 가장 위험한 생각이다.
🏷 MSA 역량 모델
MSA 역량 모델
마이크로 서비스는 현재도 발전 중이고 오래되지 않았기 때문에 표준 역량 모델이 없다.
벤더 사 및 도서 등에서 공개된 역량 모델은 본인들의 솔루션이기 때문에 표준이라 보기 어렵다.
MSA를 도입하고 운영하기 위해서는 어떤 영향들을 필요로 하는지 한눈에 알기쉽게 파악하기 위해 만든 것이 MSA 역량 모델이다.
필자는 Rajesh RV가 제안한 역량 모델 소개를 참고하여 글을 작성하였다.
MSA 역량 모델은 위와 같이 총 4가지로 분류된다.
- 핵심 역량(Core Capabilities)
- 지원 역량(Supporting Capabilities)
- 인프라스트럭쳐 역량(Infrastructure Capabilities)
- 프로세스 및 통제 역량(Process & Governance Capabilities)
역량 1. 핵심 역량
핵심 역량은 서비스 별 배포 되는 SW 패키지에 필수 요소로, 단일 서비스 내에 패키징되는 SW 컴포넌트들(서비스 리스너, 엔드포인트, 구현, 데이터저장)이다. (자동차로 따지면 엔진, 바퀴, 핸들 등)
1.서비스 Listener
- HTTP 등의 Listener가 애플리케이션에 내장되어 있어야 한다.
(Web Server, Web Application Server) - MSA의 민첩한 배포, 운영의 장점을 살리기 위해서는 자체 내장형 Listener가 필요하다.
2.서비스 Endpoint
- 역량이라 부르기에는 필수적인 요소이다.
- HTTP 요청을 받아 처리 할 API가 애플리케이션 내부에 있어야 하며, 다양한 프로토콜을 사용할 수 있다.
3.서비스 구현 부분
- 각 서비스의 핵심 로직의 구현한다.
- 서비스의 로직은 단일 책임 원칙으로 최대한 응집도 높게 구현되어야 한다.
- Hexagonal architecture를 만족시켜야 한다.
Hexagonal architecture 란❓
핵심 어플리케이션을 외부 기술과 분리시키는 패턴이다.
쉽게 말해서 비즈니스 핵심 로직이 외부 시스템에 영향을 받지 말아야 한다.
4.데이터 저장 부분
- 각 서비스마다 상태나 데이터를 저장할 데이터 소스가 존재해야 한다.
- 데이터 소스는 하나의 서비스에 한정되어야 한다.
➡️ MSA를 도입할 때 가장 장벽이 되는 부분 중 하나
➡️ 기존의 데이터 소스를 쪼개는 것은 상당히 어려운 일
역량 2. 인프라 스트럭쳐 역량
성공적인 MSA 구축 및 운영을 위해서는 인프라 역량이 필수적이다.
이러한 인프라 스트럭쳐 역량 안에는 클라우드/컨테이너 런타임/컨테이너 오케스트레이션 이 포함되어 있다.
1. 클라우드
클라우드를 이용하면 On demand 서비스 확장이 가능하다.
트래픽이 몰리는 상황에서 추가적인 서버 자원이 필요할 때마다 언제든지 사용이 가능하다.
또한 전통적인 방법에서의 복잡한 과정 없이 몇번의 클릭 만으로 리소스 사용이 가능하다.
➡️ 심지어 Auto Scaling 으로 자동화된 provising 이 가능함
컴퓨팅 자원, DB, NoSQL, Big Data, AI과 같은 다양한 자원과 서비스도 제공하고 있다.
2. 컨테이너 런타임
MSA에서는 각각의 서비스들이 다양한 기술을 사용할 수 있다.
이처럼 서비스 기술이 다양해지면 배포 방법이 또한 달라져야 한다.
이렇게 인스턴스 개수가 많아질 경우, 컨테이너 기술을 이용하면 빠른 환경 구성 및 배포가 가능해진다!
대표적인 기술로는 Docker가 있다.
3. 컨테이너 오케스트레이션
컨테이너 자체가 장점이 많다보니 다양한 곳에서 많이 사용되는데, 대규모 서비스에서는 많은 수의 컨테이너가 생기게 되고 이 많은 컨테이너를 관리할 수 있는 역량이 필요해진다.
컨테이너 오케스트레이션은 이를 배포, 모니터링, 운영관리 하는데 비용을 최소화 하기 위한 것이다.
대표적인 기술로는 Kubernetes가 있다.
역량 3. 지원 역량
"지원" 이라고 하지만, 절대 덜 중요한 것이 아니다.
지원 역량이 없다고 해서 MSA가 불가능하진 않지만, 이 환경을 제대로 운영하기 위해서는 지원 역량이 필수적이다.
1. Service Discovery
MSA를 도입하게 되면 서비스 개수 및 인스턴스 개수가 급증할 수 있고, 이렇게 되면 전체 토폴로지가 복잡해질 수 있다.
이는 한 서비스에서 다른 서비스를 호출했을 때 물리적인 정보를 유지하는 것을 비효율적으로 만들 수 있다.
Service Discovery 패턴을 사용하면 중앙의 에이전트가 시스템의 모든 서비스에 대한 정보를 유지하고 관리한다.
DNS 서버와 기존의 로드밸런스와 다른 점은, 자기 자신의 정보를 중앙 에이전트에게 자신의 정보를 등록한다는 것이다.
만약 IP가 바뀌거나 새로운 IP를 가지는 인스턴스가 생성돼도, 사람이 관리하지 않아도 자동으로 관리될 수 있다.
또한 물리적인 주소(IP, domain 주소)를 공유하지 않고, 서비스의 이름을 가지고 호출하기 때문에 인스턴스 및 서비스의 유연한 삭제와 추가가 가능해진다.
2. Config Server
기존에는 어플리케이션 설정 정보를 자체 파일이나 OS 환경 변수로 관리했다.
그러나 MSA를 도입하면 설정 관리가 복잡해진다. (개수 자체가 많아지기 때문에 관리가 어려워짐)
또한 환경에 따라 매번 새롭게 빌드/패키징 해야하는 문제가 생기고, 설정 파일이 잘못 관리되면 전체 서비스 장애 발생 가능성이 높아진다.
이러한 문제를 해결하기 위해 config server는 다음과 같은 기능을 제공한다.
- 설정 정보를 Application 파일에서 완전히 분리
- 중앙 Config Server에서 설정 관리(저장 Backend로는 Git, DBMS 사용)
- 서비스는 Application 기동 될 때 중앙 서버에서 Config 정보 Fetch
- 설정 정보 변경 시 서비스 재배포 없이 반영 가능
3. Service Gateway
Service Gateway는 다양한 서비스들에 대한 단일 진입점을 제공하는 것이다.
인증, 인가, 로깅, 필터링 등의 공통 기능을 처리한 뒤 뒷단의 서비스로 마운팅해준다.
만약 서비스에 문제 발생 시 요청을 차단하거나 대안 경로로 변경하는 등의 기능 또한 제공한다
4. SW Defined Load Balancer
MSA에서는 Monolithic보다 인프라 토폴로지가 매우 복잡하기 때문에 전통적 로드밸런서 사용은 비효율적일수 있다.
- 서비스/인스턴스의 개수가 많고 서비스 간 의존성 복잡함
- 인스턴스들의 제거, 생성이 매우 빈번하게 일어남
서비스를 호출하는 클라이언트에서 SW로 Load Balancing을 수행한다.
5. Circuit Breaker
서비스의 장애는 언제든 발생하고 따라서 장애 방지 설계는 필수적이다.
여기서 중요한 것은 MSA에서 한 서비스의 장애는 다른 서비스들에 전파되어 결국 전체 시스템 장애로 이어질 수 있기 때문에,
특정 서비스의 장애는 그 서비스만의 장애로 격리되어야 한다는 것이다.
Circuit Breaker는 서비스 간에 컴포넌트로 삽입되고, 만약 특정 서비스의 장애가 발생했다고 판단되면 이 Circuit이 차단된다.
6. Distributed Tracing
하나의 API 호출이 다양한 서비스에 분산되어 있기 때문에 에러가 발생했을 시 추적이 어렵다. (어떤 서비스에서 장애가 시작 되었는지 판단 어려움)
Distributed Tracing는 이를 해결하기 위한 방법으로 서비스 간 모든 호출에 추적 ID(긴 암호화 문자열)를 삽입한다.
하나의 API 트랜잭션은 동일한 추적 ID를 가진채로 수행되고, 추적 ID를 Key로 하여 단일 API 트랜잭션의 활동을 파악한다.
7. Data Lake
MSA의 문제는 데이터의 파편화 가능성이 존재한다는 것이다.
서비스별로 데이터 저장소도 다르고, 다른 기술을 사용하기 때문이다.
Data Lake는 비정형 원시 데이터를 가공하지 않고 그대로 저장한다.
데이터를 분석할 시점에 데이터 가공에 대해 고민하게 된다.
8. Messaging
MSA는 메시징을 이용한 서비스 간 협력 설계 방식을 권고하고있다. (즉 동기보다 비동기적 방식)
메시징 주도 설계는 서비스 간 결합도를 낮출수 있다.
이 메시징 기반의 방식을 구현하기 위해서는 고가용성의 메시징 솔루션이 필요하다.
역량 4. 프로세스 및 통제 역량
1. DevOps
애자일과 DevOps는 MSA 성공을 위한 필수 요소 중 하나이다.
앞서 말했듯 MSA 성공을 위해서는 기술적 요소 뿐만 아니라 조직에 대한, 방법론에 대한 고민도 같이 동반되어야 한다. ➡️ 애자일과 데브옵스에 대한 고민 필요
가장 중요한 건 DevOps 조직 구성하여 한 팀에서 개발, 배포, 운영, 모니터링이 되어야 한다는 것이다.
2. 자동화 도구
다수의 서비스를 테스트, 배포, 운영헤야 하기 때문에 자동화는 매우 중요한 역량이다.
자동화에는 대표적으로 테스트/배포/모니터링 및 경보 자동화가 있다.
3. 컨테이너 레지스트리
컨테이너의 핵심인 이미지에 대한 관리가 필요하다.
이 이미지를 관리하는 도구가 컨테이너 레지스트리이고 이는 코드 형상 관리와 유사하다.
주요 컨테이너 레지스트리로는 Docker Hub, GCR, ECR 등이 있다.
4. 문서화
문서화는 MSA 기술 때문이 아니어도 당연히 해야하는 일이다.
서비스들은 인터페이스를 통하여 통신하는데 이 인터페이스의 문서화가 되어있지 않으면 다른 서비스를 호출할 수 있는 방법을 알 수 없다.
5. 참조 아키텍처 및 라이브러리
탈중앙화 된 방식은 비효율성을 야기할 수 있다.
➡️ 서로 다른 아키텍처로 인한 유지 보수성이 악화될 수도 있고, 동일한 기능의 재개발이 있을 수도 있다.
이러한 문제를 완화하기 위해 조직의 기술 별 참조 모델이 중요해진다.
기술 자체는 자유도를 주되, 기술에 대해서는 특정 참조 아키텍처를 사용하라는 가이드를 줄 수 있다.
