[스터디15] 04. ELB & Auto Scaling & ECS & Lambda & API Gateway & DynamoDB

목차

11장. 백엔드 서비스 이해하기

프론트엔드가 사용자에게 보여질 시각적인 부분을 담당한다면, 백엔드는 사용자가 볼 수 없는 데이터 처리와 보안을 담당한다. AWS는 백엔드 서비스로 아마존 EC2 오토스케일링, 아마존 ECS, 아마존 다이나모DB, 아마존 API 게이트웨이, AWS 람다, 탄력적 로드 밸런서 등을 제공한다.

11.2 부하 분산 서비스, 탄력적 로드 밸런서란?

탄력적 로드 밸런서(ELB)는 사용자가 급증하더라도 트래픽을 적절하게 부하 분산해 서버를 안정적으로 운영할 수 있게 해주는 서비스이다. 웹 서버 앞에 배치되며 사용자는 로드 밸런서를 경유해 웹사이트에 접근하게 되므로, 외부로 웹 서버를 공개할 필요가 없어져 보안이 강화된다.

 

사용자가 인터넷을 통해 접근할 수 있도록 로드 밸런서는 퍼블릭 서브넷에 배치되며, 접속용 DNS 이름을 별도로 제공한다. 아마존 라우트53과 연동하면 EC2 인스턴스가 아닌 로드 밸런서에 도메인을 할당할 수 있어, 사용자와 EC2 인스턴스 간 직접적인 접근을 완전히 차단할 수 있다. 그 외에도 EC2 오토스케일링, 아마존 ECS, 클라우드프론트, S3와 연동할 수 있다.

11.3 탄력적 로드 밸런서 살펴보기

탄력적 로드 밸런서는 ALB, NLB, GWLB 유형을 제공하며, 유형에 따라 부하 분산이 이루어지는 계층이 결정된다.

유형	동작 계층	특징
ALB	응용 계층(7계층)	HTTP 혹은 HTTPS 트래픽을 라우팅하며, 경로 기반 라우팅 같은 고급 웹 기능을 제공한다.
NLB	전송 계층(4계층)	TCP 혹은 UDP 트래픽을 라우팅한다. ALB와 달리 고정 IP를 사용할 수 있어, 연결 대상을 IP로 제한해야 하는 상황에 유용하다.
GWLB	네트워크 계층(3계층)	2020년 11월에 추가된 유형으로, 주로 타사 제품을 AWS로 마이그레이션할 때 사용되며 웹사이트 구축 용도로는 적합하지 않다.

11.3.1 로드 밸런서의 작동 방식

로드 밸런서는 퍼블릭 서브넷에 생성할지 프라이빗 서브넷에 생성할지 선택할 수 있다. 로드 밸런서를 생성하면 선택한 서브넷에 로드 밸런서 노드가 만들어지고, 이 노드로 각 가용 영역을 구분해 부하 분산을 수행하게 된다.

• 퍼블릭 서브넷 선택: 퍼블릭 서브넷에 로드 밸런서 노드가 생성되어 인터넷을 통해 웹 서비스에 접근할 수 있다.
• 프라이빗 서브넷 선택: 노드가 프라이빗 서브넷에 생성되므로 인터넷을 통한 외부와의 통신이 불가능해진다. 사내에서만 특정 웹 서비스를 제공할 때 사용한다.

따라서 로드 밸런서를 생성할 때 외부로 공개할지 내부에서만 사용할지를 설계 단계에서 반드시 고민해야 한다. 또한 로드 밸런서는 EC2 인스턴스와 동일하게 보안 그룹을 설정할 수 있어, 로드 밸런서는 모두에게 열어두고 EC2 인스턴스는 로드 밸런서의 접근만 허용하도록 수정하면 외부 사용자가 인스턴스에 직접 접근할 수 없는 환경이 구성된다.

11.3.2 로드 밸런서의 대상 그룹과 리스너

로드 밸런서 노드는 어디까지나 가용 영역을 구분하는 용도로 생성되는 것이며, 부하 분산을 할 EC2 인스턴스를 선택할 수는 없다. 이 문제를 해결하는 것이 대상 그룹과 리스너이다.

