멀티 클라우드의 필요성이 부각되는 요즘, 왜 멀티 클라우드가 필요한가?

AWS 서울 리전의 장애, 그리고 멀티 클라우드의 필요성 부각

2018년 11월 22일 오전 10시쯤, 인기 게임인 베틀그라운드에 접속이 되지 않는 황당한 일이 벌어졌다. 게임 자체가 접속이 안되는 것이다. 게임을 하고자 하는 사람들은 배틀그라운드 게임 자체에 장애가 있음을 인지했다. 배틀그라운드 공식 카페에 가보니 공지가 올라와 있었다. 오전 9시 30분부터 오전 11시까지 긴급 점검을 한다는 공지였다. 뭔가 문제가 있다는 것을 알 수 있었다. 바로 밝혀진 내용이지만 배틀그라운드를 제공하는 서비스 서버가 있는 아마존 웹서비스(AWS)의 문제로 인해 서비스 접속이 되지 않는 것이었다. AWS의 문제는 11시 조금 넘어서 해결이 되었다.

배틀그라운드 뿐만이 아니다. 국내 수많은 서비스들이 AWS의 장애로 인해 서비스 접속이 되지 않는 불편을 겪었다. 한국에 있는 아시아권의 5번쨰 AWS 리전인 AWS 서울 리전에서 장애가 생겼고 그것으로 인해 AWS 서울 리전에서 클라우드 서비스로 서비스 서버를 운영하던 수많은 국내 서비스들이 접속 장애를 일으킨 것이다. 참고로 AWS 서울 리전 내 서버 자체의 장애는 아니었고 클라이언트에게 서비스 서버의 IP를 제공하는 DNS(도메인 네임 서비스) 시스템의 문제였다. 하지만 어찌되었던 AWS 서울 리즌의 문제로 인해 불편을 겪었고 이 사건으로 인해 국내에 다시 한번 클라우드 서비스에 대한 회의론과 함께 멀티 클라우드에 대한 관심이 높아지기 시작했다.

클라우드 서비스에 대한 회의론은 그동안 클라우드 서비스 사업자들이 마케팅 전략으로 내세운 장애 상황에 대한 대처가 이번 AWS 서울 리전의 장애 대응 행태를 통해 완전히 무너졌기 때문에 클라우드 서비스가 안전하다는 것은 신뢰하지 못하며 서비스 업체 스스로 시스템 자원을 보호해야 한다는 얘기다. 충분히 생각해 볼 수 있는 문제이기는 하지만 요즘 대부분의 기업들이 IT 자원 관리의 편의성 및 여러가지 돌발 상황에 대한 능수능란한 대처를 위해 클라우드 서비스로 IT 자원(서비스 서버와 데이터 베이스 등 시스템들)을 옮기는 추세이고 대세로 굳혀하고 있는 상황에서 이런 회의론은 큰 힘을 발휘하지 못하고 있다.

대신 멀티 클라우드에 대한 필요성이 점점 부각되고 있는 상황이다. 멀티 클라우드는 하니의 클라우드 서비스를 이용하는 것이 아니라 2개 이상의 클라우드 서비스를 이용하는 것을 뜻한다. 그렇다면 멀티 클라우드의 필요성에 대해서 어떤 내용들이 흘러나오고 있는지 살펴보도록 하자.

왜 클라우드 서비스를 사용하는가?

멀티 클라우드에 대해서 논하기 전에 왜 기업들이 자사의 IT 자원들을 클라우드 서비스로 옮기려고 하는지에 대해서 살펴보자. 앞서 언급했듯 최근 추세는 기업들이 자신들이 직접 구축한 전산실 안의 IT 자원(서버, 데이터베이스 등)을 AWS나 MS의 에저, 구글 클라우드 플랫폼(GCP), IBM 클라우드 등의 이른바 퍼블릭 클라우드(Public Cloud)로 옮기는 것이다.

