[AWS Summit Seoul 2023] Day2 - 오픈소스 데이터베이스로 탈 오라클! Why not?

hwwwa·2023년 5월 6일
0

🏃‍♂️ 오픈소스 데이터베이스로 탈 오라클! Why not?

현대화된 어플리케이션

  • 설계 사상: 혁신, 민첩성
  • 무제한: 성능, 확장성
  • 비용: 고가용성, 관리 편의성, 비용 효율성

이중화, 자동 백업 등등

데이터 현대화 아키텍처

전통 방식에서 마이크로 서비스, 분산 아키텍처로 변화

AWS의 현대화

  • 모놀리식 어플리케이션 → 마이크로 서비스
    • 모놀리식 어플리케이션: 중앙 데이터베이스 + 종속 팀
    • 마이크로 서비스: 독립 데이터베이스 + 2 피자 팀

데이터베이스 현대화

  1. 관리형 데이터베이스로 이동
    • 자체 관리형 → AWS 관리형
  2. 오픈소스 데이터베이스로 이동
    • 상용 → 오픈소스
  3. 목적 지향 데이터베이스로 현대화
    • 모놀리식 → 마이크로 서비스

1단계: 관리형 데이터베이스로 이관

  • 기존 관계형 데이터베이스 → 관리형 데이터베이스 도입
  • 민첩성, 관리 편의성, 비용 효율성 증가
    • 운영 부담 감소
    • 플랫폼 기능의 장점 활용
  • Amazon RDS, Amazon Aurora: 클라우드 네이티브 데이터베이스

2단계: 캐시 및 영구 인메모리 데이터

  • ex) Redis
  • 스케일링 문제 해결
    • 손쉬운 도입
    • 반복적 읽기 작업 부하 경감
    • 세션 상태 저장
    • 데이터 캐싱
  • 성능 향상
    • 빈번한 카운터
    • 급변하는 순위
    • 밀리 초 미만의 데이터 액세스
  • Amazon ElastiCache: 빈번한 액세스 데이터 캐싱
  • Amazon MemoryDB: 지속적이고 내구성 있는 인메모리 데이터 스트럭처

3단계: 비 관계형 데이터 쿼리

  • 모놀리스 구조 분해
    • 용도에 맞는 적합한 도구
    • 마이크로 서비스 액세스 패턴이 데이터 스토어를 결정
  • 장점
    • 민첩성
    • 확장성
    • 성능
  • Amazon DynamoDB: 키-벨류, 글로벌 액세스 가능한 데이터 세트
  • Amazon DocumentDB: 도큐먼트 형태 데이터 세트
  • Amazon Keyspaces: 와이드 컬럼 데이터 세트

4단계: 전문화된 데이터 상호작용

  • 워크로드 특성에 맞는 데이터베이스를 선택하여 사용
  • 전문 데이터 세트
    • 소셜 그래프
    • 추천 엔진
    • 시간 별 데이터
    • 기록 시스템
    • 디지털 기록
  • 장점
    • 민첩성
    • 확장성
    • 성능
  • Amazon Neptune: 그래프 및 고도로 연결된 데이터
  • Amazon Timestream: 시계열 데이터 세트
    • 그래프DB. IoT 센서의 데이터를 시간대별로 저장 가능
  • Amazon QLDB: 원장 데이터 기록 시스템

정리

조직적으로나 기술적으로나 목적 지향 데이터베이스로의 현대화는 여정이다.

  1. 관계형 워크로드를 관리형 데이터베이스 서비스로 이관
    • Amazon Aurora, Amazon RDS
    • 개선사항: 민첩성, 관리 편의성, 비용 효율성
  2. 캐싱 및 인-메모리로 워크로드 오프로드 구현
    • Amazon ElastiCache, Amazon MemoryDB
    • 개선사항: 확장성 및 성능
  3. 비관계형 쿼리 패턴을 NoSQL로 이관
    • Amazon DynamoDB, Amazon DocumentDB, Amazon Keyspaces
    • 개선사항: 민첩성, 혁신, 확장성, 성능, 관리 편의성, 비용 효율성
  4. 전문 데이터 세트 및 쿼리 패턴을 전문 데이터베이스 서비스로 이관
    • Amazon Neptune, Amazon Timestream, Amazon QLDB
    • 개선사항: 민첩성, 혁신, 확장성, 성능, 관리 편의성, 비용 효율성

