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. 작동(운영)

AWS Elemental Live Streaming (MediaLive & MediaPackage)

Live Streaming 필수 요소

1. 미디어 입력
   • 시청하기에 적절하게 쪼개져 있지 않고, 고해상도일 수 있다.
2. 변환 & 저장
   • MediaLive : 고해상도의 입력신호를 적합한 화질로 변환
     • HTTP Live Streaming 이라는 프로토콜로 변환되게 됨
   • MediaStore : 저장
     • 심플한 Live Workload에 적합
     • S3와 같은 storage이지만, Cache Layer를 통해 쓰기, 읽기 지연을 최소화
   • MediaPackage : 저장
     • DRM
     • Live Streaming -> DASH + HLS + MSS (여러 디바이스에서 재생 가능)
3. 전송
   • CloudFront : 실시간 데이터를 안정적이고 좀 더 빠르게 클라이언트가 재생할 수 있게 함
4. 재생 & 소비

MediaPackage

• MediaLive의 목적지로 존재하기 때문에 가장 먼저 생성
• Input A, B의 주소로 프로세싱된 스트림을 보내게 됨
• 사용자가 재생할 수 있는 엔드포인트(HLS, CMAF, DASH)는 직접 생성해줘야 함
• Packager Settings
  • 영상을 몇 초 단위로 쪼갤지, 재생 목록에는 몇 초 단위를 유지할지

MediaLive

• 채널 먼저 생성하지 않고, 입력(Input A, B)을 먼저 생성
  • Event 기반, Time 기반으로 입력을 switing하는 기능이 제공 (일정 Tab)
  • 특정 시간에는 특정 인풋으로 스트림, 다른 시간에는 다른 인풋으로 맵핑 가능
• Input Type
  • RTP : UDP 기반, 전용망(Direct Connect, MediaConnect)
  • RTMP : TCP 기반, Public망
    • Push : 영상을 밀어넣거나 (OBS - 웹캡 to RTMP)
    • Pull : 미디어 서버에서 가져오거나
  • HLS, MP4 : S3의 입력 소스를 기반으로, VOD를 라이브 신호처럼 송출할 때 사용 (VOD to Live)
  • MediaConnect : 리전간 스트리밍 전송 서비스
• 채널 생성
  • 템플릿 : 해상도, 비트레이트, 프레임레이트가 사전설정된 템플릿
  • 이중화(인풋 2개, 출력 2개) : 가용성 보장하기 위해
  • 코덱 (압축) : 아래로 갈수록 압축률 높다 (압축률 높을수록 CPU자원이 많이 사용되므로 비쌈)
  • ABR (Adaptive Bit Rate): 플레이어의 네트워크 bandwidth에 따라 자동으로 해상도가 변환되는 기능 (ex> 유튜브 auto 해상도 - 쪼개진 영상 시간이 지났을 때)
  • 파이프라인 == input
• m3u8
  • 사파리에서는 바로 재생
  • 크롬에서는 HLS 확장 프로그램 설치

AWS

고가용성, 내결함성

• 고가용성 : 전체 시스템에 대하여, 사람이 개입하지 않아도 시스템이 항상 작동하고 액세스 가능, 가동 중지를 최소화하도록 보장하는 것

  • 시스템을 1분이라도 사용할 수 없으면 비즈니스에 중대한 손상
  • ELB : 지연 시간이 길거나 서버가 과다 사용되는 경우 이를 알리는 트리거로 동작
  • EIP : 인스턴스가 실패하더라도 클라이언트가 애플리케이션에 액세스할 수 있도록 고정 IP
  • Route 53 : 단순 라우팅, 지연 시간에 따른 라우팅, 상태확인, DNS 장애 조치, 지리 위치 라우팅 지원
  • Auto Scaling
  • CloudWatch
  • 여러 AZ

• 내결함성 : 시스템의 일부 구성요소에 장애가 있어도 시스템이 계속 작동할 수 있는 기능 (애플리케이션 관점)

  • SQS : 내결함성 애플리케이션의 백본으로 사용, 안정적인 분산 메시징 시스템, 대기열 항시 사용 가능
  • S3 : 내구성과 결함성이 뛰어난 데이터 스토리지. 리전 내 여러 시설에서 각 디바이스의 모든 데이터를 중복 저장
  • RDS : 자동 백업, 스냅샷, 여러 가용 역역 지점

• 탄력성 : 용량 요구사항에 대해 신경쓰지 않고 자동화된 확장 및 축소

  • 트래픽 급증 시 웹 서버 수 증가
  • 트래픽이 줄어들 때 데이터베이스 쓰기 용량 감소 (IOPS : Input/Output Opereations Per Second)
  • 아키텍쳐 전반에 걸친 일상적인 수요 변동 처리
  • 시간 기반 탄력성 : 리소스가 사용되지 않을 때 리소스 끄기
  • 볼륨 기반 탄력성 : 수용 강도에 맞게 규모 조정

AWS MediaConvert를 이용하여 영상을 스트리밍할 때 HLS 프로토콜이 사용된다.

애플에서 개발한 HLS 프로토콜의 특징에 대해서 간단히 정리해보았다.

HLS(HTTP 라이브 스트리밍)

• HLS는 비디오 파일을 다운로드할 수 있는 HTTP 파일 조각으로 나누고 HTTP 프로토콜을 이용해 전송
• 클라이언트는 이러한 HTTP 파일을 로드한 후 비디오로 재생
• 모든 인터넷 장치가 HTTP를 지원하기 때문에 간단하게 실행 가능
• HLS 스트리밍은 재생에 지장을 주지 않고 네트워크 상태에 따라 비디오 품질을 높이거나 낮출 수 있다.
• 미디어 파일을 한 번에 모두 보내는 대신 한 번에 조금씩 지속적으로 사용자 장치에 보냄

1. 서버
   • 인코딩 : 비디오 포맷 재설정 -> 모든 장치가 데이터를 인식하도록
   • 조각화 : 비디오는 몇 초 길이(10초 정도)의 세그먼트로 쪼개짐
     • 세그먼트로 나누고, 세그먼트의 인덱스 파일(m3u8)을 만들어 세그먼트의 순서를 기록
     • HLS는 480p, 720p, 1080p 등 다양한 품질로 여러 세트 세그먼트 복제
2. 배포
   • 일반적으로 CDN을 사용하여 여러 지역으로 배포. 스트리밍을 캐시하여 클라이언트에 더 신속히 전송 가능
3. 클라이언트
   • 인덱스 파일(m3u8)을 참조하여 비디오를 순서대로 조합하고 필요에 따라 품질을 높이거나 낮춤