시스템 디자인

1. 서비스 규모의 확장

분리 - 단일서버, DB, 서버, 데이터 센터

확장

[참고](https://thalals.tistory.com/386)

1. 단일서버
2. 웹 브라우저, DNS, 웹서버
3. 데이터베이스의 분리
   1. RDBMS vs NoSQL
4. 수직적 규모확장 vs 수평적 규모확장
   • 수직적 규모확장, 수평적 규모확장 차이점
   • 로드 밸런서
     • 과정
     • 장애 대응 과정
   • DB 다중화
     • 개념
     • 장점
   • 로드 밸런서 + DB 다중화 시스템 설계
5. 캐시
   • 하는 이유 - 응답시간 개선
   • 과정
   • 유의할 점
6. CDN
   • 개념 - 정적 콘텐츠 전송 네트워크
   • 하는 이유 - 응답 시간 개선
7. 무상태 웹 계층 (Stateless)
   • rest api 왜씀?
8. 데이터 센터
   • 사용하는 이유 - 대용량 데이터, 고가용성, 장애 대응
   • 기술적 난제 - 트래픽 우회, 데이터 동기화, 테스트와 배포
9. 메시지 큐
   • 개념 - 메시지의 무손실 비동기 통신 지원 컴포넌트
   • 과정
   • 장점
10. 데이터베이스의 규모 확장 (샤딩과 파티셔닝)
    • 샤딩
    • 하는 조건
    • 샤딩 vs 파티셔닝

2. 개략적인 규모 측정

[참고](https://thalals.tistory.com/389)

규모를 추정하여 어떤 설계가 요구사항에 부합할 것인지를 보기 위한 것

1. 2의 제곱수
2. 데이터 볼륨의 단위를 2의 제곱수로 표현하는 방법을 알아야 한다.
3. 응답지연 값
4. 컴퓨터 연산 처리 속도 보기
5. 가용성에 관계된 수치들
   • 고가용성 : 지속적을 중단 없이 운영될 수 있는 능력
   • SLA(Service Level Agreement) : 9가 많으면 많을수록 좋은 것
6. 트위터 시스템 설계 예시
   • QPS(Query Per Second)
   • 저장소 요구량(미디어)

3. 시스템 설계 면접

[참고](https://thalals.tistory.com/390)

1. 기술 면접을 보는 이유
   • 기술적인 측면만을 평가하는 자리가 아님
     • 협력
     • 암박 상황 극복
     • 모호한 문제도 건석적으로 해결
     • 타협적 설계(비용)
2. 엔지니어가 가져야 할 기술
   1. 올바른 질문을 할 것
   2. 적절한 가정을 할 것
   3. 시스템 구축에 필요한 정보를 모을 것
3. 면접 떄 해야할 것, 하지 말아야할 것
   • 해야 할 것
     • 면접관을 마치 팀원인 것 처럼 대하자
     • 뇌피셜 안된다. 질문으로 확인하라. (clarification)
     • 문제의 요구사항을 **이해**하라.
     • 정답이나 최선의 답안같은 것은 없다. **요구사항을 정확하게 이해**했는지 확인하자
     • 나의 사고의 흐름을 이해할 수 있도록 설명하자, 즉 **면접관과 소통**하자
     • 가능하다면 여러 해법을 함께 제시하자
     • 전반적인 내용에 면접관이 동의하면, 그 때 면접관과 함께 세부적인 사항에대해 이야기해보자
       • 면접관의 생각도 좀 들어가며 하자. 혼자 북치고 장구치지 말자
       • 재밌게 면접하자: 면접관의 아이디어를 이끌어보자.
     • **포기하지 말라. 🔥**
     • 모르면 물어보자
   
   
   • 하지 말아야 할 것
     • 전형적인 면접 문제들을 대비하지 않은 상태에서 면접장에 가지 말자
     • 요구사항이나 가정들을 분명히 하지 않은 상태에서 설계를 제시하지 말자
     • 처음부터 특정컴포넌트 세부사항을 깊이 설명하지 말자
     • **📌 막히면 힌트를 청해보자!! 주저하지 말자.**
     • 소통을 주저하지 말자. 침묵 속에 설계를 진행하지 말자.
     • 설계안을 내놓는 순간 면접이 끝난다고 생각하지 말자. 면접관이 끝났다고 말하기 전까지는 끝난 것이 아니다. 의견을 일찍, 그리고 자주 구하라.
     • 최선의 답안을 내려고 하지 말자

4. 트래픽 처리율 제한 장치의 설계

[참고](https://thalals.tistory.com/391)

이것이 무엇이고 왜 사용해야하는지 / 처리율 제한 장치를 설계할 떄 어디에 두어야하는지 / 알고리즘

1. 처리율 제한장치란
   • 개념
   • 장점
2. 처리율 제한장치의 위치 설계 및 각각의 장 단점
   • 위치
   • 위치별 장 단점
   • 지침
3. 처리율 제한 알고리즘
   1. 토큰 버킷(token bucket)
   2. 누출 버킷(leaky bucket)
   3. 고정 윈도 카운터(fixed window counter)
   4. 이동 윈도 로그(sliding window log)
   5. 이동 윈도 카운터(sliding window counter)
4. 처리율 제한 상세 설계
   • 처리율 제한 규칙
   • 분산 환경에서 처리율 제한 규칙
5. 처리율 제한 장치 설계 시 고려야할 점 (분산 서비스, 성능 저하, 기타 등등)
   • 경성 또는 연성 처리율 제한
   • 다양한 계층에서의 처리율 제한
   • 처리율 제한을 회피하는 방법

5. 안정 해시 설계

[참고](https://thalals.tistory.com/392)

안정 해시가 왜 필요하며 어떻게 동작하는지

1. 해시 키 재배치 문제
2. 서버 장애가 발생하면 공평하게 분배가 안 됨
3. 안정 해시란
4. 안정 해시 동작 과정
5. 안정 해시 장점

6-1. key-value 저장소 설계

[참고](https://thalals.tistory.com/396)

비 관계형 데이터베이스 key-value 저장소

1. 키-값 저장소란
2. 유일한 key - value 저장, key로 value 조회 가능
3. 단일 서비스에서의 키-값 저장소 설계 및 한계점
4. 모든 데이터를 메모리 안에 두는 것이 불가능
5. 분산 키-값 저장소 설계
6. 키 -값 쌍을 여러 서버에 분산
7. CAP 이란
   1. 일관성(Consistency) : 분산 시스템에서 일관된 데이터
   2. 가용성(Availability) : 장애가 발생해도 응답
   3. 파티션 감내(Partition Tolerance theorem) : 두 노드 간 통신장애 발생해도 동작
8. 3가지 중 2가지를 충족하려면 하나 희생해야 됨

6-2. 키-값 저장소 구현에 사용될 핵심 컴포넌트들 및 기술들

1. 데이터 파티션
2. 데이터 다중화(replication)
   • 사용하는 이유
   • 서버 선정 방법
3. 일관성 (consistency)
   • 동기화 알고리즘 - 정족수 합의
   • 일관성 모델
4. 일관성 불일치 해소 (inconsistency resolution)
   • 버저닝
   • 벡터 시계
5. 장애 감지
   • 가십 프로토콜
6. 장애 처리
   • 일시적
   • 영구적 - 머클 트리
   • 데이터 센터 장애 처리
7. 시스템 아키텍처 다이어그램
   • 아키텍처 기능
8. 쓰기 경로 (write path)
   • 로그 파일
   • 메모리 캐시
   • 디스크 SSTable
9. 읽기 경로 (read path)
   • 메모리 캐시
   • 디스크 SSTable

7. 분산 시스템 환경에서 고유 ID 값 생성

[참고](https://thalals.tistory.com/440)

여러 데이터베이스 서버를 쓰는 경우 auto_increment가 안통함

1. 다중 마스터 복제(multi-master replication)
2. UUID (Universally Unique Identifier)
3. 티켓 서버 (ticket server)
4. 트위터 스노플레이크 (twitter snowflake) 접근법

10. 알림 서버 시스템 설계

[참고](https://thalals.tistory.com/441)

1. 알림 유형별 지원 방안
   • IOS
   • 안드로이드
   • SMS
2. 개략적인 알림 시스템 설계 해보기
   • 초안
   • 개선안
   • 최종 설계안

12. 채팅 서버 시스템 설계

[참고](https://thalals.tistory.com/443)

1. 요구사항
   1. 응답지연이 낮은 1:1 채팅
   2. 그룹 채팅(최대 100명) 지원
   3. 다양한 단말 지원 (앱, 웹). 하나의 계정으로 여러 단말에 동시 접속 가능
   4. 사용자 접속상태 표시
   5. 채팅 이력 보관
2. 클라이언트 통신
   • 연결 보장 기술
3. 채팅 서비스 개략적 설계
   • 무상태 서비스
   • 상태 유지 서비스
   • 제 3자 서비스 연동
4. 채팅 서비스의 데이터 저장소
   • RDB 사용하는 경우
   • key-value DB 사용하는 경우
5. 메시지 흐름 과정
   • 1:1 채팅 메시지 처리 과정
   • 그룹 채팅 메시지 처리 과정