AWS 통합아키텍처 설계

 

1. 개요

---

AWS 혹은 Azure 등과 같은 클라우드 환경하에서 시스템, 어플리케이션 아키텍처 구성 시 반드시 고려하여야 하는 요소들이 존재한다.

업무 비즈니스의 지속적인 변경에 대하여 신속하게 대응 가능하여야 하고, 이러한 대응에 대하여 전체 아키텍처에 대한 큰 변화 없이 대응할 수 있도록 유연한 구성이어야 하며, 또한 예상하지 못한 업무의 증가에 대응할 수 있도록 아키텍처를 구성하고 있는 구성요소의 규모를 업무 수행 중에 조정 가능하여야 한다. 그리고 이를 통하여 전체 아키텍처에 대한 성능을 향상 시킬 수 있어야 한다.

 

어플리케이션 아키텍처 관점에서 설계 수행 시 기존 On-Premise 환경에서 일반적으로 구성하는 Monolithic 구성의 경우, 명확하게 분리되어 있는 Application Layer와 Persistent Layer로 구성된 일반적인 3 Tier 구조를 따르는게 일반적인 모습이었다. 향후 Cloud에서 활용될 시스템의 경우, 그 용도와 구성 그리고 업무 민첩성등의 이유로 Microservice Architecutre[1]에 대한 적용을 고려할 필요가 있다.

 

개별 마이크로서비스 기능들이 전체적인 시스템으로 동작하기 위해서 Application Layer, Persistent Layer 이외에도 자료의 이동이 필요한 별도의 Channel 구성을 통한 데이터의 원할한 생산 및 소비 패턴을 구성해야 한다.

 

이에 Enterprise System에 구성된 마이크로서비스 아키텍처 상에서 개별 Service들이 어떤 식으로 연결을 해야 하는지, 설계 방안을 기존 데이터베이스 중심으로 기술하고자 한다.

 

마이크로서비스 설계 원칙은 서비스 기능(Function)을 중심으로 선행 설계 한 후 Data를 고려하는 방식이 권장되지만 현재, 기존 레거시 시스템 Migration에 대비한 인프라 설계를 위해서는 데이터베이스 분리에 대한 인프라 설계 대응 방안이 더욱 적절한 방법으로 판단된다. 또한 회사 내부에서는 모놀리딕 설계에 더욱 강점이 있으므로, 모놀리딕 설계를 어떤 식으로 변형할 지 방법을 살펴보는 것이 설명에 더욱 도움이 될 것이다.

 

일부 내용은 분산모델링가이드에 나와 있는 내용과 중복되는 부분이 있을 수 있으나, 마이크로서비스에서는 서비스 설계에 따라서 인프라 구성이 바뀔 수 있기 때문에, 서로간의 연관관계를 명시적으로 보기 위해서 함께 기술한다.

 

따라서, 본 장에서는 통합 아키텍처 설계 시 고려하여야 하는 사항에 대하여 확인하고, 클라우드 환경 하에서 아키텍처를 구성하기 위하여 참조 가능한 아키텍처 패턴에 대한 설명과 마이크로서비스를 지원하기 위한 아키텍처 방향을 확인한다. 이후, MSA 지원을 위한 Database에서의 서비스 분산 설계 방향과 개별 설계에 따른 인프라 구성 방안을 제시한다. 

---

[1] Microservice Architecture에 대한 상세 내용은 클라우드 서비스 분산 가이드 중 마이크로서비스 이해 참조

2. 통합 아키텍처 설계 고려사항

---

2.1. 아키텍처 전환 모델

2.1.1. 아키텍처 전환 모델 선택

클라우드 환경 하에서 아키텍처 설계 수행 시 가장 우선적으로 고려하여야 하는 항목은 해당 아키텍처에 대한 클라우드로의 전환모델을 선택하여야 한다. 앞서 설명한 바와 같이 클라우드로의 전환 모델은 Rehost/Replatform 및 Refactor로 구분되어지며, 이러한 전환모델을 선택하는 것은 기존 고객이 보유한 라이선스에 대한 재활용 여부/범위, 어플리케이션 코드의 수정 가능 정도 등을 기준으로 선택하여야 한다.

 

아래 표는 아키텍처 전환 시 필요한 전환모델을 선택하는 기준에 대한 예시이다.

항목	아키텍처	라이선스	어플리케이션 코드 수정
Rehost	기존 아키텍처 유지	기존 소프트웨어 라이선스 유지	어플리케이션 코드 수정 최소화
Replatform	기존 아키텍처 최대한 유지하며, 일부 소프트웨어 변경/도입으로 인한 아키텍처 변경	기존 소프트웨어 버전 업그레이드 또는 신규 소프트웨어 라이선스/Managed Service 도입	소프트웨어 및 아키텍처 변경으로 인한 코드 수정 외에 로직 등 변경 최소화
Refactor	클라우드 환경에 적합한 아키텍처로의 변경	클라우드 Managed Service 활용	소프트웨어 및 아키텍처 변경으로 인한 코드 수정 및 이로 인한 로직 변경 발생

그러나, 아키텍처 전환 시 적용 가능한 전환 모델은 위의 예시와 같이 명확한 기준으로 구분할 수 있는 것은 아니며, 전체 아키텍처 중 일부는 Rehost 개념으로, 일부는 Replatform 또는 Refactor 개념을 적용하거나, 혼합하여 적용하는 것이 일반적이라 할 수 있다.

2.1.2.  아키텍처 전환 시 변경 요소

기존 On-Premise 환경에서 클라우드 환경으로의 아키텍처 전환 시 클라우드 환경이 가지고 있는 여러가지 특징으로 인하여, 아키텍처 구성에 변경이 발생하는 부분들이 존재한다. 예를 들어, 일반적으로 On-Premise 환경의 주 DB용도로 사용하고 있는 Oracle의 경우 해당 솔루션이 제공하는 고가용성 기능 중 하나인 Oracle RAC를 클라우드 환경에서는 구성이 불가능하다.[2]

따라서, 위의 예시 처럼 기존 On-Premise 기반 시스템을 클라우드 환경으로 전환 시 아키텍처, 솔루션, 어플리케이션에 대한 변경이 발생하는 부분 또는 구성이 불가능한 부분을 사전에 식별하고 아키텍처 설계 시 이를 반영하는 것이 중요하다.

구분	변경 항목	내용
인프라	서버 인스턴스	X86 기반의 서버 하드웨어로 변경 일반적인 Unix 기반 하드웨어(IBM P-series, HP Itanium 등)에 대한 사용은 불가능[3]
	서버 운영체제	X86 기반의 서버 운영체제(Linux 또는 Windows)로 변경 일반적인 Unix 기반 운영체제(IBM AIX, HP HPUX 등)에 대한 사용은 불가능[4]
	서버 간 통신을 위한 참조	각 서버 간 통신 시 IP 기반의 Peer-to-Peer 방식을 Load Balancer 등과 같은 End-point를 이용한 통신으로 변경 각 서버 인스턴스의 자동확장(Auto-scaling) 기능 적용 시, 해당 서버 수량이 동적으로 변경되고 또한 대상 서버의 IP가 변경되므로, 서버 간 통신을 위하여 해당 서버 군 앞단에 통신을 위한 End-point 구성하고, 해당 End-point가 필요한 서버로 Re-direction하도록 구성 필요
	부하 분산 장비	On-Premise와 동일한 방식인 Load Balancer(L4 등)을 구성하나, Hardware 기반이 아닌 Software 기반으로 변경
	Appliance 장비	일반적인 클라우드 솔루션 제공업체의 경우 하드웨어 기반의 Appliance 장비에 대하여 자사 센터 반입이 불가 따라서, 이를 대체할 수 있는 Software 기반의 솔루션으로 변경 필요
솔루션	공통	기존 사용하고 있는 라이선스 활용 가능하나, 이 경우 라이선스 이전 가능여부 및 x86 기반 서버/운영체제 지원 여부 확인 필요
	미들웨어	X86 기반 서버/운영체제 지원 가능한 솔루션으로 변경 가능 WAS와 같이 Java 기반의 솔루션인 경우 이전 시 고려하여야 하는 항목이 상대적으로 적으나, C와 같은 컴파일러 기반의 솔루션은 OS에서 지원하는 라이브러리/함수 등을 고려하여 적용 가능 여부 확인 필요
	DBMS	X86 기반 서버/운영체제 지원 가능한 솔루션으로 변경 가능 특히 Oracle 기반의 DB 아키텍처 전환 시 Active-Active 구성을 위한 RAC 구성의 제약으로 인하여 Active-Standby 또는 타 DBMS로의 전환을 고려하여야 함 타 DBMS로 전환 시 기존 어플리케이션에 적용된 SQL에 대한 수정 범위/난이도 등을 고려 필요
	보안	X86기반 서버/운영체제 지원 가능한 솔루션으로 변경 가능 HSM 장비와 같이 하드웨어 기반의 Appliance의 경우 앞서 설명한 바와 같이 클라우드 솔루션 업체의 센터 반입이 불가능한 경우가 일반적이므로, 이를 대체할 수 있는 소프트웨어 기반의 솔루션으로 변경 필요
	운영관리	X86 기반 서버/운영체제 지원 가능한 솔루션으로 변경 가능 일부 특정 목적에 특화되어있는 운영관리 제품(APM 등)의 경우 클라우드 특성인 자유로운 확장 등을 지원할 수 있는지 사전에 확인 필요
	빌드/배포	X86 기반 서버/운영체제 지원 가능한 솔루션으로 변경 가능 운영관리 솔루션과 깉이 클라우드 특성인 자유로운 확장 등을 지원할 수 있는지 사전에 확인 필요

---

[2] 클라우드 환경 하에서 Oracle RAC 지원 여부는 각 클라우드 솔루션 홈페이지 참조

