[기고] 마이크로서비스 아키텍처(MSA)로의 여정
상태바
[기고] 마이크로서비스 아키텍처(MSA)로의 여정
  • 석주원 기자
  • 승인 2021.04.12 14:05
  • 댓글 0
이 기사를 공유합니다

넷플릭스로 살펴보는 MSA 도입 사례

[글=노규남 | KINX CTO]
bardroh@kinx.net

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

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

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

여기에는 여러 가지 이유가 있는데, 먼저 워크로드가 요구하는 고성능 DB를 퍼블릭 클라우드 서비스가 제공하기 어렵다는 점이다. 최근에는 이런 수요에 대응해 NVMe(비휘발성 메모리 익스프레스)를 스토리지로 사용하는 VM(가상머신)도 있지만 구성의 자유로움이나 비용을 생각하면 선뜻 택하기 어렵다. 또 막연하게 중요 자료를 외부 클라우드에 두는 것에 거부감을 갖기도 한다. 이 밖에 법적 규제로 인해 데이터 이전 자체가 불가능한 경우도 있다.

이러한 이유로 현재 가장 인기가 있는 클라우드 구성은 DBMS를 물리 서버에 두고 나머지 자원을 모두 클라우드에 두는 하이브리드 클라우드 형태다. 그리고 이런 분위기는 향후 몇 년간 쉽게 바뀌지 않을 것으로 보인다.

 

대형 DBMS 문제, 넷플릭스는 어떻게 해결했나

하지만 하이브리드 클라우드를 구성할 경우 DBMS를 직접 관리해야 하므로 단일 장애점(SPOF)이 발생할 수 있을 뿐만 아니라 서비스 확장에 따라 데이터베이스 관리자(DBA)의 부담도 증가한다. 물론 하드웨어 기술이 나날이 발전하므로 적절한 때 하드웨어를 교체해 성능을 지속 향상시키는 방법으로 스케일업(Scale-up)을 할 수는 있다. 그렇다 하더라도 중요 DBMS 하나에 수십 TB(테라바이트)의 데이터가 저장되어 있다면 장애 시 매우 큰 문제가 발생할 수 있다.

복구나 백업도 쉽지 않을 것이다. DB(데이터베이스) 구조 변경을 위해 전체 서비스를 중단시켜야 하며, DB 규모 증가에 따라 중단 시간도 점점 늘어나기 때문이다. 만약 랜섬웨어 공격이라도 당하면 그야말로 날벼락이다. 그럼에도 불구하고 DBMS가 너무 중요한 시스템이므로 직접 관리하겠다는 사람들은 여전히 줄지 않고 있다.

반면 세계적인 동영상 스트리밍 업체 넷플릭스는 접근 방식을 달리했다. 넷플릭스는 DBMS를 포함한 자사의 인터넷데이터센터(IDC) 인프라를 7년에 걸쳐 모두 클라우드로 이전했다. 말하자면 넷플릭스의 인프라는 하이브리드가 아닌 순수 클라우드로 구성되어 있는 것이다. 만약 하이브리드 구성을 채택해 DBMS를 로컬에 남겼다면 넷플릭스의 단일 DBMS는 어마어마한 규모가 되었을 것이다. 엄청난 데이터 입출력을 감당하기 위해 매우 뛰어난 성능의 스토리지를 사용하고도 DB 구조 변경을 위해 한 달에 하루 정도는 정기 점검으로 서비스를 중단하지 않을 수 없었을 것이다.

하지만 넷플릭스는 클라우드를 택했고, 현재 정기 점검이라는 이벤트 자체가 없다. 그러면서도 계속해 신규 서비스가 추가되고, 기존 서비스가 업데이트되며, 오류가 수정된다. 전체 DB의 크기를 정확히 알 수는 없지만 방대한 동영상 콘텐츠를 제공하는 서비스인 만큼 엄청난 규모일 것이라는 추측은 가능하다. 그런데도 동일 계정으로 한국과 미국에서 똑같이 서비스를 이용할 수 있다. 심지어 서비스 지연도 매우 적다. 어떻게 이런 서비스가 가능할까? 해답은 마이크로서비스 아키텍처(MSA) 구조와 넷플릭스의 스프링 클라우드(Spring Cloud) 프레임워크에 있다.

 

마이크로서비스 아키텍처와 스프링 클라우드

넷플릭스의 서비스는 수백 개의 마이크로서비스로 구성되어 있고 이들은 서로 API(응용 프로그래밍 인터페이스)로 통신한다. 그리고 하나의 통합된 DB 대신 서비스에 따라 나누어진 여러 개의 DB를 사용하는 아주 느슨한 연결로 구성되어 있다. 더불어 서킷 브레이커(Circuit Breaker)가 있어서 한 서비스의 장애가 다른 서비스에 미치는 영향을 차단한다. 각 엔드포인트는 주소 대신 이름으로 서비스 디스커버리(Service Discovery)에 등록되어 있고 API 호출은 클라이언트 로드 밸런서(Client Load Balancer)를 경유하므로 특별한 작업 없이도 노드의 장애 대응이나 확장, 실시간 무중단 서비스 변경이 가능하다.