• 대상 그룹(Target Group): 로드 밸런서 노드와 EC2 인스턴스 사이의 중간 다리 역할을 하며, 부하 분산을 시도할 EC2 인스턴스를 등록하고 관리한다. 지정한 포트로 상태 확인(Health Check)을 수행해 정상이면 healthy, 비정상이면 unhealthy를 반환한다. 대상 그룹은 n개로 나눌 수 있으므로 EC2 인스턴스의 역할에 맞추어 구분하는 것이 바람직하다.
• 리스너(Listener): n개의 대상 그룹을 운영할 때 어떤 방식으로 접근할지 설정하는 기능이다. 리스너 규칙에서 프로토콜과 포트를 지정해 대상 그룹을 연결지을 수 있다.

자주 사용되는 리스너 규칙은 다음과 같다.

• 포트 기반 라우팅: HTTPS:443으로 접속하면 대상 그룹 A, HTTPS:444로 접속하면 대상 그룹 B로 연결되도록 포트로 접근 방법을 구분한다.
• 경로 기반 라우팅: /web으로 접근하면 EC2 인스턴스 A, /api로 접근하면 EC2 인스턴스 B로 라우팅한다. /admin 경로는 관리자 전용 기능에만 접근하도록 설정해 보안을 강화할 수도 있다.
• 고정 응답 반환 규칙: 잘못된 URL로 접근했거나 웹 서버가 점검 중일 때 응답 코드와 텍스트를 반환한다. HTML, 자바스크립트, JSON 등 다양한 형식으로 반환할 수 있다.

더 안전한 통신인 HTTPS(443)나 TLS를 사용하려면 사용자 컴퓨터와 서버 사이의 암호화된 연결이 필요하므로, AWS ACM에서 SSL/TLS 인증서를 발급받아 로드 밸런서에 등록해야 한다. 이 경우 로드 밸런서와 EC2 인스턴스 사이는 HTTP 80번 포트로 통신하더라도 사용자는 HTTPS로 안전하게 웹사이트에 접근할 수 있다.

11.3.3 부하 분산을 위한 로드 밸런서의 알고리즘

• 라운드 로빈: 클라이언트로부터 받은 요청을 대상 서버에 순서대로 할당한다. 대상 서버의 성능이 동일하고 처리 시간이 짧을 때 주로 사용한다.
• 가중치 랜덤: 정상 작동하는 서버에 임의의 순서로 요청을 라우팅한다. ATW(Automatic Target Weights)와 함께 동작해 장애나 성능 저하를 감지하면 자동으로 다른 서버로 트래픽을 전달한다.
• 최소 미해결 요청: 현재 연결 수가 가장 적은 서버로 라우팅하는 동적 알고리즘이다.

이런 알고리즘은 ALB에서 사용되며, NLB는 AWS 하이퍼플레인이라는 독자적인 부하 분산 기술을 사용한다. 또한 교차 영역 로드 밸런싱은 ALB에서 항상 유효화되어 있어 무효화할 수 없지만, NLB는 기본적으로 무효화되어 있다. 무효화 상태에서는 하나의 가용 영역에 있는 인스턴스가 50%, 다른 가용 영역의 인스턴스들이 각각 12.5%를 처리하는 식으로 불균등하게 분산되므로, 가용 영역별 균등한 부하 분산을 원한다면 별도로 유효화 설정을 해야 한다.

11.3.4 환경별 로드 밸런서 구성 패턴 살펴보기

서비스를 제공하기 전에는 개발 환경이나 테스트 환경에서 애플리케이션을 검증한 뒤 실전 환경으로 배포한다. 이때 로드 밸런서를 구성하는 패턴은 두 가지이다.

• 환경별로 나누는 패턴: 개발 환경의 문제가 실전 환경에 영향을 주지 않고, 트래픽과 리소스 사용률을 분리해 관리할 수 있으며, 환경별로 액세스 제어 정책과 확장을 독립적으로 적용할 수 있는 가장 일반적이고 이상적인 패턴이다.
• 하나로 제어하는 패턴: 포트 기반 혹은 경로 기반 라우팅으로 두 환경을 구분한다. 리스너 규칙이 복잡해지고 로드 밸런서에 장애가 발생하면 두 환경 모두가 영향을 받으므로, 같은 EC2 인스턴스나 같은 환경 내에서 여러 경로로 나누고 싶을 때 사용하는 것이 좋다.

