모노산달로스의 행보
[AWS] Amazon Aurora는 대체 무엇인가? 본문
aws - Aurora
AWS(Amazon Web Services)는 아마존이 제공하는 클라우드 컴퓨팅 서비스로, 서버, 스토리지, 네트워크 등을 클라우드를 통해 이용할 수 있습니다. 높은 안정성과 확장성을 갖춘 AWS는 클라우드 분야에서 높은 점유율을 차지하고 있습니다. 스파게티처럼 많은 기술이 존재하여 올바른 사용을 위해서는 꼭 학습이 필요합니다. 반대로 배워두면 많은 클라우드 기술을 사용할 수 있게 됩니다.
Amazon Aurora
Amazon Aurora란 MySQL 및 PostgreSQL과 호환되는 완전 관리형 관계형 데이터베이스 엔진입니다. aws의 독점 기술로서 클라우드 최적화가 되어있습니다.
Aurora 엔진은 다양한 기능을 통해 RDS에서 mySQL보다 5배, PostgreSQL보다 3배 뛰어난 성능을 보여줍니다.
1. 스토리지가 자동으로 늘어납니다. 데이터가 입력될수록 128TB까지 증가합니다.
2. Databasem 및 sysops로서 디스크 모니터링에 신경쓰지 않아도 됩니다.
3. Read replica를 15개까지 가질 수 있습니다.
4. 빠른 Failover 성능을 보여줍니다.
즉, Aurora는 비싼 가격을 지불해야하지만, 데이터베이스 엔진에 비해 뛰어난 성능을 보여주는 엔진입니다.
High Availability and Read Scaling
Aurora는 3개의 AZ(Availabilty Zone)에 걸쳐 데이터 사본을 6개 저장합니다. write 작업에는 4개가 필요하고 read 작업에는 3개가 필요합니다. 즉, 한 AZ가 사용 불가 상태가 되어도 작동한다는 의미입니다. (High Availaiblity)
데이터 하나가 주어지만 자동으로 위 작업을 수행합니다. 사용자는 스토리지에 대해서만 관여하고, 이외의 모든 것은 aws가 관리합니다.
write 작업을 담당하는 인스턴스는 하나가 존재하며 이를 마스터라고 부릅니다. 이외에도 read 작업을 수행하기 위해 최대 15개의 read replica는인스턴스가 존재합니다.
이때, 만약 마스터가 동작하지 않으면 30초 이내에 자동으로 failover를 수행하여 replica중 하나가 마스터가 됩니다.
Aurora DB Cluster
이번에는 클러스터로서 Aurora Database에 대해 알아봅시다.
클라이언트가 모든 인스턴스와 어떻게 인터페이스 할 수 있을까요? Aurora는 Auto expanding shared storage volume(자동 확장 공유 스토리지 불륨)이 존재합니다. 이는 모든 인스턴스가 동일한 데이터에 원활하게 접근할 수 있도록 보장합니다.
앞서 설명했듯이 마스터만 오직 write 작업을 수행합니다. 따라서 마스터를 가리키는 writer enpoint를 제공합니다. 즉, 마스터에 장애가 발생해도 클라이언트는 여전히 writer enpoint로 접근이 가능하다는 의미입니다.
Aurora는 Auto scaling 기능을 통해 자동으로 적절한 래플리카 수를 가집니다. 이때, 애플리케이션이 추적하기 어려운 상황이 발생할 수 있습니다. 예를 들어 래플리카의 위치, url, 연결방법 등이 그렇습니다. 따라서 reader enpoint가 제공되며, 모든 래플리카에 연결 로드 밸런싱이 지원됩니다.
Aurora Security
RDS와 Aurora에서 저장된 데이터를 암호화할 수 있습니다.
At-rest encryption(정지 상태 암호화)란 데이터가 저장될 때 자동으로 암호화하는 기능입니다. KMS(Key Management Service)에서 생성한 키를 통해 암호화를 수행합니다.
마스터를 암호화하지 못한 경우 read replica 또한 암호화 될 수 없습니다. 만약 암호화 되지 않은 기존 데이터베이스를 암호화하는 경우, 스냅샷을 가져온 뒤 암호화된 데이터베이스로 복원하는 과정을 거쳐야합니다.
In-flight encryption(전송중 상태 암호화)란 클라이언트와 데이터베이스간의 이동중인 데이터를 암호화하는 기능입니다. 이때, 클라이언트는 TLS 루트 인증서를 사용합니다.
이외에도 IAM roles을 사용하여 데이터베이스에 연결하거나, Security Groups로 RDS와 데이터베이스 연결을 제어할 수 있습니다.
Amazon RDS Proxy
VPC에 RDS 데이터베이스를 배포할 수 있습니다. 이때, Fully Managed Database Proxy(완전 관리형 데이터베이스 프록시) 또한 배포가 가능합니다.
RDS Proxy는 왜 필요할까요? 애플리케이션이 데이터베이스로 설정된 연결을 풀링하고 공유가 가능해집니다. 즉, 모든 애플리케이션을 데이터베이스가 아닌 프록시로 연결하면, 프록시가 이 연결을 데이터베이스에 대한 더 적은 연결로 풀링합니다.
Pooling(풀링)이란 자원을 모아두었다가 재사용하는 것을 의미합니다. 데이터베이스의 연결이 많은 경우 유용하며, CPU 혹은 RAM 등 리소스에 대한 스트레스를 줄여 효율이 증가하기도 합니다.
failover가 발생하면 프라이머리 인스턴스에서 스탠바이 인스턴스로 이동합니다. 이때, RDS 프록시를 사용하는 경우 failover 시간이 66% 줄어듭니다. 왜냐하면 애플리케이션에서 연결을 수정 할 필요도 없고, 프록시의 풀링 기능이 사용되기 때문입니다.
추가로 프록시에 IAM 인증을 사용할 수 있습니다. 즉, IAM 인증을 거치는 경우만 RDS 인스턴스에 접근이 가능하도록 할 수 있습니다. 이러한 자격 증명은 AWS Secret Manager에 의해 안전하게 저장됩니다.
RDS Proxy에 대한 내용을 정리하자면 다음과 같습니다.
RDS Proxy는 데이터베이스 인스턴스의 연결을 최소화하고 풀링하기 위해 사용합니다.
장애 조치 시간을 최소화 할 수 있으며, IAM 인증 시행 및 자격 증명이 가능하고 이는 ASM에서 안전하게 관리됩니다.
Aurora는 다양한 기능을 지원하는 강력한 엔진입니다. 가격 부담만 없다면 마음껏 사용해보고 싶은 기능 중 하나입니다.
다음 포스트에서는 Elasti Cashe에 대하여 알아보겠습니다.
'Infrastructure > AWS' 카테고리의 다른 글
| [AWS] DNS(Domain Name System)가 대체 무엇인가? (0) | 2024.10.24 |
|---|---|
| [AWS] ElastiCache를 이해하고 캐싱 전략을 정해보자 (2) | 2024.10.20 |
| [AWS] RDS(Relational Database Service)의 대한 이해 (2) | 2024.10.17 |
| [AWS] ASG(Auto Scaling Group)의 대한 이해 (3) | 2024.10.17 |
| [AWS] ALB(Application Load Balancer) & NLB(Network Load Balancer) & GWLB(Gateway Load Balancer)의 이해 및 차이점 비교 (0) | 2024.10.16 |
