AWS 가용성,확장성
1. 개요
On-Premise 환경과 마찬가지로 클라우드 환경 하에서 아키텍처 설계 시 연속성 있는 업무 서비스를 제공하기 위하여 시스템 인프라에 대한 고가용성을 고려하여야 한다. 일반적으로 고가용성 확보는 업무 서비스가 수행되는 인프라 구성요소 별로 존재하는 Single Point of Failure(이하 SPoF)를 제거하여, 특정 구성요소에 대한 장애 시 에도 정상 구성요소를 이용하여 정상적인 서비스가 수행되도록 구성하는 것이다.
그러나, On-Premise 환경에서는 초기 물리 장비 도입부터 고가용성을 고려하여 도입을 수행하고 이를 바탕으로 아키텍처 설계가 수행되지만, 이미 물리적인 인프라 환경이 구축되어있는 클라우드 환경의 경우 개별 구성요소에 대한 가용성은 일정 수준 이상 확보가 되어있다고 할 수 있다.
따라서, 클라우드 환경 내에서의 가용성 확보는 구성요소에 대한 가용성 확보보다는 전체 아키텍처 측면에서의 가용성 확보 설계를 중점적으로 수행하는 것이 바람직하다.
또한 가용성 확보 관점에서 클라우드 환경의 특징 중 하나인 [처리 용량을 자유롭게 확장 가능한 아키텍처]와 [장애 시 자동 복구 가능한 아키텍처]을 고려한 어플리케이션/DBMS 등의 설계를 수행하여야 한다.
본 가이드에서는 클라우드 환경 내의 SPoF 구간에 대하여 살펴보고 이를 해결할 수 있는 방안을 설명한다.
2. 가용성 확보 방안
2.1. 센터
On-Premise 환경에서 센터는 평상 시 서비스를 제공하는 주 센터와 주 센터 전체 장애 또는 주 센터에서 운영중인 주요 장비 장애 시 이를 대신하여 업무 처리를 할 수 있도록 하는 DR 센터로 운영 하는 경우가 일반적이다.
해당 센터 간에는 대부분 네트워크로 연결이 되어있으며, 주 센터에서 생성되고 변경되는 데이터에 대하여 실시간/근실시간 동기화를 수행하여 센터 장애 시에 가용성을 확보하고 있다.
클라우드 환경에서의 센터는 특히 본 가이드의 대상이 되는 AWS의 경우 앞서 설명한 바와 같이 Region과 AZ라는 서비스로 On-Premise의 센터를 대신하고 있다.
항목 | 내용 |
|---|---|
Region | On-Premise의 물리 전산 센터 영역 |
Availability Zone | 물리 센터(Region) 내의 물리 서버의 집합 |
표 101. 센터 가용성
국내 지역에 한정된 일반적인 On-Premise의 센터와는 다르게 AWS의 센터인 Region(Region목록은 http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones 참조)은 전 세계에 걸쳐 구성되어있으며, 이러한 Region 간 데이터 복제 등과 같은 작업 수행을 위하여 인터넷 기반의 네트워크 연결이 기본 구성되어있다.
*Region과 Availability Zone에 대한 상세 내용은 http://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/using-regions-availability-zones.html#concepts-regions-availability-zones 참조
2.1.1. Region 간 고가용성 확보
Region을 이용하여 서비스에 대한 고가용성 확보는 On-Premise 환경에서의 Active DR 개념과 유사하다고 할 수 있다. 즉, 주센터와 DR센터에서 동일한 업무를 수행하고, 모든 사용자의 요청을 주센터와 DR센터로 분산하여 처리할 수 있는 방식이며, 이러한 분산은 네트워크 장비나 설정을 이용하여 수행하는 경우가 일반적이다.
이 경우 DR 센터에서는 주로 비즈니스 로직을 처리하는 AP 서버를 Active로 구성하고 DB의 경우 Standby 형태로 구성하여 실제 DR의 AP 서버는 주센터의 DB를 연결하여 이용하도록 구성한다.
또한 DR 센터의 DB는 주 센터에서 변경되는 데이터에 대한 실시간/근실시간 동기화를 통해 주센터 장애 시에도 이를 이용하여 서비스를 수행할 수 있도록 하는 것이 일반적이라 할 수 있다.
클라우드 환경에서도 위와 같은 방식으로 구성하는 것이 바람직하나, 지리적으로 특정 지역 내에 두 센터가 존재하는 On-Premise와는 다르게 전 세계에 해당 센터(Region)가 분산 설치되어있는 이유로 각 Region간 통신 Latency를 고려하여야 하며, 또한 Region 간의 통신은 인터넷 기반의 통신을 수행하여 Region 간 전송되는 데이터에 대한 암호화도 추가적으로 고려하여야 한다.
따라서, 일반적인 클라우드 환경에서 Region을 이용하여 가용성을 확보하는 경우는 아래와 같다.
항목 | 내용 |
|---|---|
전세계 대상 서비스 수행 시 | 업무 서비스가 특정 지역이 아닌 전 세계에 걸쳐 수행되는 경우 |
DR 구성 시 | On-Premise 환경 하에서 DR과 동일 개념 |
표 102. Region 가용성 확보 요건
2.1.2. AZ 간 고가용성 확보
AZ는 앞서 설명한 바와 같이 각 Region 내에 구성된 물리 서버의 집합이며, 이는 On-Premise 환경에서 물리 서버 1대와 동일한 개념으로 이해하는 것이 바람직하다.
예를 들어 On-Premise 환경에서 서버 이중화 구성 시 물리서버 장애에 대비하기 위하여 동일 업무를 수행하는 논리 서버는 서로 다른 물리 서버에 구성하는 것과 같이, 클라우드 환경에서도 동일 업무를 수행하는 서버는 반드시 서로 다른 AZ에 구성하여 AZ 장애 시 전체 업무 서비스가 중단되는 것을 사전에 회피할 수 있다.
따라서, 클라우드 환경 하에서 시스템 인프라를 구성할 경우, 특히 서버 인스턴스 다중화 구성 시 On-Premise와 동일하게 서로 다른 AZ에 걸쳐서 구성할 필요가 있다.
2.2. 서버 구성요소
On-Premise 환경에서의 서버는 서버 자체 및 서버 내 구성요소에 대한 이중화를 기본으로, 수행되는 업무에 따라 노드를 추가하거나 구성요소를 다중화 구성하는 것이 일반적이며, 이는 클라우드 환경에서도 동일하게 적용되는 원칙이다.
단 클라우드 환경에서 가용성 관련 설계 시 아래와 같이 추가적인 고려사항이 존재한다.
항목 | 내용 |
|---|---|
NIC 다중화 | 일반적인 NIC Trunk를 구성하여 네트워크 인터페이스에 대한 가용성 확보 가능 |
HBA 다중화 | AWS 서버 인스턴스에는 가상 HBA 할당 불가 |
표 103. 클라우드 가용성 확보 추가 고려사항
그러나 클라우드 환경에서의 서버 구성요소 다중화의 경우 특별한 경우를 제외하고는 따로 구성하지 않고 클라우드 솔루션 업체에서 제공하는 가용성 수준을 신뢰하고 활용하는 것이 바람직 하다.
2.3. 서버
서버 구성요소는 앞서 설명한 바와 같이 자체적으로 고가용성이 이미 확보되어있거나, 고가용성 구성이 필요하지 않으나, 서버 노드에 대한 고가용성은 On-Premise와 동일하게 고려하여야 한다.
일반적인 클라우드 환경 하에서의 서버 고가용성은 On-Premise와 마찬가지로 동일 업무를 수행하는 서버 노드 수를 하나 이상 구성하여 노드 장애에 대비하는 것이며, 이를 위해서 부하분산을 위한 구성요소, 확장 방안 등이 고려된 설계를 수행하여야 한다.
해당 서버 노드에 대한 고가용성 확보는 노드 별로 수행되는 업무 성격에 따라 Stateless와 Stateful로 구분할 수 있으며, 아래 Stateless 리소스와 Stateful 리소스 항목에서 각각에 대한 가용성 확보 방안을 자세히 설명한다.
2.4. 스토리지
본 가이드의 대상인 AWS에서는 서버 구성요소와 마찬가지로 스토리지 구성요소에 대한 고가용성은 이미 확보가 되어있다고 할 수 있다. 특히 스토리지 서비스인 S3/EFS의 경우 설정을 이용하여 Region간 또는 AZ 데이터 복제가 자동으로 수행되고, 장애 시 자동으로 해당 복제 볼륨으로의 접근이 가능하여 데이터에 대한 가용성 확보가 가능하다.
그 외 서버 인스턴스에 구성 가능한 EBS의 경우는 자체적으로 RAID 구성 등을 이용하여 가용성을 확보할 수 있다. 그러나 아래와 같이 구성 가능한 RAID에 대한 제약이 존재한다.
항목 | 내용 |
|---|---|
RAID 구성 | 주요 솔루션이 설치되는 디스크의 경우 RAID 1을 이용하여 데이터 안정성 확보 |
표 104. RAID 구성 제약 사항
2.5. 네트워크
네트워크 구성요소에 대한 가용성 확보는 하나의 경로 상에 존재하는 다양한 구성요소에 대한 다중화 구성과 목적지까지의 경로를 하나 이상으로 구성하는 두가지 방법을 고려하여야 한다.
일반적으로 클라우드 환경 내에서의 네트워크 관련 가용성 확보는 타 구성요소와 마찬가지로 기본적인 수준은 보장이 되어있어 클라우드 솔루션 업체에서 제공하는 가용성 수준을 신뢰하고 활용하는 것이 바람직하다.
2.6. 미들웨어
On-Premise 환경에서 미들웨어 가용성은 이중화/다중화를 통해 보장한다. 예를 들어 WAS서버를 2대로 구성하면 1대가 DOWN되거나 처리 불능 상태가 되어도 나머지 한대로 서비스가 가능하며, 3대로 구성하여 1대가 불능 상태가 되면 3대로 처리할 용량의 2/3만큼 처리가 가능하게 된다.
WAS 여러 대 중 1대가 처리불능이나 서비스 지연 상태가 되었을 때 해당 WAS 엔진이나 인스턴스를 DOWN시켜서 문제를 해결한 후 재기동 할 수 있으며, 문제가 해결될 때까지 DOWN된 WAS는 사용할 수 없게 된다.
아마존 AWS 클라우드 환경에서는 모니터링 툴인 CloudWath와 Autoscaling등을 연계하여 다중화된 WAS 서버 중 1대가 불능 상태가 되었을 때 ELB에서 해당 서버에 대한 요청을 중단하고 새 인스턴스를 기동하여 새 인스턴스에서 서비스를 계속할 수 있다.
미들웨어 가용성을 위해서는 WAS 인스턴스가 동적으로 증감할 수 있도록 특정 노드에 대한 종속성을 제거하고 장애상황을 정의하여 특정 조건에 맞게 오토스케일링이 될 수 있도록 구축해야 한다.
미들웨어 가용성 확보 관련 상세 내용은 Stateless 리소스를 참조한다.
- WEB/WAS 특정 노드 종속성 제거를 위한 어플리케이션 설계 : 세션 공유 처리,
- DB 가용성을 위한 어플리케이션 설계 : Read/Write DB 분리에 따른 CUD서비스와 Read전용 서비스 분리 설계
- 파일처리 시 특정 노드 종속성 제거 : S3 파일 공유, 로그파일
2.7. 데이터베이스
On-Premise에서 OLTP 서비스를 제공하기 위해서 사용하는 메인 데이터베이스는 ORACE 대부분이며 선호도 또한 높다. Oracle에서는 RAC라는 인스턴스 클러스터링 기능을 통해 유휴 Node 없는 Active-Active서비스를 제공하며 장애시 서비스 가용성도 제공한다. 클러스터링은 데이터베이스 인스턴스 가용성 설계의 defactor 표준으로 인식되고 있어, 이외 다른 상용 데이터베이스에서도 지속적으로 제품 개선을 통해 클러스터링 기능을 추가/제공하는 있는 추세다. 아직까지 클러스터링 기능의 안정적인 제공이 어려운 제품들은 Active-Standby 구조를 통해 가용성을 제공하고 있다.
클라우드에서는 Oracle RAC기능을 사용 할 수 없어[1] Multi-AZ와 Active-Standby구조 조합하는 방식으로 가용성을 제공하고 있다..
이미 많은 목차에서 Multi-AZ와 Active-Standby에 대해서 언급하고 있어, 본 장에서는 추가로 언급 하지 않으며 자세한 사항은 Staleful 리소스를 참조하면 된다.
아래 표는 On-Premise와 클라우드에서 데이터베이스 고가용성 구성의 특징을 정리한 것으로 데이터베이스 종류에 따라 다소 차이는 있을 수 있다. 예를 들면, 오라클의 경우는 Multi-AZ는 사용 가능하나 Active-Standby구조는 Amazon RDS에서는 사용할 수 없으며, EC2환경에서는만 Oracle Active Data Guard를 이용해서 Active-Standby를 구성 할 수 있다.
구분 | On-Premise 가용성 | 클라우드 가용성 |
|---|---|---|
개념 | 2대 이상의 Node를 클러스터로 구성하며, 한 Node의 장애시 Cluster내의 다른 Node로 failover하는 방식을 사용함. Oracle의 경우 Cluster인 RAC기능 제공. Nosql DB의 경우는 각 데이터 블록을 다른 Node에 중복 Copy하는 방식을 사용함. | Multi-AZ에 Active-Standby Node를 다수 구성하는 방식을 사용함. |
failover시간 | Cluster은 솔루션에서 장애를 감지하고 failover가능 | Cluster 솔루션 보다 다소 느림 |
확장성 및 성능 | Scale-Up과 Scale-Out 한계 존재함 | 유연한 Scale-Up과 Scale-Out 가능 |
[1] FlashGrid라는 제품을 통해 적용 가능하다고 하나 적용 사례가 없어 사용시 기능에 대한 검증은 필요하다
3. 확장성 확보 방안
3.1. 서버 인스턴스 자동 확장
앞서 설명한 바와 같이 클라우드 환경의 서버는 x86기반의 서버로 구성되어있다. 즉, On-Premise에서 흔하게 구성하는 대용량의 Enterprise 급의 Unix 기반 서버 대비 각 서버의 처리 용량이 상대적으로 낮은 편에 속하며, 동일한 업무 처리 시 필요한 서버의 노드 수는 앞서 제시한 대형 Unix 서버 대비 많아 질 수 밖에 없다.
그러나, 서버 인스턴스의 수와 기동되는 시간으로 비용 산정을 수행하는 클라우드 환경 특성 상 Peak 시 기준으로 산정된 서버 노드를 평상 시에도 운영하는 것은 비용 측면에서 낭비라 할 수 있으며, 이를 위하여 클라우드 환경에서는 서버 인스턴스에 대한 자동 확장 기능을 제공하고 있다.
본 가이드의 대상이 되는 AWS에서는 이러한 자동 확장 기능을 Auto-Scaling으로 제공하고 있으며, Auto-Scaling의 특징은 아래와 같다.
항목 | 내용 |
|---|---|
자동화 된 가용성 확보 | 서버 인스턴스가 비정상 상태일 때 이를 감지하여 종료한 다음 이를 대체할 인스턴스를 자동으로 시작 |
자동화 된 서버 인스턴스 확장 | 애플리케이션이 항상 현재 트래픽 요구를 처리할 수 있는 적절한 용량/노드수를 결정하고 인스턴스를 자동으로 시작 |
비용 절감 | 필요에 따라 용량을 동적으로 확장 및 축소할 수 있어, 사용한 서버 인스턴스에 대해서만 비용을 지불 |
Auto-scaling을 이용한 서버 인스턴스 자동 확장은 아래 Autoscaling 항목에서 자세히 설명한다.
3.2. 부하 분산
앞서 설명한 Auto-scaling을 이용한 서버 인스턴스 자동 확장을 수행하였을 때 발생할 수 있는 가장 큰 문제 중 하나는, [신규로 구성된 서버로의 부하 분산]이라 할 수 있다.
즉, 일반적인 On-Premise 환경에서는 부하분산 대상이 되는 서버가 모두 고정된 IP 기반으로 구성되며, 또한 해당 IP를 부하분산 장비(ex. L4/L7)에 설정하여 부하분산을 수행하나, 클라우드 환경에서는 신규로 생성되는 서버 인스턴스의 IP는 관리자가 아닌 클라우드 솔루션에 의하여 부여가 되고, 또한 해당 IP는 고정되어있지 않고 생성 시 마다 변경되는 것이 일반적이다.
이를 위하여 AWS에서는 Elastic Load Balancer(이하 ELB)라는 서비스를 제공하고 있으며, 이는 아래의 특징을 갖고 있다.
항목 | 내용 |
|---|---|
고가용성 | 수신되는 트래픽을 단일 AZ 또한 여러 AZ의 EC2 인스턴스에 걸쳐 배포 |
상태 확인 | ELB는 EC2 인스턴스의 상태를 감지하여 비정상적 인스턴스를 발견한 경우 해당 인스턴스를 사용하지 않고 다른 정상적인 인스턴스로 요청을 분배 |
보안기능 | VPC를 사용할 경우 ELB와 관련된 보안 그룹을 생성 및 관리하여 추가 네트워킹 및 보안 옵션을 제공 |
고정 세션 | ELB는 쿠키를 사용하여 사용자 세션을 특정 EC2 인스턴스에 고정 가능 |
운영 모니터링 | 요청 수 및 요청 지연 시간과 같은 ELB Metric은 CloudWatch를 통해 보고 |
4. Stateless 리소스
클라우드 환경의 Stateless 리소스(보통, WEB 서버나 WAS 서버)는 서비스 부하에 맞춰 안정적으로 서비스를 제공하기 위해 대수가 증가/감소할 수 있도록 Scale-out 방식의 확장성을 보장하고 기존 인스턴스에 장애가 발생하여 대체용 신규 인스턴스를 생성 하는 등 고정된 리소스가 아니라 동적으로 변경될 수 있는 요소로 서비스가 서버 변경에도 영향받지 않도록 서버 종속성을 제거하는 방향으로 설계한다.
4.1. Multi-AZ 구성
기존 On-Premise환경에서 가용성 보장을 위한 기본 구성은 모든 리소스를 이중화로 구성하는 것이다. 클라우드 환경에서도 이처럼 인스턴스의 이중화 구성을 통해 아키텍처의 가용성을 향상시킬 수 있지만 단순히 같은 기능을 하는 인스턴스를 1대 이상 배치해 서버 장애에 대응하는 것 이상으로 2개 이상의 Availability Zone (이하, AZ 또는 가용영역)을 활용해 데이터 센터 수준의 장애에 대응하는 것도 가능하다.
가용 영역은 서로 물리적으로 분리되어 있는 데이터센터로 각 가용영역 사이의 통신은 고속 전용망을 통해 이뤄지며 리전별로 최소 2개에서 최대 5개까지 (Seoul 리전의 경우 2개의 AZ가 구성) 제공된다.
그림 67 Multi-AZ 구성도
드물기는 하지만 특정 가용영역에 있는 모든 인스턴스의 가용성에 영향을 미치는 장애 (예: 정전이나 지진, 네트워크 장애) 가 발생할 경우, 하나의 가용영역에 복수개의 인스턴스를 구성했더라도 전체 서비스에 치명적인 영향을 줄 수 있기 때문에 AWS 환경에서는 최소 2개 이상의 가용 영역에 인스턴스를 이중화 구성으로 배치하여 Active-Active Multi-AZ 구성으로 데이터 센터 레벨의 가용성 확보가 필요하다.
4.1.1. Active-Active Multi-AZ 구성
인스턴스를 생성할 때 인스턴스가 생성될 가용영역을 선택할 수 있어서 2개 이상의 가용영역에 동일한 기능을 하는 인스턴스를 분리해 배치 후, 같은 리전 안에 여러 가용 영역에 걸쳐 있는 EC2에 부하를 분산시킬 수 있는 AWS관리형 로드 밸런서 서비스인 Elastic Load Balancer(이하, ELB)를 사용하면 가용 영역 하나에 장애가 발생하더라도 무중단 서비스를 제공할 수 있다.
그림 68. Active-Active Multi-AZ 구성도
4.2. Scale Out
4.2.1. 로드 밸런서로 소결합(Loose Coupling) 구조 구성
기존 On-Premise환경과 클라우드 환경 아키텍처에서 큰 차이점은 WEB-WAS 티어 사이에도 부하 분산을 위한 Load Balancer구성이 필요하다는 점이다.
ELB는 기존 L4/L7의 부하분산 기능을 대체하며 WAS 인스턴스의 수가 변경되더라도 전체 아키텍처에 영향을 미치지 않고 서비스 운영이 가능하도록 WAS 그룹의 서비스 엔드포인트 역할 및 부하 분산 대상인 인스턴스의 Health-Check 기능을 수행하여 상태가 정상인 인스턴스에게만 트래픽을 분산해 백엔드 인스턴스에 장애가 발생하더라도 서비스에 영향을 미치지 않고 운영이 가능하다.
ELB의 경우 트래픽 분배 방식으로 Round Robin 정책만을 제공하여 부하 분산 기능을 위해서는 EC2 인스턴스에 다양한 트래픽 분배 방식을 제공하는 타 소프트웨어 L4를 구성하는 것이 바람직 할 수도 있지만 Auto-Scaling 기능을 활용해서 동적으로 수량이 변경되는 아키텍처를 계획 중이라면 ELB 사용이 필수적이다.
그림 69. 로드 밸런서로 소결합(Loose Coupling) 구조 구성도
- 서비스 엔드포인트 제공으로 확장성 강화
그림 70. 서비스 엔드포인트를 통한 확장성 강화 구성도
- 인스턴스 Health-Check를 통해 내결함성(Fault tolerance) 강화
그림 71. 인스턴스 HealthCheck를 통한 내결함성 강화 구성도
4.2.2. WAS 세션 중앙 집중 처리
On-Premise환경의 WAS 서버의 경우, 특정 서버 장애시에도 세션 지속성을 유지하기 위해 WAS서버 간 Session Cluster를 구성한다. 하지만, AWS 클라우드 환경에서는 보통 Cluster 구성에서 많이 사용되는 Multicast 통신이 불가하고 세션을 공유해야하는 서버가 동적으로 변경될 수 있어, 마이크로서비스로 시스템을 운영하는 경우 이 기종 WAS간의 세션 공유 등의 조건을 만족시키기 위해 WAS 세션을 특정 리소스에서 중앙 집중식으로 처리할 필요가 있다.
그림 72. 중앙집중형 Session 처리 구성도
세션 관리용 리소스는 관리 및 확장성 문제로 RDBMS보다 대량 읽기/쓰기를 동시에 처리할 수 있는 NoSQL이 더 적합하고 AWS 서비스로 구축 할 경우 KeyValueDB인 DynamoDB와 In-memory DB인 Redis의 관리형 서비스인 ElastiCache를 선택할 수 있다.
요구사항에 적합한 상태 정보를 저장하기 위한 데이터 저장소를 준비하고 이 데이터 저장소에 사용자를 식별하는 ID (세션 ID와 사용자 ID)를 키로하여 사용자 정보를 값으로 저장하면 인스턴스 등에서는 상태 정보를 저장하지 않고 데이터 저장소의 데이터를 참조, 갱신해 상태 정보 손실을 걱정하지 않고 Scale Out 패턴을 이용할 수 있다. 다만, 여러 인스턴스에서 상태 정보에 대한 액세스가 하나의 요소로 집중되기 때문에 저장소의 성능이 병목 구간을 유발하지 않도록 주의 할 필요가있다.
아래는 이러한 Session 관리를 위하여 AWS에서 제공되는 서비스의 설명이다.
구분 | DynamoDB | ElastiCache (Redis) |
|---|---|---|
서비스 유형 |
|
|
서비스 위치 |
|
|
확장성 |
|
|
가용성 |
|
|
보안/권한 |
|
|
종합 |
| |
표 107. Session 관련 AWS 서비스
그림 73. DynamoDB와 ElastiCache를 활용한 Session 처리 구성도
만약, 이런 WAS Session 공유 구성이 불가능 하다면 Classsic ELB의 경우, Sticky Session 기능을 사용하여 Client로 부터 들어오는 HTTP request를 항상 같은 인스턴스로 라우팅하도록 설정할 수 있다.
디폴트로 사용하지 않는 Sticky Session 기능을 사용하도록 설정하면 HTTP response에 cookie를 세팅하여 해당 Client의 Session이 저장되어 있는 인스턴스에 대한 정보를 저장하는데 애플리케이션이 이미 HTTP cookie를 사용하고 있으면, 해당 cookie 명을 넣어서 사용중인 애플리케이션 cookie를 사용하게 하고 애플리케이션이 cookie를 사용하지 않으면 별도의 ELB가 생성한 cookie를 만들도록 한다.
하지만, 이 기능을 사용하는 경우, 부하의 인스턴스 편향이나 특정 인스턴스에 장애가 발생했을 때 장애 인스턴스의 세션을 유지할 수 없어 권장되는 구성은 아니다.
< 참고 URL >
- DynamoDB로 Tomcat Session Manager 구성 방안(영): http://docs.aws.amazon.com/sdk-for-java/v1/developer-guide/java-dg-tomcat-session-manager.html
- ElastiCahce와 Spring Session을 통한 Tomcat Session 관리(일): http://blog.catcloud.net/2016/05/18/100
- Configure Sticky Sessions for Your Classic Load Balancer (영): http://docs.aws.amazon.com/elasticloadbalancing/latest/classic/elb-sticky-sessions.html
4.2.3. 파일의 서버 종속 제거
클라우드 환경의 서버는 Auto Scaling으로 때에 따라 생성/삭제되는 동적 요소이기 때문에 다수의 WAS 서버에서 공유가 필요한 파일은 기존 On-premise 환경에서 NAS (ex. NFS, CIFS)나 SAN 공유 (ex. GPFS)를 통해 WAS 서버 간 공유 파일을 위한 파일시스템을 구성해 애플리케이션에서 파일을 사용하는 것처럼 인스턴스 간 공유 파일용 스토리지 구성이 필요하다.
| S3 | EFS | EC2+EBS (w.GlusterFS 등) |
|---|---|---|---|
서비스 유형 |
|
|
|
서비스 위치 |
|
|
|
사용 가능 리전 |
|
|
|
사용 가능 OS |
|
|
|
기존 애플리케이션 수정 여부 |
|
|
|
확장성 |
|
|
|
가용성 |
|
|
|
보안/권한 |
|
|
|
비용
|
|
|
|
*TCO 참조: https://aws.amazon.com/ko/efs/tco/
| |||
종합 |
| ||
표 108. AWS 파일 공유 서비스
< 참고 URL >
- Amazon S3 개발자 안내서 - 객체 관련 작업(한): https://docs.aws.amazon.com/ko_kr/AmazonS3/latest/dev/ObjectOperations.html
- Amazon EFS 사용자 안내서 (영): http://docs.aws.amazon.com/efs/latest/ug/getting-started.html
- GlusterFS Documentation - Deploying in AWS (영): https://gluster.readthedocs.io/en/latest/Install-Guide/Setup_aws/
4.3. 자동화
4.3.1. Auto Scaling Group 구성
클라우드 환경의 특징 중 기존 On-Premise 환경과 비교했을 때 가장 큰 차이점은 Auto Scaling이라는 기능을 통해 요청되는 서비스 부하에 맞춰 서비스 인스턴스의 수를 증가/감소시키는 것이 가능해 변경되는 수요에 유연하게 대응하는 시스템을 구축할 수 있다는 점이다.
Auto Scaling 은 위에서 설명한 Scale out특성을 충족해 인스턴스가 동적으로 확장/축소되어도 전체 아키텍처나 서비스에 변경이 없다는 전제 하에 특정 조건이 발생했을 때 자동으로 인스턴스 대수를 증가/감소하는 기능으로 같은 서비스를 수행하는 동일한 인스턴스의 그룹으로 구성한다.
그림 74. Auto Scaling 그룹 구성도
Auto Scaling 수행 과정 | |
|---|---|
|
|
|
|
|
|
표 109. AWS Auto Scaling 수행과정
추가로, ASG을 활용해 인스턴스의 가용성/확장성을 보장하기 위해서는 ASG 앞단의 ELB 또한 가용성/확장성을 보장해야 하는데 ELB의 디폴트 성능 임계치는 대략 초당 200~300 Request 처리 및 세션 임계치는 in/out 총 6만 세션 정도를 디폴트 수치로 판단된다.
따라서 그보다 더 큰 부하 발생 시 ELB 역시 확장이 필요한데 일반적으로 linear 형태의 트래픽 증가는 ELB 자체적으로 Scale up/out을 지원하지만 5분내에 2배 이상 트래픽 증가 등의 급격한 증가의 경우, AWS Case Open을 통해 ELB Pre-warm 신청이 필요하다.
< 참고 URL >
- Auto Scaling 사용자 설명서 (한): http://docs.aws.amazon.com/ko_kr/autoscaling/latest/userguide/WhatIsAutoScaling.html
- ELB Pre warm 참조 (영): https://aws.amazon.com/articles/1636185810492479#pre-warming
4.3.2. Auto Scaling Group 운영
Auto Scaling Group으로 관리되는 리소스는 오토스케일링으로 인스턴스가 동적으로 생성되거나 삭제될 때 함께 수행되어야 하는 관리 작업이 자동화되어야 한다.
- 최신 애플리케이션 배포
- 데이터 저장소로부터 데이터 Copy
- DNS에 해당 인스턴스 등록
- 소프트웨어 시작
- 패키지 업데이트
- 특정 AWS 리소스 (EIP, EBS 등) 할당
- 인스턴스 삭제 시, 영구 보관 필요 데이터 백업 등
자동화 작업은 Autoscaling의 Life cycle Hook을 통해 신규 생성 시, ASG에 포함되어 서비스 되기전에 필요 작업을 수행하거나 인스턴스 삭제 과정 중 제거되기 이전에 필요한 데이터를 백업하는 등의 과정을 수행하고 삭제 되는 등의 과정으로 추가될 수 있다.
그림 75. Auto Scaling 그룹 운영 구성도
- 애플리케이션 배포 - Base AMI + install code & configuration as needed
기존 On-Premise환경에서의 배포는 대상 서버가 변경되지 않아 배포 서버가 배포 대상 서버로 수정된 애플리케이션을 Push하는 형태였다면 인스턴스가 동적으로 변경되는 클라우드 환경에서는 배포 트리거에 따라 인스턴스가 고정된 엔드포인트를 제공하는 소스나 아티팩트가 보관되는 레포지토리로 최신 애플리케이션을 Pull 하는 형태로 배포 방법이 변경되야 한다.
특히 ASG로 구성된 인스턴스의 경우, OS, 미들웨어, 애플리케이션까지 설정이 끝난 AMI 를 생성하고 Launch Configuration에 해당 AMI를 설정하게 된다면 인스턴스의 빠른 생성은 가능할지 몰라도 미들웨어 설정이 변경되거나 애플리케이션이 수정될 때마다 운영중인 인스턴스의 AMI를 생성하고 수많은 버전을 관리하며 Launch Configuration의 AMI를 변경하는 것이 쉽지 않다.
따라서, 용도에 맞춰 기본이 되는 AMI를 생성하고 필요한 설정이 서버가 생성될 때 설치, 가동, 설정되는 구성을 설계할 필요가 있다. 특히, 인스턴스의 어떤 계층까지 고정된 이미지로 관리하고 어떤 계층부터 가동 시에 동적으로 설정할 것인지에 대한 고려가 중요하다. 많은 부분을 인스턴스 생성할 때 설치/설정하면 유연성은 높지만 부팅 시간이 느려서 문제가 될 수 있고 너무 적은 부분을 생성 시 설정하게 되면 시스템 변경에 맞춰 잦은 이미지 생성 작업이 필요하기 때문에 적정선을 유지할 필요가 있다.
그림 76. AMI 생성시 유연성과 부팅시간 적정성
- Via Userdata
AMI를 용도에 맞춰 생성하고 사용자 데이터 영역에 초기화 스크립트를 만들어두면 인스턴스 생성 시 필요한 여러 가지 파일이나 설정을 Amazon S3나 Git 등의 외부 저장소에서 다운로드하여 동적으로 자기 자신을 구축한다. 다만, Userdata 설정이 ASG의 Launch Configuration에 설정되어 배포과정에 수정이 필요한 경우, Launch Configuration 변경이 필요하다. 또, Userdata에 설정된 명령은 인스턴스 최초 생성 시에만 수행하기 때문에 인스턴스 재시작의 경우에도 반복적으로 수행이 필요한 경우, 인스턴스에 Cloud-init 등의 소프트웨어 설치가 필요하다.
- Using AWS CodeDeploy
특정 ASG를 CodeDeploy 서비스의 Deployment Group으로 설정하면 Scale out 이벤트가 발생하여 신규 인스턴스가 생성이 필요할 때 CodeDeploy가 이를 인지하여 자동으로 해당 인스턴스에 최신 소스 아티팩트 배포를 진행하여 완료된 이후 서비스가 가능한 상태가 된다.
그림 77. AWS 코드 디플로이 구성도
5. Stateful 리소스
클라우드의 Stateful 리소스 데이터베이스를 의미하며 데이터베이스에 대한 상세한 가용성 설계는 용량 설계 및 확장성을 참조한다.
5.1. Multi-AZ 구성 (Active-Standby)
AWS에서는 가용성 방법을 Multi-AZ 서비스를 제공하며, 데이터 이스는 Multi-AZ 에 데이터베이스 Node를 분산/중복(Active-Standby)배치하며 가용성을 확보한다.
Multi-AZ 에 대한 좀더 상세한 내용은 Multi-AZ 구성을 참조한다.
5.2. Scale-up
Scale-Up은 EC2나 RDS의 CPU, Memory 등 HW적인 사양을 높이는 방안이며, AWS에서는 쉽게 Scale-Up이 가능하다.
5.2.1. EC2 Scale-Up 방안
EC2는 AWS 콘솔상에서 옵션변경으로 처리가 불가능하다. 즉, 현재 운영중인 EC2의 옵션만을 변경하여 처리되지는 않는다
EC2 Scale-Up시 고려사항과 절차는 EC2 사용 데이터베이스 용량 관리를 참조 한다.
5.2.2. RDS Scale-Up 방안
RDS의 경우 AWS 콘솔상에서 옵션변경으로 간단히 처리가 가능하다., 단, 변경되는 동안 어느 정도의 시간(1분정도) 동안은 서비스가 중지된다.
아래 그림과 같은 console 화면(Modify DB Instance)에서 DB Instance Class만 수정해 주면 된다. DB Instance 종류는 Small DB Instance, Large DB Instance, Extra Large DB Instance, High Memory Extra Large DB Instance 등 CPU나 메모리 사양에 따라 다양하다.
단, Instance가 바뀌는 동안의 downtime이 존재한다는 단점이 있다. 내부적인 동작원리는 사용하고 있는 Instance를 down시킨 다음, 붙어 있는 EBS 스토리지를 새로운(console에서 선택한) Instance에 붙여서 부팅시킨다.
그림 78. AWS RDS 인트턴스 Scale-Up시 주요 옵션
5.2.3. PIOPS
EBS는 iSCSI기반의 SAN 스토리지다. PC로 쉽게 생각하면 외장 하드 정도로 이해하면 된다. 초기 EC2에서는 EBS 디스크를 VM에 붙였을때, EBS 디스크에 대한 IO 성능 느리고, 그 성능이 일정하지 않았던 문제가 있었다. 이를 보완하기 위해서 나온 것이 다음과 같은 두 가지 옵션이다.
- Provisioned IOPS (PIOPS)
EBS 디스크 용량에 따라서 IOPS를 보장한다. 보장 가능한 IOPS는 EBS용량에 비례하여 증가한다. GB를 기준으로 N GB사용시, 명시적으로 지정 가능한 최대 IOPS는 N*10 IOPS가 된다. (40GB면 400IOPS, 100GB면 1000IOPS) 현재 최대 1,000 IOPS까지 지원된다.
정확하게는 EC2 VM의 옵션이 아니라 EBS의 옵션으로, Provisioned IOPS를 선택하면, IO 성능을 보장할 수 있는 EBS 디스크 영역에 EBS Volume이 생성된다.
표 110. IOPS 옵션
- EBS Optimized Instance
EBS Optimized Instance는 EBS와 EC2 인스턴스간에 내부적으로 전용 네트워크를 사용하여 대역폭을 안정적으로 유지해준다. 500Mbps~1000Mbps 사이에 대역폭을 설정할 수 있다.
5.3. Scale-out
EC2환경에서 WEB/WAS의 Auto Scale-Out 기능이 AWS 데이터베이스 서비스에서는 제공하지 않으며, Scale-Out이 필요한 경우 CloudWatch 등 모니터링 툴을 통해 자원 상황을 확인하고 수동으로 증설을 진행해야 한다.
AWS사용 서비스와 데이터베이스 구성 방법에 따라 크게 2가지 Scale-Out방법이 존재한다. AWS에서 제공하는 AWS RDS의 Write-Read 구성을 사용하는 경우와, Write-Write 구성을 사용하는 경우이다. 전자는 성능 향상을 위해서 조회 서비스를분산한 형태이며, 후자는 순수한 분산 DB을 구성한 형태이다.
5.3.1. Write-Read 분리
AWS RDS에서 기본적으로 제공하는 기능으로 AWS GUI화면을 통해 손쉽게 확장이 가능하다.
그림 79. AWS RDS Write-Read 분리 구성 화면
5.3.2. 분산 아키텍처 적용
5.3.2.1. 분산 DB구성
분산 데이터베이스 구성이후 Scale-out에는 한가지 주의 사항이 있다. 기존 데이터에 대한 신규 Node의 분산 여부 이다.
기존 데이터에 대한 증설 node로의 분산이 필요한 경우는 데이터베이스 사용을 차단한 상태에서 재 분배 작업을 수행해야 한다. 증설 node에 기존 테이터가 아닌 신규 테이블만 할당할 경우는 증설 이후 추가 작업 은 없다.
단, Load Balancing를 위해 WEB/WAS/ELB 등의 설정은 변경 해야 한다.
5.3.2.2. DB 샤딩
물리적으로 다른 데이터베이스에 데이터를 수평분할 방식으로 저장하여 DB 인스턴스를 분리하는 것이 샤딩이다. 기존 테이블 Partitioning 은 한 DB 안에서의 테이블 분리였다면, 샤딩은 하나 이상 DB에서의 테이블 분리 개념이며, 샤딩의 가장 큰 장점은 성능의 저하 및 Data 량이 증가할 경우 DB 를 손쉽게 확장할 수 있다는 점이다. 그리고 샤딩시의 기준되는 컬럼이 “샤드키” 이다.
샤딩을 적용할 경우 join연산에 제약이 있어, SQL이 복잡해 진다. 분산 DB 환경으로 장애시 Failover 전략이 필요하다. Schema변경 작업 등 운영이 복잡해 진다. 분산되어 있는 데이터에 대한 백업이 복잡해 진다.
예) 원천 데이터베이스의 테이블을 사용자ID를 shard key로 하고 수평 분활한 것이다.
분산 테이블 대상 선정, Shard key 도출 및 적용 방법 등 모델링에 대한 상세한 내용은 클라우드 데이터분산 가이드를 참고한다.
그림 80. DB 샤딩 구성 예시
이론적으로 분산 DB를 구성하는 방법은 수직분활, 수평 분활, hybrid 분할, 테이블 중복이 있다. 최근에는 Hibernate Shards와 같이 FW에서 지원하는 기능이 Sharding지원하는 솔루션을 사용해서 분산 데이터 처리를 한다.
Sharding 솔루션을 사용하지 않을 경우에는 분산DB간 데이터 처리를 Application layer에서 처리해 주어야 한다. 그러나, 기존 sql를 사용 할 수 있다는 잇점이 있다.
정리하자면, 독립적인 node구성이 가능하며 join빈도가 적은 경우는 공통 데이터 복제를 통한 sharding이용하지 않은 분산 DB구성도 가능하다.
그러나, 대용량 데이터에 대한 성능 향상이 목적이고 분산 DB간 조인이 빈번 한경우는 Sharding FW를 사용할 것을 권장한다.
댓글
댓글 쓰기