* 해당 글은 AWS Summit Seoul 2019 행사 중 둘째 날인 2019년 4월 18일 발표된 세션 내용을 듣고 작성하였음을 안내합니다. 행사 전체 세션은 향후 Youtube로 모든 내용이 공유되는 것으로 알고 있습니다. 상세 내용이 궁금하시면 영상을 참고하시면 좋을 듯 합니다.
AWS Summit에 참여하기 전 현재 클라우드에서 제공되고 있는 서비스를 간략히 확인한 적이 있는데 데이터베이스로는 기본적인 RDBMS와 NoSQL DB를 모두 제공하고 있음을 알 수 있었다.
이번에 들었던 세션은 클라우드로 이전하기를 원하거나 신규 구축을 하고자 하는 이들이 각자 서비스에 맞는 DB를 고를 수 있도록 현재 제공 중인 데이터베이스 종류를 알려주고 각 특징을 안내하는 구성으로 진행되었다.
AWS Summit Seoul 2019 - 2Day
<Application에 맞는 Database 선택하기>
데이터베이스의 변화를 시간 순으로 기술해서 보여주고 있다. 2010년 이후로 정말 다양한 종류의 DB가 쏟아져 나오고 있다. 데이터 유형이 다양해졌고 이에 맞는 새로운 서비스들이 출시된 것으로 예상된다.
이런 추세에 맞추어 클라우드 데이터베이스도 다양한 형태의 서비스를 선보이고 있다.
우리가 알고 있는 일반적인 데이터베이스의 종류가 모두 나열되어 있는 듯 하다. 각 데이터베이스의 특징과 어느 분야에서 사용할 수 있는지에 대한 예시가 함께 표시되어 있다.
해당 장표를 통해 세션에서 알아볼 데이터베이스의 종류를 알아볼 수도 있다.
위에서 알아봤던 데이터 특성에 따른 AWS에서 제공하는 데이터베이스의 종류들이다.
일반적으로 알고있는 관계형 데이터베이스의 경우 AWS RDS와 매칭된다. Aurora를 비롯한 일반적으로 알고있는 오픈소스 DB인 MySQL, PostgreSQL, MariaDB 그리고 상용 DB인 오라클과 SQL Server등 대부분의 데이터베이스가 클라우드 형태로 호환 가능하다.
Key-value DB (키-값 데이터베이스) 의 경우 Amazon Dynamo DB
Document DB (문서 데이터베이스) 의 경우 Amazon Document DB
하드웨어를 최대한 이용하는 방식의 In-memory DB의 경우, Redis나 Memcached 등 캐시 메모리를 사용하는 데이터베이스 종류이다. AWS에서는 Amazon ElastiCache로 제공하고 있다.
데이터간의 관계가 중요한 경우 Graph 데이터베이스를 통해 표현한다. Amazon Neptune이 이런 기능을 제공하고 있으며, 시간별로 변화하는 데이터의 흐름을 봐야하는 경우 사용하는 Time-serial (시계열 데이터베이스) 는 Amazon Timestream로 제공한다.
Leager (원장 데이터베이스)의 경우 블록체인 기술을 적용하여 모든 데이터의 흐름을 저장하는 형태인데, Amazon QLDB를 이용하여 이런 기능을 사용할 수 있다고 한다.
각 데이터베이스의 특징을 알아보기에 앞서 데이터베이스 운영 방식을 비교하며 클라우드 데이터베이스 운영이 효과적인 이유에 대해 먼저 알아보자.
자가 관리형(Self Managed)이 기존의 형태로, 인프라에서부터 DB 설정 그리고 어플리케이션 최적화 단계까지 모두 사용자가 직접 관여해야하는 형태로 많은 부분에 손이 가는 형태이다. 하나부터 열까지 다 챙겨야했기 때문에 DBA와 인프라 관리팀의 영역이 매우 컸다고 볼 수 있다.
DBs on Amazon EC2의 형태는 DB 서버를 Amazon에 위치시키는 형태로, 인프라 관련되어 실제적인 DB 서버를 관리하는 역할을 AWS에 위임하는 형태이다. EC2 인스턴스에 올라간 서버에 대해서 AWS는 네트워크 구성 및 랙과 스택관리, 서버 운영관리 전반을 담당한다.
사용자는 물리적인 인프라 관리는 하지 않지만 향후 지속적인 패치 및 업그레이드 등에 대해서는 지속적인 관리를 해야한다. 아직 DBA의 역할은 많은 부분에서 남아있다고 한다.
최종적으로 완전 관리형 (Fully Managed). 물리적인 인프라 관리에서부터 패치 관리, 업그레이드, 백업 및 복원 등 전반적인 부분에 대해 모두 AWS에서 관리한다. DB 사용량이 늘어나서 증설해야 하거나 가용성 관리부분 모두 AWS가 담당해주므로 DBA는 어플리케이션에서 DB를 사용하는 부분에 대한 최적화만 담당하면 된다.
이제 실질적인 업무만 볼 수 있는 구조이다.
단, 완전 관리형을 사용할 수 없는 경우가 있다.
예를 들어 개인정보 보호법으로 인해 별도의 솔루션을 사용하여 데이터 암호화를 적용해야 하는 경우 RDS의 사용이 어렵다고 한다. 결국 회사 자체적인 제약사항이 있어서 사용자가 자체적인 관리를 해야하는 상황인 경우는 완전 관리형 DB로 변환하는 것은 어렵다.
AWS RDS로 변화하게 되면서 DBA의 역할이 변화하는 부분을 보여준다.
기존에는 Platform 영역이 컸는데, 이 부분은 장애가 발생하지 않기 위해서 미리 설정해야 하는 부분으로 패치 적용이나 물리/지리적 요소 등으로 인한 장애 방지를 위한 요소들 모두가 플랫폼 영역에 포함되었다.
Amazon RDS에 올라가게 되면 해당 영역은 AWS에서 제공하므로 불필요한 내용을 신경쓸 필요가 없어지고 Application단의 문제만 제어하면 된다.
이제 각 데이터베이스별 특징에 대해 알아보자.
우선 기존의 관계형 데이터베이스를 클라우드로 전환하는 경우 이용할 수 있는 Amazon RDS이다.
Amazon Aurora
- 완전 관리형 DB로 RDS의 장점을 모두 가지고 있음
- 일반 DBMS를 썼다면 바로 전환은 어렵다. 오라클DB의 경우는 스키마 및 SQL 변환 작업을 통해야 함. (단, MySQL의 경우는 바로 마이그레이션)
- 컴퓨팅과 스트리지가 분리되어 있어서 가용성이 충분한 성능을 낼 수 있음
- 병렬처리 기능을 제공함. 약 30분 처리되던 쿼리를 3분정도의 시간으로 1/10로 시간을 줄일 수 있었음
Amazon RDS on VMWare
- 현재 Preview 버전으로 완전하게 서비스되진 않지만 온프레미스와 클라우드 환경을 연결지어주는 서비스
- 온프레미스 환경에서 RDS 데이터베이스 배포 가능
- 하이브리드 방식으로 이용함. 클라우드로의 확장 및 백업 가능
Key-Value NoSQL 데이터베이스 형태를 제공하는 Amazon Dynamo DB
Amazon Dynamo DB
- 대표적인 NoSQL DB (Key-value 형태의 데이터베이스가 NoSQL의 대표이므로)
- 어떤 규모이든 일관된 성능을 제공함
- Serverless, On-Demand 방식을 적용하여 용량에 맞춰 자동으로 확장/축소하여 서비스 제공
- 트랜잭션 처리 기능이 제공되므로 서버가 없이 DB 자체적으로 트랜잭션 처리가 가능
문서 데이터베이스 방식을 제공하는 Amazon DocumentDB
MongoDB와 호환되는 데이터베이스로 빠르고 확장 가능하며 가용성이 뛰어나다. (이 특징은 사실 모든 AWS 데이터베이스가 가지고 있는 것 같다.)
Amazon DocumentDB
- 확장성이 좋고 고가용성 DB, Mongo DB를 더 대규모로 이용하고 싶을 때 고려할 수 있는 방안
- 컴퓨팅과 스트리지가 분리되어 있어서 가용성이 충분한 성능을 낼 수 있음
- 유연한 문서 모델, 데이터 유형 및 인덱싱 기능을 사용하여 성능은 물론 고가용성도 보장되는 애플리케이션을 신속하게 적용하여 개발 시간 단축 가능
- 이 역시 완전 관리형 DB로 패치 작업 및 설정, 구성, 백업 데이터베이스 관리 작업을 AWS에서 제공한다.
Redis, Memcached와 호환되는 In-memory 방식의 데이터베이스 Amazon ElastiCache
Amazon ElastiCache
- 메모리 기반의 데이터 스토어이므로 응답 시간이 매우 빠른 탁월한 성능을 자랑한다.
- 네트워크 격리, 송수신 중의 암호화, HIPAA, PCI, FedRAMP 인증, 다중 AZ, 자동 장애조치 등 보안 및 안정성이 탁월
- 주로 대규모 실시간 지리 공간 데이터를 빠르게 관리할 수 있도록 메모리 데이터 구조 및 연산자를 제공
- 주행 시간, 거리, 관심 지역 정보와 같은 위치 기반 기능을 가진 애플리케이션에 적용 가능
- Airbnb가 해당 데이터베이스를 아주 잘 사용하고 있는 사례로 볼 수 있음
위와 같이 데이터간의 관계가 중요해지는 상황에서 사용할 수 있는 DB에는 어떤 것이 있을까?
기존의 관계형 데이터베이스에서 데이터간 관계성이 증가하게 되면 연관 관계가 복잡해질수록 JOIN이 증가하게 되는데 모두 알듯이 JOIN이 증가할 수록 쿼리가 복잡하고 가독성이 떨어지게 된다.
이런 경우는 Graph 데이터베이스를 고려해볼 수 있겠다.
Amazon에서는 Neptune이라는 그래프 데이터베이스를 제공하고 있다.
Amazon Neptune
- 수십억 개의 관계 쿼리를 날리는 데 수 초도 아니고 수 밀리 초의 시간으로 조회가 가능하다.
- 뛰어난 성능뿐 아니라 가용성과 안정성을 가지고 있다.
- 데이터간의 관계를 확인하기 위해 Gremlin 및 SPARQL로 상호연결성이 높은 데이터 세트를 효율적으로 탐색할 수 있는 쿼리를 손쉽게 구축할 수 있다.
- 적용 사례 : 부정 탐지, 생명 과학, 지식 그래프, 네트워크/IT운영
* Gremlin : 그렘린(Gremlin)은 아파치 소프트웨어 재단의 아파치 팅커팝(Apache TinkerPop)이 개발한 그래프 순회 언어이자 가상 머신이다. 그렘린은 OLTP 기반 그래프 데이터베이스, OLAP 기반 그래프 프로세서와 함께 동작한다.
출처 : 위키백과 https://ko.wikipedia.org/wiki/그렘린_(프로그래밍_언어)
* SPARQL : SPARQL ("sparkle", 스파클, SPARQL Protocol and RDF Query Language의 재귀 약자)은 RDF 질의어, 즉 데이터베이스를 위한 시맨틱 질의어로서 자원 기술 프레임워크(RDF) 형식으로 저장된 데이터를 검색, 조작할 수 있다.
출처 : 위키백과 https://ko.wikipedia.org/wiki/SPARQL
시간을 축으로 해서 데이터가 생산되는 시계열 데이터의 경우, Amazon Timestream을 사용할 수 있겠다. App 이벤트 데이터, 센서 데이터, DepOps 데이터, 로그 데이터 등의 시간대별로 발생한 이벤트를 관리해야 하는 경우 시계열 데이터베이스를 사용할 수 있다.
Amazon Timestream
- 초당 수백만개의 데이터를 수집할 수 있으며, 데일리 이벤트를 손쉽게 저장/분석할 수 있는 구조
- 무려 수조 건의 데일리 이벤트를 손쉽게 저장하고 분석할 수 있다고 한다. 적응형 쿼리 처리 엔진을 사용하고 있다.
- 시계열 분석에 필요한 함수를 기본적으로 탑재하고 있음 (interpolation, smoothing, approximation)
- 서버리스! 규모에 대한 고려가 없어도 관계없음. 온디맨드 방식이 적용 가능
- 기본 탑재된 분석 기능을 사용하여 IoT 애플리케이션이나 산업용 장비들이 생성하는 시계열 데이터를 빠르게 분석, 데이터가 증가해도 가능한 한 최소 비용으로 지속적이며 예측 가능한 성능을 유지
예를 들어, 미세먼지와 같은 초단위로 바뀌는 정보를 수집하여 공기 청정기를 어떤식으로 동작해야 하는지를 분석할 때 사용할 수 있을 것이며, 클릭 스트림에 대해 어떤식으로 반응해야 하는 지 정보 등을 다룰 수 있다.
블록체인을 이용하고자 하는 이용자들의 요구사항에 맞춰 출시된 QLDB는 원장 데이터베이스를 제공한다.
애플리케이션에서 발생하는 모든 데이터 변경 기록 추적이 가능하고 내용 확인을 할 수 있다.
AWS Summit에서는 해당 블록체인 기술 적용사례를 실제적으로 보여주기 위해서 블록체인 펍이라는 부스를 만들어서 어떤 식으로 데이터 확인이 가능한지 보여주기도 했다.
맥주를 실어나르는 과정에서 맥주 출하 시의 갯수와 맥주를 받은 펍에서 수령한 갯수가 일치하는 지 어느 과정에서 문제가 있었는 지 등을 블록체인 기술이 접목된 QLDB에서 관리할 수 있음을 보여줬다.
Amazon Quantum Ledger Database (QLDB)
- 완전 관리형 원장 데이터베이스 (블록체인)
- 애플리케이션의 모든 데이터 변경 기록 추적 및 확인
- 상호간의 데이터가 같은지 비교하는 과정이 필요한 기존의 이더리움과 같은 블록체인과 달리 유효성검사가 필요없는 구조로 중앙 관리형 데이터베이스이므로 성능 문제가 크지 않음
- 적용 가능 사례 : 금융거래 등 기존의 블록체인이 적용될 수 있었던 모든 산업사례와 해외 직구 배송추적 사례 등도 적용 가능하다.
가장 인상깊었던 적용 가능 사례는 HR 이었다. 인사정보에도 원장 데이터베이스를 사용할 수 있다는 얘기를 들었는데 뭔가 아차했다. 중요한 정보를 많이 담고 있는 만큼 이 내용들을 QLDB로 적용할 수 있겠다.
계약서 써놓고 중간에 바꿔치는 그런 짓은 절대 못하겠구나.
아무래도 QLDB의 이용 예시를 쓰려고 한 듯 한데 오타가 났다. 슬쩍 모른척해보도록 하자.
위에서 소개했던 다양한 데이터베이스를 사용한 예시다.
도서관의 예시를 들면서 한 가지만 굳이 사용해야 할 필요가 없음을 사례를 통해 알려줬다. 해당 내용은 github로도 공유가 된 듯 하다.
https://github.com/aws-samples/aws-bookstore-demo-app
온프레미스 DB를 클라우드로 이전하기 위해 사용할 수 있는 SCT에 대해 소개하고 있다.
기존 Oracle, SQL Server, DB2 LUW를 PostgreSQL, MySQL, Amazon Aurora로 전환하거나
온프레미스 DW (데이터 웨어하우스)를 클라우드로 전환할 수도 있다.
DMS라는 서비스를 통해 데이터베이스를 마이그레이션 하는 서비스도 제공한다.
- 주요 업무 애플리케이션 마이그레이션
- 마이너 버전의 업그레이드
- Amazon Aurora로의 통합
- 오래된 데이터 보관
- NoSQL > SQL 또는 SQL > NoSQL, NoSQL > NoSQL 마이그레이션 모두 가능하다.
마이그레이션을 진행할 때 대부분은 다운타임이 없는 무중단 마이그레이션을 원할 것이다.
일단 다운타임이 발생하게 되면 내용 고지를 사전에 진행해야 할 뿐 아니라 그 시간 동안 유저들이 사용할 수 없다는 점에서 매출에 영향을 미칠 수도 있기 때문이다.
해당 세션에서는 무중단 마이그레이션을 위한 과정에 대해서도 소개했다.
기존 애플리케이션 사용자들은 온프레미스 환경에 연결된 채로 서비스를 사용하고 있는 상태에서
- 복제 인스턴스를 생성하여 원본 및 대상 데이터베이스를 연결하고
- AWS DMS를 통해 테이블 생성, 데이터 로드, 동기화 등을 진행하여 데이터를 클라우드로 이전한다.
- 온프레미스 환경에서 클라우드로 전환을 결정하고 애플리케이션의 타겟 데이터베이스를 변경한다.
위와 같은 과정으로 애플리케이션 사용자는 중단 시간을 거의 느낄 수 없는 무중단 마이그레이션을 진행할 수 있다.
위에 DMS에 대해 설명한 장표가 있는데 이건 또 왜 있는건지 잘 모르겠다
(역시 그 날 정리했어야 하는데 벌써 이틀이 지났다... ^_ㅜ)
AWS에서 제공하는 데이터 서비스의 전반적인 내용을 보면서 세션 정리를 마무리 한다.
해당 세션을 진행했던 솔루션즈 아키텍트분의 차분한 설명이 참 좋았던 기억이 난다.
이렇게 정리해둔 세션 내용이 미래와 현재의 나뿐 아니라 누군가엑에게 또 도움이 되기를 바라며!
'PROGRAM > AWS(Amazon Web Service)' 카테고리의 다른 글
| [AWS] Amazon EC2 : 클라우드 컴퓨팅을 위한 가상 서버 (3) | 2022.06.26 |
|---|---|
| 클라우드 컴퓨팅과 AWS 사용 전 주요 개념 (0) | 2022.06.19 |
| [AWS Dev Day SEOUL 2019] keynote (0) | 2019.09.26 |
| [AWS] AWS Summit Seoul 2019 - 1Day (1) | 2019.04.17 |
| [AWS] Amazon WebService 용어 정리 (0) | 2019.04.10 |
