[SIMFORM] AWS에서 확장 가능한 애플리케이션을 구축하고 싶으신가요?

간단 요약: 애플리케이션의 확장성은 기능과 사용자 인터페이스만큼이나 중요합니다. 특히 애플리케이션이 미래에 100만 명 이상의 사용자를 지원해야 할 경우 더욱 중요합니다. 이 블로그에서는 AWS에서 애플리케이션을 최대 100만 명의 사용자로 확장하는 방법을 배울 수 있습니다.

AWS에서 최대 100만 명의 사용자를 지원할 수 있는 확장 가능한 애플리케이션 구축 방법

웹 애플리케이션을 개발하고 몇몇 고객을 확보했다고 가정해봅시다. 피드백과 제안을 반영해 완성된 제품을 준비했습니다. 이제 마케팅 팀이 신규 고객을 확보하기 위해 Product Hunt에 애플리케이션을 공유합니다. 갑자기 수천 명의 방문자가 애플리케이션을 사용하기 시작하고, 어느 순간 사용이 불가능한 상황에 이르게 됩니다.

애플리케이션을 테스트했는데 정상적으로 작동합니다. 그런데 무슨 일이 벌어진 걸까요?

“이것은 버그가 아니라 확장성 문제입니다. 클라우드 아키텍처가 증가하는 부하를 처리하도록 설계되지 않았습니다.”

많은 기업들이 보통 기능에 집중하고 확장성에는 덜 신경 쓰는 경우를 종종 봤습니다. 회복력 있고 확장 가능한 애플리케이션을 만드는 것은 애플리케이션 아키텍처의 필수 요소입니다. 이 블로그에서는 증가하는 부하를 처리할 수 있는 확장 가능한 웹 애플리케이션 아키텍처를 구축하는 방법을 배울 수 있습니다.

Simform은 최고의 클라우드 앱 개발 서비스를 제공하며, 선도적인 클라우드 제공업체와 협력하여 인증된 개발자로 구성된 뛰어난 팀을 보유하고 있습니다. 지능형 클라우드 기반 솔루션을 구축하려면 클라우드 전문가와 상담하세요!

확장 가능한 애플리케이션이란?

확장성이란 시스템이 증가하는 수요(예: 더 큰 데이터 세트, 높은 요청률, 크기와 속도의 결합 등)에서도 합리적인 성능을 제공할 수 있는 능력을 의미합니다. 이는 1명의 사용자든 100만 명의 사용자든 문제없이 작동해야 하며, 트래픽 급증 상황도 자동으로 처리할 수 있어야 합니다. 필요한 경우에만 리소스를 추가하거나 제거함으로써, 확장 가능한 애플리케이션은 수요를 충족시키기 위해 필요한 리소스만 소비합니다.

클라우드 컴퓨팅에서 확장성을 논할 때, 종종 두 가지 주요 확장 방식, 즉 수직 확장(Vertical Scaling)과 수평 확장(Horizontal Scaling)에 대해 듣게 됩니다. 이 두 용어를 자세히 살펴보겠습니다.

수직 확장 (Scaling Up)

수직 확장 또는 확장 업(Scaling Up)은 단일 유닛의 리소스를 최대화하여 증가하는 부하를 처리할 수 있는 능력을 확장하는 것을 의미합니다. 하드웨어 측면에서는 서버를 실행하는 물리적 기계에 처리 능력과 메모리를 추가하는 것이 포함됩니다. 소프트웨어 측면에서는 알고리즘 및 애플리케이션 코드를 최적화하는 것이 포함될 수 있습니다.

수평 확장 (Scaling Out)

수평 확장 또는 확장 아웃(Scaling Out)은 애플리케이션의 클라우드 아키텍처에 유닛을 추가하여 리소스를 증가시키는 것을 의미합니다. 이는 더 큰 용량의 단일 유닛을 추가하는 대신, 더 작은 용량의 유닛을 여러 개 추가하는 것을 의미합니다. 이렇게 하면 요청이 여러 유닛에 분산되어 단일 머신에 과도한 부하가 걸리는 것을 줄일 수 있습니다.