이유는 간단하다. 첫 번째로 IT 자원 관리의 용이성 때문이다. 전산실 안에 IT 시스템 인프라를 구축하거나 아니면 외부 IDC에 IT 시스템 인프라를 구축하는 경우(둘 다 자체 데이터센터를 구축하는 경우를 뜻하며 온프라미스 데이터센터라고도 부른다) 서버의 구입부터 그 안의 OS를 비롯한 다양한 소프트웨어에 대한 구입 및 서버에 설치 등을 모두 기업이 스스로 담당해야 한다. 거기에 외부 IDC가 아닌 자체 IDC이거나 전산실에 구축하는 경우에는 네트워크 구축 및 설정, 연결을 비롯하여 전원 시스템 구축에 이르기까지 처음부터 끝까지 모두 기업 담당자의 몫이다. 그나마 외부 IDC에 구축을 하는 경우에는 네트워크와 전원 관련 부분은 IDC에서 관리해주니 그 부분은 수고를 덜 수 있으나 그만큼의 관리 비용이 들어가게 된다. 그리고 서버 설치와 그 이후의 관리는 모두 기업의 IT 담당자의 몫이다. 서버의 경우 지속적으로 체크해서 불량이 생기면, 혹은 노후가 되면 교체해야 하며 교체 시 앞서 했던 설치 작업을 또 해야 한다. 담당 인력을 별도로 둬야 하기 때문에 인건비가 나가는 부분도 있다. 외부 IDC를 이용하는 경우에는 네트워크 및 전원 부분만 IDC가 관리해줄 뿐 서버 등의 자체 장비에 대한 관리는 고스란히 기업 IT 담당자의 몫이다. 하지만 퍼블릭 클라우드를 이용하게 되면 서버 설치 및 네트워크 설치, 전원 관리 등은 모두 퍼블릭 클라우드 서비스 업체의 몫이다. 기업들은 해당 업체에서 제공하는 관리 툴을 이용하여 VM(가상머신)을 생성하고 거기에 OS와 소프트웨어를 설치하면 된다. 접속을 위한 IP도 제공해주며 직접 지정도 가능하다. 관리 툴에서 VM을 생성할 때 OS까지 포하하여 생성할 수도 있다. 이런 경우에는 필요한 소프트웨어만 설치해서 사용하면 된다. 심지어 OS에 데이터베이스까지 설치해서 나오는 VM도 제공한다. 기업 입장에서는 IT 관리 인력을 자체적으로 운영할 때와 달리 더 적은 인원으로 운영할 수 있다. VM이기 때문에 서버 노후화에 대해서 걱정할 필요도 없다. 물론 퍼블릭 클라우드 환경 역시 일반 서버들이 병렬로 연결되어 있고 그 위에 가상화 플랫폼을 올려서 사용하기 때문에 서버의 노후화가 있을 수 있지만 그것은 퍼블릭 클라우드 제공 업체의 몫이지 사용하는 기업의 몫은 아니다.

두 번째는 상황에 기민하게 대응할 수 있는 기민성 때문이다. 앞서 전산실이던 IDC든 자체적으로 데이터센터를 구축한 경우에는 구축 시 설치한 서버의 허용 용량에 따라 서비스의 성능이 결정된다. 여기서 얘기하는 성능은 동시 접속자 수나 내부에서 처리할 수 있는 프로세스 용량을 의미한다. 예를 들어 100대의 서버를 이용해서 서비스를 구축하고 운영하고 있는 경우 100대의 서버가 허용하는 트래픽이 예를 들어 10TB, 동시 접속자는 10만이라고 했을 때 갑자기 서비스에 100만의 사용자가 동시에 접속을 시도한다면, 또 50TB의 트래픽이 서비스 서버에 갑자기 몰려든다면 어떻게 해야 할까? 자체 데이터센터를 구축했을 경우에는 서버를 구입하고 또 거기에 OS와 소프트웨어를 설치하고 그 이후에 기존 서버들과 연결하여 서비스의 허용 범위를 늘릴려고 할 것이다. 문제는 이 작업이 빨리 진행되지 않는다는 것이다. 서버를 구입하는 것이 그렇게 빨리 진행되지도 않을 뿐더러 혹여나 여분의 서버가 있다고 해도 거기에 OS 및 소프트웨어를 설치해서 연결하는 과정 및 시간이 만만치 않다. 아마도 서버 증설이 끝나기 전에 사용자들은 서비스의 불안정으로 인해 해당 서비스를 떠날 가능성이 높을 것이다. 그런데 퍼블릭 클라우드에 구축했을 경우에는 어떨까? 앞서 언급했듯 서버 설치가 퍼블릭 클라우드 서비스에서 제공하는 관리 툴에서 VM을 생성하는 것으로 손쉽게 진행될 수 있다. 물론 처음부터 VM을 생성하고 거기에 소프트웨어를 설치하고 기존 VM에 연결하는 과정과 시간도 결코 무시할 수 없을 것이다. 하지만 자체 데이터센터에서 진행하는 그 작업에 비하면 1/100 수준으로 시간 및 노력이 줄어든다. 그리고 처음부터 VM을 설치하는 것이 아닌 기존에 서비스하고 있던 VM을 복사하고 설정을 바꿔서 연결하면 처음부터 VM을 설치해서 하는 그 작업에 비해 적어도 1/10 수준으로 시간 및 노력이 더 줄어든다. 그 반대의 경우도 마찬가지다. 100대의 서버로 운영을 하고 있었는데 트래픽과 동시 접속자에 여유가 있어서 20대의 서버로만 운영해도 되는 상황이라면 어떻게 할까? 자체 데이터센터를 운영하는 경우에는 80대의 서버의 전원을 내릴 것이다. 뭐 나중에 다시 필요할 때 전원을 켜서 사용하면 되겠지만 그렇지 않는 경우에는 80대의 서버는 잉여 서버가 되며 쓸데없는 비용 및 공간을 낭비하게 되는 꼴이 된다. 하지만 퍼블릭 클라우드를 이용하게 된다면 어떻게 될까? 100대의 VM에서 80대의 VM을 삭제하면 된다. 퍼블릭 클라우드의 경우 VM의 개수 및 트래픽 사용량에 따라 과금하기 때문에 기업은 80대의 VM 사용비를 절약할 수 있게 된다. 나중에 필요하면 VM을 더 늘리면 된다.

