AWS Technical Essentials #4

관계형 데이터베이스

관계형 데이터베이스는 데이터를 테이블로 정리한다. 한 테이블의 데이터를 다른 테이블의 데이터에 연결하여 관계를 생성할 수 있기 때문에 관계형이라는 이름이 붙은 것이다.

테이블은 데이터를 행과 열에 저장한다. 보통 레코드라고 칭하는 행에는 특정 항목에 대한 모든 정보가 포함된다. 열은 항목의 속성을 설명한다.

 

위 이미지에 도서 테이블, 판매 테이블, 저자 테이블이 나와 있다. 도서 테이블에서 각 행에는 국제 표준 도서 번호(ISBN), 제목, 저자 및 형식이 포함된다. 이러한 속성은 각각 다른 열에 저장된다. 도서 테이블에는 다른 두 테이블과 공통되는 부분이 있으니, 바로 저자 속성이다. 이 공통의 열이 테이블 간의 관계를 생성하는 것이다.

테이블, 행, 열과 이들 간의 관계를 논리적 스키마라고 한다. 관계형 데이터베이스에서는 스키마가 고정된다. 데이터베이스가 작동하면 스키마를 변경하기가 어려워진다. 그러므로 데이터베이스가 활성화되기 전에 대부분의 데이터 모델링이 완료된다.

 

관계형 데이터베이스 관리 시스템(RDBMS)을 사용하면 관계형 데이터베이스를 생성, 업데이트 및 관리할 수 있다. RDBMS의 일반적인 예시로는 MySQL, PostgreSQL, Oracle, Microsoft SQL Server, Amazon Aurora가 있다.

 

한편, 관계형 데이터베이스를 사용할 때의 이점은 다음과 같다.

① 복잡한 SQL : SQL을 사용할 때 여러 테이블을 조인하여 데이터 간의 관계를 더 명확히 이해할 수 있다.
② 중복성 감소 : 동일한 데이터를 여러 곳에 저장하는 대신, 한 테이블에 데이터를 저장하고 다른 테이블에서 이 데이터를 참조할 수 있다.
③ 친숙한 형식 : 관계형 데이터베이스는 1970년대부터 인기 있는 옵션이었기 때문에 연차 차이가 많이 나는 시니어들도 관계형 데이터베이스에 익숙할 것이다.
④ 정확도 : 관계형 데이터베이스는 데이터의 무결성이 높고 원자성, 일관성, 독립성, 내구성(ACID) 원칙을 준수한다.

전 세계 대부분의 애플리케이션은 관계형 데이터베이스에서 실행된다. 실제로 관계형 데이터베이스는 많은 미션 크리티컬 애플리케이션의 중심이며, 그중에는 우리의 일상에 친숙한 것도 있다.

① 고정된 스키마가 있는 애플리케이션 : 고정된 스키마를 가지며 자주 변경되지 않는 애플리케이션이다. 예시로는 앱을 거의 또는 전혀 수정하지 않고 온프레미스에서 클라우드로 리프트 앤 시프트하는 애플리케이션이 있다.

② 영구 스토리지가 필요한 애플리케이션 : 영구 스토리지가 필요하며 ACID 원칙을 준수하는 애플리케이션으로, 예는 다음과 같다.

- 전사적 자원 관리(ERP) 애플리케이션
- 고객 관계 관리(CRM) 애플리케이션
- 상거래 및 금융 애플리케이션

 

온프레미스 데이터베이스를 AWS 기반 관계형 데이터베이스로 교체하려면 먼저 데이터베이스를 실행하려는 방법, 즉 관리형 또는 비관리형 중에서 선택해야 할 것이다. 관리형 서비스와 비관리형 서비스는 공동 책임 모델과 유사하다. 공동 책임 모델은 AWS의 보안 책임과 고객의 보안 책임을 구분하는데, 마찬가지로 관리형을 비관리형에 비교하자면 편리함과 제어 권한 사이에서 장단점이 있다고 이해할 수 있다.

 

비관리형 데이터베이스

