대규모 시스템 설계

1장 사용자 수에 따른 규모 확장성

데이터베이스

관계형 데이터베이스(RDBMS) vs 비관계형 데이터베이스(NoSQL)

NoSQL을 사용하는 상황

• latency가 낮을 경우
• 다루는 데이터가 관계형 데이터가 아닐 경우
• 데이터가 직렬화 or 역직렬화만 필요할 경우
• 많은 데이터 저장이 필요할 경우

 

수직적 규모 확장 vs 수평적 규모 확장

수직적 규모 확장

• 프로세스는 서버에 고사양 자원(더 좋은 CPU, 더 많은 RAM 등)을 추가하는 행위
• "스케일 업" 이라고도 불림

수평적 규모 확장

• 더 많은 서버를 추가하여 성능을 개선하는 행위
• "스케일 아웃" 이라고도 불림

 

확장 기준

서버로 유입되는 트래픽의 양이 적을 떄 : 수직적 확장을 선택

• 수직적 규모 확장에는 한계가 존재. 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법이 없으며 비용 문제도 고려해야함
• 수직적 규모 확장법은 장애에 대한 자동복구 방안이나 다중화 방안을 제시하지 않아 장애가 발생할 경우 웹사이트/앱이 완전 중단됨

서버로 유입되는 트래픽의 양이 많을 떄 : 수평적 확장을 선택

서버의 많은 사용자가 몰리거나 장애가 발생할 경우 -> 로드 밸런서 이용

 

로드밸런서(Load Balancer)

로드밸런서 : 웹 서버들의 트래픽의 부하를 줄이기 위해 트래픽을 고르게 분산하도록 한다

여러 서버를 두고 특정 서버가 다운될 경우 다른 서버에 붙어 정상 동작 하도록 도와준다

 

DB 다중화

write 권한 : 마스터 DB에만 부여
read 권한 : 나머지 DB에 부여

DB 다중화의 이점

• 더 나은 성능 : 하나의 DB에서 모든 것을 컨트롤하지 않고 병렬적으로 처리 가능하다
• 안정성 : 하나의 DB가 꺼지거나 사라지더라도 다른 DB에 붙어 정상적으로 운영 가능하다
• 가용성 : 데이터를 여러 DB에 복제 하여 하나의 DB의 장애가 발생하더라도 정상적으로 데이터를 가져올 수 있다

 

응답 시간 개선

캐시

캐시 사용 시 주의 할 점

• 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어날 경우 사용 고려
• 캐시는 당연히 휘발성 메모리이므로 영속적인 데이터를 저장할 때 사용 x
• 캐시에 보관된 데이터는 어떻게 expire 되는가? (본인 상황에 맞는 정책을 정하는 것이 중요)
• 캐시의 데이터와 실제 DB의 데이터와 일관성이 유지되는지 고민해야한다.
• 캐시 메모리르 얼마나 크게 잡을 것인가? (너무 크게 잡으면 메모리 사용량이 증가하고 너무 작게 잡으면 제대로 역할을 하지 못함)
• 데이터가 가득 찼을 경우 어떻게 기존 데이터를 지울 것인가? (LRU, LFU, FIFO 등 사용)

CDN

CDN 사용 시 주의할 점

• 비용
• 적절한 만료 시간 설정
• CDN 장애 대처 방안
• 콘텐츠 무효화 방법

 

무상태 웹 계층

세션 데이터를 웹 계층에서 분리하고 지속성 데이터 보관소에 저장하도록 설계해야한다.

 

데이터 센터

데이터 센터 아키텍처 사용 시 고려해야할 점

• 트래픽 우회 : 올바른 데이터 센터로 트래픽을 보내는 효과적인 방법을 찾아야함
• 데이터 동기화 : 각 DB마다 동기화가 되도록 해야한다.

 

메시지 큐

메시지 큐 : 메시지의 무손실을 보장하는, 비동기로 동작하는 컴포넌트
메시지 큐를 이용하면 서비스 또는 서버 간 결합이 느슨해져서, 규모 확장성이 보장되어야 하는 안정적 애플리케이션을 구성하기 좋다.

로그, 메트릭, 자동화 사용 ㄱㄱ

 

DB 확장

샤딩 : 대규모 DB를 샤드라고 부르는 작은 단위로 분할하는 기술을 의미

샤딩 키를 어떻게 정할지 선택하는 것이 중요

샤딩을 도입할 경우 고민해야하는 점

• 데이터의 재 샤딩 : 데이터가 너무 많거나 데이터 분포가 균등하지 않을 때 재 샤딩을 해야한다
• 유명인사 문제 : 특정 샤딩 키를 가지는 데이터가 과도하게 존재할 떄 과부화를 막기 위해 생각해야한다.
• 조인과 비정규화 : 하나의 DB를 여러 개로 쪼갤 경우 여러 샤드에 걸쳐 조인하기가 힘들어진다.