[3] 클라우드 환경 하에서 사용 가능한 서버 하드웨어는 각 클라우드 솔루션 홈페이지 참조

[4] 클라우드 환경 하에서 Unix 기반 운영체제 지원 여부는 각 클라우드 솔루션 홈페이지 참조

2.2. 통합 아키텍처 설계

2.2.1. 확장에 대한 설계[5]

On-Premise 환경에서의 아키텍처 설계 시 인프라 자원(서버/스토리지 및 네트워크 등)에 대한 용량 설계를 위하여 기존 인프라 사용량에 대한 정교하고 정량화된 부하 모델 및 부하 변동성을 고려하여 설계하는 것이 일반적이며, 운영 중 이러한 자원에 대한 특정 임계값에 도달 시 이에 대한 프로비저닝 프로세스를 통하여 더 큰 용량으로 Scale-Up 또는 Scale-Out 되도록 리소스에 대한 구매를 수행하고, 해당 용량은 구매한 용량에 대한 활용 여부와 상관없이 고정되게 된다.

 

클라우드 환경에서는 앞서 설명한 규모에 대한 확장/축소가 프로비저닝 프로세스와 동시에 수행될 수 있으며, 또한 기 설정된 자동화된 프로세스에 의하여 사용자 개입 없이 자동으로 수행될 수 있다.

 

이러한 확장에 대한 설계를 수행하기 위하여 고려하여야 하는 항목은 아래와 같다.

 

설계 시 고려사항	내용
서버 인스턴스 그룹화	하나의 업무를 처리할 때 필요한 서버 인스턴스를 수행하는 기능(ex. 사용자 접속 처리 그룹, 비즈니스 로직 처리 그룹 및 데이터 처리 그룹 등) 에 맞도록 그룹화하고, 이를 그룹별로 자동확장 되도록 구성.
Load Balancer 구성	그룹화 된 서버 인스턴스 상단에 부하분산을 수행하는 서비스(ex. Load Balancer 등)을 구성하여, 신규 노드 확장 시에도 자동으로 해당 노드를 인식하고 업무를 분배할 수 있으며, 또한 해당 그룹에 소속된 인스턴스 장애에도 타 노드가 정상적으로 업무를 처리할 수 있도록 구성.
Stateless 구성	어플리케이션이 수행될 때 생성되는 세션이나 상태 정보 등을 각 어플리케이션 내부 또는 해당 어플리케이션이 수행되는 서버 인스턴스 내에 저장하지 않도록 구성.
Scale-in 구성	자동으로 생성된 서버 인스턴스가 제거될 때 해당 인스턴스에서 수행중인 어플리케이션에 대한 종료 관련 처리 수행. 어플리케이션의 일시적인 오류 처리 및 재시도 제거되는 인스턴스에서 처리중인 작업은 타 인스턴스에서 수행할 수 있도록 해당 정보를 대기열에 저

---

[5] 확장에 대한 설계의 자세한 내용은 클라우드 아키텍처 가이드 가용성/확장성 참조

2.2.2. 느슨한 결합 구조 아키텍처

규모에 대한 자유로운 확장/축소가 가능한 클라우드 환경의 특징으로 인하여 클라우드 하에서 수행되는 어플리케이션은 수평적으로 확장 가능하도록 설계되어야 한다. 즉, 어플리케이션 서비스 또는 비즈니스 계층은 상태에 대한 정보를 각 어플리케이션에 개별적으로 저장하지 않도록 설계되어야 하며, 이를 통하여 어플리케이션이 수행되는 서버 노드가 증가되더라도 어플리케이션 기능에 영향을 미치지 않게 된다.

 

또한, 어플리케이션의 상태 정보가 중요한 경우 어플리케이션 외부에 별도의 상태 정보 저장소(Cache 또는 Queue 등)를 구성하여 해당 저장소에 저장하도록 구성하여, 다른 어플리케이션이 쉽게 해당 정보를 참조하여 필요한 업무를 수행할 수 있도록 하여야 한다.

 

이러한 외부 저장소를 이용하여 어플리케이션의 상태 정보 등을 저장하는 아키텍처 구성을 흔히 느슨하게 결합된 아키텍처(Loosely Coupled Architecture)라고 하며, 이는 클라우드 환경 하에서 아키텍처를 구성할 때 가장 고려하여야 하는 아키텍처 구성 방식이다.

 

느슨한 결합을 구현하기 위하여 가장 일반적으로 사용되는 설계 접근법은 아키텍처의 주요 처리 구성 요소 사이에 대기열(Queue 등)을 구성하는 것이다. 대부분의 클라우드 솔루션 공급자는 높은 동시성과 비정상적인 업무의 급증에 대비할 수 있도록 다양한 형태의 대기열 서비스를 제공한다.

 

이러한 느슨한 결합 구조 아키텍처를 설계하기 위하여 고려하여야 하는 내용은 아래와 같다.

 

설계 시 고려사항	내용
메시지 순서 보장	메시지 순서는 대기열에 넣기와 대기열에 넣기 작업 간 유지되지 않을 수 있음. 이 순서를 엄격하게 유지하여야 하는 경우에는 각 메시지 내용의 일부로 순서 지정 정보를 포함하여야 함.
메시지 중복 처리	메시지의 복제본 중 하나가 하드웨어 장애 또는 노드의 비 가용성으로 인하여 삭제되지 않아 중복 처리 될 수 있음. 따라서 메시지의 중복 처리 시에도 최종 결과가 변경되지 않도록 어플리케이션/비즈니스에 대한 설계 필요.
메시지 반환	대기열이 여러 서버 노드에 분산되어 구성되어 있어, 대기열에 메시지가 포함되어 있어도 지정된 Polling 요청에 의하여 모든 메시지가 반환되거가, 반환되지 않을 수 있음. Polling 요청에 의하여 반환되지 않은 메시지는 다음번 Polling 요청에 반환됨.
일괄 처리	어플리케이션 요구 사항에 따라 메시지 전송 즉시 처리가 필요하지 않은 경우에 여러 요청을 일괄 처리하여 업무 처리에 대한 효율성/처리량을 향상 시킬 수 있음.
대기열 구성	다른 유형의 메시지와 처리 기간에 따라 각자 다른 대기열을 구성하여야 함. 또한 이와 같이 다중 구성된 대기열을 처리하기 위하여 하나의 프로세스에서 다중 쓰레드를 구성하는 것보다 각 대기열을 처리하기 위한 별도로 분리된 처리 프로세스를 구성하여야 함.

2.2.3. 자동화 설계

기 구성된 인프라 환경에서 수행되는 업무가 평상 시와 다르게 급증할 경우 이를 처리하기 위하여 서버 노드를 프로비저닝하고, 해당 노드에서 수행되는 어플리케이션을 식별/배포하고 이를 실행하기 위한 매개변수(ex. 데이터베이스 연결 변수 등)를 구성하는 작업 등을 자동화 할 수 있도록 설계하여야 한다.

 

이를 위하여 클라우드 솔루션 제공업체는 API 또는 스크립트를 이용하여 클라우드 플랫폼의 거의 모든 것을 자동화 할 수 있도록 구성되어있으며, 이러한 자동화 대상은 일반적인 작업, 배포, 경고에 대한 자동 복구 작업, 확장 작업 등이 포함되어있다. 예를 들어, 장애가 발생한 노드 또는 비정상적으로 작동하는 노드에 대하여 정상 노드로 대체하거나 자동으로 재시작 하도록 구성 가능하다.

 

클라우드 기반 아키텍처에서 자동화 설계를 위하여 고려하여야 하는 항목은 아래와 같다.

 

설계 시 고려사항	내용
어플리케이션 오류에 대한 처리	어플리케이션 수행 중에 발생한 오류에 대하여 오류 발생한 노드 또는 다른 노드에서 재처리를 수행할 수 있도록 구성하여야 하며, 이러한 재처리의 경우 일정 횟수 이상 재처리가 수행되지 않도록 구성.
자동화 구성에 대한 검증	자동화 구성된 환경에 대하여 무작위적인 결함 또는 비정상 조건을 발생시켜 구성에 대한 검증을 사전에 수행.

2.2.4. 장애 발생에 대한 설계

아키텍처를 구성하는 구성요소 등에 대한 장애(ex. 하드웨어 장애, 데이터센터 장애, 데이터베이스 장애/성능 저하, 예상치 못한 업무 급증, 어플리케이션 오류 등) 발생 시 전체 아키텍처 및 업무 수행에 미치는 영향을 최소화 할 수 있도록 설계를 수행하여야 한다.

 

특히, 앞서 설명한 자동화 설계와 병행하여, 장애 발생 시 에도 운영자의 수동 개입을 최소화할 수 있도록 장애 발생한 구성요소의 자동 조치가 이루어지도록 설계하여야 한다.

 

이러한 장애 발생을 효과적으로 처리할 수 있도록 하는 고려사항은 아래와 같다.

 

설계 시 고려사항	내용
어플리케이션 상태 정보	서버 노드가 정료되면 어플리케이션의 상태가 손실되므로, 어플리케이션에 대한 상태 정보(ex. 세션 정보 등)에 대하여 서버 노드 외부에 저장하여야 함.
비동기식 분산 처리 구성	동기 처리를 수행하는 경우 특정 노드에 대량의 작업이 집중되어 성능에 대한 저하 및 이로 인한 타임아웃 등의 장애로 발전할 수 있으므로, 대기열 등을 이용한 비동기 처리를 구성하여 특정 노드에 장애가 전체 노드로 전이되는 것을 방지.
로그 저장	서버/어플리케이션 등에서 발생하는 로그는 항상 중앙 집중된 장소 (ex.데이터베이스 또는 로그 저장 서비스 등)에 저장하여야 함.
로그 정보	저장된 로그에는 오류를 추적하기 위한 추가적인 정보들(ex. 서버 노드 ID, Region, AZ 등)을 저장하여야 함. 또한 문제 원인을 추적하기 위하여 필요한 어플리케이션의 특정 시퀀스의 호출 또는 요청 시점까지 포함하여야 함.
SPoF 제거	어플리케이션이 수행되는 서버 노드 등을 여러 Region 또는 AZ로 분산 구성하고, 이를 이용한 Failover 설계를 수행하여 개별 서버 노드, Region 및 AZ의 장애로 인한 업무 중단의 가능성을 최소화 함.

