어떤 데이터베이스를 사용할 것인가? #
아래의 경우 NoSQL(비-관계형 데이터베이스)가 바람직한 선택이 될 수 있습니다.
- 아주 낮은 응답 지연시간(latency) 요구
- 데이터 비정형
- 데이터 직렬화, 역직렬화를 할 수 있기만 하면 됨
- 아주 많은 양의 데이터를 저장
수직적 규모 확장 vs 수평적 규모 확장 #
수직적 규모 확장에는 다음과 같은 단점이 있습니다.
- SPOF, 서버 장애 시 모든 서비스 중단/장애
- Scale-Up에 한계가 있음
- CPU, Memory 를 무한으로 늘릴 수 없음
[다중화] (웹 계층)웹 서버의 다중화를 위해 선택할 수 있는 것? #
(웹 계층)웹 서버의 다중화를 위해서는 무상태 아키텍쳐를 보장해주어야 한다. 세션과 같은 정보를 서버에서 갖고 있는 것이 아니라 외부 저장소(RDBMS, NoSQL)에서 저장/관리하면 된다.
로드 밸런서
- 웹서버가 클라이언트의 요청을 직접 처리하지 않는다.
- (로드 밸런서 이후) 서버 간에는 사설 IP를 통해 통신할 수 있다. 즉, 보안이 향상된다.
- 특정 서버 장애 시, 살아 있는 서버를 활용할 수 있어서 서비스가 중단되지 않는다.
[다중화] (데이터 계층)DB의 다중화를 위해 선택할 수 있는 것? #
1. Replication
2. 샤딩
샤딩 사용 시 유의해야할 점 #
- 데이터의 재샤딩(resharding) : 샤드 키 계산 함수를 변경하여 데이터를 재배치해야 한다.
- 데이터가 너무 많아져서 하나의 샤드롷 더 이상 감당하기 어려울 때
- 샤드 간 데이터 분포가 균등하지 못하여, 한 샤드에 데이터가 빨리 찰 때(샤드 소진)
- Celebrity(유명인사) 문제 : 핫스팟 키들에에 대해 샤드 할당을 균등하게 해줘야한다.
- 특정 샤드에 질의가 집중되어 서버에 과부하가 걸릴 때
- 조인과 비정규화` : 샤딩 시 조인이 어려워진다. 적절한 비정규화를 통해 해결할 수 있다.
응답 시간을 개선하기 위해 선택할 수 있는 것? #
1. 캐싱
책에서는 Application Logic <-> DB 사이에서 동작하는 것을 예시로 주었다.
데이터를 캐싱하여 cache hit 시에는 캐싱된 데이터를, miss 시에는 DB 조회를 하도록 한다.
2. CDN
책에서는 Client 요청 <-> 로드밸런서 사이에서 동작하는 것을 예시로 주었다.
Client는 CDN을 먼저 조회하여 찾고자 하는 정적 데이터가 있으면 CDN에서 데이터를 받을 수 있다. 찾고자 하는 데이터가 없으면 서버에서 데이터를 찾아오고, CDN에 저장하고 Client에 내어준다.
캐시 사용 시 유의해야할 점 #
- 조회/참조가 빈번히 일어나는 데이터인가?
- 영속적으로 저장되어야 하는 데이터는 아닌가?
- 휘발성으로 날라가도 되는 데이터만 캐싱한다.
- 캐시의 만료시간은 어떻게 되어야 하는가?
- 만료시간이 짧으면, 캐싱의 이득이 없어진다.
- 만료시간이 길면, 데이터의 일관성이 깨질 수 있다.
- 캐시의 데이터와 DB의 데이터의 일관성을 어떻게 유지할 것인가?
- DB의 업데이트와 캐시의 업데이트가 단일 트랜잭션으로 처리되지 않으면 일관성이 꺠질 수 있다.
- 장애는 어떻게 대처활 것인가?
- 캐시 서버가 1대라면, SPOF이 될 수 있다.
- 여러 대로 캐시 서버를 분산시켜야한다.
- 캐시 메모리는 얼마나 크게 잡을 것인가?
- 메모리가 작으면, 캐시의 성능이 떨어진다.
- 메모리가 크면, 메모리를 많이 점유한다.
- 데이터 교체(방출) 정책은 어떻게 할 것인가?
- 흔히, LRU 가 쓰인다.
- 그 외 LFU, FIFO 등도 쓰이곤 한다.`
CDN 사용 시 유의해야할 점 #
- 비용?
- 네트워크 비용이 발생하기에, 꼭 필요한 콘텐츠만 캐싱될 수 있도록 한다.
- 만료시간?
- 적절한 만료시간을 설정한다.
- 장애?
- CDN 서버가 죽었을 때 서비스의 영향이 없도록 한다. 예를 들어, CDN이 죽었을 경우 원본 서버로부터 데이터를 받아갈 수 있도록 되어야 한다.
- 콘텐츠 무효화?
- 캐싱을 제거할 수 있어야한다.
- 데이터를 버저닝하거나, CDN 사업자가 제공하는 API를 사용할 수 있을 것이다.
`