VPC란

가상 프라이빗 클라우드(VPC)는 퍼블릭 클라우드 내에서 호스팅되는 안전하고 격리된 프라이빗 클라우드이다. VPC가 없다면 AWS Cloud 안의 리소스들을 연결하기 위해 많은 작업들이 생길 것이고 시스템의 복잡도는 높아질 것이다. 하지만, VPC를 이용하면 위 이미지와 같이 리소스들을 쉽게 관리할 수 있을 것이다. 이렇게 대부분의 AWS 서브시들은 VPC에 의존적이기 때문에 VPC에 대한 이해는 중요한 요소 중 하나이다.

네트워크 선수 지식

사용자가 AWS VPC에 서브넷 생성, 라우팅 테이블 구성 등 네트워킹 환경을 원하는 대로 제어 및 구성하려면 아래의 선수 지식들이 필수이다.

1. IP 클래스, 서브넷, 서브넷팅, 네브넷 마스크
2. CIDR

대략 위 2개의 선수 지식을 알아야 한다고 생각합니다.

IP 주소

IP 주소란

IP는 네트워크 장비 식별을 위해 개별 장비에 부여되는 고유 주소이다. 일반적으로 192.168.0.1과 같이 마침표로 구분된 4개의 10진수로 표기하고 이를 2진수로 변환하면 32비트의 11000000.10101000.00000000.00000001와 같이 표현할 수 있다.

IP 주소는 총 32비트로 구성되어 있으며 (8bit = 1byte = 1옥텟)을 10진수로 표기하고 2^32이므로 약 43억 개의 주소를 가진다.

IP 주소의 구성

IP 주소는 네트워크 ID와 호스트 ID로 구성되어 있다. 네트워크ID는 다른 네트워크와 구분하는 역할을 하게된다. 호스트ID는 해당 네트워크의 어느 호스트인지를 나타내어 다른 호스트와 구분하는 역할을 한다.

IP 주소 클래스

IP클래스는 IP주소를 효율적으로 나누어 놓은 범위이고 예전에 IP를 할당하는 방식이었다. 하지만 지금은 더 이상 사용되지 않고 CIDR 방식으로 할당되도록 바뀌었다. 위에서 말했듯이 8bit는 1옥텟이며 32비트는 4개의 옥텟으로 나눌 수 있다. 각 옥텟은 0부터 255까지의 범위를 가지어 총 256개의 값을 표현할 수 있다.

A 클래스

• A 클래스의 경우 처음 8비트가 네트워크 ID이며, 나머지 24비트가 호스트 ID로 사용된다.
• A 클래스의 첫번째 옥텟의 비트는 0으로 고정되어 있다.
  • 따라서 A 클래스의 첫 옥텟이 1 ~ 126 사이의 숫자로 시작한다.
  • 00000000(2) ~ 01111111(2)
• 호스트 ID는 24비트로 구성되어 있으므로 네트워크 당 나올 수 있는 호스트 개수는 1670만개 이므로 대규모 네트워크에 적합하다.

IP 주소에서 첫 옥텟이 0과 127로 시작할 수 없는 이유는 예약되어 있는 주소가 존재하기 때문이다. 0.0.0.0 : 미지정 주소 127.0.0.0 : 루프백 주소

B 클래스

• B 클래스의 경우 처음 16비트가 네트워크 ID이며, 나머지 16비트가 호스트 ID로 사용된다.
• B 클래스의 첫 번째 옥텟의 두개의 비트가 10으로 고정 있다.
  • 따라서 B 클래스의 첫 옥텟이 128 ~ 191 사이의 숫자로 시작한다.
  • 10000000(2) ~ 10111111(2)
• 호스트 ID는 16비트로 구성되어 있으므르 네트워크 당 나올 수 있는 호스트 개수는 65000개 이므로 중규모 네트워크에 적합하다.

C 클래스

• C 클래스의 경우 처음 24비트가 네트워크 ID이며, 나머지 8비트가 호스트 ID로 사용된다.
• B 클래스의 첫 번째 옥텟의 세개의 비트가 110으로 고정 있다.
  • 따라서 B 클래스의 첫 옥텟이 192 ~ 223 사이의 숫자로 시작한다.
  • 11000000(2) ~ 11011111(2)
• 호스트 ID는 8비트로 구성되어 있으므르 네트워크 당 나올 수 있는 호스트 개수는 256개 이므로 소규모 네트워크에 적합하다.

D 클래스

• D 클래스의 첫 번째 옥텟의 네개의 비트가 1110으로 고정 있다.
  • 따라서 D 클래스의 첫 옥텟이 224 ~ 239 사이의 숫자로 시작한다.
  • 11100000(2) ~ 11101111(2)
• 멀티캐스트용 대역으로 IP주소 할당에 사용되지 않는다.

E 클래스

• E 클래스의 첫 번째 옥텟의 네개의 비트가 1111으로 고정 있다.
  • 따라서 D 클래스의 첫 옥텟이 240 ~ 255 사이의 숫자로 시작한다.
  • 11110000(2) ~ 11111111(2)
• 연구용 예약된 주소 대역으로 IP주소 할당에 사용되지 않는다.

네트워크 주소와 브로그 캐스트 주소

하나의 네트워크에서 사용할 수 있는 IP 주소에서 사용할 수 없는 주소가 2가지 존재한다. IP 주소의 맨 첫 번째 주소와 맨 마지막 주소는 호스트 주소로 사용할 수 없다.

예를들어 192.168.100 네트워크가 있다면 첫 번째 IP 주소인 192.168.100.0과 마지막 주소인 192.168.100.255는 사용할 수 없다.

이유는 사회적으로 첫 번째는 네트워크 그 자체의 주소, 마지막은 브로드캐스트를 위한 주소이기 때문이다.

네트워크 주소는 말 그대로 네트워크 자체를 나타내는 것이고, 브로드 캐스트 주소는 인터넷 데이터를 전달하기 위한 주소로서 모든 네트워크 아이피 클래스에 동일하게 적용되는 것이다.

서브넷과 서브네팅 그리고 서브넷 마스크

서브넷

IPv4는 초기에 부족한 아이피 주소 문제를 해결하기 위해 IP 클래스로 효율적으로 나눠 할당하는 방법을 택하였다. 하지만, 해당 방법은 비효율적이었다.

예를들어 B 클래스 를 소규모 회사에게 할당하였을 경우 B 클래스 호스트 주소의 개수인 65,000개의 아이피를 다 활용하지 못하고 10,000개의 아이피만 사용한다고 가정했을 때, 나머지 55,000개의 IP는 쓰지 않은 채 회사는 클래스 B의 하나를 점유하고 있는 상태가 되어버린다. 그렇다고 C 클래스 IP를 할당하자니 IP 자원이 부족한 상태가 되어버린다. 이렇게 IP를 클래스 별로 나누어 놓았지만 낭비가 날생하고 있게 되었다.

그래서 이러한 문제를 해결하고자 IP를 네트워크 장치 수에 따라 효율적으로 사용할 수 있는 서브넷 개념이 등장하였다.

서브넷이란

1. 하나의 네트워크가 분할되어 나눠진 작은 네트워크
2. 서브넷을 만들기 위해 네트워크를 분할하는 것을 서브네팅이라고 한다.
3. 이 서브네팅을 서브넷 마스크를 통해 계산된다.

서브네팅

서브네팅은 IP 주소를 효율적으로 나누어 네트워크에 할당하는 방법을 말한다.

위 그림을 보면192.168.10.0/24 의 C 클래스 네트워크 주소를 사용한다고 했을때, 256개의 Host ID 개수를 잘게 나눠 128,128 이를 한 번 더 나눠 64, 64, 64, 64 개의 Host ID를 나눴다면 나누어진 64개를 특정 네트워크에게 할당해주는 것을 서브네팅의 예시다.

2등분을 하기 위해서 호스트 ID의 가장 왼쪽 비트를 서브넷 구분 비트로 지정하여야한다. 가장 왼쪽 비트 1개를 서브넷 구분 비트로 설정하였기에 두개의 영역으로 나눠질 수 있다. (서브넷 구분 비트가 달라지면 나눌 수 있는 영역도 달라진다) 00000000 ~ 0111111 (0 ~ 127) 10000000 ~ 1111111 (128 ~ 255)

이렇게 나눈 서브넷 부분을 회사의 네트워크에 할당하면 됩니다. 하지만, 앞서 설명했듯이 네트워크 주소와 브로드캐스트 주소를 제외한 범위만 가능하다.

서브넷 마스크

서브넷 마스크는 IP주소에서 네트워크 ID와 호스트 ID로 어느 클래스 주소인지 구분하기 위한 목적으로 만들어졌다. IP주소마다 해당 주소의 범위를 보고 어느 클래스인지 판별할 수 있지만, 더 쉽게 구분하기 위해 서브넷 마스크를 사용한다고 생각하면 된다. 서브넷 마스크는 IP주소와 다르게 연속된 1과 연속된 0으로 구성되어 있다는 것이다. ex) 1111 1111 . 1111 1111 . 1111 1111 . 0000 0000 -> 255.255.255.0(서브넷 마스크)

AWS VPC 구성도

네트워크 사전 지식에 대해 간단하게 알아보았다. 더욱 깊게 다루기엔 분량이 많아지기에 위 배경지식들을 기반으로 아래 참고 영역의 유튜브 링크의 영상을 시청하면 좋을 것 같다.

맨 처음 첨부한 사진을 다시 가져왔다. 이제부터 VPC를 구성할 것이고 아래 사진들에 표현된 각 요소들을 설명하려고 한다. 각 요소들을 설명할때 그림을 참고하면 더욱 이해하기 쉬울 것이다.

VPC

AWS VPC를 구성하기 위해서는 VPC의 IP 범위를 REC1918이라는 사설 IP 대역에 맞춰서 설계해야 한다. VPC는 각 Region에 종속되어야 하며 한 Region에 여러개의 VPC를 생성할 경우 서로 아이피는 겹쳐서는 안된다. DNS IP를 잡지 못하는 에러가 발생하기 때문이다. 또한, VPC내에서 한 번 설정된 IP 대역은 수정할 수 없다.

AWS 서브넷 구성

VPC를 생성하였다면 서브넷을 생성하여야 한다. 서브넷은 VPC 내부에 있는 IPv4 주소의 부분 범위이다. 즉, VPC를 더 작은 네트워크 단위로 세분화하는 것이다. 각 서브넷은 특정 AZ에 위치해야 하며 여러 AZ에 걸쳐서 서브넷을 생성할 수 없다. 그리고 AWS가 각 서브넷의 IP 주소 5개를 예약하여 사용하고 있다. 그렇기에 아래 예약된 주소를 고려하여 적절한 IPv4 CIDR Block을 생성해야 한다.

1. 10.0.0.0 : 네트워크 주소
2. 10.0.0.1 : VPC 라우터를 위해 예약된 주소
3. 10.0.0.2 : Amazon에서 제공된 DNS에 매핑되기 위해 예약된 주소
4. 10.0.0.3 : 당장 사용하지는 않지만 미래에 사용될 수도 있기에 예약된 주소
5. 10.0.0.255 : 네트워크 브로드캐스트 주소 하지만 AWS는 VPC에서 브로드캐스트를 지원하지 않기에 예약은 되지만 사용하는건 안된다.

서브넷 구분

Public Subnet

외부에서 접근이 가능한 네트워크영역이다. 서브넷이 인터넷 게이트웨이로 향하는 라우팅이 있는 라우팅 테이블과 연결되어 있는 경우 퍼블릭 서브넷이라고 한다. 해당 서브넷은 인터넷과 연결이 가능하므로 퍼블릭 서브넷에 위치한 AWS 리소스들은 공인IP를 가질 수 있다.

Private Subnet

외부에서 다이렉트로 접근이 불가능한 네트워크 영역이다. 즉, 인터넷과 연결되지 않은 서브넷이라고 생각하면 된다. 하지만, 특정 리소스가 인터넷 연결이 필요할 수 있다. 이럴 경우 NAT 게이트웨이를 이용하여 내부에서 외부로 접근이 가능하게 만들어준다. 또한, 같은 vpc 영역에 있으면 private subnet으로 접근이 가능하다. 이로써 엄격하게 다뤄야 하는 리소스들을 안전하게 관리할 수 있다.

네트워크 ACL과 보안그룹

네트워크 ACL(Network Access Control List)와 보안그룹(Security Group)은 VPC 내에서 인바운드, 아웃바운드 트래픽에 대한 보안 정책을 설정하고 관리합니다.

NACL과 Securiy Group은 비슷하지만 다른 차이점을 갖고 있다.

네트워크 ACL

NACL은 상태 비저장(Stateless) 방식으로 동작하여 인바운드와 아웃바운드 규칙을 독립적으로 처리한다. 즉, 특정 트래픽이 인바운드 규칙에 허용되어 진입하더라도 상태 비저장 특성 때문에(기억하지 않음) 아웃바운드 규칙에 의해 허용된 트래픽이 거절될 수도 있다는 것이다.

모든 트래픽이 기본적으로 허용되는 것이 아니기에 명시적으로 트래픽을 제한하거나 허용하는 규칙을 설정해야 한다. NACL은 서브넷 단위로 적용되며 각 서브넷마다 하나의 NACL이 할당된다. 새로운 서브넷을 생성하게되면 기본 NACL로 설정되며 모든 트래픽을 허용하는 설정을 가지고 있다. NACL에는 규칙 정의가 있다. 규칙에는 숫자가 있고 1~32766까지 정의할 수 있다. 숫자가 높을 수록 우선순위가 높다. ALLOW, DENY를 구성할 수 있다.

보안 그룹

보안 그룹(Security Group)은 상태 유지(Stateful) 방식으로 동작하기에 트래픽이 허용되면 반환 트래픽도 자동으로 허용된다. 즉, 특정 트래픽이 인바운드 규칙에 허용되어 진입한다면 상태 저장 특성 때문에(기억하고 있음) 아웃바운드 규칙과 상관없이 아웃바운드를 통과하게 된다.

보안 그룹은 트래픽의 거부 규칙을 지원하지 않는다.

네트워크 ACL과 보안 그룹 차이점

1. NACL은 상태 비저장, 보안그룹은 상태 저장 특성을 가진다.
2. 보안 그룹은 인스턴스 수준에서 동작하지만 NACL은 서브넷 수준에서 동작한다.
3. 보안 그룹은 허용 규칙을 지원하지만 NACL은 허용, 거부 2가지 규칙을 모두 지원한다.
4. NACL에서는 특정 IP를 거부할 수 있다.
5. 보안 그룹에서는 모든 규칙이 평가되고 트래픽 허용 여부를 결정하지만, NACL에서는 가장 높은 우선순위를 가진 것이 먼저 평가된다.
6. 보안 그룹은 할당된 EC2 인스턴스에 지정되지만 NACL은 연결된 서브넷의 모든 EC2 인스턴스에 적용된다.

인터넷 게이트웨이

인터넷 게이트웨이는 VPC와 인터넷 사이에 통신을 가능하게 하는 고가용성 VPC 컴포넌트이다. 수평 확장되고 가용성이 높은 중복 VPC 구성 요소로 VPC의 인스턴스와 인터넷 간에 통신할 수 있게 해준다. 따라서 네트워크 트래픽에 가용성 위험이나 대역폭 제약 조건이 발생하지 않는다.

인터넷 게이트웨이는 2가지 용도로 제공된다.

인터넷 게이트웨이는 2가지 용도

1. 인터넷 트래픽 라우팅

• 인터넷 게이트웨이는 VPC의 라우팅 테이블에서 인터넷으로의 트래픽을 전송할 수 있는 대상 역할을 한다.
• 예를 들어 퍼블릭 서브넷의 트래픽이 인터넷으로 나가야 하는 경우, 해당 서브넷의 라우팅 테이블에 "인터넷 게이트웨이를 통해 모든 트래픽(0.0.0.0/0)을 인터넷으로 보낸다" 라는 규칙을 할당하면 된다.
  • 퍼블릭 서브넷의 라우팅 테이블에 아래와 같은 규칙이 있으면 된다.
  • Range: 0.0.0.0/0 (모든 IPv4 주소)
  • target: igw-xxxxxx(인터넷 게이트웨이 ID)

2. NAT 수행

• 인터넷 게이트웨이는 VPC 내의 퍼블릭 IPv4 주소를 가진 인스턴스가 인터넷과 통신할 수 있도록 네트워크 주소 변환(NAT)를 수행한다.
• 퍼블릭 IPv4 주소를 가진 인스턴스의 네트워크 주소 변환을 관리하여 프라이빗 IP와 퍼블릭 IP 간의 트래픽을 올바르게 라우팅해준다.

NAT Gateway

NAT 게이트웨이는 프라이빗 서브넷 내 리소스가 인터넷과 통신할 수 있도록 하는 AWS 관리형 서비스이다. 위와 같은 특징 덕분에 프라이빗 서브넷의 인스턴스는 인터넷을 통해 외부 서비스를 호출하거나 데이터 업데이트, 다운로드를 할 수 있지만, 외부에서는 직접 접속할 수는 없다. 이를 통해 보안을 높일 수 있다.

프라이빗 서브넷내의 리소스가 외부 인터넷에 접근하는 과정은 다음과 같다.

1. NAT 게이트웨이를 생성 시 퍼블릭 서브넷과 연결해야 하며, 탄력적 IP(EIP) 주소를 할당받는다.
2. EC2 인스턴스가 프라이빗 IP 주소를 통해 라우터에 데이터를 전송한다.
3. 프라이빗 라우팅 테이블을 참고하여 NAT 게이트웨이로 향한다. (프라이빗 서브넷의 트래픽을 NAT 게이트웨이로 향하도록 라우팅 테이블 설정)
4. NAT 게이트웨이는 프라이빗 IP 주소를 퍼블릭 IP 주소로 변환하여 인터넷 게이트웨이를 거친 후 외부 인터넷으로 데이터를 전송한다.
5. 사용자는 NAT 게이트웨이에서 변환된 퍼블릭 IP 주소로 전달받는다.

정리

이번 포스팅으로 VPC 구성에 필요한 요소들과 필수적인 네트워크 사전 지식에 대해 학습할 수 있었습니다. 이제 아래 이미지에 표기된 요소들에 대해 충분한 이해가 되셨으리라 생각됩니다.

VPC를 학습하는 과정에서, 포스팅에서 언급한 기본 요소 외에도 다양한 AWS 서비스들이 존재합니다. 예를 들어

• VPC 피어링: 서로 다른 VPC 간의 네트워크 트래픽을 연결해주는 기능.
• Bastion 서버: 외부에서 프라이빗 서브넷에 안전하게 접속할 수 있도록 해주는 점프 서버.
• VPC 엔드포인트: 퍼블릭 인터넷을 경유하지 않고도 프라이빗 서브넷에서 AWS 서비스에 직접 접근할 수 있도록 해주는 구성 요소. 인터페이스(Interface) 엔드포인트와 게이트웨이(Gateway) 엔드포인트로 나뉩니다.

위 서비스를 제외하고도 다양한 서비스들이 존재합니다.

이와 같은 다양한 VPC 관련 서비스들을 학습하다 보면, 자연스럽게 보안, 고가용성, 내구성 측면에서 우수한 네트워크 설계를 할 수 있는 능력을 키울 수 있습니다. 또한, 이 과정에서 네트워크 지식 역시 깊이 있게 이해하게 될 것입니다. VPC와 관련된 내용을 학습하는 것은 네트워크 설계와 관리에 대한 기본적이면서도 중요한 능력을 향상시킬 수 있는 좋은 기회이기에 꼭 한번 학습해보시는 것을 추천드립니다.

참고 https://www.youtube.com/watch?v=b7Wk-6w5vgg&t=24s https://www.youtube.com/watch?v=-iMFsDdfoeI&t=1199s https://brunch.co.kr/@swimjiy/43 https://ee2ee2.tistory.com/entry/Network-IP-%ED%81%B4%EB%9E%98%EC%8A%A4ABC-class%EB%9E%80 https://inpa.tistory.com

가장 먼저 SAA 자격증에 관심을 갖게된 계기는 SI 회사를 퇴사 후 Cloud 기반의 부트캠프에 참여하면서 다양한 AWS 서비스, Docker, k8s 등을 학습하게 되었습니다. 이 과정에서 클라우드 기술에 깊은 흥미를 느꼈고, 자연스럽게 더 깊이 학습하고 싶은 욕구가 생겼습니다. 그러던 중 AWS와 관련된 자격증이 있다는 사실을 알게 되어 관심을 갖게 되었습니다.

부트캠프가 끝난 후에는 회사에 다니면서 업무와 학습 우선순위에 밀려 자격증 취득을 미루고 있었습니다..😅 회사의 인프라는 AWS 환경에서 운영되고 있었고, 이를 전담하시던 유일한 DevOps 실장님이 개인적인 사유로 퇴사하시게 되면서 개발팀에서 AWS 인프라를 함께 담당하게 되었습니다. 자연스럽게 다양한 AWS 서비스의 유지보수해야 하는 상황이 생기게 되었고, 해당 서비스들을 학습하면서 자격증 준비를 함께 병행하게 되었습니다.

취득 방법 및 기간

취득 방법은 크게 두 가지였다.

1. Udemy 강좌
2. 덤프 문제 풀이

1. 유데미

유데미 강의는 거의 28시간으로 구성되어 있어 출퇴근 시간을 활용하여 모든 강의를 수강하였습니다. 강의마다 짧은 시간으로 구성되어 있어서 지루할 틈 없이 들었고 다양한 서비스의 실습, 사용사례 등을 알게 되어 매우 유익했던 것 같다. 또한, 유데미 강의를 들으면서 네트워크 지식도 한번 더 학습하게 된 계기가 되었습니다.

강의를 다 들을때쯤 1주일 후로 시험을 타이트하게 접수했는데 응시비는 150$ 한화로 대략 20만원에 가까운 금액을 결제했습니다..(아찔한 응시비 덕분에 시험 일정을 미룰까 고민을..)

2. 덤프 문제 풀이

이제 1주일 남은 기간동안 덤프 문제를 풀어보았습니다. 덤프는 examptopic에서 무료로 제공되는 220문제 정도를 2회독 하였습니다. 많은 양의 문제를 풀어본 것 같다는 생각이 들지 않아 중고 사이트에서 코리아 덤프 문제를 구매 후 100문제 가까이 풀었던 것 같습니다. 적은 양의 문제를 풀은 것 같아 불안한 마음이 없지 않아 있었습니다.(시험장에서 1번부터 처음보는 유형의 문제를 접하고 응시비를 날리나 싶었습니다^_^)

덤프 문제를 풀면서 취득 준비를 하시는 분들에게 드리고 싶은 말씀은 코리아 덤프 문제는 제대로 번역이 안되서 보기 힘들고 examptopic 덤프만 풀어도 충분할 것 같다고 생각이 듭니다. 실제로 examptopic에서 풀었던 문제들이 시험에 여럿 출제 되었습니다.

시험

시험은 강남제일빌딩 10층에 있는 피어슨 뷰(Pearson Vue)에서 오전 9시에 시험을 보았습니다. 신분증과 신용카드로 신원 확인 후 모든 소지품은 사물함에 보관 후 시험장에 들어갔습니다.

결과

간당간당한 점수로 합격을 하였습니다 ㅎㅎ.. 시험을 응시하면서 처음 접한 유형의 문제들이 많았는데 아예 모르는 수준은 아니였고 50:50 확률로 선택해야 했던 문제들이 많았습니다ㅜ 그래서 앞서 말씀드린 examtopic 덤프 문제를 많이 풀어보시고 응시하는 것을 추천드립니다!

시험 결과는 시험을 본 당일 오후 6시쯤 메일로 결과를 받았습니다.

후기

시험 준비를 통해 다양한 AWS 서비스에 대해 전반적으로 이해할 수 있었습니다. 다만, 이 서비스들을 실제로 적용하기 위해서는 더 많은 사례 연구와 심화 학습이 필요하다는 것도 깨달았습니다. 강의나 시험 준비 과정에서는 각 서비스를 현업과 유사한 사레로 깊이 있게 다루지는 않기 때문입니다.

향후 DevOps 구성원이 많은 회사로 이직하게 되면, 특정 아키텍처나 기능을 도입할 때 명확한 요구사항을 전달할 수 있어 더 효과적인 소통이 가능할 것이라고 생각합니다. 이러한 지식은 팀 내에서의 협업을 원활하게 하고, 더 나은 솔루션을 제안하는 데 도움이 될 것같습니다.

또한, 개인 프로젝트를 진행할 때 상황에 맞는 최적화된 인프라를 구성하는 데도 큰 도움이 될 것이라고 생각합니다. (비용 최적화 인프라를 구성하신 커피한잔 개발자 인터뷰)

Snowball Edge

• AWS Snowball Edge Storage Optimized 디바이스를 사용하여 약 80TB까지 전송할 수 있다.
• 더 큰 용량의 데이터 세트도 여러 디바이스를 주문해서 전송할 수 있다.
• Snowball Edge를 사용해 최대 80TB의 데이터를 AWS로 전송하는데 걸리는 종단 간 시간은 약 1주일
• 수십, 수백 TB의 데이터를 마이그레이션 한다고 하면 Snowball

exam-9

Amazon S3 File Gateway

• 업계 표준 파일 프로토콜을 사용하여 파일을 원활하게 S3에 객체로 저장하고, 이에 액세스할 수 있는 파일 인터페이스를 애플리케이션에 제공하는 AWS Storage Gateway 서비스이다.
• 네트워크 파일 시스템(NFS) 및 서버 메시지 블록(SMB)와 같은 파일 프로토콜을 사용하여 S3에서 객체를 저장하고 검색할 수 있다.
• S3 File Gateway를 통해 작성된 객체는 S3에서 직접 액세스할 수 있다.

사용사례

1. 백업 및 아카이브를 클라우드로 이동
2. 클라우드 기반 파일 공유를 통한 온프레미스 스토리지 감소
3. 온프레미스 애플리케이션에 AWS에 저장된 데이터에 대한 짧은 대기 시간의 액세스 제공

S3 교차 리전 복제(Cross-Region Replication, CRR)

• S3의 기능 중 하나로 여러 AWS 리전 간에 객체를 자동으로 복제할 수 있게 해주는 서비스
• CSS를 사용해 데이터의 가용성을 높이고 재해복구 전략을 강화할 수 있다.
• 특정 리전에서 객체가 생성되거나 업데이트될 때, 설정된 다른 리전에 있는 동일 버킷의 객체가 자동으로 복제된다.
• 복제는 비동기로 수행되고 복제 지연 시간은 몇 초 ~ 몇 분 정도 걸린다.
• S3 교차 리전 복제를 통해 데이터 복제의 자동화와 데이터 가용성을 높일 수 있지만, 복제된 데이터가 발생하는 비용과 복제 지연 시간을 고려해야 한다.

사용사례

• 1. 재해 복구
  • 재해 시나리오를 대비하여 다른 지역에 데이터를 복제한다.
• 2. 지리적 규정 준수
  • 데이터가 특정 지역에 물리적으로 저장되어야 하는 규정 준수 요구 사항을 충족시키기 위해 데이터를 복제한다.

AWS DataSync

• AWS에서 제공하는 완전 관리형 데이터 전송 서비스.
• 해당 서비스를 통해 온프레미스 스토리지 시스템과 AWS 클라우드 스토리지 간의 데이터 동기화를 쉽고 신속하게 수행할 수 있도록 도와준다.
• 스케줄링 기능을 지원하여 주기적 또는 이벤트 기반으로 데이터 전송 작업을 자동화할 수 있다.
  • 이를 통해 지속적인 동기화를 가능하게 한다.

사용사례

• 데이터 마이그레이션
• 데이터 백업 및 복원
• 데이터 분석 및 처리 등

exam-19

게이트웨이 로드 밸런서

• 게이트웨이 로드 밸런서를 사용하면 방화벽, 침입 탐지 및 방지 시스템, 심층 패킷 검사 시스템과 같은 가상 어플라이언슬르 배포, 확장 및 관리할 수 있다.

검사VPC

• 검사 VPC에 게이트웨이 로드 밸런서를 배포한다.
• 게이트웨이 로드 밸런서 엔드포인트를 생성하여 수신 패킷을 수신하고 패킷을 어플라이언스로 전달한다.

exam-28

SSO 통합

• AWS SSO는 온프레미스 AD(Active Directory)와의 통합을 통해 중앙 인증 및 권한 부여를 관리할 수 있다.
• 단방향 포리스트 트러스트 또는 도메인 트러스트를 생성하여 자체 관리형 Microsoft Active Directory를 AWS SSO와 연결하면, 온프레미스에서 사용자 및 그룹을 유지하면서 AWS SSO를 사용해 AWS 리소스에 대한 접근을 중앙 관리할 수 있다.

exam-47

예약 인스턴스(Reserved Instance)

• 예약 인스턴스는 일정 기간(1년, 3년) 동안 특정 인스턴스 유형과 지역(Resion)에 대한 용량을 예약하는 옵션이다.
• 예약 인스턴스를 특정 가용 영역에 대해 예약할 수 없다.

주문형 용량(On-demand Capacity)

• 주문형 용량은 요구에 따라 필요한 만큼의 EC2 인스턴스를 사용할 수 있는 옵션이다.
• 사용한 시간만큼 비용이 청구된다.
• 가용 영역에 대한 예약이 가능하다.

exam-78

AWS Backup

• AWS Backup은 DynamoDB 테이블을 포함하여 다양한 서비스의 백업을 자동으로 관리하고, 백업 일정 및 보존 정책을 통해 장기적으로 데이터를 관리할 수 있는 백업 솔루션을 제공한다.
• 백업 일정과 보존 정책을 설정하면 데이터 보존을 자동화하고, 백업을 수동으로 관리할 필요가 없다.

DynamoDB 백업

• DynamoDB 백업 기능을 사용하면 테이블의 전체 백업을 생성하여 규정 준수 요건에 맞도록 장기간 유지하고 보관할 수 있다.
• 다만, 특정 시점 복구(PITR)은 최근 테이블의 35일내에서 어느 시점이던 초 단위로 복원할 수 있다.

exam-109

S3 객체 잠금 사용

• S3 객체 잠금을 사용하여 고정된 시간 혹은 무기한으로 S3 객체의 삭제 또는 덮어쓷기를 방지하는 데 도움이 된다.
• 법적 보존 잠금을 사용하면서 명시적으ㅗ 제거할 때까지 법적 보존이 유지된다.
• s3:PutObjectLegalHold 권한을 지닌 사용자가 자유롭게 배치하고 제거할 수 있다.

exam-117

CloudWatch Logs 구독

• CloudWatch Logs 구독을 사용하여 amazon OpenSearch Service 클러스터로 로그 데이터를 거의 실시간으로 스트리밍할 수 있다.
• 또한 Amazon Kinesis Stream, Amazon Data Firehose Stream 과 같은 다른 서비스로 전송하거나 사용자 지정 처리, 분석을 AWS Lambda 수행하거나 다른 시스템으로 로드할 수 있다.

CloudWatch Logs Insight

• CloudWatch Logs의 로그 데이터를 대화형 방식으로 검색하고 분석할 수 있다.
• Amazon Route 53, AWS Lambda, AWS CloudTrail, Amazon VPC와 같은 AWS 서비스의 로그와 로그 이벤트를 JSON으로 내보내는 모든 애플리케이션 또는 사용자 지정 로그의 필드를 자동으로 검색한다.

exam-135

AWS PrivateLink

• 트래픽을 공용 인터넷에 노출하지 않고 VPC, AWS 서비스 및 사내 넨트워크 간의 개인 연결을 제공한다.
• 다양한 계정 및 VPC에서 서비스를 쉽게 연결하여 네트워크 아키텍처를 크게 간소화할 수 있다.
• AWS PrivateLink에서 제공하는 인터페이스 VPC 엔드포인트는 AWS Partners에서 호스팅하는 서비스와 AWS Marketplace에서 사용할 수 있게 지원되는 솔루션에 연결한다.

가상 프라이빗(사설) 게이트웨이

• 별도의 계정에서 Direct connect Gateway가 설정되어 있는 상태에서, 다른 계정에 있는 VPC 또한 온프레미스에 접근하고 싶을 때 VGW(Virtual Private Gateway)를 사용하게 된다.

exam-172

필드 수준 암호화

• 필드 수준 암호화를 사용하여 민감한 데이터를 보호할 수 있다.
• 필드 수준 암호화는 특정 애플리케이션만 볼 수 있도록 시스템 처리 전반에 걸쳐 특정 데이터를 보호할 수 있는 추가 보안 계층을 추가한다.
• 필드 수준 암호화를 사용하려면 CloudFront 배포를 구성할 때 암호화하려는 POST 요청의 필드 세트와 이를 암호화하는데 사용할 퍼블릭 키를 지정한다.
• 요청에서 최대 10개의 데이터 필드를 암호화할 수 있다.

exam-175

Amazon RDS Proxy

• Amazon Rds Proxy는 Amazon RDS를 위한 완전 관리형 고가용성 데이터베이스 프록시로 애플리케이션의 확장성과 데이터베이스 오류에 대한 복원력 및 보안을 더욱 강화한다.
• 최신 서버리스 아키텍처 기반의 애플리케이션을 포함한 많은 애플리케이션은 DB 서버에 대한 많은 수의 연결을 가질 수 있으며 DB 연결을 빠른 속도로 열고 닫을 수 있어 DB 메모리 및 컴퓨팅 리소스에 부담을 줄 수 있다.
• Amazon RDS Proxy를 사용하면 DB와의 연결을 결합하고 공유할 수 있으므로 DB 효율성과 애플리케이션 확장성이 향상된다.
• RDS Proxy를 사용하면 Aurora 및 RDS DB의 장애 조치 시간이 최대 66% 단축된다.

exam-208

S3 인터페이스 VPC 엔드포인트

• 인터페이스 VPC 엔드포인트를 사용하면 AWS PrivateLink를 통해 Amazon S3와 연결할 수 있다.
• 이 연결은 VPC 내부 트래픽만 사용하므로, 데이터가 공개 인터넷을 통해 전송되지 않는다.

exam-219

Amazon CloudWatch 에이전트

• Amazon Ec2는 인스턴스와 관련된 일련의 지표를 CloudWatch에 전달합니다.
• 여기에는 CPU 사용률, NetWorIn, NetWorkOut 지표 집합이 포함된다.
  • EC2는 OS 수준의 메모리 사용량 또는 디스크 사용량 지표를 제공하지 않는다.
• 사용자 지정 지표로 CloudWatch에 전달하려면, CloudWatch 에이전트를 설치해야 한다.

VPC - Traffic Mirroring

• VPC에서 네트워크 트래픽을 수집하고 검사하되 방해되지 않는 방식으로 실행하는 기능
• 사용사례
  • 콘텐츠 검사
  • 위협 모니터링
  • 네트워킹 문제 해결

VPC Peering

• 다양한 리전과 계정에서 VPC를 생성할 수 있다.
• AWS 네트워크를 통해 연결하고 싶을 때 사용한다.
• VPC가 모두 같은 네트워크에서 작동하도록 만들기 위함이다.
• VPC Peering은 서로 다른 리전 혹은 계정 또는 같은 계정에 있는 VPC 간 통신을 하기 위해서는 VPC 피어링을 활성화하면 된다.
• VPC 피어링 활성화는 당연하고, VPC 서브넷 상 루트 테이블도 업데이트하여 EC2간 통신이 가능하게 해야된다.

Transit Gateway

• VPC 여러 개를 피어링으로 전부 연결하고, VPN 연결, Direct Connect 구축해서 Direct Connect Gateway로 여러 VPC를 연결하는건 굉장히 복잡하다.
• 이런 문제 해결을 위해 Transit Gateway를 만들었다.
• 중앙에 있는 Transit Gateway를 통해 VPC 여러 개를 연결할 수 있다.
  • Direct Connection Gateway와 연결하면 Direct Connect 연결이 각기 다른 VPC에 직접 연결 가능
  • Site-to-Site VPN과 VPN 연결을 선호한다면 고객 게이트웨이와 VPN connection을 Transit Gateway와 연결하여 모든 VPC에 액세스 가능
• 계정 간 공유를 하려면 Resource Access Manager를 사용한다.
• 시험에서는 IP 멀티캐스트 키워드가 나오면 Transit Gateway로 생각하면 된다.

AWS에서 네트워크 보호 방법

• 1. 네트워크 액세스 제어 목록(NACL)
• 2. Amazon VPC Security Groups
• 3. AWS WAF
• 4. AWS Shield & AWS Shield Advanced
• 5. AWS Firewall Manager(여러 계정에 적용 가능)
• 6. AWS Network Firewall(VPC 방화벽)
  • VPC 간 트래픽 인터넷 아웃바운드, 인터넷 인바운드
  • Direct Connect or Site to Site VPN
  • 내부적으로 AWS Gateway Load Balancer를 사용함
  • 단, 타사 어플라이언스가 아닌 AWS 자체 어플라이언스를 통해 트래픽을 관리
  • 도메인별 필터링이 가능하여 특정 기업 도메인 액세스를 허용 or 타사 소프트웨어 액세스 허용 등

전송중 암호화 (SSL) 전송 중 암호화는 데이터가 전송되기 전 암호화되고 서버가 데이터를 받으면 복호화한다. SSL 인증서가 암호화를 해주고 다른 방법은 HTTPS가 있다. Amazon 서비스를 다룰 때마다 HTTPS 엔드포인트가 있어서 전송 중 암호화가 됐음을 보장한다. 기본적으로 전송 중 암호화를 활성화하면 '중간자' 공격으로부터 보호된다.

서버 측 저장 데이터 암호화

데이터가 서버에 수신된 후 암호화하는 것 서버가 데이터를 암호화된 형태로 저장하고 있다는 점이 중요하다. 데이터는 클라이언트로 다시 전송되기 전에 복호화된다. 즉, 데이터 키라고 불리는 키 덕분에 데이터는 암호화된 형태로 저장되고 암호 키와 해독 키는 주로 KMS(Key Management Service) 같은 곳에 따로 관리된다. 따라서 서버는 KMS와 통신할 수 있어야 한다.

클라이언트 측 암호화

클라이언트 측 암호화에서 데이터는 클라이언트가 암호화하고 여기서 클라이언트는 우리고 서버는 그 데이터를 절대 복호화할 수 없고 데이터를 받는 클라이언트에 의해 복호화된다. 전체적으로 데이터는 서버에 저장되지만 서버는 데이터의 내용을 알 수 없다. 서버는 데이터를 복호화할 수 없어야 한다. 봉투 암호화의 간단한 예시 여기 객체가 있고 클라이언트는 데이터 키를 사용해서 클라이언트 측의 데이터를 암호화한다. 이제 해당 데이터를 원하는 데이터 저장소로 보낸다. FTP가 될 수도 있고 S3도 될 수 있고 무엇이든 상관 없다. 그리고 데이터를 받으면 클라이언트는 암호화된 객체를 받고 데이터 키에 액세스가 있거나 다른 곳으로부터 데이터 키를 찾을 수 있으면 받은 데이터를 복호화하여 복호화된 객체를 얻게 된다. 서버 데이터 저장소는 데이터를 암호화하거나 복호화할 수 없고 그저 암호화된 데이터를 받기만 할 수 있다.

KMS (Key Management Service)

