가상 면접 사례로 배우는 대규모 시스템 설계 기초 1장 - 사용자 수에 따른 규모 확장성 참조

1. 단일 서버 아키텍처

단일 서버 아키텍처는 모든 컴포넌트가 하나의 서버에서 실행되는 가장 간단한 형태의 시스템 설계 방식이다.

이 방식은 초기 서비스 구축이 용이하고 유지보수가 간단하지만, 사용자 수가 증가하면 확장성에 제한이 발생할 수 있다.

✅ 단일 서버의 동작 흐름

1. 사용자는 도메인 이름을 이용하여 웹사이트에 접속한다.
   • 웹 브라우저에서 www.example.com과 같은 도메인을 입력한다.
   • 사용자의 컴퓨터는 해당 도메인의 IP 주소를 찾기 위해 DNS(Domain Name System) 서버에 질의한다.
2. DNS는 도메인 이름을 IP 주소로 변환한다.
   • DNS 서버는 www.example.com의 IP 주소(192.168.1.1 등)를 반환한다.
   • 대부분의 경우, DNS 서비스는 클라우드 제공업체 또는 사설 DNS 서버를 통해 관리된다.
3. 클라이언트(사용자)의 요청이 웹 서버로 전달된다.
   • IP 주소가 확인되면, 사용자의 브라우저는 해당 서버로 HTTP(S) 요청을 보낸다.
   • 요청 방식(예: GET, POST)에 따라 웹 서버가 처리할 작업이 달라진다.
4. 웹 서버는 요청을 처리하고 응답을 반환한다.
   • 웹 서버(Apache, Nginx 등)는 요청을 분석하고 적절한 응답을 생성한다.
   • 응답 데이터는 HTML, JSON, 이미지 파일 등 다양한 형태가 될 수 있다.
   • 예를 들어:
     • 정적 웹사이트라면 HTML, CSS, JavaScript 파일을 반환한다.
     • 동적 웹사이트라면 백엔드 애플리케이션을 통해 데이터베이스에서 정보를 조회하고 JSON 형식의 응답을 반환한다.

---

🎯 단일 서버 아키텍처의 장점

장점	설명
구현이 간단함	모든 기능이 하나의 서버에서 동작하므로 설정 및 유지보수가 용이함
초기 비용이 저렴함	별도의 인프라 구축이 필요하지 않아 저렴한 비용으로 운영 가능
운영이 단순함	서버 하나만 관리하면 되므로 네트워크 및 데이터 동기화 문제가 없음
배포가 간편함	단일 환경에서 테스트 및 배포가 가능하여 개발 속도가 빠름

---

⚠️ 단일 서버 아키텍처의 한계

한계	설명
확장성 문제	사용자가 증가하면 CPU, 메모리, 네트워크 대역폭의 한계에 도달하여 성능 저하가 발생함
단일 장애점(SPOF)	서버가 다운되면 서비스 전체가 중단됨
보안 취약점	모든 요청이 단일 서버로 집중되므로 공격 대상이 되기 쉬움
백업 및 복구의 어려움	데이터와 애플리케이션이 한 곳에 있어 장애 발생 시 데이터 손실 위험이 큼

---

📌 단일 서버가 적합한 경우

단일 서버 아키텍처는 소규모 프로젝트나 MVP(최소 기능 제품)를 개발할 때 적합하다.

✅ 언제 단일 서버를 사용할 수 있을까?

• 트래픽이 낮고 단순한 서비스(예: 개인 블로그, 스타트업 초기 웹사이트)
• MVP(최소 기능 제품) 개발 시 빠른 배포가 필요할 때
• 유지보수 및 운영 인력이 부족한 경우

❌ 언제 단일 서버를 사용하면 안 될까?

• 사용자 수가 빠르게 증가할 가능성이 높은 경우
• 고가용성과 장애 대응이 중요한 경우
• 데이터베이스와 애플리케이션을 분리해야 하는 경우

2. 데이터베이스 분리 및 선택

사용자가 증가하면 단일 서버에서는 모든 요청을 처리하기 어려워진다.

따라서 웹 계층(Web Tier)과 데이터 계층(Database Tier)을 분리하여 독립적으로 확장할 수 있도록 설계해야 한다.

✅ 데이터 계층 분리의 필요성

1. 트래픽 증가
   • 단일 서버는 웹 요청과 데이터베이스 쿼리를 동시에 처리하므로 부하가 증가할수록 성능이 저하된다
   • 요청 수가 많아지면 웹 서버와 데이터베이스 서버를 분리하여 각각 독립적인 자원 할당이 필요하다
2. 독립적인 확장 가능
   • 웹 계층과 데이터 계층을 분리하면 각각 독립적으로 확장하여 성능을 최적화할 수 있다
   • 예를 들어, 웹 트래픽이 증가하면 웹 서버를 추가하고, 데이터 처리량이 많아지면 데이터베이스 서버를 확장할 수 있다
