본문 바로가기

Cloud Service 비교

#1 고 가용성의 기준 Region

안녕하세요. 빅두 입니다.

뭐 너무 간단한 내용이고 많은 분들이 여기까지는 포스팅/블로깅이 많습니다만, 저 역시 발은 담가야겠죠?

될 수 있으면 기본적인 내용은 다루지 않으려 했습니다만, 역시 기본이 탄탄해야 좋은 아키텍처를 그리실 수 있습니다.

그럼 AWS와 Azure는 어떻게 Region이 구분되어 있는지 봅시다.


먼저 글로벌 공룡부터 소개해 보죠.

http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html




AWS를 시작하시는 분들이나 강의를 가시면 제일 많이 보는 이미지 입니다.


AWS는 기본적으로 각 지역에서 서비스를 운영할 시 2개 이상의 데이터센터를 운영하고 있습니다. AWS에서는 이를 Availability Zone(AZ)라고 지칭합니다. 기본적으로 AWS는 VPC(Virtual Private Cloud)라는 기본적인 사설 인프라를 구성하는데 부터 시작합니다. 해당 VPC 안에서 만들 수 있는 Subnet을 생성하면서 AZ의 위치를 지정할 수 있으며, 해당 Subnet 위에서 AWS Resource들이 동작합니다. AWS의 거의 모든 Resource는 Subnet에 종속 됩니다.(S3 등 Global Region을 지원하는 서비스 제외) 즉, 사용자가 네트워크(Subnet) 디자인을 한번만 하게 되면 HA 구성은 쉽게 할 수 있습니다. 이를 AWS에서는 "여러 AZ에 서비스를 구성하였다"고 하여 Multi-AZ라는 용어를 사용합니다.


AWS에서 제공하는 모든 PaaS 기능들이 기본적으로 이중화가 되는 설정입니다. 사용자는 Data Center 라는 개념이 아닌 AZ라는 개념으로 HA를 구현하기 때문에 접근하기 쉽고, Default 설정으로 Multi-AZ라는 옵션이 활성화 되어있기 때문에 이중화를 권장하는 아키텍처를 제작하실 때 용이합니다. 물론 Single-AZ 구성도 가능합니다.


한가지 아쉬운 점은 이 AZ 간 거리가 그리 멀지 않다는 점에 있습니다. 서비스의 특성상 AZ간 높은 통신 트래픽이 발생하기 때문에 근거리에 있을 수록 구축 비용이 줄어들기 때문인지는 모르겠습니다만, 적어도 서울 Region이라 지칭하고있는 AZ는 실제로 서울 안에만 존재 한다고 알고 있습니다. 그리고 이 데이터센터라고 지칭할 수 있는 AZ의 위치는 AWS에서 제공하지 않습니다.


AWS의 SLA는 AZ구성을 하지 않으면 적용되지 않습니다. 이것도 사용자에게는 굉장히 나쁜 조항이며, 이중화 구성을 하지 않은 고객에게 모든 책임을 떠넘기는 SLA가 정의되어 있습니다.


AWS에서 지칭하는 Region의 또 다른 특이점은 Region별로 Service하는 내용이 다르다는 것 입니다. AWS에서 신규 서비스가 발표되었다고 해도, 적용되는 지역은 일부분에 불과합니다. 모든 서비스는 제일 처음 미국 버지니아(US East (N. Virginia))에 적용 됩니다. 

그 후 해당 서비스를 요청한 지역에  순차적으로 서비스가 오픈되며, 특정 Region에서 서비스 하는 기능은 다른 지역에서 사용이 불가능 합니다.


또한 각 Region간 ARN(Amazon Resource Name)을 목적지로 하지 않는 Service끼리는 연동이 되지 않습니다. Lambda나 SNS 등 다른 서비스들과 연동되는 서비스들은 같은 Region 안에서만 연동이 가능합니다. 예를 들어 도쿄 Region에서 Lambda와 SNS 서비스를 연동하여 제품을 제작 했었는데 서울 Region에 Lambda 서비스가 없다면, 이 제품은 서울 Region으로 Migration이 불가능 합니다. 해당 예시를 너무 대충 생각해서 예시 자체를 가지고 문제삼는 분들이 계실지 모르겠습니다만, 앞서 말씀 드렸듯이 리소스 참조를 ARN으로 지정할 수 없는 서비스들은 연동이 되지 않습니다. (ARN으로 지정할 수 있는 서비스라도 지원이 되지 않는 경우도 있습니다.)


사용자들이 가장 불편하게 느끼는 부분은 Consol 또는 CLI에서의 Region간 이동 입니다. AWS는 Region간 이동시 AWS Console에서 지역을 선택하여 이동해야 합니다. 특정 서비스에 대해 모든 Region의 Resource를 볼 수 없다는 점이 아쉬운 부분으로 남습니다.


당연한 이야기지만 중국(베이징) Region은 아무나 접근 가능한 Region이 아니며, 미국 정부 Region인 AWS GovCloud 또한 기본적으로 접근이 불가능합니다.



