F5 및 컨테이너화

기업들은 새로운 사업 기회를 열어주기 위한 기술 변화를 수용하는 것과, 새로운 과제와 위험으로부터 사업을 보호하는 것 사이에서 끊임없이 갈등합니다. 이 논문에서는 컨테이너화를 살펴보고 F5 제품에서 이 기술을 도입하는 것이 IT 전문가, 아키텍트 및 비즈니스 의사 결정권자에게 어떤 영향을 미치는지 알아보겠습니다.

지난 20년 동안 가상화는 서버 컴퓨팅을 혁신하여 하나의 하드웨어 플랫폼에서 여러 개의 개별 운영 체제를 실행할 수 있게 되었습니다. 더욱 현대적인 접근 방식은 컨테이너화(또는 운영 체제 가상화)로, 여러 앱이 호스트 운영 체제의 단일 인스턴스에서 실행될 수 있도록 합니다. 각 앱 인스턴스는 단일 운영 체제 인스턴스에 설치된 바이너리와 라이브러리를 공유합니다. 그림 1에서는 이러한 접근 방식을 비교합니다.

가상 머신(VM)과 달리 컨테이너는 하이퍼바이저 수준이 아닌 OS 수준에서 가상화하여 동일한 운영 체제를 공유할 수 있습니다.

놀랍지 않게도 개발자들은 컨테이너를 좋아합니다. 컨테이너를 사용하면 애플리케이션을 개발하고 배포하고 마이크로서비스를 빠르고 쉽게 시작할 수 있기 때문입니다. 컨테이너화는 앱을 다양한 운영 체제, 하드웨어 플랫폼, 클라우드 서비스에 더 쉽게 배포할 수 있으므로 이동성도 향상됩니다. 컨테이너는 베어 메탈 호스팅 운영 체제나 가상 머신에서 직접 실행되는 애플리케이션보다 리소스를 적게 사용합니다.

일반적으로 컨테이너에 대한 대부분의 논의(및 문서화)는 프로그래밍이나 DevOps 관점에 초점을 맞추고 있습니다. IT 전문가, 시스템 설계자 또는 비즈니스 의사 결정권자는 컨테이너화가 가져올 수 있는 유연성을 높이 평가하지만, 이러한 변경 사항이 사용자 환경 내의 앱과 서비스의 관리, 운영 및 모니터링에 어떤 영향을 미칠지에 대해 진정한 우려를 가질 수도 있습니다. 또한 컨테이너화가 네트워크 및 앱 보안에 부정적인 영향을 미치지 않는지 확인해야 합니다.

점점 더 경쟁이 치열해지는 시장에서 현대의 IT 시스템은 실현 가능한 비즈니스 이점을 제공해야 합니다. 이러한 요구 사항을 충족하려면 IT 부서가 애플리케이션 자본을 늘려, 단순히 더 많은 앱을 제공하는 것이 아니라 더 많은 기능, 향상된 사용성, 더 쉬운 통합을 갖춘 앱을 제공하는 아키텍처를 설계하고 만드는 것이 중요합니다.

IT 책임자의 과제는 부서가 직원 수를 늘리지 않고도 더 많은 기능을 제공해야 한다는 것입니다. 이제 생산성 향상은 더 많은 사람을 고용하는 데서 오는 것이 아니라, 고객에게 제공하는 앱의 수를 늘리고 동일한 규모의 팀에서 관리할 수 있게 해주는 기술과 자동화의 발전에서 비롯됩니다.

컨테이너 배포의 용이성은 또 다른 과제를 제기합니다. 개발자는 애플리케이션을 만들 때 규모와 보안을 모두 고려하도록 교육과 지침이 필요하며, IT 전문가는 개발자가 이러한 성과를 달성하도록 도울 수 있습니다. 여기서는 Kubernetes 및 Docker와 같은 컨테이너 플랫폼이 프로덕션에 미치는 영향에 대해 생각해야 하며, 민첩해야 한다는 필요성이 보안 관행이 부족하거나 프로덕션 부하를 고려하지 못해 바람직하지 않은 결과가 발생하지 않는지 확인해야 합니다. 

