CloudEndure

• rehosting 솔루션 (lift & shift)
• Source 서버를 aws 계정에 지속적 복제, 마이그레이션 준비가 되면 서버를 자동으로 변환하고 실행 (전환 시간 단축)
• Agent 기반 솔루션
• 지원 버전

기능

1. 재해 복구
   • CloudEndure Disaster Recovery
     • 스냅샷 기반 솔루션이 아니라 비동기적 복제이므로 초 단위의 RPO(복구 지점 목표)를 실현
     • 자동화된 시스템 변환 및 오케스트레이션을 통해 몇 분 단위의 RTO(복구 시간 목표)를 구현
     • 랜섬웨어로부터의 보호 : 손상되지 않은 서버 버전을 대상 aws 리전에서 시작
     • 온프레미스 to Cloud, 온프레미스 to 온프레미스(Outposts), 리전 간 재해 복구, 클라우드 간 재해 복구를 모두 지원
2. 데이터 무결성 보장
3. 중단없는 workflow
   • 백그라운드 실행을 통해 시스템 성능에 영향을 주지 않고, 데이터의 지속 흐름을 보장
   • 스냅샷, 디스크에 데이터 Write를 하지 않고도 메모리상에서 소스 서버를 복제
4. 보안
   • AES 256 bit를 이용해 전송 중 데이터를 암호화
   • hand-shake, 모니터링을 위해 TCP port 443에 대한 송신 액세스 필요
   • 복제 서버와 통신하기 위해 TCP port 1500에 대한 송신 액세스 필요
   • 에이전트가 복제 서버와 통신하는 것에서 Public 통신이 불가능하도록 하는 요구사항이 필요할 때, Direct Connec나 VPN으로 연결할 수 있는 옵션을 지원. 또한 이 경우에 proxy 서버를 통해서 복제 서버와 통신하도록 하는 옵션 또한 제공.

절차

1. Source 시스템에 CloudEndure Agent 설치
   • CloudEndure Agent는 CloudEndure 콘솔에 연결한 다음, destination이 되는 aws region으로 api를 호출하여, 고객 계정에 staging 영역 생성
   • staging 영역은 경량 EC2 (복제 서버 - default: t3.small)와 저렴한 EBS 볼륨으로 구성
   • 복제 서버는 CloudEndure Agent로부터 데이터를 수신하여 EBS 볼륨에 Write 수행
     • Public IP address가 자동 할당됨
   • 리눅스 machine
     1. agent 설치

         wget -O ./installer_linux.py https://console.cloudendure.com/installer_linux.py

     2. installer 실행 (Token 값은 Machine Actions -> Add Machine에서 확인 가능)

         sudo python ./installer_linux.py -t THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1-THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1 --no-prompt

   • 윈도우 machine
     1. agent 설치

         https://console.cloudendure.com/installer_win.exe

     2. installer 실행

         installer_win.exe -t THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1-THIS-NUMB-ERWI-LLBE-DIFF-EREN-TFOR-YOU1 --no-prompt

2. 모든 source 디스크가 staging 영역으로 복제된 후, agent는 source의 변경 사항을 추적하고 복제
   • 1초 미만의 지연시간으로 연속 비동기 블록 수준 데이터 복제(CDP)를 수행
   • 인스턴스 기준으로 마이그레이션이 진행되기 떄문에, 여러 개의 볼륨이 한 인스턴스에 붙어 있어도 마이그레이션이 가능
   • 중간에 볼륨 사이즈가 늘어나면, CloudEndure은 Rescanning을 통해 늘어난 볼륨 사이즈를 인식하는 과정을 수행
     • 이러한 추가된 디스크에 대한 자동 감지는 default 옵션이며, 요구사항에 따라 자동 디스크 감지가 필요없다면 agent를 설치 커맨드 실행시에 --force-volumes 플래그나 -no-auto-disk-detection 플래그를 적용하여 비활성화
3. 고객이 CloudEndure의 [Setup & Info] - [Replication settings] 에서 Source와 Target(destination)을 지정할 수 있음
   • 온프레미스 Source의 경우 Other Infrastructure을 지정
4. test 및 cutover 진행하면 대상 리전으로 마이그레이션 진행됨

