1-1. 아키텍처 설계(DB 다중화, 캐시, CDN)

데이터베이스 다중화

디자인 패턴 가운데, Master-Slave 패턴이 대표적으로 쓰이는 것으로, 서버 사이에 주(master)-부(slave) 관계를 만들고, 데이터 원본은 주 서버에 사본은 부 서버에 저장하는 방식이다.

 

핵심 내용

읽기 연산 >>> 쓰기 연산 -> 부 데이터베이스의 수 > 주 데이터베이스의 수
쓰기 연산(insert, update, delete) 은 마스터(주 데이터베이스)에서만 지원한다.
부 데이터베이스는 주 데이터베이스로부터 사본을 전달받으며, 읽기 연산(read) 만을 지원한다.

 

데이터베이스 다중화로 인한 장점

1. 성능(performance)
   주-부 다중화 모델로 인해, 연산들이 분산된다. -> 병렬로 처리할 수 있는 질의(query)의 수가 늘어나므로 성능 향상
2. 안정성(reliabilty)
   자연 재해 등의 이유로 데이터베이스의 일부가 파괴되더라도, 데이터는 보존. 데이터를 지역적으로 멀리 떨어진 여러 장소에 다중화할 수 있기 때문이다.
3. 가용성(availability)
   데이터를 여러 지역에 복제해둠으로써, 하나의 데이터베이스 서버에 장애가 발생하더라도 다른 서버에 데이터를 가져와서 계속 서비스할 수 있게 해준다.

 

상황 가정 (Simulation)

1. 부 서버가 한 대 뿐인데, 다운된 경우라면?

읽기 연산은 한시적으로 모두 주 데이터베이스로 전달, 즉시 새로운 부 데이터베이스 서버가 장애 서버를 대체할 것
부 서버가 여러 대인 경우엔 읽기 연산은 나머지 부 데이터베이스 서버들로 분산되어, 장애 서버 대체 가능

 

2. 주 데이터베이스가 다운된다면?

한 대의 부 데이터베이스만 있는 경우, 해당 부 데이터베이스 서버가 새로운 주 서버가 될 것이며, 일시적으로 모든 데이터베이스 연산은 새로운 주 서버상에서 수행될 것.
프로덕션 환경일 경우, 복구 스크립트(recovery script)를 돌려서 추가, 다중 마스터(multi-masters)나 원형 다중화(circular replication) 방식 도입 가능

 

주-부 관계를 표현한 데이터베이스 다중화

 

데이터베이스 다중화를 통한 설계안

1. 사용자는 DNS로부터 로드밸런서의 공개 IP 주소를 받는다.
2. 사용자는 해당 IP 주소를 사용해 로드밸런서에 접속
3. HTTP 요청은 서버 1이나 서버 2로 전달
4. 웹 서버는 사용자의 데이터를 부 데이터베이스 서버에서 읽는다.
5. 웹 서버는 데이터 변경 연산은 주 데이터베이스에서 전달한다. 데이터 추가, 삭제, 갱신 연산 등이 이에 해당

 

데이터베이스 다중화를 추가한 시스템 설계안

 

응답시간(latency) 개선을 위한 시스템 설계

1. 캐시(Cache)
2. CDN(Content Delivery Network)

 

캐시(Cache)

값 비싼 연산 결과, 자주 참조되는 데이터를 메모리에 두고, 뒤 이은 요청이 보다 빨리 처리하도록 도와주는 저장소
애플리케이션의 성능은 데이터베이스를 얼마나 자주 호출하느냐에 따라 크게 좌우되는데, 별도의 캐시 계층을 둠으로써, 성능 개선 뿐 아니라, 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장하는 것도 가능하다.

 

캐시 우선 쓰기 전략(read-through caching strategy)

1. 요청을 받은 웹 서버는 캐시에 응답이 저장되어있는지를 확인한다.
2. 저장되어 있다면 해당 데이터를 클라이언트에 반환, 없는 경우에는 데이터베이스에게 질의(query) 를 통해 데이터를 찾아, 캐시에 저장한 뒤, 클라이언트에 반환

 

 

