Talk Lowy(kr)

영상버전 :  https://youtu.be/gkMwrSJsUVo  제가 재섭게 자랑처럼 맨날 이야기 하는내용이 있잖아요? 4000만 DAU 60만 동접 120만 TPMC 300Gbps 트래픽 2억대 펌웨어 다운로드.. 1.76PB 머신러닝 팜 설계 DR을 Active화 하여 Geo Balancing구성을 했다거나 소프트뱅크 페퍼 공식 저서 작성 각종 블록체인의 소스코드 분석 및 토큰 에코노미 분석 요즘은 chatgpt프로젝트 세 개나 했구요..  혹자는 이렇게 생각하겠죠.. 저거 구라 아냐? 저정도 해본 인간이 왜 찌질하게 몇 명 없는 유튜브나 하고 있어? 라구요..  저처럼 지지리도 운도 없고 영어도 못하면 이 정도 실력을 가지고 있어도 이렇게 찌질하게 유튜브나 찍으면서 자기 잘난 맛에 보는 사람 없이 떠들기도 한답니다.  어디 엄청난 선구안을 가진 사람이 절 안주워갈려나요?  어디선가 저의 진짜 모습에 투자해주실 분을 기다리면서 홀로 방송 해봅니다. ^^ 주변에 엄청난 분이 계시다면 제 영상을 꼭 보여주세요~~ 쓸데없는 말은 이정도 하구요..  얼마전 대규모 설계 경험자 모집이란 내용에 대한 썰을 푸는 영상을 보았는데요..  이런 대규모 설계는 다른 설계와 뭐가 다르길래 대규모 처리 경험자와 비 경험자가 나뉘어지게 되는걸까요? 그 전에 그 대규모 라는 건 어떤 기준일까요?  제가 생각하는 대규모 라고 접어드는 단계는  서버 한 두대 정도로 케어할 수 없는 규모의 처리를 이야기 한다고 생각합니다.  예를 들어서 이런게 있죠.  하루 4천만 유저가 들어오는 시스템의 가장 중요한 건 무엇일까요?  제가 강조할 때 4000만DAU를 말하면서  다른 서비스에서는 동시 60만 클릭을 다시 이야기 합니다.  그냥 4000만으로 퉁치면 되는 거 아닌가요?  하루는 1440분 입니다. 1분에 약 3만 명의 사용자, 초당 500명의 사용자라면 순간 동접으로 따지면 그렇게 크지 않아요.   즉, 4000만 DAU일때 신경써야 하는 인프라와 60만 동시 리퀘스트에서 신경써야

영상버전 :  https://youtu.be/20n_I2J4cRs 요즘 AI, AI만 이야기 하고 있잖아요?  저도 AI를 활용한 여러가지 비즈니스를 준비는 하고 있지만,  오히려 이렇게 AI도배된 시기에 역행하는 라떼는 코너를 한 번 만들어보고 싶었습니다. 요즘 IT에 들어온 사람들은 모두 클라우드 환경이 기본이다보니  실제로 디스크를 본 적도 없는 사람도 있고 하더라구요..  아마 이젠 쓸모 없는 내용이 될 수도 있겠지만, 기록을 위해 남기는 것이니 흥미가 있는 분들만 들어주시면 됩니다,. 2000년대까지만 해도 데이터센터를 회사마다 작게는 1/4랙이나 1U단위에서 많게는 Cage라고 해서 24랙 정도 까지 직접 계약을 했었기 때문에 데이터센터를 관리하는 일이 참 많았었죠.  그 때는 고객들이 인터넷상에 서비스를 올리고자 하는데 서버구성까지 맡기는 경우가 많았습니다.  그래서 많은 서버나 장비들을 만져보고 테스트도 했었지요.  그 때 당시엔 하드 용량도 20GB나 80GB가 주력 이다보니 온라인 게임이 급격하게 성장했던 시기에 너무 데이터 저장 공간이 부족했죠. 데이터센터를 못가보신 분들도 많겠지만 이 때는 개발자도 데이터센터 달려가서 작업하던 때도 많았죠..  서버 랙을 열어보면 서버만 있는것도 아니고 별의 별 짓을 다해놓곤 하는데요..  랙 안에 자기 작업 공간처럼 황당하게 꾸민 경우도 있었는데 그 때는 사진을 안찍어놨네요..  랙 안에서 가장 신기한게 디스크들이 아주 많은 케이스였는데요..   이 때 DAS나 SAN, NAS를 효율적으로 사용해서 데이터 관리를 했습니다.  요즘 클라우드 시대에는 HDD, SSD를 쓸거냐 S3를 쓸거냐 정도인데요..   이들도 하드웨어는 SAN이나 NAS를 쓸 겁니다. 그게 서비스로 올라와서 저렇게 불리는 거죠.  요즘 세대에서는 개발자라고 들어왔지만 이 개념을 정확하게 몰라서 개발 피씨에서는 잘되던게 서버에만 올리면 안되요 하면서 premium ssd로 변경해서 요금 폭탄을 맞곤 하죠.   Aws에서 프리미엄 ssd보

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