3. 안정성과 보안 강화
   • 데이터베이스 서버를 별도로 운영하면 외부 접근을 제한하여 보안성을 높일 수 있다
   • 웹 애플리케이션 서버 장애 시에도 데이터가 손실되지 않고 보호된다

---

🏛 어떤 데이터베이스(DB)를 사용할 것인가?

데이터베이스는 크게 관계형(Relational, RDBMS)과 비관계형(NoSQL)으로 나뉜다.

각 데이터베이스 유형은 서로 다른 특성과 사용 사례를 가진다.

🔹 관계형 데이터베이스 (RDBMS)

특징:

• 데이터를 테이블, 열(Column), 행(Row) 형태로 구조화하여 저장
• SQL(Structured Query Language)을 사용하여 데이터를 관리
• 여러 테이블 간 조인(Join) 연산을 통해 데이터 관계를 유지 가능
• 트랜잭션(ACID) 지원으로 높은 데이터 일관성 보장

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

특징:

• 스키마(Schema)가 고정되지 않음 → 다양한 형태의 데이터 저장 가능
• 관계형 데이터베이스보다 수평적 확장(Scale-out)이 용이함
• 데이터 구조에 따라 다양한 NoSQL 유형이 존재

NoSQL의 주요 유형 및 특징:

유형	설명	예시
키-값 저장소	Key와 Value로 데이터를 저장, 빠른 조회 속도 제공	Redis, DynamoDB
그래프 저장소	노드(Node)와 엣지(Edge)로 데이터를 저장하여 관계 분석 최적화	Neo4j, ArangoDB
칼럼 저장소	컬럼 기반 저장으로 대규모 데이터 분석에 최적화	Cassandra, HBase
문서 저장소	JSON, BSON 등의 형식으로 데이터를 저장	MongoDB, CouchDB

---

🎯 언제 NoSQL을 선택해야 할까?

일반적으로 대부분의 웹 애플리케이션에서는 관계형 DB(RDBMS)를 기본으로 사용하지만, 다음과 같은 경우 NoSQL이 더 적합할 수 있다.

✅ NoSQL이 적합한 경우

• 아주 낮은 응답 지연시간이 필요한 경우 → 키-값 저장소(Redis) 사용
• 데이터 구조가 비정형(예: JSON, XML)인 경우 → 문서 저장소(MongoDB) 사용
• 데이터의 관계성이 거의 없거나, 관계형 모델이 적합하지 않은 경우
• 수직적 확장(Scale-Up)보다 수평적 확장(Scale-Out)이 필요한 경우
• 데이터를 빠르게 직렬화/역직렬화해야 하는 경우

🏗️ 데이터베이스 선택 가이드

✅ 관계형 DB를 사용해야 하는 경우

• 데이터가 구조화되어 있고 관계형 모델이 필요한 경우
• 데이터 정합성이 중요하며, 트랜잭션을 필요로 하는 경우 (예: 금융, 회계 시스템)
• SQL 기반의 강력한 쿼리 기능이 필요한 경우
• 데이터 변경이 빈번하지 않고, 정형화된 데이터를 저장하는 경우

✅ NoSQL을 사용해야 하는 경우

• 높은 처리량이 필요한 빅데이터 시스템을 운영하는 경우
• 대규모 수평적 확장(Scale-Out)이 필요한 경우
• 반정형 또는 비정형 데이터(예: JSON, XML, 로그 데이터)를 저장해야 하는 경우
• 분산 환경에서의 빠른 데이터 조회가 필요한 경우 (예: 실시간 애널리틱스, 검색 엔진)

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

애플리케이션의 사용자 수가 증가함에 따라 서버의 처리 능력을 확장해야 한다.

이때, 확장 방법에는 크게 수직적 확장(Scale-Up) 과 수평적 확장(Scale-Out) 두 가지가 있다.

✅ 확장의 두 가지 방법

확장 방식	설명	장점	단점
수직적 확장 (Scale-Up)	기존 서버의 성능을 업그레이드하여 처리량 증가	단순한 아키텍처 유지, 빠른 적용 가능	물리적 한계 존재, 단일 장애점(SPOF)
수평적 확장 (Scale-Out)	여러 대의 서버를 추가하여 부하 분산	확장성 우수, 장애 대응 가능	네트워크 복잡성 증가, 데이터 동기화 필요

---

🔹 수직적 확장 (Scale-Up)

수직적 확장은 기존 서버의 CPU, RAM, 디스크 용량을 업그레이드하여 성능을 향상시키는 방법이다.

✅ 장점

• 구성이 단순하여 운영이 쉬움
• 기존 애플리케이션을 변경할 필요가 없음
• 빠른 성능 향상 가능 (서버 업그레이드만 진행하면 됨)

