AWS Document DB 오프라인 세미나 후기

세미나, 왜 신청했는가!

 

2023.10.23 에 진행되는 AWS Document DB 세미나에 참여하고 왔다.

현재 우리 회사에서 MongoDB 나 DocumentDB를 사용하고 있는 것은 아니었으나,

NoSQL인 DynamoDB 를 쓰고 있고, 새롭게 시스템 구축이 필요할 때 Dynamo와는 다른 NoSQL 선택지가 어떤 것이 있을지

궁금해서 세미나에 신청했다.

 

강사님의 강사력(?)도 너무 좋았고, 내용도 일반 강의에서는 골라 듣기 어려운 실무적인 내용이 많이 들어있어서

이제 막 여러 DB를 사용해보기 시작한 나에게는 너무나 유익했던 시간이었다.

(업무시간 빼고 5시간 투자할 가치가 충분했습니다. 다들 츄라이 츄라이)

 

 

아래는 강의 세션을 들으면서 내가 기록했던 것들이다.

지식 습득용보다는, 이런 내용들로 세미나 세션이 흘러갔구나~ 하고 보면 좋을 것 같다.

 

 

---

 

 

자주 등장한 키워드

 

• Sharding
• Schemaless
• Secondary index

 

 

 

Why Document Store DB?

샤딩과 Secondary index

왜 NoSQL 진영에서 Document Store DB를 가장 많이 사용할까? 에 대한 답변이다.

NoSQL 데이터베이스 시스템은 일반적으로 데이터의 확장성 측면에서 샤딩을 쉽게 처리할 수 있다.

하지만 다른 Document Store DB 는 다른 NoSQL DB 들과 다르게 Secondary index 를 지원한다.

대표적으로 카산드라와 같은 NoSQL 은 Secondary index 를 지원하지 않는다.

 

결국 Document Store DB는 관계형 데이터베이스 수준의 B+트리로

Secondary index 를 지원하는 거의 유일한 구조이기 때문에 많이 선택되는 선택지이다.

 

 

유연한 json 지원

• 데이터의 converting 이 필요없음
• json 을 의 key를 컬럼 하나하나처럼 사용하는 것은 document store db 가 거의 유일함

 

비정규화 데이터 모델

• 기존 RDB는 스키마가 변경됨에 따라 유연하게 대응하기가 쉽지 않음
• 조회 조건을 다양하게 써야하는 상황에서 유리

 

"Schemaless 하다"

 

강사님이 계속해서 강조했던 키워드이다.

이는 장점이 아닌 특징으로, 이 특징 때문에 얻는 이점과, 단점을 명확하게 알고 선택해야한다.

 

관계형 DB는 고정적인 스키마를 사용하고 있어 테이블의 컬럼과 데이터 타입이 정해져있다.

이는 Storage에 저장될 때는 값들만 저장되고 있다는 의미이다.

 

하지만 Schemaless 한 특징을 가지고 있는 NoSQL 은 무조건 필드 명과 value 를

같이 디스크에 저장해야한다. 이는 곧 저장 사이즈가 커진다는 의미이다.

저장 사이즈가 커진다? 어? 이거 읽고 쓸 때 IO 가 더 늘어나겠네?

 

맞다. DB 인스턴스에서 성능을 결정하는 주 원인은 IO 이다.

우리가 index 를 설정하는 이유도 read query 하나를 위해 할당되는 IO 를 줄일 수 있기 때문인데,

저장 사이즈가 늘어남으로 인해 증가되는 IO... 이거 무조건 Trade Off 라는 생각을 해야한다.

 

=> 결론

: 성능이냐, 편리성이냐를 잘 고려해야한다.

 

 

30초 꿀팁!

 

컬럼명 가능한 작게 잡으세요...^~^

저장공간 뿐만 아니라 성능 자체도 올라갑니다.

 

unique id 따로 잡지 말고, _id 라는 머신 제너레이트되는 유니크한 데이터 항목을 사용하세요!

데이터가 추가될 때 _id 라는 12바이트 짜리 항목이 새로 생성되는데, 이를 이용하면 12바이트를 줄일 수 있습니다.

 

 

 

