AWS 서울 리즌 장애를 통해 살펴본 멀티 클라우드 구축에 대한 이야기

AWS 서울 리즌 장애

글을 쓰는 시점에서 어제 아침(11월 22일)에 아마존 웹서비스(AWS)의 한국 리즌에서 문제가 생겨서 AWS 한국 리즌을 쓰는 많은 기업들이 서비스에 접속이 안되는 초유의 사태가 벌어졌다. 쿠팡을 비롯하여 국내 여러 게임 서비스가 대략 1시간반 정도 접속에 문제가 있었다고 한다. 뭐 지금은 이미 다 복구가 되었지만 어찌되었던 불편했던 것이 사실이다.

일단 AWS에서 밝힌 장애 원인은 DNS 문제라고 한다. DNS가 문제가 되니 웹브라우저에서 도메인으로 접속을 해도 서비스 서버의 IP를 알 수 없어서 서비스 접속 장애가 생기는 상황이었으니 무척이나 큰 문제라고 할 수 있다. 보통 DNS 장애는 DDoS 공격으로 인한 장애가 일반적이기는 한데 AWS는 그 이유는 아닌 것 같고 아마도 다른 이유로 DNS 장애가 있었던 것 같다. 여하튼 지금은 다 복구되었으니 다행이지만 말이다.

우리쪽 문제가 아닌 다른 문제로의 장애는 머리가 아프다 -.-;

멀티 클라우드 등판 시작

이번 AWS의 장애로 인해 여러 이야기들이 나오고 있는데 특히나 멀티 클라우드에 대한 얘기가 나오고 있다. 멀티 클라우드 얘기는 이번 AWS 사태(?)가 아니어도 지속적으로 나오는 얘기이기는 하다. 어느 하나의 클라우드 서비스에 다 맡기기 불안하니 여러 클라우드를 동시에 이용해서 만약의 사태에 대비하자는 얘기다. 말은 좋은데 말이지.

멀티 클라우드에 대해서 간단히 얘기한다면 인터넷 서비스 서버를 클라우드 서비스 위에 올리게 되면 보통은 예를 들어 AWS라고 한다면 AWS의 캘리포니아 리즌, 아니면 도쿄 리즌 등 어느 리즌을 정해서 그 리즌에 있는 AWS 클라우드 IDC에 가상머신(VM)을 만들고 서비스 서버를 해당 VM에 올리는 것을 얘기한다. 이번에 문제가 된 서비스들은 다 AWS 서울 리즌에 VM을 만들고 거기에 서비스 서버를 올렸다고 보면 된다.

단일 벤더에서의 멀티 클라우드

멀티 클라우드는 일단 AWS 입장에서 본다면 서울 리즌 뿐만이 아니라 도쿄 리즌에도 설치하고 캘리포니아 리즌에도 설치해서 분산 처리하자는 것이다. 메인-서브 방식(액티브-스텐바이 방식이라고도 한다)으로 메인 서버를 서울 리즌에 두고 백업 서버를 도쿄 리즌에 두게 되면 보통은 서울 리즌의 서버에서 서비스를 제공하다가 서울 리즌에 문제가 생기면 도쿄 리즌의 백업 서버에서 서비스를 진행시키면 된다는 얘기다.

또 메인-메인 방식(액티브-액티브 방식이라고도 한다)으로 앞서 언급한 것처럼 서울 리즌과 도쿄 리즌에 서비스 서버를 두고 접속단 앞에 로드밸런싱 장비를 둬서 접속이 들어올 때마다 서울 리즌과 도쿄 리즌을 번갈아가며 접속하게 하는 것이다. 로드밸런싱 장비는 각 리즌의 상태를 체크하기 때문에 서울 리즌에 문제가 생기게 되면 로드밸런싱 장비는 서울 리즌이 아닌 도쿄 리즌에만 접속을 제공하게 된다. 그러면 서비스를 장애없이 사용할 수 있다는 얘기다.

다중 벤더를 이용한 멀티 클라우드

