Reference/대규모 시스템 설계

💡 해당 내용은 "가상 면접 사례로 배우는 대규모 시스템 설계 기초"를 참조하여 작성하였습니다.1. Introduction 📌 Key-Value Store서버 개발자라면, 키-값 저장소의 대표격인 Redis 정도는 사용해봤을 것이다.이번 파트는 이러한 키-값 저장소들을 분산 환경으로 설계하는 내용을 다룬다. 그 전에 기초 개념 정도로 책에 나온 내용을 슬쩍 다루고 넘어가야겠다. 💡 키는 짧을 수록 좋다.키-값 저장소의 키는 유일해야 한다.그리고 성능상의 이유로 짧을 수록 좋은데, 그래서 일반 텍스트보다 해시 값을 적용하는 경우가 많다.RDB도 마찬가지 아니냐고 할 수 있겠지만, RDB와 KV Store의 목적이 다름에 주의하자.1️⃣ 메모리 사용량 감소• Redis같은 in-memory 저장소는 모..

1. 수평적 규모 확장에서 고려할 점 📌 수평적 규모 확장 (Horizontal Scaling, Scale-Out)수평적 규모 확장성을 달성하기 위해서는 요청 또는 데이터를 서버에 균등하게 나눌 수 있어야 한다.클라이언트의 요청이 쏟아질 때, 일부 서버에 요청이 몰리지 않게 균등하게 분배해야 한다.데이터들이 균등하게 서버에 배치되어, 한 곳에 부하가 걸리지 않도록 유지해야 한다. 따라서 이번 논제는 "서버의 규모 확장성을 고려한 해시키 설계 방법"이 되겠다. (수직/수평적 규모 확장의 개념은 1장에서 다뤘음) 📌 이상적인 환경에서 key 설계 방법N개의 캐시 서버가 있을 때, 가장 쉽게 키를 설계하는 방법은 serverIndex를 다음과 같이 설정하는 것이다.serverIndex = hash(key)..

📕 목차1. 채팅 시스템2. 프로토콜3. 개략적 설계안4. 데이터 모델5. 상세 설계6. 개인적인 추가 고민1.  채팅 시스템 📌 과거와 현재 채팅 시스템 차이💡 책에 나온 내용은 아니고, 예전에 어딘가에서 읽었던 내용인데 출처가 기억 안 나서 정확성이 떨어집니다.과거에는 채팅 프로그램을 위해 서버가 하는 일은 그저, 두 클라이언트의 연결을 돕는 일이 고작이었다.아마, stateless 환경의 HTTP 프로토콜 방식만으로는 한계가 있었기 때문이 아닐까 싶긴 한데, 그렇게 할 수밖에 없었던 이유를 당췌 못 찾겠다. 아무튼, 1:1 실시간 소통이 고작이라면 위 방식도 기능을 제공함에 있어 문제가 되진 않을 것이다. (데이터 보존 원칙같은 건 전부 무시하고, 순수하게 기능 제공 측면만을 고려했을 때)하지..

📕 목차1. 유일 ID 생성기2. 개략적 설계3. 상세 설계1. 유일 ID 생성기 📌 auto_increment는 답이 될 수 있을까?DB가 단일 서버라면 auto_increment가 답이 될 수 있다.하지만 사용자 트래픽이 높은 곳이라면 단일 DB만으로는 요구 사항을 감당할 수 없을 것이다.그래서 DB 서버를 분산화하면, 더 이상 auto_increment만으로는 유일성을 보장할 수 없기에 이를 동기화하는 작업이 필요한데 지연 시간(delay)을 낮추기가 매우 힘들어질 수 있다. 그리고 NoSQL을 사용한다면, 애초에 선택지가 존재하질 않는다는 문제가 존재한다. (여기서부터는 책에서 나온 내용이 이해가 안 가서, 추가 자료 조사와 추론을 기반으로 작성했습니다.) 🤔 DB를 다중화?샤딩을 통해 ma..