1 Web System Design

• 현대의 웹 시스템은 높은 가용성과 확장성이 요구됩니다.
• 수많은 사용자가 동시에 접속하고, 24시간 365일 중단 없는 서비스를 제공해야 하는 환경에서 시스템 설계는 매우 중요한 과제가 되었습니다.
• 이 글에서는 웹 시스템의 가용성을 높이고 확장성을 확보하기 위한 다양한 전략과 구체적인 구현 방법에 대해 알아보겠습니다.

2 가용성(Availability)

• 가용성이란 시스템이 서비스를 정상적으로 제공할 수 있는 상태를 말합니다.
• 항상 서비스를 이용할 수 있는 시스템을 가용성이 높은 시스템이라고 합니다.

2.1 서비스 다운 원인

• 광역 네트워크 장애
• 광역 전원 장애
• 하드웨어 장애
• 소프트웨어 장애
• 점검 기간
• 고부하에 따른 요청 타임아웃

2.2 여러 하위 시스템이 연결된 환경에서의 가용성

• 마이크로서비스와 같이 여러 서비스가 연계되어 동작하는 경우 연계 서비스가 다운되어 전체 서비스에 영향을 미칠 수 있습니다.
• 시스템 A의 가용성이 a%이고, 시스템 B의 가용성이 b%일 때, 두 시스템을 연계한 전체 시스템의 가용성은 a * b%입니다.
• 예를 들어 서로 독립적으로 99.99%의 가용성을 가진 5대의 시스템을 연동하면 전체 시스템의 가용성은 99.95%입니다.
  • 이는 연간 다운 타임이 4시간 23분 정도 됩니다.
  • 만약 한대만 95%인 경우 연간 다운 타임은 18일 정도가 됩니다.

2.3 높은 가용성을 가진 시스템 설계 방법

• 가용성을 높이기 위해서는 사용 불가능 시간을 최대한 발생시키지 않고 발생하더라도 최대한 짧게 만들어야 합니다.
• 다음과 같은 방법으로 가용성을 높일 수 있습니다.
  • 시스템을 이중화한다.
  • 시스템을 확장한다.

2.4 시스템 이중화

• 시스템 이중화는 단일 장애점(SPOF, Single Point of Failure)을 제거하기 위한 방법입니다.
  • SPOF는 단일 장애점으로 이 지점에 장애가 발생하면 전체 시스템이 다운되는 지점을 말합니다.
• 결국 시스템 이중화란 시스템의 일부분이 사용할 수 없게 되어도 다른 시스템을 이용하여 서비스를 계속 제공할 수 있도록 하는 것입니다.
• 여기서 중요한 점이 대체 시스템이 별도의 시스템이어야 한다는 것입니다.
  • 예를 들어 데이터 이중화를 위해 백업 데이터를 원본 서버에 저장하면 서버 장애시 원본 데이터도 백업 데이터도 사용할 수 없게 됩니다.
• 이중화 시스템은 네트워크 지연과 데이터 전송 능력을 감안하여 범위 내 지리적, 물리적으로 떨어진 장소에 구축하는 것이 좋습니다.
• AWS에서는 Multi-AZ라는 형태로 데이터 센터 레벨의 독립적인 시스템을 제공합니다.

2.4.1 데이터베이스 이중화

• 데이터베이스의 이중화는 기본적으로 어렵습니다.
• 데이터베이스 이중화의 경우 하드웨어뿐만 아니라 안에 저장된 데이터도 이중화해야 합니다.
• 데이터베이스 이중화는 아래의 방법으로 구현할 수 있습니다.
  1. 여러 대의 데이터베이스의 같은 데이터를 저장하고 참고한다.
  2. 한쪽의 데이터를 저장하고 자동으로 반대쪽 데이터를 동기화한다. 다운이 발생하면 다른 쪽의 데이터베이스를 사용한다.
• 1번의 경우 쓰기, 읽기 모두 응답 속도의 저하를 막을 수 없습니다.
• 2번의 경우 다운 발생 시 다른 한쪽을 사용할 수 있게 하는 패일오버 작업이 어렵지 않습니다.
  • 하지만 자동으로 데이터 동기화가 어렵습니다.
  • 동기 방식의 경우 동기화 처리 중 지연에 따른 성능 저하가 발생할 수 있습니다.
  • 비동기 방식의 데이터베이스 간의 데이터 불일치 문제가 발생할 수 있습니다.

2.5 시스템 확장

