서비스 무중단 마이그레이션 : KT에서 Amazon으로

서비스 무중단 마이그레이션
KT에서 Amazon으로
애드투페이퍼 방신우

작성자 소개
방신우 Sin-Woo Bang
이메일 : sinwoobang@add2paper.com
Github : https://github.com/sinwoobang/
사이트 : http://sinwoobang.me/

내용 소개
- 중규모 아키텍처(1)
이전 경험을 공유합니다.
- 서비스 무중단 이전 경험을 공유합니다.
- 백엔드 어플리케이션, DB, 캐시, DNS 작업 등이 있습니다.
- 인력 한계로 AWS SaaS(ex. RDS, ElastiCache)를 일부 사용하지 않았습니다.
(1) 대규모까진 아니라 편의로 붙인 이름입니다. 동시 접속자 4,000명 미만을 기준 잡았습니다.

애드투페이퍼
- 대학생 대상 무료 출력 제공
- 누적 회원 70만명
- 전국 132개 대학교 사용
- 약 5,000곳 PC 클라이언트 설치

- 학생 : 모바일 앱 / 모바일 웹 / PC 웹 / PC
클라이언트
- 광고주 : PC 웹
- 현장 관리자 : PC 웹
- 사내 관리자 : PC 웹
플랫폼

기존 서버 스택(~2017.8)
- 2013년 글에서 큰 틀에서 동일
- KT 유클라우드 약 5년 이용
- 핵심
- AP 서버(Python/Django)
- 캐시 서버(Memcached)
- 비동기 워커 서버(Redis)
- 크론 서버(Crontab, Python/Django)
- DB 서버(MySQL 5.5, Master-Slave)

- Amazon Web Services(AWS)
- AP 서버(EC2)
- 캐시 서버(EC2)
- 비동기 워커 서버(EC2)
- 크론 서버(EC2)
- DB 서버(EC2, Master-Slave)
이외에도 DB 프록시 서버 등이 있지만 주제에 집중하기 위해 적지 않았습니다.
현재 스택

1. AWS에 서비스를 띄운다.
2. 유클라우드에 연결된 도메인을 AWS로 연결한다.
검토 : 무엇을 해야하는가

a. 무중단으로 이전하려면
b. 유클라우드와 동일하게 서비스를 띄워야한다.

c. 동일하게 띄우려면
i. AP를 띄워야한다.

c. 동일하게 띄우려면
i. AP를 띄워야한다.
ii. AP를 띄우려면
1. DB
2. 캐시
3. 비동기 워커
4. 크론

AWS에 서비스를 띄운다 : 1차 전략
유클라우드 AWS
AP
DB
비동기 워커
AP
캐시
크론
비동기 워커
크론

1. DB : 유클라우드 연결
2. 캐시 : 이전 완료까지 제거
a. 고려했던 것들
i. AWS에 새로운 캐시 서버 생성
1. 새로운 값은 새로운 캐시 서버에 SET
2. 한계 : 완벽 이전까지 며칠을 기다려야 하는 문제
3. 서비스가 캐시 의존적이지도 않았다.
ii. repcached : 공식 홈페이지 다수 링크가 404. 신뢰 불가.
b. 캐시 제외했을때 100ms 지연 발생. 잠깐이면 감당할만하다고 판단.
c. 캐시값이 없으면 DB를 바라보도록 의존성 제거.
3. 비동기 워커는 유클라우드, AWS 동시 운영해도 무관
4. 크론도 스케쥴 분리하여 유클라우드, AWS 동시 운영

1. DB : 유클라우드 연결
a. 기존에 내부 IP로 통신
b. AWS와 유클라우드 간 외부 통신 필요
c. 유클라우드 MySQL Master 방화벽 설정 변경
i. 기존 : 외부 IP 통신 불허
ii. 변경 : AWS AP IP만 통신 허용
d. 유클라우드 MySQL Master - AWS AP 통신 : SSH 터널링 구성
i. 고려했던 것들
1. 도메인 기반 SSL 사용
a. 편리
b. 한계 : 인증서가 서비스 단일 도메인만 존재

