종원

2. 모의해킹 환경 및 기본구조

곰종 — Wed, 5 Nov 2025 01:50:18 +0900

vmware 환경에서 kali linux로 하기 위해 설치

https://knowledge.broadcom.com/external/article?articleNumber=368734

https://www.kali.org/get-kali/#kali-virtual-machines

Get Kali | Kali Linux

Home of Kali Linux, an Advanced Penetration Testing Linux distribution used for Penetration Testing, Ethical Hacking and network security assessments.

www.kali.org

인터넷 연결 잘 되어있음 확인

처음에 칼리를 설치하면, 한글 폰트가 없기 때문에
sudo apt update 명령어를 사용하여 업데이트 패키지를 설치(확인)하고
sudo apt install fonts-nanum -y 로 나눔 폰트를 설치

칼리 리눅스는 데비안 기반의 구조.

$ < 이건 내 홈 디렉토리에 있다는 뜻 (윈도우의 C드라이브 users)

리눅스 기본

sudo dhclient - dhcp로 자동ip가 할당이 안 될때(리눅스 인터넷이 안될 때)

후 ping www.google.com 으로 인터넷 되는지 확인

sudo apt < 패키지를 업데이트 하거나 설치할 때

apache2 start를 하고 netstat으로 보면

http (80포트) 열고 있는것을 확인 할 수 있음

내 pc(vmware외 내 윈도우)에서 칼리 리눅스의 ip에 접속하면 열려있는 포트에 접속할 수 있음

칼리에서 실행하고 있는 아파치2 서비스에 대한 것은

/var/www/html index.html 파일에서 확인할 수 있고 이에 대한 로그는

/var/log/apache2 에서 access.log에서 확인 가능

html폴더에 예를 들어 test.html 파일을 추가하면

따로 테스트페이지로 들어갈 수 있음

외부 윈도우 환경에서도 마찬가지로 접속 가능

index.html 의 내용을 바꾸면, 기본 페이지도 바뀌게 됨

FTP - 파일전송

HTTP - 웹서비스 - 80/TCP

SSH - 원격접속

Telnet - 원격접속, 파일전송

Snmp - 장비로그전송

SSH 활용

칼리 리눅스에서 SSH 포트를 열어놨고, 내 윈도우 cmd에서 ssh로 칼리리눅스 네임과, ip를 입력하면

내 원도우 cmd창에서 칼리 리눅스 환경 들어갈 수 있다 (원격)

ssh 192.168.136.128을 하면 나는 현지 rlawh<에서 접속하기 때문에 앞에 kali@를 붙여 kali로 로그인을 하여 접속

서버는 IDC나 다른 보관 공간에 있기 때문에 따로 접속pc에서 들어간다

접속PC(관리자) ---- proxy서버(접근통제) ---- ssh -> 서버 접속

proxy서버를 사용하여 접근통제를 해 로그(누가 접속을 했는가)를 기록

윈도우 cmd 환경에서도 마찬가지로 kali의 root권한 획득할 수 있다.

처음부터 root 권한으로 들어갈 수 도 있다.

하지만 처음에 들어가면 permission이 denied가 되기 때문에 kali 내부에서 루트로 접근을 할 수 있게 변경해줘야한다.

RootLogin 앞에 있는 주석을 제거

그럼 cmd환경에서 원격 접속을 할 때 바로 root로 접속이 가능하다