12장. 클라우드 서버 최적화를 위한 백엔드 서비스 파악하기

12.1 클라우드 서버 최적화, 아마존 EC2 오토스케일링이란?

오토 스케일링은 클라우드 서버를 최적화하기 위해 다음 세 가지 작업을 구현하는 데 사용된다.

• 스케일업: 기존 EC2 인스턴스의 사양(CPU, 메모리, 디스크 용량 등)을 업그레이드해 성능을 향상시킨다.
• 스케일아웃: 같은 사양의 서버를 추가해 부하를 분산시키고 가용성을 향상시킨다.
• 스케일인: 스케일아웃 목적으로 생성된 서버가 더는 필요 없을 때 삭제한다.

참고로 AWS 오토스케일링은 아마존 EC2 오토스케일링을 포함해 ECS, 다이나모DB, 오로라 등 다양한 서비스의 스케일링을 중앙 집중식으로 관리하는 서비스이고, 아마존 EC2 오토스케일링은 그중 EC2 인스턴스의 스케일링을 담당하는 서비스이다.

12.2 클라우드 서버 최적화 서비스, 아마존 EC2 오토스케일링 살펴보기

오토스케일링 그룹을 생성하려면 인스턴스 유형, 보안 그룹, AMI 같은 기본적인 EC2 인스턴스 구성을 설정해야 하는데, 이때 사용하는 것이 시작 템플릿이다. 시작 템플릿에 설정한 값을 바탕으로 오토스케일링 그룹을 생성하면 같은 설정값을 가진 EC2 인스턴스가 생성되며, 이렇게 만들어진 인스턴스는 오토스케일링 그룹에 속해 관리된다.

 

시작 템플릿은 복수의 버전을 만들어 관리할 수 있다. 서로 다른 설정을 가진 버전을 생성해두고 상황에 맞추어 오토스케일링 그룹에 적용하면, 스케일업으로 인스턴스 스펙을 업그레이드하거나 다양한 설정을 적용할 수 있다.

12.2.1 클라우드 서버 최적화 백엔드 서비스, 오토스케일링 그룹이란?

오토스케일링 그룹 크기

그룹 크기	설명
원하는 용량	오토스케일링 그룹을 만들 때 생성할 초기 EC2 인스턴스 수이다.
최소 용량	수동이든 자동이든 이보다 적게 만들 수 없다. 인스턴스를 삭제해도 최소 용량을 유지하고자 새 인스턴스가 생성된다.
최대 용량	수동이든 자동이든 이 값을 초과해 인스턴스를 늘릴 수 없다.

예를 들어 원하는 용량 2, 최소 용량 2, 최대 용량 3으로 설정하면 그룹 생성 시 두 대가 만들어지고, 한 대를 삭제하더라도 항상 두 대가 유지되며, 세 대를 초과하는 인스턴스는 생성할 수 없다. 이런 용량 설정은 고정되는 것이 아니라 생성 이후에도 업데이트할 수 있다.

오토스케일링 그룹과 로드 밸런서

오토스케일링 그룹은 확장성과 가용성을 고려해 로드 밸런서와 함께 사용하는 것이 권장된다. 두 서비스 모두 상태 확인 기능을 제공하지만 결과 처리 방식이 다르다.

• 로드 밸런서만 사용: 상태 확인에 실패해 unhealthy가 발생하더라도 EC2 인스턴스의 교체 작업은 이루어지지 않는다.
• 오토스케일링 그룹과 연결: unhealthy가 발생한 인스턴스를 그룹에서 제외시키고 새로운 인스턴스를 가동해 그룹에 추가한다. 이때 빠져나온 인스턴스는 삭제되지 않고 하나의 EC2 인스턴스로 분류된다.

로드 밸런서에서의 상태 확인은 선택할 수 있는 옵션이 아니었으나, 오토스케일링 그룹에서의 상태 확인 옵션은 사용자가 임의로 선택할 수 있으며 해제하면 unhealthy가 발생해도 인스턴스를 교체하지 않는다.

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

