기업이 클라우드 네이티브(Cloud-native) 환경으로 서비스를 전환할 때 가장 많이 바뀌는 부분이 바로 애플리케이션이다. 어떤 종류 인프라를 도입해 사용하고 있는지와 상관없이 기업은 항상 자사 서비스가 365일 24시간 안정적으로 운영되기를 바란다.
여기서 '안정적'이란 수식어를 '높은 가용도(Availability)'라고 달리 표현할 수도 있다. 고객은 항상 서버나 가상머신(VM) 작동이 일시적으로 중단되지 않고 서비스가 끊김 없이 운영되는 상황을 원한다.
그래서 예전 방식 인프라 상황에선 하드웨어 방식으로 접근해 이중화에 적지 않은 투자를 진행했다. 디스크는 모두 RAID(Redundant Array of Inexpensive Disks)로 묶고, DB서버도 이중화해 하나의 서버 작동이 중단되더라도 서비스 중단 시간을 최소화하게끔 조치한다. RAID는 소용량 저장장치 여러 대를 배열로 묶어서 대용량 저장장치를 만든다. 가격이 저렴하고 장애 발생 시 복구 기능이 있어 서버에서 널리 사용하는 기술이다.
이중화 투자 단점은 유휴 자원이 항상 존재하기 때문에 인프라 낭비요소가 있다. 하지만 부담을 무릅쓰면서 그 정도 비용을 지출해서라도 기업은 예기치 못한 서비스 장애에 적극 대응했다.
일단 서비스를 클라우드로 이전하고 나면 클라우드 솔루션 공급자(CSP)가 하드웨어 관리를 맡기 때문에 이런 식의 구성은 어렵다. 또 CSP가 보장하는 가용도는 VM 기준에서 통상 월 99.9%가 표준이다. 고객 기대치보다 낮은 편이다. 이건 VM 업타임을 고객이 한 달간 직접 측정했더니 그 비율이 99.9%라는 게 아니다. 확인해보면 이 수치보다 높겠지만 CSP가 가용도 99.9%를 보장한다는 것이다.
바꿔 말하면 0.1% 시간은 서비스가 정지될 가능성이 있고 보장 범위 밖에서 서비스 중단은 CSP가 책임을 지지 않는다는 것이다. 즉 한 달(30일) 기준으로 43.2분은 VM에 이상 징후가 발생할 수 있으니 43.2분은 기업 고객이 알아서 대응해야 한다는 뜻이다.
사실 계약 내용만을 따지면 보안패치 등 어떤 이유이든지 CSP는 계약 범위 내에서 고객에게 고지와 보상 없이 서비스를 지원할 수 있다. 고객이 좋아하지 않기 때문에 서비스 중단 사고 책임을 외면할 수 없지만, 최근 쉘쇼크(ShellShock)와 멜트다운(Meltdown) 이슈가 불거졌을 때 AWS는 전체 호스트 10% 이상을 순서대로 재부팅하기도 했다.
그러나 고객은 이런 상황에서도 서비스가 중단되지 않기를 바란다. 결국 클라우드 환경에서 가용도를 끌어 올리는 역할은 애플리케이션 단으로 이전해야 한다. 클라우드로 서비스를 옮길 때 애플리케이션 수정을 진지하게 고려해야 하는 이유 중 하나이다.
따라서 기업이 클라우드에서 애플리케이션을 작성한다면 자원은 SLA(Service Level Agreement) 범위 내에서 얼마든지 작동 중지될 수도 있고 옮겨질 수도 있다는 사실을 인지해야 한다.
기업은 그 영향을 최소한 받을 수 있도록 애플리케이션을 설계해야 한다. 웹서버들은 L4 스위치를 통해 다중화 할 수 있고 만의 하나 웹서버 한대가 중지돼도 서비스에는 큰 지장이 없다.
다만 세션을 유지해야 하는 WAS(Web Application Server)나 DB서버들이 문제인데 이들도 WAS를 클러스터화해 세션을 공유하거나 매니지드 데이터베이스관리시스템(DBMS), DB클러스터를 사용하는 방식 등으로 해결하고 있다. 몽고(Mongo)DB 처럼 NoSQL은 처음부터 이런 상황에서 사용을 가정해 만든 솔루션이기 때문에 클라우드 네이티브 애플리케이션에 잘 맞는다.
또 예전에는 프로토콜부터 스테이트리스(Stateless)를 가정해 만든 웹서비스들만 이런 구조에 맞았다면 지금은 실시간으로 접속을 관리해야 하는 서비스들까지 이런 방식으로 진화하고 있는 중이다. 이 경우 애플리케이션은 완전히 독립적이며, 모든 데이터는 '별도 퍼시스턴트 스토리지(Persistent Storage)에 있다'란 가정 하에 시스템을 설계해야 한다.
일례로 모든 인프라를 클라우드에 둔 넷플릭스는 '카오스 몽키(Chaos Monkey)'란 SW 프로그램을 운영한다. 이 애플리케이션은 넷플릭스 실서비스 클라우드 자원 일부를 비정기·무작위적으로 셧 다운 한다. '카오스 몽키' 때문에 서비스에 장애가 생기면 넷플릭스는 그 부분을 보완해 서비스 중단이 되지 않게 수정한다. 이런 일들을 실서비스에서 계속 반복하면서 지속적으로 애플리케이션 복원력을 끌어올리기 때문에 넷플릭스는 호스트 장애 등 상황에서 어느 정도 안정적으로 실서비스를 운영한다.
이런 접근 방법을 카오스 엔지니어링이라고 말한다. 클라우드에서 서비스를 운영하는 기업들은 소프트웨어 설계 방식을 이미 상당히 바꿔나가고 있는 중이다. 어쩌면 클라우드 네이티브 기술은 우리 생각보다 빠르게 확산되어 가고 있는지도 모른다.
<자료 제공 : 클라우드 전문기업 케이아이엔엑스(KINX)> 노규남 클라우드사업담당 이사 bardroh@kinx.net
