데이터 스토리지 솔루션 고르기 (2)

    우리가 이전 포스팅에서 설명한 건 메인 DB를 어떤 이유로 선택했는가 하나뿐이다. 이제 나머지를 이야기하겠다(사실 이번 포스팅에서도 다룰 건 딱 한 가지다).

https://akdnjs0308.tistory.com/24

데이터 스토리지 솔루션 고르기 (1)

 

 

    그 전에, 이 포스팅 시리즈를 작성하는 의미에 대해 이전 포스팅에서 명쾌하게 전달하지 못한 것 같아 다시 남긴다. 생성형 AI의 보편화로 인해 우리는 어떤 솔루션이 무슨 장단점이 있는지, 솔루션을 어떤 식으로 활용해야 그 이점을 극대화할 수 있는지에 관해서는 몇 가지의 질문으로 금세 알 수 있게 되었다(물론 할루시네이션은 감안해야겠지만, 요새는 AI 성능이 많이 좋아져서 이에 대한 부담도 덜하다고 여긴다). 하지만 결국 그러한 조건을 분석하여 우리의 상황에 알맞은 결정을 해야 하는 건 인간의 몫이다. 그런 점에서 필자는 이 포스팅에서 단순히 어떤 솔루션이 무슨 특성이 있는지를 조망하려는 게 아니라, 그런 특성이 우리가 추구하는 바와 얼마나 어울리는지, 어떤 점에서 우리 프로젝트에게 이롭게 작용될 수 있는지에 집중하고자 했다. 

 

    이러한 복안이 잘 전달되기를 바라며, 여러분의 프로젝트에서 솔루션을 선택할 때 부디 도움이 되기를 바란다.

---

2. AWS-Managed 관계형 DB 서비스(Amazon RDS vs Amazon Aurora)

    이번 포스팅에서도 다루는 주요 주제는 데이터 스토리지 솔루션 그 자체이기 때문에 우리 프로젝트에서 왜 클라우드(AWS)를 도입했는지는 슬쩍 넘어가고, AWS에서 PostgreSQL을 메인 DB로 사용하기 위한 주요 솔루션 2가지를 비교하여 왜 Amazon RDS를 골랐는지를 제시하고자 한다.

 

a. 어떤 서비스가 비용을 절약할 수 있는가?

    비록 성능은 크게 기대할 게 못되긴 하지만 Amazon RDS는 Amazon EC2와 마찬가지로 1년 동안 프리 티어를 사용할 수 있다는 장점이 있으며, Amazon Aurora는 그러한 이점을 누릴 수 없다. 설령 프리 티어가 끝난다고 할지라도 동일 인스턴스 클래스 기준으로 단가가 Amazon Aurora가 Amazon RDS보다 대략 20% ~  정도 비싸고, 우리 프로젝트는 현 시점으로 봐도 이제 막 MVP 1차를 끝내고 차별화된 기능을 준비하면서 고객 유치를 본격적으로 준비하는 단계 쯤에 있기 때문에, Amazon Aurora로의 마이그레이션을 지금 당장 해야 할 이유는 크게 없어 보인다.

 

Amazon RDS의 인스턴스 클래스 - 비용 목록.

 

Amazon Aurora의 인스턴스 클래스 - 비용 목록. 오른쪽은 I/O-Optimized 옵션이 추가되어 더욱 비싸다(후술). 프로비저닝된 옵션(가운데)이라 할지라도 동일한 인스턴스 클래스 기준 Amazon RDS보다 값비싸다는 것을 확인할 수 있다.

---

b. Amazon Aurora의 효용이 Amazon RDS를 넘어서는 것은 언제인가?

    다만 맡은 바에 책임을 다해야 하지 않겠는가. 이제 언제부터 Amazon Aurora를 채택할 것이냐, 언제 Amazon Aurora가 제공하는 기능이 비용의 인상을 용인할 이점을 주느냐 하는 문제만 풀면 될 듯하다. 아래는 참고용으로 제시하는 각각의 서비스에 대한 소개 페이지이다.

 

Amazon Aurora

https://aws.amazon.com/ko/rds/aurora/

