본 문서는 총 2부로 구성되어 있으며 이 글은 2부입니다.
데이터베이스 구성, 백업 및 장애 조치
대부분의 웹 응용 프로그램에는 일반적으로 관계형 또는 NoSQL 데이터베이스 형식으로 지속성이 포함됩니다. AWS는 관계형 데이터베이스 인프라와 NoSQL 데이터베이스 인프라를 모두 제공합니다. 또는 EC2 인스턴스에 고유한 데이터베이스 소프트웨어를 배포할 수 있습니다. 다음 표에는 이러한 옵션이 요약되어 있으며, 이 섹션에서는 이러한 옵션에 대해 자세히 설명합니다.
Amazon RDS
Amazon RDS(Amazon Relational Database Service)를 통해 친숙한 MySQL, Postgre의 기능에 액세스할 수 있습니다. SQL, Oracle 및 Microsoft SQL Server 데이터베이스 엔진입니다. 이미 사용하는 코드, 응용 프로그램 및 도구를 Amazon RDS와 함께 사용할 수 있습니다. Amazon RDS는 데이터베이스 소프트웨어를 자동으로 패치하고 데이터베이스를 백업하며 사용자 정의 보존 기간 동안 백업을 저장합니다. 또한 특정 시점 복구를 지원합니다. 단일 API 호출을 통해 관계형 데이터베이스 인스턴스와 연결된 컴퓨팅 리소스 또는 스토리지 용량을 유연하게 확장할 수 있습니다.
또한 Amazon RDS Multi-AZ를 구축하면 데이터베이스 가용성이 향상되고 예상치 못한 운영 중단으로부터 데이터베이스를 보호할 수 있습니다. Amazon RDS Read Replicas는 데이터베이스의 읽기 전용 복제본을 제공하므로 읽기 집약적인 데이터베이스 워크로드를 위해 단일 데이터베이스 배포 용량을 초과하여 확장할 수 있습니다. 모든 AWS 서비스와 마찬가지로 초기 투자도 필요하지 않으며 사용하는 리소스에 대해서만 비용을 지불합니다.
Amazon EC2 인스턴스에서 관계형 데이터베이스 관리 시스템 (RDBMS) 호스팅
관리되는 Amazon RDS 제품 외에도 선택한 RDBMS(예: MySQL, Oracle, SQL Server 또는 DB2)를 EC2 인스턴스에 설치하고 직접 관리할 수 있습니다. Amazon EC2에서 데이터베이스를 호스팅하는 AWS 고객은 읽기 전용 복사본에 대한 미러링 및 항상 준비된 패시브 슬레이브에 대한 로그 전송을 포함하여 다양한 마스터/슬레이브 및 복제 모델을 성공적으로 사용할 수 있습니다.
Amazon EC2에서 직접 데이터베이스 소프트웨어를 관리할 때는 장애 방지 및 영구 스토리지의 가용성도 고려해야 합니다. 이를 위해 Amazon EC2에서 실행되는 데이터베이스는 네트워크 연결 스토리지와 유사한 Amazon EBS(Amazon Elastic Block Store) 볼륨을 사용하는 것이 좋습니다. 데이터베이스를 실행하는 EC2 인스턴스의 경우 모든 데이터베이스 데이터 및 로그를 EBS 볼륨에 배치해야 합니다. 데이터베이스 호스트에 장애가 발생하더라도 이러한 호스트는 계속 사용할 수 있습니다. 이 구성을 사용하면 호스트에 장애가 발생할 경우 새 EC2 인스턴스를 시작할 수 있고 기존 EBS 볼륨을 새 인스턴스에 연결할 수 있는 간단한 페일오버 시나리오가 가능합니다. 그런 다음 데이터베이스가 중지된 위치를 선택할 수 있습니다.
EBS 볼륨은 가용성 영역 내에서 중복성을 자동으로 제공하므로 단순 디스크보다 가용성이 높아집니다. 단일 EBS 볼륨의 성능이 데이터베이스 요구에 충분하지 않으면 볼륨을 스트라이핑하여 데이터베이스의 IOPS 성능을 높일 수 있습니다. 까다로운 워크로드의 경우 필요한 IOPS를 지정하는 EBS 프로비저닝 IOPS도 사용할 수 있습니다. Amazon RDS를 사용하는 경우 서비스에서 자체 스토리지를 관리하여 데이터 관리에 집중할 수 있습니다.
NoSQL 솔루션
AWS는 관계형 데이터베이스를 지원하는 것 외에도 완전하게 관리되는 NOSQL 데이터베이스 서비스인 Amazon DynamoDB를 제공하여 무한 확장성을 통해 빠르고 예측 가능한 성능을 제공합니다. AWS Management Console 또는 DynamoDB API를 사용하면 다운타임이나 성능 저하 없이 용량을 확장하거나 축소할 수 있습니다.
DynamoDB는 분산 데이터베이스를 AWS로 운영 및 확장하는 관리 부담을 처리하므로 하드웨어 프로비저닝, 설정 및 구성, 복제, 소프트웨어 패치 또는 클러스터 확장에 대해 걱정할 필요가 없습니다.
Amazon SimpleDB는 고정 스키마 없이도 데이터를 쿼리하고 인덱싱할 수 있는 경량, 고가용성 및 내결함성이 높은 핵심 비관계형 데이터베이스 서비스를 제공합니다. SimpleDB는 크고, 인덱스가 높고, 유연한 스키마 테이블이 필요한 데이터 액세스 시나리오에서 데이터베이스를 매우 효과적으로 대체할 수 있습니다.
또한 Amazon EC2를 사용하여 Cassandra, CouchDB 및 MongoDB와 같은 NoSQL 이동의 다른 많은 신흥 기술을 호스팅할 수 있습니다.
데이터 및 자산의 저장 및 백업
AWS Cloud에는 웹 응용 프로그램 데이터 및 자산을 저장, 액세스 및 백업하는 다양한 옵션이 있습니다. Amazon S3는 고가용성 및 중복 객체 저장소를 제공합니다. Amazon S3는 이미지, 비디오 및 기타 정적 미디어와 같이 다소 정적이거나 변화 속도가 느린 개체를 위한 훌륭한 스토리지 솔루션입니다. 또한 Amazon S3는 CloudFront와 상호 작용하여 이러한 자산의 에지 캐싱 및 스트리밍을 지원합니다.
첨부 파일 시스템과 같은 스토리지의 경우 EC2 인스턴스에 EBS 볼륨이 연결될 수 있습니다. 이러한 디스크는 EC2 인스턴스를 실행하기 위한 마운트 가능한 디스크와 같습니다. Amazon EBS는 블록 스토리지로 액세스해야 하며 데이터베이스 파티션이나 애플리케이션 로그와 같이 실행 중인 인스턴스의 수명을 초과하는 지속성을 요구하는 데이터에 적합합니다.
EC2 인스턴스와 독립적인 수명을 갖는 것 외에도, EBS 볼륨의 스냅샷을 작성하여 Amazon S3에 저장할 수 있습니다. EBS 스냅샷은 이전 스냅샷 이후 변경 사항만 백업하므로 스냅샷 빈도가 높아지면 스냅샷 시간이 단축될 수 있습니다. 또한 EBS 스냅샷을 사용하여 여러 EBS 볼륨에서 데이터를 복제하고 이러한 볼륨을 실행 중인 다른 인스턴스에 연결할 수 있습니다.
EBS 볼륨은 16TB까지 클 수 있으며, 더 큰 볼륨이나 I/O 성능 향상을 위해 여러 EBS 볼륨을 스트라이핑할 수 있습니다. I/O 집약적인 애플리케이션의 성능을 극대화하기 위해 프로비저닝된 IOPS 볼륨을 사용할 수 있습니다. 프로비저닝된 IOPS 볼륨은 I/O 집약적인 워크로드, 특히 스토리지 성능과 랜덤 액세스 I/O 처리량의 일관성에 민감한 데이터베이스 워크로드의 요구사항을 충족하도록 설계되었습니다. 볼륨 생성 시 IOPS 속도를 지정하고 볼륨의 수명 동안 Amazon EBS 프로비저닝을 지정합니다. Amazon EBS는 현재 볼륨당 최대 20,000 IOPS를 지원합니다. 여러 볼륨을 스트라이핑하여 애플리케이션에 인스턴스당 수천 IOPS를 제공할 수 있습니다.
플릿 자동 스케일링
AWS 클라우드 아키텍처와 기존 호스팅 모델의 주요 차이점 중 하나는 AWS가 필요에 따라 웹 애플리케이션 집합을 자동으로 확장하여 트래픽 변화를 처리 할 수 있다는 것입니다. 기존 호스팅 모델에서 트래픽 예측 모델은 일반적으로 예상 트래픽보다 호스트를 프로비저닝하는 데 사용됩니다. AWS에서는 집합을 확장 및 축소하기위한 일련의 트리거에 따라 인스턴스를 즉석에서 프로비저닝 할 수 있습니다. Auto Scaling 서비스는 필요에 따라 확장 또는 축소 할 수 있는 서버의 용량 그룹을 생성 할 수 있습니다. Auto Scaling은 지표 데이터에 대해 Amazon CloudWatch와 직접 작동하고 Elastic Load Balancing과 함께 로드 배포를 위한 호스트를 추가 및 제거합니다. 예를 들어, 웹 서버가 일정 기간 동안 80 % 이상의 CPU 사용률을보고하는 경우 추가 웹 서버를 신속하게 배포 한 다음 로드 밸런서에 자동으로 추가하여로드 밸런싱 회전에 즉시 포함시킬 수 있습니다.
AWS 웹 호스팅 아키텍처 모델에서 볼 수 있듯이 아키텍처의 여러 계층에 대해 여러 Auto Scaling 그룹을 생성하여 각 계층을 독립적으로 확장 할 수 있습니다. 예를 들어 웹 서버 Auto Scaling 그룹은 네트워크 I / O의 변경에 따라 스케일 인 및 스케일 아웃을 트리거 할 수 있는 반면, 애플리케이션 서버 Auto Scaling 그룹은 CPU 사용률에 따라 스케일 아웃 될 수 있습니다. 연중 무휴 가용성을 보장하고 그룹 내 사용을 제한하기 위해 최소값과 최대 값을 설정할 수 있습니다.
Auto Scaling 트리거는 리소스 사용률을 실제 수요에 맞추기 위해 지정된 계층에서 총 집합을 늘리거나 줄 이도록 설정할 수 있습니다. Auto Scaling 서비스 외에도 Amazon EC2 API를 통해 Amazon EC2 집합을 직접 확장하여 인스턴스를 시작, 종료 및 검사 할 수 있습니다.
추가 보안 기능
DDoS (Distributed Denial of Service) 공격의 수와 정교함이 증가하고 있습니다. 전통적으로 이러한 공격은 방어하기가 어렵습니다. 공격 기간 동안 웹 사이트 방문 손실로 인한 기회 비용뿐만 아니라 완화 시간과 소비 전력 모두에서 비용이 많이 듭니다. 이러한 공격을 방어하는 데 도움이 되는 여러 가지 AWS 요소와 서비스가 있습니다. 첫 번째는 AWS 네트워크의 규모입니다.
AWS 인프라는 상당히 규모가 크므로 규모를 활용하여 방어를 최적화 할 수 있습니다. Elastic Load Balancing, Amazon CloudFront 및 Amazon Route 53을 비롯한 여러 서비스는 트래픽이 크게 증가함에 따라 웹 애플리케이션을 효과적으로 확장 할 수 있습니다.
특히 두 가지 서비스가 방어 전략에 도움이됩니다. AWS Shield는 다양한 형태의 DDoS 공격 경로로부터 보호하는 데 도움이 되는 관리되는 DDoS 보호 서비스입니다. AWS Shield의 표준 오퍼링은 무료이며 계정 전체에서 자동으로 활성화됩니다. 이 표준 오퍼링은 가장 일반적인 네트워크 및 전송 계층 공격을 방어합니다. 이 수준 외에도 고급 서비스는 진행중인 공격에 대해 거의 실시간 가시성을 제공하고 앞서 언급한 서비스와 높은 수준으로 통합함으로써 웹 응용 프로그램에 대해 더 높은 수준의 보호 기능을 제공합니다. 또한 AWS DDoS 대응 팀 (DRT)에 액세스하여 리소스에 대한 대규모의 정교한 공격을 완화 할 수 있습니다.
AWS WAF (웹 애플리케이션 방화벽)는 가용성 또는 보안을 손상 시키거나 과도한 리소스를 소비 할 수 있는 공격으로부터 웹 애플리케이션을 보호하도록 설계되었습니다. AWS WAF는 CloudFront 또는 Application Load Balancer와 함께 사용자 지정 규칙과 함께 작동하여 크로스 사이트 스크립팅, SQL 인젝션 및 DDoS와 같은 공격을 방어합니다. 대부분의 AWS 서비스와 마찬가지로 AWS WAF에는 보안 요구가 변경 될 때 WAF에 대한 규칙 생성 및 편집을 자동화 할 수 있는 완전한 기능을 갖춘 API가 제공됩니다.
AWS를 통한 장애 조치
기존 웹 호스팅에 비해 AWS의 또 다른 주요 이점은 중복 배포 위치에 쉽게 액세스할 수 있는 가용성 영역입니다. 가용성 영역은 물리적으로 다른 가용성 영역의 장애로부터 격리되도록 설계된 위치입니다. 또한 동일한 AWS 영역의 다른 가용성 영역에 대한 저렴한 지연 시간대의 네트워크 연결을 제공합니다. 그림 3의 AWS 웹 호스팅 아키텍처 다이어그램에서 볼 수 있듯이, 웹 응용 프로그램의 내결함성을 높이기 위해 여러 가용성 영역에 EC2 호스트를 배포하는 것이 좋습니다. 장애 발생 시 가용성 영역 간에 단일 액세스 지점을 마이그레이션하기 위한 규정이 있어야 합니다. 예를 들어 두 번째 가용성 영역에 데이터베이스 슬레이브를 설정하여 예상할 수 없는 장애 시나리오 중에도 데이터의 지속성이 일관되고 가용성이 높게 유지되도록 해야 합니다. 이 작업은 Amazon EC2 또는 Amazon RDS에서 클릭 한 번으로 수행할 수 있습니다.
기존 웹 애플리케이션을 AWS Cloud로 이동할 때 아키텍처 변경이 필요한 경우가 많지만, AWS Cloud를 사용할 가치가 있는 확장성, 안정성 및 비용 효율성이 크게 개선되었습니다. 다음 섹션에서는 이러한 개선 사항에 대해 설명합니다.
웹 호스팅에 AWS를 사용할 때의 주요 고려 사항
AWS Cloud와 기존 웹 애플리케이션 호스팅 모델 사이에는 몇 가지 주요 차이점이 있습니다. 이전 섹션에서는 클라우드에 웹 애플리케이션을 배포할 때 고려해야 할 많은 주요 영역을 강조하였습니다. 이 섹션에서는 애플리케이션을 클라우드에 도입할 때 고려해야 할 주요 아키텍처 전환에 대해 설명합니다.
물리적 네트워크 어플라이언스가 더 이상 없습니다.
AWS에서는 물리적 네트워크 어플라이언스를 배포할 수 없습니다. 예를 들어 AWS 애플리케이션의 방화벽, 라우터 및 로드 밸런서는 더 이상 물리적 디바이스에 있을 수 없지만 소프트웨어 솔루션으로 교체해야 합니다. 로드 밸런싱(예: Jeus, HAProxy, NGINX Plus 및 Pound) 또는 VPN 연결 설정(예: OpenVPN, OpenSwan 및 Vyatta) 등 다양한 엔터프라이즈급 소프트웨어 솔루션이 있습니다. 이는 AWS Cloud에서 실행할 수 있는 제한 사항이 아니라 현재 이러한 장치를 사용하는 경우 애플리케이션에 대한 아키텍처 변경 사항입니다.
방화벽이 어디에나 있습니다.
간단한 DMZ를 사용한 후 기존 호스트 모델에서 호스트 간의 통신을 열면 AWS는 모든 호스트가 잠기는 보다 안전한 모델을 구현합니다. AWS 배포를 계획하는 단계 중 하나는 호스트 간의 트래픽 분석입니다. 이 분석은 어떤 포트를 열어야 하는지에 대한 결정을 안내합니다. 아키텍처의 각 호스트 유형에 대해 Amazon EC2 내에 보안 그룹을 생성할 수 있습니다. 또한 다양한 단순하고 계층화된 보안 모델을 생성하여 아키텍처 내의 호스트 간에 최소한의 액세스를 지원할 수 있습니다.
Amazon VPC에서 네트워크 액세스 제어 목록을 사용하면 서브넷 수준에서 네트워크를 잠글 수 있습니다.
여러 데이터 센터의 가용성을 고려합니다.
AWS 영역 내의 가용성 영역을 여러 데이터 센터로 간주합니다. 서로 다른 가용성 영역에 있는 EC2 인스턴스는 논리적으로나 물리적으로 모두 분리되어 있으며, 고가용성 및 안정성을 위해 데이터 센터 간에 애플리케이션을 배포하기 위한 사용하기 쉬운 모델을 제공합니다. Amazon VPC를 지역 서비스로 사용하면 모든 리소스를 동일한 논리적 네트워크에 유지하면서 가용성 영역을 활용할 수 있습니다.
호스트를 사용 후 삭제 및 동적으로 처리합니다.
AWS 애플리케이션을 설계하는 방법에서 가장 중요한 변화는 Amazon EC2 호스트를 일시적이고 동적으로 간주해야 한다는 것입니다. AWS Cloud를 위해 구축된 애플리케이션은 호스트를 항상 사용할 수 있다고 가정해서는 안 되며, EC2 인스턴스가 실패할 경우 EBS 볼륨에 없는 데이터가 손실된다는 것을 알고 설계해야 합니다. 또한 새 호스트가 생성될 때 호스트의 가용성 영역 내의 IP 주소 또는 위치에 대한 가정을 해서는 안 됩니다. 구성 모델은 유연해야 하며 호스트의 부트스트래핑 접근 방식은 클라우드의 동적 특성을 고려해야 합니다. 이러한 기술은 확장성이 뛰어나고 내결함성이 뛰어난 애플리케이션을 구축하고 실행하는 데 매우 중요합니다.
서버리스 아키텍처 고려
이 백서는 주로 보다 전통적인 웹 아키텍처에 초점을 맞춥니다. 그러나 AWS Lambda 및 Amazon API Gateway와 같은 최신 서비스를 사용하면 가상 시스템의 컴퓨팅 수행을 추상화하는 서버 없는 웹 애플리케이션을 구축할 수 있습니다. 이 경우 코드는 요청별로 실행되며, 요청 수와 요청 길이에 대해서만 지불됩니다. 서버 없는 아키텍처에 대한 자세한 내용은 여기에서 확인할 수 있습니다.
결론
웹 애플리케이션을 AWS 클라우드로 마이그레이션하는 것을 고려할 때 수많은 아키텍처 및 개념적 고려 사항이 있습니다. 비즈니스와 함께 성장하는 비용 효과적이고 확장성이 뛰어나고 내결함성이 있는 인프라를 보유하면 AWS 클라우드로 마이그레이션하는 노력보다 훨씬 많은 이점이 있습니다.
빌드업웍스에서 AWS 무료 컨설팅을 진행합니다.
AWS에 대하여 궁금하신 내용이 있으시거나, 도입을 검토 중이시라면 편하게 신청해주세요.
[ 고지 사항 (Disclaimer) ]
본 컨텐츠는 고객의 편의를 위하여 AWS 서비스 설명을 위해 제작, 제공된 것입니다. 만약 AWS 사이트와 컨텐츠 상에서 차이나 불일치가 있을 경우 AWS 사이트 (AWS.amazon.com)가 우선합니다. 또한 AWS 사이트 상에서 한글 번역문과 영어 원문에 차이나 불일치가 있을 경우(번역의 지체로 인한 경우 등 포함), 영어 원문이 우선합니다.
본 문서는 Web Application Hosting in the AWS Cloud(2019년, 영문) 내용에 기반하여 작성 되었습니다.
이 문서는 정보 제공의 목적으로만 제공됩니다. 본 문서의 발행일 당시 AWS의 현재 제품 오퍼링 및 실행방법 등을 설명하며, 예고 없이 변경될 수 있습니다. 고객은 본 문서에 포함된 정보나 AWS 제품 또는 서비스의 사용을 독립적으로 평가할 책임이 있으며, 각 정보 및 제품은 명시적이든 묵시적이든 어떠한 종류의 보증 없이 “있는 그대로” 제공됩니다. 본 문서는 AWS, 그 자회사, 공급업체 또는 라이선스 제공자로부터 어떠한 보증, 표현, 계약 약속, 조건 또는 보장을 구성하지 않습니다. 고객에 대한 AWS의 책임 및 의무는 AWS 계약에 의해 관리되며 본 문서는 AWS와 고객 사이의 어떠한 계약에도 속하지 않으며 계약을 변경하지도 않습니다.
© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.
