AWS의 여러 가지 기타 서비스 (2)

 

카테고리로는 분류하기 애매한 여러 가지 AWS 부가 서비스들을

전 글에 이어서 정리해보려고 한다.

 

#0 AWS Backup - 내가 설정한 계획으로 자동 백업하기 📥

중앙에서 관리하는 완전 관리형 서비스이고 AWS 서비스 전반에 자동으로 백업한다. 온디맨드와 예약된 백업을 실행하고 PTR(시점 복구)를 지원한다. 백업 보존 기간과 수명 주기 관리, 백업 정책 기간 등을 정의할 수 있다. Organizations에서 지원하는 region간 백업이나 계정 간의 백업도 할 수 있다. 

백업 서비스를 생성하면 '계획'을 생성해야 하는데 빈도뿐만 아니라 백업 보존 정책도 따로 생성해야 한다. 내가 지정한 서비스의 정책과 빈도에 따라 S3에 자동으로 백업된다.

 

#1 Disaster Recovery Strategies (재해 복구 전략)

1. 백업과 복원(Backup and Restore)

클라우드에 데이터가 백업하는 것으로 재해가 발생한 경우에 다른 곳에서 복원해서 애플리케이션을 다시 실행하는 것

데이터가 백업 중에는 애플리케이션이 실행되지 않고 원하는 위치에 복원됐을 때만 애플리케이션이 실행된다. 그리고 최소 비용이 발생하고 시간이 지남에 따라 백업하기 때문이다. (그래서 가장 저렴)

 

2. Pilot Light

애플리케이션의 핵심 기능을 클라우드에서 실행하는 것

클라우드에 데이터베이스가 있고 확장 준비가 됐지만 최소한의 설정만 있어서 완전히 데이터베이스가 확장되지 않고 애플리케이션/서버도 다 없다 (파일럿 라이트만 존재)

=> 즉 Pilot Light는 애플리케이션의 최소 설정과 핵심 기능이 클라우드에 있는 것이다.

=> 1번보다 백업과 복원 비용이 조금 더 비싸다. 재해 복구 전략을 실행할 때에 데이터베이스 유형을 업그레이드하고 애플리케이션 서버를 시작하게 된다. (애플리케이션의 최소 핵심 기능은 사용할 수 있는 상태)

 

3. Warm Standby

클라우드에 전체 버전의 애플리케이션이 있지만 최소 크기이다. 그리고 당연하게도 1,2번 보다 조금 더 비싸다.

재해 복구 전략을 실행하려면 애플리케이션의 크기를 늘리면 된다. 

 

4. Multi-Site/Hot-Site

무조건 사용할 수 있는 전체 크기의 전체 버전 애플리케이션이 있는 건데 4개의 항목 중 제일 비싸지만 재해가 발생하면 바로 배포할 준비가 됐기 때문에 성능은 매우 좋다.

 

#2 AWS Elastic Disaster Recovery (DRS) 👯- 빠른 재해 복구를 위한 클라우드 복제

이걸 사용하면 물리, 가상, 클라우드 기반 서버를 쉽고 빠르게 복구할 수 있다. 중요한 데이터베이스(Oracle, MySQL...)와 기업 애플리케이션을 보호하거나 랜섬웨어 공격으로부터 데이터를 보호하려 할 때 DRS 서비스를 이용하면 서버를 기업 데이터 센터에서 클라우드로 복제할 수 있다. (블록 수준에서)

기업 데티어 센터에 있는 AWS Replication Agent 덕에 저비용 EC2 인스턴스와 EBS 볼륨으로 구성된 AWS 스테이징 환경에 디스크가 지속적으로 복제된다. 데이터 센터에 문제가 발생하는 경우에는 재해 복구를 수행해야 할텐데 더 큰 인스턴스와 좋은 EBS 볼륨을 생성함으로써 몇 분만에 스테이징에서 프로덕션으로 장애조치(Failover)를 수행할 수 있다. 기업 데이터 센터가 온라인으로 돌아오면 시스템을 기업 데이터 센터로 복귀시키는 장애 복구(Failback)을 수행한다.

 

#3 DataSync (데이터 싱크) - 많은 양의 데이터 이동시키기 ➡️

DataSync를 통해 온프레미스에서 AWS로 많은 양의 데이터를 이동할 수 있다. 그리고 데이터를 Amazon S3, Amazon EFS 또는 Window용 Amazon FSx로 동기화할 수 있다. 예를 들어 일정 주기마다 복제 테스크를 예약할 수도 있고 온프레미스에서 AWS로 첫 번째 전체 데이터가 로드되면 다른 모든 테스크는 incremental(증분 - 일정단위로 증가)된다. 

설명을 위한 이미지

