Ashburton Grove

Cloud Native :  클라우드의 주요 특징과 장점을 극대화하는 방법론들의 총칭을 의미함.
(CI/CD, DevOps, Microservices, Container 개념들이 유기적으로 돌아가는 서비스를 제공하는 것)

전통적 IT 구조의 조직은 cloud native 적용에 다양한 커스터마이징이 필요.
IT 서비스 의존성이 높은 기업(스타트업 등)은 자연적으로 cloud native 하게 갖춰져 가는 경우가 많다.

1. MSA

 작은 서비스 여러개를 엮어 활용하는 구조

2. Container

 서비스가 인프라 레벨로 들어간 것. 가상화 기술 영역 중 가장 경량화된 최신 기술.

 가장 가볍고 빠르게 활용이 가능한 가상화 기술을 의미한다.

  MSA 구조를 사용하기 위해 최종적으로 고려되는 가상화 기술.

위 그림과 같이 운영체제(OS)위에 컨테이너 관리 SW가 존재한다.

컨테이너 관리 SW를 쓰게되면 사용자는 사용되는 클라우드가 Public, Private 인지 신경쓰지 않아도 되는 장점이 있다.

Hybrid cloud를 구성할 떄, 컨테이너 관리 SW(플랫폼)이 있으면 MSA가 Public과 Private을 마음대로 사용 가능하기에 
장기적인 관점에서 cloud native하다는 것은 컨테이너를 사용하는 것이라 보면 된다.

-> Multi/Hybrid cloud 사용자 관점에서는 어느 클라우드 환경의 자원을 쓰는지 상관없이(Public / Private), 동일한 인터페이스로 서비스를 활용 가능함. 컨테이너 개념을 통해 장기적으로는 클라우드의 대세는 Multi /Hybrid cloud로 나아갈 것.

3. DevOps (Development + Operation)

개발과 운영이 유기적으로 하나로 돌아가는 현상을 의미한다.
지속적인 개발, 운영, 피드백 반영, 적용을 위해 개발팀과 운영팀을 하나로 합치는 개념. 

DevOps는 아래와 같은 특징들을 가지고 있다.
1) 지속적으로 피드백을 바로 반용해서 새로 개발에 반영하도록 함
2) 조직 입장에 대응력을 높이며 신기능 추가 및 개선을 할 수 있는 환경 가능

4. CI/CD (Continuous Integration / Continuous Deployment)

지속적인 통합과 배포 

현업에서 요청한 서비스를 각 팀, 부서 별로 개발하다보면 통합(integration)의 필요성이 증대되는 경우가 많다.
여기서, 통합이란 API로 통신하면서 서비스가 유기적으로 돌아갈 수 있도록 프로토콜을 맞추는 작업을 의미함.

이러한 통합 과정을 원활하게 수행하기 위해서 활용되는 DevOps와 CI/CD는 개선사항을 빠르게 반영하고 다시 운영에 들어갈 수 있도록 한다. (비즈니스 요구사항을 맞춰주는 개발 속도와 대응력을 높임)

MicroService Architecture를 설명하기 위해서는 Monolithic Architecture의 개념에 대해 이해가 필요하다.

1. Monolithic Architecture

cloud 등장 이전, 전통적인 IT 환경에서 쓰이는 아키텍처는 Monolithic Architecture라 칭함.
일반적으로 대규모 프로젝트(3~5년 이상의)는 완전무결한 구조로 가고자 하는 니즈가 많다.

완전무결한 구조를 위해 cloud 이전 IT 프로젝트에서는 단일구조 형식을 선호하게 되었음.

* Monolithic Architecture의 특징
1) 단일화된 통합 데이터베이스를 사용
2) 서비스를 이루고 있는 전체 기능을 단 하나의 코드베이스로 개발(일원화된 코드 체계)

* Monolithic Architecture의 단점
1) 기술이 끊임없이 바뀌는 환경에서 기존 framework에 의존성이 생기며, 잠재적인 이슈가 발생할 가능성이 커짐.
2) 기능이 많아지고 규모가 커져 복잡해질수록 지속적인 통합/배포(CI/CD) 및 유지보수가 어렵다.
3) SPOF(Single Point of Failure, 한 가지 기능 장애 발생 시 전체 서비스 장애 및 사용불가)가 발생

