클라우드 네이티브 기술 진화의 기회와 도전

오늘날 클라우드 네이티브(Cloud Native)는 점점 더 인기를 얻고 있으며, CNCF는 클라우드 네이티브를 다음과 같이 정의합니다:

• 현대적이고 동적인 환경, 즉 클라우드 환경을 기반으로 합니다.
• 컨테이너화를 기본 기술로 하며, 서비스 메시(Service Mesh), 불변 인프라(immutable infrastructure), 선언적 API(declarative API) 등을 포함합니다.
• 주요 특징으로는 자동 확장(autoscaling), 관리 용이성(manageability), 관찰 가능성(observability), 자동화(automation), 빈번한 변경(frequent change) 등이 있습니다.

CNCF 2021 설문 조사에 따르면, Kubernetes 커뮤니티에는 매우 많은 수(62,000명 이상)의 기여자가 있습니다. 현재 기술 트렌드에 따라 점점 더 많은 기업들이 클라우드 네이티브에 더 많은 비용을 투자하고, 초기에 트랙에 참여하여 적극적인 클라우드 배포를 진행하고 있습니다. 기업들이 개발 과정에서 클라우드 네이티브를 받아들이는 이유는 무엇이며, 클라우드 네이티브가 그들에게 어떤 의미를 가지는 걸까요?

클라우드 네이티브의 기술적 장점

클라우드 네이티브의 인기는 기술적 수준에서의 장점에서 비롯됩니다. 클라우드 네이티브 기술에는 Docker가 주도하는 컨테이너화와 Kubernetes가 주도하는 컨테이너 오케스트레이션 두 가지 주요 측면이 있습니다.

Docker는 기술 세계에 컨테이너 이미지를 도입하여 컨테이너 이미지를 표준화된 배포 단위로 만들었습니다. 사실 Docker 이전에도 컨테이너화 기술은 이미 존재했습니다. 2008년의 LXC(Linux Containers)를 예로 들 수 있습니다. Docker와 비교했을 때, LXC는 덜 인기가 있는데, 이는 Docker가 컨테이너 이미지를 제공하여 더 표준화되고 더 쉽게 마이그레이션할 수 있기 때문입니다. 또한 Docker는 DockerHub 공개 서비스를 만들어 세계 최대의 컨테이너 이미지 저장소가 되었습니다. 또한 컨테이너화 기술은 CPU, 메모리 등의 리소스 격리뿐만 아니라 네트워크 스택 격리도 가능하게 하여 동일한 머신에 여러 애플리케이션 복사본을 더 쉽게 배포할 수 있습니다.

Kubernetes는 Docker의 급성장으로 인해 인기를 얻었습니다. Kubernetes가 주도하는 컨테이너 오케스트레이션 기술은 장애 자가 복구, 리소스 스케줄링, 서비스 오케스트레이션 등 몇 가지 중요한 기능을 제공합니다. Kubernetes는 내장된 DNS 기반 서비스 발견 메커니즘을 가지고 있으며, 그 스케줄링 아키텍처 덕분에 매우 빠르게 확장되어 서비스 오케스트레이션을 달성할 수 있습니다.

이제 점점 더 많은 기업들이 Kubernetes를 적극적으로 받아들이고 애플리케이션을 변환하여 Kubernetes 배포를 시작하고 있습니다. 우리가 이야기하는 클라우드 네이티브는 사실 Kubernetes를 전제로 한 클라우드 네이티브 기술의 초석입니다.

컨테이너화의 장점

1. 표준화된 배포

컨테이너 이미지는 이제 표준화된 배포 단위가 되었습니다. 컨테이너화 기술을 통해 사용자는 바이너리나 소스 코드 대신 컨테이너 이미지를 통해 직접 배포를 완료할 수 있습니다. 컨테이너 이미지의 패키징 메커니즘에 의존하여 동일한 이미지를 사용하여 서비스를 시작하고 모든 컨테이너 런타임에서 동일한 동작을 생성할 수 있습니다.

