해당 포스팅은 마이크로서비스 아키텍처(MSA 아키텍처)를 활용하여 커피 주문(가입, 주문, 상태) 시스템을 구축하는 프로젝트의 보고서의 서론 부분(MSA 아키텍처란 무엇인가)을 요약한 것 입니다.
본론에 해당하는 MSA 프로젝트 구축 글은 곧 업로드 예정입니다.
목차 :
1. IT 업계의 트렌드, MSA
2. MSA, 무엇인가?
3. MSA 적용사례
🚖 우버, MSA 아키텍처 VS 모놀로식
🍿 넷플릭스, 넷플릭스 OSS
1. IT 업계의 트렌드, MSA
넷플릭스가 서버를 1,000조각으로 쪼갠 이유, 왜 MSA?
"암스트롱."
프로젝트를 선정한 이유와 관련이 있는 단어입니다.
암스트롱(AMstrong)이란, ‘애플리케이션 현대화’ 프로젝트를 강하게(strong) 추진하자는 신조어인데요,
애플리케이션 현대화(Application modernization)는 기존 레거시 시스템을 현대 컴퓨터 프로그래밍 언어, 소프트웨어 라이브러리, 프로토콜 또는 하드웨어 플랫폼으로 변환 또는 이식하는 것을 말합니다.
이 애플리케이션 현대화를 위한 디자인 패턴은 위의 표와 같이 3가지가 있고, 해당 프로젝트에서는 마이크로서비스 아키텍처를 활용했습니다.
이 ‘암스트롱’의 핵심은, 기존 IT 시스템을 수천 수백 개로 쪼.개.는.것 입니다.
2. 'MSA' 란?
' Microservices Architecture '
기존 시스템은 간단한 업데이트를 위해 서버 전체를 멈춰야 하는 경우가 적지 않은 상황.
마치 손가락을 다쳐도 일단 전신 마취를 해야 하는 상황과 같은데,
애플리케이션 현대화는 이러한 상황에서 부분마취를 할 수 있게 해준다고 할 수 있습니다.
복잡한 시스템을 여러 개의 자율적인 조직으로 분화하여, 각종 업데이트 요구에 빠르게 부분마취로 대응할 수 있게 되는 것이죠.
그래서 이 MSA 아키텍처는 '암스트롱'의 핵심이자, IT 시스템을 수천 수백 개로 쪼개는 기술인 셈 입니다.
아주 작은 단위로 동작하는 서비스가 구동되도록, 시스템 및 소프트웨어의 구성과 구성요소 간의 관계를 정의한 아키텍처인 것이죠.
하나의 애플리케이션을 구성함에 있어, 분할된 다수의 서버 또는 컨테이너를 통해 애플리케이션 기능뿐만 아니라, 데이터까지 분리하여 격리 독립된 환경으로 구성되는 점이, MSA 아키텍처의 특징입니다.
그럼 MSA 아키텍처를 적용한 기업을 조금 알아보겠습니다. 첫번째 MSA 적용 사례는 기업 '우버(Uber)' 입니다.
3. MSA 적용사례, Uber(우버) 🚖
MSA 아키텍처 VS 모노리틱 아키텍쳐(Monolithic Architecture)
우버는, MSA 아키텍처 도입 이전에 '모노리틱 아키텍쳐' 기반의 서비스를 운영 중이었습니다.
잠시 이 모노리틱 아키텍쳐에 대해 보겠습니다.
모노리틱 아키텍쳐란, 기존의 전통적인 웹 시스템 개발 스타일로 하나의 애플리케이션 내에 모든 로직들이 들어 가 있는 '통짜 구조’라 할 수 있습니다. 예를 들어, 한 온라인 쇼핑몰 어플리케이션이 있을 때, 톰캣 서버의 WAR 파일(웹 애플리케이션 패키징 파일)내에 사용자 관리, 상품, 주문 관리 모든 컴포넌트들이 들어 있고, 이를 처리하는 UX 로직까지 하나로 포장돼서 들어가 있는 것이 이 모노리틱 구조입니다.
모노리틱 아키텍쳐도 처음엔 나쁘지 않다고 생각했습니다.
이 방식은 개발되어 있는 다 환경이 같으니 일단 테스트나, 같은 서버를 하나 더 만드는 등의 작업이 복잡하지 않다는 장점이 있긴 합니다.
그래서 당시 우버도 모노리틱 아키텍처로 만들졌습니다.
방금 말한 장점과 같이, 당시엔 이 구조가 하나의 코드베이스(예. git의 프로젝트 레포지토리)로 개발하는 것이 깔끔하다고 생각했고, 일단은 그 때 주요 비즈니스 이슈를 처리하는데 문제가 없었습니다.
하지만 우버는 곧 글로벌 서비스를 시작했고, 확장성과 지속적인 연동 문제에 직면하게 되었습니다.
다음은 당시 우버가 직면했던 몇 가지 중요한 난제입니다.
우버가 직면한 문제점에서 볼 수 있듯, 모놀리틱 구조의 단점은 다음과 같습니다.
그래서 이 문제를 해결하고자 우버는 기존 모노리틱 아키텍처에서 마이크로서비스 아키텍처로 이전하게 되었는데요.
도입 후, 가장 큰 변화는 운전자와 승객을 연결하는 API 게이트웨이의 등장입니다.
보시면 API 게이트웨이로 부터 각 기능들의 모든 내부 요청이 연결되어 있구요,
또 각각의 서비스는 독립적으로 분리되어 배포 가능하고 독립적으로 기능을 수행하게 되었습니다. 이렇게되면 요금청구 서비스에 변화가 있을 때, 딱 요금청구 서비스만 수정하여 배포하고, 다른 서비스는 배포할 필요가 없어집니다.
즉, 각각의 기능을 독립적으로 적용 및 확장할 수 있게 된 것입니다.
3. MSA 적용사례, 넷플릭스 🍿
그리고, 넷플릭스 OSS
두번째 적용사례로 넘어가보겠습니다.
두번째 사례는 우리에게 우버보다 친숙하고, MSA 아키텍처로 이미 유명한 기업인 넷플릭스 입니다.
Netflix는 2007년 심각한 데이터베이스 손상을 입고 3일간 서비스 장애를 겪은 후,
기존 Legacy 시스템은 MSA로 모두 전환하여 운영/개발 상의 효율성을 극대화 하였습니다.
전체 서버를 1000개 이상으로 쪼개는 작업을 통해 현재는 11.5초마다 새로운 요구사항을 반영하는 시스템을 구축하여, MSA 아키텍처로 전환 후 2007년부터 최근까지 월간 시청량은 1000배, 이용자는 10배 이상 늘었고,
2008년에 비해 스트리밍 서비스 이용 회원 수가 8배 증가했으며, 지난 8년간 전반적인 시청량이 천 배가량 증가했음에도 굉장히 안정적인 서비스를 제공하고 있습니다.
MSA 아키텍처를 도입하는 이 이전 과정에서 넷플릭스는
직접 경험한 노하우와 문제해결 방법을 공유하기 위해
MSA 전환 기술을 Netflix OSS(Open Source Software)라는 이름의
오픈소스로 공개하였고,
이것이 Spring Cloud 라는 클라우드 환경에 특화된 프레임워크이자,
Spring boot를 기반으로 MSA 구축에 특화된 라이브러리들의 집합과 만났습니다.
그래서 해당 프로젝트에서는 넷플릭스 오픈소스 중에서도 Spring Cloud 에 속해 있는 Spring Cloud Netflix를 사용할 예정입니다.
댓글