온프레미스에서 관계형 데이터베이스를 운영하면 운영의 모든 측면을 고객이 책임져야 한다. 예를 들면 데이터 센터 보안과 전력, 호스트 머신 관리, 데이터베이스 관리, 쿼리 최적화, 고객 데이터 관리를 들 수 있다. 절대적으로 모든 것에 대한 책임이 고객에게 있다. 이것은 결국 고객이 절대적으로 모든 것을 제어할 수 있다는 것을 의미한다.

 

이제 Amazon EC2에서 관계형 데이터베이스를 실행하여 일부 작업을 AWS에 넘기고 싶다고 가정한다. Amazon EC2에서 데이터베이스를 호스팅하는 경우, AWS는 물리적 인프라 및 하드웨어를 구현 및 유지 관리하고, EC2 인스턴스의 운영 체제를 설치한다. 그러나 EC2 인스턴스 관리, 해당 호스트에서 데이터베이스 관리, 쿼리 최적화, 고객 데이터 관리는 여전히 고객이 담당한다.

이를 비관리형 데이터베이스 옵션이라고 한다. 이 옵션에서 AWS는 하드웨어와 기본 인프라에 대한 책임과 제어 권한이 있다. 고객에게는 호스트와 데이터베이스의 관리에 대한 책임과 제어 권한이 있다.

 

관리형 데이터베이스

 

AWS로 더 많은 작업을 넘기려면 관리형 데이터베이스 서비스를 사용하면 된다. 관리형 데이터베이스 서비스는 EC2 인스턴스 및 데이터베이스 모두의 설정을 제공하며, 고가용성, 확장성, 패치, 백업을 위한 시스템을 제공한다. 그러나 이 모델에서도 여전히 고객이 데이터베이스 튜닝, 쿼리 최적화, 고객 데이터 보안 유지를 책임진다. 이 옵션은 이전의 두 옵션에 비해 편의성은 최대한으로 제공하지만 제어 권한은 최소한으로 제공한다.

 

Amazon RDS

Amazon RDS는 기존 데이터베이스 관리의 운영 부담 없이 클라우드에서 관계형 데이터베이스를 생성하고 관리하는 데 사용할 수 있는 관리형 데이터베이스 서비스다. 예를 들어, 우리가 수달 서비스 장비를 판매하며 강남구에서 1등 판매자가 되는 것이 목표라고 가정한다. 데이터베이스를 구축하는 일은 그 목표를 달성하는 데 직접적으로 도움이 되지 않는 것이 당연하다. 그러나 그 목표를 달성하기 위해서는 데이터베이스가 꼭 있어야만 할 것이다. 

Amazon RDS를 사용하면 데이터베이스 생성 및 관리와 같은 관련 없는 작업을 일부 덜어낼 수 있다. 프로비저닝, 패치, 크기 조정, 복구 같은 인프라 관련 태스크에 집중하는 대신 애플리케이션을 차별화하는 태스크에 집중할 수 있다.

Amazon RDS는 상용 옵션, 오픈 소스 옵션, AWS 전용 옵션에 이르기까지 널리 사용되는 대부분의 RDBMS를 지원한다. 지원되는 Amazon RDS 엔진의 예는 다음과 같다.
① 상용 : Oracle, SQL Server
② 오픈 소스 : MySQL, PostgreSQL, MariaDB
③ 클라우드 네이티브 : Aurora 

 

직접 구축하고 관리하는 데이터베이스와 마찬가지로 Amazon RDS는 컴퓨팅과 스토리지로 구축된다. 컴퓨팅 부분은 데이터베이스 엔진을 실행하는 DB 인스턴스라고 한다. 선택한 엔진에 따라 인스턴스에 지원되는 기능 및 구성이 다르다. DB 인스턴스는 엔진이 동일한 여러 데이터베이스를 포함할 수 있으며, 각 DB에는 여러 테이블이 포함될 수 있다.