그림을 참고해서 더 설명해보자면 온프레미스 서버에서 데이터를 마이그레이션하거나 복제하고자 하는데 온프레미스에서 데이터싱크 에이전트를 실행하면 이 에이전트는 DataSync 서비스에 연결해서 데이터를 S3나 모든 스토리지 클래스들에 전송한다..! 

 

#4 Application Discovery Service / Application Migration Service

<Application Discovery Service>

예를 들어 새로 시작하는데 클라우드를 직접 활용하려는 경우가 있는데 이 경우에는 마이그레이션 할 필요가 없지만 온프레미스 서버와 데이터 센터가 있고 클라우드로 마이그레이션하려는 경우엔 마이그레이션을 계획해야 한다.

마이그레이션을 계획하는 첫 번째 방법은 AWS Application Discovery Service를 사용하는 것.

서버를 스캔해서 서버 설치나 종속성 매핑에 대한 정보들을 수집해준다. => 마이그레이션할 때 중요한 정보

=> 따라서 마이그레이션 방법이나 무엇을 먼저 마이그레이션 할 것인지를 알 수 있게 된다.

두 번째는 Agentless Discovery Connector(커넥터를 사용한 에이전트리스 검색)이다.

이 방법은 가상 머신, 구성, 성능 기록에 관한 정보를 제공한다. (CPU, 메모리, 디스크 사용량 같은 것을 말한다)

그리고 에이전트를 실행해서 Agentless Discovery Connector를 수행하면 가상 머신 내에서 더 많은 업데이트와 정보를 제공한다. 

=> 결론적으로 AWS Application Discovery Service는 이동시켜야 하는 것들을 파악하고, 그것들이 어떻게 상호 연결되어 있는지 파악하는데 정말 도움이 된다.

 

<Application Migration Service(MGN)>

온프레미스에서 AWS로 이전하는 가장 간단한 방법은, MGN이라는 것을 이용하면 된다. 이것을 사용해서 리호스팅(Lift-and-shift방식)을 할 수 있다.

동작 방식 : 기업 데이터 센터에 OS, 앱, 데이터베이스가 있고 디스크에서 실행된다고 가정해본다. Application Migration Service를 실행한 다음, 복제 에이전트 데이터 센터에 설치하면 그게 지속적으로 디스크를 복제(Continuous replication)한다. 그러면 복제된 데이터를 갖는 저렴한 비용의 EC2 인스턴스, EBS 볼륨을 확보할 수 있다. 변환하는 날에는 스테이징->프로덕션으로 이동해서 원하는 크기의 EC2 인스턴스와 필요한 성능을 가진 EBS 볼륨을 사용할 수 있다.

(즉, 데이터를 복제하고 어느 시점에 변환하면 된다)

=> Application Migration Service를 사용하면 다운타임은 최소하하고 비용도 절감된다. 이 서비스는 자동으로 수행된다..!

 

#5 Migration Evaluator , Migration Hub

< Migration Evaluator >

AWS Migration Evaluator는 AWS Migration에서 데이터 기반 비즈니스를 구축하는데 도움이 된다.

우리가 마이그레이션을 해야 한다고 할 때 현재 조직에서 실행 중인 작업에 대해 명확한 기준선을 확보해야 한다. (워크로드 파악하는 것)

그리고 Agentless Collector(에이전트리스 수집기)를 설치해서 모든 인프라에 대해 광범위한 검색을 수행한다. 또한 온프레미스 풋 프린트를 스냅샷 찍는다.

=> 이것을 이용해서 현재 상태를 분석하고 목표를 설정해서 마이그레이션 계획을 수립할 수 있다.

< Migration Hub >

서버와 애플리케이션 인벤토리 데이터(마이그레이션의 평가, 계획, 마이그레이션 추적 등)를 수집할 수 있는 허브인데 이것을 통해 AWS 마이그레이션을 가속화하고 Lift-and-shift 프로세스를 자동화하는데 도움이 된다.

Migration Hub의 하위 기능인 'Migration Hub Orchestrator'도 있는데 이는 사전에 빌드된 템플릿을 이용해서 시간을 절약하고 SAP나 Microsoft SQL서버와 같은 엔터프라이즈 앱을 마이그레이션할 수 있다. 

그리고 사실 이전에 정리했던 Application Migration Service(MGN)와 Database Migration Service(DMS)와 통합되어 있다..!

=> 결국 Migration Hub는 모든 서버와 앱을 살펴보고 중앙 집중화해서 워크로드의 크기나 권장 사항을 조정할 수 있고 여러 도구 간의 마이그레이션을 오케스트레이션해서 최종적으로 이렇게 애플리케이션을 조금씩 리팩토링하면서 AWS로 이전할 수 있는 것이다.

 

#6 AWS Fault Injection Simulator(FIS) - 애플리케이션 과부하 시켜보기(카오스 엔지니어링)💀

