대규모 서비스를 위한 고려 사항 (1)

1. 데이터베이스

---

RDBMS vs NoSQL

RDBMS

• 관계형 데이터베이스는 자료를 테이블과 열, 칼럼으로 표현하고, SQL을 사용하면 여러 테이블에 있는 데이터를 관계에 따라 조인하여 합칠 수 있다.

NoSQL

• 비 관계형 데이터베이스는 크게 4가지 부류로 나눌 수 있다.
  • Key-Value Store
  • Graph Store
  • Column Store
  • Document Store
• 이러한 비 관계형 데이터베이스는 일반적으로 조인 연산을 지원하지 않는다.

대부분의 경우에는 관계형 데이터베이스가 좋은 선택지가 될 것인데, 경우에 따라 구축하려는 시스템에 적합하지 않은 경우 관계형 데이터베이스 이외의 저장소도 살펴봐야 한다.

NoSQL 데이터베이스를 도입할 상황

• 아주 낮은 응답 지연시간 (latency)가 요구됨.
• 데이터가 비정형
• 데이터를 직렬화하거나 역직렬화 할 수 있기만 하면 됨
• 아주 많은 양의 데이터를 저장할 필요.

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

---

Scale Up (수직적 규모 확장)

• 서버에 고사양 자원을 추가하여 성능 개선.

Scale Out (수평적 규모 확장)

• 더 많은 서버를 추가하여 성능 개선.

Scale Up의 한계

• 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법이 없다.
• 장애에 대한 자동 복구 (failover) 방안이나 다중화 방안을 제시하지 않는다. ⇒ 서버 장애 시 서비스 완전 중단.

이러한 단점으로 대규모 애플리케이션을 지원하는 데는 수평적 규모 확장법이 보다 적절하다.

3. 로드밸런서의 도입

---

사용자가 웹 서버에 직접적으로 연결되는 경우, 웹 서버가 다운되면 서비스를 이용할 수 없게 된다. 또한 트래픽이 증가하여 웹 서버가 한계 상황에 도달하게 되면 응답 속도가 너무 느려지거나 접속이 불가능해질 수도 있다.

이러한 문제를 해결하기 위해서는 부하 분산기 (로드 밸런서)를 도입하는 것이 최선이다.

로드 밸런서란?

• 부하 분산 집합에 속한 웹 서버들에게 트래픽 부하를 고르게 분산하는 역할을 한다.
• 사용자는 로드밸런서의 공개 IP로 접속한다. 따라서 웹 서버는 클라이언트의 접속을 직접 처리하지 않는다. (더 나은 보안을 위해서 서버 간 통신에는 사설 IP 주소가 이용된다)
• 특정 서버 A가 중단되면, 트래픽이 서버 B로 전송되서, 전체 서비스가 다운되는 일을 방지한다.
• 트래픽이 가파르게 증가하면 두 대의 서버로 트래픽을 감당할 수 없게 되면, 로드밸런서가 있으면 웹 서버 계층에 더 많은 서버를 추가하기만 하면 된다.

4. 데이터베이스 다중화

---

대부분의 애플리케이션은 읽기 연산의 비중이 쓰기 연산보다 훨씬 높다.

많은 데이터베이스에서 Master-Replication 관계를 설정해서 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식으로 다중화를 지원한다.

Master vs Replication (Slave)

• 쓰기 연산은 마스터에서만 지원한다.
• 반면 부 데이터베이스는 주 데이터베이스로부터 그 사본을 전달받으며, 읽기 연산만을 지원한다.

데이터베이스 다중화의 장점

더 나은 성능

• 모든 데이터 변경 연산은 주 데이터베이스 서버로만 전달되는 반면, 읽기 연산은 부 데이터베이스 서버들로 분산돼서 병렬로 처리될 수 있는 쿼리 수가 늘어나므로, 성능이 좋아진다.

안정성

• 자연 재해 등의 이유로 데이터베이스 서버 가운데 일부가 파괴되어도 데이터를 지역적으로 떨어진 여러 장소에 다중화시켜 놓아 데이터를 보존시킬 수 있다.

가용성

• 하나의 데이터베이스 서버에 장애가 발생하더라도, 다른 서버에 있는 데이터를 가져와 계속 서비스할 수 있게 된다.

5. 캐시와 CDN

---

응답 시간 (latency)를 개선하기 위해 캐시를 붙이고 정적 콘텐츠를 CDN로 옮기면 개선할 수 있다.

캐시란?

캐시는 비용이 비싼 작업들이나 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소이다.

캐시 계층

• 캐시 계층은 데이터가 임시적으로 보관되는 곳으로, 데이터베이스보다 훨씬 빠르다. (메모리 계층 구조)
• 별도로 캐시 계층을 두면 성능이 개선될 뿐 아니라 데이터베이스의 부하를 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장시키는 것도 가능해진다.

