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

점점 더 많은 앱 서비스가 클라우드 네이티브 아키텍처의 필수 구성 요소가 되고 있습니다. 이것이 부분적으로 우리가 IT 운영에서 DevOps로 앱 서비스에 대한 책임을 옮기는 이유입니다.

우리는 앱 서비스 현황 연구를 통해 30개 이상의 다양한 애플리케이션 서비스를 추적합니다. 그 외에도 많은 것이 있으며, 매년 우리는 목록을 검토하여 무엇을 제거하고 무엇을 추가할지 결정합니다.

2020년에는 여러 앱 서비스를 더 광범위한 카테고리로 통합했습니다. 예를 들어, 네트워크 방화벽, 스팸 방지, IPS/IDS 및 스팸 완화가 "공통 보안 서비스"로 통합되었습니다.  우리가 이런 접근 방식을 선택한 데에는 두 가지 이유가 있습니다. 첫째, 6년간의 데이터는 배포율이 매우 유사한 앱 서비스 그룹을 나타냈기 때문입니다. 두 번째로, 새로운 앱 서비스에 대한 공간을 마련하고 싶었고, 이미 인내심이 강한 응답자 기반을 압도하고 싶지 않았기 때문입니다.

새롭게 등장하는 앱 서비스는 거의 전적으로 컨테이너 네이티브 앱 서비스입니다. 이러한 기능은 일반적으로(항상은 아니지만) 클라우드 기반 애플리케이션을 제공하는 데 필요한 운영 환경 의 일부로 배포됩니다. 유입 제어, 서비스 검색, 서비스 메시에 대해 생각해 보세요. API 게이트웨이 역시 클라우드 기반 애플리케이션과 밀접하게 결합되는 경우가 많지만, 사용 방식은 대체로 모든 API 기반 애플리케이션과 일치합니다.

최신 클라우드 네이티브 앱을 제공하는 데 있어 중요성이 커지고 있으며 배포 속도도 놀라울 정도로 증가하고 있는 만큼, 클라우드 네이티브 접근 방식을 옹호하는 이들에 대해 자세히 알아보는 것이 좋을 것 같습니다.

유입 제어

애플리케이션 서비스 2020 배포 상태: 유입 제어

Ingress 제어는 HTTP 요청을 분할하고 분석하기 위해 Kubernetes 세계에 도입된 개념입니다. 이를 통해 운영자는 URI를 특정 Kubernetes 서비스에 쉽게 매핑할 수 있습니다. 이를 통해 인바운드(수신) 요청을 올바른 마이크로서비스 인스턴스로 라우팅할 수 있습니다.

이는 새로운 개념이 아니었습니다. 열성적인 독자라면 제가 종종 HTTP(7계층) 라우팅의 장점을 칭찬한다는 것을 기억하실 겁니다. 특히, 더 효율적인 확장 전략을 지원하도록 설계된 아키텍처 구성 요소로서 말이죠. 기억이 나지 않거나 방금 합류하신 분이라면 이 기조연설이 좋은 상기가 될 것입니다. 그러면 확장할 수 있다고 생각하시나요?

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

이러한 통합은 진입 제어를 환경에 연결하여 앱 아키텍처에 통합하는 것입니다. 완벽하게 작동하는 인그레스 컨트롤러는 클라우드 네이티브 애플리케이션을 확장하고 운영하는 데 필요한 인프라의 일부이므로 본질적으로 "컨테이너 네이티브"입니다. 

서비스 발견

애플리케이션 서비스 2020 배포 상태: 서비스 발견

클라우드 기반 애플리케이션에 대한 흥미로운 사실은 합성된 부분의 수명입니다. 컨테이너 클러스터 내부의 확장성의 동적 특성은 "컨테이너"가 끊임없이 변화한다는 것을 의미합니다. Sysdig의 최신 데이터 에 따르면 플럭스의 양이 증가하고 있으며, 컨테이너의 39%는 1분 미만으로, 54%는 5분 미만으로 유지되는 것으로 나타났습니다.

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

이것이 서비스 검색 구성 요소의 존재 이유 입니다. 이러한 구성 요소는 컨테이너 클러스터 내부에서 실행되며 서비스에 대한 "권한 있는 소스" 역할을 합니다. 관심 있는 당사자는 이 구성 요소를 쿼리하여 주어진 서비스에 연결하고 통신하는 방법을 알아낼 수 있습니다. 서비스 검색 구성 요소는 서비스를 실시간으로 추적하여 클러스터의 변동성을 해결하고 유입 제어와 같은 다른 구성 요소가 제대로 작동할 수 있도록 합니다. 

서비스 메시

애플리케이션 서비스 2020 배포 상태: 서비스 메시

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

서비스 메시는 컨테이너 클러스터 외부에서 찾을 수 있는 애플리케이션 서비스가 아닙니다. 검색 및 유입 제어와 마찬가지로 서비스 메시는 컨테이너 환경과 긴밀하게 통합됩니다. 따라서 컨테이너 네이티브 앱 서비스이기도 합니다. 

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

우리(업계와 기업)는 이전에 이런 방식으로 애플리케이션 서비스를 분류한 적이 없습니다. 물론, 보안, 가용성, 성능, 이동성, 신원이라는 기본 용도를 기준으로 분류합니다. 하지만 이는 광범위한 사용 범주일 뿐, 앱 아키텍처에만 국한되는 것은 아닙니다.

하지만 클라우드 기반 아키텍처와의 통합과 이에 따른 종속성으로 인해 이러한 앱 서비스(및 향후 생겨날 수 있는 다른 앱 서비스)에 대해서도 이러한 작업이 필요할 수 있습니다. 그 이유는 하나(앱 서비스)의 성장은 다른 하나(앱 아키텍처)의 성장을 명확히 나타내며 그 반대의 경우도 마찬가지이기 때문입니다. 이는 앱 서비스와 앱이 매우 밀접하게 얽혀 있어 둘의 배포 속도가 매우 유사한 독특한 상황입니다. 

모바일 iOS와 Android 앱을 구별하는 것과 비슷한 방식으로, 컨테이너화된 환경에서만 작동하도록 설계된 앱 서비스를 "컨테이너 네이티브"라고 태그하고 다른 모든 곳에서 작동하는 앱 서비스를 "컨테이너 네이티브"라고 태그하는 것이 좋습니다.

어떻게 분류하든, 이러한 기술은 확실히 증가하고 있으며 이에 의존하는 앱도 증가하고 있습니다.