2. 이식성과 경량화, 비용 절감

컨테이너화 기술은 Linux 커널의 기능을 통해 일정 수준의 격리를 달성하며, 이는 마이그레이션을 더 쉽게 만듭니다. 또한 컨테이너화 기술은 애플리케이션을 직접 실행할 수 있어 가상화 기술에 비해 기술 구현이 더 가볍고 가상 머신 내의 OS가 필요하지 않습니다.

모든 애플리케이션이 커널을 공유할 수 있어 비용을 절감할 수 있습니다. 그리고 애플리케이션이 클수록 비용 절감 효과가 더 큽니다.

3. 리소스 관리의 편의성

컨테이너를 시작할 때 컨테이너 서비스에 사용할 수 있는 CPU, 메모리 또는 디스크 IO 속성을 설정할 수 있으며, 이를 통해 컨테이너를 통해 애플리케이션 인스턴스를 시작할 때 리소스를 더 잘 계획하고 배포할 수 있습니다.

컨테이너 오케스트레이션의 장점

1. 워크플로우 단순화

Kubernetes에서는 애플리케이션 배포가 Docker보다 더 쉽게 관리됩니다. Kubernetes는 선언적 구성을 사용하기 때문입니다. 예를 들어, 사용자는 구성 파일에서 애플리케이션이 사용할 컨테이너 이미지와 노출할 서비스 포트를 간단히 선언할 수 있으며 추가 관리가 필요하지 않습니다. 선언적 구성에 해당하는 작업은 워크플로우를 크게 단순화합니다.

2. 효율성 향상 및 비용 절감

Kubernetes의 또 다른 유리한 기능은 장애 복구(failover)입니다. Kubernetes에서 노드가 충돌하면 Kubernetes는 자동으로 해당 노드의 애플리케이션을 다른 정상 노드로 스케줄링하고 실행 상태로 만듭니다. 전체 복구 과정은 인간의 개입과 작업이 필요하지 않으므로 운영 수준에서 운영 및 유지보수 효율성을 향상시킬 뿐만 아니라 시간과 비용을 절약합니다.

Docker와 Kubernetes의 등장으로 애플리케이션 배포에 큰 혁신과 기회가 생겼습니다. 컨테이너 이미지는 표준 배포 단위로서 배포 프로세스를 단축하고 CI/CD 시스템과의 통합을 더 쉽게 만듭니다.

애플리케이션 배포가 점점 더 빨라지고 있는 상황에서, 애플리케이션 아키텍처는 클라우드 네이티브 트렌드를 어떻게 따라가고 있을까요?

애플리케이션 아키텍처 진화: 모놀리식, 마이크로서비스에서 서비스 메시까지

애플리케이션 아키텍처 진화의 출발점은 여전히 모놀리식 아키텍처입니다. 애플리케이션의 규모와 요구사항이 증가함에 따라 모놀리식 아키텍처는 더 이상 협업 팀 개발의 요구를 충족시키지 못했고, 따라서 분산 아키텍처가 점차 도입되었습니다.

분산 아키텍처 중 가장 인기 있는 것은 마이크로서비스 아키텍처입니다. 마이크로서비스 아키텍처는 서비스를 여러 모듈로 분할할 수 있으며, 이 모듈들은 서로 통신하고 서비스 등록 및 발견을 완료하며, 흐름 제한 및 서킷 브레이킹과 같은 공통 기능을 달성합니다.

또한 마이크로서비스 아키텍처에는 다양한 패턴이 포함됩니다. 예를 들어, 서비스별 데이터베이스 패턴은 각 마이크로서비스를 개별 데이터베이스로 표현하며, 이는 애플리케이션에 데이터베이스 수준의 영향을 피할 수 있지만 더 많은 데이터베이스 인스턴스를 도입할 수 있습니다.

