[OCI] 로드밸런서, 오토스케일링 설정 (+프리티어 계정 업그레이드)

https://haksuperman.tistory.com/71

[OCI] 애플리케이션 배포 (Feat. Flask, PyMySQL, Faker)

이렇게 배포한 애플리케이션에 접속하는 사용자 수가 증가하면서 애플리케이션 서버를 확장해야 하는 상황을 대비해 오토스케일링이 필요하다. 그리고 이 오토스케일링이 동작하는 상황에서 부하 분산을 하기 위한 로드밸런서 또한 필수적으로 구성해야 한다.

 

1. 오토스케일링

1) 오라클 클라우드의 오토스케일링

오라클 클라우드의 오토스케일링은 인스턴스 풀에 원하는 인스턴수 수를 정의하고, 사용률 지표를 기반으로 자동으로 인스턴스 수를 조정하는 기능이다.

-> 사용자에게는 지속적인 성능을 제공하면서도 수요가 낮은 기간 동안에는 비용을 절감할 수 있게 해준다.

인스턴스 풀(instance Pool)
한 리전 내에서 구성되는 여러 컴퓨트 인스턴스의 그룹을 의미한다. 인스턴스들은 풀에 묶인 후 성능 지표나 일정에 따라 인스턴스 풀의 인스턴스 수를 자동으로 조정할 수 있다.

 

2) 메트릭 기반과 스케줄 기반의 오토스케일링

• 메트릭 기반 오토스케일링
  • 사용자가 정한 임계치에 도달하면 오토스케일링이 자동으로 활성화 된다.
  • 시스템 성능 메트릭은 1분 간격으로 수집되며, 총 3번 임계치를 충족하면 오토스케일링이 동작한다.
  • 한 번에 하나의 메트릭을 기반으로 한 오토스케일링 정책을 설정할 수 있다.
• 스케줄 기반 오토스케일링
  • cron 표현식을 활용해서 오토스케일링 일정을 정의할 수 있다.
  • 지정한 일정에 따라 자동으로 오토스케일링을 동작할 수 있다.
  • 최대 50개의 메트릭 기반 오토스케일링 정책을 추가할 수 있다

 

2. Instance Configuration

Instance Configuration에서는 오토스케일링에 활용할 인스턴스 풀의 인스턴스 설정을 정의한다.

이미 사용 중인 인스턴스를 템플릿으로 지정하거나, 새로운 인스턴스를 추가로 설정해서 사용할 수 있다. 기존의 인스턴스를 템플릿으로 지정할 때는 애플리케이션 또는 바이너리와 같은 내용은 포함되지 않는다. 그래서 해당 인스턴스에서 사용자 지정 사용자 정의 이미지(Custom Image)를 먼저 생성해야 한다.

 

3. 로드밸런서

1) 로드밸런서 효과

네트워크 트래픽을 여러 대의 가상 머신이나 서버에 균등하게 분산시켜 주는 장치나 프로그램을 의미한다. 트래픽이 특정 서버로 집중되는 것을 방지해서 부하를 고르게 분산시켜 서버의 안정성과 가용성을 향상 시킨다.

 

OCI 로드밸런서는 현재 사용이 가능한 인스턴스를 인식하고, Health Check를 통해 미리 설정한 정책에 따라 상태가 좋은 인스턴스로 트래픽을 전달하여 성능과 가용성을 최적화한다.

 

2) 퍼블릭 로드밸런서와 프라이빗 로드밸런서

퍼블릭 로드밸런서(Public Load Balancer) : 인터넷을 통해 접근이 가능한 퍼블릭 IP 주소를 가지며, 외부에서도 접근할 수 있다

프라이빗 로드밸런서(Private Load Balancer) : VCN 내에서만 접근이 가능한 프라이빗 IP 주소가 할당되며, VCN 내부에서만 사용된다.

두 유형의 로드밸런서 모두 VCN 내의 로드 밸런싱 대상 서버로 데이터 트래픽을 분산한다. 로드밸런서의 IP로 들어온 트래픽은 로드밸런서로 전송되고, 이후 리스너(Listener)라는 논리 객체를 통해 로드밸런서로 전달된다.
(리스너에서는 TCP, HTTP/1.0, HTTP/1.1 등의 네트워크 프로토콜, 포트, SSL 등의 설정을 구성할 수 있다.)

