F5 iApps: 애플리케이션 딜리버리를 네트워크 너머로 확장

소개

오늘날의 기업은 네트워크 내에서 애플리케이션을 더욱 높은 수준으로 인식하고 관리할 수 있기를 요구합니다. 데이터 센터는 애플리케이션과 서비스를 제공하도록 구축되지만, 여전히 대규모 네트워크로 관리되며 개별 네트워킹 구성 요소는 서로 분리된 단일 지점 장치로 취급됩니다. 예를 들어, 기존 라우터는 마치 다른 요소와 무관하게 IP 트래픽을 라우팅하는 역할만 하는 것처럼 관리됩니다. 그러나 애플리케이션이 정상적으로 작동하려면 해당 라우터에 전적으로 의존해야 합니다. 현재 대부분의 기업은 조직 및 데이터 센터 네트워크를 개별 그룹이 관리하는 일련의 개별 객체로 간주합니다. 하지만 이러한 구성 요소가 서로 간에, 그리고 나머지 인프라와 어떤 관계를 맺고 있는지, 또는 모든 구성 요소가 어떻게 함께 작동하여 사용자에게 애플리케이션을 제공하는지를 아우르는 전체적인 관점은 없습니다.

전체 인프라를 개별 구성 요소 단위로 관리하면 IT 운영에 지장이 생깁니다. 사용자와 데이터 센터 내 다른 서비스에 애플리케이션을 적절히 제공하고 이를 관리 및 제어하려면 여러 부서에 걸쳐 너무 많은 요소를 조율해야 하기 때문입니다. 그 결과 IT 부서는 네트워크 수준에서 각 구성 요소가 어떤 역할을 하는지 상세히 기록한 복잡한 스프레드시트를 사용하는 경우가 많지만, 이러한 구성 요소가 애플리케이션과 어떻게 연결되는지에 대한 정보는 없습니다. 이처럼 인프라를 복잡하고 단절된 관점에서 바라보면 각 인프라 구성 요소가 어떻게 결합되어 애플리케이션을 제공하는지 파악할 수 없으므로 데이터 센터 관리, 문제 해결, 셀프서비스 프로비저닝과 같은 애자일 모델을 구현하기가 어려워집니다.

애플리케이션 중심으로의 전환

이처럼 낡은 데이터 센터 관점이 여전히 많은 조직의 관리 방식에 영향을 미치고 있지만, 애플리케이션은 계속 발전하며 핵심적인 위치를 차지하고 있습니다. 이러한 변화로 인해 기업 IT 부서는 장치와 객체에서 출발해 구성 요소를 조합하여 애플리케이션을 제공하는 방식에서 벗어나, 애플리케이션 중심의 관점으로 관리를 시작하게 되었습니다. 이러한 변화는 주로 클라우드 컴퓨팅과 서비스형 소프트웨어(SaaS)의 도입 확산에 따른 것으로, 애플리케이션이 가장 중요한 구성 요소가 되고 인프라는 범용화되고 있습니다.

하지만 오늘날의 애플리케이션 관리는 불과 5년 전보다 훨씬 더 복잡해졌습니다. 백엔드에서 애플리케이션은 이제 기업 데이터 센터 내부든 외부든 어디에나 위치할 수 있습니다. 관리자는 서로 다른 클라우드 공급자 간에 앱을 배포하거나 SaaS 애플리케이션으로 실행할 수 있으며, 심지어 서로 다른 대륙의 데이터 센터에 지리적으로 분산할 수도 있습니다. 또한 가상화가 확산되면서 데이터 센터는 서버와 애플리케이션이 일대일로 대응하는 모델에서 벗어나고 있습니다. 리소스는 줄어드는 반면 서비스는 계속 증가하고 있습니다. 애플리케이션 자체도 훨씬 더 데이터 집약적인 모델로 전환되고 있으며, API를 통한 애플리케이션 간 통신에 의존함에 따라 시스템 및 네트워크 리소스 요구 사항도 늘어나고 있습니다. 그러나 앱이 중심이 되는 기업 IT의 급속한 소비자화에도 불구하고, 기반 인프라는 이에 맞춰 변화하지 못했습니다. 애플리케이션 제공 관리는 단순히 네트워크 구성 요소만의 문제가 아닙니다. 컨텍스트를 파악하고 사용자가 애플리케이션과 실시간으로 어떻게 상호 작용하는지 이해하는 것도 중요합니다.

