Talk Lowy(kr)

듣기 버전 :  https://youtu.be/G7zSPa90kd8 AWS와 Azure중에 무엇을 선택하면 좋을지에 대한 질문이 좀 있어서 올려봅니다. 한국에선 당연히 AWS라고 하고 또 레밍스 하고 있잖아요? 하지만 일본에서는 Azure의 쉐어도 엄청납니다. 이유를 좀 알아봐야겠지요? 일단 세계 클라우드 쉐어 입니다. 다들 아시다 시피 AWS가 1위이지만 거의 성장이 멈추어 있고, 가깝게 추격하면서 싸우는게 Azure지요? 그런데, 일본 총무성에는 이런 자료도 있습니다. Microsoft가 17.2%로 1위네요? 제가 지난 DB선택 코너에도 말씀 드렸듯이 1위 라는 것은 무엇을 기준으로 하느냐에 따라 달라집니다. Microsoft는 클라우드 서비스 전체 매출이 1위입니다. 말이 되냐구요? 역시 한국에서보는 정보 만으로는 그렇게 될 수밖에 없지요.. 다양한 글로벌 정보를 보시면 도움이 될 것입니다. AWS와 Azure의 커스터머 사이즈를 볼까요? 가장 초대규모 커스터머를 AWS는 23%밖에 못쥐고 있는데 비해 Azure는 33%나 가지고 있습니다. 대규모 커스터머 역시 AWS는 23%에 Azure는 33%네요.. 그런데 AWS는 미들 이하 사이즈에서는 압도적입니다. 자, 한국에서도 다시 한 번 주변을 보시겠어요? 스타트업 등의 기업들은 당연히 AWS를 쓰지만 중대형 규모의 기업들은 AWS를 쓰시나요? 여기서 일본과 극명하게 달라지는데요.. 한국의 MS매출을 볼까요? 1조원.. 엄청나죠? 그럼 일본의 MS매출을 볼까요? 1조엔.. 언제나 제가 비교하는 자료는 한국 대비 10배정도 차이나고 있군요.. 제가 예전부터 MS랑 같이 일본에서 많이 일을 해서 듣는 얘기인데요.. MS의 일본 매출은 중국을 제외한 APEC전체 매출보다 높다고 합니다. 불법복제가 만연하는 한국에선 당연히 MS를 선호할리가 없지만, 일본에선 대기업은 당연하게 MS가 엄청난 수익을 내고 있고, 그 때문에 MS는 대기업의 규모에 따라서 담당 컨설턴트를 붙여서 Azure도입을 가이드 해주고 있습니다

얼마전 aws위에서 mongodb를 올려서 서비스를 구성한 구성표를 보았다.  이 구성표를 만든 팀은 예전에 내가 도와준다고 했을 때 이미 많은 서비스를 mongodb를 이용해서 서비스 했다고 자만하던 팀이라 그냥 지켜보기로 했던 팀이었다.  2Core/4GB의 mongos 2대가 서비스 헤더, 1대가 관리헤더 2Core/4GB의 mongoc 3대가 metadata, 3대가 로그의 metadata.  4Core/16GB VM을 5대를 올려서 3대를 mongod를 올리고 2대를 서비스로그를 저장하도록 구성 했다.  물론 세세한건 보지 않았지만,  당연히 EBS가 30GB이니 30GB모두 하나의 shard로 하여 1 shard 3 replica 이지 않았을까? 안에서 추가로 쪼개기에는 EBS사이즈가 작으니.. 개발 서버 포함 총 15대의 VM으로 구성된 예상비용은 월 약1200달러.  이것을 26대로 늘리고 월 약 1100달러로 줄이는 설계를 보여줬다.  그리고 성능은 기존의 약 6배. 비용으로 환산한다면 월 7200달러 어치의 성능을 1100달러로 보여준 것이다.  AWS HW의 특성상 IOPS성능이 일반 HW보다 1/5 수준으로 떨어지는 것을 어떻게 메꿀 수 있는지가 중요하다. 특히나 EBS가 SSD라고 할지언정 물리적으로 연결되어 있는 디스크가 아닌 이상 Storage Network의 처리 성능이 가장큰 병목이 발생한다. (AWS 및 Storage를 Network로 연결하는 클라우드 아키텍쳐는 모두 같은 문제) 그리고 AWS의 특성상 1vCPU는 1Core가 아니다. 예전에는 1vCPU의 성능 수치가 있었지만 지속적인 하드웨어 추가로 인해 기존 하드웨어와의 CPU모델이 달라져 성능이 다르게 나오고 있어 이 지표는 사라졌다. 1vCPU의 성능이 얼마만큼 나오는지를 이해하여야 한다.  그 다음으로 Virtualization의 성능(Para-virtualization, Full virtualization)에 따른 퍼포먼스 저하가 얼마나 일어나는지, Linux라는