❌ 단점

• 물리적 한계 존재 → CPU 코어 수, RAM 크기 등 증가에 한계가 있음
• 비용 증가 → 고성능 하드웨어 비용이 급격히 상승함
• 단일 장애점(Single Point of Failure, SPOF) 발생 가능 → 서버 장애 시 전체 서비스 중단 위험

💡 언제 수직적 확장을 선택할까?

• 단일 서버로 운영하는 작은 규모의 애플리케이션
• 확장이 필요한데 애플리케이션을 분산할 시간이 부족한 경우
• 데이터베이스 성능이 부족하여 메모리(RAM)나 CPU 업그레이드가 필요한 경우

---

🔹 수평적 확장 (Scale-Out)

수평적 확장은 여러 대의 서버를 추가하고 로드밸런서(Load Balancer)를 사용하여 부하를 분산하는 방식이다.

✅ 장점

• 확장성이 뛰어남 → 서버를 계속 추가할 수 있음
• 장애 대응 가능 → 특정 서버가 다운되더라도 서비스 유지 가능
• 비용 절감 가능 → 여러 대의 저렴한 서버로 확장 가능

❌ 단점

• 네트워크 및 데이터 동기화가 복잡 → 서버 간 데이터 일관성 유지 필요
• 초기 설정이 어렵고 유지보수가 복잡 → 로드밸런서 설정, 데이터베이스 복제 필요
• 애플리케이션 코드 변경이 필요할 수 있음 → 분산 환경에 맞게 설계해야 함

💡 언제 수평적 확장을 선택할까?

• 트래픽이 급격히 증가할 가능성이 높은 서비스 (예: 쇼핑몰, SNS)
• 장애 발생 시 다운타임을 최소화해야 하는 서비스
• 데이터베이스의 읽기/쓰기 부하가 심한 경우

---

🏗️ 로드밸런서(Load Balancer) 역할

로드밸런서는 여러 웹 서버 간 트래픽을 분산하여 부하를 균형 있게 조절하는 역할을 한다.

이를 통해 가용성을 높이고 장애 발생 시 자동 복구를 가능하게 한다.

🔹 로드밸런서 동작 방식

1. 사용자는 로드밸런서의 공개 IP 주소로 접속
2. 로드밸런서는 부하를 감안하여 적절한 웹 서버로 요청을 전달
3. 웹 서버가 응답을 처리하고 결과를 클라이언트에게 반환

🔹 부하 분산 알고리즘

부하 분산 방식	설명
라운드 로빈 (Round Robin)	각 요청을 순차적으로 서버에 배분
최소 연결 방식 (Least Connections)	현재 가장 적은 연결을 가진 서버로 요청 전달
IP 해싱 (IP Hashing)	특정 사용자가 항상 동일한 서버에 연결되도록 설정

로드밸런서 사용 시 고려할 점

• 세션 유지(Session Persistence): 사용자가 로그인된 상태를 유지하려면 같은 서버로 연결해야 할 수도 있음
• 헬스 체크(Health Check): 장애 발생한 서버는 자동으로 트래픽에서 제외하도록 설정 가능

---

🏛️ 데이터베이스 다중화 (DB Replication)

데이터베이스 역시 읽기/쓰기 부하를 분산하고 장애 발생 시 서비스 지속성을 유지하기 위해 다중화가 필요하다.

🔹 DB 다중화 방식

방식	설명
Master-Slave	쓰기는 Master에서만 수행, 읽기는 Slave에서 분산
Master-Master	두 개 이상의 Master에서 읽기/쓰기 수행 가능
Sharding	데이터를 여러 개의 DB 인스턴스로 분할 저장

🔹 Master-Slave 복제의 장점

✅ 더 나은 성능 → 읽기 부하는 여러 Slave 노드로 분산

✅ 고가용성(High Availability) → Master 장애 시 Slave를 승격 가능

✅ 지역 분산 가능 → 물리적으로 떨어진 위치에 데이터 복제 가능

🔹 예제 시나리오: Master 또는 Slave DB 장애 발생 시

1. Master가 다운되는 경우:
   • Slave를 새로운 Master로 승격 (Failover)
   • 서비스가 지속적으로 운영될 수 있도록 설정 필요
2. Slave가 다운되는 경우:
   • Master는 정상 작동하므로 읽기 트래픽이 증가할 수 있음
   • 새로운 Slave를 추가하여 부하를 분산해야 함

---

🏁 확장 방법 선택

서버 및 데이터베이스 확장을 고려할 때는 수직적 확장과 수평적 확장의 장단점을 비교하여 적절한 방식을 선택해야 한다.

✅ 수직적 확장이 적합한 경우

