기본 콘텐츠로 건너뛰기

당신은 AWS파? Azure파? 클라우드를 선택하는 기준을 설명드립니다!

듣기 버전 : 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도입을 가이드 해주고 있습니다.

어떤 식이냐면요..

만약 대기업에서 클라우드 화를 시키라는 상부 지시가 왔습니다.
대기업 담당자는 MS를 불러서 이런이런 지시가 왔는데 도와줘! 라고 합니다.
대기업은 이미 MS의 담당자랑 오랫동안 관계를 유지 했기 때문에 상담하기 편하지요..
이 지시를 받은 MS는 자기네 비용으로 저 같은 사람들을 부르죠..
그럼 저같은 컨설턴트가 MS의 이름으로 그 프로젝트에 들어가서 고객 시스템을 분석합니다.
그 중에서 어떤 시스템을 클라우드 화 할 때 얼마나 비용이 줄어들고, 장애 리스크가 얼마나 줄어드는지를 각 기능이나 자를 수 있는 최소 내부 시스템 단위로 정리해서 보고 합니다.
보고를 기반으로 고객 담당자들은 시험삼아 망가져도 안전한 시스템을 선택합니다.
선택된 시스템을 Azure로 올리는 수순서, 기간 정리, 비용을 적습니다.
여기서 이전 비용은 모두 MS에서 지불해 줍니다.
고객은 그냥 월 비용을 낼 뿐이죠.

한국이라면 이러면 대기업은 안하실건가요?
하지만 여기서 일본만 이렇게 하는 이유가 있습니다.

바로 매출의 크기죠.. 그나마 한국이 많이 올라와서 10배 차이가 났죠.. 제가 처음 일본 왔을 때는 25배 정도 차이가 났었거든요..
이 정도 매출을 올려주는데 이렇게 안하면 안되죠..

그래서 한국에선 AWS의 아성을 누가 넘보랴 하고 있지만,
일본MS에서는 AWS따위는 쳐다보지도 않습니다.

왜냐하면 AWS에서는 자기네가 비용 내고 이렇게 옮겨올 수가 없기 때문이지요.
그래도 하도 MS에 계속 털리고 있어서 그런지
얼마전 중소형 규모를 AWS로 이전하는 프로젝트에 참여 했는데,
담당AWS엔지니어 및 파트너 엔지니어가 4명이나 달라붙어서 적극적으로 지원해 주긴 했습니다.
당연히 비용이 나가는건 고객 부담이고, AWS에서 해주는건 파트너 엔지니어의 지원 이랑 무료 사용량을 충분히 주는 정도였지요.

제가 올해와 작년에 참여 했던 DNP(대일본 출판, 일본 최대의 출판회사), 닛츠(일본통운, 일본 최대의 물류 회사), 메이지 야스다 생명(자산 2위 규모의 생명보험회사), 토요타 자동차의 프로젝트를 들어갔는데 모두 AWS가 아니고 Azure 위에서 서비스를 하고 있고, Azure의 제대로 된 서포트를 받고 있었습니다.

AWS프로젝트는 Gree등의 자산 규모 3000억엔 정도의 중대형 규모라면 많이 참여하긴 하고 있지만, 이건 신생기업이라 MS의 입김이 적었을 때 인프라를 선택한 경우이구요, 처음부터 AD를 사용하는 시스템이라면 계정 관리를 그대로 가져가기 때문에 Azure만큼 편한게 없지요..
게다가 AWS는 스타트업등의 작은 기업을 중심으로 퍼지기 때문에 Azure가 고객 하나 잡을 떄 AWS는 고객을 수백에서 수천 고객을 잡아야 합니다.
간단하게 예를 들면요..
전에 들어간 DNP는 Azure 인프라에 매달 2500만엔을 씁니다. AWS에서는 100만엔짜리 고객만 되도 대형 고객이라고 분류해서 담당 엔지니어를 붙여서 전략적으로 끌어옵니다.
토요타도 다양한 곳에서 Azure를 쓰지만 제가 담당했던 사내 인프라의 극히 일부였지만 월 1600만엔이 넘지요..
AWS쓰시는 분은 10만엔만 넘으면 어떻게든 줄이려고 안간힘을 쓰잖아요?
잘 보면 MS는 타게팅을 아주 잘하면서 견실하게 성장중인 것이지요.