4) 빠르게 변하는 트렌드를 따라잡기 어렵다. (서비스 수정 시, 배포등을 위해 전체 재기동 등의 이슈가 발생할 가능성이 높음)

-> 위 단점을 해결하고자 전용망과 고가의 HW 구입, 안정적인 유지보수를 제공하는 기업용 SW를 통해 서비스를 개발함
(장애 가능성을 원천적으로 최소화하기 위한 노력)

위와 같은 Monolitic 구조를 어떻게 보완할지에 대한 대응 방안이 바로 MSA

2. MSA(Mirco Service Architecture)

MSA는 기존 IT 체계에서 사용하던 Monolithic Architecture의 단점을 보완하기 위하여 등장하였다.
아마존, 넷플릭스와 같이 cloud 환경을 성공적으로 활용하는 회사들이 공통적으로 도입하고 있는 아키텍처.
서비스들이 다중 복합적으로 구성되어서 사용자에게 하나의 서비스 화면을 만들어주는 형태의 구조.

(아래 아마존 홈페이지 캡처본에서 붉은 테두리로 표기된 각각의 항목이 하나의 서비스) 

각 서비스들은 API를 통해 데이터를 송수신하며, 분업을 극대화시킨 구조이다,

Monolithic Architecture과 MicroService Architecture를 그림으로 비교하면 아래와 같다.

파란원으로 표기된 Business Logic는 서비스와 동일한 개념이다.

* MSA의 구성원칙
1) 단일 책임의 원칙(Single Responsibility) : 각 서비스는 하나의 책임만 가짐.
2) 독립적인 배포(Independently Deployable) : 각 서비스를 독립적으로 배포할 수 있음.
3) 느슨한 결합(Loosely Coupled) : 각 서비스 간 의존성을 최소화함. (서비스 간의 통신은 API를 통해서 진행)
4) 높은 유지성, 테스트 가능성(Highly Maintainable and Testable) : 분리된 서비스별 관리 및 유지가 편하고 테스트도 독립적으로 가능함. (각각 서비스는 변경도 되고 끊임없이 바뀌지만 별도의 다운타임 없이 사용자에게  서비스를 제공해 주는 구성이 가능함.)
5) 팀 단위 구성이 가능(Owned by a Small Team) : 서비스 단위로 팀 구성을 하여 개발/운영이 가능. (DevOps와 이어짐)

* MSA의 장점
1) 서비스별 독립적인 배포가 가능함.
2) 스케일링(Scailing, 특정 서비스 부하로 스케일링이 필요할 경우 해당 서비스만 확장) 가능
3) 장애 대응 용이(전체 서비스 제공에 미치는 영향을 최소화)

-> 일부 서비스에 이슈가 발생할 경우, 이슈가 발생한 서비스만 내리고 나머지 서비스는 제공하므로서, 사용자 입장에서는 이슈가 있었는지도 모를 정도로 유연하게 대응이 가능함.
4) 다중언어(Polyglot, 각 서비스마다 다양한 언어/환경 구성 가능) 지원 -> 신기술 적용이 용이

* MSA의 단점

1) 유지보수가 어려움 

(여러 서비스가 합쳐진 통합테스트를 진행하게 될 경우, 통합된 시스템이 아니므로 유지보수의 난이도와 복잡도가 크게 증가한다.)

2) 애매한 업무분장(도메인) (각 서비스별 업무분장, 도메인을 제대로 정하지 않을 경우, 업무에 비효율성을 초래)

* 왜 MSA 쓰는지?

cloud는 가상화 기능을 사용하게 되고 가상화 기능의 특성상,  물리서버보다 장애에 취약함.
물론 cloud 업체들이 보완기능을 제공하고 있지만, 전통적인 IT 환경보다는 장애 가능성이 더 높다.

-> 장애 취약점을 보완하기 위해 MSA를 활용하기 시작.