CloudEndure 제한사항

• Agent 설치 이후에 복제가 완료되면, 지속적으로 변경 사항을 추적한다. 이 변경 사항이 실제로 서버에 반영되는 것은 Test나 Cutover를 했을 때 반영된다.
• Blueprint에서 EIP 지정을 하지 않으면, 새롭게 test 요청을 했을 때 IP 주소가 바뀐다.
• CloudEndure 복제 속도는 다음과 같은 요소에 의해 영향을 받는다.
  • Source에서 복제 서버까지의 up-link 속도 및 대역폭
    • iperf3로 테스트 가능. 테스팅은 replication 서버가 있는 서브넷에 linux 인스턴스를 추가해서 테스팅한다.
    • sudo apt-get install iperf3 -y로 설치한 뒤, 서버 인스턴스에서 iperf3 -s, 클라이언트 인스턴스에서 iperf3 -c [IP 주소]를 실행하여 확인 가능
  • 전체 디스크 스토리지
  • 복제 중 디스크 변경
    • 쓰기가 많은 서버에서 복제 데이터의 전송을 따라잡지 못할 수 있다.
    • 따라서 DB서버 migration은 SMS나 DMS 권장
  • 원본 서버 I/O 성능
• 네트워크 대역폭 조절(스로틀링) 옵션을 통해 기존 시스템의 트래픽 압박을 줄일 수 있으나, Source 서버의 쓰기 작업량(최소 대역폭) 보다 높게 설정해야 한다. 그렇지 않으면 복제 작업이 완료되지 않음. 이 부분이 사전에 예측이 어렵기 때문에, 사전 test 진행을 통해 어느 정도로 제한할 것인지 결정해야 함.

vs AWS Server Migration Service (SMS)

Reference

• CloudEndure Migration
• CloudEndure Disaster Recovery
• CloudEndure vs AWS SMS

Storage Migration

AWS EBS (Elastic Block Store)

• EC2 인스턴스에 사용하기 위한 블록 레벨 스토리지 볼륨 제공
• 동일한 인스턴스에 여러 볼륨을 마운트할 수 있으나, 각 볼륨은 한 번에 하나의 인스턴스에만 연결
• 볼륨 타입으로 SSD, HDD
  • SSD : 일반적 용도, 낮은 대기 시간과 높은 처리량을 위한 성능이 필요하다면 선택
  • HDD : 처리량 최적화 볼륨(높은 처리량이 필요한 빅데이터나 로그 처리 등), Cold(접속은 적게하지만, 처리량에 최적화된 업무)

AWS EFS (Elastic File System)

• 파일 시스템을 만들고, EC2 인스턴스에 파일 시스템을 마운트한 다음, EFS에서 데이터를 읽고 쓸 수 있음
• EFS를 여러 EC2에 동시에 마운트할 수 있음. 즉, 여러 서버에 대한 공유 파일 시스템을 구성 가능
• AWS에 내장된 EFS를 온프레미스 서버로 마운트 가능

AWS Snowball

• 데이터 센터에서 네트워크에 직접 연결하고 로컬 네트워크를 활용하여 데이터를 복사할 수 있는 물리적 디바이스
• 최대 80TB, AWS KMS에 의해 데이터를 암호화
• 온프레미스 데이터 스토리지와 S3간 데이터를 가져오고 내보낼 수 있음

AWS Snowmobile

• 이동할 데이터가 많을 때 사용
• 최대 100페타바이트의 데이터를 보관

AWS Storage Gateway

• 온프레미스 환경에서 AWS 내의 게이트웨이 엔드포인트에 연결되는 VM 이미지르 활용
• 로컬 스토리지 리소스를 AWS 클라우드에 연결하고 스토리지 메커니즘에 가용성, 내결함성 및 확장성 추가
• 파일 기반, 볼륨 기반, 테이프 기반 옵션 제공
  • File Gateway : S3에 대한 파일 인터페이스 지원. NFS, SMB와 같은 프로토콜을 통해 S3에서 객체를 저장 및 검색 가능
  • Volume Gateway : 온프레미스 애플리케이션 서버에서 iSCSI 장치로 마운트할 수 있는 클라우드 백 스토리지 볼륨 제공
    • 캐시 볼륨 : S3에 데이터를 저장하고 자주 액세스하는 데이터 집합의 복사본을 로컬로 유지 가능
    • 저장 볼륨 : 전체 데이터 세트에 대한 짧은 지연 시간의 액세스가 필요한 경우에 사용
      • 모든 데이터는 로컬에 저장되며, 온프레미스 스토리지에서 스냅샷 생성, 로컬 볼륨 복구나 AWS 계정 내 볼륨 생서에 사용
  • Tape Gateway : 백업 데이터를 AWS에 안정적으로 보관할 수 있음