일본의 AD의 활용법에 대해서도 할말이 많으니 다음 기회에 또 올려보겠습니다.

MS이야기를 하다보니 MS의 TAM, Technical Account Manager라고 고객 대상으로 기술 서포트를 전담으로 하는 컨시어지 같은 직책인데, 여기에 있던 친구가 제게 자꾸 자기네 고객이슈 중에 해결 못한는 것을 물어보곤 하는데요..
전에도 SQL서버에서 View를 Select했는데 원래 View에서 보여야 하는거랑 필드명이 다르다고 이 해결 방법을 물어봤습니다..

제가 그건 MS버그라서 그냥 view를 alter해주면 해결된다고 얘기 했지요..
MS의 TAM은 내부 전용 MSDN을 사용합니다. 이건 외부에 안알려진 자체 버그들도 있기 때문에 분량이 너무 방대해서 찾는게 더 어렵다고 하네요..

거기서 찾다찾다 못찾아서 제게 물어본 건데
제가 바로 대답해주니까, 어떻게 알았냐고 놀라더라구요..
그래서 제가 물었죠..
네가 MS직원이고 내가 물어봐야 하는거 아냐?
하구요..

참고로 한국은 TAM이란 시스템이 없습니다. 아, 예전에 TAM을 만들려는 움직임이 있었다고 하는데 생겼는지는 잘 모르겠네요. 한국 MS는 지인이 없어서..

전 어느쪽을 쓰던 잘 쓰는 법을 알려주곤 하는데요..
제가 직접 써본 개인적인 의견으로는요..

컴퓨터를 파츠 하나하나 사서 조립하고 튜닝하는거 좋아하는 사람은 AWS가 맞고,
대기업 PC나 맥북 하나 사서 유저로서 활용만 제대로 하고 싶은 사람은 Azure가 맞습니다.

간단하게 예를 들어볼께요..

AWS에서 시스템의 로그를 분석해서 비쥬얼하게 보여줄려면?
AWS좀 하시는 분들! 바로 EKS나 ELK, EFK등등이 떠오르시지요?
그런데 이들을 붙이는데 시간이 얼마나 걸리시나요?
AWS는 전부 다 있는데 끼워 맞추는건 너네들이 알아서 해야해! 라는 것입니다.
컴퓨터 부품을 맘에 드는 것으로 이것저것 사서 조립하고
드라이버가 안맞으면 찾아서 설치하고,
조립이 안되면 고생하고..
하지만 이런걸 즐기는 사람들은 AWS가 익숙하지요?

Azure를 보겠습니다.

Azure는 내가 보고 싶은 application gateway라던가 vm같은 리소스를 선택 하고,
감시 설정 메뉴에 들어갑니다.
그리고 감시항목을 선택하고 저장 장소를 log analytics를 선택하면 끝..
마우스 몇 번 클릭으로 끝납니다.
즉, AWS의 다양함은 없지만, 필요한 것들은 모두 갖추고 있고, 굳이 Kibana를 선택할지 Tableu를 선택할지,
아니면, Elastic search를 선택할지 log stash를 선택할지는
보고자 하는 데이터랑은 상관 없잖아요?
고객은 아무거나 좋으니 이 데이터를 여기서 보게 해줘 인 것 뿐입니다.
거기에 적절한 제품만 넣어주면 되는 것이구요.

더 웃기는 것은 AWS에서 다양한 제품이 있지만 다들 제대로 쓰지 못하기 때문에 결국
AWS에서 가장 쓰기 쉬운 또는 가장 누군가가 만든 도큐먼트가 잘 되어 있는 제품을 쓰거나 누가 이게 좋아 하면 레밍스처러 쓰게 될 뿐이지, 정말로 자기가 그 제품이 좋아서 쓰는 경우는 거의 없는 거 같아요.