정책	설명
대상 추적 크기 조정	평균 CPU 사용률, 평균 네트워크 입력/출력, 대상당 ALB 요청 수 중 하나를 선택해 해당 지표를 기준으로 스케일링한다.
단계 크기 조정	클라우드워치 경보를 기반으로 스케일링하며, 추가하거나 삭제할 인스턴스 수를 설정할 수 있다.
단순 크기 조정	클라우드워치 경보 기반이지만 다음 스케일링까지 대기 시간이 존재한다. 트래픽에 빠르게 대응해야 하는 만큼 현재는 사용이 권장되지 않는다.
예측 크기 조정	머신러닝으로 클라우드워치의 24시간 기록을 분석해 향후 수요를 미리 예측한다. 동적 크기 조정 정책과 함께 사용하면 더 최적의 정책을 구성할 수 있다.
예약된 작업	지정한 날짜와 시간에 스케일링을 실시하며, 매일·매주 같은 반복 설정도 가능하다.

오토스케일링 그룹과 AMI

오토스케일링 그룹은 생성 시 설정한 값을 바탕으로 인스턴스를 만들기 때문에, 사용자가 수동으로 설치한 소프트웨어는 스케일 작업으로 새로 생성된 인스턴스에 적용되지 않는다. 따라서 소프트웨어를 설치한 인스턴스의 AMI를 생성하고, 오토스케일링 그룹의 AMI를 이 AMI로 교체하는 방식으로 해결한다. 즉, 오토스케일링 그룹을 사용할 때는 AMI를 어떻게 활용할지 고민하는 것이 중요하다.

 

그 밖에 스케일인 시 어떤 인스턴스부터 삭제할지 결정하는 종료 정책도 제공한다. 기본값, 할당 전략, 가장 오래된 시작 템플릿, 가장 오래된 시작 구성, 다음 인스턴스 시간과 가장 가까움, 최신 인스턴스, 가장 오래된 인스턴스 중에서 환경에 맞추어 선택할 수 있다.

13장. 컨테이너를 위한 백엔드 서비스 파악하기

13.1 컨테이너 서비스, 아마존 ECS란?

아마존 ECS(Elastic Container Service)는 AWS에서 도커 컨테이너를 배포하고 운영, 관리하는 완전 관리형 컨테이너 서비스이다. ECS를 이해하려면 먼저 도커와 컨테이너를 알아야 한다.

 

도커는 환경 불일치를 해결하는 오픈 소스 프로젝트이다. 같은 작업물이 윈도우에서는 정상 동작하지만 우분투에서는 동작하지 않는 상황을 환경 불일치라고 하는데, 도커는 다른 컴퓨터에서도 같은 개발 환경을 구성할 수 있게 해준다.

• 도커파일: 구성하고자 하는 환경을 정의한 설정 파일로, 파일명은 반드시 Dockerfile 혹은 dockerfile로 지정해야 한다. FROM(베이스 이미지), MAINTAINER(작성자), COPY(호스트 파일 복사), EXPOSE(노출할 포트), CMD(시작 시 실행할 기본 명령) 등의 명령어를 사용한다.
• 도커 이미지: 도커파일을 빌드하면 생성되는 정적인 상태의 결과물이다. 도커허브에서 다른 사람이 만든 이미지를 내려받아 사용할 수도 있다.
• 컨테이너: 도커 이미지를 실행하면 정적인 상태에서 동적인 상태로 변하며 컨테이너가 된다. 컨테이너는 독립적이므로 하나의 서버에 우분투용, 엔진엑스용, PHP용 컨테이너를 각각 만들어 운영할 수 있다.

생명주기는 docker pull로 이미지를 내려받고, docker create로 컨테이너화한 뒤 docker start로 시작하는 흐름이다. docker run은 이미지를 내려받고 곧바로 컨테이너를 시작하는데, 실행할 때마다 컨테이너를 새로 생성하므로 컨테이너화가 필요할 때만 사용하는 것이 좋다. 중지는 docker stop, 일시 정지는 docker pause, 삭제는 docker rm(이미지는 docker rmi)을 사용한다.

13.2.1 컨테이너 서비스, 아마존 ECR 살펴보기

아마존 ECR(Elastic Container Registry)은 정적인 도커 이미지를 보관하는 서비스이다. AWS CLI를 사용해 이미지를 ECR로 푸시하면 별도의 환경 없이 AWS에서 중앙집중식으로 이미지를 관리할 수 있다.

 