AWS DataSync

• 하이브리드 환경으로 마이그레이션할 때, 환경 간 작업에 도움을 주는 도구
• AWS Direct Connect를 통해 온프레미스 스토리지 시스템과 AWS 스토리지 서비스 간 데이터 이동 및 복제를 단순,자동,가속화하는 데이터 전송 서비스
• NFS에서 DFS, S3로의 전송을 지원.
  • Storage Gateway와의 차이점은 DataSync는 주로 NFS 소스에서 전송하는 데 사용되며 대상은 EFS
• 온프레미스 스토리지 스스템에서 데이터를 읽거나 쓰는데 사용되는 가상 머신인 에이전트 사용

AWS DMS (Database Migration Service)

• RDBMS, Data warehouse, NoSQL 등 데이터 저장소를 쉽게 마이그레이션하는 도구
• 데이터를 AWS클라우드와 온프레미스 간 마이그레이션
• 원본 데이터 저장소에 연결하여 원본 데이터를 읽은 다음, 대상 데이터 저장소에서 사용할 데이터를 형식화하고 데이터를 로드
• 마이그레이션을 모니터링할 수 있는 기능을 제공
• Oracle to Orcle, Oracle to MySql, MySql to Aurora 등 다른 DB 플랫폼간 마이그레이션을 지원
• 온프레미스 DB를 EC2 인스턴스에서 실행되는 DB로 마이그레이션도 가능
• 가동 중지 시간 없이 데이터베이스를 마이그레이션할 수 있음
• AWS DMS를 사용하려면 하나의 엔드포인트가 반드시 AWS 서비스에 있어야 함 (온프레미스 to 온프레미스는 지원 X)

AWS SSC (Storage Schema Conversion)

• 기존 데이터베이스를 가져와서 해당 스키마를 다른 엔진으로 변환 (이기종 엔진간 변환)

Amazon Aurora (Serverless)

• 데이터베이스가 애플리케이션 요구에 따라 자동으로 시작, 종료 및 용량 확장, 축소가 되는 Auto Scaling Solution
• DB 인스턴스 클래스 크기를 지정하지 않고, 데이터베이스 엔드포인트를 생성 (대신, 최대 및 최소 용량을 설정함)
• 연결을 자동으로 관리. 요청을 처리한 준비가 된(warm) 리소스 pool을 사용

AWS Direct Connect

• 개방형 인터넷을 사용하는 경우, VPN 연결로 네트워크 연결
• 개방형 인터넷을 쓰지 않는 경우, AWS Direct Connect 사용
  • 네트워크 경로에 퍼블릭 인터넷이 없어도 AWS 클라우드에 대한 가상 인터페이스를 직접 생성 가능
  • Direct Connect 링크를 통해 VPN 터널을 설정하여, 온프레미스 리소스에서 AWS의 리소스로 안전하게 통신 터널을 만듦
  • 부드러운 데이터 전송, 마이그레이션 컷오버(새 버전 오픈) 및 지속적 복제 가능

배포 전략

1. 레드/블랙

• 원래 환경과 새로운 환경 모두 실행 중
• 마이그레이션된 프로그램에 문제가 발생하면 원래 환경으로 돌림
• 트래픽 이동 후에 문제가 발생하면, 애플리케이션이 다운되어 사용자에게 부정적인 영향

2. 블루/그린

• 설치, 테스트 및 실행 중인 두 환경 모두 설정이 동일
• 즉석으로 컷오버하는 것이 아니라 적은 양의 트래픽(5~10%)만 이동
• 레드-블랙은 문제가 널리 퍼지지 않아 사용자에게 영향이 적다.
• 대신에 각 엔드포인트로 이동하는 트래픽 양을 제어할 수 있는 DNS 서비스(Route 53)을 사용해야 한다.