• 기존 서버의 성능 한계에 도달하지 않았을 때
• 단일 서버로 운영해도 무리가 없는 소규모 서비스
• 빠른 성능 향상이 필요하고 확장 비용을 절약하고 싶을 때

✅ 수평적 확장이 적합한 경우

• 사용자가 급격히 증가하는 서비스 (예: 쇼핑몰, 스트리밍 서비스)
• 데이터베이스 부하가 높아 읽기/쓰기 부하를 분산해야 할 때
• 높은 가용성이 요구되는 서비스

4. 캐시 (Cache)

캐시는 자주 참조되는 데이터를 메모리에 저장하여 반복적인 연산을 줄이고, 성능을 향상시키는 기술이다.

이를 통해 데이터베이스(DB) 부하를 줄이고, 빠른 응답 속도를 제공할 수 있다.

---

✅ 캐시 계층 (Cache Layer)

캐시는 여러 계층에서 활용될 수 있으며, 주로 아래와 같은 방식으로 적용된다.

캐시 계층	설명	예시
애플리케이션 캐시	애플리케이션 내부에서 데이터 저장	Local Cache, Memcached
데이터베이스 캐시	DB에서 조회한 데이터를 캐싱	MySQL Query Cache, Redis
웹 캐시	HTTP 요청을 캐싱하여 빠른 페이지 로드 제공	Varnish, Nginx Cache
CDN 캐시	정적 파일(이미지, CSS, JS) 캐싱	Cloudflare, AWS CloudFront

🔹 캐시를 사용하면 어떤 점이 좋을까?

• 성능 개선 → 데이터베이스 접근 없이 빠르게 응답 가능
• 트래픽 감소 → DB 및 애플리케이션 서버의 부하를 줄임
• 사용자 경험 향상 → 페이지 로드 속도가 빨라짐

---

⚠️ 캐시 사용 시 고려해야 할 점

1️⃣ 어떤 데이터를 캐싱할 것인가?

✅ 캐싱에 적합한 데이터:

• 자주 조회되지만 변경이 적은 데이터 (예: 제품 목록, 인기 게시글)
• 계산 비용이 높은 데이터 (예: 통계, 머신러닝 예측 결과)
• API 응답 데이터 (예: 외부 API 호출 결과)

❌ 캐싱에 부적합한 데이터:

• 자주 변경되는 실시간 데이터 (예: 금융 거래 내역)
• 민감한 정보 (예: 사용자 인증 정보)

---

2️⃣ 캐시된 데이터는 언제 만료되어야 하는가?

만료되지 않은 캐시 데이터가 오래 유지되면 오래된 정보가 사용자에게 제공될 위험이 있다.

이를 방지하기 위해 적절한 만료 정책이 필요하다.

만료 정책	설명
TTL(Time-To-Live)	일정 시간이 지나면 캐시된 데이터를 삭제
LRU(Least Recently Used)	가장 오래 사용되지 않은 데이터를 삭제
LFU(Least Frequently Used)	사용 빈도가 낮은 데이터를 삭제
FIFO(First In First Out)	먼저 저장된 데이터를 먼저 삭제

---

3️⃣ 캐시 데이터 일관성 유지

캐시는 데이터베이스와의 일관성이 유지되지 않으면 잘못된 정보가 반환될 위험이 있다.

이를 해결하는 몇 가지 방법이 있다.

방법	설명
Write-Through	데이터를 DB에 저장할 때 캐시에도 저장
Write-Back	캐시에 먼저 쓰고, 일정 시간 후 DB에 반영
Cache Invalidation	DB 변경 시 캐시 데이터 삭제

---

4️⃣ 캐시 장애 대응 방법

• 단일 캐시 서버를 사용하지 않는다.
  • 한 대의 캐시 서버만 사용할 경우, 해당 서버가 다운되면 캐시된 데이터를 사용할 수 없음.
  • 분산 캐시(예: Redis Cluster, Memcached Multi-node)를 통해 캐시 시스템의 안정성을 높일 수 있음.
• Fallback 처리
  • 캐시가 실패하면 DB에서 직접 데이터를 조회하도록 설정.

---

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

• CDN(Content Delivery Network)은 정적 콘텐츠(이미지, CSS, JavaScript 등)를 지리적으로 분산된 서버에 캐싱하여 빠르게 전송하는 네트워크이다.

이를 통해 사용자와 가장 가까운 서버에서 콘텐츠를 제공하여 웹사이트 로딩 속도를 향상시킨다.

---

✅ CDN의 작동 방식

1. 사용자가 웹사이트에서 정적 파일을 요청한다.
2. CDN 서버는 해당 콘텐츠가 캐시에 있는지 확인한다.
   • 캐시에 있음 → 즉시 제공
   • 캐시에 없음 → 원본 서버에서 가져온 후 저장
3. 이후 동일한 요청이 들어오면, CDN은 캐시된 콘텐츠를 제공하여 빠른 응답을 보장한다.