확장 가능한 웹 아키텍처

수평 확장이든 수직 확장이든, 확장 가능한 웹 아키텍처는 필요한 기반이 될 것입니다. 확장 가능한 아키텍처는 웹 애플리케이션이 사용자 수요에 따라 적응하고 최고의 성능을 제공할 수 있도록 합니다.

모놀리식 아키텍처의 모든 구성 요소는 밀접하게 결합되어 있습니다. 따라서 여러 계층 중 하나라도 실패하면 전체 애플리케이션이 실패할 수 있습니다. 반면, 확장 가능한 웹 아키텍처는 서로 독립적이고 경량 메커니즘으로 상호작용하는 모듈들의 느슨한 결합 구조가 필요합니다.

확장 가능한 웹 아키텍처의 전형적인 예는 LAMP(Linux, Apache, MySQL, PHP) 스택을 사용하는 것입니다. 이는 확장성, 고가용성, 느슨한 결합 서비스(내결함성), 분산 컴퓨팅과 같은 중요한 이점을 제공합니다.

확장성(Scalability): LAMP와 같은 확장 가능한 웹 아키텍처는 수평 확장을 가능하게 합니다. 분산 시스템은 노드를 추가하거나 제거하여 확장 요구에 따라 리소스 풀을 빠르게 확장하거나 축소할 수 있습니다.

고가용성(High Availability): 더 높은 가동 시간과 더 낮은 다운타임은 모든 비즈니스에서 필수적입니다. 특히 전자상거래 비즈니스의 경우, 한 시간의 다운타임은 막대한 수익 손실로 이어질 수 있습니다. 확장 가능한 웹 아키텍처는 주요 구성 요소의 중복성을 고려하고, 부분 시스템 실패에도 빠른 재난 복구를 통해 더 높은 가용성을 보장해야 합니다.

내결함성(Fault-tolerant): 단일 장애 지점이 없어야 하며, 구성 요소가 실패하더라도 시스템은 효율적으로 실행될 수 있어야 합니다.

독립 아키텍처(Share Nothing): 각 구성 요소가 독립적이며 특정 기능을 수행할 수 있는 아키텍처 패턴입니다. 이는 다음과 같은 웹 애플리케이션의 다양한 계층에서 구현할 수 있습니다.

• 데이터베이스 계층: 파티셔닝 또는 샤딩을 통해 구현
• 캐시 계층: Memcache 클라이언트 측 파티셔닝을 통해 애플리케이션 데이터를 일부는 캐시에 저장하고 나머지는 RDBMS(Relational DataBase Management Systems)로 관리
• 컴퓨팅 계층: 작업 대기열을 통해 최소 실행 조건이 충족될 때까지 작업을 대기열에 유지

일반적인 확장 가능한 웹 아키텍처는 네 가지 주요 계층으로 구성됩니다.

1. 웹 서버(Web servers)
2. 데이터베이스 서버(Database servers)
3. 로드 밸런서(Load balancers)
4. 공유 파일 서버(Shared file servers)

이러한 각 계층은 독립적으로 확장되며, 데이터베이스 계층이 가장 확장하기 어렵습니다. 마스터-슬레이브 복제 방식을 사용하는 것은 데이터베이스를 효율적으로 확장하는 훌륭한 방법입니다. 각 마스터 노드는 데이터 읽기/쓰기 기능을 가진 강력한 머신이며, 슬레이브 노드는 데이터 읽기만 가능합니다. 동시에 로드 밸런서는 마스터 노드 간의 부하 분배를 보장합니다.

최적의 성능을 위해 캐싱 계층 구조가 중요합니다. 여기서 애플리케이션의 로컬 캐시는 부트스트래핑과 같은 일반적인 작업을 처리할 수 있고, 애플리케이션 서버 캐시는 복잡하고 큰 쿼리를 처리할 수 있습니다.

