F5 및 AWS: 클라우드에서의 고급 애플리케이션 제공 서비스

Amazon Web Services(AWS)는 가장 크고 가장 널리 쓰이는 퍼블릭 클라우드 인프라 즉 서비스(IaaS) 공급업체가 되었습니다. 이제 조직에서는 온프레미스 인프라를 구매하거나 재구성하지 않고도 전체 애플리케이션 스택을 구축, 테스트 및 배포할 수 있습니다. 프로덕션 애플리케이션은 웹 애플리케이션 방화벽(WAF), SSL 가속, 콘텐츠 기반 라우팅, 부하 분산, DDoS 완화, ID 및 액세스 관리, 프로토콜 민첩성과 같은 고급 애플리케이션 제공 서비스의 이점을 누릴 수 있으며, 이를 통해 이러한 주요 애플리케이션이 더 빠르고, 더 스마트하고, 더 안전하게 실행될 수 있습니다. 클라우드 기반 AWS 배포의 경우, F5 솔루션을 사용하면 이러한 애플리케이션 서비스를 AWS 클라우드 환경에 간편하고 쉽게 제공할 수 있습니다.

IaaS 공급업체인 Amazon Web Services(AWS)는 애플리케이션을 개발하는 데 충분한 임대 컴퓨팅 인프라를 제공합니다. 자본 지출이나 유지 관리에 돈을 들이지 않고도 완벽한 애플리케이션 제품군을 개발하고 배포할 수 있습니다. AWS는 온프레미스와 동일한 컴퓨팅 인프라를 제공할 뿐만 아니라 애플리케이션 서비스를 제공하고, 인프라를 자동으로 확장하며, 여러 위치에서 애플리케이션을 호스팅합니다. 이러한 추가적인 기능으로 인해 AWS의 모범 사례는 기존 데이터 센터의 모범 사례와 다릅니다. AWS와 기존 데이터 센터의 차이점을 더 잘 이해하려면 AWS가 서비스를 제공하는 방식을 이해하는 것이 중요합니다.

AWS의 이점을 최대한 활용하려면 지리적 분포, 컴퓨팅 인스턴스, 네트워킹, 스토리지 개념 등 IaaS 서비스의 여러 가지 중요한 속성을 살펴보겠습니다.

AWS를 이해하려면 리소스가 어떻게 분산되는지에 대한 물리적 설명부터 시작하세요. AWS는 최상위 수준에서 여러 지역으로 나뉘며, 각 지역은 미국 동부와 같이 넓은 지리적 영역을 담당합니다. 각 지리적 지역에는 여러 개의 가용성 영역이 있으며, 이러한 이름은 서로의 장애로부터 격리되도록 설계되었기 때문에 붙은 것입니다. 한 가용성 영역(AZ)에서 장애가 발생해도 해당 지역 내의 다른 AZ로 확산되지 않습니다. 각 AZ는 격리되어 있는 반면, 한 지역 내의 AZ는 저지연 네트워크 링크를 통해 연결됩니다. 가용성을 목적으로, 지역 내 여러 AZ에 걸쳐 중복 기능을 제공하기 위한 설계 패턴이 존재합니다.

컴퓨팅 인스턴스는 Amazon Machine Image(AMI)라고 하는 소프트웨어 디스크 이미지로 시작됩니다. 각 AMI는 변경할 수 없습니다. 즉, AMI를 사용하는 컴퓨터에서는 읽기 전용입니다. AMI에 따라 컴퓨팅 인스턴스를 부팅하면 클라우드에서 실행 중인 가상 머신이 생성됩니다. 컴퓨팅 인스턴스의 가상 하드웨어 특성은 인스턴스에서 사용할 수 있는 CPU 수와 RAM 수 등 다양할 수 있습니다.

각 컴퓨팅 인스턴스는 가상 사설 클라우드(VPC) 내에 존재하며, 이는 물리적 세계의 LAN과 거의 같습니다. 각 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는 ELB(Elastic Load Balancing) 서비스를 제공합니다. 처음에 ELB는 풀 내의 여러 개의 정상 노드에 트래픽을 분산시키는 4계층에서 작동하는 간단한 로드 밸런서를 의미했습니다. 풀은 여러 가용성 영역에 걸쳐 있을 수 있으므로, 한 가용성 영역에 장애가 발생할 경우 자동 중복성을 생성할 수 있습니다. 이 로드 밸런서는 기본적인 네트워크 계층 7 기능을 제공하지만, 기본적으로 계층 4에서 작동하며 풀의 노드로 라운드 로빈 방식으로 TCP 트래픽을 라우팅합니다. 상태 점검은 어떤 노드가 사용 가능한지, 따라서 트래픽 후보인지를 판별합니다. AWS는 이제 이 초기 로드 밸런서를 클래식 로드 밸런서라고 부르며 새로운 애플리케이션 로드 밸런서(ALB)와 구별합니다.