이것 외에도 여러 이유들이 있을 것이다. 하지만 앞서 언급한 2가지 이유가 가장 큰 이유가 아닐까 싶다. 둘 다 비용적인 이유이며 기업 입장에서는 어쩌면 가장 중요한 부분이기 때문에 기존 자체 IT 인프라를 이용하는 것보다 퍼블릭 클라우드 서비스를 이용하는 것이 훨씬 더 저렴하고 효율적이라고 판단했기 때문에 최근 추세가 퍼블릭 클라우드로 이동하는 것이 아닐까 싶다. 물론 프라이빗 클라우드(Private Cloud)를 구축해서 운영하는 기업들도 많이 생기고 있지만 대부분이 대기업 위주고 중소기업이나 벤처기업의 경우에는 관리 및 비용적인 이유로 프라이빗 클라우드 구축보다는 퍼블릭 클라우드에 자리를 잡고 서비스를 운영하는 경우가 더 많은 것이 현실이다.

싱글 클라우드의 문제점

싱글 클라우드(Single Cloud)라 함은 하나의 클라우드 서비스를 이용하는 것을 의미한다. 여기서 얘기하는 하나의 클라우드 서비스는 하나의 리전을 의미한다. 예를 들어보자. A라는 기업이 a1이라는 서비스를 운영하기 위해 AWS에 가입하고 AWS를 이용하여 서비스를 제공하려고 할 때 A의 서비스 담당자는 먼저 AWS의 리전을 선택하게 될 것이다. 여기서 얘기하는 AWS의 리전은 AWS 서비스를 제공하는 AWS에서 운영하는 클라우드 IDC를 의미한다. AWS의 경우 전 세계적으로 수십개에 이르는 리전을 제공하고 있으며 서론에 언급한 AWS 서울 리전 역시 AWS 리전 중 하나로 아시아에서 5번째로 생긴 리전이다. A 기업 담당자는 서울 리전을 선택했다. 그 뒤에 어떤 상품을 통해 서비스를 제공받을 것인지를 선택하게 된다. 여기서 한가지 알 수 있는 것은 AWS라고 하더라도 전세계적으로 공통적으로 서버들을 사용하지는 않는다는 것이다. A 기업에서 제공하려는 a1이라는 서비스의 서비스 서버는 AWS 서울 리전이 있는 IDC에 VM으로 생성되어 운영되게 된다. 물론 인터넷으로 연결되어 있기 때문에 전세계 어디에서라도 접속이 가능하다. 하지만 해당 서버의 물리적인 위치는 서울에 있는 AWS 서울 리전 IDC라는 점이다.

앞서 AWS 서울 리전의 DNS 장애로 인해 해당 리전에서 서비스를 하고 있던 수많은 국내 서비스들이 접속 장애가 일어난 것을 언급했다. 물론 VM 자체이 문제도 아니고 VM을 동작시키는 서버의 문제도 아니다. DNS의 문제일 뿐이었다. 하지만 접속이 되지 않았다(참고로 아마존 DNS를 사용하지 않고 타 DNS를 사용하고 AWS 서울 리전에서 VM을 이용하여 서비스를 제공했던 기업들의 서비스는 문제없이 정상 동작을 했다). 만약 AWS가 리전에 상관없이 VM들을 전세계 어느 리전에서도 쓸 수 있게 설계를 했더라면 이런 문제는 없었을 것이다. 하지만 구조상으로 그렇게 되지 않았다. 이는 AWS 뿐만이 아니라 모든 퍼블릭 클라우드 서비스가 공통적으로 갖고 있는 문제다. MS의 에저 역시 서울과 부산에 리전을 갖고 있는데 서울 리전에 VM을 생성해서 쓰고 있는 상황에서 서울 리전에 문제가 생기면 마찬가지로 서비스 장애가 일어날 것이다. 우리가 흔히 클라우드 서비스라고 해서 구름 안에 데이터를 던져두면 전세계 어디에서 맘대로 꺼내고 쓸 수 있을 것이라고 생각하는데 물론 해당 서비스의 서버가 있는 클라우드 IDC가 문제가 없으면 인터넷으로 연결이 되어 있기 때문에 아무런 문제없이 데이터를 주고 받을 수 있지만 그 안에서는 앞서 언급한 것처럼 물리적으로 분명한 공간이 있고 해당 공간에 문제가 생기면 아무리 클라우드라고 하더라도 문제가 생길 수 밖에 없다는 얘기다.