2.2.5. 다중처리 설계

클라우드 환경하에서는 데이터 유입부터 이에 대한 처리까지의 아키텍처 전반에 걸쳐 다중처리에 대하여 고려하여 설계하여야 한다. 즉, 클라우드 환경으로 유입되는 서비스를 멀티 스레딩을 이용하여 병렬화하고 Load Balancer를 사용하여 부하를 분산시키며, 해당 업무를 처리하는 업무 어플리케이션을 다중 구성하거나, 업무 어플리케이션이 수행되는 서버 노드를 다중화하여 해당 업무를 동시에 수행할 수 있도록 구성하여야 한다.

이를 위하여 아키텍처 설계 시 멀티 스레딩 및 다중 노드 처리 기능을 활용하는 아키텍처 설계, 예를 들어 데이터베이스에서 데이터를 쿼리하기 위하여 여러 개의 스레드를 활용하도록 구성하는 것이 바람직 하다.

 

설계 시 고려사항	내용
병렬 처리 구성	Bigdata 처리와 같이 대량의 데이터에 대한 긴 시간의 처리 작업이 필요한 경우, 하나의 작업을 다수의 노드에서 분산하여 수행할 수 있도록 구성.

2.2.6. 성능에 대한 설계

어플리케이션이 수행될 때 필요한 데이터를 송/수신 하거나 데이터베이스에서 쿼리 시 가장 문제가 되는 부분은 지연시간(Latency)이다. 이러한 대기시간을 감소시키기 위하여 적용할 수 있는 아키텍처 구성 들, 예를 들어 메모리 최적화 서버 인스턴스의 사용, 캐시 서비스 사용 및 어플리케이션 및 데이터에 대하여 최대한 최종 사용자 측에 배치하는 기술 등을 적용할 수 있다.

 

또한 어플리케이션에서 자주 사용되는 데이터를 Prefetch하거나 자주 사용하는 페이지/데이터를 캐쉬에 저장하여 해당 데이터를 가져오기 위하여 거치게 되는 노드 수/처리 단계를 줄여 각 노드/단계 별 소요되는 지연시간을 줄일 수 있다.

 

그리고 정적 데이터의 경우 일반적인 클라우드 솔루션 업체에서 제공하는 CDN(Content Delivery Network)을 이용하여 최종 사용자가 위치하는 가장 가까운 데이터센터에서 해당 데이터를 제공받을 수 있도록 구성하여 어플리케이션 수행에 필요한 대기시간과 함께 웹 어플리케이션 및 사이트에 대한 성능을 향상시킬 수 있다.

 

설계 시 고려사항	내용
데이터 읽기/쓰기 분리 구성	하나의 데이터베이스에 읽기 작업과 쓰기 작업이 동시에 발생하는 경우, 특정 작업이 집중될 경우 다른 작업에 영향이 발생할 수 있으므로, 가급적 읽기 전용 데이터베이스와 쓰기 전용 데이터베이스를 분리하여 구성하고, 어플리케이션 레벨에서 이를 Routing하여 사용하도록 구성.
메모리 기반 아키텍처 구성	일반적으로 변경이 자주 발생하지 않는 데이터(ex. 코드성 또는 마스터성 데이터 등)의 경우 이를 메모리 기반 솔루션(ex. Cache 등)과 동기화하여 어플리케이션이 우선적으로 해당 솔루션에 접근하여 데이터를 참조할 수 있도록 구성.
정적 데이터 처리	HTML, Image 등과 같은 정적인 데이터는 이를 처리하기 위한 별도의 서비스를 네트워크 입구 가까이 구성하여, 해당 데이터 처리를 위하여 서버팜 내부의 서버 인스턴스까지 요청이 도달하지 않도록 구성.

2.2.7. 정합성에 대한 설계

일반적인 On-Premise 환경에서 최종 데이터에 대한 일관된 정합성 보장은 중요한 설계 고려사항 중 하나이다. 그러나 클라우드 환경 하에서의 데이터 정합성은 On-Premise 환경에서의 정합성 보장과 다른 측면에서 접근하여야 한다.

클라우드 환경에서의 데이터는 해당 데이터에 대한 변경이 수행된 이후에 해당 데이터의 모든 복제본에 업데이트가 반영되기까지 어느정도 지연시간이 발생하게 되며, 이러한 지연시간을 업무 측면에서 허용할 수 있다면 이를 이용하여 전체 아키텍처에 대한 성능과 확장성을 향상시킬 수 있다.

 

또한 이러한 아키텍처의 성능/확장성을 향상시키기 위하여 사용되는 설계 방식은 데이터에 대한 하나 이상의 읽기 복제본을 생성하는 방식이다. 이는 일반적으로 대량의 읽기 처리가 발생하는 업무/어플리케이션에서 사용할 수 있다. 대량의 읽기 작업과 데이터의 변경 작업을 논리적으로 분리된 노드에서 분산 처리하도록 구성하고, 변경이 발생한 데이터에 대하여 읽기 전용 노드로의 복제 지연을 지속적으로 모니터링하여 기 설정된 지연시간 허용 가능 여부를 판단하여야 한다.

 

정합성을 고려한 설계 수행 시 아래와 같은 항목에 대하여 유의하여 수행한다.

 

설계 시 고려사항	내용
데이터 파티셔닝	모든 응용 프로그램 서비스에서 공유되는 하나의 데이터 스키마에 모든 데이터를 저장하지 않도록 구성하여, 단일 데이터베이스 내에서 수행되는 데이터 저장이 다른 데이터 스키마에 미치는 영향을 최소화하도록 함.
어플리케이션을 이용한 일관성 유지	두개의 데이터베이스에 업데이트가 필요한 경우 하나의 트랜잭션으로 모든 데이터베이스에 대한 업데이트를 수행하는 것 보다, 별도의 트랜잭션으로 구분하여 구성하고, 거래 실패 시 이를 논리적으로 롤백하기 위한 보상 트랜잭션 패턴을 설계하여 구성함.

2.3. 참조 아키텍처 패턴[6]

아키텍처 패턴은 클라우드 환경 하에서 비즈니스 요구사항을 만족시키기 위하여 구성된 다양한 아키텍처를 분석하여 정형화된 모습으로 구성된 것이다. 이러한 아키텍처 패턴은 일반적으로 적용 가능한 패턴은 고가용성 관련, 데이터 관리 관련, 성능/확장 관련, 보안 관련 및 아키텍처 관리와 관련된 패턴 등이 있으며, 각 영역별로 하나 이상의 다양한 패턴이 존재한다.

 

본 가이드에서는 이 중 어플리케이션 관련된 패턴 중 일부인 N-Tier, Queue-Worker, Microservice, CQRS 아키텍처 등에 대한 설명을 수행하며, 통합 아키텍처 설계 시 업무요건에 따라 필요한 아키텍처 패턴을 조합하여 통합 아키텍처에 대한 설계를 수행한다.

2.3.1. N-Tier 아키텍처

N-Tier 아키텍처는 On-Premise에서와 마찬가지로 응용 어플리케이션을 구성하는 가장 일반적인 아키텍처 구성이다. 해당 아키텍처는 크게 사용자 접속과 화면에 대한 Rendering을 담당하는 프레젠테이션 계층과, 업무를 처리하는 로직이 수행되는 비즈니스 계층, 그리고 실제 데이터를 저장하는 데이터 계층으로 구분할 수 있으며, 보다 복잡한 응용 프로그램은 세 개 이상의 계층을 구성할 수도 있다.

 

각 계층은 물리적 또는 논리적으로 분리되어 있는 별도의 시스템에서 실행되며, 각 계층 간 호출은 직접 수행 또는 비동기 메시징을 사용하여 수행된다. 또한 하나의 계층에 하나 이상의 기능(프레젠테이션 + 비즈니스 또는 비즈니스 + 데이터 또는 프레젠테이션 + 비즈니스 + 데이터 등)을 수행하도록 구성할 수 있다. 이 경우 각 계층을 별도의 시스템으로 분리하여 구성한 아키텍처보다 네트워크를 이용한 통신 등으로 인한 대기 시간을 감소시킬 수 있으나, 아키텍처에 대한 확장성 및 유연성은 상대적으로 낮아지게 된다.

 

각 계층은 바로 하위에 있는 계층으로만 호출을 수행할 수 있도록 구성되는 것이 일반적이며, 비즈니스 처리를 수행하는 어플리케이션의 일부 수정을 수행하는 것은 어려울 수 있어 빈번한 업데이트로 인해 새로운 기능을 추가하는 속도가 제한될 수 있다.

 

N-Tier 아키텍처는 이미 계층화 된 아키텍처를 사용하는 기존 응용 프로그램을 마이그레이션하는 데 적합하며, IaaS 또는 IaaS와 관리 서비스를 혼합하여 사용하는 응용 프로그램으로 가장 많이 사용되는 아키텍처이다.

2.3.2. Queue-Worker 아키텍처

Queue-Worker 아키텍처는 업무 처리 요청을 처리하는 Front-End와 이를 이용하여 실제 업무 처리를 수행하는 Worker(또는 Back-End)로 구성되어있으며, 이 Front-End와 Worker 간의 통신은 일반적인 Queue를 이용하여 비동기 방식으로 통신을 수행한다.