캐시 요청 처리 과정

 

캐시 사용시 유의할 점

1. 데이터 갱신은 자주 일어나지 않지만, 참조는 빈번하게 일어나는 경우 캐시 사용이 바람직하다.
2. 캐시는 데이터를 휘발성 메모리에 두므로, 영속적으로 데이터를 보관할 경우에는 바람직하지 않음. -> 캐시 서버 재시작시, 캐시 내의 모든 데이터는 삭제된다.
3. 캐시에 보관한 데이터에 대한 만료 정책을 두도록 한다. 만료 시간은 적절하게 둔다. 만료 시간이 너무 짧으면 데이터베이스를 너무 자주 읽게 되므로, 부하가 늘어나며 굳이 쓸 이유가 없을 것이고, 반대로 너무 길게 가져간다면, 원본 데이터와 차이가 날 수 있다.
4. 일관성(consistency)를 위해서 저장소의 원본을 갱신하는 연산과 캐시를 갱신하는 연산이 단일 트랜잭션으로 처리하도록 한다. 그렇지 않으면 일관성이 깨지는 문제가 발생할 수 있다.
5. 캐시 서버를 한 대만 두는 경우, 단일 장애 발생 시점(Single Point Of Failure, SPOF)이 될 수 있다. 따라서 여러 지역에 걸쳐 캐시 서버를 분산 시키도록 한다.
6. 캐시 메모리는 과할당(overprovision)한다. 메모리가 너무 작으면 액세스 패턴에 따라서 데이터가 너무 자주 캐시에서 밀려나서(eviction) 성능이 떨어지게 된다. 크게 잡으면 보관할 데이터가 갑자기 많아져도 방지할 수 있다. -> eviction 정책과 관련해서는 LRU, LFU, FIFO가 자주 쓰인다.

 

컨텐츠 전송 네트워크(CDN)

정적 컨텐츠를 전송하는데 쓰이며, 지리적으로 분산된 서버의 네트워크이다.이미지, 비디오, CSS, Javascript 파일 등을 캐시, 요청을 보낸 사용자와 가장 가까운 CDN 서버가 정적 컨텐츠를 제공하기 때문에, 거리에 비례하여 로딩 시간이 걸리게 된다.

 

동적 컨텐츠 캐싱
요청 경로(request path), 질의 문자열(query string), 쿠키(cookie), 요청 헤더(request header) 등의 정보에 기반하여 HTML 페이지를 캐시하는 것

 

 

요청 과정

1. 사용자 A가 이미지 URL을 이용해 image.png에 접근 (URL의 도메인은 CDN 서비스 사업자가 제공)
2. CDN 서버의 캐시에 해당 이미지가 없는 경우, 서버느 원본(origin) 서버에 요청하여 파일을 가져온다. 원본 서버는 웹 서버일 수도 있고, AWS S3같은 온라인 저장소일 수 있다.
3. 원본 서버가 파일을 CDN 서버에 반환한다. (응답의 HTTP 헤더에는 해당 파일이 얼마나 오래 캐시될 수 있는지 설명하는 TTL 값이 들어있다.)
4. CDN 서버는 파일을 캐시하고, 사용자 A에게 반환한다. 이미지는 TTL에 명시된 시간이 끝날때까지 캐시한다.
5. 사용자 B가 같은 이미지에 대한 요청을 CDN 서버에 전송한다.
6. 만료되지 않은 이미지에 대한 요청은 캐시를 통해 처리된다.

 

CDN 요청 과정

 

CDN 사용시 고려해야할 사항

1. 비용
2. 적절한 만료 시한 설정
3. CDN 장에 대한 대처 방안
4. 콘텐츠 무효화 방법

 

응답 시간 향상을 위해 캐시와 CDN을 추가한 시스템 설계안

캐시와 CDN을 추가한 시스템 설계