컨테이너 시대의 네트워킹

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

지난 몇 년간 가상화에 이어 컨테이너화까지 확산되면서 단일 하드웨어에서 실행되는 애플리케이션의 밀도가 높아졌고, 우리는 남북 트래픽보다 동서 트래픽을 관리하는 과제에 몰두하게 되었습니다.

데이터 센터의 트래픽 패턴이 아직 다소 생소한 분들을 위해 다시 정리해 보겠습니다. 남북 트래픽은 사용자와 앱 간 또는 클라이언트와 서버 간에 오가거나 데이터 센터 안팎으로 이동하는 트래픽입니다. 동서 트래픽은 서버 간, 앱 간, 서비스 간에 오가거나 단순히 데이터 센터 내부에서 이동하는 트래픽입니다.

남북 방향 트래픽 패턴은 사용자와 앱, 사물의 증가에 영향을 받습니다. 사용자와 앱 간에 필요한 연결이 많을수록 남북 방향 트래픽도 더 많이 발생합니다. 동서 방향 트래픽은 애플리케이션 아키텍처와 인프라 기술의 영향을 받습니다. 가상화 및 컨테이너와 같은 기술을 마이크로서비스 같은 새로운 아키텍처와 결합하면 서로 통신해야 하는 ‘앱’ 또는 ‘서비스’의 수가 기하급수적으로 증가하며, 이러한 통신은 데이터 센터 전반에 걸쳐 이루어집니다.

기본적으로, 애플리케이션 아키텍처와 인프라가 더 분산될수록 동서 방향 트래픽이 더 많이 발생합니다.

이러한 증가세를 더욱 가중하는 것은 애플리케이션을 ‘적정 규모로 조정’하려는 추세입니다. 성장 전망을 기준으로 용량을 계획하는 대신, 현재 필요한 용량에 약간의 여유분을 더해 용량을 산정합니다. 자동 확장과 같은 기술이 성숙하면서 리소스를 더욱 효율적으로 활용할 수 있게 되었고, 유휴 상태로 남는 컴퓨팅 및 네트워크 리소스가 줄어들어 그에 상응하는 가치를 창출하지 못한 채 예산만 소모하는 일을 방지할 수 있습니다. 참고로 이는 프라이빗 클라우드의 장점 중 하나이기도 합니다. 서비스 중심의 프로비저닝 및 관리를 통해 리소스를 실시간으로 사용할 수 있으므로, 그렇지 않으면 비효율적으로 유휴 상태에 머물 리소스를 더 효과적으로 활용할 수 있습니다.

하지만 이야기가 잠시 샜군요. 요점은 아키텍처와 기술의 발전으로 인해 동서 트래픽이 증가하고 있으며, 그 증가 속도가 남북 트래픽의 증가 속도를 능가할 가능성이 높다는 것입니다.

지난 20년 동안 애플리케이션 아키텍처와 기술에 중대한 변화가 일어날 때마다 ‘네트워크’에도 그에 상응하는 변화가 뒤따랐습니다. 트래픽이 어느 방향으로 이동하든 이를 관리하는 것은 네트워크의 역할이기 때문입니다. 동서 방향이든 남북 방향이든 상관없습니다. 가상이든 물리적이든, 트래픽이 현재 위치에서 목적지까지 도달하도록 보장하는 데는 네트워킹이 관여합니다.

이제 마이크로서비스로 인해 애플리케이션이 분해되면서 동서 트래픽이 더욱 크게 증가하고 있는 상황에서, 네트워크는 어떻게 대응해야 할까요? 더 정확히 말하면, 사용자에게 또는 점점 더 많은 경우 다른 앱에 애플리케이션을 제공하는 데 필요한 핵심 기능(가용성, 보안, 최적화)을 제공하기 위해 네트워크 내 서비스는 어떻게 대응해야 할까요?

영향 1: 앱으로의 이동