• 사용자의 요청이 많아 지금의 인프라로 요청을 받을 수 없다면 이 또한 서비스 다운과 같은 상태입니다.
• 따라서 부하가 많을 때도 사용자의 정상적인 서비스를 제공하기 위해서는 시스템을 확장을 통해 가용성을 높여야 합니다.
• 요규되는 시스템 성능에 따라 동적으로 서버 구성으 변경되고 시스템의 처리 능력을 최적할 할 수 있는 시스템을 확장 가능한 시스템이라고 합니다.
• 확장 가능한 시스템을 구축하는 방법은 3가지가 있습니다.
  • 스케일 업/다운을 한다.
  • 스케일 아웃/인을 한다.
  • 클라우드 사업자가 확장성을 보증하는 서비스를 사용한다.

2.5.1 스케일 업/다운

• 시스템의 리소스 처리 능력을 올리거나 내리는 방법을 말합니다.
• 예를 들어 서버의 CPU, 메모리, 디스크 등의 용량을 증가시키거나 감소시키는 것입니다.
• 장점:
  • 애플리케이션 및 미들웨어가 지원하지 않는 시스템이라도 성능을 올리고 내릴 수 있다.
  • 물리 메모리 부족 등으로 스왑이 발생하는 경우 간단히 대응할 수 있다.
  • 쉽게 네트워크 및 스토리지 성능을 올릴 수 있다.
  • 스케일 인/아웃이 어려운 데이터베이스 서버에서도 성능 확장을 할 수 있다.
  • 한 대뿐인 리소스라도 리소스가 여유 있다면 스케일 다운으로 인프라 비용을 절감할 수 있다.
  • 관리가 필요한 시스템 리소스 대수가 늘지않아 시스템 관리 비용이 증가하지 않는다.
• 단점:
  • CPU 병목을 처리하고 있던 경우에는 상위 인스턴스로 스케일 업해도 CPU 코어 자체의 성능은 향상되지 않고 코어의 수만 증가합니다.
    • 따라서 멀티 코어를 적절하게 사용하지 않는 애플리케이션에서는 성능 향상이 어렵다.
  • RDS에서는 성능이 비용과 비례하여 향상되지 않는 경우도 있습니다.
  • 제공되는 성능 제한이 정해져 있어 그 이상으로 성능을 올릴 수 없습니다.
  • 중간 지점에 있는 성능이 제공되지 않는 경우가 있습니다.
    • 예를 들어 2, 4, 8, 16배로 늘어나는 형태를 제공하여 3배나 5배 등의 성능을 제공하지 않는 경우가 있습니다.
  • 스케일 업/다운 시 일시적으로 다운 타임이 발생할 수 있습니다.

2.5.2 스케일 아웃/인

• 시스템 성능을 올리기 위해 시스템 리소스 수를 늘리는 것을 스케일 아웃, 반대로 리소스 수를 줄이는 것을 스케일 인이라고 한다.
• 장점:
  • 웹 서버로 보면 서버를 stateless로 구축하게 되어 구성이 간단해진다.
  • 이중화를 통해 서비스 전체의 가용성을 높일 수 있습니다.
  • 시스템 성능의 차이는 하드웨어 대수와 비례하는 경우가 많아 스케일 업과 비교하여 비용 대비 성능이 좋습니다.
  • 스케일 인/아웃 시 다운 타임이 발생하지 않는 경우가 많습니다.
• 단점:
  • 같은 "데이터베이스 이중화를 기본적으로 어렵다"에서 보듯 데이터베이스의 스케일 아웃/스케일 인은 설계 및 개발이 난이도가 높다.
  • 주어진 하드웨어를 적절하게 사용하기 위해서는 애플리케이션과 미들웨어에서 지원해야 하는 경우가 있다.
  • 대수가 늘어남에 따라 새로운 제약 사항과 문제가 있어날 수 있다.
  • 관리가 필요한 시스템 리소스 대수가 늘어나서 시스템 관리 비용이 증가하는 경우가 있다.

2.5.3 클라우드 사업자가 확장성을 보증하는 서비스를 사용한다

• 클라우드는 사업자가 제공하는 관리형 서비스 중에는 서비스 자체가 확장 가능을 제공하는 것도 있다.
• AWS에서는 다음과 같은 서비스가 있다. 각 서비스를 제공하는 리소스에는 접속할 수 있으며, 서비스로 기능을 이용하는 형태이다. 장점도 많아 적극적으로 활용하고 싶은 것들이다.
  • Route 53(DNS 제공 서비스)
  • CloudFront(CDN 제공 서비스)
  • Elastic Load Balancing(로드 밸런서 제공 서비스)
  • S3(스토리지 제공 서비스)
