목적별 데이터베이스의 사례

작성자: AWS Sr. Solutions Architect Cullen Dejean, AWS Startup Solutions Architect Matthew de Anda

초기 단계의 Startup으로서 여러분은 제품-시장 적합성을 추구하면서 여러 가지 기술적 결정을 내려야 합니다. 이러한 기술적 결정 사항 중에는 되돌릴 수 있는 것도 있지만, 장기적으로 영향을 미치는 중대한 전환점이 되는 결정도 있습니다. 데이터베이스를 선택하는 것은 대부분 후자에 속하기 때문에, 관계형 데이터베이스를 사용하는 획일화된 접근 방식은 이제 더 이상 적합하지 않습니다. 데이터베이스를 선택하기 전에 한 걸음 물러서서 현재 사용 사례를 정확히 검토해야 합니다. 하나의 데이터베이스로 무엇이든 지원할 수 있다는 기대를 버리고, 당면한 작업에 가장 적합한 데이터베이스 서비스를 선택하세요. AWS는 다양한 데이터 모델을 지원하고 확장성이 뛰어난 데이터 기반 분산 애플리케이션을 구축할 수 있도록 해주는 포괄적이고 심층적인 목적별 데이터베이스 포트폴리오를 제공합니다. 이 블로그 게시물에서는 초기 Startup이 AWS의 데이터베이스 옵션을 검토할 때 고려해야 할 요인을 살펴보겠습니다.

데이터베이스 선택 시 고려할 요인

경험

초기 단계의 Startup은 최소 기능 제품을 만들고 추진력과 성장 가능성을 입증하는 데 집중해야 하므로, 출시 속도와 가용 기술 역량을 고려해 모든 결정을 내려야 합니다. 팀이 경험해보지 못한 생소한 기술을 선택하면 일정이 지연되고 MVP를 사용자 피드백에 따라 변경하기가 더 어려워지는 경우가 많습니다. 이것이 바로 일반적으로 처음부터 관계형 데이터베이스를 사용하는 것이 여전히 올바른 접근 방식이라고 할 수 있는 이유입니다. 팀이 특정 데이터 서비스(예: 관계형, 도큐먼트 등)를 이용한 경험이 있다면 해당 서비스를 사용하여 시작하는 것이 올바른 선택일 수 있습니다.

미래의 확장성

미래의 확장성은 초기 Startup이 염두에 두어야 할 또 다른 결정 요인입니다. 더 빠르게 성과를 실현할 수 있는 익숙한 기술을 선택하려면, 사용 사례를 재분석하고 향후 확장 요구 사항을 확인하여 균형 있는 솔루션을 선택해야 합니다. 필요에 따라 자동으로 확장되 솔루션을 활용하면서 기대 성능을 계속 유지할 수 있다면, 큰 도움이 될 것입니다. 나중에 언제든 다른 기술로 마이그레이션할 수 있지만 데이터가 증가함에 따라 마이그레이션이 더욱 복잡해질 것이라는 점을 염두에 두어야 합니다. Amazon Relational Database Service(RDS)와 Amazon Aurora 간의 마이그레이션과 같은 일부 마이그레이션은 되돌릴 수 있습니다. 이를 ‘양방향 의사 결정(two-way door decision)’이라고 합니다. 양방향 의사 결정을 통해 더 빠르게 실험하고 ‘빠른 실패’ 접근 방식을 취할 수 있습니다. 다음 섹션에서는 Amazon RDS 및 Aurora와 같은 데이터베이스 서비스에 대해 자세히 설명하겠습니다.

목적별 데이터베이스와 관련 사용 사례

오랫동안 MySQL 및 Postgres 같은 관계형 데이터베이스가 데이터베이스 분야를 지배해왔습니다. 지금은 선택할 수 있는 데이터베이스 유형이 훨씬 더 많아졌습니다. 정보에 입각한 결정을 내리는 데 있어서는 데이터베이스의 액세스 특성과 데이터 형태에 따라 데이터베이스를 평가하는 것이 도움이 됩니다.

관계형 데이터베이스

관계형 데이터베이스는 개발자가 데이터베이스의 스키마뿐만 아니라 데이터베이스의 행과 테이블 간의 관계 및 제약 조건을 정의할 수 있다는 점에서 자기 설명적이라고 할 수 있습니다. 개발자는 애플리케이션 코드가 아닌 관계형 데이터베이스의 기능에 의존하여 스키마를 적용하고 데이터베이스 내 데이터의 참조 무결성을 유지합니다. 관계형 데이터베이스의 일반적인 사용 사례로는 웹 및 모바일 애플리케이션이 있습니다. Startup은 확장성이 뛰어난 AWS 기반 고성능 애플리케이션에 Amazon RDS와 Amazon Aurora를 사용합니다. RDS와 Aurora는 모두 확장 가능한 완전관리형 데이터베이스입니다.

