사실 나 같은 취준생 입장에서는 대규모 시스템을 직접 경험해보는 게 쉽지 않다. 하지만 대부분 기업에서 대규모 시스템에 대한 지식을 요구하는 것 같아서, 조금 정리해두려고 한다. 예전에 읽었지만 기억이 가물가물해서 다시 기록하려고 한다.
참고 도서 📚​ 가상 면접 사례로 배우는 대규모 시스템 설계 기초

🤔 관계형 DB와 비관계형 DB 어떤 걸 사용해야할까?

관계형 DB는 RDBMS이라고도 부르는데, 가장 유명한 걸로는 MySQL, 오라클, PostgreSQL이 존재한다. 관계형 DB는 자료를 테이블과 열, 칼럼으로 표현한다. SQL을 사용하면 여러 테이블에 존재하는 데이터를 그 관계에 따라 조인(join)하여 합치는 것이 가능하다.

비 관계형DB는 NOSQL이라고도 부르는데, 대표적으로 CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB 등이 존재한다. 또한 네 부류로 분리할 수 있는데, 키-값(key-value) 저장소, 그래프 저장소(graph store), 칼럼 저장소(column store), 문서 저장소(document store) 등이 있다. 이런 비 관계형DB는 조인(join) 연산을 지원하지 않는다.

대부분의 개발자는 관계형 DB를 많이 사용하지만 구축한 시스템에 적합하지 않으면 비 관계형DB도 고려를 해야한다. 아래와 같은 경우다.

1.아주 낮은 응답 지연시간(latency)이 요구됨
2.다루는 데이터가 비정형(unstructured)이라 관계형 데이터가 아님
3.데이터(json, yaml, xml 등)를 직렬화하거나(serialize) 역직렬화(deserialize)할 수 있기만 하면 됨
4. 아주 많은 양의 데이터를 저장할 필요가 있음

정형 데이터는 엑셀이나 SQL 테이블처럼 행과 열이 정해져 있는 구조화된 데이터를 말한다. 그래서 검색이나 분석이 쉽고, 관계형 DB에 저장된다.
반대로 비정형 데이터는 이미지, 동영상처럼 고정된 구조가 없는 데이터로, 스키마가 없기 때문에 NoSQL이나 파일 시스템에 저장하며 분석이나 처리가 상대적으로 복잡한다.

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

1. 수직적 규모 확장 (Vertical Scaling / 스케일 업)

서버에 고사양 자원(CPU, RAM 등)을 추가하여 성능을 개선하는 방법

• 장점: 단순하고 구현이 쉬움
• 단점:
  1. 한 대의 서버에 CPU나 메모리를 무한대로 증설할 수 없음
  2. 장애 발생 시 자동복구(failover)나 다중화 방안을 제공하지 않음 → 서버 장애 시 웹사이트 / 앱 완전 중단

소규모 트래픽에는 적합하지만, 대규모 서비스에는 한계가 있음

이러한 단점 때문에, 대규모 애플리케이션을 지원하는 곳은 수평적 규모 확장법이 적절하다.

2. 수평적 규모 확장 (Horizontal Scaling / 스케일 아웃)

더 많은 서버를 추가하여 성능을 개선하는 방법

• 장점: 대규모 트래픽 처리에 적합, 장애 대비 가능
• 단점: 설계와 관리가 복잡함
• 대규모 애플리케이션에서는 수평적 확장이 더 적절

---

📌 로드밸런서

부하 분산 집합(load balancing set)에 속한 웹 서버들에게 트래픽을 고르게 분산하는 역할을 한다.

그림과 같이 사용자가 공개 IP 주소(public IP address)로 접속하면,
웹 서버는 클라이언트의 접속을 직접 처리하지 않는다.

더 나은 보안을 위해 서버 간 통신에는 사설 IP 주소(private IP address)를 사용한다.

로드밸런서는 웹 서버와 통신할 때 사설 주소(private IP address)를 이용한다.

그림과 같이 부하 분산 집합에 웹 서버를 추가하면, 장애 자동복구 문제(no failover)가 해소되고,
웹 계층의 가용성(availability)이 향상된다.

시나리오