(하지만 이 방법은 보안상 좋지않아서 사용자로 로그인 후 sudo su - 를 통하여 권한을 변경하여 사용하는게 좋다.

FTP 서버 익명구축

vsftp 설정파일로 이동하여 vsftpd.conf를 편집

~/etc 공간에 있음

vsftpd를 편집하기 전에 칼리 리눅스 공격서버를 하나 더 만든다. (VM ware에서 칼리 전원 off한 상태에서 clone하여 똑같은 상태로 만들었음)

그 다음 ip를 확인하여 서버에 접속 할 ip를 확인
(기존에 있던 서버의 ip는 192.168.140.135)

nmap으로 21번(ftp) 포트가 열려있는것을 확인했고

ftp사용하여 원격으로 접속해보겠다.

접속자 이름은 어나니머스(익명)으로 했고 로그인에 실패하였다.

기존 서버에서 익명으로의 접근을 허용하지 않기 때문.

아까 확인했던 기존서버의 vsftp 설정파일로 이동하여 vsftpd.conf를 편집하여

익명에 대한 허용을 NO에서 YES로 바꿔준다.

그리고 다시 어나니머스로 접속을 하면

로그인에 성공을 한 것을 알 수 있다.

다시 vsftpd.conf 를 편집하여

ftp로 접속 했을 때 어나니머스 홈 디렉토리(anon_root)를 홈에있는 칼리로 기본 루트 디렉토리로 설정을 한다.

그럼 어나니머스로 ftp 접속을 하여 dir명령어를 사용하여 디렉토리들을 보면 원격 서버 칼리리눅스의 홈 디렉토리들을 볼 수 있다.

칼리리눅스의 vsftp를 익명으로 연결하여 루트 저장소를 지정하였는데

FTP 서버를 사용함으로써 사용했던 악성코드나 로그파일 등을 회수할 수 있다.

Kali DPKG 패키지 관리

()

sudo dpkg -L apache2 명령어를 사용하면 apache2를 다운로드할 때 다운받은 파일들이 어디에 있는지 다 볼 수 있다.

윈도우에 경우에도 exe파일을 실행하면 다양한 디렉토리에 다운로드가 되는데 리눅스도 마찬가지인 형태이고

/usr/share 이 윈도우의 program file이랑 비슷하며 프로그램과 관련된 파일들이 설치가 되며

/usr/sbin 이라고 하는곳이 프로그램의 실행파일들 (exe파일)이 모여있다고 볼 수 있다. (실행과 관련한 파일들도)

/etc에는 프로그램의 설정 파일들이 있다.

sudo dpkg -s vsftpd 명령어를 사용하여 패키지의 정보를 파악할 수 있다.

sudo dpkg -r vsftpd로 인스톨되어있던 파일을 전부 지울 수 있음

강제로 지워야 하는 것들은 -P옵션을 사용하여 전부 지울 수 있다.

deb파일을 직접 설치하여 다운로드 해보자

dpkg로 설치할 수 있는 파일이 deb파일이다.

nessus 라는 deb파일을 다운로드 할 건데, nessus프로그램은 취약점 분석할 때 사용하는 도구인데 미리 한번 다운로드 한

다.

리눅스-데비안 (칼리리눅스) 버전을 다운로드

다운로드를 한 뒤

홈 디렉토리에 다운로드 디렉토리를 가면 deb파일이 잘 다운로드 된 것을 볼 수 있다.

dpkg -I 명령어를 사용하여 다운로드 받은 Nessus deb파일의 정보를 알 수 있다.

패키지의 정보를 다 알 수 있다.

dpkg -i 명령어를 사용하여 다운받은 nessus를 설치한다.

다운받은 nessus 또한 dpkg -s와 dpkg -L로 정보를 볼 수 있다.

// 리눅스 기본 명령어 //

Find와 locate를 많이 사용

// locate 명령어 //

이름에 ftp가 포함되어있는 디렉토리든 파일이든 전부 보여주는 것 같다. (문자열)

1169개 카운트 된다.

locate를 통해 찾고자 하는 것들이 빠르게 나타나기 때문에 특수한 이름을 찾을 때 사용하면 좋을 것 같다.

만약 locate로 검색이 되지 않는다면

sudo updatedb로 설치된 것이나 작성된 것들이 검색할 수 있는 db에 반영되도록 업데이트를 해주면 반영이 된다.

// Find 명령어 //

퍼미션 디나이 당하는 것 은 저기에 있을것으로 추정이 되지만 읽기가 불가능하여 나온거고

"ftp"만 있는 디렉토리나 파일을 찾는다.

locate와 같이 검색하려면 "*ftp*"으로 검색하면 되겠다.

여기에 -type 옵션을 줘서 "디렉토리"만 찾고 싶은 경우에는

sudo find / -type d -name "ftp" 를 사용하여 타입이 디렉토리 인것만 찾을 수 있다.

옵션을 더 줘서 sudo find /usr/share -type d -name "ftp"를 사용하면 찾기를 원하는 경로도 추가할 수 있다.

홈 디렉토리 안에서 칼리 유저가 가지고 있는 ~~~.txt 파일만 찾을 수 있다.

그리고 수정된 날짜 기준으로 찾을 수 있는데

-mtime 으로 7일 이내의 수정된 텍스트 파일을 찾아낼 수 도 있다.

sudo find / -size +10M -name "*.txt"

으로 사이즈가 10메가바이트 이상인 텍스트 파일을 찾을 수 도 있다.

// df 명령어 //

저장소를 확인하고 싶을 때 df 명령어를 사용

sudo df -h로 human이 볼 수 있는 형태로 나타난다.

sudo df -i 로 inodes를 볼 수 있다.

inodes는 각 파일과 폴더가 가지는 ‘메타데이터 저장 공간' 으로

파일의 크기
권한 (rwx)
소유자/그룹
생성/수정 시간
파일이 저장된 블록 위치
파일 유형
하드 링크 등

이 있고 inode를 다 사용하게 된다면 디스크에 공간이 있어도 파일을 만들 수 없다. (주민번호 개념?)

보안관점에서 본다면, 침해사고가 발생 했을 때 악성코드(용량을 채워 가용성을 저하시키는)의 분석을 했을 때

특정 디렉토리의 사용량이 증가했거나 그 전보다 공간이 많이 적어지는 것을 판단할 때 df명령어를 사용

// du 명령어 //

각각의 정보 (디렉토리 등의) 크기 등의 정보를 알 수 있다

sudo du -hsc *을 이용하여 현재 디렉토리의 용량을 볼 수 있다.

h : 사람이 볼 수 있게 (k, m) 단위를 보여줌

s : 요약

c : 현재 작업 디렉토리

// ncdu 명령어 //

디스크 사용량을 확인하는 명령어 (유틸리티)

sudo ncdu를 사용하면

이런식으로 용량에 대한 목록을 볼 수 있다.

// free 명령어 //

메모리 용량들을 확인 할 수 있다

-m 을 붙여 메가바이트 단위로 출력할 수 있다.

// top 명령어 //

sudo top 명령어로 윈도우의 작업 관리자로 현재 cpu의 사용 현황 등을 볼 수 있다.

어느 프로세스에서 공격이 들어올 수 있는가, 메모리 등이 사용이 증가하는 가 등 볼 수 있다

sudo htop 으로 더 직관적으로 볼 수 있으며 sort, search등 기능을 사용할 수 있다.

aws 오답노트

곰종 — Tue, 9 Jul 2024 17:50:39 +0900

AWS X-Ray - AWS X-Ray로 마이크로서비스 아키텍처(microservices architecture)로 구축된 애플리케이션과 같은 서버리스 및 분산 애플리케이션들을 분석 및 디버그할 수 있습니다. X-Ray를 사용하면 성능 문제 및 오류의 원인을 찾고 해결하기 위해 애플리케이션과 기본 서비스가 수행되는 방식을 이해할 수 있습니다.

Amazon Pinpoint - Amazon Pinpoint는 마케팅 담당자와 개발자가 고객 중심의 참여 경험을 고객 사용 데이터를 캡처하여 실시간 통찰력을 도출함으로써 제공할 수 있습니다.

AWS Compute Optimizer는 머신 러닝을 사용하여 과거 사용률 metrics를 분석하여 Amazon EC2 인스턴스 유형, Amazon EBS 볼륨 구성 및 AWS Lambda 함수 메모리 크기와 같은 최적의 AWS 리소스 구성을 식별합니다. AWS Compute Optimizer는 선택한 유형의 EC2 인스턴스, EC2 Auto Scaling 그룹, EBS 볼륨 및 Lambda 함수에 대한 권장 사항을 제공합니다.

Virtual MFA device

전화 또는 기타 장치에서 실제 장치를 에뮬레이트하는 소프트웨어 앱입니다. 이 장치는 6자리 숫자 코드를 생성하는데, time-synchronize 된 일회용 암호 알고리즘을 기반의 숫자 코드 입니다. 사용자는 로그인 중 두 번째 웹 페이지에서 장치의 유효한 코드를 입력해야 합니다. 사용자에게 할당된 각 Virtual MFA device는 고유해야 합니다. 사용자는 인증을 위해 다른 사용자의 Virtual MFA device에서 코드를 입력할 수 없습니다.

U2F security key - 컴퓨터의 USB 포트에 연결하는 장치입니다. U2F는 개방형 인증 표준으로 FIDO Alliance에서 호스팅합니다. U2F security key를 활성화하면 수동 입력 방식 대신 인증서를 입력하고 다음 장치를 눌러 로그인합니다.

Hardware MFA device - time-synchronize된 일회용 암호 알고리즘을 기반으로 6자리 숫자 코드를 생성하는 하드웨어 장치로, 사용자는 로그인하는 동안 두 번째 웹 페이지에서 장치의 유효한 코드를 입력해야 합니다. 사용자에게 할당된 각 MFA 디바이스는 고유해야 합니다. 사용자는 인증을 받기 위해 다른 사용자의 장치에서 코드를 입력할 수 없습니다.

AWS Service Health Dashboard

AWS AWS Service Health Dashboard는 AWS가 있는 모든 리전에 대해 모든 AWS 서비스의 상태 및 가용성에 대한 최신 정보를 표 형식으로 게시합니다. 이 페이지에서 확인할 수 있습니다 https://status.aws.amazon.com/ 현재 상태 정보를 가져옵니다.

AWS AWS Service Health Dashboard는 RSS 피드를 구독하여 각 서비스에 대한 중단 알림을 받을 수 있는 가능성을 제공합니다.

Amazon SNS - Amazon Simple Notification Service(Amazon SNS)는 마이크로서비스, 분산 시스템 및 서버리스 애플리케이션을 분리할 수 있는 고가용성, 내구성, 보안, 완전 관리형 게시/구독 메시징 서비스입니다. 알림을 전달하는 데 사용할 수 있지만 현재 서비스의 상태를 제공하지 않습니다. (Cloud Watch랑 연결함 보통)

AWS Personal Health Dashboard - AWS Personal Health Dashboard는 AWS에서 사용자에게 영향을 줄 수 있는 이벤트를 경험할 때 알림 및 수정 지침을 제공합니다. 모든 AWS 서비스의 일반 상태에 대한 업데이트는 제공하지 않습니다.

AWS CloudFormation (템플릿 어쩌고~ 무조건 이거)

AWS CloudFormation은 개발자와 시스템 관리자가 관련 AWS 리소스 모음을 쉽게 생성 및 관리하여 질서정연하고 예측 가능한 방식으로 프로비저닝 및 업데이트를할 수 있도록 지원합니다.

AWS CloudFormation 샘플 템플릿 사용 또는 고유한 템플릿을 생성하여 애플리케이션을 실행하는 데 필요한 AWS 리소스 및 관련 종속성 또는 런타임 파라미터를 설명할 수 있습니다. 이를 통해 모든 리소스에 대한 단일 정보 소스를 제공하고 조직 전체에서 사용되는 인프라 구성 요소를 표준화하여 구성 규정 준수 및 문제를 빠르게 해결할 수 있습니다.

CloudFormation 템플릿을 사용하면 리소스 비용을 예측할 수 있습니다.

AWS Directory Service - AWS Managed Microsoft AD라고도 하는 Microsoft Active Directory용 AWS 디렉토리 서비스를 사용하면 디렉토리 인식 워크로드와 AWS 리소스가 AWS 클라우드의 관리 Active Directory를 사용할 수 있습니다. 리소스 배포에 사용되지 않습니다.

Amazon LightSail - Amazon Lightsail은 AWS를 사용하여 가상 개인 서버를 시작하고 관리하는데 쉬운 방법으로 설계되었습니다. 이 방법은 더 복잡한 리소스를 배포할 때는 가장 적합하지 않지만 CloudFormation은 가능합니다.

AWS CodeDeploy - AWS CodeDeploy는 온프레미스에서 실행되는 EC2 인스턴스 및 인스턴스를 포함한 모든 인스턴스의 코드 배포를 자동화하는 서비스입니다. CloudFormation과 달리 인프라 구성 및 조정은 다루지 않습니다.

AWS CodeBuild 클라우드의 완전 관리형 빌드 서비스입니다. CodeBuild 소스 코드를 컴파일하고, 단위 테스트를 실행하고, 배포할 준비가 된 아티팩트를 생성합니다. CodeBuild 자체 빌드 서버를 프로비저닝, 관리, 확장할 필요가 없습니다.

AWS Config

AWS Config는 감사 및 평가할 수 있는 서비스로, AWS 리소스의 구성을 평가합니다. Config는 AWS 리소스 구성을 지속적으로 모니터링하고 기록하며, 사용자가 원하는 구성에 대해 기록된 구성을 자동적으로 평가할 수 있도록 지원합니다.

Amazon Inspector - Amazon Inspector는 AWS에 배포된 애플리케이션의 보안 및 규정 준수를 개선하는 데 도움이 되는 자동화된 보안 평가 서비스입니다. Amazon Inspector는 노출, 취약성 및 모범 사례의 편차에 대해 애플리케이션을 자동으로 평가합니다. Amazon Inspector는 DDoS(분산 서비스 거부) 공격을 방지하는 데 사용할 수 없습니다. AWS 리소스의 상태를 제공할 수 없습니다.

Amazon CloudWatch - Amazon CloudWatch는 DevOps 엔지니어, 개발자, 사이트 안정성 엔지니어(SRE) 및 IT 관리자를 위해 구축된 모니터링 및 관찰 가능성 서비스입니다. CloudWatch는 데이터와 실행 가능한 통찰력을 제공하여 애플리케이션을 모니터링하고, 시스템 전체의 성능 변화에 대응하고, 리소스 활용도를 최적화하고, 운영 상태에 대한 통합 보기를 얻습니다. 이것은 Resilient 시스템을 구축하기 위한 훌륭한 서비스입니다. 리소스 성능 모니터링, 이벤트 및 경고를 생각하십시오. CloudWatch를 생각해 보세요. AWS 리소스의 상태를 제공할 수 없습니다.

AWS Local Zones

AWS Local Zones를 통해 더 많은 최종 사용자에게 더 가까운 위치에서 컴퓨팅 및 스토리지 서비스와 같은 AWS 서비스를 사용할 수 있습니다. 이를 통해 로컬에서 실행되는 애플리케이션에 대한 액세스의 지연 시간이 크게 단축됩니다. AWS Local Zones는 또한 Amazon의 매우 높은 대역폭의 중복 프라이빗 네트워크를 통해 상위 리전에 연결되어 AWS Local Zones에서 실행되는 애플리케이션이 나머지 AWS 서비스에 빠르고, 안전하고, 원활한 액세스를 제공합니다.

지연 시간이 짧은 요구 사항을 위해 최종 사용자에게 더 가까운 위치에 워크로드를 배포해야 하는 경우 AWS Local Zones를 사용합니다. AWS Local Zones는 인터넷 연결되어 있으며 AWS Direct Connect를 지원하므로 Local Zone에 생성된 리소스는 매우 짧은 지연 시간으로 로컬 최종 사용자에게 서비스를 제공할 수 있습니다.

AWS 엣지 로케이션(Edge Locations) - AWS 엣지 로케이션은 CloudFront가 사용자 어디에 있든 콘텐츠를 더 빠르게 전달하기 위해 콘텐츠 복사본을 캐시에 저장하는 위치입니다.

Amazon CloudFront는 .html, .css, .js 및 이미지 파일과 같은 정적 및 동적 웹 콘텐츠를 사용자에게 더 빨리 배포하도록 지원하는 웹 서비스입니다. CloudFront는 엣지 로케이션이라고 하는 데이터 센터의 전 세계 네트워크를 통해 콘텐츠를 제공합니다. CloudFront를 통해 서비스하는 콘텐츠를 사용자가 요청하면 지연 시간이 가장 낮은 엣지 로케이션으로 요청이 라우팅되므로 가능한 최고의 성능으로 콘텐츠가 제공됩니다. (비용은 요청수, 교통분포)

AWS Direct Connect - AWS Direct Connect는 인터넷을 우회하여 네트워크를 AWS에 직접 연결하는 클라우드 서비스이며, 보다 일관되고 짧은 지연 시간 성능을 제공합니다. 새 연결을 구성할 때, AWS Direct Connect Delivery Partner에서 제공하는 호스팅 연결을 선택하거나 AWS 전용 연결을 선택해서 전 세계 100개 이상의 AWS Direct Connect 지역에 배포할 수 있습니다. AWS Direct Connect는 끊김이 없이 높은 대역폭과 짧은 지연 시간 액세스를 제공하며 일반적으로 온프레미스 데이터 센터와 AWS 네트워크 간에 사용합니다. Direct Connect는 주어진 요구 사항에 비해 지나칩니다.

U2F security key - U2F(Universal 2nd Factor) 보안 키는 컴퓨터의 USB 포트에 연결할 수 있는 장치입니다. U2F는 FIDO Alliance에서 호스팅하는 개방형 인증 표준입니다. U2F security key를 활성화하면 수동으로 코드를 입력하는 대신 자격 증명을 입력한 다음 장치를 눌러 로그인합니다.

(필수)

Amazon DynamoDB는 모든 규모의 고성능 애플리케이션을 실행하도록 설계된 완전 관리형, 서버리스, 키-값 NoSQL 데이터베이스입니다. DynamoDB는 자체적인 보안, 지속적인 백업, 자동화된 다중 리전 복제, 메모리 내 캐싱 및 데이터 내보내기 도구를 제공합니다.

DynamoDB에는 스키마가 없습니다. DynamoDB는 JSON 문서를 포함해 정형(structured) 혹은 반(semi)정형 데이터를 관리할 수 있습니다.

DynamoDB 글로벌 테이블은 선택한 AWS 리전에서 데이터를 자동으로 복제하고 워크로드를 수용하기 위해 용량을 자동으로 조정합니다. 전역적으로 배포된 애플리케이션은 글로벌 테이블을 사용하여 선택한 리전에서 로컬로 데이터를 액세스할 수 있으므로 10밀리초 이내의 읽기 및 쓰기 성능을 달성할 수 있습니다. DynamoDB는 회사가 요구하는 교차 리전 액티브-액티브 구성을 지원합니다.

DynamoDB Accelerator가 있는 Amazon DynamoDB - DynamoDB Accelerator (DAX)는 완전 관리형 인메모리 캐시를 통해 대규모 테이블에 대한 빠른 읽기 성능을 제공하는 인메모리 캐시입니다. DAX를 사용하면 DynamoDB 테이블의 읽기 성능을 최대 10배까지 개선할 수 있습니다. 초당 수백만 건의 요청이 들어와도, 읽기에 필요한 시간을 밀리초에서 마이크로초로 단축할 수 있습니다. DAX는 교차 리전 액티브-액티브 구성을 지원하지 않습니다.

Amazon RedShift - Amazon Redshift는 대규모 데이터 세트 저장 및 분석을 위해 설계된 완전 관리형의 페타바이트 규모 클라우드 기반 데이터 웨어하우스 제품입니다. Amazon Redshift에는 잘 정의된 스키마가 필요합니다.

Amazon Macie - Amazon Macie는 머신 러닝 및 패턴 매칭으로 AWS에서 민감한 데이터를 검색하고 보호하는 완전 관리형 데이터 보안 및 데이터 개인 정보 보호 서비스입니다. Macie는 암호화되지 않은 버킷, 공개적으로 액세스할 수 있는 버킷 및 AWS Organizations에서 정의하지 않은 AWS 계정과 공유되는 버킷 목록을 포함하여 Amazon S3 버킷의 인벤토리를 자동으로 제공합니다. 그런 다음 Macie는 선택한 버킷에 기계 학습 및 패턴 일치 기술을 적용하여 개인 식별 정보(PII)와 같은 민감한 데이터를 식별하고 경고합니다.

AWS Glue - AWS Glue는 완전 관리형 ETL(추출, 변환 및 로드) 서비스로 고객이 분석을 위해 데이터를 쉽게 준비하고 로드할 수 있게 합니다. AWS Glue 작업은 일괄 ETL 데이터 처리에 사용됩니다. AWS에서 민감한 데이터를 검색하고 보호하는 데 사용할 수 없습니다.

Amazon Polly - Amazon Polly는 텍스트를 자연스러운 음성으로 변환하는 서비스로, 이를 통해 말하는 애플리케이션을 만들고 완전히 새로운 범주의 음성 지원 제품을 구축하는데 사용됩니다. Polly의 TTS(텍스트 음성 변환) 서비스는 고급 딥 러닝 기술을 사용하여 자연스럽게 음성을 합성합니다. AWS에서 민감한 데이터를 검색하고 보호하는 데 사용할 수 없습니다.

AWS Trusted Advisor- AWS Trusted Advisor는 비용 최적화, 보안, 내결함성(fault-tolerance), 서비스 제한 및 성능 개선에 대한 AWS 모범 사례에 따라 리소스를 프로비저닝하는 데 도움이 되는 실시간 가이드를 제공하는 온라인 툴입니다

리소스 성능 모니터링, 이벤트 및 경고들에는 언제나 CloudWatch를 사용하세요.

계정별 활동 및 감사에는, CloudTrail를 사용하시면 되고,

리소스별 변경 내역, 감사 및 규정 준수 고려에는 Config를 사용하세요.

EC2 인스턴스 최소 요금

60초 - Linux 기반 EC2 인스턴스에는 최소 1분 요금이 부과되므로 이 옵션이 올바른 옵션입니다.

최소 1분, 그다음부터는 초 단위

MarketPlace 지원하는 사용 사례

AWS 고객에게 SaaS(Software as a Service) 솔루션 판매

AWS Marketplace는 디지털 카탈로그로 AWS에서 실행되는 소프트웨어를 쉽게 찾고, 테스트하고, 구매하고, 배포할 수 있도록 해주는 독립 소프트웨어 공급업체의 수천 개의 소프트웨어 목록이 있습니다. AWS Marketplace에서는 자격을 갖춘 파트너가 AWS 고객에게 소프트웨어를 마케팅하고 판매할 수 있습니다.

AWS Marketplace는 판매자가 고객에게 소프트웨어를 제공할 수 있는 두 가지 방법은 Amazon Machine Image(AMI) 및 SaaS(Software as a Service)입니다.

AWS 고객은 AWS Marketplace 판매자가 사용자 지정 AMI로 제공한 소프트웨어를 구입할 수 있습니다.

Amazon 머신 이미지(AMI): AMI은 AWS Marketplace에 제품을 리스팅할 때 선호되는 옵션입니다. 파트너는 무료 또는 유료 제품을 선택할 수 있습니다. 파트너는 시간 또는 월 단위로 청구되는 유료 제품을 제공할 수 있습니다. BYOL(Bring Your Own License) 또한 사용 가능하며 기존 소프트웨어 라이선스가 있는 고객이 AWS로 쉽게 마이그레이션할 수 있습니다.

SaaS(Software as a Service): AWS에서 실행되는 SaaS 솔루션을 제공하고 {제품을 AMI로 구축할 수 없는 경우) SaaS 리스팅은 파트너에게 소프트웨어를 고객에게 마케팅할 수 있는 방법을 제공합니다.

(머신러닝 관련서비스) 머가 먼지만 알면될듯

Amazon Transcribe로 애플리케이션에 음성 텍스트 변환 기능을 추가할 수 있습니다. Amazon Transcribe는 딥 러닝 프로세스인 ASR(자동 음성 인식)을 사용하여 음성을 텍스트로 빠르고 정확하게 변환합니다. Amazon Transcribe로 고객 서비스 호출을 기록하고, 자막 및 자막을 자동화하고, 미디어 자산에 대한 메타데이터를 생성할 수 있습니다. (STT)

Amazon Polly로 텍스트를 생생한 음성으로 변환하여 말하는 애플리케이션을 만들 수 있습니다. Polly의 TTS(텍스트 음성 변환) 서비스는 고급 딥 러닝 기술을 사용하여 자연스러운 음성을 합성합니다.

Comprehend’라는 단어는 '(충분히)이해하다’라는 뜻을 가지고 있습니다. 그런 의미로 기계학습을 사용하여 텍스트 안에 의미를 찾아내고 통찰을 얻는 자연어 처리(NLP) 서비스입니다. 자연어 처리(NLP)란 스마트하고 유용한 방식으로 컴퓨터가 텍스트 정보를 분석하고 이해하며 의미를 도출하는 방법의 하나입니다. NLP를 활용하여 중요한 구절, 감성, 구분뿐 아니라 브랜드, 날짜, 위치 사람 등 주요 엔터티와 텍스트의 언어를 추출할 수 있습니다. 결국! 텍스트 정보를 기반으로 정보를 분석하여 주요 정보를 추출하는 과정을 지원해주는 서비스라고 생각하시면 됩니다.

Amazon Rekognition은 이미지 및 비디오에서 정보와 인사이트를 추출하기 위해 사전 훈련된 컴퓨터 비전(CV) 및 사용자 지정 가능한 CV 기능을 제공합니다.

Amazon Translate는 언어 번역에 사용되는데, 딥 러닝 모델링크 신경 기계 번역을 사용하기 때문에 기존의 통계 및 규칙 기반 번역 알고리즘보다 정확하고 자연스러운 번역을 제공합니다.

AWS OpsWorks

AWS OpsWorks는 Chef 및 Puppet의 관리형 인스턴스를 제공하는 구성 관리 서비스입니다. Chef 및 Puppet은 코드로 서버 구성을 자동화할 수 있는 자동화 플랫폼입니다. OpsWorks를 사용하면 Chef 및 Puppet을 사용하여 Amazon EC2 인스턴스 또는 온프레미스 컴퓨팅 환경에서 서버를 구성, 배포 및 관리하는 방법을 자동화할 수 있습니다.

AWS Single Sign-On(SSO)

AWS SSO는 여러 AWS 계정 및 비즈니스 애플리케이션에 대한 액세스를 중앙에서 관리하기 쉽고 사용자가 한 곳에서 할당된 모든 계정 및 애플리케이션에 대한 Single Sign-On 액세스를 제공 해주는 AWS 서비스입니다.

AWS SSO는 SSO 엑세스와 모든 AWS 기관 계정에 관한 권한을 중앙에서 쉽게 관리할 수 있습니다. AWS SSO는 SSO ID 저장소에서 사용자 ID 관리 및 생성을 가능하게 하며, 이미 존재하고 있는 ID 소스를 Microsoft Active Directory, Azure Active Directory (Azure AD), and Okta Universal Directory에서 연결할 수 있습니다.

AWS SSO로 중앙에서 여러 AWS 계정, SAML 지원 클라우드 애플리케이션(예: Salesforce, Office 365, Box) 및 맞춤형 사내 애플리케이션에 대한 직원의 액세스 권한을 빠르고 쉽게 할당 및 관리를 할 수 있습니다.

AWS Cognito(코그니토) - Amazon Cognito를 사용하면 웹 및 모바일 앱에 쉽고 빠르게 사용자 등록, 로그인 및 액세스 제어를 추가할 수 있습니다. Amazon Cognito를 사용하면 Facebook, Twitter 또는 Amazon과 같은 소셜 ID 공급자를 통해 SAML ID 솔루션을 사용하거나 자체 ID 시스템링크 사용자 인증도 할 수 있습니다. 고객을 위해 B2C 또는 B2B 앱을 구축하는 고객/개발자를 위한 ID 관리 솔루션입니다.

EC2 인스턴스와 온프레미스 서버 모두에 CloudWatch Logs 사용

Amazon CloudWatch Logs로 Amazon Elastic Compute Cloud(Amazon EC2) 인스턴스, AWS CloudTrail, Route 53 및 온프레미스 서버와 같은 기타 소스에서 로그 파일을 모니터링, 저장 및 액세스할 수 있습니다.

CloudWatch Logs는 높은 확장성으로 단일 서비스의 모든 시스템, 애플리케이션 및 AWS 서비스의 로그를 중앙 집중화할 수 있습니다. 그런 쉽게 보고, 특정 오류 코드 또는 패턴을 검색하고, 특정 필드를 기반으로 필터링하거나, 향후 분석을 위해 안전하게 보관할 수 있습니다.

AWS Systems Manager Session Manager

AWS SSM Session Manager는 완전 관리형 서비스로 대화형 브라우저 기반 셸 및 CLI를 지원합니다. 인바운드 포트를 열거나, 배스천 호스트를 유지 관리하거나, SSH 키를 관리할 필요 없이 안전하고 감사 가능한 인스턴스 관리 기능을 제공합니다. Session Manager를 통해 인스턴스에 대한 액세스 제어, 보안 강화 및 감사 가능한 액세스 제공 등 기업 정책 규정을 손쉽게 준수할 수 있습니다. 동시에 최종 사용자에게 간단한 교차 플랫폼 액세스를 제공합니다.

AWS Quick Starts references

Quick Start는 AWS 솔루션 설계자와 파트너가 보안 및 고가용성을 위한 AWS 모범 사례를 기반으로 AWS에서 인기 있는 기술을 배포할 수 있도록 구축하였습니다. 이러한 액셀러레이터는 수백 개의 수동 절차를 단 몇 단계로 줄여 프로덕션 환경을 신속하게 구축하고 바로 사용할 수 있도록 하였습니다.

각 Quick Start의 가이드에는 구축을 자동화하는 AWS CloudFormation 템플릿과 아키텍처를 설명하고 단계별 구축 지침을 제공합니다.

AWS Forums - AWS Forums은 AWS 커뮤니티 플랫폼으로 사람들이 서로를 도울 수 있는 플랫폼입니다. AWS의 기술 배포에 사용되지 않습니다.

AWS Whitepapers - AWS Whitepapers는 AWS와 AWS 커뮤니티에서 작성한 기술 콘텐츠로 클라우드에 대한 지식을 확장하기 위한 백서입니다. AWS Whitepapers에는 기술 백서, 기술 가이드, 참조 자료 및 참조 아키텍처 다이어그램이 포함됩니다. 배포에 유용한 콘텐츠를 찾을 수는 있지만 기술 배포로 하는 서비스는 아닙니다.

Amazon 머신 이미지(AMI)는 인스턴스를 시작하는 데 필요한 정보를 제공합니다. 인스턴스를 시작할 때 AMI를 지정해야 합니다. 동일한 구성의 여러 인스턴스가 필요한 경우 단일 AMI에서 여러 인스턴스를 시작할 수 있습니다.

AMI는 시작할 EC2 인스턴스와 동일한 리전은 필수 입니다. AMI가 다른 리전에 있는 경우 해당 AMI를 EC2 인스턴스를 시작하려는 리전에 복사할 수 있습니다. AMI 지역은 EC2 인스턴스의 성능과 관련이 없습니다.

AWS Fargate

AWS Fargate는 Amazon Elastic Container Service(ECS) 및 Amazon Elastic Kubernetes Service(EKS)와 함께 작동하는 컨테이너용 서버리스 컴퓨팅 엔진입니다. Fargate를 사용하면 애플리케이션 구축에 집중할 수 있습니다. Fargate를 사용하면 서버를 프로비저닝하고 관리할 필요가 없고, 애플리케이션별로 리소스를 지정하고 비용을 지불할 수 있으며, 설계에 따른 애플리케이션 격리를 통해 보안이 향상됩니다.

AWS Elastic Beanstalk - AWS Elastic Beanstalk는 웹 애플리케이션 및 서비스를 배포하고 확장하기 위한 사용하기 쉬운 서비스입니다. 코드를 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 자동 크기 조정에서 애플리케이션 상태 모니터링에 이르기까지 배포를 자동으로 처리합니다. Beanstalk는 서버를 프로비저닝하므로 서버리스 서비스가 아닙니다.

Amazon SageMaker - Amazon SageMaker는 모든 개발자와 데이터 과학자에게 기계 학습(ML) 모델을 빠르게 구축, 교육 및 배포할 수 있는 기능을 제공하는 완전 관리형 서비스입니다. SageMaker는 기계 학습 프로세스의 각 단계에서 무거운 작업을 제거하여 고품질 모델을 더 쉽게 개발할 수 있도록 합니다.

AWS Systems Manager

AWS Systems Manager를 사용하면 여러 AWS 서비스의 운영 데이터를 중앙 집중화하고 전체 AWS 리소스에서 작업을 자동화할 수 있습니다. 애플리케이션, 애플리케이션 스택의 다양한 계층 또는 운영 및 개발 환경과 같은 논리적 리소스 그룹을 생성할 수 있습니다.

Systems Manager로 리소스 그룹을 선택하고 리소스 그룹의 최근 API 활동, 리소스 구성 변경 사항, 관련 알림, 작동 경고, 소프트웨어 인벤토리 및 패치 규정 준수 상태를 볼 수 있습니다. 운영상의 필요에 따라 각 리소스 그룹에 대해 작업을 수행할 수도 있습니다. Systems Manager는 AWS 리소스를 중앙에서 보고 관리할 수 있는 공간을 제공하므로 작업을 완벽하게 파악하고 제어할 수 있습니다.

EBS - Amazon Elastic Block Store(EBS)는 사용하기 쉬운 고성능 블록 스토리지 서비스로 모든 규모의 처리량 및 트랜잭션 집약적 워크로드에 대해 Amazon Elastic Compute Cloud(EC2)와 함께 사용하도록 설계되었습니다. 관계형 및 비관계형 데이터베이스, 엔터프라이즈 애플리케이션, 컨테이너화된 애플리케이션, 빅 데이터 분석 엔진, 파일 시스템 및 미디어 워크플로와 같은 광범위한 워크로드가 Amazon EBS에 널리 배포됩니다.

인스턴스 스토어 - 인스턴스 스토어는 EC2 인스턴스를 위한 임시 블록 레벨 스토리지를 제공합니다. 이 저장소는 호스트 컴퓨터에 물리적으로 연결된 디스크에 위치해 있습니다. 인스턴스 저장소는 버퍼, 캐시, 스크래치 데이터 및 기타 임시 콘텐츠와 같이 자주 변경되는 정보의 임시 저장소 또는 웹 서버의 로드 밸런싱된 풀과 같이 인스턴스 집합 전체에 복제되는 데이터에 적합합니다. 인스턴스 스토리지는 일시적이며 인스턴스에 장애가 발생 또는 종료시 데이터 손실이 일어납니다. EC2 인스턴스 스토어는 인스턴스 간 파일 공유에 사용할 수 없습니다.

읽기 전용 복제본을 사용한 데이터베이스 확장성 향상

Amazon Relational Database Service(Amazon RDS)는 클라우드에서 관계형 데이터베이스를 쉽게 설정, 운영 및 확장할 수 있습니다. 읽기 전용 복제본링크 마스터 데이터베이스와 동기화, 읽기 전용 복사본을 생성할 수 있습니다. 읽기 전용 복제본은 읽기 성능 향상 시킵니다. 성능 향상에는 사용자와 더 가까운 다른 AWS 리전에 읽기 전용 복제본을 배치할 수도 있습니다. 읽기 전용 복제본은 리소스의 수평 확장의 예입니다.

엔터프라이즈 (Enterprise) surpport

AWS는 개발자, 비즈니스 및 엔터프라이즈 지원 플랜 이렇게 세 가지 지원 플랜 제공함으로서 각 고객을 만족시킵니다. 모든 AWS 고객을 위한 기본 지원 플랜이 포함되어 있습니다.

AWS Enterprise Support는 고객이 클라우드에서 성과를 달성하고 성공을 찾는것을 목적인 둔 컨시어지와 같은 서비스를 고객에게 제공합니다. 엔터프라이즈 지원링크 자습형 실습을 통한 온라인 교육, 고품질 엔지니어의 연중무휴 기술 지원, 환경 상태를 자동으로 관리하는 툴 및 기술, 컨설팅 아키텍처 지침, 지정된 TAM(기술 계정 관리자) 사전 예방적/예방적 프로그램 및 AWS 주제 전문가에 대한 액세스를 조정합니다.

Basic (기본) - 모든 AWS 고객을 위한 기본 지원 플랜이 포함되어 있습니다.

이 세 가지 지원 계획 중 어느 것도 자기 주도형 실습을 통한 온라인 교육에 대한 액세스를 제공하지 않습니다.

사업 - AWS에서 비지니스 지원을 권장하는 경우는 프로덕션 워크로드가 있고 특정 사용 사례의 맥락에서 기술 지원 및 아키텍처 지침에 24x7 액세스를 원하는 경우입니다.

개발자 - AWS는 AWS에서 개발자 지원을 권하는 경우는 테스트하거나 초기 개발을 수행 중이고 업무 시간 동안 기술 지원을 받고 빌드 및 테스트할 때 일반적인 아키텍처 지침을 받을 수 있는 기능을 원하는 경우입니다.

AWS Cost Explorer - 비용탐색기 ( 이미 발생한 비용에 대한 시각화 )

AWS Cost Explorer에는 시간 경과에 따른 AWS 비용 및 사용량을 시각화, 이해 및 관리할 수 있는 사용하기 쉬운 인터페이스가 있습니다. AWS Cost Explorer에는 비용이 많이 발생하는 상위 5개 AWS 서비스와 관련된 비용 및 사용량을 시각화하는 데 도움이 되는 기본 보고서가 포함되어 있으며 테이블 보기에서 모든 서비스에 대한 자세한 분석을 제공합니다. 보고서를 사용하면 시간 범위를 조정하여 비용 추세를 이해하기 위해 최대 12개월까지의 과거 데이터를 볼 수 있습니다. 또한 AWS Cost Explorer는 예측을 지원하여 미래에 비용과 사용량이 어떻게 보일지 더 잘 파악하여 계획할 수 있습니다.

AWS Budgets - AWS Budgets은 비용이나 사용량이 예산 금액을 초과할 때(또는 초과할 것으로 예상되는 경우) 알림을 제공하는 사용자 지정 예산을 설정할 수 있는 기능을 제공합니다. 또한 AWS Budgets을 사용하여 예약 사용률 또는 적용 범위 목표를 설정하고 사용률이 정의한 임계값 아래로 떨어지면 알림을 받을 수 있습니다. 예산은 월별, 분기별 또는 연간 수준으로 생성할 수 있으며 시작 및 종료 날짜를 사용자 지정할 수 있습니다. 예산을 더욱 세분화하여 AWS 서비스, 연결 계정, 태그 등과 같은 여러 차원과 관련된 비용을 추적할 수 있습니다. AWS Budgets은 AWS 계정 비용 및 사용량을 예측할 수 없습니다.

AWS Cost and Usage

Reports - AWS Cost and Usage Reports (AWS CUR)에는 사용 가능한 가장 포괄적인 비용 및 사용 데이터 세트가 포함되어 있습니다. 비용 및 사용 보고서로 소유한 Amazon Simple Storage Service(Amazon S3) 버킷에 AWS 결제 보고서를 게시할 수 있습니다. 시간 또는 월, 제품 또는 제품 리소스 또는 직접 정의한 태그별로 비용을 분류하는 보고서를 받을 수 있습니다. AWS는 쉼표로 구분된 값(CSV) 형식으로 하루에 한 번 버킷의 보고서를 업데이트합니다. AWS Cost and Usage Reports는 AWS 계정 비용 및 사용을 예측할 수 없습니다.

AWS Simple Monthly Calculator - Simple Monthly Calculator는 귀하가 제공한 특정 정보를 기반으로 AWS 서비스에 대한 예상 사용 요금을 제공합니다. 고객과 잠재 고객이 월별 AWS 청구서를 보다 효율적으로 추정하는 데 도움이 됩니다. Simple Monthly Calculator는 AWS 계정 비용 및 사용량을 예측할 수 없습니다.

AWS Pricing Calculator - 비용계산기 (앞으로 솔루션을 구축하기 위한 견적)

AWS Pricing Calculator는 사용 사례를 기반으로 AWS 서비스를 탐색하고 견적을 생성할 수 있습니다. 솔루션을 구축하기 전에 솔루션을 모델링하고 추정을 바탕으로 가격대 및 계산을 탐색하고 필요에 맞는 사용 가능한 인스턴스 유형 및 계약 조건을 찾을 수 있습니다. 이를 통해 AWS 사용에 대해 합리적인 결정을 내릴 수 있습니다. 새로운 인스턴스 및 서비스 세트를 설정하여 AWS 비용 및 사용량을 계획하거나 가격을 책정할 수 있습니다. AWS Pricing Calculator는 https://calculator.aws/#/에서 액세스할 수 있습니다.

AWS는 마이그레이션 평가기(전 TSO Logic)라는 무료 서비스를 제공합니다. 데이터를 기반으로 AWS 클라우드 계획 및 마이그레이션에 대한 비즈니스 사례를 구축할 수 있습니다.

TCO Calculator는 AWS의 비용을 온프레미스(On-premise) 인프라 또는 다른 클라우드 제공자와 비교하여 요금을 추정하는 도구이다.

이 도구를 사용하면 AWS로의 이전에 따른 전체 소유 비용을 예측할 수 있다

운영 탁월성

AWS Well-Architected 프레임워크는 AWS에서 시스템을 구축 중 내리는 결정들의 장단점을 이해하는 데 도움이 됩니다. 프레임워크로 클라우드를 통해 안정, 안전, 효율, 비용-효율을 두루 갖춘 시스템을 설계 운영을 위한 아키텍처 모범 사례를 배우게 됩니다. 모범 사례에 따라 아키텍처의 일괄적으로 측정 및 개선 영역을 식별할 수 있는 방법을 제공합니다.

AWS Well-Architected 프레임워크는 5가지 기둥을 기반으로 합니다. - 운영 우수성, 보안, 안정성, 성능 효율성 및 비용 최적화

운영 탁월성 기둥은 비즈니스 가치를 제공하고 지원 프로세스 및 절차의 지속적인 개선을 위해 시스템 실행 및 모니터링 기능이 포함됩니다. 클라우드에서는 애플리케이션 코드에 사용과 동일한 엔지니어링 원칙을 전체 환경에 적용할 수 있습니다. 전체 워크로드(애플리케이션, 인프라)를 코드로 정의 및 업데이트가 가능 합니다. 작업 절차 코드화와 이벤트 응답 트리거로 실행 자동화를 구현 할 수 있습니다.

오답:

비용 최적화 - 비용 최적화는 불필요한 비용 방지에 중점을 둡니다. 주요 주제로는 비용 사용 유형 이해 및 제어와 가장 적절하고 적절한 수의 리소스 유형 선택, 사용 시간에 따른 지출 분석, 초과 지출 없는 비즈니스 요구 확장을 포함합니다.

성능 효율성 - 성능 효율성 기둥은 IT 및 컴퓨팅 리소스의 효율 사용 여부에 중점을 둡니다. 주요 주제로는 워크로드 요구 사항에 따른 적합한 리소스 유형 및 크기 선택, 성능 모니터링, 비즈니스 요구 사항 발전에 따른 효율성 유지 정보에 따른 결정을 포함합니다.

보안 - 보안 기둥은 정보 및 시스템 보호에 중점을 둡니다. 주요 주제에는 데이터의 기밀성 및 무결성, 권한 관리를 통한 권한 부여 대상 및 방법 결정 식별 및 관리, 시스템 보호, 보안 이벤트 감지를 위한 제어 설정을 포함합니다.

AWS CodeDeploy

AWS CodeDeploy는 Amazon EC2 인스턴스 및 on-premises에서 실행되는 인스턴스를 포함한 모든 인스턴스의 코드 배포 자동화 서비스입니다. AWS CodeDeploy는 새로운 기능을 더 쉽고 신속하게 출시하고 배포 중 다운타임을 방지하고 애플리케이션 복잡한 업데이트 작업 처리가 가능 합니다. AWS CodeDeploy를 사용한 배포 자동화를 통해 오류 발생 여지가 있는 수동 작업이 필요하지 않으며 서비스는 인프라에 따라 확장되므로 하나 또는 수천 개의 인스턴스에 쉽게 배포할 수 있습니다.

오답:

AWS CodeCommit - AWS CodeCommit은 보안 Git 기반 리포지토리를 호스팅하는 관리형 소스 제어 서비스입니다. 이 서비스는 팀이 안전하고 확장성이 뛰어난 에코시스템에서 코드에 관련하여 더 쉽게 협업할 수 있도록 합니다. CodeCommit로는 자체 소스 제어 시스템 운영이나 인프라 확장에는 문제가 없이 해결 할 수 있습니다. 코드 배포를 자동화하는 데 사용할 수 없습니다.

AWS CodePipeline - AWS CodePipeline은 지속 제공이 가능한 서비로, 소프트웨어 릴리스에 필요한 단계를 모델링, 시각화 및 자동화 서비스를 제공합니다. AWS CodePipeline는 코드 빌드, 사전 프로덕션 환경에 배포, 애플리케이션 테스트 및 프로덕션 릴리스를 위한 전체 릴리스 프로세스를 모델링할 수 있습니다.

AWS CloudHSM

AWS CloudHSM은 AWS 클라우드 안에서 암호화 키를 쉽게 생성하고 사용할 수 있게 해주는 클라우드 기반 HSM(하드웨어 보안 모듈)입니다. CloudHSM는 FIPS 140-2 레벨 3 검증 HSM을 사용하여 암호화 키를 관리합니다. 하드웨어 프로비저닝, 소프트웨어 패치, 고가용성 및 백업과 같이 시간이 많이 소요되는 관리 작업을 자동화하는 완전 관리형 서비스입니다.

AWS Secrets Manager - AWS Secrets Manager는 애플리케이션, 서비스 및 IT 리소스에 액세스하는 데 필요한 보안 기밀을 보호합니다.. 이 서비스를 사용하면 수명 주기 동안 데이터베이스 자격 증명, API 키 및 기타 기밀을 쉽게 교체, 관리 및 검색할 수 있습니다. 사용자와 애플리케이션은 Secrets Manager API를 호출하여 기밀을 검색하므로 민감한 정보를 일반 텍스트로 하드코딩할 필요가 없습니다. Secrets Manager는 AWS 클라우드에서 데이터 암호화 작업을 위한 하드웨어 보안 모듈로 사용할 수 없습니다.

VPC 피어링

VPC 피어링 연결은 두 VPC 간에 트래픽을 비공개로 라우팅할 수 있도록 두 VPC사이를 잇는 네트워크 연결입니다. 이를 통해 두 VPC의 인스턴스는 마치 동일한 네트워크 내에 있는 것처럼 서로 통신할 수 있습니다. 이 VPC 피어링 연결은 같은 AWS 계정의 VPC끼리뿐만 아니라 다른 AWS 계정의 VPC나 AWS 리전의 VPC와도 생성할 수 있습니다.

Site to Site VPN - AWS Site-to-Site VPN은 데이터 센터 또는 지사와 AWS 클라우드 리소스 간에 안전한 연결을 생성합니다. 이 연결은 퍼블릭 인터넷을 통해 이루어집니다. Site to Site VPN은 VPC를 상호 연결하는 데 사용할 수 없습니다.

AWS 다이렉트 커넥트 - AWS 다이렉트 커넥트는 원격 네트워크와 VPC 사이의 전용 프라이빗 연결을 생성합니다. 이 연결은 비공개 연결이며 퍼블릭 인터넷을 사용하지 않습니다. 이 연결은 설정하는 데 최소 한 달이 걸립니다. 다이렉트 커넥트는 VPC를 상호 연결하는 데 사용할 수 없습니다.

VPC 엔드포인트 - VPC 엔드포인트를 사용하면 인터넷 게이트웨이, NAT 장치, VPN 연결 또는 AWS 다이렉트 커넥트 연결 없이도 VPC를 VPC 엔드포인트가 지원되는 AWS 서비스 및 AWS PrivateLink기반의 VPC 엔드포인트 서비스에 비공개로 연결할 수 있습니다. VPC 엔드포인트를 사용하여 두 개의 VPC를 연결할 수는 없습니다. (VPC도 한 3문제?)

Network Load Balancer - Network Load Balancer는 극한의 성능이 요구되는 TCP(Transmission Control Protocol), UDP(User Datagram Protocol) 및 TLS(Transport Layer Security) 트래픽의 로드 밸런싱에 가장 적합합니다. 트래픽을 분산하고 리소스를 확장하지 않습니다.

Application Load Balancer - Application Load Balancer는 클라이언트의 단일 연락 창구 역할을 합니다. 로드 밸런서는 수신 애플리케이션 트래픽을 여러 가용 영역의 EC2 인스턴스와 같은 여러 대상에 분산합니다. 트래픽을 분산하고 리소스를 확장하지 않습니다.

Amazon S3 Glacier - Amazon S3 Glacier(S3 Glacier)는 자주 사용하지 않는 데이터 또는 "콜드 데이터"에 최적화된 스토리지 서비스입니다. S3 Glacier에 저장된 저장 데이터는 AWS에서 유지 관리하는 키로써 256비트 고급 암호화 표준(AES-256)으로 서버 측에서 자동으로 암호화됩니다.

AWS Storage Gateway - AWS Storage Gateway는 사실상 무제한의 클라우드 스토리지에 대한 온프레미스 액세스를 제공하는 하이브리드 클라우드 스토리지 서비스입니다. 게이트웨이와 AWS 스토리지 간에 전송되는 모든 데이터는 SSL을 사용하여 암호화됩니다 (파일, 볼륨 및 테이프 게이트웨이의 세 가지 유형의 게이트웨이 모두). (진짜 많이나옴보기)

APN 컨설팅 파트너

AWS 파트너 네트워크(APN)는 글로벌 파트너 프로그램으로, Amazon Web Services를 활용하여 고객을 위한 솔루션과 서비스를 구축하는 기술 및 컨설팅 비즈니스 입니다.

APN 컨설팅 파트너는 또한 모든 유형과 규모의 고객이 AWS에서 워크로드와 애플리케이션을 설계, 건축, 구축, 마이그레이션 및 관리하여 AWS 클라우드로의 마이그레이션을 가속화할 수 있도록 지원하는 전문 서비스 펌(firm)입니다.

APN 기술 파트너 - APN 기술 파트너는 AWS 클라우드 안에서 호스팅되거나 AWS 클라우드와 통합되는 하드웨어, 연결 서비스 또는 소프트웨어 솔루션을 제공합니다. APN 기술 파트너는 AWS로 마이그레이션하고 AWS 클라우드에서 애플리케이션을 관리하지 않습니다.

컨시어지 지원팀 - 컨시어지 지원 팀은 AWS 결제 및 계정 전문가로 엔터프라이즈 계정 작업을 전문으로 지원합니다. 청구 및 계정 문의를 빠르고 효율적으로 해결해 드립니다. 컨시어지 지원 팀은 엔터프라이즈 지원 플랜에만 사용할 수 있습니다. 컨시어지 지원 팀은 AWS로 마이그레이션하고 AWS 클라우드에서 애플리케이션을 관리하는 데 도움을 줄 수 없습니다.

침투 테스트

AWS 고객은 AWS 인프라에 대해 보안 평가 또는 침투 테스트를 몇 가지 일반적인 AWS 서비스에 대한 사전 승인 없이 수행할 수 있습니다. 고객은 AWS 인프라 또는 AWS 서비스 자체에 대한 보안 평가를 수행할 수 없습니다.

네트워크 스트레스 테스트 - AWS는 특정 의도된 대상 애플리케이션에 대량의 합법적 또는 테스트 트래픽을 보내는 경우 "네트워크 스트레스 테스트"로 간주합니다. 엔드포인트와 인프라는 이 트래픽을 처리할 수 있을 것으로 예상됩니다.

다음 AWS 서비스 중 AWS 클라우드에서 Well-Architected 프레임워크의 안정성 Pillar에 대한 AWS Foundation 서비스의 일부는 무엇일까요? (2개 선택)

AWS Trusted Advisor(걍 보기로 개많이나옴)

AWS 서비스 할당량( AWS Service Quotas )

기초는 AWS Well-Architected 프레임워크의 안정성 기둥의 일부입니다. AWS는 시스템을 설계하기 전에 안정성에 영향을 미치는 기본 요구 사항을 마련해야 한다고 말합니다. 기반의 일부인 서비스는 Amazon VPC, AWS Trusted Advisor, AWS 서비스 할당량(이전에는 AWS 서비스 제한이라고 함)입니다.

AWS Trusted Advisor- AWS Trusted Advisor는 비용 최적화, 보안, 내결함성(fault-tolerance), 서비스 제한 및 성능 개선에 대한 AWS 모범 사례에 따라 리소스를 프로비저닝하는 데 도움이 되는 실시간 가이드를 제공하는 온라인 툴입니다. 새로운 workflow 설정, 애플리케이션 개발 또는 지속적인 개선의 일환으로 Trusted Advisor가 정기적으로 제공하는 권장 사항링크 솔루션을 최적으로 프로비저닝할 수 있습니다. 모든 AWS 고객은 AWS 환경의 보안과 성능을 높이는 데 도움이 되는 7가지 핵심 Trusted Advisor 검사에 액세스할 수 있습니다. Trusted Advisor는 AWS로 마이그레이션하고 AWS 클라우드에서 애플리케이션을 관리하는 데 사용할 수 없습니다.

서비스 할당량은 중앙에서 AWS 서비스 할당량을 보고 관리할 수 있습니다. AWS에서 제한이라고도 불리는 할당량은 AWS 계정의 리소스, 작업 및 항목의 최대값입니다. 각 AWS 서비스는 할당량을 정의하고 해당 할당량의 기본값을 설정합니다.

"EFS" - Amazon EFS는 Amazon EC2와 함께 사용을 위한 파일 스토리지 서비스입니다. Amazon EFS는 최대 수천 개의 Amazon EC2 인스턴스에 대해 파일 시스템 인터페이스, 파일 시스템 액세스 의미 체계 및 동시에 액세스 가능한 스토리지를 제공합니다. Amazon EFS는 네트워크 파일 시스템 프로토콜을 사용합니다.

Beanstalk

웹 애플리케이션 및 서비스를 배포하고 확장할 수 있는 PaaS(Platform as a Service)입니다.

AWS Elastic Beanstalk를 사용하면 개발자가 AWS 클라우드에서 애플리케이션을 더욱 쉽게 배포하고 관리할 수 있습니다. 개발자가 애플리케이션을 업로드하기만 하면 Elastic Beanstalk가 용량 프로비저닝, 로드 밸런싱, 자동 크기 조정 및 애플리케이션 상태 모니터링의 배포 세부 정보를 자동으로 처리합니다.

애플리케이션과 데이터만 관리하는 서비스로서의 플랫폼입니다.

Amazon Neptune은 자격 증명 그래프, 지식 그래프 및 사기 탐지와 같은 그래프 사용 사례를 지원하는 빠른 완전관리형 데이터베이스 서비스입니다

AWS Server Migration Service를 이용하여 On-premis 서버를 더 쉽고 빠르게 AWS로 마이그레이션 할 수 있다. 즉, 실제 서버에 있는 가상 머신(VM)들을 AWS의 EC2로 전환하는 서비스다.

Amazon Athena는 표준 SQL을 사용해 Amazon S3에 저장된 데이터를 간편하게 분석할 수 있는 대화식 쿼리 서비스입니다. Athena는 서버리스 서비스이므로 관리할 인프라가 없으며 실행한 쿼리에 대해서만 비용을 지불하면 됩니

Amazon EMR이란 무엇입니까? Amazon EMR은 Apache Spark, Apache Hive 및 Presto와 같은 오픈 소스 프레임워크를 사용하여 데이터 처리, 대화식 분석 및 기계 학습을 위한 업계 최고의 클라우드 빅 데이터 플랫폼입니다.

Amazon Connect는 챗봇, 작업 라우팅, 대화형 음성 응답 등 완전히 통합된 셀프 서비스 기능을 통해 고객 여정의 모든 단계에서 지능적인 자동화를 지원

AWS Artifact란 무엇입니까? AWS Artifact는 콘솔에서 사용할 수 있으며, 고객에게 AWS의 규정 준수 문서와 AWS 계약에 대한 온디맨드 액세스를 제공하는 셀프서비스 감사 아티팩트 검색 포털입니다.

무료제공 - (보안) : aws게시판, aws보안블로그

다음 AWS 지원 플랜 중 7가지 핵심 AWS Trusted Advisor 검사에만 액세스할 수 있는 플랜은 무엇입니까?

B. 기본 및 개발자 지원

Amazon GuardDuty는 AWS 계정 및 워크로드에서 악의적 활동을 모니터링하고 상세한 보안 조사 결과를 제공하여 가시성 및 해결을 촉진하는 위협 탐지 서비스입니다.

Amazon Macie란? Amazon Macie는 기계 학습 및 패턴 일치를 사용하여 AWS 환경에서 민감한 데이터를 검색, 모니터링 및 보호하는 완전 관리형 데이터 보안 및 데이터 개인 정보 보호 서비스입니다

서비스중 서버리스 서비스가 뭔지? 5개중 2

보안 인스펙터 아티팩터

대부분 aws가 온프라미스에서 "어떤"형태를 마이그레이션하려고한다, 어떤 서비스를 사용해야하냐?

AWS dump

곰종 — Tue, 9 Jul 2024 00:18:47 +0900

틀린문제

2 (31/19)

B, C

B E

E는맞음

연습시험 3 (31/19)

연습시험 4 (28/22)

연습시험 5 (33/17)

AWS CCP 자격증 - 12 (클라우드 모니터링)

곰종 — Sun, 7 Jul 2024 22:37:36 +0900

CloudWatch

먼저 CloudWatch의 지표 제공 서비스를 살펴보도록 하겠습니다

CloudWatch는 AWS 내 모든 서비스에 대한 지표를 제공하며 이때 지표는 모니터링 대상이 되는 변수입니다.

예로는 CPUUtilization나 NetworkIn 등이 있죠 지표는 시간에 대한 내용을 포함하므로 타임스탬프를 갖습니다.

모든 지표를 한 번에 시각화할 수 있도록

CloudWatch 지표 대시보드를 생성할 수도 있습니다.

EC2 인스턴스에 대해서는 CPUUtilization이 있는데 이는 CPU가 현재 얼마나 사용되고 있으며

사용량이 늘어나면 인스턴스의 작업량이 과도하게 늘기 때문에

이때는 스케일 업이나 아웃이 필요하다는 판단을 할 수도 있습니다.

StatusCheck은 EC2 인스턴스가 제대로 작동하는지 확인하는 지표이며

Network는 얼마나 많은 네트워크가 인스턴스 안팎에서 실행되고 있는지를 살펴보는 지표입니다.

그리고 화면에 나와 있듯 RAM은 EC2 인스턴스에 적합한 지표가 되지 못합니다

앞서 말한 지표는 5분마다 제공되지만 더 비싼 옵션인 Detailed Monitoring을 활성화하여 1분마다 해당 지표를 제공받을 수도 있습니다

다음은 데이터를 저장하는 EBS 볼륨에 대한 지표를 볼 텐데

Disk Read/Writes로 디스크에 읽고 쓰는 정보를 알 수 있습니다

다음으로 S3 버킷 관련 지표로는 BucketSizeBytes NumberOfObjects 그리고 AllRequests 등 S3 버킷에 대한 요청 수를 알 수 있고

과금 관련 지표는 앞서 봤던 Total Estimated Charge로 us-east-1 리전에서만 지원하지만

사용자 전체 계정의 과금 내역을 볼 수 있습니다

다음으로는 서비스 한도에 관한 지표로 서비스 API 사용량을 볼 수 있습니다

끝으로 원하는 지표를 찾지 못한 경우 사용자 지정 지표를 생성할 수도 있습니다.

CloudWatch 경보는 지표에 대한 알림을 트리거 할 때에 사용됩니다.

즉 지표가 임계값을 넘어서면 CloudWatch 경보가 실행된다는 겁니다

이와 같은 경보로는 먼저 오토 스케일링 그룹이 희망하는 EC2 인스턴스의 수를 늘리거나 줄여서

자동 스케일링이 가능하도록 하는 오토 스케일링 작업과 EC2 인스턴스를 중지, 종료 재시작 또는 복구하는 EC2 작업그리고 SNS 주제에 대해 알림을 보내는 SNS 알림 작업이 있습니다

예를 들어서 EC2 인스턴스의 사용률이 90%가 넘을 경우 문제가 발생했는지 살펴볼 수 있도록 이메일로 알려 달라고 설정할 수 있겠죠

이 외에도 다양한 옵션이 있습니다 경보 생성이나 샘플링, % 표시 최대, 최솟값 등을 설정할 수 있고

경보를 평가할 기간을 정할 수도 있죠 5분, 10분, 1시간 등으로 말입니다.

끝으로 CloudWatch 과금 지표를 이용하여 과금 경보를 생성할 수 있습니다

지표에 대한 과금이 10달러나 20달러를 넘을 경우 알림을 받도록 설정할 수 있습니다.

아무 문제 없는 그린일 경우의 경보 상태는 OK,

그린인지 불량인지를 확인할 데이터 포인트가 충분하지 않은 경우는 INSUFFICIENT_DATA

불량한 경우는 ALARM이 뜹니다

Amazon CloudWatch Logs

이름에서 알 수 있듯 CloudWatch Logs는 로그 파일을 수집합니다

그럼 로그 파일이란 무엇일까요? 어느 서버든 간에 실행되는 애플리케이션에 대해 작업 내역에 대한 기록을 시킬 겁니다.

사용자에 대한 작업을 수행하거나 정리 등을 수행할 때에 말이죠 수집된 모든 로그 파일은 사용자가 트러블 슈팅을 수행할 때에 해당 로그 파일로 가서 애플리케이션의 작업이나 설명을 확인할 때에 쓰입니다

로그 파일의 형식은 다양하나 Elastic Beanstalk을 이용해 로그를 수집할 수 있죠

ECS, Lambda, CloudTrail CloudWatch 로그 에이전트에서 로그를 수집할 수 있는데 EC2 머신이나

온프레미스 서버에 로그 에이전트를 설치하여 해당 서버에서 AWS로 직접 로그를 가져올 수 있습니다

혹은 DNS 대기열을 로깅하는 Route53도 있죠

전반적으로 CloudWatch Logs는 이 모든 로그를 수집하여 로그에 대한 실시간 모니터링을 지원하며

이를 통해 로그에 발생하는 모든 상황에 대응할 수 있습니다 또한 보존 목적으로 로그를 재조정할 수도 있는데

즉 로그를 일주일이나, 30일, 1년 혹은 영원히 보존되도록 설정할 수 있다는 의미입니다.

EC2 인스턴스에서는 CloudWatch Logs가 어떻게 작동할까요?

기본적으로 EC2 인스턴스는 CloudWatch Logs에 로그 파일을 전송하지 않습니다

전송을 위해서는 EC2 인스턴스에 CloudWatch 로그 에이전트를 생성해야 합니다

그 후 생성한 에이전트가 CloudWatch Log 서비스로 로그 파일을 푸시하죠 요악해 보자면 실행 중인 CloudWatch Logs 서비스가 있고 EC2 인스턴스가 있을 때, 이 인스턴스에 CloudWatch 로그 에이전트를 설치하면 해당 에이전트가 바로 CloudWatch Logs에 로그 파일을 전송합니다.

이를 위해서는 해당 EC2 인스턴스에 CloudWatch Logs로 로그 데이터를 전송할 수 있는

올바른 IAM 권한을 갖는 인스턴스 역할이 있는지 확인해야 합니다

또한 로그 에이전트는 온프레미스 서버에도 설치할 수 있는데 이를 하이브리드 에이전트라고 부릅니다

이 에이전트는 온프레미스 또는 AWS 모두에서 작동하며

이를 통해 EC2 인스턴스와 온프레미스 서버 모두에서 로그 파일을 수집하여 CloudWatch Log 서비스로 보낼 수 있습니다

Amazon EventBridge

예전에는 CloudWatch 이벤트라고 불렸습니다

따라서 CloudWatch Events라고 하면 Amazon EventBridge를 생각하세요, 반대도 마찬가지입니다.

EventBridge가 새로운 이름입니다

EventBridge를 사용하면 AWS 계정 내에서 발생하는 이벤트에 대처할 수 있어요.

한 가지 사용 사례는 크론 작업을 예약하는 거에요

정기적으로 스크립트를 예약하고 싶다고 해보죠

예를 들어 EventBridge에서 1시간마다 이벤트가 생성된다는 규칙을 만들 수 있고

그 이벤트는 람다 함수에서 실행되는 스크립트를 트리거한다고 할 수 있습니다.

사실상 서버리스 크론 작업이죠, 또한 매시간 발생하는 이벤트에 반응할뿐만 아니라

서비스가 하는 작업에 대해서도 반응할 수도 있어요

예를 들어, 누군가가 루트 사용자를 사용하여 로그인할 때마다

보안 팀에 알림을 보낼 수 있어요, 왜냐하면 루트 사용자는 매우 드물게만 사용해야 하니까요

즉, IAM 루트 사용자 로그인 이벤트에 반응하여, 이를 이메일 알림과 결합된 SNS 토픽으로 보내는 거죠

그러면 누군가가 로그인할 때마다 이메일을 받게 되겠죠, 이렇게

Amazon EventBridge를 사용하여 다양하게 통합할 수 있어요, 목적지를 추가하거나

람다 함수를 트리거하거나, SQS/SNS 메시지를 보낼 수 있죠 할 수 있는 일은 이렇게나 많아요

기본 이벤트 버스라는 것도 있는데, AWS 서비스 또는 예를 들어 사용자의 Schedules 내에서 발생하는 이벤트입니다.

AWS의 파트너로부터 이벤트를 수신할 수도 있어요

예를 들어 Zendesk나 Datadog 또는 AWS의 파트너인 다른 서비스를 사용하는 경우 파트너 이벤트 버스를 통해 이벤트를 여러분의 계정으로 보낼 수 있어요

즉, AWS 외부에서 발생하는 이벤트에도 대응할 수 있어요

마지막으로, 여러분의 사용자 정의 애플리케이션을 연결할 수 있어요

사용자 정의 이벤트 버스를 연결하여, 원하는 통합을 만들고 전부 커스터마이징할 수 있죠

EventBridge에는 다른 기능도 많아요 스키마 레지스트리가 있어서, 이벤트 스키마를 모델링하여 스키마의 모양 및 데이터 유형 등을 확인할 수 있어요

또한 모든 이벤트를 아카이브하고 이벤트 버스로 보낼 수 있죠, 무기한 또는 설정된 기간 동안요

이렇게 보관된 이벤트를 재생할 수도 있어요

AWS CloudTrail

CloudTrail은 AWS 계정에 대한 거버넌스, 규정 준수, 감사를 제공하는 서비스입니다

계정을 사용할 때마다 기본적으로 활성화됩니다, 왜냐하면 CloudTrail은 계정 내에서 발생하는 모든 API 호출 또는 이벤트 기록을 가져오기 때문입니다.

매우 중요한 거죠, 왜냐하면 예를 들어 누군가가 콘솔에 로그인해서 어떤 작업을 하든

전부 CloudTrail에 기록되는 거니까요

만약 누군가가 SDK를 사용하면 CloudTrail에 기록됩니다

만약 누군가가 명령줄 인터페이스로 명령을 실행하면, 이 명령도 CloudTrail에 기록됩니다

어떤 서비스 활동이라도 CloudTrail에 기록됩니다

즉, 일어나는 모든 일이 CloudTrail에 기록된다는 뜻입니다

따라서 감사 및 보안 목적으로, CloudTrail 내에서 수행된 모든 이벤트 및

API 호출 기록을 가져와서, 두 군데, 즉 CloudWatch Logs 또는 Amazon S3로 보낼 수 있습니다

CloudTrail에서 트레일을 생성하면, 모든 리전에 적용하여 모니터링할 수 있어요 트레일은 CloudWatch Logs 또는 Amazon S3로 가거나, 단일 리전으로 추적할 수 있죠

시험 문제는 이렇게 나와요, 예를 들어, "사용자가 무언가를 삭제했다면"

"무엇을 누가 언제 삭제했는지 어떻게 알 수 있습니까?"라고 물어보죠 이 문제의 답은 CloudTrail이에요

API 호출을 찾아봐야 한다는 얘기가 나오면 CloudTrail이 정답이에요

정리해 볼게요, CloudTrail 콘솔 안에서 SDK 및 CLI, 콘솔, 모든 IAM 사용자, IAM 역할, 이들이 수행하는 모든 API 호출 정보를 얻을 수 있어요

CloudTrail 콘솔에 표시되지만, 데이터를 장기적으로 보존하려면

CloudWatch Logs 또는 S3 버킷으로 전송할 수 있어요

또한 CloudTrail 내에서 모든 유형의 검사 및 감사를 수행할 수 있어요

AWS X-Ray

또 다른 서비스인 AWS X-Ray를 살펴보겠습니다

기본적으로 어떤 분들은 프로덕션 환경에서 디버깅을 합니다

애플리케이션이 배포됐을 때 기본의 방식은 로컬에서 테스트한 뒤 CloudWatch Logs 등에 로그 상태를 추가하고

프로덕션 환경에서 다시 배포해서 문제를 확인하는 것입니다.

하지만 문제는 여러 서비스와 여러 애플리케이션의 로그가 있다는 것입니다

그리고 모두 결합해야 하기 때문에 로그 분석은 정말 어렵죠

아주 큰 모놀리스(Monolith)인 거대한 애플리케이션이라면 디버깅이 쉬운 편이지만

분산된 서비스이며 SQS 대기열과 SNS 주제로 연결되어 있거나 분리돼 있는 경우는 시스템에서 발생하는 일을

추적하기 매우 어렵습니다

그래서 전체 아키텍처의 일반적 뷰가 없습니다 이 문제를 해결하려면 AWS X-Ray를 사용합니다

X-Ray를 사용해서 애플리케이션을 추적하고 시각적 분석을 할 수 있습니다

따라서 서비스에서 X-Ray를 활성화하면 각 서비스에서 일어나는 일을 전체적으로 볼 수 있어서

장애나 성능을 확인할 수 있고 요청이 잘못된 경우에는 X-Ray 콘솔에서 바로 시각화할 수 있습니다

X-Ray의 장점은

병목 현상을 통해서 성능 문제를 해결하거나

마이크로서비스 아키텍처의 종속성을 이해할 수 있습니다

이전 그래프와 같이 모두 연결되어 있기 때문입니다

추적을 통해 서비스 문제를 파악할 수 있고

특정 요청을 검토할 수 있으며

해당 요청의 오류와 예외 사항을 찾을 수 있습니다

그리고 서비스 수준에 관한 계약인 SLA를 충족하는지도 알 수 있는데

이는 모든 요청을 제시간에 응답하는지를 말합니다

어떤 서비스에서 스로틀 되거나 속도가 느려지는 현상이 발생하면 이 장애의 영향을 받는 사용자를 식별할 수 있습니다

따라서 X-Ray는 분산 추적 및 문제 해결과 서비스 그래프에 유용합니다

Amazon CodeGuru (머신러닝 기반 서비스)

Amazon CodeGuru를 살펴보겠습니다 머신 러닝 기반 서비스로 2가지를 실행합니다

첫 번째는 자동화된 코드 검토이고

애플리케이션 성능 권장 사항이 두 번째입니다

개발자가 코드를 푸시하면 다른 개발자가 코드를 검토하고 코드가 프로덕션에 배포되면 코드의 성능을 모니터링하고

버그를 탐지할 수도 있습니다 CodeGuru에서 자동화된 방식으로 수행합니다

CodeGuru Reviewer는 정적 코드 분석으로 자동화된 코드 검토를 실행합니다 코드를 CodeCommit이나 GitHub와 같은

리포지토리에 배포하면 CodeGuru에서 전체 코드줄을 확인해 이전에 살펴봤던 버그나 메모리 누수와 같은 경우에 실행 가능한 권장 사항을 제공하는 것입니다.

그리고 머신 러닝 기능으로 Reviewer가 탐지하기도 전에 버그를 탐지해 매우 유용합니다

CodeGuru Profiler는 프로덕션이나 런타임 도중에 애플리케이션 성능에 관한 가시성과 권장 사항을 제공합니다.

애플리케이션을 설계하고 테스트하면 CodeGuru Profiler가 비용이 높은 사전 프로덕션 환경의 코드줄을 탐지하고 최적화 합니다.

그리고 애플리케이션을 배포하면 실시간 애플리케이션을 측정하는데 CodeGuru Profiler가 프로덕션에서 성능과 비용 개선 사항을 식별해 코드에 바로 권장 사항을 제공합니다 이것이 CodeGuru의 장점입니다

조금 더 자세히 살펴보면 CodeGuru Reviewer는 코드를 푸시할 때마다

커밋을 확인하고 잘못된 코드줄을 알려줍니다

정말 유용하죠 중요한 문제를 식별하고 보안 취약성과 찾기 힘든 버그를 식별합니다

예를 들어, 코딩 모범 사례를 구현할 수 있고 리소스 누수를 찾거나 보안 허점이 생기거나 입력값 유효성을 검사할 때 보안 탐지를 할 수 있으며 머신 러닝과 자동화된 추론을 사용해 실행합니다

CodeGuru에서 수천 개의 오픈 소스 리포지토리와 모든 amazon.com 리포지토리에서 분석한 코드 분석을 사용하는 것이죠 이런 방식으로 머신 러닝을 통해 코드 Reviewer가 학습합니다.

현재는 Java와 Python을 지원하고 GitHub, Bitbucket 그리고 CodeCommit과 통합되었습니다 제가 말한 게 전부가 아니고 나중에 더 늘어날 수도 있습니다

Profiler는 애플리케이션이 프로덕션 환경에 있거나사전 프로덕션 환경에 있을 때 애플리케이션의 런타임을 이해하고

로깅 루틴 등에서 CPU 사용률을 과도하게 소비하는 것을 확인할 수 있습니다.

따라서 코드 비효율성을 식별하고 제거해 CPU 사용률을 줄이고 컴퓨팅 비용을 줄이며

어떤 객체가 메모리 공간을 많이 차지하는지를 식별하는 힙(heap) 요약을 제공할 뿐만 아니라 애플리케이션에 문제가 생긴 경우 이상 탐지를 제공해 애플리케이션의 성능을 개선합니다

AWS 클라우드와 온프레미스에서 실행되는 애플리케이션도 지원합니다 CodeGuru Profiler를 사용해 모니터링할 애플리케이션에서 최소한의 오버헤드가 발생합니다.

CodeGuru와 CodeGuru Reviewer, CodeGuru Profiler만 알면 됩니다.

AWS Health Dashboard

대시보드는 크게 두 부분으로 나뉩니다 (서비스 기록과 계정)

서비스 기록에는 모든 리전과 서비스 상태가 표시됩니다 이렇게 보입니다

따라서 서비스가 어떻게 작동했는지, 어떤 문제가 있었는지 리전별로 추적할 수 있습니다.

기록을 볼 수도 있습니다 이건 매일의 기록이고요, RSS 피드가 있어서 구독할 수도 있죠

이전에는 AWS Service Health 대시보드라고 불렸습니다

다음으로 볼 것은, 사용자 계정의 AWS Health 대시보드입니다

예전에는 AWS Personal Health 대시보드(PHD)라고 불렀습니다

하지만 지금은 그냥 계정 Health 대시보드라고 해요

사용자에게 직접적인 영향을 미치는 이벤트가 AWS에서 발생할 때, 알림과 해결 지침을 알려줍니다.

서비스 상태 대시보드에는 모든 서비스의 일반적인 상태가 표시되지만 계정 상태 대시보드에서는 사용자의 계정과 리소스에서 사용 중인 서비스의 성능과 가용성을 확인할 수 있습니다.

시기적절한 관련 정보를 제공하며, 알림도 보내줍니다 예정된 유지 관리 활동을 미리 살펴볼 수 있도록요

또한 계정 상태 대시보드에서는 사용자의 AWS 전체 조직의 데이터를 집계할 수 있어요

상태 대시보드에 액세스하려면 오른쪽 상단 모서리 종 아이콘을 클릭하면 돼요

이건 글로벌 서비스에요, 또한 사용자에게 직접적인 영향을 미치는 운영 중단도 보여줍니다

Event log에서는 과거 이벤트를 확인할 수 있고요

예를 들어, 여기에는 us-east-2에 저에게 영향을 줄 수 있는 EC2 이슈가 있네요

알림, 문제 해결 정보, 사전 예방적 알림을 받을 수 있어요

예정된 변경 사항이나 예정된 활동이 있는 경우에요

클라우드 모니터링 요약

첫 번째는 CloudWatch로 여러 가지 종류가 있습니다

- CloudWatch Metrics은 AWS 서비스의 성능과 요금 지표를 모니터링하고

- CloudWatch Alarms로는지표가 특정 범위를 벗어나면 자동으로 알림을 받고 재부팅과 같은

EC2 인스턴스를 실행하도록 자동화 할 수 있습니다. 특정 제한을 초과하는 지표를 기반으로 SNS 서비스에 정리 알림을 보낼 수도 있습니다.

- CloudWatch Logs는 EC2 인스턴스나 서버 혹은 람다 함수에서 로그 파일 수집 시 사용하며 한 가지 서비스로 중앙화됩니다

- CloudWatch Events는 Events Bridge라고도 하며 AWS 이벤트에 반응하거나 특정 예약을 기반으로 규칙을 트리거 하는 방식입니다.

- 계정 내에서 발생한 API 호출을 감사하려면 CloudTrail 서비스를 사용합니다.

- 무엇보다 CloudTrail Insights로 CloudTrail 이벤트에 관한 자동화된 분석을 얻을 수 있습니다.

- Amazon X-Ray는 분산 애플리케이션을 통한 요청을 추적하는 데 사용합니다 특히 오류가 발생했고 모든 애플리케이션이 서로 통신할 때 성능을 분석하거나 근본 원인을 분석할 때 매우 유용합니다.

- Service Health Dashboard에서는 모든 리전 전반의 모든 AWS 서비스에 관한 상태를 확인할 수 있습니다.

- 조금 더 개인화된 것이 필요하면 배포나 인프라에 직접 영향을 미치는 AWS 이벤트에 관한 알림을 제공하는 Personal Health Dashboard를 사용합니다

- 마지막은 CodeGuru입니다 CodeGuru는 머신 러닝으로 자동화된 코드 검토를 실행하고 프로덕션 환경 내 애플리케이션의 성능을 모니터링해 애플리케이션 성능 권장 사항을 제공하며 이 또한 머신 러닝을 활용해 제공합니다

AWS CCP 자격증 - 11 (클라우드 통합)

곰종 — Sun, 7 Jul 2024 21:32:31 +0900

클라우드 통합이란?

어느 시점에 가면 애플리케이션이 여러 개 생겨서 서로 통신이 이루어져야 합니다.

두 가지 패턴 타입으로 애플리케이션을 서로 통신하게 만들 수 있습니다

첫 번째는 동기식 통신입니다.

동기식 통신의 과정은 애플리케이션이 다른 애플리케이션에 요청을 합니다.

예를 들어 뭔가를 구매하는 서비스를 만들어서 판매한 물품을 배송하는 서비스에 연결해야 된다고 하면

구매 서비스와 배송 서비스를 동시에 통합하려고 하게됩니다.

이 과정에서 서로 직접 요청을 주고받기에 동기식 통신입니다.

두 번째는 비동기식 통신 입니다. (이벤트 기반)

예를 들어 통신할 대기열이 있을 때입니다

이번에는 구매 서비스가 뭔가를 판매할 때마다 대기열에 주문을 올려두면 배송 서비스가 대기열에서 읽어들여 주문을 받습니다.

이 예시에서 볼 수 있듯이 구매 서비스와 배송 서비스는 서로 직접적으로 통합되지 않습니다

decoupled라는 게 있는데 중간에 통신할 대기열이 있어서 훌륭한 통합 패턴이 생깁니다.

Amazon SQS (Simple Queue Service)

애플리케이션을 분리할 수 있도록 해주는 첫 번째 서비스를 살펴보겠습니다

Amazon SQS인데요, Simple Queue Service의 약자입니다

Queue가 뭘까요? 여기에 SQS 대기열을 생성하고 있다고 해보죠

그러면 우리는 프로듀서가 해당 대기열로 메시지를 전송하게 할 수 있습니다

그러면 프로듀서는 하나가 될 수도 있고 여럿일 수도 있겠죠

그런 다음 메시지가 대기열에 저장되면 대기열을 폴링하는 컨슈머가 메시지를 읽을 수

있습니다

그러니까 대기열에서 메시지를 요청하면서 대기열을 폴링하는데 컨슈머는 하나일 수도 있고

여럿일 수도 있겠죠

이 예시에서는 컨슈머가 메시지를 폴링하면 작업을 공유하고요

컨슈머마다 다른 메시지를 받게 됩니다

메시지 처리가 끝나면 예를 들어 영상을 처리하기 위해 대기열의 메시지를 삭제해버리고 메시지는 사라집니다

이 구조에서는 프로듀서가 메시지를 대기열로 보내게 하고 프로듀서와 분리된 컨슈머가

대기열에서 메시지를 읽어들여서 서로 다른 속도로 처리하게 합니다

분리(Decouple)가 나온다면 SQS

SQS는 애플리케이션 티어 사이를 분리할 때 사용 가능합니다.

웹 서버가 있고 이 웹 서버가 요청을 받는데 아마 Application Load Balancer를 통해서겠죠

요청은 Auto Scaling Group의 EC2 인스턴스를 통해 처리됩니다

그리고 예를 들어 어떤 영상을 처리해달라는 사용자의 요청이 있다고 해보죠

이때 영상 애플리케이션으로 직접 전송하는 것이 아니라 메시지를 SQS 대기열에 삽입할 수 있습니다,

그러면 Auto Scaling Group의 EC2 인스턴스로 구성된 영상 처리 계층이 생깁니다

이 EC2 인스턴스가 SQS 대기열에서 읽어들여 영상을 처리하게 됩니다

여기서 좋은 점이 첫 번째를 제외한 두 번째 Auto Scaling Group의 규모를 조정할 수 있다는 건데요

그래서 분리라고 합니다

게다가 예를 들어 SQS 대기열에 있는 메시지 수에 따라 규모를 조정할 수도 있습니다

이렇게 하면 두 계층, 즉 웹 서버와 영상 처리가 SQS 대기열에서 완전히 분리되어 독립적으로 조정됩니다.

그러면 최상의 사용자 경험을 제공할 수 있고 비용 효율과 규모 조정 문제도 해결되죠

또 다른 Amazon SQS 기능은 FIFO 대기열을 둔다는 겁니다

일반적인 SQS Queue라면 컨슈머는 메시리를 한번에 읽을 수 있고 순서도 각자 다를 수 있지만

Amazon SQS FIFO Queue는 메시지가 순서대로 처리됩니다.

Amazon Kinesis

Kinesis -> 실시간 빅 데이터 스트리밍 서비스

Kinesis의 하위 서비스로 이것들이 있죠 Amazon Kinesis Streams는 클릭 스트림, IOT 기기, 척도, 로그 서버와 같은 데서

데이터를 가져옵니다 데이터를 분석하고 실시간으로 출력을 생산하길 원한다면 Kinesis Data Analytics를 사용합니다.

Kinesis Firehose는 출력값을 도착지에 직접 보낼 때 사용하죠

예를 들어, Amazon S3 버킷이나 Amazon Redshift 데이터베이스와 같이 데이터를 분석할 수 있는 곳에 말이죠

그리고 거기에서 더 많은 분석을 수행할 수 있습니다

Amazon SNS

애플리케이션을 분리하는 두 번째 방식입니다.

하나의 메시지를 다수의 수신자에게 보내고 싶을 때, 직접 통합으로 라우팅할 수 있습니다.

예를 들어, 구매 서비스는 이메일 알림을 보내고 사기 탐지 서비스, 배송 서비스와 SQS 대기열에 통신합니다.

이 방식은 꽤 복잡해집니다 4개의 직접 통합이 필요하기 때문입니다

대신에 게시-구독(pub/sub) 통합을 사용할 수 있습니다 SNS 주제가 있고 구매 서비스는 SNS 주제에 메시지를 보냅니다

주제는 똑똑하게도 자동으로 이메일 알림을 보내고 사기 탐지 서비스 배송 서비스 심지어 SQS 대기열에도 보냅니다

SNS는 Simple Notification Service의 약자로

이벤트 게시자는 오직 하나의 SNS 주제에 메시지를 보냅니다

SNS 주제 알림을 리스닝할 이벤트 구독자를 원하는 만큼 가질 수 있습니다

주제를 구독하는 각 구독자는 모든 메시지를 받을 수 있습니다

따라서 소비자가 메시지를 공유하는 SQS와는 다릅니다

주제의 각 구독자는 SNS 주제로 보내지는 모든 메시지를 받습니다

각 SNS 주제는 1,200만 명 이상의 구독자를 가질 수 있고 계정 당 100,000개의 주제를 가질 수 있습니다.

SNS는 많은 목적지를 가집니다 즉 많은 구독자에게 게시할 수 있죠 AWS 서비스 측면에서는 SQS, Lambda

Kinesis Data Firehose가 SNS 게시 활동의 대상이 될 수 있습니다

또한 SNS로부터 이메일을 직접 보낼 수 있고 SMS와 모바일 알림을 보낼 수 있습니다

마지막으로 HTTP나 HTTPS 엔드 포인트로 데이터를 보낼 수 있죠

시험에서 알림 게시-구독, 구독자 등등을 본다면 Amazon SNS를 생각하시면 됩니다.

Amazon MQ

Amazon MQ는 아주 간단합니다

RabbitMQ와 ActiveMQ 이 2가지 기술을 지원하는 관리형 메시지 브로커 서비스인데요

RabbitMQ와 ActiveMQ는 앞서 말한 개방형 프로토콜에 액세스 권한을 제공하는 온프레미스 기술입니다

그러면 Amazon MQ 덕분에 클라우드에 이런 브로커를 관리형 버전으로 갖추게 되는 거죠

이런 식으로 개념을 이해하시면 되고요

우선 AmazonMQ는 거의 무한대로 규모 조정이 가능한 SQS나 SNS만큼 확장성이 있지는 않습니다,

그리고 AmazonMQ는 서버에서 샐행되기 때문에 서버 문제가 발생할 수 있습니다

그래서 가용성을 높이고 싶다면 장애 조치를 지원하는 다중 AZ 설치를 실행하면 됩니다.

또 AmazonMQ는 SQS와 같은 대기열 기능을 제공하고 SNS와 같은 토픽 기능도 단일 브로커에 포함해 제공합니다

그러니까 AmazonMQ는 오로지 업체가 클라우드로 마이그레이션하는 경우에만 사용되고

M MQTT, AMQP, STOMP 등등 이런 개방형 프로토콜 중 하나를 사용해야 합니다

그게 아니라면 SQS와 SNS를 사용해야 되죠, AmazonMQ보다 훨씬 확장성이 좋고

Amazon Web Service와도 통합이 더 잘되니까요

클라우드 통합 요약

그럼 이 섹션에서 배운 내용을 전부 정리해보겠습니다

SQS는 AWS의 대기열 처리 서비스입니다

SQS 대기열에 여러 프로듀서를 둘 수 있고, 메시지는 대기열에 최대 14일까지 보관했다가 삭제합니다.

컨슈머는 이 메시지들을 읽을 수 있고 읽기 작업을 공유하는데요 읽기 작업을 쪼개는 거죠

메시지는 읽어서 처리가 끝나면 삭제됩니다 즉, 컨슈머가 작업을 마치면 메시지는 사라지죠

AWS 내에서 애플리케이션을 분리할 때 사용합니다 언제든 대기열 처리나 분리가 나오면 SQS를 떠올리세요

SNS는 AWS의 알림 서비스입니다 프로듀서와 구독자가 있죠

구독자는 이메일일 수도 있고 Lambda, SQS, HTTP, 모바일일 수도 있고요, 하나의 SNS 토픽에 구독자가 여럿이라면 SNS가 모두에게 메시지를 전송합니다

SNS는 메시지를 보유하지 않으니까 메시지 장기 저장 장치는 아니죠 AWS 내에서 pub/sub, 구독자, 토픽, 알림용으로

사용됩니다

마지막으로 Kinesis를 살펴봤는데요, 실시간 데이터 스트리밍 서비스로, 데이터 영속성을 갖추게 됩니다.

또 실시간으로 Kinesis 위에다 분석을 실행할 수도 있죠

끝으로 AmazonMQ가 있었습니다, 관리형 메시지 브로커로 클라우드에서 ActiveMQ와 RabbitMQ를 지원하죠

온프레미스에서 클라우드로 마이그레이션하면서 MQTT나 AMQP 아니면 그 밖의 프로토콜을 사용할 때

필요한 서비스입니다

AWS CCP 자격증 - 10 (글로벌 인프라)

곰종 — Sun, 7 Jul 2024 20:49:55 +0900

글로벌 애플리케이션을 만드는 이유

왜 글로벌 애플리케이션을 만들까요?

글로벌 애플리케이션은 여러 지역에 배포되는 애플리케이션이며

이는 AWS에서는다양한 AWS 리전과 엣지 로케이션으로 애플리케이션이 배포된다는 의미입니다.

이를 통해 전 세계의 사용자의 지연 시간이 줄어들게 됩니다

지연 시간은 네트워크 패킷이 서버에 도달하는 시간입니다

그래서 지구가 큰 것을 고려하면 패킷이 아시아에서 미국까지 도달하는데 긴 시간이 소요될 것입니다

예를 들어, 사용자는 인도에 있고 서버는 미국에 있으면 더 많은 지연이 생기고 지연 시간도 늘어나지만

사용자 근처로 애플리케이션을 배포하면 수월하게 이용할 수 있죠

첫번째는 저 지연시간을 위해서 입니다.

애플리케이션을 미국과 아시아에 배포하면 미국의 사용자와 아시아의 사용자의 지연 시간이 줄어들게 됩니다

애플리케이션 서버에 빠르게 도달하기 대문입니다

두 번째 이유는 재해 복구 계획입니다

하나의 데이터 센터나 한 리전에 의존하지 않는 것으로 그럴 리 없겠지만 지진이나 태풍 또는 정전이나 정치적인 이유 등으로 전체 리전이 정지되면 재해 복구 계획으로 다른 리전으로 장애 조치해 애플리케이션이 계속 실행되도록 하는 것입니다

그래서 재해 복구 계획은 애플리케이션의 가용성을 높이는데 매우 중요합니다

글로벌 애플리케이션을 만드는 마지막 이유는 바로 공격에 대비하기 위해서입니다

해커들은 온라인에서 여러 이유로 애플리케이션을 중단시키기 위해 애플리케이션을 공격합니다

이때 애플리케이션이 여러 리전에 있고 전 세계적으로 배포했다면 여러 리전을 한 번에 공격하기 어려워집니다

그래서 이러한 공격으로부터 안전할 수 있는 것입니다

Global Applications in AWS

Global DNS, Route 53을 살펴볼 것입니다

사용자를 최소한의 지연 시간으로 가장 가깝게 배포 리전에 라우팅 하도록 합니다.

그리고 재해 복구 계획에도 유용합니다

그리고 글로벌 CDN의 경우에는 CloudFront를 사용해 애플리케이션의 일부를

엣지 로케이션에 다시 복제해 사용자의 지연 시간을 줄이고 일반 요청을 캐시해서 사용자 경험을 개선하고

지연 시간 또한 줄이는 것입니다

그리고 S3 Transfer Acceleration도 살펴봅니다

Amazon S3로의 전 세계적인 업로드와 다운로드를 가속화합니다.

마지막은 AWS Global Accelerator로

AWS의 글로벌 네트워크로 글로벌 애플리케이션의 가용성과 성능을 개선합니다.

Amazon Route 53

Amazon Route 53입니다.

Route 53은 관리 DNS(도메인 이름 시스템)입니다

DNS가 무엇일까요? DNS는 전화번호부와 같습니다

규칙과 레코드의 모음집으로 클라이언트가 URL을 통해 올바른 서버를 찾아갈 수 있게 도와줍니다.

AWS에서 가장 흔한 레코드를 살펴보겠습니다

예를 들어, www.google.com을 IPv4 주소로 매핑하고자 합니다 이것을 A 레코드라고 합니다.

www.google.com을 긴 IPv6 주소와 매핑하면 AAAA 레코드라고 합니다.

호스트 이름을 다른 호스트 이름과 매핑하려고 한다면

즉, search.google.com을 이전 주소에 매핑하면 CNAME이라고 합니다 호스트 이름과 호스트 이름을 매핑하기 때문이죠

마지막으로 호스트 이름을 AWS 리소스에 매핑하는 것은 특별한 레코드로 별칭 레코드라고 합니다

ELB가 있거나 CloudFront, S3, RDS 데이터베이스 등을 이용하면 동작합니다

시험에서 모든 레코드 유형을 알 필요가 없지만 Route 53이 관리형 DNS란 것을 알면 됩니다

Route53 예시

A 레코드에서 무슨 일이 일어나는지 보면

웹 브라우저가 있고, 배포한 애플리케이션 서버가 있습니다.

공인 IPv4를 가지고 있죠 애플리케이션 서버에 일반 URL을 통해 접근하고 싶습니다

이를 위해 Route 53으로 가서 A 레코드를 만듭니다

웹 브라우저가 myapp.mydomain.com에 관한 DNS 요청을 합니다 그러면 DNS는 IP를 응답합니다

웹 브라우저는 이 IP를 이용하여 올바른 서버에 연결합니다 또한 서버로부터 HTTP 응답을 얻죠

대략적으로 DNS가 동작하는 기본 방식입니다

Route 53 라우팅 정책 (시험에나옴)

전반적으로 알고 있어야 하며 사용 용례에 따라 알맞은 것을 선택해야 합니다 꽤 간단합니다.

첫 번째는 단순 라우팅 정책입니다

상태 확인을 하지 않는 정책이죠 웹 브라우저는 DNS 시스템에 가서

DNS 검색을 하고 예를 들어, IPv4를 결과로 얻습니다 이것이 단순 라우팅 정책입니다 기본적인 정책입니다.

가중치 기반 라우팅 정책은 트래픽을 여러 기관의 인스턴스에 분산합니다.

예시에서는 기관 인스턴스에 가중치를 부여합니다 예를 들어, 70, 20, 10입니다

그러면 DNS는 클라이언트가 트래픽의 70%가 첫 번째로 가고, 트래픽의 20%가 두 번째로, 나머지 10%가 세 번째로 가도록 합니다

로드 밸런싱을 할 때 효율적입니다 가중치 라우팅 정책에서는 상태 확인을 합니다

지연시간 라우팅 정책

다음은 지연 시간 라우팅 정책입니다 예시에서는 애플리케이션을 전 세계적으로 표시하고 있는데요

하나는 캘리포니아에, 하나는 호주에 있습니다 사용자는 전 세계에 있죠

지연 시간 라우팅 정책은 사용자의 위치를 살펴보고 그들이 미국 캘리포이나 EC2 인스턴스에 가깝다면

해당 서버와 통신하도록 리디렉션 됩니다 .(만약 사용자가 호주와 가깝다면 호주 서버와 통신하도록 리디렉션됩니다)

지연 시간에 근거해서 말이죠

예시에서는 Route 53이 사용자와 서버 사이의 거리를 가깝게 만들어서 지연 시간을 최소화합니다

마지막으로 장애 조치 라우팅 정책이 있습니다

클라이언트가 있고 기본 EC2 인스턴스가 있고 장애 조치 인스턴스가 있습니다

DNS 시스템을 기본 인스턴스의 상태를 확인하고 만약 기본 인스턴스에 장애가 발생하면

장애 조치 인스턴스로 리디렉션합니다

장애 회복에 도움 됩니다

Route 53 덕분에 클라이언트는 인스턴스의 상태에 따라 어떤 인스턴스에 연결될지 정확히 알고 있습니다.

알아야 할 라우팅 정책은 여기까지입니다

첫 번째 정책은 상태 확인을 하지 않고 나머지는 모두 상태 확인을 합니다 모두 다른 목적이 있죠

가중치 라우팅 정책은 트래픽을 여러 기관 인스턴스에 분산합니다

지연 시간은 지연 시간을 최소화하고 장애 조치는 장애 회복에 도움 되죠

AWS CloudFront(CDN)

CloudFront는 콘텐츠 전송 네트워크, 즉 CDN입니다

언제든 시험에서 CDN이 나오면 CloudFront를 떠올리세요

여러 엣지 로케이션에서 웹사이트의 콘텐츠를 캐싱해서 읽기 성능을 향상시킵니다

전 세계에서 콘텐츠를 캐싱하기 때문에 전 세계 사용자들의 대기 시간이 단축되어서 사용자 경험을 개선해줍니다

CloudFront는 전 세계에 216개 접속 지점을 두고 있는데 세계 곳곳에 위치해 있는 AWS 엣지 로케이션에

해당합니다, 계속 로케이션을 추가해서 모든 곳에서 사용자 경험을 훨씬 더 개선하고 있어요

무엇보다 콘텐츠를 전 세계에 배포함으로써 디도스 공격을 방어합니다

디도스는 전 세계 모든 서버가 동시에 당할 수 있는 공격의 일종입니다.

요점은 애플리케이션을 전 세계에서 사용하기 때문에 CloudFront를 이용하면 이런 공격을 막아준다는 것입니다.

또 보안 섹션에서 배우게 될 Shield와 Web Application Firewall이라는 것도 이용합니다

세계 지도를 보고 싶다면 여기 지도가 있는데, 엣지 로케이션과 엣지 케이스가 나와 있습니다

이를 테면 호주에 S3 버킷을 생성하고 거기에 웹사이트를 만들었는데 사용자는 미국에 있다고 해보면

사용자는 CloudFront를 사용해서 미국에 있는 엣지 로케이션에서 콘텐츠를 요청하고 CloudFront가 호주에서 콘텐츠를 가져올 수 있습니다

미국에 있는 또 다른 사용자가 동일한 콘텐츠를 요청하고 있다면 엣지에서 곧바로 제공될 겁니다, 저 멀리 호주까지 가서 콘텐츠를 제공하는 게 아니에요

마

찬가지로 사용자가 중국에 있다면 중국의 접속 지점과 통 신해서 S3 버킷으로 리디렉션되고 콘텐츠는 엣지에서 캐싱됩니다

S3 Transfer Acceleration

S3 버킷은 한 리전에만 연결되는 것을 알고 있습니다.

사용자가 전 세계에 있는 파일을 특정 S3 버킷에 전송하고 싶다면 S3 Transfer Acceleration을 이용하여 전송 속도를 올릴 수 있습니다

이 방식은 예를 들어, 미국에 있는 파일을 호주 S3 버킷에 업로드할 때 파일을 엣지 로케이션에 업로드하여

미국 사용자에게 가깝게 하고 내부 네트워크를 사용하여 엣지 로케이션에서 호주의 S3 버킷으로 파일을 전송합니다.

좀 더 안정적이고 빠른 연결을 통해서 말이죠

S3 Transfer Acceleration가 동작하는 기본 방식입니다

이 방식은 멀리 떨어진 S3 버킷에 파일을 업로드하거나 다운로드할 때 사용합니다

멋진 점은 도구를 테스트하여 얼마나 효과적인지 볼 수 있습니다

AWS Global Accelerator

AWS Global Accelerator를 배워보겠습니다

이것은 AWS 글로벌 네트워크를 이용하여 글로벌 애플리케이션의 가용성과 성능을 개선할 때 사용합니다.

기본적으로 여러분의 요청은 이전에 AWS에서 본 사설 네트워크를 이용하여 라우팅 되고 애플리케이션의 라우팅을

약 60% 정도 최적화합니다

예시를 살펴보면 앱 브라우저를 인도에서 배포했고 전 세계 사용자가 애플리케이션에 접근하기 원합니다.

이들은 Global Accelerator로 엣지 로케이션을 연결하고 엣지 로케이션은 트래픽을 인도로 직접 라우팅합니다.

이 방식의 장점은 공용 인터넷의 트래픽이 미국과 가장 가까운 엣지 로케이션에서만 발생한다는 것입니다.

이것은 사설 AWS 네트워크를 이용하여 엣지 로케이션에서 앱 브라우저로 빠르게 연결합니다

유럽과 호주에서도 마찬가지입니다

게다가 애플리케이션의 접근은 2개의 정적 IP 또는 애니캐스트 IP로만 가능합니다.

이 정적 애니캐스트 IP를 이용하여 자동으로 올바른 엣지 로케이션에 리디렉션됩니다

Global Accelerator 없이 무슨 일이 일어나는지 보여주면, 클라이언트는 리전의 애플리케이션을 가져오기 위해

네트워크에서 많은 홉을 거치게 되고 이는 문제가 될 수 있습니다 지연 시간이 더해질 수 있습니다.

Global Accelerator를 이용한다면 AWS 엣지 로케이션에 연결하여 엣지 로케이션으로부터

연결하려는 리전까지 빠르게 갑니다 더 빠른 사설 AWS 네트워크를 이용하기 때문입니다.

Global Accelerator와 CloudFront의 공통점, 차이점

공통점 : 둘 다 AWS 글로벌 네트워크 사용, 전 세계 엣지 로케이션 사용하고 Shield와 통합하여 DDoS 보호

CloudFront : CDN(콘텐츠 전송 네트워크)으로 엣지에서 이미지, 영상, 웹사이트 같은 콘텐츠를 캐싱

- CloudFront 엣지에서 콘텐츠를 제공합니다. (엣지로케이션에서 캐싱하기 때문)

Global Accelerator : 캐싱하지 않고, 엣지 로케이션으로부터의 모든 요청은 리전의 애플리케이션으로 전달됩니다.

- TCP, UDP와 같이 넓은 범위에서의 요청에서 성능을 개선합니다.

- 정적 IP 주소를 요구하는 HTTP 사용 예시에 적합합니다.

- 결정적이고 빠른 지역 장애 조치나 좋은 성능을 요구할 때 적합합니다.

AWS Outposts

하이브리드 클라우드가 무엇일까요?

온프레미스 인프라를 유지하면서 클라우드 인프라를 가져가는 사업을 하이브리드 클라우드라고 합니다.

이때 IT 시스템을 처리하는 두 가지 방법이 있습니다

AWS 클라우드는 예를 들어, AWS 콘솔, CLI, AWS API를 이용합니다

다른 하나는 온프레미스 인프라를 위한 방법입니다

따라서 두 가지 다른 유형의 스킬이 있고 두 가지 다른 유형의 API가 있습니다

그래서 AWS는 하이브리드 클라우드를 이용하는 회사를 위해 Outposts라는 서비스를 만듭니다.

Outposts는 클라우드와 마찬가지로 자체 온프레미스 애플리케이션을 구축할 수 있도록 동일한 AWS 인프라, 서비스, API 및 도구를 제공하는 "서버 랙"입니다

즉, 사내 온프레미스 인프라 내에 있는 서버에 Outposts 랙을 설치하여 관리할 것입니다.

이 서버에는 AWS 서비스가 미리 로드되어 있고 온프레미스의 장점도 누릴 수 있습니다.

기업의 데이터 센터를 보면 AWS가 Outposts 랙을 설정하고 이는 AWS 서비스를 온프레미스 데이터 센터로 직접 확장할 수 있습니다. 클라우드에서 실행하는 EC2 인스턴스와 자체 데이터 센터에서 실행하는 EC2 인스턴스의 차이점은

사용자가 랙 자체의 물리적 보안을 책임져야 한다는 점입니다. 사용자의 데이터 센터에 랙이 있기 때문이죠

Outposts의 혜택

첫 번째는 온프레미스 시스템에 접근할 때 지연 시간이 적다는 것입니다.

데이터 처리를 로컬에서 하고 데이터는 온프레미스 시스템을 떠나지 않죠 클라우드로 절대 가지 않고

데이터 센터 내에 머무릅니다

그리고 온프레미스에서 Outposts로 옮기기는 쉽습니다. Outposts에서 데이터를 클라우드로 쉽게 보낼 수 있습니다

이것은 완전 관리 서비스입니다 AWS가 서비스를 관리해 줍니다 Outposts를 사용하여 많은 서비스를 실행할 수 있습니다

예를 들어, Amazon EC2, Amazon EBS, Amazon S3, Amazon EKS, Amazon ECS, Amazon RDS, Amazon EMR이 있고

온프레미스 시스템 인프라에클라우드를 확장하는 멋지고 혁신적인 방식입니다

AWS WaveLength

일단 시험에 5G가 나온다면 Wave Length입니다.

WaveLength 영역은 5G 네트워크 엣지에 있는 통신 제공업체의 데이터 센터 내에 내장된 인프라 배포입니다.

기본적으로 AWS 서비스를 5G 네트워크의 엣지에 배포할 수 있습니다.

EC2 인스턴스, EBS 볼륨, VPC를 WaveLength 영역에 배포할 수 있습니다.

예를 들어 5G 네트워크를 가진 통신사가 있고 WaveLength 영역이 있을 때 통신사의 게이트웨이를 통하여

EC2를 해당 영역에 배포할 수 있습니다.

그래서 영역은 5G 네트워크 자체에 속해있어서 모바일 기기의 5G 사용자가 WaveLength 영역에 접근할 때 지연 시간은 매우 적습니다 이유는 애플리케이션이 엣지에 배포되기 때문입니다

전반적으로 WaveLength는 5G 네트워크를 통해 애플리케이션의 지연 시간을 줄여줍니다

예시에서 트래픽은 통신 서비스 제공자, 즉 CSP 네트워크를 떠나지 않습니다

실제로 AWS에 도달하지 않지만 AWS로 보안 연결을 원한다면 그렇게 할 수 있습니다.

즉, WaveLength 영역은 부모 리전에 연결되어 있습니다 예시에서 WaveLength 영역에 있는

EC2 인스턴스는 데이터베이스에 접근해야 하는데요

예를 들어 AWS 리전의 RDS 또는 DynamoDB에 연결합니다 WaveLength를 사용할 때 추가 비용이나 서비스 동의는 필요 없어요

사용 사례도 다양합니다 스마트 도시, ML 기반 진단, 커넥티드 카, 대화형 실시간 영상 스트리밍, AR 및 VR, 실시간 게임이 있습니다

적은 지연 시간을 요구하고 사용자와 엣지가 매우 가까워야 하는 모든 것에 적합합니다

5G로 가능한 사용 사례였습니다

AWS Local Zones

시험에서 나올 수 있는 AWS 로컬 영역을 다뤄보겠습니다

가용 영역이 있고 전 세계에 여러 리전이 있습니다 로컬 영역이라는 개념은 컴퓨팅 스토리지 데이터베이스 및

데이터베이스가 선택한 다른 서비스를 최종 사용자와 가깝게 배치하여

지연 시간에 민감한 애플리케이션을 실행합니다

기본적으로 AWS 리전을 1개 이상의 위치 또는 1개 이상의 가용 영역으로 확장해 줍니다

이를 로컬 영역이라고 부릅니다

EC2, RDS, ECS, EBS, 일래스틱 캐시, Direct Connect 등과 호환됩니다

us-east-1 N.Virginia에 리전이 있고 6개의 AZ가 기본으로 있습니다 이 AZ를 더 많은 로컬 영역에 확장할 수 있습니다

보스턴, 시카고, 댈러스, 휴스턴, 마이애미 등으로 말이죠

어떻게 동작할까요? us-east-1 리전에 2개의 AZ가 있고

보스턴에 로컬 영역을 정의할 수 있습니다 그리고 VPC를 AZ과 로컬 영역으로 확장합니다

그러면 EC2 인스턴스를 로컬 영역에서 실행할 수 있습니다

Global Applications Architecture

어떻게 글로벌 애플리케이션을 만들까요?

아키텍처를 이야기하겠습니다

만약 하나의 리전, 하나의 AZ라면 간단합니다 하나의 리전에 한 AZ에 EC2 인스턴스가 있고

이는 가용성이 높지 않을 것입니다 글로벌 지연 시간이 좋지 않을 거예요

리전에서 멀리 떨어진 사용자가 이 기관에 접근한다면 지연 시간은 높을 것이기 때문이죠

하나의 리전에 여러 AZ가 있으면 즉, 여기에 한 리전에 2개의 AZ가 있습니다

그렇기 때문에 고가용성을 가집니다 그러나 글로벌 지연 시간은 개선하지 않습니다 AZ끼리 가까이 있죠

AZ에서 멀리 떨어진 지점에서는 지연 시간이 길 것입니다

다음으로 액티브-패시브라고 부르는 다중 리전이 있습니다.

이 말은 2개의 리전이 있다는 뜻입니다. 각 리전은 하나 이상의 AZ가 있습니다

하나의 리전에는 EC2 인스턴스가 액티브되거나 애플리케이션이 액티브될 것입니다.

이 말은 사용자가 어디에 있든지 액티브된 리전의 EC2 인스턴스에 읽고 쓸 수 있다는 뜻입니다.

다른 EC2는 패시브인데요 이 말은 액티브 리전과 패시브 리전 간 데이터 복제가 일어나 사용자는 패시브 리전에서 읽을 수 있습니다 그러나 패시브 리전에 쓸 수는 없죠 액티브-패시브라고 부르는 이유입니다.

액티브-패시브를 사용하면, 전 세계에 많은 리전이 있고 모두가 패시브라면 읽기 지연 시간을 개선합니다

전 세계에 데이터를 복제하였기 때문에 지연 시간이 줄어들었습니다

그러나 쓰기의 경우, 여전히 중앙 리전으로 가야 합니다글로벌 수준에서 쓰기는 여전히 지연 시간이 높습니다.

마지막으로 액티브-액티브가 있습니다

각 EC2 인스턴스가 쓰고 읽을 수 있습니다 2개의 인스턴스에서 복제가 일어나고 읽기 지연 시간을 개선하고

글로벌 수준의 쓰기 지연 시간도 마찬가지입니다

이제 애플리케이션이 한 리전에서 많은 것을 하므로 설정하기 더 어렵습니다

예를 들어, 액티브-액티브를 설정할 수 있는 데이터베이스는 DynamoDB 글로벌 테이블로 이전에 본 적 있습니다.

AWS 글로벌 애플리케이션 요약

먼저 글로벌 DNS Route 53을 살펴보았습니다 사용자를 가까운 배포로 라우팅하여 지연 시간을 최소화하는 좋은 방법으로 재해 복구 전략을 정의할 때 유용합니다.

레코드를 만드는 방법을 배웠고 호스트 이름에서 IP로 리디렉션하는 법 등을 배웠습니다.

CDN CloudFront를 배웠죠 Amazon S3와 실제로 연결해 보았습니다 기본적으로 애플리케이션 데이터를

어떤 AWS 엣지 로케이션에 복제하였습니다 이는 지연 시간을 줄여줍니다

추가로 CloudFront에서 일반적인 요청을 캐시에 저장했습니다 사용자 경험을 개선하고 지연 시간을 줄였죠

다음으로 S3 Transfer Acceleration입니다 이는 Amazon S3로 업로드하고 다운로드할 때 AWS 엣지 로케이션을 이용하여

속도를 빠르게 해주었습니다

Global Accelerator는 글로벌 네트워크인 엣지 로케이션을 사용하여 글로벌 애플리케이션의 가용성과 성능을 개선하였습니다

그리고 Outposts를 다뤘습니다 전체 인프라를 확장하는 방법이죠

Outposts를 통해 데이터 센터에 Outposts 랙을 배포하여 AWS 서비스를 확장합니다

온프레미스 데이터 센터 내에 AWS 클라우드가 있습니다

WaveLength는 AWS 서비스를 5G 네트워크의 엣지로 올립니다 애플리케이션의 지연 시간이 아주 낮아집니다.

마지막으로 로컬 영역입니다 로컬 영역은 AWS 리소스를 사용자와 가까운 데이터베이스 스토리지에서

컴퓨팅하도록 지원합니다

예를 들어 보스턴, 댈러스, 마이애미, 시카고 등등에서 말이죠 미국이나 세계 어느 특정 리전에서 로컬 접근이 빨라야 하는,

지연 시간에 민감한 애플리케이션일 때 정말 좋습니다

AWS CCP 자격증 - 9 (인프라 배포, 관리)

곰종 — Sun, 7 Jul 2024 17:15:36 +0900

CloudFormation

CloudFormation는 AWS에서 중요한 기술입니다.

AWS 인프라의 모든 리소스에 대해 윤곽을 잡아주는 선언적인 방식이기 때문입니다.

구체적인 예시를 드리자면 CloudFormation에서 보안 그룹을 원하고 2개의 EC2 인스턴스가 해당 보안 그룹을 사용합니다.

또한 S3 버킷을 원하고 로드 밸런서를 모든 머신 앞에 두고 싶습니다

그러면 CloudFormation이 자동으로 여러분을 위해 순서에 맞게, 여러분이 지정한 구성에 맞춰 이것들을 만들어줍니다.

CloudFormation을 사용해서 얻는 혜택은 다양합니다

먼저 모든 인프라가 코드로 되어 있습니다 즉, 사용자는 절대로 리소스를 수동으로 만들지 않습니다. (제어하기에 훌륭)

이 말은 AWS 클라우드가 어떻게 동작할지 변경을 할 때마다 코드 리뷰를 통해 검토해야 한다는 뜻입니다.

클라우드에서 작동하기 좋은 방식입니다

거기에 비용 절감 효과가 있습니다 이 스택 내 각 리소스는 스택 내 만들어진 모든 다른 리소스와 비슷한 태그를 갖게 됩니다 따라서 CloudFormation 템플릿을 사용하여 쉽게 리소스의 비용을 추정할 수 있습니다,

또한, CloudFormation 덕분에 절약 전략을 가질 수 있습니다

예를 들어, 어떤 환경에서는

오후 5시에 모든 템플릿을 자동으로 삭제할 수 있습니다. 이는 템플릿과 연결된 모든 리소스를 삭제하고 오전 9시나 8시에 안전하게 다시 만듭니다. 따라서 비용을 절약할 수 있습니다 오후 5시와 오전 8시 사이에 리소스가 없기 때문입니다

CloudFormation에서는 리소스를 만들고 지우기가 쉽습니다.

그리고 생산성도 있습니다 즉시 인프라를 삭제하고 다시 만들 수 있기 때문입니다.

템플릿에 관한 도식도 만들어 줍니다

선언적 프로그래밍도 있습니다 EC2 인스턴스에 먼저 DynamoDB 테이블을 만들어야 하는지 모든 것을 같이 만들어야 하는지 파악할 필요가 없습니다.

CloudFormation 템플릿은 어떻게 이것들을 처리할지 충분히 알고 있습니다

CloudFormation에서 이미 있는 것을 다시 만들 필요가 없죠

즉, 웹에 있는 기존 템플릿을 이용할 수 있습니다

공식 문서를 사용할 수 있고 CloudFormation은 대다수의 AWS 리소스를 지원합니다.

지원되지 않는 리소스는 사용자 정의 리소스를 사용할 수 있습니다

CloudFormation은 AWS 인프라의 기반으로, 코드화됩니다

온라인 WordPress CloudFormation 스택을 가져왔는데,

디자이너로 가서 무엇을 보여주는지 확인해 보았습니다 이 도식인데,

보이는 것처럼 다양한 구성 요소가 만들어졌습니다

예를 들어, 보안 그룹이 있고 ALBListener, 실행 구성, 로드 밸런서, RDS용 데이터베이스 인스턴스, 오토 스케일링 그룹이 있습니다

CloudFormation은 도식을 만들 만큼 똑똑하고 모든 구성 요소 간 모든 관계를 만들 수 있습니다,

모든 리소스와 관계가 보입니다

시험 측면에서는 CloudFormation은 코드로 인프라를 가질 때 아키텍처를 다른 환경, 리전, 심지어 다른 AWS 계정에서

반복해야 할 때 사용됩니다

이런식으로 코드를 통해 EC2 인스턴스를 생성합니다

AWS Clood Develoment Kit (CDK)

이는 익숙한 프로그래밍 언어로 클라우드 인프라를 정의하는 방식입니다.

예를 들어, YAML 형식이라서 CloudFormation을 직접 사용하지 않고

JavaScript, TypeScript 또는 Python이나 Java나 .NET을 사용하고 이러한 언어로 클라우드 인프라를 작성하고자 한다면

CDK를 통해 가능합니다

이런 프로그래밍 언어로 인프라를 작성하면 CDK를 통해 코드가 JSON 또는 YAML 형식으로

CloudFormation 템플릿에 컴파일 됩니다

그래서 인프라와 애플리케이션의 런타임 코드를 함께 배포할 수 있죠

동일한 언어를 공유하기 때문입니다

람다 함수에 유용하고

ECS와 EKS의 도커 컨테이너에 유용합니다

Python을 프로그래밍 언어로 선택해 예시를 살펴보겠습니다

CDK 애플리케이션을 Python으로 작성하고 다른 AWS 서비스를 위한 DynamoDB 테이블의 람다 함수를 정의합니다.

이제 CDK CLI를 사용하는 이 CDK 애플리케이션은 CloudFormation 템플릿으로 변환되고

생성된 CloudFormation 템플릿은 CloudFormation에서 인프라 배포에 적용됩니다

프로그래밍 언어를 사용해서 클라우드 인프라를 사용하는 것입니다

예시로 형식 안정(type-safe)을 갖도록 하거나 익숙한 구조 등을 갖도록 하고 빠르게 수행하거나 코드를 재사용하도록 하고For 루프와 같은 것을 갖도록 하기 때문입니다

CDK 코드의 예시를 살펴보겠습니다

JavaScript 또는 TypeScript을 사용한 예시입니다 정의된 VPC와 ECS 클러스터가 있고

Fargate 서비스용 ALB도 있습니다

이 3가지가 CDK CLI로 사용 가능한 CloudFormation 템플릿에 컴파일 되어 업로드와 배포를 할 수 있습니다

Beanstalk

AWS에서 웹 애플리케이션을 배포했을 때 일반적으로 3-티어 아키텍처라는 아키텍처를 따릅니다.

따라서 사용자는 여러 AZ에 있을 수 있는 로드 밸런서와 통신하고 로드 밸런서는 트래픽을

오토 스케일링 그룹에서 관리하는 여러 EC2 인스턴스에 보냅니다

그러면 EC 인스턴스는 데이터를 저장해야 하므로 관계형 데이터베이스인 Amazon RDS와 같은 데이터 베이스를 사용해 데이터를 읽고 씁니다

인 메모리 데이터베이스나 인 메모리 캐시가 필요하면 일래스티 캐시를 사용해 세션 데이터나 캐시 데이터를 저장하고 검색합니다 이런 아키텍처는 손쉽게 수동으로 복제할 수 있습니다

Elasic Beanstalk

일래스틱 Beanstalk은 AWS에 애플리케이션을 배포하는 개발자 중심 관점으로

Beanstalk 이면에는 이전과 동일한 구성 요소가 있습니다

EC2 인스턴스와 오토 스케일링 그룹 리고 ELB와 RDS 데이터베이스 등

하지만 Beanstalk는 개발자 중심적으로 모든 것을 이해하기 쉽도록 한 번에 볼 수 있습니다.

전체 구성 요소를 여전히 제어할 수 있지만 모두 Beanstalk 내에 있는 것입니다

클라우드의 관점에서 Beanstalk은 서비스형 플랫폼 혹은 PaaS입니다

우리는 코드가 중요하니 크게 신경 쓸 필요 없습니다

요약하자면, Iaas인 서비스형 인프라를 살펴봤고 PaaS이자 서비스형 플랫폼인 Beanstalk을 살펴봤습니다

그리고 AWS의 다른 서비스에 관한

서비스형 소프트웨어도 살펴볼 예정입니다 Beanstalk는 무료이지만 기본 인스턴스 비용이 있습니다

마지막으로 시험에는 상태 모니터링에 관해 출제됩니다

Beanstalk에는 서비스 자체에서 사용할 수 있는 전체 모니터링 suit이 있습니다

그리고 CloudWatch에 지표를 푸시할 Beanstalk의 각 EC2 인스턴스에 상태 에이전트가 있고

Beanstalk 내부에서 지표를 확인하고 모니터링 등을 할 수 있죠

또한, 애플리케이션 상태를 확인해 상태 이벤트를 게시합니다

여기 보이는 사진 Beanstalk에서

애플리케이션 상태의 모니터링 방식입니다

CodeDeploy

CloudFormation과 Beanstalk을 살펴봤으니 CodeDeploy를 살펴보겠습니다.

CodeDeploy도 애플리케이션을 자동으로 배포하는 방식입니다

차이점이라면 CodeDeploy가 조금 더 관대하다는 것인데

Beanstalk이나 CloudFormation을 사용하지 않아도 됩니다 완전히 독립적입니다.

CodeDeploy로 버전 1의 애플리케이션을 버전 2로 업그레이드 할 수 있고

CodeDeploy에서 그 방법을 파악합니다

CodeDeploy는 2가지로 실행됩니다

먼저, EC2 인스턴스로 실행되며 많은 EC2 인스턴스를 v1에서 v2로 업그레이드 할 수 있습니다

또한, 온프레미스 서버에서 실행됩니다

온프레미스에 서버가 있고 애플리케이션을 버전 1에서 버전 2로 업그레이드 하려면 CodeDeploy로 가능합니다

그래서 CodeDeploy를 하이브리드 서비스라고 합니다 온프레미스와 EC2 인스턴스에서 모두 실행되기 때문입니다

CodeDeploy는 모든 서버에서 실행되지만 서버를 미리 프로비저닝 해야 하고 업그레이드를 지원하는 CodeDeploy 에이전트를 설치하도록 구성해야 합니다 CodeDeploy는 AWS에서 꽤 유용한 서비스입니다

온프레미스 서버 또는 EC2 인스턴스로 애플리케이션을 배포하는 방식과 동일한 방식으로 온프레미스에서 AWS로

전환할 수 있기 때문입니다

기억할 것은 EC2 인스턴스 애플리케이션과 온프레미스 서버 애플리케이션을 단일 인터페이스에서 자동으로

버전 1에서 버전 2로 업그레이드 가능하다는 것입니다

AWS CodeCommit

AWS에서 코드와 연관된 도구를 살펴보겠습니다

애플리케이션 코드를 서버로 푸시하기 전에 어딘가에 저장해야 하는데 개발자들은 주로 코드 리포지토리를 선택하고

Git 기술을 사용해 백업됩니다

가장 유명한 공용 서비스는 GitHub이지만

AWS에도 경쟁 서비스가 있는데 바로 CodeCommit입니다

CodeCommit은 AWS의 버전 관리 리포지토리에 코드를 저장하는 방식입니다

따라서 Git을 기반으로 한 리포지토리입니다

CodeCommit을 기반으로 하는 이유가 뭘까요?

Git 기반의 리포지토리가 있으면 개발자들이 코드로 협업하는 것이 정말 쉽습니다.

코드 변경 사항은 자동으로 버전 관리되고 롤백이 가능합니다

CodeCommit의 장점은 완전 관리형 코드 리포지토리이며 확장성이 있고 고가용성이면서 AWS 계정 내에 있어서

프라이빗하고 안전하며 모든 AWS 서비스와 통합된다는 것입니다

AWS CodeBuild

CodeBuild 서비스를 살펴보겠습니다

이름에서 알 수 있듯이 클라우드에서 코드를 설계하도록 합니다

소스 코드가 컴파일 되고 테스트가 실행되며 출력값으로 패키지가 생성되는데

패키지는 예를 들어 CodeDeploy로 서버에 배포된 준비가 되어 애플리케이션을 실행하도록 합니다

도표로 확인해 보겠습니다

코드가 CodeCommit에 있고 CodeBuild는 CodeCommit에서 코드를 검색하고

정의해야 하는 스크립트를 실행하고 코드를 설계해서 배포 준비된 Artifact를 얻습니다.

왜 CodeBuild를 사용할까요?

완전 관리형이며 서버리스이기 때문이며 지속적으로 확장 가능하고 고가용성이며 안전하면서 종량 과금제가 있기 때문인데 종량 과금제는 코드 설계 시간에 대한 비용을 지불하는 것입니다 관리할 서버는 없습니다

즉, 사용자는 코딩만 신경 쓰면 되고 CodeCommit 리포지토리에 코드 업데이트를 푸시 할 때마다 AWS 내 서비스에서 코드 설계에 걸리는 시간만 확인하면 됩니다

AWS CodePipeline

다음은 CodePipeline입니다 CodeCommit과 CodeBuild을 어떻게 연결할까요?

CodePipeline으로 연결할 수 있습니다

CodePipeline은 코드가 자동으로 프로덕션에 푸시 되도록 다른 단계를 조정하는 방식입니다

즉, 코드를 가져오는 파이프라인을 정의하고 설계와 테스트를 하고 일부 서버를 프로비저닝 해서 해당 서버에 애플리케이션을 배포하는 것입니다

더 복잡할 수도 있죠 이러한 단계를 조정하려면 파이프라인 도구가 필요한데 이것이 바로 CodePipeline입니다

CICD라는 용어를 들어 보셨는지 모르겠지만 지속적 통합과 지속적 전달이라는 뜻입니다

전체 개념은 개발자가 리포지토리로 코드를 푸시할 때마다 구축되어 테스트 되며 일부 서버에 배포되는 것입니다

CodePipeline를 살펴보죠 오케스트레이션(orchestration) 계층인 코드가 있고 CodeCommit에서 코드를 가져와서CodeBuild로 구축하고 CodeDeploy로 배포를 결정한 뒤 일례로 일래스틱 Beanstalk 환경으로 배포됩니다

이는 파이프라인 설계의 한 방법으로 다양한 방법이 있습니다

CodePipeline 사용 이유는 완전 관리형이기 때문입니다 많은 서비스와 호환되는데 CodeCommit, CodeBuild CodeDeploy, 일래스틱 Beanstalk, CloudFormation, GitHub 등이며 다른 타사 서비스와 사용자 플러그인과도 호환됩니다

그리고 빠르게 전달되며 업데이트도 빠릅니다

AWS 내의 CICD 서비스의 핵심으로 파이프라인의 오케스트레이션에 관한 것이 시험에 출제되면 AWS CodePipeline을 생각하면 됩니다

AWS CodeArtifat

AWS CodeArtifact를 살펴보겠습니다 개발자가 생성한 소프트웨어 패키지 대게 서로 의존적으로 설계되는데

소프트웨어 패키지의 아키텍처와 같은 것이며 코드 종속성이라고도 합니다

그리고 이 종속성을 저장하고 검색하는 것을 Artifact 관리라고 합니다

기존에는 Amazon S3나 EC2 인스턴스의 사용자 지정 소프트웨어에서 자체 Artifact 관리 시스템을 설정해야 했으며 복잡할 수 있습니다

그래서 안전하고 확장 가능하며 비용 효율적인 소프트웨어 배포에 관한 Artifact 관리 소프트웨어인

AWS CodeArtifact가 출시됐습니다

지금은 자체 인프라를 설정하는 대신 CodeArtifact를 사용할 수 있고 개발자들이 사용하는 일반적인 종속성 관리 도구인Maven, Gradle, npm, yarn, twine, pip 그리고 NuGet이 CodeArtifact와 통신해 이러한 코드 종속성을 저장하고 검색합니다

따라서 개발자는 기본적으로 이러한 종속성을 저장하고 검색하는 안전한 장소를 갖게 됩니다

이는 코드를 CodeCommit으로 푸시하면 CodeBuild에서 설계하고 CodeArtifact에서 바로 종속성을 검색할 수 있습니다

시험에 관련해서도 팀이 Artifact 관리 시스템이나 코드 종속성을 저장할 장소가 필요할 경우에 CodeArtifact을 떠올리면 됩니다

AWS CodeStar

AWS CodeStar를 살펴보겠습니다 CodeStar는 통합 UI로 소프트웨어 개발 작업을 한곳에서 쉽게 관리할 수 있습니다

그러면 CodeCommit과 CodeBuild 그리고 CodeDeploy를 어떻게 설정할까요?

CodePipeline과 모두 통합해야 할까요?

복잡해 보이지만 CodeStar로 이 문제를 해결할 수 있습니다

원스톱 숍을 제공하여 개발 프로젝트를 시작하도록 하고 자동으로 이 깔끔한 대시보드를 제공합니다

그리고 대시보드와 백그라운드에서는 CodeCommit 리포지토리와 CodeBuild 설계 프로세스 CodeDeploy, CodePipeline이 생성되고 모니터링 등도 실행됩니다

Beanstalk 환경이나 EC2 인스턴스 등에서도 빠르게 시작할 수 있습니다

장점은 AWS Cloud9로 클라우드에서 바로 코드를 수정할 수 있다는 것입니다

따라서 이 모든 것이 CodeStar를 핵심 서비스로 만들고 개발자가 CICD의 모범 사례를 사용해서 빠르게 개발을 시작하도록 합니다 시험에 대비해서는 여기까지 알면 됩니다

AWS Cloud9

AWS Cloud9을 살펴보겠습니다 Cloud9은 클라우드 IDE로 통합개발환경의 줄인말이며

클라우드에서 바로 코드를 읽고, 실행하고, 디버깅할 수 있습니다.

코드 편집기처럼 보이지만 클라우드에서 실행되며 웹 브라우저에서 실행됩니다.

IntelliJ, Visual Studio Code와 같은 유명한 기존 IDE는 컴퓨터에 다운로드 되고 사용 전에 설치되지만

클라우드 IDE는 Chrome, Firefox Internet Explorer 등의 웹 브라우저에서 사용 가능합니다.

이는 어떤 설정도 없이 사무실이나 집 또는 인터넷에 액세스 가능한 모든 곳에서 프로젝트 작업을 할 수 있고

빠르게 작업으로 돌아올 수 있다는 의미입니다

또한, 실시간으로 코드 협업을 하고 페어(pair) 프로그래밍을 할 수 있도록 합니다.

오른쪽에서 보시는 것처럼 3명이 Cloud9에서 같은 시간에 같은 코드로 협업할 수 있죠

이제 IDE를 보면 Cloud9을 생각하세요

AWS SSM (Systems Manager)

AWS System Manager인 SSM을 살펴보겠습니다

SSM은 EC2 인스턴스와 온프레미스 시스템을 규모에 맞게 관리하도록 합니다.

온프레미스와 AWS 모두를 관리하는 방법인 것입니다

그래서 하이브리드 AWS 서비스라고 합니다 SSM으로 복잡한 많은 작업을 실행할 수 있습니다

Systems Manager이기 때문에 인프라 상태에 관한 운영 인사이트도 얻을 수 있고

10개 이상의 상품에 액세스할 수 있습니다

시험에 대비해 모든 상품을 살펴볼 필요는 없지만

하지만 가장 중요한 상품과 기능은 규정 준수를 강화하기 위해서 서버와 인스턴스에 패치를 자동으로 적용할 수 있습니다

또한, SSM에서 바로 전체 서버에 명령을 실행할 수 있고 SSM 파라미터 스토어로 기본 구성을 저장할 수 있습니다.

그리고 SSM은 Windows 서버와 Linux 서버에서 실행됩니다

따라서 시험에 EC2 인스턴스 플릿이나 온프레미스 서버의 패치가 나오면 SSM을 생각하면 되고 모든 서버에 전반적으로명령을 실행하는 경우에도 SSM을 생각하면 됩니다

SSM 원리를 통해 더 확실히 이해할 수 있습니다

SSM 서비스는 자체적으로 실행되지만 먼저, 제어하는 시스템에 SSM 에이전트를 설치해야 합니다.

백그라운드에서 실행될 작은 프로그램입니다

AWS에서 Amazon Linux AMI나 Ubuntu AMI를 사용하면 기본적으로 설치됩니다.

EC2 인스턴스와 온프레미스 가상 머신에서는 전체에 SSM 에이전트를 설치해야 하며

SSM 에이전트는 AWS의 SSM 서비스에 다시 리포트를 전달합니다

보시는 것처럼 EC2 인스턴스와 온프레미스 VM에 연결됐고 이렇게 하이브리드 서비스가 됩니다

SSM으로 인스턴스를 제어할 수 없는 경우는 에이전트 문제일 가능성이 높습니다.

이제 서버와 EC2 인스턴스에 에이전트가 설치됐고 SSM 서비스를 사용해 전체 서버에 명령을 실행하거나

전체를 한 번에 패치하거나 일관되게 구성할 수 있습니다 이것만 기억하면 시험에 대비할 수 있습니다

System Manager Parameter Store

System Manager Parameter Store에 대해 알아보겠습니다.

구성 데이터나 암호를 안전하게 AWS에 저장해주는 방식인데요

API 키나 비밀번호, 구성 데이터 등 원하는 것을 모두 저장할 수 있습니다

서버가 필요없습니다 즉, 제공할 게 없다는 뜻이죠 확장도 가능합니다

한번에 여러 API 호출에 응답할 수 있고요 지속적이고 사용도 간편합니다

무엇보다 안전합니다, IAM을 사용해 Parameter Store에 있는 각 파라미터의 액세스를 관리할 수 있기 때문이죠

게다가 구성 데이터가 진화할 수 있고 파라미터도 진화할 수 있습니다

그래서 버전 추적과 선택적 암호화가 가능합니다

하지만 Parameter Store에서 우리 애플리케이션이나 사용자는 일반 텍스트 구성 또는 암호화된 구성 데이터를

입력할 수 있는데 이때는 KMS로 암호화됩니다 그래서 한 곳에서 수많은 애플리케이션 구성 데이터를 관리하고 중앙 집중식으로 저장할 수 있습니다

배포 정리

첫 번째로 AWS 전용 도구인 CloudFormation이 있습니다

이것은 Infrastructure as Code를 가능하게 하며 거의 모든 AWS 리소스와 호환된다는 특징이 있었습니다.

이를 이용하여 템플릿을 제작하고 그 템플릿은 AWS에 인프라를 배포하는 데 사용할 수 있습니다

마찬가지로 AWS 전용인 Beanstalk가 있습니다 다양한 지역과 사용자에서 모두 이 템플릿을 사용할 수 있도록 함으로써

진정한 반복 가능 인프라로 만들수 있습니다.

Elastic Beanstalk는 서비스형 플랫폼, 즉 PaaS(Platform as a Service)로

특정 프로그래밍 언어 또는 Docker로 제한됩니다 알려진 아키텍처를 이용하여 코드를 지속적으로 배포할 수 있습니다

예를 들어 Load Balancer와 EC2 인스턴스, 그리고 RDS 데이터베이스를 조합할 수 있습니다

CodeDeploy는 어떤 애플리케이션도 서버로 배포하고 업그레이드할 수 있습니다

이는 예를 들어 AWS에서 EC2 인스턴스에 적용할 수도 있지만 회사의 사내 인프라에도 적용 가능합니다

CodeDeploy가 하이브리드 유형의 서비스라 불리는 이유입니다

Systems Manager 역시 하이브리드 서비스입니다 이것을 이용하면 모든 서버에서 규모를 조정해 가며 패치, 환경설정, 그리고 명령 실행이 가능합니다

배포 서비스에 관한 내용은 여기까지입니다

이제 개발자 서비스에 대하여 이야기하여 봅시다

시험에도 나오는 CodeCommit에 대해서 전에 배웠습니다

이것은 비공개 Git 저장에 코드를 저장하는 서비스로 이를 통하여 version control(버전 관리)가 되는 코드 리포지토리를 가질 수 있습니다

CodeBuild는 AWS에서 코드를 서버 없이 구축하고 테스트하도록 해 줍니다

CodeDeploy는 서버에 코드를 배포할 수 있도록 합니다 CodeDeploy는 배포와 개발자 서비스에서 모두 소개하였습니다

두 유형 모두로 볼 수 있기 때문입니다

CodePipeline은 AWS 내부에서 파이프라인을 조직하기 위하여 필요합니다 즉 코드를 짜는 것부터 구축, 테스트

배포, 그리고 공급까지 모든 곳에 쓰입니다

CodeArtifact는 AWS에서 소프트웨어 패키지와 종속성을 저장할 때 필요하며

CodeStar는 통합적 관점을 제공하고(UI)

OneStopShop은 개발자에게 CI/CD(지속적 통합/배포)와 직접 코딩이 가능케 해줍니다

그리고 마지막으로 클라우드 IDE인 Cloud9가 있습니다 이것은 즉 통합 개발 환경입니다

이것을 이용하면 웹 브라우저에서 직접 코드를 수정할 수 있으며

콜라보레이션 기능을 일부 가지고 있어 페어 프로그래밍 등을 할 수 있습니다

다음으로는 CDK가 있습니다 프로그래밍 언어를 이용하여 클라우드 인프라를 정의하는 데 사용됩니다

예를 들어 JavaScript, TypeScript, Java, Python 등등을 이용할 수 있습니다

정의한 내용은 CloudFormation 템플릿으로 번역됩니다

AWS CCP 자격증 - 8 (ECS)

곰종 — Sun, 7 Jul 2024 00:07:33 +0900

ECS

Docker?

도커(Docker)를 먼저 짚고 넘어가 보죠

도커에 대해서는 이미 들어보셨겠지만 여기서는 단순하게만 살펴볼 겁니다

도커란 앱 배포를 위한 소프트웨어 개발 플랫폼입니다

이전에는 Linux에 애플리케이션을 설치하고 그에 따라 작동하는 방식이었지만 도커를 사용하면 컨테이너에 앱을 패키징하게 됩니다

여기서 컨테이너란 모든 운영 체제에서 쉽게 실행할 수 있다는 점이 특별하다고 할 수 있겠습니다

앱이 컨테이너에 패키징되면 위치에 상관없이 매번 같은 방식으로 실행됩니다.

따라서 어떤 기계든 상관없이 호환성 문제가 없고, 동작을 예측할 수 있습니다 작업량도 적으며 유지 보수와 배포가 쉽죠

모든 프로그래밍 언어로 작업할 수 있으며 운영 체제나 기술에도 구애받지 않습니다

도커를 사용하면 몇 초 만에 컨테이너를 스케일링 업 다운이 가능하죠

이로 인해 오늘날 애플리케이션 배포에 있어서 도커가 아주 강력한 도구로 떠오른 겁니다

EC2 인스턴스에서 도커를 살펴보면

Java 코드로 실행하는 도커

NodeJS 코드를 실행하는 도커 MySQL 데이터베이스를 실행하는 도커 Java를 실행하는 도커 등이

모두 같은 EC2 인스턴스에 있습니다

따라서 도커 컨테이너에 애플리케이션을 패키징하기만 하면

EC2 인스턴스에서 실행하는 것이 아주 쉬워질 겁니다

도커 이미지는 따로 생성해 주어야 하는데

이는 컨테이너가 실행되는 방식으로

도커 리포지토리라는 장소에 저장됩니다

이 주소에서는 공용 도커 리포지토리인 도커 허브를 이용할 수 있는데 여기서 여러 기술과 운영 체제에 대한 기본 이미지를 찾아볼 수 있습니다.

Linux 운영 체제인 Ubuntu와 데이터베이스 기술인 MySQL NodeJS, Java 등 프로그래밍 언어에 대해서 찾을 수 있죠

본 섹션에서 볼 사설 도커 리포지토리 Amazon ECR에는 개인 도커 이미지를 저장할 수 있습니다.

좀 더 심화된 내용입니다만, 도커와 가상 머신 중 어느 쪽을 사용할까요?

도커는 시각화 기술에 해당하지만 정확히는 아닙니다 리소스를 호스트와 공유하게 되는데

즉 하나의 서버에 여러 컨테이너를 둘 수 있다는 의미가 되죠

EC2와 도커를 비교해 보면 쉬울 겁니다 AWS 상에는 인프라가 있고 호스트 운영 체제 그리고 하이퍼바이저가 존재합니다하이퍼바이저에는 액세스가 없죠

여기에 EC2 인스턴스가 생성되면 게스트 운영 체제 위에 애플리케이션이 들어갑니다.

또 다른 EC2도 이처럼 생성되며 세 번째 EC2 인스턴스도 이처럼 인식될 겁니다

EC2 인스턴스를 만들 때에 수행되는 작업이라고 할 수 있죠

하지만 도커의 경우에는 인프라가 있고

EC2 인스턴스인 호스트 OS 그다음에 도커 데몬이 위치합니다 도커 데몬이 실행되면 그 위에 여러 컨테이너를 실행할 수 있습니다.

이들은 아주 가볍고 패키징된 상태가 아니며 전체 운영 체제나 가상 머신 없이 실행됩니다.

도커를 다용도로 활용하고 스케일링이나 실행이 쉬운 이유라고 할 수 있죠

이렇게 도커의 개요를 살펴봤습니다

ECS

ECS = Elastic Container Service

도커 컨테이너를 실행할 때 사용합니다.

동작하기 위해서는 어딘가에서 도커 컨테이너를 실행해야 하는데 ECS에서는 반드시 여러분이 프로비저닝해야 하며

인프라를 자체적으로 유지해야 합니다

그 말은 EC2 인스턴스를 사전에 만들어야 한다는 뜻입니다.

AWS가 여러분을 위해 컨테이너를 시작하고 중지하는 것을 책임지며

사용자가 웹 애플리케이션을 ECS에서 만들기 원한다면

애플리케이션 밸런서와의 통합을 책임집니다

그림에서처럼 여러 EC2 인스턴스가 있고 우리는 사전에 이 EC2 인스턴스를 만들어야 합니다.

이들은 ECS 서비스에 의해 다른 컨테이너에서 실행됩니다

ECS 서비스는 새로운 도커 컨테이너를 가질 때마다 어떤 EC2 인스턴스를 도커 컨테이너에 위치할지 알고 있습니다.

따라서 시험에서 AWS 도커 컨테이너 실행이 나온다면 ECS를 생각하세요

Fargate

Fargate 또한 AWS에서 도커 컨테이너를 실행할 때 사용합니다

그러나 Fargate에서는 인프라를 프로비저닝할 필요가 없습니다

EC2 인스턴스를 만들 필요가 없고 관리할 필요가 없죠

AWS가 제공하는 매우 간단한 서비스입니다

이는 서버리스 서비스인데요 우리가 관리할 서버가 없기 때문입니다.

AWS는 우리가 필요한 컨테이너를 각 컨테이너의 CPU와 RAM 사양에 맞게 실행시켜 줍니다.

따라서 Fargate를 사용하는 것이 훨씬 간편합니다.

Fargate가 여기 있습니다 여기 새로운 도커 컨테이너가 Fargate에서 실행됩니다

Fargate는 자동으로 이 컨테이너를 실행해 줍니다.

어디에 있는지 우리가 알지 못하지만 실행될 것입니다

Fargate 관련 기본 아이디어는 어떤 EC2 인스턴스도 관리하지 않기 때문에 쉽게 사용할 수 있습니다.

ECS에서는 EC2 인스턴스를 먼저 만들었지만 Fargate에서는 그럴 필요가 없죠

러나 두 개의 서비스 모두 AWS에서 도커 컨테이너를 실행하게 해줍니다

ECL (Elastic Container Registry)

마지막으로 AWS에서 실행되기 위해서

도커 이미지를 저장해야 하는데요

이때 컨테이너 레지스트리가 필요합니다

여기에 ECR을 사용할 수 있는데요 바로 일래스틱 컨테이너 레지스트리입니다

AWS의 사설 도커 레지스트리입니다

도커 이미지를 저장하여 ECS 서비스나 Fargate 서비스에 의해 실행됩니다.

두 번째 예시로 ECR과 Fargate가 있습니다 애플리케이션의 이미지를 Amazon ECR에 저장하고자 합니다.

그러면 Fargate는 이 이미지를 살펴보고 이들로부터 컨테이너를 만들어 Fargate 서비스에서 직접 실행합니다.

여기에서 한 컨테이너, 여기에서 한 컨테이너가 될 수 있죠

그러나 이것은 ECR이기 때문에 여러 이미지를 가질 수 있고 Fargate에 여러 컨테이너를 만들 수 있습니다.

ECS, Fargate, ECR 비교해서 기억하시면

시험에서 관련 문제를 모두 푸실 수 있으실 겁니다

서버리스란?

서버리스가 무엇일까요? 서버리스는 귀에 익지만 개발자가 서버를 관리하지 않는 새로운 패러다임입니다.

그저 가장 잘하는 것을 합니다 코드 또는 함수를 배포하는 일이죠

처음에 서버리스는 AWS Lamdba와 함께 서비스형 함수로 만들어졌습니다.

즉, 코드를 배포하고 각 함수는 Lambda 서비스에 의해 독립적으로 실행됩니다.

그러나 요즘 들어서는 서버리스라는 뜻은 "관리되는 어떤 것"으로 여기에 사용자에 의한 서버 관리가 포함됩니다

즉, 서버리스 데이터베이스, 메시지, 스토리지 등을 포함합니다 따라서 서버리스는 서버가 없다는 뜻이 아닙니다

이면에 서버가 존재합니다 그렇지 않고서 서비스가 동작할 수 없죠

이 말은 최종 사용자 입장에서 서버를 관리하거나 프로비저닝하거나 심지어 볼 수 없다는 뜻입니다.

Amazon S3가 예시중 하나입니다.

우리가 스토리지 계층으로 사용했지만 어떤 서버도 관리하지 않았기 때문입니다.

Amazon S3는 무한대로 스케일링할 수 있고 서버가 없습니다. 그저 파일을 업로드하면 됐습니다.

DynamoDB도 마찬가지입니다 DynamoDB에서 테이블을 만들었죠 테이블을 위해 서버를 프로비저닝하지 않았습니다.

서버와 테이블은 수신하는 로드에 맞게 오토 스케일링할 수 있었죠 따라서 서버리스 서비스입니다.

도커 컨테이너를 실행할 때 사용하는 Fargate도 있습니다.

ECS에서는 도커 컨테이너를 실행하기 위해 EC2 인스턴스를 만듭니다 따라서 서버리스가 아니죠

그러나 Fargate에서는 도커 컨테이너를 보내면 Fargate에서 자동으로 실행 방법을 찾아 실행합니다 이 때문에 서버리스 서비스가 됩니다

AWS Lambda

EC2 인스턴스를 이용하면 클라우드에 가상 서버를 갖게 됩니다.

그러나 메모리의 용량과 CPU 성능에 제한을 받게 됩니다.

우리가 사용하지 않을 때도 지속해서 실행됩니다. 스케일링하고 싶을 때는 오토 스케일링 그룹을 사용합니다.

이 말은 시간이 지남에 따라 서버를 추가하거나 제거한다는 뜻인데 때때로 오래 걸리거나 구현이 복잡할 수 있습니다

Lambda에서는 이를 새롭게 생각해 볼 수 있습니다

이 경우, 서버가 필요하지 않고 가상 함수를 가지게 됩니다 이 함수들은 시간에 제한을 받는데 짧은 유형의 실행을 위한 것입니다

수요에 따라 실행함으로 함수를 실행할 때마다 실행될 것입니다

함수가 필요하지 않다면 실행하지 않을 것이고 이를 위해 구축하지 않을 것입니다.

스케일링이 필요하면 Lambda 서비스의 일부분으로 자동으로 됩니다

Lambda가 AWS에서 인기 있는 서비스가 된 이유입니다

Benefits of AWS Lambda

AWS Lambda를 사용하는 혜택은 먼저 가격 정책이 매우 쉽습니다.

요청 당 및 컴퓨팅 시간당 비용을 지불하게 되는데 프리 티어도 넉넉합니다.

매달 백만 개의 Lambda 호출과 40만 GB-초의 컴퓨팅 시간을 줍니다.

이 말은 괜찮은 서비스를 Lambda에서 공짜로 실행할 수 있다는 뜻입니다.

또한 전체 AWS 서비스와 통합됩니다 지금까지 본 많은 서비스와 통합할 수 있죠 중요한 점은 이벤트 기반이라는 것입니다

즉, 이벤트가 일어났거나 필요할 때 함수가 AWS에 의해 호출됩니다.

Lambda가 반응형 서비스인 이유입니다

시험에 중요하게 나옵니다 많은 프로그래밍 언어와 완전히 통합되며 CloudWatch를 통해 쉽게 모니터링할 수 있습니다.

CloudWatch가 무엇인지 배우지 않았지만 이는 AWS에서 솔루션을 모니터링합니다.

마지막으로 함수당 리소스를 가져오기 쉽습니다 함수당 10GB의 RAM을 사용할 수 있는데 RAM을 증가하면 CPU와 네트워크 품질 역시 개선되고 모든 것이 좋습니다

또한 Lambda는 많은 언어를 지원합니다.

Lambda의 사용사례

서버리스 섬네일 생성 서비스입니다

예를 들어, S3 버킷이 있고 여기에 이미지를 추가한다고 생각해보면, 사용자는 해변 이미지를 S3 버킷에 업로드합니다.

S3 버킷은 람다 함수를 트리거하고 이미지가 업로드되면 람다 함수가 이미지를 가지고 섬네일로 만들 것입니다.

섬네일은 Amazon S3으로 다시 보내죠 섬네일은 이미지의 작은 버전이죠

또는 섬네일 관련 메타데이터를 DynamoDB에 보낼 수도 있습니다.

이미지 크기, 이름, 생성 날짜 등등을 포함할 수 있습니다

이 모든 것은 완전히 이벤트 기반이고 완전히 서버리스입니다

S3에서 서버를 프로비저닝하지 않고 Lambda에서도 프로비저닝하지 않죠

DynamoDB에서도 마찬가지로 서버를 프로비저닝하지 않습니다.

좋은 패턴입니다 서버리스 섬네일 생성이 아주 잘 스케일링할 것이기 때문입니다.

서버를 프로비저닝하는 것과 서비스를 스케일링하는 것 관련해서 걱정할 필요가 없습니다.

Lambda에서의 다른 사용 사례로 서버리스 CRON 작업 생성이 있습니다.

CRON은 스케줄을 정의하게 해주는데 예를 들어, 매시간, 매일 또는 월요일마다 스케줄에 맞게 스크립트를 실행합니다.

기본값으로 CRON 작업은 Linux AMI에서 실행하는데 즉, Linux 머신이죠 그러나 서버리스이기 때문에

EC2 인스턴스를 프로비저닝할 수 없습니다 대신, CloudWatch Events 또는 EventBridge라는 것을 사용합니다.

매시간 람다 함수를 트리거하여 작업을 효과적으로 실행합니다 여기에 서버가 없는데, CloudWatch Events와 Lambda가 서버리스기 때문입니다.

람다 함수를 통해서 매시간 효과적으로 스크립트를 실행합니다 이것이 트리거입니다.

AWS Lambda Pricing (중요)

기본적으로 요금은 요청마다 지불합니다 (Pay per Calls)

처음 백만 번의 Lambda 호출은 무료입니다 또한 매우 저렴하죠. (프리티어)

그 이후에 백만 개의 요청당 0.20달러를 지불합니다

기간으로도 비용을 지불해야 하는데요 (Pay per duration)

프리 티어는 400,000GB-초의 컴퓨팅 시간이 무료로 제공됩니다.

즉, 함수가 1GB의 RAM을 갖는다면 400,000초입니다.

또는 함수가 120MB의 RAM일 때 320만 초입니다 그 이후로 600,000GB-초에 1달러를 지불합니다

결론은 AWS에서 Lambda를 실행하는 것은 매우 저렴합니다

따라서 서버리스 애플리케이션과 웹사이트를 실행할 때 인기 있는 서비스이기도 합니다.

CCP 시험에서는 호출과 기간에 따른 Lambda 가격을 알아야 합니다

Amazon API Gateway

시험에서는 서버리스 HTTP API를 구축하는 사용 사례로 나옵니다.

이 예시에서는 서버리스 기술이 있습니다

바로 Lambda를 사용하여 DynamoDB로부터 데이터를 읽고, 만들고, 업데이트하고 삭제합니다.

둘 다 서버리스 기술이지만 외부의 클라이언트가 람다 함수에 접근하게 하고 싶습니다.

그러나 람다 함수는 API로 바로 노출되지는 않습니다

API Gateway를 통해 노출해야 합니다.

이는 REST HTTP API를 클라이언트에게 제공하여 웹사이트에 직접 연결합니다.

클라이언트는 API Gateway에 통신합니다 API Gateway는 요청을 람다 함수에 프록시합니다.

이는 데이터를 변환하죠 API Gateway는 완전 관리 서비스에 사용되며 개발자가 클라우드에서 쉽게 만들고, 게시하고, 유지하며, 모니터링하고 안전한 API를 사용하게 합니다.

서버리스 기술로 완전히 스케일링 가능합니다

RESTful APIs와 데이터의 실시간 스트리밍을 위해 WebSocket APIs를 지원합니다 보안, 사용자 인증, API 스로틀, API 키, 모니터링 등을 지원합니다.

시험에서 서버리스 API를 만들 때를 묻는다면 API Gateway와 Lambda를 생각하셔야 합니다

AWS Batch

일괄처리(batch processing)란 컴퓨터 프로그램 흐름에 따라 순차적으로 자료를 처리하는 방식

일괄처리 = 개별적으로 어떤 요청이 있을 때마다 실시간으로 통신하는 것이 아닌, 한꺼번에 일괄적으로 대량 건을 처리하는 것.

특히 배치는 보통 정해진 특정한 시간에 실행된다.

1. 대량건의 데이터를 처리한다

2. 보통 특정 시간에 실행된다

3. 일괄적으로 처리한다

배치 작업에는 시작과 끝이 있습니다

이는 절대 끝나지 않고 항상 실행되는 지속적 또는 스트리밍 작업과 반대에 해당합니다.

배치 작업이란 예를 들어, 오전 1시에 시작하여 3시에 끝납니다 배치 작업은 특정 시점에 일어납니다

따라서 배치 서비스는 동적으로 EC2 인스턴스 또는 스팟 인스턴스를 실행하여

해당 배치 작업을 실행하는 로드를 수용합니다.

배치는 배치 대기열처리에 적합한 양의 컴퓨팅과 메모리를 프로비저닝할 수 있습니다

여러분은 그저 스케줄 된 배치 작업을 배치 대기열에 제출하면 됩니다 나머지는 배치 서비스가 알아서 해주죠

배치 작업은 어떻게 정의할까요?

간단히 도커 이미지와 테스트 정의로 ECS 서비스에서 실행됩니다 이 말은 ECS에서 실행할 수 있는 어떤 것이든

배치에서 실행할 수 있다는 뜻이죠 배치 작업을 실행하는 데 배치를 사용하는 것은 매우 유용합니다

자동으로 EC2 인스턴스 또는 스팟 인스턴스의 알맞은 개수로 스케일링해주고 작업을 실행합니다

따라서 비용 최적화를 할 수 있고 인프라에 덜 신경 써도 됩니다 배치 작업에만 집중할 수 있죠

예를 들어 사용자에 의해 Amazon S3에 배치 방식으로 제출된 이미지를 처리하고자 할 때

이미지는 Amazon S3에 보내지고 이것은 배치 작업을 트리거 합니다.

배치는 자동으로 EC2 인스턴스나 스팟 인스턴스로 만들어진 ECS 클러스터를 갖게 되고 배치를 인스턴스의 개수가 배치 대기열에 있는 배치 작업의 로드를 수용하는 데에 적절한지 확인합니다

이 인스턴스들은 작업을 수행할 도커 이미지를 실행하게 됩니다

처리된 객체를 삽입하는 작업이 될 수도 있고 다른 Amazon S3 버킷으로 이미지를 필터 처리할 수도 있습니다

문제는 Batch와 Lambda의 차이점을 구분하느냐입니다

비슷하게 보이기 때문이죠

Lambda에는 15분이라는 시간의 한계가 있어요

또한 몇 개의 프로그래밍 언어로만 접근할 수 있습니다

거기에 임시 디스크 용량이 제한되어 작업을 실행하기 원한다면 서버리스여야 합니다

반면, Batch는 다릅니다

EC2 인스턴스에 의존하기 때문에 Batch에는 시간 제약이 없습니다.

런타임은 도커 이미지로 패키징 하기만 하면 원하는 만큼 가질 수 있습니다

스토리지의 경우, EC2 인스턴스의 스토리지에 의존합니다

EBS 볼륨이 될 수도, 디스크 용량을 위한 EC2 인스턴스 스토어일 수도 있죠

람다 함수보다는 더 많습니다

마지막으로 Batch는 서버리스 서비스가 아닙니다 관리 서비스이지만 EC2 인스턴스가 실제로 만들어져야 하죠

그러나 AWS가 EC2 인스턴스를 관리하기 때문에 오토 스케일링 등에 관해 걱정할 필요는 없어요

Amazon Lightsail

Amazon Lightsail은 AWS에서 약간 독특한 서비스로 독립 실행형 서비스입니다.

Lightsail을 사용하면 가상 서버 스토리지, 데이터베이스 및 네트워크를 한 곳에서 구축할 수 있습니다.

Lightsail은 가격이 저렴하고 예측 가능합니다

사람들이 Amazon Lightsail을 사용하는 이유는 우리가 배운 EC2 RDS, ELB EBS, Route53와 같은

서비스를 사용하는 것보다 훨씬 더 쉽기 때문입니다

즉 Lightsail은 클라우드 사용 경험이 거의 없고 서비스의 복잡한 작동 방식을 익히고 싶지 않은 사람들을 위해

만들어진 서비스입니다

네트워크 작동 방식이나 서버, 스토리지 작동 방식을 배우지 않고 서비스를 사용하는 것입니다.

Lightsail은 사용자가 AWS의 작동 방식을 배울 때 사용할 서비스는 아니지만 클라우드 경험이 전혀 없는 사람이라면

Lightsail를 사용할 수 있을 것입니다

Lightsail에서도 리소스에 대한 모니터링 알람 설정을 할 수 있습니다.

Lightsail 사용 사례는 LAMP 스택, Nginx, MEAN Node.js 등을 사용한 아주 간단한 웹 애플리케이션을 배포한다면

Lightsail에는 해당 템플릿들이 있습니다 Wordpress나 Magento, Plesk, Joomla 등을 사용한 간단한 웹 사이트는

Lightsail에서 템플릿을 사용해 아주 쉽게 배포할 수 있습니다

마지막으로 AWS에 구축된 개발 또는 테스트 환경이 있는 경우에도 Lightsail은 좋은 선택지입니다.

Lightsail에는 고가용성 개념이 있지만 오토스케일링은 지원하지 않고 AWS에 제한적으로 통합됩니다

요약하자면 Lightsail은 클라우드 사용 경험이 없고 복잡한 설정 없이 저렴하고 예측 가능한 가격으로

서비스를 빠르게 시작하려는 사람에게는 Lightsail이 좋은 선택이 될 것입니다

이런 경우가 아니라면 Lightsail은 언제나 틀린 답입니다

컴퓨팅 서비스 요약

도커는 애플리케이션을 실행시킬 수 있는 컨테이너 기술입니다

그리고 AWS에서 도커를 어떻게 실행시키는지를 공부했습니다

첫 번째 방법은 ECS를 사용하는 것입니다.

ECS를 사용하면 도커 컨테이너를 EC2 인스턴스에서 실행시킬 수 있습니다.

하지만 그전에 먼저 인스턴스를 프로비저닝 해야 합니다

다른 방법인 Fargate를 사용하면 인프라 프로비저닝이 없고 과정이 보이진 않지만

동일하게 도커 컨테이너를 사용할 수 있습니다

그리고 Fargate는 서버리스 서비스입니다

도커 컨테이너를 실행하기 위해 EC2 인스턴스를 관리하지 않기 때문입니다

도커 이미지 리포지토리를 가진 ECR을 이용해서 도커 컨테이너를 AWS에 저장할 수도 있습니다

배치 서비스도 공부했습니다 배치를 사용하면 사용하고 있는 여러 EC2 인스턴스에

배치 작업을 실행할 수 있습니다. 배치 서비스는 ECS 위에서 실행됩니다

마지막으로는 저렴하고 예측 가능한 비용으로 애플리케이션을 실행할 수 있는 새로운 유형의 서비스이자

데이터베이스 기술인 Lightsail을 공부했습니다 Lightsail은 대부분 변별력 문제로 출제됩니다

람다 요약

Lambda는 서버리스 서비스로 서비스로서의 기능을 제공하며 원활한 스케일링을 가능하게 합니다.

초 당 한 번의 호출에서 수천 번의 호출까지 완전히 반응적으로 대응합니다.

람다에는 두 가지 결제 방식이 있습니다

람다 함수에 대한 메모리 프로비저닝 양에 실행 시간을 곱하는 방식과

람다 함수가 호출된 횟수를 계산하는 방식이 있습니다

지원하는 언어를 살펴보면 람다는 다양한 프로그래밍 언어를 지원합니다.

컨테이너 이미지를 지원하기는 하지만 그것을 위해서는 특정 런타임 API를 구현해야 합니다

따라서 람다는 임의의 도커 이미지를 지원하지는 않습니다

임의 도커 이미지를 쓰려면 ECS나 Fargate를 사용할 수 있습니다

하지만 사용하려는 도커 이미지에서 람다 컨테이너 런타임 API를 구현하면

도커 이미지를 람다에서 실행할 수 있습니다

하지만 일반적인 방법은 아닙니다

호출 시간은 최대 15분입니다

람다의 사용 사례는 Amazon 이력에 업로드된 이미지의 섬네일을 만들거나

또는 서버리스 CRON 작업을 실행하는 것입니다

마지막으로 우리가 만든 람다 기능을 API로 공개하고 싶다면

API Gateway라는 또 다른 서버리스 서비스를 사용할 수 있습니다

API Gateway를 사용하면 함수를 HTTP API로 공개할 수 있으며

보안, 스로틀링, API 키 등의 기능도 사용할 수 있습니다

AWS CCP - 7 (데이터베이스)

곰종 — Sat, 6 Jul 2024 22:53:27 +0900

AWS Database

Relational Databases (관계형 데이터베이스)

테이블간의 관계를 이용해서 또 다른 연결고리를 찾을 수 있습니다.

관계형 데이터베이스는 SQL 언어를 사용하여 쿼리 또는 조회가 가능합니다 (SQL을 사용한다 -> 관계형 데이터베이스)

Postgres, MySQL, MariaDB, Oracle, Microsoft SQL Server, Aurora

EC2 대신 RDS를 사용하는 이유는 RDS가 관리형 DB라서 데이터베이스 공급이 자동으로 이루어집니다.

OS 패치는 AWS에서 해줄 것이며, 지속적인 백업과 특정 시점으로의 복원(PITR)도 가능합니다.

DB의 상태를 확인하기 위한 모니터링 대시보드, 읽기 전용 복제본을 통한 부하 분산과 읽기 속도 개선, Mulit-AZ 설치를 통한 가용성 영역 다운에 대비한 재해 복구 계획 마련, 수직 수평 확장이 모두 가능하며 저장 공간은 EBS가 지원합니다.

RDS 데이터베이스 인스턴스에 SSH는 할 수 없습니다.

서비스를 이용할 뿐 이며 DB관리는 AWS가 하기에 SSH 유틸리티를 이용하여 DB 상황을 보는것은 불가능합니다.

웹으로부터 요청을 받는 ELB --- 에플리케이션 로직을 실행하는 EC2 인스턴스 ---- 데이터를 읽고 쓰는 DB레이어

EC2 인스턴스의 데이터를 어딘가에 저장 및 공유해야 합니다. 이 데이터는 정형데이터로 EBS, EFS, EC2 인스턴스 스토어를 이용하지않고 DB를 이용합니다. EC2 인스턴스들은 DB에 연결하여 모두 동시에 읽기와 쓰기를 합니다.

(백엔드에서 데이터를 실시간 공유)

Amazon Aurora

AWS가 만든 DB 기술

오픈 소스가 아니며 RD와 같은 방식으로 운영됩니다.

EC2 인스턴스는 Amazon Aurora에 직접 연결이 됩니다.

Aurora는 두가지의 DB 기술을 지원하며, PostgreSQL과 MySQL입니다.

Qurora는 클라우드 최적화를 목표로 하며, RDS에 비하여 MySQL에서 5배, PostgreSQL에서는 3배 성능이 더 좋습니다.

Aurora DB는 용량이 자동으로 확장됩니다 (10GB단위, 최대 128TB)

기본 RDS보다 약 20% 비싸지만, 더 효율적이므로 가격 대비 성능도 더 높을 것입니다.

Amazon Aurora는 프리티어에는 포함되지 않습니다만 기본 RDS는 프리티어에 포함됩니다.

Aurora 정리

AWS에 관계형 데이터베이스를 생성할 수 있는 두 가지 방법인데 두 개 모두 관리를 받으며, 클라우드에 최적화된 것은 Aurora입니다

반면에 RDS는 관리되는 서비스로서 이미 익숙한 기술을 직접 사용할 수 있습니다.

또한 Amazon Aurora는 서버리스라는 선택지도 있습니다 서버리스에서는 데이터베이스 인스턴스화가 자동화되며

데이터베이스의 실제 사용 정도에 기반해 자동 확장이 됩니다.

PostgreSQL와 MySQL 둘 다 Aurora 서버리스 데이터베이스의 엔진으로 기능할 수 있습니다/

용량을 사전에 계획하여 놓을 필요가 전혀 없습니다. 서버가 없으므로 관리도 할 필요가 없으며 비용은 초 단위로 계산되어

직접 Aurora 클러스터를 준비하는 것에 비하여 비용이 크게 절약될 수 있습니다.

이러한 장점들은

작업량이 간헐적으로나 가끔 발생하거나, 예상하기 어려울 때 가장 유용합니다

그러면 원리는 무엇일까요?

고객의 입장에서는 아주 간단합니다 Aurora에서 관리하는 프록시 플릿에 연결하면 Aurora는 보이지 않는 곳에서 규모 확장 또는 축소가 필요할 때 데이터베이스 인스턴스를 만들거나 없앱니다.

그리고 이 Aurora 데이터베이스들은 그 어떤 경우에도 같은 저장 공간을 공유합니다

만약 시험 응시 중에 Aurora에게 아무런 관리 오버헤드가 보이지 않는다면 서버리스 Aurora라고 생각하시면 됩니다.

NoSQL 데이터베이스 (비관계형 데이터베이스)

특정 데이터 모델이나 특정한 목적을 위해 구축되어 애플리케이션 구현을 위한 유연한 스키마를 가지고 있습니다.

유연성이 높은게 장점이고, 데이터 모델을 개선하기 쉬우며, 확장이 가능하며 분산 서버를 추가하여 스케일 아웃이 가능합니다.

관계형 데이터베이스는 서버를 추가해서 확장하기가 어려워 수직으로 확장하는 방법뿐이지만 NoSQL에서는 수평 확장이 가능합니다.

NoSQL 데이터베이스에서는 JSON 형식의 데이터를 사용할 수 있습니다.

JSON은 자바 스크립트 객체 표기법을 뜻하며 Excel 문서 같은 모습이 아닙니다.

위와같이 필드, 이름, 유형등이 있습니다.

AWS 데이터베이스의 공동 책임 모델

관리형 데이터베이스 사용 시 장점 :

Quick Provisioning, High Avilability, Vertical and Horizontal Scaling
운영, 업그레이드, 데이터베이스 자동 백업 및 복원
기본 인스턴스의 운영 체제를 패치해야 하는 경우, AWS의 책임(패치 작업 전담)
모니터링, 알람

EC2 인스턴스에 자체적으로 데이터베이스 기술을 실행할 수도 있으나

그럴 경우에는 복원력, 백업, 패치 작업, 고가용성, 내결함성, 스케일링 등과 같은 관련된 모든 사항을 직접 처리해야한다.

RDS 에서 스냅샷에서 DB를 생성하여 더 큰 규모의 DB 생성, DB의 복사본 생성, 해당 DB의 다른 설정을 생성하기 위해서 스냅샷으로 수행할 수 있습니다. 스냅샷 복제로 다린 리전에 복사할 수 있습니다.

포트는 3306을 사용하여 DB 인스턴스를 연결할 수 있습니다.

관리형 DB는 클라우드를 이용하는 방식에 큰 차이를 만들고 인프라를 관리하는 일이 줄어들어 사용속도가 증가합니다.

RDS DB 배포

RDS 읽기 전용 복제본을 사용하는 방식

메인 RDS DB로부터 읽기 작업을 수행하는 애플리케이션을 예로 들면 RDS 읽기 전용 DB를 복제하여 애플리케이션에서 읽을 때, 부하를 분산시킬 수 있습니다.

데이터 쓰기 작업의 경우 오직 메인 DB에서만 이루어지므로 애플리케이션은 오직 중앙 RDS DB에서만 데이터를 기록할 수 있습니다.

다중 가용영역을 사용하는 방식

Failover (장애조치)

AZ에 장애가 발생했을 때 유용하게 쓰입니다. (충돌이 발생했을 때 높은 가용성을 보장)

메인 RDS DB에서 읽고 쓰기 작업을 수행하며 이때, AZ를 넘나드는 복제본을 다른 가용영역에 설정합니다.

이때 복제본은 장애 조치 DB가 되는데, 다른 가용영역에 있어서 다중 AZ라고 불립니다.

메인 RDS DB가 충돌하면 다른 db가 대체작동합니다. 또한 단 하나의 AZ만 장애 조치 AZ로 설정할 수 있습니다.

다중 리전을 사용하는 방식

이 또한 읽기 전용 복제본을 한 리전이 아닌 여러리전에 걸쳐 복제합니다.

그럼 각 리전에서는 읽기 전용 복제본을 통해 로컬에서 읽을 수 있습니다.

하지만 해당 애플리케이션에 데이터를 써야 할 때는, 리전 간 쓰기 작업을 수행해야 합니다.

왜 다중 리전 배포를 수행할까요?

한 리전에 문제가 생겼을 때를 대비한 재해 복구 전략이 필요하기 때문에 사용합니다.

또한 서로 다른 리전에 있는 애플리케이션들이 로컬 DB로 부터 읽어 들이기 때문에 지연시간이 짧다는 장점이 있습니다.

하지만 리전 간 데이터를 복제할 때에는, 리전 간 복제된 데이터를 네트워크를 통하여 전송하는 비용이 발생합니다.

Amazon ElastiCashe

일래스티 캐시를 사용하여 관리형 레디스(Redis) 또는 멤캐시트 DB를 이용해 보겠습니다.

이와 같은 캐시는 높은 성능과 짧은 지연 시간을 자랑하는 인 메모리 데이터베이스 입니다.

인 메모리 데이터베이스가 나온다? -> 일래스티 캐시

RDS DB에서 많은 쿼리 작업을 동일한 쿼리에서 진행하면 많은 부하가 발생하는데,

캐시를 사용하면 일래스티 캐시를 통해 인 메모리 데이터베이스로 캐시가 직접 전송되도록 하여 DB의 부하를 줄일 수 있습니다.

이 서비스 또한 관리형 DB로 AWS가 모든 운영 체제 유지 보수와 패치 작업, 최적화 설정, 구성, 모니터링, 장애 회복 및 백업을 담당합니다

캐시에 대한 솔루션 아키텍쳐

ELB가 EC2 인스턴스로 갑니다, 아마 ASG일 확률이 높습니다

이때 RDS DB로부터 데이터를 읽고 쓰는데 이때 속도가 느릴 수 있습니다.

그래서 가능한 경우에 일부 값을 일래스티 캐시 DB에 캐싱 처리하게 되는데 이 작업은 인 메모리에서 이루어지므로 속도가 빠르며 일래스티 캐시를 이용하기 때분에 RDS DB의 부하를 줄일 수 있습니다.

DynamoDB

DynamoDB는 완전 관리형 고가용성 DB로 세 개의 가용 영역에 걸쳐 복제본을 두고 운영됩니다.

NoSQL 데이터베이스 이므로 비관계형 DB입니다.

AWS의 대표 상품 중 하나이며, 막대한 작업량도 소화할 수 있고, 분산된 서버리스 데이터베이스 입니다.

즉 RDS나 ElastiCache를 이용해서 서버에 프로비저닝을할 필요가 없습니다.

원래라면 인스턴스 유형에 프로비저닝이 필요하겠지만 DynamoDB에서는 필요가 없습니다. (서버리스)

DynamoDB의 장점은

초당 수백만 건의 요청, 조 단위가 넘는 행, 수백 TB의 스토리지까지 확장해도

신속하고 한결같은 성능을 보여주기 때문입니다.

따라서 검색 지연 시간이 한 자릿수 밀리초인 성능을 필요로 할 경우에는 DynamoDB가 적합한 데이터베이스 입니다.

시험에는 서버리스, 한 자릿수 밀리초의 지연시간 같은 저지연시간을 나타내는 키워드로 문제를 구별합니다.

보안, 인증, 관리상 IAM과 통합되어 있으며, 비용이 적고 오토 스케일링 기능을 갖추고 있습니다.

비용절금을 위해 Standard & IA테이블 클래스가 있습니다.

DynamoDB는 키/값으로 저장됩니다.

기본키가 있고, 하나 혹은 두 개의 열로 파티션 키, 정렬키로 구성되어 있습니다.

우측에 있는 속성은 사용자의 데이터에 대해 열을 임의로 정의할 수 있습니다.

모든 아이템은 행으로 저장됩니다.

정리하면 Dynamo DB는 NoSQL 데이트베이스로서, 데이터 검색의 지연 시간이 짧고 서버리스 데이터베이스에 대한 액세스가 가능합니다.

DynamoDB Accelerator, DAX

DynamoDB를 위한 완전 관리형 인 메모리 캐시, ElastiCache와는 달리 DynamoDB전용 캐시입니다.

DAX는 오직 DynamoDB전용이고, ElastiCashe를 사용할 수 있지만, 이미 완벽히 통합된 전용 캐시를 쓰는게 성능이 10배 향상됩니다.

DynamoDB 테이블에 액세스 할 때마다 한 자릿수 밀리초 지연시간이 아니라 마이크로초 지연 시간을 볼 수 있습니다.

보안도 완벽하며 확장성과 가용성 모두 높습니다.

DAX = DynamoDB전용

ElastiCashe = 다른 DB에서도 캐시 저장에 사용 가능

DynamoDB - GlobalTables

짧은 지연 시간으로 DynamoDB 테이블에 액세스할 수 있도록 하는 기능, 여러 리전에서 사용 가능합니다.

버지니아와 가까이 있는 사용자는 해당 리전에서 짧은 지연 시간을 거쳐 글로벌 테이블에 액세스할 수 있고,

파리 리전에 가까이 있는 사용자는 파리 리전의 글로벌 테이블에 액세스할 수 있습니다.

글로벌 테이블이 있는 모든 AWS 리전에서 읽기/쓰기 액세스가 가능하다는 점은, 즉 액세스한 내용이 바로 다른 리전에 복제가 된다는 뜻입니다 (액티브-액티브 복제)

Redshift

Redshift는 PostgreSQL 기반의 DB이며, OLTP 에는 사용되지 않습니다.

OLTP? OnLine transaction Processing

Redshift는 OLAP(OnLine Analytical Processing)에 특화되었습니다.

이것은 분석과 데이터 웨어하우스에 사용됩니다.

DB의 역할이 분석과 데이터 웨어하우스다? -> Redshift

Redshift는 데이터를 지속적으로 로드하지않고, 1시간 등의 간격으로 로드하게 됩니다.

Redshift의 장점은 데이터를 분석하는 것과 계산하는 일에 매우 특화되어 있습니다.

다른 DB 웨어하우스들의 10배 성능을 자랑하며 용량은 PB단위까지 확장됩니다.

데이터는 열 저장 방식으로 저장됩니다. 행 기반에 반대되는 Coumnar(열 기반)입니다.

Redshift는 MPP(Massiverly Parallel Processing) 엔진이라는 것을 가지고 있어, 이러한 계산들을 빨리 할 수 있습니다.

사용자가 공급한 인스턴스에 따라 비용이 청구되며, 조회는 SQL 인터페이스를 통하여 합니다.

BI(Business Intelligence)도구 들과 통합되어 있습니다.

-> 데이터 웨어하우스에 대시보드를 생성하고자 할 때 유용합니다.

데이터 웨어하우스는 data set에 대하여 계산과 분석 및 시각화를 대시보드를 통하여 실행하는 데 사용됩니다.

Redshift Serverless

이것을 사용하면 Redshift를 실행하면서도 데이터 창고의 크기 조정 또는 공급을 걱정할 필요가 없습니다.

AWS에서 대신 해 줄 것입니다 이름에 Serverless(서버리스)가 붙은 이유입니다.

분석 작업만을 실행하고 데이터 창고의 기반은 관리하지 않는다는 발상으로, 그래서 매우 편리합니다.

그리고 사용한 양만큼만 돈이 청구되기 때문에 비용도 절약할 수 있습니다.

그러므로 적절한 사용 예는 보고서 작성, 대시보드 애플리케이션 또는 실시간 분석 등입니다

비용은 분석 중인 작업량과 사용된 저장 공간에 대해서만 청구되어 Redshift를 운영하는 아주 가성비 좋은 방법입니다

Amazon EMR

EMR은 Elastic MapReduce를 나타냅니다

즉 EMR은 실제 데이터베이스가 아니라 AWS에서 빅 데이터를 작업하고자 할 때 사용하는 Hadoop 클러스터를 생성하며

이때 Hadoop 클러스터란 방대한 양의 데이터를 분석하고 또 처리하는 데 이용됩니다

Hadoop은 오픈 소스 기술로 클러스터에서 작동하는 여러 서버를 통해 데이터를 함께 분석할 수 있습니다 따라서 EMR을 사용하면 수백 개의 EC2 인스턴스로 구성된 클러스터를 생성하여 데이터 분석을 위해 동시에 사용할 수 있습니다.

Hadoop 생태계, 즉 빅 데이터 생태계에는 Apache Spark, HBase Presto, Flink 등 다양한 프로젝트가 있는데

이들 모두 Hadoop 클러스터를 이용해서 작업합니다

그렇다면 EMR이란 뭘까요? EMR은 모든 EC2 인스턴스의 프로비저닝과 구성을 담당하며 이들 모두 원활히 작동하여

빅 데이터 관점에서 데이터를 분석할 수 있도록 지원합니다

또한 오토 스케일링이 가능하고 스팟 인스턴스와 통합되죠 EMR은 데이터 처리와 머신 러닝 웹 인덱싱(Indexing)

또는 일반적으로 빅 데이터에 대해 사용할 수 있습니다

따라서 시험 문제에 Hadoop 클러스터가 나온다면 주저 말고 Amazon EMR을 답으로 선택하면 되겠습니다

Amazon Athena

Amazon Athena는 서버리스 쿼리 서비스로

Amazon S3에 저장된 객체에 대한 분석을 수행합니다. 따라서 SQL 쿼리 언어를 통해 해당 파일을 생성하면

이들을 따로 로드할 필요 없이 S3에 그대로 두면 Athena가 분석을 수행하는 겁니다.

CSV, JSON, ORC Avro, Parquet 등 파일의 형식은 다양할 수 있습니다/

참고로 Athena는 Presto 엔진을 이용해 구축되었습니다

작동 원리를 보면 사용자가 Amazon S3에 데이터를 로드하면 Amazon Athena가 이에 대해 쿼리 작업을 수행하고 데이터를 분석하는 간단한 원리입니다

원하는 경우 Athena에 대한 보고를 살펴볼 수 있는데, 이 경우에는 Amazon QuickSight를 이용합니다.

Athena는 스캔 된 데이터 TB당 5달러로 책정되어 있습니다 압축된 데이터나 열 형식으로 저장된 데이터를 다룰 때에는

데이터 스캔을 줄일 수 있으므로 비용을 절감할 수 있습니다.

Athena는 다양한 경우에 활용되는데 비즈니스 인텔리전스나 분석, 보고 또는 VPC 흐름 로그나 ELB 로그 Cloudtail 로그플랫폼 로그 등 모든 AWS 로그의 분석 시에 Athena를 이용하면 좋습니다.

시험에서는 서버리스 SQL을 이용하여 S3 내 데이터를 분석한다고 하면 Amazon Athena를 바로 떠올리면 되겠습니다

Amazon QuickSight

이는 서버리스 머신 러닝 방식의 비즈니스 인텔리전스 서비스로 대화형 대시보드를 생성합니다.

말은 복잡하지만 Amazon QuickSight에서 기억할 점은 데이터베이스에 대시보드를 만들어서 데이터를 시각적으로 나타내고 비즈니스 사용자가 원하는 인사이트를 보여 준다는 것입니다.

QuickSight를 이용하면 이처럼 멋진 그래프나 도표를 생성할 수 있습니다 속도도 빠르고 자동으로 확장되며 내장 설정이 가능하며 세션별로 가격을 책정하여 서버를 프로비저닝할 필요가 없습니다.

QuickSight는 비즈니스 분석이나 시각화를 구축하거나 임시 분석을 수행할 때 데이터를 이용한 비즈니스 인사이트 도출 시에 활용합니다 .

QuickSight는 RDS 데이터베이스나 Aurora, Athena, Redshift, Amazon S3 등의 기반에서도 작동합니다

QuickSight는 AWS에서 DI를 위한 도구라고 할 수 있겠습니다

DocumentDB

DocumentDB는 MongoDB의 Aurora 버전과 다름 없습니다.

MongoDB는, 또 하나의 NoSQL 데이터베이스이며 이것은 시험을 위해 기억하셔야 합니다.

DocumentDB는 NoSQL 데이터베이스이고 MongoDB 기술에 기반해있습니다. MongoDB와 호환 가능한 것입니다

MongoDB는 JSON 데이터를 저장, 쿼리, 인덱스하기 위해 사용되며 Aurora와 비슷한 배포 개념을 DocumentDB와 가집니다. 즉, 완전히 관리되는 데이터베이스이고 유용성 높으며 데이터는 세 개의 가용 영역에 걸쳐 복제되며 DocumentDB 스토리지는 자동적으로 10 GB까지 확장합니다.

DocumentDB는 초당 수백만개의 요청을 작업할 수 있도록 확장되도록 설계되어있습니다.

시험을 볼 때 MongoDB에 관련된 것을 보신다면 DocumentDB나 NoSQL 데이터베이스에 관련된 것을 생각하시면 됩니다.

Amazon Neptune

Neptune은 완전 관리형 그래프 데이터베이스입니다.

그래프 데이터셋의 예로는 우리 모두 익히 알고 있는 소셜 네트워크를 들 수 있겠습니다.

소셜 네트워크에서는 사람들이 친구로 연결되고 서로 코멘트를 남길 수도 있으며 사용자가 친구를 갖고 게시물에 코멘트를 남기며 코멘트나 게시물에 사용자가 좋아요를 누르거나 이를 공유하는 등 이 모든 것들이 연결되어 있으니 하나의 그래프를 생성할 수 있는 겁니다.

이것이 바로 Neptune이 그래프 데이터셋에 가장 적합한 이유입니다.

Neptune은 세 개의 AZ에 최대 15개 읽기 전용 복제본을 가질 수 있고 소셜 네트워크와 같이 고도로 연결된 데이터셋을 다루는 애플리케이션을 구축 및 실행할 때 사용됩니다.

Neptune은 이처럼 그래프 데이터셋에 복잡하고 어려운 쿼리를 실행하는 데에 최적화되어 있기 때문이죠

최대 수십억 개의 관계를 데이터베이스에 저장할 수 있으며 밀리초를 자랑하는 지연 시간 안에 그래프를 쿼리할 수 있습니다.

애플리케이션 가용성을 다중 가용 영역에 걸쳐 지원하고 있으며 지식 그래프를 저장할 때 그 활용도가 뛰어납니다.

위키피디아 데이터베이스를 지식 그래프의 예로 들 수 있는데 위키피디아 문서는 모두 상호 연결되어 있기 때문입니다.

사기 탐지, 추천 엔진 그리고 소셜 네트워크에서도 활용되죠

시험에서 그래프 데이터베이스와 관련된 내용이 나오면 주저 말고 Neptune을 답으로 고르면 되겠습니다

Amazon timestream

이름으로부터 알 수 있듯이, time series(시계열)을 위한 서비스입니다

즉, time series(시계열) 데이터를 저장하고, 완전한 관리를 받으며 빠르고, 규모 조정이 가능한 서버리스인 데이터베이스입니다.

그런데 time series(시계열) 데이터는 무엇일까요?

시간에 따라 계속적으로 변화하는 데이터입니다

예를 들어 이 그래프의 세로축에는 숫자 가로축에는 연도가 표시되며 연도는 옛날부터 점점 최근으로 변화합니다.

그러므로 연도가 시간에 따라 변하고 이 그래프의 데이터는 time series data set(시계열 데이터 세트)가 되는 것입니다.

Timestream은 이러한 데이터에 사용됩니다.

Timestream은 데이터 용량과 요구되는 계산량에 따라 자동으로 크기가 조정됩니다.

Time series(시계열)의 형태로 하루에 수 조 개의 이벤트를 저장하고 분석할 수 있습니다/

관계형 데이터베이스에 비하여 속도는 약 1000배이며 비용은 1/10입니다 게다가, 실시간으로 time series(시계열) 데이터를 분석하고자 한다면 Time series(시계열) 분석 기능을 통하여 데이터베이스로부터 패턴을 찾아낼 수 있습니다.

그러므로 시험에 time series(시계열) 데이터가 등장할 때마다 Amazon Timestream만을 떠올리시면 됩니다

Amazon QLDB

QLDB는 Quantum Ledger Database의 약자로

Ledger, 즉 원장이란 금융 거래를 기록한 장부로 QLDB도 역시 금융 거래를 기록하는 장부의 역할을 합니다.

완전 관리형 데이터베이스로 서버리스에 고가용성을 자랑하며 세 개의 가용 영역에 걸쳐 데이터의 복제본을 갖습니다.

또한 시간이 지남에 따라 발생한 애플리케이션 데이터의 모든 변경 내역을 살펴볼 때에 사용하므로 원장이라는 이름이 붙었죠.

변경이 불가능한 시스템이기 때문에 데이터베이스에 작성하고 나면 그 후 삭제하거나 수정할 수 없습니다.

또한 삭제된 사항이 없음을 인증하는 암호 서명을 설정할 수 있습니다.

작동 원리는 어떻게 될까요? 먼저 보이지 않는 저널이 존재하는데 저널(Journal)은 일련의 수정 사항을 갖습니다.

따라서 수정이 발생할 때면 암호화 해시가 연산되어서 삭제 또는 수정된 사항이 없음을 보장하게 되므로 이에 해당 데이터베이스를 사용하는 모든 사용자가 이를 확인할 수 있습니다.

따라서 이 기능은 금융 거래가 데이터베이스로부터 사라진 바가 없도록 확인할 수 있으므로 클라우드에서 QLDB를

유용한 원장 데이터베이스로 사용할 수 있는 이유가 되어 줍니다.

QLDB는 일반적인 원장 블록체인 프레임워크에 비해 두 배에서 세 배 더 뛰어난 성능을 자랑하며 데이터를 다룰 때에 SQL을 사용할 수도 있습니다.

또 다른 데이터베이스 기술인 Amazon Managed Blockchain을 볼 텐데 QLDB와 Managed Blockchain의 차이점은

QLDB에서는 탈중앙화 개념을 찾아볼 수 없다는 데에 있습니다.

즉 Amazon이 관리하는 중앙 데이터베이스에 접근할 수만 있으면 이와 같은 저널을 작성할 수 있다는 의미입니다.

또한 이는 많은 금융 규제와 일치합니다 따라서 QLDB와 Managed Blockchain 간의 차이는 QLDB에는 중앙집중형 요소가 있으며 원장에 집중하지만

Managed Blockchain은 탈중앙화 요소가 있다는 것으로 꼽을 수 있겠습니다.

시험에서 금융 거래나 원장이라는 단어가 보이면 QLDB를 바로 떠올리시기 바랍니다

Amazon Managed Blockchain

여기서 블록체인이란 신뢰할 수 있는 중앙 기관 없이도 여러 당사자의 트랜잭션 실행이 가능한 애플리케이션을 구축할 수 있는 기술이 되어 줍니다.

블록체인에는 탈중앙화라는 개념이 있는 것이죠

Amazon의 Managed Blockchain은 공용 블록체인 네트워크에 가입하거나 AWS 내에서 확장 가능한 블록체인 네트워크를생성할 수 있는 서비스입니다.

지금까지는 두 가지의 블록체인과 호환이 가능한데 Hyperledger Fabric 프레임워크와 Ethereum 프레임워크입니다

시험에서는 블록체인과 관련된 내용이나 Hyperledger fabric 혹은 Ethereum이 나오면

탈중앙화된 블록체인인 Amazon의 Managed Blockchain를 반드시 떠올리시기 바랍니다

DMS - Database Migration Service

데이터의 마이그레이션 방법을 볼 차례입니다.

이를 위해 DMS, 즉 데이터베이스 마이그레이션 서비스를 사용할 수 있습니다.

먼저 소스 데이터베이스에서 데이터를 추출하기 위해 DMS 소프트웨어를 실행하는 EC2 인스턴스를 실행한 다음

소스 데이터베이스로부터 데이터를 추출하면 DMS가 다시 해당 데이터를 다른 위치에 있는 대상 데이터베이스로 입력합니다.

따라서 DMS를 이용하면 데이터베이스를 AWS로 신속하고 빠르게 마이그레이션하여 복원과 자가 복구를 수행할 수 있습니다.

또 다른 이점으로 마이그레이션 작업 동안에도 소스 데이터베이스를 사용할 수 있으므로 중단할 필요가 없습니다.

여러 마이그레이션을 지원하는데 그 중 하나는 동종 마이그레이션으로 Oracle 간 마이그레이션에 사용됩니다.

소스와 대상 데이터베이스가 동일한 데이터베이스 기술을 사용할 때에 해당되죠

이기종 마이그레이션도 지원하는데 이는 소스와 대상 데이터베이스가 서로 다른 데이터베이스 기술을 이용할 때

가령 Microsoft SQL Server에서 오로라로 마이그레이션일 때 DMS가 소스에서 대상으로 데이터를 변환하는 작업을 수행해 줍니다.

시험에서 데이터베이스 마이그레이션 내용이 나올 때면 DMS가 해답이라고 알면 되겠습니다

AWS Glue

Glue는 관리형 추출, 변환 및 로드 서비스로 줄여 말하면 ETL 서비스가 되는데 시험에서는 이 정도만 알면 됩니다만

좀 더 깊이 들어가서 작동 원리를 알아보도록 하겠습니다

ETL이 정확히 무엇일까요? ETL은 데이터셋에 대한 분석을 수행할 때에 그 형식이 올바르지 않거나 원하는 형식이 아닐 때에 유용하게 쓰입니다.

ETL 서비스를 통해서 데이터를 준비하고 변환할 수 있는 거죠 기존에는 서버를 사용하여 해당 작업을 수행하지만

완전 서버리스 서비스인 Glue를 통해서도 할 수 있습니다.

실제 데이터 변환에만 신경 쓰고 나머지는 Glue에게 맡기면 되죠

그림으로 살펴보면 Glue ETL을 가운데 두고서 S3 버킷과 Amazon RDS 데이터베이스 모두에서 데이터를 추출하고자 한다고 해 봅시다.

두 소스에 대한 데이터 추출을 위해 Glue를 사용해 볼 텐데 데이터가 추출되고 나면 Glue 서비스에서 스크립트를 작성하고 변환 단계로 넘어갑니다.

Glue가 데이터를 변환해 주면 이제 변환된 데이터를 분석할 차례입니다.

이를 위해 예를 들어서 해당 데이터를 Amazon Redshift DB에 로드한다고 하면 분석이 바로 수행되겠죠

Glue가 가운데에서 이를 지휘하는 거죠 Glue는 아주 강력한 도구로 모든 변환이 가능하며

이를 어떤 장소에든 로드할 수 있습니다

Glue ETL를 살펴봤는데 여기에 또 다른 서비스인 Glue Data Catalog가 있는데 시험에 출제되지는 않겠지만

Glue 제품군의 일부로서 알아 두는 것이 좋으니 살펴보도록 하죠

Glue Data Catalog는 이름에서 알 수 있듯이 AWS 인프라 내 데이터셋의 카탈로그를 제공합니다.

Glue Data Catalog에는 열 이름, 필드 이름, 필드 유형 등 모든 항목에 대한 참조가 있습니다

그리고 이 서비스는 Athena 레드시프트, EMR 등의 서버에서 데이터셋을 검색하고 이에 적합한 스키마를 구축할 때에 쓰일 수 있습니다.

AWS 데이터베이스와 분석 요약

어떤 DB가 어느 상황에 대응되는지 알아야 할 것

Relational Database에다가 OLTP, 즉 online transaction process(온라인 트랜잭션 처리)가 있다면

RDS와 Aurora를 떠올리셔야 합니다

이 두 가지 데이터베이스 모두 데이터 조회에 SQL 언어를 지원합니다

또한 RDS에 대해서는 Multi-AZ, 읽기 전용 복제본, 그리고 다중 리전 간의

차이를 이해하고 각각의 이용 사례 역시 알고 있어야 합니다

인 메모리 데이터베이스 또는 인 메모리 캐시를 찾아야 할 때는 ElastiCache,

키-값 데이터베이스를 찾고 있다면 서버리스 데이터베이스인 DynamoDB를 떠올리시고

DynamoDB를 위한 캐시 기술이 필요하다면 DAX 기술을 사용하여야 합니다.

DynamoDB만을 위하여 만들어진 캐시입니다

웹 데이터 창고 또는 OLAP(온라인 분석 처리) 할 방법을 찾아야 한다면,

데이터 웨어하우스 기술인 Redshift를 생각하셔야 합니다

또한 Redshift에 있는 데이터는 SQL 언어로 조회할 수 있습니다

빅데이터 분석을 위하여 Hadoop 클러스터를 구축할 때는 EMR 서비스가 사용됩니다

Amazon S3의 데이터를 서버리스 방식으로 SQL 언어를 사용하여 조회할 때는 Athena를 사용합니다.

QuickSight는 상호작용 가능한 시각 요소를 가진 대시보드 등을 생성할 수 있습니다.

데이터와의 서버리스 상호작용 역시 가능합니다그런 것이 필요할 떄는 비즈니스 인텔리전스에도 사용되는 Amazon QuickSight를 이용해야 합니다

DocumentDB는 "MongoDB의 Aurora"라고 부를 수 있습니다.

그러므로 MongoDB가 보일 때마다 DocumentDB를 떠올리시면 되며

DocumentDB는 JSON 유형의 데이터세트를 사용합니다.

또한 이것은 NoSQL 데이터베이스이기도 합니다 즉 DynamoDB 외의 또 다른 NoSQL 데이터베이스가 되겠습니다.

그 다음에는 금융 거래 장부인 Amazon QLDB가 있습니다

금융 거래, 변경 불가능한 저널 또는

암호 기법으로 인증 가능한 것이 보이면 Amazon QLDB를 생각하십시오

Amazon QLDB는 중앙 데이터베이스인데,이와 반대로 분산 데이터베이스로

Amazon Managed Blockchain이 있습니다

이것을 이용하여 Hyperledger Fabric과 Etherium 블록체인을 AWS 상에서 관리 받도록 할 수 있습니다

마지막으로, 관리형 ETL(Extract, Transform, Load, 추출 변환 로드) 도구가 필요하다면

Glue를 이용하면 되며, Glue는 데이터 카탈로그 서비스도 있어

AWS에 있는 데이터베이스들로부터 data set(데이터 세트)를 찾아낼 수 있습니다

데이터베이스 간에 데이터를 옮겨야 한다면 데이터 이전 서비스인 DMS를 이용하고

그래프 데이터베이스가 필요하다면 Neptune을 사용하여야 합니다

그리고 time series(시계열) 데이터베이스를 사용하고자 한다면 Amazon Timestream이 필요합니다

AWS CCP 자격증 - 6 (S3)

곰종 — Wed, 3 Jul 2024 12:14:50 +0900

Amazon S3

제한 없이 스케일할 수 있는 스토리지

Amazon S3는 스토리지라서 백업과 저장소로 활용된다.

파일을 저장할 수도 있고 디스크 역할도 합니다.

예를들어 리전이 다운되어 재해 복구를 위해 한 리전에 있는 데이터를 옮겨야 할 때, 백업용이나 보관용으로 사용됩니다.

Amazon S3에 아카이브 해두었다가 나중에 꺼내 쓸 수도 있습니다 (꽤 저렴한 비용)

S3 Buckets

S3는 사람들이 버킷에 객체(Object, Files)를 저장할 수 있도록 허용합니다.

버킷의 이름은 반드시 전 세계적으로 유일해야 합니다. (AWS에서 유일하게 전역적으로 고유한 이름)

버킷은 리전 레벨에서 정의된다.

S3은 글로벌 서비스처럼 보이지만 버킷은 리전 안에서 만들어 진다.

Objects (파일)

객체는 각각 키를 가지고 있습니다.

키는 해당 파일의 전체 경로 입니다.

ex) s3://my-bucket/my_file.txt
키는 prefix와 object name으로 구성되어 있다.
ex)s3://my-bucket/my_folderl/another_folder/my_file.txt

