MSA에 대한 기본개념 - 1. Legacy에서 MSA로 진화하는 여정

AS-IS시스템의 Pain-Points는 다음의 것들이 있었다. 

• 서비스 업그레이드가 수시로 요청이 들어와 거의 매일 야근
• 테넌트별 다형성 지원을 제대로 하지 못하여 가입 고객이 늘 때마다 전체 관리 비용이 급수로 올라가는 한계에 봉착
• 운영팀과 개발팀이 분리되어 개발팀의 반영을 운영팀이 거부하는 사례 발생
• 개발팀은 새로운 요건을 개발 했으나 반영하면서 발생하는 오류가 두려워 배포를 꺼려함
• 현재 미국, 일본, 유럽 등 수요가 늘어나는 상황이나 상기한 문제로 신규 고객의 요구사항을 받아들이지 못하는 상황
• 수동 운영의 문제로 SLA 준수가 되지 못하여 고객 클레임이 높은 편
• 기존 모놀리식 아키텍처의 한계로 장기적인 발전의 한계에 봉착

모놀리식의 장점

상호 데이터 참조가 용이하여 개발 리소스를 최소화 시킬 수 있다. 

 

모놀리식의 단점

쉬운 상호연동은 의존성을 높여 기술부채를 증가시켜 어플리케이션의 변화민첩성이 떨어짐

 

글로벌 IT회사는 얼마나 자주 배포할까?

회사명	배포주기	배포지연시간	안정성	고객 요구 응답성
아마존	23,000/일	몇분	높음	높음
구글	5,500/일	몇분	높음	높음
넷플릭스	500/일	몇분	높음	높음
페이스북	1/일	몇시간	높음	높음
트위터	3/주	몇시간	높음	높음
일반회사	9개월 주기	수개월-수분기별	낮음/보통	낮음/보통

※ 출처 : 도서 The Phoenix Project

 

Agile의 정의

기존 개발 사업에 있어서는 "계획"이 중요했다. 그리고 "실패"는 허용되지 않았고 "비용" 중식적 사고가 우선시 되었다. 

하지만 이러한 사업방식은 위에서 보인바와 같은 Pain-Points를 유발시켰으며 다른 방법론이 필요하게 되는데 Agile 방법론이 대두되었다.

 

Agile 방법론은 "변화민첩성(Agility)"가 가장 중요한 덕목이다. 지속적인 성장을 지향하는 마인드셋이 필요하고, 고객중심적 사고가 가능하며, 실패에 대한 기술부채를 감소시키는데 초점을 두고 있다. 

 

Biz-DevOps의 정의

기존 DevOps사상은 IT개발과 IT운영조직을 연결성을 극대화 하려는 움직임이었다면 여기서 한발 더 나아가 DevOps 수명주기에 비즈니스 영역을 통합하는 개념이다. 비즈니스 전략에서 배포 및 유지관리에 이르기까지 효율적인 워크플로우를 만드는 것을 의미한다. 

 

다만 기존 DevOps는 IT Process의 효율성에 집중했다면, Business가 들어오면서 Business 성과에 집중합니다. 비즈니스목표를 달성하기 위한 아이디어가 실제 적용되기까지의 싸이클을 극단적으로 단축하고 지속배포를 통해 시장 반응에 따른 전략수정과 보완을 통해 목표달성에 다가가는 기민한 체계를 확보하는것이다.

 

 

개발방법론 뿐만아니라 아키텍처 영역에도 변화의 바람이 부는데 다음과 같다. 

구분	AS-IS	과도기	TO-BE
애플리케이션 생명주기	수개월 또는 수년	수개월 또는 몇주	몇주 또는 몇일
개발방법론	폭포수방법론	애자일	DevOps
어플리케이션 아키텍처	모노리스	N-티어	MSA
배포 및 패킹	물리적서버	가상서버	Container
인프라스트럭쳐 운영방식	직접운영	데이터센터	Cloud

 

Service-Oriented Architecture