1. 서버 1이 다운되면 모든 트래픽은 서버 2로 전송된다. 따라서 웹 사이트 전체가 다운되는 일이 방지된다. 부하를 나누기 위해 새로운 서버를 추가 가능하다.

2. 웹 사이트로 유입되는 트래픽이 가파르게 증가하면 두 대의 서버로 트래픽을 감당할 수 없는 시점이 오는데, 로드밸런서가 존재하므로 우아하게 대처가 가능하다. 바로 웹 서버 계층에 더 많은 서버를 추가하기만 하면 된다. 그러면 로드 밸러서가 자동으로 트래픽을 분산해준다.

📌 DB 다중화

많은 DBMS는 다중화를 지원한다! 보통은 서버 사이에 주(master) - 부(slave)관계를 설정하고 데이터 원본은 주 서버에, 사본은 부 서버에 저장하는 방식이다. 요즘에는 master, slave가 인종차별(?), 어쨌든 차별을 두는 용어라 금지한다고 하는데 아직까지는 많이 사용하는 것 같다.

쓰기 연산 (write operation)은 주 DB (master DB)에서만 처리되며,
읽기 연산 (read operation)은 부 DB (slave DB)가 주 DB로부터 데이터를 복제받아 수행한다.

DB를 변경하는 명령어(INSERT, DELETE, UPDATE 등)는 모두 주 DB로 전달된다.

대부분의 애플리케이션에서 읽기 연산(read operation)의 비중이 쓰기 연산(write operation)보다 크기 때문에, 부 DB의 수가 부 DB보다 많은 경우가 일반적이다.

DB 다중화 장점

1. 병렬로 처리 될 수 있는 질의(Query)의 수가 늘어나므로, 성능이 좋아진다.
2. DB 서버의 일부가 다운되어도 데이터가 보존된다.

🤔 DB 서버 하나가 다운되면 어떤 일이 발생할까?

• Slave 서버가 한 대뿐인 경우
  해당 slave 서버가 새로운 master 서버의 역할을 수행하게 되며, 모든 DB 연산은 일시적으로 새로운 master 서버에서 수행된다.
  slave 서버가 여러 대인 경우, 읽기 연산은 나머지 slave 서버들로 분산되며, 새로운 slave 서버가 장애 서버를 대체한다.

• 이전 slave 서버 데이터가 최신이 아닌 경우
  서버 다운 전 동기화되지 않은 상태라면, 없는 데이터는 복구 스크립트(recovery script)를 돌려 추가해야 한다.

• 다중 마스터(multi-masters), 원형 다중화(circular replication)
  이러한 방식을 도입하면 위 상황에 대응하는 데 도움이 될 수 있다.

로드밸러서와 DB 다중화를 고려한 경우

1. 사용자는 DNS로부터 로드밸러서의 공개 IP주소를 받는다.
2. 사용자는 해당 IP 주소를 사용해 로드밸런서에 접속한다.
3. HTTP요청은 서버 1이나 서버 2로 전달된다.
4. 웹 서버는 사용자의 데이터를 부 DB 서버에서 읽는다.
5. 웹 서버는 데이터 변경 연산은 주 DB로 전달한다.

🤔 응답시간은 어떤 방법으로 개선할까??

캐시(cache)를 붙이고 정적 콘텐츠를 콘텐츠 전송 네트워크(CDN)로 옮기면 개선이 가능하다.

캐시(cache)

값비싼 연산 결과 or 자주 참조되는 데이터를 메모리 안에 두고, 뒤이은 요청이 보다 빨리 처리될 수 있도록 하는 저장소

캐시 계층(cache tier)

데이터가 잠시 보관되는 곳으로 DB보다 훨씬 빠르다. 별도의 캐시 계층을 두면, 성능이 개선될 뿐만 아니라 DB의 부하도 줄일 수 있고, 캐시 계층의 규모를 독립적으로 확장 시키는것도 가능하다.

캐시(Cache) 사용 시 고려 사항

• 캐시는 언제 필요한가?
  데이터 갱신이 자주 일어나지 않지만, 조회가 빈번하게 발생하는 경우 캐시 계층을 추가하는 것이 좋다.

