#DB 서버 설계
-샤딩(sharding) : 데이터베이스의 수평적 확장. 이를 통해 성능 향상
ㄴ 대규모 데이터베이스를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술을 샤딩이라 함
ㄴ 사용자 데이터를 어느 샤드에 넣을지는 샤딩 키(=파티션 키)에 따라 정해 짐
-샤딩 전략 고려시 중요한 것은 샤딩 키(sharding key)를 어떻게 정할것인가
ㄴ 샤딩 키는 파티션 키라고도 부르는데 데이터가 어떻게 분산될지 정하는 하나 이상의 칼럼으로 구성됨
ㄴ 샤딩 키를 통해 올바른 데이터베이스에 질의를 보내어 데이터 조회나 변경을 처리하도록 효율을 높일 수 있다
ㄴ 샤딩 키를 정할때는 데이터를 고르게 분할 할 수 있도록 하는게 가장 중요함
-샤딩은 데이터베이스 규모 확장을 실현하는 훌륭한 기술이지만 완벽하진 않다. 샤딩을 도입하면 시스템이 복잡해지고 풀어야 할 새로운 문제도 생긴다
ㄴ데이터의 재샤딩 : 데이터가 너무 많아져서 하나의 샤드로 감당이 안될때, 샤드간 데이터 분포가 균등하지 못할때
ㄴ핫스캇 키 문제 : 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 문제
ㄴ조인과 비정규화 : 여러 샤드 서버로 쪼개고 나면 여러 샤드에 걸친 데이터를 조인하기가 힘들어진다. 이를 해결하려면 DB를 비정규화하여 하나의 테이블에서 질의가 수행되도록 함
- 캐싱 전략과 올바른 선택 방법
- active-active for multi-regional resiliency
- What the heck are you actually using NoSQL for?
# 단축URL 설계
- 301, 302 응답의 차이
ㄴ 301 Permanently Moved : 해당 URL에 대한 HTTP 요청의 처리 책임이 영구적으로 Location 헤더에 반환된 URL로 이전되었다는 응답. 영구적으로 이전되었으므로 브라우저는 이 응답을 캐시한다. 따라서 추후 단축 URL에 요청을 보낼 필요가 있을때 브라우저는 캐시된 원래 URL로 요청을 보냄
ㄴ 302 Found : 주어진 URL로의 요청이 일시적으로 Location 헤더가 지정하는 URL에 의해 처리되어야 한다는 응답. 따라서 클라이언트의 요청은 언제나 단축 URL 서버에 먼저 보내진 후에 원래 URL로 리디렉션 되어야 한다
ㄴ서버 부하를 줄이는 것이 중요하면 301 Permanent Moved를 사용하는 것이 좋다
ㄴ트래픽 분석이 중요할 때는 302 Found를 쓰면 클릭 발생률이나 발생 위치를 추적하는데 유리
# 채팅 시스템 설계
- 폴링 : 클라이언트가 주기적으로 서버에게 새 메시지가 있냐고 물어보는 방법
- 롱폴링 : 클라이언트는 새 메시지가 반환되거나 타임아웃 될때 까지 연결을 유지. 클라이언트는 새 메시지를 받으면 기존 연결 종료하고 서버에 새로운 요청을 보내어 모든 절차를 다시 시작
- 웹소켓 : 서버가 클라이언트에게 비동기 메시지를 보낼때 가장 널리 사용하는 기술
ㄴ 웹소켓 연결은 클라이언트가 시작. 한번 맺어진 연결은 항구적 연결이 만들어지고 나면 서버가 클라이언트에게 비동기적으로 메시지 전송할수 있다.
ㄴ 처음에는 HTTP 연결이지만 특정 핸드셰이크 절차를 거져 웹소켓 연결로 업그레이드 된다
#서비스 탐색
-서비스 탐색 기능의 주된 역할은 클라이언트에게 가장 적합한 채팅 서버를 추천하는 것
-서비스 탐색 기능을 구현하는데 아파치 주키퍼를 사용
# 유튜브 설계
# 구글 드라이브 설계
# 기타 참고
'Architecting' 카테고리의 다른 글
| Cache 전략과 올바른 선택 방법 (0) | 2022.01.06 |
|---|