3) 백엔드셋과 세션 지속성

로드밸런싱의 대상이 되는 서버를 백엔드 서버(Backend Server), 백엔드 서버들을 묶은 논리적인 개념을 백엔드셋(Backend Set)이라고 한다. 로드밸런싱 정책은 백엔드셋 단위로 설정된다.

 

OCI 로드밸런서는 클라이언트에서 발생하는 모든 요청을 최초 백엔드 웹 서버로 보내는 세션 지속성(Session Persistence)을 지원한다. 이 기능은 주로 HTTP 트래픽에서 동작하며, 이를 위해 쿠키(Cookie)를 사용한다.

 

세션 지속성을 활성화하기 위해 두 가지 옵션 중 하나의 옵션을 선택할 수 있다.

• 애플리케이션 쿠키 stickiness
  • 로드밸런서가 쿠키의 해시 값을 계산해서 클라이언트에게 보내고, 클라이언트는 이를 저장해서 추후에 해당 백엔드 서버로의 요청에 사용한다.
  • 서버에서 해시 값이 변경되는 경우에는 로드밸런서가 다시 클라이언트로 쿠키 값을 전송한다.
    -> "너 요청 얘가 처리했어. 앞으로는 얘 지정해서 요청하도록 해." 하고 미리 백엔드 서버를 알려주는 느낌
• 로드밸런서 stickiness
  • 로드밸런서가 클라이언트로 보내는 응답에 쿠키를 넣어서 사용한다.
    -> "너 요청 얘가 처리했어. 얘한테 연결시켜주는 열쇠 줄게. 가서 해." 지속성이 있는 연결을 맺어주는 느낌

오토스케일링과 관련해 로드밸런서는 컴퓨트 인스턴스들의 엔트리 포인트 역할을 수행한다. 따라서 오토스케일링 정책에 의해 인스턴스의 수가 증가하거나 감소하게 되면 로드밸런서는 자동으로 해당 인스턴스와의 연결을 설정하거나 해제한다.

엔트리 포인트
시스템이나 애플리케이션에 접근하기 위한 시작지점을 의미한다.
로드밸런서의 엔트리 포인트는 클라이언트가 로드밸런서를 통해 서버 자원에 접근할 수 있도록 하는 지점이다.

 

4) 오토스케일링 동작 후 로드밸런서

오토스케일링이 동작해서 새로운 인스턴스가 생성되면 로드밸런서는 새로운 인스턴스를 포함해서 트래픽을 여러 인스턴스로 균등하게 분산하고, 인스턴스가 감소하면 해당 인스턴스와의 연결을 자동으로 끊고 남은 인스턴스들로 트래픽을 분산시킨다.

 

3. 다이내믹 그룹 생성, 권한 정책 추가

1) 다이내믹 그룹이란

오라클 클라우드에서의 권한 관리는 사용자를 그룹으로 묶고, 해당 그룹에 권한을 부여하는 방식을 기본적으로 사용한다. 하지만 사용자가 아닌 컴퓨트 인스턴스가 다른 자원들을 필요로 할 때에는 그 권한을 어떻게 줘야 할까?

 

바로 컴퓨트 인스턴스를 권한 주체(actor)로 지정하고, 다른 오라클 클라우드 자원을 사용할 수 있도록 하는 것이다.

이를 통해 컴퓨트 인스턴스는 API 호출로 필요로 하는 자원에 접근할 수 있다. 이 컴퓨트 인스턴스는 개별적으로 지정되거나 여러 개가 그룹으로 묶일 수 있다. 이게 바로 다이내믹 그룹이다.

 

예를 들어, 인스턴스 하나 또는 여러 개를 "oci-demo-admin"이라는 이름의 다이내믹 그룹으로 묶고, 해당 그룹에게 테넌시 내 모든 네트워크 자원을 관리할 수 있는 권한을 부여할 수 있다.

Allow dynamic-group oci-demo-admin to manage virtual-network-family in tenancy

 

이 예시와 동일하게 컴파트먼트 내의 인스턴스를 다이내믹 그룹으로 묶고, 오토스케일링과 관련된 자원을 제어할 수 있도록 설정할 것이다.

 

2) OCID(Oracle Cloud ID) 확인