또 다른 하나는 API 게이트웨이 패턴으로, 클러스터 또는 전체 마이크로서비스 아키텍처의 입구 트래픽을 게이트웨이를 통해 받아들이고 API를 통해 트래픽 분배를 완료합니다. 이는 가장 많이 사용되는 패턴 중 하나이며, Spring Cloud Gateway 또는 Apache APISIX와 같은 게이트웨이 제품을 적용할 수 있습니다.

인기 있는 아키텍처는 점차 클라우드 네이티브 아키텍처로 확장되고 있습니다. 클라우드 네이티브 환경에서 마이크로서비스 아키텍처는 원래의 마이크로서비스를 컨테이너 이미지로 구축하고 Kubernetes로 직접 마이그레이션할 수 있을까요?

이론적으로는 가능해 보이지만, 실제로는 몇 가지 도전 과제가 있습니다. 클라우드 네이티브 마이크로서비스 아키텍처에서 이러한 구성 요소는 컨테이너 내에서 실행될 뿐만 아니라 서비스 등록, 발견 및 구성과 같은 다른 측면도 포함해야 합니다.

마이그레이션 과정에는 비즈니스 수준의 변환과 적응도 포함되며, 인증, 권한 부여, 관찰 가능성 관련 기능(로깅, 모니터링 등)을 K8s로 마이그레이션해야 합니다. 따라서 원래의 물리적 머신 배포에서 K8s 플랫폼으로의 마이그레이션은 생각보다 훨씬 더 복잡합니다.

이 경우, 우리는 Sidecar 모델을 사용하여 위의 시나리오를 추상화하고 단순화할 수 있습니다.

일반적으로 Sidecar 모델은 Sidecar Proxy 형태로 제공되며, 아래 다이어그램의 왼쪽에서 오른쪽으로 일부 공통 기능(예: 인증, 권한 부여, 보안 등)을 Sidecar로 내리는 방식으로 진화합니다. 다이어그램에서 볼 수 있듯이, 이 모델은 여러 구성 요소를 유지해야 하는 것에서 두 가지(애플리케이션 + Sidecar)만 유지하면 되는 것으로 적응되었습니다. 동시에 Sidecar 모델 자체에는 일부 공통 구성 요소가 포함되어 있으므로 비즈니스 측에서 직접 유지할 필요가 없어 마이크로서비스 통신 문제를 쉽게 해결할 수 있습니다.

각 마이크로서비스에 Sidecar를 도입할 때 별도의 구성과 반복적인 작업을 피하기 위해, 이 과정은 컨트롤 플레인을 도입하거나 컨트롤 플레인 주입을 통해 구현할 수 있으며, 이는 현재의 서비스 메시를 점차 형성합니다.

서비스 메시는 일반적으로 두 가지 구성 요소, 즉 컨트롤 플레인 + 데이터 플레인이 필요합니다. 컨트롤 플레인은 구성의 분배와 관련 논리의 실행을 완료하며, 현재 가장 인기 있는 Istio가 있습니다. 데이터 플레인에서는 Apache APISIX와 같은 API 게이트웨이를 선택하여 트래픽 전달 및 서비스 통신을 수행할 수 있습니다. APISIX의 높은 성능과 확장성 덕분에 일부 사용자 정의 요구 사항과 사용자 정의 논리도 수행할 수 있습니다. 다음은 Istio+APISIX를 사용한 서비스 메시 솔루션의 아키텍처를 보여줍니다.

이 솔루션의 장점은 이전의 마이크로서비스 아키텍처에서 클라우드 네이티브 아키텍처로 마이그레이션할 때 서비스 메시 솔루션을 직접 사용하여 비즈니스 측에서 대규모 변경을 피할 수 있다는 것입니다.

클라우드 네이티브의 기술적 도전

이전 글에서는 현재 클라우드 네이티브 트렌드의 기술적 측면에서의 일부 장점을 언급했습니다. 그러나 모든 동전에는 두 가지 면이 있습니다. 일부 새로운 요소와 기회를 가져올 수 있지만, 특정 기술의 참여로 인해 도전 과제도 나타납니다.

컨테이너화와 K8s로 인한 문제

