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/mVwIZ1nof8w 지난 번에 고객의 현재 상황 및 요건을 들었습니다.  원래라면 분석에 2주를 잡긴 하지만, 이번은 아주 간단해서 바로 1차 제안을 세 종류 만들어 봤습니다.  현재 개발사가 제안한 scaling에 대한 문제를 제기해야 겠지요..  우선 원래 시스템 중 문제가 있는 서버의 프로세스 구성입니다.  하나의 VM에 Listener, Real time analyzer, Final Analyzer의 세 개가 돌고 모든 IP PBX의 스트리밍 데이터를 받아서 하나의 VM이 처리를 하고 있는 식이죠.  이걸 분산하려고 하고 있습니다. 우선 개발사가 생각한 1안입니다.  하나의 인스턴스에 Thread를 나누어 처리를 하려고 합니다. 하지만 같은 인스턴스다보니 CPU가 터지는 지금 상황에서는 Thread를 분리해봤자 분리된 Thread가 터져서 인스턴스가 뻗을 것 같네요.  개발사가 제안한 2안 입니다.  이건 두 개의 인스턴스로 나누어 왼쪽에 IP PBX에서 데이터를 받아 리얼타임으로 저장하고 CPU부하가 큰 Final analysis는 다른 인스턴스에서 땡겨서 처리하겠다는 발상인데요.. 아마 이번에 테스트한 50세션 동시 처리에는 먹힐 지도 모르겠습니다. 30정도에서 터졌으니까요..  하지만 이건 일시방편이지, 유저를 계속 늘려가는 서비스 입장에서는 오히려 왼쪽 입구에서 받는 트래픽에 그걸 모아서 오른쪽의 VM 복수개에 동시에 파일을 내보내면 트래픽 병목으로 전송 실패가 나겠죠.  아마 700세션 전후에서 터질 것입니다.  그래서 제가 이 내용을 기준으로 일반적인 제안을 했습니다.  1안입니다.  전형적인 Application Gateway에 VMSS설정으로 Application gateway가 알아서 분산하고 VMSS가 알아서 부하도에 따라 증가 시키는 방식이죠.  장점은 Application Gateway에서 SSL을 관리하므로 SSL의 관리가 단순하고 편합니다. 그리고 모든 부하분산 룰 설정 및 장애 제

음성 버전 :  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

giip에서는 내가 만든 RPA스크립트로 인해서 얼마나 업무 시간을 줄여 주고 있는지 한 눈에 알 수 있습니다.  한 달 평균 업무 시간은 160시간 전후이지만,  로봇은 여러 대로 무한하게 일을 시킬 수 있기 때문에  내가 로봇들에게 시킨 업무로 인해 800시간을 줄일 수 있었네요!  점점 늘어나는 것을 기대하면서 계속 업무를 자동화 해가고 있습니다. ^^ UiPath를 사용해도 되고 Auto Hot Key를 사용해도 됩니다.  아니면 자신이 직접 만든 스크립트를 사용해도 됩니다.  이 모든 것을 giip에서 통합 관리를 하고, 자신이 만든 자동화가 얼마만큼의 인건비를 줄일 수 있었는지 알 수 있는 지표를 대시보드로 나타냈습니다.  여러분은 얼마나 많은 일을 아직까지 수동으로 하고 계신가요? giip :: Free mixed RPA orchestration tool!  https://giipasp.azurewebsites.net/

결국엔 버라이존(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로서 인식하여 부팅