[Identity & Security → Domains] 메뉴 선택

 

사용 중인 컴파트먼트 선택

 

OCID 복사해두기

 

OCID(Oracle Cloud ID)
오라클 클라우드의 모든 자원들은 오라클이 할당한 고유한 ID를 가지며, 이를 OCID라고 한다. 해당 클라우드 자원의 식별을 위해 사용되며, 각 자원의 고유한 특성과 위치 정보를 포함하고 있다.
-> OCID를 통해 각 자원을 식별하고 추적할 수 있다.

 

3) 다이내믹 그룹 생성

[Identity & Security → Domains] 메뉴 선택

 

Default 도메인 선택

 

Dynamic groups 선택

 

Create dynamic group 선택

 

Name : oci-demo-dyngroup

Description : oci demo dynamic group

Rule 1 : All {instance.compartment.id = '<이전에 복사해 놓은 OCID>'}

 

다이내믹 그룹 생성된 것 확인

 

4) 오토스케일링 관련 자원 정책 구문 추가

[Identity & Security → Policies] 메뉴 선택

 

이전에 생성한 oci-demo-policy 선택

(보이지 않으면 컴파트먼트 변경)

 

Edit Policy Statements 선택

 

정책 추가

(이전에 CA 생성할 때 정책 추가했던 Basic으로 하나씩 추가해도 되고, Advanced로 한번에 추가해도 된다.)

Allow dynamic-group oci-demo-dyngroup to manage compute-management-family in compartment ociexplained Allow dynamic-group oci-demo-dyngroup to manage object-family in compartment ociexplained Allow dynamic-group oci-demo-dyngroup to manage auto-scaling-configurations in compartment ociexplained

 

추가된 것 확인

 

기존에 사용 중이던 정책에 "oci-demo-dyngroup" 이름으로 된 다이내믹 그룹에 compute-management-family, object-family, auto-scaling-configurations 권한을 부여 한 것이다.

-> ociexplained 컴파트먼트 내의 모든 인스턴스를 묶은 다이내믹 그룹에 권한을 부여하는 정책을 추가했기 때문에 결과적으로 ociexplained 컴파트먼트 내의 모든 인스턴스들이 이 권한을 가지게 된다.

 

4. 오토스케일링을 위한 사용자 정의 이미지 생성

부하에 따라 자동으로 확장하거나 축소하려면 먼저 해당 애플리케이션 서버의 사용자 정의 이미지를 생성해야 한다.

이 이미지는 현재 운영 중인 애플리케이션 서버 상태와 동일한 인스턴스를 오토스케일링 하는데 필요하다.

 

[Compute → Instances] 메뉴 선택

 

생성했던 oci-demo-app 선택

 

[More actions → Create custom image] 선택

 

Create in compartment : ociexplained

Name : oci-demo-app

 

Custom image를 생성하는 과정 중 인스턴스가 일시적으로 중지되는데, Custom iamge가 생성되면 다시 가동된다.

 

5. 로드밸런서 구성

1) 로드밸런서 타입 설정

[Networking → Load balnacers → Load balancer] 메뉴 선택

 

Load balancer와 Network load balancer 중 Load balancer 선택

로드밸런서 vs 네트워크 로드밸런서

OCI 로드밸런서
  - OSI 7 Layer의 7계층(애플리케이션 계층) 트래픽에 적용이 가능한 로드밸런서이다.
  - OSI 모델의 애플리케이션 계층에서 동작하며, 메시지의 실제 콘텐츠를 분석하고 들어오는 헤더를 분석해서 결정을 내릴 수 있다.
  - Session Persistence 또는 Sticky Session 기능과 같이 클라이언트가 연결된 서버를 유지하는 기능을 제공한다. 이를 통해 사용자 세션을 특정 타깃 서버에 바인딩 해서 백엔드 서버의 부하를 효과적으로 분산시킬 수 있다.
  - 최대 8000Mpbs까지 대역폭 설정이 가능하다.

OCI 네트워크 로드밸런서
  - OSI 7 Layer의 3계층(네트워크 계층) 및 4계층(전송 계층) 워크로드에 적용이 가능한 로드밸런서이다.
  - 패킷의 내용을 검사하지 않고, 업스트림 서버로 네트워크 패킷을 전달한다.
  - 대역폭 설정에 제한이 없으므로 상황에 맞게 필요한 대역폭을 설정할 수 있다. 

 