글의 시작 부분에서 언급했듯이, 컨테이너화 기술은 공유 커널을 사용하며, 공유 커널은 경량화를 가져오지만 격리 부족을 초래합니다. 컨테이너 탈출이 발생하면 해당 호스트가 공격받을 수 있습니다. 따라서 이러한 보안 도전 과제를 해결하기 위해 보안 컨테이너와 같은 기술이 도입되었습니다.

또한 컨테이너 이미지는 표준화된 배포 방법을 제공하지만, 공급망 공격과 같은 공격에 취약할 수 있습니다.

마찬가지로, K8s의 도입은 구성 요소 보안에 대한 도전 과제를 가져왔습니다. 구성 요소의 증가는 공격 표면의 증가를 초래하며, 기본 구성 요소 및 종속성 수준과 관련된 추가 취약점도 발생합니다. 인프라 수준에서 전통적인 물리적 또는 가상 머신에서 K8s로 마이그레이션하는 것은 인프라 변환 비용과 클러스터 데이터 백업, 주기적 업그레이드, 인증서 갱신을 수행하기 위한 추가 인력 비용이 필요합니다.

또한 Kubernetes 아키텍처에서 apiserver는 클러스터의 핵심 구성 요소이며 모든 내부 및 외부 트래픽을 처리해야 합니다. 따라서 경계 보안 문제를 피하기 위해 apiserver를 보호하는 방법도 중요한 문제가 됩니다. 예를 들어, Apache APISIX를 사용하여 이를 보호할 수 있습니다.

보안

새로운 기술의 사용은 보안 수준에서 추가적인 주의가 필요합니다:

• 네트워크 보안 수준에서, Network Policy를 통해 트래픽의 세밀한 제어를 구현하거나 mTLS와 같은 다른 연결 암호화 방법을 사용하여 제로 트러스트 네트워크를 형성할 수 있습니다.

• 데이터 보안 수준에서, K8s는 기밀 데이터를 처리하기 위해 secret 리소스를 제공하지만, 실제로는 안전하지 않습니다. secret 리소스의 내용은 Base64로 인코딩되어 있으며, 특히 etcd에 배치된 경우 etcd에 접근할 수 있다면 직접 읽을 수 있습니다.

• 권한 보안 수준에서, RBAC 설정이 합리적이지 않은 경우 공격자가 관련 토큰을 사용하여 apiserver와 통신하여 공격 목적을 달성할 수 있습니다. 이러한 권한 설정은 주로 컨트롤러와 오퍼레이터 시나리오에서 볼 수 있습니다.

관찰 가능성

대부분의 클라우드 네이티브 시나리오에는 로깅, 모니터링 등과 같은 관찰 가능성 관련 작업이 포함됩니다.

K8s에서 다양한 방식으로 로그를 수집하려면 각 K8s 노드에서 직접 집계를 통해 수집해야 합니다. 이러한 방식으로 로그를 수집하려면 애플리케이션이 표준 출력 또는 표준 오류로 내보내야 합니다.

그러나 비즈니스가 관련 변경을 하지 않고 여전히 모든 애플리케이션 로그를 컨테이너 내의 파일에 기록하기로 선택한다면, 각 인스턴스에 로그 수집을 위한 Sidecar가 필요하게 되어 배포 아키텍처가 매우 복잡해집니다.

아키텍처 거버넌스 수준으로 돌아가면, 클라우드 네이티브 환경에서 모니터링 솔루션 선택도 몇 가지 도전 과제를 제기합니다. 솔루션 선택이 잘못되면 사용 비용이 매우 높아지고, 방향이 잘못되면 손실이 클 수 있습니다.

또한 모니터링 수준에서 용량 문제도 포함됩니다. K8s에 애플리케이션을 배포할 때 속도 제한을 구성하여 애플리케이션이 사용할 수 있는 리소스 세부 정보를 제한할 수 있습니다. 그러나 K8s 환경에서는 리소스를 과도하게 판매하거나, 리소스를 과도하게 사용하거나, 이러한 조건으로 인해 메모리가 오버플로우되는 것이 여전히 쉽습니다.