---

⚡ CDN 사용 시 이점

이점	설명
응답 속도 향상	사용자와 가까운 CDN 서버에서 콘텐츠를 제공
서버 부하 감소	원본 서버에 대한 요청 수를 줄임
대역폭 절감	정적 콘텐츠 전송을 최적화하여 네트워크 비용 절감
트래픽 급증 대응	갑작스러운 트래픽 증가에도 안정적인 서비스 제공

---

⚠️ CDN 사용 시 고려해야 할 점

1️⃣ 비용 문제

• CDN은 트래픽 사용량에 따라 요금이 부과됨.
• 자주 사용되지 않는 콘텐츠는 캐싱하지 않는 것이 비용 절감에 도움이 될 수 있음.

2️⃣ 적절한 만료 시간 설정

• 짧으면 → 원본 서버에 자주 접속하여 부하 증가
• 길면 → 오래된 콘텐츠가 사용자에게 제공될 가능성 증가

3️⃣ CDN 장애 시 대처 방법

• CDN 서비스가 다운될 경우, 원본 서버에서 직접 콘텐츠를 제공하도록 설정해야 함.
• 서버 구성 예시

  server {
      location /static/ {
          proxy_pass <http://cdn.example.com>;
          error_page 502 = @fallback;
      }
  
      location @fallback {
          root /var/www/html/static/;
      }
  }
  

6. 무상태 웹 계층 (Stateless Web Tier)

대규모 트래픽을 처리하기 위해 웹 계층을 수평적 확장(Scale-Out) 하려면 무상태 아키텍처(Stateless Architecture)를 적용해야 한다.

웹 서버가 특정 상태를 유지하면 확장성과 장애 대응이 어려워지므로, 상태 정보를 외부 저장소에 보관하는 것이 중요하다.

---

✅ 무상태 웹 계층의 개념

무상태(State-less) 웹 계층에서는 각 요청이 독립적으로 처리되며, 웹 서버는 클라이언트의 상태를 저장하지 않는다.

이 방식은 수평적 확장(Scale-Out)을 가능하게 하고, 특정 서버에 의존하지 않도록 한다.

🔹 왜 무상태(State-less) 웹 계층이 필요할까?

• 트래픽 증가에 대비한 확장성 확보 → 여러 웹 서버를 추가하여 부하 분산 가능
• 장애 복구 및 가용성 향상 → 특정 서버 장애 시에도 다른 서버에서 요청을 처리 가능
• 로드밸런서 부담 감소 → 특정 서버에 종속되지 않으므로 부하를 고르게 분산 가능

---

🔄 상태 정보 의존적인 아키텍처(Stateful Architecture)

상태를 유지(Stateful)하는 웹 계층은 클라이언트 세션 정보를 서버가 직접 관리하는 방식이다.

이 경우, 클라이언트의 요청이 항상 같은 서버로 가야 하며, 로드밸런서는 고정 세션(Persistent Session) 또는 세션 스티키(Session Stickiness) 기능을 사용하여 요청을 특정 서버로 유지해야 한다.

⚠️ 상태 유지 아키텍처의 문제점

• 확장성이 제한됨 → 특정 서버에 의존하므로 새로운 서버를 추가해도 부하가 자동으로 분산되지 않음
• 장애 발생 시 문제 → 사용자가 로그인한 서버가 다운되면 세션 데이터 손실 가능
• 로드밸런서 부담 증가 → 특정 사용자 요청을 같은 서버로 보내야 하므로 균등한 부하 분산이 어려움

---

🌍 무상태 아키텍처 (Stateless Architecture)

무상태 웹 계층에서는 상태 정보를 웹 서버에서 제거하고, 필요할 때 외부 저장소에서 조회하는 방식으로 동작한다.

✅ 상태 정보를 어디에 저장할까?

저장소 유형	설명	예시
세션 저장소	세션 데이터를 외부 DB 또는 캐시에 저장	Redis, Memcached
토큰 기반 인증	클라이언트가 인증 토큰을 저장하여 매 요청마다 전송	JWT, OAuth
분산 데이터 저장소	상태 정보를 공유 데이터베이스에 저장	MySQL, PostgreSQL

🔹 무상태 웹 계층을 구현하는 방법

1. 세션 데이터를 외부 저장소(예: Redis)에 저장
2. JWT(JSON Web Token)를 사용하여 클라이언트에서 상태 관리
3. 각 요청이 독립적으로 처리되도록 설계
4. 모든 서버가 동일한 요청을 처리할 수 있도록 구성

✅ 예제: JWT를 이용한 인증 방식

• 사용자가 로그인하면 JWT를 생성하여 클라이언트에 전달
• 이후 모든 요청에서 JWT를 포함하여 인증 수행
• 서버가 상태를 저장하지 않으므로 모든 서버에서 동일한 방식으로 처리 가능