iApps: 애플리케이션의 시대

F5 iApps는 데이터 센터의 애플리케이션 전송 아키텍처를 더욱 효과적으로 설계할 수 있도록 지원하는 BIG-IP 시스템의 강력한 신규 기능 모음입니다. iApps는 데이터 센터 내부와 외부는 물론 그 너머에서 애플리케이션을 관리하고 전송하는 방식에 대해 총체적인 애플리케이션 중심 접근 방식을 기반으로 합니다. iApps 기술은 비즈니스를 지원하는 애플리케이션 서비스에 대한 상황별 보기와 고급 통계를 제공하는 BIG-IP 시스템 내 프레임워크를 제공합니다. 이를 통해 애플리케이션, 보안, 네트워크, 시스템 및 운영 담당자는 애플리케이션 전송 서비스를 통합하고 간소화하며 더욱 효과적으로 제어할 수 있습니다.

iApps는 애플리케이션 제공에 필요한 여러 개별 구성 요소를 추상화하고, 이러한 리소스를 특정 앱과 연결된 템플릿으로 그룹화합니다. 이를 통해 관리자가 네트워크의 개별 구성 요소를 일일이 관리해야 하는 부담을 줄여 줍니다.

대부분의 기업 IT 부서는 네트워크의 여러 영역에 대한 관리 책임을 각기 다른 팀에 위임합니다. IP 주소, 라우팅 및 DNS는 네트워크 팀이 관리하고, 물리 및 가상 서버, OS 빌드 및 바이러스 관리는 서버 팀이 담당하며, API 연동, 애플리케이션 표준 및 액세스 권한은 애플리케이션 팀과 보안 팀이 담당합니다. 따라서 일반적으로 IT 부서 내에는 "조직에서 이메일을 제공하려면 어떤 구성 요소가 필요하며, 각 구성 요소는 어떻게 구성되어 있습니까?"라는 질문에 답할 수 있는 단일 팀이 없습니다. 서로 조율되지 않은 요소가 너무 많기 때문입니다.

iApps는 모든 요소를 애플리케이션 중심의 관점에서 관리함으로써 이러한 상황을 개선합니다. iApps를 사용하면 노드, 애플리케이션 모니터, 풀과 같은 애플리케이션 전송 서비스 구성 요소를 하나로 묶어 애플리케이션 워크플로의 일부로 관리할 수 있습니다. 이를 통해 주요 관리 작업을 자동화하여 애플리케이션 및 네트워크 관리자가 애플리케이션을 성공적으로 제공하는 데 필요한 인프라 구성 요소를 손쉽게 정의할 수 있습니다.

iApps는 애플리케이션 전송 서비스를 구성하고 관리할 뿐만 아니라 추가 애플리케이션 전송 리소스 배포와 같은 자동화 작업도 정의할 수 있습니다. iApps는 F5의 iRules 엔진을 통해 AAA 보안 인프라에 부하 분산 규칙을 적용하는 것부터 애플리케이션 진단 및 가시성 데이터를 F5의 고객 지원 포털인 iHealth에 제공하는 것까지, 애플리케이션 전송의 모든 부분을 관리하기 위해 BIG-IP 시스템의 다양한 구성 요소를 활용합니다.

iApps를 사용하면 모든 애플리케이션 전송 서비스 구성 요소가 하나로 묶여 애플리케이션의 확장 요소로 취급됩니다. 예를 들어 새로운 SharePoint 애플리케이션에는 SharePoint의 웹 프런트 엔드, 검색 및 데이터베이스 구성 요소의 상태를 확인하는 특정 상태 모니터가 필요합니다. 기존에는 이러한 구성 요소를 개별적으로 할당하고 관리해야 했기 때문에 오류가 발생할 여지가 있었고 배포 시간도 크게 늘어났습니다. SharePoint용 iApp을 사용하면 이러한 모든 요소가 애플리케이션 자체의 구성 요소가 되어 하나의 중앙 위치에서 배포하고 관리할 수 있습니다.

