일상_자기계발

거래소의 기본 기능은 구매자와 판매자가 효율적으로 연결될 수 있도록 돕는 것이다. 1단계: 설계 범위1. 비기능 요구사항가용성: 최소 99.99%, 거래소의 가용성은 매우 중요한 문제. 단 몇 초의 장애로도 평판이 손상될 수 있다.결함 내성: 프로덕션 장애의 파급을 줄이려면 결함 내성과 빠른 복구 메커니즘이 필요하다.지연 시간: 왕복 지연 시간은 밀리초 수준이어야 하며, 특히 p99 지연 시간이 중요하다. 왕복 지연 시간은 주문이 거래소에 들어오는 순간부터 주문의 체결 사신이 반환되는 시점까지다.보안: 거래소는 계정 관리 시스템을 갖추어야 한다. 법률 및 규정 준수를 위해 거래소는 새 계좌 개설 저에 사용자 신원 확인을 위한 KYC 확인을 수행한다.2. 개략적 규모 추정100가지 주식하루 10억 건의 주..

결제 플랫폼은 일반적으로 고객에게 전자 지갑 서비스를 제공하여 고객으로 하여금 지갑에 돈을 넣어 두고 필요할 때 사용할 수 있도록 한다. 예를 들어, 은행 카드에서 전자 지갑에 돈을 이체해 두면 전자상거래 사이트에서 제품을 구매할 때 그 지갑의 돈을 사용하여 결제하는 옵션을 선택할 수 있다. 1단계: 설계 범위1. 기능 요구사항전자 지급 간 이체1,000,000TPS99.99%의 안전성트랜잭션재현성2. 개략적인 규모 추정TPS를 거론한다는 것은 배후에 트랜잭션 기반 데이터베이스를 사용한다는 뜻이다.오늘날 데이터센터 노드에 실행되는 관계형 데이터베이스는 초당 수천 건의 트랜잭션을 지원할 수 있다.이체 명령을 실행하려면 두 번의 연산이 필요하기 때문에 1백만 건의 TPS를 처리하기 위해서는 2백만 TPS를 ..

S3와 유사한 객체 저장소 서비스를 설계한다.S3는 AWS가 제공하는 서비스로 RESTful API 기반 인터페이스로 이용 가능한 객체 저장소이다. 1. 저장소 시스템 1011) 블록 저장소HDD(Hard Disk Drive)나 SSD(Solid State Drive)처럼 서버에 물리적으로 연결되는 형태의 드라이브는 블록 저장소의 가장 흔한 형태다.블록 저장소는 원시 블록(raw block)을 서버에 볼륨(volume) 형태로 제공한다.서버는 원시 블록을 포맷한 다음 파일 시스템으로 이용하거나 애플리케이션에 블록 제어권을 넘겨버릴 수도 있다.데이터베이스나 가상 머신 엔진 같은 애플리케이션은 원시 블록을 직접 제어하여 최대한의 성능을 끌어낸다.서버에 물리적으로 직접 연결되는 저장소에 국한되지 않고, 고속 ..

결제 시스템이란?위키백과에 따르면 "금전적 가치의 이전을 통해 금융 거래를 정산하는데 사용되는 모든 시스템"이다.1단계: 설계 범위1. 기능 요구사항대금 수신(pay-in) 흐름: 결제 시스템이 판매자를 대신하여 고객으로부터 대금을 수령한다.대금 정산(pay-out) 흐름: 결제 시스템이 전 세계의 판매자에게 제품 판매 대금을 송금한다.2. 비기능 요구사항신뢰성 및 내결함성: 결제 실패는 신중하게 처리해야 한다.내부 서비스와 외부서비스 간의 조정 프로세스: 시스템 간의 결제 정보가 일치하는지 비동기적으로 확인한다.3. 개략적인 규모 추정하루에 100만건의 트랜잭션을 처리해야 한다.이는 초당 10건의 트랙잭션(TPS)이다.일반적인 데이터베이스로 별 문제 없이 처리 가능한 양이다.2단계: 개략적 설계안결제 ..