Amazon S3에선 디렉터리라는 개념이 없고 무엇이든 키라고 생각해야 합니다.

키에는 슬래시도 포함합니다.

Amazon S3 실습

누군가 이미 test라고 써버림 (이미 선정됨)

버킷은 전역적이지 않고, 단 하나의 리전에만 위치 (ap-northeast-2)

나머지는 권장값이나, 기본값으로 생성합니다.

기본적인 gomjong-demo-s3 버킷이 생성 완료 되었습니다.

이 버킷에 이제 오브젝트를 올려보겠습니다.

업로드 - 파일 추가 - 올리고싶은 파일 선택 후 업로드

coffee.jpg 파일이 객체 목록에 있는 걸 확인할 수 있습니다

파일 이름을 클릭하면 파일의 상세 정보를 볼 수 있습니다.

아 파일은 S3의 버킷으로 업로드했고 위 열기 버튼으로 인해 이미지를 페이지로 열 수 있습니다.

https://gomjong-demo-s3.s3.ap-northeast-2.amazonaws.com/coffee.jpg?response-content-disposition=inline&X-Amz-Security-Token=IQoJb3JpZ2luX2VjEMn%2F%2F%2F%2F%2F%2F%2F%2F%2F%2FwEaDmFwLW5vcnRoZWFzdC0yIkcwRQIgV1%2BkuczOKE0Ob4sIlklpJvvBw%2BOgUxxo1QqqBLoFXIsCIQChIEB%2F3eocAYcVjGaf34i7qGuoICcikgh%2Fg1UDrDYE9yqOAwiC%2F%2F%2F%2F%2F%2F%2F%2F%2F%2F8BEAAaDDEwNjQzNjMwNzIwNCIMaAT50s2TLYi%2FMOyLKuICT5%2BE2jhU81EjalD72wkKxgwzPU9PrAjmVAtJaAJtMHqf18iMEYq9qq%2BSpWZHCoRKP7RG6L%2BG4PZn8MAjIUGaEjMrR2IfhYCKytjfdE2deE7Pe1RlqeLcZAwJxwcEd01oVYW%2BIsb79rfnJDIs%2FwFh8cnRqzTU6vNLSmpJvPPQ5%2BNUijbRAfZQuXxuhQBCyVjxzavaKeyH1ZO4hJGh0PpjcSnWheh1gc864wDKyx1heAqGBcX9uxGwGsFPN3pz8VN2bOkMIY%2FEvPUpKM7KyLHo19cL895smCymJOK85zGlej6v9N9deoMhFiFKWenzxNZn8Rmmi6KXTOTBFaZ1ZgMl4W%2FEnHveNTi%2BL1uZkl6mR50dvxOgJqjMyMLUCh6VaW9jp1TzRuuUyUq8bmczhmuUtcsDe2jURHfhP5%2F%2B5407EudRjxAwJUwfQTDJmeHOmMH9IDwHSd%2BXW%2FVfgrn5BFLFo%2FdgMPy9krQGOrMCQVyBzcJ3I4g0yqRNYe%2BZTKbKgfuK8goiftQ%2FUppyzl404i5rQCXjUdAgSpB19FI4BJN8H8ez9KfeqlvU9LVWFVeg7M0TN%2FZlr%2FU7o5KjH3Seb7x3FEXUsKgH0ve4CpjBVisXuO%2FDA1S%2F9VJBR5aqzLILSsSzZBVGXktbDt0PGneo%2F2g8CiuHH6M6a5WxDQnb6llUx7OkPZUomMXcXJUiv5nZtulCccFAct7duWaeFfHOcGtFjuzEg1zLODRztvQycoWcJt4Y9h0C%2FNKNsDVIigxTASG6yzrV2MkKere%2BLdzCWyAhnil8rZBJgN%2F%2FV%2BYqiek7Kxg%2B6VkdCdO6FwxELbaPfHE3SQuLaZ0V4jV8XL3MG53whvSIzO5aP2rd1LQ5tB5TM9OPKosHkWiG2fDFdABWBg%3D%3D&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Date=20240703T012533Z&X-Amz-SignedHeaders=host&X-Amz-Expires=300&X-Amz-Credential=ASIARRSAZFECLGQUF6VA%2F20240703%2Fap-northeast-2%2Fs3%2Faws4_request&X-Amz-Signature=088bf147106c2786855ab49068305ddc5d090330d04c473e050e8556287da16b