또한 작업 대기열은 복잡한 데이터 처리를 위해 높은 CPU 작업을 제어하는 데 훌륭한 방법입니다. 마지막으로, 정적 공개 콘텐츠를 위해 콘텐츠 배포 네트워크(CDN)를 활용하고, 설계 시스템은 내결함성을 가져야 합니다.

마찬가지로 클라우드 기반 확장 아키텍처와 관련해서는 Amazon Web Services가 필요한 모든 것을 제공합니다. 애플리케이션 확장성뿐만 아니라, AWS는 기능을 향상시키는 다양한 서비스 통합도 제공합니다.

앞서 언급했듯이 확장 가능한 애플리케이션은 밀접하게 결합된 구성 요소 스택이 아니라, 독립적으로 확장 가능한 다양한 계층이 필요합니다. 이제 이러한 확장 가능한 웹 아키텍처를 활용한 몇 가지 성공적인 애플리케이션 사례를 살펴보겠습니다.

확장 가능한 주요 애플리케이션 사례:

• Evernote: 새로운 기능 개발 속도를 높이고 500만 개의 노트와 120억 개의 파일 첨부를 지원하기 위해 마이크로서비스 아키텍처를 사용하는 메모 애플리케이션
• Bitly: 200억 클릭을 매달 지원하기 위해 구성 요소의 장애를 격리하고 분산 구조를 생성하는 마이크로서비스 아키텍처를 활용하는 URL 단축 서비스
• Dropbox: 분산 데이터베이스 서비스를 관리하기 위해 자체 클러스터를 사용하는 Atlas와 같은 오케스트레이션 서비스를 활용하며, 15분마다 100만 개 이상의 파일을 저장
• Slack: 1,200만 명 이상의 일일 활성 사용자를 위해 실시간 커뮤니케이션, 영상 통화, 화면 공유를 가능하게 하는 마이크로서비스를 활용

확장 가능한 웹 애플리케이션 구축 시 고려해야 할 과제

확장 가능한 웹 애플리케이션을 구축할 때는 프레임워크 선택, 테스트, 배포, 인프라 요구 사항 등 여러 도전 과제가 있습니다.

적합한 프레임워크

확장 가능한 웹 애플리케이션을 구축하기 위해 적절한 프레임워크를 선택하는 것은 도전 과제가 될 수 있습니다. 먼저 시스템 아키텍처를 애플리케이션 기능 및 기술 스택과 함께 분석해야 합니다. 그런 다음 특정 프레임워크가 모든 요구 사항을 충족하는지 결정할 수 있습니다.

Django와 Ruby on Rails 같은 프레임워크는 확장 가능한 웹 애플리케이션을 구축하기에 좋은 옵션입니다. 그러나 Ruby on Rails와 Node.js를 비교하면, 후자는 복잡한 비동기 쿼리를 실행하는 데 뛰어난 능력을 제공합니다. 시도해 볼 수 있는 다른 프레임워크로는 Asp.net, Angular JS, React.js, Laravel 등이 있습니다.

테스트 요구 사항

테스트는 전체 웹 애플리케이션 개발 수명 주기의 필수적인 부분입니다. 특히 부하 테스트 시뮬레이션은 애플리케이션의 확장 기능을 이해할 수 있게 해주므로 매우 중요합니다.

또한 부하 테스트는 응답 시간, 처리량, 리소스 소비를 측정하여 애플리케이션의 한계점을 파악할 수 있게 합니다. 그러나 부하 테스트가 기반을 두고 있는 프로토콜의 복잡성으로 인해 실행이 어려울 수 있습니다. 예를 들어, HTTP 기반 부하 테스트를 수행하는 경우 쿠키나 세션 ID와 같은 여러 동적 매개변수를 고려해야 합니다.

그 외에도 애플리케이션 확장성을 측정하고 향상시키기 위한 여러 성능 테스트 요구 사항이 있습니다. 운영 체제와의 호환성 테스트에서부터 실시간 오류 감지까지, 다양한 조건을 위한 테스트를 생성하고 다수 사용자를 시뮬레이션하는 애플리케이션 사용 경험도 고려해야 합니다.