• 장점:
  • 각 서비스는 이중화되어 있고 사용자가 접접하지 않아도 되기 때문에 가용성이 높다.
  • 소프트웨어 점검은 클라우드 사업자 측에서 수행한다.
  • 사용 형태에 따라서 종량제 서비스가 많으면 저렴해진다.
• 단점:
  • 서비스 자체의 특성이 있고 그 특성을 공부해야 한다.
  • 사용 형태에 따라 비용이 높아질 수 있다.

3 온프레미스 시스템과 클라우드 시스템의 가용성 비교

3.1 온프레미스 시스템의 가용성

• 온프레미스 시스템은 자체적으로 하드웨어를 보유하고 운영하는 방식입니다.
• 장점:
  • 시스템에 대한 완전한 통제권을 가질 수 있습니다.
  • 데이터 보안과 규정 준수를 직접 관리할 수 있습니다.
  • 장기적으로는 초기 투자 비용을 상환할 수 있습니다.
  • 네트워크 지연이 적습니다.
• 단점:
  • 초기 구축 비용이 높습니다.
  • 하드웨어 유지보수와 업그레이드에 많은 시간과 비용이 필요합니다.
  • 확장성이 제한적입니다.
  • 재해 복구를 위한 별도의 시설이 필요합니다.
  • 24/7 운영을 위한 전문 인력이 필요합니다.

3.2 클라우드 시스템의 가용성

• 클라우드는 온프레미스 시스템과 반대되는 개념으로 내부에서 하드웨어를 관리하지 않고 클라우드 사업자 소유의 리소스를 시간 단위로 빌려 사용하는 형태를 말합니다.
• 장점:
  • 초기 투자 비용이 낮습니다.
  • 필요에 따라 즉시 확장/축소가 가능합니다.
  • 지리적 이중화가 용이합니다.
  • 관리형 서비스를 통해 운영 부담을 줄일 수 있습니다.
  • 최신 기술과 보안 업데이트를 자동으로 적용받을 수 있습니다.
• 단점:
  • 장기적으로는 비용이 증가할 수 있습니다.
  • 네트워크 지연이 발생할 수 있습니다.
  • 클라우드 서비스 제공업체에 대한 의존도가 높아집니다.
  • 데이터 주권과 규정 준수에 대한 추가 고려가 필요합니다.

3.3 클라우드 디자인 패턴

클라우드 디자인 패턴이란 여러 클라우드 서비스를 사용하여 고가용성/높은 확장성의 시스템을 보다 저렴하고 빠르게 구축하기 위한 모범 사례를 말합니다.

3.3.1 가용성을 위한 패턴

• 다중 가용 영역 배포 패턴
  • 여러 가용 영역에 시스템을 분산 배포하여 단일 데이터센터 장애에 대비
  • 로드 밸런서를 통한 트래픽 분산 처리
• 서킷 브레이커 패턴
  • 장애가 발생한 서비스로의 호출을 차단하여 연쇄 장애 방지
  • 빠른 실패(Fast Fail) 처리로 시스템 안정성 확보
• 헬스 엔드포인트 모니터링 패턴
  • 각 서비스의 상태를 주기적으로 확인
  • 이상 징후 발견 시 자동 복구 프로세스 시작

3.3.2 확장성을 위한 패턴

• 정적 콘텐츠 호스팅 패턴
  • 정적 콘텐츠를 CDN을 통해 제공
  • 원본 서버의 부하 감소 및 사용자 경험 개선
• 샤딩 패턴
  • 데이터를 여러 데이터베이스에 분산 저장
  • 데이터베이스 성능과 확장성 개선
• 캐시 사이드 패턴
  • 자주 사용되는 데이터를 캐시에 저장
  • 데이터베이스 부하 감소 및 응답 시간 개선

3.3.3 운영 효율성을 위한 패턴

• 불변 서버 패턴
  • 서버 구성을 변경하지 않고 새로운 서버로 교체
  • 배포 안정성 향상 및 롤백 용이성 확보
• 마이크로서비스 패턴
  • 시스템을 작은 단위의 서비스로 분리
  • 독립적인 배포와 확장 가능
• 서버리스 아키텍처 패턴
  • 관리가 필요한 서버를 최소화
  • 운영 부담 감소 및 자동 확장 기능 활용