위의 얘기는 하나의 클라우드 서비스 벤더를 이용하는 경우(AWS)고 실제로 멀티 클라우드 서비스를 주장하는 사람들이 얘기하는 것은 같은 클라우드 서비스 벤더가 아니라 서로 다른 클라우드 서비스 벤더의 서비스를 이용하자는 얘기다. AWS를 쓰고 있다면 MS 에저로도 구축해놓고 구글 클라우드도 이용하고 IBM 클라우드도 이용하자는 얘기다.

이런 얘기가 나온 이유가 뭐 각 클라우드 서비스 벤더들이 자기들 서비스를 팔기 위한 마케팅이기도 하지만 어느 하나의 벤더 서비스에 종속이 되었을 때 해당 서비스 자체에 문제가 생기면 전체가 문제가 생길 수 있기 때문에 보안이나 인터페이스가 다른 다른 벤더의 서비스를 함께 사용한다면 적어도 보험 차원에서 문제에 대한 대응을 손쉽게 할 수 있다는 얘기다.

뭐 말은 쉽다. VM을 만들고 그 위에 서비스 서버를 올려서 돌리면 된다. 어차피 각 VM마다 IP는 다 제공해줄테니까 말이다. 앞서 로드밸런싱 방식을 이용하면 어느 하나의 벤더에, 혹은 지역에 문제가 생긴다고 하더라도 대응이 가능하다는 것이 이들 멀티 클라우드를 주장하는 사람들의 얘기인데 실제로 구축도 구축이지만 운영하는 입장에서는 정말로 힘들다.

서로 다른 인터페이스의 클라우드 서비스로 어떻게 멀티 클라우드를?

가장 큰 걸림돌은 각 클라우드 서비스를 관리하는 관리 인프라가 각기 다 다르다는 것이다. VM을 만들고 그 안에 접속하여 어플리케이션을 만들거나 실행하는 것은 비슷하거나 동일할 수 있다. 하지만 그 VM을 만드는 과정이나 거기에 IP를 설정하는 과정, 방화벽 등을 설정하는 과정, 용량이 모자를 때 늘리는 방법이나 반대로 줄이는 방법, 메모리를 늘리거나 줄이는 방법 등 VM의 관리적인 부분은 AWS, 구글 클라우드, MS 에저, IBM 클라우드가 모두 다 다르다. 그러다보니 해당 서비스의 서비스 관리자, 혹은 운영자는 멀티 클라우드를 적용하게 되면 해당 클라우드 서비스의 방식을 모두 알아야 하고 문제가 생겼을 때 대응도 각기 다 다르게 해야 한다는 불편함이 있다.

물론 그런 불편함을 해결해주는(?) 솔루션들도 있다. 멀티 클라우드 시대에 각 클라우드 서비스의 인터페이스에 다 맞춰서 통합적으로 관리하는 솔루션이 등장하고 있다. 가상화 솔루션 업체인 VMware도 멀티 클라우드 통합 솔루션을 제공해주고 있으며 최근에 IBM에 합병된 리눅스 업체인 레드헷 역시 이런 멀티 클라우드에 대응하는 방법을 제시하고 있다. 구글에 멀티 클라우드라고 검색하면 그 외에 수많은 멀티 클라우드 관련 서비스, 솔루션 들을 볼 수 있다. 이런 솔루션이나 서비스를 이용한다면 멀티 클라우드를 구축하는데 있어서 어느정도는 도움을 받을 수 있고 편리하게 관리가 가능할 것이다.

뭐 어찌되었던 단일 솔루션, 단일 벤더로는 위험하니 다중 솔루션, 다중 벤더를 이용하는 것이 좋다는 얘기다. 솔루션이든 서비스든 100% 완벽한 제품은 없으니 조금이라도 위험부담을 분산시켜 줄이자는 것이 멀티 클라우드를 주장하는 사람들의 논리이며 뭐 나 역시 어느정도는 수긍하는 편이다. 위험부담은 분산시켜 줄이는 것이 좋은 것은 맞으니까.