AWS CloudFormation

• CloudFormation 엔진을 통해 인프라를 생성, 구성 및 업데이트할 수 있는 템플릿 기능
• 테스트 환경을 신속하게 가동할 수 있기 때문에 마이그레이션에 유용

AWS Systems Manager

• 실행 중인 서버에 대한 경로를 제공하여 명령과 업데이트를 예약할 수 있다.
• 서버에 직접 연결하지 않고도 명령을 실행할 수 있기 떄문에 시간과 노력이 절약
• AWS 뿐만 아니라 온프레미스 서버로 시스템을 관리 가능(SSM 에이전트 == AWS 시스템 관리자 에이전트 사용)

TSO Logic

• AWS 내에 존재하는 솔루션으로, 기존 리소스를 검색하여 컴퓨팅, 스토리지, DB 등 영역에서 실행중인 대상을식별하는 데에 도움을 줌
• 애플리케이션에 대한 총 소유 비용(TCO)를 평가할 수 있고, 예측 분석을 통해 클라우드의 워크로드(마이그레이션)에 적합한 것을 결정 가능

CloudEndure

• 물리적, 가상 및 클라우드 기반 인프라에서 AWS로의 대규모 마이그레이션을 단순화, 촉진 및 자동화한다.
• 스냅샷을 만들거나 디스크에 데이터를 기록하지 않으므로 성능에 거의 영향을 주지 않음
• 수천대의 시스템에서 동시에 데이터를 복제할 수 있으며, 각 머신을 병렬으로 작동시킴
• 전체 마이그레이션 라이프사이클을 관리하며, 컷오버 준비 상태를 확인할 수 있음

Rehosting & Replatforming

Scaling

• Horizontal Scaling (scaling out)
  • 자원을 추가하고 이를 통해 분배할 때
  • 원래 자원에 대한 정지 시간이 발생하지 않음
  • 로드가 증가함에 따라 더 많은 리소스를 추가하고 로드를 분산
  • 로드가 줄어들면 다시 원래 숫자로 돌릴 수 있음
• Vertical Scaling (scaling up)
  • 동일한 논리적 리소스를 유지하지만 해당 리소스를 효율적으로 사용
  • 리소스가 더 많은 작업량을 처리하도록, 메모리, 스토리지, 컴퓨팅 파워 등의 항목을 추가
  • 하나의 논리적 리소스이기 때문에 여러 개의 요청을 분배할 필요가 없음
  • 약간의 정지시간 발생
  • 규모가 확장되지 않을 수 있음

High Availability

• 단일 구성 요소나 노드 장애로 시스템 실패를 피함

• 여러 엔드포인트 혹은 노드에 트래픽과 요청을 분배(Load Balancing)

• 확장성 (수평, 수직 확장)

• 환경을 모니터링 (비정상적인 작업 탐지 및 복구)

Migrating DB

• DB Migration
  • 크기
  • 스키마
  • 테이블 유형
  • 엔진 관련 제한 사항

AWS Server Migration Services (SMS)

• AWS 클라우드 환경으로 가상 리소스를 쉽게 전송할 수 있음
• Agent 없는 서비스로, 최대 수천 개의 온프레미스 작업량을 AWS로 쉽고 빠르게 마이그레이션할 수 있음
• VMware vSphere, Microsoft Hyper-V, Azure 가상 머신을 AWS로 마이그레이션하는 데만 사용 가능
• 서버 VM을 Amazon Machine Images(AMI)로 복제하여 EC2에 배포할 수 있음
• AWS로 서버 VM을 전달하려면 Connecter가 필요함
• 마이그레이션 모니터링은 CloudWatch를 통해 가능하며, 로깅 및 품질 검사는 CloudTrail을 통해 가능
• VM Import/Export를 통해 기존 환경에서 AWS로 Virtual Machine Image를 쉽게 가져올 수 있음

AWS Migration Hub