하지만 객체 URL을 복사해서 주소창에 입력하면

접근이 거절됩니다.

이 메시지가 이야기 하는것은 제 오브젝트에 퍼블릭 URL로는 접근이 불가능합니다.(이 퍼블릭 URL은 동작하지않고있다.)

무슨 차이일까요?

위 열기 URL을 보면 앞부분은 퍼블릭 URL이랑은 같은데 뒤에 나머지 부분이 매우 복잡하고 깁니다.

이 복잡하고 긴 내용 안에는 S3의 미리 서명된 URL 이라는 내용인데

URL안에 서명을 담고있습니다 즉 제 자격 증명을 가지고 있는 셈이고, 자격 증명이 인코딩된 채로 URL에 들어가 있어서

https://gomjong-demo-s3.s3.ap-northeast-2.amazonaws.com/beach1.jpg 이 URL에 대해 뒤에 자격증명으로 미리 서명을 함으로써 접근이 가능하도록 하는것 입니다.

퍼블릭 URL에서 이미지에 접속할 수 있는 방법은 나중에 배워 볼 예정입니다.

일단 다시 버킷으로 돌아와서 오브젝트에 Images 폴더를 생성합니다. 이 폴더 안에도 파일을 업로드 할 수 있습니다.

객체 안에 폴더를 만들고 그 폴더 안에도 파일을 업로드 할 수 있었습니다.

