확장 가능한 웹 아키텍처

확장 가능한 웹 아키텍처

확장성은 필요할 때 리소스를 추가하거나 제거함으로써 다양한 워크로드를 처리하는 시스템의 능력

사용자 기반이 늘어나고 트래픽이 증가하더라도 웹 애플리케이션이 계속해서 중단없이 효율적으로 작동함을 보장

확장성

시스템의 성장을 우아하게 다룰 수 있는 웹 아키텍처 능력

• 사용자, 트랜잭션, 요청 혹은 데이터가 늘어남에 따라 시스템에 그 성능을 유지하거나 개선

• 중단 없는 서비스를 제공

• 지속적으로 비용-대비-효과를 거둘 수 있음을 의미

• 선형적으로 확장될 수 있는 인프라스트럭처를 구축하는것을 의미

인프라스터럭처란?

어떤 시스템이나 조직이 원활하게 운영될 수 있도록 기반이 되는 구조물, 서비스, 기술 등을 의미

로드 밸런서

유입되는 트래픽을 여러 서버에 분산시켜 부하의 균형을 유지

• 로드밸런서는 모든 트래픽의 진입점 및 관리 역할을 함

• 클라이언트와 서버 클러스터 사이에 위치

• 개별 서버가 과도한 부하에 의해 오작동하는것을 방지

• 높은 트래픽이 몰리더라도 최적의 성능을 유지

• 트래픽을 효과적으로 분산시키기 위한 다양한 핵심 고려사항을 포함함

  • 알고리즘 선택: 로드 밸런싱 알고리즘(라운드 로빈, 최소 커넥션, IP 해시 등)

  • 헬스 체크: 정기적인 헬스 체크를 통해 서버가 작동하고 있음을 보장해야함

  • 자동 스케일링: 이상적으로 자동 스케일링 시스템을 사용해 매끄럽게 작동해야함

    • 아키텍처가 효율적으로 확장/축소됨을 보장해야함

캐싱

빈번하게 접근되는 데이터를 항상 접근할 수 있는 스토리지 위치에 일시적 저장해 데이터 로드 속도를 높이는 프로세스

• 원래 저장소(DB, 백엔드 서버) 위치에 접근할 때보다 빠르게 데이터에 접근할 수 있게함

• 브라우저 캐싱: 사용자가 방문했을 때 웹 사이트 리소스를 사용자 로컬 컴퓨터에 저장하여 이후 로딩타임을 줄임

• CDN 캐싱: 지역적으로 분산된 서버를 활용해 콘텐츠를 빠르게 전달

• 애플리케이션/데이터 캐싱: 일반적으로 질의되는 데이터를 Redis, Memcached 같은 인메모리 캐시에 저장

  • DB와 백엔드 시스템의 부하를 줄임

• 결과적으로 최종 사용자에 대한 보다 빠른 응답 시간으로 이어짐

• 각 요청을 처리하기 위해 필요한 프로세싱 파워를 줄임

  • 트래픽이 몰릴 때 아주 중요

캐싱 전략

• 이미지, CSS, JS 등 자주 변경되지 않는 정적 컨텐츠는 오랫동안 캐시 될 수 있음

• 동적 컨텐츠는 그 컨텐츠가 변경되는 빈도와 캐시 업데이트되기 전까지 견딜 수 있는 지연에 따라 보다 복잡한 전략 필요

CDN 컨텐츠 전달 네트워크

전 세계 여러 위치에 전략적으로 배치된 서버의 네트워크

• 가장 가까운 서버에서 정적 컨텐츠(HTML, CSS, JS, Assets)를 제공하는 목적으로 설계됨

• CDN은 지리적으로 사용자에게 가까운 위치에서 컨텐츠를 가져다주기 때문에 지연을 줄이고 전달 속도를 높임

  • 사용자 위치와 가장 가까운 '에지 로케이션'에 컨텐츠를 캐싱하는 방식으로 작동

• Amazon CloudFront

수평적 확장, 수직적 확장

정확한 사용자 수를 예측하고 확장을 위해 필요한 인프라스트럭처를 결정하는 것은 어려운 일

이를 위해 조직들은 대게 수평적 확장과 수직적 확장을 조합한다.

수평적 확장 (스케일 아웃)

• 애플리케이션 클라우드 아키텍처에 보다 많은 장비(인스턴스)를 추가하는 것,

• 유연성과 탄력성을 제공하여 웹 기반 아키텍처에서 선호

• 적합한 상황

  • 단일 실패 포인트로 인한 다운 타임을 피하고 싶을 때

  • 앱이 빈번하게 업그레이드 해야할 때

  • 벤더 락인을 피하고 여러 서비스를 탐색하고 싶을 때

    • 벤더락인이란 특정 기업의 제품이나 서비스에 종속되어 다른 벤더로 쉽게 전환하지 못하는 상황

  • 여러 서비스를 사용함으로써 시스템 탄력성을 개선하고 싶을 때

