Cloud Migration 과 Modernization 을 위한 30가지 아이디어-박기흥, AWS Migrations Specialist SA::AWS 마이그레이션 A to Z 웨비나

CLOUD MIGRATION 과 MODERNIZATION을 위한 30가지 아이디어
© 2022, Amazon Web Services, Inc. or its affiliates.
Cloud Migration 과
Modernization을 위한
30가지 아이디어
박기흥
Migration Solutions Architect
AWS Korea

Agenda
Toyota Production System, 제약이론
Software Delivery 흐름 최적화와 함께 Migration &
Modernization Ideas 확인

Application Modernization
People, Process, & Culture
Technology & Architecture
Modernization is the refactoring of legacy technology by combining modern
infrastructure, architecture, organization patterns together to maximize resiliency,
engineering efficiency, and business agility.
1 2

Technology Adoption Lifecyle
출처: https://setandbma.wordpress.com/2012/05/28/technology-adoption-shift/
최신 기술 트렌드
• InfoQ Trends Report
• https://www.infoq.com/infoq-trends-
report/
• Thoughtworks Technology Radar
• https://www.thoughtworks.com/radar
• Hacker News
• https://news.ycombinator.com/
• Gartner Hype Cycle Reports
• State of DevOps Reports
• https://www.devops-
research.com/research.html

혁신은 거인의 어깨위에서
이루어진다
이정동
서울대 공대 교수 (축적의 시간)

Modern Software Delivery Practice 의 계보
2016
2010
2018
2015
2018
2019
1999
1984
Agile Manifesto
도구
→ 사람
문서
→ 작동하는 SW
계약
→ 고객과 협력
계획
→ 변화에 대응
2001
W. Edward Deming
Fred W. Taylor
1978
2011
1996
2015
2003
2010
Triumph of
the Lean
Production
System
1988

도요타 자동차
미국 시장에서 1980~2010 도요타의 성장 추이
출처: (좌) https://public.knoema.com/vrpklhg/u-s-vehicle-sales-market-share-by-company-1961-2016-discontinued
(우) : https://en.wikipedia.org/wiki/NUMMI
도요타-GM 합작법인 NUMMI
(New United Motor Manufacturing, Inc)
GM
Ford
Chrysler
Toyota

Toyota Production System
오노 다이이치 (1912~1990)
낭비의 최소화
Just In Time 자동화(自働化)
출처: https://global.toyota/jp/company/vision-and-philosophy/production-system/ , papago로 변역