이미지를 푸시하려면 리포지토리를 별도로 생성해야 하며, 리포지토리는 IAM 등 특정 권한을 가진 사용자만 사용하는 프라이빗과 누구나 사용할 수 있는 퍼블릭으로 나뉜다. 이 설정은 생성 후 재설정이 불가능하므로 목적을 명확히 생각해 설정할 필요가 있다.

13.2.2 컨테이너 서비스, 아마존 ECS 구성 요소

작업 정의와 네트워크 모드

작업 정의(task definition)는 ECR의 이미지를 비롯한 컨테이너의 전체적인 구성을 정의하는 작업이다. 작업 이름, 컨테이너 이름, 사용할 이미지, 포트 번호, 환경 변수, 연결할 볼륨, 실행 역할, 네트워크 모드가 포함되며, 네트워크 모드는 네 가지 중에서 선택할 수 있다.

모드	특징
호스트	호스트의 ENI를 사용해 통신하며, 호스트에서 사용하는 포트가 곧 컨테이너 포트가 된다. 컨테이너의 네트워크 네임스페이스가 호스트와 공유되어 이미 사용 중인 포트를 중복해서 사용할 수 없으며, 로드 밸런서를 통한 부하 분산이 불가능하다.
브리지	브리지의 동적 매핑 기능으로 호스트 포트와 컨테이너 포트를 별도로 지정할 수 있다. 호스트 포트를 0으로 지정하면 에페메랄 포트(32768~61000)에서 동적으로 매핑되지만, 포트 제어가 어려워지므로 주의가 필요하다.
awsvpc	각 컨테이너마다 ENI를 생성하며, VPC 내에서 자체 사설 IP가 할당된다. 컨테이너별 보안 설정이 가능해 가장 유연하지만, 생성할 수 있는 ENI 수에 제한이 있다.
없음	포트 매핑과 외부 연결이 모두 차단된다. 로그 수집, 데이터 교환, 데이터베이스 등 네트워크 기능이 불필요할 때 사용한다.

작업, 서비스, 클러스터

• 작업(Task): 작업 정의를 기반으로 시작한 컨테이너의 모음이다. 엔진엑스와 마리아DB처럼 여러 컨테이너를 단일 작업 내에서 실행시킬 수도 있다.
• 서비스(Service): 작업을 관리한다. 작업 수를 2로 설정했다면 하나가 실패하더라도 자동으로 새 작업을 시작해 항상 2가 유지되도록 한다. 컨테이너의 시작 유형과 보안 그룹, VPC, 서브넷도 여기서 선택한다.
• 클러스터(Cluster): 서비스와 작업을 포함하는 컨테이너 관리 및 배포를 위한 컴퓨팅 자원의 집합이다. 여러 EC2 인스턴스나 파게이트 작업으로 구성된다.

시작 유형은 EC2 인스턴스와 파게이트 중 선택할 수 있다. 파게이트는 컨테이너를 서버리스로 실행할 수 있게 해주며, 필요한 리소스를 자동으로 관리하고 실행 환경을 프로비저닝하므로 운영체제 관리나 운용 보수를 신경 쓰지 않고 애플리케이션에만 집중할 수 있다.

14장. 이벤트 기반 코드 실행 백엔드 서비스 파악하기

14.1 이벤트 기반 코드 실행 서비스, AWS 람다란?

AWS 람다는 서버를 구축하지 않고도 작성한 코드를 실행할 수 있는 이벤트 구동형 프로그램 실행 환경이다. 넓은 의미로는 서버리스이며, 더 명확하게는 FaaS(Functions-as-a-Service)로 표현할 수 있다. 서버리스는 스토리지, 데이터베이스, 컴퓨팅 등 다양한 서비스 범주에 중점을 두며, FaaS도 이 안에 포함된다.

• IaaS: 스토리지, 네트워크, 서버와 같은 하드웨어 리소스를 제공한다. 대표적으로 아마존 EC2가 있다.
• PaaS: 애플리케이션을 개발하고 테스트, 배포하기 위한 환경을 제공한다. AWS 엘라스틱 빈스토크, 아마존 S3가 이에 해당한다.
• SaaS: 최종 사용자를 위한 소프트웨어로, 구글 닥스와 같은 서비스가 해당한다.
• FaaS: 개별 함수를 클라우드에서 실행하는 서버리스 아키텍처로, 개발자는 특정 이벤트가 발생할 때 실행되는 함수만 작성하면 된다.

