클라우드 환경을 위한 데브옵스(DevOps)

글. 손영수 상무(어니컴 성능솔루션 사업부)

시스템을 개발하는 방법에는 여러 가지가 있지만, 통상적으로 소프트웨어를 개발하고 빌드·배포 과정을 거쳐 테스트하는 일련의 과정을 거친다. 또한, 소프트웨어를 배포 후 운영하는 과정에서 별도로 나누어 관리하게 되는데, 클라우드 기반의 시스템은 이러한 과정에서 서로 다른 조직이나 팀에서 관리하는 방식보다는 하나의 통합된 조직이나 팀에서 관리하도록 하는 데브옵스(DevOps) 라는 개념으로 소프트웨어를 개발하는 방법을 선호하고 있다.

데브옵스(DevOps) 정의

데브옵스(DevOps)란 개발(Dev)와 운영(Ops)의 합성으로, 개발과 운영이 하나로 묶여, 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시킬 프로세스, 도구, 문화 등을 말한다.

DevOps에 사용되는 도구들

개발의 코드 생성부터 저장, 테스트를 통한 품질 확보, 배포, 운영까지 전 사이클을 하나의 체인으로 묶어, 기존의 소프트웨어 개발 및 인프라 관리 프로세스를 별도로 운영하는 조직보다 제품을 더 빠르게 고객에게 제공할 수 있게 된다.

DevOps가 나온 배경

DevOps가 클라우드 환경에서 대두된 큰 이유는 두 가지다.

하나. 고 스펙의 서버 하나 보다는 낮은 스펙의 여러 대의 서버를 운영하는 것이 가용성 확보가 용이하고, 비용 면에서 효율적이다. 그러므로 늘어나는 수많은 서버들을 사람이 아닌, 자동으로 운영 관리할 수 있어야 한다.

둘. 멀티 리전 운영의 필수. 천재 지변으로 IDC에 장애가 난다거나, 고객 접근 속도 향상, 가용성을 확보 등을 위해 다수의 리전에 배포해야 한다. 넷플리스 같은 경우는 여러 AWS 대규모 장애, 통신사 화재에도 서비스가 운영되었던 이유가, 한국 리전이 죽을 경우에도 다른 리전(국가)에서 한국서비스가 제공하는 모든 백업 플랜을 제공하고 있다. 이를 카오스 엔지니어링이라고 한다.
이로 인해 더 많은 VM 인스턴스를 관리하고, 다양한 리전에 배포 운영을 해야 하다 보니, 사람의 손이 아닌 자동으로 배포 운영되는 환경에 대한 구성이 필요해졌다.

DevOps의 1인자, 넷플릭스의 DevOps 파이프라인

우스갯소리로, AWS 보다 AWS를 더 잘아는 기업이 있다. 바로 넷플릭스다. 넷플릭스는 7년의 준비를 거쳐, IDC를 버리고 AWS로 모든 서비스를 이전했다. AWS에서 무수한 장애를 겪으며, 장애를 흡수하는 방법을 터득하였고, 그 산물 중 하나가 바로 Spring Cloud이다.
그럼 넷플릭스는 어디까지 DevOps 환경을 구축했을까? 결론부터 말하자면 코드 커밋부터, 리그레이션, 성능, 부하 테스트를 거쳐 실 서버에 배포하여 반영까지 되는데, 단 16분밖에 걸리지 않는다.
넷플릭스가 구성한 DevOps의 흐름(파이프라인)은 다음과 같다. 넷플릭스의 파이프라인은 배포 (Devployment) 단계가 세밀하게 구성되어 있으며, 매우 높은 수준의 내재화 기술을 가지고 있다.

1) CI(지속적 통합) : CI를 빠르게 하기 위해, Java를 자동빌드하는 Gradle 플러그인들의 집합체인 Nebula를 자체 구축하여 사용함. 작은 단위의 라이브러리로 나누어 관리함으로써, 배포, 테스트가 용이해짐.

2) BAKE(이미지 굽기) : 직접 코드를 배포하는 것이 아닌, 아마존 VM 이미지(AMI) 또는 Docker로 구워서 배포함. 오픈소스의 대안으로는 Packer가 존재.

3) Deployment(배포) : 이전 단계에서 구운 여러 이미지들을 Spinnaker를 사용하여 기능 테스트를 할 수 있는 최소 단위의 아마존 인스턴스들에 배포함(오픈소스의 대안으로는 Terraform이 존재하며 사용자 층이 훨씬 많음). 여기서 오해는 바로 라이브(운영) 서비스에 배포하지는 않고 전체 서비스가 동작하는 최소한의 세트를 구성하여 배포함. 라이브 배포 직전의 단계(스테이징 배포)를 구성.

