마이크로 서비스 아키텍쳐 (MSA)

마이크로 서비스 란

마이크로 서비스는 서비스 디자인스타일로써 작은 서비스의 결합을 토해 하나의 응용프로그램을 개발하는 방법으로 각각의 서비스는 독립적인 비즈니스 로직으로 구성되며, 완전 자동화된 개발/배포환경에 의해 각각 독립적으로 배포될 수 있다. 최소한의 중심적인 관리 체계가 있으며, 이 시스템은 각각 다른 프로그래밍 언어, 다른 데이터스토리지 기술로 작성하는 것이 가능하다.
마이크로 서비스를 나타내는 용어들
작은 빌딩 블록들, 높은 비결합성, 작은 작업을 수행, 모듈식의 접근, 디자인 스타일

기존 서비스와는 어떤 차이가 있는가

Monolitics vs. SOA vs. MSA

Monolithic: 전체 큰 하나의 입자에서 비즈니스 로직이 돌아가고 그에 포함되어 있는 컴포넌트들이 하나의 패키지로 서비스되는 형태
SOA: 세련된 컴포넌트들을 나눠가지고 그들간의 미들웨어로 둠으로써 (대부분 엔터프라이즈 서비스) 서로 의사소통해서 진행하는 것
Microservices: 각각의 컴포넌트들이 작은 단위로 서비스화 되어서 배포가 되고 다른 서비스들과 연결되어 서비스를 진행함. 내부에 있는 기능, 데이터 등을 외부에서 바로 접근하는 것을 막는다. 대신 API를 공개해놓고 이 API를 통해서만 접근할 수 있도록 함
=> SOA보다는 Microservices가 더 작은 단위다.

Monolitic 아키텍쳐

Monolitic 아키텍쳐(왼쪽)와 확장할 경우(오른쪽)

위의 이미지에서 볼 수 있듯이 Order UI, User UI 등 기능들이 구분이 되어 있지만 결국엔 하나의 데이터로 패키지화 되어 서비스 된다. EC2를 사용하게 될 경우 하나의 EC2안에 왼쪽의 이미지의 내용이 다 올라가게 된다. 확장을 하는 경우는 CPU, 네트워크 등에 맞춰 인스턴스를 추가하여 모든 것을 한 곳에 올려둔다.

마이크로 서비스

마이크로 서비스(왼쪽)와 확장할 경우(오른쪽)

하나의 기능들이 하나의 서비스이며 이 서비스들은 하나의 패키지의 하나의 인스턴스로 올라가게 된다. 확장시에 필요한 서비스 기준으로 독립적으로 확장되기 때문에 리소스를 효율적으로 사용할 수 있다.

Monolitic 아키텍쳐에서 발견할 수 있는 것들

- 복잡한 코드와 관리의 어려움: 하나의 패키지에 모든 컴포넌트들을 포함 (예, IDE를 쓸 때 프로젝트를 로드하는데 시간이 오래걸림, 컴파일 할 때의 시간)
- BottleNeck이 될 수 있는 배포: Dev테스트, 종속성, Staging 배포, Q&A, Production 배포
- 변경의 두려움: 비지니스 새로운 요구사항을 해결하는 새로운 프레임워크, 서비스 등장
- 부족한 주인의식: 그거 할 시간 없어요. 그런건 QA가 해야죠.
- 연쇄 실패: 하나의 실패 => 시스템 전체 에러
- 확장의 어려움: 기능 추가는 다양한 부서의 의사소통이 필요. => 늦어지는 업데이트

마이크로 서비스에서 얻을 수 있는 것들

- 서로 다른 서비스들은 서로 다른 언어들로 개발이 가능.
- 쉬운 integration 과 automatic deplyment
- 쉽게 이해하고 수정가능한 코드들 => 새로운 팀원의 생산성 향상
- 최근 기술을 비교적 쉽게 도입
- 빠른 서비스 시작 속도와 빠른 배포
- 기능 추가시 해당 서비스만 수정 및 배포 할 수 있음

마이크로 서비스의 오해

+ Dropwizrd, SpringBoot는 rest API를 만들기 위한 프레임워크들...

Conway의 법칙: 소프트웨어 아키텍쳐는 조직의 구조를 그대로 반영한다.

SQL DB 개발자, Javascript/CSS 개발자, C# 개발자가 있으면 전형적인 3-tier 시스템이 될 경향이 높다.
=> 만약 서비스가
데이터 저장은 파일로 충분, 상호작용은 CLI로 충분
하지만 왼쪽의 세 개발자가 모이면 3-tier가 될 가능성이 높다.

아키텍쳐 ~ 팀 조직

어떤 팀조직이 필요한가
SuperCell: CoC의 회사. 
"작게 생각해서 큰 걸 얻자" 팀의 규모가 작을 수록 매우 빠르게 프로젝트를 만들어 낼 수 있다.
선호 팀 크기
아마존: 6~8명/팀
Navy SEAL(네이비 씰): 4명/유닛

커뮤니케이셔 링크

Jeff Bezos(아마존닷컴 CEO): "커뮤니케이션은 좋지 않다. 커뮤니케이션이 늘어날 수록 문제 발생이 높고 실제 프로젝트의 효율성이 떨어진다."