14.2.1 이벤트 기반 코드 실행 서비스, AWS 람다 이점

• 비용 절감: 코드 실행 시간과 요청 수에 따라 비용이 청구되므로 실행되지 않을 때는 비용이 발생하지 않는다. 이벤트가 많지만 실행 시간이 짧을 때 특히 유리하며, 별도의 서버를 준비할 필요가 없어 서버 관리 비용도 절감된다.
• 보다 안전한 실행 환경: AWS가 실행 환경을 관리하며, 보안 전문가 팀이 24시간 시스템을 모니터링한다.
• 장애 위험 부담 감소: 서버 관리를 AWS가 담당하므로 람다 함수에 장애가 발생해도 AWS가 대응한다.
• 다양한 프로그래밍 언어 제공: 직접 코드를 작성하거나 AWS가 제공하는 템플릿을 사용해 함수를 생성할 수 있다.
• 다른 AWS 서비스와의 연동: 아마존 S3, API 게이트웨이, 다이나모DB 등과 연동해 서버리스 웹 호스팅 같은 구성을 만들 수 있다.

14.2.2 이벤트 기반 코드 실행 서비스, AWS 람다 구성 요소

람다 함수는 새로 작성, 블루프린트 사용, 컨테이너 이미지 세 가지 유형으로 생성할 수 있다. 블루프린트를 사용하면 샘플 코드를 제공받아 더 간편하게 함수를 작성할 수 있다.

 

새로 작성하는 함수는 함수 이름, 런타임, 아키텍처, 권한으로 구성된다.

• 런타임: 함수에서 사용하는 프로그래밍 언어 또는 프레임워크의 버전을 의미하며, 2025년 기준 .NET 8, 자바 21, Node.js 22.x, 파이썬 3.13, 루비 3.4, 아마존 리눅스 2023을 지원한다.
• 아키텍처: 사용할 컴퓨터 프로세서의 유형으로 x86_64와 arm64 중에서 선택한다.
• 권한: 람다 함수는 다양한 AWS 서비스와 연동되므로 연동하려는 각 서비스에 대한 권한이 필요하며, IAM 서비스를 이용해 부여한다.

15장. API 관리를 위한 백엔드 서비스 파악하기

15.1 API 관리 백엔드 서비스, 아마존 API 게이트웨이란?

API는 소프트웨어나 애플리케이션 기능의 일부를 외부에 공개하는 것으로, 애플리케이션 A에서 애플리케이션 B의 기능을 사용할 때 요청을 보내고 응답을 받아 작동한다. 쇼핑몰의 결제 기능을 직접 개발하는 대신 카드사나 은행에서 제공하는 API를 이용하면, 보안 문제를 직접 처리할 필요 없이 간편하게 기능을 구현할 수 있다.

 

아마존 API 게이트웨이는 이런 API를 간편하게 구축하고 게시하고 모니터링할 수 있게 도와주는 완전 관리형 서비스이다. 게이트웨이를 사용하지 않으면 애플리케이션이 결제, 장바구니, 주문 목록, 재고 관리 API와 각각 개별적으로 통신해야 하지만, 게이트웨이를 두면 애플리케이션은 게이트웨이하고만 통신하면 되므로 API 남용을 방지해 비용을 줄이고 개발자의 부담을 덜 수 있다. AWS 람다와 연계해 다양한 이벤트 처리를 수행하는 것도 가능하다.

15.2.1 API 관리 백엔드 서비스, 아마존 API 게이트웨이 장단점

• 효율적인 API 개발: 특정 API의 다양한 버전을 실행하고 최소한의 노력으로 테스트하고 반복 및 업데이트할 수 있는 환경을 제공한다.
• 간편한 모니터링: API 호출 정보, 오류율, 데이터 대기 시간 등을 실시간으로 모니터링할 수 있으며, 클라우드워치와 함께 쓰면 데이터를 시각적으로 확인할 수 있다.
• 비용 절감: API를 사용하는 만큼 비용이 발생하며 무료 티어가 제공된다.
• 생산성: 클라우드프론트와 통합되어 글로벌 엣지를 활용해 최적의 대기 시간으로 API 요청과 응답을 처리한다.
• 단점: 모든 API를 통합해 처리하기 때문에 게이트웨이에 문제가 발생하면 전체 API의 동작이 멈추게 된다. 또한 타사 API를 사용하는 경우 해당 API의 보안에 개발자가 직접 관여할 수 없다.

