변화와 혁신을 위한 클라우드 마이그레이션 – 김진우 AWS 어카운트 매니저, 이아영 네오위즈 가버너스팀 팀장, 박주희 우아한형제들 시스템신뢰성개발팀 매니저:: AWS Cloud Week - Industry Edition
10 de Nov de 2020•0 gostou
0 gostaram
Seja o primeiro a gostar disto
mostrar mais
•179 visualizações
visualizações
Vistos totais
0
No Slideshare
0
De incorporações
0
Número de incorporações
0
Baixar para ler offline
Denunciar
Tecnologia
비즈니스 환경은 빠르게 진화하며, 고객들에게 같은 속도의 혁신을 요구하고 있습니다. 고객들은 클라우드를 통해 빠른 속도의 환경변화, Compliance, Software life cycle에 빠르게 적응하고, 더 나아가 새로운 비즈니스를 창출하고 있습니다. AWS 마이그레이션 사례를 통해 카멜레온처럼 진화하고 생존하는 방법을 알아봅니다.
클라우드 마이그레이션 가치
비용절감 (TCO)
TCO 절감
인프라스트릭처 비용 절감/
클라우드 전환 비용 최소화
비용 관점
What is it?
Examples
비지니스 가치 (Value)
(1) https://pages.awscloud.com/Global_IDC_Enterprise_Whitepaper.html
클라우드 마이그레이션 가치
비용절감 (TCO) 직원 업무 생산성 비지니스 민첩성운영 탄력성
AWS 서비스를 활용하여
내부 개발 및 출시 속도 향상
갑작스러운 트래픽에 대한
증감/감소 대응 및 글로벌 확장
TCO 절감 각 팀별 서버를 구성하는데
사용되는 시간을 줄임
인프라스트릭처 비용 절감/
클라우드 전환 비용 최소화
개별 업무 단위로의
효율 개선
예상하지 못한 트래픽 대응 및
서비스 확장성
새로운 기능 및 서비스들을
빠르게 출시
비지니스 가치 관점비용 관점
What is it?
Examples
Digital Native 회사의 혁신은?
비즈니스
가치 Level 1 – FUN & EXPERIENCE
직감과
경험
모델 Level 2 – 다양한 서비스 제작,
새로운 아이디어, 실험, 새로운 장르
프로세스기술 모듈화
Level 3 –클라이언트 개발, 서버 개발,
디자인, 아트, 사운드, 운영, 배포 등
인프라스트럭쳐 [IT Fundamentals]
Digital Native 회사의 혁신은?
지속적으로 새로운 것을 시도하기
(실험, Fast try-Fast fail)
프로세스기술 모듈화
혁신은 끊임없이 새로운 실험과 실패를 거듭하는 문화와 환경구축에 있습니다.
혁신을 지원하는 Resilient Infrastructure
AWS는 하나의 서비스를 위한 인프라가 아니라,
회사의 전략과 경쟁력을 확보를 위한 전략적 플랫폼입니다.
AWS Migration Acceleration Program
성공적인 Cloud Migration 여정을 지원하기 위해서 AWS는 Comprehensive Framework를 제공
Assess Mobilize Migrate & modernize
Mobilize through experiences Accelerate migration at scale
CART/Migration readiness
assessment (MRA)/TSO Logic
Rapid migration business case
(RMBC)
Rapid discovery TCO report
Pre-MRP accelerators
Briefings &
workshops
Immersion day
Create a case for change
Operate
Migrate
Modernize
Discovery and
planning
Landing
zone
Skills / center
of excellence
Migration
experience
Business case /
TSO Logic
Migration
plan
Operating
model
Security and
compliance
Migration Readiness Planning (MRP)
Fact 기반의 결정이 필수입니다.
IDC: Quantifying Datacenter Inefficiency
http://www.integra1.net/uploads/files/IDC%20Making%20the%20Case%20for%20Composable%20Infrastructure.pdf
• 우리 IDC의 실제 AVG/MIN/MAX 리소스 사용율과
미사용되는 스토리지 용량은?
• 해당 데이터 기반으로 AWS 로 이동했을 때
사이즈와 비용은?
• 실제 절감되는 상면, 전기, 쿨링 비용은?
Directional Business Case: TCO 분석
Infrastructure Discovery 및 AWS 경험 기반, 상세 Cost Saving 기회를 발굴하여 전달
• 비즈니스 목표에 맞춘
마이그레이션 방안 검토
• Discovery Tool (TSO Logic)을
기반으로 정확한 분석
• TCO report를 통한 구체적인
비용절감 방안 분석
• C-level 보고를 위한 Executive
level presentation 작성하여 제공
고객의 실제 Data를 기반으로 TCO 및
ROI 분석을 무상으로 제공
TSO Logic
On-premise 환경 내 Serve instance, 라이센스 옵션 등을 Discovery 하는 자동화 Tool
단순화된
Discovery
On-premises 컴퓨팅,
로컬 스토리지, 메모리
및 윈도우 라이센스
리소스 및 사용량 확인
최적화된
Cloud Planning
최적의 인스턴스
사이즈, 라이센스 옵션
및 스토리지 타입
모든 리전 및 비용
지불 모델
Business Case
개발
Directional 혹은
Detailed 리포트
(Windows OLA 포함)
AWS 혹은 APN
파트너를 통해서
Delivery
✓ Fast
✓ Agentless
✓ 실제 데이터 사용
✓ 분석 시간 단축
✓ 추가 비용 없음
✓ AWS 서비스와 통합
클라우드 Business Value Workshop
고객 워크숍
킥오프 워크숍 : 0.5일
환경 서베이 : 0.5일
에이전트를 통한 데이터 수집 : 약 2-4주
• 실제 고객 데이터 사용
• Deep dive 프레젠테이션
• 다양한 AWS 분석/수집 툴 사용
• 온프라미스 환경 상세 분석 대시보드 제공
• 일반적인 TCO 절감 +-30-40%
• 일반적인 전체 클라우드 비즈니스 가치 비용 절감+- 50-70%
도입배경
2019년에 맞닥뜨린 과제 _ System 노후화
System 노후화
2010년 Data Center 이전 때 구축한 Infra
H/W 노후화
S/W Version, License 비용
비싼 유지보수 비용
➔ Infra 전략에 변화 필요
➔ Data Center에 대규모 투자를 할 것인가?
➔ 방향을 틀어 Cloud로 이전할 것인가?
마이그레이션 진행
Wave 단위 Migration
Jan Feb Mar Apr May Jun Jul Aug Sep Oct
2020
Wave 1 (2월 ~ 4월)
Landing Zone 구축/ Direct Connect 구성
PoC (DB, 정보분석)
Light한 Service Migration (8개)
Wave 2 (5월 ~ 7월)
Service Migration
- PC Pmang Home, 각종 Admin Tool 등
Wave 3 (8월 ~ 10월)
Service Migration
- Mobile Pmang, PC방, Billing 등
마이그레이션 진행
서비스 마이그레이션 과정
1 2 3 4 5 6
대상선정
- Year Plan
- Wave Plan
Infra 구축/ 개발
Open 준비
- 시나리오 검토
- Open Check List 검토
- 공지
서비스 전환
- 마이그레이션 진행
회고
System 최적화
- Open 2주 ~ 4추 후)
마무리
✓ 오랜 기간 동안 클라우드를 경험하고 고민한 후 올인을 선언하였다.
✓ 검토와 의사결정 과정에서 구성원들의 의견을 적극 수렴하였다.
✓ AWS가 권장한 모든 영역이 아닌 네오위즈의 상황에 맞는 필수 영역만 컨설팅을 받고
약간 독립적이고 내부전용 서비스를 시작으로 마이그레이션을 진행하였다.
✓ Wave 단위로 경험과 자신감이 쌓여 이제는 좀더 공격적으로 마이그레이션을 하고
있으며 클라우드로의 전환에 따라 조직과 문화에 많은 긍정적인 변화가 생기고 있다.
Monolithic database for multiple services
• 장애 확산
▪ 부분적인 이슈가 전체 장애로 확산
• 트래픽에 따른 Scale 정책 적용 불가
▪ 이벤트성 대규모 트래픽 대응 이슈
• 신규 서비스 및 기능 추가 속도 저하
▪ 분석 및 수정 범위 증가
▪ 기능 테스트 복잡도 상승
Limits on Monolithic Database Architecture
Failure Experience
• Monolithic Database Cloud Migration
▪ 클라우드 환경에서 수용 가능 스펙 초과
– Dedicated 장비 사용 필수
– RDS SQL Server: 일부 Admin 권한 제약
– SQL Server on EC2: License 문제로 인한 비용증가 및 HA 구성 추가로 인한 복잡도 증가
– 데이터마이그레이션 과정에서 On-premise-AWS 클러스터 구성의 불안정성
▪ Migration 이후 운영 이슈
– 메인 DB 구조상 스케일아웃이 어려움
– 최고 스펙 장비 사용으로 스케일업 불가능
▪ 서비스 안정성을 보장할 수 없고, 비용 절감 효과가 미비하여 이관 중단 결정
Monolithic Database Cloud Migration
Database Migration Steps
• 마이크로 서비스 단위의 완전한 분리 및 클라우드 마이그레이션
▪ 1. 마이크로 서비스 단위 정의
– 회원 서비스, 주문 서비스 등
▪ 2. 핵심 데이터 (테이블 or 데이터 단위) 리스팅
– 회원: 회원 정보 테이블, 회원 등급 테이블, 공통 코드 중 일부 코드 값 데이터 등
▪ 3. 마이크로 서비스 단위 마이그레이션
– 개별 서비스 맞춤 마이그레이션 전략 사용
▪ 4. 레거시 코드 및 가비지 데이터 정리 후 백업
How to change entire architecture?
Database Migration Strategy
• 사용 예시
▪ 마이그레이션 범위가 넓은 경우
▪ 서비스 중단이 불가능한 경우
• 특징
▪ 마이그레이션 중 지속적인 데이터 변경 발생
▪ Validation을 위한 충분한 시간 필요
▪ Master-Standby 구조로 마이그레이션 이후 이슈 발생 시 빠른 롤백 가능
무중단 마이그레이션
Database Migration Strategy
• 사용 예시
▪ 서비스 운영 시간이 제한되어 있는 경우
▪ 내부 운영을 위해 사용되는 경우
• 특징
▪ 서비스 중단으로 데이터 변경 최소화
▪ AWS Schema Conversion Tool & AWS Database Migration Service 활용
– 테이블 단위 이관 용이
– Backup file or dump file 이동 과정 생략 가능
– 별도의 마이그레이션 로직 개발 불필요
빠른 마이그레이션
After the migration
• 서비스 최적화 아키텍쳐
▪ 서비스 특성에 맞는 데이터 저장소(Aurora(MySQL), SQL Server, MariaDB, MongoDB,
DynamoDB, 등) 선택
▪ 서비스 특성에 맞는 스케일 전략 사용
• 신규 서비스 및 기능 론칭 시간 단축
▪ 작은 범위의 분리된 데이터베이스 설계
– 마이크로 서비스 단위 변경 시 타 시스템 영향도 최소화
• 장애 확산 방지
▪ 상호 의존성 최소화
– Circuit breaker 적극 활용
서비스 개선
After the migration
• Performance Improvement
▪ Parameter group 튜닝을 통한 성능 개선
▪ 스케일업 + 스케일아웃을 적절히 활용한 트래픽 대응
▪ 손쉬운 업그레이드 및 장비 관리로 서비스 다운타임 최소화
• Monitoring
▪ AWS Cloudwatch + Lambda 연계를 통한 손쉬운 모니터링 환경 구축
• AWS Support
▪ 하드웨어 이슈 및 비정상 동작에 대한 AWS support 요청
Database 운영 개선