통합 iApps 구성 요소

내부적으로 iApps는 여러 개의 개별 구성 요소로 이루어져 있으며, 각 구성 요소는 애플리케이션 딜리버리 인프라의 일부를 관리합니다. 이러한 구성 요소는 서로 연계되어 통합 BIG-IP 애플리케이션 딜리버리 컨트롤러(ADC)를 구성합니다.

iApps 애플리케이션 서비스

iApps는 애플리케이션 구성 요소를 하나로 묶어 제공하기 위해, 애플리케이션 제공 과정에서 애플리케이션의 어느 부분에나 적용할 수 있는 iApps Application Services를 생성합니다. 예를 들어 SharePoint용 iApps Application Service를 처음에는 BIG-IP Local Traffic Manager (LTM) 정책 및 SSL 관련 iRules 모음과 연결할 수 있습니다. 이후 관리자는 iApps 확인란 하나만 선택하여 BIG-IP Access Policy Manager (APM) 액세스 정책을 동일한 SharePoint용 iApps Application Service와 연결한 다음, 전체 네트워크에 다시 배포할 수 있습니다. iApps Application Services는 전체 애플리케이션 제공 인프라에 대한 가시성을 제공하고 애플리케이션과 네트워크 간의 종속성을 하나의 통합 시스템으로 결합하여 운영 비용을 절감합니다.

객체 지향 프로그래밍이 애플리케이션 작성 방식을 바꾼 것처럼, iApps Application Services는 일반적인 애플리케이션 전송 서비스가 애플리케이션의 "앞단"에 배치되는 방식의 패러다임을 바꿉니다. iApps Application Services는 전송 중 언제든지 애플리케이션 전송 체인의 어느 부분에나 적용할 수 있으므로, 조직은 상황에 따라 어떤 서비스 구성 요소가 애플리케이션의 어느 부분에 언제 영향을 미칠지 선택할 수 있습니다. iApps 정책은 단순히 부하 분산 구성을 구축하는 데만 국한되지 않습니다. 전체 BIG-IP 통합 ADC 플랫폼의 일부인 iApps 정책에는 BIG-IP APM을 사용하여 애플리케이션에 사용자 액세스 정책을 할당하는 것과 같은 고급 BIG-IP 시스템 모듈 및 기능의 구성 설정도 포함될 수 있습니다.

iApps 템플릿

템플릿에 액세스할 수 있다는 점은 iApps의 가장 매력적인 이점 중 하나입니다. 애플리케이션 템플릿은 버전 10부터 BIG-IP LTM에서 제공되었지만, 새 애플리케이션의 초기 배포 단계에서만 사용할 수 있었습니다. 또한 이후에는 실행 중인 구성을 수정하는 데 사용할 수 없었습니다.

iApps 템플릿은 애플리케이션 서비스를 배포하고 관리할 때 유연하고 사용하기 쉬우며, 모든 BIG-IP 시스템 모듈에서 애플리케이션을 구축, 관리 및 모니터링하기 위한 단일 인터페이스 역할을 합니다. 관리자가 기존 템플릿을 사용하여 새 iApps 구성을 만들면, 생성된 구성은 디바이스 서비스 클러스터의 모든 BIG-IP 디바이스에서 사용되며 F5 Analytics에 필요한 정보를 제공합니다.

iApps 템플릿을 사용하면 BIG-IP 시스템을 구성하고 관리하는 것뿐만 아니라 IT 내 여러 그룹이 애플리케이션 제공 및 관리에 필요한 모든 설정을 정의할 수 있습니다. 여러 부서의 아키텍트로 구성된 팀은 IP 주소 정보를 제공하는 네트워크 팀, 캐싱 및 압축 정책을 구성하는 애플리케이션 팀, 사용자 및 지역별 액세스 정책을 정의하는 보안 팀에 이르기까지 애플리케이션 매개변수와 배포 절차를 iApps 템플릿에 정의할 수 있습니다. 그런 다음 테스트 또는 프로덕션 BIG-IP 장치에 배포할 수 있도록 해당 템플릿을 IT 운영팀에 전달할 수 있습니다. 일단 구축된 iApps 템플릿은 해당 그룹에서 수정할 수 있으며, 비즈니스 및 IT 요구 사항의 변화에 따라 조직 전체에서 재사용할 수 있습니다.