한 가지 가능한 해결책은 반복 개발 접근 방식을 활용하는 테스트 주도 개발(TDD)을 선택하는 것입니다. 이는 웹 애플리케이션 요구 사항을 완전히 개발하기 전에 테스트 케이스로 전환하는 소프트웨어 개발 접근 방식입니다. 이를 통해 개발자는 다양한 테스트 케이스를 사용하고 반복 과정을 통해 웹 애플리케이션 개발을 추적할 수 있습니다.

TDD의 "테스트 우선(Test First)" 접근 방식 덕분에, 테스트 코드로 사전 정의된 애플리케이션 기능에 대해 신속하게 피드백을 받을 수 있습니다. 따라서 애플리케이션을 확장할 때 특정 기능이 예상대로 작동하지 않으면, 다음 반복 이전에 코드를 빠르게 수정할 수 있습니다.

배포 과제

여러 서비스가 상호작용하는 배포는 신뢰할 수 있는 통신 메커니즘이 필요하며, 이는 도전 과제가 됩니다. 이러한 이유로, 통신 메커니즘과 오케스트레이션 서비스를 동시에 테스트하여 중단을 최소화해야 합니다. 이를 효율적으로 수행하지 못하면 병렬 개발 및 테스트 활동으로 인해 개발 프로세스가 지연될 수 있습니다.

가능한 해결책 중 하나는 CI/CD 시스템을 사용하는 것입니다. 이러한 시스템은 테스트 및 배포 활동에 대해 걱정할 필요 없이 기능을 구축할 수 있도록 합니다.

인프라 요구 사항

정확한 사용자 수를 예측하는 것은 어렵습니다. 따라서 이에 따라 확장할 수 있는 실제 인프라 요구 사항을 측정하는 것도 어려운 일입니다. 그러나 상황에 따라 수평 확장과 수직 확장이라는 두 가지 유형의 확장을 사용할 수 있습니다. 두 방식 모두 고유한 사용 사례를 가지고 있으며, 아래에서 논의됩니다.

수평 확장을 선택할 수 있는 경우:

• 단일 장애 지점으로 인해 다운타임이 발생할 위험을 감수할 수 없는 경우
• 애플리케이션 업그레이드 범위가 큰 경우
• 특정 벤더에 종속되지 않고 다양한 벤더 서비스를 탐색하고 싶은 경우
• 여러 서비스를 사용하여 시스템 회복력을 높이고 싶은 경우

한편, 수직 확장을 선택할 수 있는 경우:

• 운영 비용이 감소된 간단한 아키텍처가 필요한 경우
• 전력을 많이 소비하지 않고 확장할 수 있는 시스템이 필요한 경우
• 설치가 쉽고 확장 가능한 시스템이면서 라이선스 비용이 낮은 시스템이 필요한 경우
• 애플리케이션 호환성을 유지하고 싶은 경우

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

확장성은 어떤 모습일까요? 애플리케이션이 확장 가능하다고 간주되기 위해서는 몇 가지 영역에서 뛰어나야 합니다.

성능

가장 중요한 것은 애플리케이션이 낮은 대기 시간으로 스트레스 상황에서도 잘 작동해야 한다는 점입니다. 웹사이트 속도는 사용량, 사용자 만족도, 검색 엔진 순위에 영향을 미치며, 이는 수익과 유지율에 직접적으로 상관관계가 있습니다. 따라서 빠른 응답 시간과 낮은 대기 시간을 최적화하는 확장 가능한 웹 애플리케이션 아키텍처를 만드는 것이 중요합니다.

가용성 및 신뢰성

이 두 가지는 밀접하게 관련되어 있으며 모두 필수적입니다. 확장 가능한 애플리케이션은 스트레스 상황에서도 거의 다운되지 않아야 합니다. 요청 시 데이터를 안정적으로 제공하고 저장된 정보를 잃지 않아야 합니다.

관리 가능성