OLTP 데이터베이스, MySQL 및 PostgreSQL 관리형 데이터베이스 - Amazon Aurora - AWS

 

Amazon RDS

https://aws.amazon.com/ko/rds/

관리형 SQL 데이터베이스 - Amazon Relational Database Service(RDS) - AWS

 

    Amazon Aurora말고도 Amazon RDS를 다중 AZ에 걸쳐 구성하는 경우까지 고려하여 각각의 서비스를 언제까지, 혹은 언제부터 사용하면 좋을지 판단한 바를 이야기해 보겠다.

 

1) 다중 AZ에 걸친 Amazon RDS 인스턴스"들"

    우리 프로젝트에서 PostgreSQL을 사용하는 이상, 앞으로 쓸 이유는 없을 듯하다. 이 방법에 포함되는 구체적인 옵션으로 떠올릴 수 있는 건 다중 AZ DB 인스턴스 옵션과 다중 AZ DB 클러스터 옵션 정도이니 나눠서 생각해 보겠다.

 

1-1) 다중 AZ DB 인스턴스

    이 방법은 간단히 말하자면 인스턴스를 하나 추가하며, 인스턴스를 하나를 주(Primary) 인스턴스로 나머지 인스턴스를 대기(Standby) 복제본으로 씀으로써 고가용성을 기하는 방법으로 요약할 수 있을 듯하다. 다만 이러한 기능 하나를 위해 비용을 두 배로 쓸 바에는 Amazon Aurora를 써서 비용 20% 정도를 더 내고 3개의 AZ에 걸쳐 6개의 스토리지 노드로 데이터를 자동으로 복제하는 게, 고가용성 하나만 놓고 봐도 훨씬 이득이라고 보인다.

 

1-2) 다중 AZ DB 클러스터

    이 방법도 간단하게만 표현하자면 인스턴스를 두 개 추가하며, 인스턴스 하나를 쓰기 전용으로 두고 나머지 인스턴스 두 개 모두를 읽기 전용 복제본으로 씀으로써 고가용성을 기하는 동시에 성능에서의 이점을 추구하는 방식이라고 요약할 수 있을 것이다. 다만 이 방법을 쓰려면 비용을 세 배나 더 내야 한다는 치명적인 문제가 존재하며, 고가용성도 6개의 복제본을 두는 Amazon Aurora보다 뛰어나다고 할 수 없고, 성능 이점도 Aurora에 미치지는 못할 것이다. Aurora는 소개 페이지에서 언급하는 "PostgreSQL의 3배에 달하는 처리량"을 제공하기 위해 Amazon RDS와 차별화되는 다양한 기능을 보유하고 있는데, 이는 밑에서 다시 이야기하겠다.

---

2) 단일 Amazon RDS 인스턴스 또는 Amazon Aurora 인스턴스(Serverless v2 또는 I/O-Optimized 옵션 사용)

    위와 같은 논의를 통해 추가적인 Amazon RDS 인스턴스를 사용하는 건, 어떤 경우든 좋지 않다는 결론에 이르렀다. 다음으로 Amazon Aurora에 관해 언급하기 전에, 단일 Amazon RDS 인스턴스도 충분히 좋을 수 있는 시나리오가 있다는 것을 먼저 이야기하고자 한다. 이를 위해서는 다음의 조건이 충족되어야 한다(중요한 것 위주로 추려봤다):

 

1. 낮은 컴퓨팅 성능으로도 충분할 때
2. 고가용성을 포기해도 괜찮을 때
3. 사용되는 컴퓨팅 리소스의 시간에 따른 편차가 적을 때
4. 스토리지로의 I/O가 많지 않아 초과분을 설정하는 정도로 충분할 때

 

    1번과 2번은 Aurora를 사용하는 본질적인 이유에 관한 것이다. 필자는 이들이 우리가 Amazon RDS 대신 Amazon Aurora를 사용했을 때 얻을 수 있는 가장 큰 이점이라고 여긴다. 성능은 당연하거니와, 고가용성 또한 다음과 같은 이유로 프로덕션에서 필수적으로 고려해야 할 것이다:

 