자, Azure에 간단히 클릭클릭 만으로
뭘 할 수 있냐구요?
Log Analytics에 가면
SQL처럼 수집된 모든 정보를 자유롭게 JOIN처럼 엮어서 볼 수가 있습니다.
スクリーンショット 2023-11-19 120140

그리고 그걸 그래프로 표시할 수 있구요,
CSV로 다운받을 수도 있습니다.
Tableu같은 서드파티 연결도 connection string만 넣으면 쉽게 연결 됩니다.

AWS의 설정하는데 며칠 걸리고 하는 고생같은게 전혀 없지요..
게다가 수집 항목 조차 all을 선택해서 나중에 로그 용량에 맞추어 항목 조절하거나 저장 기간만 조절하면 됩니다.

MS가 후발 주자인 것은 맞지만,
그 동안 쌓아온 노우하우로 유저의 니즈를 가장 잘 맞춘 것이 MS인 것 같더라구요.
그래서 AWS는 스타트업은 잡았으나 규모가 커지면 Azure에게 빼앗기고 Azure는 잘 키워주셔서 감사합니다 하고 커진 기업을 먹어치우고 성장을 하고 있지요.

이제 가장 중요한 것은 여러분이 무얼 선택할까 인데요..

해외는 대기업이 Azure를 많이 쓴다고 했죠?
즉, 해외에서 대기업에 입사하거나 대기업 프로젝트를 하게 될 수록 Azure를 접할 기회가 많습니다.
스타트업이나 급성장을 좋아하는 일확천금 파라면 AWS가 좋겠지요.

여러분이 클라우드 인프라를 선택할 때는 이런 부분을 초점을 두시기 바랍니다.
물론 이건 일본 및 글로벌 기업에 진출하고자 하는 사람을 위한 조언이지,
한국은 전혀 시장 상황이 다르므로 참고가 되지 않을 것 같네요..

참고로, 저는 스타트업에서도 Azure를 추천하고는 있습니다.
제가 관리하기 편하구요, 가성비 좋게 가져가기 좋거든요..
라이선스 포함 전체적으로도 저렴하게 됩니다.

Azure SQL의 자동 튜닝 같은걸로 DB튜닝은 신경도 안쓰고 있구요..
가끔 들어가서 봐도 퍼포먼스 이슈에 아무것도 안올라와요..할일이 없네요;; ㅠㅡㅠ
저야 무슨 기술을 들이파는 것보다 그냥 고객이 원하는 목적을 최소한의 노력으로 최적의 효율로 제공하고 싶은 것 뿐이지,
엔지니어 기질이 있어서 장인이 되어야 해! 하는 것은 없거든요..
그냥.. Azure는 아무것도 하기 싫은 제게 가장 편한 클라우드 인프라 서비스 인것 같습니다.
어디까지나 제 개인 의견이었구요,

한국처럼 AWS만 좋아 하는 편협한 정보 말고
클라우드에 대해서 조금 더 아시는 기회가 되셨으면 합니다!


giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

댓글

이 블로그의 인기 게시물

Alter table 에서 modify 와 change 의 차이 :: SQL Server

두 개의 차이를 모르는 경우가 많아서 정리합니다.  modify는 필드의 속성값을 바꿀때 사용하구요.. change는 필드명을 바꿀떄 사용합니다.  alter table tbbs modify bNote varchar(2000) NULL; alter table tbbs change bNoteOrg bNoteNew varchar(2000) NULL; change에는 원래 필드와 바꾸고 싶은 필드명을 넣어서 필드명을 바꾸는 것이죠~ 더 많은 SQL Server 팁을 보려면  https://github.com/LowyShin/KnowledgeBase/tree/master/wiki/SQL-Server giip :: Control all Robots and Devices! Free inter-RPA orchestration tool! https://giipasp.azurewebsites.net/

책에서는 안 알려주는 대규모 트래픽을 위한 설계