15.2.2 API 관리를 위한 백엔드 서비스, 아마존 API 게이트웨이 구성 요소

API 유형	설명
REST API	REST 규칙으로 만든 API로, 리소스를 생성하거나 검색하고 업데이트 및 삭제하는 작업에 적합하다.
REST API 프라이빗	REST API와 동일하지만 VPC 내에서만 접근할 수 있도록 제한된 API이다.
HTTP API	REST의 네 가지 원칙을 반드시 적용하지 않는 API로, REST API에 비해 대기 시간이 짧고 비용 효율적이다.
웹소켓 API	양방향 통신 프로토콜로, 하나의 TCP 연결로 송신과 수신을 동시에 실시할 수 있다. 채팅이나 게임처럼 실시간성이 요구될 때 적합하다.

REST의 네 가지 원칙

• 주소 가능성: 제공하는 정보가 URI를 통해 표현될 수 있으며, 각 정보는 고유한 URI를 가진다.
• 상태 비저장: 정보를 교환할 때 상태를 유지하지 않고 요청과 응답을 한 번만 사용해 완료한다. 반대로 상태 저장은 상태를 유지해 연속적인 상호작용을 가능하게 한다.
• 연결성: 정보 내에 다른 리소스에 대한 링크가 포함되어 서로 상호 작용이 가능하다.
• 통일 인터페이스: 미리 정의한 공유 방식을 의미하며, 대표적으로 HTTP 메서드(GET, PUT, POST, DELETE)가 있다.

16장. 유연한 NoSQL 데이터베이스 서비스 파악하기

16.1 유연한 NoSQL 데이터베이스 서비스, 아마존 다이나모DB란?

아마존 다이나모DB는 AWS가 제공하는 NoSQL 데이터베이스로, SQL을 사용하지 않고 고정된 스키마도 없으며 데이터를 키-밸류 형식이나 JSON 형식으로 저장한다. 구조가 단순해 높은 확장성과 빠른 처리 속도를 제공하므로 실시간 데이터 분석, IoT, 모바일 애플리케이션에 적합하다.

• 완전 관리형: 인프라 관리를 하지 않아도 되며, OS 패치 같은 정기 유지보수는 AWS가 직접 처리한다.
• 고가용성 및 무제한 스케일링: 자동으로 수평 확장이 가능하고 테이블 크기에 제한이 없으며, 데이터 용량과 트래픽이 증가해도 퍼포먼스가 떨어지는 일이 거의 없다.
• 초저지연성과 내구성: 읽기 및 쓰기 작업에서 밀리초 단위의 지연 시간을 제공하고, 세 개의 가용 영역에 자동으로 데이터를 복제한다.
• 보안 통합과 서버리스 모델: AWS IAM과 통합되어 세부적인 보안 관리가 가능하며, 용량 계획 없이 사용한 만큼만 지불한다.

아마존 RDS는 먼저 VPC를 설계하고 구축해야 하며 그 내부에 생성되지만, 다이나모DB는 VPC 설계 없이도 리전 단위로 생성되고 관리된다. 이렇듯 인프라 유지보수를 클라우드에 맡겨 개발자가 온전히 개발에 집중할 수 있다는 점이 다이나모DB의 강점이며, API 게이트웨이 및 람다와 함께 연동해 서버리스 환경을 구축하는 데 주로 사용된다.

16.2.1 유연한 NoSQL 데이터베이스 서비스, 아마존 다이나모DB 제약

다이나모DB는 키밸류 형태의 NoSQL이므로 대규모 데이터 분석에 적합한 OLAP에는 어울리지 않고, 소규모 데이터를 대량으로 처리하는 OLTP에 적합하다. 쇼핑몰에서 구매부터 결제, 발송 수속까지 이어지는 일련의 처리가 OLTP에 해당한다.

