아키텍쳐

고려사항

  • 사용자 수가 얼마나 되는가?
  • 얼마나 성장할 것인가?
  • 기술 스택이 무엇인가?

설계 전

  • 시스템에서 전반적으로 달성해야 할 목표와 가능 범위 확인
  • 전체 설계의 개략적 청사진 마련
  • 상세 설계에서 집중해야 할 영역들 확인

목표 설정

  • 시스템 아키텍쳐 설계는 명확한 목표를 설정하는 것이 중요하다.
  • 잘못된 목표를 설정하면 시스템 성능, 보안, 확장성에 큰 영향을 준다.
  • 서비스 소준 목표(SLO): 서비스가 충족해야 할 성능, 가용성, 응답 시간 등의 구체적 기준을 정의

SLA -> the agreement you make with your clients or users SLOs -> the objectives your team must hit to meet that agreement SLIs -> the real numbers on your performance

안정성, 확장성, 신뢰성을 고려한 아케텍쳐 설계

  • 안정성
    • 장시간동안 중단 없이 동작할 수 있도록 보장하는 것이 목표다.
    • 이를 위해서 장애를 감지하고 복구하는 기능이 있어야 한다.
    • 회복력 있는 아키텍쳐(Self-Healing이 가능한)로 안정성을 도모한다.
  • 확장성
    • 더 많은 사용자를 수용하거나 데이터 처리량을 증가시킬 수 있도록 설계되어야 함
    • 수직 vs. 수평 -> ScaleUp vs. ScaleOut
      1. 유연한 리소스 확장
        • 수평 확장은 상대적으로 저렴한 서버나 인스턴스를 여러 대 추가하여 성능을 높일 수 있기에 비용 대비 성능 효율성이 높다.
      2. 비용 효율성
        • 수직 확장은 자체 Spec을 올려서 성능을 향상시키는 방식이다. 고사양으로 가면 갈수록 단가가 높아진다.
        • 수평 확장은 클라우드 특성인 탄력성을 극대화할 수 있다.
      3. 고가용성
        • 수평 확장을 사용하면 여러 대의 서버에 트래픽을 분산할 수 있다.(고가용성)
        • 로드밸런서를 통해 트래픽을 여러 서버로 분산시키고 하나가 장애가 발생해도 자동 복구와 장애 서버 대체가 가능
      4. 무중단 서비스 운영
        • 수평 확장은 시스템을 확장하면서도 무중단 배포가 가능하게 해줌(blue-green/ canary)
        • 수직 확장에는 서버 업그레이드나 재시작 시 서비스가 중단될 수 있다.
        • 수평 확장은 서버 교체가 유연하다.
      5. 클라우드 네이티브 애플리케이션에 적합
        • 클라우드 네이티브 애플리케이션은 분산 시스템을 기반으로 설계되기에 수평확장이 더 자연스럽고 효율적이다.
        • 마이크로 서비스 아키텍쳐를 사용해서 각 서비스가 독립적으로 확장될 수 있다.
        • 각 서비스가 컨테이너화되어 있고, 이러한 컨테이너를 여러 대 실행해서 부하 분산을 시킬 수 있다.
      6. 성능 병목 해결
        • 수직 확장은 물리적 자원의 한계에 도달할 수 있다.
        • 수평 확장은 병목이 발생하는 구간에만 추가 리소스를 투입할 수 있어서 각 구성요소가 필요에 따라 확장할 수 있다.
      7. 글로벌 확장에 유리
        • 수평 확장은 글로벌 서비스가 적합
        • CDN과 결합하면 더 좋다.
  • 신뢰성
    • 시스템의 데이터 무결성, 일관성을 유지하는 것이 목표다.
    • 데이터 복제, 분산 DB는 데이터 손실 방지를 보장한다.
    • 장애 복구전략: 장애 발생 시 데이터 손실을 방지하기 위한 복구 계획이 필수적이다.
    • 지리적 복제: 데이터를다른 리전에 복제할 수 있다.

클라우드 기반 시스템 설계 시 고려 사항

  • 자동화: 리소스 프로비저닝, 스케일링, 모니터링을 자동화하여 사람이 개입하지 않고도 원활히 운영될 수 있음
  • 보안: 클라우드 시스템에서는 데이터 암호화, 접근 제어와 같은 보안 조치가 필수. 민감한 데이터 처리 시, 규정 준수도 중요
  • 비용 관리: 클라우드 리소스는 사용량에 따라 비용이 발생하므로, 불필요한 자원 낭비를 줄이고 최적의 성능을 제공하면서도 비용을 최소화하는 아키텍쳐 설계가 중요
  • 트래픽 관리: 로드 밸런싱, 오토스케일링을 통해서 클라우드 트래픽 증가에 대비해야 하며, 이를 통해 시스템 성능을 유지하고 트래픽 급증에도 서비스가 안정적으로 운영될 수 있도록 해야한다.

시스템 아키텍쳐 유형

System-Architectures1.png

  1. Integrated
    • FitForPurpose(규모 확장에 적합): 통합형 시스템은 특정 목적을 당성하기 위해 설계된 아키텍쳐. 모든 요소가 서로 통합되어 작동하며, 각 워크로드에 맞게 개별적으로 조정됨
  2. Distributed
    • FitForScale(규모 확장에 적합): 분산형 아키텍쳐는 여러 서버와 자원들이 문산위어 운영됨으로써 수평확장이 용이
  3. Pooled
    • FitForEfficiency(효율에 적합): 풀링 아키텍쳐는 여러 자원을 하나의 풀로 모아 효율적으로 자원을 공유하고 관리한다.
  4. Converged
    • FitForAgility(유연성에 적합): 융합형 아키텍쳐는 다양한 IT 자원을 통합하여, 필요에 따라 쉽게 자원을 추가하거나 제거할 수 있는 유연한 구조다.