AWS에는 사용 가능한 대기 용량이 있으므로 풀 내에서 노드를 확장하는 옵션을 제공할 수 있습니다. AWS CloudWatch 서비스는 풀 내의 각 노드에 대한 성능 지표를 모니터링합니다. 미리 정의된 임계값(예: CPU 사용률이 5분 동안 60%를 초과하는 경우)을 초과하면 다른 노드가 프로비저닝됩니다. 반대로, 더 낮은 임계값을 넘어서면 노드가 제거됩니다. 설계자는 풀의 최대 및 최소 노드 수와 노드 인스턴스화 또는 노드 제거를 트리거하는 임계값을 결정할 수 있습니다. 로드 밸런서 뒤에서 자동 크기 조정을 사용하면 부하에 따라 필요에 따라 노드 풀을 확장하거나 축소할 수 있습니다.

애플리케이션은 비즈니스 규칙과 논리를 처리하지만, 대규모 프로덕션 배포, 관리 및 운영에 필요한 강화 기능이 부족한 경우가 많습니다. F5 솔루션은 아래 표에 자세히 설명된 고급 애플리케이션 전송 서비스를 제공하여 애플리케이션이 보다 빠르고, 스마트하고, 안전하게 실행될 수 있도록 합니다.

F5 고급 애플리케이션 제공 서비스

애플리케이션 수준 모니터링

• 고급 애플리케이션 상태 점검(다단계 모니터 사용)
• 다중 레벨 상태 점검(데이터베이스와 애플리케이션이 모두 사용 가능한지 확인하는 것과 같은)
• HTTP가 아닌 상태 검사(SIP, Microsoft Windows SQL Server 및 FTP 등)
• 트래픽을 가장 잘 작동하는 서버로 더 잘 분산하기 위한 고급 알고리즘

글로벌 가용성

• 다양한 클라우드 공급자 또는 데이터 센터의 이기종 혼합에 걸친 애플리케이션 가용성
• BIG-IP 고급 모니터와 통합
• DNSSec 지원

고급 애플리케이션 제공 서비스를 통해 애플리케이션은 더 높은 수준에서 수행되고, 가용성이 높고 보안이 강화됩니다. 이러한 서비스는 각 애플리케이션과 별개로 전략적 제어 지점에 존재할 수 있습니다. 서비스를 애플리케이션 비즈니스 로직에서 분리하면 개발팀에 인프라, 관리, 성능 문제에 대한 부담을 주지 않고도 애플리케이션이 비즈니스 요구 사항을 충족할 수 있습니다. 전략적 제어 지점을 통해 거버넌스 문제를 각 애플리케이션에서 균일하고 독립적으로 처리할 수도 있습니다.

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가 생성되어 AWS에 등록됩니다. 이 AMI에서 부팅하는 모든 이후 인스턴스에는 이미 변경 사항이 적용됩니다. 이 접근 방식을 사용하면 변경 사항이 효과적으로 영구적으로 적용되고 새 AMI를 생성하는 데 시간이 많이 소요될 수 있으므로 AMI에 내장된 변경 사항은 일반적으로 장기간 지속되고 여러 인스턴스에서 사용할 수 있습니다. AMI를 사용하는 또 다른 이유는 일부 클라우드 초기화 프로세스가 시간이 많이 소요될 수 있기 때문에 부팅 시간을 단축할 수 있다는 것입니다.

새로운 AMI에 통합하기에 적합하지 않은 필수 변경 사항은 인스턴스가 부팅될 때마다 시작 스크립트를 활성화하는 cloud-init에 적합한 후보입니다. cloud-init을 사용하면 간단한 인스턴스별 변경 사항을 인스턴스에 포함할 수 있습니다.

Cloud-init의 단점은 패키지 설치 등의 구성 변경 사항을 부팅 시에 실행해야 하므로 부팅 시간이 더 오래 걸린다는 것입니다. 부팅 시간이 길면 자동 크기 조정 시나리오에서 실제로 영향을 미쳐 부팅 시간이 길어지면 자동 크기 조정이 효과적이지 않을 수 있습니다. 이러한 이유로, 많은 시간이 걸리는 변경 사항은 cloud-init을 통해 변경하는 대신 새 AMI에 포함시키는 것이 좋습니다.