iApps의 또 다른 주요 이점은 ADC 및 전체 인프라에 새 애플리케이션을 배포할 때 발생하는 ‘분야별 전문가’의 장벽을 없애 준다는 것입니다. 이제 애플리케이션 소유자는 가용성을 위해 개별 BIG-IP LTM 장치를 배포하거나 보안을 위해 BIG-IP ASM 장치를 배포하는 방안을 고민할 필요가 없습니다. iApps를 사용하면 애플리케이션 소유자가 해당 서비스를 iApps 애플리케이션 구성의 일부로 추가하기만 하면 BIG-IP 플랫폼이 적절한 서비스와 그 서비스에 관련된 모든 구성 요소를 배포합니다. 일반적으로 애플리케이션 소유자는 BIG-IP 시스템 어플라이언스를 통해 제공할 애플리케이션을 구성하는 데 많은 시간을 할애합니다. iApps Templates를 사용하면 이러한 사전 작업을 조직 전체에서 재사용할 수 있습니다. 사용자 지정이 가능한 iApps Templates를 활용하면 애플리케이션 정책을 한 번 세부 조정하고 한 번 테스트한 후, 구성을 내보내 추가 BIG-IP 장치 및 다른 IT 조직과 공유하여 해당 작업을 재사용할 수 있으므로 운영 비용을 절감할 수 있습니다.

iApps 에코시스템

iApps 구성 정책은 BIG-IP 시스템 간 및 사용자 간에 이식할 수 있도록 설계되었습니다. iApps 템플릿은 애플리케이션별로 내보내 애플리케이션 네트워크 전반에서 재사용할 수 있습니다. 또한 F5의 커뮤니티 사이트인 DevCentral의 iApps 에코시스템을 통해 내보내고 공유할 수 있으며, 이곳에서 BIG-IP 시스템 관리자와 개발자는 다른 애플리케이션을 위한 자체 iApps 템플릿을 생성, 수정 및 공유하거나 기존 iApps 템플릿을 조정할 수 있습니다.

F5는 DevCentral의 iApps Ecosystem을 통해 새로운 애플리케이션을 위한 공식 iApps 템플릿을 정기적으로 출시합니다. 이를 통해 Microsoft, IBM, Oracle과 같은 F5 파트너가 새로운 애플리케이션을 위해 수행한 엔지니어링 작업뿐만 아니라 금융, 정부, 의료 등 특정 산업 분야에 특화된 애플리케이션 템플릿도 활용할 수 있습니다.

F5 분석

iApps 정책의 대부분은 애플리케이션 제공에 필요한 트래픽 관리 구성 요소를 설정하는 데 중점을 둡니다. 그러나 BIG-IP 플랫폼에는 애플리케이션 모니터링 도구도 포함되어 있으며, 실시간 애플리케이션 성능 통계를 제공합니다. 또한 전체 애플리케이션, 가상 서버, 풀 및 노드에 대한 애플리케이션 응답 시간, 네트워크 지연 시간, 연결 통계 등의 진단 및 문제 해결 정보도 제공합니다.

기존 모니터링 도구와 달리 F5 Analytics는 애플리케이션 수준에서 성능 데이터를 수집하여 개별 인프라 구성 요소가 아닌 애플리케이션 자체에 정보를 연결합니다. 애플리케이션 소유자는 애플리케이션에서 애플리케이션 서버를 거쳐 네트워크에 이르기까지 전 구간의 성능을 모니터링할 수 있습니다. 이를 통해 조직은 애플리케이션 응답, 네트워크 상태 및 사용자 컨텍스트를 기반으로 애플리케이션의 실시간 성능을 정확하게 모니터링할 수 있습니다.

F5 Analytics는 BIG-IP 시스템의 통계 및 로그 데이터를 활용합니다. 이 데이터를 JSON 객체 형식으로 변환한 후 F5 BIG-IQ와 같은 데이터 소비자나 Splunk와 같은 애플리케이션에서 사용할 수 있도록 내보냅니다.