수직적 확장 (스케일 업)

• 한 단위의 리소스를 최대화해서 증가하는 부하를 처리하는 것

• 새로운 서버를 설정하기 위한 복잡성이 요구되지 않기 때문에 수평적 확장보다 쉽고 빠름

• 한 대의 서버를 물리적으로 업그레이드하는데 한계가 있고, 여전히 업그레이드한 서버에도 다운타임 발생 가능

• 적합한 상황

  • 운용 비용을 줄인 단순 아키텍처가 필요할 때

  • 낮은 전력을 소비하면서 확장할 수 있는 시스템이 필요할 때

  • 낮은 라이선싱 비용으로 쉽게 설치 및 확장할 수 있는 시스템이 필요할 때

  • 애플리케이션 호환성을 유지하고 싶을 때

마이크로 서비스

앱을 작고 독립적으로 배포할 수 있는 서비스로 분해하는 아키텍처 접근법

• 분해된 각 서비스를 독립적으로 확장 및 관리할 수 있다.

• 앱 전체를 확장하는 것보다 비용 대비 효과가 뛰어나고 덜 복잡함

• 서비스 통합과 관리라는 관점에서는 복잡성을 가져다줌

• 서비스 디스커버리, 로드 밸런싱, 실패시 복구를 위한 강건한 인프라스트럭처를 요구할 수 있다.

  • 쿠버네티스, 도커같은 도구 및 클라우드 기반 서비스들은 오케스트레이션, 컨테이너화, 서비스 디스커버리 같은 기능을 제공하여 복잡성을 관리함

서비스 디스커버리란?

• 분산 시스템에서 서비스들이 서로의 위치(IP, 포트 등)를 자동으로 찾을 수 있도록 도와주는 메커니즘

• 컨테이너나 마이크로서비스 환경에서 서비스 위치가 동적으로 변경되기 때문에 고정된 방식으로 관리하기 어려움

확장 가능한 애플리케이션 특징

실제 확장가능한 시스템은 다른 요소들이 응집적이고 효율적으로 통합해 성능 저하나 비용 초과 없이 증가하는 요청에 반응할 수 있음을 보장한다.

• 전형적인 확장 가능한 웹 애플리케이션 아키텍처는 4개의 기본 계층(웹 서버, DB, 로드 밸런서, 공유파일 서버)로 구성된다.

• 각 계층은 독립적으로 확장 가능

  • DB 계층이 제일 확장하기 어려운 계층

  • 효율적인 DB 확장을 위한 접근법은 마스터(쓰기,읽기) - 슬레이브(읽기)

도커

컨테이너 안에서 애플리케이션의 생성, 배포, 실행 프로세스를 단순화함

• 컨테이너는 애플리케이션과 그 의존성을 함께 패키징함

• 모든 환경에서 일관성 있게 실행됨을 보장함

• 쉽게 복잡한 웹 애플리케이션을 구축하고 확장하도록 도움

도커 장점

• 이식성: 다양한 환경에서 일관성 있게 실행함

• 격리: 컨테이너는 애플리케이션과 그 의존성을 캡슐화해서 충돌을 최소화하고 보안을 개선

• 리소스 효율: 컨테이너는 호스트 운영체제의 커널을 공유, 가상머신보다 더 적은 리소스를 소비함

• 버전관리 및 컴포넌트 재사용: 도커 이미지는 버전 관리와 공유를 쉽게 하여 코드 재사용과 단순 앱 관리를 가능케함

도커 단점

• 학습 곡선: 새로운 개념과 명령어를 학습해야함

• 제한된 윈도우 지원: 윈도우 컨테이너를 지원하지만 리눅스 컨테이너에 비해 기능 셋이 충실하지 않음

• 보안 우려: 루트 권한으로 컨테이너를 실행하거나, 오래된 이미지를 사용하면 앱 보안 리스크에 노출 가능

쿠버네티스

컨테이너 오케스트레이션 플랫폼

컨테이너화한 애플리케이션의 배포, 확장, 관리를 자동화함

• 확장성: 컨테이너화한 애플리케이션의 관리와 확장을 단순화 및 서드파티 플러그인 제공

• 높은 가용성: 실패한 컨테이너를 자동으로 찾아 대체

• 로드 밸런싱과 서비스 디스커버리: 내장 로드 밸런싱과 서비스 디스커버리 기능 제공

• 롤링 업데이트와 롤백: 최소한의 다운타임으로 매끄러운 앱 업데이트와 롤백 지원