해당 Worker는 Queue에 저장된 작업 요청에 의하여 트리거되어 실행되거나, 또는 Queue에 대한 주기적인 확인(Polling) 작업을 통하여 수행이 필요한 작업 요청을 수신하여 해당 요청을 처리하도록 구성되어있으며,

 

Queue 기반 메시징 아키텍처는 N-Tier와 마찬가지로 단순한 아키텍처로 구성되어있으며, 자원 집약적 인 작업을 수행하는 업무요건에 적합하나 복잡한 업무 요건 등에서는 각 요청 간의 종속성을 관리하기가 어려울 수 있다.

 

2.3.3. Microservice 아키텍처

Microservice 아키텍처는 전체 비즈니스를 단독으로 실행 가능하고 독립적으로 배치될 수 있는 작은 단위로 기능을 분해하고 이를 서비스로 구성하는 아키텍처로, 하나의 업무 처리는 다수의 서비스들의 조합으로 수행되는 아키텍처이다.

이러한 서비스들은 API 호출을 통하여 상호간에 연계를 수행하며, Service Discovery와 API Gateway에 의하여 모든 서비스들의 엔드포인트를 단일화하여 묶어주고 API에 대한 인증과 인가 기능 및 메세지에 따라 여러 서버 노드로 라우팅 하는 기능을 수행한다.

 

각 서비스는 작고 집중된 개발 팀에 의해 구축 될 수 있으며, 개별 서비스는 팀간에 많은 조정없이 배포 될 수 있으므로 잦은 업데이트가 수행될 수 있다. 또한 Microservice 아키텍처는 N-Tier 또는 Queue 기반 메시징 아키텍처보다 구축하고 관리하기가 더 복잡하며, 업무요건을 서비스 형태로 개발하기 위한 개발자의 개발 능력도 필요하다. 하지만 Microservice 아키텍처는 업무요건에 대한 서비스로의 개발/테스트 및 실 업무 적용이 신속해 질 수 있다.

 

2.3.4. CQRS 아키텍처

CQRS (Command and Query Responsibility Segregation) 아키텍처는 데이터베이스에 대한 읽기 작업과 쓰기 작업을 별도의 작업으로 구분한다. 전통적인 아키텍처에서는 동일한 데이터베이스를 대상으로 필요한 데이터의 읽기 작업과 업데이트 작업을 동시에 수행하는 것이 일반적이며, 이러한 구성은 하나의 업무가 변경을 위하여 데이터를 Lock하고 있는 경우에 이를 참조하기 위한 다른 업무는 참조하고자 하는 데이터의 변경작업이 완료될 때 까지 대기하여 전체 시스템에 대한 성능이 저하되는 결과를 가져오게 된다.

 

이러한 문제를 해결하기 위하여 데이터를 물리적으로 읽기 작업을 수행하는 부분과 업데이트 작업을 수행하는 부분을 시스템 적으로 분리 구성하여 읽기 및 쓰기 작업 부하를 수행하는 시스템에 대하여 독립적으로 확장이 가능하도록 구성할 수 있으며, 각 시스템에서 수행되는 쿼리에 대하여 독립적인 최적화 수행이 가능하도록 구성할 수 있다.

 

CQRS는 대규모 사용자 또는 업무가 집중되는 아키텍처의 데이터 계층에 적용될 때 가장 적합한 아키텍처이며, 일반적으로 많은 사용자가 동일한 데이터에 액세스하는 경우에 해당 아키텍처의 적용을 고려할 수 있다.

 

---

[6] 본 가이드에서 설명하고 있는 클라우드 아키텍처 패턴 외에 추가적인 패턴은 http://en.clouddesignpattern.org/index.php/Main_Page 및 https://docs.microsoft.com/ko-kr/azure/architecture/patterns/ 참조

3.  아키텍처 레퍼런스 모델

---

각 클라우드 솔루션 제공업체에서는 각 업무 도메인, 기술 특성별로 아키텍처에 대한 Reference를 가지고 있으며, 이를 활용하여 전체 업무 도메인 Set를 구성하는게 가능하다.

향후, LG CNS에 특화되어 있는 MSA 아키텍처에 대한 Reference 모델을 획득하게 된다면,  Cloud Formation과 같은 아키텍처 구성 도구를 활용할 수 있을 것이다.

 

현재, 각 클라우드 솔루션 업체에서 제공하고 있는 Reference 모델을 분석한 결과 유사한 형태를 보이고 있으며, 차이가 발생하는 부분은 아키텍처를 구성하고 있는 각 구성요소에 대한 명칭으로 판단되어, 이 중 AWS를 대상으로 참조할만한 MSA 아키텍처 모델을 선정하여 공유한다.

해당 내용은 Microservice Architecture 특히 API 중심적인 아키텍처 모델에 대하여 기술하고 있다. AWS에서 제시하는 방향은 기존 자체 제작하는 API 서비스 인프라를 좀 더 AWS에서 보장하는 가용성/확장성을 최대한 활용하여, 표준 아키텍처를 발전시키는 형태로 되어 있다.

• 표준 아키텍처 #1

  아키텍처구성도
  설명	API Gateway를 EC2 VM을 이용하여 자체 구성한다. Application Layer는 기존 구성과 큰 차이 없이 Legacy 시스템을 그대로 활용하거나, 독립된 서비스로 구성한다.
  적용범위	기존 Legacy System에 대하여 API Wrapper를 제공하고자 하는 경우
  특징	Application Layer와 API Layer를 기본적으로 분리하여 활용

• 표준 아키텍처 #2 (API Gateway 이용)

  아키텍처구성도
  설명	API Layer를 API Gateway를 활용하여 구성 기존 Application Layer는 일반 3Tier 구조에서 AP-DB 구성을 따름
  적용범위	일반적인 상황에서 적용해야 할 구조
  특징	API Gateway를 도입하기 위해, Application Layer에 추가적인 인증 모듈을 설치 구성해야 함

• 표준 아키텍처 #3 (컨테이너 이용)

  아키텍처구성도
  설명	기존 Application Layer(WAS/AP)에 Container 서비스를 적용하여, 적절한 수준의 AP Image를 통해, Instance에 대한 Auto scaling을 좀 더 세밀하게 조절 가능
  적용범위	향후, Docker/RocketOS 와 같은 Container 솔루션 내재화 후 활용(예정)
  특징	Docker Image를 이용한 Immutable Server 구성을 수행할 수 있음

• 표준 아키텍처 #4 (Serverless)

  아키텍처구성도
  설명	DB Layer를 DynamoDB와 같은 Key-Value 스토리지에 저장하고, Application Layer는 Lamda와 같은 Operation제공 기능만 활용하게 되면, EC2와 같은 서버 자원 할당 없이, 특정 기능을 수행할 수 있음
  적용범위	특정한 단위 업무 처리에서 한정적으로 처리 가능 (Lamda 특성 상 Connection Pool 등 미지원으로 Persistent Layer RDS 사용시 주의할 필요가 있음. Dynamo DB는 Autoscaling이 되므로 이슈가 없음)
  특징	Servless 아키텍처로 API 를 노출할 수 있는 대표적인 아키텍처임

4.  서비스 분산 설계

---

기존 모놀리딕 구조에서는 전체 Domain에 대한 테이블이 통합 데이터베이스 형태로 RDBMS에 포함되어 있으며, 개별 Domain은 논리적인 구분으로만 활용되었다.
향후 전개될 MSA 구조에서는 개별 Domain이 물리적으로 분리되어 있는 독립적인 DB를 구성할 수 있으며, 물리 구현시에는 기존 RDBMS를 포함해서, NoSQL이 될수도 있으며, 아니면 아예 Message Stream형태로도 저장될 수 있다. 

그림 4. 서비스분산/DB 분산 구성도
위와 같이 서비스 구분을 통해서 발생할 수 있는 설계상의 이슈를 해결하기 위한, 기본적인 설계 원칙과 개별 이슈에 대한 솔루션을 제공한다. 

4.1. 기본설계 원칙

기본적인 서비스 단위 설계 원칙은 아래와 같으며, 세부 내용은 분산설계가이드를 참조한다. 

• 하나의 트랜잭션으로 처리 가능한 단위를 Bounded Context 로 구성한다.
• Conway's Law와 같이 분리되어 있는 조직 업무를 시스템으로 구성할 경우, 조직 단위가 업무 단위로 변형하는 것을 고려한다. (예: 주문처리, 광고/마케팅, 배송)
• 분산 트랜잭션은 피할 수 없으나, 과도한 분산 트랜잭션이 발생하는 경우, Context 조정을 고려하여야 한다.

• 여러 Service에서 사용하는 Entity의 경우, 이를 적절하게 배포하여, 사용할 수 있게 해주는 [중복 Entity 처리 방안] 이 구성되어야 한다

• 기존 2PC 처리외에도 업무 변경 및 인터페이스 변경등을 통한 [Service간 Transaction 처리 방안]이 구성되어야 한다.

분산된 서비스는 각자가 독립적인 기능을 표시하게 된다. 따라서 개별 서비스의 Persistent Layer는 독립적인 자기 완결성을 가지고 있어야 하며, 외부 Domain에 있는 자료를 소모할 경우 외부 Entity에 사용에 대한 독립적인 설계가 필요하다. (예: 별도의 전달 Channel 설계) 

4.2. 중복 Entity 처리 방안

서비스를 분산한다는 이야기는 데이터의 관점에서 중복을 허용할 수 밖에 없으며, 이를 해결하기 위한 다양한 방안 가지고 있어야 한다. 
각 서비스간 중복된 Entity에 대한 처리 방안은 아래와 같다. 

 
그림 5. 중복 엔티티 처리 방안

분산 Entity에 대한 솔루션을 결정하기 전에 해당 Entity가 가지고 있는 자료 특성을 이해하여야 한다. 
Entity에 대한 자료 발생량이 많은가, 조회 빈도가 높은가, 자료 정합성 측면에서 Master Node의 변화에 즉각적인 반응(적시성)이 필요한가 등이다. 
해당 Entity가 발생량이 많을 경우,