7. 데이터 센터 (Data Center)

대규모 서비스에서는 단일 데이터 센터를 사용하기보다 다중 데이터 센터 아키텍처(Multi Data Center Architecture)를 도입하여 가용성과 성능을 향상시킨다.

---

✅ 데이터 센터 아키텍처

• 데이터 센터(Data Center)는 사용자의 지리적 위치에 따라 가장 가까운 서버를 제공하여 네트워크 성능을 최적화하고, 장애 발생 시에도 서비스를 지속할 수 있도록 한다.

🔹 데이터 센터 확장의 필요성

1. 성능 최적화 → 사용자와 가까운 데이터 센터에서 콘텐츠 제공하여 응답 시간 단축
2. 장애 복구(Failover) → 특정 데이터 센터가 다운되더라도 다른 데이터 센터에서 서비스 지속 가능
3. 트래픽 관리 → 트래픽이 특정 지역에 집중되지 않도록 분산 가능

---

🌐 트래픽 우회 (Traffic Routing)

• 지리적 라우팅(GeoDNS)을 활용하면 사용자의 위치에 따라 가장 가까운 데이터 센터로 트래픽을 전달할 수 있다.

트래픽 우회 방법	설명
GeoDNS	사용자의 위치를 기반으로 가장 가까운 데이터 센터로 연결
Anycast IP	여러 데이터 센터에 동일한 IP를 제공하여 최적의 경로 선택
로드밸런서	부하를 분산하여 여러 데이터 센터로 트래픽 전달

✅ 예제: GeoDNS를 활용한 트래픽 우회

• 미국 사용자는 US 데이터 센터
• 유럽 사용자는 EU 데이터 센터
• 아시아 사용자는 APAC 데이터 센터로 연결되도록 구성

---

🔄 데이터 동기화 (Data Synchronization)

다중 데이터 센터를 운영할 때는 데이터 일관성을 유지하기 위한 데이터 동기화 전략이 필요하다.

동기화 방식	설명
Master-Slave 복제	한 개의 Master에서 쓰기, 여러 Slave에서 읽기 수행
Multi-Master 복제	여러 데이터 센터에서 쓰기/읽기 가능 (충돌 해결 필요)
Eventual Consistency	일정 시간이 지나면 모든 데이터가 동기화됨

🔹 데이터 동기화 문제 해결 방법

1. 쓰기 연산을 특정 데이터 센터로 제한하고 읽기 분산
2. Conflict Resolution(충돌 해결) 알고리즘 적용
3. 데이터 업데이트 시 동기화 주기를 고려하여 설계

---

🚀 다중 데이터 센터에서의 배포 및 테스트

여러 데이터 센터를 운영하는 경우, 애플리케이션의 배포 및 테스트 전략이 중요하다.

🔹 배포 시 고려 사항

• 블루-그린 배포(Blue-Green Deployment) → 새로운 버전을 특정 데이터 센터에 먼저 배포 후 점진적 적용
• 카나리아 배포(Canary Deployment) → 일부 사용자를 대상으로 새로운 버전을 테스트 후 전체 적용
• 롤백 전략 → 문제 발생 시 이전 버전으로 즉시 복구 가능하도록 설계

✅ 예제: 블루-그린 배포

• Green: 새로운 버전이 적용된 서버 그룹
• Blue: 기존 버전이 유지되는 서버 그룹
• 새 버전이 안정적인지 확인 후 전체 트래픽을 Green으로 전환

8. 메시지 큐 (Message Queue)

• 메시지 큐(Message Queue, MQ)는 비동기 통신을 지원하며, 메시지의 무손실 전송을 보장하는 시스템이다.

이를 통해 생산자(Producer)와 소비자(Consumer) 간의 비동기 메시지 전달이 가능하다.

---

✅ 메시지 큐의 개념 및 필요성

메시지 큐는 시스템 간의 비동기 데이터 전송을 위한 버퍼 역할을 하며, 생산자와 소비자가 독립적으로 동작할 수 있도록 한다.

🔹 메시지 큐가 필요한 이유

1. 비동기 작업 처리 가능 → 요청을 바로 처리하지 않고 메시지 큐에 저장 후 비동기적으로 실행 가능
2. 부하 분산(Load Balancing) → 트래픽 급증 시에도 요청을 안정적으로 처리 가능
3. 서비스 독립성 증가 → 생산자와 소비자가 별도로 동작하여 서로의 장애 영향을 받지 않음
4. 신뢰성 보장 → 메시지가 손실되지 않고 안정적으로 전달됨

---

🔄 메시지 큐의 기본 아키텍처

메시지 큐는 생산자(Producer)와 소비자(Consumer)로 구성된다.