• 어떤 데이터를 캐시에 두어야 하는가?
  캐시는 휘발성 메모리에 데이터를 두는 것이므로, 영속적으로 보관해야 하는 데이터는 캐시에 두는 것은 적합하지 않다.

• 캐시 데이터 만료(expire) 기한은?
  캐시에 저장된 데이터가 언제 만료될지 정책을 정해야 한다.

  • 만료 기한이 너무 짧으면 DB를 너무 자주 조회하게 된다.
  • 만료 기한이 너무 길면 원본과 캐시 간 데이터 차이가 발생할 수 있다.

• 데이터 저장소 원본과의 일관성 유지
  DB 원본과 캐시 내 데이터가 최대한 동일하게 유지되어야 한다.

  • 원본 갱신과 캐시 갱신 연산이 단일 트랜잭션으로 처리되지 않으면 일관성이 깨질 수 있다.
  • 여러 지역에 걸쳐 시스템을 확장할 경우 일관성 유지가 더욱 어려워진다.

• 장애 대처
  캐시 서버를 단일로 운영하면 해당 서버가 SPOF(Single Point of Failure)가 될 수 있다.

  • SPOF를 피하기 위해 여러 지역에 캐시 서버를 분산시켜야 한다.

• 캐시 메모리 크기
  캐시 메모리가 작으면 데이터가 자주 캐시에서 밀려 캐시 성능이 떨어질 수 있다.

  • 이를 방지하기 위해 캐시 메모리를 과할당(overprovision)할 수 있다.

• 데이터 방출 정책(Eviction Policy)
  캐시가 꽉 찼을 때 어떤 데이터를 제거할지 결정하는 정책이 필요하다.

  • 대표적인 정책: LRU(Least Recently Used), FIFO(First In First Out)

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

• 정적 콘텐츠를 전송하는데 쓰이는, 지리적으로 분산된 서버의 네트워크, 이미지, 비디오, CSS, 자바스크립트 등을 캐시할 수 있다.

어떤 사용자가 사이트에 방문하면, 그 사용자에게 가장 가까운 CDN 서버가 정적 콘텐츠를 전달하게 된다. 사용자가 CDN서버로부터 멀면 멀수록 웹 사이트는 천천히 로드된다. 위에 있는 그림을 보면 CDN이 사이트 로딩 시간을 어떻게 개선하는지 확인이 가능하다.

1. 사용자 요청

   • 사용자가 이미지 URL(image.png)에 접근한다.
   • URL의 도메인은 CDN 서비스 제공자가 제공한다.

2. CDN 서버 확인

   • CDN 서버 캐시에 해당 이미지가 없는 경우:
     • 서버는 원본 서버(웹 서버 또는 AWS S3 같은 클라우드 저장소)에 파일 요청.

3. 원본 서버 응답

   • 원본 서버가 파일을 CDN 서버로 반환.
   • 응답의 HTTP 헤더에는 파일의 TTL(Time-to-live) 값 포함:
     • TTL은 해당 파일이 얼마나 오래 캐시될 수 있는지를 나타냄.

4. CDN 캐시 및 사용자 반환

   • CDN 서버는 파일을 캐시하고 사용자에게 반환.
   • 이미지 캐시는 TTL에 명시된 시간 동안 유지됨.

5. 다른 사용자 요청

   • 다른 사용자(B)가 같은 이미지에 접근하면 CDN 서버로 요청 전송.

6. 캐시 활용

   • TTL이 만료되지 않았다면 이미지 요청은 캐시를 통해 처리됨.

CDN 사용 시 고려해야 할 사항

• 비용
  CDN은 보통 제3자 사업자(third-party providers)가 운영하며, CDN으로 들어가고 나가는 데이터 전송량에 따라 비용이 청구됨.
  자주 사용하지 않는 콘텐츠를 캐싱하지 않는 것은 이득이 크지 않으므로, CDN에서 빼는 것을 고려해야 함.

• 적절한 만료 시한 설정
  시의성이 중요한(time-sensitive) 콘텐츠의 경우 만료 시점을 잘 정해야 함.

  • 긴 경우: 콘텐츠의 신선도가 떨어짐
  • 짧은 경우: 원본 서버에 빈번히 접속하게 되어 비효율적