더 나은 아키텍쳐 설계

  • 더 나은 아키텍쳐는 상황에 맞는 유연성을 기반으로 시스템 안정성과 확장성을 동시에 고려해야 한다.
  • 초기 단계에서 과도한 리소스 투자는 피하고, 필요할 때 필요한 만큼만 확장하는 전략을 통해 효율적인 운영을 가능하게 함
  • 오버 엔지니어링, 언더 엔지니어링을 피하고, 적절한 엔지니어링을 통해서 서비스 성장을 뒷받침하는 것이 중요

1. 서비스 운영 방식에 적합한 더 나은 아키텍쳐

개발자 관점의 필수 요소

  1. 단순히 복잡하고 최신 기술 도입이 아니라, 실제 서비스 운영 환경에 맞춰서 효율적인 솔루션을 제공하는 아키텍쳐
  2. 최선의 성능과 기능을 위해 복잡한 아키텍쳐를 선호할 수 있지만, 서비스의 실질적 요구와 비용, 유지보수성 등을 고려한 아키텍처 선택이 중요

오버엔지니어링, 언더엔지니어링

  • 오버엔지니어링(over-engineering) : 서비스 요구 사항에 비해 지나치게 복잡한 시스템을 설계하는 것을 의미한다. (유지보수 비용을 증가시키고 비효율성을 초래할 수 있다.)
  • 언더엔지니어링(under-engineering) : 서비스 확장 가능성을 충분히 고려하지 않고 최소한의 아키텍쳐만을 설계하는 경우 (확장될 때 발 빠르게 대응하지 못함)

사용자 관점의 병목 방지

  • 더 나은 아키텍쳐는 사용자 경험을 최우선으로 하여 bottleneck을 최소화하는 데 중점을 둔다.
  • 서비스 성장에 따라 문제가 발생할 수 있는 부분을 예측하고, 이를 대비한 설계를 통해 병목을 방지하는 것
  • 네트워크 트래픽 분산, 데이터베이스 최적화, 캐싱 전략등을 통해 성능 극대화하면서도 복잡해지지 않도록 해야 한다.

2. 일반적인 케이스에서 고려할 점

엔지니어링 관점에서

  • 안정적인 서비스를 운영하기 위해서 기본적으로 로드 밸런서, 캐싱, DB 복제 등을 통해 시스템 안정성을 확보해야 한다.
  • 성능 모니터링 도구와 자동화된 테스트 환경을 구축하여 실시간으로 성능을 추적하고, 장애나 성능 저하가 발생할 경우 즉각적으로 대응할 수 있는 시스템을 갖추는 것이 중요하다.

유연한 아키텍처의 필요성

  • 더 나운 아키텍쳐는 유연성이 핵심이다.
  • 모든 서비스가 복잡한 클러스터링이나 오토스케일링을 필요로 하지는 않으며, 서비스의 성장 단계와 요구사항에 따라 필요한 리소스를 점진적으로 추가하는 방식이 가장 효율적
  • 초기 단계에서는 간단하게, 서비스 확장되거나 트래픽이 증가할 때 점진적으로 인프라를 확장하는 방식이 비용 효율적

초기 단계에서

  • 과도한 오토스케일링, 클러스터링은 솔직히 필요 없음
  • 서비스 안정화 이후 리소스를 추가하는 방식으로 확장하는 것이 합리적

SLO(Service Level Objective) 측정 방법

  • SLO는 서비스 성능과 가용성 등 운영 목표를 정략적으로 측정하는 기준이다.
  • 따라서 정확하게 측정하는 방법이 중요하다.
  • SLO를 측정하기 위해서는 서비스가 정의한 목표에 대한 데이터를 지속적으로 수집하고 분석해야 한다.

SLO 측정 프로세스

  1. 측정할 SLO 항목 정의
    • 서비스에 중요한 성능 지표를 정의
    • SLO는 가용성, 응답시간, 오류율 드의 항목으로 나눌 수 있다.
  2. 메튜릭 수집 도구 사용
    • SLO 측정을 위해서 성능 데이터를 자동으로 수집하고 저장하는 도구가 필요하다. 일반적으로 모니터링 도구나 애플리케이션 성능 관리(APM) 도구를 사용
  3. SLO 성능 데이터 분석
    • 수집된 데이터를 기반으로, 정의된 SLO 기준에 맞춰 서비스가 목표를 달성하고 있는지 분석
  4. SLO 성과 대시보드 구축
    • Grafana, Kibana 같은 시각화 도구를 사용하여 SLO 성과를 모니터링하는 대시보드를 구축한다.
    • 실시간으로 SLO 목표 달성 여부를 확인하고, 이상 발생시 신속하게 대응할 수 있다.
  5. 경고 설정 및 자동화
    • SLO 준수하지 못할 경우 알림을 받을 수 있는 경고 시스템을 설정
  6. 주기적인 SLO 리뷰 및 조정
    • 서비스가 발전하거나 사용자 요구가 변화할 경우, SLO도 주기적으로 리뷰하고 조정해야 한다.

클라우드 시스템에서 보안 및 규정 준수

  1. 데이터 보호
  2. 규정 준수: 각국의 규정은 데이터 보호와 보안에 대한 강력한 요구사항을 규정한다. 클라우드 사용 기업은 GDPR, HIPAA 등을 준수해야 한다.
  3. 서비스의 신뢰성: 보안 사고는 기업의 신뢰성을 손상시킬 수 있다. 신뢰성의 문제다.