이 질문에 대한 첫 번째 답은 분명히 애플리케이션 친화형 서비스를 앱에 더 가깝게 배치해야 한다는 것입니다. 이러한 서비스를 남북 방향 패턴의 가장자리에 그대로 둔 채, 주로 동서 방향 패턴으로 서비스를 이용하는 앱에 제공해서는 안 됩니다. 이는 네트워크 리소스를 비효율적으로 사용하는 것이며, 그로 인해 발생하는 라우팅 패턴은 애플리케이션 통신에 지연을 초래합니다. 여기서부터 트래픽 패턴의 ‘트롬보닝’이나 ‘헤어피닝’ 같은 용어가 등장합니다. 이는 한 시스템에서 나와 네트워크를 북쪽 방향으로 통과한 다음 다시 같은 시스템으로 돌아와야 하는 네트워크 경로를 뜻합니다. 이러한 지연은 생산성 저하(‘잠시만 기다려 주세요. 오늘 제 ‘컴퓨터’가 느리네요’)와 소비자의 장바구니 및 웹 앱 이탈 증가라는 실질적인 비즈니스 비용으로 이어집니다. 바로 이것이 우리가 피하려는 상황입니다. 트래픽이 동서 방향으로 흐른다면 서비스도 해당 데이터 경로에 있어야 합니다.

두 번째 영향: 운영 호환성

두 번째 해답은 부하 분산 및 웹 애플리케이션 보안과 같은 서비스를 운영 환경과 호환되는 형태로 배포할 수 있어야 한다는 것입니다. 다시 말해, 새로 등장하는 모든 애플리케이션(또는 마이크로서비스) 앞에 네트워크 하드웨어를 설치할 수는 없습니다. 따라서 이러한 서비스를 제공하는 플랫폼은 새롭게 부상하는 아키텍처 및 기술과 운영 측면에서 호환될 수 있도록 가상화되거나 컨테이너화되어야 합니다. 또한 프로비저닝 및 관리에 DevOps 중심의 접근 방식을 적용할 수 있도록 API와 템플릿을 제공하는 등 프로그래밍 방식으로 제어할 수 있어야 합니다. 애플리케이션 서비스든 네트워크 서비스든 오케스트레이션이 가능해야 합니다. SDN도 인프라 및 애플리케이션 운영 환경에서 널리 사용되는 도구 및 프레임워크와 통합할 수 있다면 이러한 요구 사항을 충족할 수 있습니다.

세 번째 영향: 아키텍처가 핵심이다

세 번째 답은 아키텍처가 그 어느 때보다도 더욱 중요해진다는 것입니다. 네트워킹 서비스를 애플리케이션과 동일한 호스트에 배포할 수 있다고 해서 반드시 그렇게 해야 하는 것은 아닙니다. 해당 서비스의 성격과 다른 서비스(및 서비스 인스턴스)와의 상호 작용 방식에 따라 배치 위치는 신중히 고려해야 할 중요한 문제가 됩니다. 예를 들어, 잘못 설계된 부하 분산은 불필요한 지연을 유발하는 심각한 트래픽 패턴을 초래할 수 있습니다. 이러한 지연은 곧바로 기업의 이익 또는 손실로 이어질 수 있습니다. 이 시나리오에서 서비스가 배포된 호스트에 장애(하드웨어, 소프트웨어, 네트워크, 스토리지)가 발생하면 애플리케이션의 가용성을 보장하는 서비스까지 중단되므로 다운타임이 발생하며, 그 양상도 매우 심각할 수 있습니다. 고도로 분해된 애플리케이션 아키텍처(마이크로서비스)에서는 이러한 애플리케이션에 대한 의존도가 높을 경우 치명적인 결과를 초래할 수 있습니다.

가장 명백하고 쉬운 해답에 이끌려 성능과 가용성에 관한 모범 사례를 간과하지 않도록 신중한 검토(아키텍처 설계)가 필요합니다.

네트워킹은 여전히 아키텍처 설계의 영역이다

네트워킹은 지금까지도, 그리고 앞으로도 아키텍처 차원의 과제입니다. 단순히 폼 팩터에 관한 문제가 아닙니다. 폼 팩터는 필요한 곳에 네트워크 리소스를 더 빠르고 효율적으로 배치하기 위한 수단일 뿐입니다. 핵심은 이러한 리소스를 어디에 배치하느냐, 그리고 그 배치가 스택의 상위 계층에 있는 네트워크 서비스, 애플리케이션 서비스, 애플리케이션 성능, 궁극적으로는 비즈니스의 성공 또는 실패에 어떤 영향을 미치느냐입니다.

컨테이너와 가상화, 클라우드 시대의 네트워킹은 운영만큼이나 아키텍처가 중요합니다.

작성자 소개

Lori Mac Vittie수석 엔지니어 겸 최고 에반젤리스트 | F5

Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.

Lori Mac Vittie의 다른 블로그 게시물