F5 Analytics를 사용하면 내보낼 여러 데이터 범주를 구성할 수 있습니다. Splunk와 같은 데이터 소비자의 경우 데이터가 전송될 네트워크 엔드포인트를 구성할 수 있습니다.

그림 1: F5 Analytics 가시성

디바이스 서비스 클러스터

데이터 센터 하드웨어 장치는 일반적으로 액티브/스탠바이(한 시스템이 모든 작업을 전담하고, 다른 시스템은 첫 번째 시스템이 오프라인 상태가 될 때까지 대기한 후 해당 작업을 인계받는 방식) 또는 액티브/액티브(두 시스템이 장치 간에 워크로드를 분산하는 방식)의 이중화 쌍으로 운영됩니다. 두 이중화 구성 모두 미션 크리티컬 하드웨어를 배포할 때 권장되는 모범 사례이지만, 한 가지 중대한 설계 결함이 있습니다. 바로 이러한 이중화 아키텍처가 장치 전체의 장애를 전제로 한다는 점입니다.

더 나은 접근 방식은 전체 장치의 온라인 또는 오프라인 여부가 아니라 애플리케이션 전송 중 특정 시점에 장치가 수행하는 작업을 기반으로 내결함성 아키텍처를 구축하는 것입니다. BIG-IP 장치는 애플리케이션 수준에서 확장 가능한 내결함성 아키텍처를 지원하여 장치 간 애플리케이션 구성에 대한 장애 조치 보호 기능을 제공합니다. BIG-IP 장치 서비스 클러스터는 Sync-Only 모드와 Sync-Failover 모드라는 두 가지 구성 옵션으로 실행됩니다.

동기화 전용

BIG-IP 디바이스 서비스 클러스터의 Sync-Only 모드를 사용하면 여러 BIG-IP 하드웨어 및 소프트웨어 어플라이언스가 애플리케이션별 전송 구성과 템플릿을 디바이스 간에 동적으로 공유할 수 있습니다. 따라서 변경 사항이 발생할 때마다 관리자가 전체 디바이스 구성을 수동으로 업데이트할 필요가 없습니다. BIG-IP 애플리케이션 정책은 하드웨어 구성과 분리되어 있으므로 관리자는 전체 BIG-IP 구성 파일을 복제하는 대신 디바이스 간에 애플리케이션 및 네트워킹 정보를 동기화할 수 있습니다. 이를 통해 IT 부서는 서로 다른 구성의 BIG-IP 디바이스를 운영하면서도 해당 디바이스 간에 고유한 애플리케이션 구성과 정책을 동기화할 수 있습니다. 예를 들어, 각 디바이스의 다른 애플리케이션 정책에 영향을 주거나 보안 팀이 개별 BIG-IP ASM 정책을 각 디바이스에 수동으로 설치할 필요 없이 BIG-IP 디바이스 간에 BIG-IP Application Security Manager(ASM) 정책을 동기화할 수 있습니다.

동기화-장애 조치

장치 간 동기화뿐만 아니라 애플리케이션 구성은 현재 처리 중인 실시간 애플리케이션 트래픽을 장치 간에 장애 조치할 수 있으므로 Active/Active 개념을 애플리케이션 계층까지 확장할 수 있습니다. BIG-IP 장치 서비스 클러스터의 Sync-Failover 모드는 Active/Active의 1:1 개념을 N:1로 확장하여, 리소스 제약과 가용성에 따라 필요한 만큼의 활성 장치가 애플리케이션 부하를 분담할 수 있도록 합니다. 이는 필요성과 이중화 수준에 따라 디스크 수를 결정할 수 있는 RAID 5 스트라이핑 개념과 매우 유사합니다.

더 많은 애플리케이션 전송 리소스가 필요해지면 관리자는 활성 BIG-IP 디바이스를 디바이스 서비스 클러스터에 추가할 수 있습니다. 이 클러스터는 새 디바이스가 오프라인 상태가 될 경우에 대비해 두 번째 전용 대기 디바이스를 추가하지 않고도 전체 애플리케이션 전송 부하의 일부를 담당합니다. BIG-IP 디바이스 서비스 클러스터에서는 그룹에 새로 추가되는 모든 디바이스가 다른 디바이스 중 하나가 오프라인 상태가 될 경우 추가 애플리케이션 부하를 처리할 수 있도록 대기함으로써 일정 수준의 이중화 역할을 담당합니다. 디바이스 서비스 클러스터에 포함되는 BIG-IP 디바이스가 많을수록 애플리케이션 부하를 사용 가능한 모든 디바이스에 더 효율적으로 분산할 수 있습니다.

