컨테이너 시대의 네트워킹

지난 몇 년 동안 가상화와 컨테이너화가 주어진 하드웨어에서 앱의 밀도를 증가시키면서 우리는 남북 트래픽 대신 동서 트래픽을 관리하는 과제에 집착하게 되었습니다.

데이터 센터 트래픽 패턴에 대해 아직 잘 모르는 분들을 위해 요약해 보겠습니다. 남북 방향 은 사용자-앱 또는 클라이언트-서버 또는 데이터 센터 내부-외부 방향입니다. 동서 방향은 서버 간, 앱 간, 서비스 간 또는 단순히 데이터 센터 내에서의 방향입니다.

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

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

이러한 증가에 더해 앱의 "적정 크기 조정" 추세도 있습니다. 용량 계획은 성장 예측에 따른 것이 아니라, 현재 필요한 것에 조금 더 많은 것을 더한 것에 따라 결정됩니다. 자동 확장과 같은 기술이 발전함에 따라 리소스를 보다 효율적으로 사용할 수 있게 되었고, 유휴 상태로 방치되는 컴퓨팅 및 네트워크 리소스가 줄어들어 적절한 가치를 창출하지 못하고 예산만 소모하게 되었습니다 . 이게 바로 프라이빗 클라우드의 이점 중 하나입니다. 즉, 낭비적으로 유휴 상태로 남아 있을 리소스를 더 잘 활용할 수 있는 기능입니다. 즉, 리소스의 실시간 사용을 가능하게 하는 서비스 지향적 프로비저닝 및 관리를 제공합니다.

하지만 제가 곁길로 가네요. 요점은 동서 방향 교통량이 건축과 기술 덕분에 남북 방향 교통량 증가 속도를 능가할 가능성이 크다는 것입니다.

이제 지난 20년 동안 애플리케이션 아키텍처와 기술의 모든 중요한 변화는 "네트워크"에서 동일한 반응을 가져왔습니다. 그 이유는 네트워크가 방향에 관계없이 트래픽을 관리해야 하기 때문입니다. 동서, 남북은 중요하지 않습니다. 가상이든 물리적이든, 트래픽이 있는 곳에서 필요한 곳으로 이동하도록 보장하는 데는 네트워킹이 필요합니다.

이제 마이크로서비스로 인해 애플리케이션이 분해되면서 동서 트래픽이 더욱 크게 증가하는 상황에서 네트워크는 어떻게 대응해야 할지가 문제가 됩니다. 더 정확하게 말하면, 앱을 사용자 또는 점점 더 다른 앱에 전달하는 데 필요한 중요 기능(가용성, 보안, 최적화)을 제공하기 위해 네트워크의 서비스는 어떻게 대응해야 할까요?

영향 1: 앱으로 이동하기 

이 질문에 대한 첫 번째 답은 애플리케이션-아핀 서비스가 앱에 더 가까이 이동해야 한다는 것입니다. 그들은 북쪽-남쪽 패턴의 가장자리에 머물러서 주로 동쪽-서쪽 패턴으로 소비하는 앱에 서비스를 제공할 수 없습니다. 이는 네트워크 리소스를 비효율적으로 사용하며, 라우팅 패턴의 영향으로 인해 애플리케이션 통신에 지연이 발생합니다. 여기서 우리는 네트워크를 통과하는 경로를 설명하는 교통 패턴의 "트롬보닝" 및 "헤어피닝"과 같은 용어를 듣기 시작합니다. 이는 기계를 떠나 네트워크를 북쪽으로 가로지른 다음 동일한 기계로 돌아와야 합니다. 이러한 지연은 생산성 감소('잠깐만요, 오늘 제 '컴퓨터'가 느려요')와 소비자가 쇼핑 카트와 웹 앱을 포기하는 빈도 증가라는 측면에서 실제적인 비즈니스 비용으로 이어집니다. 우리는 이런 상황을 피하고자 합니다. 트래픽이 동서로 이동하는 경우, 서비스는 해당 데이터 경로에 있어야 합니다.

영향 2: 작동 호환성 

두 번째 답변은 로드 밸런싱과 웹 앱 보안과 같은 서비스는 운영상 호환되는 형식으로 배포 가능해야 한다는 것입니다. 다시 말해, 우리는 나타나는 모든 앱(또는 마이크로서비스) 앞에 네트워크 하드웨어를 놓지 않을 것입니다. 따라서 이러한 서비스가 제공되는 플랫폼은 새로운 아키텍처 및 기술과 운영상 호환되도록 가상화되거나 컨테이너화되어야 합니다. 또한 DevOps 중심 접근 방식으로 프로비저닝 및 관리를 수행할 수 있는 API와 템플릿을 제공하는 프로그래밍 방식이어야 합니다. 애플리케이션이든 네트워크이든 서비스는 조율 가능해야 합니다. SDN은 인프라와 애플리케이션 운영 환경을 지배하는 도구와 프레임워크와 통합할 수 있다면 이러한 요구 사항도 해결할 수 있습니다. 

영향 3: 건축은 중요하다

세 번째 답변은 건축이 그 어느 때보다도 더욱 중요해졌다는 것입니다. 네트워크 서비스를 해당 애플리케이션과 동일한 호스트에 배포할 수 있다고 해서 반드시 그곳에 배포해야 한다는 것은 아닙니다. 서비스의 종류와 다른 서비스(또는 서비스 인스턴스)와의 상호작용에 따라 배치는 심각하게 고려해야 할 문제입니다. 예를 들어, 로드 밸런싱이 제대로 설계되지 않으면 불필요한 지연이 발생하는 끔찍한 트래픽 패턴이 발생할 수 있습니다. 이러한 지연은 비즈니스 이익 또는 손실로 직접 전환될 수 있습니다 . 이 시나리오에서 서비스가 배포된 호스트에서 하드웨어, 소프트웨어, 네트워크, 스토리지 등의 장애가 발생하면 앱의 가용성을 보장하는 서비스도 다운되어 다운타임(심지어 보기 흉한 다운타임)이 발생합니다. 고도로 분해된 애플리케이션 아키텍처(마이크로서비스)에서 이러한 앱에 대한 종속성이 높으면 치명적일 수 있습니다.

성능과 가용성에 대한 모범 사례가 가장 분명하고(그리고 가장 쉬운) 답의 유혹에 의해 무시되지 않도록 하려면 신중한 고려(아키텍처)가 필요합니다.

네트워킹은 여전히 건축의 연습입니다.

네트워킹은 건축적 노력이었고 앞으로도 그럴 것입니다. 이는 단순히 폼 팩터에 대한 것이 아니라 네트워크 리소스를 필요한 곳에 더 빠르고 효율적으로 제공하는 방법입니다. 이는 해당 리소스의 배치와 그것이 스택의 상류에 있는 모든 것, 즉 네트워크 서비스, 앱 서비스, 앱 성능, 그리고 궁극적으로 비즈니스 성공 또는 실패에 어떤 영향을 미치는지에 대한 것입니다.

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