4) Post-Deploy Test(배포 후 테스트) : 배포 후 전체적인 기능에 문제가 없는지 테스트를 진행. 기존 기능과 새로운 기능 간에 문제 없이 잘 동작하는지 리그레션 테스트, 부하 테스트, 부하 테스트 시 자원 사용량 측정 등을 통해 안정성도 점검.

5) Canary(일부만 운영에 배포) : 전체 다 배포하지 않고, 일부 10% 미만만 배포를 해서 기존 버전(Base)과 신규 배포한 인스턴스만 간의 성능과 안정성 비교

6) Live(운영 배포) : Canary 배포 후 문제가 없으면, 운영계에 점진적 배포를 진행함. 기준이 미달하면 롤백 시킴.

공유자원인 클라우드의 제약을 받아들여라

클라우드를 사용할 때 운영하는 입장에서 가장 중요시 여겨야 하는 것은 클라우드는 공유자원이라는 것이다. 위 그림처럼, 하나의 물리머신과 Host OS 위에서 나의 VM이나 Docker가 동작한다는 것이며, 여기에는 다른 회사 또는 고객의 VM과 Docker도 같이 입점해서 자원을 공유해서 쓴다는 것이다.

클라우드 플랫폼 제공자 입장에서는 극단적으로 말하면 하나의 물리인스턴스에 여러 개의 VM을 많이 담으면 담을수록 더 이익이 되는 구조이다. 또한 클라우드에서 제공하는 vCore는 물리코어의 최대 16배까지 OverCommit 할 수 있기에(즉 4개의 물리 CPU를 64개의 가상 코어로 만들 수 있기에) 클라우드 플랫폼 제공자 입장에서는 얼마나 부풀릴지 고민할 수밖에 없다. 또한 같은 CPU와 메모리를 가진 인스턴스라고 하더라도, 한국 리전의 성능과 중국 리전의 성능은 다를 수 있다는 점을 감안해야 한다.

공유자원의 단점을 말하면, 특정 새벽시간에 내가 입점해 있는 Host OS에서, 다른 고객의 서비스가 빅데이터 분석 작업을 실행시켰다면, IO, CPU 자원을 과도하게 사용할 수 있다는 점이다. 그리고 우리가 운영 중인 서비스에도 악영향을 줄 수 있다. 즉 오늘 측정한 성능과 장애가 나는 시점에 우리 VM·Docker에 배분된 자원 배분이 다를 수 있다는 점을 받아들여야 한다. (보통 클라우드 밴더가 주는 가상 코어의 성능은 직접 운영을 하기 이전까지는 정확한 성능에 대한 산정이 어려우며 보통 물리 인스턴스의 40% 정도의 성능을 가지는 것으로 예상을 하고 측정해야 한다.)
퍼블릭 클라우드 환경에서 안정적인 서비스를 사용하기 위해 클라우드 하모니 (CloudHarmony.com)와 같은 클라우드 비교 서비스를 통해, 클라우드 서비스 간에 장애 상황과 네트워크 속도 등을 포함한 성능을 주기적으로 체크할 수 있다.

장애를 흡수하거나, 최소화하는 전략을 세워라!

넷플릭스 시스템의 운영 철학 중 가장 중요한 것은, 장애를 흡수하거나 최소화하는 전략을 곳곳에 적용했다는 것이다. 그중 가장 대표적인 운영 전략이 앞서 말한 카오스 엔지니어링이다.
장애를 의도적으로 발생시키는 원숭이인 시미안 아미(Simian Arm)를 풀어 장애를 수시로 발생시킨 후 그 장애를 흡수할 수 있는 아키텍처를 만든다는 것이다. 예를 들어 네크워크 응답 에러 404 발생, 특정시간(30초) 이상 지연시키기, CPU 과다 사용, 익셉션 던지기, 패킷 버리기 등 여러 장애를 발생시키는 원숭이들을 ‘카오스 원숭이(Chaos Monkey)’라고 부르며, 클라우드 인스턴스 곳곳에 숨겨둔다. 여러 가지 원숭이들 중 대표적인 사례는 꼽는다면 다음과 같다.

아키텍처 구성, 모니터링 체계 구축이 관건

모니터링 서비스는 운영적인 서비스의 정보들을 동적으로 관리할 수 있게 지원한다. 서비스 게이트웨이는 클라이언트 요청을 해석하여 가용성을 유지할 수 있게 부하 분산과 적절한 서비스로 연결해주는 라우팅 기능을 지원한다.

