가상 면접 사례로 배우는 대규모 시스템 설계 기초

NoSql : key value, 그래프, 칼럼, 문서 저장소등이 있음.

조인은 불가능함

언제 쓰나? 아주 낮은 지연시간이 필요할 때.

다루는 데이터가 비정형일 대 , 많은 양의 데이터 저장이 필요할 때

 

수직확정성은 장애 자동 복구와 다중화가 불가

수평적 확장은 이후에 부하분산을 위해 로드밸런서를 둔다.

로드밸런서는 공개 주소로 접근. 로드밸런서는 서버와 사설 주소로 소통

DB의 다중화로 인해 안정성과 성능 향상

 

응답시간은 캐시로 줄일 수 있음

정적 콘텐츠는 CDN으로 뺀다. 웹서버가 CDN을 본다.

캐시 만료 정책이 있으면 좋다. 일관성 관련은 Facebook의 논문이 있다.

 

DB 캐시와 CDN 활용.

CDN이 죽었을 경우를 대비해야 한다.

캐시로 DB의 부하를 줄일 수 있다.

상태에 의존적인 서버를 만들 수 있다. 로드밸런서가 스태키 세션을 지원하지만 부하가 더 가게 된다.

사용자의 위치에 따라 어느 ip를 내어줄지 정하는 GeoDNS를 통해 데이터 센터 다중화를 돕는다.

데이터 센터 다중화를 하게 되면 데이터의 동기화가 필요하고 이는 넷플릭스의 사례를 찾아보자.

 

데이터베이스의 수평적 확장 방법 중 하나는 샤딩이 있다.

샤딩은 샤드라는 단위로 데이터를 여러 DB에 나눠 담는다. 때문에 샤딩 키를 어떻게 하냐가 중요하다.

샤딩의 단점으로는 복잡성과 재샤딩의 문제, 유명인사 문제, 조인과 비정규화 활용의 문제가 있다.

각각 재샤딩은 샤딩 키를 뽑는 함수가 특정 한 키만 반환하면 하나의 DB가 부하가 된다.

이를 재분배해야 하는 문제가 있다. 유명인사는 오바마, 트럼프 등이 같은 샤드에 저장되면 특정 DB만 부하가 가게 되는 것이다. 더 잘게 샤드를 나누던지 아니면 각자 다른 샤드에 넣던지 해야 한다. 조인은 샤드끼리 조인인 힘드니 하나의 row에서 데이터를 뽑을 수 있게 비정규화를 할 수 있는 것이다.  

 

고가용성: 시스템이 중단없이 운영될 수 있는 능력

설계과정에서 내린 결정들에 대한 방어능력, 피드백을 건설적으로 처리

요구사항을 명확히하는 질문을 던져라

개략적인 설계안을 제시하고 면접관의 동의를 얻어라

시스템이 전반적으로 달성해야 하는 목표

서버오류, 운영이슈도 논의할 가치가 충분하다.

대기업들은 rate limiter를 통해 dos공격을 방어한다.

보통 api gateway에 구현한다. 서버나 미들웨어에 구현하든 정답은 없다

 

사용자에게 http 헤더에 사용량을 알려줄 수 있다.

병렬 서버에서 레이스 컨디션과 동기화를 고려해야 한다.

레디스에는 정렬집합으로 해결할 수 있다. 루아 스크립트라는 것도 있다.

스태키 세션은 규모면에서 확장 x 유연하지 않다.

경성은 특정 임계치를 엄격하게 지키는 것이고 연성은 잠시동안 넘어설 수 있도록 하는 것이다.

 

유니크한 id를 여러 분산 시스템에서 사용하고자 할 때 auto_increment는 DB가 다를 경우 사용할 수 없다.

새로운 방법을 생각해내야 한다.

마스터 복제: auto_increment인데 서버 수만큼 증가시키는 것. 근데 서버 추가 삭제 시 잘 동작하게 하기 어렵다.

UUID는 유니크하지만 정렬일 될 수 없고 128비트이다.

타깃서버는 SPOF이다. 복제하면 되지만 동기화의 어려움이 있다.

트위터 스노플레이크라는 방법이 있는데 id값에 여러 정보를 넣어서 사용하는 방법이다.

 

알림 서버는 SPOF가 될 수 있으니 확장하고 추후에 재시도, 분석용, rate limit들이 붙을 수 있다. 붙을 때 의존성을 낮추기 위해 메시지 큐 등을 사용할 수 있다.

파드 설계. 팬아웃을 쓰기 시점에 하면 피드 발송은 친구가 많을수록 핫키 문제가 있을 수 있다. 읽기 시점에 팬아웃을 하면 피드를 읽는데 시간을 많이 쓴다. 트위터의 인플루언서 문제처럼 친구가 많은 경우가 있다. 기본적으로 푸시 모델을 사용하는데 친구가 많다면 풀모델을 사용하자.

친구 목록은 그래프 DB가 적절하다.

 

채팅시스템, 클라이언트가 서버로 요청은 쉽지만 서버가 클라이언트에게 요청은 폴링, 롱폴링, 웹소켓등이 있다.

폴링인 클라이언트가 주기적인 요청을 하는 것이고 롱폴링은 새 메시지가 있거나 타임아웃 때까지 연결을 해놓는 것이다.

웹소켓방식을 많이 사용한다. 서버가 클라이언트에게 비동기로 메시지를 보내는 방법 중 가장 많이 쓰인다.

처음 연결은 http 핸드셰이크 이후에 웹소켓으로 진행한다.

웹소켓을 채팅과 접속상태를 관리할 수 있다.

채팅은 최근 것을 많이 보고 점프, 맨션등의 기능을 사용할 수 있으며 그렇기에 DB로는 RDB보다 NoSQL이 적합하다. 이유는 확장이 쉽고, latency가 적으며 무작위 접근의 비용이 RDB보다 적다. 다만 auto_increment를 적용할 수 없으니 스노플레이크 방식의 id생성이나 지역적인 id 생성방식을 사용해야 한다.

채널 탐색(서비스탐색)에 많이 쓰이는 것은 주키퍼이다. 여기에 모든 채널을 등록해 놓고 사용할 수 있다.

단말기가 여러 개 일 때는 단말기별로 current message id값을 저장해 신규 메시지 여부를 확인할 수 있다.

접속상태는 웹소켓과 더불어 하트비트를 사용할 수 있다. 

 

검색어 시스템, 글자를 입력할 때만다 서버에 요청. 인기도등은 질의문이 사용된 빈도를 따라 저장할 수 있음

인기검색어는 RDB에 매번 업데이트하는 것보다 트라이 자료구조가 적당하다. prefix 다음에 올 글자를 트리형태로 저장

노드별로 인기검색어를 캐실할 수 있다.

트위터 같이 실시간에 민감한 서비스가 아니면 매번 인기도를 업데이트할 필요 없다.

질의 추천은 잘 바뀌지 않으니 브라우저 캐시를 이용할 수도 있다.

필터계층을 두어서 부적절한 질의어를 막을 수 있다. DB증설은 검색 기록을 기반으로 샤딩할 수 있다.

1. 샤딩 DB 조회, 2 해당 DB에 질의