Jins' Dev Inside

클라우드 환경에서 AWS 의 솔루션들을 사용하는 데 있어서 AWS Auto Scale 은 그 꽃이라고 할 수 있다.

AWS 의 Auto Scale 솔루션은 서비스의 스케일링(Scaling) 을 자동화할 수 있게 해주는 클라우드 인프라 솔루션이다.

AWS 의 Auto Scaling Group / Launch Configuration / Scaling Plan 와 같은 핵심 구성 요소들을 포함한다.

오토 스케일링 정책을 통한 설정을 바탕으로 몇 개의 인스턴스를 운용할지, 어떤 시점에 Scale 을 늘리고 어떤 시점에 낮출지 결정할 수 있다.

(Scaling 에 대해 잘 모른다면 다음 포스트를 참조하자. 

https://jins-dev.tistory.com/entry/Scaling-%EC%9D%98-%EC%A2%85%EB%A5%98%EC%97%90-%EB%8C%80%ED%95%9C-%EC%A0%95%EB%A6%AC)

이에 따라 Auto Scale 솔루션은 다음과 같은 장점들을 갖고 있다.

1. Cost Optimization

Scale 이 커져서 AWS 의 인프라들을 많이 사용하게 되면 비용이 증가하고 Scale 을 낮출 경우 비용을 절감시킬 수 있기 때문에 비용적인 측면을 같이 고려해서 사용해야 하며,

이러한 측면이 고려된 설계를 한다면 Auto Scale 을 통해 필요한만큼만 리소스를 사용함으로써 비용을 최적화할 수 있다.

(단, Auto Scale 솔루션 자체는 추가 비용이 들지 않는다.)


2. High Availability

Auto Scale 솔루션을 이용하면 Auto Scaling Group 에 대해 여러 Availability Zone 들에 고르게 인스턴스들을 할당하고 해제할 수 있다.

가령 Scale Out 을 통해 인스턴스들의 숫자가 많아질 때 하나의 영역에만 할당하는 것이 아니라 여러 영역에 고르게 분포시킬 수 있고, 해제할 때에도 균등하게 할당을 해제할 수 있다.

3. Well-Architectured Service

Auto Scale 을 통해 실제 요구량보다 많은 리소스를 사용하는 Over-Provisioning(오버 프로비저닝) 이나 실제보다 적은 리소스를 할당하는 Under-Provisioning(언더 프로비저닝) 을 방지할 수 있다.

이는 아키텍처를 설계함에 있어 유연성을 가져다줄 수 있다.


Auto Scale 솔루션은 다음과 같은 수명주기를 갖고 있다.

수명 주기에 따라 Scale Out 된 인스턴스들은 Pending 상태 이후 In-Service 상태로 전환되며 Scale In 될 때에는 Terminating 프로세스를 수행하게 된다.

진행 중인 인스턴스를 Attach 하거나 Detach 하는 과정 역시 라이프사이클에 포함된다.

위와 같은 수명 주기 내에서 Auto Scale 은 주로 CloudWatch 지표를 바탕으로 이벤트가 트리거되며 이벤트를 통해 Lambda 함수를 호출한다던지, SNS 알림을 생성한다든지 하는 다른 작업을 같이 진행할 수 있다

Amazon EC2 Auto Scaling API 에 대한 호출은 AWS CloudTrail 을 통해 추적해볼 수 있다.

JWT 란 JSON Web Token 의 약어로 필요한 모든 정보와 검증을 위한 Signature 를 포함하는 JSON 객체를 통해 만들어내는 토큰의 일종이다.

웹표준으로 지정되면서 계정에 대한 인증 및 API 사용에 있어서 권한 확인을 위한 Security Token 으로 사용된다.

토큰은 지정한 객체(주로 인증 정보가 된다.)를 JSON 화하여 만든 데이터를 암호화하고, 특정 키를 이용해 서명하게 된다. 따라서 발급된 토큰은 해당 서버 / 서비스가 인증한 Token 이라는 의미가 되고, 이는 권한 인증에 있어 Key 로 사용할 수 있게 된다.

JWT 토큰은 Header 와 Payload, Signature 의 3가지 부분을 포함한다.

자세한 설명은 다음을 참고하자.

(https://velopert.com/2389)

JWT 를 사용한 일반적인 인증 절차는 다음과 같다.

 (1) 허용된 API 로 토큰을 발급. 주로 회원가입 / 로그인 API 만을 Token 없이 접근 가능하도록 설계하고, 해당 API 들에서 토큰을 발급해준다.

 (2) JWT Token 이 발급된다.

 (3) 클라이언트는 모든 요청에 Token 을 Header 에 포함시켜서 전달한다.

 (4) 서버는 유효한 JWT 토큰의 경우 인증하고 API 의 사용을 승인시키지만 아닐 경우 401 오류를 표시한다.

이는 일반적인 Token 을 이용한 API 프로세스와 동일하다.

JWT 의 장점은 다음과 같다.

 - 간편한 사용 및 인증 절차

 - Horizontal Scalable

 - REST API 에 최적화된 키 인증 방식

 - Expired date 정보의 포함

 - 관리와 서버 부하에 있어 부담이 적음

반면 다음과 같은 단점도 있다.

 - 인증 정보가 커질 수록 토큰의 크기가 커진다

 - 모든 요청에 토큰 정보가 포함되므로 Token 의 크기가 Message 의 크기보다 커질 경우 비효율적인 통신 구조가 된다.

다음 예제는 JWT 토큰을 이용한 인증절차를 가장 알기 쉽고 직관적인 예제를 통해 설명한다.

구현이 처음이라면 강추 하는 예제이다.

https://medium.com/swlh/spring-boot-security-jwt-hello-world-example-b479e457664c

분산처리 환경을 구축하는 데 있어서 로드밸런서의 역할은 핵심적이다.

클라우드 환경에서 분산처리를 위한 아키텍처를 설계한다면, AWS 의 Load Balancer 를 이용해볼 수 있다.

Amazon Web Service 가 Provisioning 하는 Load Balancer 는 ELB(Elastic Load Banacing) 서비스라 하며, 기본적으로 Logging, Cloud Watch 를 통한 지표, 장애 복구, Health Check 와 같은 기능들을 제공한다.

ELB 서비스의 종류로는 2019년 8월 기준으로 3가지 종류가 있다.

 (1) Classic Load Balancer

가장 기본적인 형태이자 초기에 프로비저닝되던 서비스로, 포스팅 등에 나오는 설명에 단순히 ELB 라고 나와있으면 Classic Load Balancer 를 말하는 경우가 많다.

L4 계층부터 L7 계층 까지 포괄적인 로드밸런싱이 가능하며, 따라서 TCP, SSL, HTTP, HTTPS 등 다양한 형태의 프로토콜을 수용할 수 있고 Sticky Session 등의 기능도 제공해준다.

특징적으로 Classic Load Balancer 는 Health Check 를 할 때, HTTP 의 경우 /index.html 경로를 참조한다.

즉, 웹서버 인스턴스의 경로에 /index.html 가 포함되어있지 않다면(404) Health Check 를 실패한다는 뜻이다...

따라서 이럴 때에는 Health Check 를 위한 프로토콜만 TCP 로 바꾸고 포트만 80 으로 체크하게 하는 방법이 있다.

중요한 특징으로... CLB 는 로드밸런서가 url 하나를 가질 수 있다. 즉, CLB 로 매핑되어있는 인스턴스들은 무조건 하나의 URL 을 통해 접근하게 된다.

 (2) Application Load Balancer

Classic Load Balancer 이후 출시된 서비스로 HTTP 및 HTTPS 트래픽 로드밸런싱에 최적화되어있다.

L7 계층에서 작동하며 Micro Service Architecture 와 같은 Modern 환경을 겨냥한 많은 강점들이 있는데, WebSocket 이나 HTTP/1.1 이상의 프로토콜에 대한 지원, 향상된 라우팅 정책과 사용자의 인증 까지도 지원을 해준다.

웹서비스를 목적으로 한다면 기존 Classic Load Balancer 가 갖고 있던 장점 이상의 강점들을 많이 포함하고 있다.

단 L7 계층에서 작동하기 때문에 TCP 등에 대한 밸런싱은 지원되지 않는다.

직접 사용해서 구축 할때에 Classic Load Balancer 에 비해 좀 더 구축이 편하고 웹서버 밸런싱에 있어서는 확실히 다양한 옵션이 있다. Health Check 경로 또한 지정할 수 있으며, 기본이 / 로 정해져있다.

CLB와 다르게 ALB 는 host-based Routing 과 path-based Routing 을 지원한다. Content Based Routing 이라고도 하며 ALB 에 연결된 인스턴스들은 여러개의 URL 과 path 를 가질 수 있다.

 (3) Network Load Balancer

Load Balancer 중 성능적으로 최적의 로드밸런싱을 지원한다. TCP, UDP 등의 서버를 구축할 때 해당 프로토콜 들에 대해 굉장히 낮은 지연 시간으로 최적의 성능을 보여준다고 한다. 

사용해본적이 없는데... 사용해본다면 좀 더 포스팅 내용을 보강해야겠다.

로드밸런서에 EIP 를 직접 붙일 수는 없고, 필요하다면 DNS 의 도메인 네임 대신 CNAME 을 사용하거나 Route53 서비스와 같이 사용해야 한다. 그 이유는... ELB 역시 서버이기 때문에, 부하 상황에서 오동작의 위험이 있고 그에 따라 자체적으로 Scale In - Scale Out 을 수행하기 때문이다. (즉, IP 를 지정할 서버가 한대가 아니게 될 수 있다.)

또한, ELB 는 Multi-AZ 환경에서 "내부적으로는" 각 Availability Zone 별로 구성된다. 이 때 트래픽의 분배는 AZ 당 ELB 사정에 맞게 분배되므로... Multi AZ 환경에서는 각 Availability Zone 별 인스턴스의 숫자를 동일하게 맞춰주는 것이 좋다. (동일하게 맞추지 않으면 특정 Zone 의 인스턴스들에 트래픽이 몰릴 수 있다.)

로드밸런서를 통해 Cloud 환경에서 아키텍처를 설계할 때에는 Private Subnet 들에 EC2 인스턴스들을 배치해둔 상태에서, ELB로 트래픽을 연결할 수 있도록 인스턴스들을 연결시켜주고, Public 영역에 위치시켜 놓는 식으로 구성을 한다.

혹은, ELB 자체는 VPC 내부에 형성시켜 두고, ELB로 들어온 트래픽을 Private Subnet 으로 전개시켜주며, 인터넷에 연결을 위한 Public NAT 를 두고 출력을 해당 NAT 를 거치게 하는 방식도 있다.