실현 가능한 비즈니스 혜택을 제공하는 데 있어 핵심 요소는 가치 실현 시간을 최소화하는 것입니다. 점점 더 성능이나 지연 시간과 같은 요소가 삽입 용이성보다 덜 중요하게 여겨지고 있습니다. 결과적으로, 두 가지 구성 요소가 있고 둘 다 거의 동일한 기능을 가지고 있지만, 하나가 더 높은 성능을 보이고 다른 하나가 통합하기 쉬운 경우, 조직은 현재 환경과 통합하기 쉬운 구성 요소를 선택하는 경향이 있습니다. 환경의 복잡성이 증가함에 따라 이런 편향은 계속될 가능성이 높습니다.

컨테이너화와 같은 기술을 구현하려면 이 새로운 접근 방식이 가져오는 가치를 측정할 방법이 필요합니다. 가치에 영향을 미치는 요인으로는 일반적으로 적합성, 역량, 노력, 비용이 포함됩니다. 다음 방정식은 이러한 요소에 기초하여 상대적 가치를 할당하는 방법의 예를 보여줍니다.

방정식에 사용하는 단위는 중요하지 않습니다. 중요한 것은 평가하는 각 항목에 대해 단위가 동일하다는 것입니다.

이 방정식은 기술을 원활하게 통합할 수 있어야 하며, 익숙함(즉, 삽입의 용이성)이 동급 최고의 기능이나 성능보다 더 중요할 수 있다는 점을 강조합니다. 결과적으로 배포 노력은 전반적인 가치 계산에 있어서 균형 효과를 가져오며, 삽입의 용이성으로 인해 성능이 낮은 제품이 고객에게 더 매력적으로 다가갈 수 있습니다.

이런 효과의 한 예로는 두 개의 경쟁 모니터링 솔루션이 있습니다. 제품 A는 동급 최고의 로깅 및 보고 기능을 갖춘 환상적인 사양을 갖추고 있습니다. 군사 수준의 보안이 통합되어 있으며 관리가 매우 용이합니다. 안타깝게도 독점적인 명령줄 인터페이스, 개방형 표준에 대한 지원 부족, 통합 기능 부족으로 인해 설치가 어렵습니다. 또한 시중에 판매되는 대부분의 다른 제품보다 가격이 비싼 편입니다.

비교해 보면 제품 B는 경쟁사의 기능에는 전혀 미치지 못하지만, 여전히 허용 가능한 수준의 모니터링과 보안을 제공합니다. 하지만 비용과 설치 용이성 측면에서는 경쟁 제품보다 우수한 점수를 받았습니다. 각 제품의 점수를 표로 정리하면 아래 표와 같습니다. 적합성, 역량, 설치 노력 등에 따라 1점에서 10점까지 점수를 매기며, 1점이 가장 낮고 10점이 가장 높습니다.

이러한 수치를 위의 방정식에 넣으면 표의 아랫줄에 나열된 가치 점수가 산출됩니다.

설치가 5배 더 쉽고 가격은 절반인 덜 적합하고 성능이 떨어지는 제품이 동급 최고 경쟁 제품과 비교했을 때 약 3배의 가치를 제공하는 것을 확인할 수 있습니다. 많은 조직에서는 이러한 고려사항을 이해하고 있으며 새로운 기술을 도입하고 배포할 때 설치 및 통합의 용이성을 주요 요소로 사용하는 경우가 늘고 있습니다. 컨테이너 기반 접근 방식은 적합성과 기능을 모두 유지하면서도 배포 노력을 크게 줄이고 비용을 제어할 수 있습니다.

앱이 비즈니스 가치를 점점 더 주도함에 따라 컨테이너화는 DevOps 중심 IT 구현 관행의 과제에 대한 논리적인 솔루션을 제공합니다. 컨테이너는 가상 머신을 실행하는 데 따른 관리 오버헤드 없이 컨테이너가 실행되는 플랫폼과 컨테이너끼리의 격리를 제공합니다. 개발자는 필요한 네트워킹 및 관리 시설이 내장되어 있고, 필요한 모든 바이너리와 라이브러리가 포함된 앱 환경을 쉽게 구축할 수 있습니다. 컨테이너화는 또한 애플리케이션 테스트와 배포를 단순화합니다.