1. 해당 Entity를 꼭 동기화 해야 하는 것인지, Shared DB, Remote DB 등과 같은 조회만 가능한 방안을 도입할 수 있는지
2. Service를 통해서 충분히 기능 전달을 받을 수 있는 것인지 (Service Interface)

먼저 확인해 보아야 한다. 과도하게 발생하는 로그성 자료를 과연 Sync Replication과 같은 DB 에 높은 부하를 주는 쪽으로 설계한다면 이는 잘못된 접근 방식이라고 볼 수 있다. 
두번째로 고려할 내용은 해당 Entity를 사용하는 외부 Service입장에서 얼마나 자주 그리고 얼마나 많은 자료량을 활용하는가이다. 활용율이 높다면,

1. 로컬에 사본을 두고 직접 활용하게 하는 방법 (DB Replica, CDC)
2. 아니면, 직접 해당 DB를 보는 방법 (Shared DB)

등을 생각해 보아야 한다. 
마지막으로, 해당 Entity가 자주 변경되는 항목으로, 외부 Service에서 상태 변경을 모니터링 하거나, 직접 활용해야 하는 경우에는

1. 직접 해당 DB를 보거나(Shared DB, Remote DB)
2. 아니면, 동기화된 사본을 보거나 (Sync Replica)
3. 이도 저도 안된다면, Event Publish/Subscribe를 통한 Event 모니터링

을 활용해야 한다.

공통 코드와 같이 발생량이 적고 / 활용율이 높고 / 적시성이 낮을 경우에는 솔루션 선정(DB Replica, CDC, Message)이 용이하나, 업무 도메인에 속해있는 Entity의 경우, 개별 특성을 잘 파악하여 Trade Off 관계를 파악하고 솔루션을 적용하여야 한다.

아래와 같은 [중복 Entity에 대한 솔루션 적용 Matrix]를 제시한다. 

솔루션 명칭	자료복제 여부	적시성 수준	대량자료발생 적합	대량자료조회 적합	응답성	기타 고려 사항
Shared DB (통합 DB)	X	상	적합	적합	상
DB Link/Remote DB	X	상	적합	낮음	중
Replication/CDC	O	중	중간	적합	상	DB 특성이 있음 CDC 별 솔루션 특성고려
Message	O	중(하)	중간	적합	상	거의 대부분의 솔루션에 적용 가능
Batch / ETL	O	하	적합	적합	상	적시성이 높은 쪽에는 활용이 어려움
Service Interface	X	중	적합	낮음	중	대량자료조회시에는 서비스 인터페이스가 맞지 않음

표 9. 중복 Entity에 대한 솔루션 적용 Matrix 

중요한 것은 개별 Entity마다, 상황이 다른 점을 인식하고, 맞춤형 솔루션을 제시할 수 있어야 한다는 점이다. 
다음 예제들을 통하여, 각 상황별 솔루션 선정을 수행해 보자. 

4.2.1. 중복 Entity 처리 방안 1 (예시)

• 상황 : 공통 코드 테이블에 대해서 변경이 발생하였다. 현재 공통 코드 테이블은 시스템 공통 코드와 업무 공통 코드가 섞여 있다. 어떻게 처리를 해야 하는가?
• 시스템 특성 : 공통 코드는 표준 코드 관리 시스템을 사용하여 배포될 예정이며, 코드 배포는 특정 시간에 걸처 진행될 것이다.
• 부분복제 가능성 : CDC 솔루션 적용이 가능하며, DB도 MySQL(MariaDB)를 이용

위와 같은 상황에서 중복 Entity인 공통코드를 어떻게 사용하고 있는지, 사용 패턴을 확인하면 명확하다. 
먼저, 사용 빈도가 많은지 적은,. 사용자 측면에서 접근하는 방법이다. 사용이 많다면, 복제를 통하여 내부에서 처리하는 것이 좋으며, 사용이 적다면, API Interface를 통하여 필요할 때마다 Lookup하는 것이 좋을 것이다. 공통코드는 사용 측면에서 많은 조회를 발생시키기 때문에, 내부 복제를 통한 Local 조회가 권장될 수 있다. 
두번째는 해당 자료의 생성 측면에서 접근하는 것이다. 발생이 많다면, 전체 Row를 복제를 통하여, 전파를 시도할 경우, 네트워크에 많은 병목을 발생시킬 수 있을 것이다. 따라서 발생량에 따라서 솔루션 선정을 수행하여야 한다. 이번 예제에서 등장한 공통코드의 경우 발생양이 한정되므로, Row별 복사를 수행해도 큰 문제가 발생하지 않는다. 
세번째는, 해당 자료를 소진하는 측에서 해당 Entity에 대한 적시성이 필요한 지 여부다. 공통코드를 예로 들면, 코드 담당자가 코드 관리 시스템에서 변경된 코드에 대한 반영을 진행할 경우, Master Node와 실제 내부 서비스에 있는 사본간에 불일치가 얼마나 빨리 반영되는지가 중요할 경우, 적시성이 높다고 할 수 있다. 현 시스템에서는 그 차이가 중요하지 않다고 가정한다. 
즉 정리하면, 다음과 같은 표를 구성할 수 있다. 

	적시성	대량자료 발생	대량자료 조회	기타
업무특성	하	적음	많음

표 10. 업무 특성별 요건 구분

위 내용을 토대로 우리는 아래와 같은 솔루션을 선정할 수 있다. 

	적용여부	자료복제 여부	적시성 수준	대량자료발생 적합	대량자료조회 적합	응답성
Shared DB (통합 DB)	X	X	상	적합	적합	상
DB Link/Remote DB	X	X	상	적합	낮음	중
Replication/CDC	O	O	중	중간	적합	상
Message	O	O	중(하)	중간	적합	상
Batch / ETL	O	O	하	적합	적합	상
Service Interface	O	X	중	적합	낮음	중

표 11. 요건별 솔루션 선정 기준

4.2.2. 중복 Entity 처리 방안 2 (예시)

• 상황 : 프레임워크 로그 테이블에 대하여 공통 시스템에서 통계 조회를 요청함
• 시스템 특성 : 프레임워크 로그 테이블은 CUD가 순간적으로 많이 발생할 수 있는 테이블임 조회는 전체 ROW가 아닌 Aggregate된 최종 결과 값만 조회하면 됨
• 부분복제 가능성 : CDC 솔루션 적용이 가능하며, DB도 MySQL(MariaDB)를 이용

위와 같은 상황에서 로그 테이블 Entity의 특성과 사용하는 내용을 살펴보면 아래와 같다.

 

통계 정보를 활용하는 쪽은 [공통 시스템]이며, [프레임워크 서비스]에 있는 로그 테이블 Entity에 대한 통계 자료를 요청하는 경우이다. 이럴 경우, 로그 테이블 Entity전체 Rowset이 필요한가? 결론은 전체 Rowset이 아닌 일부 Aggregate 된 결과 값만 필요하다. 이럴 경우, 조회 결과의 Size나, 자료의 양은 전체 Rowset의 부분일 수 밖에 없으므로, 전체 Rowset을 동기화 하는 방향보다는 Service Interface를 통해서 가져오는 것이 낫다.

 

로그 테이블 Entity측면에서 보아도, 로그 테이블은 자료 발생량이 많은 편이다. 즉 해당 로그 테이블 Rowset 전체를 동기화 한다는 것은 시스템 전체적으로도 많은 부하를 발생시키는, 좋지 않은 패턴이 된다.

 

정리하면 업무 상황은 아래와 같다. 

	적시성	대량자료 발생	대량자료 조회	기타
업무특성	중	높음	적음

표 12. 업무 특성별 요건 구분

이에 대한 솔루션 선정 결과는 아래와 같다. 

	적용여부	자료복제 여부	적시성 수준	대량자료발생 적합	대량자료조회 적합	응답성
Shared DB (통합 DB)	X	X	상	적합	적합	상
DB Link/Remote DB	X	X	상	적합	낮음	중
Replication/CDC	O	O	중	중간	적합	상
Message	O	O	중(하)	중간	적합	상
Batch / ETL	O	O	하	적합	적합	상
Service Interface	O	X	중	적합	낮음	중

표 13. 요건별 솔루션 선정 결과 

4.2.3. 중복 Entity 처리 방안 3 (예시)

• 상황 : 상품 항목은 자산 관리 시스템에서 등록하나, 상품별 재고관리는 입/출고 관리 시스템에서, 실제 상품을 활용한 출고 요청은 주문 시스템에서 수행한다. 재고 관리시스템에서 상품 (Product) 엔터티에 대한 처리 방안은?
• 시스템 특성 : 자산 관리 시스템의 상품 등록은 일부 담당자에 의해서 순차로 처리된다. 입/출고 관리 시스템은 센서 및 외부 시스템을 통해 대량 처리가 발생된다. 출고 요청에 대한 주문 시스템은 OLTP 성으로 처리된다.
• 부분복제 가능성 : CDC 솔루션 적용이 가능하며, DB도 MySQL(MariaDB)를 이용

업무 도메인에서 발생하는 경우에 대한 예시이다. 
상품항목은 거의 전 시스템에서 사용하는 공통 항목이며, 변경이 가능하고, 대부분의 시스템에서 중심Entity로 동작한다. 
사용 측면에서는 대부분의 Service에서 전체 Rowset에 대해서 조회할 확률이 높다, 발생 측면에서는 대규모 발생은 하지 않게지만, 업무 테이블이므로 중간 수준의 CUD가 발생할 것이다. 상품 변경이 전체 시스템에 대해서 매우 중요하게 판단하는 기초자료이므로, 적시성은 중~상 정도로 평가할 수 있을 것이다. 
정리하면, 업무 특성은 아래와 같다.

	적시성	대량자료 발생	대량자료 조회	기타