클라우드 아키텍처의 관리 가능성은 운영 확장성, 즉 유지보수 및 업데이트와 직결됩니다. 관리 가능성을 위해 고려해야 할 사항은 문제가 발생했을 때 이를 진단하고 이해하는 용이성, 업데이트나 수정의 용이성, 시스템 운영의 간단함입니다. (즉, 실패나 예외 없이 지속적으로 작동하는가?)

비용

확장 가능한 애플리케이션은 구축, 유지보수, 확장 비용이 과도하게 비쌀 필요가 없습니다. 개발 중 확장성을 계획하면, 수요가 증가함에 따라 과도한 비용 없이 애플리케이션을 확장할 수 있습니다.

고성능 웹 애플리케이션 아키텍처를 구축할 때 클라우드 공급자를 선택할 수 있는 다양한 옵션이 있습니다. 주요 클라우드 컴퓨팅 벤더인 AWS, Microsoft Azure, Google Cloud는 각각의 강점과 약점을 가지고 있으며, 다양한 사용 사례에 이상적입니다.

이 블로그에서는 확장 가능한 웹 애플리케이션을 구축하는 방법을 보여주기 위해 AWS를 선택했습니다. AWS는 잘 알려진 Amazon의 자회사로, 다양한 요구 사항에 맞는 클라우드 중심 서비스를 제공합니다. AWS는 클라우드 컴퓨팅 시장에서 33%로 가장 높은 점유율을 차지하고 있습니다. AWS는 각 서비스에 대한 훌륭한 문서, 유용한 가이드 및 백서, 일반 애플리케이션을 위한 참고 아키텍처를 제공합니다.

사용자가 1명에서 100만 명으로 증가하는 확장 가능한 애플리케이션 구축 단계

1명 사용자

클라우드 아키텍처 초기 설정

로컬 호스트에서 애플리케이션을 사용하는 유일한 사용자입니다. 시작은 단순히 애플리케이션을 단일 상자에 배포하는 것만큼 간단할 수 있습니다. 다음의 AWS 서비스를 사용하여 시작할 수 있습니다.

• Amazon Machine Images (AMI)
• Amazon EC2
• Amazon VPC
• Amazon Route 53

Amazon Machine Images (AMI)

Amazon Machine Image(AMI)는 클라우드에서 가상 서버(인스턴스)를 시작하는 데 필요한 정보를 제공합니다. 인스턴스를 시작할 때 AMI를 지정할 수 있습니다. AMI에는 인스턴스의 루트 볼륨 템플릿, AMI를 사용하여 인스턴스를 시작할 수 있는 AWS 계정을 제어하는 시작 권한, 인스턴스를 시작할 때 연결할 볼륨을 지정하는 블록 디바이스 매핑이 포함됩니다.

Amazon Elastic Compute Cloud (Amazon EC2)

Amazon Elastic Compute Cloud는 AWS 클라우드에서 확장 가능한 컴퓨팅 용량을 제공합니다. 이를 통해 하드웨어 초기 비용을 제거하고 애플리케이션 개발 및 배포를 더 빠르게 할 수 있습니다.

Amazon Virtual Private Cloud (Amazon VPC)

Amazon Virtual Private Cloud는 가상 네트워크에서 AWS 리소스를 시작할 수 있는 프로비전을 제공합니다. 이는 IP 주소 범위 선택, 서브넷 생성, 라우팅 테이블 및 네트워크 게이트웨이 구성 등 가상 네트워킹 환경에 대한 완전한 제어를 제공합니다.

Amazon Route 53

Amazon Route 53은 고가용성과 확장성을 갖춘 클라우드 DNS 웹 서비스입니다. Amazon Route 53은 AWS에서 실행 중인 인프라(예: Amazon EC2 인스턴스, Elastic Load Balancing 로드 밸런서 또는 Amazon S3 버킷)로 사용자 요청을 효과적으로 연결합니다.