DB 인스턴스 아래에는 EC2 인스턴스가 있다. 그러나 이 인스턴스는 Amazon EC2 콘솔 대신 Amazon RDS 콘솔을 통해 관리된다. DB 인스턴스를 생성할 때 인스턴스 유형과 크기를 선택하는데, 선택한 DB 인스턴스 클래스는 처리 능력과 메모리 용량에 영향을 준다.

 

Amazon RDS의 DB 인스턴스에서 스토리지 부분은 데이터베이스 및 로그 스토리지로 Amazon EBS 볼륨을 사용한다. 여기에는 MySQL, MariaDB, PostgreSQL, Oracle, SQL Server 등이 포함된다. Aurora를 사용할 때 데이터는 SSD를 사용하는 단일 가상 볼륨인 클러스터 볼륨에 저장된다. 클러스터 볼륨은 단일 AWS 리전에 속한 3개의 가용 영역에 데이터 사본을 포함한다. 비영구적인 임시 파일의 경우 Aurora는 로컬 스토리지를 사용한다.

 

Amazon RDS는 범용 SSD(gp2 및 gp3), 프로비저닝된 IOPS SSD(io1), 마그네틱(표준) 등 3가지 스토리지 유형을 제공한다. 각 유형은 성능 특성과 가격이 다르므로, 데이터베이스 워크로드의 필요에 맞게 스토리지 성능과 비용을 조정할 수 있다.

 

DB 인스턴스를 생성할 때 데이터베이스가 상주할 Amazon VPC를 선택한다. 그런 다음, DB에 지정될 서브넷을 선택한다. 이것을 DB 서브넷 그룹이라고 하며, 이 그룹의 리전에는 최소 2개의 가용 영역이 있다. DB 서브넷 그룹의 서브넷은 인터넷 게이트웨이로의 라우팅이 없도록 프라이빗이어야 한다. 이렇게 하면 DB 인스턴스 및 그 내부의 데이터에 애플리케이션 백엔드에서만 접근할 수 있다.

네트워크 ACL 및 보안 그룹을 사용하여 DB 인스턴스에 대한 액세스를 더욱 제한할 수 있는데, 이런 방화벽을 사용하여 데이터베이스에 액세스를 제공할 트래픽의 유형을 세밀하게 제어할 수 있을 것이다.이러한 제어를 사용하면, 인프라에 보안 계층을 제공하여 백엔드 인스턴스만 데이터베이스에 액세스할 수 있도록 제한을 강화할 수 있다.

 

Amazon RDS 다중 AZ 배포의 경우 Amazon RDS는 다른 가용 영역에 데이터베이스의 중복 복사본을 생성한다. 결국 데이터베이스의 복사본이 2개가 된다. 즉, 하나의 가용 영역에 있는 서브넷에 기본 복사본이 생성되고 두 번째 가용 영역의 서브넷에 대기 복사본이 생성된다.

데이터베이스의 기본 복사본은 애플리케이션이 정보를 쿼리하고 표시할 수 있도록 데이터에 대한 액세스를 제공한다. 기본 복사본의 데이터는 대기 복사본에 동기식으로 복제된다. 대비 복사본은 활성 데이터베이스로 간주되지 않으며, 애플리케이션의 쿼리를 받지 않는다.

가용성을 높이기 위해 Amazon RDS 다중 AZ는 데이터베이스의 두 복사본이 실행되고 그 중 하나가 기본 역할에 있도록 한다. 프라이머리 데이터베이스의 연결이 끊어지는 등 가용성 문제가 발생하면 Amazon RDS는 자동 장애 조치를 시작할 것이다.

DB 인스턴스를 생성할 때는 DNS 이름이 제공된다. AWS는 해당 DNS 이름을 사용하여 대기 데이터베이스로 장애 조치를 수행한다. 자동 장애 조치 시 대기 데이터베이스가 기본 역할로 승격되며, 쿼리가 새로운 프라이머리 데이터베이스로 리디렉션되는 것이다.

 