Toyota Production System – 낭비의 최소화 (1/3)
도요타 생산 방식의 기본 원칙.
1. 왜 기계가 멈춰 섰지?
- 과중 부하가 걸려 퓨즈가 끊어졌기 때문이야
2. 왜 과중 부하가 발생했지?
– 베어링 부분이 너무 빡빡했기 때문이야
3. 왜 뻑뻑해졌지?
– 윤활펌프가 제대로 작동하지 못했기 때문이야
4. 왜 충분히 작동하지 못했지?
– 펌프의 축이 닳아서 덜컹거리기 때문이야
5. 왜 닳았지?
– 여과기가 달려있지 않아 가루가 들어갔기 때문이야
낭비 분석 방법 1 : Five Whys 낭비 분석 방법 2 : 표준 작업표 ,Value Stream Mapping
공정을 작업 순서와 Cycle Time(대기+작업시간) 으로 정리
출처: 5 whys – 도요타 생산방식 / 오노 다이이치 지음/ 미래사, Value Stream Mapping: Wkipedia (https://en.wikipedia.org/wiki/Value-stream_mapping)

낭비 최소화 운동의 특징
• Top Down 보다는 Bottom Up :
• 개선 아이디어 제안시 상금
• 지속적인 개선 활동 → 改善 / Kaizen
출처: https://slidesplayer.org/slide/11158983

오노씨가 어떤 선배한테
'저기 라인에 있는 작업원을 잘 살펴보고 동작에서 비효율적인 부분을 찾아보도록 해'
라고 지시했습니다. 그런 다음 분필로 반지름 1미터 되는 원을 그리더군요. 선배에게
'자, 이 원 안에 계속 서 있도록 해. 급하면 화장실은 갔다 와도 돼'
라고 말했습니다.
….
" 저 친구 말입니다. 범퍼를 달기 전에 셀로판 포장을 벗기고 있죠?
착 달라붙어 있는 셀로판을 벗겨내는 건 정말 귀찮은 작업입니다.
하루에 몇 번씩 셀로판을 벗겨내다 보면 짜증이 날 수 밖에 없죠.
그러니 어딘가에 셀로판을 벗겨내는 공정을 만들어야 합니다.
아니면 셀로판이 아닌 다른 포장재로 바꾸는 방법을 생각하든지요"
일화:
출처:

제약이론 (Theory of Constraints)
제약이론:
• 이스라엘 물리학자에서 기업 컨설턴트로 변신한 앨리 골드렛(1948~2011) 이 창시.
• The Goal 책에서 제약이론을 소설 형태로 소개
• 앨리 골드렛은 오노 다이이치를 "My Hero" 로 부름
"오노가 만든 도요타 생산방식은 20세기 일대의 발명이다" (도요타 이야기 中)
• 정의: 최적 생산 기술에서 출발한, 경영 과학의 체계적 이론. 생산 일정의 계획뿐만
아니라 성과 측정을 위한 회계 이론과 정책의 분석ㆍ수립을 위한 사고 과정이
포함되는 것으로 모든 기업은 더 높은 수준의 성과를 제약하는 자원이 반드시 하나
이상은 존재한다는 이론이다. 이 이론에 따르면 기업은 이러한 제약 자원들을
파악하고 개선해야만 기업의 성과를 높일 수 있다. (출처: 네이버 국어사전)

제약 이론 – 예(1/2)
얼마 후..
문제 발생!
대열이 나눠져
위험에 노출
The Goal 책에 나온 예: 학생들과 1박2일 하이킹
제약 조건 (Bottleneck 공정, Neck공정)
Image: Flaticon.com

제약 이론 – 예(2/2)
Image: Flaticon.com
The Goal 책에 나온 예: 학생들과 1박2일 하이킹
해결 방안 1
• 가장 느린 친구를
대열 앞에 위치
해결 방안 2
• 느린 친구의 짐을
나눠 속도를 높임

Toyota Production System – Just In Time
공정이 필요한 것 만을 물 흐르듯이 정체 없게 생산하는 생각
• 자동차를 흐름 작업으로 만들 때 필요한 부품이, 필요한 때, 필요한 양만큼 생산 라인에 도착
• 그렇지 않으면 재고가 낭비됨 (창고를 만들어야 하고, 찾으러 사람이 다녀야 함)
• 간판(乾板, Kanban) 운영
• 오노 다이이치가 미국의 슈퍼마켓 시스템을 듣고 구상
• 공정별 재고 상태를 정확히 시각화 하는 효과
• JIT는 시류에 맞게 운영. 2011 동일본 대지진 이후 JIT완화(재고 많이 보유) → 반도체 공급 부족 사태
때 비교적 문제를 덜 격음

간판(乾板, Kanban) 시스템
1
2
KANBAN Card:
Part no, 수령, 작업 공정
위치 등이 적힌 카드
오노 다이이치가 미국의 슈퍼마켓 진열 시스템, 즉 고객이 진열대의 상품을 가져가면 그 때 그때 채워 넣는 시스템을
듣고 구상. 처음 슈퍼마켓 시스템으로 이름 지었다 후에 간판 시스템으로 이름 변경.
1. 조립공정에서 부품을 가져다 조립에 사용하면 부품에 붙여진 간판(Kanban) 카드를 간판포스트로 이동하고
2. 간판포스트에 간판 카드가 놓이면 부품 가공공정에서 간판 가져가 부품을 가공해서 조립공정으로 전달
→ 재고 최소화, 재고 상태 가시화 효과
조립공정 부품 가공 공정
간판 포스트
슈퍼마켓 진열대

Kanban in Software Development
대기 진행 중 검증 완료
프로젝트 업무
일상 업무
Image: Flaticon.com
철수 영희 민철
기능 버그 기타
예: DevOps 3팀의 2022 Sprint 13 Kanban 보드
더 많은 예제
도요타의 Kanban 시스템의 아이디어를 차용해 Agile 과제의 업무를 시각화 하는데 사용

Toyota Production System – 자동화
이상이 발생하면 기계가 즉시 정지하고, 불량품을 만들지 않는다는 원칙
움직일 동(動)에 사람 인 을 붙인 동(働)자를 사용.
• 도요타 전신인 도요타 방직의 자동화 기기에서 유래. 자동 직기는 날실이 한 가닥 끊어지면 곧바로
자동으로 멈추도록 설계하여 불량이 다음 공정으로 넘어가지 않도록 함.
• 다능공화(多能工化)
• 한사람이 한 공정을 담당하는 것을 자동화와 함께 여러 공정을 담당하도록 변경 → 다품종 소량생산
• 한반도의 38선을 보고, 서로 간의 업무에 38선을 그으면 안된다고 생각 (오노 다이이치)
Image: Flaticon.com

SW Delivery Process
요구사항 작성
(프로젝트 매니저)
설계
(개발)
구현
(개발)
검증
(QA)
배포 승인
(개발, 운영)
신규서버 발주
(개발)
구매
(구매)
설치
(운영)
WAR 파일 복사
(운영)
배포
(개발, 운영)
WAS Restart
(운영)
시험, 로그 확인
(운영)
인프라 수정SR
(운영)
방화벽 수정
(운영/네트웍)
Monolith App
개발 (개발)
기능별 Branch
작성 (개발)
Dev 환경서 검증
(개발)
TPS 의 사상을 바탕으로 SW Delivery Process 의 개선을 진행해 보면..
Product
Requirement
Document 작성
Software
Requirement
Specification 작성
검증 요청
(개발)
Test Suite 추가
/Regression Test
(QA)
비기능 테스트
(QA)
Resource 생성
(운영/Cloud)
정기 승인 회의 운영
(월 2회)
정기 배포 운영
(월 2회)
SW 개발 프로세스의 Value Streaming Map (예)
Work: 14d
Wait: 1d
Work: 14d
Wait: 5d
Work: 7d
Wait: 3mo
Work: 2d
Wait: 3d
Work: 2h
Wait: 7d

Neck 공정 : 요구사항 작성
요구사항 작성
설계
(개발)
구현
(개발)
검증
(QA)
배포 승인
(개발, 운영)
배포
(개발, 운영)
잘못된 통념: 스펙을 조기에 확정한다
"존경하는 고객님, 소프트웨어 원하는 기능을 빠트리지 않고 목록으로 만들어 주십시오.. "
개선 안:
• MVP(Minimum Viable Product) 을 만들어 빠르게 아이디어를 검증.
• 고객의 피드백을 바탕으로 개선된 제품을 출시한다.

Project to Product
Project Product
시간 시간
변화 변화
출처: 속도의 경제를 위한 클라우드 전략 – 2장. 클라우드는 1차 결과물을 생각한다

Project to Product : 팀 구조
Project Product
PMO
OOO계
OO계
• AA O명
• DA O명
• 개발 OO명
• 웹 OO 명
• AA O명
• DA O명
• 개발 OO명
• 앱 OO 명
Project Leader
Project Manager
Product Owner
Product Manager
Product-Based Team
- User Microservice
- Auth Microservice
Full Stack. Two Pizzas. Full Stack. Two Pizzas.
Product-Based Team
- Mall Frontend
- BFF Service
"Bring team to the work" "Bring work to the team"

Team Topology
Conway's law를 인정하고 SW Architecture에 따라 팀을 구성한다는 아이디어.
4가지 종류의 팀으로 구성 (각 팀은 6~20 Two-Pizza Team 을 권장)
• Stream-Aligned Team: 단일 업무 흐름에 정렬된 팀. 수개의
Microservice를 담당. 개발 부터 운영까지 책임. Werner Vogels의 'You
build it, you run it 에 부합하는 팀
• Platform Team: 여러 스트림 정렬 팀이 공통적으로 사용하는 Tool을
담당하는 팀
• Enabling Team: 신기술, 신제품을 미리 익히고, 각 팀 간의 역량 차이를
메우는 가교 역할 수행. 테크니컬 컨설팅 팀.
• Complicated Subsystem Team: 비디오 코덱, 수학 계산 모델 등
습득하기 어려운 전문 기술을 가지고 있는 팀.

Team Topology
Application Development
Infrastructure Management
Application Configuration
Alarms
Runbooks
Testing
Compliance
Roadmap Tracking
Goals Tracking
On-Call
Support Escalation
…
Deployment Tools
CI/CD Tools
Monitoring Tools
Metrics Tools
Logging Tools
APM Tools
Infrastructure Provisioning Tools
Security Tools
Database Management Tools
Test Tools
….
Stream Aligned Team
Responsible For
Platform Team
Responsible For

Neck 공정 : 하드웨어 발주, 인프라 변경
요구사항 작성
설계
(개발)
구현
(개발)
검증
(QA)
배포 승인
(개발, 운영)
배포
(개발, 운영)
신규 서비스를 위한 장비 구입에 상당 시간 소요.
장비 발주가 아니더라도 인프라 변경(Routing, Reverse Proxy, Firewall) 변경에 상당 시간 소요.
개선 안:
• Cloud 사용 (NIST Cloud 정의)
• On-demand Self-Service: 사람의 개입을 필요로 하지 않고, 필요에 따라 서버, 스토리지 등
컴퓨팅 기능을 OnDemand로 사용할 수 있다.
• Rapid Elasticity: 자원이 필요할 때 빠르게 확장할 수 있다.
신규서버 발주
(개발)
인프라 수정SR
(운영)

Cloud 전환에 관한 Tips
클라우드는 비용 모델이 다릅니다.
개발과 함께 진행하세요. 운영이 주도하면 제2의 IDC Migration이 됩니다.
Cloud vendor lock in 이 걱정된다면 Portable 한 구조로 만드세요
Lock in 에 너무 몰입하면 Cloud 의 장점을 활용할 수 없습니다.

Neck 공정: Monolithic Application
developers
delivery pipelines
Monolithic
Application
monitor
release
test
build
Monolithic Application을 여러 팀이 같이 개발 → 다른 팀 완성까지 대기, Branch Merge 대기, QA 대기 발생

해결안: Microservice
developers Microservices
monitor
release
test
build
delivery pipelines
monitor
release
test
build
monitor
release
test
build
monitor
release
test
build
monitor
release
test
build
Microservice : 다른 팀에 의존 않고 독립적으로 배포 → 대기 시간 감소

Monolith to Microservice
Event decoupling Strangler pattern
Domain-driven design
도메인 기반 디자인
이벤트 기반 분리 스트랭귤러 패턴
Legacy Monolith 어플리케이션이 있다면
2 Pizza Team 이 처리할 수 있는 규모로
Monolith 을 Microservice 로 분리시켜냅니다

Neck 공정 : 검증
요구사항 작성
설계
(개발)
구현
(개발)
검증
(QA)
배포 승인
(개발, 운영)
배포
(개발, 운영)
검증을 사람이 진행함으로써 대기가 발생.
개선안:
• Shift Left Testing
• 검증/운영에 가서 문제가 발생하기 전에 사전에 발견토록 함
• 자동화 → Unit test, Code quality, Static Code Analysis, Dependency scan
• 실패하면 다음공정 X
• 검증 단계 자동화
• Regression Test의 경우 자동 테스트 인정

Neck공정: 한달에 두 번 있는 배포, 운영팀이 배포
출처: https://twitter.com/bibryam/status/884815033741570049
정상 동작 시험
(Integration Test, Monitoring)
실패 시 롤백
정상 동작 시험
(Integration Test, Monitoring)
실패 시 롤백
3가지 배포 방법

Neck공정: 한달에 두 번 있는 배포, 운영팀이 배포
Speed Repeatability Confidence Transparency
DEPLOY
TEST
BUILD
SOURCE/
ARTIFACT
AUTHOR
AWS Cloud9
AWS IDE Toolkits
AWS
CodeBuild
AWS
CodeCommit
AWS
CodeDeploy
AWS CodeBuild
+ Third Party
AWS CodePipeline
AWS
CodeArtifact
개선 안: CI/CD의 자동화를 통해 배포의 두려움을 없애고, 필요할 때 언제나 배포하고, 개발이 직접 배포 토록 함

DevSecOps pipeline 출처: https://aws.amazon.com/blogs/devops/building-end-to-end-aws-devsecops-ci-cd-pipeline-with-open-source-sca-sast-and-dast-tools/
CI/CD pipeline에 보안 체크
과정을 추가하여 배포
자동화와 더불어 보안도
함께 가는 솔루션

Neck 공정: Infrastructure 를 수동으로 관리
개선 안: Infrastructure as Code(IaC) 도입
• Hashicorp Terraform, AWS Cloudformation, AWS CDK, Plumi 등의 IaC 도구를 이용하여
Infrastructure 형상도 코드로 관리
• 인프라 형상의 변경을 Dev 환경에서 먼저 확인하고 실수 없이, 빠른 속도로 Stage 및 Prod
환경으로 전파 가능
• 인프라 형상변경시 코드 리뷰 과정을 통해 휴먼 에러가 인프라에 반영될 확률을 낮춤

고객 중심의 성장 플라이휠
Growth
Feedback
Customer
experience
Improvements
Usage
고객 중심의 성장 플라이휠

고객으로부터 시작해서 고객으로 끝나는 VSM 예
Agile / Scrum
그림 출처: wikimedia

DORA DevOps 평가 지표
우리가 잘하고 있는지 어떻게 정량적으로 측정할 수 있을까?
→ DORA(DevOps Research & Assessment) 에서 4가지 측정 지표를 제안
지표명 측정 내용
Deployment Frequency 배포 빈도
Lead Time for Change 소스를 수정 한 후 변경이 운영 환경에 반영될 때 까지의 시간
Change Failure Rate 배포 후 장애가 발생한 비율
Time to Restore Service 운영 환경에서 장애가 발생했을 때 복구까지 걸린 시간

SRE (Site Reliability Engineering)
출처: https://sre.google/resources/practices-and-processes/enterprise-roadmap-to-sre/?
구글의 서버 운영 방식의 집약
• 구글 운영 초기부터 Scale Up 대신 Scale Out 을 선택
• 선형적으로 증가하는 서버에 비례해 운영인력이 증가하지 않도록 자동화 진행
SRE Principles (일부)
• Service Level Objective : 서비스의 가용성 목표를 세우고 목표를 충족하는 범위에서
혁신 활동을 허용
• 예: SLA(Service Level Agreement) 가 99.9 이면 연간 8시간 45분을 Error
Budget을 활용 가능
• Eliminating Toil : 낭비/의 제거 → 자동화

Cloud Billing
Tagging
Tag 불가
리소스 구별
공유비용 할당
(ES, Network, ..)
upfront RI
상각비 계산
지출 데이터를
비즈니스에
매핑
Biz Data
(매출, MAU, ..)
쇼백과 차지백
FinOps 성적표
작성 (BU 별)
예산 수립
추세, 편차
분석
목표 설정
Paying Less
Using Less
클라우드 사용에 대한
거버넌스 구축
자동화, 지속적인
개선
Biz Unit에 비용 할당
Inform
Visibility & Allocation
Optimize
Utilization
Operate
Continuous Improvement & Operations
비용최적화 - FinOps
→ 내부/외부 벤치마킹
→ 멀티 아카운트
→ Right Sizing, Removing,
Re-architecting
→ Spot, RI, Private Offer,
Savings Plan, Proper
Storage, CSP 비교
프로세스 수립 및
이행
→ 이해관계자에 지출 데이터 제공
→ 정책 기반 태깅 (tag-or-terminate, tag-on-deploy)
→ 정책 기반 스토리지 수명주기 관리
→ 비용 효율화 추천을 JIRA 에 통합
→ 중앙 FinOps 조직
구축
→ 목표에 맞추어 조직
문화 구축

FinOps : Inform 단계
가시성 확보
• 비용을 분석하고, 부서별로 할당
• Tagging, Multi Account, ..
• 예산 수립에 활용
비즈니스 데이터와 비교하여 클라우드 비용 증가의 성격을 파악
Value based KPIs
$ AWS cost per search
$ AWS cost per listing
$ AWS cost per guest
$ AWS cost per host
$ AWS cost per mobile user
$ AWS cost per microservice
$ AWS cost per backend job
…
Cost based KPIs
($) Daily AWS run rate
(#) Total EC2 Hours
(%) RI Coverage
(%) RI Utilization
($) Underutilized/idle resources
(%) Resources untagged
(%) Variance (budget to actual)
…

FinOps Optimize 단계: Using Less
• Removing
• 안 쓰는 자원 찾아서 제거
• EBS 고아 볼륨, IOPS 2 볼륨, ‘아 아직도 있나요, 까먹었어요’ 등
• Moving
• 저렴한 storage 로 이동(Glacier), Snapshot 을 S3 로 이동
• Right Sizing
• Utilization 확인하여 size 조정, Auto Scaling
• 저렴한 Storage, CPU 로 이동 gp2 → gp3, x86 → arm, r3 → r5, s3 → glacier
• Re-Architecting
• Serverless, Container 등 cloud native architecture 로 전환하여 효율↑
• 노력 대비 이익을 고려하여 진행
• 안 쓰는 시간에 끄기
• https://aws.amazon.com/ko/solutions/implementations/instance-scheduler/

FinOps Optimize 단계: Paying Less
• Reserved Instance
• Savings Plan
• 대량 구매 할인
• 협상 요금
• Spot Instance
→ RI/SP 적용은 한번이 많이 보다 점진적으로 적용

J Curve 효과
생산성
시간
과제
시작
자동화 등 과제를 시작하면 초기에 툴 구축 등에 따라 생산성이 저하될 수 있음.

심리적 안정감 (Psychological Safety)
심리적 안정감:
• 인간관계의 위험으로 부터 근무 환경이 안전하다고 믿는 마음.
• 새로운 시험/도전을 할 때 설령 실패하더라도
무시당하지 않고, 질책 받거나 징계받지 않는 토대위에 형성
• 규칙을 위반하지 않으면 제제하지 않음
(문화를 악용하면 단호히 처벌)

두려움 없는 조직 – 실패를 받아들이는 관점
기존의 프레임 새로운 프레임
실패의 개념 절대 받아드릴 수 없는 것
도전하는 과정에서 생기는 당
연한 결과
효과적인 결과에
대한 생각
능력 있는 직원은 실패하지
않음
능력 있는 직원은 실패를 통
해 배우고 학습하며 동료와
공유함
목표 실패를 막는 것
실패를 통해 학습을 증진하는
것
출처: 두려움 없는 조직 / 에미드 에드먼슨 지음, 최윤영 옮김 / 다산 북스 / page 131

30가지 아이디어
Technology Adoption Lifecycle, Software Delivery Practice 계보, Toyota
Production System, 낭비의 최소화, 5 Whys, Value Stream Mapping,
Kaizen, 제약이론, Just In Time, Kanban, 자동화, Minimum Viable
Production, Project to Production, Team Topology, Why Cloud,
Microservice, CI/CD, Domain Driven Design, DevSecOps, DevOps, IaC,
고객 중심의 성장 플라이휠, FinOps, Using Less, Paying Less,
Psychological Safety, J Curve, SRE, DevOps Metrics, Cloud Strategy

Thank you!

Appendix

AWS의 Migration 과
Modernization을 위한 가이드

Simple three-step Migration approach
Migrate & Modernize
Assess Mobilize
Build readiness through experiences Accelerate transformation at scale
Rapid discovery TCO report
Briefings &
workshops
Migration Readiness
Assessment
Create a case for change
Operate &
optimize
Migrate
Modernize
Discovery & pl
anning
Migration
plan
Business case/
Mig. Evaluator
Migration & m
odernization
experience
Skills/center
of excellence
Landing
zone
Operating mod
el
Security & com
pliance
Immersion day
People Platform
Portfolio Migrate
Accelerators

Business Value on AWS

Migration and modernization strategies
Current IT snapshot Discover & organize data Strategies for each
workload (7Rs)
Applications
Performance
Infrastructure
Level
of
effort
Retire
Retain
Relocate
Rehost
Repurchase
Re-platform
Refactor
Tribal knowledge
SLA/OLA
App
configuration
data
Asset inventories
CMDB Architecture
Performance
Information
Strategy decision criteria should
be based on both business and
technical needs

7'R' 패턴에 따라 마이그레이션을 진행
Relocate VMware on AWS 으로 VMware HCX를 이용해 옮깁니다
Rehost Application Migration Service 를 이용해 Lift & Shift 합니다.
Replatform 빌드 및 배포 자동화와 함께 새 플랫폼으로 이동합니다.
Refactor 어플리케이션을 작고 유연한 구조로 재설계합니다
Repurchasing SaaS 솔루션으로 재구매 합니다.
Retain Onprem 에 워크로드를 유지합니다
Retire 사용하지 않는 서비스를 중단합니다

vRealize Suite, PowerCLI
AWS global infrastructure
Customer data center
vCenter
On premises
vSphere-based environment
Access to all native AWS services
Amazon EC2 Amazon S3 Amazon RDS
Amazon
Redshift
AWS Direct
Connect
Amazon
DynamoDB
AWS CLI, SDK
Amazon
SageMaker
AWS Shield
vSphere vSAN NSX
vCenter
VMware Cloud on AWS
Relocate: VMware 마이그레이션

Rehost: AWS Application Migration Service 이용
AWS Application Migration Service를 이용해 Onprem 그대로를 AWS로 이동합니다 (Lift & Shift)
AWS Cloud
Corporate
data center
Disk
Onprem server
(AWS Replication Agent installed)
AWS Application
Migration Service
Block Device 실시간 복제
Instances
Volume
Staging Area
Instance
Volume
Migrated Resource
Cut Over

Replatform: 데이터베이스
오픈소스, 목적에 맞는 Database 로 이동합니다
450,000 databases
migrated to date using
AWS Database Migration
Service
Oracle
instance
SQL Server
instance
MariaDB
instance
AWS Snowball Edge – 80 TB
On premises
Amazon
RDS
Amazon
Redshift
Amazon OpenSearch
Service
Amazon
DynamoDB
Amazon
Aurora
Amazon DocumentDB (with
MongoDB compatibility)
Amazon
Neptune
Amazon Kinesis
Data Streams
Amazon Managed
Streaming for Apache
Kafka
AWS Region
AWS Cloud
AWS Database
Migration Service
AWS Schema
Conversion Tool

AWS Schema Conversion Tool (AWS SCT)
Features
Create assessment reports for
homogeneous/heterogeneous migrations
Convert database schema
Convert data warehouse schema
Convert embedded application code
Code browser that highlights places where manual edits are required
Secure connections to your databases with SSL
Service substitutions/ETL modernization to AWS Glue
Migrate data to data warehouses using AWS SCT data extractors
Optimize schemas in Amazon Redshift
The AWS Schema Conversion Tool helps automate
many database schema and code conversion tasks
when migrating from source to target database engines
Source
database
AWS
SCT
Target
database

Replatform: 데이터
워크로드에 맞는 최적의 클라우드 스토리지로 이동합니다.
On premises
AWS Snowball Edge –
80 TB usable HDD
AWS DataSync
AWS Region
AWS Snowcone –
8 TB usable
Amazon S3
AWS Cloud
File system
Amazon FSx for Lustre
Amazon EFS
AWS Storage
Gateway Family
Amazon FSx for
Windows File Server
Direct Copy

Cloud Migration 과 Modernization 을 위한 30가지 아이디어-박기흥, AWS Migrations Specialist SA::AWS 마이그레이션 A to Z 웨비나

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Cloud Migration 과 Modernization 을 위한 30가지 아이디어-박기흥, AWS Migrations Specialist SA::AWS 마이그레이션 A to Z 웨비나

Similar to Cloud Migration 과 Modernization 을 위한 30가지 아이디어-박기흥, AWS Migrations Specialist SA::AWS 마이그레이션 A to Z 웨비나 (20)

More from Amazon Web Services Korea

More from Amazon Web Services Korea (20)

Cloud Migration 과 Modernization 을 위한 30가지 아이디어-박기흥, AWS Migrations Specialist SA::AWS 마이그레이션 A to Z 웨비나