음성 버전 :  https://www.youtube.com/watch?v=ZZlW6diG_XM 대규모 트래픽을 커버하는 첫 페이지 만드는 법..  보통 DB를 연결할 때 대규모 설계는 어떻게 하시나요?  잘 만들었다는 전제 하에 동접 3000명 이하는  어떤 DBMS를 사용해도 문제 없이 돌아갑니다.  여기서 이미 터졌다면 이 콘텐츠를 보기 전에 DB의 기초부터 보셔야 합니다.  아.. 개발 코드가 터졌다구요? 그럼 개발자를 때리셔야지요..  만약 3000명을 넘겼다면? 이제 Write/Read를 분리해서  1 CRUD + n개의 READ Replica를 만들겠죠?  보통 Read Replica는 5개가 최대라고 보시면 됩니다.  누가 연구한 자료가 있었는데...  6번째 레플리카를 만든느 순간 마스터가 되는 서버의 효율 저하 때문에  5번째에서 6번쨰로 올릴때의 성능이 급격히 줄어든다는 연구 결과가 있습니다.  때문에 Azure에서도 replica설정할 때 5대까지 밖에 설정 못하게 되어 있지요.  유저의 행동 패턴에 따라 다르긴 하지만,  1 CRUD + 5 Read Replica의 경우 동접 15000명 정도는 커버 합니다.  즉, 동접 15000명 에서 다시 터져서 저를 부르는 경우가 많지요..  이 때부터는  회원 DB, 게시판DB, 서비스DB, 과금 DB 등등 으로 성격, 서로의 연관도에 따라 나누기 시작합니다.  물리적으로 DB가 나눠지면 Join을 못하거나 Linked Table또는 LinkDB등의 연결자를 이용해서 JOIN이 되기도 합니다.  그에 따라 성능 차이가 생기지만 가장 중요한 포인트는  서로 다른 물리적 테이블의 JOIN은 인덱스를 타지 않는다!  라는 것입니다. 즉, JOIN할 테이블들을 최소한으로 만든 뒤에 JOIN을 걸지 않으면 NoSQ...

BI의 궁극판! Apache Drill을 써보자!

사실 Apache Drill 은 BI(Business Intelligence)라고 부르는 것 보다는 단순 데이터 연결 엔진이다. https://drill.apache.org/ 하지만 내가 왜 극찬을 하느냐면.. DBA로서 항상 문제가 되어왔던게, 이기종 데이터의 변환이나 처리였다. 포맷을 맞추는데 엄청난 시간이 걸리고, 데이터 임포트 실패가 무수하게 나고.. 한 번 잘못 데이터를 추출하면 다시 조정, 변환, 추출하는데 시간이 많이 걸린다. 그런데! Apache Drill은 그냥 RDB를 CSV랑 연결해서 조인해서 통계를 낼 수 있다. 그것도 표준 SQL을 사용하여! 예를 들어, CSV의 세 번째 컬럼이 price 이고, 물건의 판매이력을 PG사에서 CSV로 출력 받았다. 우리 DB와의 검증을 위해서는 수동으로 Import를 한 뒤에 포맷이 안맞아 잘리는 데이터가 있다면 다시 맞춰주고, 재 임포트를 수십 번, 그리고 나서 겨우 들어간 데이터를 조인하여 빠진 데이터를 분간한다. 숫자가 적다면 개발자가 개발로 처리할 수도 있지만, 건수가 하루에 300만건 짜리라면.. 한 달 온 파일은 9천만 건이다. 프로그램으로 고작 처리하는 것이 초당 500건. 거의 20만초, 에러 없이 약 56시간.. 에러가 생기면 다시 56시간.. ㅠㅡㅠ 이런게 현실이기 때문에 쿼리 말고는 방법이 없다. apache drill 의 진면목을 보자! 이번에는 좀 범용 적인 MySQL DB와 붙여 보자. . 난 이번에는 Mac에서 작업을 했기 때문에 그냥 다운 받아서 풀었음.. https://drill.apache.org/download/ 여기서 자기 OS에 맞는 버전을 받아서 설치하시길.. 압축을 풀고 나면 MySQL 커넥터를 붙여야 한다. https://dev.mysql.com/downloads/connector/j/5.1.html 여기서 다운로드 이런 커넥터 들을 붙일 때마다 콘피그를 수정해 줘야 하지만, 몇 번만...