Talk Lowy(kr)

프라이빗 클라우드(Private Cloud) :  VMWare처럼 솔루션을 구입하여 자체 보유한 하드웨어 상에 클라우드 시스템을 구축하는 것을 말한다. 자체 보유하고 있는 인프라 풀을 사용하기 때문에 크기의 제약은 있지만, 현재 가지고 있는 인프라가 있다면 이를 활용하는데 도움을 줄 수 있다. 그리고 다른 사람들이 사용할 수 없다는 보안성등의 잇점이 있고, 구축 비용은 인프라 풀 만큼의 비용이 들기 때문에 초기 예상을 잘 해야한다.  그래도 기존 레거시 시스템과는 달리 필요에 따라서 조금씩 추가하여 확장할 수 있다는 장점이 있어 프라이빗 클라우드는 지속적인 수요가 늘고 있다. 퍼블릭 클라우드(Public Cloud) :  AWS(Amazon Web Service)등처럼 누구나 가입을 하고 바로 사용할 수 있는 공개되어있는 클라우드 환경을 이야기한다.  초기 솔루션 도입비용이나 인프라 풀을 미리 구입할 필요가 없어서 비용적인 측면에서는 유리하지만 동일 스펙을 1년을 쓴다면 실제 장비를 구입하는 것이 더욱 저렴하다고 보면 된다. 즉, 단기간에 신축성있게 인프라를 사용하는 경우 추천하는 모델이다. 하이브리드 클라우드(Hybrid Cloud) :  프라이빗 클라우드로 최소한의 구축을 하고, 퍼블릭 클라우드를 신축성있게 사용할 수 있는 구조를 하이브리드 클라우드라고 한다. 대부분 하이브리드 클라우드는 직접 설계하고 구축하고 연동을 하는 것이 보통이나, MS의 System Center 2012에서는 Hyper-V를 활용한 프라이빗 클라우드에 Azure서비스를 연동할 수 있게 지원을 해주고 있어 하이브리드 클라우드를 손쉽게 구축할 수 있다. 인터 클라우드 (Inter Cloud) :  2013년 6월 IEEE에서 시작한 클라우드 통합 프로젝트를 말한다.  다양한 프라이빗 클라우드와 퍼블릭 클라우드를 필요에 따라 자유롭게 사용할 수 있는 통합 UI를 제공하고 유저는 하나의 UI로 다양한 클라우드 서비스를 사용할 수 있다는 것이 장점이지만, 개념의

요즘들어 모바일 게임업체에서 클라우드 컴퓨팅 환경으로 이전 또는 신규 구축 의뢰가 많이 들어오고 있다. 이유는 다음과 같다. 1. 모바일 게임의 수명이 너무 짧아 1년이상 약정은 리스크가 너무 크다. 2. 모바일 게임의 유저수를 책정할 수 없어 스타트 규모를 산정할 수 없다. 3. Latency에 크게 구애받지 않기 때문에 다소 느려도 상관없다. 이러한 이유가 클라우드 인프라를 활용하기에 최적의 니즈가 되고있다. 모바일 게임업체인 A사에서 자신들이 만든 게임서버의 구조를 보여주며 클라우드 환경으로의 이전을 검토해달라고 하였다. 아무리 클라우드 환경으로 이전한다 하더라도 게임인 이상 타 서비스와 영향을 받지 않는 것이 좋기 때문에 Hybrid cloud 의 형태로 제안을 했다. Hot standby가 불가능한 서버에 대해서는 물리서버 또는 독립가상화 서버를 제안하고, 죽어도 유저의 게임서비스에 문제가 없는 서버를 Public Cloud로, 그리고 이 둘을 VPC로 묶어 로컬 환경과 같은 형태로 제안을 하였다. 그리고 유저가 늘어날때 같이 늘어나야 하는 서버들을 산정하여 Auto Scaling으로 제안을 하였고, 폭발적으로 늘기 쉬운 특성을 감안하여 초기 구조를 Sharding(샤딩, 수평분산구조)으로 변경할 것을 권고하였다. 대부분의 게임이 그러하듯이, 메인 유저DB가 있고, 월드DB가 있어 여러대의 채널서버에서 월드DB에 붙어 유저의 정보를 액세스 한다. 이것은 수십만 유저까지는 커버하는데 전혀 지장이 없지만, 수백만에서 수천만에 달하는 유저를 커버하기에는 역부족이 된다. 이 때 로그성 데이터는 MongDB쪽으로 권하기도 하지만, 개발리소스의 큰 변화를 주지 않도록 하기 위해서는 한 유저당 하루에 쌓을 수 있는 데이터량을 감안하여 수평분산이 가능하도록 Node Server를 별도로 두고 서버를 쉽게 분리 통합이 가능한 구조로 제안을 하였다. 이렇게 하면 100만명 단위로 게임서버 + DB서버를 하나의 물리서버에 가상화를 시켜

어느날 고객이 질문을 했다. 고객 : "클라우드를 도입하고 싶은데 어떠한 매리트가 있는지 모르겠어요" 이 고객은 게임업체 고객이고 서버는 약 20대정도로 게임 포털처럼 웹서비스를 하나 하고 있고, 게임은 이제 하나를 붙인 상태이다. 두 번째 게임을 붙이려고 준비중에 있는 듯 하다. 나 : "현재 서버 구성도를 주시면 제가 프라이빗 클라우드의 형태로 재설계를 해드리겠습니다." 고객이 서버 구성도를 주었다. ==웹서비스== 서비스용 웹 서버 : 3대 회원 DB : 1대 웹DB : 1대 관리자 웹 서버 : 1대 빌링 웹 서버 : 1대 빌링DB : 1대 ==게임 서비스== 로비서버 : 1대 맵 서버 : 2대 워(War) 서버 : 1대 인증서버 : 1대 게임DB : 1대 로그DB : 1대 복구DB : 1대 게임서버 여유분 : 1대 관리 서버 : 1대 테스트 서버 : 1대 샵 서버 : 1대 이렇게 총 20대의 물리서버가 있었다. 이 서버들을 메모리만 증설 시킨 뒤에 가상화를 하여 묶어 주었다. 총 10대의 서버를 가상화 하고, 5 대의 서버만 물리 머신 그대로 두었다. 총 15대를 사용하고, 10대의 가상화 서버는 크로스로 이중화 설정을 하였다. 즉, 물리적으로 어딘가의 서버가 죽어도 다른 서버의 Cold Stand-by(VM을 세팅해놓고 전원을 내려놓은 상태)의 VM의 전원을 넣기만 하면 바로 복구가 가능한 구조를 만들었다. 모든 DB도 리플리케이션을 해놓아서 DBMS가 죽어도 최소한의 로스로 바로 살릴 수 있도록 설계를 해주었다. 결론적으로 20대였던 서버가 15대로 줄면서 이중화까지 되어있어 모든 서버중 어느 하나가 죽어도 쉽게 복구가 되는 이중화가 된 것이다. 즉 40대분량의 설정이 된 것이다. 게다가 5대가 남아서 가상화를 하여 신규 서비스의 테스트용으로 사용하게 했다. 가상화라는 것은 마약이다. 중독되면 너무 매달려 화를 자초할 수도 있다. 하지만 의