• CDN 장애에 대한 대처 방안
  CDN 자체가 죽었을 경우 웹사이트/애플리케이션이 어떻게 동작해야 하는지 고려 필요.

  • 일시적으로 CDN이 응답하지 않는 경우, 문제를 감지하여 원본 서버로부터 직접 콘텐츠를 가져오도록 클라이언트를 구성할 수도 있음

• 콘텐츠 무효화(invalidation)
  아직 만료되지 않은 콘텐츠라 하더라도 아래 방법으로 CDN에서 제거 가능:

  • CDN 서비스 사업자가 제공하는 API로 콘텐츠 무효화
  • 콘텐츠의 다른 버전을 서비스하도록 오브젝트 버저닝(object versioning) 이용
    (URL의 마지막에 버전 번호를 인자로 주면 됨)

📌 무상태(stateless) 웹 계층

웹 계층을 수평적으로 확장(스케일 아웃)하는 방법을 고민할려면, 우선 상태 정보(사용자 세션 데이터 등)를 웹 계층에서 제거해야한다.

상태 정보 의존적인 아키텍쳐

각 서버가 서로 다른 클라이언트의 상태 정보를 저장하는 경우, 상태 의존적인 아키텍처는 이렇게 설명할 수 있다.

사용자 A, B, C는 각각 서버 1, 2, 3에 세션 데이터와 상태 정보를 가지고 있으므로, HTTP 요청이 해당 서버로 전달되어야만 인증 절차가 정상적으로 진행된다.

문제는 같은 클라이언트의 요청이 항상 같은 서버로만 전달되어야 한다는 점이다.

이를 위해 대부분의 로드밸런서는 고정 세션(sticky session) 기능을 제공하지만, 로드밸런서에 부담을 줄 수 있다.

무상태(stateless) 아키텍쳐

상태 정보에 의존하지 않는, 무상태 아키텍처의 경우, 사용자로부터의 HTTP 요청은 어떤 웹 서버로도 전달 가능하다.

웹 서버는 상태 정보가 필요한 경우 공유 저장소(shared storage)에서 데이터를 가져온다.

따라서 상태 정보는 웹 서버와 물리적으로 분리되어 있다.

무상태 웹 계층을 갖도록 설계하면 아래 그림과 같다.

세션 데이터를 웹 계층에서 분리하고, 지속성 데이터 보관소에 저장하도록 하였다. 이 공유 저장소는 그림과 같이 NoSOL, 또는 Redis 같은 캐시 시스템이나 RDB일 수도 있다.

자동 규모 확장(autoscaling)은 트래픽 양에 따라 웹 서버를 자동으로 추가하거나 삭제하는 기능을 말한다.

상태 정보가 웹 서버들 로부터 제거되었으므로, 트래픽 양에 따라 웹 서버를 넣거나 빼기만 하면 자동으로 규모를 확장할 수 있는 용이한 구조를 띄게 된다. 가용성을 높이고 전 세계 어디서도 쾌적하게 사용 가능하게 할려면 여러 데이터 센터(data center)를 지원하는것이 필수다.

📌 메세지 큐(Message Queue)

• 메시지의 무손실(durability, 즉 메시지 큐에 일단 보관된 메시지는 소비자가 꺼낼 때까지 안전히 보관된다는 특성)을 보장하는, 비동기 통신을 지원하는 컴포넌트

• 메시지의 버퍼 역할을 하며, 비동기적으로 전송

• 생산자(producer, publisher): 입력 서비스가 메시지를 만들어 큐에 발행(publish)

• 소비자(consumer, subscriber): 큐에 연결되어 메시지를 받아 처리

메시지 큐의 장점

• 서비스 또는 서버 간 결합이 느슨해짐
• 규모 확장성 보장
• 생산자는 소비자가 프로세스 다운 상태여도 메시지 발행 가능
• 소비자는 생산자 서비스가 가용하지 않아도 메시지 수신 가능

예시: 이미지 보정 앱

• 이미지 크롭, 샤프닝, 블러링 등의 기능 지원