SK 텔레콤 마이그레이션 사례

TANGO

TANGO(T-ADVANCED NEXT GENERATION OSS)의 클라우드 전환 계획

  • TANGO란?
    • SKT 망 관리 시스템
    • 주요기능: 장비 관리, 감시, 분석, 망 설계 구축
    • 구성: O, I, PF, A, EC
      • Operation: 성능, 고장 감시 → 클라우드 전환 대상
      • Inventory: 장비 관리 → 클라우드 전환 대상
      • Platform: 공통 기능 → 클라우드 전환 대상
      • Analytics: 데이터 분석 → On premise 유지
      • Engineering & Construction: 설계 및 구축 → On Premise 유지
  • 퍼블릭 클라우드 전환 추진 일정
    • 오픈소스 DB 전환 방안 설계 (21년)
    • 5G 망 감시 시스템 (22년)
    • 3G, LTE, IP 망 감시시스템 (23년)
    • 장비관리 및 공통기능 (24년)

클라우드 전환 목표

클라우드 기반 TANGO 서비스의 변화 혁신을 목표로 함

단순한 클라우드로의 이전이 아닌 앱의 리팩토링을 통해 성능, 비용 및 안정성 개선을 목표로 함

  • 클라우드 네이티브 개발
    • MSA/컨테이너 기반 개발
    • 확장성, 가용성 향상
  • 서비스 구조개선(리팩토링)
    • 앱 구조 개선
    • 단위 성능, 속도 향상
  • 오픈소스 DB 전환
    • 탈 오라클
    • 비용 절감, 종속성 제거
  • TCO 구조 혁신
    • 중복 기능, 데이터 제거
    • 투자비, 운영비 최소화

현재 DB의 구조적 이슈

  • DB 구조: 모놀리식
  • 환경 변화
    • 망 진화(LTE/5G)로 인한 관리 대상 장비 및 데이터 증가
    • 자동화(AI) 및 데이터 분석 등 연동 요구 데이터 증가
  • 확장성 한계
    • 수직적 확장에 의존
    • 수평적 확장을 위해서 DB 및 앱 재설계 필요
  • 성능 이슈
    • 처리 및 연동 데이터 증가에 따른 성능 이슈 발생
    • AI 기반 앱 진화에 어려움 발생
  • 비용 증가
    • 시스템 확장에 따른 S/W 라이센스 비용 부담 증가
    • 단일 솔루션 의존성 경감 필요

→ 확장성 한계 및 성능 이슈를 극복하기 위해 오픈소스 DB로의 전환 필요

오픈소스 DB 전환 여정

전환 단계별 검토 필요 항목

오픈소스 DB 전환 단계별 검토 항목 (체크리스트)

  • 설계
    • 적합한 DB 선택
    • 확장성, 성능 및 비용을 고려한 설계
      • 분산 설계
      • Query Awareness
      • SS 활용 (DB 대안)
    • SQL 전환 가이드 작성
  • 개발
    • DB 구축
    • SQL 전환 개발
  • 데이터 이전
    • 서비스 중단 최소화를 고려한 데이터 이전 계획 수립
    • 리허설 및 계획 수정/고도화
    • 데이터 검증 방안 필요
  • 운용 최적화
    • 성능/쿼리 최적화(APM)
    • 비용 최적화
      • 리소스 최적화
      • Graviton 적용
      • 개발 검증 환경 RDS 대상 야간/주말 리소스 사용 중지 자동화

적합한 데이터베이스 선택

애플리케이션의 특징, 전환 개발 및 유지보수 비용을 고려한 적합한 DB 선택 필요

  1. 전환 대상 탐색
    • Oracle
  2. DB 형태 고려
    • 관계형 DB
      • 데이터 재처리 빈번, Join 다수 발생 → RDB가 우수하다고 판단
      • 재개발 비용에 대한 고려
    • NoSQL
    • 시계열 DB
  3. DB 선택
    • MySQL
      • Oracle과 성능, 기능 유사
      • Vacuum 동작 시 실시간 성능 고려
    • PostgreSQL
  4. 관리형/자체 관리형 선택
    • Aurora MySQL
      • 비용 대비 효과 성능 우수
      • 구성 민첩성
      • 관리 편의성
      • 운영 부담 감소
    • RDS for MySQL
    • Serverless
    • EC2에 자체 구축

