[AWS Community Day 2020 세션 레포트] 스푼라디오 일본에서 한국으로 이전하기 – 최상기님 (마이쿤)

안녕하세요! 클래스메소드 주식회사 의 김태우입니다.

작년에는 한국에서 AWS 소모임이나 각종 행사들이 열릴때마다 항상 가고싶어서 부러워하곤 했는데요..ㅋㅋ 올해부터는 적극적으로 한국의 AWS 행사에도 참여하고자 합니다! 그런 의미에서 저도 지난 1/21(화) 에 열린 AWS Community Day 2020 에 다녀왔습니다.

본 블로그는 마이쿤의 최상기님께서 발표하신 세션을 참가하면서 개인적으로 노트했던 내용을 정리한 글입니다.

본 행사의 다른 블로그도 작성해두었으니 관심있으신 분들은 읽어주세요 :)

[AWS Community Day 2020 세션 레포트] Heroes 패널토크 – 클라우드 기술의 미래

[AWS Community Day 2020 세션 레포트] 전 세계 팬들이 모일 수 있는 플랫폼 만들기 – 강진우님 (beNX)

[AWS Community Day 2020 세션 레포트] 스푼라디오 일본에서 한국으로 이전하기 – 최상기님 (마이쿤)

목차

세션 슬라이드

발표자 소개

• 최상기님 (리드, 마이쿤)
• 스푼라디오 글로벌 서비스 운영

세션 소개

일본에서 서비스를 제공하고 있으면서 왜 마이그레이션 준비를 해야했는지, 준비하면서 고민했던 사항들, AWS 기본 및 자동화에 대해 소개하겠다.

발표내용 노트

SPOON RADIO

• 실시간 오디오 스트리밍 서비스
• 별게 아닌데 소통을 통해 별게 되는 그런 서비스를 제공하고 있다.

2016년 - 스푼 라디오

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

2019년 - 스푼라디오

• 리젼은 6개, 나라는 10개국
• 대규모보다는 고객한명한명과 강결합된 서비스

2020년 - 스푼 라디오

• ISMS-P
• 고객 데이터가 잘 관리되고 있는지 규제함
• 연매출 100억원 이상이거나 OR 일일 사용자가 100만명 이상인 서비스는 무조건 따라아하는 규제
• 규제... 어떻게하지
• 이참에 정리해서 마이그레이션 하자

마이그레이션 전략

• 안전 : 잘해봐야 본전. 못하면 폭망
• AWS Well-Architected Framework
• 자동화 : 안전하게 하기 위해 반복테스트가 필요 - 자동화 필수
• 모니터링 : feature-over 및 take-over 가 되는 지 확인하기 위해 필수

무엇을 이전할 것인가?

• 미션 크리티컬한 작업
• 80여개 Workload
• 50여개 EC2
• 150GB DB
• 300TB S3
• 10여개 Serverless
• 안정성에 가장 많이 신경 썼음

AWS Well-Architected Framework

• AWS Well-Architected Framework 백서가 정말 도움이 많이 되었음.
• 백서 링크

자동화 도구들

• 총 7가지 정도를 썼다.
• 코드관리는 Bitbucket
• IaC Terraform and Terragrunt
• 이미지는 Packer 와 Ansible
• Vault 랑 Ansible - 특정국가에 의존하는 환경변수때문에 같은 애플리케이션이 다르게 동작함. 통합 설정 관리가 필요했음
• CI/CD 는 Jenkins 와 AWX
• Sentry / Kibana (Application Error System)
• Zabbix (글로벌 인프라) / New Relic (API 관련)

AWS

• AWS 에서는 Landing Zone 이라는 솔루션을 제공하고 있음. 근데 우리가 쓰기에는 너무 복잡. 요구사항 많음. 그래서 그걸 참고삼아 목적별로 어카운트를 나눔
• HUB : 유저 사용자 (Switch-role 허브)
• PRD/STG/DEV
• DATA & LOG (자국민의 데이터는 자국서비스 리젼에 있어야한다는 요구사항)
• MGT (Sentry / Zenkins / Zabbix 운용)

신규 인프라 환경

• VPC 를 나눔 (데이터와 서버 쪽) : 완전 격리시킴 (NAT 는 서비스 VPC 에만 존재)
• CI/CD 는 젠킨스로 멀티 파이프라인 구축 (Zenkins + Vault)

데이터 VPC 와 서비스 VPC 로 나누고 VPC Peering 으로 묶는 아키텍쳐는 좀 신기했습니다. 생각해보면 동일 AZ 상에 위치한 VPC 라면 latency 문제도 없고 비용도 발생하지 않으니 subnet 으로 나누는것보다 한층 더 secure 한 아키텍쳐라는 생각이 들었습니다. 하지만 VPC 가 다르기때문에 서비스 운영측면에서는 use case 에 따라 약간의 공수가 더 발생할 지도 모른다는 생각이 들었습니다. 여러가지로 꼼꼼히 따져보고 설계해야겠네요!

