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

안녕하세요! 클래스메소드 주식회사의 김태우입니다. 작년에는 한국에서 AWS 소모임이나 각종 행사들이 열릴때마다 항상 가고싶어서 부러워하곤 했는데요..ㅋㅋ 올해부터는 적극적으로 한국의 AWS 행사에도 참여하고자 합니다! 그런 의미에서 저도 지난 1/21(화) 에 열린 AWS Community Day 2020 에 다녀왔습니다. 본 블로그는 마이쿤의 최상기님께서 발표하신 세션을 참가하면서 개인적으로 노트했던 내용을 정리한 글입니다.
2020.01.23

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

작년에는 한국에서 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 관계자 분들에게 너무너무 감사드립니다!!