NoSQL: 키 값 및 도큐먼트 데이터베이스

시스템이 성장함에 따라, 많은 양의 데이터가 프라이머리 키에 단일 행이 매핑되는 키 값 데이터의 형태로 존재하는 경우가 많습니다. 키 값 데이터베이스는 파티셔닝이 매우 용이하며 다른 유형의 데이터베이스로는 불가능한 수준으로 수평적 확장이 가능합니다. 알려진 키 값에 대해 지연 시간이 짧은 Get/Put을 요구하는 액세스 패턴의 키 값 데이터 모델은 게임, 광고 기술, IoT 등의 사용 사례에 특히 적합합니다.

Amazon DynamoDB는 모든 규모에서 10밀리초 미만의 성능을 제공하는 완전관리형 서버리스 키 값 NoSQL 데이터베이스입니다. 고성능 키 값 사용 사례를 지원하기 위해 확장성과 가용성이 뛰어난 관리형 Apache Cassandra 호환 데이터베이스 서비스인 Amazon Keyspace도 제공합니다.

또 다른 관련 데이터베이스 유형으로 도큐먼트 데이터베이스가 있습니다. 도큐먼트 데이터베이스의 경우 애플리케이션 계층의 데이터가 일반적으로 JSON 문서로 표현되기 때문에, 개발자가 직관적으로 사용할 수 있습니다. 도큐먼트 데이터베이스는 콘텐츠 관리 시스템 데이터의 저장과 쿼리는 물론, 사용자 프로필, 기본 설정, 추천 생성 및 트랜잭션 활성화 요청 등을 관리하는 사용 사례에도 널리 사용됩니다.

문서 데이터의 경우, 개발자는 개발자 효율성을 높이고 초당 수백만 건의 문서 읽기를 지원하는 동시에 컴퓨팅 및 스토리지를 독립적으로 확장하면서 초당 수백만 건의 문서 읽기를 지원하는 완전관리형 데이터베이스인 Amazon DocumentDB(MongoDB 호환)의 유연한 스키마 모델을 사용하여 애플리케이션 코드에서 사용하는 것과 동일한 문서 모델 형식으로 데이터를 유지할 수 있습니다.

데이터 웨어하우스

데이터 웨어하우스의 필요성을 판단할 때는 트랜잭션(OLTP) 데이터베이스와 분석(OLAP) 데이터베이스를 구분하는 것이 중요합니다. OLAP 데이터베이스는 웨어하우징 및 데이터 아카이빙을 위한 대규모 데이터베이스입니다. 대다수의 초기 단계 Startup의 경우 OLAP 사용 사례를 처리할 솔루션으로 Amazon Athena를 고려하는 것이 올바른 선택일 수 있습니다. Amazon Athena는 표준 SQL을 사용하여 Amazon Simple Storage Service(S3)에 저장된 데이터를 분석할 수 있는 서버리스 SQL 쿼리 인터페이스입니다.

애플리케이션에서 더 복잡한 쿼리와 더 엄격한 SLA가 요구되기 시작하면, 데이터 웨어하우스를 활용하여 데이터 전략과 요구 사항을 확장하는 것이 좋은 옵션이 될 수 있습니다. Amazon Redshift는 클라우드에서 제공되는 페타바이트 규모의 완벽관리형 데이터 웨어하우스 서비스입니다.

인 메모리 데이터베이스

인 메모리 데이터베이스는 마이크로초의 지연 시간으로 제공되는 데이터에 실시간으로 액세스해야 하는 애플리케이션에 사용됩니다. 금융 서비스, 전자 상거래, 웹, 모바일 및 게임 애플리케이션의 경우 인 메모리 데이터베이스를 사용하여 순위표, 세션 스토어, 캐싱 및 실시간 분석을 구축해왔습니다. 인 메모리 데이터베이스는 관계형 데이터베이스의 부하를 줄이거나, 짧은 지연 시간으로 결과를 제공하거나, 관계형 데이터베이스를 대체하여 기본 인 메모리 키 값 데이터 스토어로 사용될 수 있습니다.