컨테이너 기반 환경은 서버에서 실행할 수 있는 애플리케이션 인스턴스 수를 엄청나게 확장함으로써 가상 컴퓨터보다 리소스 활용도가 더 높습니다. 호스트와 게스트 운영 체제 모두의 오버헤드가 없기 때문에 컨테이너 환경에서는 운영 체제 커널을 공유하여 프로세서 시간과 메모리 공간을 보다 효율적으로 사용할 수 있습니다. 컨테이너화는 기본 플랫폼이 가상 머신이나 물리적 서버가 될 수 있으므로 아키텍처에 대한 유연성도 더 높아집니다. Red Hat 제품 전략¹ 향후 컨테이너에 앱을 배포하는 Kubernetes 고객의 거의 절반이 컨테이너 엔진을 베어 메탈에서 직접 실행할 것임을 나타냅니다.

컨테이너화는 하드웨어 기반 컴퓨팅에서 가상화로, 그리고 멀티 클라우드로 나아가는 과정에서 차세대 발전을 제공하며, 최대 100% 자동화, 1초 미만의 서비스 생성 시간, 그리고 몇 초 단위로 측정할 수 있는 서비스 수명을 가능하게 합니다. Docker, OpenShift, Kubernetes와 같은 컨테이너 환경은 최신 IT 아키텍처 내에서 서비스와 마이크로서비스를 즉각적으로 프로비저닝하고 프로비저닝 해제하는 것을 가능하게 합니다.

중요한 점은 컨테이너화가 오늘날의 다중 플랫폼, 다중 클라우드 환경에 꼭 필요한 핵심 이점을 제공한다는 것입니다. 즉, 기본 코드를 변경하지 않고도 온프레미스에서 클라우드로, 다른 클라우드 공급업체로, 그리고 다시 온프레미스로 앱을 이식할 수 있는 기능입니다. 상호 운용성이 아키텍처 관련 결정을 뒷받침하는 핵심 요소이므로 이러한 이식성을 통해 IT 부서는 앱 서비스 배포를 위한 주요 이정표를 달성하고 DevOps 팀이 조직적 목표를 달성할 수 있습니다. 최근 IBM 보고서² 앱 배포에 컨테이너를 사용하면 기업에서 앱 품질을 개선하고, 결함을 줄이고, 애플리케이션 다운타임과 관련 비용을 최소화할 수 있다는 점을 강조합니다.

같은 보고서에는 컨테이너 기반 환경에 고유하게 적합한 애플리케이션, 즉 데이터 분석, 웹 서비스, 데이터베이스도 나열되어 있습니다. 여기서 핵심 요소는 성능이지만, 고려해야 할 다른 관련 요소로는 애플리케이션이 여러 환경에서 실행될 가능성이 있는지, 그리고 병렬로 작업하는 여러 DevOps 팀을 지원하기 위해 마이크로서비스를 사용하는지 여부 등이 있습니다. 컨테이너를 사용하면 앱의 인스턴스를 더 많이 생성하는 것만으로 성능 문제를 해결할 수 있습니다. 단, 상태 비저장 아키텍처 디자인을 구현하고 대규모로 앱 서비스를 제공해야 합니다.

컨테이너가 배포 측면에서 전혀 문제가 없는 것은 아니며, 이 젊은 기술은 아직 가상화의 성숙 수준에 도달하지 못했습니다. 다음 섹션에서는 컨테이너가 가져오는 몇 가지 과제를 강조합니다.

