도쿄 리전에서 서비스하던 스푼 라디오를 서울 리전으로 옮기면서 겪은 다양한 삽질과 노하우를 함께 공유합니다.

1. SEOUL
스푼라디오
일본에서 한국으로
이전하기
최상기 / 리드, 마이쿤

2. 발표자 소개
최상기
스푼라디오 글로벌 서비스 운영
E: sanggi.choi@gmail.com
L: https://www.linkedin.com/in/sanggi-choi/

3. 이야기 할 내용
● 마이그레이션
● AWS 기본
● 자동화

4. SPOON RADIO (#Be A’LiVE)
Ordinary can be Extraordinary

5. 생존 그리고 성장

6. 2016년 - 스푼 라디오
2015년 하반기 부터 AWS
Tokyo Region에 서비스
오픈 준비
2016년 3월 스푼 라디오
한국 서비스 시작
2016년 1월 AWS Seoul
Region Launch

7. 월간 콘텐츠 생산자 수
250,000
콘텐츠 생산자 비율 11%
(2018) KB Investment, GOODWATER, SoftBank 등으로부터 190억 원
(2019) KB Investment, IMM Investment, NAVER 등으로부터 450억 원
LVE 콘텐츠 평균 청취자 수
15
쌍방향 소통 중심의 작은 방송
출시 국가
10
한국, 일본, 미국, 베트남, 인도네시아 등
일간 콘텐츠 업로드 수
100,000
88%는 LIVE 콘텐츠
월간 활성 사용자 수
2,200,000
해외 사용자가 75%
연간 아이템 판매액 (2019년)
460억 원
전년 대비 100% 성장
투자 유치
2019년 - 스푼 라디오

8. 2020년 - 스푼 라디오
출처
- 한국 인터넷 진흥원 ISMS-P 인증 대상
● 정보보호 및 개인정보보호 관리체계 인증

9. 그러나 스푼 라디오 AWS 인프라 구성은
회사 생존과 서비스 성장을
위해 구전으로만 전달되고
있었으니……..

10. 이참에 정리해 마이그레이션 하자!

11. 마이그레이션 전략

12. 마이그레이션 전략
● 안전
● AWS Well-Architected Framework
● 자동화
● 모니터링

13. 무엇을 이전할 것인가?
● 80 여개 Workload
○ 50여개 EC2
○ 150GB DB
○ 300TB S3
○ 10 여개 Serverless
○ 약 100여개의 AWS Resource들로 구성
미션
크리티컬한
자원들

14. AWS Well-Architected

15. 자동화 도구들
Code
Repository
Infrastructure
Provisioning
Image
Management
Configuration
Management
CI/CD
Application
Error System
Monitoring
System
Code
Repository
(Terraform,
Packer, AWX,
Ansible,
Dockerfile..etc)
AWS
Infrastructure
(VPC, Subnet,
Security Group,
IAM, S3.. etc)
AWS AMI Base
Image
(Amazon Linux,
Ubuntu,
CentOS..etc)
Software
Provisioning
(Nginx,Python,J
ava,Docker..etc)
Continuous
Integration &
Delivery
(Terraform,
Packer,
Application,
Web)
Open-source
full-stack error
tracking system
Open Source
Monitoring
Software for IT
Infrastructure
and New Relic
APM
Terragrunt
Sentry

16. Rebuling AWS Infra

17. Multi Account AWS
● 각 서비스 용도별 Account 구성
○ HUB
○ PRD / STG / DEV
○ DATA & LOG
○ MGT

18. 신규 서비스 인프라 환경

19. CI / CD

20. 운영 시스템

21. 마이그레이션 준비

22. 사무실 인터넷
인프라 구성
CI / CD
모니터링
Data 이관
(DB, Log etc)
서비스 오픈 전
인하우스
테스트
도메인 이관(-)
마케팅 이벤트
개발 스프린트
서비스 운영(CS)
배포 / 테스트
서비스 차단/해지
거버넌스 반복 테스트
(실수 방지)
사전 완료
서비스 오픈 후
테스트
AWS / Megazone

23. 파일럿 테스트

24. Database Migration
● Cross Region Replica
● Database Migration Service
● Snapshot Cross Region Copy & Share, Restore

25. Database - Cross Region Replica(불가)
• 서비스 중단 최소화 ( Replica를 Master로 승격 )
• Aurora Postgresql은 Cross Region Replica 지원하지 않음.
(MySql Aurora 만 지원 - 2019년 11월 기준)

26. Database - Database Migration Service(불가)
• 서비스 중단 최소화
• Aurora Postgresql 10.x 부터 DMS 사용 가능
• Aurora Postgresql 9.x 사용 중
• DMS로 DB Migration 진행 불가

27. Database - Snapshot Cross Region Copy & Share, Restore
• 단순하지만 다른 방법에 비해 시간이 오래 걸림.
• 서비스 중단 필요 (Operation 포함해 약 60분 정도 소요)
• 그러나 가장 안정적임.
• 그리고 Aurora Postgresql 9.x 버전에서도 사용 가능

28. S3 Migration - 약 300TB
97,033,120 (300T) Object
복사 수행, 62시간 소요
6,625,278 Object 복사
수행, 42개 에러 발생

29. Elasticsearch Service

30. DocDB - Mongodump / Mongorestore
DocumentDB
(with MongoDB
Compatibility)
Public subnet
Tokyo Region (ap-northeast-1)
Private subnet
Migration File
transfer Server
Seoul Region (ap-northeast-2)
DocumentDB
(with MongoDB
Compatibility)
Public subnet
Migration dump Server
Private subnet
Migration restore Server
• 기존 MongoDB 마이그레이션 에서 사용되는 검증된
방법
• 서비스 중단이 필요 (약 60~70분 소요)
• 클라우드 환경의 장점, High spec Docdb 사용시
마이그레이션 시간을 단축 시킬 수 있음.
(최종 35분 소요)

31. 서비스 중단
● 테스트
○ 데이터 마이그레이션 3회, 전체 5회 진행
○ 20명 인원, 소요 시간 1시간 30분
● 서비스 중단
○ 월요일 새벽 5시 부터 7시 30분 (2시간 30분)

32. 마이그레이션
- 2019년 11월 25일 05:00

33. 계획과 현실
● 일주 전 부터 고객 사전 공지
● 계획대로 진행
그러나 예상 외 이슈 발생(결제, Live LB, DNS 등등)
○ 이슈 해결을 위해 6회 배포 진행
● 계획된 2시간 30분을 모두 채우고 서비스 오픈

34. 마이그레이션
legacy Infra
latest Infra
(UTC±0)
05:00 07:00
06시 DNS 변경

35. 마이그레이션 이후
● 달라진게 없음
○ 시스템 반응성 약 15% 향상
○ 좀 더 보안이 강화된 서비스 제공 기틀 마련

36. 마이그레이션 이후
● 좀 더 다른 방법으로 또 다른 마이그레이션 준비
○ 10.x postgresql engine upgrade
○ 실수 발생 환경 제거
○ 견고한 IaC 구성

37. 정리

38. 마이그레이션
전략 수립현황 분석 사전 작업 테스트 마이그레이션 안정화
- ISMS-P
인증 대상
- 한국
서비스는
한국에서
- 안정
- 리팩토링
- 자동화
- Account 분리
- 신규 인프라
구성
- CI / CD
- Monitoring
- ALB Pre-Warm
- 사람 실수
방지
- 신규 시스템
안정성 확보
- 마이그레이션
에 걸리는
시간 확인
- 2시간
30분
- 테스트 &
6회 배포
- 마이그레이션
리소스 삭제
- 안정화 및 또 다른
마이그레이션
준비
2 M 1M 2h 30min2 M 3 M
DevOps 여정 마이그레이션

39. 정리
● AWS Well-Architected Framework
● 트렌드
● 자동화

41. 감사합니다