[MSA] Cloud Native Architecture - (1)
시작에 앞서
이 포스트는 Dowon lee님의 인프런 강의 "Spring Cloud로 개발하는 마이크로서비스 애플리케이션" 의 내용을 정리한다.
(링크는 이곳을 참고)
도데체 개발자들이 말하는 MSA는 무엇인지, 기존의 필자가 진행했던 프로젝트의 구조와 어떤 점에서 다른지에 대한 고찰을 누추한 블로그에 방문해주신 귀한 여러분들과 함께 나누고자 한다.
Antifragile
쉽게 손상을 입을 수 있는 ‘프래질’이라는 단어의 반대 의미로 충격을 받으면 더 강해지는 특징을 뜻한다.
2010년대로 들어서며 Software Architecture(쉽게 말해서 소프트웨어를 만드는 구조)의 형태가 해당 방식을 지향한다고 한다. (맞으면서 강해지는 건가..)
4 가지의 핵심을 살펴보자.
- Auto Scaling : 사용량에 따라 자동으로 인스턴스를 증가, 감소할 수 있음
- MicroServices : 전체 서비스를 구축하고 있는 개별적인 모듈을 독립적으로 개발하고 배포하는 것
- Chaos engineering : 시스템이 예측하지 못한 상황이어도 견딜 수 있게 만든 규칙
- Continuous deployments : 지속적인 배포, 통합 (ex. CI / CD)
이러한 핵심들은 MSA구조를 알아가며 반복적으로 접하게 될테니 이런 개념이 있다는 느낌만 알고 일단 지나가도록 하자.
Cloud Native Architecture
요즘은 어딜 가도 클라우드에 대한 이야기를 빼놓을 수가 없다.
기존에는 회사에서 자사 내에 서버실을 두어 직접 관리했다. 만약 사업이 확장되어 서버를 증설해야 한다면?
무한정으로 서버실을 늘릴 순 없는 노릇이다. 이러한 단점을 극복하고자 클라우드라는 가상 공간에서 서버를 관리하기 시작한 것이다.
이러한 클라우드 기반의 구조는 다음과 같은 3가지의 특징이 있다.
- 확장 가능한 아키텍처
- 서버를 계속 설치하는 것이 아닌, 클라우드 내에서 서버 인스턴스를 여러 개 늘리는 방식으로 확장 가능하다.
- 이러한 방식을 Scaling이라고 하며 scale up은 하드웨어의 스펙을 높이는 일 (메모리 카드를 새로 산다던지..)
scale out은 인스턴스를 여러 개 늘리는 것을 뜻한다. (아마존의 서버 인스턴스를 여러개 산다던지..)
- 탄력적 아키텍처
- 기존에는 코드에 변경 사항이 있으면 개발자가 수동으로 프로젝트 build후 배포를 해야 했다. (필자도 마찬가지)
허나 클라우드 기반의 구조에서는 CI / CD를 통해 자동 빌드, 배포로 이러한 시간을 단축한다.
(CI / CD 에 대한 설명은 바로 나오니 일단 자동으로 빌드, 배포가 이루어지는 방식이라고 알면 된다.)
- 기존에는 코드에 변경 사항이 있으면 개발자가 수동으로 프로젝트 build후 배포를 해야 했다. (필자도 마찬가지)
- 장애 격리
- 특정 서비스에 오류가 발생해도 다른 서비스에 영향을 주지 않음
Cloud Native Application
이름은 거창해 보이지만 위에서 언급한 클라우드 네이티브한 구조로 설계한 어플리케이션을 의미한다.
즉 클라우드의 이점을 최대로 활용할 수 있도록 구축한 어플리케이션을 의미한다.
바로 윗부분에서 다룬 내용들이 '클라우드의 이점'이라고 볼 수 있겠다.
그림을 통해 좀 더 직관적으로 살펴보자.
4가지 항목을 좀 더 자세히 들여다보겠다.
- Microservices
- 각각의 서비스들이 독립적인 단위로 나눠져 있는 구조
- 홈쇼핑 웹서비스를 설계하는 경우 [장바구니] [구매] [마이페이지] 등의 여러 서비스들로 구성되어 있을 것이다. 이전에 방식으로는 모든 서비스를 하나로 묶어 어플리케이션을 구성했으나 Microservices의 경우 각각의 서비스가 독립적으로 존재하여 각각 서로의 영향을 받지 않고 패키징 되어 있어 전체적 시스템에 영향을 주지 않는다.
- msa방식이 아니라면, 장바구니의 코드 내용을 변경할 때 전체 프로젝트를 실행하여 코드를 수정한 후 다시 올려야 하지만, msa방식의 경우 장바구니 service에 대한 부분만 따로 관리하면 된다! 와! 신기하다!
- CI/CD
- 앞서 말한 대로 '빌드'와 '배포'를 자동화 해주는 녀석이라고 생각하면 쉽다.
- 지속적인 통합 (CI : Continuous Integration)
- 소스 관리(형상관리), 빌드, 테스트를 모두 포함한다.
- 자주 사용하는 도구로는 젠킨스, Team CI, Travic CI등이 있다.
- 지속적인 배포 (CD : Continuous Delivery & Deployment)
- 지속적인 전달 과 지속적인 배포로 나눠져있다.
- 지속적인 전달의 경우 빌드는 자동이지만 배포를 수동으로 반영한다.
- 지속적인 배포의 경우 프로젝트 빌드부터 배포까지 모두 자동 반영된다.
3. DevOps
- 개발 조직과 운영 조직의 통합을 의미한다.
- 이전에는 개발과 운영이 분리되어 개발자가 구동할 프로그램 준비를 끝나면, 이후 배포와 운영 작업은 다른 조직이 했다. 만약 우리가 단 몇줄의 코드를 바꿔야 할지라도 바꾼 후에 운영 조직과 다시 소통하여 배포해야 하므로 매우 번거로운 일이 아닐 수 없다..
- 이를 극복하기 위해 나온 개념으로 서비스의 문제가 생기면 바로 수정해서 즉시 배포하는 과정을 반복하는 것을 목적으로 한다.
4. Container 가상화 기술
- 아래의 그림과 같이 기존에는 서로 다른 OS환경을 위해 가상머신을 사용했었다.
- 이는 새로운 OS를 올려야 하므로 비용적이나 여러 측면에서 부담이 많았다.
- 이후 도커라는 컨테이너 가상화 기술을 도입하여 각각의 서비스와 앱을 관리하게 되었다.
도커 및 컨테이너에 대한 개념은 짧게 다루기엔 무리가 있어서 따로 게시글을 정리할 예정이다.
컨테이너 및 도커는 개발자에게 있어서 아~~주 중요한 개념이니 여러분들도 꼭! 알아두고 넘어갔으면 하는 바램이다.
(나나 잘하자..)
무튼 위 4가지 항목이 Cloud Native Application의 특징이나 핵심이라고 할 수 있다.
간단하게 정리해보자면
- 각각의 서비스들이 서로 독립적으로 배포, 실행된다 (ex. 장바구니 <-> 주문 서비스가 서로 독립적으로 존재함)
- 프로젝트 소스에 대한 build 및 배포가 다양한 도구를 통해 자동으로 진행된다.
- 개발과 운영 조직을 통합하여 코드 수정(개발 업무) 시 즉각적으로 배포(운영 업무)하는 구조를 가지고 있다.
- 모든 서비스는 '컨테이너'라는 개념을 통해 가상화하여 앱과 앱 구동환경을 서로 분리한다.
아직도 Microservice와 MSA(MicroService Architecture)에 대해 뭔지 감이 안잡히는가?
어쩌면 당연하다. 필자도 한 두번으로는 개념 자체가 제대로 와닿지 않았다.
다음 게시글은 MSA구조와 이전에 우리가 사용하던 방식을(Monolithic) 비교하는 내용을 통해 MSA에 대한 개념을 좀 더 자세히 다룰 예정이다.
넷플릭스, 아마존 등 세계를 선도하는 IT기업들이 왜 이러한 구조를 선택했는지, 발빠른 IT시장에서 MSA라는 트랜드에 대해 무엇인지 따라갈 수 있도록 힘써보도록 하겠다..!
참고