Cloud와 MSA

클라우드(Cloud)와 MSA(MicroService Architecture)는 최근 IT 업계에서 중요한 이슈이다.

 

하이브리드 클라우드는 왜 인기 있을까?

2006년 AWS가 상업용 클라우드 컴퓨팅 서비스를 출시한 이후로 클라우드는 피할 수 없는 대세가 됐다. IT 시장조사기관 가트너는 2020년 전 세계 클라우드 시장 규모를 2579억 달러로 추정했다. 이는 서버 시장의 규모(240억 달러)를 10배 이상 추월한 숫자다. 더욱이 향후 몇 년간 20% 가까운 성장률을 예상한다고 하니 그 규모는 더 빠르게 커질 것이다. 이 차이는 어찌 보면 당연하다. 서버는 단순히 고객에게 물리적인 하드웨어를 파는 것인데 반해 클라우드는 서버 외에도 오브젝트 스토리지, 관리형 DBMS(데이터베이스관리시스템), 애플리케이션 등 훨씬 넓은 범위의 서비스를 제공하기 때문이다.

기업들도 이제 서비스 인프라의 상당 부분을 클라우드로 이전했다. 신규 인프라 구축 시에도 당연히 클라우드를 전제로 시스템을 설계한다. 그럼에도 불구하고 여전히 고객의 자체 시스템으로 남아 있는 부분이 있는데, 그중 하나가 바로 DBMS이다. 그간 DBMS를 클라우드로 옮기고자 하는 시도가 없지는 않았다. 볼륨이 작은 서비스의 경우 DBMS를 클라우드로 이전하는 경우도 종종 있었다. 그러나 기업 대부분은 아직도 중요 DBMS를 이중화해 자체 구축한 온프레미스(On-Premise) 환경에 두는 것이 일반적이다.

 

 

On-Premise 환경이란?

 서버 팜이나 클라우드와 같은 원격 시설이 아닌 소프트웨어를 사용하는 개인 또는 조직의 구내 컴퓨터에 설치 및 실행하는 것.

