F5와 AWS: 클라우드의 고급 애플리케이션 딜리버리 서비스
소개
Amazon Web Services(AWS)는 가장 규모가 크고 널리 사용되는 퍼블릭 클라우드 서비스형 인프라(IaaS) 제공업체로 자리 잡았습니다. 이제 조직은 온프레미스 인프라를 구매하거나 재구성하지 않고도 전체 애플리케이션 스택을 구축, 테스트 및 배포할 수 있습니다. 프로덕션 애플리케이션은 웹 애플리케이션 방화벽(WAF), SSL 가속, 콘텐츠 기반 라우팅, 부하 분산, DDoS 완화, ID 및 액세스 관리, 프로토콜 민첩성과 같은 고급 애플리케이션 전송 서비스를 활용하여 핵심 애플리케이션을 더 빠르고 스마트하며 안전하게 운영할 수 있습니다. 클라우드 네이티브 AWS 배포 환경에서 F5 솔루션을 사용하면 이러한 애플리케이션 서비스를 AWS 클라우드 환경에 간편하게 제공할 수 있습니다.
Amazon Web Services란 무엇인가요?
IaaS 제공업체인 Amazon Web Services(AWS)는 애플리케이션 개발에 충분한 컴퓨팅 인프라를 임대 방식으로 제공합니다. 자본 비용이나 유지 관리 비용을 들이지 않고도 완전한 애플리케이션 제품군을 개발하고 배포할 수 있습니다. AWS는 온프레미스 환경과 같은 컴퓨팅 인프라를 제공할 뿐만 아니라 애플리케이션 서비스를 제공하고, 인프라를 자동으로 확장하며, 여러 위치에서 애플리케이션을 호스팅합니다. 이러한 추가 기능으로 인해 AWS의 모범 사례는 일반적인 데이터 센터의 모범 사례와 다릅니다. AWS와 기존 데이터 센터의 차이점을 더 잘 이해하려면 AWS가 서비스를 제공하는 방식을 파악하는 것이 중요합니다.
인프라 서비스
AWS를 최대한 활용하기 위해 지리적 분포, 컴퓨팅 인스턴스, 네트워킹, 스토리지 개념 등 AWS의 IaaS 서비스가 제공하는 몇 가지 주요 특성을 살펴보겠습니다.
지리적 분포
AWS를 이해하려면 먼저 리소스가 물리적으로 어떻게 분산되어 있는지 알아야 합니다. 최상위 수준에서 AWS는 여러 리전으로 구성되며, 각 리전은 미국 동부와 같은 넓은 지리적 영역을 포괄합니다. 각 리전에는 여러 가용 영역이 있으며, 가용 영역이라는 명칭은 각 영역이 서로의 장애로부터 격리되도록 설계되었다는 데서 유래합니다. 한 가용 영역(AZ)에서 발생한 장애는 동일한 리전 내의 다른 AZ로 확산되지 않습니다. 각 AZ는 서로 격리되어 있지만, 동일한 리전 내의 AZ들은 지연 시간이 짧은 네트워크 링크로 연결됩니다. 가용성을 확보하기 위해 리전 내 여러 AZ에 걸쳐 기능을 이중화하는 설계 패턴을 사용할 수 있습니다.
컴퓨팅
컴퓨팅 인스턴스는 Amazon Machine Image(AMI)라고 하는 소프트웨어 디스크 이미지에서 시작됩니다. 각 AMI는 변경할 수 없으므로 이를 사용하는 컴퓨터에서는 읽기 전용입니다. AMI를 사용하여 컴퓨팅 인스턴스를 부팅하면 클라우드에서 실행되는 가상 머신이 생성됩니다. 컴퓨팅 인스턴스의 가상 하드웨어 사양은 인스턴스에서 사용할 수 있는 CPU 수와 RAM 용량 등에 따라 달라질 수 있습니다.
네트워킹
각 컴퓨팅 인스턴스는 물리적 환경의 LAN과 대략적으로 대응하는 가상 사설 클라우드(VPC) 내에 존재합니다. 각 VPC는 논리적으로 분리되어 있습니다. 하나의 VPC는 서브넷 간 암시적 라우팅이 적용되는 여러 서브넷으로 구성될 수 있습니다. 퍼블릭 서브넷은 인터넷에서 라우팅할 수 있지만, 프라이빗 서브넷은 내부에서만 사용할 수 있습니다. 완전한 애플리케이션을 배포하려면 하나 이상의 컴퓨팅 인스턴스를 VPC 내에 배포합니다. 컴퓨팅 인스턴스 또는 로드 밸런서에 DNS 항목이 할당되어 있으면 VPC 간 통신이 가능합니다.
스토리지
앞서 언급했듯이 각 AMI는 이를 사용하는 인스턴스에서 변경할 수 없습니다. 영구 스토리지를 위해 AWS는 다양한 솔루션을 제공하며, 대표적으로 Simple Storage Service(S3)와 Elastic Block Storage(EBS)가 있습니다. S3는 객체를 이름으로 저장하고 액세스할 수 있는 객체 스토리지 서비스입니다. 객체 크기는 0바이트에서 5TB까지 가능합니다. 실제로 각 AMI는 암묵적으로 S3 객체입니다. 객체는 수정할 수 없고 생성 및 삭제만 가능하므로 사진이나 가상 머신 이미지처럼 비교적 정적인 콘텐츠에 적합합니다.
EBS는 기존 스토리지와 유사한 형태의 스토리지를 제공합니다. EBS에 연결된 컴퓨팅 인스턴스는 EBS를 일반적인 하드 디스크로 인식합니다. 한 번에 하나의 실행 중인 인스턴스만 EBS 볼륨에 연결할 수 있으므로 EBS는 공유 스토리지로 사용할 수 없습니다.
서비스 확장
AWS는 핵심 인프라 구성 요소를 제공할 뿐만 아니라 애플리케이션 확장을 지원하는 추가 서비스도 제공합니다. AWS는 인프라 리소스를 신속하게 프로비저닝할 수 있으므로, Amazon은 이러한 리소스의 자동 확장과 부하 분산을 지원하는 솔루션을 개발했습니다.
로드 밸런싱
AWS는 Elastic Load Balancing(ELB) 서비스를 제공합니다. 처음에 ELB는 계층 4에서 작동하며 풀에 있는 정상 상태의 여러 노드로 트래픽을 분산하는 단순한 로드 밸런서를 의미했습니다. 이 풀은 여러 가용 영역에 걸쳐 구성할 수 있어, 한 가용 영역에 장애가 발생하더라도 자동으로 이중화를 제공합니다. 이 로드 밸런서는 몇 가지 기본적인 네트워크 계층 7 기능도 제공하지만, 주로 계층 4에서 작동하며 TCP 트래픽을 라운드 로빈 방식으로 풀의 노드에 전달합니다. 상태 확인을 통해 사용 가능한 노드를 파악하고 트래픽을 전달할 대상을 결정합니다. AWS는 이제 이 초기 로드 밸런서를 새로운 Application Load Balancer(ALB)와 구분하기 위해 Classic Load Balancer라고 부릅니다.
오토 스케일링
AWS에는 대기 용량이 있으므로 풀 내의 노드 수를 조정하는 옵션을 제공할 수 있습니다. AWS CloudWatch 서비스는 풀 내 각 노드의 성능 지표를 모니터링합니다. CPU 사용률이 5분 동안 60%를 초과하는 경우와 같이 사전 정의된 임계값을 넘으면 노드가 하나 더 프로비저닝됩니다. 반대로 하한 임계값 아래로 내려가면 노드 하나가 제거됩니다. 설계자는 풀의 최대 및 최소 노드 수와 노드 생성 또는 제거를 트리거하는 임계값을 지정할 수 있습니다. 로드 밸런서 뒤에서 오토 스케일링을 사용하면 부하에 따라 필요에 맞게 노드 풀을 확장하거나 축소할 수 있습니다.
F5 애플리케이션 전송 서비스
애플리케이션은 비즈니스 규칙과 로직을 처리하지만, 대규모 프로덕션 환경에서 배포, 관리 및 운영하는 데 필요한 보안 강화가 부족한 경우가 많습니다. F5 솔루션은 아래 표에 설명된 고급 애플리케이션 딜리버리 서비스를 제공하여 애플리케이션이 더 빠르고 스마트하며 안전하게 작동하도록 지원합니다.
F5 고급 애플리케이션 전송 서비스
애플리케이션 수준 모니터링
- 고급 애플리케이션 상태 점검(다단계 모니터 사용)
- 다단계 상태 확인(예: 데이터베이스와 애플리케이션이 모두 사용 가능한지 확인)
- 비HTTP 상태 확인(예: SIP, Microsoft Windows SQL Server 및 FTP)
- 가장 원활하게 작동하는 서버에 트래픽을 더 효율적으로 분산하는 고급 알고리즘
글로벌 가용성
- 서로 다른 클라우드 제공업체 또는 데이터 센터가 혼재된 이기종 환경 전반에서 애플리케이션 가용성 확보
- BIG-IP 고급 모니터와의 통합
- DNSSEC 지원
더 빠르게
네트워크 및 전송 최적화
- WAN 및 셀룰러 네트워크에서 최적의 전송 성능을 제공하도록 구성할 수 있는 TCP 스택
- 백엔드 인프라를 변경하지 않고도 추가 압축 및 요청 멀티플렉싱의 이점을 제공하는 HTTP/2 게이트웨이
애플리케이션 및 데이터 최적화
- 감지된 네트워크 또는 클라이언트 특성에 따른 선택적 실시간 이미지 최적화
- 적응형 압축 및 TCP 최적화를 통한 SSL 암호화 터널상의 WAN 가속
더 스마트하게
데이터 경로 프로그래밍 기능
- 애플리케이션 데이터의 모든 측면을 읽고, 쓰고, 검사하는 기능을 포함하여 애플리케이션 트래픽을 프로그래밍 방식으로 완벽하게 제어
- 이벤트 기반의 포괄적인 언어
제어 플레인 프로그래밍 기능
- 서버 부하, 애플리케이션 동작 또는 인프라의 변화와 같은 이벤트에 대응하여 구성을 수정할 수 있는 기능
- 완전 자율형 또는 외부 API 기반 트리거
더 안전함
고급 네트워크 방화벽 서비스
- 지리적 위치나 엔드포인트 평판 등 단순한 IP:포트:프로토콜을 넘어서는 기준을 활용한 트래픽 제어 결정
- HTTP 프로토콜 검증
- 요일 및 시간 일정
웹 애플리케이션 방화벽 서비스
- 웹 애플리케이션 위협을 식별하고 악성 트래픽을 차단하는 종합 도구
- 아웃바운드 데이터 손실 방지(DLP) 서비스
액세스 및 ID 서비스
- 2단계 인증 토큰, CAPTCHA 또는 지역 제한과 같은 고급 인증 서비스
- 클라이언트 인증서 확인 및 엔드포인트 검사
- SAML 서비스 공급자(SP) 및 ID 공급자(IdP) 서비스
서비스 거부(DoS) 공격 완화
- 선제적 봇 방어
- 레이어 7 DoS 탐지 및 완화
SSL 및 암호화
- SSL 복호화, 트래픽 검사 및 재암호화
- 컴퓨팅 노드 리소스에서 SSL 워크로드 오프로딩
고급 애플리케이션 딜리버리 서비스를 활용하면 애플리케이션의 가용성과 보안을 강화하는 동시에 더 높은 수준의 성능을 구현할 수 있습니다. 이러한 서비스는 각 애플리케이션과 독립된 전략적 제어 지점에 배치할 수 있습니다. 서비스를 애플리케이션 비즈니스 로직과 분리하면 개발 팀에 인프라, 관리 및 성능 관련 부담을 주지 않으면서 애플리케이션이 비즈니스 요구 사항을 충족할 수 있습니다. 또한 전략적 제어 지점을 통해 거버넌스 문제를 각 애플리케이션과 독립적으로 일관되게 처리할 수 있습니다.
모든 요소의 통합: F5와 AWS
F5는 AWS 인프라와의 클라우드 네이티브 통합을 제공하여 조직이 AWS 배포 환경을 최대한 활용하고 애플리케이션의 성능, 가용성 및 보안을 강화할 수 있도록 지원합니다. 다음 섹션에서는 AWS와 F5가 어떻게 연동되는지 살펴보겠습니다.
부트스트래핑
서버 인스턴스가 일반 이미지로 부팅될 때는 호스트 이름과 IP 주소 같은 매개변수를 변경하거나 구성을 설정해야 하는 경우가 많습니다. 클라이언트 시스템에서는 이러한 매개변수를 DHCP를 통해 설정하지만, 서버 매개변수를 DHCP로 설정하면 문제가 발생하는 경우가 많습니다. 네트워크 설정 외에도 특정 인스턴스에 특정 소프트웨어 패키지나 소프트웨어 구성이 필요할 수 있습니다.
BIG-IP 배포의 경우 관리자는 BIG-IP Local Traffic Manager (LTM)의 가상 서버 및 풀 구성, BIG-IP Application Security Manager의 특정 WAF 구성 또는 BIG-IP Advanced Firewall Manager의 방화벽 설정과 같은 각 모듈의 구성을 자동화하고자 할 수 있습니다. 서버 인스턴스를 설치하는 사람이라면 누구나 동일한 문제에 직면합니다. 기본 이미지가 올바르게 작동하려면 추가 구성이 필요합니다.
AWS는 인스턴스를 구성하는 두 가지 주요 방법을 제공합니다. 하나는 새 AMI를 생성하는 것이고, 다른 하나는 cloud-init을 사용하여 부팅 과정에서 서버를 수정하는 것입니다. 새 AMI를 생성하는 방법은 여러 인스턴스에 공통으로 적용되며 자주 업데이트될 가능성이 낮은 변경 사항에 더 적합합니다. 반면 cloud-init은 더 적은 수의 인스턴스에 영향을 미치고 수명이 짧은 변경 사항에 더 적합합니다.
AMI
장기간 유지될 것으로 예상되는 변경 사항이나 여러 인스턴스에 공통으로 적용되는 변경 사항의 경우, 원하는 구성과 유사한 AMI로 머신을 부팅한 후 새 AMI를 생성하는 것이 좋습니다. 관리자가 실행 중인 인스턴스에 필요한 변경 사항을 적용한 다음 인스턴스를 중지하면, 새 AMI가 생성되어 AWS에 등록됩니다. 이후 이 AMI로 부팅되는 모든 인스턴스에는 해당 변경 사항이 이미 적용되어 있습니다. 이 방식은 변경 사항을 사실상 영구적으로 적용하며 새 AMI를 생성하는 데 시간이 걸릴 수 있으므로, 일반적으로 AMI에 포함하는 변경 사항은 장기간 유지되고 여러 인스턴스에서 사용할 수 있는 것들입니다. AMI를 사용하는 또 다른 이유는 일부 cloud-init 프로세스에 많은 시간이 소요될 수 있는 만큼 부팅 시간을 단축할 수 있기 때문입니다.
Cloud-init
새 AMI에 포함하기에 적합하지 않은 필수 변경 사항은 인스턴스가 부팅될 때마다 시작 스크립트를 실행할 수 있게 해 주는 cloud-init을 사용하는 것이 좋습니다. cloud-init을 사용하면 간단한 변경 사항과 인스턴스별 변경 사항을 인스턴스에 포함할 수 있습니다.
cloud-init의 단점은 패키지 설치와 같은 구성 변경 작업을 부팅 시 실행해야 하므로 부팅 시간이 길어진다는 점입니다. 부팅 시간이 길어지면 자동 확장 시나리오에서 실질적인 영향을 미치며, 지나치게 긴 부팅 시간으로 인해 자동 확장이 제대로 작동하지 않을 수 있습니다. 따라서 시간이 많이 걸리는 변경 사항은 cloud-init을 통해 적용하는 대신 새 AMI에 포함해야 합니다.
변경 사항을 여러 인스턴스에 적용할 수 있지만 모든 인스턴스에 적용할 수는 없는 경우, 구성 관리가 번거로울 수도 있습니다. 예를 들어 특정 가상 서버 구성을 사용하는 자동 확장 그룹에 특정 BIG-IP 배포가 사용된다고 가정해 보겠습니다. 해당 머신에는 하나의 AMI를 사용하고, 다른 자동 확장 그룹의 다른 BIG-IP 머신에는 별도의 AMI를 사용할 수 있습니다. 자동 확장 그룹마다 하나의 AMI를 사용하면 cloud-init 프로세스에서는 각 호스트에만 해당하는 변경 사항만 적용하면 됩니다. 그룹에 공통으로 적용되는 변경 사항은 AMI에 포함할 수 있습니다. 이 접근 방식의 단점은 모든 머신에 공통으로 적용되는 변경 사항이 있을 때마다 AMI를 업데이트해야 한다는 것입니다.
자동 확장
애플리케이션은 일반적으로 여러 사용자에게 동시에 기능을 제공합니다. 애플리케이션이 더 성공적으로 운영될수록 해당 애플리케이션이 실행되는 컴퓨터의 용량을 초과할 수 있습니다. 애플리케이션의 요구 사항이 컴퓨터의 용량을 초과하면 용량을 늘릴 수 있는 방안을 검토해야 합니다. 확장에는 일반적으로 스케일 업, 파이프라이닝, 스케일 아웃이라는 세 가지 접근 방식이 있습니다.
스케일 업
스케일 업은 기존 컴퓨터를 더 빠른 컴퓨터로 교체하기만 하면 되므로 용량을 늘리는 가장 간단한 방법입니다. 더 빠른 컴퓨터를 설치하면 애플리케이션이나 인프라를 변경하지 않아도 애플리케이션의 모든 부분과 해당 컴퓨터에서 실행되는 기타 서비스의 속도가 향상됩니다. 스케일 업의 단점은 성능이 향상될수록 비용이 기하급수적으로 증가하는 경향이 있어 결국 수익 체감 지점에 이르게 된다는 것입니다. 일정 임계점을 넘어서면 스케일 업은 비용 부담이 지나치게 커집니다.
파이프라이닝
파이프라이닝은 조립 라인과 유사하게 워크로드를 순차적인 단계로 분해한 결과입니다. 서로 다른 컴퓨터가 각 단계를 독립적으로 처리할 수 있으면 전체 처리량을 높일 수 있습니다. 하지만 파이프라이닝은 처리량만 늘리며, 그 과정에서 지연 시간이 늘어나는 경우가 많습니다. 다시 말해, 파이프라이닝은 전반적인 성능을 향상시킬 수 있지만 개별 사용자나 단일 요청의 성능은 저하시킬 수 있습니다. 파이프라이닝의 또 다른 단점은 분해 가능한 워크플로를 깊이 이해해야 하며, 인프라도 그에 맞게 구성해야 한다는 점입니다. 이로 인해 인프라 관련 결정이 비즈니스 로직과 긴밀하게 결합되는데, 이는 많은 조직이 추구하는 방향과 정반대입니다.
스케일 아웃
스케일 아웃은 애플리케이션과 컴퓨터는 그대로 둔 채, 여러 서버로 구성된 풀에 요청을 고르게 분산하는 방식입니다. 일반적으로 애플리케이션은 서로 독립적인 여러 요청을 동시에 처리하므로, 동일한 애플리케이션 서버로 구성된 풀 전체에 요청을 안전하게 분산할 수 있습니다. 또한 스케일 아웃은 풀의 구성원 중 하나에 장애가 발생하더라도 전체 애플리케이션이 중단되지 않는다는 이중화의 이점이 있습니다. 단점은 풀의 노드 전체에 요청을 균등하게 분산하려면 애플리케이션 외부에서 복잡한 오케스트레이션이 필요하다는 점입니다.
AWS 오토 스케일링
AWS Auto Scaling은 용량이 필요한 애플리케이션을 위해 스케일 아웃 방식으로 용량을 늘립니다. CloudWatch 서비스는 풀의 노드를 모니터링합니다. 노드가 사전 정의된 임계값을 넘으면 CloudWatch가 필요에 따라 새 노드를 자동으로 시작하거나 풀의 노드를 종료합니다. BIG-IP 플랫폼에서는 이 프로세스를 두 가지 방식 중 하나로 수행할 수 있습니다. BIG-IP 인스턴스 수를 변경하거나 단일 BIG-IP 인스턴스 뒤에 있는 풀의 노드 수를 변경하는 방식입니다. 두 방식의 차이는 확장 대상이 BIG-IP 인스턴스인지 풀인지에 따라 결정됩니다.
첫 번째 시나리오에서는 BIG-IP 풀이 한 쌍의 ELB 디바이스 사이에 위치합니다. 첫 번째 ELB 디바이스는 BIG-IP 멤버의 인스턴스 생성 및 종료를 제어하고, 두 번째 ELB 디바이스는 각 BIG-IP 인스턴스의 서버 풀에 있는 유일한 항목입니다. 이 방식은 BIG-IP 인스턴스가 SSL 종료 또는 웹 애플리케이션 방화벽 역할과 같은 고급 애플리케이션 전송 서비스를 제공할 때 적합합니다. 첫 번째 ELB 디바이스는 부하 분산을 수행하는 동시에 필요에 따라 풀을 확장하거나 축소합니다.
두 번째 시나리오에서는 CloudWatch를 통해 백엔드 풀 멤버 수가 늘어나거나 줄어들지만, 로드 밸런싱은 BIG-IP 인스턴스가 수행합니다. BIG-IP 인스턴스는 AWS와 통신하여 풀에 추가되거나 풀에서 제거되는 노드를 감지합니다. 이 방식은 iRules 스크립팅 언어와 같은 고급 로드 밸런싱 기능을 사용하거나 URL 또는 콘텐츠를 기반으로 요청을 전달할 때 적합합니다. 이러한 경우에는 단일 BIG-IP 인스턴스만으로도 백엔드 풀에 있는 서버의 부하를 충분히 관리할 수 있습니다.
보안 및 IAM
BIG-IP 인스턴스는 최소 두 가지 시나리오에서 AWS 인프라와 상호 작용해야 합니다. 첫째, 다중 영역 AWS 배포에서는 AWS 탄력적 IP에 연결된 IP 주소를 변경해야 합니다. 둘째, BIG-IP 인스턴스는 풀 내 서버 수를 확장하거나 축소하는 AWS CloudWatch 서비스에 의해 추가되거나 제거되는 풀 멤버를 파악할 수 있어야 합니다. 인프라와의 각 상호 작용은 API 호출을 통해 이루어지며, API를 호출하는 다른 소프트웨어와 마찬가지로 BIG-IP 인스턴스도 AWS에 인증해야 합니다. 일반적으로 AWS 인증 방식에는 자격 증명을 사용하는 방식과 IAM 역할을 사용하는 방식의 두 가지가 있습니다.
자격 증명
가장 간단한 인증 방법은 API 호출에 적절한 자격 증명을 포함하는 것입니다. AWS 자격 증명은 사용자 이름과 암호에 대략적으로 대응하는 액세스 키와 보안 키로 구성됩니다. 관리자가 자격 증명을 생성하면 개발자가 이를 애플리케이션에 포함합니다. 이를 통해 애플리케이션은 적절한 API 호출에 액세스할 수 있습니다.
간단한 방법이기는 하지만, 애플리케이션에 자격 증명을 포함하면 보안 위험이 따릅니다. 개발자가 애플리케이션 내 자격 증명을 안전하게 보호하지 않으면 다른 사람이나 소프트웨어가 이를 알아내 악의적으로 사용할 수 있습니다. 또한 이 방식은 소프트웨어를 변경하지 않고 자격 증명만 변경하기 어렵게 만듭니다. 자격 증명을 사용하는 방식은 빠른 테스트에는 적합하지만, 프로덕션 솔루션에서는 다른 인증 방식을 사용해야 합니다. 이러한 이유로 AWS 모범 사례에서는 애플리케이션에 저장된 자격 증명을 사용하지 않도록 권장합니다.
ID 및 액세스 관리
API 호출 인증에 IAM 역할을 사용하는 것이 더 안전한 접근 방식입니다. AWS Identity and Access Management(IAM)를 사용하면 AWS 인프라에 대한 액세스를 관리할 수 있습니다. BIG-IP 머신과 같은 모든 컴퓨팅 인스턴스에는 특정 기능 집합을 승인하는 IAM 역할을 할당할 수 있습니다. 인스턴스가 시작되면 IAM은 해당 인스턴스에 사용할 임시 자격 증명 집합을 생성합니다. 이러한 자격 증명은 인스턴스가 작동하는 동안 유효하며 지정된 API 기능만 사용할 수 있도록 합니다. IAM 역할로 구성된 BIG-IP 인스턴스는 자격 증명을 저장하지 않고 필요한 인프라 API에만 액세스하므로 자격 증명 기반 인증보다 더 높은 보안성을 제공합니다.
다중 영역 가용성
앞서 언급했듯이 AWS 데이터 센터는 여러 지리적 리전에 위치하며, 각 데이터 센터는 가용 영역(AZ)에 속할 수 있습니다. 한 리전 내의 각 AZ는 전력, 네트워크, 건물 등 어떤 것도 다른 AZ와 공유하지 않습니다. 실제로 한 리전 내의 각 AZ는 지리적으로 서로 분리되어 있습니다. 이처럼 영역이 분리되어 있으므로 AWS 구독자는 한 AZ에 영향을 미치는 이벤트가 다른 AZ에는 영향을 미치지 않을 것이라고 확신할 수 있습니다. 즉, 원칙적으로 특정 시점에 한 리전 내에서 사용할 수 없는 AZ는 최대 하나여야 합니다. 따라서 두 개 이상의 가용 영역에 배포된 서비스는 지속적으로 사용 가능해야 합니다.
BIG-IP 플랫폼은 컴퓨팅 인스턴스에 본질적으로 연결되지 않는 IP 주소인 AWS 탄력적 IP를 사용하여 AWS AZ 전반에서 고가용성을 지원합니다. 이 IP 주소는 실행 중인 컴퓨팅 인스턴스의 프라이빗 IP 주소로 동적으로 전달될 수 있습니다. 다중 영역 고가용성을 구현하기 위해 동일하게 구성된 BIG-IP 인스턴스 및 애플리케이션 서버 세트를 각각 별도의 AZ에 배치합니다. 처음에는 탄력적 IP가 BIG-IP 인스턴스 중 하나에 할당됩니다. 각 클라이언트는 탄력적 IP에 연결되며, 탄력적 IP는 연결을 BIG-IP 인스턴스 중 하나의 프라이빗 IP 주소로 전달합니다. 장애가 발생하면 다른 BIG-IP 인스턴스가 AWS에 API 호출을 보내 탄력적 IP 주소가 자신에게 전달되도록 요청함으로써 해당 역할을 인계받습니다.
Elastic Load Balancer
ELB와 통합하면 BIG-IP 플랫폼은 여러 AZ 및 BIG-IP 노드 자동 확장과 같은 AWS 기능과 원활하게 연동되는 애플리케이션 서비스를 제공할 수 있습니다.
BIG-IP 인스턴스 앞에 ELB를 배치하면 여러 AZ에 걸친 배포가 간소화됩니다. ELB가 BIG-IP 인스턴스에서 애플리케이션 서비스를 제공하는 각 AZ 내의 개별 애플리케이션 스택으로 트래픽을 원활하게 분산할 수 있기 때문입니다. 이 접근 방식은 여러 AZ에 걸친 부하 분산을 간소화합니다.
BIG-IP 인스턴스의 탄력성이 필요한 경우, 자동 확장 기능이 있는 ELB는 BIG-IP 가상 어플라이언스 풀을 자동으로 확장하거나 축소하면서 웹 애플리케이션 방화벽, ID 관리 또는 SSL 종료와 같은 애플리케이션 서비스를 제공할 수 있습니다. ELB 샌드위치 구성을 사용하면 트래픽이 첫 번째 ELB로 라우팅되고, 이 ELB가 BIG-IP 인스턴스 풀로 전달되는 트래픽의 부하를 분산하고 자동으로 확장합니다. BIG-IP 풀 전체의 구성을 간소화하기 위해 각 BIG-IP 인스턴스는 서버 풀에서 단일 ELB 주소를 사용합니다. 그런 다음 두 번째 ELB가 트래픽을 다운스트림 서버 풀로 라우팅합니다.
ELB와 BIG-IP 토폴로지를 다양하게 조합하면 어느 한쪽만으로는 제공할 수 없는 자동 확장, 가용성 및 애플리케이션 서비스를 제공할 수 있습니다. 아키텍트는 ELB와 BIG-IP 플랫폼의 장점을 모두 활용하여 특정 배포에 필요한 수준의 서비스를 제공할 수 있습니다.
CloudFormation 템플릿
반복 가능하고 스크립트로 자동화된 배포를 지원하기 위해 AWS는 배포와 지속적인 관리를 간소화하는 Cloud Formation Templates(CFT)를 제공합니다. 원하는 서비스 또는 애플리케이션 아키텍처에 맞는 CFT를 생성하면 AWS에서 이를 사용해 애플리케이션을 빠르고 안정적으로 프로비저닝할 수 있습니다. CFT는 DevOps 환경에서 특히 유용하며, 팀이 테스트 및 프로덕션 배포를 위한 반복 가능한 프로세스를 손쉽게 구축할 수 있도록 지원합니다.
F5는 CFT를 사용한 BIG-IP 인스턴스 배포를 지원할 뿐만 아니라, 일반적인 BIG-IP 배포를 위한 여러 참조 CFT 파일도 제공합니다.
참조 CFT 파일의 매개 변수를 조정하면 BIG-IP 인스턴스 또는 BIG-IP 인스턴스 뒤의 백엔드 서버를 자동으로 확장하는 시나리오를 비롯해 더욱 복잡한 시나리오까지 다양한 상황에 맞게 BIG-IP 솔루션을 스크립트로 배포할 수 있습니다. CFT와 F5 솔루션을 사용하여 AWS 내에서 반복 가능한 배포를 자동화하면 복잡한 애플리케이션 환경을 적은 작업만으로 신속하게 배포할 수 있습니다.
문서
물론 기술을 충분히 활용할 수 없다면 그 유용성은 크지 않습니다. 이를 위해 F5는 광범위한 문서를 제공합니다. BIG-IP 플랫폼 전반에 관한 문서와 AWS 내 BIG-IP 인스턴스의 세부 사항에 관한 문서를 이용할 수 있습니다. 궁금한 사항이 있다면 먼저 Ask F5에서 확인해 보십시오.
문서 탭에서는 특정 BIG-IP 모듈에 대한 정보와 AWS 통합에 관한 전체 섹션을 제공합니다. AWS 포털에서는 시작하기부터 복잡한 배포 시나리오에 이르기까지 문서, 문서 자료, 커뮤니티 및 리소스를 검색할 수 있는 인터페이스를 제공합니다.
문서에서 답을 찾을 수 없는 질문에 대해서는 F5 DevCentral 커뮤니티에서 답변과 도움을 제공해 드립니다.
결론
퍼블릭 클라우드 도입은 더 이상 일시적인 유행이 아니라 IT 업계의 지속적인 추세로 자리 잡았습니다. 세계 최대 규모이자 가장 포괄적인 퍼블릭 클라우드 서비스 제공업체인 Amazon Web Services를 통해 조직은 온프레미스 장비 없이도 애플리케이션을 구축, 테스트 및 배포할 수 있습니다. F5는 AWS 에코시스템의 일부로 고급 애플리케이션 딜리버리 서비스를 제공하며, AWS 클라우드 환경에서 앱이 더 빠르고 스마트하며 안전하게 작동하도록 구성했습니다.
2017년 3월 14일 게시