1983년, 제가 아직 Apple ][e에서 하드웨어를 직접 들여다보고 조작하는 법을 배우던 시절, 컴퓨터 및 통신 업계에서 뜻을 같이하는 사람들이 모여 개방형 시스템 상호 연결(OSI)이라는 상세한 명세를 만들었습니다. 실제 인터페이스를 구체화하려는 노력으로 시작된 이 작업은 결국 공통 참조 모델로 발전했고, 이후 IETF 같은 다른 조직이 이를 활용해 인터페이스를 개발할 수 있게 되었습니다. 그리고 이러한 인터페이스는 마침내 IP, TCP, HTTP 등의 표준으로 자리 잡았습니다…
이 참조 모델은 대학에서 컴퓨터 과학 수업을 힘겹게 이수한 우리 대부분이 배운 내용입니다. 우리는 ‘OSI 7계층’을 배웠지만, 실제 환경에서는 구현이 OSI 네트워킹 모델에 깔끔하게 대응되는 경우가 드물다는 사실을 알게 되었습니다.
그럼에도 실제 네트워크와 충분히 잘 대응하기 때문에, 우리는 애초 의도된 대로 이를 참조 모델로 계속 사용하고 있습니다. 대부분은 계층 4가 TCP를, 계층 7이 HTTP를, 계층 2/3이 IP와 이더넷을 가리킨다는 것을 알고 있습니다. 이 용어들은 거의 같은 의미로 통용됩니다.
몇 년 전에는 SDN 및 가상 네트워킹과 관련된 오버레이 프로토콜이 정확히 어느 계층에 속하는지를 두고 논쟁을 벌이기도 했습니다. 엄밀히 말해 계층 2도 아니었고, 그렇다고 정확히 계층 3도 아니었습니다. 그 중간쯤에 해당했습니다.
우리는 대체로 그 문제를 무시한 채 두 계층을 두루뭉술하게 가리키며 그저 ‘오버레이 네트워킹’이라고 불렀습니다. 모두가 그 의미를 이해했고, 클라우드의 정의나 DevOps가 기업 환경에 적합한지 여부처럼 논쟁할 다른 주제도 있었습니다.
컨테이너, 더 정확히 말하면 컨테이너 네트워킹이 등장했습니다. 변동성이 매우 크고 자동화된 컨테이너 오케스트레이션 환경(COE)으로 인해 네트워킹 스택에 더 많은 계층이 필요해졌습니다.
오버레이 네트워킹과 마찬가지로, 우리는 OSI 모델에 새로운 계층을 만들고 싶어 하지 않습니다. 현재로서는 OSI 모델이 표준 참조 모델로 자리 잡았고, 표준을 변경하는 데는 오랜 시간이 걸릴 수 있기 때문입니다. 아주. 아주. 오랜. 시간이요. 하지만 오버레이 네트워킹과 마찬가지로, 이러한 계층은 여전히 네트워크 스택에서 실질적인 인터페이스로 존재합니다. 또한 오버레이 네트워킹과 마찬가지로, 이러한 계층은 COE 네트워킹의 미래에 그만큼 중요하기 때문에 저는 이를 “절반” 계층으로 분류하고자 합니다.
계층 4.5: 서비스 메시
첫 번째 ‘중간 단계’는 레이어 4와 5 사이에 있습니다. 여기서 서비스 메시의 실행과 자동화가 이루어집니다. 간단히 말해, 서비스 메시는 모든 요청을 가로채는 사이드카 방식으로 배포된 프록시로 구성됩니다. 이를 통해 컨테이너 환경 전반의 서비스에 대해 도메인별 라우팅을 수행할 수 있습니다. 서비스 메시는 하위 프로토콜이 존재한다고 전제하고 이를 효과적으로 확장합니다. 이는 그 아래의 모든 네트워크 레이어가 연결과 라우팅이 오직 IP 주소만을 기반으로 한다고 가정하기 때문에 필요합니다. 궁극적으로 컨테이너 환경에서 패킷이 이동하는 방식은 그러하지만, 특정 요청을 어떤 IP 주소와 포트로 보낼지 결정하는 것은 해당 정보를 기반으로 하지 않습니다. 그 결정은 서비스와 애플리케이션의 상태 및 위치와 관련된 다양한 변수를 기반으로 합니다. 본질적으로 요청에 관한 메타정보를 살펴보고 이를 사용해 라우팅 방법을 결정하는 것입니다. 이 메타정보는 각 서비스의 가용성과 확장성을 보장하는 ‘메시’를 구축하는 데 매우 중요합니다.
계층 7.5: 서비스 태그
두 번째 ‘반 단계’는 상단부인 7계층 위에 위치합니다. ‘인간 계층(8계층)’에 관한 농담은 차치하더라도, COE는 실제로 애플리케이션 위에 메타데이터 계층을 배치하여 컨테이너화된 환경에서 확장성이 제대로 작동하도록 이어 주는 ‘접착제’ 역할을 하게 합니다. 이는 COE가 자동 확장을 제공하는 개별 서비스를 식별하는 데 사용되는 애플리케이션 또는 서비스 ‘태그’입니다. 태그가 없으면 애플리케이션을 서로 구분하기가 거의 불가능합니다. OSI 스택의 모든 계층은 IP 주소와 포트 같은 특정 구성 요소로 식별되기 때문입니다. 이러한 구성 요소를 환경 외부에서 공유하는 아키텍처 구현 방식(가상 서버 및 호스트 기반 네트워킹)은 오래전부터 잘 알려져 있었지만, 컨테이너는 환경 내부에서도 동일한 문제를 일으켰습니다. 포트와 IP 주소를 공유하면 요구되는 속도로 서비스를 구분하기가 어렵습니다.
컨테이너화된 환경의 7.5계층에 ‘태그’를 추가하면 네트워킹 서비스(예: 부하 분산 및 라우팅)가 리소스를 고유하게 식별하고 확장성과 가용성을 동시에 보장할 수 있습니다.
새로운 ‘컨테이너 계층’은 환경이 네트워킹 구성 요소로부터 분리될 수 있게 해 주며, 그 과정에서 네트워크 스택의 다른 계층에 긴밀하게 종속되어 있던 기존 기술보다 뛰어난 이식성을 보장합니다. 컨테이너화된 환경은 ‘중간 계층’에서 작동하면서 기존 계층의 존재를 전제로 하므로, 특정 네트워킹 방식이나 아키텍처에 종속되지 않으며 개발 환경과 테스트 환경, 테스트 환경과 운영 환경, 온프레미스와 클라우드 사이를 모두 손쉽게 이동할 수 있습니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 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 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.