알림 시스템 뉴스, 업데이트, 이벤트, 선물 등 고객들에게 주요할 수 있는 정보들을 비동기적으로 제공하기 위해 사용하는 시스템 크게 모바일 푸시 알림, SMS 메시지, 이메일 로 알림 시스템을 분류할 수 있다. 문제 이해 및 설계 범위 확정 하루에 백만 건 이상의 알림을 처리하는 확장성 높은 시스템을 구축하는 건 쉬운 과제가 아니다. 알림 시스템이 어떻게 구현되는 지에 대한 깊은 이해가 필요하고, 모호하게 문제가 주어질 가능성이 높기 때문에 적절한 질문을 통해 요구 사항이 무엇인지 스스로 도출해야 한다. 요구사항 지원하는 알림 종류: 푸시 알림, SMS 메시지, 이메일 연성 실시간 시스템(Soft real-time system) 알림은 가능한 빨리 전달되어야 하지만 시스템에 높은 부하가 걸렸을 때, 약간의 지연은 허용됨 IOS, AOS, Laptop/Desktop 지원 알림을 만드는 생산자는 클라이언트, 서버 스케줄링 사용자는 알림 설정을 통해서 수신 거부를 할 수 있어야 한다. 알림 전송 수 모바일 푸시: 10,000,000 건 이상 SMS 메시지: 1,000,000 건 이상 이메일: 5,000,000 건 이상 개략적 설계안 제시 및 동의 구하기 알림 유형별 지원 방안 IOS 푸시 알림 알림 제공자(Provider)

문제 이해 및 설계 범위 확정 ID는 유일해야 한다. ID는 숫자로만 구성되어야 한다. ID는 64비트로 표현될 수 있는 값이여야 한다. ID는 발급 날짜에 따라 정렬 가능해야 한다. 초당 10,000개의 ID를 만들 수 있어야 한다. 요구사항을 이해하고 모호함을 해소하는데 초점을 갖고 질문을 해야 한다. 개략적인 설계안 제시 및 동의 구하기 다중 마스터 복제(Multi-master replication) 데이터베이스의 Auto increment 기능을 활용한다. 다음 ID 값을 구할 때1만큼 증가 시키는 것이 아닌 K 만큼 증가시킨다. K는 현재 사용중인 데이터베이스 서버의 수다. 다중 마스터 복제의 단점 여러 데이터 센터에 걸쳐 규모를 늘리기 어렵다. ID의 유일성은 보장되지만 그 값이 시간 흐름에 맞추어 커지도록 보장할 수는 없다. 서버를 추가하거나 삭제할 때도 잘 동작하도록 만들기 어렵다. 서버를 추가/삭제 시 키 설정 시 정했던 K가 변동이 되어 이전 키와 신규 생성 키의 생성 규칙이 달라지게 됩니다. UUID(Universally Unique Identifier) 유일성이 보장되는 ID를 만드는 또 하나의 간단한 방법 컴퓨터 시스템에 저장되는 정보를 유일하게 식별하기 위한 128비트의 수

키-값 저장소(Key-Value Store) 키-값 저장소(Key-Value Store)는 키-값 데이터베이스라고도 불리는 비 관계형(non-relational) 데이터베이스이다. 저장소에 저장되는 값은 고유 식별자(identifier)를 키로 가져야 한다. 키와 값 사이의 이런 연결 관계를 키-값 쌍(key-value pair)라고 한다. 키-값 쌍에서 키는 유일해야 하며, 해당 키에 매달린 값은 키를 통해서만 접근할 수 있다. 키는 일반 텍스트, 해시 값 등일 수 있다. 값을 구분할 수 있는 키면 된다. 키는 짧을 수록 좋다. 값은 문자열, 리스트(List), 딕셔너리(Dictionary), 객체(Object) 등이고, 값으로 무엇이 오든지 상관없다. Amazon DynamoDB, Memcached, Redis 등이 있다. 문제 이해 및 설계 범위 확정 완벽한 설계란 없다. 읽기, 쓰기 그리고 메모리 사용량 사이에 어떤 균형을 맞추고, 데이터의 일관성과 가용성 사이에서 타협적 결정을 내려야 한다. 키-값 상의 크기는 10KB 이하이다. 큰 데이터를 저장할 수 있어야 한다. 높은 가용성을 제공해야 한다. 따라서 시스템은 설사 장애가 있더라도 빨리 응답해야 한다. 높은 규모 확장성을 제공해야 한다. 따라서 트래픽 양에 따라 자동적으로 서버 증설/삭제가 이루어져야 한다. 데이터의 일관성 수준은 조정이 가능해야 한다. 응답 지연시간(Latency)이 짧아야 한다. 단일 서버 키-값 저장소 한 대의 서버만 사용하는 키-값 저장소를 설계하는 것은 쉽다. 가장 직관적인 방법은 키-값 전부를 메모리에 해시 테이블로 저장하는 것이다. 약점

