컨테이너 네이티브 앱 서비스

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

점점 더 많은 앱 서비스가 클라우드 네이티브 아키텍처의 핵심 구성 요소로 자리 잡고 있습니다. 이러한 흐름은 앱 서비스에 대한 책임이 IT 운영에서 DevOps로 이동하는 이유 중 하나입니다.

당사는 애플리케이션 서비스 현황 연구에서 30개가 넘는 다양한 애플리케이션 서비스를 추적합니다. 이 외에도 더 많은 서비스가 있으며, 매년 목록을 검토하여 제외하거나 추가할 항목을 결정합니다.

2020년에는 여러 애플리케이션 서비스를 더 포괄적인 범주로 통합했습니다. 예를 들어 네트워크 방화벽, 스팸 방지, IPS/IDS, 스팸 완화 기능을 "공통 보안 서비스"로 묶었습니다. 이러한 방식을 택한 데에는 두 가지 이유가 있습니다. 첫째, 6년간의 데이터를 통해 배포율이 매우 유사한 애플리케이션 서비스군이 확인되었기 때문입니다. 둘째, 새롭게 부상하는 애플리케이션 서비스를 위한 여지를 마련하는 동시에, 이미 충분히 인내심을 보여 준 설문 응답자들에게 지나친 부담을 주고 싶지 않았기 때문입니다.

이러한 새로운 애플리케이션 서비스는 거의 전적으로 컨테이너 네이티브 애플리케이션 서비스입니다. 이러한 서비스는 일반적으로—항상 그런 것은 아니지만—클라우드 네이티브 애플리케이션을 제공하는 데 필요한 운영 환경의 일부로 배포됩니다. 인그레스 제어, 서비스 디스커버리, 서비스 메시를 예로 들 수 있습니다. API 게이트웨이 역시 클라우드 네이티브 애플리케이션과 긴밀하게 결합되는 경우가 많지만, 전반적으로 모든 API 기반 애플리케이션에서 사용됩니다.

최신 클라우드 네이티브 앱을 제공하는 데 있어 이들의 중요성이 점점 커지고 있고 배포율도 놀라울 정도로 높아지고 있는 만큼, 지금이야말로 클라우드 네이티브 접근 방식을 이끄는 이 주역들을 좀 더 자세히 살펴볼 좋은 시점인 듯합니다.

인그레스 제어

2020년 애플리케이션 서비스 현황 - 배포: 인그레스 제어

인그레스 제어는 HTTP 요청을 세분화하기 위해 Kubernetes 환경에 도입된 개념입니다. 운영자는 이를 통해 URI를 특정 Kubernetes 서비스에 손쉽게 매핑할 수 있습니다. 따라서 인바운드(인그레스) 요청을 적절한 마이크로서비스 인스턴스로 라우팅할 수 있습니다.

이는 새로운 개념이 아니었습니다. 열성적인 독자라면 제가 HTTP(레이어 7) 라우팅의 장점을 자주 강조해 왔다는 사실을 기억하실 겁니다. 특히 더 효율적인 확장 전략을 지원하도록 설계된 아키텍처 구성 요소로서 말입니다. 기억나지 않거나 이제 막 함께하신 분이라면 다음 기조연설을 통해 내용을 되짚어 보실 수 있습니다: 확장할 수 있다고 생각하시나요?

새로운 점은 "맵"을 관리하는 방식입니다. 인그레스 컨트롤러는 컨테이너 클러스터 내부의 현재 상태에 따라 동적으로 업데이트되어야 합니다. 즉, 인그레스 컨트롤러가 클러스터의 현재 상태를 파악할 수 있어야 합니다. 이를 위해서는 운영 API를 통해 적절한 Kubernetes 구성 요소와 통합해야 합니다.

이러한 통합을 통해 인그레스 제어가 환경과 긴밀하게 연결되고, 결과적으로 애플리케이션 아키텍처에 내재됩니다. 완전한 기능을 갖춘 인그레스 컨트롤러는 클라우드 네이티브 애플리케이션을 확장하고 운영하는 데 필요한 인프라의 일부이므로 본질적으로 "컨테이너 네이티브"입니다.