업무특성	중	낮음	높음

표 14. 업무 특성별 요건 구분

이를 통한, 솔루션 선정 결과는 아래와 같다. 

	적용여부	자료복제 여부	적시성 수준	대량자료발생 적합	대량자료조회 적합	응답성
Shared DB (통합 DB)	X	X	상	적합	적합	상
DB Link/Remote DB	X	X	상	적합	낮음	중
Replication/CDC	O	O	중	중간	적합	상
Message	O	O	중(하)	중간	적합	상
Batch / ETL	O	O	하	적합	적합	상
Service Interface	O	X	중	적합	낮음	중

표 15. 요건별 솔루션 선정 결과

4.3. 서비스간 트랜잭션 처리 방안

서비스간 트랜잭션에 대한 업무 설계는 분산모델링 가이드에서 설명하고 있으며, 여기서는 분산 트랜잭션에 필요한 기술요소와 이에 대한 배치를 기술한다. 
분산 트랜잭션에서 중요한 부분은 Global Lock과 분산 트랜잭션 Cordinator역할을 해 주어야 하는 중간 계층이다. 

• Global Lock

현재 대부분의 Monolithic 아키텍처에서 Lock 메커니즘은, DB에 있는 Row Lock을 이용하는 방식이다. 하지만, Service 간 개별 Transaction을 수행해야 하는 입장에서는 전체 Service와 독립적으로 전체 Service의 Lock을 관리해야 되는 Global Lock 메커니즘을 가지고 있어야 한다. 물론 개별 서비스 내에서의 Lock 메커니즘은 기존과 동일하게 DB의 Row Lock 메커니즘을 활용해도 되지만, 여기서 기술하는 것은 Service간 분산 트랜잭션을 수행하기 위해 필요한 부분이다. (Global Lock에 대한 세부 설계 및 구현 방안은 Phase 2에서 수행한다.) 

• 분산 Cordinator

분산 Transaction에서 중요한 부분은, 분산 처리진행 도중, 오류가 발생하였을 경우, 이에 대한 처리를 수행해야 되는 서비스와 독립적인 Cordinator가 필요한 부분이다. 여기서는 Redis를 이용한 분산 Cordinator를 가정하여 설계하였다. 

4.3.1. 분산 Cordinator 설계

분산 Cordinator는 서비스별 분산 트랜잭션이 처리되는 경우, 이를 제어할 메커니즘과, 오류가 발생할 경우 이를 방지하기 위한 2단계로 구분하여 설계할 수 있다. 쉽게 설명하기 위하여, Reservation Pattern을 활용하여 설명한다. Reservation pattern은 분산설계가이드를 참조하면 된다. 

• 제어 메커니즘

분산 트랜잭션에서 제어는 Global Lock을 이용하여 구현할 수 있다. 예를 들면 Reservation 단계에서 주문 수량을 넣을 경우, 주문 수량은 처리하기 전까지는 실제 재고에서 처리를 하지 않고 대기하고 있다가, 주문 처리가 끝난 이후, 재고 차감을 수행하면서, 주문 수량은 0으로 변경해야 한다. 이럴 경우, Redis와 같은 Persistent Layer에 (RDBMS도 상관 없음) 주문 수량을 별도로 관리하면서, 다른 주문이 들어오는 것을 방지하여야 한다. (아래와 같이, 주문에 대한 예약 주문수량을 지속적으로 관리하는 방법도 있음) 

 
그림 6. 분산 코디네이터 제어 메커니즘 구성도

• 두번째는 오류발생시 후속 진행을 처리하는 방법이 필요하다.

분산 트랜잭션은 두개 이상의 서비스에서 발생하는 트랜잭션이 동시에 처리되는 것을 가정하고 있다. 만약 서비스 진행도중 한 쪽 서비스에 문제가 발생하는 경우, 이에 대한 예외 처리를 수행하는 방안이 필요하다. 예를 들어 Reservation Pattern에서 예약을 건 주문 서비스 프로세스가 죽었다고 가정해 보자, 이럴 경우, 예약 처리된 주문 수량은 평생 사용할 수 없게 된다. 즉, 예외가 발생하였을 경우, 이를 보정하기 위한 추가적인 설계가 필요해진다. Redis/HBase의 경우, Expire 기능이 지원되며, 예약 수량에 Expired Time을 넣을 경우 자동적으로 예외 보정을 수행할 수 있다. 예시는 아래와 같다. 

그림 7. 분산 코디네이터 오류 발생 처리 흐름도

분산 Cordinator로 활용하기 위한 Redis 설계 방안은 Phase 2에 진행한다. 

5. 대량 처리를 위한 분산 설계 – 읽기 분산

일반적인 OLTP성 업무 시스템에서 Read : Write는 비대칭적으로 발생하는 경우가 대부분이다. 보통 8:2 ~ 7:3 정도의 분포를 보이나, 9:1로 읽기가 압도적으로 많이 발생하는 경우도 있다. 
이 때 읽기 성능 향상을 위하여, Database Read분산을 수행하면, 기존 Database를 Scale-Out하여 처리할 수 있다. 

5.1. 기본 설계 원칙

Read 분산에 대해서는 아래와 같은 사항을 고려하여 설계하여야 한다. 

• 현 시스템이 Read 수행이 Write 수행보다 확실히 많을 경우, Read 분산을 고려할 수 있다.
• 즉, 8 : 2 시스템을 Read 분산을 수행하여, Read를 외부에서 호출하게 하는 경우, Master Node는 5배 정도 처리 능력을 향상 시킬 수 있다. (Write만 수행한다고 가정)
• Slave Node에서 Read 분산을 수행하는 경우, Read/Write 경합을 줄여, Master Node의 Write Performance가 더욱 올라갈 수 있다.
• DB가 가지고 있는 Replication의 특성을 활용하여 Replication 계획을 구성하여야 한다.
• 동기 Replication의 경우, DB의 N개에 Commit되기 전까지 Commit 결과를 돌려주지 않기 때문에, 전체적인 Write성능이 낮게 나올 수 있다.
• 비동기 Replication의 경우, 비동기 특성상 Master Node와 Slave Node간 Time gap이 발생할 수 있기 때문에, 이를 고려하여 환경 설정을 조정하여야 한다.
• 메시지 시스템을 이용한 자료 동기화 방안의 경우, 서비스 분산/Read분산에 고르게 적용될 수 있으나, Time Gap을 고려하여야 한다.

위 내용을 기준으로 Read Replica 구성 방식은 아래와 같다.

생성 방안	적시성 수준	동일 DB여부	특징
Streaming Replication (Sync)	상	동일	DB에서 Sync Replica 지원이 되는 경우에 한정 (Postgres/PPAS) 성능 저하 발생 가능
Streaming Replication (Async/Semi)	상(중)	동일	DB에서 Streaming Replication 지원 (Postgres/MySQL 류)
CDC	중	동일하지 않아도 됨	CDC 솔루션에 따라 일부 특성이 달라질 수 있음
Queue + Avro	중(하)	동일하지 않아도 됨	Master Node가 일반 RDBMS가 아니어도 됨

표 16. 읽기 분산 요건별 솔루션 선정 결과

그럼 솔루션 선정 수행을 예시로 진행해 보기로 한다.

5.1.1. 읽기 분산 처리 방안 1 (예시)

• 상황 : 상품 조회 목록을 제공하는 서비스이다. 상품에 대한 세부 정보도 같이 REST 로 노출되며, 상품 등록은 개별 MD가 업체를 섭외하여, 상품을 등록하기 때문에, OLTP성으로 등록이 된다.
• 시스템 특성 : 상품 등록과 조회에 대한 수행 능력 비율은 95 : 5 정도로 읽기에 특화되어 있으며, 상품 세부 정보 조회를 사용하는 서비스는 주로 외부 시스템에서 사용된다.
• 현재 Master Node는 MySQL 로 구성되어 있다.
• Read Replica는 MySQL, Redis 등으로 구성할 예정이다.

위와 같은 상황에서 먼저 고려해야 할 사항은 Read Replica를 Cache로 처리할 수 있는지 여부를 확인하여야 한다. Redis와 같은 In-Memory 솔루션의 경우, 단순 조회 성능은 일반 Disk기반 RDBMS가 제공할 수 없는 고성능을 제공할 수 있다. 이럴 경우, Cache Value에 대한 Validation을 어떻게 처리할지 고려해야 한다. 
크게 보아서는 Cache는 Read Replica의 다른 측면으로 볼 수 있다. 즉 Master Node는 RDBMS를 사용하고, Read Replica는 NoSQL 데이터베이스인 Redis로 접근한 경우이다. 하지만, 이럴 경우 RDBMS 스키마 정보가 NoSQL 데이터베이스와 일치하지 않기 때문에 Application에서 사용할 수 있는 형태로 변형된 것이 Cache로 볼 수 있다. 
현재 사용하는 DBMS는 MySQL DB로 Replication이 자체 내장되어 있으며, async/semi-sync 동작 방식을 제공하고 있다. 이럴 경우, MySQL DB Replica를 이용하여, Read Transaction을 분리하는 것이 간단한 설정으로 수행될 수 있다. 
현재 업무 상황을 정리하면 아래와 같을 것이다.

	적시성 수준	동일 DB여부
업무 특성	중	동일

표 17. 읽기 분산 업무 요건

여기에 적절한 Read Replica 구성방안은 위에 논의한 바와 같이, Schema가 복잡하지 않고, Cache적용이 용이할 경우에는 Redis와 같은 NoSQL DB를 Read Replica로 이용하고, Schema가 복잡하고 많은 내용을 전달할 경우에는 Master Node와 동일한 MySQL을 활용한 구성이 적절할 것이다. 