1. 키 관리 – 컨테이너 간 키 관리가 문제가 될 수 있습니다. 특히 컨테이너의 주요 이점이 이동성이기 때문입니다. 주요 관리 환경은 온프레미스 호스트 간뿐만 아니라 클라우드에서 컨테이너로의 이동과 다시 클라우드에서 컨테이너로의 이동도 처리할 수 있어야 합니다.
2. 네트워킹 – 컨테이너는 컨테이너가 시작되고 종료되는 속도 때문에 기존 네트워킹 모델에 도전합니다. 결과적으로 그러한 환경에서는 정적 네트워크 주소가 작동하지 않게 됩니다. DHCP(Dynamic Host Configuration Protocol)와 같은 주소 지정 메커니즘이 실제 호스트와 가상 머신에서 잘 작동하더라도 컨테이너 워크로드는 컨테이너의 IP 주소에 등록되고 컨테이너 자체가 검색 가능해지기 전에 나타났다가 사라질 수 있습니다. 컨테이너 기반 소프트웨어 정의 네트워킹(SDN)을 사용하여 물리적 네트워크 하드웨어와 분리하는 것은 온프레미스에서 프라이빗 및 퍼블릭 클라우드 환경으로 전체 컨테이너 토폴로지를 마이그레이션하는 데 필수적입니다. 대부분의 컨테이너 환경은 이 기능을 수행하기 위해 어떤 형태의 컨테이너 네트워크 인터페이스(CNI)를 구현합니다.
3. 다중 컨테이너 기술 – 귀하의 조직은 이미 환경 내에 여러 가지 다른 컨테이너 기술을 구현했을 수 있습니다. 이러한 구현에도 불구하고 직원들이 이러한 모든 환경에 대한 심층적인 기술적 이해가 부족할 가능성이 있습니다. 교육이 중요하며, 팀이 다양한 컨테이너 구현에 익숙해질 수 있도록 시간을 주는 것도 중요합니다. 이러한 다중 컨테이너 기술을 관리하는 데도 비용이 더 많이 듭니다. 그러나 관리 용이성이 향상되고 특히 최신 Kubernetes 릴리스에서는 조직에서 가장 쉽고 가장 많이 사용되는 환경을 표준화하는 경향이 있습니다.
4. 기본 구성 위험 – 앱이 컨테이너에서 개발됨에 따라 잘못 구성된 컨테이너의 위험이 증가합니다. 기본 구성으로 컨테이너를 배포하는 것이 그 예입니다. 팔로 알토의 Unit 42 글로벌 위협 인텔리전스³ 최근 기본 구성 설정을 갖는 40,000개 이상의 고유한 컨테이너 장치를 식별했습니다. 물론 모든 사례가 악용되기 쉬운 것은 아니지만, 기본적인 구성 오류 관행이 널리 퍼져 있으며 이러한 조직이 추가 악용의 대상이 될 수 있다는 점을 보여줍니다.

컨테이너화의 중요한 설계 기준은 그림 2에서 볼 수 있듯이 성능, 밀도, 안정성의 세 가지 벡터 간의 균형입니다.

F5 접근 방식은 시스템 수준이 아닌 구성 요소 수준의 컨테이너화에 초점을 맞추는 것입니다. 이러한 접근 방식은 다음과 같은 여러 가지 장점을 제공합니다.

• 사용되지 않는 네트워크 기능에 메모리를 할당하지 않음으로써 각 컨테이너의 메모리 공간을 줄입니다.
• 호스트 CNI에 대한 종속성을 최소화하여 네트워크 성능 문제를 방지합니다.
• 장애 도메인을 구독자/사용자 수준까지 낮추는 작고 가벼운 구성요소를 구현합니다.

구성 요소 수준 컨테이너화를 사용하면 분리, 스케줄링, 오케스트레이션을 통해 3가지 균형이 달성됩니다. 컨테이너를 구현하는 F5 제품은 이러한 기능을 사용하여 컨테이너화의 이점을 극대화합니다.

조직이 컨테이너 기반 기술을 도입할 때 이를 지원하기 위해 F5는 오픈 소스 컨테이너 통합 서비스인 F5® 컨테이너 인그레스 서비스를 제공합니다. 컨테이너 인그레스 서비스는 라우팅, SSL 오프로드, HTTP 라우팅, 강력한 보안과 같은 자동화, 오케스트레이션 및 네트워킹 서비스를 제공합니다. 중요한 점은 Kubernetes와 Red Hat OpenShift와 같은 기본 컨테이너 환경과 다양한 BIG-IP 서비스를 통합한다는 것입니다.

아키텍처 측면에서 Container Ingress Services는 컨테이너화된 앱과 관련하여 다음과 같은 위치를 차지하며, 프런트 도어 Ingress 컨트롤러 서비스를 추가하고 BIG-IP를 통해 가시성과 분석을 지원합니다.

컨테이너 인그레스 서비스는 이 논문의 앞 부분에서 언급한 두 가지 핵심 문제인 확장성과 보안을 해결합니다. 보안 서비스를 활성화하여 컨테이너 작업 부하에 맞춰 앱을 확장하고 컨테이너 데이터를 보호할 수 있습니다. BIG-IP 플랫폼 통합을 사용하면 오케스트레이션 환경 내에서 셀프 서비스 앱 성능을 구현할 수 있습니다. Container Ingress Services를 사용하면 템플릿 기반 배포 및 업그레이드에 Helm 차트를 사용함으로써 개발자가 기본 설정으로 Kubernetes 컨테이너를 구현할 가능성도 줄어듭니다.