DocumentStore Data Model

 

이 단계가 잘못되면, 서비스에 문제가 생기고 데이터를 다시 쌓아야한다고 하셨다.

모델링 방식은 크게 embedded 방식과 reference 방식이 있다.

 

embedded data model

• Document store 계열 DB를 사용하는데에 올바른 모델링이 맞음
• 서브 도큐먼트를 변경할 때 lock 문제가 발생함.
  • 즉, 동시성 처리가 힘들어짐.

 

reference data model

• 분리되어 있으므로 서브 도큐먼트 수정이 가능해짐.
• join 과정이 필요함. 만약 mongoDB 기준이면 lookup 을 이용해서 join 해야하는데,
  join 이 너무 과도하면 차라리 RDB 선택하는게 더 나음.

 

=> 결론

: 모델링 잘해야합니다. Access pattern 에 대한 분석이 무엇보다 중요해요.

 

 

이 모델에 대한 설명 이후 실제 예시를 통해 어떤 식으로 모델링을 하면 좋을지에 대한 얘기가 이어졌다.

인상적이었던 부분은,
같은 N:M 관계일 때도 그 숫자, 패턴에 의해 임베디드를 선택할지, 레퍼런스를 선택할지가 분명하게 갈린다는 점이었다.

(정말.. 케바케 그 자체. 경험과 통찰력이 참 중요해보였다.)

우리 회사 서비스 중 일부가 RDB에서 NoSQL 로 넘어가면서 수없이 구조를 뒤엎었다.

솔직히 나는 내가 아직 이 기술에 대한 이해가 부족해서 그런가보다... 하고 생각했었는데,

이 부분에서 많은 위안을 얻었다. 정답은 없고, 정답에 가까워지는 길만 무수하게 존재했었던 거구나!

이건 당연하게 겪었어야할 시행착오였구나..! 라는 생각을 하면서 마음이 편안(?)해졌다.

 

 

DocumentDB Architecture

 

 

• AWS Aurora 와 동일한 아키텍처(Mongo DB와는 다른 아키텍처이다.)
• 완전 관리형
  • 고가용성 내장
  • 백업 기본
  • 내구성 기본 제공
  • 모니터링 및 알람
• 확장성
  • 몇 분 내 컴퓨팅 확장
  • 스토리지 및 IO 자동 확장
• MongoDB API 호환

 

 

DocumentDB 는 크게 컴퓨트 레이어와 스토리지 레이어로 분리될 수 있다.

컴퓨트 레이어는 API, Query processor, Caching 등의 역할을,

스토리지 레이어는 logging, storage 의 역할을 담당한다.

 

(이러한 구조는 트래픽에 따라 필요에 맞춰 증설, 축소 시키기 편리하기 때문이라고 한다.)

 

 

 

이 밖에도 복제는 없으나 복제 지연은 있는 신기한 DocumentDB 의 특징, 샤딩을 위한 Elastic Cluster 등

다양한 설명이 이어졌다.

 

강사님이 실제 설계 단계에서의 잘못된 판단이 실제 서비스의 장애로 이어졌던 경험을 얘기해주시는데,

이거 남일 같지가 않았다. ㅠㅅㅠ

쿼리의 중요성 판단과 서비스의 액세스 패턴을 파악하고 분석하는 일은 DBA 의 업무가 아닌

개발자의 몫이 맞는 것 같다. 

나는 설계 단계에서 어디까지 우리 서비스를 이해하고 분석할 수 있는가? 하며 자기 반성의 시간도 짧게 가졌다.

 

좋은(훌륭한) 샤드 키 설정 방법도 나오고, DocumentDB 와 MongoDB 의 비교 세션도 있었다.

해당 키워드에 평소 관심이 있었거나 궁금해졌다면 서칭해보길 바란다.

예전 운영체제 시간에 들었던 것만 같은 내용(dirty page)들도 있었다. 개인적으로 너무 재밌었다.

정말 유익하고도 훌륭한 시간이었으니, 기회가 있으면 신청해보길 바라며 이만 포스팅을 마치겠다!