스케일링을 고려한 아키텍쳐

Scaling

• 성능 저하 없이 더 많은 요청을 처리할 수 있도록 리소스를 확장하는 과정을 의미
• 데이터 처리량의 증가에 대비해 확장 가능한 아키텍쳐를 설계하는 것이 중요

• 클라우드 네이티브의 장점으로 클라우드 네이티브 아키텍쳐는 마이크로 서비스, 컨테이너, 오토스케일링을 통해 자동으로 확장성을 제공한다.

  1. 수직: 스펙업
  2. 수평: 서버 개수 증가

Scaling을 고려한 시스템 아키텍처 설계 원칙

1. 유연성: 확장 가능성을 고려한 모듈화된 아키텍쳐 설계가 필요하다.
2. 복원력: 확장 과정에서 장애를 방지하고, 시스템이 자동으로 복구할 수 있도록 설계한다.
3. 확장 가능한 데이터 관리: 데이터 일관성을 유지하면서 여러 서버 간에 데이터를 효율적으로 분산하는 방법을 고려

AutoScaling 전략

1. AWS Auto Scaling: EC2 인스턴스나 컨테이너 수를 트래픽 및 리소스 사용량에 따라 자동으로 조정
2. Kubernetes HPA(Horizontal Pod Autoscaler):
   • HPA는 Kubernetes에서 Pod의 수를 자동으로 조절하는 기능
   • 클러스터 내에서 리소스 사용량에 따라 Pod의 수를 증가 또는 감소시켜 애플리케이션 성능을 유지

     고려 사항

     • 임계값 설정: 자원을 확장하는 기준이 되는 메트릭의 임계 값을 적절하게 설정해야 한다.
     • 트리거: 스케일링 유발 트리거를 설정해야 한다.
     • 자동화와 모니터링: 자동으로 확장되도록 설정했더라도, 시스템이 예상대로 작동하는지 모니터링이 필요
     • 비용 관리: 오토스케일링은 편리하지만 과도한 리소스 확장은 비용 문제로 돌아올 수 있다.
     • 오토스케일링을 통한 비용 최적화 전략
       • 온디맨드 리소스와 리저브드 인스턴스를 혼합
       • 자동화 도구로 피크/ 비피크 시간대를 고려한 스케쥴링

로드밸런싱

• 대규모 트래픽이 발생할 때 서버 하나가 감당할 수 없는 부하가 생기지 않도록 트래픽을 여러 서버에 분산시켜 성능을 최적화한다.
• 여러 서버에 분산해서 안정성, 성능을 유지시키는 중요 기술
• 트래픽 집중을 방지하고 장애 시에도 트래픽을 다른 서버로 자동 분산할 수 있다.

ELB(AWS Elastic Load Balancer)

• AWS 네트워크 계층에서 동작하는 로드 밸런서
• 여러 EC2 인스턴스에 트래픽을 균등하게 분산
• 모든 네트워크 트래픽을 분산시키며, 네트워크 레벨에서 작동

ALB(Application Load Balancer)

• ALB는 애플리케이션 계층에서 동작하는 로드밸런서
• 주로 HTTP, HTTPS 트래픽을 처리
• 경로기반, 호스트 기반 라우팅으로 특정 트래픽을 특정 애플리케이션으로 정확하게 분배
• Websocket 지원 등 애플리케이션 레벨의 추가 기능을 제공

ELB vs. ALB

• ELB는 네트워크 계층에서 모든 트래픽을 분산
• ALB는 애플리케이션 계층에서 HTTP/HTTPS를 주로 처리

안정성을 유지하는 방법

• 세션 유지
• 성능 모니터링
• 다중 리전 로드 밸런식

네트워크 최적화, 트래픽 분산 시 추가 고려 사항

• 지리적 분산: CDN 등과 함께 사용
• 로드밸런서 상태 체크: 서버 상태를 주기적으로 확인해서 비정상 서버로 트래픽이 라우팅되지 않도록 한다.