여기에 인프라 일부를 무작위로 다운시키는 테스트를 지속해 서비스의 안정성을 시험하고 보완해 나간다. 이때 일명 카오스 도구(Chaos Tool)를 사용하는데, 인스턴스는 카오스 몽키(Chaos Monkey)가, 가용 영역은 카오스 고릴라(Chaos Gorilla), 리전은 카오스 콩(Chaos Kong)이 맡아서 다운시킨다. 이런 프로세스를 통해 넷플릭스는 전 세계에 걸친 서비스 인프라를 구축하면서도 빠르게 서비스를 업데이트하고 확장해 나갈 수 있었다.

넷플릭스 카오스 툴
넷플릭스 카오스 툴

물론 이런 상황에서도 넷플릭스 서비스에 장애가 전혀 없었던 건 아니다. 과거 AWS DNS 장애처럼 전체 AWS 서비스에 문제가 생기면 어쩔 수 없이 넷플릭스에 장애가 발생하게 된다. 이를 해소하기 위해서는 메인 인프라를 AWS 외의 다른 CSP(클라우드 서비스 공급자)로 일부 옮기는 다중화가 필요하다. 그러나 AWS와 넷플릭스의 오래된 관계를 생각하면 당분간 그렇게 될 가능성은 적어 보인다.

다만 여기서 아이디어를 얻는다면 복수의 CSP에 걸쳐 인프라를 구성하고 글로벌 서버 로드 밸런싱(GSLB)을 사용하면 대단히 견고한 시스템을 구축할 수 있다는 것이다. 하나의 CSP에서 장애가 발생해도 서비스는 중단되지 않을 것이다. 다시 말해 대형 글로벌 서비스는 향후 멀티 클라우드 형태로 구성될 가능성이 크다. 복수의 CSP에 인프라를 전개하며 컨테이너 기반의 서비스를 올려 서비스 메시(Service Mesh)를 구축하게 될 것이다.

 

넷플릭스가 먼저 겪은 문제들

넷플릭스가 이런 의사 결정을 하게 된 데에는 그럴 만한 사정이 있었다. 원래 넷플릭스는 클라우드를 사용하지 않고 자체 IDC를 쓰고 있었다. 중요 데이터는 모두 하나의 오라클 DBMS에 저장하고 애플리케이션도 하나의 단일 서비스로 구성했다. 그야말로 전형적인 모놀리식(Monolithic) 구조였다. 물론 지금도 많은 기업에서 이런 구조를 사용하고 있으며 그 자체가 나쁘다고 할 수는 없다.

만약 구축한 인프라가 충분한 용량과 성능을 가지고 있으며, 서비스나 고객이 천천히 확장된다면 이런 구조로도 충분히 의미가 있다. 하지만 당시 넷플릭스는 세계에서 가장 빠르게 성장하는 기업 중 하나였고 이런 구조는 넷플릭스의 고성장을 감당할 수 없었다. 결국 넷플릭스는 2008년 8월 DB 서버의 손상으로 인한 대규모 장애 사태를 겪었다. 이때 3일간 서비스가 중단되고, 수백만 달러의 매출 손실을 보았다고 한다. 이를 통해 모놀리식 구조로는 고속 성장하는 넷플릭스의 서비스를 감당할 수 없다는 것이 분명해졌다.

이런 배경으로 인해 넷플릭스는 단일 DB, 단일 애플리케이션이라는 기존 구조와 IDC를 버리고 모든 인프라를 클라우드로 이전하기로 결정한다. 단순히 자원을 옮기는 것이 아니라 애플리케이션의 구조를 모두 뜯어고치고 필요한 도구는 직접 만드는 과정이었다. 이 작업은 2008년부터 7년 동안 진행됐고 넷플릭스는 2015년 12월 마침내 모든 서비스를 AWS로 이전했다. 이로써 넷플릭스는 모든 워크로드를 퍼블릭 클라우드에서 운영하는 거의 최초의 대형 서비스 업체가 됐다.

넷플릭스는 많은 업체가 하이브리드 형태로 사용 중인 DBMS를 포함한 모든 자원을 AWS 위에서 구동한다. 넷플릭스가 DBMS까지 클라우드로 이전한 이유는 클라우드를 선호해서라기보다는 향후의 성장을 고려했기 때문이다. 언젠가는 DBMS도 클라우드로 이전할 수밖에 없다는 사실을 깨닫고 과감하게 조금 일찍 시작한 것이다.