graph LR
    A["Producer (생산자)"] -->|메시지 전송| B["Message Queue"]
    B -->|메시지 전달| C["Consumer (소비자)"]
    B -->|메시지 전달| D["Consumer (소비자)"]

✅ 메시지 큐 동작 방식

1. 생산자(Producer)가 메시지를 생성하여 큐에 삽입한다.
2. 메시지 큐(Message Queue)는 메시지를 보관하고 관리한다.
3. 소비자(Consumer)가 메시지를 가져가서 처리한다.
4. 메시지가 정상적으로 처리되면 메시지는 큐에서 삭제된다.

🌍 메시지 큐 시스템 비교

메시지 큐 시스템	특징
RabbitMQ	메시지 라우팅, 트랜잭션 지원, AMQP 프로토콜 기반
Apache Kafka	대량 데이터 스트리밍, 로그 기반 메시지 처리
AWS SQS	관리형 메시지 큐 서비스, 서버리스 환경에서 적합
Google Pub/Sub	클라우드 기반 이벤트 스트리밍, 비동기 메시징

✅ 예제: RabbitMQ를 활용한 비동기 메시지 처리

• 사용자 요청을 처리할 때, 이메일 발송을 동기적으로 수행하면 응답 시간이 길어질 수 있음.
• 메시지 큐를 사용하면 이메일 발송 작업을 비동기적으로 처리하여 사용자 응답 속도를 개선할 수 있음.

---

9. 로그, 메트릭, 자동화

시스템의 안정성과 성능을 유지하려면 로그(Log)와 메트릭(Metrics)을 분석하고, 자동화(Auto-scaling & Automation)를 적용하는 것이 필수적이다.

---

✅ 로그 (Log)

로그(Log)는 시스템의 동작을 기록하는 데이터이며, 장애 발생 시 원인을 분석하는 데 필수적이다.

🔹 로그의 종류

로그 유형	설명
애플리케이션 로그	애플리케이션에서 발생한 이벤트 및 오류 기록
시스템 로그	OS 및 서버에서 발생한 이벤트 기록
보안 로그	로그인 및 인증 관련 활동 기록
네트워크 로그	트래픽 모니터링 및 네트워크 이벤트 기록

✅ 로그 분석을 위한 도구

도구	설명
ELK Stack (Elasticsearch, Logstash, Kibana)	로그 수집, 저장, 분석 및 시각화
Splunk	실시간 로그 모니터링 및 분석
Fluentd	로그 수집 및 전달에 최적화된 오픈소스 도구

✅ 예제: ELK Stack을 활용한 로그 분석

• Logstash로 다양한 소스에서 로그를 수집하고, Elasticsearch에 저장한 후 Kibana에서 시각화 가능

---

📊 메트릭 (Metrics)

메트릭(Metrics)은 시스템의 성능 및 상태를 측정하는 데이터로, 실시간 모니터링을 통해 장애를 사전에 감지할 수 있다.

🔹 주요 메트릭 유형

메트릭 유형	설명
호스트 메트릭	CPU, RAM, 디스크 사용량 등
애플리케이션 메트릭	응답 시간, 오류율 등
비즈니스 메트릭	사용자 수, 거래량, 트랜잭션 수 등

✅ 메트릭 모니터링 도구

도구	설명
Prometheus	시계열 데이터 저장 및 모니터링
Grafana	실시간 대시보드 시각화 도구
Datadog	클라우드 기반 모니터링 및 경고 시스템

✅ 예제: Prometheus & Grafana를 활용한 실시간 모니터링

• Prometheus가 시스템 메트릭을 수집하고, Grafana에서 대시보드를 통해 실시간 모니터링 가능

---

⚙️ 자동화 (Automation)

• *자동화(Auto-scaling & Automation)는 시스템이 일정한 조건을 충족하면 자동으로 확장 또는 축소**하도록 설정하는 기능이다.

🔹 자동화가 필요한 이유

1. 트래픽 변화 대응 → 사용자가 급증할 때 자동으로 서버를 추가하고, 트래픽 감소 시 자원을 회수
2. 비용 절감 → 필요할 때만 리소스를 사용하여 비용 최적화
3. 운영 효율성 향상 → 수작업 없이 시스템이 자동으로 조정됨

✅ 자동화 기술 및 도구

자동화 도구	설명
AWS Auto Scaling	트래픽 증가에 따라 EC2 인스턴스 자동 추가/제거
Kubernetes Horizontal Pod Autoscaler	컨테이너 수를 자동으로 확장
Terraform	인프라를 코드로 관리하는 IaC(Infrastructure as Code) 도구
Ansible	서버 설정 및 배포 자동화

✅ 예제: AWS Auto Scaling 활용

• EC2 인스턴스를 자동 확장하여 트래픽 변화에 유연하게 대응할 수 있도록 설정