Amazon ElastiCache를 사용하면 인 메모리 데이터 스토어 또는 캐시 환경을 손쉽게 설정, 관리 및 확장할 수 있습니다. Amazon ElastiCache는 Redis 및 Memcached 엔진 모두에서 작동합니다. Redis용 Amazon MemoryDB는 초고속 성능을 제공하는, Redis와 호환되고 내구성이 뛰어난 인 메모리 데이터베이스 서비스입니다. 또한 마이크로서비스 아키텍처를 사용하는 현대적 애플리케이션을 위한 목적별 데이터베이스입니다. 이러한 오퍼링 중 사용할 솔루션을 결정하는 방법 중 하나는 사용 사례가 일시적인지 아니면 높은 내구성을 요하는지를 기준으로 선택하는 것입니다. Amazon ElastiCache는 독립형 데이터베이스로 사용되기도 하지만, 내구성이 요구되지 않는 애플리케이션에만 사용됩니다. 반면 MemoryDB는 프라이머리 데이터베이스로 설계되었습니다. 또 다른 결정 요인으로, 팀이 Redis 또는 Memcached 엔진 중 무엇에 익숙한지를 고려합니다.

검색

검색 데이터베이스는 실시간에 가까운 분석 및 검색 기능을 제공합니다. 검색 데이터베이스의 일반적인 사용 사례로는 로그 분석, 실시간 애플리케이션 모니터링, 클릭스트림 분석 등이 있습니다.

Amazon OpenSearch Service를 사용하면 대화형 로그 분석, 실시간 애플리케이션 모니터링, 웹 사이트 검색 등의 작업을 손쉽게 수행할 수 있습니다. Amazon OpenSearch Service는 OpenSearch와 레거시 Elasticsearch OSS를 지원합니다.

그래프 데이터베이스

그래프 데이터베이스는 고도로 연결된 데이터 세트와 관련한 작업을 수행하는 애플리케이션을 손쉽게 구축하고 실행할 수 있도록 하는 용도로 사용됩니다. 그래프 데이터베이스의 일반적인 사용 사례로는 소셜 네트워킹, 추천 엔진, 사기 탐지, 지식 그래프 등이 있습니다. 그래프 데이터베이스가 적합한 옵션인지 판단할 때는 먼저 데이터를 그래프 구조로 표현하는 것이 가장 효과적인지 여부를 판단해야 합니다. 관계의 폭과 깊이가 확장되고 있나요? 관계가 복잡해질수록 관계형 데이터베이스에 대한 쿼리는 느려집니다. 스키마를 변경하는 작업이 팀에 부담이 될 정도로 모델 자체가 많이 변경되고 있나요? 마지막으로, 데이터의 관계에 대한 질문에 답해야 하나요? 그래프 데이터베이스는 이러한 관계에 대한 복잡한 쿼리를 지원하면서 이러한 유연성을 제공합니다. Amazon Neptune은 빠르고 신뢰성이 높은 완전관리형 그래프 데이터베이스 서비스입니다.

원장 데이터베이스

원장 데이터베이스는 데이터의 전체 계보를 추적하는 데 도움이 될 수 있습니다. Amazon Quantum Ledger Database(QLDB)는 완전관리형 원장 데이터베이스로, 중앙의 신뢰할 수 있는 기관이 소유하는 투명하고, 변경 불가능하며, 암호화 방식으로 검증 가능한 트랜잭션 로그를 제공합니다.

시계열 데이터베이스

시계열 데이터베이스는 애플리케이션이 시계열 데이터를 처리하고 내장된 분석 함수를 사용하여 그 데이터를 신속하게 분석해야 하는 사용 사례를 지원합니다. Amazon Timestream은 IoT 및 운영 애플리케이션을 위한 빠르고 확장 가능한 서버리스 시계열 데이터베이스 서비스입니다.

결론

초기 단계의 Startup으로서 여러분이 결정해야 할 가장 중요한 사항 중 하나는 어떤 유형의 데이터베이스 기술을 사용할지를 결정하는 것입니다. AWS에서 제공하는 목적별 데이터베이스를 검토할 때는 먼저 사용 사례부터 검토한 후 적합한 데이터베이스 서비스를 필터링하는 데 필요한 요구 사항을 정의합니다. 거기에 더해 출시 속도와 팀의 가용 기술 역량을 검토하되, 이러한 요인과 미래의 요구 사항을 균형 있게 함께 고려해야 합니다. 이제 이러한 요인을 고려하고 작업에 가장 적합한 데이터베이스 서비스를 선택하는 데 시간을 할애하는 것이 중요합니다.