클라우드 컴퓨팅에 대해서 사람들이 많이 논하고 있다. 하지만, 정확히 아는 사람도 아직 적은 편이다. 그리고 정의만 달달 외우는 우리나라식 주입식 암기만 하고 있는 사람들도 있다. 약간 깊이 있게 논해보자. NIST(National Institute of standards and technology, 미국 표준 기술 연구소)에서 클라우드 컴퓨팅을 이렇게 정리했다. On-demand self service 내가 직접 액션을 취해서 받는 서비스이다. Broad network access 어디서든 엑세스 되는 네트워크 환경을 가진다. 하지만 여기서는 다양한 디바이스에서의 접속을 얘기하기도 한다. Resource pooling 리소스 풀을 가지고 있어 원할때 바로 꺼내사용할 수 있어야 한다. Rapid Elasticity 빠른 신축성을 가지고 바로 사용하고 바로 돌려줄 수 있는 가변성을 가져야 한다. Measured Service 위의 네 가지를 다 가능하게 한다면 사용한 만큼 과금을 할 수 있는 측정서비스를 가지고 있어야 한다. 이 다섯가지를 구비하고 있으면 클라우드 컴퓨팅이다. 어디에서 가상화(Virtualization)이니 이중화(Redundancy)이니 보안(Security)이니 하는게 있는가.. 아직도 클라우드는 가상화 아니냐.. 죽지 않는 서비스 아니냐 하는식의 얘기는 안하겠지.. 그럼 클라우드라고 불리는 서비스들이 제대로 클라우드의 정의에 따르는지 보자. AWS, Azure, GCE(Google Computing Engine), LG Cloud N, KT 유클라우드(U Cloud)의 경우 대표적인 IaaS로서 자리잡고 있다. 회원 가입을 하고 직접 서버를 생성한다. 그리고 모바일 버전등 다양한 디바이스에서 접속해서 서비스 사업자들이 제공하는 리소스 풀에서 꺼내 쓰고 바로 삭제가 가능하다. 그리고 월말에 사용량만큼 과금한다. 이게 바로 클라우드 서비스라고 하는 것이다. 대표적인 PaaS(Platform

이제서야 다시 이글을 쓰게 된 이유는, 아직도 처음부터 설명을 해야할 필요가 있는 사람들이 많기 때문에다. 새롭게 학교를 마치고 취업전선으로 뛰어든 사람들, 전혀 다른 업종에 있다가 클라우드쪽으로 넘어와야 하는 사람들.. 그동안 간과하고 있다가, 대답을 해줄만큼의 지식은 없는데 물어보는 사람들이 많은 윗사람들.. 이들을 위해서 클라우드 컴퓨팅에 대해서 명확히 짚어 넘어가보고자 한다. 클라우드 컴퓨팅이란 단어는 어디서 시작했을까? 아는 사람들은 알겠지만, 2006년 8월9일 검색엔진 컨퍼런스에서 구글 CEO인 Eric Schmidt(에릭 슈미츠)가 가볍게 언급하면서 파장이 급속도로 확산되었다. 그 때는 아주 간단한 말을 했다. What's interesting [now] is that there is an emergent new model, and you all are here because you are part of that new model. I don't think people have really understood how big this opportunity really is. It starts with the premise that the data services and architecture should be on servers. We call it cloud computing – they should be in a "cloud" somewhere. And that if you have the right kind of browser or the right kind of access, it doesn't matter whether you have a PC or a Mac or a mobile phone or a BlackBerry or what have you – or new devices still to be developed – you can get access to the c

클라우드 환경이 보편화 되면서 많은 SE분들은 클라우드 서비스를 사용해 보았을 것입니다. 하지만 SE의 입장에서는 현재 사용중인 Legacy장비들을 그대로 사용하면서 추가로 Cloud Service를 사용해야 하는 경우가 대부분 입니다. 심지어는 여러 클라우드 서비스를 사용하면서 복잡한 유저포털을 익히는데 더 시간이 걸리고 있습니다. AWS의 경우 너무 많은 기능으로 인해 거의 사용하지 않으면서 비용은 비용대로 지불하면서 Co-Location의 레거시 장비들과 혼용하여 사용하기도 합니다. 정말 AWS가 좋은 것인가요? 아니, 클라우드가 정말 필요한 것인가요? SE분들은 어디에 어떤 서버를 이용해도 결국 수동으로 자산관리를 위한 엑셀시트를 열어보고 있을 것입니다. 그리고 그 자산들의 정보는 수동으로 기입하고, 시스템 내에서 변경사항이 발생했는데 엑셀에는 업데이트 되지 않는 경우도 허다합니다. 어떠한 클라우드 서비스를 사용하건 호스팅을 사용하건 SE분들은 처음에만 접속하고, 생성 후에는 거의 접속하지 않고 있지 않나요? 결국 생성에만 필요하고, 그외에는 그 복잡한 서비스보다는 기존에 익숙한 시스템 내의 기능을 사용하려 할 것입니다. 그리고 다시 익숙한 엑셀을 펼쳐서 정보를 기입하고 있겠죠.. 이제 SE분들께 실질적인 제안을 할까 합니다. MSP서비스 라는 ITAM(IT Asset Managent, IT자산관리) 서비스를 이용해보세요. http://msp.littleworld.net 그동안 기능이 뭐니 서비스가 어떻니 하는 비현실적인 서비스에 매달려 여러 화면을 짜집기 하고 있었다면, 이 서비스 하나로 모든 시스템을 통합해 보세요. - 물리 서버 자원 관리 - 가상 서버 자원관리 - IP 자원관리 - HDD자원관리 - 자원정보 자동 갱신 - 자원 여유량 체크 - 도메인 자산 관리 그밖에 SE로서 필요로 하는 기능들을 지속적으로 도입하고 있습니다. 서드 파티 및 API를 활용한 자체 툴 개발자 분들의 참여도 기다리고 있습니다

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

결국엔 버라이존(Verizon)의 클라우드 인프라까지 구축하게 되었다. 정말 다양한 환경에서 구축을 하다보니.. 서로의 서비스의 특장점을 많이 알게 되었다.  Verizon 의 가장큰 특징은 VMWare로 인프라가 구성되어있는데, 프론트는 일반 AWS같은 UI를 제공한다. 깔끔한 UI가 괜찮은 것 같다. 그리고 VM생성하는 개념도 VMWare를 사용해본 사람이면 쉽게 알 수 있을 것 같다. 단지 네트워크가 조금 다르다. 이중 네트워크를 지원하여 두 개의 네트워크 대역을 제공하고, 하나는 글로벌로 하나는 로컬로 사용하면 된다. IP는 Local IP를 할당한 뒤에 Network 설정에서 Global IP에 서비스를 추가하여 VM을 매핑한다. 이 때 서비스에 여러 VM을 매핑하면 바로 LB서비스가 되는 것이고, 그냥 하나의 서버만 매핑하면 Port Forwarding같은 느낌으로 사용할 수 있다. 관리만을 목적으로 한다면 Port Forwarding을 하지 않더라도 관리화면에 있는 VPN Connect 버튼을 클리만 하면 Cisco VPN접속 플러그인을 통한 접속이 가능하여 편리하게 작업환경에 접속할 수가 있다. 때문에 굳이 관리용 Port를 Global로 뽑지 않아도 된다. 이런 면이 보안상 강점을 만들 수 있다. VM생성은 기본 제공 템플릿은 몇개 없지만 Blank VM을 만들 수 있어 자신이 원하는 모든 OS Image를 올릴 수 있다. (물론 VMWare에서 서포트 하는 OS만 가능) 그리고 OVF, vmdk 포맷의 파일을 Catalog에 등록하여 언제든 Deploy를 할 수 있는 것도 편리하다. 이미 생성된 VM을 전원을 내리고 복제를 걸면 쉽게 동일 VM을 확장해나갈 수 있는 것도 VMWare가 가지는 장점을 그대로 이식한 것이다. Blank VM을 만들면 접속한 Client 에서 ISO이미지를 가지고 있을 때 그걸 다이렉트로 Mount가능하며 마운트된 ISO는 Optical Drive로서 인식하여 부팅

어느날 고객이 질문을 했다. 고객 : "클라우드를 도입하고 싶은데 어떠한 매리트가 있는지 모르겠어요" 이 고객은 게임업체 고객이고 서버는 약 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대가 남아서 가상화를 하여 신규 서비스의 테스트용으로 사용하게 했다. 가상화라는 것은 마약이다. 중독되면 너무 매달려 화를 자초할 수도 있다. 하지만 의

사람들이 많이 사용하는 내용중에 퍼블릭 클라우드(Public Cloud), 프라이빗 클라우드(Private Cloud), 하이브리드 클라우드(Hybrid Cloud)라는 용어를 자주 사용하곤 한다. 이 외에도 인터 클라우드(Inter Cloud)라는 용어도 있다. AWS(Amazon Web Service)에서는 VPC(Virtual Private Cloud, 가상 프라이빗 클라우드) 라는 용어를 쓰기도 한다. 얘네들은 도대체 어떻게 구분을 하는 것일까? AWS처럼 일반인들을 대상으로 시스템을 제공해주고 그 틀에 맞추어 여러 사람이 같이 자원을 나누어 사용하면서 가격적인 매리트를 살린 것이 퍼블릭 클라우드(Public Cloud)이다. 대신 시스템을 그대로 사용해야 하기 때문에 시스템의 한계를 알고 이용을 해야 한다. 퍼블릭 클라우드의 장점은 쉐어를 하기 때문에 비용이 저렴하다는 것이다. AWS는 워낙 많은 기능을 서비스로서 제공을 하기 때문에 거의 한계가 없지만, U Cloud는 vNIC 기능이 안되어 IP를 두 개로 나누어 글로벌, 로컬 네트워크 처럼 나누거나 할 수 없다. Cloud N은 스토리지 이중화가 기본으로 되어있지 않아 스스로 두 배를 신청해서 동기 시키거나 백업을 시켜야 한다.(물론 RAID구성은 되어있지만..) Azure는 Elastic IP가 없어 서버를 리부팅 하면 IP가 바뀐다. 도메인 베이스로 설정을 해야한다. 프라이빗 클라우드(Private Cloud)는 직접 인프라를 가지고 있는데 이를 활용하여 클라우드 인프라 환경을 만들고자 할 때 사용한다. 이 때 많이 사용하는 툴이 VMWare, Hyper-V, Xen 등이 있는데 이를 자동으로 리소스풀링(Resource Pooling)을 하기 위해서는 각각의 관리 시스템이 필요하다. VMWare의 VCenter, Hyper-V의 System Center, Xen의 XenCenter 등이 바로 그것이다. 이러한 관리시스템은 고가이기 때문에 대부분 그냥 Hypervisor

난 지금 한국의 모 클라우드 서비스 업체의 고객 지원.. 좋은말로 클라우드 컨설팅을 하고 있다. 2011년에 한국에 들어와서 느낀 것은... 해외에서는 2009년쯤에 붐이 일어났는데 이제서야 클라우드 서비스가 시작되는구나.. 싶었다. 그런데.. 이게 웬걸.. 다덜.. 클라우드를 모르고 사업을 하고 개발을 한 것이다. 그이후로 클라우드 컴퓨팅의 진정한 의미를 교육시키며 컨설팅을 해오고 있다. 고객 사이트에 나가서 컨설팅을 하다가 재미난 경우가 있고, 다양한 사례들이 나와 이를 정리를 해보고자 한다. 클라우드 컴퓨팅에 대해서는 아마 이전 투고중에 있을테니 잘 찾아보시길.. ^^;;; 참고로 난 2011년에 한국 클라우드 컴퓨팅 서비스가 오픈된 시점에 모 기업에서 서비스하는 클라우드 컴퓨팅 인프라 관리 솔루션 업체에서 상품기획 및 영업지원, 교육을 맡았다가 잠시 외도를 하고, 2012년 12월 다시 참가를 하게 되었다. =============== 어느날 사업부에서 영업인원이 모자라다고 나혼자 가달라는 부탁을 받았다. 모 종교단체의 온라인 도서관 솔루션을 개발한 업체인 듯 하다. 고객은 60이 넘어보이는 신사같은 느낌의 사람이었다. 나 : "클라우드 컴퓨팅 서비스를 희망하신다고 해서 왔습니다." 고객 : "2년동안 개발을 하다가 자금이 떨어졌는데 이제 올리기만 하면 되요. 클라우딩에 올리면 된다고 들어서 컨설팅을 요청했습니다." 요즘 사이트를 다니면서 "클라우딩" 이란 단어를 많이 듣는다. 어느 사전에도 "클라우딩" 이란 단어는 없는데.. "클라우드 컴퓨팅"을 대충 줄여서 그렇게 말하고 있는걸까... 나 : "서비스를 올리고 싶으신 내용이 무엇이고 어느정도의 자원이 필요한가요?" 고객 : "내가 전문이 아니라서 당신을 부른거 아니요. 이거 직접 보고 산정해주세요." 하면서 PC를

글로벌 노드를 구축하기 위해 AWS(Amazon Web Service)와 Azure를 테스트 하는 중이다. 모두들 AWS를 벤치마크해서 서비스를 준비하기 때문에 모든 기준이 AWS이다.. 그래도 MS의 Azure도 테스트를 해야해서 VM도 만들고 이것저것 해보았다.. 기본 성능 테스트를 했을때.. Azure의 성능이 AWS를 압도적으로 능가했다.. RDP의 반응속도나 SSH반응속도, 네트워크 처리속도등... 그럼 Azure만 쓰면 되는거 아녀? 하고 Azure로 LB까지 세팅해서 만반의 준비를 다 했다.. 서비스하려고 보니.. 응? IP가 바꼈넹.. AWS의 Elastic IP같은거 없나? 아무리 찾아봐도 없다. MS에 물어봤다.. 답변이 왔다.. "연내 출시할 예정입니다." .... 서비스를 하란 말이냐! 참고로, Azure는 VM하나하나 리부팅할때마다 IP바뀌는 것도 모자라.. Windows서버를 디폴트 세팅같은거 해서 실수로 LB밑에 VM 네 개가 수요일 새벽 3시에 동시 리붓하면... LB의 VIP(Virtual IP)도 바껴 버린다... =ㅅ=;;;; 어이어이... 이건 좀 아니지 않아? 결국... 훌륭한 인터페이스니 성능이 있어도.. 아직까지 일반 서비스로 하기에는... 좀.. 뭐, 도메인 베이스의 서비스를 한다면 가능할 수도 있겠지만..