Create load balancer 선택

 

2) 로드밸런서 이름, 네트워크 설정

Load balancer name : oci-demo-lb

Choose visibility type : Public 선택

Assign a public IP address : Ephemeral IP address 선택

 

[Choose networking] 섹션 Virtual cloud network : OCI_DEMO

[Choose networking] 섹션 subnet : public-subnet-OCI_DEMO (regional)

 

인터넷에 노출시키기 위해 Public 선택, Reserved IP를 사용하지 않기 때문에 Ephemeral IP address 선택한다.

 

3) 백엔드 서버 설정

Choose backends 화면에서 기본 값인 Weighted routed robin 선택

 

Add backends 클릭 후 oci-demo-app 선택

 

로드밸런서와 백엔드 서버가 통신할 포트 번호 5000 입력

 

로드밸런서 정책
1) Round Robin
   - 백엔드셋 목록에 있는 서버를 순서대로 차례차례 트래픽을 분산시키는 방식이다.
   - 서버들이 비슷한 성능을 가지고 있을 때에는 유용하지만, 성능 차이가 큰 경우에는 공정한 분배가 힘들 수 있다.
2) IP Hash
   - 네트워크 트래픽 소스의 IP 주소를 해싱 키로 사용해서 트래픽을 특정 백엔드 서버로 라우팅하는 방식이다.
   - 같은 클라이언트의 요청은 세션 일관성을 유지할 수 있다.
   - 일부 서버에 부하가 집중될 수 있다.
3) Least Connections
   - 현재 활성화된 연결 수가 가장 적은 백엔드 서버로 트래픽을 분산시키는 방식이다.
   - 연결 개수에 따라 부하를 분산하기 때문에 연결이 많은 서버는 상대적으로 적은 부하가 가해진다.
   - 연결 수가 많이 변동하는 상황에서 유용하다.

 

port : 5000

URL path (URI) : /hello

 

헬스체크에서는 서버의 가용성을 어떻게, 어떤 간격으로 할지 설정한다.

 

4) 리스너 설정

Listener name : oci-demo-listener

specify the type of traffic : HTTPS

[SSL certificate] 섹션의 Certificate resource : Certificate service managed certificate

[SSL certificate] 섹션의 Certificate in <HTTPS 연결 설정 게시에서 생성한 CA 컴파트먼트> : <HTTPS 연결 설정 게시물에서 생성한 인증서>

 

SSL Termination
HTTPS 통신에서는 웹 서버가 클라이언트의 요청을 받아들이고 SSL 연결을 설정해서 데이터를 암호화 및 복호화하는 과정은 서버 자원이 소비되므로 성능에 영향을 줄 수 있다. 부하가 많은 웹 사이트나 애플리케이션의 경우에는 병목 현상(시스템 성능 저하)을 초래할 수 있다.

SSL Termination은 프록시 서버나 로드밸런서와 같은 중간 장치가 SSL 연결을 해제하고 복호화 해서 클라이언트와의 통신을 처리한 후 백엔드 서버와는 암호화되지 않은 HTTP 요청으로 통신하는 방식이다. (중간 장치가 대신 복호화해주는 셈)
중간 장치가 SSL 연산을 대신 처리하기 때문에 백엔드 서버의 부하를 줄일 수 있다.

<OCI 로드밸런서에서 SSL Termination 구성하는 방법>
1) 로드밸런서의 리스너 구성에서 443과 같은 포트로 리스너를 생성한다.
2) 업로드된 인증서 번들을 리스너와 연결해서 SSL Termination을 설정한다.

★ 로드밸런서는 클라이언트와의 SSL 연결을 처리하고, 백엔드 서버와는 암호화되지 않은 데이터로 통신하게 된다.

 

5) 로깅 설정

Log name : oci-demo-log-lb-error

 

하단의 Access logs가 활성화되지 않았으므로 Error logs만 수집한다.

 

로드밸런서의 상태가 "OK" 되는 것 확인

 

6) 시큐리티 리스트 설정