AWS 서비스로 암호화한다고 하면 KMS 암호화일 가능성이 크다. KMS 서비스를 사용하면 AWS에서 암호화 키를 관리한다. KMS는 권한 부여를 위해 IAM과 완전히 통합되고 KMS로 암호화한 데이터에 관한 액세스를 더 쉽게 제어하도록 한다. AWS KMS를 사용의 장점으로는 CloudTrail을 통해 키를 사용하기 위해 호출한 모든 API를 감사할 수 있다는 점이다. (중요) 저장 데이터를 EBS 볼륨에서 암호화하려면 KMS 통합을 활성화하면 된다. S3, RDS, SSM도 동일 KMS을 직접 적용할 수도 있다. (API 호출, AWS CLI, SDK) 암호 데이터는 절대로 평문으로 저장하면 안 된다. 특히 코드에는 남기면 안된다.

대칭키(Symmetric)

대칭 KMS 키에는 데이터 암호화와 복호화에 사용하는 단일 암호화 키만 있어서 KMS와 통합된 모든 AWS 서비스는 대칭 키를 사용 KMS 대칭 키를 생성하거나 사용하면 키 자체에는 절대로 액세스할 수 없고 키를 활용 또는 사용하려면 KMS API를 호출해야 한다.

비대칭키(Asymmetric), 공개키

KMS에서 사용 가능한 두 번째 키는 바로 비대칭 키라고 한다. 2개의 키를 의미 데이터 암호화에 사용하는 퍼블릭 키와 데이터 복호화에 사용하는 프라이빗 키 따라서 암호화, 복호화와 작업 할당 및 검증에 사용 이 경우에는 KMS에서 퍼블릭 키를 다운로드 할 수 있지만 프라이빗 키에는 액세스할 수 없다. 프라이빗 키에 액세스하려면 API 호출로만 가능

KMS 키 타입7

KMS로 호출하는 모든 API도 비용을 지불해야 한다. API 호출 10,000건당 약 3센트

AWS 관리형 키

이 키는 aws/rds나 aws/ebs와 같이 이름이 지정된다. AWS 서비스와 통합되어 있으며 무료 서비스이므로 AWS에서 관리하며 특정 서비스에 관한 저장 데이터 암호화에 사용할 수 있다.

고객 관리형 키 (CMK)

KMS를 사용해 생성 가능하고 키 하나에 매달 1달러의 비용이 든다.

외부에서 가져온 고객 관리형 키

자체 키 구성 요소를 KMS에 가져올 수 있다. KMS에서 생성할 수 있고 동일하게 매달 1달러의 비용이 든다.

키 교체

보안을 위해서 자동으로 키를 교체하도록 설정할 수 있다. AWS 자동 관리형 키를 사용하면 자동으로 1년에 한 번씩 교체되며 고객 관리형 KMS 키를 사용하면 반드시 교체되도록 활성화해야 한다. 활성화한 후에는 자동으로 1년에 한 번씩 교체되며 교체 빈도를 변경할 수는 없다. 자체 키 구성 요소를 KMS로 보내려면 수동으로만 키를 교체할 수 있고 올바르게 키를 교체하려면 반드시 KMS 키 별칭을 사용해야 한다.

키 정책

KMS 키에 관한 액세스를 제어하는 것으로 S3 버킷 정책과 비슷하지만 차이점이 있는데 KMS 키에 KMS 키 정책이 없으면 누구도 액세스할 수 없다. 이와 관련해 2가지 유형의 KMS 키 정책이 있다.

기본 정책

기본 정책은 사용자 지정 키 정책을 제공하지 않으면 생성된다. 기본적으로 계정의 모든 사람이 키에 액세스하도록 허용 즉, 사용자 또는 키 정책의 액세스를 허용하는 IAM 정책이 있으면 된다.

사용자 지정 키 정책

제어를 조금 더 특정하고자 할때 KMS 키에 액세스할 수 있는 사용자 또는 역할을 정의하고 키 관리자를 정의할 수 있는 정책 KMS 키에 관한 교차 계정 액세스 시 매우 유용 다른 계정이 KMS 키를 사용하도록 권한을 부여하기 때문 사용 사례는 계정 간에 스냅샷을 복사할 때 자체 KMS 키로 암호화한 스냅샷을 생성하면 고객 키 정책을 연결해야 하므로 고객 관리형 키가 되며 교차 계정 액세스 권한 부여를 위해 KMS 키 정책을 연결 암호화된 스냅샷을 대상 계정에 공유하면 대상 계정에서는 스냅샷 복제본을 생성하고 해당 대상 계정에서 다른 고객 관리형 키로 암호화한다. 이렇게 대상 계정의 스냅샷에서 볼륨을 생성하면 끝이다.

KMS Multi Region Keys

AWS KMS에는 다중 리전 키를 둘 수 있다. 선택된 한 리전에 기본 키를 갖는다는 의미 다른 리전도 동일한 키를 갖게 되는데 키 ID와 구성 요소가 완전히 똑같다. KMS 다중 리전 키는 다른 AWS 리전에서 사용할 수 있는 KMS 키 세트로 서로 교차해서 사용할 수 있다. 한 리전에서 암호화한 다음 다른 리전에서 복호화 할 수 있다. 핵심은 한 리전에서 암호화하고 다른 리전에서 복호화해 다음 리전으로 복제할 때나 교차 리전 API 호출을 실행할 때 데이터를 재암호화하지 않아도 된다는 점 하지만 KMS 다중 리전 키는 전역으로 사용할 수 없다. 기본 키가 있고 복제본이 있는 것 각 다중 리전 키는 자체 키 정책 등으로 각각 독립적으로 관리 따라서 특정 사용 사례를 제외하고는 다중 리전 키 사용을 권장하지 않는다. 다중 리전 키의 사용 사례에는 전역 클라이언트 측 암호화가 있다.

S3 암호화 복제

한 버킷에서 다른 버킷으로 S3 복제를 활성화하면 암호화되지 않은 객체와 SSE-S3로 암호화된 객체가 기본으로 복제 고객 제공 키인 SSE-C로 객체를 암호화하면 복제되지 않는다. SSE-KMS로 암호화된 객체도 있다. 기본적으로 복제되지 않지만 만약 객체를 복제하려면 옵션을 활성화해야 한다. 따라서 어떤 KMS 키로 대상 버킷 내 객체를 암호화하는지 지정해야 합니다 그리고 이 KMS 키 정책을 대상 키에 적용해야 하고 S3 복제 서비스를 허용하는 IAM 역할을 생성해서 소스 버킷의 데이터를 먼저 복호화하도록 한 뒤 대상 KMS 키로 대상 버킷의 데이터를 다시 암호화한다. 이렇게 하면 복제가 활성화되는데 이는 수많은 암호화와 복호화가 발생하기 때문 KMS 스로틀링 오류가 발생한 경우는 서비스 할당량을 요청해야 한다. 여기서 S3 복제에 다중 리전 키를 사용해야 할까? 공식 문서에 따르면 S3 복제에 다중 리전 키를 사용할 수 있으나 현재는 Amazon S3 서비스에서 독립 키로 취급하고 있으므로 객체는 여전히 복호화될 것이고 다중 리전 키인 경우에도 동일한 키로 암호화된다.

암호화된 AMI 공유 프로세스

AMI는 KMS 키로 암호화 되어 있습니다 AMI는 소스 계정에 있고 KMS 키로 암호화된 것 어떤 방식으로 A 계정의 AMI에서 B 계정의 EC2 인스턴스를 시작할 수 있을까? 먼저, 시작 권한으로 AMI 속성을 수정해야 하는데 이 시작 권한은 B 계정에서 AMI를 시작하도록 허용한다. 이렇게 AMI를 공유 시작 권한을 수정하고 특정 대상인 AWS 계정 ID를 추가하는 것 그런 다음 B 계정에서 사용하도록 KMS 키도 공유해야 하므로 일반적으로 키 정책으로 실행 이제 B 계정에서 KMS 키와 AMI를 모두 사용할 수 있는 충분한 권한을 가진 IAM 역할이나 IAM 사용자를 생성 따라서 DescribeKey API 호출과 ReEncrypted API 호출 CreateGrant, Decrypt API 호출에 관한 KMS 측 액세스 권한이 있어야 한다. 모두 완료된 후에는 AMI에서 EC2 인스턴스를 시작하면 되는데 선택 사항으로 대상 계정에서 자체 계정의 볼륨을 재암호화하는 KMS 키를 이용해 전체를 재암호화할 수 있다. 이제 EC2 인스턴스를 실행할 수 있다.

SSM 매개변수 저장소

구성 및 암호를 위한 보안 스토리지 구성을 암호화할지 선택할 수 있으므로 KMS 서비스를 이용해 암호를 만들 수 있다. SSM Parameter Store는 서버리스이며 확장성과 내구성이 있고 SDK도 사용이 용이 또한 매개변수를 업데이트할 때 구성과 암호의 버전을 추적할 수도 있다. IAM을 통해 보안이 제공되며 특정한 경우에는 Amazon EventBridge로 알림을 받을 수도 있다. CloudFormation이 Parameter Store의 매개변수를 스택의 입력 매개변수로 활용할 수 있다.

Paramters Policies

고급 매개변수에서만 사용할 수 있다. 매개변수 정책을 통해 만료 기한을 뜻하는 타임 투 리브(TTL)를 매개변수에 할당할 수 있다. 비밀번호 등의 민감한 정보를 업데이트 또는 삭제하도록 강제한다. 한 번에 여러 정책을 할당할 수도 있다.

AWS Secrets Manager

암호를 저장하는 최신 서비스로 SSM Parameter Store와는 다른 서비스 Secrets Manager는 X일마다 강제로 암호를 교체하는 기능이 있어 암호 관리를 더 효율적으로 할 수 있다. 또한 AWS Secrets Manager로 교체할 암호를 강제 생성 및 자동화할 수 있다. 이를 위해 새 암호를 생성할 Lambda 함수를 정의해야 한다. AWS Secrets Manager는 AWS가 제공하는 다양한 서비스와도 아주 잘 통합된다. (RDS, MySQL,PostgreSQL, Aurora 등) AWS 외 여러 서비스와 데이터베이스에도 즉시 통합할 수 다. 데이터베이스에 접근하기 위한 사용자 이름과 비밀번호가 AWS Secrets Manager에 바로 저장되고 교체 등도 가능하다. 암호는 KMS 서비스를 통해 암호화된다. RDS와 Aurora의 통합 혹은 암호에 대한 내용이 시험에 나오면AWS Secrets Manager를 떠올려야 한다.

다중 리전 암호

복수 AWS 리전에 암호를 복제할 수 있고 AWS Secrets Manager 서비스가 기본 암호와 동기화된 읽기 전용 복제본을 유지한다는 개념 이렇게 두 리전이 있을 때 기본 리전에 암호를 하나 만들면 보조 리전에 동일한 암호가 복제된다. 이렇게 하는 데에는 여러 이유가 있다. 첫째, us-east-1에 문제가 발생하면 암호 복제본을 독립 실행형 암호로 승격할 수 있다. 그리고 여러 리전에 암호가 복제되니 다중 리전 앱을 구축하고 재해 복구 전략도 짤 수 있다. 한 리전에서 다음 리전으로 복제되는 RDS 데이터베이스가 있다면 동일한 암호로 동일한 RDS 데이터베이스즉 해당 리전의 해당 데이터베이스에 액세스할 수 있다.

AWS Certificate Manager(ACM)

ACM은 TLS 인증서를 AWS에서 프로비저닝, 관리 및 배포하게 해준다. ACM은 퍼블릭과 프라이빗 TLS 인증서를 모두 지원하며 퍼블릭 TLS 인증서 사용 시에는 무료로 이용할 수 있다. 인증서를 자동으로 갱신하는 기능도 있다. 그리고 여러 AWS 서비스와 통합되어 있어 Elastic Load Balancer(ELB)에 TLS 인증서를 불러올 수 있다. (ALB, NLB) CloudFront 배포나 API Gateway의 모든 API에서도 불러올 수 있다. 다만 ACM을 사용할 수 없는 곳이 하나 있는데 바로 EC2 인스턴스

엔드 포인트 유형

엣지 최적화(edge-optimized) 유형

글로벌 클라이언트를 위한 유형으로 먼저 CloudFront 엣지 로케이션으로 요청을 라우팅하여 지연을 줄이는 방법으로 하나의 리전에만 있는 API Gateway로 보내지는 경우

리전(regional) 엔드 포인트 유형

클라이언트가 API Gateway와 같은 리전에 있을 때를 쓰인다. 이 경우 CloudFront는 사용할 수 없지만 자체 CloudFront 배포를 생성하여 캐싱 및 배포 전략을 제어할 수 있다

프라이빗(private) API Gateway 엔드포인트 유형

인터페이스 VPC 엔드 포인트(ENI)를 통해 VPC 내부에만 액세스할 수 있다. 또한 프라이빗 모드에서는 API Gateway에 대한 액세스를 정의하는 리소스 정책이 필요하다. ACM은 엣지 최적화 및 리전 엔드포인트에 적합하다.

웹 애플리케이션 방화벽 (WAF)

WAF는 7계층에서 일어나는 일반적인 웹 취약점 공격으로부터 웹 애플리케이션을 보호한다. 계층 7은 HTTP이니 HTTP 취약점 공격을 막아주는 것 웹 애플리케이션 방화벽(WAF)의 배포는 애플리케이션 로드 밸런서, API Gateway CloudFront AppSync GraphQL API Cognito 사용자 풀에 할 수 있다. WAF의 배포가 어디에 되는 지 꼭 기억해야한다. WAF를 NLB에 배포한다는 것은 틀렸다. 이는 4계층 이러한 서비스에 방화벽을 배포한 후에는 웹 액세스 제어 목록(ACL)과 규칙을 정의해야 한다. 이 규칙이란 IP 주소를 기반으로 필터링하는 등의 규칙 IP 세트를 정의할 수 있으며 각 IP 세트는 최대 10,000개의 IP 주소를 가질 수 있다. 또한 HTTP 헤더와 본문에 기반해 필터링할 수도 있고 URI 문자열을 조건으로 두어 SQL 주입, 크로스 사이트 스크립팅(XSS) 등의 일반적인 공격을 차단할 수도 있다 용량에 제약을 걸어 요청이 최대 2MB를 넘지 않게 하거나 지역 일치(Geo-match) 조건을 두어 특정 국가를 허용 또는 차단 가능 또 속도 기반 규칙을 설정하면 IP당 요청 수를 측정하여 디도스 공격을 막을 수도 있다 웹 ACL은 리전에만 적용되며 CloudFront는 글로벌로 정의됩니다 규칙 그룹은 여러 웹 ACL에 추가할 수 있는 재사용 가능한 규칙 모음

AWS Shield

AWS Shield는 디도스 공격으로부터 스스로를 보호하기 위한 서비스 디도스란 분산 서비스 거부 공격이라는 뜻. 인프라에 동시에 엄청난 양의 요청이 세계 곳곳의 여러 컴퓨터에서 유입되는 공격 그 목적은 인프라에 과부하를 일으키는 것으로 실제 사용자들에게 서비스를 제공할 수 없게 만든다. 즉 분산 서비스 거부가 발생 디도스 공격을 방어하려면 AWS Shield 스탠다드 서비스를 이용하면 된다. 이 서비스는 모든 AWS 고객에게 무료로 활성화되어 있는 서비스로 SYN/UDP Floods나 반사 공격 및 L3/L4 공격으로부터 고객을 보호해 준다. 고급 보호가 필요한 고객을 위한 AWS Shield 어드밴스드 서비스도 있는데 어드밴스드는 선택적으로 제공되는 디도스 완화 서비스로 조직당 월 3,000달러를 지불해야 한다. 어드밴스드에서는 더욱 정교한 디도스 공격을 막아주며 Amazon EC2, ELB Amazon CloudFront AWS Global Accelerator 그리고 Route 53를 보호한다. 또한 AWS 디도스 대응 팀이 항시 대기하고 있어 공격을 받았을 때 지원을 받을 수 있다. 따라서 디도스 공격으로 인한 요금 상승을 AWS Shield 어드밴스드를 통해 방지할 수 있겠다. 또 Shield 어드밴스드는 자동 애플리케이션 계층 디도스 완화도 제공하여 자동으로 WAF 규칙을 생성, 평가, 배포함으로써 L7 공격을 완화할 수 있다. 즉 웹 애플리케이션 방화벽이 L7에서 일어나는 디도스 공격을 완화하는 규칙을 자동으로 갖게 된다는 뜻

AWS Firewall Manager

AWS Organizations에 있는 모든 계정의 방화벽 규칙을 관리하는 서비스 여러 계정의 규칙을 동시에 관리할 수 있다. 또한 보안 규칙의 집합인 보안 정책을 설정할 수 있는데 여기에는 ALB, API Gateway CloudFront 등에 적용되는 웹 애플리케이션 방화벽(WAF) 규칙이나 ALB, CLB, NLB, 엘라스틱 IP CloudFront를 위한 AWS Shield 어드밴스드 규칙 등이 포함된다. 또 EC2, 애플리케이션 로드 밸런서 VPC의 ENI 리소스를 위한 보안 그룹을 표준화하는 보안 정책과 아직 다룬 적은 없지만 VPC 수준의 AWS Network Firewall도 해당된다. 그리고 Amazon Route 53 Resolver DNS Firewall도 포함된다. AWS Firewall Manager는 이와 같은 모든 방화벽을 한 곳에서 관리할 수 있도록 지원해 준다. 정책은 리전 수준에서 생성되며 조직에 등록된 모든 계정에 적용된다.

WAF, Firewall Manager, Shield 차이

WAF, Shield Firewall Manager는 모두 포괄적인 계정 보호를 위한 서비스 일단 WAF에서는 웹 ACL 규칙을 정의하는데 리소스별 보호를 구성하는 데에는 WAF가 적절합니다 여러 계정에서 WAF를 사용하고 WAF 구성을 가속하고 새 리소스 보호를 자동화하려면 Firewall Manager로 WAF 규칙을 관리 Firewall Manager는 이러한 규칙들을 모든 계정과 모든 리소스에 자동으로 적용해준다. Shield 어드밴스드는 디도스 공격으로부터 고객을 보호하고 WAF의 기능 외에도 더 많은 기능을 제공 예를 들어 Shield 대응 팀 지원 고급 보고서 제공 그리고 WAF 규칙 자동 생성 등의 기능을 추가로 이용할 수 있다. 디도스 공격을 자주 받는다면 Shield 어드밴스드를 사용하는 것도 좋은 선택지가 될 수 있다. 또한 Firewall Manager는 모든 계정에 Shield 어드밴스드를 배포에도 도움을 준다.

GuardDuty

AWS 계정을 보호하는 지능형 위협 탐지 서비스 백엔드에서 머신 러닝 알고리즘을 사용하여 이상 탐지를 수행하고 타사 데이터를 이용하여 계정에 대한 공격을 탐지한다. Amazon GuardDuty는 여러 소스에서 입력 데이터를 얻는다. CloudTrail 이벤트 로그의 입력 데이터를 가지고 비정상적 API 호출과 무단 배포 등을 탐지한다. 관리 이벤트에서 사용하여 해당 이벤트가 VPC 서브넷을 만들 때 생기는지 API가 계정에 호출하는 추적 생성 시 생기는지 확인한다. CloudTrail S3 데이터 이벤트를 확인한다. 예를 들어 버킷에서 발생하는 이벤트인 API 호출, 즉 get object, list objects delete object 등 VPC 흐름 로그를 통해 비정상적인 인터넷 트래픽과 IP 주소를 찾고 또한 DNS 로그는 DNS 쿼리에서 인코딩된 데이터를 전송할 EC2 인스턴스가 손상되었는지 확인할 수 있다. Kubernetes 감사 로그를 확인하여 의심스러운 활동 및 잠재적인 EKS 클러스터 손상을 감지한다. 이 모든 작업이 내부적으로 이루어진다. 그리고 CloudWatch 이벤트 규칙을 설정하여 탐색 결과가 나타나면 알림을 받을 수 있다. 마지막으로 시험에 나올 수 있는 내용은 GuardDuty로 암호화폐 공격을 보호할 수 있다는 점 요약하면 GuardDuty는 VPC 흐름 로그, CloudTrail 로그 DNS 로그 및 EKS 감사 로그를 모두 GuardDuty로 가져온다. 그리고 CloudWatch 이벤트 규칙 덕분에 Lambda 함수나 SNS 주제 알림을 받을 수 있다.

Amazon Inspector

Amazon Inspector는 몇 군데에서 자동화된 보안 평가를 실행할 수 있는 서비스

EC2 인스턴스 경우

EC2 인스턴스에서 시스템 관리자 에이전트를 활용하면 Amazon Inspector가 해당 EC2 인스턴스의 보안을 평가하기 시작한다. 의도되지 않은 네트워크 접근 가능성에 대해 분석하고, 실행 중인 운영 체제에서 알려진 취약점을 분석한다. 이건 연속적으로 수행된다.

컨테이너 이미지를 Amazon ECR로 푸시할 때 실행

예를 들어 도커 이미지 컨테이너 이미지가 Amazon ECR로 푸시되면 Amazon Inspector가 알려진 취약점에 대해 검사 Lambda 함수에 대해서도 사용 가능한데요 Amazon Inspector는 Lambda 함수가 배포될 때 함수 코드 및 패키지 종속성에서 소프트웨어 취약성을 다시 분석 즉, 함수가 배포될 때 평가 Amazon Inspector가 작업을 완료하면 결과를 AWS 보안 허브에 보고한다. 또한 이러한 결과 및 결과 이벤트를 Amazon Event Bridge로 보낸다. 이를 통해 인프라에 있는 취약점을 모아서 볼 수 있다. Inspector는 실행 중인 EC2 인스턴스, Amazon ECR의 컨테이너 이미지, Lambda 함수에만 사용된다

Macie

Macie는 완전 관리형의 데이터 보안 및 데이터 프라이버시 서비스이며 머신 러닝과 패턴 일치를 사용하여AWS의 민감한 정보를 검색하고 보호한다. 구체적으로 말하면 민감한 데이터를 경고하는데 예를 들면, 개인 식별 정보 즉, PII 같은 정보다. ex) S3버킷에 PII가 있다면 Macie에 의해 분석되고 어떤 데이터를 PII로 분류할 수 있는지 알아낸 후 EventBridge를 통해 발견 결과를 알려준다.

CloudWatch는 AWS의 모든 서비스에 대한 메트릭을 제공한다. 메트릭은 모니터링할 변수다. 계정에서 일어나는 모든 일을 모니터링할 수 있다. EC2 인스턴스의 메트릭은 CPUUtilization, NetworkIn 등이 있고 Amazon S3의 지표로는 버킷 크기 등이 있다. 메트릭은 namespaces에 속하므로 각기 다른 namespaces에 저장되며 서비스당 namespaces은 하나다. 지표의 속성으로 측정 기준(Dimension)이 있다. CPU 사용률에 대한 지표는 특정 인스턴스 ID나 특정 환경 등과 관련이 있다. 지표당 최대 측정 기준은 10개다. 지표는 시간을 기반으로 하므로 타임스탬프가 꼭 있어야 하고 지표가 많아지면 CloudWatch 대시보드에 추가해 모든 지표를 한 번에 볼 수 있다. CloudWatch 사용자 지정 지표를 만들 수도 있다.

Streams

CloudWatch 지표는 CloudWatch 외부로 스트리밍할 수 있다. CloudWatch 지표를 원하는 대상으로 지속적으로 스트리밍하면 거의 실시간으로 전송되고 지연 시간도 짧아진다. Amazon Kinesis Data Firehose가 대상이 될 수 있고 여기서 원하는 곳으로 전송할 수 있다. Datadog, Dynatrace New Relic, Splunk, Sumo Logic 같은 타사 서비스 제공자로 CloudWatch 지표를 직접 전송할 수도 있다. 모든 이름공간에 속한 모든 지표를 스트리밍하거나 몇몇 이름공간의 지표만 필터링할 수 있다. 필터링한 지표의 서브셋만 Kinesis Data Firehose로 보낼 수 있다.

CloudWatch Logs

CloudWatch Logs는 AWS에서 애플리케이션 로그를 저장할 수 있는 완벽한 곳이다. 로그들을 로그 그룹으로 그룹화하는데, 로그 그룹의 이름으로는 보통 애플리케이션을 나타낸다. 각 로그 그룹 내에는 다수의 로그 스트림이 있다. 로그 스트림은 애플리케이션 내 인스턴스나 다양한 로그 파일명 또는 컨테이너 등을 나타낸다. 로그 만료일도 정의할 수 있다. (로그가 만료되지 않게 하거나 일정 기간 후 만료되게 할 수 있다.) CloudWatch Logs 스토리지는 유료다. 로그는 Amazon S3나 Kinesis Data Streams 및 Firehose Lambda, ElasticSearch 등으로 내보낼 수 있다.

CloudWatch Logs - Sources

SDK, CloudWatch Logs 에이전트, 통합 CloudWatch 에이전트를 통해 로그를 보낼 수 있다. Elastic Beanstalk는 애플리케이션의 로그를 CloudWatch에 전송하고 ECS는 컨테이너의 로그를 CloudWatch에 전송한다. Lambda는 함수 자체에서 로그를 보낸다. VPC Flow Logs는 VPC 메타데이터 네트워크 트래픽 로그를 보내고 API Gateway는 받은 모든 요청을 CloudWatch Logs에 보낸다. CloudTrail은 필터링해 로그를 보낼 수 있고 Route53은 모든 DNS 쿼리를 로그로 저장한다.

CloudWatch Logs Metric Filter & Insights

CloudWatch Logs에서 필터 표현식을 쓸 수 있다. 로그 내 특정 IP를 찾을 수 있고, 특정 IP가 찍힌 로그를 찾거나 또는 'ERROR'라는 문구를 가진 모든 로그를 찾을 수 있다. 이 메트릭 필터를 통해 출현 빈도를 계산해 메트릭을 만들 수 있다. 그렇게 만들어진 메트릭은 CloudWatch 경보로 연동할 수 있다. CloudWatch Logs Insights 기능을 통해 로그를 쿼리하고 이 쿼리를 대시보드에 바로 추가할 수 있다.

기능

CloudWatch Logs에서 로그를 스트림하고 싶다면 구독 필터를 사용해야 한다. 구독 필터란 CloudWatch Logs 상단에 적용하여 이를 목적지로 보내는 필터를 말한다. 또한 CloudWatch Logs로 여러 계정과 리전간 로그를 집계할 수 있다.

CloudWatch 에이전트 & CloudWatch Logs 에이전트

CloudWatch Logs for Ec2

EC2 인스턴스에서 CloudWatch로는 기본적으로 어떤 로그도 옮겨지지 않는다. EC2 인스턴스에 에이전트라는 작은 프로그램을 실행시켜 원하는 로그 파일을 푸시해야 한다. CloudWatch Logs 에이전트가 EC2 인스턴스에서 작동해 CloudWatch Logs로 로그를 보낸다. 그러려면 EC2 인스턴스에 로그를 보낼 수 있게 해주는 IAM 역할이 있어야 한다. 또한 이 에이전트는 온프레미스 환경에서도 셋업될 수 있다.

CloudWatch Logs Agent & Unified Agent

CloudWatch에는 두 가지 에이전트가 있다. 오래된 CloudWatch Logs 에이전트와 최근에 나온 통합 CloudWatch 에이전트가 있다. 둘 다 EC2 인스턴스나 온프레미스 서버 같은 가상 서버를 위한 것 CloudWatch Logs 에이전트는 CloudWatch Logs로 로그만 보낸다. 반면 통합 에이전트는 프로세스나 RAM 같은 추가적인 시스템 단계 지표를 수집한다. 그리고 CloudWatch Logs에 로그를 보낸다. 이전 버전에는 없는 기능인 SSM Parameter Store를 이용해서 에이전트를 쉽게 구성할 수 있다. 모든 통합 에이전트를 대상으로 중앙 집중식 환경 구성을 할 수 있다.

Unified Agent Metrics

통합 에이전트를 EC2 인스턴스나 Linux 서버에 설치하면 지표를 수집할 수 있다. 먼저 훨씬 세분화된 수준으로 CPU 지표, 디스크 지표, 디스트 IO 지표, RAM 지표, 넷 상태 지표, 프로세스 지표, 스왑 공간 지표를 가져올 수 있다. 여기서의 핵심은 통합 CloudWatch 에이전트가 더 세부적이고 많은 지표를 수집한다는 것이다. (기본 EC2 인스턴스 모니터링보다) 세부 지표를 얻고 싶다면 통합 CloudWatch 에이전트를 이용하자.

CloudWatch Alarms

경보는 지표에서 알림을 트리거할 때 사용 sampling, %, max, min 등의 다양한 옵션을 추가해 복잡한 경보를 정의할 수도 있다. 경보에는 세 상태가 있다. OK: 트리거되지 않았음을 의미 INSUFFICIENT_DATA: 상태를 결정할 데이터가 부족함을 뜻함 ALARM: 임계값이 위반되어 알림이 보내지는 상태 기간은 경보가 지표를 평가하는 기간을 의미한다. 짧게 설정할 수도 길게 설정할 수도 있다. 고해상도 사용자 지정 지표에도 적용될 수 있는데 10초, 30초 또는 60초의 배수로 설정될 수 있다. 경보의 주 대상은 세 개 첫 번째는 EC2 인스턴스의 동작들. 인스턴스를 멈추거나, 삭제하거나 재시작하거나 복구하는 등의 동작을 말한다. 둘째는 Auto Scaling 동작의 트리거. 스케일 아웃과 스케일 인 등이 있다. 마지막은 SNS 서비스에 알림을 보내는 것. 예를 들어 SNS 서비스를 람다 함수로 연결해 람다 함수를 통해 위반된 경보에 우리가 원하는 작업을 수행할 수 있는 것. 경보 알림을 시험해 보고 싶다면 set-alarm-state라는 CLI 호출을 사용하면 된다.

Amazon EventBridge

과거 이름은 CloudWatch Events 클라우드에서 CRON 작업을 예약할 수 있고 스크립트를 예약할 수 있다. 이벤트 패턴에 반응할 수도 있다. 예를 들어 콘솔의 IAM 루트 사용자 로그인 이벤트에 반응할 수 있다. 또한 대상(destination)이 다양하다면 Lambda 함수를 트리거해서 SQS, SNS 메시지 등을 보낼 수 있다. Amazon EventBridge로 전송되는 이벤트에 필터를 설정할 수 있다. 예를 들어 Amazon S3에 있는 특정 버킷의 이벤트만 필터링하도록 하면 Amazon EventBridge는 이벤트의 세부 사항을 나타내는 JSON 문서를 생성할 겁니다 어떤 인스턴스가 이 ID로 실행되는지 등을 나타내고 시간, IP 등의 정보가 담긴다. JSON 문서 생성이 끝나면 이벤트들을 다양한 대상으로 전송할 수 있고 유용한 통합 기능을 사용할 수 있다. 지금 살펴본 Amazon EventBridge는 기본 이벤트 버스다. 파트너 이벤트 버스라는 서비스가 있다. 파트너와 통합된 AWS 서비스를 말하는데 대부분의 파트너는 소프트웨어 서비스 제공자다. 이 파트너들은 파트너 이벤트 버스로 이벤트를 전송한다. 특정 파트너 이벤트 버스로 이벤트를 전송할 수 있고 우리 계정을 통해 AWS 외부에서 일어나는 변화에 반응할 수 있게 된다. 사용자 지정 이벤트 버스도 있다. 사용자 커스텀 애플리케이션의 자체 이벤트를 사용자 지정 이벤트 버스로 전송한다. Amazon EventBridge 규칙 덕분에 다른 이벤트 버스처럼 여러 대상으로 이벤트를 보낼 수 있다. 리소스 기반 정책을 사용해 다른 계정의 이벤트 버스에 액세스할 수도 있고 이벤트도 아카이빙 된다.

Schema Registry

EventBridge는 여러 곳에서 이벤트를 받는다. 그러므로 이벤트가 어떻게 생겼는지 파악해야 한다. 이벤트는 JSON 형식 Amazon EventBridge는 버스의 이벤트를 분석하고 스키마를 추론하는 능력이 있다. 스키마 레지스트리의 스키마를 사용하면 애플리케이션의 코드를 생성할 수 있고 이벤트 버스의 데이터가 어떻게 정형화되는지 미리 알 수 있다. 스키마를 버저닝할 수도 있어 애플리케이션의 스키마를 반복할 수 있다.

리소스 기반 정책

특정 이벤트 버스의 권한을 관리할 수 있다. 예를 들면 특정 이벤트 버스가 다른 리전이나 다른 계정의 이벤트를 허용하거나 거부하도록 설정하는 것이다.

CloudWatch Insights

CloudWatch Container Insights