문제는 단일 벤더로 여러 리즌에 설치를 하든, 다중 벤더로 멀티 클라우드 시스템을 구축을 하든 돈은 2배, 혹은 그 이상으로 들어간다는 것이다. 물론 사고가 터져서 복구하는데 들어가는 비용을 고려한다면 미리 보험을 들어두는 것이 맞고 그렇게 본다면 앞서 언급한 멀티 클라우드 시스템(다중 리즌, 혹은 다중 벤더)을 구축하는 것이 맞을지도 모른다. 서비스 서버에 갑자기 몰리는 트래픽을 분산시켜 서비스의 퀄리티를 높이는 방법이기도 하고 말이다. 그런 식으로 생각해서 투자를 한다는 생각으로 접근한다면 괜찮을 듯 싶기도 하다.

멀티 클라우드 구축을 위한 조건?

그런데 이런 멀티 클라우드를 구축하는데 있어서 몇가지 조건들이 있다. 앞서 멀티 클라우드를 구축하는 이유가 장애로 인한 보험이라고 했는데 해킹이나 DDoS 공격 등으로 인한 장애도 문제지만 더 큰 문제는 다름아닌 자연재해다. 지진, 허리케인 등의 자연재해로 인해 클라우드 서비스의 IDC가 무너지거나 파괴되는 경우도 비일비재하다. 어떤 의미에서 멀티 클라우드 얘기가 나온 이유가 바로 이런 자연재해 등의 예기치 못한 장애로부터 대응을 빨리하자는 것도 있다.

그렇다보니 멀티 클라우드를 구축하는데 있어서 동일한 지역에 구축하는 것은 의미가 없다. 예를 들어 다중 벤더로 진행한다고 해도 관리자가 연락하기 편하려고 AWS 서울 리즌에 설치하고 MS 에저 서울 리즌에 설치하는 것은 의미가 없다는 것이다. 물론 해킹이나 DDoS 공격 등으로 AWS 서울 리즌에 문제가 생겼을 때 MS 에저 서울 리즌의 서버로 동작시키게 한다는 것은 의미가 있을지도 모르겠지만 예를 들어 서울 전체가 정전이 되어서 AWS 서울 리즌, MS 에저 서울 리즌이 모두 문제가 생긴다면, 아니면 태풍으로 인해, 혹은 지진으로 인해 둘 다 문제가 생긴다면 전혀 장애에 대한 대응이 되지 않는다. 물론 IDC는 예비 전력이 있기 때문에 정전이 되어도 하루나 이틀 정도는 문제없이 사용할 수 있지만 지진의 경우는 방법이 없는 것이 사실이다(물론 내진 설비는 해뒀겠지만).

그렇기 때문에 보통 멀티 클라우드를 구축할 때는 구축하고자 하는 서비스 리즌(그것이 같은 벤더나 서로 다른 벤더라 할지라도)간의 충분한 거리가 필요하다. 적어도 300km 이상은 차이가 나야 좀 안심할 수 있지 않을까 싶다. 그래서 AWS만 이용한다면 서울 리즌에 설치하고 가까운 도쿄 리즌에 설치한다던지, 아니면 미국의 켈리포니아 리즌에 설치한다던지 하면 되는 것이다. 다른 서비스 벤더를 이용한다고 하더라도 AWS 서울 리즌에 설치하고 MS 에저 싱가폴 리즌에 설치하는 것도 방법이다. 보통은 이렇게 지리적으로 확실히 떨어진 지역의 클라우드 IDC를 이용하는 것이 일반적이다.

한국에서의 멀티 클라우드 구축은?

그런데 국내법에 국내 개인정보관련 내용은 해외 반출이 금지되어 있다. 즉, 개인정보를 저장하는 서버는 반드시 한국 안에 있어야 한다는 것이다. 멀티 클라우드를 구축한다고 해도 서비스 서버를 서울 리즌, 도쿄 리즌에 분산해서 구축했다고 해도 개인정보가 담겨져있는 데이터베이스는 서울 리즌에만 있어야 한다는 것이다. AWS가 한국에 서울에만 있고 다른 곳에는 없기 때문에 이런 멀티 클라우드 구축에 애로사항이 있는 상황이다.