서평 3장을 처음 읽었을 때 생각이 든 건, 사실 해당 내용은 평소에 시스템을 설계할 때 어떻게 접근할 지 겪을 때 주로 고민하는 내용이라고 생각했습니다. 회사마다 시스템이 다르고, 이를 여러 사람들이랑 같이 만들어야 합니다. 그렇기 때문에 분야가 프론트엔드, 백엔드 등으로 다양하게 나누고 회사에서 채용합니다. 회사 내부에서 시스템을 설계할 때 협업을 해야하는 경우가 많습니다. 이 때 같이 일하는 사람들끼리 시스템을 접근하는 방법에 따라서 쉽게도 어렵게도 해결할 수도 있습니다. 매번 정말 좋은 방법으로만 해결할 수는 없지만, 책에서 나오는 방법을 통해서 구체적으로 문제를 접근할 수 있다고 생각합니다. 문제 이해 및 설계 범위 확정: 요구사항 및 가정 이해 및 모호함 제거, 깊이 생각하고 질문함. 개략적인 설계안 제시 및 동의 구하기: 요구사항에 맞는 시스템 컴포넌트 설계 및 제약사항 만족 여부 파악 상세 설계: 시스템에서 달성해야 할 목표 및 기능 범위 파악, 청사진(Blueprint) 마련, 면접 담당자(팀원) 의견 청취 마무리: 병목 지점(Bottlenack) 파악, 설계에 대한 요약, 오류 발생 시 영향 범위 제시, 운영 이슈(지표 수집, 로그 설계, 배포 등), 규모 확장 요구, 기타 개선 사항 같이 일하는 과정을 면접에서 시스템 설계로 책은 표현합니다. 짧은 시간 내에 면접을 담당하는 실무자(이하, 면접 담당자)는 면접자가 같이 일하기 적합한 사람인 지 판단하기 위한 다양한 방법을 사용합니다. 방법 중에서 시스템 설계 면접은 효율적인 방법 중 하나라고 생각합니다. 면접 시간은 제한이 있고 이 안에 가장 효율적인 방법으로 면접자는 문제를 풀어야 합니다. 실무에서 겪었던 상황들과 배운 것들을 종합적으로 판단하여 풀면서 면접자는 평소에 갖고 있던 습관들이 나올 수 있습니다. 이를 보면서 면접 담당자는 같이 일할 사람인 가를 면밀하게 판단할 수 있습니다. 해당 장은 두 사람 모두에게 좋은 영향을 줄 수 있는 방법들을 제시합니다. 책에서는 시스템 면접 설계를 다음과 같이 이야기 합니다. 시스템 설계 면접은 두 명의 동료가 모호한 문제를 풀기 위해 협력하여 그 해결책을 찾아내는 과정에 대한 시뮬레이션 해당 접근 방법을 이후 장에서 각각 아키텍처와 관련된 면접 내용을 설명할 때 구성됩니다. 시스템 면접 시 고려할 부분 해야 할 것 질문을 통해 확인하라. 스스로 내린 가정이 옳다 믿고 진행하지 말라. 문제의 요구사항을 이해하라. 정답이나 최선의 답안 같은 것은 없다는 점을 명심하라. 면접관이 여러분의 사고 흐름을 이해할 수 있도록 하라. 면접관과 소통하라. 가능하다면 여러 해법을 함께 제시하라. 개략적 설계와 면접관이 동의하면, 각 컴포넌트의 세부사항을 설명하기 시작하라. 가장 중요한 컴포넌트부터 진행하라. 면접관의 아이디어를 이끌어 내라. 좋은 면접관은 여러분과 같은 팀원처럼 협력한다. 포기하지 말라. (Don’t give up!)