캐시 전략

1. Look aside Cache

• 읽기 주도형 캐시 전략이라고도 부른다.

1. 웹 서버는 데이터가 존재하는지 캐시를 먼저 확인한다.
2. 캐시에 데이터가 있으면 캐시에서 데이터를 가져오고, 만약 캐시에 데이터가 존재하지 않으면 DB에서 데이터를 읽어온다.
3. (DB에서 읽어온 경우) DB에서 읽어온 데이터를 캐시에 다시 저장한다

2. Write Back

• 쓰기 작업이 비싼 작업의 경우 Write Back 캐시 전략을 고려해볼 수 있다.

1. Web Server는 모든 데이터를 캐시에만 저장.
2. 캐시에 있는 데이터를 특정 시점에 DB에 저장하고, DB에 저장된 데이터를 삭제한다.

디스크 I/O를 줄일 수 있고, Batch 쿼리를 통해 개선 가능.

캐시 고려 사항

• 데이터 갱신은 자주 일어나지 않지만 참조는 빈번하게 일어나는 경우
• 캐시는 데이터를 휘발성 메모리에 두기 때문에 영속적으로 보관할 데이터를 캐시에 두는 것은 적합하지 않다. (캐시 서버가 재시작되면 캐시 내의 모든 데이터는 사라진다)
• 캐시에 보관된 데이터에 대한 만료 정책을 마련해 두는 것이 좋다. 만료 정책이 없다면 데이터는 캐시에 계속 남게 된다
  • 만료 기한은 너무 짧으면, 데이터베이스를 너무 자주 읽게 되는 문제가 발생
  • 반대로 만료 기한이 너무 길면, 원본과 차이가 날 가능성이 높아진다.
• 일관성 유지를 고려해야 한다.
  • 일관성이란 데이터 저장소의 원본과 캐시를 갱신하는 사본이 같은지 여부이다.
• 장애가 발생시, 캐시 서버를 한 대만 두는 경우 해당 서버는 단일 장애 지점(SPOF)이 되어버릴 가능성이 있다.
  • SPOF란 특정 지점에서의 장애가 전체 시스템의 동작을 중단시켜버릴 수 있는 경우를 의미.
  • 이를 피하려면 여러 지역에 걸쳐 캐시 서버를 분산시켜야 한다.
• 캐시 메모리의 크기를 어떻게 잡을 것인가?
  • 캐시 메모리가 너무 작으면 액세스 패턴에 따라서는 데이터가 너무 자주 캐시에서 밀려나버려 캐시의 성능이 떨어지게 된다.
  • 이를 막기 위한 한 가지 방법은 캐시 메모리를 과할당 하는 것이다.
• 데이터 방출 정책은 무엇인가?
  • 캐시가 꽉 차버리면 추가로 캐시에 데이터를 넣어야 할 경우 기존 데이터를 내보내야 한다.
  • 가장 널리 쓰이는 것은 LRU(Least Recently Used, 마지막으로 사용된 시점이 가장 오래된 데이터를 방출), 혹은 LFU(Least Frequently Used, 사용된 빈도가 가장 낮은 데이터를 방출), FIFO(First in First Out, 가장 먼저 캐시에 들어온 데이터를 먼저 방출) 등 다양한 전략이 존재하며 경우에 맞게 적용 가능하다.

CDN 란? (콘텐츠 전송 네트워크)

---

• 정적 콘텐츠를 전송하는 데 쓰이는, 지리적으로 분산된 서버의 네트워크. (이미지, 비디오, CSS, JS 파일 등을 캐시 할 수 있다.)
• 사용자가 웹 사이트를 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다.
  • 예를 들어서 한국에 위치한 사용자는 LA에 위치한 서버보다 서울 리전에 위치한 서버에서 콘텐츠를 전달하면, 네트워크가 지리적으로 더 빠름을 이용.

CDN 고려사항

적절한 만료 시한 설정

• 시의성이 중요한 콘텐츠의 경우 만료 시점을 잘 정해야 한다.
• 너무 길면 콘텐츠의 신선도는 떨어지고, 너무 짧으면 원본 서버에 빈번히 접속하게 되어 좋지 않다.

CND 장애 대한 대처 방안

• CDN 자체가 죽었을 경우 웹사이트/애플리케이션이 어떻게 동작해야 하는지 고려해야 한다.

콘텐츠 무효화 방법

• 아직 만료되지 않은 콘텐츠라 하더라도, 다음과 같은 방법으로 CDN에서 제거가 가능하다.
  • CDN 서비스 사업자가 제공하는 API를 이용하여 콘텐츠 무효화
  • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝 이용.