Elastic Load balancing는 여러개의 가용영역(Availability)에 존재하는 아마존 EC2 인스턴스, 컨테이너와 IP 주소와 같은 목적지로 네트워크 트래픽을 분산해서 전달하는 일을 한다. Elastic Load balancing는 애플리케이션으로 향하는 트래픽을 골고루 분산히키며, 트래픽이 애플리케이션의 처리 용량을 초과할 경우 자동으로 스케일아웃할 수 있다.
로드밸런스의 이점
로드 밸런서는 가상 서버와 같은 여러 개의 컴퓨터 자원으로 워크로드를 분산한다. 로드밸런서를 이용해서 애플리케이션의 가용성(availability)와 내결함성(Fault tolerance)를 높일 수 있다.
사용자는 필요에 따라서 로드 밸런서가 관리하는 컴퓨터 리소스를 "애플리케이션의 중단과 같은 방해 없이" 추가하거나 제거 할 수 있다.
사용자는 헬스 체크(health check)기능을 이용해서 컴퓨터 리소스에 대한 모니터링을 수행 할 수 있다. 만약 컴퓨터 리소스에 문제가 생기면, 로드밸런서는 해당 리소스에 요청을 전송하지 않는다. 또한 로드밸런서는 인터넷 트래픽에 대한 암호화/복호화를 수행한다. SSL offloading 이라는 기능을 로드밸런서에 맡김으로서 애플리케이션 본연의 작업에만 집중하게 할 수 있다.
Elastic Load Balancing의 기능
Elastic Load Balancing는 Application Load Balancer, Network Load Balancer, Class Load Balancers, 3가지 타입의 로드밸런서를 제공한다. 사용자는 애플리케이션 요구사항에 맞춰서 로드밸런서를 선택 할 수 있다.
사용자는 아래의 방법들을 이용해서 로드밸런스의 생성, 접근, 관리, 삭제 등의 작업을 수행 할 수 있다.
AWS Management Console - 웹 인터페이스를 이용해서 Elastic Load Balancing 작업을 할 수 있다.
AWS Command Line Interface (AWS CLI) - Elastic Load Balancing를 비롯한 광범위한 AWS 서비스에 대한 명령을 제공한다. AWS CLI는 윈도우즈, 맥, 리눅스를 지원한다.
AWS SDKs - 주요 언어별로 제공하는 API를 이용해서 AWS 인프라와 관련된 세부정보를 처리하는 애플리케이션을 개발 할 수 있다.
Query API - 낮은 수준의 HTTPS 요청을 이용 할 수 있다. Elastic Load Balancing에 접근하는 가장 직접적인 방법은 Query API를 이용하는 것이다. 하지만 낮은 수준인 만큼 요청의 서명에 필요한 해시 생성과 오류처리와 같은 세부 사항을 직접처리해야 하는 어려움이 있다.
관련 서비스
Elastic Load Balancing은 아래의 서비스와 함께 작동하면서 가용성과 확장성을 향상시킨다.
Amazon EC2 - 클라우드에서 애플리케이션을 실행하기 위한 가상 서버다. 사용자는 트래픽이 EC2 인스턴스로 라우팅되도록 설정 할 수 있다.
Amazon EC2 Auto Scaling - 인스턴스가 실패하더라도 원하는 수의 인스턴스가 실행되고 있는지 확인한다. 또한 인스턴스에 대한 수요가 변함에 따라서 인스턴스의 수를 자동으로 늘이거나 줄일 수 있다. Elastic Load Balancing으로 Auto Scaling을 활성화하면 인스턴스들이 로드밸런서에 자동으로 등록된다.
AWS Certificate Manager - HTTPS 리스너를 만들때 ACM을 이용해서 인증서를 관리 할 수 있다. 로드배런서는 인증서를 이용해서 클라이언트의 암호호 된 요청을 복호화해서 뒷단에 있는 인스턴스등에 전달한다.
Amazon CloudWatch - 로드밸런서에 대한 모니터링을 활성화 할 수 있다.
Amazon ECS - EC2 인스턴스로 도커 클러스터를 구성하고 여기에 컨테이너를 실행하거 중지하는 등의 관리 작업을 할 수 있다. 사용자는 로드밸런서의 트래픽을 컨테이너로 라우팅 할 수 있다.
AWS Global Acclerator - AWS Global Accerator는 AWS의 글로벌 네트워크를 사용해서 AWS 애플리케이션으로 인터넷 트래픽을 전달한다. AWS에서 관리하는 네트워크이기 때문에 일관된 사용자 경험을 제공한다. AWS Global Acclerator를 이용해서 하나 이상의 AWS 리전에서 여러 로드 밸런서로 트래픽을 분산 할 수 있다.
Route 53 - 도메인이름을 IP 주소로 변환하여 방문자를 웹사이트로 라우팅하는 역할을 한다. 예를 들어 www.example.com을 IP 주소 15.111.10.13으로 변환한다. 이 도메인이름은 로드밸런서와 같은 리소스에 할당 할 수 있다.
AWS WAF - Application Load Balancer은 WAF를 사용해서 웹 방화벽 기능을 수행 한다.
Elastic Load Balancing 의 작동원리
로드밸런스는 클라이언트로 부터 입력되는 트래픽을 받아서 하나 이상의 가용 영역(Availability Zones)에 등록된 타켓(EC2 인스턴스 혹은 컨테이너)으로 라우팅한다. 로드밸런서는 타겟에 등록된 자원들의 상태를 모니터링해서 정상적으로 작동하는 타겟에만 트래픽을 라우팅한다. 로드밸런서가 문제가 되는 타켓 자원을 감지하면 해당 타켓으로의 라우팅을 중지시킨다. 타겟이 다시 정상작동한다면, 라우팅을 수행한다.
사용자는 하나 이상의 리스너를 지정해서 입력 트래픽을 허용하도록 로드밸런서를 구성한다. 리스너는 연결 요청을 확인하는 프로세스다. 리스너는 클라이언트와 로드밸런서를 연결하기 위한 프로토콜과 포트번호로 구성된다. 또한 클라이언트 연결을 타겟으로 라우팅하기 위한 타겟의 프로토콜과 포트번호도 구성된다. Elastic Load Balancing는 아래 세 가지 유형의 로드 밸런서를 지원한다.
Application Load Balancers
Network Load Balancers
Classic Load Balancers
가용 영역과 로드밸런서 노드들
Elastic Load Balancing에 대해서 가용영역(Availability Zone)을 활성화하면, 가용영역에 걸쳐서 로드밸런서를 만들 수 있다. 가용영역을 사용하려면 가용영역을 활성화 해야 한다. 당연하지만 가능하면 여러 가용 영역을 활성화 하는 것이 좋다.(Application Load Balancer는 반드시 여러 가용 영역을 활성화해야만 한다.) 이런 구성은 단일 장애점(single point of failure)를 제거함으로써 로드 밸런서가 가능한 중지 없이 작동하게 할 수 있다. 예를 들어 한 가용 영역이 사용 할 수 없는 경우에도 다른 가용 영역의 로드밸런서가 대신해서 라우팅을 할 수 있다.
크로스 존 로드 밸런싱
로드 밸런서는 클라이언트의 요청을 등록된 대상(Target)으로 분배한다. 크로스 존 로드 밸런싱(Cross-zone load balancing)를 활성화 하면, 로드 밸런서는 활성화된 모든 가용영역의 등록된 타겟으로 트래픽을 분산시킨다. Application load balancing는 크로스 존 로드 밸런싱이 할상 활성화 된다.
아래 그림을 보자. 각 가용 영역에 노드의 개수가 다르다. 크로스 존 로드 밸런싱이 활성화되면 10개의 타겟이 10% 씩 트래픽이 분산된다.
크로스 존 로드 밸런싱이 비활성화된다면 아래와 같은 일이 발생한다.
가용 영역 A의 인스턴스들은 각 25%의 트래픽을 처리한다.
가용 영역 B의 인스턴스들은 각 6.25%의 트래픽을 처리한다.
왜냐하면 가용 영역 A와 B로 50%씩의 트래픽이 흐르기 때문이다.
Network Load Balancer은 크로스 존 로드 밸런싱이 기본적으로 비활성화 된다. Network Load Balancer은 생성한 후 언제든지 크로스 존 로드 밸런싱을 활성화 할 수 있다.
Classic Load Balancer는 로드 밸런서를 만드는 방법에 따라서 크로스 존 로드 밸런싱의 설정이 달라진다. API와 CLI를 이용하면 크로스 존 로드 밸런싱이 기본적으로 비활성화 된다. AWS Management Console의 경우 크로스 존 로드 밸런싱을 활성화 하는 옵션이 있다. 일단 생성한 후에는 언제든지 크로스 존 로드 밸런싱을 활성화 할 수 있으니, 약간만 주의하면 사용하는데 큰 문제는 없다. 크로스 존 로드 밸런싱을 꺼야 하는 경우는 없을 것이다. 굳이 찾는다면 Weight를 다르게 하고 싶은 경우인데, 이런 필요가 있을지는 모르겠다.
라우팅 요청
클라이언트는 DNS(Domain Name System)을 이용해서 로드밸런서를 확인한다. 로드 밸런서는 Amazon에서 제어하는 amazonaws.com 도메인을 사용한다. Amazon DNS 서버는 하나 이상의 IP 주소를 클라이언트로 반환하고 클라이언트는 이 주소로 접근을 한다.
Network Load Balancer의 경우, 각 가용 영역에 로드밸런서 노드가 만들어진다. 가용 영역의 각 로드 밸런서 노드는 이 네트워크 인터페이스를 이용해서 고정 IP 주소를 만들 수 있다. 사용자는 EIP(Elastic IP)주소를 각 네트워크 인터페이스에 연결 할 수 도 있다. 때때로 네트워크 보안 정책 때문에 고정 IP를 요구하는 경우에 사용 할 수 있다.
애플리케이션에 대한 트래픽이 늘어나면 Elastic Load Balancing는 로드밸런서를 자동으로 확장하고 DNS 항목을 업데이트 한다. DNS는 TTL을 60초 지정하는데, 이를 통해서 트래픽의 갑작스러운 변화에 신속하게 대응 할 수 있다.
라우팅 알고리즘
Application Load Balancer는 아래의 프로세스를 이용해서 라우팅을 결정한다.
리스너(listener)의 룰을 우선해서 평가한다.
라우든로빈 알고리즘을 이용해서 타겟 그룹에서 타겟(노드)를 선택한다.
Network Load Balancer은 아래의 프로세스를 사용한다.
흐름 해시 알고리즘(flow hash algorithm)을 이용해서 타겟 그룹에서 타겟을 선택한다. 이 알고리즘은 아래의 데이터를 기반으로 한다.
클라이언트는 하나 이상의 TCP 연결을 만들 수 있다. 이들은 서로 다른 소스포트와 sequence number를 가지기 때문에 서로 다른 타겟으로 라우팅 될 수 있다.
Classic Load Balancer를 아래의 방법으로 라우팅한다.
TCP 리스너를 위해서 라운드 로빈 알고리즘을 사용한다.
HTTP와 HTTPS리스너에 대해서는 최소 미해결 요청 라우팅(Least outstanding request routing) 알고리즘을 사용한다. 최소 미해결 요청 라우팅은 해당 순간에 미 해결(미정, 미완료)요청 수가 가장 적은 인스턴스를 선택하는 알고리즘이다.
HTTP Connections
Classic Load Balancer는 pre-open connections를 허용한다. 하지만 Application Load Balancer는 허용하지 않는다. 사전 개방 연결(Pre-open connections)는 클라이언트가 LB에 연결하기전에 Classic load balancer가 타겟 노드와 미리 TCP 연결을 맺어 놓는 것을 의미한다. 클라이언트 요청이 들어오면 이 TCP 세션을 사용하기 때문에, 요청 처리시간을 줄일 수 있다.
Classic Load Balancer과 Application Load Balancer는 모두 Multiplex connection을 이용해서 다수의 클라이언트의 요청을 단일 백엔드 연결을 통해서 지정된 대상으로 라우팅 할 수 있다.
Application Load Balancer는 HTTP/0.9, HTTP/1.0, HTTP/1.1 및 HTTP/2 프로토콜을 지원한다. HTTPS 리스너에서만 HTTP/2를 사용 할 수 있으며 하나의 HTTP/2 연결을 사용하여 최대 128개의 요청을 병렬로 보낼 수 있다. Application Load Balancer는 HTTP에서의 WebSocket으로의 업그레이드도 지원한다.
Application Load Balancer과 Class Load Balancer는 백앤드 연결로 HTTP/1.1을 사용한다. 연결유지(Keep-alive)는 기본적으로 지원한다. 호스트(Host) 헤더가 없는 클라이언트의 HTTP/1.0 요청의 경우 로드밸런서는 백앤드에 연결된 HTTP/1.1 요청에 대한 호스트 헤더를 생성한다. Application Load Balancer의 경우 호스트 헤더에는 로드밸런서의 DNS이름이 포함된다. Class Load Balancer의 경우 호스트 헤더에 로드 밸런서의 IP 주소가 포함된다.
Application Load Balancer과 Classic Load Balancer는 모두 idle timeout을 설정할 수 있다. 기본 값은 60초다. Application Load Balancer의 경우 프론트 엔드 연결에만 적용된다. Classic Load Balancer의 경우 연결이 휴유 시간 초과를 초과할 경우 연결이 끊기고 클라이언트는 오류 응답을 받는다.
Application Load Balancer 및 Classic Load Balancer는 프런트 연결에 대해서 pipelined HTTP를 지원한다. 백앤드 연결에 대해서는 pipelined HTTP를 지원하지 않는다.
HTTP Headers
Application Load Balancer과 Classic Load Balancer는 X-Forwarded-For, X-Forwarded-Proto 및 X-Forwarded-Port 헤더를 지원한다. HTTP/2를 사용하는 프런트 엔드 연결의 경우 헤더 이름은 소문자이다.
HTTP Header Limits
Application Load Balancers는 아래와 같은 헤더크기 제한이 있다.
HTTP/1.x 헤더
Request line: 16K
Single header: 16K
Whole header: 64K
HTTP/2 헤더
Request line: 8K
Single header: 8K
Whole header: 64K
Load Balancer Scheme
로드 밸런서는 internal load balancer과 internet-facing load balancer 2개 타입이 있다. EC2 Classic 타입에 대한 Classic Load Balancer는 항상 internet-facing load balancer 이어야 한다.
Internet-facing load balancer는 인터넷에 노출되는 로드밸런서로 퍼블릭 IP 주소가 부여된다. 로드밸런서의 DNS 이름을 룩업해서 로드밸런서 노드의 퍼블릭 IP 주소를 확인 할 수 있다. 따라서 internet load balancer는 인터넷에서 전송되는 요청을 라우팅 할 수 있다.
Internal load balancer는 private IP 주소만 있다. Internal load balancer에 대한 DNS 룩업을 하면 private IP 주소가 리턴된다. 따라서 Internal load balancer는 VPC 내부에서만 사용 할 수 있다.
Internet-facing Load balancer과 interlan Load balancer 모두 private IP를 이용해서 라우팅한다. 따라서 타겟은 내부 또는 외부의 요청을 수신하기 위한 퍼블릭(public) IP가 필요하지 않다.
만약 애플리케이션이 멀티 티어 구성을하고 있다면, 인터넷과 내부 모두에서 로드밸런서를 사용하는 아키텍처를 설계 할 수 있다. 예를 들어 클라이언트 프로그램은 Internet-facing Load balancer를 이용해서 웹 서버에 연결하고, 웹 서버는 internal load balancer를 이용해서 API 서버 혹은 데이터베이스등에 연결 할 수 있다.
Elastic Load Balancing 다루기
Amazon은 Application Load Balancers, Network Load Balancers, Classic Load Balancers 세 가지 타입의 로드밸런서를 제공한다. 사용자는 애플리케이션 요구사항에 따라서 적당한 로드밸런서를 선택할 수 있다. 로드 밸런서 타입에 대한 자세한 설명은 Elastic Load Balancing 기능문서를 참고하자.
로드 밸런서에 대한 설정은 Elastic Load Balancing Demos를 참고하자.
만약 Classic Load Balancer를 사용하고 있다면 Application Load Balancer 이나 Network Load Balancer로의 마이그레이션을 고려해 볼 수 있다.
AWS는 보안 자격 증명(Security credentials)을 사용해서 사용자를 식별하고 AWS 리소스에 대한 접근권한을 부여한다. 그리고 AWS IAM(Identity and Access Management)를 이용해서 다른 사용자와 서비스, 애플리케이션의 접근을 허용 할 수 있다.
기본적으로 IAM 사용자는 AWS 리소스의 생성, 확인, 수정의 권한이 없다. IAM 유저가 로드 밸런서와 같은 리소스에 접근하고 작업을 수행하도록 하기 위해서는 아래의 작업을 수행해야 한다.
IAM 유저가 특정 리소스와 API작업을 할 수 있는 IAM 정책을 만든다.
IAM 유저자 혹은 IAM 유저가 포함된 그룹에 IAM 정책을 Attach 한다.
IAM 유저는 개인 이나 시스템 혹은 애플리케이션이 될 수 있다.
IAM 정책을 이용해서 권한 부여
IAM 정책을 만들어서 유저 혹은 그룹에 attach 하는 것으로 특정 리소스에 원하는 작업을 할 수 있는 권한을 부여하거나 거부 할 수 있다. IAM 정책은 아래와 같은 JSON으로 정의한다.
Effect : Allow 혹은 Deny를 설정 할 수 있다. 기본적으로 IAM 사용자는 리소스와 API를 이용 할 수 있는 권한이 없으므로 모든 요청이 거부된다. 따라서 명시적으로 Allow를 설정해야지만 자원을 사용 할 수 있다. 명시적으로 Deny를 설정할 경우 모든 권한이 무시된다.
Action : Action으로 API에 대하여 Allow 혹은 Deny를 적용할 행동을 설정 할 수 있다. 자원에 따라서 Action이 달라진다.
Resource : Action의 영향을 받는 자원이다. 사용자는 로드밸런서의 특정 기능에 대한 권한을 제한하거나 허용 할 수 있다.
Condition : 권한이 적용되는 시기를 제어하기 위한 여러 조건을 사용 할 수 있다.
OSI 모델에 따르면 로드밸런서는 Layer 4(전송 계층)과 Layer 7(애플리케이션 계층) 두 가지 타입이 있다. 전송계층의 대표적인 프로토콜들들로 TCP, UDP, RDP, SPX, SCTP있다. L4 로드밸런서는 TCP와 UDP를 주로 로드밸런싱 한다. 애플리케이션 계층은 FTP, HTTP, DNS, HTTPS, NTP, POP와 같은 인터넷 애플리케이션들이 사용하는 프로토콜들을 다룬다. 즉 L7 로드밸런서라 하면, HTTP와 HTTPS의 (헤더와 본문)내용을 읽어서 로드밸런싱 할 수 있는 기능을 가졌음을 의미한다. 대표적인 기능들은 Host 기반 라우팅, URL 경로 기반 라우팅, HTTP 요청 메서드, 출발지 IP, 쿼리 문자열, HTTP 헤더등 다양한 방식으로 라우팅을 수행 할 수 있다. 이러한 라우팅 기능은 REST 기반의 MSA 애플리케이션을 개발하는데 큰 도움을 준다.
Application Load Balancer를 이용하면 아래와 같은 구성이 가능하다.
경로기반 라우팅 기능을 이용해서 아래와 같이 이미지를 처리하는 웹 애플리케이션을 개발한다.
POST /wiki/image 는 이미지를 업로드하는 API다. POST /wiki/image 경로로의 요청은 Image Target Group으로 라우팅한다.
POST,GET /wiki/doc 는 웹 페이지를 서비스한다. POST,GET /wiki/doc 경로로의 요청은 App Target Group으로 라우팅한다.
Image Target Group과 App Target Group에 최적화된 인스턴스를 배치하는 식으로 서비스의 품질과 비용을 관리 할 수 있다.
Application Load Balancer과 Lambda
2018년 11월 Application Load Balancer 에서도 람다(Lambda) 함수를 호출해서 HTTP(S)를 호출할 수 있게 됐다. 이제 개발자는 Serverless(서버가 없는) 애플리케이션을 만들 수 있게 됐다.
Network Load Balancer
NLB는 Layer 4에서 작동하는 로드밸런서다. 로드 밸런서로드는 고정된(Static) Public IP, 즉 EIP 를 가질 수 있다. 어떤 인터넷 서비스들은 보안을 위해서 목적지 IP를 제한하기도 하는데, 이러한 경우 유용하게 사용 할 수 있다.
모든 애플리케이션은 추상화 단계가 높아질 수록 성능이 떨어지는 문제가 있다. NLB는 Layer 4에서 작동하기 때문에, Application Load Balancer 보다 훨씬 빠른 속도로 트래팩을 처리 할 수 있다. 반면 SSL 오프로딩, 호스트기반 라우팅, cross-zone 로드 밸런싱등의 기능을 사용 할 수 없기 때문에 목적에 맞게 사용하는게 중요하다.
용어 정리
Connection multiplexing
사용자가 클라이언트(웹 브라우저)로 요청을 보낼 경우, 웹 페이지의 여러 요소를 가져오기 위해서 여러 개의 요청을 웹 서버에 전송한다. 따라서 클라이언트와 서버 간에 많은 수의 연결을 만들 수 있다. 웹 서버에 대한 각 연결은 일반적으로 수명이 짧기 때문에, 연결 관리에 대한 오버헤드가 발생한다.
HTTP 1.1는 하나의 연결을 통해서 여러 요청을 처리하는 방식으로 오버헤드를 줄일 수 있다. 그러나 대량의 컨텐츠를 제공하는 인터넷 서비스 업체의 경우에는 이 것으로 부족 할 수 있다.
TCP 멀티플렉싱(TCP multiplexing)는 이미 열린 TCP 연결을 재 사용하는 기술이다. TCP 연결과 해제에는 많은 네트워크 오버헤드가 발생한다. 많은 네트워크 장비들은 서버와의 연결을 한 번 설정하고 이를 사용해서 클라이언트의 여러 요청을 처리함으로써 서버의 응답시간을 단축하고 처리 용량을 높인다.
HTTP pipelining
TCP 연결과 종료는 자원을 소비하기 때문에 이러한 단순한 모델을 사용하는 것은 성능의 제약을 가져온다. HTTP/1.1도 TCP를 기반으로 하기 때문에 동일한 문제를 가진다. 이 문제를 해결하기 위해서 HTTP/1.1은 Persistent connection 과 HTTP Pipelining으 두 가지 연결 모델을 제공한다.
Persitent connection은 연속적인 요청을 하나의 컨넥션으로 유지하며 새 연결을 만드는데 필요한 시간을 줄인다. HTTP pipeline은 연속적인 요청을 보내서 네트워크 지연을 더욱 줄일 수 있다.
Contents
Elastic Load balancing는 무엇인가 ?
로드밸런스의 이점
Elastic Load Balancing의 기능
Access Elastic Load Balancing
관련 서비스
Elastic Load Balancing 의 작동원리
가용 영역과 로드밸런서 노드들
크로스 존 로드 밸런싱
- 가용 영역 A의 인스턴스들은 각 25%의 트래픽을 처리한다.
- 가용 영역 B의 인스턴스들은 각 6.25%의 트래픽을 처리한다.
왜냐하면 가용 영역 A와 B로 50%씩의 트래픽이 흐르기 때문이다.라우팅 요청
라우팅 알고리즘
- 리스너(listener)의 룰을 우선해서 평가한다.
- 라우든로빈 알고리즘을 이용해서 타겟 그룹에서 타겟(노드)를 선택한다.
Network Load Balancer은 아래의 프로세스를 사용한다.- 흐름 해시 알고리즘(flow hash algorithm)을 이용해서 타겟 그룹에서 타겟을 선택한다. 이 알고리즘은 아래의 데이터를 기반으로 한다.
- 프로토콜
- Source(출발지) IP address와 Source port
- Destination(목적지) IP adress와 Destination port
- TCP sequence number
- TCP 연결이 지속되는 동안에는 단일 대상으로 라우팅한다.
클라이언트는 하나 이상의 TCP 연결을 만들 수 있다. 이들은 서로 다른 소스포트와 sequence number를 가지기 때문에 서로 다른 타겟으로 라우팅 될 수 있다. Classic Load Balancer를 아래의 방법으로 라우팅한다.HTTP Connections
HTTP Headers
HTTP Header Limits
- Request line: 16K
- Single header: 16K
- Whole header: 64K
HTTP/2 헤더Load Balancer Scheme
Elastic Load Balancing 다루기
Application Load Balancer 생성
Network Load Balancer 생성
Classic Load Balancer 생성
로드밸런서에서의 인증(Authentication)과 접근제어(Access Control)
- IAM 유저가 특정 리소스와 API작업을 할 수 있는 IAM 정책을 만든다.
- IAM 유저자 혹은 IAM 유저가 포함된 그룹에 IAM 정책을 Attach 한다.
IAM 유저는 개인 이나 시스템 혹은 애플리케이션이 될 수 있다.IAM 정책을 이용해서 권한 부여
{ "Version": "2012-10-17", "Statement":[{ "Effect": "effect", "Action": "action", "Resource": "resource-arn", "Condition": { "condition": { "key":"value" } } }] }- Effect : Allow 혹은 Deny를 설정 할 수 있다. 기본적으로 IAM 사용자는 리소스와 API를 이용 할 수 있는 권한이 없으므로 모든 요청이 거부된다. 따라서 명시적으로 Allow를 설정해야지만 자원을 사용 할 수 있다. 명시적으로 Deny를 설정할 경우 모든 권한이 무시된다.
- Action : Action으로 API에 대하여 Allow 혹은 Deny를 적용할 행동을 설정 할 수 있다. 자원에 따라서 Action이 달라진다.
- Resource : Action의 영향을 받는 자원이다. 사용자는 로드밸런서의 특정 기능에 대한 권한을 제한하거나 허용 할 수 있다.
- Condition : 권한이 적용되는 시기를 제어하기 위한 여러 조건을 사용 할 수 있다.
IAM에 대한 자세한 내용은 IAM User Guide를 참고하자.Application Load Balancer
- POST /wiki/image 는 이미지를 업로드하는 API다. POST /wiki/image 경로로의 요청은 Image Target Group으로 라우팅한다.
- POST,GET /wiki/doc 는 웹 페이지를 서비스한다. POST,GET /wiki/doc 경로로의 요청은 App Target Group으로 라우팅한다.
Image Target Group과 App Target Group에 최적화된 인스턴스를 배치하는 식으로 서비스의 품질과 비용을 관리 할 수 있다.Application Load Balancer과 Lambda
Network Load Balancer
용어 정리
Connection multiplexing
HTTP pipelining
참고
Recent Posts
Archive Posts
Tags