1. 무중단 서비스 운영
2. 데이터의 내결함성 향상
3. 유저로의 응답성 개선

 

    3번과 4번은 Amazon RDS의 비용이 어떤 식으로 청구되는지와 연결하여 설명할 수 있을 듯하다. Amazon RDS는 크게 다음과 같은 항목으로 요금을 청구한다:

 

1. 스토리지 크기
2. DB 인스턴스 클래스 및 실행 시간
3. IOPS 및 처리한 데이터의 양(초과 설정 분)

 

    먼저 1번에 관해서는 Amazon Aurora에서는 자동 크기 축소가 가능한 것과 달리 Amazon RDS는 불가하므로 차이가 있긴 하지만, 우리 프로젝트에서 용량이 줄어들 일은 딱히 없을 것 같기 때문에(스토리지 용량의 선형적인 증가를 예상한다), 이 부분이 그다지 중요하지는 않다고 생각한다.

 

    2번에 관해서는 중요한 의미가 있을 수도 있는데, Amazon RDS는 프로비저닝이 기본이기 때문에 컴퓨팅 용량을 쓰든 말든 인스턴스 클래스에 대한 비용을 지불해야 한다. 하지만 Amazon Aurora에서는 Serverless v2 옵션을 통해 ACU(Aurora Capacity Unit) 기반의 동적 컴퓨팅 리소스 관리가 가능하므로, 컴퓨팅 리소스의 시간에 따른 편차가 크다면 이쪽을 고려하는 것도 좋을 것이다. 다만 동일 컴퓨팅 리소스를 인스턴스 클래스로 환산하면 해당 서버리스 옵션은 Amazon RDS 대비 몇 배 정도 더욱 비싼 비용을 요구하기 때문에, 자칫하다가는 비용 폭탄을 맞을 우려가 있다. 추후에 컴퓨팅 리소스의 시간대별 활용 현황이라든지 유저의 유입 시간대 등을 분석할 필요가 있어 보인다.

 

    끝으로, 3번에 관해서는 먼저 Amazon RDS와 Amazon Aurora의 차이점을 이해하고 넘어가면 좋을 듯하다. Amazon RDS는 Amazon EBS 기반이며, EBS에서 IOPS와 처리량에 대해 설정된 바에 따라 추가적인 요금이 부과될 수 있다(gp3 모델 기준. gp2모델에는 다른 설정이 적용되며, 해당 성능 지표를 개선하기 위해 별도로 수정할 수 있는 기능은 없다). Amazon Aurora는 I/O의 호출 수에 따른 요금이 청구된다. 여기서 중요한 건, 늘 같은 수준의 서비스를 제공하기 위해 Amazon EBS에서의 설정은 유저가 가장 몰리는 때를 기준으로 설정할 수밖에 없다는 점이다. 계산기를 두들겨 봐야 할 일이긴 하지만, 피크 시간대에 필요한 리소스가 확대될수록 비용 증가와 비효율성이 자연히 따라올 수 있으며, 결국에 비용만 따지고도 프로비저닝된 Amazon Aurora(또는 I/O가 매우 빈번하게 발생할 경우 I/O-Optimized Amazon Aurora)를 사용하는 것이 유리해지는 때가 올 수도 있다. 시간을 두고 피크 시간대에서도 원활한 서비스 운영을 위해 어느 정도의 리소스가 필요한지 추적해 볼 필요가 있어 보인다.

---

3) Amazon Aurora(Provisioned + Standard 옵션 사용)

    말이 길어졌는데, 이제 남은 건(메모리가 부족하다면 인스턴스 클래스를 확장하는 쪽으로 생각해야겠지만) "성능을 개선할 필요가 있다면 Amazon RDS에서 Amazon Aurora로 마이그레이션하는 것이 권장된다"는 설명에 근거를 덧대는 정도인 듯하다. 정말 언급할 만한 가치가 있는 개념만 짚어보자.

 