생성 방안	적시성 수준	동일 DB여부	특징
Streaming Replication (Sync)	상	동일
Streaming Replication (Async/Semi)	상(중)	동일
CDC	중	동일하지 않아도 됨
Queue + Avro	중(하)	동일하지 않아도 됨

표 18. 읽기 분산 요건별 솔루션 선정 결과 

5.2. Read Replica 동기화 방안

개별 Persistent Layer간 Read Replica 지원 방안은 추가적인 설계 고려 사항이 필요하므로, 설계시에 참고할 내용을 추가로 명시한다. 

5.2.1. Sync/Async Stream Replication

• PostgreSQL Streaming Replication 환경에서는 Primary 노드에서 생성 및 변경된 데이터가 다른 노드로 near real timed replication 되므로, 디스크 용량이 확보되어야 한다.
• Primary 노드에서만 Read/Write가 가능하므로, 조회전용 업무를 식별하여 다른 노드로 연결시켜야 한다.
• Primary 노드에서 대량의 DML이 발생하면 delayed replication이 발생하므로, CPU, Network bandwidth, PostgreSQL 서버 파라미터 중 Replication과 관련된 것 (max_Standby_streaming_delay 등)에 대한 검토가 필요하다.

그림 9. Read-Replica 스트림 동기화 구성도

5.2.2. CDC(Change Data Capture)

CDC는 소스 시스템에서 발생하는 데이터의 변경내용을 실시간으로 Capture하여 해당 데이터가 필요로하는 시스템으로 변환 및 복제해 주는 데이터 통합 솔루션으로, AWS의 경우 CDC는 온프레미스와 EC2 SQL Server에서 지원됩니다. Amazon Aurora는 RDS에서만 사용 가능하다. 

기본 아키텍처(예, OGG)

1) EXTRACT Process : Redo/Archive Log로 부터 Commit된 Transaction 변경분을 Read하여 Source Trail에 변경정보 저장 2) REPLICAT Process : Target Trail을 Read하여 주어진 Mapping Rule 조건에 맞게 Target DB에 Insert/Update/Delete 수행 (SQL문 생성), SQL 생성 시 파라메터 파일의 맵핑 정보를 참조. : 생성된 SQL과 Target Trail의 데이터를 결합하여 SQL문 완성 : Database Native API를 호출하여 데이터베이스에 적재 3) Manager Process : OGG 전체 Process들에 대한 제어 및 Monitoring 4) Source/Target Trail : Capture된 변경정보 데이터를 저장하는 File

5.2.3. Kafka+Avro

• Kafka 

구분	상세 설명
정의	Apache Kafka는 스트리밍 데이터를 사용하여 실시간 애플리케이션을 구축할 수 있게 해주는 오픈 소스 분산 메시징 시스템이다. 웹 사이트 클릭스트림, 금융 트랜잭션 및 애플리케이션 로그와 같은 스트리밍 데이터를 Kafka 클러스터에 전송할 수 있으며, Kafka는 데이터를 버퍼링하고 Apache Spark Streaming, Apache Storm 또는 Apache Samza를 비롯하여 프레임워크에 구축된 스트림 처리 애플리케이션이다.. 고성능의 분산 메세징 시스템 기존 큐와 다르게 메모리 기반이 아니라 파일(디스크) 기반 => 높은 데이터 안정성 Message Queue 역하과 Log Aggregation 역할을 함께 할 수 있음 LinkedIn에서 모든 실시간 데이터를 다루기 위한 통일된 플랫폼으로 만들어져서 2011년 오픈 소스로 공개 다양한 플랫폼과 테크닉에 구애받지 않고 하나의 메시지 시스템이 받아서 분산 처리 하기 위해 만들어짐
특징	Fast: 단일 카프카가 1초당 몇 천개의 client로부터 유입되는 수백 메가바이트 처리 가능 Scalable: 유입되는 데이터는 파티션으로 분할되어 여러 대의 클러스터에 보내짐 => 한 대의 서버에서 처리할 수 있는 양보다 더 큰 데이터도 처리 가능 Durable: 메시지가 디스크에 저장되고, 유실을 막기 위해 클러스터에 복제 Distributed by Design; 강력한 데이터 복제와 장애 복구를 보장하는 근대적인 클러스터 기반의 디자인 채용
구조	Producer  데이터가 들어오는 부분  데이터를 토픽(특정 파티션)으로 전송  partitioner interface를 구현하면 파티션에 분배 방법 지정 가능 (default : round-robin)  broker로 메시지 보낼 때 sync/async 가능 Broker 클러스터로 구성된 큐 Consumer 큐에 저장된 데이터를 가져가는 부분 queuing : consumer의 pool에서 서버로부터 각 메시지를 읽어들임 publish-subscribe : 메시지가 모든 consumer에 broadcast
AWS에서 Kafka를 실행하는 방법	Amazon EC2에서 Kafka사용하기 위해 EC2 인스턴스 유형을 선택 및 프로비저닝하고, Kafka 및 Apache Zookeeper를 비롯한 소프트웨어 구성 요소를 설치 및 구성한 다음, Amazon Elastic Block Store(EBS)를 사용하여 스트리밍 데이터 처리량을 수용하는 데 필요한 블록 스토리지를 프로비저닝해야 한다. Kafka 클러스터가 예상치 못한 이벤트(스트림의 용량 한도를 넘는 데이터 볼륨의 스파이크 등)를 관리할 수 있도록, Apache Zookeeper를 사용해 복제를 구축할 도 있다. Kafka가 설치되면, Kafka 클러스터의 보안을 위해 HTTPS를 배포하고, 인증 기관을 유지 관리하며, SSL용 Kafka 인스턴스를 구성해야 한다.

표 19. 동기화 - Kafka 솔루션

• Apach Avro

구분	상세 설명
정의	Thrift, protocolBuf와 비슷한 데이터직렬화를 지원하는 라이브러리로 RPC호출과 파일에 데이터를 저장하는 기능이 있다
특징	지원언어: C/C++, Java, PHP, Python, Ruby 풍부한 데이터구조: 작고 빠른 바이너리 타입 지원 컨테이너 파일을 영구적으로 저장 바이너리 구조의 데이터와 JSON구조의 데이터통신 Schema지원 Thrift에 비해 개발이 활발하고 카산드라의 내부 인터페이스로 사용
AWS에서 AVRO를 실행하는 방법	Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 분석할 수 있는 대화식 쿼리 서비스로 Amazon S3에 저장된 데이터를 지정하고 스키마를 정의한 후 표준 SQL을 사용하여 쿼리를 하면 대부분 결과가 수 초 만에 제공된다. ANSI SQL을 지원하는 Presto를 사용하며, CSV, JSON, ORC, Parquet와 함께 호환이 가능한  표준 데이터 형식으로 Avro가 포함되어 있다

표 20. 동기화 – Apache Avro

5.3. N Slave에 대한 처리 방안

Read Replica가 한 개만 생성되는 경우, Application Server에서 Datasource 설정은 매우 간단하게 설정할 수 있다. 하지만 Read Replica는 Scale-Out이 가능하고, Scale-Out이 동적으로 수행되는 경우, 이를 지원하기 위한 Application Layer에서의 지원 방향이 필요하다. 

5.3.1. N Slave 적용 시 설계 원칙

• Read Replica가 구성되었을 경우, Master 1개, Slave N개를 고려하여 설계한다.
• Slave Node N개에 대한 부하 분산이 가능한 구성을 하여야 한다.
• 분리된 데이터 소스는 개별적으로 CUD 수행과 이를 지원하는 소스 패키지로, Query를 수행하는 소스 패키지로 구성해야 한다.
• Read Replica는 기본적으로 Transaction 처리가 불가능하므로, Transaction Manager 구성시에도 Master Node Datasource와 분리하여 구성하여야 한다.

5.3.2. 구현 방안

위와 같이 Application Layer에서 Slave N개에 대한 대응방안을 고려해 보면 아래와 같은 구성이 가능하다. 

그림 10. N-Slaver 처리 구성도

첫번째 방안은, DNS를 이용한 구성방안이다. DB에 접근할 경우, IP로 접근하는 방식이 아니라, Domain Name을 이용하여 접근하되, Slave Node N개의 IP에 대하여 DNS에서 Round-Robin방식으로 IP를 제공해주는 방식이다. 이럴 경우, AP에서 Connection Pool 생성 시 DNS에 먼저 Lookup을 수행하여, Slave N개 중의 하나를 선정한 후 그 값을 돌려주면, AP는 선정된 IP를 활용하여, Slave Connection Pool을 구성하는 방식이다. 다시말해, Lookup Time에 Slave DB Node가 정해지며, Connection은 하나의 Slave Node에 쏠리는 방식이다. 이 방식은 추가적인 컴포넌트가 필요한데, 바로 모니터링 도구이다. 모니터링 도구는 각 Slave들의 상태 체크를 수행하여, 해당 Slave Node가 비활성화 될 경우, DNS에 있는 Entry에서 해당하는 Slave IP를 제거하는 역할을 수행하여야 한다. 현재 AWS RDS에서는 이 구조가 이미 설정되어 있기 때문에 별도의 추가 설정 없이 이 구조를 활용할 수 있다. 

두번째 방안은, Middle Tier를 활용한 방안이다. MySQL의 경우, MaxScale, PostgreSQL의 경우는 PgPool과 같은 Middle Tier를 이용하여, Multi Slave에 대한 Connection을 Middle Tier에서 모두 관리하도록 Role을 부여하고, AP에서는 Middle Tier를 이용하여, N개의 Slave에 접근하는 방식이다. 이 방식의 장점은, 고르게 Connection이 분포될 수 있다는 점이나, Node 확장시, Middle Tier를 재기동해야하는 문제점이 있을 수 있다. 
세번째 방안은, AP와 DB 사이에 L4를 끼워 넣는 형태로 Load Balancing을 유도하는 방식이다 이 방식의 장점은 L4를 이용하기 때문에, Latency에 대한 문제점도, Autoscaling 발생해는 Node추가 시 발생할 수 있는 작동 중단의 문제도 없다. 하지만 이 경우, 오류가 발생할 경우 세밀한 Control이 불가능하여(단순 Watcher 기능만 활용 가능) 많이 활용되지는 않는다. 
AWS에서 Read Replica를 구성할 경우에는 첫번째 방안을 이용하여 구성하는 것으로 한다. 