그 외에도 다양한 문제점이 있다. 앞서 AWS 서울 리전의 문제는 다행히 서울 리전에 국한하여 문제가 생겼지만 만약에 AWS 관리 툴에 취약점이 발견되어 그 취약점을 노려서 전 세계의 모든 AWS 서비스에 장애를 일으킨다면 어떻게 될까? 이럴 경우에는 AWS 서울 리전이 문제가 되는 것이 아니라 AWS 서비스 자체가 문제가 되며 전 세계 AWS가 다 장애가 일어나는 대형 사고로 이어질 것이다. 애플과 MS와 같은 대형 IT 기업들도 AWS를 이용하고 있으며 수많은 국내외 스타트업들이나 중소기업들, 또 대기업들이 AWS를 이용하고 있기 때문에 그 피해 규모는 어마무시할 것이라 예상이 된다. 이런 예 말고도 다양한 문제점들이 있을 수 있다. 그래서 하나의 클라우스 서비스, 즉 싱글 클라우드만으로는 안심하지 못한다고 얘기를 하고 멀티 클라우드를 강조하고 있는 것이다.

멀티 클라우드의 종류

서론에서 잠깐 언급했지만 멀티 클라우드(Multi Cloud)의 의미는 2개 이상의 클라우드 서비스를 이용하는 것을 의미한다. 앞에서 싱글 클라우드에 대해서 언급을 했는데 멀티 클라우드는 싱글 클라우드를 2개 이상 이용하는 것을 일반적으로 의미한다. 여기서 일반적이라고 언급한 이유는 멀티 클라우드에 대해서 얘기하고 있는 업체들마다 멀티 클라우드에 대한 정의가 조금씩 다르기 때문이다. 여기에 하이브리드 클라우드와 프래그머틱 하이브리드 클라우드라는 용어도 함께 나온다. 다 큰 의미에서 멀티 클라우드의 범주에 속하는데 업체들마다 자사의 솔루션에 맞춰서 용어를 만들어 마케팅을 하고 있는 셈이다. 일단 기본적으로 멀티 클라우드는 '1개의 퍼블릭 클라우드 + a'라고 보면 되며 그 a에 어떤 것이 들어가느냐에 따라 하이브리드 클라우드냐 프래그머틱 하이브리드 클라우드냐로 또 나뉜다고 보면 된다.

멀티 클라우드

일반적으러 멀티 클라우드라고 하면 2개 이상의 퍼블릭 클라우드 서비스를 이용하는 것을 의미한다. 예를 들어 AWS를 이용하고 있는 가운데서 MS 에저를 이용하는 것을 의미하며 AWS를 이용하면서 IBM 클라우드를 함께 이용하는 것을 의미한다. 서로 다른 벤더의 퍼블릭 클라우드 서비스를 2개 이상을 운영하는 것이 일반적으로 많은 벤더들이 얘기하는, 또 일반 사람들이 알고 있는 멀티 클라우드 서비스의 정의라고 보면 된다.

여기에 또 하나의 변수가 있다. 앞서 언급했듯 퍼블릭 클라우드 서비스를 이용한다고 하더라도 리전에 종속될 수 밖에 없는 구조이기 때문에 AWS를 쓴다고 하더라도 엄밀히 따지면 글로벌로 쓰는 것이 아니다. 그렇기 때문에 같은 AWS 서비스를 쓴다고 하더라도 서울 리전을 사용하는 것과 캘리포니아 리전을 사용하는 것, 도쿄 리전을 사용하는 것은 엄밀히 따지면 다른 서비스를 사용하는 것과 마찬가지다. 그래서 2개 이상의 다른 리전을 사용하는 것도 어떻게 보면 멀티 클라우드라고 얘기하는 전문가들도 있다. 즉, 같은 퍼블릭 클라우드 서비스를 이용하더라도 서로 다른 리전을 사용하여 물리적으로, 또 지리적으로 VM의 위치를 다르게 이용한다면 이것 역시 멀티 클라우드의 범주에 들어갈 수 있다고 본다.

하지만 일반적으로는 서로 다른 벤더의 퍼블릭 클라우드 서비스를 2개 이상 이용하는 것을 가장 일반적인 멀티 클라우드라고 얘기를 한다.

하이브리드 클라우드

하이브리드 클라우드(Hybrid Cloud)는 퍼블릭 클라우드 서비스와 함께 프라이빗 클라우드 서비스를 함께 이용하는 것을 의미한다. 말 그래도 하이브리드로 퍼블릭과 프라이빗의 결합, 연동을 의미한다고 보면 된다. 예를 들어 A라는 기업이 a1이라는 서비스를 운영하는데 있어서 AWS를 이용하면서 동시에 A사가 자체적으로 구축한 IDC에, 혹은 타 IDC에 프라이빗 클라우드 서비스를 구축하고 그 프라이빗 클라우드 서비스에 a1이라는 서비스를 함께 운영한다면 이것이 하이브리드 클라우드 서비스인 것이다.

