글로벌 칼럼 | “히드라 만세!” 눈송이 서버를 없애고 클라우드 제대로 구현하기

고가용성과 자동 확장, 자체 치유가 되는 클라우드 인프라는 그리스 신화의 머리 많은 괴물 히드라만큼이나 회복력이 뛰어나다. 이런 회복력의 대부분은 컨테이너를 사용해 만든다.

그리스 신화의 머리 아홉 달린 괴물 히드라는 최신 클라우드 아키텍처의 비밀을 품고 있다. 신화 속의 히드라는 머리 하나를 자르면 그 자리에서 두 개가 돋아나 좀처럼 죽이기 어려웠는데, 클라우드 인프라에 바라는 것이 바로 이런 회복력이기 때문이다.
 

신화에서는 영웅 헤라클레스마저도 히드라를 잡기 위해 조카 이올라스의 도움을 받아야만 했다. IT 인프라의 세계에서는 아직 끊임없이 증식하는 히드라는 없고, 클라우드에서 흩날리는 눈송이 같은 서버에 디지털의 미래를 맡기고 있는 실정이다. 아직 고가용성과 자동 확장, 자체 치유 솔루션을 가져다주는 인프라 자동화의 진정한 잠재력을 구현하지 못한 것이다. 이유는 무엇일까? 최고 경영진 모두가 가능한 한 실질적인 변화는 최소화하면서 적절한 시기에 얌전하게 클라우드로 이전하기를 바라기 때문이다.

이런 경영진의 기대는 IT팀이 자사의 레거시 코드 기반을 가상머신으로 ‘리프트 앤 시프트’해 기존 온프레미스 데이터센터와 거의 흡사한 모습을 만드는 동기를 부여했다. 이런 접근법이 필요하고 알맞은 시나리오가 따로 있는데, 임대 데이터센터에서 클라우드로 급하게 이전해야 하는 경우가 대표적인 예이다. 하지만 이런 방식은 대부분 진정한 트랜스포메이션은 포기하게 된다. 유사한 환경의 친숙함에 빠지면 IT 부서는 계속 예전과 같은 눈송이 서버 구성에 의존하게 되며, 자동화된 배치에도 여전히 서버의 수작업 설정이 필요하다.

이런 맞춤형 수작업 구성은 베어메탈 서버에서 구동하는 온프레미스 가상머신에 주로 사용된다. 하지만 관리자는 시스템마다 변경 작업을 해야 한다. 이런 서버는 반려동물처럼 주기적인 관심과 보호가 필요하며, IT팀은 동일한 서버를 오랫동안 관리해야 한다.

심지어 IT 인프라를 클라우드로 마이그레이션할 때도 IT 관리자는 계속 수작업 구성을 통해 가상머신을 프로비저닝하는 경향이 있다. ‘리프트 앤 시프트’의 정수를 만족하는 가장 단순한 방법처럼 보이지만, 퍼블릭 클라우드가 약속하는 완전히 자동화된 인프라 구현을 방해한다. 

결과는 어떨까? 클라우드에 상당한 자원을 투자했음에도 기업은 클라우드의 장점을 활용할 기회를 놓치고 만다. AWS나 애저, 구글 클라우드 등 클라우드 컴퓨팅 서비스 배치 환경을 기존 데이터센터와 똑같은 방식으로 다뤄서는 안된다. 둘은 근본적으로 전혀 다른 통치 이데올로기를 가지고 있다.
 

가상머신을 버리고 선택하는 스테이트리스

클라우드 네이티브 배치는 전혀 다른 마음가짐이 필요하다. 개별 서버 하나하나는 전혀 문제가 되지 않는 스테이트리스(Stateless) 환경이기 때문이다. 손길이 필요한 반려동물과는 달리 가상의 히드라를 생성하고, 뭔가 잘못되거나 부하가 커지면 인프라가 새로 머리를 만들어낸다.

클라우드 플랫폼이 제공하는 자동 확장 규칙을 이용해 이런 환경을 구현할 수 있는데, 진정한 클라우드 네이티브 패러다임으로 가는 반환점을 돈 것이다. 여기에 컨테이너 오케스트레이션까지 구현하면 히드라의 진정한 힘을 온전히 방출할 수 있다. 완전한 스테이트리스 환경에 자체 치유와 손쉬운 확장이 가능해진다.

만약 신화 속의 히드라가 머리가 새로 날 때마다 몇 분 정도의 다운타임이 필요하다면 어땠을까? 헤라클레스는 혼자서도 히드라를 손쉽게 처치했을 것이다. 하지만 컨테이너는 매우 가볍기 때문에 잘 설계된 컨테이너 환경이라면, 수평 확장과 자체 치유에 5초가 걸리지 않는다. 진정한 고가용성을 보장하는 이런 속도는 어느 영웅의 칼보다 빠르다.

대형 온프레미스 서버와 결별하고 워크로드를 일용품화해 빛처럼 빠르게 확장할 수 있게 된 데는 구글의 공이 크다. 창고 시절의 래리 페이지와 세르게이 브린은 레고 블록으로 만든 캐비닛에 4GB 하드디스크 10대를 쌓고 범용 데스크톱 컴퓨터 여러 대를 연결했다. 구글이 탄생한 순간이자 “대형 서버는 더 이상 필요없어” 혁명이 시작된 순간이었다. 표준 컴퓨팅 장비를 배치해 원하는 것을 원하는 시간에 배치할 수 있고 만들자마자 사용할 수 있다면, 더 이상 신경 쓸 일이 있겠는가?