이 단계에서는 더 큰 상자가 필요합니다. 이를 위해 수직 확장이라고 하는 더 큰 인스턴스 유형을 선택할 수 있습니다. 초기 단계에서는 수직 확장이 충분하지만 무한정 확장할 수는 없습니다. 결국 한계에 도달하게 되며, 이 방식은 장애 조치와 중복성을 해결하지 못합니다.

사용자 > 10명

다수의 호스트 생성 및 데이터베이스 선택

사용자가 증가하고 데이터를 생성하기 시작하면 데이터베이스를 선택해야 합니다. SQL 데이터베이스로 시작하는 것이 권장되며, 그 이유는 다음과 같습니다.

• 검증된 기술 및 광범위한 커뮤니티 지원
• 최신 도구 지원
• 초기 1,000만 명의 사용자를 감당하는 데 SQL DB가 충분함

단, 사용자가 다양한 형태로 대량의 데이터를 생성할 경우 NoSQL 데이터베이스를 선택할 수 있습니다.

이 단계에서는 모든 것이 단일 버킷에 포함됩니다. 이러한 아키텍처는 확장이 어렵고 장기적으로 관리가 복잡합니다. 따라서 애플리케이션에서 데이터베이스를 분리하는 다중 계층 아키텍처를 도입해야 합니다.

사용자 > 100명

Amazon RDS에 데이터베이스 저장으로 운영 간소화

사용자가 100명으로 증가하면 첫 번째로 해야 할 일은 데이터베이스 배포입니다. AWS에서 데이터베이스를 배포하는 데는 두 가지 주요 방향이 있습니다. 첫 번째 옵션은 Amazon Relational Database Service(Amazon RDS) 또는 Amazon DynamoDB와 같은 관리형 데이터베이스 서비스를 사용하는 것입니다. 두 번째는 Amazon EC2에서 자체 데이터베이스 소프트웨어를 호스팅하는 것입니다.

• Amazon RDS
• Amazon DynamoDB

Amazon RDS

Amazon Relational Database Service(Amazon RDS)는 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있게 해줍니다. Amazon RDS는 Amazon Aurora, Oracle, Microsoft SQL Server, PostgreSQL, MySQL 및 MariaDB를 포함한 6가지 친숙한 데이터베이스 엔진을 제공합니다.

사용자 > 1000명

가용성 향상을 위해 다중 가용 영역 생성

현재 아키텍처로는 가용성 문제가 발생할 수 있습니다. 웹 애플리케이션 호스트가 실패하면 애플리케이션이 다운될 수 있습니다. 따라서 RDS에 슬레이브 데이터베이스를 두고 다른 가용 영역(AZ)에 또 다른 웹 인스턴스를 배치해야 합니다.

• Elastic Load Balancer (ELB)
• 다중 AZ 배포

이 단계에서는 Elastic Load Balancer(ELB)를 사용하여 두 AZ에 있는 두 웹 호스트 인스턴스 간의 부하를 분산해야 합니다.

Elastic Load Balancer (ELB)

ELB는 들어오는 애플리케이션 트래픽을 EC2 인스턴스에 분산합니다. 수평적으로 확장되며 대역폭 제한이 없고, SSL 종료를 지원하며, 헬스 체크를 수행하여 정상적인 인스턴스에만 트래픽을 전달합니다.

이 구성에서는 ELB 뒤에 2개의 인스턴스가 있습니다. ELB 뒤에 수천 개의 인스턴스를 둘 수도 있습니다. 이것이 수평 확장입니다.

이 단계에서는 수천 명의 사용자를 지원하기 위해 다수의 EC2 인스턴스를 사용하게 되며, 이는 궁극적으로 클라우드 비용을 증가시킵니다. 비용을 절감하려면, 부하 변화에 따라 인스턴스 사용을 최적화해야 합니다.

사용자: 10,000명 – 100,000명

성능 향상을 위해 정적 콘텐츠를 객체 기반 스토리지로 이동

성능과 효율성을 개선하려면 RDS에 더 많은 읽기 복제본을 추가해야 합니다. 이를 통해 쓰기 마스터 데이터베이스의 부하를 줄일 수 있습니다. 또한 정적 콘텐츠를 Amazon S3와 Amazon CloudFront로 이동하여 웹 서버의 부하를 줄일 수 있습니다.