음성 버전 :  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을 걸지 않으면 NoSQL처럼 느려터져 죽습니다.  양이 많은 DB에서 양이 적은 테이블을 가져와서 JOIN을 해야겠지요..  이렇게 해서 동접 10만명까지 커버를 했다 칩시다.  여기서 일반적인 동접의 기준도 서비스마

많은 일본 기업의 IT, DX(디지털 트랜스포머) 를 지원해 오면서 느낀 내용들을 정리 해본다.  토요타의 내부 인트라넷은 하루 30만명이 매일 아침에 접속을 한다.  관계 기업들도 접속을 해서 아침업무 확인 및 지시를 하기 때문이다.  여타 서비스에 비해 상당히 규모가 크다.  게다가 하나의 환경만 쓰는 것이 아니라 업무에 따라 많은 환경을 만들고 그들끼리 연결할 수 있는 방법론을 통일 하는 것에 더 많은 신경을 쓰고 있다.  때문에 연결사양서가 가장 중요한 포지션을 가지고 있다.  한국처럼 "갈아엎고 다시"는 통하지 않는다.  기존 환경에 어떻게 효율적으로 연결하느냐를 가장 중요시 한다.  다른 업무 환경이 무엇으로 이루어져 있는지 확인할 수 없다. 게다가 확인할 필요가 없도록 연결사양서를 받는다.  그러면 제일 먼저 할 것이 연결 사양서로 주고 받는 데이터가 무엇이고, 받은 데이터를 누가 가져가며 어디서 병목이 발생하는지를 체크해야 한다.  그리고 새로 구성된 환경을 이용하는 사람들이 어떠한 쿼리로 얼마나 집중해서 처리하는지를 분석하고 퍼포먼스 지표를 만든다.  이렇게 준비된 자료를 기반으로 스테이징을 구성하고 기존 개발 환경에서 자동 디플로이가 되도록 스크립트를 만들어 개발팀에 주면 준비는 끝.  스테이징 환경으로 올라온 서비스에 부하를 주는 설계를 한다.  부하가 정상적을 줄 수 있게 되면 그 타이밍에 부하를 주고 나머지 사람들은 자기 분야에서 병목이 발생하는지 확인한다.  들어온 부하들을 종합해서 퍼포먼스 분석 레포트를 하고,  분석 결과를 기반으로 튜닝 포인트를 찾아낸다. 대부분의 인프라 설계 및 튜닝 포인트를 찾아서 각 분야의 담당자에게 튜닝 어드바이스를 하는게 내 일이다. OS 레벨 및 Network레벨에서 DB, 소스 코드 레벨까지 튜닝 포인트를 찾을 수 있는 사람은 흔하지 않기 때문이다.  그렇게 튜닝된 자료를 기반으로 수 차례 부하테스트, 튜닝을 반복한다.  마지막으로 더이상 튜닝할 곳이 없게 되면 그 상황에서 Produ