welcome!

이번 장에서는 분산 시스템에서 유일 ID를 생성해볼 것 입니다. 아래 문제 이해 및 설계 범위 확정에서 유일 ID 생성기 요구사항을 확인해봅시다. 유일 ID 를 생성하는데 사용 될 수 있는 기법은 총 네가지 입니다. 다중 마스터 복제, UUID, 티켓 서버, 트위터의 스노플레이크 접근법이 있습니다. 이를 차례로 살펴볼 것입니다. 먼저 다중 마스터 복제 입니다. PPT내용으로 갈음합니다. 그다음 UUID인데, UUID는 중복이 발생할 확률이 극히 낮은 방법입니다. 이 내용도, PPT내용으로 갈음합니다. 그다음 티켓서버입니다. 티켓서버도 PPT내용으로 갈음합니다. 마지막으로 스노플레이크 기법입니다. 이번 장에서 가장 주목할 만한 기법입니다. 분할정복을 활용하여 64비트를 각각 나눠서 해결하는 방법입니다. 단..

먼저 이번 장은 내용이 매우 깁니다. 책 주제에서 채팅시스템 설계와 같은 가장 많은 장으로써, 많은 내용을 다룹니다. 다만 내용이 자세하고 깊다기 보다 개념적으로 어루만지는 느낌이라 ... 보다 자세히 보기 위해선, 인터넷 자료나 데이터 중심 애플리케이션 설계라는 책도 같이 보는 것을 추천드립니다. 이번 장에서는 키-값 저장소 설계입니다. 키-값 저장소는 단일 키-값 저장소로 유지하면 충분하지 않아, 그 이상의 것을 이야기 하기 위해 나옵니다. 그 이상의 것은 분산형 키-값 저장소 입니다. 단일 키-값 저장소의 장점은 전부 메모리에 해시테이블로 저장하는 것인데 이 접근 법은 빠른 속도를 보장합니다. 하지만 모든 데이터를 메모리 안에 두는 것이 불가능하다는 약점이 존재 합니다. 다음과 같은 우회법이 있습니..

이번장에서 이야기 할 주제는 안정 해시 설계입니다. 해시 키를 재 배치하는 문제에 대해서 알아볼 것입니다. 수평적 규모 확장을 하기 위해 데이터를 서버에 균등하게 나누는 것인데, 데이터를 서버에 균등하게 나누었을 때 서버의 변화에 따라 생기는 문제에 대한 내용입니다. 서버를 분산했을 때 임의의 데이터를 어떤 서버에 배치시킨다고 할 때 그 데이터를 대표하는 키를 만들고 키에 모듈러 연산을 수행하여 데이터를 해당 서버로 넣습니다. 이 방법이 가장 간단한 방법인데, 간단한 방법이지만, 안타깝게도 서버의 수가 변경한다면 모듈러 연산의 분모가 변경되므로 전반적인 데이터가 저장될 데이터가 변경되게 됩니다. 캐시미스가 많이 발생할 것이고, 이는 감당하기 힘든 문제입니다. 안정해시는 이 문제를 아름답게 해결합니다. 안..

처리율 제한 장치입니다. redis zadd (ordered set)을 활용한 처리율 제한장치 설계 링크 https://medium.com/phyllo-engineering-blog/rate-limiter-using-sorted-set-in-cache-redis-bee5d939448d

이번에 살펴볼 내용은 효과적 시스템 설계 면접 공략법입니다. 총 네 가지 단계 나누어 접근합니다. 첫번째로는 문제 이해 및 설계 범위 확정, 두번째로는 개략적인 설계안 제시 및 동의 구하기, 세번째는 상세 설계, 4단계는 마무리 단계입니다. 크게 흐름을 보자면 추상에서 구체로 들어가고 구체에서 추상으로 다시 나오는 방법입니다. 좀 더 상세하게 설명하자면, 각 단계에서는 면접관의 동의를 구하거나 질문이 오갈 수 있습니다. 추상에서 구체로 넘어가기 전에 면접관들의 동의를 구하고 또는 질문을 통해 앞으로 나아갈 구체적인 방향 가닥을 잡습니다. 그리고 구체 단계에서는 개략적인 설계를 제시하고, 좀 더 심도있는 이야기로 넘어가기전에 동의를 구하고 더 깊은 구체 단계로 나아가게 됩니다. 이 단계에서는 개략적인 설계..

한 사람의 영향도가 너무 큰 시스템은 성공하기 어렵다. 초기설계가 완료되고 상당히 견고해지면 여러사람이 다양한 관점을 가지고 각각 실험을 진행하면서 테스트는 시작된다. - 도널드 커누스 요청, 응답, 질의, 결과 현대 데이터 시스템에서 가정하고 있는 데이터 처리 방식은 먼저 시스템에 요청하거나 지시를 보낸 후 잠시 뒤에 해당 시스템으로부터 결과를 반환받는 방식이다. 데이터베이스, 캐시, 검색 색인, 웹 서버 등 그 밖의 많은 시스템이 이 같은 방식으로 동작한다. 온라인 시스템은 브라우저가 특정 페이지를 요청하든 서비스가 원격 API를 호출하든 일반적으로 사람이 사용자로서 요청을 보내고 응답을 기다린다고 가정한다. 사용자는 오래 기다릴 수 없기 때문에 이런 시스템에서는 응답 시간 단축에 노력을 많이 기울인..

이번 장은 개략적인 규모 측정에 관련한 간단한 팁입니다. 킬로바이트 부터, 기가바이트 테라바이트, 페타바이트는 종종 나올 수 있다고 생가합니다. 일상 생활에서는 테라바이트 까지만 해도 충분하지만, 실무에 데이터를 다루는 데에 있어서 페타바이트 까지 도달하는 경우가 있는 경우를 들었습니다. 각 데이터는 2^10 을 기준으로 대략 1,000이므로(~1024) 1천씩 증가한다고 보면 됩니다. 그리고 응답 지연 값입니다. L1 캐시가 대략 L2캐시 보다 빠르다고 알지만 정확히 몇배가 빠른지는 잘 모릅니다. 2010 자료에 의하면 14배 정도 빠르네요. 그리고 뮤텍스락/언락은 100ns에 이루어집니다. 가장 느린 것은 패킷 왕복지연 시간으로 150ms 입니다. 데이터를 전송하기 위해선 먼저 압축을 하는게 필수적일..

가상 면접 사례로 배우는 대규모 시스템 설계 기초 북리뷰 1장을 시작하겠습니다. 먼저 천리길도 한 걸음부터라는 말이 있듯이 복잡한 시스템을 설명하기 전에 가장 단순한 서버부터 설명하고자 합니다. 먼저 단일 웹서버와 데이터베이스로 시작을 해보겠습니다. 사용자가 사용자 단말 웹브라우저 또는 클라이언트 앱을 이용하여 특정 도메인의 데이터를 요청하면 DNS는 해당 도메인을 ip로 resolve하고, 해당 웹서버로 요청을 가게끔 해줍니다. 그림은 아래와같습니다. 클라이언트의 요청을 받은 웹서버는 필요에 의해 데이터베이스에 접근하여 데이터를 가져오거나 쓰게됩니다. 그리고 데이터를 반환하거나 쓰기 결과를 반환할 수 있습니다. 지금 껏 본 것이 단일 서버, 단일 데이터베이스의 구조입니다. 잠시 다중 웹서버로 넘어가기 ..