변경 사항을 여러 인스턴스에 적용할 수 있지만 모든 인스턴스에 적용할 수는 없는 경우 구성을 관리하는 것도 번거로울 수 있습니다. 예를 들어, 특정 BIG-IP 배포가 특정 가상 서버 구성을 갖춘 자동 확장 그룹에서 사용된다고 가정해 보겠습니다. 단일 AMI가 해당 머신에 적용될 수 있고, 다른 AMI가 다른 자동 확장 그룹에 있는 다른 BIG-IP 머신에 적용될 수 있습니다. 각 자동 확장 그룹에 대해 단일 AMI를 사용하면 cloud-init 프로세스 내에서 각 호스트에 특정한 변경만 필요합니다. 그룹에 공통적인 모든 변경 사항은 AMI에 임베드될 수 있습니다. 이 접근 방식의 단점은 모든 머신에 공통적인 각 변경 사항에 대해 AMI를 업데이트해야 한다는 것입니다.

응용프로그램은 일반적으로 여러 사용자에게 동시에 기능을 제공합니다. 응용 프로그램이 성공할수록, 응용 프로그램을 실행하는 컴퓨터의 용량을 초과할 수 있습니다. 애플리케이션의 필요성이 컴퓨터의 필요성을 초과하게 되면, 용량을 늘리기 위한 옵션을 평가해야 합니다. 확장에는 확장, 파이프라인, 확장이라는 세 가지 일반적인 접근 방식이 있습니다.

확장은 기존 컴퓨터를 더 빠른 컴퓨터로 교체하는 것뿐이므로 용량을 늘리는 가장 간단한 방법입니다. 더 빠른 컴퓨터를 설치하면 애플리케이션의 모든 측면과 컴퓨터의 다른 모든 서비스가 애플리케이션이나 인프라를 변경할 필요 없이 더 빨라집니다. 확장의 단점은 성과가 증가함에 따라 비용이 기하급수적으로 증가하여 결국 수익이 감소하는 지점에 도달한다는 점입니다. 임계값을 넘어서면 확장하는 데 비용이 많이 들게 됩니다.

파이프라인은 조립 라인과 비슷하게 작업 부하를 순차적인 단계로 분해한 결과입니다. 여러 컴퓨터가 각 단계에서 독립적으로 작업할 수 있으면 전체 처리량을 늘릴 수 있습니다. 그러나 파이프라인을 적용하면 처리량만 늘어나고, 종종 지연 시간이 늘어나는 단점이 있습니다. 다시 말해, 파이프라인은 전반적인 성능을 향상할 수 있지만, 단일 사용자나 단일 요청에 대한 성능은 저하시킬 수 있습니다. 파이프라인의 또 다른 단점은 분해 가능한 워크플로에 대한 심층적인 이해가 필요하고, 그 이해에 맞는 인프라가 필요하다는 것입니다. 이는 인프라 결정과 비즈니스 로직을 긴밀하게 결합하는데, 이는 많은 조직이 시도하는 것과는 정반대입니다.

확장은 애플리케이션과 컴퓨터를 그대로 두고 대신 요청을 여러 서버 풀에 균등하게 분산하는 것을 의미합니다. 일반적으로 애플리케이션은 여러 개의 독립적인 요청을 동시에 처리하므로, 요청을 동일한 애플리케이션 서버 풀에 안전하게 분산시킬 수 있습니다. 확장은 풀 멤버 중 하나에 장애가 발생해도 전체 애플리케이션이 중단되지 않는다는 중복성이라는 추가 이점이 있습니다. 확장의 단점은 풀 내의 노드 전체에서 요청이 균형을 이루도록 하기 위해 애플리케이션 외부에서 복잡한 오케스트레이션이 필요하다는 것입니다.

AWS 자동 확장은 필요한 애플리케이션의 용량을 늘리기 위해 확장형 방식을 사용합니다. 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 인스턴스만으로 백엔드 풀의 서버 부하를 관리하는 데 충분합니다.

BIG-IP 인스턴스는 최소한 두 가지 시나리오에서 AWS 인프라와 상호 작용해야 합니다. 첫째, 다중 영역 AWS 배포에는 AWS 탄력적 IP 뒤에 있는 IP 주소를 변경해야 합니다. 두 번째로, BIG-IP 인스턴스는 풀 내에서 서버를 확장하거나 축소하는 AWS CloudWatch 서비스를 통해 추가되거나 제거된 풀 멤버에 대한 가시성이 필요합니다. 인프라와의 각 상호작용은 API 호출을 통해 이루어지며, API 호출을 수행하는 다른 소프트웨어와 마찬가지로 BIG-IP 인스턴스는 AWS에 인증되어야 합니다. 일반적으로 AWS에 인증하는 방법에는 자격 증명을 통한 방법과 IAM 역할을 통한 방법 두 가지가 있습니다.