일반적으로 클라우드 서비스라고 하면 퍼블릭 클라우드 서비스를 의미하지만 국내외 수많은 대기업들이 프라이빗 클라우드 서비스를 구축하여 운영하고 있다. 이유는 시스템 자원 안에 들어있는 데이터의 관리 및 보안 등을 아마존이나 MS, 구글, IBM 등의 클라우드 서비스 벤더에게 맡기는 것에 대해서 불안감을 느끼는 기업들의 기본적인 생리 때문이다. 자신들의 기밀 데이터, 중요 데이터가 저장되어 있는 서버가 자신들의 관리 하에 있는 것이 아니라 다른 벤더에게 있다는 것 자체에 불안감을 느끼기 때문에 자체적으로 클라우드 서비스를 만들어서 자신들이 관리하도록 하는 것이 프라이빗 클라우드 서비스의 핵심이다. 물론 이렇게 됨으로 앞서 언급한 첫 번째 장점이라 불리는 시스템 자원의 관리에 대한 매리트는 사라지지만 두 번째 장점이라 불리는 기민성은 유지할 수 있다. 프라이빗 클라우드 서비스의 장점은 클라우드 서비스의 다양한 정책을 서비스 제공 벤더가 정의하는 것에 따르지 않고 스스로 만들어서 적용할 수 있다는 점이다. 그렇기 때문에 많은 기업들이 프라이빗 클라우드 서비스를 만들어서 자사의 IT 인프라에 적용하고 있다.

하이브리드 클라우드 서비스는 퍼블릭 클라우드 서비스와 함께 프라이빗 클라우드 서비스를 함께 이용하는 것을 일반적으로 얘기한다.

프래그머틱 하이브리드 클라우드

프래그머틱 하이브리드 클라우드(Pragmatic Hybrid Cloud)는 이름 조차 무척이나 길고 생소한데 앞서 언급한 하이브리드 클라우드의 한 종류라고 보면 된다. 프래그머틱 하이브리드 클라우드는 퍼블릭 클라우드에 기존 기업들이 구축해 놓은 자체 데이터센터를 연동하는 방식을 의미한다. 자체 데이터센터는 앞서 언급했듯 서버, 데이터베이스 등의 시스템 자원들과 다양한 네트워크 장비들을 전산실이나 혹은 IDC에 구축해서 자체적으로 운영하는 시스템을 의미하며 보통 레거시 시스템이라고도 많이 얘기하는데 클라우드 서비스가 활성화 되기 이전에는 모두 이런 레거시 시스템을 이용했다. 즉, 프래그머틱 하이브리드 클라우드는 AWS나 MS 에저와 같은 퍼블릭 클라우드를 이용하면서도 동시에 자체 데이터센터를 통해서 레거시 시스템을 운영하는 것을 의미한다고 보면 된다.

일반적으로 프래그머틱 하이브리드 클라우드는 하이브리드 클라우드의 범주 안에 들어가지만 같은 부류의 클라우드 서비스를 이용하는가, 아니면 자체 데이터센터를 이용하는가를 구분하기 위해 일부 밴더들이 나눠놓은 개념이라고 보면 된다.

왜 멀티 클라우드가 힘을 받고 있는가?

가장 기본적인 이유는 앞서 언급한 싱글 클라우드의 문제점을 해결하기 위함이다. 자체 데이터센터를 이용하는 것과 클라우드 서비스를 이용하는 것은 이용하는 인프라 자체가 자체 구축인가 아니면 이미 구축된 인프라를 사용하는가, 그리고 그 안의 다양한 시스템 자원을 물리적인 하드웨어로 직접 구성해서 사용하는가 아니면 가상화 방식을 이용하여 VM으로 이용하는가의 차이다. 물론 앞서 설명했던 것처럼 물리적인 하드웨어를 사용하게 되면 트래픽이 많아져서 시스템 자원을 늘리거나 트래픽이 줄어들어서 시스템 자원을 줄일 때 여러가지 불편함이 있지만 클라우드 서비스 환경에서 VM을 이용하게 되면 이 부분이 손쉽게 해결될 수 있다. 또한 방화벽, IDS, IPS, L4 스위치 등의 보안장비 및 기타 네트워크 장비 역시 자체 데이터센터의 경우 직접 구축해야 하지만 클라우드 서비스를 이용하면 해당 클라우드 서비스에서 제공하는 기능을 이용하면 된다. 하지만 기본적으로 시스템이 가져가야 하는 구성들, 즉 인터넷 서비스를 제공한다면 웹 서버가 필요하고, 데이터를 보관하는 데이터베이스 서버도 필요하며 이들 서버가 1대로 처리할 수 없으니 2대 이상으로 로드밸런싱 용, 혹은 이중화 용으로 구성을 해야 한다. 즉, 물리적 하드웨어가 VM으로 변경이 되는 것일 뿐 그 안의 네트워크 환경을 잡는다던지 시스템 자체의 구성은 기존 데이터센터에서 구축하는 것과 다를 것이 없다는 얘기다.