캐싱 전략

• 캐싱은 데이터, 계산 결과를 미리 저장해 두었다가 나중에 동일한 요청이 들어올 때 빠르게 응답하기 위한 기술
• 캐싱 전략을 사용하면 응답속도를 향상시킬 수 있으며, API 응답이나 반복적인 데이터 조회에 유용

  종류

• REDIS
• Memcached

인기있는 캐싱 전략 및 데이터 일관성 관리

1. LRU(Least Recently Used) 전략: 오래 사용하지 않은 데이터를 우선적으로 삭제해서 캐시 공간을 확보
2. 캐시 무효화: 데이터 변경 시, 캐시된 오래된 데이터를 무효화하고 새로운 데이터로 대체하는 방법
3. 캐시 계층 설계
   • 캐시 계층을 설계할 때 만료 정책과 데이터 일관성을 고려해야한다.
   • 너무 오래된 캐시가 있다면 데이터 불일치 문제가 발생할 수 있따.
   • TTL(Time To Live): 유효 기간을 설정해서 일정 기간이 지나면 자동으로 삭제되도록한다.
   • 다중 계층 캐싱(Multi-layer Caching): 데이터를 효율적으로 저장하고 빠르게 접근하기 위해서 여러 단계의 캐시 시스템을 이용하는 것

로드밸런싱

• 크기가 작을 때:
  • 고정 트래픽 분산: 간단한 로드밸런싱으로 충분히 성능을 보장할 수 있다. (ALB, ELB 설정 정도로 충분히 대응 가능)
• 크기가 커지면:
  • 지리적 분산, 다중 리전 지원: 트래픽이 많아지면, 로드밸런서가 더 복잡해지고 고급 기능이 필요해진다. (CDN, Anycast 네트워크 활용)

캐싱 전략

• 크기가 작을 때:
  • 간단한 캐싱 적용
• 크기가 커지면
  • 다중 계층 캐싱 도입: 트래픽이 늘어나면, 다중 계층 캐싱을 통해 성능 극대화한다.
  • 서버 간의 캐시 분산을 적용하고, 데이터 일관성을 유지하기 위한 복잡한 캐시 전략을 도입

데이터베이스 전략

• 크기가 짝을 때:
  • 기본적 사용으로 안정성과 비용 모두 챙김
• 크기가 커지면
  • 샤딩이나 분산 데이터베이스로 효율화

1. 다중 계층 캐싱의 기본 개념

• 효율 극대화를 위해서 여러 단계로 나눠서 사용할 수 있다.

  • L1(첫 번째 계층):
    • 애플리케이션 내부에서 가장 빠르게 접근할 수 있는 캐시
    • 주로 메모리 내부에 저장되며, 자주 접근하는 데이터를 여기에 저장
    • 접근 속도가 매우 빠르지만, 용량이 제한적임
  • L2(두 번째 계층):
    • 메모리보다 느리지만, 더 많은 양의 데이터를 저장할 수 있는 외부 캐시 시스템을 의미
    • Redis, Memcached 같은 외부 솔루션을 사용해 더 많은 데이터를 저장
    • L1보다 느리지만, 훨씬 더 많은 데이터를 저장할 수 있다.
  • L3(세 번째 계층):
    • 더 낮은 단계의 캐시, DB나 원번 서버와 같은 위치를 의미
    • 최후의 데이터 저장소
    • L1, L2 캐시에서 찾을 수 없는 데이터를 가져오는 곳
    • 접근 속도가 가장 느리지만, 데이터를 항상 저장하고 있음

2. 다중 캐싱 동작 방식

1. L1 탐색
2. L1에 없으면 L2 탐색
3. L2에 없으면 L3 또는 DB 조회

3. 장점

1. 성능 향상
2. 리소스 절약
3. 확장성

4. 단점, 고려 사항