그런데 이 틈을 잽싸게 MS가 파고 들고 있다. MS 에저는 서울과 부산에 다 리즌이 있다는 것이다. 그래서 MS 에저로 오라고 지금 공격적으로 마케팅을 하고 있다(^^). AWS 서울 리즌을 그대로 쓰면서 백업 시스템을 MS 에저 부산 리즌을 이용하라는 얘기다. 뭐 이것도 방법이 될 수 있다. 아마도 MS는 지금이 천우의 기회라고 생각할지도 모르겠다(ㅎㅎ).

또 다시 클라우드가 아닌 서버 유치 시대로 돌아가는 것이 맞다고 얘기하는 사람들도 있다. 서비스 서버를 클라우드 서비스가 아닌 예전처럼 서버를 사고 그 서버를 서울과 대전, 부산에 설치해서 관리하자는 것이다. 클라우드 플랫폼이 없어도 운영이 가능하다는 얘기도 함께 말이다. 결국 과거로 돌아가자는 얘기인데 일단 클라우드 서비스의 맛에 빠지면 이전으로 돌아가는 것은 어렵다(거의 불가능에 가깝다고 본다). 그러니 이 얘기는 그냥 나오는 얘기로 넘어가면 될 듯 싶다.

신뢰성에 금이 간 클라우드 서비스

뭐 어찌되었던 이번 AWS 서울 리즌의 장애 문제로 인해 클라우드 서비스의 안정성 및 보안 문제가 대두되고 있는 것은 사실이다. 클라우드 서비스의 생명은 신속성과 신뢰성인데 신뢰성에서 금이 간 것이다. 게다가 AWS는 이번 사태에 대해서 제대로 된 해명을 내놓고 있지도 않다(앞서 DNS 문제라고 알려진 것도 몇몇 언론을 통해서 밝혀진 내용이라고 한다). 이 글을 쓰는 시점에서 다음주에 AWS 행사인 리인벤트(re:invent)가 있는데 과연 거기서 이번 사태에 대해서 어떻게 얘기할지 궁금해진다.

그리고 이것은 비단 AWS만의 문제로 보기도 어렵다. 모든 클라우드 서비스가 공통적으로 가질 수 있는 문제라는 얘기다. 앞서 언급한 MS 에저도 IBM 클라우드도 구글 클라우드도 똑같은 문제가 생길 수 있다. 결국 사용자들은 이 부분에 대해서 어떻게 대응해야 할지 고민을 해야 할 것이다.

그래서 현실적인 대응 방안은?

이래나저래나 현재로서 그나마 현실적으로 가장 편하게 접근할 수 있는 방법은 돈은 들지만 멀티 클라우드를 구축하는 것이다. 거기에 관리의 용이성을 위해 멀티 클라우드 관리 솔루션을 도입한다면 더 편해질 것이다. 물론 돈이 많이 든다. 투입되는 금액 대비 효과가 어떨지는 각각의 서비스 사업 담당자들의 몫이기는 하지만 말이다.

아니면 정말로 옛날 방식으로 서버 방식으로 돌아가고 그 서버를 지리적으로 먼 IDC에 설치해서 관리하는 것도 방법일 것이다. 물론 앞서 언급한 것처럼 클라우드 서비스에 맛들리면 되돌아가기 어려운 것이 사실이겠지만 말이다.

여하튼 이번 AWS 서울 리즌 장애 문제로 인해 서비스 제공자들의 머리가 아퍼지게 되었다. 타 클라우드 서비스 사업자들은 이때가 기회라고 열심히 마케팅을 하겠지만 말이다. 상황이 어떻게 될지는 좀 지켜봐야겠다.

ps) 이 글을 이번에 구입한 롤리키보드2와 샤오미 MiA1을 이용해서 에버노트로 작성해서 옮기는데 생각보다 힘들구먼. 익숙해질때까지 시간 좀 걸리겠는데.. -.-;

ps2) AWS 서울 리전에 대한 AWS 공지가 나왔네. 그런데 이슈 요약이라서 그닥.. 자세한 내용은 [여기]를 참고하면 될 듯..