• 트랜잭션 제약: 단일 트랜잭션 내의 개별 작업을 최대 100건까지만 설정할 수 있어, 수천 혹은 수백만 건을 처리하는 RDS에 비하면 적은 처리 양이다.
• 검색 조건의 유연성 제약: 인덱스 구조에 크게 의존하므로 SQL처럼 복잡한 쿼리 패턴을 처리하는 데 제약이 있다.
• JOIN 제약: 테이블 간 JOIN을 할 수 없어, 여러 번 쿼리를 실행하거나 단일 테이블에 항목을 정리하는 싱글 테이블 설계가 필요하다.
• 항목 크기: 항목당 크기 상한이 400KB이므로 큰 데이터를 직접 저장하는 용도로는 적합하지 않다.

구분	아마존 다이나모DB	아마존 RDS
유형	NoSQL	SQL
검색 조건	사전에 지정된 키 또는 인덱스로만 검색 가능	SQL문으로 자유롭게 검색 가능
검색 처리	JOIN 연산을 지원하지 않아 복잡한 검색 처리를 할 수 없음	JOIN 연산을 통한 복잡한 검색 처리 가능
확장성	높은 확장성을 제공해 많은 양의 트래픽 처리 가능	쿼리 처리는 뛰어나지만 리드 복제본 생성 등 추가 설정이 필요
사용 사례	실시간·모바일 애플리케이션 및 IoT 디바이스의 데이터 관리에 적합	복잡한 관계와 일관된 트랜잭션 처리가 필요한 비즈니스 및 금융 시스템에 적합

16.2.2 유연한 NoSQL 데이터베이스 서비스, 아마존 다이나모DB 구성 요소

파티션과 키

다이나모DB의 데이터는 여러 파티션에 분산되어 저장되며, 어느 파티션에 저장되는지는 파티션 키로 결정된다. 정렬 키가 설정된 경우 파티션 내에서 정렬 키를 기준으로 정렬되어 물리적으로 가깝게 배치되고, 기본키는 파티션 키 또는 파티션 키와 정렬 키의 복합 키를 의미한다. 데이터를 읽고 쓰는 작업은 기본적으로 기본키를 지정해 수행되므로, 데이터 접근의 특징에 따라 파티션 키와 정렬 키를 적절하게 설계하는 것이 좋다.

보조 인덱스

테이블의 파티션 키와 정렬 키만으로 충분하지 않을 경우 다른 키를 설정할 수 있는 보조 인덱스를 사용한다.

보조 인덱스	설명
글로벌 보조 인덱스	어느 한 테이블을 바탕으로 다른 파티션 키와 정렬 키를 지정해 테이블을 작성하는 구조이다. 테이블 작성 후에도 설정할 수 있다.
로컬 보조 인덱스	파티션 키는 유지하며 다른 정렬 키만 지정해 테이블을 작성한다. 테이블을 생성할 때 설정해야 한다.

엑셀러레이터와 용량 모드

• 다이나모DB 엑셀러레이터(DAX): 다이나모DB와 호환되는 완전 관리형 인메모리 캐시 서비스이다. 캐시가 있으면 바로 반환하고, 없으면 다이나모DB에 요청해 받은 결과를 캐시에 보존한 뒤 반환하여 밀리초에서 마이크로초로 퍼포먼스를 올린다.
• 온디맨드 모드: 읽기 및 쓰기 용량을 설정하지 않고 자동으로 스케일링하므로 트래픽을 예측할 수 없을 때 유용하다.
• 프로비저닝 모드: 읽기와 쓰기 용량을 설정해 그 값을 상한으로 트래픽을 처리한다. 트래픽을 예측할 수 있을 때 유용하며 오토스케일링으로 용량을 자동 조정할 수 있다.

가용성과 내구성

다이나모DB는 기본적으로 다중 AZ를 지원해 같은 리전 내 3개의 가용 영역 간 데이터가 실시간으로 복제된다. 또한 글로벌 테이블을 생성하면 다중 리전에 걸쳐 테이블을 복제해, 복제 솔루션을 직접 구축하고 관리할 필요 없이 각 리전에 같은 테이블을 만들고 변경 내용을 모든 리전에 전파할 수 있다. 이는 대규모 애플리케이션에 적합하며 사용자가 어디에 있든 낮은 대기 시간으로 데이터를 제공한다.

이 글은 『AWS 잘하는 개발자 되기』책을 학습한 내용을 정리한 것입니다.