1. 복잡성 증가: 캐시 일관성 고려, 캐시 무효화 전략 설계
2. 데이터 일관성: 부패된 캐시 데이터는 DB와 싱크가 맞지 않을 수 있다.

분산 아키텍쳐

1. 분산 아키텍쳐

• 분산 시스템의 정의:
  • 여러 독립적인 서버 또는 노드가 협력하여 하나의 시스템처럼 작동하는 구조
  • 대규모 애플리케이션에서 널리 사용된다.
  • 이를 통해서 더 많은 트래픽을 처리하고, 장애에 대한 내성을 강화할 수 있다.
• 확장:
  • 단일 서버는 물리적 한계가 있음
  • 따라서 여러 서버로 확장하는 것이 필요하며, 트래픽을 유연하게 대응할 수 있다.

2. 데이터 복제 및 분산 처리

• 데이터 복제: 데이터를 여러 노드에 복사해서 저장하면 자여스레 부하 분산이 가능하다.
• 분산 처리: MapReduce는 대표적 분산 처리 프레임 워크다.
• 일관성 문제:
  • 각 노드 간 싱크가 살짝씩 맞지 않을 수도 있으며, 이를 해결하기 위해서 일관성 모델을 적용한다.
  • 강한 일관성 : 모든 노드에서 동일한 데이터를 보장
  • 최종 일관성 : 시간이 지남에 따라 데이터가 동기화됨을 의미

3. SPOF 방지 및 고가용성(HA) 유지

1. SPOF: 컴포넌트 하나의 장애가 다른 곳으로 전파되는 것을 방지
2. 고가용성: 시스템이 지속적으로 사용 가능하도록 복제와 장애 복구 기능을 설계

4. 분산 트랜잭션 관리

1. 2PC(2-PhaseCommit):
   • 분산 시스템에서 트랜잭션을 안전하게 커밋하는 기법으로, 모든 노드가 트랜잭션 준비가 완료되면 커밋/ 롤백을 결정한다.
   • 단, 네트워크 지연이 생기면 같이 늦어진다.
2. SAGA 패턴:
   • 각 트랜잭션을 작은 단위로 나눠 처리하는 방식
   • 성공적으로 실행된 트랜잭션 이후에 문제가 발생하면 롤백을 수행

5. 트랜잭션 관리 시 확장성 문제 고려

1. 네트워크 분할 문제:
   • 네트워크 분할 + 장애일 경우 일부가 독립적으로 운영되면서 전체 시스템이 정상적으로 동작할 수 있도록 해야 함
2. 확장성을 고려한 관리 기법:
   • 비동기 트랜잭션 처리 방식과 같은 확장성 기법을 적용해서 트랜잭션이 독립적 노드에서 처리되도록 설계

DB 확장 전략

1. 수직

1. 장점
   • 구조 변경 없이 자원만 추가하면 된다.
   • 성능 향상이 손쉬움
2. 단점
   • 물리적 한계가 있다.
   • 비용이 급격하게 증가할 수 있다.

2. 수평

• 샤딩: 샤드 단위로 분할해서 여러 서버에서 분산 처리하는 방식이다. 샤딩 키를 기준으로 데이터를 나누며 각 샤드는 독립적인 DB처럼 작동한다.
  1. 장점
  • 여러 서버로 부하 분산
  • 이론적으로 무한히 확장 가능
    1. 단점
  • 샤딩 키 선택이 매우 중요하다.
  • 데이터 일관성 유지가 어렵고 복잡하다.

3. Replication

• 여러 복제본을 생성하여, 읽기 및 쓰기 작업을 분산하는 방식
  1. M-S:
  • Master는 쓰기, Slave는 읽기
  • 읽기 성능이 중요한 시스템에 적합
    1. M-M
  • 여러 Master가 쓰기 작업을 하며, 데이터 동기화가 필요하다.
  • 글로벌 서비스나 대규모 시스템에서 주로 사용