출처 : CCTV뉴스(http://www.cctvnews.co.kr)

 

 

물론,

 

https://www.bespinglobal.com/tech-company-cloud-spending/

 

넷플릭스처럼 IDC까지 전부 Cloud환경에서 운용하는 사례도 존재한다.

하지만 이는 그만한 기술력이 뒷받침되어야 하기 때문에 쉽게 시도할 수는 없다.

 

 

아무튼,

최근 기업은 IDC를 제외한 모든 서비스 인프라를 Cloud로 이전하고 사용한다.

 

 

클라우드 컴퓨팅

사용자의 직접적인 활발한 관리없이, 컴퓨터 리소스를 필요시 바로 제공하는 것을 말한다.

인터넷 기반 컴퓨팅의 일종으로 On-Premise 환경이 아닌 클라우에 연결된 다른 컴퓨터로 처리하는 기술을 의미한다.

(AWS, GCP, Naver Cloud 등...)

 

컴퓨터 네트워크, 데이터베이스, 서버, 스토리지, 애플리케이션 등 컴퓨팅 자원에 대해 어디서나 접근할 수 있는, 주문형 접근을 가능케 하는 모델이며, 빠른 릴리스와 확장을 용이하게 한다.

 

데이터 관리, 보안등의 문제로 DBMS는 물리서버에 두고 나머지 기능을 클라우드에서 운용하는 것을 하이브리드 클라우드라고한다.

 

 

Monolithic Architecture와 MSA

이 클라우드 서비스와 밀접한 관련이 있는것이 MSA이다.

 

https://shaul1991.medium.com/%EC%B4%88%EB%B3%B4%EA%B0%9C%EB%B0%9C%EC%9E%90-%EC%9D%BC%EC%A7%80-%EB%8C%80%EC%84%B8-msa-%EB%84%88-%EB%AD%90%EB%8B%88-efba5cfafdeb

- Monolithic Architecture

중요 데이터는 모두 하나의 DBMS에 저장하고 애플리케이션도 하나의 단일 서비스로 구성하는 것을, Monotlithic 방식이라고 부른다. 많은 기업에서 사용되고 있으며 문제가 없다면 나쁘지 않은 구조이다.

 

하지만 상황에 따라 단점이 존재한다.

1. 급속도로 서비스를 성장하는 상황이라면 이러한 Monolithcic 구조는 이 서비스를 감당할 수 없다.

실제로 넷플릭스는 2008년 8월 DB 서버의 손상으로 인한 대규모 장애 사태를 겪었다. 이때 3일간 서비스가 중단되고, 수백만 달러의 매출 손실을 보았다고 한다.

이러한 점이 성장 측면에서 모놀리식 구조가 갖는 가장 큰 단점이다.

 

2. 모든 서비스가 가 하나의 DBMS에 의존한다면 DB에 대한 중요작업을 수행할때, 전체 서비스를 동시에 중단하게 된다.

이러한 서비스 중단은 대게 정기 점검이라고 불린다.

제한된 시간 내에 서버의 재시작, DB의 백업 및 구조 변경, 애플리케이션 적용, 테스트 등을 모두 마쳐야 한다.

그러나 데이터의 양이 점점 늘어나면 작업 시간도 증가할 수밖에 없다. 어느 시점에서는 더 이상 이런 식으로 작업을 할 수 없게 될 것이다. 

 

따라서 각각의 서비스와 DB가 분리되고 독립적으로 작동하는 구조가 필요하다.

이것이 MSA이다.

 

 

- MSA(MicroService Architecture)

 

https://www.cctvnews.co.kr/news/articleView.html?idxno=223594

 

가장 직관적인 MSA의 구조이다.

각각의 점이 모드 단일 서비스, DB라고 생각하면된다. 이러한 각 서비스는 독립적으로 구성되어 있으며 서로 상호작용한다. 서비스 단위로 기능을 구분하고 관리하여 사용한다. 이러한 방식을 통해 Cloud에 맞게 최적화 할 수 있다.

 

Monolithic + Cloud 가 불편한 이유 

---

 

Monolithic 구조를 클라우드에 접목한다면 비용에서 비효율성이 증가하게된다.

클라우드는 기본적으로 사용량을 기준으로 비용을 측정하는데, 하나의 클라우드 환경에서 모든 서비스를 동작한다면 기존 하드웨어 동작하는 것보다 비용이 저렴하지 않을 것이다.(실제로 시뮬레이션 해보면 더 비싼 경우도 존재한다고 한다)

 

반면, MSA 구조는 Cloud 환경에 맞게 최적화를 할 수 있어(서비스 단위로 기능을 구분) 비용적인 문제를 해결할 수 있다. Monolithic 구조를 하드웨어에서 동작할때보다 더 저렴하게 운영 및 관리를 할 수있다.

---

 

MSA 아키텍쳐는 수백개의 마이크로 서비스로 구성되어있고, 이들은 서로 API로 통신한다.

DB 또한 여러개로 나누어진 느슨한 연결(Loosely-Bound)을 구성한다.

이러한 구조를 통해 서비스 확장이나 코드 재사용을 용이하게 한다.

 

하지만 아래와 같은 단점 또한 존재한다.

• 하나의 서비스의 오류가 전체 서비스에 악영향
• 인터페이스의 수가 늘어남
• 디버깅하기 어려움

 

이를 해소하기 위해 API 서비스들이 최대한 독립적인 구조를 갖게 하는 것이 중요하다.

DB를 분리하고 서킷 브레이커를 두어 한 서비스의 장애가 다른 서비스에 미치는 영향을 차단해야 한다.

또한, 각 API 실패 시의 대체 로직을 구현하여 가용한 서비스는 사용할 수 있게 해야한다.

 

이러한 분할된 DB에서의 데이터 처리를 고민하며 MSA에서 분산 트랜잭션을 처리하는 사가(Saga)패턴도 등장했다.

 

 

이러한 방식을 통해

 

1. 각 서비스가 다른 서비스에 미치는 영향을 고려하지 않고 독립적으로 개발, 배포
2. 서비스의 다운타임을 최소화하기 위해 빌드 및 배포 파이프 라인을 자동화

이 MSA의 핵심이다.

 

 

- Netflix의 서비스

넷플릭스는 여러개의 DB를 사용하는 느슨한 연결(Loosely-Bound) 구조와 서킷브레이커를 두어 위와 같은 단점을 극복한다.

또한, 각 엔드포인트는 이름으로 서비스 디스커버리에 등록하고, API 호출은 클라이언트 로드밸런서를 경유하여

특별한 작업없이 노드의 장애대응, 확장, 무중단 서비스 변경을 가능하게한다.

 

그 뿐만 아니라, 카오스 툴을 두어 안정성을 관리한다.

 

각각 아래와 같은 인프라를 맡아서 무작위로 다운시키는 테스트를 지속적으로 수행하여 서버의 안정성을 시험하고 보완한다.

• Chaos Monkey - 인스턴스
• Chaos Gorilla - 가용 영역
• Chaos Kong - 리전

---

출처

[기고] 마이크로서비스 아키텍처(MSA)로의 여정 - CCTV뉴스

Cloud와 MSA[MicroService Architecture]

클라우드 컴퓨팅 - 위키백과, 우리 모두의 백과사전