저희가 알고 있는 구글 드라이버, 네이버 클라우드 그런 것과 다를게 없습니다.

Amazon S3에서도 비슷한 UX를 제공합니다. 그래서 당연히 Images라는 폴더도 삭제할 수 있고 삭제하면

폴더 내의 내용물도 다 삭제합니다.

Amazon S3 보안

User 기준

사용자에게는 IAM 정책을 적용하는데,

IAM 정책이 정의하는 건 어떤 API가 어떤 IAM 사용자에 의해 호출될 수 있는가 입니다.

Resource 기준

버킷 정책 : S3 콘솔에서 여러 버킷에 적용되는 규칙을 생성할 수 있습니다.

이 규칙은 특정 사용자에게 이용을 허용하거나 또 다른 계정 사용자를 허용할 수도 있습니다 (교차 계정 액세스 허용)

액세스 컨트롤 리스트 (ACL)도 있는데, 세밀하게 보안을 관리하는 장치 입니다.

Object Access Control List - 오브젝트 단위로 관리

Bucket Access Control List - 버킷 단위로 관리

IAM 정책으로 S3 오브젝트에 접근할 수 있는 건 언제일까요?

IAM 권한이 허용으로 돼 있거나 리소스 정책이 허용으로 돼 있거나, 접근 거절 액션이 명시되어 있지 않다면