백엔드 서버와 통신을 위해 5000번 포트로 설정했다. 로드밸런서가 사용하는 서브넷 내에서 통신할 수 있도록 Stateful Ingress 규칙으로 시큐리티 리스트에 자동으로 추가된다.

 

로드밸런서 리스너가 인터넷과의 통신을 위해 443번 포트를 사용하도록 설정한 경우 이 포트에 대한 통신 허용을 위해 시큐리티 리스트에 규칙을 추가해야 한다.

Source CIDR : 0.0.0.0/0

Destination Port Range : 443 

 

443번 추가된 것 확인

 

7) 로드밸런서를 통한 애플리케이션 서버 테스트

로드밸런서의 퍼블릭 IP 확인

 

https://<로드밸런서 퍼블릭 IP 주소>

 

오라클 클라우드에서 제공한 내부 인증서로 외부 인증 기관에 의해 인증되지 않았으므로 최초 접속 시 해당 메시지가 출력된다.

 

고급 클릭

 

<퍼블릭 IP 주소(안전하지 않음)> 클릭

 

접속 성공

 

6. Instance Configuration 구성

[Compute → Instance Configurations] 메뉴 선택

 

Create instance configuration 선택

 

Name : oci-demo-instance-config

 

기존의 Oracle Linux 8 이미지로 선택되어 있는 것 변경

 

앞서 생성한 Custom Image 선택

 

public subnet-OCI_DEMO 선택된 것 확인

 

oci-demo-app 인스턴스 생성할 때 생성한 SSH 퍼블릭 키 업로드

 

생성된 것 확인

 

7. 인스턴스 풀 구성

[Compute → Instance Pools] 메뉴 선택

 

Create instance pool 선택

 

Name : oci-demo-app-instance-pool

Instance configuration : (앞서 생성한) oci-demo-instance-config

Number of instances : 1

 

Primary VNIC : OCI_DEMO

subnet : public-subnet-OCI_DEMO (regional)

 

Load balancer : oci-demo-lb

Backend set : <로드밸런서가 라우팅할 백엔드셋 이름 선택> (자동 생성 값)

Port : 5000

 

PROVISIONING 대기

 

생성 실패

 

OCI의 프리티어 제한 때문에 생성되지 않는 것 같다.

 

프리티어 업그레이드

 

★ 프리티어 계정 업그레이드

 

결제 방법 추가

 

Credit Card 선택

 

카드 정보를 입력하면 해당 카드로 결제 후 취소가 진행된다.

 

100달러가 결제되었다가 취소된다.

(처음 프리티어 가입할 때는 1.38달러가 결제되었는데, 프리티어 계정을 업그레이드 하는 경우에는 미화 100달러가 결제되었다가 취소된다.)

 

[참고]

https://docs.oracle.com/en-us/iaas/Content/Billing/Tasks/changingpaymentmethod.htm

Managing Account Upgrades and Payment Method

https://haksuperman.tistory.com/64

[OCI] 오라클 클라우드 계정 생성 (Feat. Free Tier 및 2단계 인증)

 

결제 정보가 등록 되었지만, 하단의 계정 업그레이드를 선택해야 업그레이드가 된다.

 

법인이 아닌 개인이기 때문에 세금 정보 입력x

 

Upgrade account 선택

 

계정 업그레이드 신청 완료

 

업그레이드가 완료되면 이메일로 알려준다고 하루에서 이틀 정도 걸린다고 한다.

 

무료 계정에서 유료 계정으로 업그레이드 되면 완료 되었다는 메일이 온다.

 

어쩔 수 없이 기존의 인스턴스 2개를 지우고 오토스케일링 테스트를 진행해야 한다....

 

다시 인스턴스 풀 생성해보기

-> 정상적으로 생성되는 것 같다.

 

생성 완료

 

설정한대로 인스턴스도 자동으로 하나 생성된다.

 

8. 오토스케일링 설정 및 부하 테스트

[Compute → Autoscaling Configurations] 메뉴 선택

 

Create autoscaling configuration 선택

 

Name : oci-demo-autoscale-config

Instance pool : 앞서 생성한 인스턴스 풀 oci-demo-app-instance-pool 선택

 

Metric-based autoscaling 선택

Autoscaling policy name : oci-demo-autoscale-policy

Performance metric : CPU utilization 선택

 

Scale-out rule 항목의 Threshold percentage : 40

