🏃♂️ 오픈소스 데이터베이스로 탈 오라클! Why not?
현대화된 어플리케이션
- 설계 사상: 혁신, 민첩성
- 무제한: 성능, 확장성
- 비용: 고가용성, 관리 편의성, 비용 효율성
이중화, 자동 백업 등등
데이터 현대화 아키텍처
전통 방식에서 마이크로 서비스, 분산 아키텍처로 변화
AWS의 현대화
- 모놀리식 어플리케이션 → 마이크로 서비스
- 모놀리식 어플리케이션: 중앙 데이터베이스 + 종속 팀
- 마이크로 서비스: 독립 데이터베이스 + 2 피자 팀
데이터베이스 현대화
- 관리형 데이터베이스로 이동
- 오픈소스 데이터베이스로 이동
- 목적 지향 데이터베이스로 현대화
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: 원장 데이터 기록 시스템
정리
조직적으로나 기술적으로나 목적 지향 데이터베이스로의 현대화는 여정이다.
- 관계형 워크로드를 관리형 데이터베이스 서비스로 이관
- Amazon Aurora, Amazon RDS
- 개선사항: 민첩성, 관리 편의성, 비용 효율성
- 캐싱 및 인-메모리로 워크로드 오프로드 구현
- Amazon ElastiCache, Amazon MemoryDB
- 개선사항: 확장성 및 성능
- 비관계형 쿼리 패턴을 NoSQL로 이관
- Amazon DynamoDB, Amazon DocumentDB, Amazon Keyspaces
- 개선사항: 민첩성, 혁신, 확장성, 성능, 관리 편의성, 비용 효율성
- 전문 데이터 세트 및 쿼리 패턴을 전문 데이터베이스 서비스로 이관
- 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 전환 가이드 작성
- 개발
- 데이터 이전
- 서비스 중단 최소화를 고려한 데이터 이전 계획 수립
- 리허설 및 계획 수정/고도화
- 데이터 검증 방안 필요
- 운용 최적화
- 성능/쿼리 최적화(APM)
- 비용 최적화
- 리소스 최적화
- Graviton 적용
- 개발 검증 환경 RDS 대상 야간/주말 리소스 사용 중지 자동화
적합한 데이터베이스 선택
애플리케이션의 특징, 전환 개발 및 유지보수 비용을 고려한 적합한 DB 선택 필요
- 전환 대상 탐색
- DB 형태 고려
- 관계형 DB
- 데이터 재처리 빈번, Join 다수 발생 → RDB가 우수하다고 판단
- 재개발 비용에 대한 고려
- NoSQL
- 시계열 DB
- DB 선택
- MySQL
- Oracle과 성능, 기능 유사
- Vacuum 동작 시 실시간 성능 고려
- PostgreSQL
- 관리형/자체 관리형 선택
- Aurora MySQL
- 비용 대비 효과 성능 우수
- 구성 민첩성
- 관리 편의성
- 운영 부담 감소
- RDS for MySQL
- Serverless
- EC2에 자체 구축
성능 확보 및 확장성을 고려한 DB 분산 설계
- 업무 영역 별 DB 분산
- DB 샤딩
- 성능과 수평적 확장성 고려
- 샤드 간의 조인 불가한 조건을 고려한 Key 도출
- 비용 절감을 위한 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
- 성능 측면에서 기대 이상으로 만족, 비용 측면에서 지속적인 절감 노력 필요
- Oracle과 동등 수준 E2E 성능 확보
- 성능 갭 최소화를 위한 DB 최적화(분산) 설계 중요
- 쿼리 변환 및 애플리케이션 전환 개발에 대한 사전 가이드 수립 필요
- SQL 전환 가이드 사전 제공, 변경된 DB에 최적화된 스키마 및 인덱스 재구성 필요
- 데이터 마이그레이션 시 서비스 단절 최소화 및 데이터 검증 계획 필요
- DMS 등의 툴 활용 숙지, 수 차례의 리허설 진행을 통한 계획 수정 및 고도화
- DB 비용 비중 높음 (약 56%), DB 분산에 따른 유지보수 비용 증가 가능성 존재
- Graviton 사용 필수, 저가형 스토리지 사용 확대 필요, 유지보수 절감 방안 필요
향후계획 (23년)
- 애플리케이션 구조 개선 및 S3 활용 확대를 통한 비용 절감 추진
- TANGO의 클라우드 전환 지속 추진 (3G, LTE, IP 감시 기능 등)
- 비용 절감을 위한 애플리케이션 구조 최적화
- 캐쉬 활용 및 사용성이 적은 DB는 S3(Athena)로 전환 확대
- 서버리스 DB 활용 방안 검토중
- 사용률이 낮고, 절체 시간에 민감하지 않은 Slave DB에 적용 예정