그리고 싱글 클라우드의 문제점에서 얘기했듯 이 모든 설정들이 리전 단위로 진행이 된다는 것이다. 클라우드 서비스를 이용하여 서비스 서버 시스템을 구축했다고 하더라도 해당 서버 시스템은 클라우드 서비스의 사용자가 지정한 리전에만 구축이 되어 있는 상황이다. 예를 들어, AWS에서 구축을 한다고 하더라도 처음에 서울 리전을 선택하고 거기에 AWS 상품을 사서 구축을 했다면 서비스 서버 시스템은 AWS 서울 리전이 구축된 AWS 서울 리전 클라우드 IDC에만 구축이 되어 있다는 것이다. 접속은 인터넷이 연결되는 모든 지역에서 가능하지만 AWS 서울 리전이 구축된 클라우드 IDC 전체가 장애로 인해 서비스가 제공되지 않는 상황이 벌어진다면? 아무리 클라우드 서비스에 서비스 서버 시스템을 구축했다고 하더라도 해당 서비스를 사용할 수 없는 상황이 오게 된다는 것이다.

서론에 언급했던 AWS 서울 리전의 DNS 장애 문제 외에도 해외의 경우 허리케인이나 태풍, 지진, 산불, 그 외의 다양한 자연재해로 인해 클라우드 IDC 센터 자체에 장애가 발생하는 경우가 많다. 지진이 많은 일본도 그렇고 허리케인이나 산불이 많은 미국 역시도 클라우드 IDC 센터가 종종 장애를 일으키고 있다고 한다. 자연재해 뿐만이 아니다. 관리자의 실수로 인해, 혹은 해커들의 공격으로 인해 클라우드 IDC 센터가 장애를 일으키는 일들은 많다. 물론 해당 클라우드 서비스 전체가 공격을 받고 장애를 일으키는 상황은 거의 없지만 특정 리전에 대해서는 자주 일어나는 일이다. 클라우드 서비스 전체로 봤을 때에는 큰 문제가 아니라고 생각할 수도 있다.

하지만 앞서 언급한 것처럼 사용자가 자신들의 서비스를 제공하기 위해 클라우드 서비스 안에 자신들의 IT 인프라를 구축하는데 그 대상은 클라우드 서비스 전체가 아닌 특정 리전이 된다. 사용자 입장에서는 앞서 언급한 자연재해, 관리자의 실수, 해커의 공격으로 인해 특정 리전의 클라우드 IDC 센터가 장애를 일으키게 되면, 그리고 그 클라우드 IDC 센터 안에 자신들의 서비스 서버 시스템이 구축되어 있다면 상당히 심각한 문제가 야기된다.

그렇기 때문에 싱글 클라우드 하나, 리전 하나만 사용하지 말고 2개 이상의 멀티 클라우드를 이용해서 이런 장애에 대해서 대응해야 한다는 주장이 힘을 받게 되는 것이다. 서비스 서버 시스템을 2개 이상의 서비스 인프라에(퍼블릭 클라우드가 되었건 프라이빗 클라우드가 되었건 혹은 자체 데이터센터를 이용하건간에) 구축해 놓는다면 어느 한쪽이 문제가 생겼을 경우에도 다른 서비스 인프라를 통해 일반 클라이언트들에게 인터넷 서비스가 제공되는데에는 문제가 되지 않기 때문이다. 우리가 보통 시스템의 장애에 대비하여 마스터-슬레이브 방식으로 2중화를 진행하는데(마스터가 장애를 일으키면 슬레이브가 마스터 역할을 함으로 서버 운영에 문제가 없게 하는 방식) 서비스 인프라 자체를 이렇게 2중화 해야 하며 그것을 멀티 클라우드 방식으로 하자는 얘기가 된다.

멀티 클라우드에서 신경을 써야 할 부분

일반적으로 서비스 서버 시스템을 구축할 때 서버의 장애에 대응하기 위해 서버 2중화를 고려하여, 혹은 서비스 서버의 부하를 줄이고 안정성 높은 서비스를 제공하기 위해 로드밸런싱 목적으로 2대 이상의 서비스 서버를 둔다. 그렇기 때문에 서비스 서버 앞에 L4 스위치를 두고 로드밸런싱을 하던지 마스터-슬레이브 스위칭을 하던지 한다. 즉, 클라이언트가 인터넷 서비스를 제공받기 위해 DNS에 해당 서비스 서버의 정보를 요청할 때 서비스 서버의 정보가 오는 것이 아닌 그 앞단의 L4 스위치의 정보가 오는 경우가 많다. 보통 L4 스위치는 로드밸런싱을 하기 위해 많이 사용하는데 2대 이상의 서비스 서버를 연결하고 L4 스위치는 자신에게 연결된 서비스 서버의 상태를 체크하여 클라이언트가 연결을 요청하면 상태가 가장 좋은 서비스 서버로 연결하는 역할을 담당한다. 아니면 마스터-슬레이브 방식에서는 L4 스위치는 마스터 역할을 하는 서비스 서버로 클라이언트의 연결 요청이 오면 연결을 시켜주다가 마스터 역할을 하는 서비스 서버에 문제가 생기면 슬레이브 역할을 하는 서비스 서버로 클라이언트의 연결 요청을 처리하는 역할을 하기도 한다. 즉, 서비스 서버의 서비스 인프라라고 하면 서비스 서버들과 함께 L4 스위치까지 포함하여 얘기를 많이 한다. 싱글 클라우드나 자체 데이터센터를 이용하여 구축할 때에도 이렇게 진행한다.