또한 K8s 클러스터에서 전체 클러스터 또는 노드의 리소스가 고갈되는 경우 리소스 축출이 발생할 수 있으며, 이는 노드에서 실행 중인 리소스가 다른 노드로 축출됨을 의미합니다. 클러스터의 리소스가 부족한 경우 노드 폭풍이 쉽게 전체 클러스터를 충돌시킬 수 있습니다.

애플리케이션 진화 및 멀티 클러스터 패턴

애플리케이션 아키텍처 진화 수준에서 핵심 문제는 서비스 발견입니다.

K8s는 기본적으로 DNS 기반 서비스 발견 메커니즘을 제공하지만, 비즈니스에 클라우드 비즈니스와 기존 비즈니스가 공존하는 경우 DNS 서비스 발견 메커니즘을 사용하여 상황을 처리하는 것이 더 복잡해집니다.

동시에 기업이 클라우드 네이티브 기술을 선택하면 비즈니스 규모가 확장됨에 따라 점차 멀티 노드 처리 방향을 고려하게 되며, 이는 멀티 클러스터 문제를 포함하게 됩니다.

예를 들어, 여러 클러스터를 통해 고객에게 더 높은 가용성 모델을 제공하려고 할 때, 이번에는 여러 클러스터 간의 서비스 오케스트레이션, 멀티 클러스터 로드 분배 및 동기화 구성, 멀티 클라우드 및 하이브리드 클라우드 시나리오에서 클러스터를 처리하고 배포하는 전략을 어떻게 처리할지와 같은 도전 과제가 발생합니다.

APISIX가 디지털 전환을 가능하게 하는 방법

Apache APISIX는 Apache 소프트웨어 재단의 클라우드 네이티브 API 게이트웨이로, 동적, 실시간, 고성능이며 로드 밸런싱, 동적 업스트림, 카나리 릴리스, 서킷 브레이킹, 인증, 관찰 가능성 등과 같은 풍부한 트래픽 관리 기능을 제공합니다. Apache APISIX를 사용하여 전통적인 남북 트래픽뿐만 아니라 서비스 간의 동서 트래픽도 처리할 수 있습니다.

현재 위에서 설명한 아키텍처 진화와 애플리케이션 변화를 기반으로 APISIX 기반의 Ingress 컨트롤러와 서비스 메시 솔루션도 파생되어 기업이 더 나은 디지털 전환을 수행할 수 있도록 돕고 있습니다.

APISIX Ingress 솔루션

Apache APISIX Ingress Controller는 주로 Kubernetes의 남북 트래픽을 처리하기 위한 트래픽 게이트웨이 역할을 하는 Kubernetes Ingress Controller 구현입니다.

APISIX Ingress Controller 아키텍처는 APISIX와 유사하게 컨트롤 플레인과 데이터 플레인이 분리된 아키텍처입니다. 이 경우 APISIX는 실제 트래픽 처리를 위한 데이터 플레인으로 사용됩니다.

현재 APISIX Ingress Controller는 다음 세 가지 구성 방법을 지원하며 모든 APISIX 플러그인과 즉시 호환됩니다:

• K8s의 기본 Ingress 리소스를 지원합니다. 이 방법은 APISIX Ingress Controller가 더 높은 수준의 적응성을 가지도록 합니다. 현재까지 APISIX Ingress Controller는 오픈소스 및 영향력 있는 Ingress 컨트롤러 제품 중 가장 많이 지원되는 버전입니다.

• 사용자 정의 리소스를 사용하는 것을 지원합니다. 현재 APISIX Ingress Controller의 사용자 정의 리소스는 APISIX 의미에 따라 설계된 CRD 사양 세트입니다. 사용자 정의 리소스를 사용하면 APISIX와 쉽게 통합할 수 있으며 더 네이티브합니다.