이제 컨테이너로 돌아가자. 컨테이너를 머리 아홉 달린 히드라라고 생각하자. 쿠버네티스나 아마존 ECS, 기타 컨테이너 오케스트레이션 서비스를 제대로 구성했다면, 한 대가 죽어도 클라우드가 간단하게 새로운 컨테이너로 대체한다. 

물론, 이런 접근법을 구현하기 위해서는 비용이 든다. 대신에 완전히 새로운 수준의 안정성을 제공하는 엄청난 확장성과 속도를 인프라 운영에 가져다준다. 클라우드를 데이터센터처럼 취급하고 데이터센터 비용을 비즈니스에 활용할 역량도 구현하지 못하면, 클라우드가 제공하는 핵심 이점도 놓치면서 비용은 더 많이 들고 말 것이다.
 

히드라 기반 아키텍처의 조건

이제 오늘날의 클라우드 아키텍처에 히드라의 머리가 필요한 이유와 실제로 이런 환경을 구축하는 방법을 알아보자.

구성과 코드의 분리
12팩터 앱 원칙을 기반으로 히드라 아키텍처는 환경 기반의 구성을 이용해 코드에 어떤 변경이 발생해도 탄력적인 고가용성 인프라의 독립성을 보장해야 한다.

로컬 불가 항시 자동화
파일 시스템이 불가변적이고 절대 로컬에 위치하지 않는다고 생각해야 한다. 다시 말하지만, 로컬 IO는 안된다. 로그는 프로메테우스나 아마존 클라우드워치로 보내고, 파일은 아마존 S3나 애저 Blob 스토리지 같은 BLOB(Binary Large Object) 스토리지에 저장한다. 또한 CI/CD나 재해 복구를 위해 필요할 때 새 컨테이너가 자동으로 생겨나도록 자동화 서비스를 배치해야 한다.

컨테이너 빈 패킹
비용을 제어하고 낭비를 줄이기 위해 컨테이너 빈 패킹(Bin Packing) 원칙을 지키자. 일부 클라우드 플랫폼은 빈 패킹을 지원하며, 일부는 수작업 접근법으로 처리해야 한다. 어떤 식으로든 자원을 최적화해야 한다. 가상머신은 화물선의 적재공간과 같다. 컨테이너는 배로 운송해야 할 상자이다. 비용을 최적화하려면 적재 공간에 최대한 많은 상자를 실어야 한다. 

서비스에 알맞은 규모
서비스는 가능한 한 스테이트리스 상태여야 한다. 적절한 규모의 서비스를 설계하는 것은 마이크로서비스와 모놀리식 구조 사이에 있는 함정과 같다. 상황과 영역에 맞게 적절한 규모의 서비스를 구축해야만 문제를 해결할 수 있다. 비교하자면, 마이크로서비스는 복잡성을 불러오고 모놀리식 구조는 확장하기가 어렵다. 인생의 모든 것이 그렇듯이 적절한 중도를 취하는 것이 최선의 선택이 될 것이다.

성공의 기준
컨테이너를 적절하게 구성했는지는 어떻게 알 수 있을까? 간단한 테스트 방법이 있다. 배치된 서버 다섯 대를 꺼도 별도의 수작업없이 인프라가 정상으로 돌아오는가? 그렇다면, 제대로 구성한 것이다. 돌아오지 않는다면, 화이트보드를 가져와 원인을 파악해야 한다. 이 개념은 어떤 퍼블릭 클라우드에도 적용된다. 모든 것을 자동화해야 한다. 비용 효과적이라면 재해복구 전략도 마찬가지이다. 필요하다면 애플리케이션이 이런 시나리오에 대응하는 방법도 변경해야 한다.

보너스 : 컴플라이언스 준비 시간 절감
수평 자동 확장 및 자체 치유 환경을 구현했다면, 기존에 보안 및 컴플라이언스에 들이던 시간도 절감할 수 있다. 매니지드 서비스를 사용하면, 운영체제 패치에 더 이상 많은 시간을 들일 필요가 없다. 누군가의 시스템에서 컨테이너 기반 서비스를 구동한다는 것은 호스트 OS의 보안과 네트워크 구획 관리도 맡기는 것을 의미한다. SOC나 HIPPA 컴플라이언스를 쉽게 만족할 수 있다.
 

이제 코딩에 집중할 때

결론적으로 소프트웨어 엔지니어는 클라우드 인프라를 돌보는 것 말고 더 중요한 일을 할 수 있으며, 특히 처음에 가상화로 얻으려 했던 이점을 얻지 못하고 비용만 증가할 때 해결책이 될 수 있다. 자동 수평 확장과 자체 치유를 구현하는 데 시간과 노력을 들이면, 고가용성 인프라의 이점을 향유하면서 제품 개발과 같은 더 가치 있는 활동에 시간을 더 투여할 수 있다.

이제 다음 프로젝트는 히드라가 언제나 또 하나의 머리를 만든다는 확신을 가지고 준비하자. 클라우드에 가장 가깝게 날 수 있는 방법이다.
editor@itworld.co.kr