수년간 네트워크 세분화는 위협 격리, 서비스 품질 차등화, 사고 대응 및 분석, 규정 준수 감사와 그 밖의 여러 핵심 상호운용성 기능을 뒷받침하는 중추 역할을 해왔습니다. 하지만 제로 트러스트 원칙을 강조하고 AI 도입을 서두르는 과정에서, 현대 사이버 보안과 서비스 운영의 토대가 되는 이 핵심 네트워크 인프라 요소를 소홀히 해온 것은 아닐까요?
앞서 AI 팩토리 시리즈에서 AI 팩토리를 정의할 때 대규모·고성능 학습 및 추론 요구 사항을 충족하기 위한 스토리지, 네트워킹, 컴퓨팅에 대한 막대한 투자라고 설명했습니다. 이러한 투자에서 수익을 창출하기 위해 AI 팩토리는 고가의 그래픽 처리 장치(GPU)와 컴퓨팅 자원의 사용을 동적으로 예약하여 학습과 추론을 수행합니다. GPU를 예약하려면 AI 클러스터마다 AI 서비스의 여러 ‘테넌트’를 구성해야 합니다. 이로 인해 많은 운영 팀이 미처 예상하지 못하다가 이미 너무 늦은 뒤에야 깨닫는 문제가 발생합니다.
AI 팩토리 클러스터 리소스와 네트워크 세분화의 연계
AI 클러스터 내에서는 테넌트 컨텍스트를 기반으로 리소스를 논리적으로 세분화하여 테넌트 할당량, 리소스 사용량 제한, 호스트 시스템 보안, 관리 역할 기반 액세스 제어(RBAC)를 적용할 수 있습니다. 그러나 AI 클러스터와 나머지 AI 팩토리 네트워크 간 트래픽의 인바운드 및 아웃바운드를 처리하는 기본 네트워크 서비스에는 테넌트 컨텍스트가 노출되지 않습니다. 이러한 컨텍스트가 없으면 데이터 센터 사이버 보안의 근간인 네트워크 세분화가 제 기능을 할 수 없습니다. 필요한 테넌트 컨텍스트를 노출하는 일반적인 방법은 AI 팩토리의 고가치 컴퓨팅 리소스를 크게 잠식하거나, 네트워크 경로의 성능을 서비스 지연 시간, 대역폭 또는 동시성에 필요한 기준 이하로 떨어뜨립니다. 결국 고가치 AI 팩토리 리소스를 효율적으로 활용하는 것과 테넌트를 네트워크에 적절히 통합하는 것 중 하나를 선택해야 하는 잘못된 양자택일에 직면하게 됩니다.
퍼블릭 클라우드 인프라에서 오케스트레이션된 멀티테넌트 네트워크 설계는 클라우드 리전 내 모든 서비스의 기반이며, 가상 프라이빗 클라우드(VPC)를 통해 구현됩니다. 이러한 가상화된 네트워크 세분화는 보안과 리소스 사용량 측정에 핵심적입니다. 퍼블릭 클라우드 제공업체는 네트워크 소프트웨어 개발자 팀과 SmartNIC을 비롯한 특수 네트워킹 하드웨어 및 데이터 처리 장치(DPU)를 활용해 이 기능을 유지합니다. 퍼블릭 클라우드의 AI 팩토리 클러스터는 기반 인프라의 VPC 네트워크 오케스트레이션을 활용하도록 설계됩니다. VPC 유지 비용은 상당히 높지만, 이는 퍼블릭 클라우드 비즈니스 모델의 핵심 요소입니다.
여기서 한 가지 의문이 생깁니다. 조직은 퍼블릭 클라우드 제공업체와 같은 수준의 투자를 하지 않고도 AI 팩토리 투자의 효과를 극대화하고 GPU와 컴퓨팅 리소스를 동적으로 스케줄링하려면 어떻게 해야 할까요?
이 여정에서 업계가 가장 먼저 선택한 방법은 서버 가상화를 사용해 가상 머신(VM)을 만드는 것이었습니다. VM은 하드웨어 패스스루를 활용해 분할된 데이터 센터 네트워크에 연결됩니다. 단일 AI 클러스터의 단일 테넌트만 고려한다면 모든 가상 머신을 동일한 VLAN에 배치하기만 하면 기존과 동일한 방식으로 운영을 계속할 수 있습니다.
GPU 공급업체는 GPU 장치를 코어와 메모리 집합으로 세분화한 후 특정 가상 머신에 할당하는 방식을 지원하므로, VM을 통해 GPU 분할 문제도 해결할 수 있습니다. 그러나 GPU 장치 분할은 동적으로 이루어지지 않으며 VM을 다시 시작해야 합니다. 또한 이 설계는 여러 테넌트에 걸쳐 사용량을 측정할 수 있는 GPU 리소스 풀을 구성하는 데 제약이 있습니다. 이는 이 솔루션의 중대한 단점입니다.
네트워크 세분화를 멀티테넌트 AI 팩토리 클러스터에 맞게 조정
AI 팩토리 클러스터가 더 이상 단일 테넌트만 지원하지 않게 되면 어떻게 될까요? 문제는 데이터 센터로 옮겨갑니다. AI 팩토리 클러스터에서는 기본적으로 데이터 센터로 나가는 모든 네트워크 트래픽의 소스 네트워크 주소가 네트워크 요청을 보내는 컨테이너화된 워크로드가 실행 중인 개별 클러스터 노드의 IP 주소로 변환(SNAT)되므로, 실제 소스가 사실상 가려집니다. 이후 트래픽은 해당 노드가 배포된 네트워크 세그먼트에서 발생한 것으로 처리됩니다. 멀티 테넌트 클러스터에서는 이로 인해 테넌트 컨텍스트가 사라지고, 여러 테넌트의 송신 트래픽이 뒤섞여 분류, 보안 적용, 문제 해결 또는 감사가 불가능해집니다.
기본적으로 클러스터 테넌트 컨텍스트는 외부로 나갈 때 손실됩니다.
인그레스 트래픽까지 포함하면 이 문제는 더욱 심각해집니다. 인그레스 트래픽은 이미 세분화된 데이터 센터에서 유입되므로 관리하기가 더 쉬울 수 있지만, 단일 테넌트의 인그레스 트래픽과 이그레스 트래픽을 어떻게 연계할 수 있을까요? 그 해답은 검색 증강 생성(RAG)과 에이전틱 서비스를 중심으로 합니다. 이러한 서비스는 외부 데이터를 확보하고 외부 서비스를 활용하기 위해 빈번하게 통신합니다. 따라서 고객의 문제를 파악하거나 보안 감사를 통과하려면 플랫폼 엔지니어와 NetOps가 협업해야 합니다.
기업에서는 “소프트웨어 정의 네트워킹(SDN) 오버레이 기술을 사용해 하이퍼스케일러처럼 VPC 네트워크를 구축하면 되지 않을까?”라고 물을 수 있습니다. 물론 가능하지만, 기존 데이터 센터 인프라에서 SDN VPC 네트워크를 유지 관리하는 데 비용이 발생하게 됩니다. 레이어 2(예: VxLAN) 세분화가 필요한 경우에는 ToR(Top-of-Rack) 스위칭과 연계한 터널 오케스트레이션과 네트워크 세분화에 맞춘 해당 스위치의 프로비저닝이 문제가 됩니다. 이것이 바로 하이퍼스케일러가 SmartNIC을 선택하고 호스트 간 수준의 오케스트레이션으로 전환해 데이터 센터 네트워크를 빠르지만 지능적이지 않은 상태로 유지한 이유입니다.
대부분의 조직은 이처럼 복잡한 호스트 수준의 오케스트레이션을 직접 운영할 수 있는 네트워크 프로그래밍 인력을 갖추지 못했거나 이를 직접 운영할 의향이 없습니다. 또는 서비스 품질을 보장하는 데 필요한 백본 네트워크 가시성을 포기할 수 없는 경우도 있습니다. 이러한 문제를 해결하기 위해 제안된 레이어 3(예: IP) 라우팅 솔루션은 네트워크 팀이 기본적인 IP 서브넷 테넌시를 제공하고자 여러 라우트 리플렉터를 사용하면서 모든 AI 클러스터 노드를 데이터 센터의 동적 라우팅(BGP) 피어로 구성하도록 만들었습니다. 이 역시 운영자를 매우 복잡한 라우팅 문제와 보안 감사에 노출시키며, 리전 전체의 장애로 이어진 사례도 있습니다.
AI 팩토리를 위한 클러스터 인식 기반 오케스트레이션 네트워크 세분화
AI 팩토리는 다양한 네트워크 기능을 갖추고 프로그래밍이 가능하며 안전하고 지연 시간이 짧은 동시에, 대역폭과 동시 처리 능력 모두 확장 가능한 솔루션을 계획해야 합니다. 레이어 2(예: VLAN, VxLAN) 및 레이어 3(예: 서브넷, IPSEC 인터페이스)의 테넌트 컨텍스트는 클러스터 내부에서 AI 팩토리 네트워크까지 제공되어야 합니다. NetOps에서 관측성 메트릭, 로그 및 디버깅 도구를 사용할 수 있어야 합니다.
전통적으로 이러한 애플리케이션 테넌시 및 가시성 솔루션 중 상당수는 F5 BIG-IP에서 제공됩니다. F5 BIG-IP Container Ingress Services (CIS)는 Kubernetes 서비스를 동적으로 검색하여 가상 서버 형태로 데이터 센터에 노출합니다. 가상 서버는 BIG-IP 관리자가 물리적 서버와 가상 머신을 제공하도록 구성할 때 익숙하게 다뤄 온 구성 객체입니다. BIG-IP는 솔루션에 필요한 요구 사항을 대부분 충족하지만, 세분화를 유지하는 데 필요한 AI 클러스터에서 AI 팩토리 네트워크로의 송신 트래픽은 관리하지 않습니다.
이 문제를 해결하기 위해 당사는 차세대 플랫폼인 BIG-IP Next를 기반으로 멀티테넌트 컴퓨팅 클러스터를 지원하는 솔루션인 F5 BIG-IP Next for Kubernetes를 설계했습니다.
BIG-IP Next for Kubernetes를 통해 NetOps는 클러스터 테넌트를 네트워크 세그먼트에 연결할 수 있습니다.
BIG-IP Next for Kubernetes는 Kubernetes 컨트롤 플레인을 통해 완전히 관리되며, Kubernetes 관리 인증과 선언된 모든 리소스에 대한 RBAC를 지원합니다. 또한 네임스페이스를 통해 Kubernetes 테넌시를 인식하여 인그레스 및 이그레스 트래픽 모두에 필요한 네트워크 세분화를 지원합니다. 이는 AI 팩토리와 같이 오케스트레이션을 우선시하는 아키텍처의 핵심 요소입니다.
BIG-IP Next for Kubernetes는 NetOps가 Kubernetes 네임스페이스와 네트워크 세그먼트 간의 매핑을 간편하게 선언할 수 있도록 지원합니다. AI 팩토리 네트워크와 BIG-IP Next 인스턴스 간의 동적 경로 피어링에는 익숙한 경로 구성 구문이 사용됩니다. NetOps 팀은 클러스터 인그레스 및 이그레스의 실시간 네트워크 스트림 문제를 안전하게 해결할 수 있는 고유한 기능을 활용할 수 있습니다. SecOps 팀은 클러스터 테넌트별 인그레스 및 이그레스 방화벽 액세스 제어 목록(ACL), 분산 서비스 거부(DDoS) 방어 및 IPS 기능을 활용할 수 있습니다.
플랫폼 엔지니어링 팀의 경우, BIG-IP Next for Kubernetes는 데이터 인그레스 및 이그레스 트래픽 처리, Source NAT, 방화벽과 같은 네트워크 기능을 오프로드하여 컴퓨팅 리소스의 부담을 줄여 줍니다. 이를 통해 서비스의 가용성과 효율성을 유지하면서 운영 비용을 절감할 수 있습니다.
BIG-IP Next for Kubernetes는 NetOps, 플랫폼 엔지니어링, DevOps 및 MLOps의 특정 조직 역할에 맞게 설계된 최초의 커뮤니티 인그레스 API인 Kubernetes Gateway API도 지원합니다. BIG-IP Next for Kubernetes는 Gateway API를 통해 일반적인 레이어 4 포트 기반 또는 레이어 7 HTTP(S) 경로 인그레스 서비스를 DevOps/MLOps용 제품군, 즉 TCPRoute, UDPRoute, HTTPRoute, TLSRoute 및 GRPCRoute로 확장하며, 이 모든 기능은 주요 AI 프레임워크에서 동일한 CI/CD 자동화를 통해 제어됩니다.
관리 관점에서 BIG-IP Next for Kubernetes는 Kubernetes API 선언을 통해 NetOps, SecOps, 플랫폼 엔지니어링, DevOps 및 MLOps가 모두 효과적으로 협업할 수 있도록 지원합니다. 네트워크 세분화를 지원하면서 Kubernetes의 관점에서 BIG-IP에 기대하는 모든 기능을 제공합니다.
DPU의 부상
데이터 처리 장치(DPU)는 AI 팩토리에서 폭발적인 주목을 받고 있습니다. AI 팩토리 시리즈의 이전 블로그 게시물에서 정의했듯이, DPU는 하드웨어 가속을 통해 네트워크 회선 속도로 방대한 양의 데이터를 이동하고 처리하도록 설계된 프로그래밍 가능한 프로세서입니다. F5의 제품 혁신과 NVIDIA와의 협력을 통해 NVIDIA의 DOCA API를 사용하여 NVIDIA BlueField-3 DPU에 배포함으로써 네트워크 세분화와 보안 기능을 지원하는 동시에 인그레스 및 이그레스 트래픽의 데이터 흐름을 오프로드하는 BIG-IP Next for Kubernetes를 출시했습니다. 이를 통해 AI 클러스터에 데이터가 원활히 공급되도록 보장하여 AI 팩토리에 대한 투자 효과를 극대화합니다.
F5 기반 AI 팩토리
AI 팩토리에 투자할 때는 인프라가 최적화되고 효율적이며 확장 가능하도록 보장하는 것이 필수적입니다. NVIDIA BlueField-3 DPU에 배포된 F5 BIG-IP Next for Kubernetes는 동적 GPU 및 컴퓨팅 스케줄링에 필요한 네트워크 세분화를 제공하는 동시에, AI 투자 수익을 극대화할 수 있는 고성능 확장성을 지원합니다. 자세히 알아보려면 F5에 문의하여 F5 어카운트 매니저 및 솔루션 엔지니어나 아키텍트와 상담하세요.
AI 팩토리에 대해 더 자세히 알아보고 싶으신가요? AI 팩토리 블로그 시리즈의 다른 글도 살펴보세요:
- AI 팩토리란 무엇인가요? ›
- AI 팩토리를 위한 검색 증강 생성(RAG) ›
- AI 팩토리 데이터 수집을 위한 트래픽 관리 최적화 ›
- 엣지 데이터 소스를 AI 팩토리에 최적으로 연결하기 ›
- 멀티클라우드의 확장성과 유연성으로 AI 팩토리 지원 ›
- AI 팩토리를 위한 NVIDIA BlueField DPU의 성능과 의미 ›
- AI 팩토리를 위한 API 보호: AI 보안을 향한 첫걸음 ›
- AI 팩토리가 만들어 내는 가장 현대적인 최신 앱: AI 앱 ›
작성자 소개
관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 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 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.