순위표란? 특정 토너먼트나 경연에서 누가 선두를 달리고 있는지 보여주기 위해 게임등에서 흔히 사용하는 장치다.사용자는 과제나 도전을 완료하면 포인트를 받으며, 가장 많은 포인트를 획득한 사람이 순위표의 맨 위에 자리한다.1단계: 설계 범위1) 기능 요구사항순위표에 상위 10명의 플레이어를 표시한다.특정 사용자의 순위를 표시한다.어떤 사용자보다 4순위 위와 아래에 있는 사용자를 표시한다.2) 비기능 요구사항점수 업데이트는 실시간으로 순위표에 반영한다.일반적인 확장성, 가용성 및 안정성 요구사항3) 개략적 규모 추정DAU가 50만 명인 게임의 경우 초당 평균 50명의 사용자가 게임을 플레이한다.사용량이 균등한 경우는 없기 때문에 초당 250명의 사용자를 감당할 수 있어야 한다.QPS는 50 * 10 = 50..

1단계: 설계 범위1. 기능 요구사항호텔 정보 페이지 표시객실 정보 페이지 표시객실 예약 지원호텔이나 객실 정보를 추가/삭제/갱신하는 관리자 페이지 지원초과 예약 지원2. 비기능 요구 사항높은 수준의 동시성적절한 지연 시간3. 개략적 규모 추정총 5,000개 호텔, 100만개의 객실평균 객실의 70%가 사용 중이고, 평균 투숙 기간은 3일이라고 가정일일 예상 예약 건수: 233,333초당 예약 건수  ~3., 그다지 높지 않다.2단계: 개략적 설계안1. API 설계reservationID는 이중 예약을 방지하고자 동일한 예약은 단 한 번만 이루어지도록 보증하는 멱등 키(idempotent key)다.이중 예약은 같은 날 같은 객실에 예약이 중복으로 이루어지는 것을 말한다.(동시성 문제)호텔 관련 APIA..

페이스북이나 구글 규모에 걸맞는 광고 클릭 이벤트 집계 시스템을 설계한다.온라인 광고의 핵심적 혜택은 실시간 데이터를 통해 광고 효과를 정량적으로 측정할 수 있다는 것이다.디지털 광고의 핵심 프로세스는 RTB(Real-Time Bidding), 즉 실시간 경매라고 부르고 RTB 프로세스는 1초내에 모든 프로세스가 마무리된다. 데이터의 정확성도 중요하다. 광고 클릭 이벤트 집계는 온라인 광고가 얼마나 효율적이었는지 측정하는데 결정적인 역할을 하며, 광고주가 얼마나 많은 돈을 지불할지에 영향을 끼친다.클릭 집계 결과에 따라 광고 캠페인 관리자는 광고 예산을 조정하기도 하고, 타깃 그룹이나 키워드를 변경하는 등 광고 전략을 수정하기도 한다. 핵심 지표는 CTR(Click-Through Rate, 클릭률), C..

1단계: 설계 범위1. 개략적 요구사항대규모 인프라를 모니터링일간 활성 사용자수(DAU, Daily Active Users)는 1억 명서버 풀 1,000개, 풀당 서버 수 100개.데이터 보관 기간 1년수집한 데이터를 보관하는 기간은 일주일, 그 뒤에는 1분 단위 데이터로 변환 후에 30일간 보관, 그 뒤에는 1시간 단위 데이터로 변환한 뒤에 1년간 보관모니터링할 지표CPU 사용률요청 수메모리 사용량메세지 큐 내의 메세지 수2. 비기능 요구사항규모 확장성: 늘어나는 지표 수와 경보의 양에 맞게 확장될 수 있어야 한다.낮은 응답 지연:대시보드와 경보를 신속하게 처리할 수 있도록, 질의에 대한 낮은 응답 지연 보장안정성: 높은 안정성을 제공하여 중요 경보를 놓치지 않도록 해야 한다.유연성: 기술은 계속 변화..

3단계: 상세 설계6. 푸시 vs 풀브로커가 데이터를 소비자에게 보낼 것이냐 아니면 소비자가 브로커에게 가져갈 것인지 고민해야하는 부분이다.푸시 모델잠정낮은 지연: 브로커는 메세지를 받는 즉시 소비자에게 보낼 수 있다.단점소비자가 메세지를 처리하는 속도가 생산자가 메세지를 만드는 속도보다 느릴 경우, 소비자에게 큰 부하가 걸릴 가능성이 있다.생산자가 데이터 전송 속도를 좌우하므로, 소비자는 항상 그에 맞는 처리가 가능한 컴퓨팅 자원을 준비해두어야 한다.풀 모델장점메세지를 소비하는 속도는 소비자가 알아서 결정한다.소비자는 지난번 마지막으로 가져간 로그 위치 다음에 오는 메세지를 한 번에 가져갈 수 있다. 따라서 데이터의 공격적 일괄 처리에 더 적합하다.단점브로커에 메시지가 없어도 소비자는 계속 데이터를 끌..