AWS에 서비스를 띄운다 : 1차 전략 완료
1. 1차 전략 완료
2. ELB IP로 직접 연결하여 테스트
3. AWS에서도 서비스 정상 작동(환호)

유클라우드 AWS
AP
DB
비동기 워커
AP
캐시
크론
비동기 워커
크론
DB

1. DB 이전 큰 그림
a. 유클라우드 MySQL Master - AWS MySQL Slave 구성
b. AWS MySQL Slave를 Master로 승격
2. 큰 그림만 마치면 이전 95% 완료

최초 검토사항 수정 필요

1. AWS에 유클라우드 의존적인(ex. DB) 서비스를 띄운다.
3. AWS에서 유클라우드 의존성을 걷어낸다.

1. (1차 전략) AWS에 유클라우드 의존적인(ex. DB) 서비스를 띄운다.
3. (2차 전략) AWS에서 유클라우드 의존성을 걷어낸다.

1. (1차 전략) AWS에 유클라우드 의존적인(ex. DB) 서비스를 띄운다.
a. 2차 전략을 위해서 선행 필요
3. (2차 전략) AWS에서 유클라우드 의존성을 걷어낸다.

1. DNS TTL : 0으로 설정
2. 유클라우드 LB IP에서 AWS ELB로 설정
3. AWS CloudWatch : 유저 유입 확인
도메인 연결 : Route 53

2차 전략으로 돌아가서

i. SSH 터널링 구성
ii. Slave 무중단 생성 : Percona XtraBackup https://goo.gl/6hB1mn
b. 유클라우드 AP - AWS MySQL Slave간 SSH 터널링 구성
c. AWS MySQL Slave를 Master로 승격
i. Slave) STOP SLAVE
d. AP DB IP를 Slave IP로 변경 후 배포

i. SSH 터널링 구성
ii. Slave 무중단 생성 : Percona XtraBackup https://goo.gl/6hB1mn
b. 유클라우드 AP - AWS MySQL Slave간 SSH 터널링 구성
c. AWS MySQL Slave를 Master로 승격
i. Slave) STOP SLAVE
d. AP DB IP를 Slave IP로 변경 후 배포
2. 서비스 정상 작동 확인

1. 비동기 워커
a. KT, AWS 동시 운영 후 KT AP 트래픽이 사라지자 비동기 워커도 자동 소멸
2. 크론
a. KT, AWS 동시 운영 후 스케쥴별로 점진 이전
3. HTTPS 트래픽
a. 유클라우드 사용 시절 HTTP, HTTPS 로드밸런서를 따로 운영
i. 유클라우드 서비스 초기 HTTPS 로드밸런서 미지원
ii. HTTP 트래픽을 먼저 옮기고 HTTPS는 차후 이전하였음.
4. 고정 IP 대응
a. 일부 클라이언트(학교) 방화벽 정책 : IP 화이트리스트
b. 고정 IP는 구입 불가
c. 해당 IP에서 운영중인 서버를 프록시 서버로 전환
d. 프록시 서버는 AWS 서버 HTTP 호출
ETC

Q&A
1. 왜 AWS RDS, DMS를 사용하지 않았나요?
a. MySQL 5.5 GTID 미지원
b. MySQL 5.5 binlog_format=STATEMENT 상태
c. Percona XtraBackup은 디렉토리 직접 접근 필요하나 RDS는 SSH 접속 미지원

감사합니다
내용이 많아 PPT에 못 담은 내용이 많습니다.
문의 : sinwoobang@add2paper.com

서비스 무중단 마이그레이션 : KT에서 Amazon으로

More Related Content

What's hot (20)

Similar to 서비스 무중단 마이그레이션 : KT에서 Amazon으로 (20)

서비스 무중단 마이그레이션 : KT에서 Amazon으로