서비스 디스커버리

2020년 애플리케이션 서비스 현황 - 배포: 서비스 디스커버리

클라우드 네이티브 애플리케이션에서 흥미로운 점은 이를 구성하는 요소들의 수명입니다. 컨테이너 클러스터 내 확장성의 동적인 특성상 "컨테이너"는 끊임없이 생성되고 사라집니다. Sysdig의 최신 데이터에 따르면 이러한 변화는 더욱 빈번해지고 있으며, 컨테이너의 39%는 수명이 1분 미만이고 54%는 5분 미만입니다.

문제는 다른 구성 요소가 해당 컨테이너를 찾을 수 있어야 한다는 점입니다.

이것이 바로 존재 이유입니다. 서비스 디스커버리 구성 요소는 컨테이너 클러스터 내부에서 실행되며 서비스에 대한 "신뢰할 수 있는 정보원" 역할을 합니다. 필요한 주체는 이 구성 요소를 조회하여 특정 서비스에 연결하고 통신하는 방법을 알아낼 수 있습니다. 서비스 디스커버리 구성 요소는 서비스를 실시간으로 추적함으로써 클러스터의 변동성에 대응하고 인그레스 제어와 같은 다른 구성 요소가 제대로 작동할 수 있도록 합니다.

서비스 메시

2020년 애플리케이션 서비스 현황 - 배포: 서비스 메시

서비스 메시는 아마도 가장 논란이 많은 컨테이너 네이티브 애플리케이션 서비스일 것입니다. 개념적 가치 때문이 아니라 구현 방식에 대한 선호가 엇갈리기 때문입니다. 서비스 메시는 컨테이너 클러스터 내의 가시성, 확장성 및 보안 문제를 해결하도록 설계되었습니다. 사이드카 또는 애플리케이션별로 긴밀하게 연결된 프록시 형태로 구현되며, 개발자와 운영자 모두에게 다양한 기능을 제공합니다.

서비스 메시는 컨테이너 클러스터 외부에서는 찾아볼 수 없는 애플리케이션 서비스입니다. 서비스 검색 및 인그레스 제어와 마찬가지로 서비스 메시는 컨테이너 환경과 긴밀하게 통합되어 있습니다. 따라서 서비스 메시 역시 컨테이너 네이티브 애플리케이션 서비스입니다.

컨테이너 네이티브 앱 서비스

우리(업계와 기업으로서의 우리)는 이전까지 애플리케이션 서비스를 이런 방식으로 분류한 적이 없습니다. 물론 보안, 가용성, 성능, 모빌리티, ID와 같은 주요 용도에 따라 분류하기는 합니다. 하지만 이는 광범위한 용도 범주이며, 어느 것도 특정 앱 아키텍처에만 해당하지는 않습니다.

하지만 클라우드 네이티브 아키텍처와의 통합 및 이에 대한 종속성으로 인해 이러한 앱 서비스(그리고 향후 등장할 수 있는 다른 모든 서비스)를 이와 같이 분류해야 할 수도 있습니다. 한쪽(앱 서비스)의 성장은 다른 쪽(앱 아키텍처)의 성장을 명확히 보여 주며, 그 반대도 마찬가지이기 때문입니다. 이는 앱 서비스와 앱이 매우 긴밀하게 얽혀 있어 두 영역의 배포 증가율이 매우 비슷하게 나타나는 독특한 상황입니다.

모바일 iOS 앱과 Android 앱을 구분하는 것과 마찬가지로, 컨테이너화된 환경에서만 작동하도록 설계된 앱 서비스에는 "컨테이너 네이티브"라는 태그를 지정하여 그 밖의 모든 환경에서 작동하는 앱 서비스와 구분하는 것이 유용할 수 있습니다.

어떤 방식으로 분류하든, 이러한 앱 서비스는 이를 기반으로 하는 앱과 함께 확실히 증가하고 있습니다.

작성자 소개

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

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

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