6. 대량 처리를 위한 분산 설계 – 쓰기 분산

대량의 조회가 들어오는 경우, 읽기 수행은 Replica를 이용한 Read Node의 Scale-Out으로 처리할 수 있다. 하지만, 쓰기 수행의 경우, 쓰기는 DB/IO 별로 한계가 존재한다. 
DB는 기본적으로 두가지 Write Operation을 수행한다. 하나는 Dirty Buffer에 대한 Random I/O(Write)이며, 하나는 Log Write(예를 들어, Oracle의 Redo log writer, PostgreSQL의 WAL Writer, MySQL Binlog등)에 대한 Sequence IO이다. 둘 중 하나라도 하드웨어 IO의 한계치에 도달하면 CPU Engine과는 상관 없이 DB자체는 Operation에 한계를 가질 수 밖에 없다. 
이를 해결하기 위한 몇가지 지원 방안을 살펴본다. 

6.1. 기본 설계 원칙

Write가 많은 대량의 자료 발생이 예상되는 서비스의 경우 아래 내용을 고려해서 설계하여야 한다. 

• 먼저, 하나의 DB Node에서 Range Partitioning/Hash Partitioning을 이용하여 Block Contention을 방지할 경우, 해결되는 수준인지 확인한다.
• 들어오는 양이 많아 IO자체가 병목이 되는 경우 DB 분리를 생각한다.
• 최초의 DB 분리 방법은 서비스 분리 방안이며, 다량의 중요한 자료가 들어오는 서브 도메인이 있을 경우, 이는 독립될 수 있는 중요 업무영역으로 식별하여, 별도 서비스로 분리하는 것도 좋은 방안이 될 수 있다.
• 두번째는 Tenant나 지역적으로 전체 DB가 깔끔하게, 분할 될 수 있는지 확인하는 방법이다. Tenant나 지역적으로 분리가 되는 경우, Tenant별 DB를 생성하여, 원 DB의 Write 부하를 해결할 수 있다.
• 세번째 방식은 단위(사용자/상품)별 분리가 가능한 경우이다. 즉 특정한 Hash키를 이용하여 전체 DB를 분리할 수 있다고 한다면, Hash를 이용한 DB 분리를 고려할 수 있다. (Sharding)
• Sharding된 DB도 DB 자체적으로는 자료 무결성을 유지하는게 기본 원칙이며, Sharding은 가장 최후의 수단으로 활용된다.

Tenant 분리 방안/지역 분리 방안은 분산설계가이드를 참조하면 된다. 환경 구성시 고려가 필요한 주요 경우는 Shard에 대한 내용으로 Shard 구성시 결과 값에 대한 Aggregation 방안이 필요하다. 

6.2. Aggreation 구현 방안

Aggregation도 다양한 의미로 활용될 수 있다. 각 Data Node별로 서로 Cross되게 Join도 되고, Aggregation(Groupoing)도 되는 복잡한 형태도 가능하고, 단순하게 개별 Node에 대한 결과값을 Union처리하는 방안도 고려해 볼 수 있다. 하지만, 첫번째와 같은 경우는, DB가 자체적인 자료 무결성이 있다고 한다면 거의 발생할 이유가 없으며, 단순하게 개별 Node에 대한 결과값에 대한 Union/Aggregation만 고려하면 된다. 
일단, Aggregation을 실제로 구현한 수 있는 다양한 방법을 살펴보면 아래와 같다.

 
그림 11. N-Slaver 처리 구성도

많이 활용되지는 않으나 업무적으로 적시성(timeliness)이 필요하면서, 대용량 조회가 안되는 경우, DB 자체적인 기능을 활용하여 풀 수도 있다. 즉 DB LINK나 Remote DB 형태의 DB간 조회 기능을 이용하는 방식이다. Node간 Cross 된 형태로 Column간 Join이 발생하면서, Return Result가 적을 경우, 사용을 고려해 볼 수 있을 것이다. 
또 다른 방법은 Aggregated DB(Reporting DB)를 활용하는 방식이다. 이는 개별적으로 나뉘어져 있는 Node 정보를 하나의 거대 DB에 축척하여 View진행 시에는 통합 DB를 이용하는 방법이다. 하지만 잘 생각해 보면, Write Intensive한 자료가 들어오는 시스템의 자료를 어떻게 하나의 시스템으로 통합 할 수 있는지 고려해보아야 한다. 가장 널리 이용되는 방법은 HDFS와 같은 Big Data 시스템과 Impala와 같은 Query Middleware를 혼용하여 사용하는 방법이다. 이 경우, Write Intensive한 부분은 HDFS의 개별 Node에서 담당하고, Query를 이용하여 편리하게 Aggregated된 자료를 조회할 수 있다. 
Batch/ETL 방법은 기존 대규모 자료 처리와 유사한 형태로 처리가 되는 경우에 한정된다. 이미 Write Intensive한 자료가 들어오는 상황에서 Raw Data를 그대로 Batch/ETL로 사본 생성을 유도한다기 보다는 Batch/ETL에서 Query에서 필요한 중간 테이블 생성한 후 이를 각자 Node에서 생성하였다가 활용하는 방식이다. 
제일 마지막 방법은, Application Layer에서 Message Queue와 같은 컴포넌트를 활용하여, Aggregator를 사용하는 방식이다. 이 방식을 활용하면 개별 Shard Node에 개별 Command 처리에 대한 Agent 를 추가해야 하며, 호출한 Node에서는 이를 Merge/Aggregation해 주는 방식이 필요하다. 이 형태는 개별 Node에서 처리된 결과를 단순하게 Union하는 경우 활용하는 것이 좋은 활용 방안이다. (이 방안은 Phase 2에서 수행) 
이를 정리하면 아래와 같은 Matrix가 나온다. 

생성 방안	실시간 적용 여부	복잡한 조회 기능 활요	DB Node간 JOIN	업무 중요도
Remote DB	높음	높음	중간	낮음
Agg. DB (Reporting DB)	높음	높음	높음	높음
Batch / ETL	낮음	중간	중간(Batch처리)	중간
Aggregation Module	중간	낮음	낮음	낮음

표 21. Aggregation 요건 

서비스 중에서 Write Intensive한 구조가 발생할 경우 서비스 특징을 잘 분석하여, 거기에 맞는 Write 분산 구조를 선정하여 활용한다. 

7. 대량 처리를 위한 분산 설계 – Hot & Cold 데이터

기존 데이터를 Migration해야 하는 경우, 기존 데이터베이스는 이미 십수년간 운영된 운영자료가 들어가 있는 경우가 많다. 사전에 데이터 라이프사이클 관리에 대한 정책을 수립하고 관리된 데이터베이스의 경우에는, Hot Data의 경우에는 운영 DB에 존재하고, Wam 데이터의 경우에는 Archive DB또는 조회성 DB로 이관되면, 법적/기록물적인 의미로서 존재하는 데이터의 경우, Archiving 된 상태로 존재하게 된다. 
문제는 Migration이 수행되는 순간에 아직 데이터 라이프 사이클 관리가 안된 경우이다. 이 경우, 데이터를 분리하여, 먼저 Data 활용도에 맞게 Data 재배치에 대한 설계를 사전에 수행하여, 실질적인 운영 DB에서 활용되는 Database의 사이즈를 확인하는 것이 필요하다. 
AWS에서는 Database별 Storage별로 저장 Cost가 달라지기 때문에 사전에 자료 분리를 수행하는 것이 필수 항목이다. 

7.1. 자료형태별 특성

운영 DB에 있는 자료는 Hot 상태로 판단해야 한다. 만약 오랫동안 활용되지 않는 자료라면 조정을 검토해야 한다. Hot 자료는 Online DB에 있기 때문에, OLTP의 경우 값이 지속된다기 보다는 변경 가능성이 높다고 보아야 하며, 그 응답성은 ms 단위로 매우 낮아야 한다. 이를 보장하기 위해서 스토리지도 IOPS와 Latency를 보장하는 고급 Storage를 사용하여야 한다. 
Warm 데이터의 경우, 조회는 간혹가다 들어오지만, 그 자료가 이미 최신 자료가 아닌 상태로, CUD 대상이라기 보다는 Query 대상으로 들어가는 경우이다. 이럴 경우, 간혹 가다 발생하는 조회를 위하여 대규모의 Cost를 투자하는 것 보다는 적절한 스토리지 및 DB engine을 활용해야 한다. 
Cold 데이터의 경우, 법적/자료보관적 의미로만 존재하며, Archiving 여부만 중요한 경우이다. 이럴 경우 복원 가능성과 저장 Cost에 대한 부분이 중요한 아키텍처 설계 요소로 작용한다. 
이를 정리하면 아래와 같다. 

	Hot	Warm	Cold
Volume	MB - GB	GB - TB	TB – PB
Item Size	B - KB	KB - MB	KB – TB
Latency	ms	ms, sec	min, hours
Durability	Low-High	High	Very High
Request Rate	Very High	HIgh	Low
Cost / GB	$$ - $	$ - Cent	Cent

표 22. 데이터 형태별 특성 

Legacy 시스템을 Migration하는 경우 Data Life Cycle을 고려하여, 운영 DB에 대한 Size및 분산 설계를 수행하여야 하며, 단순하게 크기에 의존적인 판단을 하면 안된다.