개발하는 애플리케이션을 AWS 워크로드에서 결함을 찾기 위해 주입하는 실험을 하는데 이걸 사용해서 상당히 파괴적인 이벤트를 발생시켜서 애플리케이션에 스트레스를 가하는 카오스 엔지니어링을 기반으로 한 서비스이다.

사용하면 CPU 이용률이 치솟거나 데이터베이스가 메모리가 부족하면 오류가 발행하는 등의 이벤트를 미리 경험할 수 있다. 애플리케이션 자체가 탄탄한지도 확인할 수 있고 이를 통해서 몰랐던 버그나 병목 현상이 있는지를 찾아낼 수 있는 것이다.

(그러나 FIS는 일부 서비스만 지원하니 확인해봐야 한다)

그림을 빌려 더 설명하자면 FIS로 먼저 '실험 템플릿'을 생성하고 리소스에 대한 재해를 일으킨다. 여러 리소스(EC2..)에 어떤 일이 발생할지 선택하면 이 실험은 시작되 CloudWatch, X-ray EventBridge 등을 통해 애플리케이션의 양상을 모니터힝하는 것이다.

 

#7 AWS Step Funtions - 복잡한 워크플로우 쉽게 처리하기 feat.람다

Step Funtions은 서버리스로 오케스트레이션을 하기 위해 시각적 워크플로를 구축하는 방법이다. 람다 함수를 사용하고 그래프라는 것을 디자인할 수 있는데 그래프의 각 단계에서 성공/실패를 확인할 수 있고 다음에 어떻게할지 정할 수 있다.

=> AWS 내에서 복잡한 워크플로를 시작할 수 있게 도와주는 툴이다.

Step Funtions의 기능은 시퀸싱, 조건 시간 초과 확인, 오류 처리 등이 있고 람다 함수만 수행하는 것이 아니라 수 많은 AWS 서비스와 통합이 가능하다.

그리고 Step Funtions에 단계 함수때문에 특이한 기능이 존재하는데 워크플로우가 어느 단계에 이르렀을 때, 사용자에게 결과를 보여주고 '예'라고 하면 계속 진행하고 그렇지 않으면 실패하도록 할 수 있다.

=> 결론은 주문 처리나 데이터 처리, 혹은 설명하기 복잡한 모든 종류의 워크플로우를 처리할 수 있다. (일종의 그래프가 필요한 것들)

 

#8 Ground Station 🛰️- 위성과 통신하여 데이터 처리

완전 관리형 서비스인데 위성 통신을 제어하고 데이터를 처리하고 위성의 운영을 확장할 수 있는 서비스이다. 위성까지 다룰 일은 없겠지만 그 데이터에 액세스하고 싶을 때 Ground Station에서 AWS region 근처의 위성 지상국 글로벌 네트워크를 제공한다 (즉, 위성의 데이터를 클라우드로 더 쉽게 가져올 수 있다)

Ground Station로 위성데이터를 VPC로 다운로드할 수 있고 위성에서도 S3나 EC2 인스턴스로 데이터를 다운로드해서 원하는 방식으로 데이터를 처리할 수도 있다.

사용 사례에 감을 더 잡자면 일기 예보나 지표면을 이미징하는 것들에 대해 사용할 수 있다.

 

#9 Amazon PinePoint ✉️ - 사용자에게 자동으로 개인 맞춤 메세지 보내기

인바운드/아웃바운드 마케팅 커뮤니테이션 서비스로 이메일, SMS, 푸쉬 알림, 음성, 인앱 메세징을 Pinepoint를 통해 보낼 수 있다.

주요 사용 사례는 SMS, 고객은 Pinepoint를 통해 보내는 SMS를 수신하는데 각각 고객에게 적합한 콘텐츠로 메세지를 개인화(세분화)할 수 있다. => 그룹이나 세그먼트를 만들 수 있다

=> 즉 Pinepoint는 마케팅 이메일을 대량으로 보내거나 트랜잭션이 포함된 SMS 메세지를 보낼 때 유용하게 사용할 수 있다!

=> 이벤트들이 Amazon SNS, Kinesis 데이터 파이어호스, CloudWatch Logs 로 전달이 되어서 Pinepoint을 기반으로 어떤 종류의 자동화더라도 쉽게 구축할 수 있다.

 

+) Pinepoint과 Amazon SNS/SES 차이점 알아보기

일부 겹치는 기능이 있어 비슷해보이는데 조금 다르다.

Amazon SNS/SES는 우리가 스스로 직접 메세지나 콘텐츠, 스케줄을 설정하고 관리해야하는데 아무래도 작업이 조금 더증가하고 확장성면에서도 조금 떨어질 수 있다.

Pinepoint는 메세지 템플릿과 전송 스케줄, 고도로 타겟팅된 세그먼트/전체 캠페인을 만들 수 있다

=> 즉, Pinepoint는 SNS/SES의 차세대 진화 버전이라고 볼 수 있다! (마케팅 커뮤니케이션이 필요할 때 유용)