• Gateway API를 지원합니다. Ingress 표준의 다음 세대로, APISIX Ingress Controller는 Gateway API(Beta 단계)를 지원하기 시작했습니다. Gateway API가 진화함에 따라 K8s의 내장 리소스로 직접 될 가능성이 높습니다.

APISIX Ingress Controller는 Ingress NGINX에 비해 다음과 같은 장점이 있습니다:

• 아키텍처 분리. APISIX Ingress에서는 데이터 플레인과 컨트롤 플레인의 아키텍처가 분리되어 있습니다. 트래픽 처리 압력이 높고 용량을 확장하려는 경우 데이터 플레인의 확장만 수행하면 되며, 컨트롤 플레인에 대한 조정이 필요하지 않습니다.

• 높은 확장성과 사용자 정의 플러그인 지원.

• 데이터 플레인으로 선택된 고성능 및 완전 동적 기능. APISIX의 완전 동적 기능 덕분에 APISIX Ingress를 사용하여 비즈니스 트래픽을 최대한 보호할 수 있습니다.

현재 APISIX Ingress Controller는 전 세계 많은 기업에서 사용되고 있으며, 중국 모바일 클라우드 오픈 플랫폼(오픈 API 및 클라우드 IDE 제품), Upyun, Copernicus(유럽의 Eyes on Earth의 일부) 등이 있습니다.

APISIX Ingress Controller는 계속해서 반복적으로 개선되고 있으며, 다음과 같은 방식으로 더 많은 기능을 개선할 계획입니다:

1. Gateway API에 대한 완전한 지원을 통해 더 많은 시나리오 구성을 가능하게 합니다.
2. 외부 서비스 프록시를 지원합니다.
3. 여러 레지스트리에 대한 네이티브 지원을 통해 APISIX Ingress Controller를 더 다목적으로 만듭니다.
4. 새로운 아키텍처 모델을 만들기 위한 아키텍처 업데이트;
5. Argo CD/Flux 및 기타 GitOps 도구와 통합하여 풍부한 생태계를 만듭니다.

APISIX Ingress 솔루션에 관심이 있다면, 커뮤니티 업데이트를 통해 제품 반복 및 커뮤니티 동향을 자유롭게 따라갈 수 있습니다.

APISIX 서비스 메시 솔루션

현재 API 게이트웨이 및 Ingress 솔루션 외에도 APISIX 기반의 서비스 메시 솔루션도 적극적으로 반복되고 있습니다.

APISIX 기반의 서비스 메시 솔루션은 주로 컨트롤 플레인과 데이터 플레인 두 가지 구성 요소로 구성됩니다. 컨트롤 플레인으로는 Istio를 선택했는데, 이는 업계 리더이며 활발한 커뮤니티와 여러 벤더의 지원을 받고 있기 때문입니다. 데이터 측에서는 Envoy를 대체하기 위해 APISIX를 선택하여 APISIX의 높은 성능과 확장성을 발휘할 수 있게 했습니다.

APISIX의 서비스 메시는 여전히 적극적으로 추진 중이며, 다음과 같은 방향으로 후속 반복이 계획되어 있습니다:

• eBPF 가속을 수행하여 전체 효과를 개선합니다.

• 플러그인 기능 통합을 수행하여 서비스 메시 아키텍처 내에서 APISIX Ingress 기능을 더 잘 활용할 수 있도록 합니다.

• 원활한 마이그레이션 도구를 만들어 사용자에게 더 쉬운 도구를 제공하고 프로세스를 단순화합니다.

일반적으로 클라우드 네이티브 시대의 아키텍처와 기술 진화는 우리에게 기회와 도전을 모두 가져다줍니다. Apache APISIX는 클라우드 네이티브 게이트웨이로서 클라우드 네이티브 트렌드에 대한 더 많은 기술적 적응과 통합을 위해 노력해 왔습니다. APISIX를 기반으로 한 다양한 솔루션은 기업 사용자가 디지털 전환을 수행하고 클라우드 네이티브 트랙으로 더 원활하게 전환할 수 있도록 돕기 시작했습니다.