인프라 아키텍처: 컨테이너 네 번째 평면 생성
기존의 네트워크 인프라에는 일반적으로 데이터, 제어, 관리라는 세 가지 아키텍처 측면이 네트워크 인프라와 연관되어 있습니다.
정확한 정의는 인프라의 장르와 구체적인 구현에 따라 다를 수 있지만, 대부분의 네트워크 인프라에서는 원형이 대체로 정확합니다.
- 데이터 플레인
- 현대 용어로 데이터 경로라고도 하는 데이터 플레인은 패킷(데이터)이 전달되는 경로입니다. 데이터 플레인은 패킷을 수신하고 올바른 목적지로 전달하는 역할을 합니다.
- 제어 평면
- 일반적으로 제어 평면은 데이터가 어디로 전달되는지 결정합니다. 라우팅 프로토콜은 제어 평면 기능의 좋은 예이며, 오늘날에는 더욱 역동적으로 전개되는 고차원 의사 결정도 마찬가지입니다. 구체적인 구현 방법은 다양하지만 데이터 플레인이 결정을 위해 제어 플레인에 데이터를 전달하는 것부터 제어 플레인이 데이터를 투명하게 관찰하고 특정 트리거에 따라 조치를 취하는 것까지 다양합니다. 제어 평면은 장치의 상태를 모니터링하고 통계를 수집하는 역할도 맡습니다.
- 관리 평면
- 관리 평면은 세 평면 중 가장 눈에 띄는 평면인데, 제어 평면과 상호 작용하기 때문입니다. 기존 관리 플레인은 CLI(명령줄 인터페이스)를 사용하는 반면, 최신 관리 플레인은 API(애플리케이션 프로그래밍 인터페이스)를 선호합니다. 어떤 방법을 사용하든 관리 평면을 통해 운영자는 제어 평면에서 시행되는 정책을 설정할 수 있습니다. 여기에는 부하 분산 알고리즘 및 IP 주소 및 장치 유형 등의 특성에 따른 허용/거부 정책과 같은 구성 옵션이 포함됩니다.
하지만 운영자의 눈에는 거의 띄지 않지만 그 이면에는 또 다른 종류의 오케스트레이션이 작동하고 있습니다. 이는 인간 운영자의 책임 중 일부를 빼앗는 것일 뿐 경영과는 아무런 관련이 없습니다.
여기서의 차이점은 해당 작업이 배포 이벤트로서가 아니라 실행 중에 환경이 변경되면 자동으로 트리거된다는 것입니다. 하지만 무엇이 바뀌었는지에 대한 정보는 중요하기 때문에 어딘가에서 얻어야 합니다.
기존의 운영 모델에서는 해당 정보가 일반적으로 변경 티켓이나 요청에서 나옵니다. 최신 운영 모델, 특히 컨테이너의 경우 이 정보는 검색 메커니즘을 통해 서비스 레지스트리에서 제공됩니다.
서비스 레지스트리 및 검색
컨테이너 환경의 특성에는 IP 주소가 애플리케이션 환경에 중요하지 않다는 가정이 포함됩니다. 하지만 클라이언트와 애플리케이션 간 경로를 통과하기 위해서는 데이터가 여전히 장치에서 장치로 라우팅되고 전달되어야 하기 때문에 인프라에 중요합니다. 최신 환경에서 이러한 IP 주소는 짧은 기간(컨테이너/서비스의 수명) 동안만 존재하는 경우가 많습니다.
DataDog 의 다음 결과를 고려해 보세요(강조 추가):
오케스트레이터의 급속한 도입( 사실 4 참조 )으로 인해 컨테이너의 수명이 더욱 짧아지고 있는 것으로 보입니다. 컨테이너의 자동 시작 및 중지로 인해 이탈률이 높아지기 때문입니다. 오케스트레이터를 운영하는 조직에서 컨테이너의 일반적인 수명은 약 12시간입니다. 오케스트레이션이 없는 조직에서는 평균 컨테이너의 수명이 6일입니다.
< https://www.datadoghq.com/docker-adoption >에서
운영자가 12시간마다는커녕 6일마다 라우팅 테이블이나 로드 밸런싱 풀을 업데이트해야 한다고 상상해보세요. 그 밖에는 별로 할 일이 없을 겁니다. 컨테이너 클러스터의 변경 사항을 관리하기 위해 수동 모드로 운영해야 하는 시간이 길어질수록 잘못된 구성이 발생할 가능성이 상당하며, 그 가능성도 커집니다.
Consul 과 같은 서비스 레지스트리는 컨테이너 배포의 중요한 구성 요소가 됩니다. 서비스 레지스트리는 인스턴스와 서비스 및 관련 IP 주소를 추적합니다. 이 점에서 이는 "컨테이너 및 서비스를 위한 DNS"에 비유될 수 있습니다.
따라서 서비스 레지스트리는 클러스터 내 컨테이너의 현재 특성을 추적합니다. 검색은 일치하는 인스턴스를 IP 주소와 연결하여 서비스 레지스트리에 연결하는 프로세스입니다(API를 통해 또는 메시지 대기열을 구독하여).
즉, 컨테이너 클러스터 내부의 특정 서비스나 인스턴스로 트래픽을 라우팅해야 하는 인프라의 경우 IP 주소를 검색할 수 있어야 합니다. 컨테이너가 애플리케이션에서 네트워크를 숨기는 만큼, 한 곳에서 다른 곳으로 데이터를 가져오는 데는 여전히 네트워크에 의존합니다.
네 번째 비행기: 관현악법
이를 통해 컨테이너 오케스트레이션 환경과 상호 작용하는 새로운 아키텍처 계층이 인프라에 도입됩니다. 이 계층(오케스트레이션 계층)은 컨테이너 환경과 통합되고 서비스 검색과 같은 기능을 활용하여 서비스 및 인스턴스 검색을 자동화합니다. 즉, 로드 밸런서는 풀 멤버를 자동으로 검색하고 환경의 변화에 따라 지속적으로 업데이트할 수 있습니다. 이를 통해 부하 분산 풀을 수동으로 업데이트하는 작업의 부담이 줄어들고 컨테이너의 수명이 평균 1주일 미만인 경우 이러한 작업은 점점 더 지루해집니다.
이 비행기는 조종사와 상호 작용하기 위한 것이 아닙니다. 구성, 모니터링 및 운영은 여전히 관리 평면을 통해 수행됩니다. 서비스 레지스트리의 위치는 관리 평면을 통해 구성되지만, 오케스트레이션 평면에서 제어 평면에 연결하고 변경 사항을 전달하는 데 사용됩니다.
오케스트레이션 평면은 다음과 같이 정의할 수 있습니다.
- 오케스트레이션 평면은 인프라 아키텍처에서 가장 눈에 띄지 않는 평면 중 하나입니다. 이와의 상호작용은 관리 평면을 통해 이루어지는데, 관리 평면은 주로 적절한 서비스 레지스트리에서 오케스트레이션 평면을 가리키는 역할을 합니다. 그 책임은 컨테이너화된 리소스의 적절한 전달과 가용성을 보장하기 위해 제어 평면의 동적 구성 요소를 업데이트하는 것입니다.
이 평면을 제어 및 데이터 평면과 함께 장치에 통합해야 하는지, 아니면 단순히 관리 평면을 덮은 겉치레에 불과한지(이렇게 하면 다이어그램이 약간 달라지지만 평면과 구성 요소 간의 상호 작용에는 영향을 미치지 않음)에 대한 의문이 여전히 남아 있습니다. 이미 많은 기존 기기가 컨테이너 환경과 통합되고 관리 평면을 통해 변경 사항을 적용하는 확장 기능을 제공함으로써 이 새로운 평면을 지원하고 있습니다. 이는 기존 아키텍처를 리팩토링하여 기능을 현대적 환경으로 확장한 좋은 예입니다. 하지만 궁극적으로 이는 이상적인 해결책이 아닐 수도 있습니다.
왜 중요한가요?
처음에는 인프라를 위한 네 번째 항공기 도입이 중요하지 않은 것처럼 보일 수 있습니다. 결국, 그 기능은 운영자로부터 지루한 작업에 대한 책임을 일부 제거하는 것입니다. 나쁘지 않네요.
나쁘지는 않지만, 정적 구성에서 동적 구성으로의 이러한 전환이 제어 평면의 가장 중요한 기능 중 일부에 영향을 미친다는 것을 이해하는 것이 중요합니다. 서비스 발견의 중요성은 서비스 가용성과 보안이 반드시 필요하다는 것입니다. 실제로 이는 전체 애플리케이션 인프라의 기반이 되는 단일 실패 지점이 됩니다.
서비스 레지스트리는 대부분의 현대 애플리케이션과 동일한 전제, 즉 장애를 처리하도록 구축됩니다. 방금 발견한 IP 주소가 해당 인스턴스로 트래픽을 전달하기 전에 사라지는 상황이 발생할 수 있습니다. 대부분의 인프라는 그 시점에서 재전송이 가능하지만, 이 과정에는 시간이 걸립니다. 디지털 경제에서는 마이크로초가 중요하므로, 타임아웃과 검색 간격과 같은 기존 옵션은 검색 기능에 의존하는 최신 아키텍처에서 차이를 만들어냅니다. 또한, 모니터링의 중요성이 훨씬 더 커졌는데, 가능한 한 빨리 상태와 가용성을 파악하는 능력은 사용자의 만족과 이탈을 가르는 요인이 될 수 있기 때문입니다. 둘 다 현대 조직의 모든 구성원이 알고 있어야 하며, 자체 지표와 기대치에 반영해야 하는 비즈니스 수준의 문제입니다.
인프라에 오케스트레이션 플레인을 구현하는 것과 서비스 레지스트리를 선택하는 것은 사용할 기술을 결정하는 데 중요한 요소가 됩니다. 컨테이너 기반 아키텍처를 통해 제공되는 애플리케이션의 가용성과 성능 모두에 영향을 미치므로 선택 사항을 신중하게 고려하세요.