• Amazon S3
• Amazon CloudFront
• Amazon DynamoDB
• Amazon ElastiCache

Amazon S3

Amazon S3는 객체 기반 스토리지입니다. EC2 인스턴스에 연결되지 않아 JavaScript, CSS, 이미지, 동영상과 같은 정적 콘텐츠를 저장하는 데 적합합니다. 99.999999999%의 내구성을 제공하도록 설계되었으며, 여러 페타바이트의 데이터를 저장할 수 있습니다.

Amazon CloudFront

Amazon CloudFront는 콘텐츠 전송 네트워크(CDN)입니다. Amazon S3 버킷에서 데이터를 가져와 여러 데이터 센터 위치에 배포합니다. 콘텐츠를 엣지 로케이션에 캐시하여 사용자가 가장 낮은 지연 시간으로 액세스할 수 있도록 합니다.

또한, 데이터베이스 서버의 부하를 줄이기 위해 세션 상태를 저장하는 데 관리형 NoSQL 데이터베이스인 DynamoDB를 사용할 수 있습니다. 데이터베이스에서 캐싱 데이터를 가져오는 데에는 Amazon ElastiCache를 사용할 수 있습니다.

Amazon DynamoDB

Amazon DynamoDB는 일관되고 단일 밀리초 대기 시간의 성능을 필요로 하는 애플리케이션을 위한 빠르고 유연한 NoSQL 데이터베이스 서비스입니다. 완전히 관리되는 클라우드 데이터베이스로, 문서 및 키-값 저장 모델을 지원합니다.

Amazon ElastiCache

Amazon ElastiCache는 서비스형 캐싱(Caching-as-a-Service)입니다. 분산 캐시 환경 배포 및 관리와 관련된 복잡성을 제거합니다. 노드가 실패하면 자동으로 새 노드가 시작되는 자가 복구 인프라를 제공합니다.

사용자 > 500,000명

자동 확장을 설정하여 변동하는 수요를 자동으로 충족

이 단계에서는 소규모 팀이 아키텍처를 관리하기 어렵고, 적절한 모니터링 없이 분석하기 어려운 복잡한 구조가 됩니다.

• Amazon CloudWatch
• AWS Elastic Beanstalk
• AWS OpsWorks
• AWS CloudFormation
• AWS CodeDeploy

웹 계층이 훨씬 가벼워진 만큼, 이제는 자동 확장(Auto Scaling)을 설정해야 할 때입니다!

"자동 확장은 수요에 따라 컴퓨팅 클러스터의 크기를 자동으로 조정하는 것입니다."

자동 확장은 "적시 프로비저닝(just-in-time provisioning)"을 가능하게 하여 사용자 수요에 따라 인프라를 동적으로 확장할 수 있습니다. 트래픽 급증에 따라 EC2 인스턴스를 자동으로 시작하거나 종료할 수 있습니다. 필요한 리소스에 대해서만 비용을 지불합니다.

Amazon CloudWatch

Amazon CloudWatch는 다양한 AWS 서비스의 상태와 리소스 사용량을 모니터링하기 위한 도구를 제공합니다. CloudWatch에서 수집된 메트릭은 경보 설정, 알림 전송, 경보 발생 시 작업 트리거에 사용할 수 있습니다. Amazon EC2는 자동 확장 인스턴스를 설명하는 메트릭을 CloudWatch로 전송합니다.

자동 확장 그룹에는 동일한 지역에 있는 여러 AZ(가용 영역)를 포함할 수 있으며, 확장성뿐만 아니라 가용성을 위해 여러 AZ에 인스턴스를 배치할 수 있습니다.

자동 확장을 효율적으로 최적화하려면 모니터링, 메트릭, 로깅을 추가해야 합니다.