• 애플리케이션의 전체 마이그레이션 상태를 한눈에 파악하고 적합한 마이그레이션 도구를 선택
• 개별 애플리케이션의 마이그레이션 진행 사항 파악 (모니터링)
• 검색 혹은 마이그레이션을 시작한 이후, Migration Hub에서 환경 탐색 가능
• 마이그레이션이 완료되면, Migration Hub는 EC2 인스턴스르 만들거나 실행하는 AMI에 대한 링크 제공
• AWS Database Migration Service(DMS)에서 마이그레이션한 DB의 경우, 검색 필터로 사용 가능한 엔드포인트 ID 제공

AWS Application Discovery Service (ADS)

• 온프레미스 서버에 대한 사용 및 구성 데이터를 수집하여 AWS 클라우드로의 마이그레이션을 계획할 수 있음
• 온프레미스 서버 검색 및 데이터 수집에서 에이전트 없는 검색 / 에이전트 기반 검색 둘다 지원함
  • 에이전트 없는 검색
    • VMware vCenter에서 작동
    • AWS Agentless Discovery Virtual Appliance를 배치하여 수행
    • 검색 커넥터 구성 -> vCenter와 연결된 가상장치 호스트 식별 -> 서버 구성 정보(서버 호스트 이름, IP, Mac주소 등) 수집, VMs에 대한 metrics 수집
      • Replatform 방식 마이그레이션에 유용
    • 검색 커넥터는 VMs의 내부를 볼 수 없기 때문에, 실행 중인 프로세스나 네트워크 연결을 파악할 수 없음
      • 이 정보가 필요하다면 에이전트 기반 접근 방식을 사용해야 함
  • 에이전트 기반 검색
    • 각 VMs에 AWS Application Discovery Agent를 배치하여 수행
    • 에이전트가 정적 구성 데이터, 시계열 시스템 성능 정보, 인바운드 아웃바운드 네트워크 연결, 실행 중 프로세스 등 수집
    • Application Discovery Service는 AWS Migration Hub와 통합
    • 수집한 모든 데이터는 Amazon Athena 및 Amazon QuickSight와 같은 도구를 사용하여 분석

Migration to the Cloud

https://ko.coursera.org/learn/aws-fundamentals-cloud-migration

• AWS Cloud Adoption Framework (CAF) : 조직 내 비즈니스 프로세스를 클라우드로 변환하는 과정 지원
  • Business : 아키텍쳐 접근 방식이 기술 제공과 비즈니스 핵심을 어떻게 연계하는지
  • People : 클라우드 플랫폼을 도입하는 데 필요한 기술은 무엇인지 (역할, 교육, 자격증, 멘토링 등)
  • Governance : 클라우드 투자를 관리 및 측정하는 데 필요한 조직 프로세스 업데이트
  • platform : 기술 서비스를 최적화하는 데 필요한 패턴, 도구
  • security : 규정 준수을 달성하는 데 필요한 보안, 위험관리 구현
  • operations : 최적 운영 서비스 관리

단계

1. migration planning
2. 포트폴리오 검색 및 계획
   • 애플리케이션 간 상관 관계 파악하고 적합한 마이그레이션 유형 파악
3. 응용 프로그램 설계, 마이그레이션 및 검증
   • Rehost
     • lift and shift
     • 애플리케이션을 클라우드로 직접 이동 (직접 마이그레이션, 포크 리포팅)
     • 기존 시스템의 안정성, 기능, 보안을 유지하며 빠르게 클라우드에 도달하는 것이 목표
   • Replatform
     • lift, tinker, shift
     • RDS에서 데이터베이스 옮기기
       • 데이터베이스 기능을 잃지 않으며
       • 고가용성 및 자동화된 유지 관리
   • Repurchase
     • 다른 제품 또는 라이센스 모델로 이동하기로 결정
       • 제품의 새 버전으로 업그레이드하거나 라이센스를 변경할 때
       • 시스템의 디자인을 근본적으로 변경하지 않는다는 점
   • Refactor
     • 사용 시간을 따질 때 가장 비용이 많이 들지만, 클라우드의 이점을 최대한 활용
   • Retire (폐기)
     • 레거시 시스템이 항상 존재하는 환경인 경우, 마이그레이션할 자산을 제거
   • Retain (유지)
     • 마이그레이션할 준비가 되지 않았을 때
     • 유지하는 것이 훨씬 수월할 때
4. 작동(운영)