그리고 다중 AZ 구성이 손실되지 않도록 새 대기 데이터베이스를 생성하는 방법에는  2가지가 있다.
① 여전히 실행 중이면, 이전의 프라이머리 데이터베이스를 대기 데이터베이스로 강등한다.
② 새로운 대기 DB 인스턴스를 구축한다.

Amazon RDS 데이터베이스에 여러 서브넷을 선택하는 이유는 다중 AZ 구성 때문이다. 기본 복사본과 대기 복사본에 대해 서로 다른 가용 영역에 서브넷이 있는지 확인해야 한다.

 

모든 애플리케이션 요구 사항을 위한 목적별 데이터베이스

관계형 데이터베이스는 마치 다용도 도구처럼 많은 역할을 할 수 있지만, 모든 서비스가 그러하듯, 어떤 작업에도 완벽하게 들어맞지는 않기 때문에 우리의 비즈니스 요구 사항에 항상 가장 좋은 옵션은 아닐 수 있다. 그렇기에 모든 것에 관계형 데이터베이스를 사용하는 획일적인 접근 방식은 적합하지 않다. 그외의 다양한 선택지로는 다음이 있다.

 

① Amazon DynamoDB
DynamoDB는 어떤 규모에서나 빠르고 일관적인 성능을 제공하는 완전관리형 NoSQL 데이터베이스다. 결제 모델이 유연하며, 코드형 인프라(IaC)와의 긴밀한 통합 및 자동 운영 모델을 제공한다. DynamoDB는 대규모 애플리케이션과 서버리스 애플리케이션에서 주로 사용하는 데이터베이스라 할 수 있다. 그런데 DynamoDB가 대규모 및 서버리스 애플리케이션에서 자주 선택받는 데이터베이스이기야 하지만, 거의 모든 온라인 트랜잭션 처리 애플리케이션 워크로드에 사용할 수도 있다.

 

② Amazon ElastiCache 
ElastiCache는 완전관리형 인 메모리 캐싱 솔루션으로, 2개의 오픈 소스 및 인 메모리 캐시 엔진인 Redis와 Memcached를 지원한다. 인스턴스 장애 조치, 백업 및 복원, 소프트웨어 업그레이드를 우리가 책임지지 않아도 된다.

 

③ Amazon MemoryDB for Redis
MemoryDB는 내구성이 뛰어나고 Redis와도 호환되는 인 메모리 데이터베이스 서비스로, 초고속 성능을 구현한다. MemoryDB를 사용하면 마이크로서비스 아키텍처를 기반으로 개발된 애플리케이션 등 현대적 애플리케이션에서 마이크로초 단위의 읽기 지연 시간, 10밀리초 미만의 쓰기 지연 시간, 높은 처리량, 다중 가용 영역의 내구성을 달성할 수 있다. 또한, MemoryDB를 완전관리형의 프라이머리 데이터베이스로 사용하여 고성능 애플리케이션을 구축할 수 있다. 캐시, 내구성을 갖춘 데이터베이스, 필수 기본 인프라는 별도로 관리하지 않아도 된다.

 

④ Amazon DocumentDB(MongoDB 호환)
Amazon DocumentDB는 AWS가 제공하는 완전관리형 문서 데이터베이스다. 문서 데이터베이스는 애플리케이션에서 풍부한 내용의 문서를 저장 및 쿼리하는 데 사용할 수 있는 NoSQL 데이터베이스다. 이런 데이터베이스는 콘텐츠 관리 시스템, 프로필 관리, 웹 및 모바일 애플리케이션에 적합하다. Amazon DocumentDB는 MongoDB와 API로 호환이 가능하다. 즉, 인기 있는 오픈 소스 라이브러리를 사용하여 Amazon DocumentDB와 상호 작용하거나, 아주 간단하게 기존 데이터베이스를 Amazon DocumentDB에 마이그레이션할 수 있다는 것이다.

 

