Elastic Beanstalk 정복하기 - 4 (인스턴스, 용량, 로드밸런서)

EB 정복하기 - 1

EB 정복하기 - 2

EB 정복하기 - 3 

 

인스턴스

 

 

인스턴스의 루트볼륨, 모니터링, 보안그룹 설정을 해야 한다.

 

루트 볼륨

 

루트 볼륨은 기본적으로 인스턴스 즉 EC2의 저장소를 의미한다. EBS (Elastic Block Storage)를 선택하는데, 각자의 맞는 Storage를 선택하면 된다. (루트 볼륨은 가용영역에 바인딩된다.)

 

1. 컨테이너 기본값: gp2(범용 SSD)로 구성되며, 8GB, 10 IOPS, 125 MiB/s 스펙을 가짐

2. 마그네틱: stl, scl이 존재하는데 stl이 사용됨 (성능은 좋지 않지만 가격이 저렴함)

3. 범용 (SSD): gp2를 사용하는데, 저장 용량에 따라서 처리량과 IOPS가 결정되므로 별다른 이유가 없다면 gp3가 좋음

4. 범용 3 (SSD): gp2의 발전 형태로 저장 용량, 처리량, IOPS를 별도로 지정할 수 있음 (gp2보다 저렴함 웬만하면 이것 선택)

5. 프로비저닝 된 IOPS (SSD): I/O 집중적인 애플리케이션에 사용하면 좋음 

 

성능 관계없이 저렴한 것(마그네틱)을 이용하는 목적이나, I/O 집중적인 애플리케이션(프로비저닝 된 IOPS)이 아닌 이상 gp3가 가장 이상적인 선택이라고 본다.

 

Amazon Cloudwatch 모니터링

 

EC2의 지표를 모니터링하는 간격을 설정한다. 1분, 5분이 있으며 각자 선택하면 되는데, 1분 간격이 5분 간격 지표 수집을 하기 많이 때문에 비용이 많이 나온다. 

 

인스턴스 메타데이터 서비스 (IMDS)

 

인스턴스 메타데이터를 조회할 수 있는 서비스다. 대표적인 종류는 인스턴스 ID, 인스턴스 유형, 인스턴스 프로파일이다. 

IMDS는 해당 인스턴스 내에서만 액세스 가능하다. http://169.254.169.254/latest/meta-data/ 로 쿼리를 날리면 된다.

 

중요한 것은 IMDS의 버전이다.

 

IMDSv1: 별다른 보안 처리 없이 조회 가능

IMDSv2: PUT 요청을 통해 시간제한이 있는 토큰을 얻고 나서 사용 가능

 

현재 EB에서 지원하는 모든 플랫폼은 IMDSv2를 지원하므로 해당 버전을 선택하는 것이 좋다.

 

보안 그룹

 

EC2의 보안 그룹으로 인스턴스로 트래픽이 들어오기 전에 VPC 경계에서 트래픽을 검증한다. 해당 트래픽이 보안 그룹에 적합하면 인스턴스로 보내고, 아니면 인스턴스로 보내지 않기에 오류가 뜨면 Connection Timeout이 반환되며, 인스턴스 해당 트래픽을 아예 알지 못한다. (보안 그룹은 VPC와 Region에 바인딩된다.)

 

용량

 

 

 

 

용량은 가장 복잡한 부분으로, 인스턴스의 스케일링, 아키텍처, 스폿 설정을 구성할 수 있다.

 

오토 스케일링 그룹

 

여러 가지 조합이 있다.

 

1. 단일 인스턴스 (온디맨드)

2. 단일 인스턴스 (스폿)

3. 고가용성

4. 고가용성 (스폿 및 온디맨드)

 

가장 먼저 단일과 고가용성이 나뉘게 되는데, 단일을 사용할 경우 로드밸런서가 존재하지 않아 Public Subnet에 인스턴스를 배치해야 한다. 고가용성을 선택하는 경우 로드밸런서를 Public Subent에 두고, 인스턴스를 Private Subent에 둠으로써 외부 접근을 제한하도록 구성하는 것이 좋다. 

 

이제 스폿 인스턴스는 온디맨드에 비해서 최대 90퍼센트까지 저렴하게 사용할 수 있는 유형으로, 사용자 상한 가격을 선택하여 그것보다 적으면 인스턴스를 사용할 수 있다. 문제는 사용자가 설정한 가격보다 스팟 인스턴스의 가격이 비싸지만 인스턴스가 회수된다. Production의 경우 중단될 예정인 인스턴스에 대한 대처가 필요하다.

 

스팟 인스턴스 설정

 

 

스팟 인스턴스 설정에는 크게 3가지가 있다.

 

1. 최고 스팟 가격

 

기본 값과 최고 가격 설정이 옵션으로 존재한다. 

기본 값은 온디맨드 인스턴스의 가격을 상향선으로 설정한다. 예를 들어서 온디맨드 가격이 1 USD이면, 1 USD미만 까지는 사용하고, 1 USD가 넘어가면 회수 절차가 진행된다.

 