멀티 클라우드라 함은 이런 서비스 인프라의 다중화를 의미한다. 싱글 클라우드의 경우 클라이언트가 서비스 서버의 정보를 요청할 때 싱글 클라우드 안의 해당 서비스 서버 인프라의 L4 스위치 정보를 전달해주면 되지만 멀티 클라우드에서는 어느 클라우드 서비스의 서비스 인프라로 가야 하는지에 대한 컨트롤 타워가 필요하다. 즉, 각 서비스 인프라의 상태를 늘 체크해서 클라이언트의 요청에 대해 어느 서비스 인프라에 있는 서비스 서버에 연결할 것인지에 대해서 제어를 해주는 별도의 시스템이 필요하다는 얘기다. 이 부분에 대해서는 여러가지 방법이 있을 수 있다. 서비스 인프라에 대해서 주기적으로 체크해서 상태가 안정적인 서비스 인프라에 대한 정보를 DNS에 주기적으로 반영해주는 방식(현재로서는 이 방식이 가장 많이 쓰인다)이 있고 또 하나는 앞서 싱글 클라우드에서 L4 스위치가 하는 역할처럼 클라이언트가 서비스 서버의 정보를 DNS에 요청할 때 별도의 서비스 인프라를 선택할 수 있는 최상단의 어떤 스위칭 장비의 정보를 제공하여 해당 스위칭 장비가 상태가 좋은 서비스 인프라로 이동시키겠끔 하는, 아니면 로드밸런싱을 하는 그런 방법도 있다. 현재는 전자의 방법을 가장 많이 사용하고 있는데 후자의 경우 최상단의 해당 스위칭 장비에 문제가 생기면 전체 서비스에 문제가 생기기 때문에 잘 사용하지 않는다. 어찌되었던 서비스 인프라 선택을 위한 스위칭 방식이 필요하며 별도의 추가 작업이 필요하다는 얘기다.

또한 데이터베이스의 데이터 동기화도 고려를 해야 한다. 싱글 클라우드의 경우에도 데이터베이스를 2중화 하게 되면 2대 이상의 데이터베이스 서버가 그 안의 데이터들을 동일하게 유지하기 위해 다양한 방법을 이용하게 된다. 오라클의 경우 RAC라는 데이터베이스 이중화 솔루션을 제공하기도 하며 MySQL이나 MariaDB의 경우 리플리케이션이나 클러스터링 방식을 이용하기도 한다. MS SQL 서버 역시 리플리케이션 방식을 제공한다. 그런데 보통 서비스 인프라에 데이터베이스 서버 역시 함께 두는 것이 일반적인데 멀티 클라우드를 하게 되면 마찬가지로 데이터베이스 역시 각 클라우드 서비스에 각기 별도로 둬야 한다. 그리고 이 데이터베이스들에 있는 데이터들도 서로 동일하게 맞추는 것을 고려해야 한다. 그래야 어느 하나의 클라우드 서비스에 문제가 생긴다고 하더라도 다른 클라우드 서비스를 통해서 서비스를 제공받을 때 문제가 없다. 즉, 데이터베이스 동기화 방식이 필요하며 이에 대한 별도의 추가 작업 역시 필요하다는 얘기다.

