새로운 OSI 네트워크 스택: 컨테이너 및 반층

1983년으로 돌아가서, 제가 아직 Apple ][e의 하드웨어를 들여다보고 찔러보는 법을 배우던 시절, 컴퓨터 및 통신 산업에 종사하는 비슷한 생각을 가진 사람들로 구성된 그룹이 모여서 OSI(Open Systems Interconnection)라는 자세한 사양을 만들었습니다. 실제 인터페이스를 구체화하려는 노력으로 시작된 것이 결국 IETF 등 다른 단체에서 인터페이스를 개발하는 데 사용할 수 있는 공통 참조 모델로 바뀌었습니다. 이러한 인터페이스는 결국 표준이 될 수 있었고 실제로 표준이 되었습니다. IP, TCP, HTTP 등 

이 참조 모델은 대학에서 컴퓨터 과학 수업을 수강한 대부분의 사람들에게 가르쳐졌습니다. 우리는 "OSI의 7개 계층"에 대해 배웠지만, 현실 세계에서 실제 구현이 OSI 네트워킹 모델에 정확하게 매핑되는 경우가 거의 없다는 것을 알게 되었습니다.

그래도 이는 본래 의도했던 대로 참조 모델로 계속 사용할 만큼 충분히 잘 매핑되어 있습니다. 우리 대부분은 4계층이 TCP를, 7계층이 HTTP를, 2/3계층이 IP와 이더넷을 의미한다고 알고 있습니다. 그 둘은 거의 호환이 가능합니다.

몇 년 전만 해도 우리는 SDN과 가상 네트워킹에 관련된 오버레이 프로토콜이 정확히 어디에 속하는지에 대한 논쟁을 벌인 적이 있었습니다. 그것들은 실제로 2계층은 아니었지만, 엄밀히 말해서 3계층도 아니었습니다. 그들은 일종의 중간에 있었습니다.

우리는 대부분 그것을 무시할 수 있었고, 두 계층을 막연히 무시하고 단순히 "오버레이 네트워킹"이라고 불렀습니다. 모두가 우리의 의미를 이해했고, 클라우드의 정의와 DevOps가 기업에 적합한지 여부 등 다른 주제에 대해서도 논쟁이 있었습니다.

컨테이너, 혹은 더 정확히 말하면 컨테이너 네트워킹이 등장했습니다. 컨테이너 오케스트레이션 환경(COE)의 매우 불안정하고 자동화된 환경으로 인해 네트워킹 스택에 더 많은 계층이 필요하게 되었습니다.

오버레이 네트워킹과 마찬가지로, 우리는 OSI 모델에 새로운 계층을 만드는 것을 꺼립니다. 왜냐하면, 그것은 아직 표준 참조일 뿐이고, 표준을 변경하는 데는 오랜 시간이 걸릴 수 있기 때문입니다. 을 따라. 긴. 시간. 하지만 오버레이 네트워킹과 마찬가지로 이러한 계층은 여전히 네트워크 스택에서 실존적 인터페이스로 존재합니다. 오버레이 네트워킹과 마찬가지로 저는 COE의 네트워킹 미래에 매우 중요하기 때문에 "절반" 계층을 제공하는 경향이 있습니다.

레이어 4.5: 서비스 메시

첫 번째 '반 단계'는 4번째와 5번째 층 사이에 있습니다. 여기에서 서비스 메시 실행과 자동화가 중요해집니다. 간단히 말해서, 서비스 메시는 모든 요청을 가로채는 사이드카 배포 프록시로 구축됩니다. 이를 통해 컨테이너 환경 전반의 서비스에 대한 도메인별 라우팅을 실행할 수 있습니다. 하위 프로토콜이 존재한다고 가정하고 이를 효과적으로 확장합니다. 이는 그 아래의 모든 네트워크 계층이 연결성과 라우팅이 IP 주소에만 기반한다고 가정하기 때문에 필요합니다. 패킷이 컨테이너 환경에서 이동하는 궁극적인 방법은 바로 이것이지만, 주어진 요청을 보낼 IP 주소 와 포트를 결정하는 것은 그 정보에 기반하지 않습니다. 이는 서비스 및 애플리케이션 상태와 위치와 관련된 다양한 변수를 기반으로 합니다. 기본적으로 우리는 요청에 대한 메타 정보를 살펴보고 이를 사용하여 요청을 어떻게 라우팅할지 결정합니다. 이 메타 정보는 각 서비스의 가용성과 규모를 보장하는 "메시"를 설정하는 데 중요합니다. 

레이어 7.5: 서비스 태그

두 번째 '반음계'는 7번째 층 위, 맨 위에 위치합니다. "인간 계층(8계층)"에 대한 모든 농담은 제쳐두고, COE는 실제로 컨테이너화된 환경에서 확장성을 가능하게 하는 '접착제'를 제공하는 애플리케이션 위에 메타데이터 계층을 배치합니다. 이는 COE가 자동화된 확장을 제공하는 개별 서비스를 식별하는 데 사용되는 애플리케이션 또는 서비스 "태그"입니다. 태그가 없으면 하나의 앱을 다른 앱과 구별하는 것이 거의 불가능합니다. 이는 OSI 스택의 모든 계층이 IP 주소와 포트와 같은 특정 구조로 식별 가능하기 때문입니다. 우리는 환경 외부 의 구성 요소(가상 서버 및 호스트 기반 네트워킹)를 공유하여 아키텍처를 구현하는 방식을 오랫동안 알고 있었지만, 컨테이너는 환경 내부에서 동일한 문제를 일으켰습니다. 포트와 IP 주소를 공유하면 필요한 속도에서 서비스를 구별하기 어렵습니다.

컨테이너화된 환경에서 7.5계층에 '태그'를 추가하면 네트워크 서비스(로드 밸런싱 및 라우팅 등)에서 리소스를 고유하게 식별하고 동시에 확장성과 가용성을 보장할 수 있습니다.

새로운 "컨테이너 계층"은 환경이 네트워킹 구성 요소에서 분리될 수 있도록 하며, 이 과정에서 네트워크 스택의 다른 계층에 긴밀하게 연결되어 있던 이전 기술보다 더 큰 이동성을 보장합니다. "절반 계층"에서 운영하고 기존 계층의 존재를 가정함으로써 컨테이너화된 환경은 특정 네트워킹 방식이나 아키텍처로부터 독립성을 얻고 개발과 테스트, 테스트와 프로덕션, 온프레미스와 클라우드 간에 동등하게 쉽게 이동할 수 있습니다.