F5와 컨테이너화
소개
조직은 새로운 비즈니스 기회를 창출하기 위해 기술 변화를 수용하는 것과 새로운 과제 및 위험으로부터 비즈니스를 보호하는 것 사이에서 끊임없이 고심합니다. 이 백서에서는 컨테이너화와 F5 제품에 이 기술을 도입하는 것이 IT 전문가, 아키텍트 및 비즈니스 의사 결정권자에게 미치는 영향을 살펴봅니다.
지난 20년 동안 가상화는 하나의 하드웨어 플랫폼에서 서로 독립된 여러 운영 체제를 실행할 수 있게 함으로써 서버 컴퓨팅을 혁신해 왔습니다. 보다 현대적인 접근 방식인 컨테이너화(또는 운영 체제 가상화)를 사용하면 호스트 운영 체제의 단일 인스턴스에서 여러 애플리케이션을 실행할 수 있습니다. 이때 각 애플리케이션 인스턴스는 단일 운영 체제 인스턴스에 설치된 바이너리와 라이브러리를 공유합니다. 그림 1에서는 이러한 접근 방식을 비교합니다.
가상 머신(VM)과 달리 컨테이너는 동일한 운영 체제를 공유할 수 있으며, 하이퍼바이저 수준이 아닌 OS 수준에서 가상화됩니다.
당연하게도 개발자들은 컨테이너를 선호합니다. 컨테이너를 사용하면 애플리케이션을 빠르고 쉽게 개발 및 배포하고 마이크로서비스를 구동할 수 있기 때문입니다. 또한 컨테이너화는 이식성을 높여 줍니다. 컨테이너에 담긴 앱은 다양한 운영 체제, 하드웨어 플랫폼 및 클라우드 서비스에 더 쉽게 배포할 수 있습니다. 컨테이너는 베어 메탈에서 호스팅되는 운영 체제나 가상 머신에서 직접 실행되는 애플리케이션보다 더 적은 리소스를 사용합니다.
일반적으로 컨테이너에 관한 논의(및 문서)는 대부분 프로그래밍 또는 DevOps 관점에 초점을 맞춥니다. IT 전문가, 시스템 아키텍트 또는 비즈니스 의사 결정권자로서 컨테이너화가 제공하는 유연성의 가치를 인정하면서도, 이러한 변화가 조직 환경 내 앱과 서비스의 운영, 관리 및 모니터링에 어떤 영향을 미칠지 실질적인 우려가 있을 수 있습니다. 또한 컨테이너화가 네트워크 및 앱 보안에 부정적인 영향을 미치지 않도록 해야 합니다.
현대 IT 과제 해결
경쟁이 갈수록 치열해지는 시장에서 현대적인 IT 시스템은 실질적인 비즈니스 이점을 제공해야 합니다. 이러한 요구 사항을 충족하려면 IT 부서가 애플리케이션 자산을 확충하고, 단순히 더 많은 애플리케이션뿐만 아니라 기능이 더욱 풍부하고 사용성이 향상되었으며 통합이 용이한 애플리케이션을 갖춘 아키텍처를 설계하고 구축할 수 있어야 합니다.
IT 책임자들이 직면한 과제는 인력을 늘리지 않고도 부서에서 더 많은 기능을 제공해야 한다는 것입니다. 이제 생산성 향상은 인력을 추가로 채용하는 것이 아니라, 동일한 규모의 팀으로 관리하면서 고객에게 제공되는 앱의 수를 늘릴 수 있게 해주는 기술과 자동화의 발전을 통해 이루어집니다.
컨테이너를 손쉽게 배포할 수 있다는 점은 또 다른 과제를 야기합니다. 개발자가 애플리케이션을 개발할 때 확장성과 보안을 모두 고려하도록 교육하고 안내해야 하며, IT 전문가는 개발자가 이러한 목표를 달성하도록 지원할 수 있습니다. 이때 Kubernetes 및 Docker와 같은 컨테이너 플랫폼이 프로덕션 환경에 미치는 영향을 고려해야 하며, 민첩성에 대한 요구로 인해 미흡한 보안 관행이나 프로덕션 부하에 대한 고려 부족과 같은 바람직하지 않은 결과가 발생하지 않도록 해야 합니다.
Kubernetes는 컨테이너화된 서비스와 워크로드를 관리하기 위한 오픈 소스 플랫폼입니다. Kubernetes는 원래 Google의 컨테이너 스케줄링 및 오케스트레이션 시스템으로 개발되었으며, 이후 Google이 이를 Cloud Native Computing Foundation에 기증하면서 누구나 소스 코드를 이용할 수 있게 되었습니다. Docker 역시 이와 유사한 형태의 오픈 소스 아키텍처와 배포 방식을 제공하며, 서로 연계된 SaaS(Software as a Service) 및 PaaS(Platform as a Service) 제품군으로 구성됩니다.
가치 실현 시간 계산
실현 가능한 비즈니스 이점을 제공하는 데 있어 핵심 요소는 가치 실현 시간을 최소화하는 것입니다. 최근에는 성능이나 지연 시간 같은 요소보다 도입의 용이성이 더 중요하게 여겨지고 있습니다. 따라서 기능이 거의 동일한 두 구성 요소 중 하나는 성능이 더 뛰어나고 다른 하나는 통합이 더 쉬운 경우, 조직은 현재 환경에 더 쉽게 통합할 수 있는 구성 요소를 선택하는 경향이 있습니다. 환경의 복잡성이 증가함에 따라 이러한 경향은 계속될 가능성이 높습니다.
가치 결정
컨테이너화와 같은 기술을 도입하려면 이 새로운 접근 방식이 제공하는 가치를 측정할 방법이 필요합니다. 가치에 영향을 미치는 요인에는 일반적으로 적합성, 역량, 노력 및 비용이 포함됩니다. 다음 방정식은 이러한 요인을 바탕으로 상대적 가치를 산정하는 방법의 예를 보여 줍니다.
방정식에 사용하는 단위 자체는 중요하지 않습니다. 중요한 것은 평가하는 각 항목에 동일한 단위를 사용하는 것입니다.
이 방정식은 기술이 원활하게 통합될 수 있어야 하며, 익숙함(즉, 도입의 용이성)이 동급 최고의 기능이나 성능보다 더 중요할 수 있음을 보여 줍니다. 따라서 배포에 필요한 노력은 전체적인 가치를 산정할 때 균형을 맞추는 요소로 작용하며, 그 결과 성능이 다소 떨어지는 제품이라도 도입이 쉽다는 이유로 고객에게 더 매력적으로 다가갈 수 있습니다.
이러한 효과의 예로 서로 경쟁하는 두 모니터링 솔루션을 들 수 있습니다. 제품 A는 동급 최고의 로깅 및 보고 기능을 갖춘 뛰어난 사양을 자랑합니다. 군사 등급의 보안 기능을 제공하며 관리 편의성도 매우 높습니다. 하지만 독점 명령줄 인터페이스, 미흡한 개방형 표준 지원, 통합 기능 부족으로 인해 설치가 어렵습니다. 또한 시중의 다른 제품 대부분보다 가격도 비쌉니다.
이에 비해 제품 B의 기능은 경쟁 제품에 크게 미치지 못하지만, 모니터링 및 보안 수준은 여전히 준수합니다. 그러나 비용과 설치 편의성 측면에서는 경쟁 제품보다 높은 평가를 받습니다. 각 제품의 점수를 표로 정리하면 아래와 같습니다. 적합성, 기능, 설치 난이도를 1점부터 10점까지 평가했으며, 1점이 가장 낮고 10점이 가장 높습니다.
이 수치들을 위의 방정식에 대입하면 표의 맨 아래 행에 표시된 가치 점수가 산출됩니다.
적합성과 기능은 다소 떨어지지만 가격은 절반이고 설치는 5배 더 쉬운 제품이 동급 최고의 경쟁 제품보다 약 3배 높은 가치를 제공한다는 것을 알 수 있습니다. 많은 조직이 이러한 고려 사항을 이해하고 있으며, 새로운 기술을 도입하고 배포할 때 설치 및 통합의 용이성을 핵심 요소로 삼는 경우가 늘고 있습니다. 컨테이너 기반 접근 방식은 적합성과 기능을 모두 유지하면서도 배포에 드는 수고를 크게 줄이고 비용을 관리하는 데 도움이 될 수 있습니다.
컨테이너의 인기가 점점 높아지는 이유는 무엇일까요?
애플리케이션이 비즈니스 가치를 창출하는 데 점점 더 중요한 역할을 하면서, 컨테이너화는 DevOps 중심의 IT 구현 방식에서 발생하는 과제를 해결할 수 있는 합리적인 방안으로 자리 잡고 있습니다. 컨테이너는 가상 머신을 실행할 때 발생하는 관리 부담 없이 실행 플랫폼 및 다른 컨테이너로부터 격리된 환경을 제공합니다. 개발자는 필요한 모든 바이너리와 라이브러리는 물론, 필수 네트워킹 및 관리 기능까지 내장된 애플리케이션 환경을 손쉽게 구축할 수 있습니다. 또한 컨테이너화는 애플리케이션 테스트와 배포를 간소화합니다.
컨테이너 기반 환경은 서버에서 실행할 수 있는 애플리케이션 인스턴스 수를 대폭 늘려 가상 컴퓨터보다 리소스 활용도를 높입니다. 컨테이너 환경은 호스트 및 게스트 운영 체제의 오버헤드 없이 운영 체제 커널을 공유하므로 프로세서 시간과 메모리 공간을 더욱 효율적으로 사용합니다. 또한 기반 플랫폼으로 가상 머신이나 물리적 서버를 모두 사용할 수 있어 컨테이너화를 통해 아키텍처의 유연성도 향상됩니다. Red Hat 제품 전략1 에 따르면 향후 애플리케이션을 컨테이너에 배포하는 Kubernetes 고객 중 거의 절반이 베어 메탈에서 컨테이너 엔진을 직접 실행할 것으로 예상됩니다.
컨테이너화는 하드웨어 기반 컴퓨팅에서 가상화를 거쳐 멀티클라우드로 발전하는 과정의 다음 단계로, 최대 100%의 자동화, 1초 미만의 서비스 생성 시간, 초 단위로 측정할 수 있는 서비스 수명을 실현합니다. Docker, OpenShift, Kubernetes와 같은 컨테이너 환경은 최신 IT 아키텍처 내에서 서비스와 마이크로서비스를 즉시 프로비저닝하고 프로비저닝 해제할 수 있도록 지원합니다.
특히 컨테이너화는 오늘날의 멀티플랫폼 및 멀티클라우드 환경에서 필수적인 핵심 이점을 제공합니다. 바로 기본 코드를 변경하지 않고도 앱을 온프레미스에서 클라우드로, 다른 클라우드 공급업체로, 그리고 다시 온프레미스로 이전할 수 있다는 점입니다. 상호 운용성이 아키텍처 결정의 핵심 요소인 만큼, 이러한 이식성은 IT 부서가 앱 서비스 배포의 주요 목표를 달성하고 DevOps 팀이 조직의 목표를 달성하는 데 도움이 됩니다. 최근 IBM 보고서2에서는 앱 배포에 컨테이너를 사용하면 기업이 앱 품질을 개선하고 결함을 줄이며 애플리케이션 가동 중단 시간과 관련 비용을 최소화할 수 있다는 점도 강조합니다.
동일한 보고서에서는 데이터 분석, 웹 서비스, 데이터베이스 등 컨테이너 기반 환경에 특히 적합한 애플리케이션도 소개합니다. 여기서 핵심 요소는 성능이지만, 애플리케이션이 여러 환경에서 실행될 가능성이 있는지, 그리고 여러 DevOps 팀의 병렬 작업을 지원하기 위해 마이크로서비스를 사용하는지도 고려해야 할 중요한 요소입니다. 컨테이너를 사용하면 상태 비저장 아키텍처를 구현하고 앱 서비스를 대규모로 제공한다는 전제하에, 앱 인스턴스를 추가로 가동하는 것만으로 성능 문제를 해결할 수 있습니다.
컨테이너의 과제
컨테이너에도 배포상의 어려움이 있으며, 아직 초기 단계인 이 기술은 가상화만큼 성숙하지 않았습니다. 다음 섹션에서는 컨테이너로 인해 발생하는 몇 가지 과제를 살펴봅니다.
- 키 관리 – 컨테이너의 주요 이점 중 하나가 이식성이라는 점에서, 컨테이너 간 키 관리는 특히 문제가 될 수 있습니다. 키 관리 환경은 온프레미스 호스트 간 컨테이너 이동뿐만 아니라 클라우드로의 이동과 온프레미스로의 복귀도 처리할 수 있어야 합니다.
- 네트워킹 – 컨테이너는 빠르게 생성되고 종료될 수 있기 때문에 기존 네트워킹 모델에 어려움을 초래합니다. 따라서 이러한 환경에서는 고정 네트워크 주소를 사용할 수 없습니다. 또한 DHCP(Dynamic Host Configuration Protocol)와 같은 주소 지정 메커니즘은 물리적 호스트와 가상 머신에서는 원활하게 작동했지만, 컨테이너 워크로드는 컨테이너의 IP 주소가 등록되어 컨테이너 자체를 검색할 수 있게 되기도 전에 나타났다가 사라질 수 있습니다. 전체 컨테이너 토폴로지를 온프레미스에서 프라이빗 및 퍼블릭 클라우드 환경으로 마이그레이션하려면 컨테이너 기반 소프트웨어 정의 네트워킹(SDN)을 사용하여 물리적 네트워크 하드웨어와 분리하는 것이 매우 중요합니다. 대부분의 컨테이너 환경은 이 기능을 수행하기 위해 일종의 컨테이너 네트워크 인터페이스(CNI)를 구현합니다.
- 다양한 컨테이너 기술 – 조직의 환경에 이미 여러 컨테이너 기술이 구현되어 있을 수 있습니다. 이러한 기술이 구현되어 있더라도 직원들이 모든 환경을 기술적으로 깊이 이해하지 못하고 있을 가능성이 큽니다. 교육도 중요하지만, 팀이 다양한 컨테이너 구현 방식에 익숙해질 시간을 주는 것도 중요합니다. 여러 컨테이너 기술을 관리하려면 비용도 더 많이 듭니다. 그러나 특히 최신 Kubernetes 릴리스에서 관리 편의성이 개선됨에 따라 조직은 가장 사용하기 쉽고 널리 사용되는 환경으로 표준화하는 경향이 있습니다.
- 기본 구성의 위험 – 컨테이너에서 앱을 개발할수록 컨테이너가 잘못 구성될 위험이 커집니다. 대표적인 예로 컨테이너를 기본 구성 그대로 배포하는 경우를 들 수 있습니다. Palo Alto의 Unit 42 글로벌 위협 인텔리전스3 는 최근 기본 구성 설정을 사용하는 고유한 컨테이너 장치를 40,000개 이상 식별했습니다. 물론 이러한 인스턴스가 모두 악용에 취약한 것은 아니지만, 기본적인 구성 오류가 널리 퍼져 있으며 이로 인해 해당 조직이 추가 공격의 표적이 될 수 있음을 보여 줍니다.
균형 잡힌 컨테이너화
컨테이너화에서 중요한 설계 기준은 그림 2와 같이 성능, 집적도, 안정성이라는 세 가지 요소 간의 균형을 유지하는 것입니다.
F5의 접근 방식은 시스템 수준이 아닌 구성 요소 수준의 컨테이너화에 중점을 두는 것입니다. 이 접근 방식은 다음과 같은 여러 이점을 제공합니다:
- 사용하지 않는 네트워크 기능에 메모리를 할당하지 않아 각 컨테이너의 메모리 사용량을 줄입니다.
- 호스트 CNI에 대한 의존도를 최소화하여 네트워킹 성능 문제를 방지합니다.
- 장애 도메인을 가입자/사용자 수준으로 축소하는 작고 가벼운 구성 요소를 구현합니다.
구성 요소 수준의 컨테이너화를 통해 분리, 스케줄링 및 오케스트레이션으로 이러한 세 가지 요소 간의 균형을 달성할 수 있습니다. 컨테이너를 구현하는 F5 제품은 이러한 기능을 활용하여 컨테이너화의 이점을 극대화합니다.
F5 컨테이너 인그레스 서비스
조직의 컨테이너 기반 기술 도입을 지원하기 위해 F5는 오픈 소스 컨테이너 통합 솔루션인 F5® Container Ingress Services를 제공합니다. Container Ingress Services는 라우팅, SSL 오프로딩, HTTP 라우팅, 강력한 보안과 같은 자동화, 오케스트레이션 및 네트워킹 서비스를 제공합니다. 특히 다양한 BIG-IP 서비스를 Kubernetes 및 Red Hat OpenShift와 같은 네이티브 컨테이너 환경과 통합합니다.
아키텍처 측면에서 Container Ingress Services는 컨테이너화된 앱과 관련하여 다음과 같은 위치를 차지하며, 프런트 도어 Ingress 컨트롤러 서비스를 추가하고 BIG-IP를 통해 가시성과 분석 기능을 제공합니다.
Container Ingress Services는 이 백서에서 앞서 언급한 주요 문제 중 확장성과 보안이라는 두 가지 문제를 해결합니다. 앱을 확장하여 컨테이너 워크로드를 처리하고, 보안 서비스를 활성화하여 컨테이너 데이터를 보호할 수 있습니다. BIG-IP 플랫폼을 통합하면 오케스트레이션 환경 내에서 셀프서비스 방식으로 앱 성능을 관리할 수 있습니다. 또한 Container Ingress Services는 템플릿 기반 배포 및 업그레이드에 Helm 차트를 사용함으로써 개발자가 기본 설정으로 Kubernetes 컨테이너를 구현할 가능성을 줄여 줍니다.
또한 Container Ingress Services는 고급 컨테이너 애플리케이션 공격 방어 및 액세스 제어 서비스를 통해 보안을 강화합니다. 구성에 익숙하지 않은 앱 개발자와 DevOps 전문가를 위해 F5 애플리케이션 서비스는 즉시 사용 가능한 정책과 역할 기반 액세스 제어(RBAC), 엔터프라이즈급 지원을 제공하며, DevCentral 고객 및 오픈 소스 커뮤니티도 지원합니다.
NGINX Kubernetes 인그레스 컨트롤러
네이티브 Kubernetes와 관련된 과제는 복잡성을 가중하지 않으면서 최신 컨테이너 앱을 개발하고 확장하는 데 있습니다. 성능과 안정성에 제약이 있을 수 있으며, Kubernetes 컨테이너의 진입점 역할을 하는 서비스가 일관되지 않게 구현될 수 있어 배포 및 구성 시 더 많은 통합 작업이 필요할 수 있습니다.
이러한 과제에 대한 해결책은 NGINX Kubernetes Ingress Controller입니다. 이 컨트롤러는 Kubernetes 앱을 위한 전송 서비스를 제공하여 기본 Kubernetes 환경을 개선합니다. 일반적으로 Kubernetes Pod는 동일한 클러스터에 있는 다른 Pod와만 통신할 수 있습니다. 그림 4에서는 Kubernetes Ingress Controller가 외부 네트워크에서 Kubernetes Pod에 액세스할 수 있도록 하는 모습을 보여 줍니다. 이러한 액세스는 URI(Uniform Resource Identifier) 경로, 백엔드 서비스 이름 및 기타 구성 정보와 같은 요소를 제어하는 Ingress 리소스 규칙에 따라 관리됩니다. 사용 가능한 서비스는 NGINX 또는 NGINX Plus 중 무엇을 사용하는지에 따라 달라집니다.
NGINX를 사용하는 기업은 부하 분산, SSL 또는 TLS 암호화 종료, URI 재작성, 업스트림 SSL 또는 TLS 암호화 등의 기능을 활용할 수 있습니다. NGINX Plus는 상태 저장 애플리케이션을 위한 세션 지속성과 JSON 웹 토큰(JWT) API 인증 등의 추가 기능을 제공합니다.
Aspen Mesh
조직이 개발자의 민첩성과 클라우드 네이티브 확장성을 확보하기 위해 마이크로서비스를 도입하면, 조직의 역량이 기술 수준을 따라잡는 과정에서 학습 곡선을 겪게 됩니다. 이러한 조직은 고객 경험을 뒷받침하는 안정성을 유지하면서도 마이크로서비스의 이점을 신속하게 활용하고자 합니다.
Aspen Mesh 는 완전한 지원이 제공되는 오픈 소스 Istio 서비스 메시로, 기업이 마이크로서비스와 Kubernetes를 대규모로 도입하고 마이크로서비스 아키텍처의 가시성, 제어 및 보안을 확보할 수 있도록 지원합니다. Aspen Mesh는 서비스의 상태와 건전성을 쉽게 시각화하고 파악할 수 있는 사용자 인터페이스, 세분화된 RBAC, 컨테이너화된 애플리케이션이 원하는 방식으로 동작하도록 지원하는 정책 및 구성 기능 등 주요 엔터프라이즈 서비스 메시 기능을 추가로 제공합니다.
Aspen Mesh는 Kubernetes 네이티브 구현을 제공하며, Kubernetes 클러스터에 배포되어 프라이빗 또는 퍼블릭 클라우드나 온프레미스 환경에서 실행할 수 있습니다. 특히 Container Ingress Services를 사용하여 더욱 심층적인 레이어 7 기능을 프로비저닝함으로써 F5 기반 인그레스 메커니즘과 연동할 수 있습니다.
아키텍처 측면에서 Aspen Mesh는 사이드카 프록시 모델을 활용하여 컨테이너화된 애플리케이션의 기능과 보안 수준을 강화합니다(그림 5 참조).
F5와 컨테이너 도입
F5는 컨테이너 도입을 선도하며, 조직이 단순한 워크로드부터 대규모 산업별 워크로드에 이르기까지 애플리케이션 서비스를 확장할 수 있는 안정적이고 안전한 고성능 컨테이너형 애플리케이션 환경을 운영하도록 지원합니다. 컨테이너 기술은 서버리스 구현, 서비스 메시 아키텍처, 모바일 엣지 보안과 같은 미래의 애플리케이션 개발 및 배포 환경을 구현하는 핵심 요소가 될 것입니다. F5는 자체 개발 연구와 상용 컨테이너 구현을 모두 활용하여 고객의 비즈니스에 실질적인 변화를 가져올 앱과 서비스를 개발하고 발전시킵니다.
기존 제품을 가상화할 때와 마찬가지로, F5는 관리자에게는 즉시 드러나지 않을 수 있지만 최종 사용자에게는 완전히 투명한 방식으로 컨테이너 기술을 통합합니다. 고객은 향상된 성능과 유연성, 보안을 경험할 수 있습니다. F5가 이러한 새로운 앱과 서비스를 원활하게 구현하는 동안 고객은 필요한 기능을 확보하는 데 집중할 수 있습니다.
또한 최고의 오픈 소스 솔루션을 제품에 도입하여 이러한 오픈 소스 플랫폼이 제공하는 서비스를 확장하고 컨테이너 환경의 기능을 강화하기 위해 노력하고 있습니다. 당사의 목표는 언제나 배포가 더 쉽고, 기존 네트워크에 더 빠르게 통합할 수 있으며, 안정성과 보안성이 더욱 뛰어난 제품을 만드는 것입니다.
컨테이너 도입 전략을 실행하기 위해 다음과 같은 접근 방식에 중점을 두고 있습니다:
- 당사가 제공하는 비보안 애플리케이션 서비스의 범위를 확대합니다. 여기서는 애플리케이션 성능 관리, 로깅 및 추적, 향상된 디버깅, 전반적인 애플리케이션 상태 모니터링 등 컨테이너 환경의 관찰 가능성과 관리 용이성을 높이는 더 나은 도구를 제공하는 데 중점을 둡니다.
- 컨테이너에 데이터 플레인 이외의 영역을 위한 보안 서비스를 추가합니다. 이를 위해 실행 중인 컨테이너의 공격 표면을 줄이는 보안 서비스를 제공하는 혁신을 추진할 계획입니다.
- F5 제품에서 타사 컨테이너를 호스팅할 수 있도록 지원합니다. 이 통합 옵션을 사용하면 고객이 개발한 앱이나 타사 앱을 현재 및 향후 F5 제품의 유연한 컨테이너 런타임 인터페이스 내에서 실행할 수 있습니다. 이를 통해 F5는 다양한 상용 또는 맞춤형 컨테이너와 앱을 포함하는 턴키 솔루션을 구축하여 상호 운용성을 크게 향상할 수 있습니다.
- 오픈 소스 도구를 사용하여 기존 애플리케이션 서비스를 패키징할 수 있도록 지원합니다. 이 옵션을 통해 레거시 환경과 신규 구축 환경 전반에 일관된 서비스 정책을 제공할 수 있습니다.
- 컨테이너 앱의 확장 및 보안 서비스를 자동화하여 지원에 할당되는 리소스를 제한하면서 관리 대상 애플리케이션을 늘립니다.
컨테이너의 미래
F5는 컨테이너가 향후 다양한 애플리케이션 서비스 기술을 제공하는 핵심 기반으로 자리 잡는 미래를 실현하기 위해 노력하고 있습니다. 이러한 기술에는 서버리스, 서비스 메시, 모바일 엣지가 포함되며, 현재 개발 중이거나 아직 구상되지 않은 다른 접근 방식도 포함될 수 있습니다. F5는 효과적인 네트워크 관리의 핵심 요소를 저해하지 않으면서 솔루션에 컨테이너를 통합할 수 있도록 제품군을 재설계하고 있습니다.
가상화와 마찬가지로 컨테이너 자체도 컨테이너 엔진이 실행되는 하드웨어의 기본 기능을 더욱 잘 인식하게 될 것입니다. 멀티스레딩, 메모리 속도, 스토리지 액세스 및 네트워킹은 각 컨테이너에서 실행되는 앱에 점점 더 투명하게 제공되어 리소스 활용도가 한층 더 향상될 것입니다.
당사는 컨테이너를 가상화를 대체하는 기술이 아니라 가상화를 보완하는 기술로 봅니다. 따라서 컨테이너는 적어도 가상화만큼 오랫동안 사용되며, 두 기술의 공존도 계속될 것으로 예상합니다. 마지막으로, 향후 가상화 및 컨테이너와 함께 공존할 한층 더 높은 수준의 추상화 기술이 등장할 것으로 전망합니다.
고객에게 보안이 언제나 핵심적인 우려 사항이라는 점을 잘 알고 있습니다. 이에 따라 F5는 하드웨어 및 소프트웨어 어플라이언스, 방화벽, 네트워킹 분야에서 축적한 경험을 바탕으로 모든 제품에 최고 수준의 보안을 지속적으로 제공합니다.
요약하면, F5는 기존의 컨테이너 관련 기술에 더해 앞으로도 F5 제품군에 컨테이너를 지속적으로 통합하여, 업데이트된 앱과 향후 출시될 앱에서 더 다양한 통합 옵션, 향상된 안정성과 성능, 단축된 배포 시간을 제공할 계획입니다.
F5 및 앱의 컨테이너 지원에 대한 자세한 내용은 다음 페이지를 참조하세요. f5.com/solutions/bridge-f5-with-container-environments
각주
1 베어메탈 Kubernetes 서버의 부상, Container Journal, Mike Vizard, 2019
2 컨테이너 기반 애플리케이션 개발 현황, IBM Cloud 보고서, 2018
3 잘못 구성되어 노출된 컨테이너 서비스, Palo Alto Networks, Nathaniel Quist, 2019
2022년 6월 23일 게시