전략적 제어 지점

iApps의 두 가지 핵심 원칙은 가시성과 제어입니다. iApps는 전체 인프라에 걸쳐 전례 없는 수준의 가시성과 제어 기능을 제공합니다. 하지만 이러한 기능이 제공되는 수준은 사용자, 애플리케이션 및 데이터 사이에 조정된 중재 계층을 두고, 모든 양방향 애플리케이션 트래픽에 모든 애플리케이션 전송 로직을 동적으로 적용할 수 있는 전략적 지점에 iApps가 배치되어 있는지에 따라 달라집니다. 이 계층은 현재 위치와 관계없이 모든 애플리케이션과 데이터에 사용할 수 있는 일관된 인터페이스와 서비스 집합을 제공합니다. 누가 어디에서 무엇에 왜 액세스하는지와 같은 컨텍스트를 지능적으로 파악하여 사용자, 애플리케이션 및 데이터 간의 최적 연결을 결정합니다. 또한 컨텍스트를 심층적으로 파악하여 기반 애플리케이션 및 데이터 요소에 현재 리소스 요구 사항을 알리고, 최적화된 애플리케이션 및 데이터 액세스를 보장하도록 인프라가 실시간으로 조정되게 합니다.

이러한 애플리케이션 정보의 전략적 흐름은 iApps 구성의 일부가 됩니다. iApps Template을 사용한 초기 구성은 이상적인 아키텍처에서 애플리케이션이 제공되어야 하는 방식을 기반으로 하며, 애플리케이션은 제공 수명 주기 전반에 걸쳐 iApps Templates와 BIG-IP 디바이스 서비스 클러스터를 통해 관리되어 무엇을 어디에서 제공할지를 결정합니다. F5 Analytics는 그 이유에 해당하는 정보를 제공하고, 해당 정보를 분석할 수 있도록 IT 부서에 다시 보고합니다. iApps는 전략적 제어 지점에 위치하며, 이처럼 세분화되고 광범위한 애플리케이션 제공 관리를 지원하는 유일한 위치입니다.

결론

조직이 보다 모듈화된 클라우드 및 SaaS 모델로 전환함에 따라, 인프라 구축보다 애플리케이션 관리가 더욱 중요해졌습니다. 보다 민첩한 모델로 전환함으로써 얻는 많은 이점은 인프라 관리와 관련이 없습니다. 하지만 애플리케이션이 여전히 인프라에 종속되어 있기 때문에 클라우드 및 SaaS 환경에서 애플리케이션의 배포, 성능 및 가용성을 관리하기란 쉽지 않은 경우가 많습니다. iApps는 애플리케이션 제어, 가시성 및 관리를 데이터 센터 외부에서 해당 애플리케이션과 서비스를 제공하는 데 필요한 인프라와 연계합니다.

iApps는 네트워크를 서로 분리된 구성 요소로 이루어진 정적인 리소스에서 애플리케이션 또는 서비스와 직접 연계된 통합형의 유연하고 복원력 있는 리소스 풀로 전환하는 아키텍처를 지원합니다. 이러한 전환을 통해 애플리케이션 계층에서 네트워크를 신속하게 배포하고 통합 및 관리하며 가시성을 확보할 수 있습니다. iApps는 네트워크를 애플리케이션에 맞게 조정하여 전체 애플리케이션 전송 인프라를 완벽하게 제어할 수 있도록 합니다. 그 결과, 신속한 배포와 단일 지점 관리 기능을 통해 운영 비용을 절감할 수 있습니다. 조직은 F5 iApps를 통해 전략적 제어 지점에서 보안, 가속 및 가용성 서비스를 위한 공통의 재사용성 높은 카탈로그를 구축하여 F5 BIG-IP 디바이스의 조직 민첩성과 효율성을 크게 높일 수 있습니다.

2017년 12월 14일 게시