API 호출 시 정책에 기반해 S3오브젝트에 접근할 수 있습니다.

마지막의 보안 방식은 함호화 키를 이용하여 오브젝트를 암호화하는것입니다.

S3 버킷 정책은 JSON으로 정의합니다.

Resource엔 어떤 버킷 또 어떤 오브젝트에 이 정책이 적용되는지를 명시합니다.

이 예시는 버킷에 있는 모든 오브텍트에 적용이 됩니다. (*)

Effect로는 허용이나 거절을 결정합니다

무엇을 결정하냐면 Action에 있는 API목록이 있습니다. (예시에서는 GetObject)

Principal은 보안 주체를 설정하는데 여기서 *으로 되어 있기 때문에 "아무나" 허용됩니다.

보안 주체는 이 정책이 적용되는 대상 계정이나 사용자를 명시합니다.

익명의 www 웹사이트 방문자의 접근을 허용하려면 퍼블릭 액세스를 허용하는 S3 정책을 적용합니다.

이 방법은 AWS IAM 사용자가 S3에 접근하려고 하는데 이때 사용자에게 IAM 권한을 부여하여 버킷에 접근합니다.

EC2 인스턴스가 S3 버킷에 접근해야 한다면 EC2 인스턴스 역할을 만들고 적합한 IAM권한을 부여하면 됩니다.