컨테이너로부터 지표와 로그를 수집, 집계, 요약하는 서비스 Amazon ECS나 Amazon EKS EC2의 Kubernetes 플랫폼에 직접 실행하는 컨테이너에서 사용할 수 있다. ECS와 EKS의 Fargate에 배포된 컨테이너에서도 사용할 수 있다. ` CloudWatch Container Insights를 사용하면 컨테이너로부터 지표와 로그를 손쉽게 추출해서 CloudWatch에 세분화된 대시보드를 만들 수 있다. CloudWatch Container Insights를 Amazon EKS나 Kubernetes EC2에서 실행되는 Kubernetes에서 사용할 경우 컨테이너화된 버전의 CloudWatch 에이전트를 사용해야 컨테이너를 찾을 수 있다.

Lambda Insights

AWS Lambda에서 실행되는 서버리스 애플리케이션을 위한 모니터링과 트러블 슈팅 솔루션 CPU 시간, 메모리 디스크, 네트워크 콜드 스타트나 Lambda 작업자 종료와 같은 정보를 포함한 시스템 수준의 메트릭을 수집, 집계, 요약한다. Lambda 함수를 위해 Lambda 계층으로 제된다. Lambda 함수 옆에서 실행되며 Lambda Insights라는 대시보드를 생성해 Lambda 함수의 성능을 모니터링한다. AWS Lambda에서 실행되는 서버리스 애플리케이션의 세부 모니터링이 필요할 때 사용

Contributor Insights

기고자(Contributor) 데이터를 표시하는 시계열 데이터를 생성하고 로그를 분석하는 서비스 예를 들어 상위 N개의 기고자나 총 고유 기고자 수 및 사용량을 볼 수 있다. VPC 로그, DNS 로그 등 AWS가 생성한 모든 로그에서 작동한다. 네트워크 로그나 VPC 로그를 확인해서 사용량이 가장 많은 네트워크 사용자를 찾을 수 있다. DNS 로그에서는 오류를 가장 많이 생성하는 URL을 찾을 수 있다. 모든 네트워크 요청에 대해 VPC 내에서 생성되는 로그인 VPC 플로우 로그가 CloudWatch Logs로 전달되고 CloudWatch Contributor Insights가 분석한다. 그러면 VPC에 트래픽을 생성하는 상위 10개의 IP 주소를 찾고 좋은 사용자인지 나쁜 사용자인지 판단할 수 있다.

CloudWatch Application Insights

모니터링하는 애플리케이션의 잠재적인 문제와 진행 중인 문제를 분리할 수 있도록 자동화된 대시보드를 제공한다. Java나 .NET Microsoft IIS 웹 서버나 특정 데이터베이스를 선택해 선택한 기술로만 애플리케이션을 실행할 수 있다. EBS, RDC, ELB ASG, Lambda, SQS DynamoDB, S3 버킷과 같은 AWS 리소스에 연결된다. 애플리케이션에 문제가 있는 경우 CloudWatch Application Insights는 자동으로 대시보드를 생성하여 서비스의 잠재적인 문제를 보여 준다. 자동화된 대시보드를 생성할 때 백그라운드에서는 내부에서 SageMaker 머신 러닝 서비스가 사용된다. 발견된 문제와 알림은 모두 Amazon EventBridge와 SSM OpsCenter로 전달된다. 애플리케이션에서 문제가 탐지되면 우리에게 알림이 온다.

CloudTrail

CloudTrail는 AWS 계정의 거버넌스, 감사 및 규정 준수를 돕는다. CloudTrail은 기본적으로 활성화돼 있고 콘솔, SDK, CLI뿐만 아니라 기타 AWS 서비스에서 발생한 AWS 계정 내의 모든 이벤트 및 API 호출 기록을 받아 볼 수 있다. 글로벌 서비스 즉 모든 로그가 CloudTrail에 표시된다. CloudTrail의 로그를 CloudWatch Logs나 Amazon S3로 옮길 수 있다. 전체 또는 단일 리전에 적용되는 트레일을 생성해 모든 리전에 걸친 이벤트 기록을 한 곳으로 모을 수 있다. (ex S3) 모든 이벤트를 90일 이상 보관하려면 CloudWatch Logs 또는 S3 버킷으로 보내야 한다.

CloudTrail Events

CloudTrail에는 세 종류의 이벤트가 있습니다 첫 번째는 관리 이벤트로 이는 AWS 계정의 리소스에서 수행되는 작업을 나타낸다. 예를 들어 누군가가 보안 설정을 구성하면 IAM AttachRolePolicy라는 API를 사용하게 되는데 이것이 CloudTrail에 표시된다. 리소스나 AWS 계정을 수정하는 모든 작업이 CloudTrail에 표시된다. 트레일(추적)은 기본적으로 관리 이벤트를 기록하도록 구성되어 있다. 관리 이벤트는 두 종류로 구분할 수 있다. 리소스를 수정하지 않는 읽기 이벤트와 리소스를 수정하는 쓰기 이벤트 두 번 째 이벤트는 데이터 이벤트 데이터 이벤트는 고볼륨 작업이므로 기본적으로 로깅되지 않는다. 데이터 이벤트란 무엇일까요? GetObject, DeleteObject PutObject와 같은 Amazon S3 객체 수준 작업은 S3 버킷에서 빈번히 발생하는 이벤트이므로 기본적으로 로깅되지 않고 읽기 이벤트와 쓰기 이벤트로 분리할 수 있다. Lambda 함수 실행 작업이 있다. 누군가 Invoke API를 사용할 때마다 Lambda 함수가 몇 번 활용되었는지 알 수 있다. 이 역시 Lambda 함수가 많이 실행되면 볼륨이 커질 수 있다. 세 번째 이벤트 종류는 CloudTrail Insights 이벤트 모든 유형의 서비스에 걸쳐 너무 많은 관리 이벤트가 있고 계정에서 다수의 API가 매우 빠르게 발생해서 무엇이 이상하거나 특이한지 파악하기 어려울 때 CloudWatch Insights를 활용 비용을 지불하고 CloudTrail Insights를 활성화하면 이벤트를 분석해서 계정 내의 특이한 활동을 탐지 특이한 활동에는 부정확한 리소스 프로비저닝 서비스 한도 도달 AWS IAM 작업 버스트 주기적 유지 관리 작업 부재가 있다. CloudTrail이 정상적인 관리 활동을 분석해서 기준선을 생성한 다음 무언가를 변경하거나 변경하려고 시도하는 모든 쓰기 유형의 이벤트를 지속적으로 분석해서 특이한 패턴을 탐지 이상 상황, 즉 인사이트 이벤트는 CloudTrail 콘솔에 표시된다. 원한다면 Amazon S3로 전송할 수도 있고 이메일을 보내는 CloudTrail Insights에 자동화를 추가하면 EventBridge 이벤트가 생성된다.

CloudTrail의 이벤트 보존 기간

이벤트는 CloudTrail에 기본적으로 90일 간 저장되고 이후에는 삭제된다. 기본 기간 이상으로 이벤트를 보존하려면 S3로 전송해서 S3에 로그를 기록하고 Athena를 사용해 분석하면 된다.

참고

CloudTrail 통합 중에 API 호출을 가로채는 Amazon EventBridge와의 통합은 꼭 알아야 한다. 사용자가 테이블 삭제 API 호출을 사용해서 DynamoDB의 테이블을 삭제할 때마다 SNS 알림을 받고 싶다고 가정하면, AWS에서 API 호출을 실행할 때마다 API 호출 자체가 CloudTrail에 로깅된다. 그리고 모든 API 호출은 Amazon EventBridge에 이벤트로 기록된다. 여기서 특정 테이블 삭제 API 호출을 찾아 규칙을 생성 규칙에는 대상이 필요 Amazon SNS를 대상으로 설정하면 경고를 생성할 수 있다. 어떤 API 호출에도 적용할 수 있어요

AWS Config

Config는 AWS 내 리소스에 대한 감사와 규정 준수 여부를 기록할 수 있게 해주는 서비스 설정된 규칙에 기반해 구성과 구성의 시간에 따른 변화를 기록할 수 있으며 이를 통해 필요할 경우 인프라를 빠르게 롤백하고 문제점을 찾아낼 수 있다. Config로 해결할 수 있는 질문은 다음과 같다 '보안 그룹에 제한되지 않은 SSH 접근이 있나?' '버킷에 공용 액세스가 있나?' '시간이 지나며 변화한 ALB 구성이 있나?' 이럴 경우 규칙이 규정을 준수하든 아니든 변화가 생길 때마다 SNS 알림을 받을 수 있다. Config는 리전별 서비스이기 때문에 모든 리전별로 구성해야 하며 데이터를 중앙화하기 위해 리전과 계정 간 데이터를 통합할 수 있다 모든 리소스의 구성을 S3에 저장해 나중에 분석할 수도 있다. 규정 미준수를 예방하지는 못하지만 리소스가 규정을 미준수할 때마다 수정 작업을 트리거 할 수 있다. EventBridge를 사용해 리소스가 규정을 미준수했을 때마다 알림을 보낼 수 있다. 예를 들어 보안 그룹을 모니터링하다가 규정 미준수 상태가 됐다면 EventBridge에서 이벤트를 트리거 해서 원하는 리소스에 넘길 수 있다.

Amazon Rekognition은 기계 학습을 이용해 객체, 사람, 텍스트와 이미지와 비디오의 장면을 찾는 서비스다. 얼굴을 분석하고 비교하여 사용자 확인을 하며 이미지 내의 인물 수를 셀 수 있다. 익숙한 얼굴을 저장해 자체 데이터베이스를 생성하거나 이미지 속 인물이 궁금할 때 유명인 얼굴의 데이터베이스와 비교할 수 있다. Amazon Rekognition의 사용 사례로는 촬영한 사진이나 비디오의 라벨링 콘텐츠 조정, 텍스트 탐지 얼굴 탐지 및 분석을 들 수 있다. 성별이나 연령 범위 얼굴에 나타나는 표정을 탐지할 수 있다. 얼굴 검색 및 확인이나 유명인 얼굴 인식에도 쓰이며 이동 경로를 따라가므로 스포츠 경기 분석에도 사용된다. 모든 연령에 적절한지 확인하는 콘텐츠 조정 기능도 있고 경주하는 이미지에서 텍스트를 탐지해 각 주자의 번호를 알 수도 있다. 얼굴 탐지 및 분석과 감정 분석도 가능하다. 보안 애플리케이션에는 얼굴 검색 및 확인 기능을 쓸 수 있다.

Transcribe

오디오를 넣으면 자동으로 텍스트로 변환한다. 자동 음성 인식(ASR)이라는 딥러닝 프로세스를 사용하여 음성을 텍스트로 매우 빠르고 정확하게 변환한다. Redaction을 사용하여 개인 식별 정보(PII)를 자동으로 제거할 수 있다. 예를 들어 누군가의 나이, 이름, 사회보장번호가 있다면 자동으로 제거된다. 다국어 오디오를 자동으로 언어 식별할 수 있다. Amazon Transcribe의 사용 사례는, AS 전화의 대본을 자동으로 폐쇄 자막이나 자막으로 만드는 것이다. 또한 완전히 검색 가능한 아카이브를 만들기 위해 미디어 자산에 대한 메타데이터를 만든다.

Polly

딥 러닝 기술을 사용해 텍스트를 음성으로 변환한다. 말하는 애플리케이션을 만들 수 있다. Amazon Polly는 어휘 목록과 SSML을 활용한다. 먼저 '발음 어휘 목록'을 사용해 사용자 지정 발음을 생성할 수 있다. 어휘 목록을 업로드해서 SynthesizeSpeech 작업에 사용하면 된다. 두 번째 기능은 SSML 기능 SSML은 '음성 합성 마크업 언어'라는 뜻으로 보다 다양한 사용자 지정 음성을 만들 수 있는 기능이다. Amazon Polly 서비스 페이지에서 텍스트를 자연스러운 음성으로 변환할 수 있다.

Amazon Translate

자연스럽고 정확한 언어 번역 기능을 제공한다. Translate를 통해 콘텐츠를 현지화할 수 있다. 즉 해외 사용자를 위한 웹사이트와 애플리케이션 등에 적용 가능하다. 또한 대량의 텍스트를 효율적으로 번역할 수 있다.

Lex & Connect

Lex를 사용하여 자동 음성 인식을 할 수 있다. 음성을 인식하는 ASR이라서 말을 텍스트로 바꿔준다. Lex가 자연어 이해를 통해 말의 의도를 파악하고 문장을 이해할 수 있다. Amazon Lex 기술은 챗봇 구축이나콜 센터 봇 구축에 도움을 준다. Amazon Connect라는 가상 고객 센터가 있다. 전화를 받고 고객 응대 흐름을 생성하는 클라우드 기반 서비스다. 다른 고객 관계 시스템 혹은 관리 시스템인 CRM 및 AWS 서비스와 통합할 수 있다. Amazon Connect는 기존 고객 센터 방식에 비해 초기 비용이 없고 비용이 약 80% 저렴하다. 정리하면 Lex는 ASR이고 Connect는 고객 센터

Comprehend

자연어를 처리하는 NLP(Natural Language Processing) 완전 관리형 서버리스 서비스. 머신 러닝을 사용하여 텍스트에서 인사이트와 관계를 도출한다. 분석 중인 텍스트가 긍정적인지 부정적인지 파악하는 감정 분석을 할 수 있다. 토큰화 및 품사를 사용하여 텍스트를 분석할 수 있고 음성을 식별한다. 텍스트 파일 모음을 주제에 따라 정리하고 주제를 식별한다. 대량의 데이터가 있으면 Comprehend가 그 데이터의 의미를 이해하려고 시도하는 것이다. 따라서 텍스트 혹은 구조화되지 않은 데이터를 이런 기능을 사용해 구조화하는 것 시험에서 NLP가 보이면 Amazon Comprehend를 떠올려야 한다.

Comprehend Medical Overview

비정형 의료 텍스트에서 유용한 정보를 탐지해서 반환해 주는 서비스 의사 소견서나 퇴원 요약서, 검사 결과서 의료 사례 기록을 발견하면 NLP, 즉 자연어 처리를 사용해 텍스트를 탐지한다. 문서와 문서 속의 보호된 개인 건강 정보(PHI)를 DetectPHI API로 탐지해낸다. 아키텍처 관점에서 보면 Amazon S3에 문서를 저장하고 Comprehend Medical API를 실행하는 거고 Kinesis Data Firehose로 실시간으로 데이터를 분석하거나 Amazon Transcribe를 사용해 음성을 텍스트로 변환한 후 텍스트 형식의 콘텐츠를 Amazon Comprehend Medical 서비스에 전달하는 것이다. Amazon Comprehend Medical로 텍스트에서 정보를 추출해 인사이트를 얻을 수 있다는 게 핵심이다.

SageMaker

SageMaker는 완전 관리형 서비스이며 머신 러닝 모델을 구축하는 개발자와 데이터 과학자를 위한 서비스다. SageMaker는 높은 수준의 머신 러닝 서비스로 조직의 실제 개발자와 데이터 과학자가 머신 러닝 모델을 만들고 구축하기 위해 사용한다. 라벨링과 구축, 훈련 및 조정, 적용 모두 SageMaker에서 가능하다.

Forecast

완전 관리형 서비스이며 머신 러닝을 사용하여 매우 정확한 예측을 제공한다. (데이터 자체를 확인하는 것보다 50% 더 정확) 관리형 서비스는 예측 시간을 몇 달에서 몇 시간으로 줄여준다. 예측이 필요한 것은 모두 사용 사례가 된다. 제품 수요 계획과 재무 계획 자원 계획 등

Forecast 예시

과거 시계열 데이터에 제품 특징, 가격, 할인 웹사이트 트래픽, 상점 위치 기본적으로 모델을 향상시킬 데이터를 추가한다. 그리고 Amazon S3에 이를 업로드한 뒤에 Amazon Forecast 서비스를 시작한다. 그러면 예측 모델이 생성되고 이 모델을 사용하여 미래의 비옷 판매량이 내년에 $500,000라고 예측하는 것이다.

Kendra

머신 러닝으로 제공되는 완전 관리형 문서 검색 서비스. 문서(text, pdf, HTML PowerPoint, MS Word, FAQ 등) 내에서 답변을 추출할 수 있게 도와준다. Amazon Kendra는 이런 문서를 인덱싱하여 머신 러닝으로 작동되는 지식 인덱스를 내부적으로 구축한다. 최종 사용자 관점에서는 자연어 검색 능력이 도움이 된다. 예를 들어 사용자가 Amazon Kendra에 'IT의 지원 데스크 위치가 어디야?'라고 물으면 Kendra는 '1층입니다'라고 대답할 수 있다. 이게 가능한 이유는 Kendra가 모든 리소스를 검색하여 IT 지원 데스크의 위치가 1층임을 알 수 있기 때문 물론 일반적인 검색도 가능하다. 사용자의 상호 작용 및 피드백에서 학습하고 선호되는 검색 결과를 내놓는 증분식 학습도 가능 검색 결과를 조정할 수도 있다. 데이터의 중요성 및 새로움 또는 사용자 정의 필터를 기반으로 조정 가능하다. 시험 문제에서 문서 검색 서비스를 보게 되면 Amazon Kendra를 생각하면 된다.

Personalize

실시간 맞춤화 추천으로 애플리케이션을 구축한다. 예를 들어 맞춤화된 제품 추천 그리고 재순위화(re-ranking) 또는 맞춤화된 직접 마케팅 Amazon Personalize API를 사용하여 Amazon Personalize 서비스에 실시간 데이터를 통합할 수 있다. 맞춤화를 위해 SMS나 이메일을 보낼 수도 있다. ML 솔루션을 구축, 훈련 및 배포할 필요가 없다. 제공되는 번들 그대로 사용하면 된다. 사용 사례는 소매 상점, 미디어 그리고 엔터테인먼트 등 시험을 대비해서는 추천 및 맞춤화된 추천을 위한 머신 러닝 서비스가 나올 때마다 Amazon Personalize를 생각하면 된다.

Textract

텍스트, 손글씨, 폼, 테이블, PDF, 이미지 또는 스캔을 한 문서의 텍스트 데이터를 추출한다. AI나 머신 러닝이 사용된다. 텍스트를 추출하는 사용 사례는 여럿 있지만 금융 서비스에서는 송장이나 재무 보고서를 처리하고 건강 보험의 경우 의료 기록과 보험 청구에 사용되고 공공 기관의 경우 세금 양식, 신분증 및 여권 등에 사용된다.

머신 러닝 요약

Rekognition으로 얼굴 탐지 및 라벨링, 유명인 인식을 수행할 수 있다. Transcribe를 사용하면 자막을 얻을 수 있다. 오디오를 텍스트로 전환하는 기능과 같다. 반대로 Polly를 사용하면 텍스트로 오디오를 얻을 수 있다. Translate로 번역을 할 수 있고 Lex는 챗봇과 같은 대화형 봇을 구축한다. 이를 Connect 서비스와 묶으면 클라우드 고객 센터를 만들 수 있다. Comprehend는 자연어 처리를 하는 방법이다 SagaMaker는 개발자와 데이터 과학자를 위한 완전한 기능의 머신 러닝 서비스이다. Forecast를 통해 정확한 예측을 할 수 있다. Kendra는 ML 기반의 문서 검색 엔진이다. Personalize는 고객을 위한 실시간 맞춤형 추천을 제공한다. Textract는 텍스트와 데이터를 탐지하고 다양한 문서에서 이를 추출하는데 사용된다.

Athena는 Amazon S3 버킷에 저장된 데이터 분석에 사용하는 서버리스 쿼리 서비스로 데이터를 분석하려면 표준 SQL 언어로 파일을 쿼리해야 한다. Athena는 SQL 언어를 사용하는 Presto 엔진에 빌드된다. 사용자가 S3 버킷에 데이터를 로드하거나 우리 S3 버킷에 데이터를 로드하면 Athena 서비스를 사용해 이동하지 않고 Amazon S3에서 데이터를 쿼리하고 분석할 수 있다. CSV, JSON, ORC, Avro Parquet 등 다양한 형식을 지원하고 가격 책정은 스캔된 데이터의 TB당 고정 가격을 지불하면 된다. 전체 서비스가 서버리스여서 데이터베이스를 프로비저닝 할 필요가 없다. Athena는 Amazon QuickSight라는 도구와 함께 사용하는 일이 많다. 이를 통해 보고서와 대시보드를 생성한다. QuickSight는 S3 버킷에 연결된 Athena 다음에 배치된다. Amazon Athena의 사용 사례로는 임시 쿼리 수행이나 비즈니스 인텔리전스 분석 및 보고가 있고 AWS 서비스에서 발생하는 모든 로그를 쿼리하고 분석할 수 있다. (VPC 흐름 로그, 로드 밸런서 로그 CloudTrail 추적 등) 시험에선 서버리스 SQL 엔진을 사용한 Amazon S3 데이터 분석이 나오면 Athena를 떠올리자.

성능 향상

1. 비용을 지불할 때 스캔된 데이터의 TB당 가격을 지불하므로 데이터를 적게 스캔할 유형의 데이터를 사용하는 것 열 기반 데이터 유형을 사용하면 필요한 열만 스캔하므로 비용을 절감할 수 있다. 따라서 Amazon Athena에 권장하는 형식은 Apache Parquet과 ORC다. 파일을 Apache Parquet나 ORC 형식으로 가져오려면 대표적으로 Glue를 사용해야 한다. 또한 더 적은 데이터를 스캔해야 하므로 데이터를 압축해 더 적게 검색해야 한다. (bzip2, gzip, lz4, snappy, zlip, zstd등)

2. 특정 열을 항상 쿼리한다면 데이터 세트를 분할하면 된다. (S3 버킷에 있는 전체 경로를 슬래시로 분할한다는 뜻) 각 슬래시에 다른 열 이름을 붙여 열별로 특정 값을 저장한다. 데이터를 쿼리할 때 Amazon S3의 어떤 폴더 즉, 어떤 경로로 데이터를 스캔할지 정확히 알 수 있다.

3. 큰 파일을 사용해서 오버헤드를 최소화하면 성능을 향상할 수 있다. S3에 작은 파일이 너무 많으면 Athena는 큰 파일이 있을 때보다 성능이 떨어진다. 파일이 클수록 스캔과 검색이 쉬우므로 128MB 이상의 파일을 사용해야 한다.

연합 쿼리

Athena는 S3뿐만 아니라 어떤 곳의 데이터도 쿼리할 수 있다. (SQL, NOSQL, 사용자 커스텀 등) AWS나 온프레미스에 데이터가 있다면 데이터 원본 커넥터를 사용하면 된다. 데이터 원본 커넥터는 Lambda 함수로 다른 서비스에서 연합 쿼리를 실행한다. CloutWacth Logs, DyanamoDB RDS 등에서 실행하며 매우 강력하다. 데이터 원본 커넥터당 하나의 Lambda 함수를 가지며 Amazon Athena을 통해 ElastiCache, DocumentDB DynamoDB, Redshift와 Aurora, SQL 서버, MySQL EMR 서비스의 HBase에서 쿼리를 실행할 수 있고 Athena에서 바로 Amazon S3뿐만 아니라 모든 온프레미스 데이터베이스를 쿼리할 수 있으며 쿼리를 조인할 수 있다. 쿼리 결과는 사후 분석을 위해 Amazon S3 버킷에 저장할 수 있다.

Redshift

Redshift는 PostgreSQL 기술 기반이지만 온라인 트랜잭션 처리(OLTP)에 사용되지 않는다. 온라인 분석 처리를 의미하는 OLAP 유형의 데이터베이스이며 분석과 데이터 웨어하우징에 사용한다. 다른 어떤 데이터 웨어하우징보다 성능이 10배 이상 좋고 데이터가 PB 규모로 확장되므로 모든 데이터를 Redshift에 로드하면 Redshift에서 빠르게 분석할 수 있다. Redshift는 성능 향상이 가능한데 이는 열 기반 데이터 스토리지를 사용하기 때문 (행 기반이 아니라 병렬 쿼리 엔진) Redshift 클러스터에서 프로비저닝한 인스턴스에 대한 비용만 지불하면 된다. 쿼리를 수행할 때 SQL 문을 사용할 수 있고, Amazon Quicksight 같은 BI 도구나 Tableau 같은 도구와 통합 가능

Athena vs Redshift

Redshift는 먼저 Amazon S3에서 모든 데이터를 Redshift에 로드해야 한다. Redshift에 데이터를 로드하고 나면 Redshift의 쿼리가 더 빠르고 조인과 통합을 훨씬 더 빠르게 할 수 있다. (Redshift에는 인덱스가 있기에) Redshift는 데이터 웨어하우스가 높은 성능을 발휘하도록 인덱스를 빌드한다. Amazon S3의 ad hoc(즉선)쿼리라면 Athena가 좋은 사용 사례가 되지만, 쿼리가 많고 복잡하며 조인하거나 집계하는 등 집중적인 데이터 웨어하우스라면 Redshift가 더 좋다.

Redshift Cluster

Redshift 클러스터에는 두 노드가 있다. 리더 노드(쿼리 계획과 결과 집합을 시킴)와 계산노드(Compute Node)가 존재한다. 리더 노드에 쿼리를 SQL 형식으로 제출하면 백엔드에서 쿼리가 발생한다. 리더 노드는 쿼리를 계획하고 결과를 집계하며 계산 노드는 실제로 쿼리를 실행하고 결과를 리더 노드에 보낸다. Redshift 클러스터는 노드 사이즈를 사전에 프로비저닝해야 하고 비용을 절감하려면 예약 인스턴스를 사용하면 된다.

Snapshots & DR

Redshift는 대부분의 클러스터에 대해 싱글 AZ이지만 특정 클러스터 유형에 대해 멀티 AZ모드가 있다. 그래서 멀티 AZ가 있다면 피해 복구가 잘 되겠지만, 싱글 AZ라면 재해 복구 전략을 적용하려면 스냅샷을 사용해야 한다. 스냅샷은 클러스터의 지정 시간 백업으로 Amazon S3 내부에 저장되며 증분한다. 변경된 사항만 저장 -> 많은 저장 공간 절약 새로운 Redshift 클러스터에 스냅샷을 복원할 수 있으며 스냅샷에는 두 가지 모드가 있다. (수동, 자동) 스냅샷이 8시간마다 또는 5GB마다 자동으로 생성되도록 일정을 예약할 수 있고 자동화된 스냅샷의 보존 기간을 설정할 수 있다. 수동 스냅샷을 사용할 경우 직접 스냅샷을 삭제하기 전까지 스냅샷이 유지된다.

Redshift는 자동이든 수동이든 클러스터의 스냅샷을 다른 AWS 리전에 자동으로 복사하도록 Redshift를 구성하여 재해 복구 전략을 적용할 수 있다는 점.

원본 Redshift 클러스터와 다른 리전이 있을 때 스냅샷을 생성하면 새로운 리전에 자동으로 복사되고 복사된 스냅샷에서 새 Redshift 클러스터를 복원할 수 있다.

데이터 수집 방법

Amazon Kinesis Data Firehose

Firehose가 다양한 소스로부터 데이터를 받아서 Redshift에 보내는 것 먼저 Amazon S3 버킷에 데이터를 써야겠죠 그러면 자동으로 Kinesis Data Firehose가 S3 복사 명령을 실행해 Redshift에 데이터가 로드됩니다

S3 using COPY command

수동으로도 가능하다. S3에 데이터를 로드하고 Redshift에서 복사 명령을 실행하면 IAM 역할을 사용해 S3 버킷에서 Amazon Redshift 클러스터로 데이터를 복사한다. 인터넷을 사용할 수 있다. S3 버킷은 인터넷과 연결돼 있기 때문 데이터가 인터넷을 통해 다시 Redshift 클러스터로 이동하게 되는데 향상된 VPC 라우팅 없이도 가능하다. 모든 네트워크를 가상 프라이빗 클라우드에 비공개 상태로 유지하고 싶다면 모든 데이터가 VPC로 완전히 이동되도록 향상된 VPC 라우팅을 사용하면 된다.

JDBC 드라이버

애플리케이션에 Redshift 클러스터에 써야 하는 EC2 인스턴스가 있을 때 이 방법을 사용 이때 Amazon Redshift에 큰 배치로 데이터를 쓰는 것이 좋다. 이 유형의 데이터베이스에 한 번에 한 행씩 쓰는 건 비효율적

Spectrum

Redshift Spectrum은 Amazon S3에 있는 데이터를 Redshift를 사용해 분석은 하고싶지만 Redshift에 로드하고 싶지 않을때 사용할 수 있다. 또는 더 많은 처리 능력을 사용하고 싶을 때 사용할 수 있다. Redshift Spectrum을 사용하려면 쿼리를 시작할 수 있는 Redshift 클러스터가 있어야 한다. 일단 쿼리를 시작하면 S3에 있는 데이터에 쿼리를 실행할 수천 개의 Redshift Spectrum 노드에 쿼리가 제출된다. Spectrum이 자동으로 시작되고 쿼리는 Amazon S3에서 데이터를 읽고 집계하는 수천 개의 Redshift Spectrum 노드에 제출된다. 제출이 완료되면 결과가 Amazon Redshift 클러스터를 통해 쿼리를 시작한 곳으로 전송된다. 이 기능을 사용하면 Amazon S3에서 Redshift로 데이터를 로드하지 않아도 되므로 클러스터에서 프로비저닝한 것보다 더 많은 처리 능력을 활용할 수 있습니다

OpenSearch Service

Amazon OpenSearch는 Amazon ElasticSearch의 후속 서비스. 서버리스 X 기본 키나 데이터베이스의 인덱스로만 데이터를 쿼리할 수 있는 DynamoDB와 비교해 보면 OpenSearch로는 부분적으로 일치하는 필드를 포함해 모든 필드를 검색할 수 있다. 그래서 OpenSearch는 애플리케이션에서 검색 기능을 제공할 때 많이 사용되고 일반적으로 다른 데이터베이스를 보완하는데 사용 OpenSearch는 검색에 사용되지만 OpenSearch를 사용하면 쿼리를 분석할 수도 있다. OpenSearch 클러스터를 프로비저닝하는데 두 가지 모드가 있다. 사용자가 직접 물리적인 인스턴스를 프로비저닝, 서버리스 경로를 선택해 서버리스 클러스터를 생성(AWS에서 스케일링~운영까지) 자체 쿼리 언어가 있지만 SQL을 지원하지 않고 Kinesis Data Firehose AWS IoT, CloudWatch Logs나 사용자 지정 애플리케이션의 데이터를 주입하여 SQL 호환성을 활성화할 수 있다. Cognito, IAM과 통합해 제공하는 보안을 통해 저장 데이터 암호화와 전송 중 암호화가 가능하다. OpenSearch Dashboards로 OpenSearch 데이터를 시각화할 수 있다. DynamoDB, CloudWatch Logs로 OpenSearch에 데이터를 주입할 수도 있다.

EMR

EMR은 Elastic MapReduce의 약어로 AWS에서 빅 데이터 작업을 위한 하둡 클러스터 생성에 사용된다. 방대의 양의 데이터를 분석하고 처리할 수 있다. 하둡 클러스터는 프로비저닝해야 하며 수백 개의 EC2 인스턴스로 구성될 수 있다. EMR은 빅 데이터 전문가가 사용하는 여러 도구와 함께 제공된다. Apache Spark, HBase, Presto Apache Flink는 설정이 어려운데 Amazon EMR이 상기 서비스에 관한 프로비저닝과 구성을 대신 처리해 준다. 전체 클러스터를 자동으로 확장할 수 있고 스팟 인스턴스와 통합되므로 가격 할인 혜택을 받을 수도 있다.

시험 측면에서 본 Amazon EMR의 사용 사례로는 데이터 처리와 기계 학습, 웹 인덱싱 빅 데이터 작업이 있는데 모든 작업은 하둡, Spark, HBase Presto, Flink와 같은 빅 데이터 관련 기술을 사용한다.

Node 유형

Amazon EMR은 EC2 인스턴스의 클러스터로 구성되며 여러 노드 유형이 있다. 마스터 노드는 클러스터를 관리하고 다른 모든 노드의 상태를 조정하며 장기 실행해야 한다. 코어 노드는 태스크를 실행하고 데이터를 저장합니다 장기 실행해야 한다. 마지막 유형은 테스트만 실행하는 태스크 노드다. 대게 스팟 인스턴스를 사용 온디맨드 EC2 인스턴스 유형을 사용하면 신뢰할 수 있고 예측 가능한 유형의 워크로드를 얻게 되고 절대 종료되지 않는다 최소 1년을 사용해야 하는 예약 인스턴스를 사용하는 경우에는 비용을 크게 절약할 수 있으며 가능한 경우에 EMR이 자동으로 예약 인스턴스를 사용한다. 예약 인스턴스는 장기 실행해야 하는 마스터 노드와 코어 노드에 적합하다. EMR에서 배포할 때는 장기 실행 클러스터에서 예약 인스턴스를 사용하거나 임시 클러스터를 사용해 특정 작업을 수행하고 분석 완료 후에 삭제할 수 있다.

QuickSight

Amazon QuickSight는 서버리스 머신 러닝 기반 비즈니스 인텔리전스 서비스 비즈니스 인텔리전스니까 대화형 대시보드를 생성해 소유한 데이터 소스와 연결할 수 있다. 시각화할 수 있고 빠르며 오토 스케일링이 가능하다. 웹사이트에 임베드할 수 있으며 세션당 비용을 지불한다. QuickSight의 사용 사례에는 비즈니스 분석 시각화 구현 시각화된 정보를 통한 임시 분석 수행 그리고 데이터를 활용한 비즈니스 인사이트 획득이 있다. RDS, Aurora, Athena Redshift, S3 등 다양한 데이터 소스에 연결할 수 있다. SPICE 엔진이라는 것이 있는데, 인 메모리 연산 엔진이며 Amazon QuickSight로 데이터를 직접 가져올 때 사용되며 Amazon QuickSight가 다른 DB에 연결돼 있을 때는 작동하지 않는다. Amazon QuickSight의 엔터프라이즈 에디션에서는 액세스 권한이 없는 사용자에게 일부 열이 표시되지 않도록 열 수준 보안(CLS)을 설정할 수 있다.

통합

RDS 데이터베이스, Aurora 데이터 웨어하우징 서비스인 Redshift S3에서 임시 쿼리를 수행하는 Athena 데이터를 가져오기 위한 Amazon S3 OpenSearch 및 시계열 데이터를 최적할 수 있는 Timestream과 통합할 수 있다. 타사 데이터 소스와 통합할 수도 있는데, QuickSight가 지원하는 서비스형 소프트웨어여야 한다. Salesforce와 Jira가 대표적 내부적으로 JDBC 프로토콜을 사용하는 온프레미스 데이터베이스와 통합할 수 있다. QuickSight로 직접 Excel 파일, CSV 파일 JSON 문서, TSV 파일 로그 형식의 ELF 및 CLF 등의 데이터 소스를 가져올 수 있다. Amazon QuickSight로 데이터 소스를 가져온 다음 SPICE 엔진을 활용해 매우 빠르게 인 메모리 연산을 수행할 수 있다. 시험에는 QuickSight를 Athena나 Redshift와 함께 사용하는 문제가 자주 나오지만 다른 통합도 출제될 수 있다.

대시보드와 분석

QuickSight에는 세 가지 개념이 있다. 대시보드 및 분석 그리고 사용자가 있다. 스탠다드 버전에서는 사용자를 정의할 수 있고 그룹은 엔터프라이즈 버전에서만 사용할 수 있다. QuickSight의 사용자와 그룹은 QuickSight 서비스 전용 IAM 사용자와는 다르다. IAM 사용자는 관리용으로만 사용된다. QuickSight 내에서 사용자와 그룹을 정의하고 대시보드를 생성하면 된다. 대시보드는 읽기 전용 스냅샷이며 분석 결과를 공유할 수 있다. 또한 분석의 구성을 저장한다. 분석을 위해 설정한 필터 또는 매개변수 제어, 정렬 옵션 등이 저장되어 대시보드에 표시된다. 따라서 분석이 좀 더 충실하며 특정 사용자 또는 그룹과 분석 결과나 대시보드를 공유할 수 있다. 액세스 권한이 있는 사용자는 기본 데이터를 볼 수도 있다. QuickSight에서는 분석 및 대시보드를 생성해야 하고요 특정 사용자나 그룹과 공유할 수 있다.

Glue

Glue는 추출과 변환 로드 서비스를 관리하며 ETL 서비스이자 완전 서버리스 서비스다. 분석을 위해 데이터를 준비하고 변환하는 데 매우 유용하다.

고급 기능

Glue 작업 북마크

새 ETL 작업을 실행할 때 이전 데이터의 재처리를 방지한다.

Glue Elastic Views

SQL을 사용해 여러 데이터 스토어의 데이터를 결합하고 복제한다. 가령 RDS 데이터베이스와 Aurora 데이터베이스 Amazon S3에 걸친 뷰를 생성하는 것 커스텀 코드를 지원하지 않으며 Glue가 원본 데이터의 변경 사항을 모니터링한다. 서버리스 서비스 또한 여러 데이터 스토어에 분산된 구체화된 뷰인 가상 테이블을 생성할 수 있다.

Glue DataBrew

사전 빌드된 변환을 사용해 데이터를 정리하고 정규화한다.

Glue Studio

Glue에서 ETL 작업을 생성, 실행 및 모니터링하는 GUI

Glue 스트리밍 ETL

Apache Spark Structured Streaming 위에 빌드되며 ETL 작업을 배치 작업이 아니라 스트리밍 작업으로 실행할 수 있다. Kinesis Data Streaming Kafka 또는 AWS의 관리형 Kafka인 MSK에서 Glue 스트리밍 ETL을 사용해 데이터를 읽을 수 있다.

Lake Formation

데이터 레이크란 데이터 분석을 위해 모든 데이터를 한곳으로 모아 주는 중앙 집중식 저장소다. Lake Formation은 데이터 레이크 생성을 수월하게 해 주는 완전 관리형 서비스 Lake Formation은 데이터 레이크에서의 데이터 검색, 정제, 변환 주입을 돕는다. 게다가 데이터 수집, 정제나 카탈로깅, 복제 같은 복잡한 수작업을 자동화하고 기계 학습(ML) 변환 기능으로 중복제거를 수행한다. 데이터 레이크에서는 정형 데이터와 비정형 데이터 소스를 결합할 수 있으며 블루프린트를 제공한다. 내장된 블루프린트는 데이터를 데이터 레이크로 이전(migrate)하는 것을 도와주며 Amazon S3, Amason RDS 온프레미스에서 실행되는 관계형 데이터베이스 NoSQL 데이터베이스 등에서 지원된다. Lake Formation을 설정하는 이유는 모든 데이터를 한곳에서 처리하는 것 외에도 애플리케이션에서 행, 열 수준의 세분화된 액세스 제어를 할 수 있기 때문 AWS Lake Formation에 연결된 애플리케이션에서는 세분화된 액세스 제어가 가능 Lake Formation은 AWS Glue 위에 빌드되는 계층이긴 하지만 Glue와 직접 상호 작용하지 않는다. Lake Formation은 Amazon S3에 저장되는 데이터 레이크의 생성을 돕는다. 데이터 소스로는 Amazon S3 RDS, Aurora SQL, NoSQL 같은 온프레미스 데이터베이스가 있고 Lake Formation의 블루프린트를 통해 데이터를 주입한다. Lake Formation에는 소스 크롤러와 ETL 및 데이터 준비 도구 데이터 카탈로깅 도구가 포함됩니다 Glue의 기본 서비스에 해당되고요 데이터 레이크의 데이터를 보호하는 보안 설정과 액세스 제어도 포함된다. Lake Formation을 활용하는 서비스로는 Athena, Redshift, EMR Apache Spark 프레임워크 같은 분석 도구가 있다. 사용자는 이와 같은 서비스를 통해 Lake Formation 및 데이터 레이크에 연결합니다

중앙화된 권한

회사가 데이터 분석에 Athena와 QuickSight를 사용할 때 사용자는 허용된 데이터만 볼 수 있어야 하고 읽기 권한이 있어야 한다. Athena에 보안을 설정하거나 QuickSight에서 사용자 수준의 보안을 설정할 수 있다. S3 버킷 정책이나 사용자 정책에 보안 설정을 할 수도 있다. RDS, Aurora도 마찬가지. 이렇게 보안을 관리할 곳이 많아지면 엉망이 될 텐데, 이럴때는 Lake Formation이 답이다. 액세스 제어 기능과 열 및 행 수준 보안이 있기 때문이다. Lake Formation에 주입된 모든 데이터는 중앙 S3 버킷에 저장되지만 모든 액세스 제어와 행, 열 수준 보안은 Lake Formation 내에서 관리된다. 따라서 Lake Formation에 연결하는 서비스는 읽기 권한이 있는 데이터만 볼 수 있게 된다. Athena, QuickSight 등 어떤 도구를 사용하든 Lake Formation에 연결하면 한곳에서 보안을 관리할 수 있다.

Kinesis Data Analytics

SQL 애플리케이션용 Kinesis Data Analytics

중앙에 위치하여 Kinesis Data Streams와 Kinesis Data Firehose 데이터 소스에서 데이터를 읽는다. 둘 중 한군데서 데이터를 읽어 온 다음 SQL 문에 적용하여 실시간 분석을 처리할 수 있다. Amazon S3 버킷의 데이터를 참조해 참조 데이터를 조인할 수도 있다. 그리고 여러 대상에 데이터를 전송한다. Kinesis Data Streams는 Kinesis Data Analytics의 실시간 쿼리로 스트림을 생성한다. Kinesis Data Firehose로 바로 보내면 Amazon S3 Amazon Redshift이나 Amazon OpenSearch 또는 기타 Firehose 대상에 전송된다. Kinesis Data Streams에 보내면 EC2에서 실행하는 애플리케이션이나 AWS Lambda로 스트리밍하는 데이터를 실시간으로 처리할 수 있다. Amazon S3로 데이터를 강화할 수 있고 완전 관리형 서비스이므로 서버를 프로비저닝하지 않는다. 오토 스케일링이 가능하며 Kinesis Data Analytics에 전송된 데이터만큼 비용을 지불한다. Kinesis Data Streams나 Kinesis Data Firehose에 데이터를 출력할 수 있고 사용 사례로는 시계열 분석과 실시간 대시보드와 실시간 지표가 있다.

Apache Flink용 Kinesis Data Analytics

Apache Flink를 사용하면 Java, Scala, SQL로 애플리케이션을 작성하고 스트리밍 데이터를 처리, 분석할 수 있다. Flink는 코드로 작성해야 하는 특별한 애플리케이션이다. Flink 애플리케이션을 Kinesis Data Analytics의 Flink 전용 클러스터에서 실행할 수 있다. (백그라운드) Apache Flink을 사용해 두 개의 메인 데이터 소스인 Kinesis Data Streams나 Amazon MSK의 데이터를 읽을 수 있다. AWS의 관리형 클러스터에서 Apache Flink 애플리케이션을 실행할 수 있다. Apaches Flink는 표준 SQL보다 훨씬 강력하기 때문에 고급 쿼리 능력이나 필요하거나 Kinesis Data Streams나 AWS의 관리형 Kafka인 Amazon MSK 같은 서비스로부터 스트리밍 데이터를 읽는 능력이 필요할 때 Apache Flink용 Kinesis Data Analytics를 사용한다. 이 서비스를 사용하면 컴퓨팅 리소스를 자동 프로비저닝할 수 있고 병렬 연산과 오토 스케일링을 할 수 있다. 체크포인트와 스냅샷으로 구현되는 애플리케이션 백업이 가능하고 Apache Flink 프로그래밍 기능을 사용할 수도 있다. 참고로 Apache Flink는 Kinesis Data Streams나 Amazon MSK의 데이터는 읽지만 Kinesis Data Firehose의 데이터는 읽지 못합니다 Kinesis Data Firehose에서 데이터를 읽고 실시간 분석하려면 SQL 애플리케이션용 Kinesis Data Analytics를 사용해야 한다.

MSK

MSK는 AWS의 완전 관리형 Kafka 클러스터 서비스로 그때그때 클러스터를 생성, 업데이트, 삭제합니다 Kafka는 Amazon Kinesis의 대안으로 두 서비스 모두 데이터를 스트리밍한다. MSK는 클러스터 내 브로커 노드와 Zookeeper 브로커 노드를 생성 및 관리하고 고가용성을 위해 VPC의 클러스터를 최대 세 개의 다중 AZ 전역에 배포한다. 일반 Kafka 장애를 자동 복구하는 기능이 있으며 EBS 볼륨에 데이터를 저장할 수도 있다. Amazon MSK 서버리스를 사용할 수도 있다. MSK에서 Apache Kafka를 실행하지만 서버 프로비저닝이나 용량 관리가 필요 없다. MSK가 리소스를 자동으로 프로비저닝하고 컴퓨팅과 스토리지를 스케일링한다.

MSK vs Kafka

Kafka는 Kinesis와 유사하지만 몇 가지 차이점이 있다. Kinesis Data Streams에는 1MB의 메시지 크기 제한이 있다. Amazon MSK에서는 1MB이 기본값이고 더 큰 메시지 보존을 위해 10MB로 설정할 수도 있다. Kinesis Data Streams에선 샤드로 데이터를 스트리밍한다. Amazon MSK에선 파티션을 이용한 Kafka 토픽을 사용한다. Kinesis Data Streams에서 용량을 확장하려면 샤드 분할을 축소하려면 샤드 병합을 한다. Amazon MSK에서는 파티션 추가로 주제 확장만 할 수 있다. 파티션 제거는 불가능 Kinesis Data Streams에는 TLS 전송 중 암호화 기능이 있고 Amazon MSK에는 평문과 TLS 전송 중 암호화 기능이 있다 두 클러스터 모두 저장 데이터 암호화가 가능하다. Amazon MSK에서는 원한다면 1년 이상 데이터를 보관할 수도 있다. (EBS 스토리지 비용을 지불할 경우)

MSK vs Kafka

Kafka는 Kinesis와 유사하지만 몇 가지 차이점이 있다. Kinesis Data Streams에는 1MB의 메시지 크기 제한이 있다. Amazon MSK에서는 1MB이 기본값이고 더 큰 메시지 보존을 위해 10MB로 설정할 수도 있다. Kinesis Data Streams에선 샤드로 데이터를 스트리밍한다. Amazon MSK에선 파티션을 이용한 Kafka 토픽을 사용한다. Kinesis Data Streams에서 용량을 확장하려면 샤드 분할을 축소하려면 샤드 병합을 한다. Amazon MSK에서는 파티션 추가로 주제 확장만 할 수 있다. 파티션 제거는 불가능 Kinesis Data Streams에는 TLS 전송 중 암호화 기능이 있고 Amazon MSK에는 평문과 TLS 전송 중 암호화 기능이 있다 두 클러스터 모두 저장 데이터 암호화가 가능하다. Amazon MSK에서는 원한다면 1년 이상 데이터를 보관할 수도 있다. (EBS 스토리지 비용을 지불할 경우)

관리형 PostgreSQL, MySQL Oracle, SQL 서버 MariaDB용 및 사용자 지정 RDS가 있다. Amazon RDS를 사용할 때는 RDS 인스턴스 크기와 EBS 볼륨 유형 및 크기를 프로비저닝해야 한다. 스토리지 계층에 오토 스케일링 기능이 있어도 프로비저닝해야 한다. 읽기 용량 확장을 위해 읽기 전용 복제본을 지원한다. 고가용성 목적으로 대기 데이터베이스를 다중 AZ에 둘 수 있다. 대기 데이터베이스는 재해 발생 대비용이며 쿼리를 수행할 수는 없다. RDS 데이터베이스 보안은 IAM을 통해 설정할 수 있다. 사용자 이름과 비밀번호로 DB에 연결할 수 있게 하거나 일부 사용자에게 IAM 인증을 부여할 수 있다. 네트워크 보안을 위해 Amazon RDS DB에 보안 그룹을 설정할 수 있다. 저장 데이터 암호화에는 KMS를 전송 데이터 암호화에는 SSL과 TLS를 사용할 수 있다. 자동 백업 옵션도 있습니다 최대 35일까지 지원된다. 최근 35일 내에는 지정 시간 복구 기능을 지원하고 복구 시 새 데이터베이스가 생성된다. 장기 보존 백업이 필요한 경우에는 수동 DB 스냅샷을 사용하면 된다. 유지 관리 기능을 예약할 수 있기 때문에 데이터베이스 다운타임이 발생할 수 있다. 프로비저닝하거나 AWS가 데이터베이스 엔진을 주기적으로 업데이트하고 기본 EC2 인스턴스에 보안 패치를 실행할 때 발생할 수 있다. RDS 프록시를 강제하여 RDS에 IAM 인증을 추가하는 기능이 있다. Secrets Manager와 통합하여 DB 자격 증명을 관리할 수도 있다. 기본 인스턴스에 액세스하고 사용자 지정하려면 RDS 사용자 지정 옵션을 사용할 수 있다. Oracle, SQL 서버 유형의 데이터베이스에서 지원된다.

Aurora

Aurora는 데이터베이스 엔진인 PostgreSQL, MySQL과 호환되는 API다. 컴퓨팅과 스토리지가 분리된 특별한 서비스다. 스토리지의 경우 기본적으로 데이터를 세 가용 영역에 걸쳐 여섯 개의 복제본에 저장한다. 이 설정은 바꿀 수 없다. (고가용성) 스토리지에 문제가 발생하면 백그라운드에서 자가 복구 처리가 이뤄진다. 오토 스케일링이 기능이 내장돼 있어 스토리지 확장도 문제없다. 컴퓨팅의 경우 클러스터화된 실제 데이터베이스 인스턴스를 여러 가용 영역에 걸쳐 저장할 수도 있다. 읽기 전용 복제본이 있다면 로드가 증가할 때 오토 스케일링을 통해 용량을 늘릴 수 있다. 데이터베이스 인스턴스 클러스터가 있으므로 읽기와 쓰기를 위한 사용자 지정 엔드 포인트, 즉 라이터(writer) 엔드 포인트와 리더(reader) 엔드 포인트가 필요하다. Aurora는 RDS와 동일한 보안 모니터링, 유지 관리 기능을 갖는다. Aurora Serverless는 워크로드가 간헐적이거나 예측할 수 없는 경우 용량 계획을 하지 않아도 되므로 매우 유용하다. 쓰기 고가용성을 위해 쓰기 장애 조치가 지속해서 필요할 때 Aurora Multi-Master를 사용하면 DB 인스턴스 여러 개가 스토리지에 쓰기를 할 수 있도록 설정할 수 있다. 글로벌 데이터베이스를 원할 땐 Aurora Global을 사용하면 된다. 데이터베이스가 복제된 리전마다 최대 16개의 데이터베이스 읽기 전용 인스턴스를 제공하고 리전 간 스토리지 복제에 걸리는 시간은 일반적으로 1초 미만다. 기본 리전에 문제가 발생하면 보조 리전을 새 기본 리전으로 승격할 수 있다. Aurora Machine Learning 모듈을 사용하면 SageMaker와 Comprehend를 사용해 Aurora에서 머신 러닝을 수행할 수 있다. 프로덕션 데이터베이스로부터 테스트 데이터베이스나 스테이징 데이터베이스를 만들려면 Aurora Database Cloning 기능을 사용해기존 클러스터에서 새 Aurora 클러스터를 만들면 된다. 스냅샷을 사용해서 복구하는 것보다 훨씬 빠르다. Aurora의 사용 사례는 RDS와 같지만 Aurora는 유지 관리할 게 적고 유연성은 높으며 성능도 더 좋을 뿐만 아니라 내장된 기능도 더 많다.

ElasticCache

Amazon ElastiCache는 관리형 Redis/Memcached로 RDS와 비슷한 기능을 제공하지만 주로 캐싱 작업에 활용된다. ElastiCache는 인 메모리 데이터 스토어로 데이터를 읽을 때 1밀리초 미만의 지연 시간을 제공한다. 캐시를 위한 EC2 인스턴스 유형을 프로비저닝해야 계속 진행할 수 있다. Redis용에서는 클러스터 생성, 다중 AZ와 샤딩을 위한 읽기 전용 복제본을 사용할 수 있다. IAM을 통해 프로비저닝한 보안과 보안 그룹을 사용할 수 있고 저장 데이터 암호화를 위한 KMS와 Redis 인증을 사용할 수 있다. RDS처럼 백업 및 스냅샷 지정 시간 복구 같은 기능을 사용할 수 있다. 관리형 및 예약된 유지 관리가 가능하다. Amazon ElastiCache를 사용해 RDS가 결합된 데이터베이스에서 캐싱 작업을 수행하려면 애플리케이션 코드가 ElastiCache를 활용하도록 코드를 수정해 줘야 한다. (중요) 시험에서 코드 변경이 필요 없는 캐싱 솔루션을 물어본다면 ElastiCache는 선택하면 안 된다. ElastiCache의 사용 사례에는 키-값 스토어가 있고 데이터베이스를 자주 읽는다면 데이터베이스 쿼리를 캐싱하는 게 좋다. 웹사이트 사용자를 위해 세션 데이터를 저장할 수도 있다. 참고로 ElastiCache에선 SQL을 사용할 수 없다.

DynamoDB

DynamoDB는 AWS의 독점 기술로 관리형 서버리스 NoSQL 데이터베이스이나 밀리초 수준의 지연 시간을 제공한다. 선택형 오토 스케일링이 탑재된 프로비저닝된 용량 모드로 점진적으로 늘어나거나 점진적으로 줄어드는 이중(double) 워크로드가 있을 때 유용하다. 온디맨드 용량 모드에서는 용량을 프로비저닝하지 않아도 된다. 하지만 오토 스케일링이 실행되므로 워크로드를 예측하기 어려울 때나 데이터베이스의 수요가 급증할 때 유용한 모드다. ElastiCache 대신 DynamoDB에 키-값을 저장할 수 있는데, 웹사이트의 세션 데이터를 저장하는 좋은 방법이다. TTL 기능과 결합하면 일정 시간 후에 행이 만료되게 설정할 수 있다. DynamoDB는 가용성이 아주 높다. 기본적으로 다중 가용 영역에 걸쳐 있기 때문이다. 읽기와 쓰기가 완전히 분리되어 있고 DynamoDB 테이블에서 트랜잭션을 처리할 수 있다. DynamoDB와 호환되는 읽기 캐시 즉, DAX 클러스터를 생성할 수 있다. DAX는 DynamoDB Accelerator를 의미하고, DAX 클러스터의 특징은 읽기 지연 시간이 백만분의 1초라는 점이다.(중요) 보안, 인증, 권한 부여는 IAM을 통해 처리된다. DynamoDB에는 이벤트 처리 용량이 있어 DynamoDB Streams로 데이터베이스의 모든 변경 사항을 스트리밍할 수 있다. DyanmoDB Streams를 AWS Lambda와 통합할 수도 있다. 그러면 DynamoDB 테이블에서 변경이 발생할 때마다 Lambda가 실행된다. DynamoDB Streams 대신 Kinesis Data Streams로 데이터를 전송할 수도 있다. Kinesis Data Firehose와 같은 다른 통합의 기능을 사용할 수 있다는 이점이 있다. 가령 Kinesis Data Streams에서 보유 기간을 1년까지 설정할 수 있다. DynamoDB에는 글로벌 테이블 기능도 있다. 여러 리전 간에 다중 활성 복제를 할 수 있다. 어느 리전에서든 읽고 쓸 수 있으므로 다중 활성(active-active)이라고 부르는 것 백업 옵션은 두 가지다. 먼저 자동 백업이다. 지정 시간 복구를 활성화하면 새 DynamoDB 테이블에 테이블을 복구할 수 있다. 35일까지 가능 백업 보유 기간을 더 길게 설정하려면 온디맨드 백업을 활성화해서 새 테이블을 복구하면 된다. 지정 시간 복구 기간 내에 읽기 용량 단위를 사용하지 않고 DynamoDB 테이블을 Amazon S3로 내보낼 수 있다. (35일 이내에 S3로 내보내는 기능을 사용하면서) 쓰기 용량 단위를 사용하지 않고 S3에서 새 테이블로 불러올 수도 있다. 시험에서 스키마를 빠르게 전개해야 하는 경우가 나온다면 DynamoDB를 떠올리자. DynamoDB의 사용 사례로는 400KB 미만의 문서를 다루는 작은 서버리스 애플리케이션 개발 서버리스 캐시 분산이 있다. 참고로 DynamoDB는 SQL 쿼리 언어를 사용할 수 없다.

S3

S3는 객체를 키-값으로 저장하므로 큰 객체를 저장할 때는 유용하지만 여러 개의 작은 객체를 저장할 때는 유용하지 않다. Amazon S3는 서버리스이므로 확장성이 무한하다. 객체의 최대 크기는 5TB이며 시간 경과에 따라 계속 버저닝한다. 스토리지 계층으로는 S3 Standard, Infrequent Access Intelligent와 Glacier가 있으며 계층을 전환하려면 수명 주기 정책을 사용해야 한다. 꼭 알아야 할 중요한 기능으로는 버저닝, 암호화, 복제 멀티 팩터 인증(MFA) 삭제와 액세스 로그가 있다. 보안 기능에는 IAM 보안이 있다. S3 버킷에 버킷 정책을 생성할 수도 있고 ACL 기능도 있다. Amazon S3에 액세스 포인트를 생성할 수도 있다. S3 Object Lambda를 사용해 객체를 애플리케이션에 전송하기 전에 수정할 수도 있다. CORS 정책도 있다. Glacier의 객체 잠금 또는 볼트 잠금 개념을 활용할 수도 있다. (중요) SSE-S3, 자체 KMS 키를 가져올 수 있는 SSE-KMS, SSE-C, 클라이언트 측 암호화 전송 중 TLS 암호화가 있다. S3 버킷에 기본 암호화 체계를 설정할 수도 있다. Amazon S3 버킷에 있는 모든 파일을 한 번에 작업하려면 S3 Batch를 사용해 배치 작업을 하면 유용하다. 파일 목록은 S3 인벤토리를 사용해 생성할 수 있다. Amazon S3의 향상된 성능에는 파일을 병렬식으로 업로드할 수 있는 멀티파트 업로드가 있다. S3 전송 가속화를 통해 S3 파일을 한 리전에서 다른 리전으로 더 빠르게 전송할 수 있다. S3 Select로 Amazon S3에서 필요한 데이터만 검색할 수도 있다. 자동화 관련해서는 S3 Event Notifications가 있다. SNS, SQS, Lambda EventBridge 등을 사용해서 Amazon S3 버킷에서 새로운 객체가 생성되는 이벤트에 반응할 수 있다. Amazon S3의 사용 사례에는 정적 파일 큰 파일의 키-값 스토어 또는 웹사이트 호스팅이 있다.

Document DB

DocumentDB는 몽고DB용 Aurora. 몽고 DB 기술을 기반으로 한다. 즉, DocumentDB는 NoSQL 데이터베이스다. 몽고DB와 호환된다. 몽고DB는 JSON 데이터를 저장, 쿼리, 인덱스하는 데 사용됩니다, DocumentDB에도 Aurora와 같은 배포 개념이 있다. 즉, 완전 관리형 데이터베이스다. 고가용성 데이터는 3개의 가용 영역에 복제된다. 스토리지는 자동으로 10GB 단위로 최대 64TB까지 증가한다. 이렇게 DocumentDB는 초당 수백만 건의 요청이 있는 워크로드로 확장될 수 있도록 설계되었다.

Neptune

Neptune은 완전 관리형 그래프 데이터베이스다. 그래프 데이터 셋의 예는 소셜 네트워크다. 그래프 데이터 셋에서는 Neptune을 데이터베이스로 선택하는 게 좋다. Neptune은 3 AZ에 걸쳐 최대 15개의 읽기 전용 복제본으로 복제한다. Neptune은 소셜 네트워크처럼 고도로 연결된 데이터 셋을 사용하는 애플리케이션을 구축하고 실행하는 데 사용된다. Neptune은 그래프 데이터 셋에서 복잡하고 어려운 쿼리를 실행하기에 최적화되어 있다. 데이터베이스에 최대 수십억 개의 관계를 저장할 수 있고, 그래프를 쿼리할 때 지연시간은 밀리초다. 여러 가용 영역에 걸친 애플리케이션에서도 매우 가용성이 높으며 지식 그래프를 저장하는 데도 뛰어나다. 예를 들어 모든 위키피디아 기사들은 서로 연결되어 있으니까 위키피디아 데이터베이스는 지식 그래프, 사기 탐지, 추천 엔진, 소셜 네트워킹도 마찬가지

Keyspaces

Keyspaces는 AWS의 관리형 Apache Cassandra(오픈 소스 NoSQL 분산 데이터베이스)를 보조한다. Keyspaces를 사용하면 클라우드에서 AWS가 Cassandra를 직접 관리해 준다. 서버리스 서비스이며 확장성과 가용성이 높으며 AWS 완전 관리형이다. 애플리케이션 트래픽에 따라 테이블을 자동으로 확장/축소하며, 테이블 데이터는 여러 AZ에 걸쳐 세 번 복제됩니다 Keyspaces에서 쿼리를 수행하려면 Cassandra 쿼리 언어(CQL)을 사용하면 된다. 어떤 규모에서도 지연 시간이 10밀리초 미만으로 짧고 초당 수천 건의 요청을 처리한다. DynamoDB처럼 두 가지 용량 모드가 있다. 온디맨드 모드와 크기가 자동 조정되는 프로비저닝 모드다. DaynamoDB의 모드와 동일하다. 암호화와 백업 기능을 제공하고 최대 35일까지 지정 시간 복구가 가능하다. 사용 사례로는 IoT 장치 정보와 시계열 데이터 저장 등이 있다.

QLDB

퀀텀 레저 데이터베이스의 약자 원장(Ledger)은 금융 트랜잭션을 기록하는 장부다. 따라서 QLDB는 금융 트랜잭션 원장을 갖게 된다. 완전 관리형 데이터베이스이며, 서버리스고, 고가용성이다. 3개의 가용 영역에 걸쳐 데이터를 복제할 수 있다. 또한 애플리케이션 데이터의 시간에 따른 모든 변경 내역을 검토하는 데 사용된다. 불변 시스템이다. 즉, 데이터베이스에 무언가를 쓰면, 삭제하거나 수정할 수 없다. 정말로 아무 것도 삭제되지 않았는지 확인하기 위해, 암호화 서명을 하기도 한다. 내부적으로 저널이 있다. 저널에는 수정 시퀀스가 있다. 따라서 수정이 일어날 때마다, 암호화 해시가 계산된다. 아무 것도 삭제되거나 수정되지 않도록 보장하는 것이다. 데이터베이스를 사용하는 모든 사람이 확인할 수 있다. 금융 트랜잭션에 매우 유용하다. 왜냐하면 어떤 금융 트랜잭션도 데이터베이스에서 사라지게 하고 싶지 않기 때문이다. 이런 이유로 QLDB가 클라우드에서 훌륭한 원장 데이터베이스이다. 일반 원장 블록체인 프레임워크보다 2-3배 더 나은 성능을 얻을 수 있다. 또한 SQL을 사용하여 데이터를 관리할 수도 있다. Amazon 관리형 블록체인이라는 다른 데이터베이스 기술도 있다. QLDB와 관리형 블록체인의 차이점은, QLDB에는 탈중앙화 개념이 없다. 즉, Amazon 소유의 중앙 데이터베이스에서만 저널을 작성할 수 있다. 많은 금융 규제 규칙들을 따르는 것 즉, QLDB와 관리형 블록체인의 차이점은, QLDB에는 중앙 권한 구성 요소가 있다는 것 하지만 관리형 블록체인에는 탈중앙화 구성 요소도 있다.

Timestream

시계열 데이터베이스다. 완전 관리형이며 빠르고 확장성 있는 서버리스 서비스다. 시계열은 시간 정보를 포함하는 포인트의 모음을 말한다. Timestream를 사용하면 데이터베이스의 용량을 자동으로 확장, 축소할 수 있고 매일 수조 건의 이벤트를 저장 및 분석할 수 있다. 시계열 데이터가 있을 때는 관계형 데이터베이스보다 시계열 데이터베이스를 사용하는 것이 훨씬 빠르고 저렴하다. 쿼리를 예약하고 다중 척도 레코드도 얻을 수 있다. SQL과도 완벽히 호환 최신 데이터는 메모리에 저장되고 과거 데이터는 비용 효율적인 스토리지 계층에 저장된다. 또한 시계열 분석 기능이 있어 거의 실시간으로 데이터를 분석하고 패턴을 찾을 수 있다. AWS의 다른 데이터베이스들처럼 전송 중 데이터와 저장 데이터의 암호화를 지원한다. Timestream의 사용 사례로는 IoT 애플리케이션이 있다. 운영 애플리케이션, 실시간 분석 등 시계열 데이터베이스와 관련된 모든 곳에서 사용할 수 있다. Timestream은 AWS IoT 즉, 사물 인터넷에서 데이터를 받을 수 있고 Kinesis Data Streams의 데이터도 Lambda를 통해 받을 수 있다. Prometheus, telegraf와 통합할 수 있다. Apache Flink용 Kinesis Data Analytics는 Kineis Data Stream과 Amazon MSK의 데이터를 Amazon Timestream에 전달한다. Timestream과 연결 가능한 것으로는 대시보드를 빌드할 수 있는 Amazon Quicksight 기계 학습을 할 수 있는 Amazon SageMaker Grafana가 있다. 데이터베이스에 표준 JDBC가 연결돼 있으므로 JDBC, SQL과 호환 가능한 애플리케이션은 Amazon Timestream을 활용할 수 있다.

문제

아래와 같은 문제들로 인해 앱 메인 코드 로직의 복잡도는 높으며 객체 지향 원칙을 위배하고 있어 저 포함 동료 개발자들은 로직을 수정할 때 불안한 마음을 갖고 있었습니다.

1. 코드 복잡도

700라인에 육박하는 절차지향적 코드가 존재합니다.

대략적인 코드 품질을 확인할 수 있는 CodeMetrics 플러그인 기준으로 저희 앱 메인 페이지의 코드 복잡도는 65 Bloody hell..입니다. 😭

다양한 비즈니스 로직이 하나의 객체에 집중되어 있어 코드가 복잡하고 가독성이 떨어졌습니다.

2. 유지보수 어려움

신규 섹션 추가나 변경 시 기존 코드의 많은 부분을 수정하거나 코드 탐색에 오랜 시간이 걸렸습니다.

또한, 사이드 이펙트는 없는지 불안함이 동반되었습니다.

public class AppMainService {

  for(MainPageItem item : mainPageIteams()) {
      swich(type) {
          case ASection:
              if() {
                  ...
              } else {
                  ...
              }
              break;

           case BSection:
              if() {
                  ...
              } else if() {
                  ... 
              } else if() {
                  ...
              } else {
                  ...
              }
              break;

           ...

      }
   }
}

위 코드를 확인해보시면 AppMainService 객체는 너무 많은 책임을 갖고 있어 특정 섹션 수정, 추가 요구사항이 발생하면 어떠한 파급 효과가 발생할지 예상되지 않을 뿐더라 유지보수, 확장성은 떨어지고 코드의 복잡도는 높아지기 마련입니다.

3. 확장성 제한

새로운 섹션을 추가할 때마다 기존 로직을 수정해야 하므로 확장성이 제한되었습니다.

4. 테스트 어려움

비즈니스 로직이 한 곳에 집중되어 있어 단위 테스트 작성에 어려움을 겪었습니다.

어떻게 구조를 개선할까?

우선 하나의 엔드포인트에서 데이터를 조합하여 클라이언트에게 응답을 제공하는 설계는 변경하지 않았습니다.(성능 개선이 아닌 구조 개선이었기에)

구조를 개선하기 위해서 전략 패턴을 적극적으로 이용하였습니다.

1. 디자인 패턴 적용

특정 타입에 맞는 전략을 선택 후 실행하는전략 패턴을 적용하였습니다.

1-1 디자인 패턴 적용

코드 구조를 개선하면서 유지보수성과 코드 가독성이 높아진 것을 확인할 수 있습니다. 또한, 새로운 요구사항이 발생하여도 SRP 원칙과 OCP 원칙을 준수할 수 있게 되었습니다.

새로운 SectionStrategy 구현체를 추가할 때 기존 코드를 수정할 필요 없이, 단순히 새로운 구현체를 추가하고 DI 컨테이너에 등록하기만 하면 됩니다. 즉, 시스템의 확장성을 크게 향상시킬 수 있게 되었습니다.

public class AppMainService {
    private final List<SectionStrategy<SectionType>> sectionStrategies;

    public SectionResponse retrieveSection() {
        List<SectionData<?>> sectionResponseList = new ArrayList<>();

        SectionComponent sections = sectionCacheService.getSectionComponents();

        for(SectionComponent component : sections) {
            // 요청 객체 생성
            SectionRequest request = SectionReqeust.of();

            // type에 해당하는 strategy 조회
            SectionStrategy<SectionType> sectionStrategy = findStrategy(SectionType.valueOfType(request.getType()))
            if(sectionStrategy == UNDEFINED) {
                return;
            }

            // 섹션 조회 및 조합
            sectionStrategy.execute(request, sectionResponseList)
        }
    }

    private SectionStrategy<SectionType> findMyHomeStrategy(MyHomeSectionType type) {
        return sectionStrategies.stream()
              .filter(myHomeStrategy -> myHomeStrategy.isMatchingRole(type))
              .findFirst()
              .orElse(UNDEFINED);      
    }
}

1-2 개별 전략 알고리즘 객체 생성

개별 전략 알고리즘에서는 공용 인터페이스에 정의된 메소드를 구현하고 있습니다.

1. isMatchingRole(): 자신의 전략에 해당하는지 확인합니다.
2. execute(): 비즈니스 로직을 수행합니다.

public class ASectionStrategy implements SectionStrategy<SectionType> {

    private final AService aService;

    @Override
    public boolean isMatchingRole(SectionType type) {
        return ASectionType == type;
    }

    @Override
    public void execute(SectionRequest request, List<SectionData<?>> sectionResponseList) {
        SectionData<AResponse> sectionData = createSectionData(new SectionData(), request);

        // execute business logic
        ...

        sectionResponseList.add(sectionData);
    }

     @Override
    public <T> MenuSectionData<T> createSectionData(T t, MenuSectionRequest request) {
        return new MenuSectionData<>(request.getMenuSection());
    }
}

1-3 공통 전략 알고리즘 인터페이스 개발

전략 알고리즘 인터페이스에는 함수들이 정의되어있습니다.

1. 전략 알고리즘 인터페이스에는 모든 알고리즘 객체에서 구현해야 될 함수를 정의하였습니다.
2. 응답에 필요한 기본 데이터를 생성하는 메소드들이 존재합니다. 상황에 따라 기본 데이터를 세팅할 수도 있고, supplier를 제공받아 데이터를 세팅할 수도 있기에 createSectionData() 함수를 오버로딩을 통해 구현하였습니다.
3. 선택적으로 재정의할 수 있는 메소드들이 필요하여 default 메소드를 제공합니다.

public interface MenuSectionStrategy<E1 extends Enum<E1>> {

    boolean isMatchingRole(E1 type);

    void execute(SectionRequest request, List<SectionData<?>> sectionList);

    /**
     * 섹션의 기본 데이터를 생성합니다.
     *
     * @param t
     * @param request
     * @param <T>
     * @return
     */
    <T> SectionData<T> createSectionData(T t, SectionRequest request) {
        return new SectionData<>(request.getSection());
    }

    /**
     * 기본 데이터 생성과, Supplier 로 제공 받은 함수를 수행하여 데이터까지 세팅합니다.
     *
     * @param request
     * @param dataFactory
     * @param <T>
     * @return
     */
    <T> SectionData<T> createSectionData(SectionRequest request, Supplier<T> dataFactory) {
        SectionData<T> sectionData = new SectionData<>(request.getSection());

        T data = dataFactory.get();

        if (data == null || (data instanceof Collection && ((Collection<?>) data).isEmpty())) {
            return sectionData;
        }

        sectionData.setData(data);

        return sectionData;
    }

    deafult AMethod() {
        ...
    }

    deafult BMethod() {
        ...
    }
}

결론

이번 구조 개선을 통해 절자지향적으로 작성된 하나의 거대한 객체를 전략 패턴을 이용해 OOP 원칙을 준수할 수 있게 되었고, 동료 개발자들은 조금 더 유지보수하기 용이해졌습니다.

서버리스는 서버가 없다는게 아니라 서버를 관리할 필요가 없고, 서버가 보이지 않고, 서버를 프로비저닝 하지 않는 것이다. 그냥 코드를 배치하면 된다. 쉽게 말해 함수를 배치하는 것. 원래 서버리스는 FaaS(Function as a Service)를 뜻했지만 지금의 서버리스는 원격 관리되는 것을 모두 포함한다. Lambda, DynamoDB Cognito, API Gateway, Amazon S3, SNS와 SQS, Kinesis Data Firehose, Aurora Serverless, Step Functions, Fargate 등이 있다.

람다(Lambda)

람다는 가상의 함수이다. 관리할 서버 없이 코드를 프로비저닝하면 함수가 실행된다. 제한 시간이 있어서 실행 시간이 짧다. 최대 15분. Lambda를 사용하지 않으면 람다 함수가 실행되지 않고 비용 역시 함수가 실행되는 동안만 청구되며 호출을 받으면 온디맨드로 실행된다. 스케일링이 자동화된다. 더 많은 람다 함수를 동시에 필요로 하는 경우 AWS가 자동으로 프로비저닝해서 람다 함수를 늘려준다.

가격책정

Lambda가 수신하는 요청의 횟수에 따라 과금되는데 호출 횟수와 컴퓨팅 시간, 즉 Lambda가 실행된 시간만큼 청구된다. 프리 티어에서도 Lambda를 넉넉하게 제공해 주는데 Lambda 요청 1백만 건과 40만 GB-초의 컴퓨팅 시간이 포함된다.

장점

다양한 AWS 서비스와 통합할 수 있다. Lambda에 여러 가지 프로그래밍 언어를 사용할 수 있어서 상당히 자유로운 편이다. CloudWatch와의 모니터링 통합도 쉽다. 그리고 함수당 더 많은 리소스를 프로비저닝 하려면 함수당 최대 10GB의 램을 프로비저닝 할 수 있다. 함수의 RAM을 증가시키면 CPU 및 네트워크의 품질과 성능도 함께 향상된다.

지원 언어

Node.js 또 Python, Java 즉 Java 8 호환이나 Java 11, C# .NET Core Golang, C# /Powershell Ruby, 또 웬만한 언어는 모두 Lambda에서 사용 가능하다. 커뮤니티가 지원하는 사용자 지정 런타임 API 덕분이다. 예를 들어 Rust 언어 함수를 Lambda에서 사용하는 것도 오픈 소스 프로젝트가 있어서 가능하다.

컨테이너 이미지

Lambda 컨테이너 이미지를 지원한다. Lambda 컨테이너 이미지는 아주 특별한 것인데 컨테이너 이미지 자체가 Lambda의 런타임 API를 구현해야 한다. 즉 아무 컨테이너 이미지나 Lambda에서 실행되지는 않고 컨테이너 이미지를 만들 때 전제 조건이 필요하다. ECS와 Fargate는 계속 임의의 도커 이미지를 실행할 때 더 많이 사용된다. 따라서 시험에서 Lambda에 컨테이너를 실행해야 할 경우 해당 컨테이너가 Lambda 런타임 API를 구현하지 않으면 ECS나 Fargate에서 컨테이너를 실행해야 한다.

람다 제한

제한에는 실행 제한과 배포 제한이 있다.

실행 제한

실행 시 메모리 할당량은 128MB에서 10GB이고 메모리는 1MB씩 증가한다. 메모리가 증가하면 더 많은 vCPU가 필요하다. 최대 실행 시간은 15분이다. 이를 초과하면 Lambda 실행에 바람직하지 않다. 환경변수는 4KB까지 가질 수 있는데 상당히 제한적인 공간이나 Lambda 함수를 생성하는 동안 큰 파일을 가져올 때 사용할 수 있는 임시 공간이 있다. /tmp 폴더에 용량이 있으며 크기는 최대 10GB다. Lambda 함수는 최대 1,000개까지 동시 실행이 가능하며 요청 시 증가할 수 있지만 동시성은 미리 예약해 두는 것이 좋다.

배포 제한

압축 시 최대 크기는 50MB 압축하지 않았을 때는 250MB다. 이 용량을 넘는 파일의 경우 /tmp 공간을 사용해야 한다. 시작할 때 크기가 큰 파일이 있으면 /tmp 디렉터리를 사용한다. 배포 시에도 환경변수의 한도는 4KB다. (중요하다) 예를 들어 30GB의 RAM과 30분의 실행 시간이 필요하고 3GB의 큰 파일을 있을 때는 워크로드 처리에 Lambda 함수가 적합하지 않다는 걸 판단할 수 있어야 한다.

Customization At the Edge (엣지에서의 사용자 지정)

보통은 함수와 애플리케이션을 특정 리전에서 배포하지만 CloudFront를 사용할 때는 엣지 로케이션을 통해 콘텐츠를 배포한다. 모던 애플리케이션에서는 애플리케이션에 도달하기 전에 엣지에서 로직을 실행하도록 요구하기도 한다. 이를 엣지 함수라고 하며 CloudFront 배포에 연결하는 코드다. 이 함수는 사용자 근처에서 실행하여 지연 시간을 최소화하는 것이 목적이다. CloudFront에는 두 종류의 함수가 있는데 CloudFront 함수와 Lambda@Edge다. 엣지 함수를 사용하면 서버를 관리할 필요가 없다. 전역으로 배포되기 때문 사용 사례로는 CloudFront의 CDN 콘텐츠를 사용자 지정하는 경우를 들 수 있다. 사용한 만큼만 비용을 지불하며 완전 서버리다.

사용 사례

웹사이트 보안과 프라이버시 엣지에서의 동적 웹 애플리케이션에도 쓰이고 검색 엔진 최적화(SEO)에도 활용 가능 오리진 및 데이터 센터 간 지능형 경로에도 활용 엣지에서의 봇 완화 엣지에서의 실시간 이미지 변환 A/B 테스트 사용자 인증 및 권한 부여 사용자 우선순위 지정 사용자 추적 및 분석 등

CloudFront Functions

CloudFront에 클라이언트가 요청을 보내는 것을 뷰어 요청이라고 한다. 그런 다음 CloudFront가 오리진 요청을 오리진 서버에 전송한다. 서버가 CloudFront에 오리진 응답을 보내고 CloudFront가 클라이언트에게 뷰어 응답을 전송한다. CloudFront 함수는 JavaScript로 작성된 경량 함수로 뷰어 요청과 응답을 수정할 때만 사용한다. 확장성이 높고 지연 시간에 민감한 CDN 사용자 지정에 사용된다. 시작 시간은 1밀리초 미만이며 초당 백만 개의 요청을 처리한다. CloudFront의 네이티브 기능으로 모든 코드가 CloudFront에서 직접 관리된다. CloudFront 함수는 고성능, 고확장성이 필요할 때 뷰어 요청과 뷰어 응답에만 사용된다.

Lambda@Edge

이 함수는 Node.js나 Python으로 작성하며 초당 수천 개의 요청을 처리할 수 있다. 모든 CloudFront 요청 및 응답을 변경할 수 있다. 뷰어 요청은 앞서 본 대로고 오리진 요청은 CloudFront가 오리진에 요청을 전송하기 전에 수정할 수 있다. 오리진 응답은 CloudFront가 오리진에서 응답을 받은 후에 수정된다. 뷰어 응답은 CloudFront가 뷰어에게 응답을 보내기 전에 수정된다. 함수는 하나의 리전에만 작성할 수 있다. CloudFront 배포를 관리하는 리전과 같은 리전이다. 함수를 작성하면 CloudFront가 모든 로케이션에 해당 함수를 복제한다.

사용 사례

CloudFront Functions는 캐시 키를 정규화한다. 요청 속성을 변환하여 최적의 캐시 키를 생성한다. 요청이나 응답에 HTTP 헤더를 삽입, 수정, 삭제하도록 헤더를 조작하고 URL을 다시 쓰거나 리디렉션한다. 요청을 허용 또는 거부하기 위해 JWT를 생성하거나 검증하는 요청 인증 및 권한 부여에도 사용되며, 모든 작업이 1밀리초 이내에 이뤄진다. 반면에 Lambda@Edge의 실행 시간은 10초가 걸릴 수도 있다. CPU와 메모리가 증가하므로 여러 라이브러리를 로드할 수 있고 타사 라이브러리에 코드를 의존시킬 수 있다. 가령 SDK에서 다른 AWS 서비스에 액세스할 수 있도록 네트워크 액세스를 통해 외부 서비스에서 데이터를 처리할 수 있어 대규모 데이터 통합도 수행할 수 있다. 파일 시스템이나 HTTP 요청 본문에도 바로 액세스할 수 있다. 다양한 사용자 커스텀이 가능하다.

Lambda in VPC

기본적으로 Lambda 함수를 시작하면 여러분의 VPC 외부에서 시작된다. 즉 우리는 VPC 내에서 리소스에 액세스할 권한이 없다. RDS 데이터베이스, ElastiCache 캐시 내부 로드 밸런서를 시작하면 Lambda 함수가 해당 서비스에 액세스할 수 없다. Lambda 배포의 기본 설정이다. 인터넷의 퍼블릭 API에 액세스하는 것은 가능하다. DynamoDB에 액세스할 수 있는 건 DynamoDB가 AWS 클라우드의 퍼블릭 리소스이기 때문이다. 하지만 프라이빗 RDS 데이터베이스에는 연결할 수 없다. 이를 해결하려면 VPC에서 Lambda 함수를 시작해야 한다. 이를 위해서는 VPC ID Lambda 함수를 시작하려는 서브넷을 지정하고 Lambda 함수에 보안 그룹을 추가해야 한다. 그러면 Lambda가 서브넷에 ENI를 생성해 우리의 VPC에서 실행되는 가령 Amazon RDS에 액세스할 수 있게 된다.

사용 예시 (RDS 프록시)

Lambda 함수가 RDS 프록시에 연결할 수 있으려면 VPC에서 Lambda 함수를 시작해야 한다. RDS 프록시는 퍼블릭 액세스가 불가능하므로 Lambda 함수를 퍼블릭으로 시작하면 RDS 프록시에 네트워크 연결을 할 수가 없다.

Dynamo DB

완전 관리형 데이터베이스로 데이터가 다중 AZ 간에 복제되므로 가용성이 높다. DynamoDB는 클라우드 네이티브이며 AWS의 독점 서비스다. NoSQL DB지만, 트랜잭션을 지원한다. DynamoDB를 이용하면 방대한 워크로드로 확장이 가능합니다 데이터베이스가 내부에서 분산되기 때문이다. 초당 수백만 개의 요청을 처리하고 수조 개의 행, 수백 TB의 스토리지를 갖게 된다. 성능은 한 자릿수 밀리초를 자랑하고 일관성 또한 높다. 보안과 관련된 모든 기능은 IAM과 통합되어 있다. (보안, 권한 부여, 관리 기능 포함) 비용이 적게 들고 오토 스케일링 기능이 탑재돼 있다. 유지 관리나 패치 없이도 항상 사용할 수 있다. 데이터베이스를 프로비저닝할 필요가 없다. 항상 사용할 수 있으므로 테이블을 생성해 해당 테이블의 용량만 설정하면 된다. 테이블 클래스는 두 종류다. 액세스가 빈번한 데이터에는 Standard 클래스 액세스가 빈번하지 않는 데이터는 IA 테이블 클래스. DynamoDB는 테이블로 구성되며 데이터베이스를 생성할 필요가 없다. 이미 존재하기 때문이다.

테이블

DynamoDB에 테이블을 생성하면 각 테이블에 기본 키가 부여되는데 기본 키는 생성 시 결정된다. 각 테이블에 데이터를 추가한다. 항목, 즉 행을 무한히 추가할 수 있다. 각 항목은 속성을 가지며 속성은 열에 표시된다. 속성은 나중에 추가할 수도 있고 null이 될 수도 있다. DynamoDB에서는 사전 요구 사항 없이 나중에 쉽게 속성을 추가할 수 있다. DynamoDB 항목의 최대 크기는 400KB이므로 큰 객체를 저장할 때는 적합하지 않다. 문자열, 숫자, 바이너리, 불리언 null과 같은 스칼라 유형 목록, 지도와 같은 문서 유형과 세트 유형을 지원한다. 데이터의 유형과 구성 면에서 스키마를 빠르게 전개해야 할 때 Aurora나 RDS보다는 DynamoDB가 더 나은 선택이다. 기본 키는 파티션 키와 선택 사항인 정렬 키로 구성되며, 속성 테이블이 있다. 데이터베이스 형태다. 속성은 null로 설정하거나 나중에 추가할 수 있다.

Read/Write Capacity Modes

DynamoDB를 사용하려면 읽기/쓰기 용량 모드도 설정해야 한다. 테이블 용량 관리 방식을 제어하는 데는 두 가지 모드가 있다. 기본 설정은 프로비저닝된 모드로 미리 용량을 프로비저닝 해야 한다. 초당 읽기/쓰기 요청 수를 예측해서 미리 지정하면 그것이 테이블의 용량이 된다. 미리 용량을 계획하고 프로비저닝된 RCU와 WCU만큼의 비용을 지불하는 방식이다. RCU는 읽기 용량 단위 WCU는 쓰기 용량 단위를 뜻한다. 미리 용량을 계획한 경우에도 오토 스케일링 기능이 있으므로 테이블의 로드에 따라 자동으로 RCU와 WCU를 늘리거나 줄일 수 있다. 프로비저닝된 모드는 로드를 예측할 수 있고 서서히 전개되며 비용 절감을 원할 때 적합하다. 온디맨드 모드에서는 읽기/쓰기 용량이 워크로드에 따라 자동으로 확장된다. 미리 용량 계획을 하지 않으므로 RCU나 WCU 개념 자체가 없다. 온디맨드 모드에서는 정확히 사용한 만큼의 비용을 지불한다. 모든 읽기와 쓰기에 비용을 지불해야 한다. 비싼 솔루션으로 볼 수도 있지만 워크로드를 예측할 수 없거나 급격히 증가하는 경우에 유용하다. 수천 개의 트랜잭션을 수백만 개의 트랜잭션으로 1분 내로 확장해야 하는 애플리케이션에서 온디맨드 모드를 선택해야한다. 트랜잭션이 없거나 하루에 많아야 4~5회밖에 되지 않는 워크로드라면 트랜잭션 횟수만큼만 비용을 지불하는 온디맨드 모드가 적합하다.

고급 기능

DynamoDB Accelerator, 즉 DAX는 DynamoDB를 위한 고가용성의 완전 관리형 무결점 인메모리 캐시로DynamoDB 테이블에 읽기 작업이 많을 때 DAX 클러스터를 생성하고 데이터를 캐싱하여 읽기 혼잡을 해결한다. DAX는 캐시 데이터에 마이크로초 수준의 지연 시간을 제공한다. DAX 클러스터는 기존 DynamoDB API와 호환되므로 애플리케이션 로직을 변경할 필요가 없다. DynamoDB 테이블과 애플리케이션이 있을 때 몇몇 캐시 노드가 연결된 DAX 클러스터를 생성하면 백그라운드에서 DAX 클러스터가 Amazon DynamoDB 테이블에 연결된다. 캐시의 기본 TTL은 5분으로 설정되어 있으나 변경할 수 있다. ElastiCache가 아니라 DAX를 사용하는 이유는 무엇일까? DAX는 DynamoDB 앞에 있고 개별 객체 캐시와 쿼리와 스캔 캐시를 처리하는 데 유용하다. 예를 들어 집계 결과를 저장할 때는 Amazon ElastiCache가 좋고 Amazon DynamoDB는 대용량의 연산을 저장할 때 좋다. Amazon DynamoDB에 캐싱 솔루션을 추가할 때는 보통 DynamoDB Accelerator 즉 DAX를 사용한다.

Streams

DynamoDB에서는 스트림 처리도 가능하다. 테이블의 모든 수정 사항 즉 생성, 업데이트, 삭제를 포함한 스트림을 생성할 수 있다. 사용자 테이블에 새로운 사용자가 등록됐을 때 환영 이메일을 보내는 등 DynamoDB 테이블의 변경 사항에 실시간으로 반응하는 데 활용할 수 있다. 실시간으로 사용 분석을 하거나 파생 테이블을 삽입할 수도 있다. 리전 간 복제를 실행하거나 DynamoDB 테이블 변경 사항에 대해 Lambda 함수를 실행할 수도 있다. DynamoDB에는 두 가지 스트림 처리가 있다. DynamoDB 스트림은 보존 기간이 24시간이고 소비자 수가 제한된다. Lambda 트리거와 함께 사용하면 좋다. 자체적으로 읽기를 실행하려면 DynamoDB Stream Kinesis 어댑터를 사용한다. Kinesis Data Streams에 변경 사항을 바로 보내는 방법도 있다. 이 스트림은 보존 기간이 1년이고 더 많은 수의 소비자 수를 갖고 데이터를 처리하는 방법이 훨씬 많다. AWS Lambda 함수 Kinesis Data Analytics Kinesis Data Firehose Glue 스트리밍 ETL 등

Global Table

글로벌 테이블은 여러 리전 간에 복제가 가능한 테이블이다. 테이블을 US-EAST-1과 AP-SOUTHEAST-2에 둘 수 있다. 두 테이블 간에는 양방향 복제가 가능하다. US-EAST-1이나 AP-SOUTHEAST-2 테이블 둘 중 하나에 쓰기를 하면 된다는 뜻 DynamoDB 글로벌 테이블은 복수의 리전에서 짧은 지연 시간으로 액세스할 수 있게 해 준다. 다중 활성 복제가 가능하므로 애플리케이션이 모든 리전에서 테이블을 읽고 쓸 수 있다는 뜻 글로벌 테이블을 활성화하려면 DynamoDB 스트림을 활성화해야 리전 간 테이블을 복제할 수 있는 기본 인프라가 구축된다.

TTL

DynamoDB의 기능 중에 타임 투 리브(TTL)라는 기능은 만료 타임스탬프가 지나면 자동으로 항목을 삭제하는 기능이다. 가령 SessionData라는 테이블에서 ExpTime(TTL)이라는 만료 기간 속성이 있는데, 이 안에 타임스탬프가 들어간다. TTL을 정의한 다음 에포크 타임스탬프에서의 현재 시간이 ExpTime 열을 넘어설 경우 해당 항목을 만료 처리하고 삭제 처리를 진행하는 개념이다. 데이터 테이블의 항목이 일정 시간 후에 삭제되도록 하는 것. 사용 사례는 웹 세션 핸들링이다.

재해 복구

재해 복구에도 DynamoDB를 활용할 수 있다. 지정 시간 복구(PITR)를 사용하여 지속적인 백업을 할 수 있다. 활성화를 선택할 수 있고 35일 동안 지속된다. 활성화하면 백업 기간 내에는 언제든 지정 시간 복구를 실행할 수 있다. 복구를 진행할 경우 새로운 테이블을 생성한다. 이보다 더 긴 백업 옵션으로는 온디맨드 백업이 있고 이 백업은 직접 삭제할 때까지 보존된다. 온디맨드 백업은 DynamoDB의 성능이나 지연 시간에 영향을 주지 않는다. 백업을 좀 더 제대로 관리할 수 있는 방법 중 하나로 AWS Backup 서비스가 있다. 백업에 수명 주기 정책을 활성화할 수 있고 재해 복구 목적으로 리전 간 백업을 복사할 수 있다. 이 옵션 또한 백업으로 복구를 진행하면 새로운 테이블이 생성된다.

S3와 통합

S3에 테이블을 내보낼 수 있다. 이를 위해서는 지정 시간 복구 기능을 활성화해야 한다. DynamoDB 테이블을 S3로 내보내고 쿼리를 수행하려면 Amazon Athena 엔진을 사용한다. 지속적인 백업을 활성화한 상태이므로 최근 35일 이내 어떤 시점으로든 테이블을 내보낼 수 있다. 테이블을 내보내도 테이블의 읽기 용량이나 성능에 영향을 주지 않는다. 따라서 DynamoDB를 Amazon S3로 먼저 내보내기 하여 데이터 분석을 수행할 수 있다. 감사 목적으로 스냅샷을 확보할 수도 있고 데이터를 DynamoDB로 다시 가져오기 전에 데이터 ETL 등 대규모 변경을 실행할 수 있다. 내보낼 때는 DynamoDB JSON이나 ION 형식을 이용한다. Amazon S3에서 테이블을 가져올 수도 있다. S3에서 CSV, JSON 그리고 ION 형식으로 내보낸 다음 새로운 DynamoDB 테이블을 생성하는 식이다. 쓰기 용량을 소비하지 않고 새로운 테이블이 생성된다. 가져올 때 발생한 오류는 모두 CloudWatch Logs에 기록된다.

API GATEWAY

AWS의 서버리스 서비스로 REST API를 생성할 수 있으므로 클라이언트가 퍼블릭 액세스할 수 있다. API Gateway에 클라이언트가 직접 소통하며 다양한 작업을 할 수 있고 Lambda 함수에 요청을 프록시할 수 있다. API Gateway를 사용하는 이유는 HTTP 엔드포인트뿐만 아니라 다양한 기능, 예를 들어 인증부터 사용량 계획, 개발 단계 등의 기능을 제공하기 때문이다. API Gateway는 Lambda와 통합하면 완전 서버리스 애플리케이션이 구축되므로 인프라 관리가 필요 없다. WebSocket 프로토콜을 지원하므로 API Gateway로 두 가지 방법의 실시간 스트리밍이 가능하다. API 버저닝을 핸들링하므로 버전 1, 2, 3이 생겨도 클라이언트 연결이 끊기지 않는다. dev, test, prod 등 여러 환경을 핸들링할 수 있고 보안에도 활용할 수 있다. 인증, 권한 부여 등 수많은 보안 기능을 API Gateway에 활성화할 수 있다. API 키를 생성할 수 있고 API Gateway에 클라이언트 요청이 과도할 때 요청을 스로틀링할 수 있다. Swagger나 Open API 3.0과 같은 공통 표준을 사용하여 신속히 API를 정의하여 가져올 수 있다. API Gateway 수준에서 요청과 응답을 변형하거나 유효성을 검사해 올바른 호출이 실행되게 할 수 있다. SDK나 API 스펙을 생성하거나 API 응답을 캐시할 수도 있다.

통합

Lambda 함수를 사용하는 REST API를 완전 서버리스 애플리케이션에 노출시키는 가장 일반적이고 간단한 방법이다. 백엔드의 HTTP의 엔드포인트를 노출시킬 수 있다. 온프레미스에 HTTP API가 있거나 클라우드 환경에 애플리케이션 로드 밸런서가 있을 때 API Gateway를 활용하면 속도 제한 기능 캐싱, 사용자 인증, API 키 등의 기능을 추가할 수 있다. HTTP 엔드포인트에서 API Gateway 계층을 활용하는 것이다. AWS 서비스와도 통합되며, 어떤 AWS API라도 노출시킬 수 있다. 단계 함수 워크플로우를 시작할 수 있고 API Gateway에서 직접 SQS에 메시지를 게시할 수도 있다. 인증을 추가하거나 API를 퍼블릭으로 배포하거나 특정 AWS 서비스에 속도 제한을 추가하기 위해 통합하는 것이다.

엔드 포인트 타입

첫 번째 유형은 기본 유형인 엣지 최적화다. 글로벌 클라이언트용 전 세계 누구나 API Gateway에 액세스할 수 있다. 모든 요청이 CloudFront 엣지 로케이션을 통해 라우팅되므로 지연 시간이 개선된다. API Gateway는 여전히 생성된 리전에 위치하지만 모든 CloudFront 엣지 로케이션에서 액세스될 수 있다. CloudFront 엣지 로케이션을 원하지 않을 때는 리전 배포를 사용한다. 모든 사용자는 API Gateway를 생성한 리전과 같은 리전에 있어야 한다. 자체 CloudFront 배포를 생성할 수도 있다. 엣지 최적화 배포와 동일한 결과를 내며 캐싱 전략과 CloudFront 설정에 더 많은 권한을 가질 수 있다. API Gateway 배포 유형은 프라이빗으로 퍼블릭 배포가 아니다. 프라이빗 API Gateway는 VPC 내에서만 액세스할 수 있다. ENI 같은 인터페이스 VPC 엔드포인트를 사용 API Gateway에 액세스를 정의할 때는 리소스 정책을 사용

보안

첫 번째 방법은 IAM 역할을 사용하는 것이다. 가령 EC2 인스턴스에서 실행되는 내부 애플리케이션에서 유용하다. API Gateway의 API에 액세스할 때 IAM 역할을 사용하도록 하는 것이다. 모바일 애플리케이션이나 웹 애플리케이션의 외부 사용자에 대한 보안 조치로 Amazon Cognito를 사용할 수 있다. 자체 로직을 실행하려면 사용자 지정 권한 부여자를 사용하면 된다. (Lambda 함수) HTTPS 보안도 있다. 사용자 지정 도메인 이름을 AWS Certificate Manager 즉 ACM과 통합할 수 있다. 엣지 최적화 엔드포인트를 사용할 경우 인증서는 us-east-1에 있어야 하고 리전 엔드포인트를 사용한다면 인증서는 API Gateway 단계와 동일한 리전에 있어야 한다. 끝으로 Route 53에 CNAME이나 A-별칭 레코드를 설정해 도메인 및 API Gateway를 가리키도록 해야 한다.

Step Function

Step functions는 서버리스 워크플로를 시각적으로 구성할 수 있는 기능으로 주로 람다 함수를 오케스트레이션 하는 데 활용한다. 그래프를 만들어서 각 그래프 단계별로 해당 단계의 결과에 따라 다음으로 수행하는 작업이 뭔지 정의한다. 좀 복잡한 워크플로를 만들어 AWS에서 실행시킬 수 있는 편리한 도구 Step functions가 제공하는 기능으로는 시퀀싱, 병행 실행, 조건 설정 타임아웃, 에러 처리하기 등이 있다. 람다 함수만 처리하는 게 아니라 EC2랑도 연동할 수 있고, ECS, 온프레미스 서버 또 API 게이트웨이랑 SQS 큐 등 다양한 AWS 서비스를 워크플로에 넣을 수 있다. 워크플로에 사람이 개입해서 승인을 해야만 진행되는 단계를 설정할 수 있다. 어떤 지점에 이르러서는 사람이 결과를 확인하고 승인을 하면 다음 단계로 넘어 가고, 아니면 워크플로가 멈춰 실패하게 한다. 다양한 사용처가 있는데, 예를 들어 주문 이행이나 데이터 처리, 웹 애플리케이션 등 구성하기 복잡한 워크플로를 시각적으로 구성하려고 할 때 사용한다.

EC2 시작 유형

AWS에서 컨테이너를 실행하면 ECS 클러스터에 이른바 ECS 태스크를 실행하는 것이다. ECS 클러스터에는 들어있는 게 있는데 EC2 시작 유형을 사용하면 EC2 인스턴스가 들어있는 것이다. EC2 시작 유형으로 EC2 클러스터를 사용할 때는 인프라를 직접 프로비저닝하고 유지해야 한다. 즉 Amazon ECS 및 ECS 클러스터가 여러 EC2 인스턴스로 구성된다. 이때 ECS 인스턴스는 특별하게 각각 ECS 에이전트(Agent)를 실행해야 한다. 그럼 ECS 에이전트가 각각의 EC2 인스턴스를 Amazon ECS 서비스와 지정된 ECS 클러스터에 등록한다. 이후에 ECS 태스크를 수행하기 시작하면 AWS가 컨테이너를 시작하거나 멈춘다. 즉 새 컨테이너가 생기면 미리 프로비저닝한 EC2 인스턴스에 지정된다. ECS 태스크를 시작하거나 멈추면 자동으로 위치가 지정된다.

Fargate 시작 유형

Fargate 유형은 AWS에 컨테이너를 실행하는데 인프라를 프로비저닝하지 않아 관리할 EC2 인스턴스가 없다. 서버를 관리하지 않아 서버리스라 부르는데 서버가 없는 건 아니다. Fargate 유형은 ECS 클러스터가 있을 때 ECS 태스크를 정의하는 태스크 정의만 생성하면 필요한 CPU나 RAM에 따라 ECS 태스크를 AWS가 대신 실행한다. 즉 새 도커 컨테이너를 실행하면 어디서 실행되는지 알리지 않고 그냥 실행된다. 작업을 위해 EC2 인스턴스가 생성, 관리할 필요도 없고, 확장하려면 간단하게 태스크 수만 늘리면 된다. 시험에서는 서버리스인 Fargate를 사용하라는 게 자주 나온다.

IAM Roles for ECS

EC2 Instance Profile

EC2 시작 유형에서만 사용 가능하다. 먼저 EC2 인스턴스가 도커에 ECS 에이전트를 실행한다. EC2 시작 유형을 사용한다면 EC2 인스턴스 프로필을 생성한다. ECS 에이전트만이 EC2 인스턴스 프로필을 사용하며 그 EC2 인스턴스 프로필을 이용해 API 호출 한다. 그럼 인스턴스가 저장된 ECS 서비스가 CloudWatch 로그에 API 호출을 해서 컨테이너 로그를 보내고 ECR로부터 도커 이미지를 가져온다. Secrets Manager나 SSM Parameter Store에서 민감한 데이터를 참고하기도 한다.

EC2 Task Role

ECS 태스크는 ECS 태스크 역할을 가진다. EC2와 Fargate 시작 유형에 모두 해당되며 두 개의 태스크가 있다면 각자에 특정 역할을 만들 수 있다. 역할을 다르게 하는 이유는 무엇일까? 역할이 각자 다른 ECS 서비스에 연결할 수 있기 위함이다. ECS 서비스의 태스크 정의에서 태스크의 역할을 정의한다.

로드 밸런서와 통합

HTTP나 HTTPS 엔드 포인트로 태스크를 활용하기 위해 애플리케이션 로드 밸런서(ALB)를 앞에서 실행하면 모든 사용자가 ALB 및 백엔드의 ECS 태스크에 직접 연결된다. NLB는 처리량이 매우 많거나 높은 성능이 요구될 때만 권장한다. AWS Private Link와 사용할 때도 권장되는 옵션이다. ALB는 Fargate와도 사용 가능. CLB는 불가능.

Data Volumes

EFS가 자주 사용된다. 네트워크 파일 시스템이라 EC2와 Fargate 시작 유형 모두 호환이 되며 EC2 태스크에 파일 시스템을 직접 마운트할 수 있다. 어느 AZ에 실행되는 태스크든 Amazon EFS에 연결되어 있다면 데이터를 공유할 수 있고 원한다면 파일 시스템을 통해 다른 태스크와 연결할 수 있다. Fargate로 서버리스 방식으로 ECS 태스크를 실행하고 파일 시스템 지속성을 위해서는 Amazon EFS를 사용하는 방식이 좋다. EFS 역시 서버리스이기 때문에 서버를 관리할 필요 없고 미리 비용을 지불한다. 미리 프로비저닝하기만 하면 바로 사용할 수 있다. 사용 사례로는 EFS와 ECS를 함께 사용해서 다중 AZ가 공유하는 컨테이너의 영구 스토리지가 있다. Amazon S3는 ECS 태스크에 파일 시스템으로 마운트될 수 없다.

ECR (Elastic Container Registry)

AWS에 도커 이미지를 저장하고 관리하는 데 사용되며, ECR에는 두 가지 옵션이 있다. 첫 번째는 계정에 한 해 이미지를 비공개로 저장하는 건데 여러 계정으로 설정할 수도 있다. 혹은 퍼블릭 저장소를 사용해 Amazon ECR Public Gallery에 게시하는 방법이 있다. ECR은 Amazon ECS와 완전히 통합되어 있고 이미지는 백그라운드에서 Amazon S3에 저장된다. ECR 저장소에 여러 도커 이미지가 있는데 ECS 클러스터의 EC2 인스턴스에 이미지를 끌어오기 위해서는EC2 인스턴스에 IAM 역할을 지정하면 된다. IAM 역할이 도커 이미지를 인스턴스에 끌어온다. ECR에 대한 모든 접근은 IAM이 보호하고 있다. ECR에 권한 에러가 생긴다면 정책을 살펴봐야 한다. EC2 인스턴스에 이미지를 끌어온 후에는 컨테이너가 시작된다. Amazon ECR은 단순히 저장하는 리포지토리에 그치지 않고 이미지의 취약점 스캐닝, 버저닝 태그 및 수명 주기 확인을 지원한다.

EKS (Elastic Kubernetes Service)

AWS에 관리형 Kubernetes 클러스터를 실행할 수 있는 서비스다. EKS에는 두 가지 실행 모드가 있다. EC2 시작 모드는 EC2 인스턴스에서처럼 작업자 모드를 배포할 때 사용하고 Fargate 모드는 EKS 클러스터에 서버리스 컨테이너를 배포할 때 사용한다. 클라우드 또는 컨테이너 간 마이그레이션을 실행하는 경우 Amazon EKS가 솔루션이 될 수 있다. EKS Node는 ASG로 관리할 수 있다. EKS 서비스나 Kubernetes 서비스를 노출할 때는 프라이빗 로드 밸런서나 퍼블릭 로드 밸런서를 설정해 웹에 연결해야 한다.

EKS 노드 유형

관리형 노드 그룹은 AWS로 노드, 즉 EC2 인스턴스를 생성하고 관리한다. 노드는 EKS 서비스로 관리되는 오토 스케일링 그룹의 일부다. 온디맨드 인스턴스와 스팟 인스턴스를 지원한다. 자체 관리형 노드 그룹은 사용자 지정 사항이 많고 제어 대상이 많은 경우 직접 노드를 생성하고 EKS 클러스터에 등록한 다음 ASG의 일부로 관리해야 한다. 사전 빌드된 AMI인 Amazon EKS 최적화 AMI를 사용하면 시간을 절약할 수 있다. 자체 AMI를 빌드해도 되지만 복잡하다. 온디맨드 인스턴스와 스팟 인스턴스를 지원한다. 끝으로 노드를 원치 않는 경우에는 Amazon EKS가 지원하는 Fargate 모드를 선택하면 유지 관리도 필요 없고 노드를 관리하지 않아도 되며 Amazon EKS에서 컨테이너만 실행하면 된다. Amazon EKS 클러스터에 데이터 볼륨을 연결하려면 EKS 클러스터에 스토리지 클래스 매니페스트를 지정해야 한다. 컨테이너 스토리지 인터페이스(CSI)라는 규격 드라이버를 활용하는데 시험에 나올 만한 키워드다. Amazon EBS와 Fargate 모드가 작동하는 유일한 스토리지 클래스 유형인 Amazon EFS를 지원하고 Amazon FSx for Lustre와 Amazon FSx for NetApp ONTAP을 지원한다.

App Runner

이 서비스로는 누구나 AWS에 배포를 할 수 있다. 인프라나 컨테이너, 소스 코드 등을 알 필요가 없기 때문이다. 먼저 소스 코드나 Docker 컨테이너 이미지를 가지고 원하는 구성을 설정한다. vCPU의 수나 컨테이너 메모리의 크기 오토 스케일링 여부 상태 확인을 설정하면 된다. 웹 애플리케이션이나 API에 들어갈 기본 설정을 설정하는 것이다. 다음 작업은 자동으로 이뤄진다. App Runner 서비스가 웹 앱을 빌드하고 배포한다. 또는 컨테이너가 생성되고 배포된다. API나 웹 앱이 배포된 다음엔 URL을 통해 바로 액세스할 수 있다. 배후에서 AWS 서비스가 사용되는 것이겠지만 사용자는 굳이 몰라도 빠른 배포를 할 수 있다. 오토 스케일링이 가능하고 가용성이 높으며 로드 밸런싱 및 암호화 기능을 지원한다. 애플리케이션, 즉 컨테이너가 VPC에 액세스할 수도 있어서 데이터베이스와 캐시 메시지 대기열 서비스에 연결할 수 있다. 사용 사례로는 빨리 배포해야 하는 웹 앱, API 그리고 마이크로서비스가 있다. 신속한 프로덕션 배포가 필요할 때도 가장 좋은 방법은 AWS App Runner 서비스를 사용하는 것이다.

SQS의 핵심은 자료구조 큐다. 큐는 메시지를 포함한다. 메시지를 담기 위해서 프로듀서가 SQS 대기열에 메시지를 전송해야 한다. 프로듀서는 한 개일 수도 그 이상일 수도 있다. 여러 프로듀서가 여러 개의 메시지를 SQS 대기열에 보내게 할 수 있다. 큐에서 메시지를 처리하고 수신해야 하는 대상을 컨슈머라고 한다. 만일 큐에 메시지가 있으면 소비자는 이 메시지를 폴링해서 정보를 얻는다. 그리고 그 메시지로 처리를 하고 큐에서 그 메시지를 삭제한다. 여러 컨슈머가 SQS 큐에서 메시지를 소비할 수 있도록 할 수도 있다.

Standard Queue

완전 관리형 서비스이며 애플리케이션을 분리하는 데 사용된다. 초당 원하는 만큼 메시지를 보낼 수 있고 큐에도 원하는 만큼 메시지를 포함시킬 수 있습니다 처리량에 제한이 없고 큐에 있는 메시지 수에도 제한이 없다. 각 메시지는 수명이 짧다. 메시지는 기본값으로 4일 동안 큐에 남아 있고 큐에 있을 수 있는 최대 시간은 14일이다. 즉 큐에 메시지를 보내자마자 컨슈머가 읽고 해당 보존 기간 내에 처리한 후 큐에서 삭제해야 한다. 그렇지 않으면 소실된다. 지연 시간이 짧아서 SQS는 메시지를 보내거나 SQS에서 메시지를 읽을 때마다 게시 및 수신 시 10밀리초 이내로 매우 빠르게 응답을 받게 된다. SQS의 메시지는 작아야 한다. 전송된 메시지당 256KB 미만이어야 한다. SQS는 대기열 서비스이므로 높은 처리량, 높은 볼륨 등이 있어서 중복 메시지가 있을 수 있습니다 최선의 오더라는 뜻으로 품절 메시지를 보낼 수도 있다.

SQS FIFO Queue

큐에 첫 번째로 도착한 메시지가 큐를 떠날 때도 첫 번째가 되도록 큐 내의 순서가 정렬된다는 의미다. 즉 Standard Queue보다 순서가 더 확실히 보장되는 것이다. FIFO Queue는 순서를 확실히 보장하기 때문에 이 SQS 큐의 처리량에는 제한이 있다. 묶음이 아닐 경우에는 초당 300개의 메시지를 처리하고 메시지를 묶음으로 보낸다면 그 처리량은 초당 3,000개가 된다. 중복을 제거하도록 해주는 SQS FIFO 대기열의 기능으로 인해 정확히 한 번만 보낼 수 있게 해 준다. 우리는 메시지가 소비자에 의해 순서대로 처리된다는 것을 알고 있다. 따라서 분리가 발생하거나 메시지의 순서를 유지할 필요가 있을 때 FIFO 대기열을 사용하면 된다. SQS로 너무 많은 메시지를 보내지 않도록 처리량에 제한도 할 수 있다.

Message Producer

프로듀서는 SDK를 사용해 메시지를 SQS로 전송한다. 메시지가 작성되면 프로듀서가 해당 메시지를 읽고 삭제할 때까지 SQS 큐에 유지된다. 메시지가 삭제됐다는 것은 메시지가 처리됐다는 뜻이다. Standard SQS는 무제한 처리량을 보장한다.

Message Consumer

코드로 작성해야 하는 애플리케이션이다. 이러한 애플리케이션은 EC2 인스턴스 즉 AWS 상의 가상 서버에서 실행될 수 있다. 원하는 경우 자체 온프레미스 서버에서 실행할 수도 있고 AWS Lambda의 람다 함수에서 실행할 수도 있다. 컨슈머는 메시지들을 처리할 책임이 있으므로, 메시지들을 처리 후 DeleteMessage API로 큐에서 삭제한다. 그러면 다른 소비자들이 이 메세지를 볼 수 없게 되고, 메시지 처리가 완료된다.

Multi Ec2 Instance Consumer

SQS 큐에서 더 많은 메시지가 있어서 처리량을 늘려야 하면 소비자를 추가하고 수평 확장을 수행해서 처리량을 개선할 수 있다. 이런 경우에는 ASG(Auto Scaling groups)와 더불어 SQS를 사용한다. 컨슈머가 ASG의 내부에서 EC2 인스턴스를 실행하고 SQS 큐에서 메시지를 폴링한다. ASG는 일종의 지표에 따라 확장되어야 하는데 우리가 사용할 수 있는 지표는 큐의 길이다. ApproximateNumberOfMessages라고 한다. 모든 SQS 큐에서 쓸 수 있는 CloudWatch 지표다. 알람을 설정할 수도 있는데 큐의 길이가 특정 수준을 넘어가면 CloudWatch Alarm을 통해 오토 스케일링 그룹의 용량을 X만큼 증가시킨다. 만일 웹사이트에 오더가 폭주했다거나 해서 오토 스케일링 그룹이 더 많은 EC2 인스턴스를 제공하면 메시지들을 더 높은 처리량으로 처리할 수 있다.

SQS Security

SSE-SSQ 타입을 통해 메시지를 보내고 생성함으로써 전송 중 암호화를 하거나KMS 키를 사용하여 미사용 암호화를 얻고 원한다면 클라이언트 측 암호화를 할 수도 있다. 이는 클라이언트가 자체적으로 암호화 및 암호 해독을 수행해야 함을 의미한다. SQS에서 기본적으로 지원하는 것은 아니다. 액세스 제어를 위해 IAM 정책은 SQS API에 대한 액세스를 규제할 수 있고 S3 버킷 정책과 유사한 SQS 액세스 정책도 있다. SQS 큐에 대한 교차 계정 액세스를 수행하려는 경우나 곧 배울 SNS 혹은 Amazon S3 같은 다른 서비스가 SQS 큐에 S3 이벤트 같은 것을 쓸 수 있도록 허용하려는 경우에 매우 유용하다.

메시지 가시성 시간 초과

소비자가 메시지를 폴링하면 그 메세지는 다른 소비자들에게 보이지 않게 된다. 예시를 들어보자. 컨슈머가 ReceiveMessage 요청을 하면, 큐에서 메시지가 반환된다. 이제 가시성 시간 초과가 시작된다. 기본값으로 메시지 가시성 시간 초과는 30초다. 그 말은 이 30초 동안 메시지가 처리되어야 한다는 것이다. 그러면 동일한 혹은 다른 컨슈머가 메시지 요청 API를 호출하면 메시지가 반환되지 않는다. 시간 초과 기간 내에 또 다른 요청이 들어와도 메시지가 반환되지 않는다. 즉 가시성 시간 초과 기간 내에서는 그 메시지는 다른 소비자들에게 보이지 않는다. 하지만 가시성 시간 초과가 경과되고 메시지가 삭제되지 않았다면 메시지는 큐에 다시 넣는다. 그러면 다른 컨슈머 또는 동일한 컨슈머가 또 ReceiveMessage API 호출을 하면 이전의 그 메시지를 또 받게 된다. 가시성 시간 초과 기간 내에 메시지를 처리하지 않으면 메시지가 두 번 처리될 수도 있다는 것을 알 수 있다. 만일 컨슈머가 메시지를 적극적으로 처리하고 있지만 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있는데 메시지를 처리하지 않아 가시성 시간 초과 기간을 벗어날 때를 위해 ChangeMessageVisibility라는 API가 있다. 즉 컨슈머가 메시지를 처리하는 데 시간이 더 필요하다는 것을 알고 있고 해당 메시지를 두 번 처리하고 싶지 않다면 컨슈머는 ChangeMessageVisibility API를 호출하여 SQS에 알려야 한다. 가시성 시간 초과는 애플리케이션에 합당한 것으로 설정되어야 하고 컨슈머는 시간이 조금 더 필요하다는 것을 알면 ChangeMessageVisibility API를 호출하도록 프로그래밍해야 한다. 그러면 더 많은 시간을 확보하고 해당 가시성 시간 초과 기간을 늘릴 수 있다.

SQS Long polling

컨슈머가 큐에 메시지를 요청하는데 대기열에 아무것도 없다면 메시지 도착을 기다리면 된다. 이것을 롱 폴링이라고 합니다 첫 번째 장점은 지연 시간을 줄이기 위해서다. 두 번째 장점는 SQS로 보내는 API 호출 숫자를 줄이기 위해서다.

롱 폴링을 구성하는 방법엔 두 가지가 있다. 큐 레벨에서 구성하여 폴링하는 아무 컨슈머로부터 롱 폴링을 활성화하는 방법이 있다. WaitTimeSeconds를 지정함으로 컨슈머가 스스로 롱 폴링을 하도록 선택할 수도 있다.

만약 시험에서 SQS 큐에 대한 API 호출 수를 최적화하고 지연 시간을 줄이는 법을 묻는다면 롱 폴링을 떠올려야 한다.

SQS With ASG

SQS 큐와 ASG가 있을 때 ASG 내의 EC2 인스턴스가 메시지를 SQS 큐에서 폴링한다. 이는 ASG를 자동으로 큐 크기에 따라 확장시키기 위함으로 CloudWatch 지표인 큐 길이를 보고 결정할 수 있다. ApproximateNumberOfMessages라고 하는 이 지표는 대기열에 몇 개의 메시지가 남아 있는지를 표시한다. 이를 기반으로 경보를 지정할 수 있는데 가령 이 지표가 1,000을 넘는 경우 1,000개의 메시지가 대기열에서 처리를 기다리고 있다는 뜻으로 처리에 지연이 발생하고 있음을 파악할 수 있다. 따라서 경보를 생성하여 1,000개의 메시지가 대기 중임을 경보를 통해 알리면 이 경보가 EC2 인스턴스가 충분하지 않음을 근거로 오토 스케일링 그룹에 확장 동작을 트리거한다. 이렇게 하면 ASG에 더 많은 EC2 인스턴스가 추가되며 확장이 이루어져 메시지가 훨씬 더 빨리 처리된다. 동시에 SQS 큐의 크기는 줄어들어 이에 대한 축소 또한 실행된다.

분리나 급격히 증가한 로드 혹은 시간초과 등의 문제에서 신속한 스케일링이 필요한 경우에는 SQS 큐를 떠올려야 한다.

SNS (Simple Notification Service)

메시지 하나를 여러 수신자에게 보낸다고 가정하면 pub/sub 구조를 사용하는 것이 이상적이다. 메시지를 토픽으로 publish 한다. 토픽에는 많은 구독자가 있으며 각 구독자는 SNS 토픽에서 해당 메시지를 수신하고 이를 보관할 수 있다. SNS에서 "이벤트 프로듀서"는 한 SNS 토픽에만 메시지를 보낸다. SNS 토픽 구독자는 해당 토픽으로 전송된 메시지를 모두 받게 된다. 그리고 메시지를 필터링하는 기능을 사용하는 경우에도 메시지를 받을 수 있다. 토픽 별로 최대 1,200만 이상의 구독자까지 가능하다. (추후 변경 가능) 계정당 가질 수 있는 토픽 수는 최대 10만 개다. (추후 변경 가능) SNS에서 직접 이메일을 보낼 수도 있고 SMS 및 모바일 알림을 보낼 수도 있다. 또한 지정된 HTTP 또는 HTTPS 엔드 포인트로 직접 데이터를 보낼 수도 있다. SNS는 SQS와 같은 특정 AWS 서비스와 통합하여 메시지를 큐로 직접 보낼 수도 있고 메시지를 수신한 후 함수가 코드를 수행하도록 Lambda에 보내거나 Firehose를 통해 데이터를 Amazon S3나 Redshift로 보낼 수 있다. SNS는 다양한 AWS 서비스에서 데이터를 수신할 수 있다. CloudWatch 경보 Auto Scaling 그룹 알림, CloudFormation State Changes Budgets, S3 버킷, DMS, Lambda, DynamoDB RDS 이벤트 등이 있다. AWS에서 알림이 발생하면 이러한 서비스가 지정된 SNS 토픽으로 알림을 보낸다. 구독자에게 메시지를 push 하는 부분이 중요하다. 완전 관리형 서비스다.

메시지 발행 방법

SDK Topic Publish를 사용해 SNS에 메시지를 게시할 수 있다. 먼저 토픽을 만든 다음 하나 또는 여러 개의 구독을 만들고 SNS 토픽에 게시하면 된다. 그럼 모든 구독자가 자동으로 해당 메시지를 받는다. 혹은 모바일 앱 SDK 전용 직접 게시 방법이 있다. 플랫폼 애플리케이션을 만든 다음 플랫폼 엔드 포인트를 만들고 플랫폼 엔드 포인트에 게시하면 된다. 수신 가능 대상은 Google, GCM, Apple APNS 또는 Amazon ADM 구독자다. 모두 모바일 애플리케이션으로 알림을 수신한다.

Security

기본적으로 전송 중 암호화와 KMS 키를 사용한 저장 데이터 암호화가 있고 클라이언트가 SNS에 암호화된 메시지를 보내려는 경우를 위한 클라이언트 측 암호화가 있다. 액세스 제어는 IAM 정책 중심이다. 모든 SNS API가 IAM 정책으로 규제되기 때문이다. S3 버킷 정책과 매우 유사한 SNS 액세스 정책을 정의할 수 있다. SNS 토픽에 교차 계정 액세스 권한을 갖거나 S3 이벤트와 같은 서비스가 SNS 토픽에 작성할 수 있도록 허용하려는 경우 유용하다.

SNS + SQS Fan Out

SNS 토픽에 메시지를 전송한 후 다수의 SQS 큐가 이 SNS 토픽을 구독하게 해보자. 다수의 Queue는 구독자로서 SNS로 들어오는 모든 메시지를 받는다. 이는 완전히 분리된 모델이며 데이터도 손실되지 않는다. SQS로 작업을 다시 시도할 수 있을 뿐 아니라 데이터 지속성, 지연 처리도 수행할 수 있다. 게다가 이런 방식으로 SNS 토픽을 구독하도록 더 많은 SQS 큐를 추가할 수도 있다. 이를 위해서는 앞서 살펴봤듯이 SQS 액세스 정책에서 SNS 토픽이 SQS 큐에 쓰기 작업을 할 수 있도록 허용해야 한다. 리전 간 전달도 가능하다. 즉 보안상 가능하다면 한 리전의 SNS 토픽에서 다른 리전의 SQS 큐로 메시지를 보낼 수 있다.

FIFO Topic

Amazon SNS에는 토픽의 메시지 순서를 지정하는 FIFO, 즉 선입 선출 기능이 있다. 여기에서 프로듀서가 메시지 1, 2, 3, 4를 보내고 구독자는 1, 2, 3, 4의 순서로 메시지를 수신하는 SQS FIFO 큐가 된다. 이 SNS FIFO는 SQS FIFO와 유사하다. 메시지 그룹 ID에 따라 순서를 매기고 중복 제거 ID를 활용하거나 내용을 비교하여 중복 데이터를 제거하며 SQS FIFO 큐를 FIFO SNS 토픽의 구독자로 설정한다. 처리량은 제한적이며 SQS FIFO 대기열과 동일하다. SQS FIFO 큐만 SNS FIFO 토픽을 읽어 들일 수 있기 때문이다.

SNS FIFO + SQS FIFO + Fan Out

SQS FIFO를 활용하여 팬아웃을 수행하려면 팬아웃, 순서, 중복 제거가 필요하다.

Message Filtering

팬아웃 패턴과 관련한 SNS의 기능은 SNS에서 메시지 필터링을 할 수 있다는 것이다. SNS 토픽을 구독할 때 전송되는 메시지를 필터링하는 데 사용되는 JSON 정책이다. 토픽에 어떤 필터링 정책도 없다면 모든 메시지를 받아들이며 이것이 기본 동작이다. 필터링 정책과 SQS 큐도 만들 수 있고 아무 필터링 정책 없이 SNS 토픽에 있는 모든 메시지를 받는 SQS 큐도 만들 수 있다.

Kinesis

Kinesis를 활용하면 실시간 스트리밍 데이터를 손쉽게 수집하고 처리하여 분석할 수 있다. 실시간 데이터에는 애플리케이션 로그, 계측, 웹 사이트 클릭 스트림, IoT 원격 측정 데이터 등 다양하다. 데이터가 빠르게 실시간으로 생성된다면 모두 실시간 데이터 스트림으로 간주할 수 있다. Kinesis는 네 가지 서비스로 구성되어 있다. Kinesis Data Stream에서는 데이터 스트림을 수집하여 처리하고 저장한다. Kinesis Data Firehose에서는 데이터 스트림을 AWS 내부나 외부의 데이터 저장소로 읽어 들인다. Kinesis Data Analytics에서는 SQL 언어나 Apache Flink를 활용하여 데이터 스트림을 분석한다. 시험에는 나오지 않지만 Kinesis Video Stream에서는 비디오 스트림을 수집하고 처리하여 저장한다.

Kinesis Data Stream

시스템에서 큰 규모의 데이터 흐름을 다루는 서비스다. Kinesis Data Stream은 여러 개의 샤드로 구성되어 있고 이 샤드는 1번, 2번에서 N번까지 번호가 매겨진다. 이건 사전에 우리가 프로비저닝해야 한다. 예를 들어 Kinesis Data Stream을 시작할 때 스트림을 여섯 개 샤드로 구성하겠다고 결정해야 한다는 의미다. 데이터는 모든 샤드에 분배된다. 샤드는 데이터 수집률이나 소비율 측면에서 스트림의 용량을 결정한다. 프로듀서는 데이터를 Kinesis Data Stream으로 보낸다. 컨슈머는 다양하다. 애플리케이션일 수도 있고 데스크톱이나 휴대전화와 같은 클라이언트일 수도 있고 매우 낮은 수준에서 AWS SDK를 활용하거나 더 높은 수준에서 Kinesis Producer Library (KPL)을 활용하기도 한다. Kinesis Agent를 활용해서 스트리밍할 서버, 예를 들면 Kinesis 스트림에서 애플리케이션 로그를 처리할 수도 있다. 프로듀서는 모두 동일한 역할을 한다. 매우 낮은 수준에서 SDK에 의존하며 Kinesis Data Stream에 레코드를 전달한다. 레코드는 근본적으로 두 가지 요소로 구성됩니다. 파티션 키와 최대 1MB 크기의 데이터 블롭으로 구성된다. 파티션 키는 레코드가 이용할 샤드를 결정하는 데 사용되고 데이터 블롭은 값 자체를 의미한다. 프로듀서는 데이터를 스트림으로 보낼 때 초당 1MB를 전송하거나 샤드당 1초에 천 개의 메시지를 전송할 수 있다. 데이터가 스트림에 들어가면 많은 컨슈머가 이 데이터를 사용한다. 컨슈머는 다양하다. SDK에 의존하거나 높은 수준에서는 Kinesis Client Library, KCL에 의존하는 애플리케이션이 있다. Kinesis 스트림에서 서버리스로 처리하려는 경우 Lambda 함수도 가능하다. Kinesis Data Firehose도 있고 Kinesis Data Analytics도 있다. 컨슈머가 레코드를 받으면 여기에는 파티션 키, 샤드에서 레코드의 위치를 나타내는 시퀀스 번호, 데이터 자체를 의미하는 데이터 블롭이 있다. Kinesis Data Stream에는 여러 소비 유형이 존재한다. 샤드마다 초당 2MB의 처리량을 모든 컨슈머가 공유할 수 있다. 아니면 컨슈머마다 샤드당 1초에 2MB씩 받을 수도 있다. 효율성을 높인 소비 유형, 즉 효율성을 높인 팬아웃 방식 정리하면 프로듀서가 Kinesis Data Stream에 데이터를 전송하고 데이터는 잠시 거기에 머물면서 여러 컨슈머에게 읽힌다.

특징

보존 기간은 1일에서 365일 사이로 설정할 수 있다. 즉, 데이터를 다시 처리하거나 확인할 수 있다. 데이터가 일단 Kinesis로 들어오면 삭제할 수 없으며 이러한 특징을 불변성이라고 한다. 또한 데이터 스트림으로 메시지를 전송하면 파티션 키가 추가되고 파티션 키가 같은 메시지들은 같은 샤드로 들어가게 되어 키를 기반으로 데이터를 정렬할 수 있다. 프로듀서는 SDK, Kinesis Producer Library (KPL), Kinesis Agent를 사용하여 데이터를 전송할 수 있고 컨슈머는 Kinesis Client Library (KCL)나 SDK를 써서 직접 데이터를 작성할 수 있다. 아니면 AWS에서 관리하는 Lambda나 Kinesis Data Firehose, Kinesis Data Analytics를 활용할 수도 있다.

Capacity Modes

Kinesis Data Stream에는 두 가지 용량 유형이 있다. 먼저 전통적인 용량 유형으로 프로비저닝 유형이 있다. 여기에서는 프로비저닝할 샤드 수를 정하고 API를 활용하거나 수동으로 조정한다. Kinesis Data Stream에 있는 각 샤드는 초당 1MB나 1천 개의 레코드를 받아들이고 출력량의 경우에는 각 샤드가 초당 2MB를 받아들인다. 이는 일반적인 소비 유형이나 효율성을 높인 팬아웃 방식에 적용할 수 있다. 다만 샤드를 프로비저닝할 때마다 시간당 비용이 부과되므로 사전에 심사숙고해야 한다. 두 번째는 온디맨드 유형이다. 여기에서는 프로비저닝을 하거나 용량을 관리할 필요가 없다. 시간에 따라 언제든 용량이 조정된다. 기본적으로는 초당 4MB 또는 초당 4천 개의 레코드를 처리하지만 이 용량은 지난 30일 동안 관측한 최대 처리량에 기반하여 자동으로 조정된다. 이 유형에서는 시간당 스트림당 송수신 데이터양(GB 단위)에 따라 비용이 부과된다. 두 유형은 비용 산정 방식이 다르다. 어쨌든 사전에 사용량을 예측할 수 없다면 온디맨드 유형을 선택하자. 하지만 사전에 사용량을 계획할 수 있다면 프로비저닝 유형을 선택하자.

보안

IAM 정책을 사용하여 샤드를 생성하거나 샤드에서 읽어 들이는 접근 권한을 제어할 수 있다. HTTPS로 전송 중 데이터를 암호화할 수 있으며 미사용 데이터는 CMS로 암호화할 수 있다. 클라이언트 측에서 데이터를 암호화하거나 해독할 수 있으며 이를 클라이언트 측 암호화라고 한다. 이는 직접 데이터를 암호화하고 해독해야 하기 때문에 수행하기 더 어렵다. 하지만 그만큼 보안이 더 강화된다. Kinesis에서 VPC 엔드포인트를 사용할 수 있다. 이를 이용하면 Kinesis에 인터넷을 거치지 않고 프라이빗 서브넷의 인스턴스에서 직접 손쉽게 접근할 수 있다. 마지막으로 모든 API 요청은 CloudTrail로 감시할 수 있다.

Data Firehose

프로듀서에서 데이터를 가져올 수 있는 유용한 서비스이며, 프로듀서는 Kinesis Data Stream에서 본 무엇이든 될 수 있다. 즉, 애플리케이션, 클라이언트, SDK, KPL, Kinesis Agent 모두 Kinesis Data Firehose로 생산할 수 있다. Kinesis Data Stream과 아마존 CloudWatch (로그 및 이벤트) 그리고 AWS IoT도 Kinesis Data Firehose로 생산할 수 있다. 이 모든 애플리케이션이 Kinesis Data Firehose로 데이터를 전송하면 Kinesis Data Firehose는 람다 기능을 활용해 데이터를 변환할지 선택할 수 있는데 이는 옵션이다. 일단 데이터를 변환하면 배치로 수신처에 쓸 수 있다. Kinesis Data Firehose는 소스에서 데이터를 가져오는데 주로 Kinesis Data Stream이다. 그리고 수신처에 데이터를 쓸 수 있다. 이때 Kinesis Data Firehose가 데이터 쓰는 법을 알기 때문에 별도로 코드를 쓸 필요가 없다. Kinesis Data Firehose의 수신처는 세 종류가 있다. 첫 번째 범주는 AWS 수신처다. (매우 중요) S3가 있다. 모든 데이터를 아마존 S3에 쓸 수 있다. 데이터 웨어하우스인 아마존 레드시프트도 있는데, 여기에 데이터를 쓸 때는 아마존 S3에 데이터를 쓰면 Kinesis Data Firehose가 복사 명령어를 내보낸다. 이 복사 명령어가 아마존 S3의 데이터를 아마존 레드시프트로 복사하는 것이다. AWS 범주의 마지막 수신처는 아마존 ElasticSearch다. 써드 파티 파트너 수신처도 있다. 데이터독, 스플렁크, 뉴렐릭, 몽고DB 다양한 수신처로 Kinesis Data Firehose가 데이터를 전송할 수 있다. 마지막으로, 만약 HTTP 엔드포인트가 있는 자체 API를 보유하고 있다면 Kinesis Data Firehose를 통해 커스텀 수신처로 데이터를 보낼 수 있다. 데이터가 이러한 수신처로 전송되고 나면 우리에게는 두 가지 옵션이 있다. 모든 데이터를 백업으로 S3 버킷에 보내거나, 혹은 수신처에 쓰이지 못한 데이터를 실패 S3 버킷에 보낼 수도 있다. Kinesis Data Firehose는 완전 관리형 서비스다. 관리가 필요하지 않으며, 자동으로 용량 크기가 조정되고, 서버리스이므로 관리할 서버가 없다. Kinesis Data Firehose를 통하는 데이터에 대해서만 비용을 지불하면 되므로 아주 효율적이다. 근 실시간으로 이루어집니다. 왜 근 실시간이냐면 Kinesis Data Firehose에서 수신처로 데이터를 배치로 쓰기 때문이다. 전체 배치가 아닌 경우 최소 60초의 지연시간이 발생하거나, 데이터를 수신처에 보내는 데 한 번에 적어도 1MB의 데이터가 있을 때까지 기다려야 한다. 그러므로 실시간 서비스가 아니라 실시간에 가까운 서비스다.

Kinesis Data Stream VS Kinesis Data Firehose

시험에 Kinesis Data Stream을 사용할 경우, Kinesis Data Firehose를 사용해야 하는 경우를 구분해야 하는 문제가 나온다. Kinesis Data Stream은 데이터를 대규모로 수집할 때 쓰는 스트리밍 서비스고, 프로듀서와 컨슈머에 대해 커스텀 코드를 쓸 수 있다. 실시간으로 이루어지며약 70ms 혹은 200ms 정도의 지연시간이 발생한다. 용량을 직접 조정할 수 있어 샤드 분할이나 샤드 병합을 통해 용량이나 처리량을 늘릴 수 있다. 제공한 용량만큼 비용을 지불하면 되며, 데이터는 1일에서 365일간 저장된다. 덕분에 여러 소비자가 같은 스트림에서 읽어 올 수 있고, 반복 기능도 지원된다. Kinesis Data Firehose도 수집 서비스로 데이터를 아마존 S3나 레드시프트, ElasticSearch 써드 파티 파트너나 자체 HTTP로 스트리밍해준다. 완전 관리되며, 서버리스이고, 근 실시간으로 이루어진다. 자동으로 용량 조정되어 관련해 걱정할 필요 없고, Kinesis Data Firehose를 통과하는 데이터에 대해서만 비용을 지불하면 된다. 데이터 스토리지가 없어 Kinesis Data Firehose의 데이터를 반복하는 기능은 지원되지 않는다.

Kinesis의 SQS FIFO에 대한 데이터 정렬

SQS FIFO는 그룹 ID 숫자에 따른 동적 소비자 수를 원할 때 사용하면 좋은 모델이다. Kinesis 데이터 스트림을 사용할 경우는 예를 들어 트럭 10,000대가 많은 데이터를 전송하고 또 Kinesis 데이터 스트림에 샤드당 데이터를 정렬할 때다.

Amazon MQ

MQTT, AMQP 등과 같은 기존에 쓰던 프로토콜을 사용하고 싶을 수 있는데 이때 Amazon MQ를 쓴다. RabbitMQ와 ActiveMQ 두 가지 기술을 위한 관리형 메시지 브로커 서비스다. RabbitMQ와 ActiveMQ는 온프레미스 기술로 앞서 설명했던 개방형 프로토콜 액세스를 제공한다. Amazon MQ를 이용하면 해당 브로커의 관리형 버전을 클라우드에서 사용할 수 있다. 먼저 Amazon MQ는 무한 확장이 가능한 SQS나 SNS처럼 확장성이 크지는 않다. Amazon MQ는 서버에서 실행되므로 서버 문제가 있을 수 있다. 고가용성을 위해 장애 조치와 함께 다중 AZ 설정을 실행할 수 있다. Amazon MQ는 SQS처럼 보이는 큐 기능과 SNS처럼 보이는 토픽 기능을 단일 브로커의 일부로 제공한다. Amazon MQ의 고가용성은 어떨까요? us-east-1라는 리전에 us-east-1a와 us-east-1b 두 개의 가용 영역이 있다고 가정해보자. 영역 하나는 활성 상태 그리고 또 다른 영역은 대기 상태다. 이제 두 영역에 각각 활성, 대기 상태인 Amazon MQ 브로커를 추가한다. 장애 조치 실행을 위해 백엔드 스토리지에 Amazon EFS도 정의해야 한다. EFS는 네트워크 파일 시스템으로 다중 가용 영역에 마운트할 수 있다. 이렇게 설정하면 장애 조치가 일어날 때마다 대기 상태 영역 역시 Amazon EFS에 마운트되므로 첫 번째 활성 큐와 동일한 데이터를 가질 수 있고 따라서 장애 조치도 올바르게 실행된다. 클라이언트가 Amazon MQ 브로커와 통신해서 장애 조치가 실행되는 경우에도 Amazon EFS 덕분에 데이터가 저장된다.

• SnowFamily는 아주 안전한 휴대 기기를 가리킨다.
• AWS 내에서 두 가지 활용 사례가 있다.
  • 엣지에서 데이터를 수집하고 처리하기 위해 사용 (Snowcone, Snowball Edge)
  • WS 안팎으로 데이터를 마이그레이션할 때 (Snowcore, Snowball Edge, Snowmobile)

Snow Family를 사용한 데이터 마이그레이션

AWS Snow Family를 이용한 마이그레이션 이유

• 대용량의 데이터를 네트워크를 경유해 전송하려면 많은 시간이 걸린다.
• AWS에 빠르게 접속해야 할 때가 있는데 그런 경우에 생기는 문제점은 전송 가능한 데이터의 양이 적다는 것과 제한된 연결 및 제한된 대역폭 문제와 네트워크를 통한 데이터 전송으로 비용이 발생한다는 것이다.
• 대역폭 문제도 존재한다. AWS에서 영상을 다운로드하는데 그 데이터 크기가 10TB라면 사무실 전체가 차단된다.
• 이런 이유로 인해 Snow Family가 사용된다.
• Snow Family는 오프라인에서 데이터 마이그레이션을 실행하는 장치다.
• AWS가 우편으로 물리적 장치를 보내주면 거기에 데이터를 끌어오고 다시 AWS로 전송하는 것
• 일반적으로 데이터 전송 시 네트워크를 사용할 경우 일주일이 넘는 시간이 걸린다면 Snowball 장치를 사용해야 한다.

Snowball Edge

• TB(테라바이트) 혹은 PB(페타바이트) 용량의 데이터를 AWS와 교환하기 위해 사용한다.
• 네트워크를 대신해서 데이터를 옮길 수 있고, 데이터 전송 건마다 비용이 청구된다.
• Snowball Edge 인터페이스는 블록 스토리지를 제공하거나 Amazon S3 호환 객체 스토리지를 제공한다.
• Snowball Edge에는 두 가지 형태가 존재한다.
  • 1. 스토리지가 최적화된 형태(Snowball Edge Storage Optimized)는 블록 볼륨으로 사용할 수 있도록 80TB의 하드웨어 디스크 용량을 제공하거나 S3 호환 객체 스토리지를 제공한다.
  • 2. 컴퓨팅에 최적화된 형태(Snowball Edge Compute Optimized)는 42TB의 HDD 용량을 제공한다.
  • 그래서 더 큰 스토리지가 필요할 때 사용할 옵션은 Snowball Edge Storage Optimized다.
• Snowball Edge를 데이터 전송에 쓰는 경우는 데이터 센터 폐쇄를 위한 대량의 데이터 클라우드 마이그레이션이나 AWS에 데이터를 백업함으로써 재해 복구를 하는 경우다.

Snowcone

• 아주 작은 휴대 기기이다. 견고하고 안전하다. 약2.1kg
• 엣지 컴퓨팅, 스토리지 및 데이터 전송에 사용되는데 용량이 작을 경우 사용한다.
• Snowcone에는 두 가지 형태가 존재한다.
  • 1. 8TB의 HDD 스토리지가 장착된 Snowcone
  • 2. 14TB의 SSD가 장착된 Snowcone
  • Snowball Edge Storage Optimized와 비교하면 10배는 적은 용량이다.
• Snowball 사용이 불가능할 때 Snowcone을 쓸 수 있다.
  • 예를 들면 공간의 제약을 받는 환경이다.
  • 이러한 경우에는 AWS DataSync 서비스를 사용해서 데이터를 다시 AWS에 전송한다.
• 데이터를 AWS에 보내는 방법은 두가지가 존재한다.
  • 1. 오프라인으로 데이터를 발송하는 방법
  • 2. 네트워크에 연결해서 AWS DataSync를 사용해 데이터를 재전송할 수 있다.

Snowmobile

• 실제 트럭으로, Snowmobile가 전송하는 데이터는 EB(엑사바이트)에 달한다.
• 각 Snowmobile의 용량은 100PB이다.
• 보안성이 뛰어나고 온도 조절이 가능하며 GPS 추적 및 연중무휴 비디오 감시로 굉장히 안전한 데이터 전송 방법
• 10PB 이상의 데이터를 전송하려면 Snowball보다 좋은 방법이라고 할 수 있다.

제품군 비교

• Snowcone, Snowball Edge, Snowmobile이 있고 각각의 스토리지 용량이 서로 다릅니다. (8TB, 80TB, 100 PB)
• AWS에서 권장하는 마이그레이션 크기는 Snowcone이 24TB까지 Snowball Edge는 PB까지다.
• AWS로 오프라인 재전송도 가능하다.
• Snowmobile의 경우 최대 EB 데이터까지 전송 가능하다.
• Snowcone에는 DataSync가 미리 설치되어 있어서 DataSync는 네트워크 연결을 통해 AWS에도 데이터를 전송할 수 있다.
• Snowball Edge에서는 스토리지 클러스터링으로 Snowball Edge 15개를 함께 구축하면 스토리지 크기를 늘릴 수도 있다.

Snow Family 기기 사용 방법

• 콘솔을 위해 배송을 요청
• Snowball 클라이언트나 AWS OpsHub를 서버에 설치
• Snowball을 서버에 연결하고 클라이언트를 사용해서 파일을 복사
• 준비가 끝나서 장치를 다시 보내면 올바른 AWS 시설로 바로 옮겨진다. E 잉크 마커 덕분
• 그리고 S3 버킷에 해당 데이터를 불러들이고 나면 가장 높은 보안 조치에 따라 Snowball은 전부 지워진다.
• 이것이 데이터 마이그레이션인데 Snowball 장치의 유일한 사용 사례

Snow Family를 사용한 엣지 컴퓨팅

• 엣지 컴퓨팅은 데이터가 엣지 로케이션에서 생성될 때 실시간으로 처리하는 방식을 뜻한다.
• 엣지 로케이션이란
  • 연결이 제한되어 있거나 인터넷 액세스가 없거나 컴퓨팅을 할 수 없는 곳
  • 도로 위의 트럭, 바다에 있는 배, 지하에 있는 광산 등
• 이런 장소에서 컴퓨팅이나 데이터 처리를 해야 할 경우 바로 엣지 컴퓨팅이 필요하다.
• 따라서 Snowball Edge나 Snowcone을 주문해서 엣지 로케이션에 장착시키면 엣지 컴퓨팅을 시작할 수 있게 된다.
• 엣지 컴퓨팅의 활용 사례를 들면 데이터 전처리, 또는 클라우드로 보내지 않고 엣지에서 머신 러닝, 사전 미디어 스트림 트랜스코딩 등이 있으며, 최종적으로는 데이터를 AWS로 재전송해야 하는 경우 Snowcone이나 Snowball Edge 장치를 보내면 된다.
• 다시 말해 데이터가 생성되는 곳의 아주 가까이에서 그 데이터를 처리하고, AWS로 보내는 것이다.

Snowcone

• 2 CPUS, 4GB메모리, 유무선 엑세스 Wi-Fi
• USB-C 혹은 선택적 배터리로 작동

Snowball Edge (Compute Optimized)

• 52개의 vCPU를 가지며 200GB의 RAM과 더불어 선택적 GPU가 있다.
• 영상 처리나 머신 러닝을 할 경우
• 그리고 사용 가능한 스토리지는 42TB

Snowball Edge (Storage Optimized)

• 더 적은 40개 vCPU와 80GB RAM을 가진다.
• 여기서는 객체 스토리지 클러스터링을 할 수 있다.

모든 Snocone 기기들은 EC2 인스턴스나 람다 함수를 실행할 수 있다. 람다 함수를 위해 AWS Iot Greengrass라는 서비스를 통해서 가능하다. 장기 배포 옵션을 선택할 수 있는데, 가령 1~3년 빌리면 가격 할인을 받을 수 있다.

OpsHub

• 예전에는 위 장치를 사용할 때 CLI, 즉 명령줄 인터페이스 도구를 써서 처리했으며 방식도 매우 어려웠다.
  • 그래서 OpsHub이 등장했다.
• 컴퓨터에 다운로드하여 사용해야만 한다.
• 그리고 연결이 되면 그래픽 인터페이스를 통해 Snow 장치에 연결해서 구성 및 사용할 수 있으니 아주 쉽다.
• 이것으로 단일 장치와 클러스터 장치를 잠금 해제하고 구성할 수 있으며 파일 전송이 가능해지고 Snow 장치에서 실행되는 EC2 인스턴스를 시작 및 관리할 수 있게 된다.
• 또한 장치 메트릭 모니터링과 AWS 호환 서비스 실행이 가능하다. (EC2 인스턴스, DataSync 혹은 네트워크 파일 시스템 등)

Snowball에서 Glacier까지

• Snowball은 Glacier에 데이터를 직접 끌어올 순 없다.
• 그렇게 하려면 먼저 Amazon S3를 사용해서 수명 주기 정책을 생성하여 Amazon Glacier로 객체를 전환해야 한다.
• Snowball이 데이터를 Amazon S3로 가져오면 S3의 수명 주기 정책을 통해 해당 데이터가 Amazon Glacier로 전환된다.

Amazon FSx

• AWS에서 완전 관리형 서비스로 타사 고성능 파일 시스템을 실행한다.
• RDS에서 AWS에 MySQL나 Postgres를 실행하는 것과 같은 개념이다.
• RDS가 FSx로 바뀌었고 파일 시스템을 실행한다는 점이 다르다.

FSx for Windows File Server

• 완전 관리형 Windows 파일 서버 공유 드라이브로 Windows를 사용하기 때문에 SMB 프로토콜과 Windows NTFS를 지원한다.
• Microsoft Active Directory 통합을 지원하므로 사용자 보안을 추가할 수 있고 ACL로 사용자 할당량을 추가해 액세스를 제어할 수 있다.
• FSx for Windows File Server의 특징으로는 겉보기에는 Windows에서만 사용할 수 있는 것 같지만 Linux EC2 인스턴스에도 마운트할 수 있다.
• 기존에 온프레미스 등에 Windows 파일 서버가 있는 경우 Microsoft 분산 파일 시스템인 DFS 기능을 이용해서 파일 시스템을 그룹화할 수 있다.
• 성능 면에서는 초당 수십 GB에 수백만 IOPS 그리고 수백 PB의 데이터까지 확장될 수 있으며 FSx for Windows File Server의 스토리지 옵션으로는 SSD로 지연 시간이 짧아야 하는 워크로드를 저장할 수 있다. 데이터베이스, 미디어 처리 데이터 분석 등이 들어간다.
• 혹은 더 비용이 싼 HDD로 넓은 스펙트럼의 워크로드를 저장할 수 있다. 홈 디렉터리나 CMS를 예시로 들 수 있다.
• FSx for Windows File Server는 프라이빗 연결로 온프레미스 인프라에서 액세스할 수 있다.
• 고가용성 다중 AZ에 대해 FSx for Windows File Server를 구성할 수 있다.
• 모든 데이터는 재해 복구 목적으로 Amazon S3에 매일 백업된다.

Fsx for Lustre

• Lustre는 원래 분산 파일 시스템으로 대형 연산에 쓰인다.
• Lustre는 Linux와 클러스터(Cluster)를 합친 단어로 머신 러닝과 HPC, 즉 고성능 연산에 쓰인다.
• 동영상 처리나 금융 모델링 전자 설계 자동화 등의 애플리케이션에서 쓰이고 확장성이 상당히 높다.
• 초당 수백 GB의 데이터에 수백만 IOPS로 확장되고 밀리초보다 짧은 지연 시간을 자랑한다.
• 스토리지 옵션은 두 가지다.
• 1. 낮은 지연 시간의 SSD나 워크로드가 많거나, 크기가 작은 무작위 파일 작업이 많으면 IOPS도 사용 가능하다.
• 2. 처리량이 많은 워크로드나 크기가 큰 시퀀스 파일 작업에는 HDD를 쓸 수 있다.
• SSD가 HDD보다 비용은 많이 나간다.
• Amazon S3와 무결절성 통합이 가능허더. 다시 말하면 FSx로 S3를 파일 시스템처럼 읽어들일 수 있다.
  • 그리고 FSx의 연산 출력값을 다시 Amazon S3에 쓸 수 있죠
• FSx for Lustre는 VPN과 직접 연결을 통해 온프레미스 서버에서 사용할 수 있다.

FSx의 파일 시스템 배포 옵션

스크래치파일 시스템

• 스크래치 파일 시스템은 임시 스토리지로 데이터가 복제되지 않는다.
• 즉 기저 서버가 오작동하면 파일이 모두 유실된다.
• 하지만 최적화로 초과 버스트를 사용할 수 있다.
• 영구 파일 시스템보다 성능을 여섯 배 높일 수 있다.
• TiB 처리량당 초당 200MB의 속도가 나온다. 아주 규모가 크다.
• 스크래치 파일 시스템은 단기 처리 데이터에 쓰이며 데이터 복제가 없어 비용을 최적화할 수 있다.
• FSx가 있으면 컴퓨팅(Compute) 인스턴스가 AZ 1과 AZ 2에 연결하는데 이때 FSx for Lustre 스크래치 파일 시스템을 사용하면 데이터의 사본이 하나만 존재한다.
• 또한 데이터 저장소에 추가로 S3 버킷을 둘 수도 있다.

영구 파일 시스템

• 영구 파일 시스템은 장기 스토리지로 동일한 가용 영역에 데이터가 복제된다.
• AZ 간은 아니라 동일한 AZ 내에서만 복제된다.
• 다시 말하면 기저 서버가 오작동했을 때 단 몇분 내에 해당 파일이 대체된다.
• 영구 파일 시스템의 예시는 이름에서 알 수 있듯 민감한 데이터 장기 처리 및 스토리지를 들 수 있다.

FSx for NetApp ONTAP

• AWS의 관리형 NetApp ONTAP 파일 시스템으로 NFS, SMB, iSCSI 프로토콜과 호환 가능하다.
• FSx for NetApp ONTAP 파일 시스템을 사용하여 온프레미스 시스템의 ONTAP이나 NAS에서 실행 중인 워크로드를 AWS로 옮길 수 있다.
• 다양한 운영 체제에서 사용 가능하다.
  • (Linux, Windows, MacOS AWS의 VMware Cloud, Workspaces, Appstream EC2, ECS, EKS)
  • 즉, 호환 가능한 폭이 아주 넓고 그리고 스토리지는 자동으로 확장 및 축소된다. (오토스케일링)
• 복제와 스냅샷 기능도 지원. 비용도 적게 들고 데이터 압축이나 데이터 중복제거도 가능하다.
• NetApp ONTAP에서 중복 파일을 찾을 수 있다.
• 아주 유용한 지정 시간 복제 기능이 있는데 새 워크로드 등을 테스트할 때 상당히 유용하다.
• 파일 시스템에서 신속히 복제가 가능하고 스테이징 파일 시스템을 둘 수 있다.

Amazon FSx for OpenZFS

• AWS의 관리형 OpenZFS 파일 시스템으로 여러 버전에서의 NFS 프로토콜과 호환이 가능하다.
• 주로 ZFS에서 실행되는 워크로드를 내부적으로 AWS로 옮길 때 사용한다.
• Linux, Mac, Windows에서 사용할 수 있다.
• 성능이 상당히 좋아서 백만 IOPS까지 확장 가능하고 지연 시간은 0.5 밀리초 이하다.
• 스냅샷, 압축을 지원하고 비용이 적지만 데이터 중복제거 기능은 없다.
• NetApp ONTAP처럼 역시 지정 시간 동시 복제 기능이 있어서 새 워크로드 테스트 시에 유용하다.

Storage Gateway

• Amazon S3는 독점 스토리지 기술로 NFS 규정 준수 파일 시스템인 EFS와는 다르다.
• AWS Storage Gateway가 S3와 여러분의 온프레미스 인프라를 이어주는 가교의 역할을 한다.
• AWS의 스토리지 클라우드 네이티브 옵션을 보면 Amazon EBS나 EC2 인스턴스 같은 블록 스토리지가 있다.
• Amazon EFS나 Amazon FSx 같은 파일 시스템도 있다.
• Amazon S3나 Amazon Glacier 같은 객체 수준 스토리지도 있다.
• AWS Storage Gateway를 이용해서 온프레미스 데이터를 클라우드로 이동시킨다.

사용사례

• 재해 복구 목적으로 온프레미스 데이터를 클라우드에 백업할 수 있다.
• 혹은 백업과 복구 목적으로 클라우드 마이그레이션, 혹은 온프레미스에서 클라우드 간 스토리지 확장을 사용할 수 있다.
• 클라우드에는 콜드 데이터를 두고 온프레미스에는 이보다 더 자주 쓰는 웜 데이터를 두는 방식
• 데이터 중 대부분을 AWS에 저장하고 파일 액세스 지연 시간을 줄이기 위해 AWS Storage Gateway를 온프레미스 캐시로 사용하는 방법도 있다.

S3 File Gateway

• S3 버킷에는 원하는 스토리지 클래스를 임의로 사용할 수 있다. (Glacier 제외 전부 가능)
• S3 버킷을 온프레미스 상의 애플리케이션 서버에 연결하려는데 이때 표준 네트워크 파일 시스템을 활용하고자 한다.
• 이를 위해 S3 파일 게이트웨이를 생성하여 애플리케이션 서버가 NFS나 SMB 프로토콜을 사용하도록 한다.
• 이 프로토콜을 통해 S3 파일 게이트웨이는 해당 요청을 HTTPS 요청으로 변환시켜 Amazon S3 버킷으로 보낸다.
• 따라서 애플리케이션 서버가 보기에는 일반적인 파일 공유 액세스로 보이나 실제로는 Amazon S3 버킷을 사용하는 셈이다.
• 이렇게 S3 객체를 온프레미스 애플리케이션 서버를 통해 가져올 수 있다.
• 해당 객체를 아카이브하고자 하는 경우 S3 버킷에 수명 주기 정책을 생성하여 S3 Glacier로 객체를 옮겨서 아카이브되도록 한다.
• 따라서 S3 파일 게이트웨이로 구성한 모든 버킷은 NFS 및 SMB 프로토콜을 이용해서 액세스할 수 있고 이 외에도 사용된 데이터는 신속한 액세스를 위해 파일 게이트웨이에 캐시로 저장된다.
• 따라서 전체 S3 버킷이 아닌 최근에 사용한 파일만 파일 게이트웨이에 있다.
• S3 버킷에서는 여러 스토리지 클래스를 지원하며 수명 주기 정책을 사용하면 S3 Glacier로도 옮길 수 있다.
• 이제 버킷에 액세스하려면 각 파일 게이트웨이마다 IAM 역할을 생성해야 한다.
• Windows 파일 시스템 네이티브인 SMB 프로토콜을 사용하는 경우에는 사용자 인증을 위해 Active Directory와 통합해야 한다.
• 이렇게 하면 S3 파일 게이트웨이에 사용자가 액세스할 때 인증을 거치며 결국 S3 버킷에 액세스할 때도 인증을 거친다고 할 수 있다.

FSx 파일 게이트웨이

Amazon FSx 파일 게이트웨이가 있는데 이는 Amazon FSx for Windows File Server에 네이티브 액세스를 제공한다. 게이트웨이를 생성하면 자주 액세스하는 데이터의 로컬 캐시를 확보할 수 있다. 즉 중요한 파일의 로컬 캐시가 회사 데이터 센터에 쌓이고 액세스 시 지연 시간을 단축시킬 수 있다. 이것이 바로 FSx for Windows File Server와 더불어서 Amazon FSx 파일 게이트웨이를 함께 사용하는 이유다. 파일 게이트웨이에서 Windows 네이티브인 SMB, NTFS Active Directory가 호환 가능하다. 따라서 그룹 파일 공유나 온프레미스를 연결할 홈 디렉터리로 사용할 수 있다.

볼륨 게이트웨이

블록 스토리지로 Amazon S3가 백업하는 iSCSI 프로토콜을 사용한다. 볼륨이 EBS 스냅샷으로 저장되어 필요에 따라 온프레미스 볼륨을 복구할 수 있다. 볼륨 게이트웨이에는 두 가지 유형이 있는데 하나는 캐시 볼륨으로 최근 데이터 액세스 시 지연 시간이 낮다. 다른 하나는 저장 볼륨으로 전체 데이터 세트가 온프레미스에 있으며 주기적 Amazon S3 백업된다. 이렇게 애플리케이션 서버 백업이 필요한 경우 iSCSI 프로토콜로 볼륨 게이트웨이를 생성하고 이 볼륨 게이트웨이가 Amazon S3에 저장되는 Amazon EBS 스냅샷을 생성한다. 볼륨 게이트웨이도 온프레미스 서버에 볼륨을 백업하는 것이 중요하다.

테이프 게이트웨이

테이프 게이트웨이로는 물리적으로 테이프를 사용하는 백업 시스템이 있는 회사가 백업에 테이프 대신에 클라우드를 활용해 데이터를 백업할 수 있게 해준다. 가상 테이프 라이브러리(VTL)는 Amazon S3와 Glacier를 이용한다. 테이프 기반 프로세스의 기존 백업 데이터를 iSCSI 인터페이스를 사용하여 백업한다. 업계를 선도하는 백업 소프트웨어 벤더가 사용하는 서비스다. 테이프 기반인 회사 데이터 센터의 백업 서버가 있을 때 테이프 게이트웨이가 이를 클라우드에 연결하여 Amazon S3나 Amazon Glacier에 해당 테이프를 저장하는 방식이다.

Hardware appliance

게이트웨이는 우리의 회사 데이터 센터에 설치되어야한다. 회사 데이터 센터 내에서 운영해야 한다. 하지만 종종 게이트웨이를 실행할 가상 서버가 없는 경우가 있다. 이 경우 AWS의 하드웨어를 사용할 수 있다. 이 서비스를 Storage Gateway 하드웨어 어플라이언스라고 하며 온프레미스에 서버가 없는 경우 Storage Gateway 하드웨어 어플라이언스를 사용할 수 있는데 amazon.com에서 주문할 수 있다. 미니 서버가 될 하드웨어 어플라이언스를 여러분의 인프라에 설치한 후 파일 게이트웨이, 볼륨 게이트웨이 혹은 테이프 게이트웨이로 설정하면 된다. 물리적으로 설치해야 하는데 제대로 작동하려면 충분한 CPU, 메모리 네트워크, 그리고 SSD 캐시 리소스가 필요하다. 소규모 데이터 센터의 일일 NFS 백업처럼 가상화가 없는 경우 상당히 유용하다.

AWS Transfer Family

Amazon S3 또는 EFS의 안팎으로 데이터를 전송하려고 하는데 오직 FTP만 사용할 때 AWS Transfer Family을 사용한다. 우선 FTP(파일 전송 프로토콜)의 AWS 전송을 지원한다. 참고로 FTP는 암호화되지 않는 반면에 FTPS와 SFTP는 전송 중에 암호화된다. FTP 프로토콜을 사용해서 S3 혹은 EFS에 업로드할 수 있다. 전송 제품군은 완전 관리형 인프라이며 확장성, 안정성이 높고 가용성 또한 높다. 시간당 프로비저닝된 엔드 포인트 비용에 전송 제품군 안팎으로 전송된 데이터의 GB당 요금을 더한다. 또 서비스 내에서 사용자 자격 증명을 저장 및 관리할 수도 있다. 다음과 같은 기존의 인증 시스템과 통합할 수도 있다. (Microsoft Active Directory, LDAP Okta, Amazon Cognito, 사용자 지정 소스) 사용 사례는 물론 Amazon S3나 EFS의 FTP 인터페이스를 갖기 위해서다. 파일 공유 및 공개 데이터셋 공유를 위해 그리고 CRM, ERP 등을 하기 위해서다. 사용자는 FTP의 엔드 포인트를 통해 직접 액세스하거나 선택적으로 Route 53라는 이름의 DNS를 사용하여 FTP 서비스에 고유의 호스트 이름을 제공할 수 있다. 그리고 FTP 서비스의 전송에는 IAM 역할이 있어서 Amazon S3나 Amazon EFS의 파일을 보내거나 읽도록 한다. AWS Transfer Family의 보안을 위해 외부 인증 시스템을 통해서 사용자를 인증할 수 있는데 는 Active Directory, LDAP 등이 있다.

Data Sync

Data Sync는 데이터를 동기화하며 대용량의 데이터를 한 곳에서 다른 곳으로 옮길 수 있다. 온프레미스나 AWS의 다른 클라우드로 데이터를 옮길 수 있는데 이때 서버를 NFS, SMB HDFS 또는 다른 프로토콜에 연결해야 하고 옮길 위치인 온프레미스나 연결할 다른 클라우드에 에이전트가 있어야 한다. 모든 Amazon S3의 Glacier를 포함하여 모든 스토리지 클래스에 동기화할 수 있다. Amazon EFS로 네트워크 파일 시스템에 저장할 수도 있다. Amazon FSx는 다양한 운영 체제에서 사용 가능하다. (Windows, Lustre, NetApp, OpenZFS) 복제 작업은 계속 이루어지지 않고 일정을 지정하여 DataSync가 매 시간, 매일, 혹은 매주 실행되도록 할 수 있다. 지연이 발생하긴 하지만 일정에 맞춰서 데이터가 동기화된다. DataSync에는 파일 권한과 메타데이터 저장 기능이 있다. 보안과 관련되어 NFS POSIX 파일 시스템 그리고 SMB 권한을 준수한다. 파일을 한 곳에서 다른 곳으로 옮길 때 이를 이용하여 파일의 메타데이터를 보존할 수 있다. (시험에서 중요) DataSync 에이전트 하나의 태스크가 초당 10Gb까지 사용할 수 있으며 네트워크 성능을 초과하고 싶지 않은 경우 대역폭에 제한을 걸 수 있다. 가끔 시험에서 DataSync를 이용하고자 하지만 네트워크 용량이 따라 주지 못하는 경우가 나온다. 이때 AWS Snowcone 장치를 사용할 수 있다. Snowcone 장치에는 DataSync 에이전트가 사전에 설치되어 있다. 온프레미스에서 Snowcone을 실행하고 데이터를 가져온 다음 DataSync 에이전트를 실행하면 다시 에이전트가 AWS 리전으로 전송되면서 AWS의 스토리지 리소스 외부에 데이터를 동기화할 수 있다. DataSync 에이전트를 이용하여 다른 클라우드에서 동기화할 때도 같다. DataSync를 통해 서로 다른 AWS 스토리지 서비스 간 동기화도 가능하다. Amazon S3, Amazon EFS 또는 Amazon FSx를 Amazon S3, Amazon EFS Amazon FSx로 다시 동기화하려는 경우 AWS DataSync 서비스를 사용하여 데이터 복사본을 만든다. 서로 다른 AWS 스토리지 서비스 간 메타데이터 또한 유지된다. (시험에서 중요) DataSync로 거의 대부분의 데이터를 동기화할 수 있으나 지속적이지는 않고 일정에 따라 움직인다. 매 시간, 매일, 혹은 매주 진행할 수 있다. 메타데이터와 파일 권한은 보존된다. 끝으로 NFS 또는 SMB 서버에 연결하려면 DataSync 에이전트를 실행해야 한다.

• CloudFront란 CDN, 컨텐츠 전송 네트워크를 의미한다.
• CDN은 웹사이트의 컨텐츠를 서로 다른 엣지 로케이션에 미리 캐싱하여 읽기 성능을 높인다.
• 네트워크 전체에 캐싱되므로 전세계 사용자들이 낮은 레이턴시로 접근할 수 있어서 사용자 경험을 증대시킬 수 있다.
• 컨텐츠가 전체적으로 분산되어 있으므로 DDoS 공격에서 보호를 받을 수 있다.

CloudFront의 원본 제공 방식은 2가지

S3 사용

• 먼저 S3 버킷으로, CloudFront를 통해 파일을 분산하고 캐싱할 수 있게 한다.
• 버킷에는 CloudFront만 접근할 수 있게 보장한다.
• 이를 가능하게 하는 것이 OAC라 불리는, Origin Access Control(원본 접근 제어)로 기존의 OAI(Origin Access Identity)를 대체한다.
• CloudFront를 통해 버킷에 데이터를 보내는 방법도 가능한데, 이를 Ingress라고 한다.

Custom Origin(HTTP)

• ALB, EC2 인스턴스, S3 웹사이트가 예시
• 단 S3 웹사이트의 경우 버킷을 활성화해서 정적 웹 사이트로 설정해야 한다.
• 그 외의 다른 HTTP 백엔드도 가능하다.

CloudFront와 CRR(교차 리전 복제) 차이점

• CloudFront는 전세계의 엣지 네트워크를 이용한다.
• 216개의 엣지 로케이션에 하루 동안 파일들이 캐싱된다.
• 교차 리전 복제는 조금 다르다.
• 복제를 원하는 각 리전에 이 설정이 되어 있어야 한다. 즉 전세계를 대상으로 한 것은 아니다.
• 파일은 거의 실시간으로 갱신된다. 즉 캐싱이 되지 않고, 또한 읽기 전용으로만 설정이 가능하다.
• 이런 것은 일부 리전을 대상으로 동적 컨텐츠를 낮은 지연 시간으로 제공하고자 할 때 유용하다.
• CloudFront는 전세계에 걸친 컨텐츠 전송 네트워크라면, S3 교차 리전 복제는 다른 리전으로의 버킷 복제다.

Cloud Geo Restriction(지리적 제한 설정)

• 사용자들의 지역에 따라 배포 객체 접근을 제어할 수 있다.
• 접근이 가능한 국가 목록(Allow list)을 만들거나, 반대로 접근이 불가능한 국가 목록(Black list)을 만들어서 설정할 수 있다.
• 이 국가는 서드 파티 지역 DB에서 설정한 것으로, 사용자의 IP가 어떤 국가에 해당하는지를 확인할 수 있다.
• 사용사례는 컨텐츠 저작권법으로 인한 제한

Price Classes(가격 등급)

• CloundFront 엣지 로케이션은 전 세계에 고루 분포해 있으므로 엣지 로케이션마다 데이터 전송 비용이 다르다.
• CloudFront에서 더 많은 데이터가 전송될수록 비용은 낮아집니다
• 비용 절감을 위해 CloudFront를 분산할 엣지 로케이션 수를 줄이는 방법이 있다.
• 최상의 성능을 제공하는 Price Class All (전세계 모든 엣지 로케이션 사용)
• Price Class 200도 있.
  • 대부분의 리전을 사용할 수 있지만 가장 비싼 리전은 제외(북미와 유럽 엣지 및 일부 리전 추가)
• Price Class 100은 가장 저렴한 리전만 사용할 수 있다. (북미와 유럽 엣지)

Cache Invalidations (캐쉬 무효화)

• CloudFront에는 항상 백엔드 Origin이 있다.
• CloudFront 엣지 로케이션은 우리가 백엔드 Origin을 업데이트할 때 업데이트 사항을 모른다.
• 캐시의 TTL이 만료되면 백엔드 Origin으로부터 업데이트된 콘텐츠를 받는다.
• 우리는 전체 또는 일부의 캐시를 강제로 새로고침해서 캐시에 있는 타임 투 리브(TTL)를 모두 제거할 수 있다.
• 이를 위해 CloudFront 무효화를 실행해야 하는데, 쉽게 말해 캐쉬를 제거하는 것이다.
• 이때 특정 파일의 경로 혹은 전체 파일의 경로를 알려줘야한다.

Global Accelerator

• 글로벌 애플리케이션이다.
  • 글로벌 사용자들이 직접 접근하려고 하는데 우리 애플리케이션은 오직 한 리전에 배치되어 있다.
• 사용자들이 애플리케이션에 접근할 때는 공용 인터넷을 통하게 되는데 라우터를 거치는 동안의 수 많은 Hop으로 인해 상당한 지연이 발생할 수 있다.
  • 따라서 지연 시간을 최소화하기 위해 최대한 빨리 AWS 네트워크를 통하는 것이 좋다.
  • 이때 Global Accelerator를 사용한다.
• Global Accelerator는 애니캐스트 IP 개념을 사용한다.
• 애플리케이션을 라우팅하기 위해 AWS 내부 글로벌 네트워크를 활용한다.

유니 캐스트 & 애니캐스트

• 유니캐스트 IP: 하나의 서버가 하나의 IP 주소를 가진다.
• 애니캐스트 IP: 모든 서버가 동일한 IP 주소를 가지며, 클라이언트는 가장 가까운 서버로 라우팅된다.

Global Accelerator 동작 방식

• 공용 인터넷을 거쳐서 보내는 대신에 가장 가까운 엣지 로케이션과 통신한다.
• 엣지 로케이션으로부터 사설 AWS 네트워크를 거쳐 ALB로 곧장 연결된다.
• 애니캐스트 IP는 사용자와 가장 가까운 엣지 로케이션으로 트래픽을 직접 전송한다. 이것이 애니캐스트 IP의 장점.
  • 엣지 로케이션은 훨씬 안정적이고 지연 시간이 적은 사설 AWS 네트워크를 거쳐 애플리케이션 로드 밸런서로 트래픽을 전송한다.
• Global Accelerator는 어떤 애플리케이션에 대해서도 전 세계의 유저들에게 두 개의 고정 IP 주소를 제공할 수 있다.
  • 탄력적 IP, EC2 인스턴스, ALB, NLB (모두 공용 or사설) 등과 함께 동작한다.
• 지능형 라우팅으로 지연 시간이 가장 짧은 엣지 로케이션으로 연결되며 뭔가 잘못될 경우에는 신속한 리전 장애 조치가 이루어진다.
• 아무것도 캐시하지 않기에 클라이언트 캐시와도 문제가 없다.
• 우리가 사용하는 두 개의 애니캐스트 IP는 변하지 않는다.

헬스 체크

• Global Accelerator가 애플리케이션에 대해 상태 확인을 실행한다. 그리고 애플리케이션이 글로벌한지 확인한다.
• 한 리전에 있는 한 ALB에 대해 상태 확인을 실패하면 자동화된 장애 조치가 1분 안에 정상 엔드 포인트로 실행된다.
• 상태 확인 덕분에 재해 복구에 특히 뛰어나다.
• 클라이언트가 화이트리스트 해야 하는 단 두 개의 외부 IP만 존재하기 때문에 보안 측면에서도 매우 안전하다.
• Global Accelerator를 통해 DDoS 보호도 자동으로 받게 된다.

사내 서비스에서 URL 단축키는 여러 도메인에서 사용중에 있습니다. 이커머스 서비스 특성상 상품의 URL Shortcut이 필수로 존재해야 합니다. URL 단축에 대해 자세히 알고 싶으신 분은 가상 면접 사례로 배우는 대규모 시스템 설계 기초 8장을 참고하면 좋을 것 같습니다.

URL 리다이렉션 구조

현재 URL 리다이렉션의 메커니즘의 대략적인 구조는 아래와 같다.

1. 사용자가 단축 URL을 클릭한다.
2. Shortcut URL을 Shortcut Web Server에 전달한다.
3. Shortcut URL이 이미 캐시에 있는 경우 원래 URL을 가져와 클라이언트에게 반환한다.
4. 캐시에 Shortcut URL이 존재하지 않는 경우 DB에서 조회한다.(이때도 결과가 없으면 exception)
5. DB에서 조회한 Shortcut URL을 캐시에 write 후 클라이언트에게 반환한다.

요구사항 발생

이커머스 특성상 상품의 이름, 짧은 소개 문구, 이미지가 변경될때마다 오픈그래프 정보를 갱신해야하기에 Shortcut URL을 새로 생성하고 있습니다. 그래서 간혹 MD분들이 백오피스에서 상품 대량 변경을 수행하게되면 새로운 Shortcut을 생성, 업데이트 하는 과정에서 부하가 발생하게 되는 경우도 있었습니다.

위 과정에서 부하가 발생하는 이유는 저희 서버 구조를 대략적으로 확인해야 합니다. API 서버가 있고, Back office 서버가 따로 있습니다. 백오피스에서 숏컷과 관련된(상품명, 소개문구, 이미지) 수정 작업이 발생하면 API Server에서 Shortcut URL을 반환받고 있습니다. 이 과정에서 readTimeout 등이 발생하고 있어 결과를 반환받지 못하는 이슈도 함께 발생하고 있었죠.

오픈 그래프 정보를 수정하기 위해 Shortcut을 새로 생성하는 과정은 불필요하다고 생각되었고 이를 개선하였습니다.

개선

1. 상품 정보가 변경될 경우에는 API Server의 네트워크를 발생시키지 말자.
2. 불필요하게 새로운 shortcut을 생성하지 말자.

위 방안을 만족시키기 위해 아래의 구조로 변경

1. shortcut을 담고 있는 테이블에 json 구조를 담을 수 있는 컬럼을 추가한다.
2. 오픈 그래프 정보를 신규 컬럼에 저장한다.
3. 상품 정보 변경시 오픈 그래프 정보만 변경하여 update한다. 3-1 위 과정에서 불필요한 insert 제거, API Server 통신을 하지 않음.
4. 숏컷 서버에서 신규 컬럼에서 데이터를 가져와 오픈 그래프 정보를 생성하면 된다.

결과

ReadTimeout이 발생하는 이유로 전체적인 성능 개선 수치 측정이 어려웠다. 다만, 백오피스에서의 이슈를 해결하였고, 불필요하게 데이터가 추가 적재되는 것도 해결하게 되었다.

• S3는 파일을 버킷에 저장한다.
• 버킷은 상위 레벨 디렉토리로 표시된다. 사실 S3 그 자체는 디렉토리의 개념은 없다.
• S3 버킷의 파일은 객체라고 하며, 이 버킷은 계정 안에 생성된다. 즉 객체란 S3 저장소에 저장되는 데이터를 의미한다.
• 버킷 이름은 계정에 있는 모든 리전과 AWS에 존재하는 모든 계정에서 유니크해야 한다.
• 버킷은 리전 수준에서 정의되므로, 반드시 특정 AWS 리전에서 정의되어야 한다.
• 객체나 파일에는 키가 있으며, 키는 Amazon S3 키는 파일의 전체 경로다.
• 키는 접두사와 객체 이름으로 구성되며, 키는 길이가 굉장히 긴 이름으로 슬래시를 포함하며, 키는 접두사와 객체 이름으로 만들어진다.
• 파일 등 원하는 것은 뭐든지 업로드 가능하며, 최대 객체 크기는 5TB이다.
• 업로드하는 것이 5TB 보다 크다면 이때는 멀티 파트 업로드를 사용해서 해당 파일을 여러 부분으로 나눠 업로드한다.
  • 보통 100MB가 넘는 경우에는 멀티파트 업로드를 권장한다.
• 객체에는 메타 데이터가 있는데, 객체의 키-값 쌍 리스트를 말한다.
• 메타데이터 시스템이나 사용자에 의해 설정되어 파일에 관한 요소나 메타데이터를 나타낼 수 있다.
• 태그는 가령 유니코드 키-값 쌍은 최대 10개까지 가능하며, 태그는 보안과 수명 주기에 유용하다.

S3 사용 용도

• 백업과 스토리지
• 재해 복구 용도
• 아카이브
• 하이브리드 클라우드 스토리지
• 애플리케이션 호스팅, 미디어 호스팅
• 데이터 레이크, 빅데이터 분석
• 정적 웹사이트 호스팅

S3 보안

사용자 기반

• 사용자에게 IAM 정책이 주어진다.
  • 참고로 IAM 정책 내의 DENY은 S3 버킷 정책보다 우선적으로 고려된다.

리소스 기반

• S3 버킷 정책
  • 이 정책은 S3 콘솔에서 직접 할당할 수 있는 전체 버킷 규칙이다.
  • 특정 사용자가 들어올 수 있게 하거나 다른 계정의 사용자를 허용할 수 있다.
  • 이를 S3 버킷에 액세스할 수 있는 교차 계정이라고 한다.
• 객체 액세스 제어 목록(ACL)
  • 이 목록은 보다 세밀한 보안이며 비활성화할 수 있다.
• 버킷 액세스 제어 목록
  • 버킷이 퍼블릭으로 오픈되어있어도 해당 설정이 안되어있으면 버킷은 공개되지 않는다.
  • 버킷 수준에서 살펴보면 버킷 ACL이 있는데 훨씬 덜 일반적. 비활성화가 가능하다.

암호 키를 사용한 객체 암호화

S3 버전 관리

• Amazon S3에서는 파일을 버전 관리할 수 있다.
  • 해당 설정은 버킷에서 허용을 해야 한다.
• 사용자가 파일을 업로드할 때마다 선택 키에서 해당 파일의 버전이 생성된다.
• 동일한 키를 업로드하고 해당 파일을 덮어쓰는 경우 버전 2, 버전 3 등을 생성하게 된다.
• 버킷을 버전 관리하는 것이 좋다. 이 방법은 의도하지 않게 삭제하지 않도록 보호해주기 때문이다.
• 이전 버전으로 복구 가능하다. 버전을 제거하면 삭제 마커가 붙게 되는데, 삭제 마커를 제거하면 이전 버전으로 복구 가능하다.
• 버전 관리를 활성화하기 전에 버전 관리가 적용되지 않은 모든 파일은 널(null) 버전을 갖게 된다.
• 버전 관리를 중단해도 이전 버전을 삭제하지 않는다.

S3 복제

• 교차 리전 복제 CPR: 두 리전이 다를 때 사용한다.
• 같은 리전 복제 SRR: 두 리전이 같을 때 사용한다.
• 버킷은 서로 다른 AWS 계정간에도 사용할 수 있다. 복제는 비동기식으로 이루어진다. 복제 과정은 백그라운드에서 이루어진다.
• 복제 기능이 정상적으로 실행되려면, S3에 올바른 IAM 권한, 즉 읽기, 쓰기 권한을 S3에 부여해야 한다.
• 복제를 활성화한 후에는 보셨다시피 새로운 객체만 복제 대상이 된다.
• 기존의 객체를 복제하려면 S3 배치 복제 기능을 사용해야 한다.
• 기존 객체부터 복제에 실패한 객체까지 복제할 수 있는 기능이다.
• 체이닝 복제는 불가능하다.
  • ex) A Bucket -> B Bucket 복제 설정, B Bucket -> C Bucket 복제 설정을 했을때, A Bucket의 내용이 C Bucket 내용으로 복제되지 않는다.

스토리지 클래스

S3 standard - General Purpose

• 제일 기본 클래스
• 99.99% 가용성
• 자주 액세스하는 데이터에 사용한다.
• 지연 시간이 짧고 처리량이 높다.
• AWS에서 두 개의 기능 장애를 동시에 버틸 수 있다.
• 사용 사례는 빅데이터 분삭, 모바일, 게임 애플리케이션, 그리고 콘텐츠 배포다.

S3 standard-Infrequent Access (IA)

• 자주 액세스하지는 않지만 필요한 경우 빠르게 액세스해야하는 데이터에서 사용한다.
• 99.9% 가용성
• 스탠다드보다는 비용이 적게 들지만 검색 비용이 발생한다.
• 재해 복구와 백업에서 많이 사용한다.

S3 One Zone-Infrequent Access

• 단일 AZ 내에서는 높은 내구성을 갖지만 AZ가 파괴된 경우 데이터를 잃는다.
• 가용성은 99.5%
• 온프레미스 데이터를 2차 백업하거나 재생성 가능한 데이터를 저장하는데 사용하는 경우가 있다.

s3 Glacier Instant Retrieval

• 밀리초 단위로 검색이 가능하다.
• 분기에 한 번 액세스하는 데이터에 아주 적합하다.
• 최소 보관기간이 90일. 백업이지만 밀리초 이내에 액세스해야하는 경우 적합하다.

s3 Glacier Flexible Retrieval

• Flexible는 데이터를 검색하는 데 최대 12시간까지 기다려야 한다는 의미다.
• 3가지 옵션이 있다. 최소 보관 기간은 역시 90일
  • Expedited: 데이터를 1 ~ 5분 이내에 받을 수 있다.
  • Standard: 데이터를 돌려 받는데 3 ~ 5시간이 걸린다.
  • Bulk: 무료지만 5 ~ 12시간이 소요된다.

s3 Glacier Deep Archive

• 장기 보관을 위한 스토리지 클래스. 두 가지 검색 티어가 있다.
  • Standard: 12시간
  • Bulk: 48시간
• 최소 보관기간도 180일, 오래 걸리지만 가장 저렴하다.

글래시어 스토리지 클래스는 아카이빙과 백업을 위한 저비용 객체 스토리지다. 비용은 스토리지 비용과 검색 비용이 들어간다.

S3 Intelligent Tiering

• 사용 패턴에 따라 액세스된 티어 간에 객체를 이동할 수 있게 해준다.
• 소액의 월별 모니터링 비용과 티어링 비용이 발생하지만 검색 비용이 없다.
• FrequentAccess 티어는 자동이고 기본 티어다.
• Infrequent Access 티어는 30일 동안 액세스하지 않는 객체 전용 티어
• Archive Instant Access 티어도 자동이지만 90일 동안 액세스하지 않는 티어 전용
• Archive Access 티어는 선택 사항이며 90일에서 700일 이상까지 구성할 수 있고
• 선택 사항인 Deep Archive Access 티어는 180일에서 700일 이상 액세스하지 않는 객체에 구성할 수 있다.
• S3 Intelligent Tiering은 알아서 객체를 이동시켜 주기 때문에 편하게 스토리지를 관리할 수 있다.

• 고가용성, 확장성을 갖춘, 완전히 관리되며 권한있는 DNS다.
• 권한이 있다라는 뜻은 고객인 우리가 DNS 레코드를 업데이트 할 수 있다는 의미다.
  • 즉, DNS에 대해 완전히 제어할 수 있다.
• Route 53 역시 도메인 이름 레지스트라로 도메인 이름을 등록할 수 있다.
• Route 53의 리소스 관련 상태 확인을 확인할 수 있다.
• 100% SLA 가용성을 제공하는 유일한 AWS 서비스입니다
• Route 53에서 여러 DNS 레코드를 정의하고 레코드를 통해 특정 도메인으로 라우팅하는 방법을 정의한다.

레코드가 갖고 있는 속성

• 도메인/서브도메인 이름
• 레코드 타입
  • A: 호스트 이름과 IPv4 IP를 매핑
  • AAAA: 호스트 이름과 IPv6 매핑
  • CNAME: 호스트 이름을 다른 호스트 이름과 매핑
    • 대상 호스트 이름은 A나 AAAA 레코드가 될 수 있다.
    • Route 53에서 DNS 이름 공간 또는 Zone Apex의 상위 노드에 대한 CNAMES를 생성할 수 없다.
    • ex) example.com에 CNAME을 만들 수는 없지만 www.example.com에 대한 CNAME 레코드는 만들 수 없다.
    • 즉, 루트 도메인 이름이 아닌 경우에만 사용할 수 있다.
  • NS: 호스팅 영역의 네임 서버다. 트래픽이 도메인으로 라우팅 되는 방식을 제어한다. 서버의 DNS이름 또는 IP주소로 호스팅 존에 대한 DNS 쿼리에 응답이 가능하다.
  • CAA, DS. MX, NAPTR, PTR, SOA, TXT, SPF, SRV 등
• Value: IP
• 라우팅 정책: Route 53이 쿼리에 응답하는 방식
• TTL: DNS 리졸버에서 레코드가 캐싱되는 시간.

호스팅 존

• 호스팅 존은 레코드의 컨테이너다.
• 도메인과 서브도메인으로 가는 트래픽의 라우팅 방식을 정의한다.
• 호스팅 존에 두 종류가 있는데 퍼블릭 호스팅 존과 프라이빗 호스팅 존이 있다.
• 프라이빗 호스팅 존: 가상 프라이빗 클라우드(VPC)만이 URL을 리졸브 할 수 있다.
• 퍼블릭 호스팅 존 : 퍼블릭 호스팅 존은 공개된 클라이언트로부터 온 쿼리에 응답할 수 있다.

CNAME vs Alias

로드밸런서나 CloudFront 등 AWS 리소스를 사용하는 경우 호스트 이름이 노출된다. 도메인에 호스트 이름을 매핑할 수 있다. 도메인에 AWS 리소스를 매핑하는 경우는 2가지 옵션이 있을 수 있다. CNAME, Alias

1. CNAME

• CNAME 레코드로 호스트 이름이 다른 호스트 이름으로 향하도록 할 수 있다.
  • ex) app.mydomain.com -> blabla.anything.com
• 이건 루트 도메인 이름이 아닌 경우에만 가능해서 mydomain.com 앞에 뭔가 붙어야 한다.

2. Alias

• 호스트 이름이 특정 AWS 리소스로 향하도록 할 수 있다.
  • ex) app.mydomain.com -> blabla.amazonaws.com
• 루트 및 비루트 도메인 모두에 작동한다.
• Alias는 무료다.
• 자체적으로 상태 확인이 가능하다.
• AWS의 리소스에만 매핑되어 있다.
• CNAME과 달리 Alias는 Zone Apex라는 DNS 네임스페이스의 상위 노드로 사용될 수 있다.
• Alias 레코드를 사용하면 TTL을 설정할 수 없다.
• 대신, Route 53에 의해 자동으로 설정된다.
• Alias 대상은 다음과 같다.
  • ELB, CloudFront 배포, API Gateway, Elastic beanstalk, S3 웹사이트, S3 버킷은 불가, VPC 인터페이스 엔드포인트 Global Accelerator 등이 있다.
• EC2의 DNS 이름에 대해서는 Alias 레코드 설정할 수 없다.

Route 정책

• 라우팅 정책은 Route 53이 DNS 쿼리에 응답하는 것을 돕는다.

단순 라우팅 정책(Simple)

• 트래픽을 단일 리소스로 보낸다.
• 동일한 레코드에 여러 개의 ip 지정할 수도 있다.
• 그럼 DNS가 다중 값을 응답하고 클라이언트가 랜덤으로 골라서 라우팅에 적용한다.

가중치 기반 정책(Weighted)

• 가중치를 활용해 요청의 일부 비율을 특정 리소스로 보낸다.
• 각 레코드에 상대적으로 가중치를 할당한다.
• DNS 레코드들은 동일한 이름과 유형을 가져야 하며 상태 확인과도 관련될 수 있다.
• 서로 다른 지역들에 걸쳐 로드 밸런싱을 할 때나 적은 양의 트래픽을 보내 새 애플리케이션을 테스트하는 경우에 사용한다.

대기 시간 기반 정책(Latency-based)

• 가장 가까운 리소스로 리다이렉팅을 한다.(지연 시간이 가장 짧은)
• 지연 시간은 유저가 레코드로 가장 가까운 식별된 AWS 리전에 연결하기까지 걸리는 시간을 기반으로 측정된다.

장애 조치 정책(Failover)

• 상태확인과 DNS 레코드를 묶은 방식이다.
• 세 가지의 상태 확인이 가능하다.
  • 공용 엔드 포인트를 모니터링(애플리케이션, 서버, 혹은 다른 AWS 리소스가 될 수 있다.)
  • 계산된 상태 확인(다른 상태 확인을 모니터링)
  • CloudWatch 경보의 상태를 모니터링
• Primary 리소스 / Secondary - Disaster Recovery 리소스가 필요하다.
• Primary에 에러가 발생하면 Disaster Recovery로 쿼리한다.

지리적 위치 (Geolocation)

• 사용자의 실제 위치를 기반으로 합니다. 즉 가장 가까운 곳 IP로 응답한다.
• 사용 사례로는 콘텐츠 분산을 제한하고 로드 밸런싱 등을 실행하는 웹사이트 현지화가 있다.

지리 근접 (GeoProximity)

• 사용자와 리소스의 지리적 위치를 기반으로 트래픽을 리소스로 라우팅한다.
• 편향값을 사용해 특정 위치를 기반으로 리소스를 더 많은 트래픽을 이동시킨다.
  • 지리 근접 라우팅은 편향을 증가시켜 한 리전에서 다른 리전으로 트래픽을 보낼 때 유용하다.

IP 기반 (IP-based)

• 클라이언트 IP 주소를 기반으로 라우팅한다.
• Route 53에서 CIDR 목록을 정의(클라이언트의 IP 범위)
• CIDR에 따라 트래픽을 어느 로케이션으로 보내야 하는지 정한다.
  • 이걸 사용해 성능 최적화, 네트워크 비용 절감이 가능하다.
  • IP를 미리 알고 있으니까 가능, IP가 어디서 오는지 알고 있으니까

다중 값 (Multi-Value)

• 트래픽을 다중 리소스로 라우팅할 때 사용한다.
• Route 53은 다중 값과 리소스를 반환한다.
• 상태 확인과 연결하면 다중 값 정책에서 반환되는 유일한 리소스는 정상 상태 확인과 관련이 있다.
• 각각의 다중 값 쿼리에 최대 8개의 정상 레코드가 반환된다.
• ELB와 유사해 보이지만 ELB를 대체할 수는 없다.
• 클라이언트 측면의 로드 밸런싱이다.
• 다중 값이 있는 단순한 라우팅의 경우에는 단순 라우팅 정책은 상태 확인을 허용하지 않기 때문에 단순 라우팅 정책의 쿼리가 반환하는 리소스 중 하나는 비정상일 가능성이 있다.
• 다중 라우팅은 정상 상태 확인과 연동되며, 정상인 리소스를 반환할 수 있다.

• Relational Database Service, AWS가 제공하는 관리형 서비스다. (프로비저닝과 OS가 자동화)

• 다양한 데이터베이스 엔진을 제공한다.

  • Aurora
  • Postgresql
  • Mysql
  • MariaDB
  • Oracle
  • Microsoft SQL Server

• 지속적으로 백업이 되므로, 특정 시점으로 복원이 가능하다.

• 데이터베이스의 성능을 대시 보드에서 모니터링 가능하다.

• 읽기 전용 복사본을 생성해 읽기 성능을 올릴 수도 있다.

• 재해 복구 목적으로 다중 AZ 설정 가능하다.

• 유지 관리 기간에 업그레이드도 가능하다.

• 수직 확장하거나 읽기 전용을 추가해 수평 확장도 가능하다.

• 파일 스토리지는 EBS에 구성된다. (gp2, io1)

• RDS 인스턴스는 ssh 액세스가 불가능하다.

• EC2 인스턴스에 데이터베이스 엔진을 배포할 때 설정할 모든 것을 AWS가 제공함 -> 완전 관리형

• RDS 스토리지 오토 스케일링 기능이 활성화되어 잇으면 RDS가 이를 감지해서 자동으로 확장한다.

• 디비 스토리지 용량을 늘리려고 디비를 다운시키는 등의 작업이 필요 없다.

• IO가 많으면 스토리지를 오토 스케일링 해야 하는데, 이를 위해 최대 스토리지 임계값을 정해야한다.

• 할당된 용량에서 남은 공간이 10% 미만이 되면 스토리지를 자동으로 수정한다.

  • 스토리지 부족 상태가 5분이상 지속되거나 지난 수정으로부터 6시간이 지났을 경우에 오토 스케일링이 활성화되어 있다면 스토리지가 자동 확장된다.
  • 워크로드를 예측할 수 없는 애플리케이션에서 굉장히 유용하다.
  • 스토리지 오토 스케일링은 모든 RDS 디비 엔진에서 지원된다.

RDS 읽기 전용 복제본

• 읽기 전용 복제본은 최대 15개까지 생성 가능하다.
• 동일한 가용 영역 또는 가용 영역이나 리전을 걸쳐서 생성될 수 있다.
• 읽기 전용 복제본이 2개가 있고 메인 RDS가 있다면 두 읽기 전용 복제본 사이에 비동기식 복제가 발생한다.
  • 비동기이므로 읽기가 일관적으로 유지된다.
• 읽기 전용 복제본을 마스터 데이터베이스로 승격시켜 사용할 수 있다.

사용 사례

• 운영 디비의 읽기 전용 복제본을 만들어서 분석 애플리케이션과 전용 복제본을 사용해 데이터를 분석할 수 있다.
  • 클라이언트의 요청을 받는 운영DB에는 영향을 주지 않는다.

네트워크 비용

• AWS에서는 하나의 가용 영역에서 다른 가용 영역으로 데이터가 이동할 때 비용이 발생한다.
• 하지만 예외가 존재하며 보통 이 예외는 관리형 서비스다.
• RDS 읽기 전용 복제본은 관리형 서비스다.
• 읽기 전용 복제본이 다른 AZ지만 동일한 리전 내에 있을 때는 비용이 발생하지 않는다.
  • 하지만 서로 다른 리전에 복제본이 존재하는 경우에는 이동할 때 네트워크에 대한 복제 비용이 발생한다.

Multi-AZ

• 다중 AZ는 주로 재해 복구에 사용된다.
• AZ A의 마스터 DB 인스턴스 AZ B의 스탠바이(대기) 인스턴스로 동기식 복제를 한다.
  • 즉 마스터 DB의 모든 변화를 동기적으로 복제한다.
• 하나의 DNS 이름을 갖고 마스터에 문제가 생기면 스탠바이(대기) 인스턴스에도 자동으로 장애 조치가 수행된다.
• 전체 AZ 또는 네트워크가 손실될 때에 대비한 장애 조치이자, 마스터 DB가 고장나면 스탠바이 DB가 마스터 DB가 되도록 한다.
• 자동으로 장애 스탠바이가 마스터로 승격되기에 스케일링에 사용되지 않는다. 오로지 대기 목적이므로, 읽기 쓰기가 불가능하다.
• 읽기 전용 복제본을 다중 AZ로 설정할 수 있다.
• 단일 AZ에서 다중 AZ로 RDS 디비 전환이 가능한데 변환시에 다운 타임이 전혀 없다.
  • 즉, DB를 중지할 필요가 없다
• 기본 DB의 RDS가 자동으로 스냅샷을 생성한다. -> 스탠바이 DB에 복원된다.
• 기존 DB를 읽기 전용 DB 복제본을 만들어 다중 AZ를 활성화하면 된다.

RDS Custom

• Oracle, Microsoft SQL Server에서만 가능하다.
• 기저 운영체제나 DB 사용자 지정 기능에 액세스할 수 있다.
• 내부 설정 구성, 패치 적용, 네이티브 기능 활성화, SSH 접근이 가능해진다.

Amazon Aurora

• AWS의 고유 기술로 Postgres 및 MySQL과 호환된다.
• RDS의 MySQL보다 5배 높은 성능, RDS의 Postgresql보다는 3배 높은 성능을 보장한다.
• Aurora 스토리지는 자동으로 확장된다. 10GB에서 시작하지만 디비에 더 많은 데이터를 넣을 수록 자동으로 128TB까지 커진다. (10GB ~ 128TB)
• 읽기 전용 복제본은 최대 15개의 복제본을 둘 수 있다. 복제 속도도 훨씬 빠르다.
• Aurora는 다중 AZ, MySQL RDS보다 훨씬 빠른 즉각적인 장애 조치를 취한다. 가용성도 높다.
• RDS에 비해 20% 비싸지만 스케일링 측면에서 훨씬 더 효율적이다.

높은 가용성과 읽기 스케일링

• Aurora는 특이하게 3 AZ에 걸쳐 데이터의 6개의 사본을 저장한다.
• 쓰기에는 6개 사본 중 4개가 필요하다.
• 읽기에는 6개 사본 중 3개만 있으면 된다.
• 일부 데이터가 손상되거나 문제가 있으면 백엔드에서 p2p 복제를 통한 자가 복구가 진행된다.
• 단일 볼륨에 의존하지 않고 수백개의 볼륨에 의존한다.
• 스토리지가 수백 개의 볼륨에 걸쳐 스트라이핑된다.
  • 스트라이핑 : 스트라이핑(striping)은 데이터를 여러 개의 디스크나 스토리지 볼륨에 분산하여 저장하는 기술.
• 쓰기를 받는 인스턴스는 하나다.
• Aurora도 마스터가 존재하며 여기서 쓰기를 진행한다.
• 마스터가 작동하지 않으면 평균 30초 이내로 장애 조치가 시작된다. -> 매우 빠르게 장애 조치
• 마스터 외에 읽기를 제공하는 읽기전용 복제본은 최대 15개. 자동 스케일링도 설정 가능하다.
• 복제본을 많이 두고 읽기 워크로드를 스케일링할 수 있다.
• 마스터에 문제가 생기면 읽기 전용 복제본이 마스터로 대체된다.
• 이 복제본들은 리전 간 복제를 지원한다.
• 정리하면 마스터는 하나고 ,복제본은 여럿이며 스토리지가 복제된다.
• 작은 블록 단위로 자가 복구 또는 확장이 일어난다

Aurora DB cluster

• 마스터가 바뀌거나 장애조치가 실행될 수 있으므로 Aurora는 Writer 엔드포인트를 제공한다.
  • Writer 엔드포인트는 DNS 이름으로 항상 마스터를 가리킨다.
  • 따라서 장애 조치 후에도 클라이언트는 라이터 엔드포인트와 상호작용하게 되며 올바른 인스턴스로 자동으로 리다이렉트된다.
• 읽기 복제본도 오토 스케일링을 설정해 항상 적절한 수의 읽기 전용 복제본이 존재하도록 할 수 있다.
• Reader 엔드포인트도 존재한다. 모든 읽기 전용 복제본과 자동으로 연결된다.
• 따라서 클라이언트가 reader 엔드포인트에 연결될 때마다 읽기 전용 복제본 중 하나로 연결되며 이런 방식으로 로드 밸런싱을 도와준다.

Aurora 특징

1. 자동 장애 조치
2. 백엽 및 복구
3. 격리 및 보안
4. 산업 규정 준수
5. 자동 스케일링
6. 제로다운 타임 자동 패치
7. 고급 모니터링
8. 통상 유지 관리
9. 백트랙: 과거 어떤 시점의 데이터로도 복원 가능하게 해주는 기능. 백업에 의존 하지 않는다.

Amazon Aurora 고급 개념

• 복제본 자동 스케일링을 사용해 읽기 요청을 분산하고 CPU 사용량을 감소시킬 수 있다.
• 사용자 지정 엔드포인트를 정의하고 사용해 특정 복제본에서 작업이 가능하다.
  • 일반적으로 사용자 지정 엔드포인트를 정의하면 Reader 엔드포인트가 동작하지 않는다.
  • 실무에서는 여러 사용자 지정 엔드포인트를 만든다.
• 서버리스 기능을 사용해 실제 사용량에 기반한 자동 데이터베이스 인스턴스화와 오토 스케일링을 가능하게 해준다. 이는 비정기적, 간헐적 또는 예측 불허한 워크로드에 유용하다. 용량 계획을 세울 필요가 없고 각 Aurora 인스턴스에 대해 매 초당 비용을 지불한다. 비용면에서 효율적이다.
• 멀티 마스터: 라이터 노드에 대한 즉각적 장애 조치로 라이터 노드에서 높은 가용성을 갖추고자 할때 사용한다.
  • 이 경우 Aurora 클러스터의 모든 노드에셔 읽기 및 쓰기가 가능하다
• Global Aurora
  • 모든 쓰기 및 읽기가 진행되는 하나의 기본 리전이 있다.
  • 복제 지연이 1초 미만인 보조 읽기 전용 리전을 다섯개까지 설정할 수 잇고, 각 보조 지역마다 읽기 전용 복제본을 16개까지 생성가능하다. 이렇게 하면 세계 각지의 있는 읽기 전용 복제본의 지연시간을 단축할 수 있다.
  • 또한 한 리전의 데이터베이스가 작동 중단될 경우 재해 복구 목적으로 다른 지역을 승격하는데 필요한 RTO, 즉 복구 시간 목표는 1분 미만이다.
  • 평균적으로 Aurora 글로벌 데이터베이스에서 한 리전에서 다른 리전으로 데이터를 복제하는데는 1초 이하의 시간이 걸린다. -> 글로벌 Aurora를 사용하라는 힌트
• Aurora는 AWS내의 머신 러닝 서비스와의 통합을 지원한다. (Amazon SageMaker, Amazon Comprehend와 통합 가능)
  • 이를 통해 Aurora는 머신 러닝 서비스에 데이터를 보내고 Aurora는 쿼리 결과를 응용 프로그램에게 반환한다.

RDS & Aurora

RDS 백업

자동 백업

• 이는 RDS 서비스가 자동으로 디비 유지 관리 시간에 데이터베이스 전체를 백업한다는 의미다.
• 5분마다 트랜잭션 로그도 백업. 가장 최신 백업이 5분전 임을 의미한다.
• 이 자동 백업을 사용하면 5분 전 어떤 시점으로도 복구가 가능하다.
• 자동 백업 보유 기간은 1일에서 35일까지로 설정 가능하다. 이 기능은 비활성화도 가능하다.

  수동 DB 스냅샷 생성

• 사용자가 수동으로 트리거해야 한다.
• 수동 백업은 원하는만큼 오랫동안 보유할 수 있다는 장점이 있다.
• 원하는 기간동안 보유가 가능하다.

Aurora 백업

자동 백업

• 하루에서 35일까지 보유 가능한 자동 백업이다. 비활성화가 불가능하다.
• 지정 시간 복구 기능이 있는데, 정해진 시간 범위 내의 어느시점으로도 복구가 가능하다.

  수동 디비 스냅샷

• 사용자가 수동으로 만들고, 원하는 기간만큼 보유 가능하다. RDS와 매우 유사하다.

복원(Restore)

• 복원이 가능한 것은 RDS 및 Aurora 백업 또는 스냅샷이다.
• 이를 새로운 디비로 복원 가능 자동 백업이나 스냅샷을 복원할 때마다 새로운 디비가 생성된다.
• S3로부터 MySQL RDS 디비를 복원 가능하다.
• 기본적인 개념은 온프레미스 디비의 백업 파일을 객체스토리지인 S3에 업로드하고 백업 파일을 복원하는 것이다.
• S3로부터 MySQL Aurora 클러스터로 복원
  • Percona XtraBackup 이라는 소프트웨어를 사용해 백업한 후에 S3에 업로드하고 백업 파일을 복원하면 된다.

Aurora DB 복제

• 기존의 디비로부터 새로운 Aurora DB 클러스터를 만들 수 있다.
• 기존 배포 디비에 영향을 주지 않고 복제하여 개발 또는 테스트 수행 가능하다.
• 실제로 스냅샷을 만들고 복원하는 것보다 복제한 Aurora를 사용하는 편이 더 빠르다.
  • 이유: 복제는 copy-on-write 프로토콜을 사용한다.
  • 새로운 디비는 같은 클러스터 볼륨을 사용하기 때문에 빠르고 효율적이다. 데이터를 복제하지 않기 때문에
  • 그리고 시간이 흐름에 따라 새 디비로 업데이트되면 변경된다.
• 디비 복제는 매우 빠르고 비용 면에서 효율적이다

RDS & Aurora Security

• RDS 및 Aurora 디비에 저장된 데이터를 암호화할 수 있다. 데이터가 볼륨에 암호화된다.
• KMS를 사용해 마스터와 모든 복제본의 암호화가 이뤄지며 이는 디비를 처음 실행할 때 정의된다.
  • 어떤 이유에서든 마스터 데이터베이스를 암호화하지 않았다면 읽기 전용 복제본을 암호화할 수 없다.
  • 암호화 되어 있지 않은 기존 디비를 암호화하려면 암호화되지 않은 디비의 디비 스냅샷을 가지고 와서 암호화된 디비 형태로 데이터베이스 스냅샷을 복원해야 한다.
• RDS와 Aurora는 전송중 데이터 암호화라는 기능이 있다. 따라서 클라이언트는 AWS의 TLS 루트 인증서를 사용해야 한다.
• IAM 역할을 사용해서 디비에 접속하거나 사용자 이름/비밀번호로 접속 가능하다.
• 보안 그룹을 사용해 디비에 대한 네트워크 액세스를 통제할 수 있다.(포트, 아이피, 보안 그룹 등)
• RDS & AURORA는 SSH로 접근 불가능. custom RDS는 제외다.
• 감사 로그 작성을 활성화하면 시간에 따라 RDS 및 Aurora에서 어떤 쿼리가 생성되는지 확인 가능 장기관 보관하고 싶다면 CloudWatch Log 서비스로 전송해야 한다.

RDS Proxy

• 애플리케이션과 RDS 데이터베이스에 대한 연결을 최소화한다.
• RDS PRoxy는 완전한 서버리스로 오토 스케일링이 가능해 용량 관리가 필요 없고 가용성이 높다.(다중 AZ 지원)
• 장애 조치 시간을 66%까지 줄일 수 있다.
• RDS Proxy를 사용하면 애플리케이션은 장애와 무관한 RDS 프록시와 연결된다.
• RDS 프록시는 장애가 발생한 RDS 데이터베이스 인스턴스를 처리하므로 장애 조치 시간이 개선된다.
• RDS PROXY는 MySQL, PostgreSQL, MariaDB용 RDS를 지원하고 MySQL, PostgreSQL 용 Aurora를 지원한다.
• DB에 IAM 인증을 강제함으로써 IAM 인증을 통해서만 RDS 디비 인스턴스에 연결하도록 할 수 있다. 이때 자격증명은 AWS Secrets Manager 서비스에 안전하게 저장된다.
• RDS는 프록시는 퍼블릭 액세스가 절대 불가능하다.

ElasticCache

• 모든 캐시는 IAM 인증을 지원하지 않는다.
  • IAM 정책은 AWS API 수준의 보안에만 사용된다.
• RDS와 동일한 방식으로 관계형 디비를 관리할 수 있다.
• 레디스와 멤캐시 같은 캐시 기술을 관리한다
• 낮은 지연 시간을 가진 인 메모리 디비다.
• 엘라스틱 캐시를 사용해 읽기 집약적인 워크로드의 부하를 줄이는데 도움이 된다.
• 애플리케이션의 상태를 Amazon 엘라스틱 캐시에 저장해 애플리케이션을 무상태로 만들 수 있다
• RDS와 같은 장점을 갖기 때문에 AWS는 동일한 유지 보수를 수행한다. (운영체제, 패치, 최적화와 설정, 구성, 모니터링, 장애 회복 그리고 백업 수행한다.)
• 엘라스틱 캐시를 사용할 때 캐시의 정합성을 고려하면 어려운 부분이 존재한다.
• 엘라스틱 캐시를 디비 캐시, 유저 세션 스토어로 많이 사용한다.
• Redis는 자동 장애 조치와 함께 다중 AZ를 수행한다.
• Redis 읽기 전용 복제본은 읽기 스케일링에 사용되며 고가용성을 가짐 지속성으로 인해 데이터 내구성도 갖추고 있다. 백업, 복원이 가능하며 RDS와 유사하다.
• Memcached는 데이터 분할을 위해 멀티 노드(샤딩)를 사용한다.
  • 고가용성이 없고 복제가 일어나지 않으며 영구 캐시가 아니다.
  • 백업 및 복원의 기능이 없다.
  • 멀티 스레드 아키텍처이다.
  • Memcached에서는 여러 인스턴스가 모두 샤딩을 통해 작동한다.
• Redis는 고가용성, 백업, 읽기 복제본 등을 위해 존재
• 반면, Memcached는 분산되어 있는 순수한 캐시. 데이터 손실되어도 괜찮은 경우, 고가용성이 없으며 백업, 복원 기능 없다.

  ElasticCache 보안

• Redis에서만 IAM 인증을 지원하며, 나머지 경우에는 사용자 이름과 비밀번호를 사용하면 된다.
• ElasticCache에서 IAM 정책을 정의하면 AWS API 수준 보안에만 사용된다.
• Redis AUTH라는 Redis 내 보안을 통해 비밀번호와 토큰을 설정할 수 있다. -> Redis 클러스트를 생성할때
  • 이는 캐시에 사용할 수 있는 보안 그룹에 대한 추가적인 수준의 보안이다.
• 그리고 전송 중 암호화를 위해 SSL 보안을 지원할 수 있다.
• EC2 인스턴스와 클라이언트가 있는 경우 Redis AUTH를 사용하여 Redis 클러스터에 연결할 수 있다.
  • 이는 Redis 보안 그룹에 의해 보호되는 것이다.
  • 또한, in-flight 암호화 사용하거나, Redis에서 IAM 인증을 활용할 수 있다.

Memcached

• 좀 더 높은 수준인 SASL 기반 인증을 지원한다. 상당히 고급이라 다른 종류의 인증 메커니즘이다.

일래스틱 캐시의 패턴

일래스틱 캐시에 데이터를 불러오는 패턴에는 3가지 패턴이 있다.

1. 지연 로딩

• 모든 읽기 데이터가 캐시되고 데이터가 캐시에서 오래될 수 있다. (케케 묵을 수 있다.)

  2. Write Through

• 데이터를 오래된 데이터가 없는 디비에 기록될때마다 캐시에 데이터를 추가하거나 업데이트하는 것이다.

  3. 세션 저장소

• Time To Live 속성으로 세션을 만료시킬 수 있다.

고가용성

• 고가용성은 애플리케이션 또는 시스템을 적어도 둘 이상의 AZ나 데이터센터에서 가동하는 것이다.
• 고가용성은 데이터센터에서의 손실에서 살아남아야 한다. 즉, 가동중인 데이터센터에 문제가 생겨도 다른 데이터센터에서 정상적으로 돌아가야 한다.
• 동일한 애플리케이션의 동일한 인스턴스를 멀티AZ에서 가동해야 한다.
• 멀티AZ가 활성화된 오토 스케일링 그룹이나 로드밸런서에서도 사용한다.
• 고가용성은 수동적일 수도 있다(ex. RDS Multi AZ)
• 활성형도 존재한다.(수평 확장의 경우)

확장성

수직 확장성

• 수직 확장성은 인스턴스의 스펙을 확장한다. 시스템의 스펙을 향상시키는 것이다.
• 데이터베이스와 같이 분산되지 않은 시스템에서 주로 사용한다.
• 하드웨어 제한이 걸려있기 때문에 한계가 존재한다.

수평 확장성

• 수평 확장성은 애플리케이션에서 인스턴스의 수를 늘리는 방법이다.
• 현대 애플리케이션은 대부분 분배 시스템이므로 해당 방식이 적절하다.
• 요즘은 클라우드 제공 업체 덕분에 수평적으로 확장이 수월하다.

ELB(Elastic Load Balanceer)

Load Balancing

• 로드밸런서는 다수의 서버에게 트래픽을 전달하는 서버이다.
• 사용자는 로드밸런서를 사용하므로 어떤 서버를 사용하고 있는지 구체적인 동작은 모른다.

Load Balaner

• 로드밸런서는 부하를 다수의 다운 스트림 인스턴스로 분산하기 위해서 사용한다.
• 애플리케이션에 단일 액세스 지점(DNS)를 노출하고 다운 스트림 인스턴스의 장애를 원활하게 처리할 수 있다.
• 헬스 체크 메커니즘을 사용해 인스턴스의 상태를 확인하고 요청을 보낸다.
• SSL 종료도 가능하므로 HTTPS 트래픽을 받을 수 있다.
• 쿠키로 고정도를 강화할 수 있고 영역에 걸친 고가용성을 가지며 클라우드 내에서 개인 트래픽과 공공 트래픽을 분리할 수 있다.

ELB 소개

• ELB는 관리형 로드 밸런서다. AWS가 관리하는 서비스이며 어떤 경우에도 작동할 것을 보장한다.
• AWS가 업그레이드와 유지 관리 및 고가용성을 책임지며 로드 밸런서의 작동 방식을 수정할 수 있게 일부 구성 knobs도 제공한다.
• 자체 로드밸런서를 만드는 것보다 저렴하고 확장성 측면에서 유리하다.
• 로드밸런서는 다수의 aws 서비스랑 묶이는 EC2인스턴스, 스케일링 그룹, 아마존 EC2와 인증서 관리(ACM), 클라우드 워치, Rout53, AWS WAF, AWS Global Accelerator 등
• 헬스 체크는 ELB가 EC2에 동작이 올바르게 작동하고 있는지를 확인한다.

관리형 로드 밸런서 종류

로드밸런서 보안

• 유저는 http, https를 사용해 어디서든 로드밸런서에 접근이 가능하다.
• 로드밸런서도 보안그룹 규칙 적용 가능하다.
• 로드밸런서를 사용하는 이상적인 EC2의 인스턴스 보안은 오직 로드밸런서와 연결하는 것이다.
• 즉 EC2 인스턴스의 보안 그룹을 로드밸런서의 보안 그룹으로 연결하면 된다.
• 그러면 EC2 인스턴스는 로드밸런서에서 온 트래픽만을 허용한다.
• 로드밸런서의 다양한 리스너 규칙을 정의할 수 있다.
  • 리다이렉트, path에 따른 응답 코드 정의

1. CLB(클래식 로드밸런서)

• CLB는 현재 거의 사용하지 않기에 생략한다.

2. ALB(애플리케이션 로드밸런서)

• HTTP, HTTPS, WEBSOCKET에 특화되어있다.
• OSI 7계층(응용)에서 동작한다. 즉 HTTP 전용 로드밸런서다.
• 로드밸런서의 라우팅 타겟 머신들은 타겟 그룹이라는 그룹으로 묶인다.
• 리스너 규칙을 정할 수 있다.
  • PATH를 지정하면 라우팅을 지원한다.
  • URL의 호스트 이름에 기반한 라우팅을 지원한다.
  • 쿼리 문자열과 헤더에 기반한 라우팅을 지원한다.
• 컨테이너 기반 애플리케이션에 가장 좋은 로드밸런서이다.
• 포트 매핑 기능이 있어 ECS 인스턴스의 동적 포트로의 리다이렉션을 가능하게 해준다.

2-1 ALB의 Target Group

• EC2 인스턴스, ECS, 람다가 타겟 그룹이 될 수 있다.
• 타겟 그룹들은 오토스케일링 그룹에 의해 관리될 수 있다.
• ALB는 IP주소들의 앞에도 위치할 수 있다. 하지만 이때 꼭 사설IP주소여야 한다.
• ALB는 여러 타겟 그룹으로 라우팅할 수 있으며 상태 확인은 타겟 그룹 레벨에서 이뤄진다.
• 온프레미스 환경과 클라우드를 섞어서도 ALB를 사용할 수 있다. 해당 경우에어 쿼리 문자열이나 매개변수 라우팅을 사용하면 된다.
• ALB를 사용하는 경우에도 CLB와 마찬가지로 고정 호스트 네임이 부여된다.
• 애플리케이션 서버는 클라이언트의 IP를 직접 보지 못하며 클라이언트의 실제 IP는 X-Forwarded-For라고 불리는 헤더에 삽입된다. X-Forwarded-Port를 사용하는 포트와 X-Forwarded-Proto에 의해 사용되는 프로토콜도 얻게된다.

3. NLB(네트워크 로드밸런서)

• TCP, TLS, Secure TCP, UDP에 특화되어있다.
• L4 로드 밸런서이기에 TCP, UDP 트래픽을 다룰 수 있다.
• 성능이 매우 뛰어나며 초당 수백만건의 요청을 처리 할 수 있다.
• ALB보다 지연시간도 짧다. ALB는 400ms, NLB는 100ms
• NLB의 특징은 가용 영역별로 하나의 고정 IP를 갖게 된다.
• 탄력적 IP 주소를 각 AZ에 할당 할 수 있다.
• 여러개의 고정 IP를 가진 애플리케이션을 노출할 때 유용하다. 탄력적 IP 사용 가능하다.
• 1~3개의 IP로만 액세스할 수 있는 애플리케이션을 설계하라는 문제는 NLB 고려!, TCP, UDP, 정적IP가 있어도 NLB 고려

3-1 NLB의 Target Group

• EC2 인스턴스들이 타겟 그룹이 될 수 있다.
• NLB가 TCP, UDP 트래픽을 EC2 인스턴스로 리다이렉트할 수 있다.
• IP 주소를 등록할 수 있는데 IP주소는 반드시 하드코딩 되어야하며 private IP만 가능하다.
  • 자체 데이터 센터의 private IP도 사용할 수 있다.
• 온프레미스, 클라우드 둘 다 같은 네트워크 밸런서를 앞단에 두고 사용할 수 있다.
• ALB 앞에 NLB를 사용할 수 있다.
• NLB 덕분에 고정 IP 주소를 얻을 수 있고 ALB를 이용해 HTTP 유형의 트래픽을 처리하는 규칙을 정의할 수 있다
• 네트워크 로드 밸런서 타겟 그룹이 수행하는 상태 확인이 중요하다.

4. GWLB(게이트웨이 로드밸런서)

• 6081 포트의 GENEVE 프로토콜을 사용한다.
• 다른 로드밸런서보다 낮은 수준에서 실행된다. 3계층에서 실행된다.
• IP 패킷의 네트워크 계층의 L3에서 동작한다.
• GWLB는 배포 및 확장과 AWS의 타사 네트워크 가상 어플라이언스의 플릿 관리에 사용된다.
• GWLB는 네트워크의 모든 트래픽이 방화벽을 통과하게 하거나 침입 탐지 및 방지 시스템에 사용한다.
  • 그래서 IDPS나 심층 패킷 분석 시스템 또는 일부 페이로드를 수정할 수 있지만 네트워크 수준에서 가능하다.
• GWLB의 동작과정
  1. GWLB를 생성하면 VPC 내부에서 라우팅 테이블이 업데이트 된다.
  2. 라우팅 테이블이 수정되면, 먼저 모든 사용자 트래픽은 GWLB를 통과한다. 그리고 GWLB는 가상 어플라이언스의 대상 그룹 전반으로 트래픽을 확산한다. 그래서 모든 트래픽은 어플라이언스에 도달하고 어플라이언스는 트래픽을 분석하고 처리한다(방화벽, 침입탐지)
  3. 이상이 없으면 다시 GWLB로 보내고 이상이 있으면 트래픽을 드롭한다.
  4. GWLB를 통과하면 GWLB에서는 트래픽을 애플리케이션으로 보낸다. 모든 트래픽이 GWLB를 통과해 타사 가상 어플라이언스를 통과해 애플리케이션으로 보내진다.
• GWLB 기능은 네트워크 트래픽을 분석하여 애플리케이션으로 진입시킬지 확인한다.

4-1 GWLB의 Target Group

• 타사 어플라이언스가 있다.
• EC2 인스턴스일 수도 있고 인스턴스 id로 등록하거나 ip 주소일 수도 있다. 이 경우는 private IP여야 한다
  • 자체 네트워크나 자체 데이터 센터에서 이런 가상 어플라이언스를 실행하면 IP로 수동 등록할 수 있다.

ELB Sticky Session

• 고정 세션을 실행하는 것으로 로드 밸런서에 2가지 요청을 수행하는 클라이언트가 요청에 응답하기 위해 백엔드에 동일한 인스턴스를 갖는 것이다.
• 첫번째 클라이언트가 특정 인스턴스에 첫 요청을 보내면 두 번째 요청도 동일한 인스턴스로 이동해야 한다.
• 타겟 그룹에서 설정이 가능하다.
• 보통 고정 세션은 사용자의 로그인과 같은 중요한 정보를 취하는 세션 데이터를 잃지 않기 위해 사용자가 동일한 백엔드 인스턴스에 연결하기 위해 사용한다.
  • 그러나 고정성을 활용하면 백엔드 ec2 인스턴스 부하에 불균형을 초래할 수 있다. 일부 인스턴스가 고정 사용자를 갖게 되기 때문이다.
• 고정 세션에는 애플리케이션 기반의 쿠키와, 기간 기반의 쿠키 2가지 유형이 있다.

애플리케이션 기반 쿠키

애플리케이션 기반의 쿠키는 애플리케이션에서 기간을 지정.

• 커스텀 쿠키
  • 애플리케이션 기반의 쿠키는 대상으로 생성된 사용자 정의 쿠키로 애플리케이션에서 생성된다.
  • 애플리케이션에 필요한 모든 사용자 정의 속상을 포함할 수 있다
  • 쿠키 이름은 각 대상 그룹별로 개별적으로 지정하는데, 다음과 같은 이름은 사용하면 안된다.
  • AWSALB, AWSALBAPP, AWSALBTG는 ELB에서 사용하기 때문이다.
• 애플리케이션 쿠키
  • 애플리케이션 쿠키가 될 수도 있는데 지금은 로드밸런서 자체에서 생성된다.
  • ALB의 쿠키 이름은 AWSALBAPP.

    기간 기반 쿠키

• 로드 밸런서에서 생성되는 쿠키로 ALB에서는 AWSALB이다 CLB는 AWELB
• 특정 기간을 기반으로 만료되며 그 기간이 로드 밸런서 자체에서 생성된다.

ELB Cross Zone 로드밸런싱

• 교차 영역 로드밸런싱을 쓰면, 각각 로드 밸런서 인스턴스가 모든 가용 영역에 등록된 모든 인스턴스에 부하를 고르게 분배한다.
• ALB는 교차 영역 로드밸런성이 기본으로 활성화되어 있다. 데이터를 다른 가용 영역으로 옮기는데 비용이 들지 않는다.
• NLB와 GWLB는 기본으로 교차 영역 로드 밸런싱이 비활성화되어 있다. 따라서 활성화하면 비용을 내야한다.

ELB SSL TLS

• SSL 인증서는 클라이언트와 로드 밸런서 사이에서 트래픽이 이동하는 동안 암호화 해준다. 이를 전송중(in-flight) 암호화라고 한다.
• 데이터는 네트워크를 이동하는 동안 암호화되고, 송신자와 수신자측에서만 이를 복호화할 수 있다.
• 퍼블릭 SSL 인증서를 로드밸런서에 추가하면, 클라이언트와 로드 밸런서 사이의 연결을 암호화할 수 있다.
  • 로드 밸런서는 X.509 인증서를 사용하는데, 이걸 SSL 또는 TLS 서버 인증서라고 부른다
  • AWS에는 이 인증서들을 관리할 수 있는 ACM이란게 있다. AWS 인증서 관리자의 역할이다.
  • 우리가 가진 인증서를 ACM에 업로드하여 사용할 수도 있다.
• HTTP 리스너를 구성할 때 반드시 HTTPS 리스너로 해야 한다.
• 기본 인증서를 지정해줘야 한다.
• 다중 도메인을 지원하기 위해 다른 인증서를 추가할 수 있다. 도메인별로 인증서를 사용할 수 있기 때문이다.
• 클라이언트는 SNI(서버 이름 지정)라는 걸 써서 접속할 호스트의 이름을 알릴 수 있다.
  • 이렇게 SNI, 즉 서버 이름 지정을 써서 여러 개의 대상 그룹과 웹사이트를 지원할 수 있습니다, 다중 SSL 인증서를 사용해서요
• 우리가 원하는 대로 보안 정책을 지정할 수 있다. 구 버전의 SSL과 TLS, 즉 레거시 클라이언트를 지원할 수도 있다.

SNI

• Server Name Indication의 약어다.
• 여러개의 SSL 인증서를 하나의 웹 서버에 로드해 하나의 웹 서버가 여러 개의 웹사이트를 지원할 수 있게 해준다.
• 이것은 확장된 프로토콜로 최초 SSL 핸드세이크 단계에서 클라이언트가 대상 서버의 호스트 이름을 지정하도록 한다.
• 그러면 클라이언트가 접속할 웹사이트를 말했을 때, ALB는 어떤 인증서를 로드해야 하는지 알 수 있다.
• 이건 새롭게 확장된 프로토콜로 모든 클라이언트가 지원하지 않는다.
• 이 프로토콜은 ALB와 NLB 그리고 cloudFront에서만 동작한다.
• 어떤 로드밸런서에 SSL 인증서가 여러개 있다면 ALB나 NLB 둘중 하나다.

연결 드레이닝 (Connection Draining)

• CLB를 사용하면 연결 드레이닝이라고 부르고 ALB, NLB를 쓰면 등록 취소 지연이라고 부른다.
• 인스턴스가 등록 취소, 혹은 비정상인 상태에 있을 때 인스턴스에 어느 정도의 시간을 준다. 이를 드레이닝이라고 부른다.
• 즉 인스턴스가 드레이닝 되면 ELB는 등록 취소 중인 Ec2 인스턴스로 새로운 요청을 보내지 않는다.
• 연결 드레이닝 파라미터는 매개변수로 표시할 수 있다. 1부터 36000초 사이의 값을 설정 가능하다. 기본은 5분이다.
  • 이 값을 0으로 설정하면 전부 다 비활성화한다는 값이 0 이면 드레이닝도 일어나지 않는다
  • 짧은 요청의 경우에는 낮은 값으로 설정하면 좋다.
  • 예를 들어 1초보다 적은 아주 짧은 요청인 경우에는 연결드레이닝 파라미터를 30초 정도로 설정하면 된다.
  • 그래야 EC2 인스턴스가 빠르게 드레이닝될 테고 그 후의 오프라인 상태가 되어 교체 등의 작업을 할 수 있다.
  • 요청 시간이 매우 긴 업로드 또는 오래 지속되는 요청 등의 경우에는 어느 정도 높은 값으로 설정하면 된다.
  • 그러면 EC2 인스턴스가 바로 사라지지 않음
  • 연결 드레이닝 과정이 완료되기를 기다려야 한다.

ASG(오토 스케일링 그룹)

• ASG의 목표는 스케일 아웃, 즉 증가한 로드에 맞춰 EC2 인스턴스를 추가하거나 감소한 로드에 맞춰 EC2 인스턴스를 제거한다.
• ASG에서 실행되는 EC2 인스턴스의 최소 및 최대 개수를 보장하기 위해 매개변수를 전반적으로 정의할 수 있다.
• 로드밸런서와 페어링하는 경우 ASG에 속한 모든 EC2 인스턴스가 로드 밸런서에 연결된다.
• 한 인스턴스가 비정상이면 종료하고 이를 대체할 새 EC2 인스턴스르 생성할 수 있다.
• ASG는 무료이며 EC2 인스턴스와 같은, 생성된 하위 리소스에 대한 비용만 내면 된다.
• cloudwatch 경보를 기반으로 ASG를 스케일인, 스케일 아웃할 수 있다.
• 클라우드 워치에서 경보가 울리면 스케일 아웃이 발생한다. 경보에 의해 내부에서 자동으로 스케일링이 이루어질 수 있다.
• 경보를 기반으로 정책을 만들면 좋다.

오토 스케일링 그룹 조정 정책

동적 스케일링 정책

대상 추적 스케일링

• 가장 단순하고 쉽다.
• 모든 Ec2 인스턴스에서 오토 스케일링 그룹의 평균 cpu 사용률을 추적해 이 수치가 40%대에 머무를 수 있도록 할 때에 사용한다.
• 이처럼 기본 기준선을 세우고 상시 가용이 가능하도록 한다.

단순/단계 스케일링

• cloud watch 경보를 설정하고 전체 ASG에 대한 CPU 사용률이 70%를 초과하는 경우 용량을 두 유닛 추가하도록 설정할 수 있다.
• 그리고 ASG의 CPU 사용률이 30% 이하로 떨어지면 유닛 하나를 제거한다는 설정도 추가할 수 있다.
• 대신 클라우드 워치 경보를 설정할 때 제거하고 추가할 유닛의 수를 단계별로 정의해야 한다.

예약된 작업

• 나와 있는 사용 패턴을 바탕으로 스케일링을 예상한다.
• 예시로 금요일 오후 5시에 큰 이벤트가 있으니 대비해서 ASG 최소 용량을 매주 금요일 오후 5시마다 자동으로 10개로 늘리는 것이다.

예측 스케일링 정책

• 예측 스케일링을 통해서 aws 내 오토 스케일링 서비스를 활용하여 지속적으로 예측을 생성할 수 있다
• 기존 로드를 보고서 다음 스케일링을 예측하는 것이다.
• 시간에 걸쳐 과거를 분석하고 예측을 생성한다.
• 그리고 이 예측을 기반으로 스케일링 작업을 예방한다.
• 머신러닝 기반

스케일링 기반이 되는 지표

• CPU 사용률
• 대상별 요청의 수 (참고로 EC2 인스턴스는 한번에 대상별로 1000개의 요청을 최적으로 작동)
• 평균 네트워크 I/O: 평균 네트워크 입출력량을 기반으로 스케일링을 수행 커스텀 메트릭

Scaling Cooldowns (스케일링 휴지)

• 스케일링 작업이 끝날 때마다 인스턴스의 추가 또는 삭제를 막론하고 기본적으로 5분 혹은 300초의 휴지 기간을 갖는 것이 스케일링 휴지다.
• 휴지 기간에는 ASG가 추가 인스턴스를 실행 또는 종료할 수 없다. 이는 지표를 이용해 새로운 인스턴스가 안정화될 수 있도록 하며 어떤 새로운 지표의 양상을 살펴보기 위함이다.
• 따라서 스케일링 작업이 발생할 때에 기본으로 설정된 휴지가 있는지 확인해야 한다.
• 그럴 경우는 작업을 무시하고 아닐 경우에는 인스턴스를 실행 또는 종료하는 스케일링 작업을 수행한다.
• 즉시 사용이 가능한 AMI를 이용해 EC2 인스턴스 구성 시간을 단축하고 이를 통해 요청을 좀 더 신속히 처리하는 것이 좋다.
  • EC2 인스턴스 구성에 할애되는 시간이 적으면 즉시 적용이 가능할테니 말이다
  • 이렇게 활성화 시간이 빨라지면 휴지 기간이 짧아지므로 ASG에서 더 많은 동적 스케일링이 가능해진다.
• 또한 ASG가 일 분마다 지표에 접근할 수 있도록 세부 모니터링 기능등을 사용하도록 설정하고 이와 같은 지표를 신속히 업데이트할 필요가 있다.

참고 자료 https://adityagoel123.medium.com/deep-dive-into-aws-for-developers-part2-2b9e8baf3373

현재 서비스의 특정 화면에서 래플 이벤트의 당첨 확률의 정보를 표기해줘야하는 부분이 존재한다. 회원들의 응모가 이뤄질때마다 당첨 확률의 변동이 발생되어야 한다. 해당 요구사항을 해결하기 위한 방법은 여러가지가 있을 것이다. API를 한번 더 호출하거나, polling 방식을 이용하는 등 다양한 방식이 존재할 것이다.

기존에는 변경된 확률을 즉각 반영해서 회원들에게 노출하지 않고 새로고침(API 호출)을 통해 변경된 확률이 노출되고 있었다. 이를 개선하기 위해 SSE를 활용하였고, SSE 활용을 앞서 현재 비즈니스를 간단한 프로토타입으로 개발하여 테스트를 진행하였다.

먼저, HTTP 기반으로 문제를 해결하기 위한 방법을 알아본 후 간단한 예제 코드로 확인하고자 한다. (단, API 재호출 방식은 제외)

HTTP 문제 해결법

Short Polling

클라이언트가 서버에 주기적으로 요청을 보내는 방식이다. 일정 시간마다 서버에 요청을 보내 데이터 변경이 발생했는지 확인하고 변경이 이뤄졌다면 응답을 받는다.

장점

• 클라이언트 서버 모두 Short Polling 구현이 단순하다.
• 실시간성이 중요하지 않는 요구사항에 적절할 수 있다.
  • QR 코드의 상태를 확인하기 위해 서버에 요청하는 방식 등

단점

• 변경 유무와 관계없이 지속적으로 서버에 요청을 보내 서버 부담이 증가하게 된다.
  • 주기가 짧을 수록 부하는 커진다.
• 네트워크나 HTTP 커넥션을 맺기 위한 비용이 발생하게된다. 불필요한 오버헤드가 발생한다.

Long Polling

요청을 보낸 후 서버에서 데이터 변경이 일어날 때까지 대기하는 방법이다. 실시간 메시지 전달이 중요하지만, 상태 변경이 빈번하지 않는 경우에 적합하다. 서버로 부터 응답을 받은 후 다시 연결 요청을 하기 때문에 상태가 빈번하게 발생하게 된다면 Short Polling과 같이 불필요한 오버헤드가 발생한다.

장점

• 타임아웃 설정을 통해 Short Polling 보다는 HTTP 요청 수가 줄어든다.

단점

• 요청 수를 줄이지만, 각 열린 요청이 여전히 서버에 연결을 유지하고 있다.
• 클라이언트가 많을수록 서버 리소스에 부담이 증가한다.

Web Socket

클라이언트와 서버가 HTTP 기반으로 HandShaking 후 ws 프로토콜을 통해 상호간 응답을 주고 받는 방식. 단, websocket 프로토콜을 처리하기 위해 전이중 연결과 새로운 웹소켓 서버가 필요하다.

장점

• 실시간 전송
• 처음 한 번만 핸드쉐이크 과정만 수행하므로 통신 오버헤드가 낮다.

단점

• 구현이 복잡하다.
• HTTP/1.1 이하에서는 적합하지 않는다.
  • HTTP/1.1 에서는 데이터 전송이 일반적으로 순차적으로 이뤄지기 때문이다. 요청 후 응답 제공 방식.
  • 웹 페이지 상호 작용에는 충분하지만 실시간 통신에는 부족하다.
• 로드 밸런싱, 메시지 크기 제한, 보안 문제 등 다양하게 고려해야 할 사항과 설계의 복잡성이 발생할 수 있다.

Server-Sent Events

클라이언트가 SSE 연결을 설정하면 서버는 연결을 열린 상태로 유지하여 지속적으로 업데이트 내역을 보냅니다. 서버가 정기적으로 클라이언트에 데이터를 푸시해야 하는 상황에 적합하며, 클라이언트는 서버에 정보를 다시 보낼 필요 없이 데이터만 수신한다.

장점

• 구현이 비교적 단순하다.
• 자동 재연결을 지원한다.
• 리소스를 더 효율적으로 사용할 수 있다.
• 새로운 커넥션을 설정하기 위한 오버헤드가 감소한다.

단점

• SSE는 양방향 통신을 지원하지 않으므로 양방향 통신 요구사항에는 적절하지 않는다.
• 서버에 많은 클라이언트가 연결될 경우 서버 리소스 부담이 증가할 수 있다.
• 네트워크 환경이 불안정한 경우 연결 끊김이 발생하게 되고 이로 인해 재연결을 시도하여 오버헤드가 발생할 수 있다.

조금 더 자세히 SSE(Sever-Sent Events) 알아보기

SSE란, Server-Sent Events이며 서버가 클라이언트로 데이터를 실시간으로 보내는 단방향 통신 방식이다.

• 서버는 클라이언트의 요청 없이도 데이터를 전송할 수 있다는 장점이 있다.
• SSE를 통해 진행 상황을 보여주는 프로그레스 바, 실시간 뉴스 피드, 주식 거래 정보, 실시간 모니터링 서비스 등 다양한 상황에서 사용할 수 있다.
• 클라이언트는 서버에 SSE 요청을 보내고(Header정보에 text/event-stream) 서버(text/event-stream + keep-slive)는 해당 요청을 수락하여 이벤트가 발생할 때마다 클라이언트로 메시지를 전달하면서 커넥션이 유지되게 된다.
• SSE는 HTTP 기반이기에 방화벽, 프록시 서버를 통과하는데 문제가 없으며 단방향 통신이 필요한 서비스에 적합하다.
• WebSocket과 달리 서버 설정이 덜 복잡하고, 클라이언트는 별도 라이브러리 없이 쉽게 구현이 가능하다.
• 다만, Client의 수가 늘어날 수록 서버의 부담이 커지기에 Scale-out, 커넥션 유지 최적화 등 전략을 세워야 합니다.

예제

Spring SSE를 활용하여 래플에 응모하기

Spring에서 SSE를 활용해 래플에 응모 후 당첨 확률을 제공하는 프로토타입 기능을 구현하였습니다. 전체 코드는 깃헙에서 확인하시면 됩니다.

SSE + 분산서버

SSE를 사용할 때 단일서버에서는 큰 문제가 생기지는 않는다. SseEmitter가 서버 메모리에 저장되기 때문이다. 그래서 분산서버에서의 문제를 해결하기 위해 Redis의 Pub/Sub 을 이용하기로 하였다.

    /**
     * 래플 참여 시 래플 참여 정보를 저장하고, 래플 정보를 Redis로 Publish 한다.
     *
     * @param raffleId
     * @param memberId
     */
    public void participateInRaffle(Long raffleId, Long memberId) {
        Raffle raffle = raffleRepository.findById(raffleId)
            .orElseThrow(() -> new IllegalArgumentException("해당하는 래플이 존재하지 않습니다."));

        participationRepository.save(Participation.builder()
            .raffleId(raffle.getId())
            .memberId(memberId)
            .build());

        redisOperations.convertAndSend(
            RaffleChannelGenerator.getChannelName(String.valueOf(raffle.getId())),
            RaffleParticipationRequest.of(raffle, memberId)
        );
    }

    public SseEmitter subscribe(final Long raffleId) throws IOException {
        final String id = String.valueOf(raffleId);
        final SseEmitter emitter = createSseEmitter(id);

        // Redis에 새로운 이벤트가 발생하면 자동으로 onMessage 호출
        final MessageListener messageListener = createMessageListenerAndSendToClient(emitter, id);

        // redisMeesageListenerContainer에 새로운 MessageListener를 추가함
        // MessageListener들을 redisMessageListenerContainer에 추가하여 관리한다.
        addMessageListenerToContainer(messageListener, id);

        // emitter 완료되었는지 타임아웃이 났는지
        handleEmitterCompletionAndTimeout(emitter, messageListener);

        return emitter;
    }

테스트

1. 이벤트 구독

http://localhost:9998/api/v1/raffle/1/subscribe

2. 응모진행(데이터 발행)

3. 발행된 데이터가 전송됐는지 확인

• 위와 같이 구독한 클라이언트에서는 이벤트를 전송받을 수 있다.
• 샘플 코드에서는 id가 유니크하지 않다. 마지막 이벤트 데이터가 중요하지 않았기 때문이다.(깃헙에는 유니크한 id를 생성하도록 예제를 수정했으니 필요한 사람은 참고하면 좋을 것 같다.)

4. Redis Monitor

주의할 점

• 우선 테크톡에서 포스팅된 내용을 보시면 좋은 인사이트를 얻을 수 있다고 생각합니다.

1. Timeout 설정

• Timeout 설정을 길게 설정하는 것은 서버 입장에서 좋지 않다. 긴 수명을 가지게 된다면 커넥션 유지, 쓰레드의 퍼포먼스 저하 요소가 될 수 있기 때문이다. 때문에 적절한 Timeout 시간을 설정하는 것이 중요하다.
• 서버에서의 커넥션 연결이 만료되어도 브라우저 레벨에서 자동으로 재연결 요청을 보내기 때문이다.

2. 503 Service Unavailable

• 만료될때까지 서버에서 단 1개의 Event도 전송하지 않는 경우 위 에러가 발생하기 때문에 SseEmitter 객체를 생성하고 응답해주면 간단히 문제를 해결된다.

3. IOException, IllegalStateException

• IOException의 경우 클라이언트에서 브라우저 새로고침 or 브라우저 종료 등이 발생하면 에러가 발생하게 된다.

• IllegalStateException의 경우 Timeout이 발생해서 그런데 아래 사진 처럼 후처리에서 해당 객체들을 제거해주면 된다.

  

4. 재전송시 데이터 유실

• EventStream이 만료되어 클라이언트에서 자동으로 재연결 요청하는 것이 SSE 장점이라고 할 수 있다.
• 하지만, 이때 재연결을 위해 수초가 소요될 수 있는데, 재연결 중에 서버에서 Event를 전송하게 될 경우 유실될 수 있다. 이러한 문제를 해결하기 위해 클라이언트가 마지막 수신 데이터가 무엇인지 알 수 있도록 id를 고유한 스펙으로 설계하였다.
• SSE protocol에 따르면 클라이언트는 Optional하게 Last-Event-ID를 이용해서 마지막으로 본 이벤트를 서버에 알릴 수 있다.
• 이를 통해 미수신한 이벤트도 수신할 수 있다.

마치며

특별한 이유가 있지 않는 이상 애플리케이션을 단일 서버로 구성하는 경우는 별로 없을 것이라고 생각합니다. 현재 저희 서비스 또한 여러 AZ에 걸쳐 분산 서버로 운영되고 있습니다. 그래서 분산 서버 환경에서 동기화 처리가 필요했고 레퍼런스를 조사하다보니 Redis의 Pub/Sub 구조를 선택하게 되었습니다. Redis를 회사에서 사용중에 있었고 SQS와 같은 메세징 서비스와는 다르게 Producer가 생성한 이벤트를 가장 먼저 consume한 consumer만 해당 데이터를 처리할 수 있기 때문에 더욱 적절하다고 생각하였습니다.

현재 저희 서비스에서 특정 래플의 당첨 확률을 보여주고 있는데 확률을 보는 사이에 여러 사용자들이 래플에 응모하게 되면 그 당첨 확률을 변동하게 될 것입니다. 이러한 요구사항에 가장 적절한 방식이라고 생각했기에 SSE를 활용하게 되었습니다. 이번 SSE를 적용한 덕분에 현재는 SSE가 필요한 영역에서 적절하게 사용되고 있습니다.

참고 https://blog.bytebytego.com/p/network-protocols-behind-server-push https://medium.com/techieahead/http-short-vs-long-polling-vs-websockets-vs-sse-8d9e962b2ba8 https://medium.com/@saurabh.singh0829/redis-pub-sub-implementation-f3208e4625c7