그리고 가장 중요한 부분인데 물리적인 거리 역시 심각하게 고려를 해야 한다. 앞서 멀티 클라우드가 필요한 이유로 자연재해가 있었는데 이런 자연재해는 지역 단위로 일어나게 된다. 그런데 만약 서로 다른 밴더의 클라우드 서비스로 멀티 클라우드를 구축하였다고 하더라도 같은 지역에 있는 다른 클라우드 IDC에 멀티 클라우드를 구축했다고 치자. 해당 지역에 지진이나 허리케인이 발생하여 그 2개의 클라우드 IDC에 모두 문제가 생긴다면 멀티 클라우드를 구축한 의미가 없다. 멀티 클라우드를 구축할 때에는 적어도 200km 이상 떨어진 지역의 클라우드 IDC가 있는 클라우드 서비스를 선택하는 것이 안정적이다. 400km 이상이면 더욱 좋고 말이다(400km라면 서울에서 부산의 거리인데 만약 서울에서 지진이 나도 부산까지는 영향을 줄 가능성이 크지는 않으니까 말이다). 보통은 국가를 아예 달리 해서 멀티 클라우드를 구축하는 것을 추천한다. 한국에 있는 AWS에 서비스 인프라를 구축했다면 싱가폴에 있는 MS 에저에 멀티 클라우드로 서비스 인프라를 구축한다던지, 한국에 있는 MS 에저에 서비스 인프라를 구축했다면 일본에 있는 AWS에 멀티 클라우드로 서비스 인프라를 구축한다던지 하는 것이 좋다는 얘기다. 미국의 경우 땅이 크니 캘리포니아에 있는 클라우드 서비스에 서비스 인프라를 구축했다면 멀티 클라우드로 뉴욕에 있는 다른 밴더의 클라우드 서비스에 서비스 인프라를 구축하는 것도 좋은 방법이 될 수 있다.

그런데 문제는 한국의 경우 약간 예외가 생기게 된다. 다름아닌 개인정보 관련 내용인데 국내법 상 개인정보가 들어있는 데이터베이스는 반드시 한국 소재의 서버에 구축하도록 하고 있다. 서비스 서버 자체는 다른 국가의 클라우드 서비스를 이용할 수 있다고 하더라도 데이터베이스는 국내에 있는 클라우드 서비스나 아니면 국내에 위치한 데이터센터에 구축해야 한다는 것이다. 물론 개인정보의 종류에 따라 해외에 데이터를 유치할 수도 있지만 개인식별이 가능한 개인정보의 경우 아직까지는 국내 유치만 허용하고 있다. 현재 관련 법안에 대한 개정이 진행되고 있지만 처리까지는 시간이 필요하다. 그래서 한국의 경우 멀티 클라우드를 이용하기 위해서는 물리적인 거리 부분을 어쩔 수 없이 무시해야 하는 경우도 생기게 된다. 방법이 아예 없는 것은 아니다. AWS 서울 리전과 MS 에저 부산 리전을 이용하는 방법이 있다. 아니면 데이터베이스의 경우에는 자체 데이터센터를 이용하고 서비스 서버만 멀티 클라우드를 적용하는 방법도 있는데 어떤 방법을 사용하는가는 서비스를 제공하고자 하는 사용자의 상황에 따라 선택해야 할것이다.

서비스의 안정적인 제공을 위해 멀티 클라우드는 이제 필수가 되어 가는데..

이전에 클라우드 서비스가 활성화되기 전에 자체 데이터센터에서 서비스 인프라를 구축하여 제공할 때에는 서비스의 안정성을 위해 서버 이중화는 필수로 구축해야 했다. 이제 서비스 인프라의 환경이 자체 데이터센터에서 클라우드 서비스로 넘어오면서 이런 안정성을 클라우드 서비스에서 어느정도 제공할 것으로 기대를 했지만 이번 AWS 서울 리전의 장애 사태도 그렇고 지진이나 허리케인 등의 자연재해로 클라우드 서비스의 클라우드 IDC가 장애를 일으키면서 그 위에 구축한 서비스 인프라 역시 장애를 일으키는 것을 보게 됨으로 결코 클라우드 서비스도 안전에 완벽한 솔루션이 아님을 확인하게 되었다. 즉, 100% 완전한 시스템, 버그 없는 시스템은 없다는 얘기다.

이런 이유로 서버 이중화에 이어 이제는 서비스 인프라의 이중화, 즉 클라우드 서비스의 이중화가 필수가 되어 가고 있다는 얘기가 된다. 지금은 멀티 클라우드가 서비스 제공 업체의 사정에 따라 선택할 수 있는 옵션 사항처럼 보일 수 있겠지만 조만간 선택이 아닌 필수가 될 것이라고 많은 전문가들이 예측하고 있는데 서버 이중화가 필수가 된 것과 같은 맥락에서 멀티 클라우드 역시 필수가 될 것이라는 얘기다. 자체 데이터센터에서 클라우드 서비스로 서비스 인프라의 기반이 되는 플랫폼은 변경되었지만 서비스를 제공하기 위한 시스템 자체가 갖고 있는 속성, 성질은 변하지 않았기 때문에 자체 데이터센터에서 진행했던 보안 작업을 클라우드 서비스에 맞게 확대해서 작업하는 상황이 되었고 그것이 멀티 클라우드라는 이름으로 지금 제시가 되고 있다고 보면 될 것이다.

그렇기 때문에 당장은 아니지만 조만간 멀티 클라우드는 선택이 아닌 필수가 될 것이라고 본다. 이에 대한 대비 역시 지금부터 충분히 해야 하지 않을까 싶다.

본 내용은 디지에코에 보고서로 제출한 내용을 블로그로 옮긴 글이다. 디지에코 보고서는 [여기]를 누르면 확인할 수 있다.