완전 관리형 데이터베이스

• 고객은 스키마 설계, 쿼리 작성, 쿼리 최적화에만 신경

• AWS에서 백업, 복구, 보안, 스케일링, 모니터링 등 모두 지원

• MySQL, PostgreSQL, MariaDB 등 오픈소스DB 지원

  • 상용 DB보다 성능, 가용성 안 좋다

• 이를 해결하기 위해 Amazon Aurora 출시

AWS DB 종류

• 관계형 : RDS, Aurora (ACID)
• Key-value : DynamoDB (높은 처리량, 낮은 지연)
  • Aurora와는 달리 서버리스
  • 아이템(항목) (== RDB의 row)
  • Attributes (속성) (== RDB의 column)
    • 모든 아이템들이 동일한 속성을 가지지 않아도 된다
    • 테이블이 생성된 이후에도 원하는 아이템에 대해서 속성을 추가할 수 있다.
  • 파티션키 지정 (데이터 분산이 잘 되도록)
  • 조회를 빠르게하기 위해 소트키를 옵션으로 지정
• Document : DocumentDB
• In-memory : ElastiCache (마이크로 초단위 레이턴시, 애플리케이션에서 바로 접근 가능한 캐시 구조)
• GraphQL : Neptune
• Time-series : Timestream (시계열 데이터)
• Ledger : QLDB (블록체인)
• Wide column : Keyspaces (아파치 카산드라 호환)

OLAP vs OLTP

• OLAP (OnLine Analytical Processing) : 온라인 분석 처리
  • 데이터 웨어하우스의 데이터를 전략적인 정보로 변환시키는 역할. 기본 접근, 조회, 계산, 시계열, 복잡한 모델링
• OLTP (OnLine Transaction Processing) : 온라인 트랜잭션 처리
  • 여러 이용자가 실시간으로 데이터 베이스의 데이터 갱신, 조회하는 작업을 처리하는 방식. 주로 금융 전산 관련

DR 구성

• mirroring 상태로 active/active로 두면 동기화 문제는 없지만 비용 높음
• Hot / Cold로 나눠서 생각할 수 있음
  • Hot : 데이터만 이중화, 네트워크는 이중화 X
  • Cold : 수동 작업

DevOps

• 유연함을 위한 작은 단위로 나눔 (MSA, 2 피자팀)

  • 유닛을 가능한 작게, 기능 단위가 아니라 Sacling(확장) 단위 기반으로 분리
  • 각각의 서비스를 별도로 운영하여, 각각 다른 라이프사이클로 돌게 함
  • 투- 피자팀 : 12~15명 정도

• 모든 것을 자동화

  • 개발, 테스팅 모두 자동화

• 애플리케이션 아키텍쳐적인 변화가 중요하다!!

• 표준 도구 사용

• 프로세스 표준화(템플릿)

• IaC

• 아마존도 초기에 모놀리스 서비스였음 (운영 파이프 라인도 1개만 있었음, 모든 개발자가 한 사이클이 지날 때까지 기다릴 수 밖에 없는)

  • 따라서 운영 파이프라인을 서비스 단위로 나누게 되었음

DevOps 도구

• CodeCommit : 소스를 저장 관리

• CodeBuild (빌드, 테스트)

• CodeDeploy (배포)

• AWS X-Ray, AWS CloudWatch (모니터링)

• Cloud9

• 디펜던시, 패키징, 빌드 검증 (중간)

• 베타(성능), 감마(프로덕션 레디 검증), 프로덕션 (프로덕션)

AWS 운영 책임 모델

• 서버리스 (Lambda, Fargate, S3, Aurora, DynamoDB)

• 컨테이너 (EKS, ECR, ECS)

• AWS Cloud Development Kit(CDK) : VPC 생성하는 코드가 2줄 내지, IaC로 코드로 관리할 수 있는 것

  • CloudFormation 템플릿화, DevOps가 CloudFormation으로 구현되는 것이다
  • CloudFormation의 러닝 커브를 줄여 준다.

• 블루-그린 배포

  • 블루 : 기존 버전
  • 그린 : 새 버전
  • 트래픽을 일정 수준 이상 전환해보고 문제 없이 작동되면 그린 환경으로 배포, 이후 블루 환경 제거

• DevOps Guru는 머신러닝 기반으로, 애플리케이션 가용성을 개선

  • 이상을 감지하고, 노이즈 제거
  • 연관관계를 몰라서 의미를 찾기 힘든 경우를 찾아줌
  • CDK 혹은 CloudFormation 단위로 적용 가능

AWS Managed Services

• 변경 요청, 모니터링, 패치 관리, 보안, 백업 서비스
• Amazon Elasticsearch Service
• Amazon Redshift
• Amazon EMR

Serverless Analytics Services

• 운영이 없고, SQL, Script 등에만 집중

• Amazon Athena : 서버 운영 없이 SQL 기반으로 분석

  • 분석할 데이터를 S3에 Json, csv, parquet 등 포맷으로 넣으면, S3 데이터로 테이블 생성하여 SQL 분석 가능
  • User Defined function (UDF) 지원 (SQL 뿐만으로 부족한 부분 해결)
  • 1Tb -> $5.75 (비용 절감을 위해 parquet으로 변환)

• AWS Glue : 데이터 카탈로그를 관리하거나 spark 경험에서 ETL 작업하려면 선택

  • 데이터 카탈로그 생성 (데이터의 테이블 정보) -> Athena, EMR, Redshift Spectrum 등 다양한 분석 툴에서 분석 -> QuickSight로 시각화하여 대시보드 생성 가능
  • Glue Job을 통해서 스크립트로 ETL 작업
  • AWS Glue DataBrew : S3, RDS, 데이터 카탈로그의 데이터를 연결하여, 데이터의 정교화를 도와줌 (필드에 대한 통계 정보, 상관 관계)

• Amazon QuickSight

• 서버리스한 데이터 레이크(S3) 활용

• 데이터 저장은 S3에 하면 된다.

• 조그만 데이터로도 Athena, QuickSight로 데이터 분석 가능

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