최고 가격 설정은 사용자가 직접 정하는 옵션이다. 어디까지나 사용자에게 달려있어서, 온디맨드보다 비싸게 설정해도 무방하지만 스폿 인스턴스의 비용 측면의 장점을 가져갈 수 없다.

 

2. 온디맨드 기준

 

오토스케일링 그룹에서 온디맨드 인스턴스의 최소 개수이다. 3을 설정하면, 최소 3개의 온디맨드 인스턴스가 존재한 후에야 스팟 인스턴스의 프로비저닝을 고려하게 된다. 

 

3. 기준 이상의 온디맨드

 

오토스케일링 그룹에서 온디맨드 인스턴스와 스팟 인스턴스의 비율에 대한 설정인데 위에 설명한 온디맨드 기준의 인스턴스는 제외한 값이다. 

 

즉 온디맨드 기준 = 3, 기준 이상의 온디맨드 = 50 %라고 가정하자.

 

4개의 인스턴스가 필요해지면, 온디맨드 기준으로 인해서 온디맨드 인스턴스 3개 + 스팟 or 온디맨드로 결정된다.

이때 온디맨드 기준 이상의 옵션의 경우 온디맨드 기준(3개)을 고려하지 않으므로 온디맨드와 스폿 비율이 0:0이므로 온디맨드 인스턴스가 추가돼 4개 모두 온디맨드가 된다. 

 

5개인 경우에는 온디맨드 기준 3 + 온디맨드 1 + 스팟 인스턴스 1로 구성되게 된다. 

 

4. 용량 재분배

 

스폿 인스턴스를 활성화 했을 때 사용할 수 있는 옵션으로 스팟 인스턴스를 사용할 때 단점인 중단 위기를 어느 정도 해소가 가능하다.

설정해 놓은 가격을 뛰어넘을 경우 이벤트가 발생하는데, 해당 이벤트를 기반으로 스폿 -> 온디맨드로 교체하는 플로우가 시작된다.

 

아키텍처 설정

 

아키텍처는 x86_64, arm64가 있으며, arm64가 20% 정도 가격대비 좋은 성능으로 서비스할 수 있다고 한다. 아키텍처를 바꿨을 때 애플리케이션이 정상 동작하는지 확인해봐야 한다.

 

인스턴스 유형

 

 

인스턴스가 시작될 때 어떤 유형인지 결정하는 옵션이다. 지정한 순서대로 우선순위가 부여된다.

동일한 vcpu, memory를 설정하는 것이 성능 튜닝 및 안정적인 서비스를 기대할 수 있다.

 

AMI ID

 

Amazon Machine Image ID로서 이전에 선택한 플랫폼 및 아키텍처를 기준으로 입력되는데, 변경하지 않아도 된다. 

 

스케일링 쿨다운

 

 

스케일링 쿨다운음 스케일링 업 혹은 다운이 동작한 다음에 일정 시간 동안 스케일링을 하지 않는 시간을 의미한다. 디폴트가 360초이고, 애플리케이션 성격에 알맞게 조정하면 된다.

 

크기 조정 트리거

 

오토스케일 업, 다운 이벤트를 언제 발생시킬지 설정하는 옵션이다.

 

1. 지표: 어떤 지표를 트리거로 할 건지

2. 통계: Sum, Average, Maximum

3. 단위: Percent, Count, Count/Second

4. 기간: Amazon CloudWatch가 트리거의 측정치를 측정하는 빈도

5. 위반 기간: 조정 작업을 트리거하기 전 측정치가 상한 또는 하한 임계값을 벗어날 수 있는 시간

6. 상위 임계값: 이것을 넘으면 스케일 업

7. 스케일 업 증가분: 몇 개씩 스케일 업할 것인지

8. 하위 임계값: 이것보다 적으면 스케일 다운

9. 스케일 다운 감소분:  몇 개씩 스케일 다운할 것인지

 

로드 밸런서 유형

 

 

로드밸런서 유형은 2가지 고를 수 있고, 새롭게 만들 것인지 선택할 수 있다.

 

Application Load Balancer: 프로토콜, 포트, URI 등을 기반으로 트래픽을 분산함

Network Load Balancer: IP를 기반으로 트래픽을 분산함

 

전용: EB만의 새로운 로드 밸런서를 생성

공유됨: 이미 존재하는 로드 밸런서를 사용함

 

리스너, 프로세스, 규칙

 

 

 

리스너: Client -> LB로 들어온 요청을 프로세스(타깃 그룹)에 라우팅함

프로세스: LB -> 타깃그룹에 라우팅 할 때 프로토콜과 포트를 지정함

규칙: 우선순위를 지정한 후 트래픽 처리 방법을 명시함 (대표적인 예로 HTTP로 온 요청을 HTTPS로 리다이렉트)

 

로그 파일 액세스

 

 

로드 밸런서로 전송된 요청에 대한 로그를 S3에 저장할 수 있다. S3에 저장한 후 Athena에 쿼리 하면서, WAF를 구성할 때 도움이 될 수 있다.