만약 서비스가 하나의 중요한 단일 DB를 갖고 있고, 모든 서비스가 이 DB에 의존한다면 DB에 대한 중요 작업을 수행하기 위해서는 전체 서비스를 동시에 중단하지 않을 수 없다. 오늘날 이런 서비스 중단은 주로 정기 점검이라 불린다. 서비스 사용량이 적은 자정부터 새벽 사이에 주로 진행되며 제한된 시간 내에 서버의 재시작, DB의 백업 및 구조 변경, 애플리케이션 적용, 테스트 등을 모두 마쳐야 한다.

그러나 데이터의 양이 점점 늘어나면 작업 시간도 증가할 수밖에 없다. 어느 시점에서는 더 이상 이런 식으로 작업을 할 수 없다는 것을 깨닫게 된다. 넷플릭스와 같이 빠르게 성장하는 기업은 이런 작업 방식을 수용하기 어렵다. 때문에 넷플릭스가 전체 서비스와 DB를 분할한 후 각각 독립적으로 작동하는 구조로 인프라를 변경한 것은 어쩔 수 없는 선택이었다. 따라서 앞으로 많은 서비스 업체들은 넷플릭스의 뒤를 따르거나 아니면 스스로 서비스의 성장을 제한하게 되거나 둘 중 하나의 길을 선택하게 될 것이다.

마이크로서비스 아키텍처 구조
마이크로서비스 아키텍처 구조

 

오픈 API 구조의 맹점과 해결 방안

AWS가 각 서비스를 API로 느슨하게 연동하는 구조를 전격 도입한 후 많은 서비스 업체에서 이 같은 방식이 유행했던 적이 있다. DB나 스토리지 등을 통해 강하게 연결된(Tightly-bound) 구조에 비해 이런 느슨한 연결(Loosely-bound) 구조가 확장이나 코드 재사용 측면에서 유리한 것은 사실이다. 하지만 각 API 서비스가 실패할 경우에 대한 대비가 없는 상태에서 오픈 API 구조를 남용하는 것은 매우 위험하다. 한 API 서비스의 실패가 전체 서비스로 전파되며 각각의 API 서비스 모두가 단일 장애점이 되는 결과를 낳을 수 있기 때문이다. 이런 구조에서는 한 서비스에서만 문제가 발생해도 전체 서비스를 사용하지 못하게 되며, 서비스 간 연결이 증가하고 복잡해짐에 따라 장애의 빈도는 계속 늘어나게 된다.

이를 해소하기 위해서는 각 API 서비스들이 최대한 독립적인 구조를 갖게 하는 것이 바람직하다. DB를 분리하고 서비스 메시 위에 올려서 서킷 브레이커를 적용해야 한다. 더불어 각 API의 실패 시의 대체 로직을 구현해 가용한 서비스는 사용할 수 있게 해주어야 한다. 이런 구조로 변경하면 DB의 양이 늘어남에 따른 성능과 용량 증가를 더 이상 걱정하지 않아도 되며 한 서비스의 추가나 변경이 다른 서비스에 가하는 영향도 최소화된다. 이런 형태로 서비스가 변경되어야 비로소 클라우드 시대에 걸맞은 빠른 개발과 배포가 가능해지는 것이다.

또한 이렇게 분할된 DB에서의 데이터 처리 작업을 고민하게 되면서 MSA에서 분산 트랜잭션(Transaction)을 처리하는 사가(Saga) 패턴이 등장했다. 비로소 각 서비스가 다른 서비스에 미치는 영향을 고려하지 않고 독립적으로 개발, 배포할 수 있게 되었다. 또한 서비스의 다운타임을 최소화하기 위해 모든 빌드 및 배포 파이프라인은 자연스럽게 자동화됐다.

한편, 넷플릭스와 반대로 MSA를 시도했다가 모놀리식으로 다시 돌아온 반대 사례도 있다. 데이터 스타트업 세그먼트(Segment)를 예로 들 수 있다. 이 회사는 기존의 모놀리식 애플리케이션을 140여 개의 마이크로서비스로 분할한 후 수많은 장애를 겪었다. 다시 모놀리식으로 복귀한 후에야 비로소 안정적인 서비스를 제공할 수 있게 되었다. 이 사례는 MSA 구조에 문제가 있다는 것이 아니라 MSA를 도입하기 위해서는 개발, 운영, 시스템 등 그에 걸맞은 기술력이 필요하다는 점을 시사한다. 충분하지 않은 역량으로 MSA를 시도할 경우 어떤 문제가 발생하는지를 극명하게 보여준다.

아직도 수많은 기업이 성능, 안정성 등 여러 이유로 DB만은 로컬에 남기는 하이브리드 구성을 선호한다. 하지만 이런 구조는 서비스의 성장을 제한할 수밖에 없다는 점을 넷플릭스는 분명하게 보여주었다. 따라서 오래된 모놀리식 구조를 계속 고수하기보다는 시간이 남아 있을 때 MSA에 투자하고 시행착오를 해보기 권한다. MSA는 애플리케이션 서버 아키텍처의 분명한 미래이기 때문이다.



댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
0 / 400
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.