[AWS 2023 Summit] 오픈소스 데이터베이스로 탈 오라클

최근에 AWS 2023 Summit의 2번째 날에 참가할 기회가 있었는데, 이 때 본 내용 중 가장 흥미로웠던 세션에 대해 소개해보고자 한다.

글 자체는 행사(4월 말 경) 끝나고 직후에 거의 작성해놨는데, 정리해서 올리는데 너무 오래 걸렸다...ㅎㅎ

같이 참가했던 팀원분들과 함께

오픈소스 데이터베이스로 탈 오라클

온프레미스로 떠있던 상용 데이터베이스 데이터를 클라우드 데이터베이스로 마이그레이션

이를 진행하기 전까지의 고민에 대한 이야기

데이터 베이스 트렌드

프론트↔서버↔(큐 캐시 메시지) ↔ 데이터 베이스

기존에는 oracle과 같은 RDBMS

aws로 마이그레이션 된 경우 dynamo db가 핵심

 

1.자체 관리형 → AWS 관리형

• 다른 클라우드와 연계가 쉽다
• 운영부담 감소
• 캐시 및 영구 인메모리 데이터를 활용
• 스케일링 문제 해결
• 성능 향상

2.상용 → 오픈소스

• 상용은 라이센스 비용 등의 비용들이 많이 들어감

3.모놀리식 → 마이크로서비스

 

비관계형 쿼리 패턴? DynamoDB?

💡 비관계형 쿼리 패턴 관계형 데이터베이스를 사용하면서 성능적인 문제를 일으키는 원인 중 하나인 Join 연산을 최소화하고 데이터를 정규화하지 않는 방식으로 관계형 데이터베이스의 성능 문제를 해결하고자 하는 패턴

AWS DynamoDB는 관계형 데이터베이스와는 다른 NoSQL 데이터베이스입니다. 기존의 DBMS인 Oracle과 비교하면 DynamoDB는 다음과 같은 차이점이 있습니다.

💡 NoSQL 데이터베이스 NoSQL은 SQL이 아닌 다른 데이터 저장 및 조회 기술을 지칭하는 용어입니다. NoSQL은 관계형 데이터베이스와는 다른 데이터 모델을 사용하며, 대부분 분산 시스템으로 구성되어 있습니다. NoSQL 데이터베이스는 스키마리스(Schemaless)이며, JOIN 연산을 지원하지 않으므로 비관계형 쿼리 패턴과 유사한 성격 가짐

1. 데이터 모델

Oracle은 관계형 데이터베이스이기 때문에 데이터는 테이블과 테이블 간의 관계로 구성됩니다. 반면에 DynamoDB는 NoSQL 데이터베이스로서 Key-Value 모델을 사용합니다. 이 모델은 데이터가 테이블 내의 항목(Item)으로 구성되며, 각 항목은 고유한 식별자인 Primary Key를 갖습니다.

 

2. 확장성

Oracle과 같은 기존의 DBMS는 일반적으로 수직 확장을 지원합니다. 이는 서버를 업그레이드하거나 추가하면 더 많은 리소스를 얻을 수 있다는 것을 의미합니다. 반면 DynamoDB는 수평 확장을 지원하며, 클러스터링을 통해 여러 대의 서버를 연결하여 대규모의 데이터 처리를 지원합니다.

 

3. 유연성

Oracle과 같은 관계형 데이터베이스는 스키마를 미리 정의하고 데이터를 삽입하기 전에 테이블을 만들어야 합니다. 이와 달리 DynamoDB는 스키마리스(Schemaless)이므로 데이터를 삽입하기 전에 미리 정의할 필요가 없습니다. 이는 데이터 모델을 빠르게 변경하고 새로운 필드를 추가하거나 삭제하는 등의 작업이 용이합니다.

 

4. 비용

Oracle과 같은 기존의 DBMS는 라이선스 및 유지보수 비용이 매우 높을 수 있습니다. 반면 DynamoDB는 서버나 라이선스 비용이 없으며, 사용한 용량에 대해서만 비용을 지불하면 됩니다.

따라서, Oracle과 같은 기존의 DBMS는 복잡하고 대규모의 데이터를 다루는 경우 적합하지만, DynamoDB는 대규모의 데이터를 빠르고 확장 가능하게 처리하고자 하는 경우에 적합합니다.

 

sk 텔레콤 Tango 클라우드 마이그레이션 사례

동기: 통신 기술의 발달로 데이터 통신량이 많아지고, 이러한 통신 데이터를 분석하고 다른 시스템과 연계 필요성이 늘어나 기존의 DB 시스템가 변화된 환경에 적합하지 않다 판단하여 전환을 하기로 결정하였음

 

tango = skt 망관리 시스템

하는김에 시스템 리팩토링도 했다+ 오픈소스DB로 전환

과정

설계, 개발, 데이터이전, 운용 최적화