⑤ Amazon Keyspaces(Apache Cassandra용)
Amazon Keyspaces는 확장 가능한 고가용성의 완전관리형 데이터베이스 서비스로, Apache Cassandra와 호환된다. Apache Cassandra는 최고의 성능이 필요한 대규모 애플리케이션에 많이 쓰인다. Amazon Keyspaces는 간단한 액세스 패턴을 갖는 대용량 애플리케이션에 적합할 것이다. Amazon Keyspaces를 사용하면 현재 사용하는 것과 동일한 Cassandra Query Language(CQL) 코드, Apache 2.0 라이선스가 적용된 드라이버, 도구를 사용하여 AWS에서 Cassandra 워크로드를 실행할 수 있다.

 

⑥ Amazon Neptune
Neptune은 AWS에서 제공하는 완전관리형 그래프 데이터베이스다. 그래프 데이터베이스는 다양한 관계를 통해 고도로 연결된 데이터에 유용한 옵션이다. 기업에서는 추천 엔진, 사기 행위 탐지, 지식 그래프에 그래프 데이터베이스를 사용하는 경우가 많다.

 

⑦ Amazon Timestream
Timestream은 사물 인터넷(IoT)과 운영 애플리케이션을 위한 빠르고 확장 가능한 서버리스 시계열 데이터베이스 서비스다. 관계형 데이터베이스와 비교할 때 하루에 수조 개의 이벤트를 최대 1,000배 빠르게 저장 및 분석하면서도 비용은 10분의 1정도밖에 되지 않는다. 시계열 데이터는 특정 시간 간격을 두고 기록되는 데이터 포인트의 시퀀스로, 시간에 따른 주가 또는 기온 등 시간이 지나면서 변화되는 이벤트를 측정하는 데 사용되는 개념이다.

 

⑧ Amazon Quantum Ledger Database(QLDB)
기존의 데이터베이스에서는 데이터를 덮어쓰거나 삭제할 수 있기 때문에 개발자들이 데이터 계보를 추적하기 위해 감사 테이블과 감사 추적 등의 기법을 사용했다. 이런 방법은 확장하기가 어렵고 모든 데이터가 기록되도록 확인하는 부담을 개발자가 지게 된다. Amazon QLDB는 애플리케이션 데이터에 적용된 모든 변경 사항에 대해 완전하고 암호로 확인할 수 있는 내역을 제공하도록 특별히 설계된 원장 데이터베이스다.

 

Amazon DynamoDB

DynamoDB는 완전관리형 NoSQL 데이터베이스 서비스로, 원활한 확장성과 함께 빠르고 예측 가능한 성능을 제공한다. DynamoDB를 사용하여 면산 데이터베이스의 운영 및 크기 조정에 따른 관리 부담을 줄일 수 있다. 하드웨어 프로비저닝, 설정 및 구성, 복제, 소프트웨어 패치 또는 클러스터 크기 조정에 대해 걱정할 필요가 없는 것이다.

 

DynamoDB를 사용하면 다음 작업을 수행할 수 있다.
① 데이터 규모와 관계없이 데이터를 저장 및 검색하고, 어떤 수준의 요청 트래픽이라도 처리할 수 있는 데이터베이스 테이블을 생성한다. 
② 가동 중지 또는 성능 저하 없이 테이블의 처리량을 확장 또는 축소한다. 
③ AWS Management Console을 사용하여 리소스 사용률 및 성능 지표를 모니터링한다.

DynamoDB는 테이블의 데이터와 트래픽을 충분한 수의 서버로 자동 분산하여 처리량 및 스토리지 요구 사항을 충족하면서도 일관되고 빠른 성능을 유지할 수 있다. 모든 데이터가 SSD에 저장되고 한 리전 내의 여러 가용 영역에 자동으로 복제되기 때문에 기본적으로 고가용성과 데이터 내구성을 제공한다.

 

DynamoDB에서는 테이블, 항목 및 속성이 작업해야 할 핵심 구성 요소다. 테이블은 항목의 모음이고 각 항목은 속성의 모음이라 할 수 있다. DynamoDB는 기본 키를 사용하여 테이블의 각 항목을 고유하게 식별하고 보조 인덱스를 사용하여 보다 유연하게 쿼리를 작성하도록 해준다.

 