또한, 마이크로 서비스의 요청 상태를 파악해 클라우드 인스턴스를 오토 스케일링 하는 것이 가능하다. 또한 일순간 많이 들어오는 트래픽을 제어하는 서킷 브레이커 기능도 제공을 해야 한다.
넷플릭스 서비스 운영 중 일순간 갑자기 많은 요청이 들어왔을 때, 클라이언트들이 연결을 하지 못해 대기하던 중 이로 인해 기존에 접속해서 서비스를 받고 있는 사용자도 영향을 받아, 80%의 요청이 거절된 대규모 장애가 발생한 적이 있다. 이에 큰 교훈을 얻은 넷플릭스는 서비스당 처리할 수 있는 최대 요청 수를 제한해 놓고, 그 이상의 요청이 들어오면 고객들에게 404 에러를 발생시킴으로써 요청을 거절해 이미 접속한 유저에게는 안정적으로 서비스를 제공하는데, 이것이 바로 서킷 브레이커의 작동 원리다.

예를 들어 로그인 서비스의 최대 접속 수가 초당 500개의 요청이라고 제한을 한다면, 임계점 이하까지는 Circuit(회로)이 Close(연결)되어 요청을 받다가, 초당 501번 째의 요청부터는 회로 접속을 끊어(Open) 더 이상의 요청을 받지 않게 하는 것이다. 이러한 기능을 Hystrix라는 오픈소스를 통해서 하고 있으며, 국내의 다양한 기업들이 이를 활용하고 있다.

금융 클라우드, 남은 시장을 장악해라

퍼블릭 클라우드 시장은 주요 고객사인 게임, 제조사, 리테일 사를 위한 여러 가지 기능은 제공하고 있으나 금융 시장에 대한 접근은 시도도 못하고 있다. 국내 금융 보안 요건의 지원 미비, 기존 IDC와의 연동 등에 대해서는 그렇다 할 만한 전략이 없다. 이에 시장 크기도 크면서 상대적으로 외국계 3사가 접근하기 힘든 금융 시장과 같이 비어 있는 영역에 집중하는 것이 필요하다. 금융 클라우드를 예로 들어보자.

먼저, 금융 클라우드는 퍼블릭 클라우드와 어떤 차이점이 있을까? 금융 클라우드는 금융기관 기본적 준수사항인 전자감독규정을 100% 만족하는 구성을 갖추고 있으며, 각종 보안침해로부터 고객의 주요 정보를 보호하며 체계적인 Compliance를 지원해야 한다. 이를 위해 금융보안성 심의 요건을 충족하는 금융전용 클라우드 데이터센터와 일반 금융 서비스 Zone 외에 금융 지주 및 대형 금융사를 위한 금융전용 Zone 및 국정원 CC인증 규격 장비 구성을 통한 보안 특화 관제(모니터링)서비스를 제공해야만 한다.

코스콤의 금융 클라우드는 CC 인증을 받은 장비와 SW로 구성이 되어 있어, 기존 증권망과의 망 연계 및 분리 제공이 용이하다. 이로 인해 기존 퍼블릭 클라우드에서 CC인증 제품을 연계하기 위한 별도의 시간, 노력, 비용을 줄일 수 있다. 또한 금융 시스템의 필수 조건인 재해복구(DR) 구성도 훨씬 쉽게 구축 가능한 장점을 가지고 있다.

최근 기업들의 비대면 환경 구축 및 정부의 디지털 뉴딜 계획 시행 등으로 언택트 수요가 늘면서 국내 클라우드 시장이 급성장세를 보이고 있다. 국내 클라우드 시장의 3파전 구도를 형성하고 있는 NHN, KT, NBP의 경쟁도 한층 달아올랐다.

NHN은 HDC현대산업개발과 함께 총 5000억 원을 투입, 경남 김해시에 두 번째 클라우드 전용 데이터센터인 ‘TCC2(토스트 클라우드센터2)’를 건립하겠다는 계획을 발표했다. 클라우드 시장으로 사업영역을 빠르게 확장하고 있는 KT는 최근 티맥스에이앤씨, 한글과컴퓨터, 틸론, 인베슘 등 4개 사와 공공기관 대상 서비스형 데스크톱(DaaS·Desktop as a Service) 생태계 조성을 위한 사업 모델 공동개발 및 활성화를 위한 업무협약(MOU)을 체결했다. DaaS는 네트워크가 연결돼 있으면 언제 어디서든 개인화된 PC 환경을 사용할 수 있는 서비스다. NBP는 ‘뉴로클라우드’ 서비스를 선보였다. 뉴로클라우드는 금융권과 의료, 공공 등 보안 규제가 있는 분야의 클라우드 도입을 타깃으로 NCP를 유기적으로 연결해 운영하는 방식이다.

특히, 코스콤은 금융권에 특화해서 NBP와 함께 공동으로 금융 클라우드 서비스를 제공하고 있으며, 최근 코로나 시기에 맞춰 금융권 콜센터 서비스를 금융 클라우드 상에 적극 개발함으로써 유의미한 결과를 만들어내고 있다.

* 저작권법에 의하여 해당 콘텐츠는 코스콤에 저작권이 있습니다.
* 따라서, 해당 콘텐츠는 사전 동의없이 2차 가공 및 영리적인 이용을 금합니다.