다음은 하드웨어 명가에서 제공하는 Cloud를 소개해 보겠습니다.

https://azure.microsoft.com/ko-kr/regions/

https://azure.microsoft.com/ko-kr/documentation/articles/best-practices-availability-paired-regions/





처음 딱 보고 와! 했던 것은 모두가 동의하실것 같은 UI입니다. 뭐 그 이외에 감동인 것은 모든 Resource를 한 눈에 볼 수 있다는 점 이었습니다. 그 다음으로 눈에 띄는 부분은 Resource Group 입니다. Azure의 모든 Resource는 Group화 하여 만들어 지는 것은 알고 있었습니다만, 실제로 사용해 보니 Resource Group이 굉장히 편한 녀석이더군요.


Resource Group은 편합니다만, 엄청난 착각을 불러 일으킬 수 있다는 것을 알았습니다. 바로 하나의 Resource Group 안에 존재하는 모든 Resource들은 통신이 될 것이다 라는 착각 입니다. AWS를 이용하다 와서 그런지 "현재 보이는 Resource들이 통신이 될 것이다." 라는 무언가의 확신이 있었던 것 같습니다. 예를 들어 일본 동부와 일본 서부에 VM을 제작했을 시 같은 Resource Group에 지정할 수 있습니다만, 이 두 개의 VM간 통신은 논리적으로 외부 통신만 가능하지, 내부 통신을 묶을 수 없더군요.


조금 더 추가 설명을 드리자면, 하나의 Resource Group에는 다른 지역의 Virtual Network를 만들 수 있습니다.(이게 되더라고요.) 그 다음, 각각 지역에 VM을 생성하고 사설 대역으로 통신을 시키면 되겠지? 하고 생각하고 짠! 했는데? 안되더라고요... 두무룩.... 그래서 위와 같은 내용은 조심해야 한다고 생각합니다.


좀 아쉬운 점은 Region내 이중화 개념이 좀 약한것 같습니다. 개인적으로 Hyper-V를 잘 알고 있어서 데이터센터 내 이중화는 아주 쉽게 설정할 수 있다는 것을 알고 있습니다만, AWS처럼 사용자가 직접 다른 데이터센터에 리소스를 지정한다는 느낌이 없어서 뭔가 고가용성이 떨어지는 아키텍처인 것 처럼 느껴집니다. 실제로 내가 만든 리소스가 어떤 Host에 올라가 있는지 확인이 안되니 동일한 Resource Pool에 존재할 수도 있지 않습니까? 최소한 "Active-Standby로 지정하는 옵션 값 같은 무언가를 만들어서 Resource Pool에 존재하지 않도록 지정할 수 있었으면 좋았겠다"는 개인적인 생각이 들었습니다.


또 다른 문제점은 HA개념입니다. 직접 Azure 쌍을 확인하고 고가용성을 구성하기 위해 조작을 해야 하는 부분이 생각보다 팍! 와닿지 않았습니다. 특정 지역에 리소스를 생성하면 HA를 구성하기 위한 권장 지역에 리소스를 만드는 것을 권장할 수 있는 무언가가 있었으면 좋았겠다고 생각 합니다. 특히 Region간 트래픽 비용이라든지 기타 비용을 따져봤을 때 과연 HA구성에 대한 고려사항을 "어느 수준의 고객까지 권장해야 하는가?" 에 대한 내용도 굉장히 애매모호한 상태입니다.


한가지 다행인 것은 Azure SLA를 읽어본 결과 이중화 구성과는 별개로 각 개개별의 가용량에 따라 크래딧 지원을 해준다는 것이 좋았습니다. (이 부분은 제가 잘못 알고 있다면 언급 부탁드립니다.)


Azure만의 특장점은 Azure Pair가 정의되어 있어서 Pair간 HA구성을 권장한다는 부분은 참 좋았습니다. 역시 장애 대비는 400km 이상은 떨어져 있어야 제맛이죠. 또 다른 장점은 Region내 장애에 대해서 이것저것 조건이 붙지 않아서 매우 심플한 SLA라는 부분에서 감동했습니다.


Azure도 AWS와 마찬가지로 중국 지역은 아무나 접근이 불가능 합니다.




글에 있어서 문제점이나 잘못된 부분에 대한 테클러 분들께 미리 감사합니다.

그리고, 여기까지 읽어 주신 모든 분들께 감사의 말씀 전달 드립니다.


다음으로는 가상 머신에 대해 다뤄 보도록 하겠습니다.


============================================

수정 1. SLA에 대한 내용 추가하였습니다.

수정 2. AWS쪽 AZ에 대한 개념이 부족하여 보수공사좀 하였습니다.

수정 3. Azure도 중국은 접근이 어려운 부분 추가했습니다.

수정 4. Resource Group간 통신이 되지 않는다는 내용에 어패가 있어 수정하였습니다.