가장 간단한 인증 방법은 API 호출에 적절한 자격 증명을 포함하는 것입니다. AWS 자격 증명은 액세스 키와 비밀 키로 구성되며, 이는 대략 사용자 이름과 비밀번호에 해당합니다. 관리자가 자격 증명을 생성하면 개발자는 이를 애플리케이션에 내장합니다. 이를 통해 애플리케이션은 적절한 API 호출에 액세스할 수 있습니다.

간단하지만 애플리케이션에 자격 증명을 내장하면 보안 위험이 따릅니다. 개발자가 애플리케이션의 자격 증명을 안전하게 보호하지 않으면 다른 사람이나 소프트웨어가 해당 자격 증명을 복구하여 악의적인 용도로 사용할 수 있습니다. 이러한 접근 방식에서는 소프트웨어를 변경하지 않고 자격 증명을 변경하는 것이 어렵습니다. 자격 증명을 사용하는 것은 빠른 테스트를 위한 합리적인 방법이지만, 프로덕션 솔루션에서는 인증을 위한 다른 방법을 사용해야 합니다. 이것이 AWS 모범 사례에서 애플리케이션에 저장된 자격 증명을 사용하지 말 것을 권장하는 이유입니다.

API 호출을 인증하는 데 있어 보다 안전한 방법은 IAM 역할을 사용하는 것입니다. AWS Identity and Access Management(IAM)를 사용하면 사용자는 AWS 인프라에 대한 액세스를 관리할 수 있습니다. BIG-IP 머신과 같은 모든 컴퓨팅 인스턴스에는 특정 기능 세트를 승인하는 IAM 역할이 할당될 수 있습니다. 인스턴스가 시작되면 IAM은 인스턴스에 대한 임시 자격 증명 세트를 생성합니다. 해당 자격 증명은 인스턴스가 작동하는 동안 지속되며 지정된 API 기능만 활성화합니다. IAM 역할로 구성된 경우 BIG-IP 인스턴스는 자격 증명을 저장하지 않고, 대신 필요한 인프라 API에만 액세스할 수 있으므로 자격 증명 기반 인증보다 더 높은 보안을 제공합니다.

앞서 언급했듯이 AWS 데이터 센터는 여러 지역에 존재하며, 각 지역은 가용성 영역(AZ)에 존재할 수 있습니다. 한 지역 내의 각 AZ는 다른 AZ와 아무것도 공유하지 않습니다. 전력, 네트워킹 또는 건물을 공유하지 않습니다. 실제로 각 AZ는 지역 내의 다른 AZ와 지리적으로 분리되어 있습니다. 영역이 분리되어 있기 때문에 AWS 구독자는 한 AZ에 영향을 미치는 이벤트가 다른 AZ에는 영향을 미치지 않는다는 점을 확신할 수 있습니다. 다시 말해, 원칙적으로 한 지역 내의 AZ는 최대 한 개만 특정 순간에 사용할 수 없습니다. 즉, 두 개 이상의 가용성 영역에 배포된 모든 서비스는 지속적으로 사용 가능해야 합니다.

BIG-IP 플랫폼은 컴퓨팅 인스턴스와 본질적으로 연결되지 않은 IP 주소인 AWS 탄력적 IP를 사용하여 AWS AZ에서 고가용성을 지원합니다. 대신, IP 주소는 실행 중인 컴퓨트 인스턴스의 개인 IP 주소로 동적으로 전달될 수 있습니다. 다중 영역 고가용성을 구현하기 위해 동일한 BIG-IP 인스턴스와 애플리케이션 서버 세트가 각각 별도의 AZ에 배치됩니다. 처음에는 탄력적 IP가 BIG-IP 인스턴스 중 하나에 할당됩니다. 각 클라이언트에서 탄력적 IP로 연결이 설정되고, 이를 통해 BIG-IP 인스턴스 중 하나의 개인 IP 주소로 전달됩니다. 장애가 발생하면 다른 BIG-IP 인스턴스가 AWS에 API 호출을 하여 해당 Elastic IP 주소를 전달해 달라고 요청함으로써 책임을 주장합니다.

ELB와 통합하면 BIG-IP 플랫폼은 여러 AZ 및 BIG-IP 노드 자동 확장 등 AWS 기능과 원활하게 통합되는 애플리케이션 서비스를 제공할 수 있습니다.

ELB를 BIG-IP 인스턴스 앞에 배치하면 여러 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 플랫폼의 장점을 모두 활용함으로써 설계자는 특정 배포에 필요한 수준의 서비스를 제공할 수 있습니다.

반복 가능하고 스크립트화된 배포를 가능하게 하기 위해 AWS는 배포와 지속적인 관리를 모두 간소화하는 클라우드 형성 템플릿(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 클라우드 환경에서 앱이 더 빠르고, 더 스마트하고, 더 안전하게 실행될 수 있도록 이를 구성했습니다.