Scale-in rule 항목의 Threshold percentage : 20

Scaling limits:

Minimum number of instance : 1 (인스턴스 풀을 줄일 수 있는 최소 인스턴스 수)

Maximum number of instance : 2 (인스턴스 풀을 늘릴 수 있는 최대 인스턴스 수)

Initial number of instance : 1 (오토스케일링이 활성화된 후 즉시 인스턴스 풀에서 시작할 인스턴스 수)

 

정상적으로 생성된 것 확인

 

★ 오토스케일링 테스트

부하 테스트용 유틸리티로 stress-ng와 locust를 사용할 것이다. 

stress-ng는 리눅스 운영체제 커널에서 동작하는 로드 테스트 도구이고, locust는 파이썬으로 구현된 HTTP 요청을 수행할 수 있는 로드 테스트 도구이다.

 

1) 인스턴스 풀에 생성된 가상 머신에 stress-ng 설치 및 CPU 사용률 50% 유지

2) 애플리케이션 서버에 locust 설치

3) 애플리케이션 서버 및 인스턴스 풀의 인스턴스에 locust HTTPS 요청 수행

4) 오토스케일링 스케일 아웃 발생 여부 확인

5) 부하 테스트 종료 후 일정 시간 대기

6) 오토스케일링 스케일 인 발생 여부 확인

 

의 방식으로 진행할 것이다.

 

실습에서는 부하 테스트 서버 없이 진행했지만, 실제 운영 환경에서는 부하 테스트를 위해 별도의 서버 또는 테스트 환경을 구성하는 것이 보편적이다.
-> 실제 운영 서버와 분리되어 부하 테스트를 진행하기 때문에 운영환경에 영향을 주지 않으면서 부하를 시뮬레이션하고 오토스케일링 기능을 검증할 수 있다.

 

1) 인스턴스 풀에 생성된 가상 머신에 stress-ng 설치 및 CPU 사용률 50% 유지

원격 접속

 

stress-ng 설치

 

stress-ng 실행

(CPU 사용률은 50%로 유지하도록 1개의 CPU 스레드를 사용하고, 1800초 동안 부하를 발생)

 

2) 애플리케이션 서버에 locust 설치

별도 터미널을 통해 파이썬 locust 모듈 설치

 

3) 애플리케이션 서버 및 인스턴스 풀의 인스턴스에 locust HTTPS 요청 수행

 

부하 테스트 시 HTTPS 프로토콜을 사용해서 서비스를 호출하는 경우 로드밸런서에 연결된 인증서가 오라클 클라우드 내부 TLS 인증서이기 떄문에 관련된 인증서 에러가 발생할 수 있다.
SSL 인증서 검증 과정을 건너뛰는 verify=False 옵션을 사용하였고, 경고 메시지 출력의 비활성화를 위해 warnings 모듈을 활용하였다.

 

로드밸런서의 퍼블릭 IP 주소로 443번 포트를 사용해서 500명의 사용자로부터 1초마다 HTTP GET 요청을 발생시키는 부하 테스트를 진행한다.

 

4) 오토스케일링 스케일 아웃 발생 여부 확인

[Compute → Instance Pools] 화면에서 생성한 인스턴스 풀을 선택하면 자원 사용률 차트를 확인할 수 있다.

-> 이미 임계치인 40%를 넘은적이 많다.(스케일 아웃 되었어야 하는 상황)

 

인스턴스가 자동으로 스케일 아웃 되었다.

 

오토스케일링이 실행되면 인스턴스 풀의 상태가 RUNNING에서 SCALING으로 바뀐다.

 

자동 생성된 인스턴스(10.0.0.120, 10.0.0.192)가 로드밸런서의 백엔드셋에 자동으로 추가된 것 확인 가능

(10.0.0.85는 이전에 수동으로 인스턴스 생성했던 인스턴스이다. 프리티어 계정의 제한 때문에 수동 삭제한 것.)

 

5) 부하 테스트 종료 후 잠시 대기

ctrl+c로 stress-ng 중지

 

ctrl+c로 locust HTTPS 요청 중지

 

6) 오토스케일링 스케일 인 발생 여부 확인

오토스케일링을 통해 스케일 아웃 된 인스턴스가 자동으로 스케일 인 되어 삭제되었다.