성공한 인터넷 기업들과 비즈니스 민첩성
아마존, 넷플릭스, 우버와 같은 기업들이 성공할 수 있었던 이유는 민첩성이라고 생각한다
비즈니스 민첩성은 어떻게 나타날까?
성공 사례 : 아마존의 배포 속도
먼저 아마존의 성공 사례를 살펴보자
아마존의 서비스 배포 주기는 11.6초라고 한다
비즈니스는 꾸준히 변경되므로 이에 따라 개선된 시스템도 계속 배포해야 한다
빠른 배포 주기는 비즈니스 민첩성을 간접적으로 보여주는 지표다
다른 예로 국내 한 쇼핑몰 시스템 배포 주기는 1주일이다
아마존 쇼핑몰은 전체 과정이 독립적으로 완료되어 초당 1.5번씩 변경, 개선되고 있다
긴급 배포를 포함하면 1주일에 3일정도로 생각할 수 있다
아마존과 비교하면 아마존 서비스는 0.66초마다 진화하고, 국내 쇼핑몰은 3일마다 진화하는 셈이다
(초당 1.5번이면 0.66초에 1번이다)
아마존은 어떻게 이런 속도를 가지게 됐을까?
시스템과 어플리케이션 측면에서 살펴보자
클라우드 인프라의 등장
이제 개발에 필요한 인프라를 준비하는 데 오랜 시간이 들지 않는다
클라우드 플랫폼 벤더를 선택해 손쉽게 시스템 인프라를 마련할 수 있다
ex) 아마존 웹서비스, 마이크로소프트사의 애저, 구글의 구글 클라우드 플랫폼
클라우드 인프라에 어울리는 애플리케이션의 조건
클라우드 인프라는 사용량에 따라 유연하게 조정할 수 있다
애플리케이션 구조도 이러한 형태로 만들면 효율성을 극대화할 수 있다
모듈에 따라 스케일 업과 스케일 아웃을 조절할 수 있다
스케일 업(Scale-up) : 성능을 높여 처리를 증가 (수직 확장)
스케일 아웃(Scale-out) : 성능이 비슷한 장비를 병행 추가하여 사용량을 분산 (수평 확장)
예를 들어,
로그를 쌓는 서버에서 용량이 부족해서 용량을 증설한다면 스케일 업이다
실시간 트래픽을 받고 있는 서버에서 트래픽이 계속 증가하여 부하가 간다면 스케일 아웃을 통해 사용량을 분산한다
이벤트 서버만 따로 배포가 필요하다면 이벤트 서버 모듈만 배포한다
이렇게 애플리케이션 구조가 조각으로 분리돼 있으면 서버마다 스케일 아웃, 스케일 업, 배포 등을 자유롭게 할 수 있다
이렇게 아마존은 빠르게 배포한다
클라우드 프렌들리 애플리케이션 (Cloud Friendly Application)
→ 큰 덩어리로 클라우드 환경에 올라갈 수 있게 한 애플리케이션
클라우드 네이티브 애플리케이션 (Cloud Native Application)
→ 독립적으로 분리되어 배포될 수 있는 조각으로 구성된 애플리케이션
클라우드 프렌들리 → 클라우드 네이티브 애플리케이션으로 가야한다
마이크로서비스란 무엇인가?
모노리스와 마이크로서비스 비교
전통적인 시스템 모노리스(monolith)는 하나의 단위로 개발되는 일체식 애플리케이션이다
적은 범위의 수정에도 전체 빌드를 해서 배포해야 한다
일부 서비스만 스케일 업/아웃이 불가능할 수 없다
데이터베이스는 통합되어 하나이므로 탄력적으로 대응할 수 없다
반면, 마이크로서비스는 서버 측이 여러 개의 조각으로 구성돼 각 서비스가 별개의 인스턴스로 로딩된다
모두 모아두면 하나의 서비스가 된다
업무 단위로 모듈 경계가 명확히 구분된다
일부 필요한 서비스만 스케일 업/아웃이 가능하다
변경이 있다면 해당 서비스만 빌드해서 배포할 수 있다
서비스가 독립적이어서 서로 다른 언어로 개발할 수 있다
SOA와 마이크로서비스
모듈화 개념의 발전 흐름 : 구조적 방법론 → 객체지향 방법론 → CBD(Component Based Development) → SOA(Service Oriented Architecture)
(CBD : 모듈화의 단위가 기능별로 재사용할 수 있는 좀 더 큰 컴포넌트로 모듈화)
(SOA : 컴포넌트를 모아 비즈니스적으로 의미 있고 완결적인 서비스 단위로 모듈화)
CBD와 SOA도 넓게 보면 단위 컴포넌트나 서비스를 구성해서 시스템을 만드는 개념이다
즉, 마이크로서비스 시스템 구조와 매우 유사하다
마이크로서비스 아키텍처(MSA)는 마이크로서비스 기반으로 시스템을 개발하는 방식이다
SOA와 MSA는 개념적으로 큰 차이는 없다
SOA는 구체적이지 않고 이론적이며, 실제 비즈니스 성공 사례가 많지 않았다
반면, MSA는 클라우드 인프라 기술의 발전과 접목되어 아마존, 넷플릭스 등 구체적인 비즈니스 성공 사례가 공유되었다
마이크로서비스는 여러 개의 작은 서비스 집합으로 개발하는 접근 방식이다 각 서비스는 개별 프로세스에서 실행되고, HTTP 자원 API와 같은 가벼운 수단을 사용해서 통신한다 또한 서비스는 비즈니스 기능 단위로 구성된다 자동화된 배포 방식을 이용하여 독립적으로 배포된다
특정 서비스를 구축하는 데 사용되는 언어나 저장소를 자율적으로 선택할 수 있는 방식을 '폴리글랏(Polyglot) 하다' 라고 표현한다
CBD/SOA의 접근법에서는 애플리케이션은 모듈별로 분리했으나 데이터 저장소까지는 분리하지 못했다
하지만 MSA에서는 데이터 저장소까지 독립적으로 분리했다
마이크로서비스를 위한 조건은 무엇인가?
MSA는 CBD, SOA처럼 기술에만 의존한 아키텍처 스타일을 추구하는데 그치지 않는다
MSA는 개발 환경, 문화, 일하는 방식과도 연계돼 있다
조직의 변화: 업무 기능 중심 팀
마이크로서비스를 만드는 팀은 업무 기능 중심의 팀이어야 한다
다양한 역할로 구성되고, 서비스를 처음부터 끝까지 만들기 위한 모든 단계의 역할을 갖추고 있어야 한다
이 팀은 서비스 개발과 이후에 운영할 책임까지 진다
이런 팀은 마이크로서비스를 만드는 데 필요한 기능과 기술을 팀 내부에 모두 가지고 있으므로 다른 마이크로서비스팀과는 협력할 일이 적다
관리체계의 변화 : 자율적인 분권 거버넌스, 폴리글랏
"우리가 만들고 우리가 직접 운영한다"
마이크로서비스팀으로 구성된 조직은 중앙의 강력한 표준이나 절차 준수를 강요하지 않는다
빠르게 서비스를 만드는 것을 최우선 목적으로 두고 스스로 효율적인 방법론과 도구, 기술을 찾아 적용한다
개발 생명주기의 변화 : 프로젝트가 아니라 제품 중심으로
마이크로서비스팀은 갑작스런 트렌드 변화에 유연하게 대처해야 하고 개발뿐만 아니라 운영을 포함한 소프트웨어 전체 생명주기를 책임져야 한다
제품을 바라보고, 우선 개발한 뒤에 반응을 보고 개선하는 방식으로 소프트웨어 개발을 한다
즉, 소프트웨어 개발하는 방식 측면에서 프로젝트 형태의 폭포수 모델이나 빅뱅 방식이 아닌, 점진 반복적인 모델, 제품 중심의 애자일 개발 방식을 채용한다
이 같은 방식으로 2~3주 단위의 스프린트를 통해 소프트웨어를 개발 및 배포해서 바로 피드백 받아 반영할 수 있게 해준다
지속적으로 개선되고 발전시킬 제품으로 바라본다
즉, 마이크로서비스는 계속 피드백을 받아 지속적으로 변화, 개선되고 향상되는 존재다
개발 환경의 변화 : 인프라 자동화
마이크로서비스는 독립적으로 배포된다
마이크로서비스처럼 여러 개로 쪼개진 상태에서는 수동으로 배포하는 방식은 바람직하지 않다
마이크로서비스팀이 단기간에 개발하고 피드백 받기 위해서는 이런 개발지원 환경의 자동화가 반드시 갖춰져야 한다
빌드/배포 파이프라인 프로세스는 도구를 통해 자동화해야 한다
(빌드/배포 파이프라인은 보통 '소스코드 빌드 → 개발 환경 배포 → 스테이징 환경 배포 → 운영 환경 배포'로 구성된다)
최근 배포 환경 마이크로서비스 개수가 급격히 늘어남에 따라 효율적으로 관리하기 위해 인프라 구성과 자동화를 마치 소프트웨어처럼 처리한다
이런 방식을 'Infrastructure as Code'라고 한다
즉, 코드를 이용해 인프라 구성부터 애플리케이션 빌드, 배포를 정의하는 것을 의미한다
저장소의 변화 : 통합 저장소가 아닌 분권 데이터 관리
마이크로서비스는 폴리글랏 저장소 접근법을 선택한다
서비스별로 데이터베이스를 갖도록 설계한다
각 저장소는 서비스별로 분산돼 있어야 하며, 다른 서비스의 저장소를 직접 호출할 수 없고 API를 통해서만 접근해야 한다
마이크로서비스는 데이터 일관성 문제를 해결하기 위해 두 서비스를 단일 트랜잭션으로 묶지 않고 비동기 이벤트 처리를 통한 협업을 강조한다
각 트랜잭션을 분리하고 큐 메커니즘을 이용해 보상 트랜잭션을 활용한다
위기 대응 방식의 변화 : 실패를 고려한 설계
내결함성 : 시스템은 언제든 실패할 수 있고, 실패해서 더는 진행할 수 없을 때도 자연스럽게 대응할 수 있도록 설계해야 한다
실패하지 않는 시스템을 만드는 것보다 실패에 빠르게 대응할 수 있는 시스템을 만드는 편이 더 쉽고 효율적이다
이를 위해 다양한 실패에 대비해서 완벽히 테스트할 수 있는 환경을 마련해야 하고, 실패를 감지하고 대응하기 위해 실시간 모니터링 체계도 갖춰야 한다
MSA의 성공을 위해서는 아키텍처 및 개인 역량에만 집중할 것이 아니라 조직 문화, 일하는 절차 등을 고려해야 한다
이 글은 "도메인 주도 설계로 시작하는 마이크로서비스 개발" 책 내용을 요약한 글입니다
자세한 내용은 "도메인 주도 설계로 시작하는 마이크로서비스 개발" 책을 통해 학습하실 수 있습니다
해당 내용이 저작권 관련 문제가 있다면 바로 삭제하겠습니다
댓글