읽은 책 57

7장. 호텔 예약 시스템

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

6장. 광고 클릭 이벤트 집계

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

5장. 지표 모니터링 및 경보 시스템

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

4장. 분산 메세지 큐 - 2

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

4장. 분산 메세지 큐 - 1 편

메세지 큐를 사용하면 어떤 이득을 얻을 수 있을까?결합도 완화(decoupling): 컴포넌트 사이의 강한 결합이 사라지므로 각각 독립적이다.규모 확장성 개선: 데이터를 생산하는 생상자(producer)와 메세지를 소비하는 소비자(consumer) 시스템 규모를 트래픽 부하에 맞게 독립적으로 늘릴 수 있다.가용성 개선: 특정 컴포넌트에 장애가 발생해도 다른 컴포넌트는 큐와 계속 사호작용을 이어갈 수 있다.성능 개선: 메세지 큐를 사용하면 비동기 통신이 쉽게 가능하다. 메시지 큐 vs 이벤트 스트리밍 플랫폼데이터 장기보관, 메세지 반복 소비 등 부가 기능을 갖춘 이벤트 스트리밍 플랫폼을 사용한다.아파치 카프카나 펄사는 메세지 큐가 아니라 이벤트 스트리밍 플랫폼이다.메세지 큐(RokcetMQ, RabbitM..

3장. 구글 맵 - 2편

3단계: 상세 설계1. 데이터모델1) 경로 안내 타일도로 데이터는 외부 사업자나 기관이 제공한 것으로, 방대한 양의 도로 및 메타데이터로 구성된다.가공되지 않은 데이터이므로, 경로 안내 알고리즘의 입력으로 활용할 수 없다.경로 안내 타일 처리 서비스라 불리는 오프라인 데이터 가공 파이프라인을 주기적으로 실행하여 경로 안내 타일로 변환한다. 경로 안내 타일 처리 서비스는 가공 결과로 만든 타일을 어디에 저장해야 할까?=> 일반적으로 그래프 데이터는 메모리에 인접 리스트 형태로 보관한다. 데이터 양이 방대하기 때문에 비용 등의 문제로 S3 같은 객체 저장소에 파일을 보관하고 파일을 이용할 경로 안내 서비스에 적극적으로 캐싱하는 방법이 효율적이다.타일을 객체 저장소에 보관할 때는 지오해시 기준으로 분류해 두는..

3장. 쿠버네티스 - 1편

※ 해당 내용은 도커 홈페이지 및 책 내용을 가져왔습니다. ※  3.1 쿠버네티스 이해하기내용 들어가기 전, 쿠버네티스라는 것이 왜 생겼는지 이해가 필요한 것 같다.1) 여정 돌아보기 전통적인 배포 시대: 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책으로 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행할 수도 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았..

3장. 구글 맵 - 1편

1단계: 설계 범위1) 기능 요구사항지원하는 단말은 모바일, 스마트폰이다.사용자 위치 갱신경로 안내 서비스(ETA 서비스 포함)지도 표시2) 비기능 요구사항정확도: 사용자에게 잘못된 경로를 안내하면 안 된다.부드러운 경로 표시: 경로 안내 용도의 지도는 부드럽게 표시되고 갱신되어야 한다.데이터 및 배터리 사용량: 클라이언트는 최소한의 데이터와 배터리를 사용해야한다.가용성 및 확장성3) 기본 개념 및 용어측위 시스템세계는 축을 중심으로 회전하는 구인데, 측위 시스템은 구 표면 상의 위치를 표현하는 체계이다.위경도 기반의 측위 시스템의 경우, 최상단에는 북근 최하단에는 남극이 있다. 위도(Latitude)는 주어진 위치가 얼마나 남쪽/북쪽인지를 나타낸다.경도(Longitude)는 얼마나 동쪽/서쪽인지를 나타..

2장. 주변 친구

"주변친구" 기능은 본인 위치 정보 접근 권한을 허락한 사용자에 한해 인근의 친구 목록을 보여주는 시스템이다.근접성 서비스의 경우 사업장 주소는 정적이지만, 주변 친구 위치는 자주 바뀔 수 있다.1단계: 설계 범위 확정기능 요구 사항모바일 앱에서 주변 친구를 확인할 수 있어야 한다.주변 친구 목록에 보이는 각 항목에는 해당 친구까지의 거리, 해당 정보가 마지막으로 갱신된 시각(timestamp)이 함께 표시친구 목록은 몇 초마다 한 번씩 갱신되어야 한다.비기능 요구 사항낮은 지연 시간(low latency): 주변 친구의 위치 변화가 반영되는데 오랜 시간이 걸리면 안된다.안정성: 때로 몇 개 데이터가 유실되는 것 정도는 용인할 수 있다.결과적 일관성(eventual consistency):강한 일관성을 ..