성능 확보 및 확장성을 고려한 DB 분산 설계

  • 업무 영역 별 DB 분산
    • 의존성이 없는 데이터의 DB 분리
  • DB 샤딩
    • 성능과 수평적 확장성 고려
    • 샤드 간의 조인 불가한 조건을 고려한 Key 도출
      • ex) 성능 지표 ID
  • 비용 절감을 위한 S3 활용
    • 조회 빈도와 성능 민감도를 고려하여 DB 대안으로 활용
  • Query Awareness를 활용한 처리 분산
    • Slave(Read Replica)를 활용한 Select Query 처리
    • Master 노드의 부하 경감

SQL 전환 가이드 작성 및 활용

  • 효율적인 전환 개발 및 성능 확보를 위해 MySQL 적용 가이드라인 사전 제공
    • SQL 유형별 성능 개선 방안을 제공
    • 성능 우려가 있는 모듈은 업무 조건 및 기능 변경 진행

데이터마이그레이션

  • 중계 서버 및 DMS를 활용하여 Oracle에서 Aurora MySQL로 데이터 마이그레이션 진행
    • DMS의 소스와 타겟 데이터 간의 데이터 형태가 호환될 수 있도록 중계 서버에 임시 테이블 구성
  • AWS DMS (Database Migration Service)
    • 데이터베이스 및 분석 워크로드를 AWS로 빠르고 안전하게 이동하여 가동 중단 시간 및 데이터 손실 방지를 돕는 관리형 마이그레이션 및 복제 서비스

GRAVITON 적용을 위한 테스트 결과 공유

  • TANGO 애플리케이션의 정상 동작 및 성능 비교를 위한 Graviton vs Intel 비교 테스트 진행
  • TANGO 정상 동작, 부하가 낮은 DB의 경우에는 성능 차이가 없으나, 부하가 큰 경우 Graviton이 우수한 성능을 보임
    ⇒ Graviton CPU의 가격은 11.7% 저렴하고 성능은 약 1.3배 이상 우수하여 TANGO 적용 의사결정

비용 최적화

  • 쿼리 최적화 진행 및 리소스 사용량을 기반으로 적절한 리소스를 선택하여 비용 최적화
  • 개발이 완료된 이후 Read Replica 삭제야간/휴일 리소스 중지/시작 자동화 기능 적용

Lesson Learned

  • 성능 측면에서 기대 이상으로 만족, 비용 측면에서 지속적인 절감 노력 필요
  1. Oracle과 동등 수준 E2E 성능 확보
    • 성능 갭 최소화를 위한 DB 최적화(분산) 설계 중요
  2. 쿼리 변환 및 애플리케이션 전환 개발에 대한 사전 가이드 수립 필요
    • SQL 전환 가이드 사전 제공, 변경된 DB에 최적화된 스키마 및 인덱스 재구성 필요
  3. 데이터 마이그레이션 시 서비스 단절 최소화 및 데이터 검증 계획 필요
    • DMS 등의 툴 활용 숙지, 수 차례의 리허설 진행을 통한 계획 수정 및 고도화
  4. DB 비용 비중 높음 (약 56%), DB 분산에 따른 유지보수 비용 증가 가능성 존재
    • Graviton 사용 필수, 저가형 스토리지 사용 확대 필요, 유지보수 절감 방안 필요

향후계획 (23년)

  • 애플리케이션 구조 개선 및 S3 활용 확대를 통한 비용 절감 추진
  1. TANGO의 클라우드 전환 지속 추진 (3G, LTE, IP 감시 기능 등)
    • 오픈소스 DB 전환 확대
  2. 비용 절감을 위한 애플리케이션 구조 최적화
    • 캐쉬 활용 및 사용성이 적은 DB는 S3(Athena)로 전환 확대
  3. 서버리스 DB 활용 방안 검토중
    • 사용률이 낮고, 절체 시간에 민감하지 않은 Slave DB에 적용 예정

0개의 댓글