DynamoDB는 운영 작업을 처리하는 완전관리형 서비스인데, 분산 데이터베이스의 운영 및 크기 조정에 따른 관리 부담을 AWS에 넘길 수 있다. 그렇기에 다음과 같은 상황에서 DynamoDB를 사용하는 것을 고려해볼 수 있을 것이다.
① 다른 기존의 데이터베이스 시스템에서 확장성 문제를 겪고 있는 경우
② 애플리케이션 또는 서비스 개발에 적극적으로 참여하는 경우
③ OLTP 워크로드로 작업하는 경우
④ 수동 개입 없이 언제나 고가용성을 발휘해야 하는 미션 크리티컬 애플리케이션을 배포하는 경우
⑤ 어떤 백업 및 복원 전략을 사용하든 높은 수준의 데이터 내구성이 필요한 경우

DynamoDB는 간단하다는 특징 덕분에 소규모 작업부터 Amazon.com에서 필요로 하는 매우 큰 규모의 작업까지 다양한 워크로드에 사용된다.

 

한편, 구현할 수 있는 DynamoDB 보안 모범 사례는 다음과 같다.

① AWS CloudTrail을 사용하여 AWS 관리형 키 사용 현황 모니터링 : 저장 시 암호화에 AWS 관리형 키를 사용하는 경우, 키 사용 현황이 AWS CloudTrail에 기된니다. CloudTrail은 누가 요청했는지, 어떤 서비스를 사용했는지, 어떤 작업을 수행했는지, 작업의 파라미터는 무엇인지, 반환된 응답 요소는 무엇인지 알려줄 수 있다.

② IAM 역할을 사용하여 DynamoDB 액세스 인증 : 사용자, 애플리케이션, 다른 AWS 서비스가 DynamoDB에 액세스하려면 AWS API 요청에 유효한 AWS 자격 증명을 포함해야 한다. IAM 역할을 사용하여 임시 액세스 키를 획득한다.

③ 세분화된 액세스 제어를 위해 IAM 정책 조건 사용 : DynamoDB에서 권한을 부여할 때 권한 정책이 적용되는 방식을 결정하는 조건을 지정할 수 있다. 보안 위험을 줄이고 오류 또는 악의적인 의도로 인한 영향을 완화하기 위해서는 최소 권한의 원칙을 적용하는 것이 중요하다.

④ CloudTrail을 사용하여 DynamoDB 작업 모니터링 : DynamoDB에서 활동이 발생하면 해당 활동이 CloudTrail 이벤트에 기록된다. DynamoDB 및 AWS 계정에서 이벤트를 지속적으로 기록하기 위해 추적을 만들어 로그 파일을 Amazon S3 버킷에 전달한다.

 

AWS 데이터베이스 서비스

앞서 쭈우우욱 정리한 서비스를 표로 간단하게 정리하면 다음과 같다.

AWS 서비스	데이터베이스 유형	사용 사례
Amazon RDS, Aurora, Amazon Redshift	관계형	기존 애플리케이션, ERP, CRM, 전자 상거래
DynamoDB	키값	높은 트래픽의 웹 애플리케이션, 전자 상거래 시스템, 게임 애플리케이션
Amazon ElastiCache for Memcached, Amazon ElastiCache for Redis	인 메모리	캐싱, 세션 관리, 게임 순위표, 지리 공간 애플리케이션
Amazon DocumentDB	문서	콘텐츠 관리, 카탈로그, 사용자 프로파일
Amazon Keyspaces	와이드 컬럼	산업용 대규모 애플리케이션(장비 유지 관리, 플릿 관리, 라우팅 최적화용)
Neptune	그래프	사기 행위 탐지, 소셜 네트워킹, 추천 엔진
Timestream	시계열	IoT 애플리케이션, 개발 운영(DevOps), 산업용 텔레메트리
Amazon QLDB	원장	레코드 시스템, 공급망, 등록, 은행 거래