기본 콘텐츠로 건너뛰기

라벨이 설계인 게시물 표시

경험자가 이야기 하는 대규모 처리 경험이란?

영상버전 :  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://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만명까지 커버를 했다 칩시다.  여기서 일반적인 동접의 기준도 서비스마

요즘은 아키텍트(Architect) 되기가 더욱 힘들어진 거 같아요.

얼마전 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라는