서평 1장을 보고 2장부터 필기를 하기 시작하였습니다. (1장은 시간되는데로 필기 예정) 많은 사람들이 가상 면접 사례로 배우는 대규모 시스템 설계 기초 책을 많이 학습한 것으로 알고 있었습니다. 그래서 2023년도 초에 책을 구매하고 이제서야 산지 1년만에 1장부터 읽어 나가기 시작하였습니다. 오늘 작성한 2장은 이러한 규모를 어떻게 추정할 지에 대한 개략적인 규모 추정에 대한 이야기가 써져 있었습니다. 2장은 데이터엔지니어로 일하고 있는 저에게는 중요한 내용 중 하나입니다. 데이터 저장소가 얼만큼 적재될 지, 파이프라인 동작 시간은 얼마일 지 추정하여 계획을 세우는 작업을 해야 하기 떄문입니다. 특히나 현재 회사에서는 파이프라인을 구성하는데 AWS Lambda를 사용하고 있습니다. AWS Lambda 는 메모리나 타임아웃 시간 등을 직접 정해야 하기 때문에 해당 작업이 얼마만큼의 시간을 갖어야 하는 지에 따라서 최대로 제공되는 15분이 부족할 수 있습니다. (주로 API를 통한 데이터 증분 시 Network Latency 때문에 부족한 경우가 많이 발생 했었습니다. Next Cursor 😭) 시간, 메모리, CPU, GPU 등 이를 발견하고 조치를 해야지 안정적으로 데이터 파이프라인이 유지될 수 있었습니다. 특히 고가용성이나 SLA 같은 내용들이 저에게는 빅테크 기업들에서만 사용되는 것들이라 생각했었습니다. 사실은 현재 운영하고 있는 파이프라인, 서버들에도 충분히 적용할 수 있는 내용이였습니다. 이런 부분을 계산해야겠다라고 생각을 못하고 있었는데 인식을 바꾸어주어 책이 저에게 좋은 영향을 준 것 같습니다:) 개략적인 규모 추정(back-of-the-envelope experiments) 보편적으로 통용되는 성능 수치 상에서 사고 실험을 행하여 추정치를 계산하는 행위 어떤 설계가 요구사항에 부합할 것인지 보기 위한 것 효과적으로 해 내려면, 규모 확장성을 표현하는 데 필요한 기본기에 능숙해야 함 특히, 2의 제곱수나 응답 지연(latency) 값, 가용성과 관계된 수치들을 기본적으로 잘 이해하고 있어야 한다. 2의 제곱수 분산 시스템에서 다루는 데이터 양은 엄청나게 커질 수 있으나, 그 계산법은 기본을 벗어나지 않음. 제대로 된 계산 결과를 얻으려면 데이터 볼륨의 단위를 2의 제곱수로 표현하면 어떻게 되는 지를 알아야 한다. 최소 단위는 1바이트 = 8비트 1KB(210), 1MB(220), 1GB(230), 1TB(240), 1PB(2**50) 응답 지연(Latency) 값 개략적으로 응답 지연값을 참조하여 시스템을 설계할 때 소요되는 시간을 산정할 수 있다. ns = nanosecond(나노초) = (1 / 10 ** 9)초 us = microsecond(마이크로초) = (1 / 10 ** 6)초 ms = milisecond(밀리초) = (1 / 10 ** 3)초 연산명 시간

문제 이해 및 설계 범위 확정 시스템 설계 면접 문제는 의도적으로 어떤 정해진 결말을 갖지 않도록 만들어진다. 면접장에서 시스템을 성공적으로 설계해 내려면 질문을 통해 모호함을 줄이고 요구사항을 알아내야 한다. 설계 범위(요구 사항) URL 단축: 주어진 긴 URL을 훨씬 짧게 줄인다. URL 리디렉션(Redirection): 축약된 URL로 HTTP 요청이 오면 원래 URL로 안내 높은 가용성과 규모 확장성, 장애 감내 요구 개략적 추정 쓰기 연산: 매일 1억 개의 단축 URL 생성 초당 쓰기 연산: 1억(100,000,000) / 24 / 3,600 = 1,160번 읽기 연산: 읽기 연산과 쓰기 연산 비율은 10:1, 읽기 연산은 초당 11,600회 발생 URL 단축 서비스를 10년간 운영한다고 가정하면 1억 * 365 * 10 = 3,650억개의 레코드를 보관해야 함 축약 전 URL의 평균 길이는 100 Byte 라 가정 10년 동안 필요한 저장 용량은 3,650억 * 100 Byte = 36.5TB 개략적 설계안 제시 및 동의 구하기 API 엔드포인트 클라이언트는 서버가 제공하는 API 엔드포인트를 통해서 서버와 통신 REST 스타일로 API 설계 URL 단축용 엔드포인트 새 단축 URL을 생성하고자 하는 클라이언트는 해당 엔드포인트에 단축할 URL을 인자로 실어서 POST 요청 API Method: POST

웹 크롤러 로봇(Robot) 또는 스파이더(Spider)라고 부른다. 검색 엔진에 널리 사용되는 기술, 웹에 새로 올라오거나 갱신된 콘텐츠를 찾아내는 것이 주된 목적 웹 페이지 내 글자, 이미지, 비디오, PDF 파일 등 수집 페이지 링크 등을 욺겨다니면서 새로운 컨텐츠 수집 활용 용도 검색 엔진 인덱싱(Search Engine Indexing) - 크롤러의 가장 보편적 용례 웹 아카이빙(Web Archiving) - 나중에 사용할 목적으로 장기보관을 위해 웹에서 정보 수집 웹 마이닝(Web Mining) - 유용한 정보(기업 정보, NFT 정보 등) 수집 웹 모니터링(Web Monitoring) - 저작권에 침해되는 자료 발견 웹 크롤러의 기능은 다양하고, 설계에 따라서 규모가 달라지기 때문에 이에 대한 요구사항(데이터의 규모, 기능 등)을 명확하게 확인해야 한다 문제 이해 및 설계 범위 확정 요구사항 검색 엔진 인덱싱 월 10억 개(1B) 웹 페이지 수집 새로 만들어진 웹 페이지 및 수정된 웹 페이지 고려 저장된 페이지는 5년간 저장 중복된 컨텐츠를 갖는 페이지 무시 좋은 웹 크롤러가 만족시켜야 할 속성 병행성(parallelism) - 병렬적으로 수십억개의 페이지를 수집한다. 안정성(Robustness) - 웹은 함정(잘못 작성된 HTML, 악성코드 등)이 많기 떄문에, 이런 비정상적인 입력이나 환경에 대응할 수 있어야 한다.