또한, Container Ingress Services는 고급 컨테이너 애플리케이션 공격 보호 및 액세스 제어 서비스를 통해 보안을 강화합니다. 구성에 익숙하지 않은 앱 개발자와 DevOps 전문가를 위해 F5 애플리케이션 서비스는 DevCentral 고객과 오픈 소스 커뮤니티 외에도 엔터프라이즈급 지원과 함께 즉시 사용 가능한 정책 및 역할 기반 액세스 제어(RBAC)를 제공합니다.

네이티브 쿠버네티스와 관련된 과제는 복잡성을 증가시키지 않으면서 최신 컨테이너 앱을 개발하고 확장하는 것과 관련이 있습니다. 성능과 안정성에 제약이 있을 수 있으며, Kubernetes 컨테이너에 프런트 도어를 제공하는 서비스가 일관되지 않게 구현되어 배포 및 구성을 위해 더 큰 통합 노력이 필요할 수 있습니다.

이러한 과제를 해결하기 위한 솔루션은 Kubernetes 앱에 대한 전송 서비스를 제공하여 기본 Kubernetes 환경을 향상시키는 NGINX Kubernetes Ingress Controller 입니다. 일반적으로 Kubernetes Pod는 동일한 클러스터 내의 다른 Pod와만 통신할 수 있습니다. 그림 4는 Kubernetes Ingress Controller가 외부 네트워크에서 Kubernetes Pod로의 액세스를 제공하는 모습을 보여줍니다. 이는 URI(Universal Resource Identifier) 경로, 백킹 서비스 이름 및 기타 구성 정보와 같은 요소를 제어하는 Ingress 리소스 규칙을 사용하여 관리됩니다. 사용 가능한 서비스는 NGINX를 사용하는지 NGINX Plus를 사용하는지에 따라 달라집니다. 

NGINX를 사용하는 기업은 부하 분산, SSL 또는 TLS 암호화 종료, URI 재작성, 업스트림 SSL 또는 TLS 암호화와 같은 기능을 얻을 수 있습니다. NGINX Plus는 상태 저장 애플리케이션을 위한 세션 지속성 및 JSON 웹 토큰(JWT) API 인증과 같은 추가 기능을 제공합니다.

조직이 개발자의 민첩성과 클라우드 기반 확장성을 확보하기 위해 마이크로서비스를 도입함에 따라 조직 역량이 기술을 따라잡을 때까지 학습 곡선에 직면하게 됩니다. 이러한 조직에서는 고객 경험의 기반이 되는 안정성을 유지하면서도 마이크로서비스의 이점을 빠르게 활용하고자 합니다.

Aspen Mesh는 기업이 대규모로 마이크로서비스와 쿠버네티스를 도입하고 마이크로서비스 아키텍처의 관찰성, 제어 및 보안을 확보하는 데 도움이 되는 오픈 소스 Istio 서비스 메시의 완벽히 지원되는 버전입니다. Aspen Mesh는 서비스 상태와 운영 상태를 쉽게 시각화하고 이해할 수 있는 사용자 인터페이스, 세분화된 RBAC, 컨테이너화된 애플리케이션에서 원하는 동작을 보다 쉽게 구현할 수 있는 정책 및 구성 기능 등 주요 서비스 메시 엔터프라이즈 기능을 추가합니다.

Aspen Mesh는 Kubernetes 클러스터에 배포되고 프라이빗 또는 퍼블릭 클라우드나 온프레미스에서 실행할 수 있는 Kubernetes 기본 구현을 제공합니다. 중요한 점은 컨테이너 인그레스 서비스를 사용하여 더욱 심층적인 레이어 7 기능을 프로비저닝하고 F5 기반 인그레스 메커니즘과 협력하여 작동할 수 있다는 것입니다.

아키텍처 측면에서 Aspen Mesh는 사이드카 프록시 모델을 활용하여 컨테이너화된 애플리케이션에 다양한 수준의 기능과 보안을 추가합니다(그림 5 참조).