웹 시스템 설계 방법

:아마존 웹 서비스 부하테스트 입문

 

내구성

• 데이터의 손실이 발생하지 않는다는 것
  • cf. 시스템이나 제품이 오랜 시간 동안 사용되거나 다양한 조건에 노출되어도 본래의 성능과 기능을 유지할 수 있는 능력
• e.g. 내구성 99.99% → 데이터 저장 후 1년 후에 데이터 손실 없이 저장한 데이터를 사용할 수 있는 확률

 

가용성

• 시스템이 서비스를 정상적으로 제공할 수 있는 상태
• e.g. 가용성 99.99% → 99.99% 시간을 정상적으로 이용 가능한 시스템
• 가용성 높이기 → 서비스 사용 불가능 시간을 최대한 발생시키지 않게 하며 발생하더라도 서비스 사용 불가능 시간을 짧게 만들기
• 이러한 다운 타임을 줄이는 데 필요한 것
  • 시스템 이중화
  • 시스템 확장

 

시스템 이중화

• 단일 장애점을 없애는 방법 → 시스템의 일부분을 사용할 수 없게 되어도 다른 시스템을 이용하여 서비스를 계속 제공하는 것
  • 단일 장애점: 그 지점에 장애가 발생하면 서비스를 제공할 수 없는 지점
• ★ 이중화된 대체 시스템은 독립된 별도의 시스템이어야 함 ★
  • 네트워크 지연과 데이터 전송 능력이 허락되는 범위 내에서 지리적, 물리적으로 떨어진 장소에 설치 → 천재지변으로 발생하는 정전이나 네트워크 장애를 대비
• AWS의 경우 Multi-AZ라는 형태로 데이터 센터 레벨의 독립적인 시스템을 사용하는 경우가 많음
• cf. 리던던시(Redundancy): 시스템이나 프로세스에서 중요한 요소를 백업하거나 중복시켜 안정성과 신뢰성을 향상시키는 것

 

데이터베이스 이중화의 어려움

• 여러 대의 데이터베이스에 같은 데이터를 저장하고 참고할 경우
  • 쓰기, 읽기 모두 응답 속도의 저하를 막을 수 없으며 데이터가 맞지 않을 때는 어떻게 복구할지에 대한 문제 발생
• 한쪽의 데이터를 저장하고 자동으로 반대쪽 데이터를 동기화할 경우 (다운이 발생했을 때는 다른 한쪽의 데이터베이스를 이용)
  • 다운이 발생했을 때 한쪽을 사용할 수 있게 하는 Fail Over 작업이 어렵진 않지만 자동으로 데이터 동기화가 어려움
    • Sync 방식 → 동기화 중 처리 지연에 따른 성능 저하 발생 가능
    • Async 방식 → 데이터베이스 간 데이터 무결성 문제 발생 가능

 

시스템 확장

• 확장 가능한 시스템: 요구되는 시스템 성능에 따라 동적으로 서버 구성이 변경되고 시스템의 처리 능력을 최적화할 수 있는 시스템
• 확장 가능한 시스템을 구축하는 방법
  • 스케일 업/다운
  • 스케일 아웃/인
  • 클라우드 사업자가 확장성을 보증하는 서비스를 사용

 

스케일 업/다운

• 시스템 성능을 높이기 위해 병목이 되는 부분의 시스템 리소스를 보다 높/낮은 성능으로 변경하는 것
• e.g. 인스턴스 타입 변경
• 장점
  • 애플리케이션 및 미들웨어가 지원하지 않는 시스템이라도 성능을 올리고 내릴 수 있음
  • 물리 메모리 부족 등으로 스왑이 발생하는 경우에도 간단히 대응 가능
  • 쉽게 네트워크 및 스토리지 성능을 올릴 수 있음
  • 관리가 필요한 시스템 리소스 대수가 늘어나지 않아 시스템 관리 비용이 증가하지 않음
• 단점
  • CPU 병목을 처리하고 있던 경우에는 상위 인스턴스 타입으로 스케일 업해도 CPU 코어 자체의 성능은 향상되지 않고 CPU 코어 수만 증가함 → 멀티 코어를 적절하게 사용하지 않는 애플리케이션은 효과를 얻을 수 없음
  • 제공되는 성능 제한이 정해져 있어 그 이상으로 성능을 올릴 수 없는 경우가 발생
  • 중간 지점에 있는 성능이 제공되지 않는 경우 e.g. 성능과 비용이 2배 → 4배 → 8배 → 16배로 늘어나는 형태로 제공되어 3배나 5배 등의 성능으로 올릴 수 없음
  • 일시적으로 다운 타임 발생 → 가용성 저하

 

스케일 아웃/인

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

 

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

• e.g. Route53(DNS 제공 서비스), CloudFront(CDN 제공 서비스), Elastic Load Balancing(로드 밸런서 제공 서비스), S3(스토리지 제공 서비스)
• 장점
  • 각 서비스는 이중화되어 있고 사용자가 점검하지 않아도 되기 때문에 가용성이 높음
  • 소프트웨어 점검을 클라우드 사업자 쪽에서 수행함
  • 사용 형태에 따라서 종량제 서비스가 많으면 저렴해짐
• 단점
  • 서비스 자체의 특성이 있고 그 특성을 공부해야 함
  • 사용 형태에 따라 비용이 높아질 수 있음

 

클라우드에서의 시스템 구축

• 클라우드: 클라우드 사업자 소유의 리소스를 시간 단위로 빌려 사용하는 시스템
• 장점
  • 초기 비용 저렴
  • 종량제 과금 정책을 많이 시행하고 있어 사용한 만큼 지불
  • 서버 리소스 추가 빠름 → 높은 확장성
  • 서버를 모두 가상화하여 서버 복제 등의 작업 간단
  • 서비스 사업자가 보안 패치를 지원하고 점검 서비스도 대부분 제공
  • 여러 데이터 센터를 사용하여 데이터 센터 레벨의 장애 대응 가능
• 단점
  • 종량 과금 서비스가 많아 사용 전에는 비용 산정 어려움
  • 서버가 가상화되어 있어 물리 장비와 달리 성능 떨어질 때 있음
  • 관리형 서비스는 클라우드 사업자가 제공하는 범위 내에서만 설정할 수 있어 유연한 구성이 어려움

 

클라우드 디자인 패턴을 사용한 고가용성/높은 확장성의 시스템 구축

• EC2 인스턴스를 이요한 동적 콘텐츠 배포
  • Route 53, ELB, EC2, Auto Scaling Group
• S3를 이용한 정적 콘텐츠 배포
  • Route 53, S3, CloudFront
• 동적 콘텐츠와 정적 콘텐츠
• 서버리스 아키텍처를 이용한 동적 웹 서비스 구축
  • Route 53, API Gateway, Lamda
• RDS를 이용한 RDB 구축
  • 이중화를 지원하지 않는 제품도 Multi-AZ 옵션을 사용하여 간단하게 이중화 구성 가능
    • cf. 이중화: 여러 가용 영역에 인스턴스를 복제하거나 배포하는 것
  • 마스터 DB 확장 불가능 → 인스턴스 타입 변경으로 부하 대응 → 인스턴스 정지 발생 → Multi-AZ를 사용하면 인스턴스 타입 변경이 순차적으로 이루어지고 서비스 다운 타입을 최소화할 수 있음
  • 참조계 서버 확장 필요 시 ReadReplica를 추가하여 확장 가능