• 호스트 수준 메트릭: 자동 확장 그룹 내 단일 CPU 인스턴스에서 문제가 무엇인지 파악
• 집계 수준 메트릭: Elastic Load Balancer의 메트릭을 통해 전체 인스턴스 집합의 성능 이해
• 로그 분석: CloudWatch Logs를 사용하여 애플리케이션에서 발생하는 문제를 분석. CloudTrail은 로그를 분석하고 관리하는 데 도움을 제공

AWS 모니터링 도구에서 지역별로 구성된 CloudWatch 메트릭을 결합하기 어려운 경우, Loggly와 같은 로그 관리 도구를 사용하여 CloudWatch와 CloudTrail에서 로그와 메트릭을 가져와 통합 분석할 수 있습니다.

AWS Elastic Beanstalk

AWS Elastic Beanstalk는 Java, .NET, PHP, Node.js, Python, Ruby, Go, Docker로 작성된 코드를 Apache, NGINX, Passenger, IIS와 같은 서버에 배포할 수 있는 서비스입니다.

AWS OpsWorks

AWS OpsWorks는 애플리케이션 관리를 위한 독특한 접근 방식을 제공합니다. OpsWorks는 애플리케이션 스택을 자동으로 복구하고, 시간 또는 작업 부하에 따라 확장하며, 모니터링을 위한 메트릭을 생성합니다.

AWS CloudFormation

AWS CloudFormation은 JSON 형식의 템플릿을 사용하여 리소스를 제공합니다. 일반 작업을 시작하는 데 유용한 샘플 템플릿을 선택할 수 있습니다.

AWS CodeDeploy

AWS CodeDeploy는 Amazon EC2 인스턴스 및 온프레미스에서 실행 중인 인스턴스에 코드 배포를 자동화하는 플랫폼 서비스입니다.

사용자 > 1백만 명

유연성을 위한 서비스 지향 아키텍처(SOA) 사용

100만 명 이상의 사용자를 지원하려면 대규모 웹 애플리케이션을 설계할 때 서비스 지향 아키텍처(SOA)를 사용해야 합니다.

• Amazon Simple Queue Service (SQS)
• Amazon Simple Notification Service (SNS)
• AWS Lambda

SOA에서는 각 구성 요소를 해당 계층에서 분리하고 별도의 서비스를 만들어야 합니다. 개별 서비스는 독립적으로 확장할 수 있습니다. 웹 및 애플리케이션 계층은 서로 다른 리소스 요구 사항과 서비스를 가지며, 이를 통해 확장성과 고가용성을 제공하는 유연성을 확보할 수 있습니다.

Amazon Simple Queue Service (SQS)

SQS는 클라우드 애플리케이션의 구성 요소를 분리하고 조정하는 간단하고 비용 효율적인 서비스입니다. SQS를 사용하면 소프트웨어 구성 요소 간에 메시지를 쉽게 전송, 저장, 수신할 수 있습니다.

Amazon Simple Notification Service (SNS)

SNS는 많은 구독자에게 메시지를 보낼 수 있습니다. 설정이 간단하고 원활한 운영과 높은 신뢰성을 제공하여 모든 엔드포인트에 알림을 보낼 수 있습니다.

AWS Lambda

AWS Lambda는 서버를 프로비저닝하거나 관리하지 않고 코드를 실행할 수 있는 컴퓨팅 서비스입니다. AWS Lambda는 필요할 때만 코드를 실행하며 수요에 따라 자동으로 확장합니다. 사용한 컴퓨팅 시간에 대해서만 비용을 지불하며, 코드가 실행되지 않을 때는 비용이 청구되지 않습니다. Lambda를 사용해 이벤트로 트리거되는 함수로 구성된 서버리스 아키텍처를 구축할 수도 있습니다.

결론

확장성 접근 방식에 대한 결정을 초기 단계에서 내려야 합니다. 언제 애플리케이션이 인기를 얻을지 알 수 없기 때문입니다! 또한, 페이지 충돌(또는 느려짐)은 사용자 불만족과 애플리케이션의 나쁜 평판으로 이어질 수 있으며, 이는 궁극적으로 수익에 영향을 미칩니다.