오픈소스 DB 전환 과정

 

postgre vs mysql

SKT 측에서는 관계형 DB를 어떤 것을 쓸 것인지 검토할 때 최종적으로 MySQL과 PostgreSQL 사이에서 고민하다가 성능과 기능은 유사한데 postgresql 같은 경우 Vaccum 동작시 실시간 성능에 문제가 있을 우려가 있다라는 판단을 근거로 MySQL을 선택하셨다고 발표했었다.

(작성중)[Postgresql] Vacuum동작 과 MVCC (tistory.com)

(작성중)[Postgresql] Vacuum동작 과 MVCC

 

 

타겟데이터와 소스데이터 형태가 호환 되어야하기에 임시테이블 만들어 해결

 

데이터 마이그레이션 시 고려사항

1. 데이터 형식 변환
   마이그레이션 대상 데이터가 다른 DBMS나 파일 형식 등으로 저장되어 있을 경우, 이를 대상 DBMS에서 사용하는 형식으로 변환해야 합니다. 이를 위해서는 데이터 타입 변환, 문자열 인코딩 변환 등의 작업이 필요합니다.
   
   
2. 데이터 무결성 보장
   마이그레이션 대상 데이터는 데이터의 무결성이 보장되어야 합니다. 이를 위해 데이터 검증 프로세스를 추가하여 데이터 불일치 문제를 최소화하고, 데이터의 무결성을 보장할 수 있도록 해야 합니다.
   
   
3. 데이터 적재 방법
   마이그레이션 대상 데이터를 대상 DBMS에 적재하는 방법은 다양합니다. 대량의 데이터를 적재해야 하는 경우, 일괄 적재를 수행하는 방법이 효율적일 수 있습니다. 하지만, 대용량 데이터를 적재하는 경우, 데이터를 분할하여 여러 개의 작은 작업으로 나누어 수행하는 것이 효율적일 수 있습니다.
   
   
4. 성능 최적화
   마이그레이션 프로세스는 대량의 데이터를 다루기 때문에, 성능 최적화가 필요합니다. 이를 위해 병렬 처리, 인덱싱, 캐싱 등의 기술을 사용하여 처리 성능을 최적화할 수 있습니다.
   
   
5. 백업과 롤백
   마이그레이션을 수행하기 전에는 대상 시스템의 백업을 수행하고, 마이그레이션을 수행하는 도중에 문제가 발생하면 롤백할 수 있는 방법을 마련해야 합니다.
   
   
6. 보안
   마이그레이션 대상 데이터는 중요한 정보를 담고 있기 때문에, 보안에 대한 고민이 필요합니다. 데이터 암호화, 접근 권한 제한, 보안 로그 등의 기술을 사용하여 보안을 강화할 수 있습니다.
   
   
7. 유지보수 계획
   마이그레이션 후에도 시스템의 안정성을 유지하기 위해 유지보수 계획을 수립해야 합니다. 이를 위해 시스템 모니터링, 이슈 트래킹 등의 방법을 사용하여 유지보수를 수행할 수 있습니다.

서비스의 단절

db의 유효성 검증

클라우드 전환시 가장 큰 문제는 비용, 이를 줄이기 위한 노력

어떤 cpu를 선택할지 실험하고 의사결정하였음

쿼리 최적화, 적절한 리소스 선택

인스턴스 최적화

야간 휴일 리소스 중지/시작 람다 통해 개발

 

교훈

오라클과 동등 수준의 성능 확보

다만 그냥 도입만으로는 성능 못따라간다 오픈소스 db는 최적화 필요

 

느낀점

기존의 서비스를 클라우드로 단순히 옮기면 땡이 아니라는 것을 느꼈다.

온프레미스 환경이 비효율적이라 생각하여 클라우드로 넘어갔지만, 결국 클라우드를 효율적으로 사용하기 위해서는 많은 노력이 필요하다는 것을 느꼈다. 특히 클라우드 같은 경우는 사용하는 만큼 비용이 지불되는 구조가 대부분이기에 얼마나 효율적으로 사용하냐? 가 비용에 직접적으로 연결되기에 더욱 중요한 것 같다. 

 

또한 서비스를 유지하기 위해 필수적인 요소들을 클라우드 서비스를 통해 사용하다가 어느 순간 클라우드 업체(Aws 등)가 요금을 인상한다든지 등의 우리가 통제할 수 없는 외부 요인에 의해 서비스 유지비용이 급격히 증가하고, 이에 따른 서비스 장애 혹은 추가적인 유지보수가 필요할 수 있겠다는 보수적인(?) 생각이 들기도 했다.

 

이전까지 클라우드로의 서비스 이전의 장점을 주로 보았다면, 위의 실제 마이그레이션 사례를 들으며 역시 모든 것엔 장점만 있을 수는 없다는 것을 느꼈다.