10. 데이터베이스 규모 확장 (Database Scalability)

대규모 트래픽과 데이터 증가에 대비하기 위해 데이터베이스(DB)는 지속적으로 확장 가능해야 한다.

확장 방법에는 수직적 확장(Scale-Up)과 수평적 확장(Scale-Out, 샤딩)이 있으며, 각각 장단점이 존재한다.

---

✅ 수직적 확장 (Scale-Up)

수직적 확장은 기존 서버의 하드웨어 성능을 업그레이드하여 데이터베이스의 처리 용량을 증가시키는 방식이다.

🔹 수직적 확장의 한계

1. 하드웨어 확장의 물리적 한계 → CPU, RAM, 디스크 성능에는 한계가 있음
2. 단일 장애점(SPOF, Single Point of Failure) → 단일 서버에 모든 데이터를 저장하면 장애 발생 시 전체 서비스가 중단될 위험이 있음
3. 고비용 → 고성능 장비는 비용이 기하급수적으로 증가함

✅ 언제 수직적 확장을 선택할까?

• 데이터 양이 크지 않고, 단일 서버에서도 충분한 성능을 제공할 수 있을 때
• 애플리케이션의 구조를 변경하기 어렵고, 즉각적인 성능 향상이 필요할 때

---

🔄 수평적 확장 (Scale-Out, Sharding)

수평적 확장은 여러 개의 데이터베이스 서버를 추가하여 부하를 분산하는 방식이며, 일반적으로 샤딩(Sharding) 기술을 사용한다.

🔹 샤딩(Sharding)이란?

샤딩은 샤드(Shard) 라고 불리는 작은 단위로 데이터를 나누어 저장하는 기술이다.

모든 샤드는 같은 스키마(Schema)를 사용하지만, 저장하는 데이터는 중복되지 않는다.

graph TD;
    A[전체 데이터베이스] -->|Shard Key에 따라 데이터 분할| B[Shard 1];
    A -->|Shard Key에 따라 데이터 분할| C[Shard 2];
    A -->|Shard Key에 따라 데이터 분할| D[Shard 3];

✅ 샤딩을 사용할 때 고려해야 할 점

가장 중요한 요소는 샤딩 키(Sharding Key)를 올바르게 설계하는 것이다.

샤딩 키(또는 파티션 키)는 데이터가 어떤 샤드에 저장될지를 결정하는 기준 값이다.

🔹 샤딩 키 설계 시 고려해야 할 사항

1. 균등한 데이터 분포 → 특정 샤드에 과부하가 집중되지 않도록 설계해야 함
2. 조인(Join) 최소화 → 여러 샤드 간 조인이 어렵기 때문에 데이터를 비정규화하여 설계해야 함
3. 데이터 재샤딩(Re-sharding) 가능성 고려 → 데이터가 증가하면 샤드를 추가할 수 있도록 유연한 설계 필요

⚠️ 샤딩 사용 시 발생할 수 있는 문제점

1️⃣ 데이터 재샤딩(Re-sharding)

데이터가 특정 샤드에 집중되거나 용량을 초과하면 새로운 샤드로 데이터를 이동해야 하는 경우가 발생할 수 있다.

✅ 데이터 재샤딩이 필요한 경우

• 한 개의 샤드가 너무 커져서 더 이상 감당할 수 없을 때
• 샤드 간 데이터 분포가 불균형하여 일부 샤드가 과부하될 때

2️⃣ 유명인사(Hotspot) 문제

• 특정 샤드에 인기 있는 데이터(예: 인기 게시글, 특정 사용자 데이터)가 집중될 경우 해당 샤드에 과부하가 발생할 수 있음.
• 해결책:
  • 샤딩 키를 랜덤한 값 또는 해싱(Hashing) 기반으로 설정
  • 인기 데이터는 별도의 캐시 시스템(Redis 등)에서 제공

3️⃣ 조인과 비정규화(De-normalization)

• 여러 샤드에 분산된 데이터를 조인(Join)하는 것이 어렵다.
• 해결책:
  • 비정규화(Denormalization) → 필요한 데이터를 한 테이블에 저장하여 조인을 최소화
  • 애플리케이션에서 조인 처리 → 데이터 조회 후 애플리케이션에서 조합

🏗️ 데이터베이스 확장 전략 비교

확장 방식	장점	단점	사용 사례
수직적 확장(Scale-Up)	운영이 단순함, 즉각적인 성능 향상 가능	물리적 한계, 고비용, 단일 장애점	소규모 서비스, 데이터베이스 변경이 어려운 경우
수평적 확장(Scale-Out, Sharding)	무한한 확장 가능, 장애 발생 시 일부 샤드만 영향	샤딩 키 설계 필요, 조인 어려움, 재샤딩 필요	대규모 데이터 처리, 글로벌 서비스