버킷 정책에서 퍼블릭 액세스를 허용해도 위 설정이 활성화 되어 있다면 버킷은 절대 퍼블릭에서 접근할 수 없습니다.

S3 버킷 정책을 잘못 설정하는 실수를 해도 보호해줍니다 (AWS가 기업데이터 유출을 위해 이중 보안)_

S3 버킷 정책

이번엔 버킷 정책을 만들어 아까 접근이 안되었던 퍼블릭 url로 접근할 수 있도록 해보겠습니다.

권한 탭으로 이동하고 퍼블릭 액세스 차단이 활성화 되어있기 때문에 편집을 진행합니다.

퍼블릭 액세스 차단을 해제한 뒤 이제는 오브젝트가 공개될 수 있는 상태가 되었습니다.

이제 버킷 정책 부분을 편집하겠습니다.

정책 예제를 보면 다양한 유스케이스들이 나열되어 있고, 어떤 정책이 적합한지와 알맞는지 보여줍니다.

저는 정책 생성기를 통해 S3 버킷 정책을 생성하겠습니다.

정책 유형을 설정합니다

그 다음 effect를 설정하고, 보안주체에는 *을 이용하여 모든 주체에게 권한을 줍니다

그리고 버키엣 있는 object를 읽는게 목적이니 action은 get object로 진행합니다.