서비스 인터페이스를 통한 소프트웨어 컴포넌트의 재사용을 가능하게 하는 방법을 정의한다. 이러한 인터페이스는 매번 깊은 통합을 수행하지 않고도 새 애플리케이션에 빠르게 통합될 수 있는 방식으로 공통 통신 표준을 활용한다. SOA의 각 서비스는 완벽한 개별적 비즈니스 기능(예: 고객 신용 확인, 월별 융자 상환액 계산 또는 모기지 신청 처리)의 실행에 필요한 코드와 데이터 통합을 구현한다. 서비스 인터페이스는 느슨한 결합을 제공하며 이는 아래에 구현되는 방법에 대한 지식이 거의 없거나 전혀 없이 호출될 수 있음을 의미한다. 서비스는 데이터 읽기 또는 변경 요청의 전송을 위해 SOAP(Simple Object Access Protocol)/HTTP 또는 JSON/HTTP 등의 표준 네트워크 프로토콜을 사용하여 노출된다. 서비스는 개발자가 신속하게 검색하여 새 애플리케이션을 구축하는 데 재사용할 수 있는 방식으로 공개된다.

 

 

그래서 제프베조스는 자신의 회사의 개발자에게 다음과 같은 지침을 메일로 날렸다. 

1. 모든 팀은 서비스화된 인터페이스로 기능과 데이터를 노출시킨다.
2. Team은 서로간에 인터페이스로 communication 해야한다.
3. 다음과 같은 그 어떠한 직접적 서비스간의 연동은 허용하지 않겠다.
- No direct linkning, No direct reads of another team's data store, No shared-memroy model, No back-doors whatsoever.
- 오직 네트워크 레이어상의 서비스 인터페이스로 communication할것
4. 팀은 인터페이스를 외부 개발자에게 노출할수 있도록 Plan과 Design을 해야한다. 

 

이러한 여정을 거쳐 지금의 MSA의 자양분이 되었다. 

 

Micro Service Architecture는 다음의 효과가 있다.

• Service 별로 분리된 Database /  Server → 독립적으로 기술 적용이 쉬움
• Service-Oriented Architecture → Loosely Coupled
• 자치성 향상 → 코드/데이터의 재사용성보다는 자치성을 높게 본다. 그래서 단일 실패지점이 없음. 국지적 Deploy와 테스트가 용이해짐
• 기능단위의 Fine-Grain → 기능단위의 Single Responsibility. 작은 코드로인해 리뷰가 쉬워 오류 및 버그가 최소화됨. 시스템 기동이 빠름

 

Loosly Coupled를 구현하는 기술적 방법

- HTTP/REST를 이용한 약결합 연동 → 빌드타임의 약결합일뿐 서비스간에는 강결합을 제공하는 아쉬움

• 클라이언트-서버 REST API는 내부 구현을 숨길수 있으면서 연동
• 동기식 연동
• SOAP에 비하여 REST는 API 정의 및 관리 비용이 낮으나, 각 클라이언트에 대한 요청에 충분한 API를 정의하고 관리하는 비용이 높아질 수 있음
• API는 하위호환성을 유지하기 위하여 추가적인 수정만을 허용

- 비동기 메시징처리를 통한 약결합 연동 → 런타임에서도 약결합을 제공함

• 상대의 수신을 기다리지 않는 비동기식 메시징
• Publish-Subscribe 구조의 API 통신방식
• "준" 실시간으로 동작함
• 데이터 Stream을 Message Queue 서비스 내로 숨길 수 있음

 

MSA로 가면서 받게 되는 Challenge

• 개발도구들을 어떻게 최적화 시킬것인가?
• 전체적인 테스트는 어떻게 하나? 복잡해보인다.
• 운영과 디플로이가 복잡해져 컨테이너/클라우드가 필수적이다.
• 서비스를 어떻게 쪼갤것인가?
• 서비스간 연동을 통해서만 구현할때 발생하는 비용의 상승
• 서비스 개수가 많아진 상황의 보안처리를 어떻게 할 것인가?