2018년 초, 저는 네트워킹과 새롭게 부상하던 5G 표준 분야의 전문가인 친구 및 동료들과 비슷한 대화를 계속 나누곤 했습니다. 우리 모두는 수많은 미지의 요소를 안고 성급하게 전환을 추진하고 있다는 막연한 불안감을 느꼈습니다. 5G가 컨테이너와 클라우드 네이티브 아키텍처로의 전환을 촉진할 것이라는 점은 모두 이해하고 있었지만, Kubernetes를 비롯한 클라우드 네이티브 도구가 애초에 전혀 다른 사용 사례를 염두에 두고 만들어졌다는 사실도 알고 있었습니다. 우리 모두가 목격한 것은(아마 이 글을 읽는 많은 분도 마찬가지였겠지만) 업계가 큰 골칫거리와 정면충돌할 수밖에 없는 방향으로 치닫고 있다는 점이었습니다.
그렇게 우려하던 시기를 지나, 통신 서비스 제공업체(CSP)는 클라우드 네이티브 인프라로 마이그레이션하기 위한 본격적인 작업에 착수했습니다. 이러한 배포를 선도적으로 추진한 기업들은 당초 설계된 Kubernetes 네트워킹의 핵심 영역이 서비스 제공업체의 사용 사례에서 요구되는 사항을 충족하지 못하는 예상 밖의 장벽을 실제로 발견하고 있습니다. 통신사의 목표가 5G 단독 모드(SA) 코어 배포로 전환하는 것이든, 분산 클라우드 아키텍처를 활용한 현대화 이니셔티브의 일환이든, 네트워크 상호 운용성, 통신사급 확장성 및 통신사 보안 정책을 지원하도록 Kubernetes를 조정하는 것은 클라우드 네이티브 인프라 전반에 필요한 핵심 역량입니다.
Kubernetes는 이후 퍼블릭 클라우드 또는 엔터프라이즈 환경에서 실행되는 웹 및 IT 사용 사례에 주로 초점을 맞춰 발전해 왔기 때문에, 서비스 제공업체의 사용 사례를 배포하는 데 필요한 고유한 요구 사항과 프로토콜이 애초에 고려되지 않았던 것은 이해할 만합니다. 하지만 다행히도 Kubernetes 설계자들은 Kubernetes를 확장할 수 있도록 견고한 설계 패턴을 마련했으며, 이를 통해 네트워크 트래픽 관리, 가시성 및 제어, 그리고 HTTP/2, GTP, SIP, Diameter와 같은 확장 프로토콜 지원 등 통신사의 핵심 사용 사례를 구현할 수 있는 길을 열었습니다.
오늘날의 서비스 제공업체 사용 사례에 Kubernetes를 적합하게 만들기 위해 어떤 개선 사항이 필요한지 설명하기에 앞서, 먼저 서비스 제공업체 네트워크의 고유한 요구 사항을 살펴보겠습니다.
Kubernetes는 더 큰 생태계에 부합해야 합니다
우선 Kubernetes 클러스터는 서비스 제공업체의 광범위한 네트워크 및 운영 환경과 통합되어야 합니다. 아키텍처 결정은 운영 비용과 복잡성을 증가시키는 등 장기적인 영향을 미칠 수 있습니다. 네트워크 아키텍트는 다양한 통신사 사용 사례와 레거시 프로토콜 지원, 그리고 Kubernetes 내부의 동적 변경이 기존 네트워크 토폴로지에 미칠 수 있는 영향을 고려해야 합니다. 이러한 영향으로 인해 복잡성이 더욱 커질 수 있습니다.
둘째, 통신 워크로드(네트워크 기능)는 IT 워크로드와 다릅니다. 서비스 제공업체의 네트워크와 네트워크 기능은 표준 HTTP/HTTPS 또는 TCP 외에도 다양한 프로토콜을 사용합니다. 이동통신 사업자에게는 SIP, GTP, SCTP 등의 기존 3G/4G 프로토콜과 5G HTTP2를 모두 지원하는 네트워킹 기능이 매우 중요합니다. 또한 통신 워크로드에는 IT 워크로드와 달리 기존 네트워킹 계층 위에 추가적인 표준 계층이 존재합니다.
마지막으로, 결코 빼놓을 수 없는 보안은 새로운 모든 노출 지점에서 무엇보다 중요하며, 이를 위해서는 새로운 자동화, 가시성 및 관리 기능이 필요합니다. 보안은 모든 계층에 배포되어야 하며, 새로운 기술을 도입할 때 새로운 클러스터와 함께 작동해야 합니다. 서비스 제공업체의 SecOps 팀은 공격 표면을 줄이고 일관된 보안 제어를 유지할 방법을 항상 모색하고 있습니다. 또한 네트워크 전반의 보안 정책은 지속적으로 업데이트되고 변화에 맞게 조정될 수 있어야 합니다.
이러한 기능적 격차를 해소하기 위한 현재의 두 가지 접근 방식
Kubernetes 패턴 우회
클라우드 네이티브 패턴을 우회한다는 것은 Kubernetes에 통신사 워크로드를 처리할 도구가 기본적으로 제공되지 않기 때문에 아키텍트들이 어쩔 수 없이 임시방편을 만들어 내고 있음을 보여주는 징후입니다. 통신사들이 이러한 패턴을 깨뜨리는 몇 가지 우려스러운 방식을 확인했습니다:
- Kubernetes 네트워킹 우회 – 대다수의 CNF는 하나 이상의 인터페이스를 Kubernetes의 제어 범위 밖에 두고 있습니다. 이러한 CNF에는 네트워크에 직접 액세스할 수 있는 기능이 필요합니다(외부에 직접 연결되는 추가 인터페이스를 허용하기 위해 흔히 ‘multus’ 요청으로 제시됨). 네트워킹을 중앙에서 제어하지 않으면 Kubernetes 내부의 복잡성이 외부 서비스 제공업체 네트워크에 노출되어 운영 복잡성과 비용이 증가하고 보안 공격 표면도 확대됩니다. 또한 모든 앱/네트워크 기능 개발자와 네트워크 운영자가 IP 주소를 관리하고, 이제 외부에 노출된 Kubernetes 컨테이너의 동적 특성까지 처리해야 하므로 부담이 더욱 커집니다.
- 각 네트워크 기능을 위한 별도의 클러스터 – Kubernetes 네트워킹은 기본적으로 네트워크 트래픽의 인그레스/이그레스를 중앙에서 제어하는 지점을 제공하지 않습니다. Kubernetes는 일부 인그레스 제어 기능을 제공하지만 이그레스 트래픽은 거의 전적으로 무시하며, 인그레스와 이그레스 네트워킹을 연계하는 기본 제공 방식도 없습니다. 서버의 IP 주소와 네트워크 기능의 IP 주소를 서로 연계할 수 있도록 각 네트워크 기능을 자체 클러스터에서 실행하는 여러 배포 사례를 확인했습니다. 이로 인해 추가적인 리소스 오버헤드와 CapEx 지출 증가가 발생하며, 운영 복잡성까지 가중되어 OpEx 지출도 증가합니다.
Kubernetes 패턴에 맞게 조정
또 다른 접근 방식은 Kubernetes 설계 패턴에 맞춰 외부에서 Kubernetes 클러스터의 인그레스/이그레스 네트워킹과 보안을 통합적으로 관리할 수 있는 서비스 프록시를 도입하는 것입니다. 서비스 프록시의 목표는 서비스 제공업체 환경에서 Kubernetes를 사용할 때 발생하는 기능적 공백을 보완하는 것입니다. 서비스 프록시는 다음을 수행해야 합니다:
- Kubernetes 네이티브 패턴 사용을 통해 Kubernetes 네트워킹 확장(사용자 정의 리소스 정의, K8s 제어 루프)
- 더 광범위한 네트워크와 연동 (BGP 라우팅, 송신 SNAT IP 할당, IPv4/v6 변환)
- 인그레스 및 이그레스 연결 각 CNF별로 개별적으로
- 광범위한 L4/L7 지원 제공 (tcp, udp, sctp, NGAP, HTTP/2, Diameter, GTP, SIP)
- 보안 계층 제공 (TLS 종료, 방화벽, DDoS, 웹 애플리케이션 방화벽)
- 일관된 CNF 제공, 매우 동적인 Kubernetes 이벤트 숨김
F5의 접근 방식 — 서비스 프록시 소개
F5는 Kubernetes를 확장하고 이러한 서비스 프록시를 구축해 부족한 기능을 제공하기 위해 위에서 설명한 두 번째 시나리오를 선택했습니다. 수십 년간 축적해 온 트래픽 관리 및 보안 전문성을 바탕으로, F5는 이 기능이 대규모 클라우드 네이티브 마이그레이션을 지원하는 데 반드시 필요하다고 판단합니다. F5는 Kubernetes의 한계를 직접 해결하고 서비스 제공업체가 기본 Kubernetes에는 없는 리소스를 생성할 수 있도록, 현재 프로덕션 환경에 바로 도입 가능한 클라우드 네이티브 인프라 제품인 BIG-IP Next Service Proxy for Kubernetes(SPK)를 개발했습니다. SPK는 광범위한 네트워크 및 보안 정책과 원활하게 통합되고 자동화되는 프레임워크를 통해 아키텍처를 간소화하고 보호합니다. 통신사를 위한 이러한 Kubernetes 접근 방식은 복잡성과 운영 비용을 지속적으로 낮추는 동시에 더욱 탄력적이고 안전한 인프라를 구현합니다. 현재 5G SA로의 전환이 둔화되고 있는 상황에서(GlobalData, 통신 사업자들의 5G SA 도입이 부진하다고 분석), 적합한 서비스 프록시가 도입되지 않으면 전환이 더욱 차질을 빚을 것이라고 보는 것이 타당합니다. 대규모 디지털 현대화를 진행 중인 실제 프로덕션 환경의 통신사 고객들은 SPK가 미처 인식하지 못했던 5G 네트워크 아키텍처 문제를 해결하는 Kubernetes 솔루션임을 확인하고 있습니다.
F5의 SPK는 이제 정식 출시(GA)되었으며 현재 대규모 통신사에서 프로덕션 환경에 사용되고 있습니다. 향후 행사에서는 다른 접근 방식과 비교한 SPK의 기능과 당사 플랫폼에서 CNF를 인증하는 방법을 시연할 예정입니다. 자세한 내용은 이 페이지를 참조하시고, F5 팀원과 직접 상담하려면 문의해 주세요.
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.