공유 스토리지 아키텍처(Shared Storage Architecture)란, 

 

    필자가 보기에 공유 스토리지 아키텍처만큼 Amazon Aurora가 Amazon RDS와 차별화되는 지점도 없는 듯하다. 그도 그럴 것이, 이 아키텍처는  Amazon Aurora의 근본적인 설계 방식이기 때문이다. 핵심은 컴퓨팅과 스토리지 계층이 연결되는 방식이다. 여기서 컴퓨팅 계층은 인스턴스 클래스로, 스토리지는 가상 볼륨으로 대표된다.

 

    Amazon RDS에서는 특정한 인스턴스에 대응해서 Amazon EBS가 하나씩 할당되어야 한다. 그에 따라 클러스터를 구성하기 위해서는 여러 개의 독립된 Amazon EBS가 필요하다. 이들 간 데이터 전송은 동기식(다중 AZ DB 인스턴스, 전자로 후술) 또는 반동기식(다중 AZ DB 클러스터, 후자로 후술)이고, 그게 데이터 블록을 직접 작성하는 것이든(전자), 로그로부터 데이터를 재현하는 것이든(후자), 스토리지의 CPU와 I/O 부하를 일정 수준 야기하는 것은 매한가지다.

 

   그와 다르게 Amazon Aurora는 스토리지 계층으로 가상 볼륨(Virtual Volume)이라는, 수백 개의 스토리지 노드에 분산되는 논리적 데이터 저장소를 사용한다. 각 복제본으로의 데이터 복제는 원자적인 명령을 담은 형태를 갖는 로그 레코드라는 형태로 이뤄지며, 각 복제본은 이를 받고 각자의 버퍼 풀을 갱신하는 정도의 작업만 수행해서 쓰기 작업을 완료 처리한다. 이후 읽기를 위한 데이터 참조는 스스로가 보유하고 있는 데이터가 아닌 바로 이 가상 볼륨에 저장된 데이터를 사용함으로써 스토리지 계층에 속하는 복제본에서 발생할 수 있는 부하를 극단적으로 최소화하고 높은 처리량을 달성하도록 하는 것이 이 아키텍처가 주는 주요한 장점 중 하나다.

 

    여기에 더하여 Amazon Aurora는 위에서 언급했듯 총 6개의 복제본을 기본으로 제공하며, 이 중 2개의 복제본에 문제가 있어도 쓰기에 지장이 없고, 3개가 문제가 있어도 읽기에 지장이 없을 만큼 견고하다. 문제가 생긴 복제본에 대한 자가 치유 기능은 가십 프로토콜을 통해 자동적으로 수행된다. 끝으로 원래 메모리는 휘발성이므로 인스턴스가 중단되는 경우 저장된 데이터가 모두 날아가게 되어 캐시 데이터 휘발로 인한 콜드 스타트의 위험성이 동반되는데 반해 Amazon Aurora에서는 버퍼 풀을 다루는 프로세스를 DB 엔진의 메인 프로세스(postgres)로부터 분리하기 때문에, 인스턴스의 재시도에도 캐시 데이터를 보존할 수 있다.

 

    이런 점 때문에, Amazon RDS를 사용하다가 성능 문제로 곤욕을 치른다면 웬만하면 Aurora로 넘어가는 게 옳다고 판단한다.

---

    이번 포스팅을 쓰면서 Amazon RDS와 Aurora에 대한 공부를 보강했는데, 그로부터 느낀 점은 필자가 스스로 생각하는 것보다도 PostgreSQL의 기본 원리에 대해서 모르는 게 많다는 것이다. Amazon RDS나 Aurora에서의 데이터 흐름 자체는 PostgreSQL의 기존 모델을 상당수 차용했음을 이번 기회에 알게 되었고, Postmaster라든지 PostgreSQL의 공유 버퍼 등에 관해 시간이 날 때마다 공부해야겠다. 또한 아직도 AI가 세부 사항에서는 갈 길이 멀었다는 것도 다시금 배웠다. 용어는 실제로 쓰이는지 구글링하고, 뭔가 이상하다 싶은 부분은 그냥 지나치면 안 되겠다.

 

    끝으로, 남은 스토리지 솔루션 비교가 최소 2개 남았는데, 다른 과업도 생각해서 우선순위를 잘 정해야겠다!