그리고 ARN은 의 S3 버킷 정보를 복사하고 값을 붙여넣습니다.

ARN 마지막에 /* 을 추가해 버킷안에 있는 모든 오브젝트에 이 서비스를 적용한다고 편집을 마무리합니다.

아래 요약

정책 생성을 누르면 JSON형식으로 정책을 제공해줍니다.

이걸 복사하여

버킷 정책 편집에 붙여넣어줍니다.

이 정책의 요약은 누구든지 이 버킷 내에 있는 아무 오브젝트에 GetObject를 수행할 수 있게 한것입니다.

버킷정책 생성을 완료하고, 이제 퍼블릭 접근이 허용됐습니다.

아까 접근이 안되었던 객체 URL (퍼블릭URL) 이 이제 접근이 허용된것을 볼 수 있습니다.

이제 Amazon S3 버킷에 어떤 오브젝트를 올리든지 퍼블릭 URL로 접근할 수 있는 상태가 됐습니다.

Amazon S3 - 정적 웹사이트

S3은 정적 웹사이트를 호스팅할 수 있습니다.

사이트를 인터넷상에서 접근할 수 있게 할거고 웹 사이트의 URL은 어느 리전에서 생성하느냐에 따라 약간씩 다릅니다만

기본적으로 매우 비슷합니다. (bucket-name.s3-website.or-)

정적 웹사이트를 호스팅하는 원리는, S3 버킷에 파일을 담고(HTML, 이미지파일) 그 버킷의 url을 버킷정책을 통해

접근을 활성화 합니다.

실습을 진행해보겠습니다.

속성 탭에 들어가서 정적 웹사이트 호스팅을 편집합니다.

index.html은 업로드 해야하는거고 이 파일은 웹사이트의 기본, 홈 페이지 역할을 합니다.

여기에도 보면 웹 사이트 엔드포인트의 콘텐츠에 액세스할 수 있게 하려면 모든 콘텐츠를 공개적으로 읽기 가능하도록 설정해야 한다고 나와있습니다.

이대로 저장한 후 정적 웹사이트 호스팅을 활성화 하고 index.html파일을 업로드 하겠습니다.

index.html을 업로드 하고, 다시 속성 탭으로 가면

버킷 웹사이트 엔드포인트가 생깁니다.

이 url에 접속하면

url 마지막 부분에 /beach.jpg로 하면

html이 해변사진으로 바귑니다.

S3 버킷에 정적 웹사이트 호스팅 옵션을 활성화됐고 S3 버킷 정책이 퍼블릭 접근을 허용하여 이 url에 접근이 가능했습니다.

Amazon S3 버전관리

Amazon S3에서 파일에 버전을 매길 수가 있습니다.

이 설정은 버킷 단위에서 설정을 해야합니다. 버킷에 버전 관리 기능이 활성화되어 있다면,

사용자가 파일을 업로드할 때마다 해당 파일의 새 버전이 생성되고 키가 할당됩니다.

버전 관리의 장점

의도치 않게 파일 삭제하는 것을 막아준다. (파일을 삭제하면 삭제하기 전 버전으로 롤백)_

버전 기능을 활성화하기 전 파일의 버전값은 null입니다.

버전 기능을 쓰다가 중단해도 이전 파일 버전들을 삭제하지 않습니다. 안전하게 이용할 수 있습니다!

버전관리 실습

S3의 속성탭으로 이동하여 버킷 버전 관리 편집 클릭

이 시점부터 같은 파일을 다시 올리면 버킷에서 파일 버전이 생성됩니다.

아까 index.html의 내용을 수정하여 다시 업로드 해보겠습니다.

내용을 수정하고 다시 업로드 하니 덮어씌워졌고 마지막 수정 시간이 바뀌었습니다.

다시 퍼블릭 url을 들어가서 index.html을 가보면

I love coffee -> I really love coffee로 바뀐것을 확인할 수 있습니다.

객체로 돌아가서 버전을 표시하면

버전 관리 하기전 업로드했던 beach, coffee, index.html은 버전 ID가 null이고

index.html 파일은 버전이 두 개가 있는 것을 알 수 있습니다.

그 전에 올린 파일의 버전 ID는 null이고

버전관리기능을 활성화 하고나서 올린 파일의 버전 ID는 생성된 것을 알 수 있습니다.

여기서 대상 오브젝트의 버전 id가 있는 파일을 삭제하게 되면

이렇게 오브젝트의 어떤 버전 id를 삭제하는 행위를 영구 삭제라고 합니다. (파괴 행위)

다시 그냥 i love coffee가 저장되어 있는 index.html이 올라와있는것을 볼 수 있습니다 (롤백)

버전 표시를 끄고 커피의 이미지를 삭제하면 영구삭제가 아닌 삭제 자체가 버전 id가 남는 기록이 됩니다.

실제로 삭제 되는건 아니고 삭제마커가 남습니다.

Cross-Region Replication

: CRR, 교차 리전 간 복제

특정 리전에 S3 버킷이 있을 때, 다른 리전의 S3 버킷에 복제하는 것을 의미합니다.

가령, ap-northeast-2 리전에 S3 버킷이 있고, 이를 us-east-2 리전의 S3 버킷에 비동기 복제를 해야 하는 상황에 적합합니다. 소스 버킷과 복제 대상 버킷 둘 모두 버전 관리 기능이 활성화되어야 합니다.

Use cases

: compliance, lower latency access, replication across accounts

CRR은 여러 Region에 분포되어 있어야 성능이나 기능 상 유리할 때 사용합니다.

가령, 사용 사례는 법규나 내부 체제 관리(compliance)일 때 여러 리전 S3로 분산시킬 수 있고,

여러 서버에서 S3 객체를 접근할 때 발생할 수 있는 지연 시간(lower latency access)을 줄일 수 있습니다. 가령, 한국과 싱가포르, 프랑스 리전에 서버를 단독 리전의 S3에 접근하는 것보다 각각 한국, 싱가포르, 프랑스 리전의 S3로 복제해 접근하면 훨씬 빨라집니다.

마지막으로 계정 간 복제(across accounts)에도 쓸 수 있습니다.

Same-Region Replication

: 같은 리전으로 복제

쉽게 구분하면, CRR은 이름 그대로 두 리전이 달라야 하며, 반대로 SRR은 같은 리전이어야 합니다

Use cases

: log aggregation, live replication between production and test accounts.

SRR은 다수의 S3 버킷간의 로그를 통합할 때나, 개발 환경이 별도로 있어 운영 환경과 개발 환경간의 실시간 복제를 필요로 할 때 사용될 수 있습니다.

Amazon S3 복제실습

origin 으로 이름을 정하고 버킷 버전 관리를 활성화하여 생성합니다.

또 다른 버킷은 replica 이름으로 정하고, 버킷 버전 관리를 활성화하여 총 2개의 버킷을 생성합니다.

이제 origin 버킷에 파일을 올려보겠습니다

여기 origin 버킷에 beach 사진을 올렸고, 원하는것은 replica버킷에도 복제가 되는 것 입니다.

origin 버킷에서 관리 섹션을 가면 복제 규칙이 있는데 규칙을 생성해보겠습니다.

설정을 하고 복제 규칙을 생성 완료하면

기본 객체도 복제할 것 인지 물어봅니다.

기본적으로 복제규칙을 이용한 복제를 활성화 시키는 시점부터 복제가 활성화되기 때문에 기존에 있는 객체들은 복제가 되지 않습니다.

따라서 AWS S3에서 기존 객체를 복제 할 것이냐고 물어봅니다.

저는 일단 아니오를 선택하겠습니다

그리고 replica 버킷에 들어가보면 beach는 복제 되어있지 않습니다.(위에서 아니오를 선택했기 때문에)

이제 origin에 복제 규칙이 설정 되었으니 origin 버킷에 coffee 사진을 업로드해보겠습니다.

origin 버킷에 coffee.jpg 파일을 업로드했고, 이 경우 버전 id는 zgcl ~~~ 입니다.

이제 replica 버킷에가서 복제가 되었는지 확인해보겠습니다.

이 버킷에 보면 coffee.jpg가 업로드 되어있고 버전 id도 zgcl ~~ 로 파일과 버전 id가 같이 복제된것을 알 수 있습니다.

만약 beach.jpg도 복제를 하고싶다면 origin에서 다시 업로드하여 해당 파일의 새 버전을 업로드하면

replica에도 새로운 버전의 id와 함께 복제가 됩니다.

S3 Storage Classes (중요)

Amazon S3에서 객체를 생성할 때, 클래스를 선택할 수 있습니다. (상황에 적절한 비용절감을 위해)

스토리지 클래스를 수동으로 수정할 수도 있고

Amazon S3 수명 주기 구성을 이용해서 모든 스토리지 클래스 간에 객체를 자동으로 이동시킬 수도 있습니다.

S3타입들을 알아보기 전에 내구성과 가용성의 개념을 알아보고 가겠습니다.

내구성이란 Amazon S3로 인해 객체가 손실될 수 있는 확률입니다.

Amazon S3의 내구성은 아주 높습니다.

99.999999999% (9가 11개)로 Amazon S3에 객체 천만 개를 저장했을 때 1만 년에 한 번 객체가 손실된다는 의미입니다.

모든 스토리지 클래스의 내구성은 동일합니다.

가용상이란, 얼마나 쉽게 서비스를 이용할 수 있느냐 입니다.

S3 Standard의 가용성은 99.99%입니다. 1년에 약 53분 동안 서비스를 이용할 수 없다는 뜻인데

서비스를 처리할 때 오류가 생긴다는 의미이므로 애플리케이션을 개발할 때 고려해야할 부분입니다.

S3 Standard - General Purpose

가장 보통의 범용 클래스입니다. S3에 저장되는 Object의 Default Class 입니다.

S3에서 설명하는 설계 목적은 아래와 같습니다.

Frequently accessed data (more than once a month) with milliseconds access
- 밀리세컨드 내 접근해야하며 자주 접근(한 달에 한 번 이상)하는 데이터

Standard 특징

- 99.99%의 가용성(Availability)을 제공

- 지연 시간이 짧고 (Low Latency), 높은 처리량 (High throughput)

- 한 시설의 데이터가 손실될 경우에도 작동을 유지할 수 있도록 설계

Standard 활용 사례 (Use cases)

- Big Data Analytics

- Mobile and Gaming Applications

- Content Distribution

- Dynamic Websites

- Cloud Applications

Standard IA (Infrequent Access)

자주 사용하지는 않지만 빠르게 접근해야 하는 데이터를 위한 클래스입니다.

S3보다 저렴한 가격이지만, 검색 비용이 발생합니다.

Standard IA의 특징은 99.9%의 가용성을 제공하는데, 이는 Standard 보다 0.09% 적습니다.

Standard IA 활용 사례 (Use cases)

- Disaster Recovery 재해복구

- Backups 백업

Standard와 가격을 비교해보면 다음과 같습니다.

One Zone-Infrequent Access

One Zone-IA는 Standard IA 종류 중 하나로, 자주 액세스하지 않지만 필요할 때 빠르게 액세스해야 하는 데이터에 적합합니다. 해당 클래스는 이름에 명시된 One Zone, 즉 하나의 지역에만 사용 가능한 S3 클래스입니다.

단일 AWS 가용 영역에 데이터를 저장하기 때문에 스토리지 클래스에 저장된 데이터는 가용성 영역이 파괴되는 경우 손실됩니다.

S3 One Zone-IA는 단일 AZ에 데이터를 저장하며 비용이 S3 Standard-IA보다 20% 적게 듭니다.

조금 더 저렴하면서, S3 Standard-IA 스토리지와 같은 가용성 및 복원력이 필요 없을 때 적합합니다.

가령, 쉽게 다시 생성할 수 있는 데이터의 보조 백업 복사본을 저장하는 업무에 사용될 수 있습니다.

Standard-IA와 가격을 비교해보면 다음과 같습니다.

Glacier Storage

Glacier 저장소는 아카이빙 또는 백업을 위한 저가의 객체 저장소입니다.

가격은 저장 비용과 객체 검색 비용이 계산됩니다.

Glacier 저장소는 세 가지 종류가 있습니다.

세 가지 클래스 모두 아카이빙 또는 백업 용이지만, 상황에 따라 구별하여 비용을 최적화하여 사용해야 합니다.

- S3 Glacier Instant Retrieval: 즉각적인 액세스 (밀리초 단위의 검색 시간)

- S3 Glacier Flexible Retrieval: 큰 데이터 집합이 필요 시 (용량의 유연성), 즉각적인 액세스 X

- S3 Glacier Deep Archive: 장기 보관용

아주 대략적인 구분인데요. 각각의 보관 기간, 검색 속도가 다르고 그에 따라 가격이 다르기 때문에 하나씩 살펴보겠습니다.

Intelligent Tiering

S3 Intelligent-Tiering(S3 Intelligent-Tiering)은 사용 패턴에 따라 액세스된 티어 간에 객체를 이동할 수 있게 해줍니다. 즉, 성능, 검색 요금 또는 액세스 빈도에 따라 가장 비용 효율적인 액세스 티어로 데이터를 자동으로 이동하기 때문에 운영 부담없이 편하게 스토리지를 관리할 수 있습니다. 세분화된 객체 수준에서 스토리지 비용을 자동으로 절감해주는 효과를 줍니다.

S3 Intelligent-Tiering은 접근 빈도와 저장 기간에 따라 3개의 액세스 티어에 객체를 다음과 같이 자동으로 저장합니다.

Frequent Access: 기본 티어 (빈번한 액세스에 최적화)

Infrequent Access: 30일 동안 액세스하지 않는 객체 (빈번하지 않은 액세스에 최적화). 40% 더 저렴.

Archive Instant Access: 90일 동안 액세스하지 않는 객체 (거의 액세스하지 않는 데이터). 8% 더 저렴.

Archive Access: 90일에서 최대 730일까지 액세스하지 않은 객체. 표준 검색 시간 3~5시간

Deep Archive Access: 180일에서 최대 730일까지 액세스하지 않는 객체. 성능은 S3 Glacier Deep Archive와 동일. 표준 검색은 12시간

S3 Encryption

서버 측 암호화 :

S3 버킷에 대한 기본 암호화 동작을 설정하여 모든 새 객체가 버킷에 저장될 때 암호화되도록 할 수 있습니다.

Amazon S3로의 모든 새 객체 업로드는 추가 비용 없이 성능에 영향을 미치지 않고 자동으로 암호화(기본값: SSE-S3)됩니다.

Server-Side Encryption
- SSE-S3
- SSE-KMS
- SSE-c

클라이언트 측 암호화 : 사용자가 파일을 업로드하기 전에 직접 암호화

Client-Side Encryption

서버 측 암호화가 기본적으로 항상 활성화되어있다.

IAM Access Analyzer for S3

Amazon S3 버킷을 모니터링 하는 기능

접근을 허용한 사람만 의도된 대로 S3 버킷에 접근할 수 있나를 확인합니다.

버킷 규칙, S3 ACL, S3 액세스 포인트 규칙 등을 분석합니다.

어떤 버킷이 퍼블릭 액세스가 가능한지, 또 어느 버킷이 다른 AWS 계정과 공유가 됐는지를 확인합니다.

우리는 분석된 결과를 보고 보안이슈 등을 판단할 수 있습니다.

Amazon S3 공동책임 모델

AWS 측

늘 그렇듯 AWS에게는 인프라에 대한 전반적인 책임이 있습니다.

내구성, 가용성, 두 개의 시설에서 동시에 데이터 손실이 발생하는 사실도 해당됩니다.

여기에 자체적인 내부 구성과, 취약성 분석도 따르며 인프라 내부에서 자체적인 규정 준수 검증도 수반됩니다.

사용자 측

올바른 S3 버킷 정책 설정을 함으로써 버킷 내에서 데이터가 보호될 수 있도록 해야 합니다.

복제 작업이 필요할 시에는 직접 설정하며 로깅과 모니터링은 선택사항이므로 사용자가 자체적으로 활성화해야 합니다.

또한 사용자가 직접 스토리지의 클라우드를 선택하여 사용하는 것도 사용자 본인의 책임입니다.

마지막으로 Amazon S3 버킷에 데이터를 암호화할지 여부 또한 사용자에게 달려있습니다.

AWS Snow Family

AWS Snow 제품군은 보안성이 높고, 엣지에서 데이터를 수집하고 처리하기 위해 사용되거나 AWS 안팎으로 데이터를 마이그레이션 할 때 사용하는 휴대용 장치입니다.

데이터 마이그레이션을 위한 Snow 제품군으로는 Snowcone, Snowball Edge, Snowmobile이 있습니다.

엣지 컴퓨팅을 위한 Snow 제품군으로는 Snowcone, Snowball Edge가 있습니다.

왜 AWS Snow 패밀리를 이용해서 데이터를 이관(마이그레이션)할까요?

일반적인 네트워크를 사용해서 대량의 데이터를 전송하려면 시간이 엄청 오래걸립니다.

예를 들어 100TB를 1Gbps 속도를 지원하는 네트워크에서 전송하면 총 12일이 소요됩니다.

만약 전송할 데이터의 단위가 PB가 넘어가게 된다면 상상도 할 수 없을 만큼 오랜 시간이 걸릴 것 입니다.

이 뿐 만이 아니라 네트워크 회선을 사용하는 비용도 무료가 아니라 클라우드 회사에 엄청나게 많은 비용을 지불해야 합니다. 따라서 문제점은 아래와 같습니다.

대역폭 공유 문제 (AWS에서 10TB의 파일을 다운 받아서 가용 대용폭을 다 써버려 공유되고있는 네트워크 마비)
높은 네트워크 비용
제한된 대역폭 문제
연결 안정화 문제

이런 문제들 때문에 Snow 제품들이 사용됩니다. Snow 제품들은 오프라인에서 데이터 마이그레이션을 실행하는 장치입니다. snow 패밀리는 오프라인 기기입니다.

AWS가 사용자에게 실제 물리적인 기기를 전송합니다. 그럼 사용자는 기기에 데이터를 담아 다시 AWS로 보냅니다.

핵심은 AWS로 데이터를 이전하는 건데, 물리적인 경로로 한다는 것 입니다 ( 네트워크가 아님)

Snowball Edge

TB 나 PB 이상의 데이터를 전송해야 할 경우 사용한다.
데이터 전송 건마다 비용이 청구된다.
자체적으로 블록 스토리지를 사용하나 Amazon S3 호환되는 객체 스토리지도 제공해준다.
Snowball Edge 에는 두 가지 옵션이 있다.
1. Snowball Edge Storage Optimized : 블록 스토리지로 사용할 수 있도록 80 TB 의 HDD 를 제공해주고 필요하다면 S3 와 호환되는 객체 스토리지를 제공해준다.
2. Snowball Edge Compute Optimized : 42 or 28TB 의 HDD 를 제공해주고 필요하다면 S3 와 호환되는 객체 스토리지를 제공해준다.
Snowball Edge 를 데이터 전송에 쓰는 경우는 보통 온프레미스에서 클라우드로 전환할 때 대량의 데이터를 클라우드에 마이그레이션 하거나 재해 복구를 위해 AWS 에 데이터를 백업하는 경우다.

Snowcone

Snowball Edge 보다 더 작은 장치로 휴대 가능한 장치이며 무게는 2.1kg 정도 된다. 어느 환경에서도 사용할 수 있다.(사막이나 물속이든 상관 없다.)
8TB HDD or 14TB SSD를 저장할 수 있고 용도는 엣지 컴퓨팅이나 데이터 전송에 사용된다.
Snowcone 은 보통 환경이나 공간의 제약을 받는 상황에 사용한다. 드론에 연결하여 데이터를 저장할 수도 있고 이외에도 활용 방법은 많다.
Snowcone를 사용해서 AWS로 데이터를 보내는 방법은 두 가지가 있는데, 우편으로 보내는 방법과 기기를 연결하는 방법입니다. 데이터센터의 데이터를 저장했으면 인터넷 연결이 가능한 기기랑 연결한 다음 AWS Datasync를 이용해 AWS로 데이터를 보내는 방법이 있습니다.

Snowmobile

Snowmobile은 실제 트럭입니다. 데이터 트럭
Snowmobile로 이전할 수 있는 데이터는 엑사바이트 단위입니다. 1 EB = 1024 PB = 1,000,000TB
Snowmobile 한 대당 저장할 수 있는 데이터는 100PB이고 1EB를 처리하려면 10대를 주문해야 합니다.
안전성이 굉장히 높은 데이터 전송방법을 사용합니다 (온도조절, GPS, CCTV) 데이터를 10PB 이상 이전한다면 Snowball보다는 Snowmobile을 사용하는 것이 좋습니다.

Snow Family - Usage Process

1. 콘솔에서 기기를 요청

2. 사용자의 서버에 Snowball 클라이언트나 AWS OpsHub 설치

3. Snowball을 서버와 연결하고 클라이언트를 이용해 서버의 데이터를 복사

4. 복사가 끝나면, 기기를 우편으로 보냄

5. 기기의 있는 E-잉크 마커에 따라 적합한 AWS 시설로 보냄

6. 데이터는 S3 버킷에 로딩되고 Snowball에 기록된 데이터는 깔끔하게 삭제

원래는 Snowball 기기 용도가 이게 유일했으나 엣지 컴퓨팅이라는 용도도 생겼습니다.

엣지 컴퓨팅?

데이터가 엣지 로케이션에서 생성될 때 실시간으로 데이터를 처리하는 방식을 뜻한다.
엣지 로케이션이란 데이터를 생성은 하지만 인터넷과 연결되어 있지 않는 모든 장소를 뜻한다(바다 위 배, 광산, 도로 위 트럭 등) 인터넷이 연결되지 않는 곳에서 데이터 처리를 해야 할 경우 엣지 컴퓨팅이 필요로 하다.
Snowball Edge 나 Snowcone 장치를 주문해서 엣지 로케이션에 장착시키면 엣지 컴퓨팅을 시작할 수 있다.
엣지 컴퓨팅의 예시를 들면 데이터 전처리, 클라우드에서 머신 러닝을 하지 않고 엣지 컴퓨팅으로 머신 러닝을 하거나 미디어 스트림을 트랜스 코딩하는 작업들이 있다.
어찌됐든 간에 데이터를 AWS 로 보내야 하는 경우 Snowcone 이나 Snowball Edge 장치를 AWS 로 보내주면 된다. 즉, Snowball Edge, Snowcone 에서 엣지 컴퓨팅을 하고 완료된 작업물을 AWS 로 보내서 클라우드에 업로드하는 것이다.

AWS OpsHub

원래는 snow 기기를 이용하려면 CLI가 필요하고 이용이 까다로웠는데,

이를 AWS가 인지하고 Opshub라는 프로그램을 만들었습니다.

컴퓨터나 노트북에 설치하는 프로그램이고, 이 프로그램이 실행되면 UI상에서 기능을 제공합니다.

Snow 기기에 연결하기도 하고 기기의 설정을 바꾸기도 하며 아주 간편하게 사용할 수 있습니다.

제공하는 기능은 단일 기기나 클러스터 내 기기를 해제하기, 설정하기, 파일을 이전하기, 인스턴스 실행, 관리가 있습니다.

OpsHub를 이용하여 Snow 패밀리 기기에서 실행되는 EC2 인스턴스들을 간편하게 제어할 수 있습니다.

Snowball Edge Pricing

Amazon S3 로 전송되는 데이터의 요금은 GB당 0.00 USD입니다.

디바이스가 물리적 위치에 있는 전체 기간(일)을 기준으로 요금이 부과됩니다.

10일 이용에 80TB, 15일에 210TB가 있고 10일,15일이 경과한 시점 이후 하루당 비용이 발생합니다.

선불 약정

엣지 컴퓨팅과 관련하여 Snowball Edge 기기 이용료로 할인율은 62%입니다. (온디맨드, 월별 이용요금 대비)

월간, 연간, 혹은 3년 단위 이용을 위해 선불로 지불합니다.

AWS의 다양한 스토리지 옵션

블록 스토리지 : EBS, EC2인스턴스

파일 스토리지 : Amazon EFS

객체 스토리지 : Amazon S3, Glacier

Storage Gateway

AWS 내 사용자의 온프레미스 데이터와 클라우드 데이터를 연결합니다.

즉 하이브리드 스토리지를 사용하여 온프레미스 시스템에서도 문제없이 클라우드를 이용할 수 있도록 확장합니다.

정리하면 Storage Gateway를 이용하면 온프레미스에서 발생하는 작업이 바로 AWS 클라우드로 연결이 됩니다

Amazon S3 - 요약

버킷과 오브젝트의 차이

버킷의 이름은 전역적으로 고유해야 합니다. 그리고 특정 리전에 위치해야 합니다.

오브젝트는 버킷 안에 존재합니다.

S3 보안을 위해서는 사용자나 역할에 IAM 규칙을 적용할 수 있고, 버킷 규칙을 이용하는 방법도 있습니다.

S3 버킷에 퍼블릭 액세스를 허용하고, 특정 파일을 보호하기 위한 암호화도 있었습니다.

S3 버킷에서 웹사이트를 서비스하기 위해 버킷을 퍼블릭으로 만들어 파일을 정적으로 호스팅도 하였습니다.

S3 버전 관리 기능을 통해 파일을 버전 단위로 관리해 실수로 삭제하는것을 방지할 수 있었고 이전으로 롤백할 수도 있었습니다.

S3 복제 종류에는, 동일 리전 복제와 리전 간 복제가 있었습니다. 복제를 하려면 버전 관리 기능을 활성화 시켰어야 합니다.

S3 스토리지 클래스간의 차이도 확인했는데

Standard, Infrequent Access, One Zone Infrequent Access, Intelligent, 아카이브를 위한 Glacier에 클래스가 세 개 있는것도 확인했습니다.

Snow 패밀리로 Amazon S3로 데이터를 임포트할 수 있는 물리적인 기기도 봤으며, Snowmobile, Snowcone, Snowball등도 봤습니다. Snowcone, Snowball Edge 기기를 이용하면 데이터에 엣지컴퓨팅을 잘 활용할 수 있었습니다.

OpsHub는 데스크탑 애플리케이션으로, Snow 패밀리 기기를 관리하고 데이터를 기기에 옮겨줍니다.

AWS Storage Gateway를 이용하여 온프레미스 스토리지를 Aazon S3로 확장할 수도 있습니다