이전글에서도 적었듯이 앞으로 모든 내용은 클라우드 기반, 그중에서도 특히 GCP ( Google Cloud Platform )을 기반으로 작성된다.
모든 용어는 GCP 베이스로 진행될 예정이며, 여기서 이야기하는 Region 역시 클라우드의 리전과 100% 일치한다.
대개의 클라우드들은 하나의 Region (지역: 이하 리전)을 여러개의 Zone 으로 구성한다. 클라우드 벤더에 따라 이 Zone 을 AZ ( 가용구역)으로 다시 표시하는 경우도 있으나 일반적으로 존 이라 하면 대부분 알아듣는다.
클라우드는 수 많은 고객사들이 이용을 하고 그 고객사들은 다시 수많은 고객들이 있어서 안정성을 최 우선으로 따진다.
특히 GCP의 경우 안정성에 대한 집착은 거의 병적이라고 할 수 있을 만큼이나 집착적이다.
하나의 클라우드에 문제를 일으킬 수 있는 우리가 상상할 수 있는 모든 것들에 대한 대비를 해두고, 그걸로 모자라서 가혹한 테스트를 반복적으로 한다. 그러한 이야기들은 구글 홈페이지에 나와 있으니 패스하기로 하고, 우리는 그것을 어떻게 활용할것인가에 대해서만 이야기 해보도록 하자.
GCP의 개별 리전들은 최소 3개의 지역 ( zone )으로 나뉘어 있고 경우에 따라 그 이상의 숫자를 가지는 리전들도 있다. ( 보통 오래된 리전들이 그 이상의 갯수로 구성되어 있다. )
오늘 다루게 될 단일 리전 DR 의 경우에는 사실 구성이 매우 쉽다. 특별히 복잡하게 설계해야 할 내용도 없을뿐 아니라, 기존에 이미 사용하고 있던 사용자들이라면 옵션을 몇가지 변경해주는것만으로도 끝난다.
우선 가장 기본적인 다음과 같은 구성을 보자.
하나의 로드밸런서와 그 뒤에 GKE( Kubernetes ) 서버 그리고 마지막으로 SQL DB 가 구성되어 있다.
사실 더 할나위 없이 단순한 구성이다. 지난 7년간 GCP를 사용해 봤는데, 저 구성으로도 큰 문제는 없을 정도로 GCP는 신뢰를 줬다.
그러나 우리는 DR을 목표로 하고 있으므로 여기다 몇가지를 추가할 계획이다.
우선 하나씩 나눠서 생각해보자.
구글의 로드밸런서는 SLA를 99.99% 이상 보장하는 시스템으로 구성되어 있고 단일 IP 애니캐스트를 지원하는 로드밸런서이다.
풀어서 설명하자면, SLA 99.99% 즉, 가동시간의 99.99%를 보장한다는 이야기인데, 1달에 4분 이하의 다운타임을 보장한다는 의미다.
그리고 단일 IP 애니캐스트를 지원한다는 의미는 만약에 우리가 단일 리전이 아니라, 멀티리전 나아가 전세계 모든 리전에 서버를 둔다 하더라도, 하나의 IP 만 가지고도 접속자의 근처에 있는 서버가 응답을 할 수 있도록 만들어주는 시스템이라는 의미다. 애니캐스트에 관해서는 카카오의 애니캐스트 문서를 읽어보자 ^^
다음으로 GKE : Google Kubernetes Engine 은 구글에서 만든 쿠버네티즈 시스템이다. 애초에 쿠버네티즈 자체를 구글에서 만들긴 했는데, 이건 GCP에서 사용하기 위해 조금 더 커스텀 되어 있다. ( 예를들면 TPU라던가.. 등등 몇가지가 ) 이 문서는 쿠버네티즈를 다루는 문서가 아니니 매우 간략하게만 설명하면, 여러대의 서버가 알아서 프로그램이 동작하다가, 한대에 문제가 생기게 된다면, 다른 서버들이 작업을 나눠서 감당하고, 가능하다면 새로운 서버를 세팅해서 그 서버에 일을 같이 나눠줄 수 있는 관리 프로그램이라고 생각하면 쉽다. ( 실제로는 정말 많은 일을 수행한다. )
이것만으로도 하나의 존에 있는 여러대의 시스템이 동시에 다운되지 않는다면 문제가 없겠지만, 우리가 가정하는것은 존 자체( 데이터 센터 )가 다운되는 상황이니까..
마지막으로 흔한 SQL 서버라고 생각하면 된다.
우리가 서비스를 이용한다 라고 하는것은 위에 있는 기본적인 3가지를 조금더 복잡하게 만든것에 불과하다.
우리가 어딘가에 접속해서 ( 로드밸런서 ) 그곳에 있는 데이터를 읽거나 새로운 데이터를 쓰는 ( DB ) 데 그 과정을 중간에 서버에서 프로그램이 제어해주는것 ( 서버 ) 을 하나로 합쳐서 서비스를 이용한다고 한다.
사실 어떻게 보면 서비스라는게 그 3가지를 합쳐 놓은것인데, 그렇다고 하면 그 3가지를 안전하게 구성할 수만 있다면 재난 상황에서도 문제가 없이 동작하게 할 수 있다는것을 쉽게 알 수 있다.
앞에서 우린 클라우드를 사용한다고 했다.
이 클라우드를 사용한다는것은 클라우드라는곳에 단순하게 서버를 올리고, 사용하는것만 의미하지 않는다.
대부분의 클라우드들은 다양한 서비스들을 제공한다. 예를들면, 앞에서 말한 GKE 를 사용하기 위해서는 GKE에서 동작할 서버 프로그램들을 사전에 패키징해놓은 파일 묶음같은것이 필요한데, 이를 Image (이미지) 라고 한다. 그러한 이미지들을 보관해주는 저장소가 있어야 하는데, 그걸 클라우드에서는 서비스로 제공해준다. 따라서, 하나의 서버가 문제가 생겼을경우에는 새로운 서버를 구성한뒤 즉시, 그 이미지 저장소에서 이미지를 가져와서 동작 시킬 수 있도록 만들어주는 서비스를 제공해준다. 앞에서 말한 로드밸런서도 마찬가지다. 클라우드에서 제공해주는 서비스중의 하나이며, Cloud SQL 또한 우리가 단지 설정만으로도 자동으로 백업을 하거나 Fail-Over 를 할 수 있도록 기능을 제공해주는것들이 클라우드에서 제공해주는 서비스들중의 하나이다.
방금 이야기한 기능들을 직접 구현하거나 설정하려면 굉장히 복잡하기에 대부분의 온프레미스로 서버를 운영하는 회사들은 거의 대부분 사용하지 못한다. Private Cloud 를 사용하는 회사라면 모를까, 대부분은 사용하지 못하며 그래서 문제가 생겼을경우 일이 커지는 경우가 발생하게 된다.
아직, 우리는 Single Region DR을 이야기 하지 않았다.
앞에서 우리는 구글의 경우 하나의 리전에 여러개의 존을 운영한다고 했다.
Zone 이라는 개념은 하나의 지역안에 여러개의 데이터 센터를 이용해서 만약에, 하나의 데이터센터가 문제가 아주 크게 ( 예를들면 불이 나더라도 ) 생기더라도, 나머지 데이터센터들이 문제가 없는한 영향을 받지 않도록 하는 개념이라고 이해하면 된다.
그렇다면, 하나의 "리전" 전체가 문제가 생기는 경우는 없을까?
있다.
구글에 따르면 그러한 케이스는 "전쟁" 이라고 했다.
전쟁이 나면 해당 지역에 있는 모든 데이터센터들은 다 파괴될 가능성이 매우 높기 때문이다.
바꿔서 말하면, 전쟁을 제외하고는 단일 리전 DR은 충분한 재난 대비가 되는것이다.
( 멀티 리전 DR은 다음편 부터 이야기를 진행할 예정이다. )
GCP에서 단일 리전 DR을 하는 법을 이제 알아보자.
생각보다 설정은 간단하다.
GKE
신규 생성시
영역을 선택시 하단의 기본 노드 위치 지정을 해서 2개 이상을 지정을 하거나 혹은 영역이 아닌 리전을 선택한다.
기존 변경시
기본 노드 위치 수정을 통해 영역을 추가할 수 있다.
Cloud SQL
기본적으로 Cloud SQL은 여러개 영역에서 동시에 동작한다기 보다는 Fail-Over 의 개념으로 추가가 가능하다.
신규 추가 혹은 기존 SQL을 수정을 통해서 여러 영역에 고가용성으로 업데이트가 가능하다. 고가용성을 선택하면 서로 다른 영역에 예비 서버를 둠으로써 재난 대비가 된다.
사실 단일 리전에서의 DR은 이미 구글에서 다 준비를 해놨기 때문에 옵션만 선택하는것으로 끝이 난다.
진짜 어려운것은 멀티 리전이다. 다음편 부터 멀티 리전에 관한 이야기를 하도록 하겠다.