• 보정 작업은 시간이 오래 걸리는 프로세스 → 비동기 처리가 편리

• 동작 예시)

1. 웹 서버가 사진 작업(job)을 메시지 큐에 넣음
2. 사진 보정 작업(worker) 프로세스들이 큐에서 작업을 꺼내 비동기적으로 처리
3. 생산자와 서비스의 규모는 독립적으로 확장 가능
4. 규모가 커지면 더 많은 job을 추가하여 처리 시간 단축 가능

📌 데이터베이스 규모 확장

데이터베이스의 규모를 확장하는 데에는 두 가지 접근법이 존재한다. 하나는 수직적 규모 확장 , 또 다른 하나는 수평적 규모 확장 이다.

수직적 규모 확장

• 위에 서버를 수직적 규모 확장 하는 것처럼 데이터베이스에서도 스케일 업 이라고 부른다.
• 기존 DB 서버에 더 많은, 또는 고성능의 자원(CPU, RAM, 디스크 등)을 증설하는 방법

단점

• DB 서버 하드웨어에는 한계가 있으므로, CPU, RAM등을 무한 증설할 수 없다.
• SPOF(Single Point Of Failure)로 인한 위험성
• 비용 문제

수평적 확장

• 데이터베이스의 수평적 확장은 샤딩(sharding) 이라고도 부른다.
• 더 많은 db 서버를 추가함으로써 성능을 향상시 키는 방법이다.
• 샤딩은 대규모 DB를 샤드(shard)라고 부르는 작은 단위로 분할하는 기술이다. 모든 샤드는 같은 스키마를 쓰지만, 샤 드에 보관되는 데이터 사이에는 중복이 없다.

위의 그림은 user_id 값에 따라 샤드에 데이터를 넣는 기준을 정한다. 예를 들면, user_id %4를 해시 함수로 사용하여 데이터가 보관되는 샤드를 정할 수 있다. 결과가 0이라면 0번 샤드에 넣는다.

샤딩 전략 구현 시 고려해야 할 점

데이터를 어떻게 분산할지 결정하는 하나 이상의 칼럼, 즉 샤딩 키(sharding key, partition key)를 어떻게 정하느냐가 매우 중요하다.

샤딩 키를 통해 올바른 데이터베이스에 질의를 보내 데이터 조회나 변경을 처리하여 효율을 높일 수 있다.

샤딩 키를 정할 때는 데이터를 고르게 분할할 수 있도록 하는 것이 가장 중요하다.

---

샤딩 도입 시 풀어야 할 문제들

1. 데이터의 재샤딩 (resharding)

데이터가 너무 많아 하나의 샤드로는 더 이상 감당하기 어려운 경우, 새로운 샤드를 추가해야 한다.

또는 샤드 간 데이터 분포가 균등하지 못하여 샤드 소진(shard exhaustion)이 발생할 때도 샤드 키를 계산하는 함수를 변경하고 데이터를 재배치해야 한다.

해결 방법: 안정 해시(Consistent Hashing) 기법을 활용

2. 유명인사(celebrity) 문제

핫스팟 키(hotspot key) 문제라고도 하는데, 특정 샤드에 질의가 집중되어 서버에 과부하가 걸리는 현상이다.
예: SNS 애플리케이션에서 많이 검색되는 단어(Justin Bieber, Lady Gaga 등)를 같은 샤드에 저장하면, 해당 샤드는 read 연산으로 인해 과부하가 발생할 수 있다.

3. 조인과 비정규화 (join, denormalization)

하나의 DB를 여러 샤드로 분할한 경우, 여러 샤드에 걸친 데이터 조인이 어려워진다.

이를 해결하기 위해 DB를 비정규화하여, 하나의 테이블에서 질의가 수행될 수 있도록 설계하는 방법이 있다.

마지막으로...

저번달에 후쿠오카를 다녀오면서 찍은 사진이다. 조금은 힘들기도 했지만, 취준을 하면서 받았던 스트레스가 조금 날아가긴 했다.

다음 주면 예비군으로 2박 3일 다녀와야 한다.
조금 귀찮기도 하지만, 그래도 다치지 말고 무사히 다녀왔으면 좋겠다.