마이그레이션

거버넌스

• 마이그레이션 전후로 마케팅 이벤트를 조정해주세요
• 서비스 운영(CS) 쪽에서는 공지사항 계속 올릴 수 있도록
• 개발 스프린트를 조정을 해서 마이그레이션에 집중할 수 있도록
• AWS/Megazone 과 협력사항

반복테스트

• 이외에는 별다른게 없다. 반복테스트 밖에 없음.
• 사이클을 계속 돌면서 실수를 하지 않도록.

파일럿 테스트

• 아예 전부다 새로 만든 인프라에 스테이징 테스트를 했음

Database Migration

• Aurora PostgreSQL 을 쓰고 있었는데 Aurora PostgreSQL 은 Cross Region Replica 는 지원안해서 쓸 수가 없음
• DMS 는 Aurora PostgreSQL 10.x 부터 사용가능해서 사용 불가, 그러나 이걸 위해 DB 버전을 업그레이드 하고 싶지는 않았다. (안전성을 최우선시)
• 결국 할 수 있었던건 스냅샷 떠서 리젼 쉐어 및 리스토어 하는것 (오퍼레이션 포함 한시간 소요)

S3 마이그레이션

S3 replication

• replication 을 건 시점에 오브젝트부터 replication 시작함

S3 Batch

• 이전의 오브젝트는 S3 Batch 를 씀

S3 마이그레이션 후기

• 이렇게 많은 오브젝트는 62시간 정도. 3일이 채 안걸림 (굉장히 빠름)
• 6,625,278 Object 복사 수행 42개 에러 발생. 이거는 수동으로 대응

Elasticsearch Service

• 스냅샷 떠서 복구 - DB 랑 유사하게

DocumentDB - Mongodump / Mongorestore

• 팁은 스냅샷 뜨는 인스턴스 샤앙이 낮으면 시간이 오래 걸리므로 충분히 높은 사양의 인스턴스로 작업할 것

마이그레이션 수행 (p31)

테스트

• 데이터 마이그레이션 3회, 전체 5회 진행
• 20명 인원, 소요시간 1시간 30분

서비스 중단

• 월요일 새벽 5시부터 7시30분 (2시간 30분)

계획과 현실

• 일주일 전부터 고객 사전 공지했음에도 불가하고 활성화된 스트림이 있었음
• config 적인 이슈는 계속 발생을 해서
• 총 6회 정도의 테스트 진행

마이그레이션 이후

• 시스템 반응성 15% 향상되었으나 고객이 느끼기에 달라진 것은 없음
• 그러나 보안이 강화된 서비스 제공 기틀 마련
• postgreSQL 엔진 업그레이드 준비중
• 실수발생 환경 제거하고 견고한 IaC

뒤돌아보며

• 성공적인 마이그레이션 이면에는 사전에 7개월가량의 데브옵스 과정을 거쳤다.
• 이 과정이 없었다면 성공적인 마이그레이션은 불가능했을듯

정리

AWS Well-Architected Framework

• 가장 중요한 프레임웍이라고 생각.
• 아무리 AI/ML 서비스가 좋다고 해도 서비스의 안정성이 확보되어야 비즈니스의 성장을 이끌어 낼 수 있다

트렌드를 따라가는 게 중요

• postgresl 가 아닌 mysql 썼다면, documentDB 가 아닌 DynamoDB 를 썼다면 다른 방법으로 마이그레이션을 할 수 있었을 것

자동화

• 자동화를 통한 서비스 안정성 확보에 많은 준비를 해야한다고 생각.

결론

• 7개월간의 데브옵스 과정을 거쳐서 시간이 주는 복리효과를 충분히 누렸다고 생각한다.
• 한땀한땀 엔지니어링을 통해 목표된 2시간 남짓한 기간동안 마이그레이션을 성공적으로 수행할 수 있었다.

후기

대규모 서비스 마이그레이션 시에는 어떤 점을 특별히 고려해야할까, 노하우는 있는걸까, 혼자서 고민했던 적이 많았는데, 최상기님의 마이그레이션 후기 발표 덕분에 그냥 실수안할때까지 반복테스트하는 수 밖에 없고, 이 테스트를 잘 할 수 있는 환경을 만들기 위해 전체적인 아키텍쳐를 데브옵스 친화적인 아키텍쳐로 한땀한땀 바꿔가는 과정이 성공적인 마이그레이션의 핵심의 핵심이라는 것을 가슴속에 새길 수 있었습니다!

이런 멋진 마이그레이션 후기를 공유해주신 최상기님, 그리고 스푼라디오팀, 그리고 AWS Community Day 관계자 분들에게 너무너무 감사드립니다!!