Kubernetes에서 클라우드 네이티브로 전환하기 위한 3단계 가이드

오늘날 많은 기업이 클라우드 네이티브(Cloud-Native) 기반 환경으로 전환하거나 적응형 애플리케이션으로 전환해 나가고 있습니다. “적응형”이란 앱이 요구 수준에 따라 자동으로 확장, 문제 감지 및 완화, 장애 복구 등을 통해 운영 환경의 변화에 대응한다는 것을 의미합니다. 또한 트래픽 패턴이 변화하고 기본 인프라가 개발되고 사이버 공격이 점점 더 많고 복잡해짐에 따라 비즈니스 및 기술 환경의 변화하는 요구 사항을 충족하기 위해 앱을 업데이트하는 것이 상당히 쉽다는 것을 의미합니다. 하지만 적응형 앱으로의 전환은 하룻밤 사이에 이루어지지 않습니다.

대부분의 경우 적응형 앱을 MSA(microservices architectures)에 의해 구동 되고 복잡한 세계인 elastic cloud 환경 내의 컨테이너에서 실행되는 것으로 생각합니다. 노드, 포트 및 컨테이너가 위아래로 회전하면서 모든 변경 사항을 수동으로 처리해야 하는 경우 이를 따라잡을 수 없습니다. 혼란을 막으려면 특히 컨테이너 오케스트레이션이 필요합니다.

적응형 앱은 최소한 네 가지 요소에 걸쳐 환경 변화에 대응해야 합니다.

  1. Performance
  2. Scalability (or flexibility)
  3. Observability
  4. Security

그룹 단위로 적응형 애플리케이션을 원활하게 orchestrate 및 관리하여 정기적으로 변화하는 상황에 신속하게 자동 대응할 수 있도록 지원하는 방법은 무엇입니까? 자, Kubernetes에 대해 말하지 않고는 orchestration 대해 이야기하기 어렵습니다.

Kubernetes는 CNCF(Cloud Native Computing Foundation)에서 가장 인기 있는 프로젝트 중 하나 입니다. 특히 다양한 특성을 가지고 있는 노드들을 지속적으로 조정해야 하는 기업에게 많은 기능과 필요한 유연성을 제공하므로 작업을 위한 최적의 도구이며 2015년 7월에 출시 이후 완전한 솔루션으로 만들기 위해 계속해서 업데이트되고 커뮤니티 생태계가 생겨나고 있습니다. 그러나 강력한 도구인 만큼 복잡하고 어려우며 모든 문제를 해결하지는 못할 수 있습니다.

목차

1. 클라우드 네이티브 항해 시작
2. Rehost (Lift and Shift)
3. 클라우드 네이티브 재구성
3-1. NGINX Unit을 사용한 오픈 소스 리팩토링
4. 클라우드 네이티브 재설계
4-1. NGINX Ingress Controller 및 NGINX Kubernetes Gateway를 사용한 재설계
5. 클라우드 네이티브 그리고 오픈 소스

1. 클라우드 네이티브 항해 시작

새 코드 베이스로 시작하지 않는 한 이미 운영 중인 응용 프로그램이 있을 수 있습니다. 모든 애플리케이션이 클라우드 네이티브일 필요는 없으며, 특히 최신 애플리케이션에 대한 요구 사항을 이미 충족하고 있는 경우에는 더욱 그렇습니다. 또한 Kubernetes에 다양한 기능이 많다고 해서 모든 곳에서 사용해야 하는 것은 아닙니다. 그러나 마이크로서비스와 컨테이너로 이동하는 것은 확실히 유리할 수 있습니다.

그렇다면 클라우드 네티이브(Cloud-Native) 환경으로의 전환을 어떻게 시작해야 할까요?

너무 많은 리소스가 있으므로 Kubernetes orchestration을 사용하여 모놀리식에서 클라우드 네이티브로 전환하는 가장 간단한 방법을 분석 하려고 합니다. 지난 2010년 Gartner는 클라우드 마이그레이션에 대한 5가지 접근 방식(rehost, refactor, revise, rebuild, replace)을 요약했습니다. Microsoft는 Gartner의 사고 리더십을 바탕으로 이른바 클라우드 합리화를 위한 프레임워크를 구축했습니다.(이 과정에서 세 번째 접근 방식을 재구성 하는 것으로 변경). 그러나 접근 방식/프레임워크 구성 요소를 개발자와 운영, 코드 및 프로세스에 영향을 미치는 단계, 그리고 이제 막 시작했거나 이미 시작한 단계라고 생각할 수도 있습니다. 여기서는 rehost, refactor, rearchitect의 세가지 단계에 초점을 맞추고 있습니다.

2. Rehost (Lift and Shift)

클라우드 네이티브(Cloud-Native) 전환은 기존 모놀리식에서 시작되는 경우가 많습니다. 하지만 한번에 모놀리식에서 Cloud-Native로 전환하고 싶지는 않을 것입니다. 그렇다면 인프라를 다시 호스팅 또는 캡슐화하는 것부터 시작하는 것이 좋습니다.

우리는 클라우드 환경에서 마이크로서비스의 훌륭함에 대해 자주 듣지만 여전히 모놀리식이 많이 있습니다. 왜냐하면 아직 문제 없이 잘 작동하고 있기 때문입니다. 그러나 모놀리식 기존 3계층 아키텍처가 여전히 사용 중이라 하더라도 이를 사용하는 애플리케이션에서는 확장 문제가 발생하거나 오늘날의 사용자와 연결하기 위해 하이브리드 모델을 구축해야 할 가능성이 높습니다.

이 첫 번째, rehosting 단계는 lift and shift라고도 합니다. 즉, 기존 애플리케이션의 복사본을 만들어 적절한 Cloud 플랫폼에 “붙여넣기”하면 됩니다. 기본적으로 응용프로그램에 미치는 영향을 최소화하면서 “다른 사용자의 컴퓨터”로 이동합니다.

이는 클라우드에서 앱 관리를 시작하고 처리해야 할 문제를 식별하는 데 도움이 되는 가상 머신(VM) 환경에서 자주 발생합니다. lifting and shifting만으로 적응형 앱의 많은 이점을 활용할 수 없습니다. 단 한 가지 기능만 병목 현상이 발생하더라도 전체 앱을 복제하여 확장할 수 있기 때문입니다. 클라우드 네이티브의 세계로 들어가면서 코드를 동적으로 실행하는 웹 앱과 정적 자산에 적용되는 낯선 문제에 직면하게 됩니다.

아직 컨테이너 및 orchestration 수준보다 높지만 계속 진행 중이며 다음 단계를 위한 준비가 되어 있습니다.

3. 클라우드 네이티브 재구성

다음 단계에서는 앱을 조각(일반적으로 모듈로 구현)으로 refactor하여 각각 단일 기능(또는 밀접하게 관련된 기능 세트)을 수행합니다. 동시에 새로운 App 기능을 추가하거나 일부 기능을 특정 Cloud 서비스(예: 데이터베이스 또는 messaging 서비스)에 연결할 수 있습니다. 또한 인프라를 구성하는 일부 VM을 그대로 유지하면서 컨테이너로 이동할 가능성이 높으며, orchestration의 중요성도 높아지고 있습니다.

이 과정에서 단순히 rehost 때보다 더 많은 움직이는 조각을 얻을 수 있습니다. refactored services는 컨테이너에 포함되어 있기 때문에 느슨하게 결합된 통신 경로 및 API 호출을 유지하면서 확장하거나 축소할 수 있습니다. 이제 Kubernetes를 데려와 새로운 컨테이너를 적절한 수준으로 orchestrate해야 합니다.

물론, Kubernetes에서 발생하는 복잡성을 감안할 때 고려해야 할 몇 가지 문제가 있습니다. 가장 큰 것 중 하나는 Kubernetes 클러스터(서비스로 표시)에서 호스팅되는 애플리케이션에 대한 HTTP load balancing을 구성하고 해당 서비스를 클러스터 외부의 클라이언트에 전달할 수 있게 해주는 Kubernetes resource인 Ingress입니다. NGINX Ingress Controller를 사용하여 콘텐츠 기반 라우팅 및 TLS/SSL 종료의 표준 Ingress 기능을 지원할 수 있습니다. NGINX Ingress Controller 또한 WebSocket, gRPC, TCP 및 UDP 애플리케이션을 위한 load balancing과 같은 몇 가지 추가 기능으로 표준 Ingress resource를 확장합니다.

초기 refactoring 작업에 따라 새로운 클라우드 네이티브(Cloud‑Native) 앱은 다양한 방식으로 통신할 수 있는 유연성이 필요할 수 있습니다. 그리고 NGINX Ingress Controller 자체가 Kubernetes pod에서 실행되기 때문에 다음 단계인 재설계에 대한 준비가 잘 되어 있습니다.

3-1. NGINX Unit을 사용한 오픈 소스 리팩토링

NGINX Unit과 같은 오픈 소스 도구를 사용하면 API, 요청(Request) 라우팅 및 보안 기능을 통한 동적 재구성을 통해 리팩토링을 보다 쉽게 수행할 수 있습니다. 차세대 기술인 NGINX Unit은 또한 모놀리식을 Cloud-Native 전환하여 현대화할 수 있도록 지원합니다. NGINX Unit의 RESTful 구성 방법은 균일한 인터페이스를 제공하고 클라이언트 문제와 서버 문제를 분리합니다. 3계층 모놀리식이 이미 그렇게 하려고 노력하고 있을 수 있지만 NGINX Unit은 클라우드 네이티브(Cloud-Native)에 접근하기 쉽게 만들고 운영을 더 쉽게 만듭니다. 이렇게 하면 통신 회선이 명확해지고 refactoring 후에 필요한 추가 단계를 식별하는 데 도움이 됩니다.

refactoring 단계는 종종 애플리케이션 제어에 걸림돌이 된다. NGINX Unit은 이미 컨테이너 친화적인 기술이기 때문에 앱을 refactoring할 때 애플리케이션 제어 기능(동적 재구성 포함)을 통해 모놀리식에서 분리된 서비스를 원활하게 추가할 수 있습니다. NGINX Unit은 고성능 HTTP, 프록시, Backend 및 진정한 종단(End to End) 간 SSL/TLS를 포함하여 Layer 4에서 사용자 공간에 이르기까지 애플리케이션 제어를 제공합니다. 또한 NGINX Unit이 여러 프로그램 언어의 실행를 지원하고 적절한 시기에 올바른 언어를 사용할 수 있다는 사실은 초기 refactoring 작업에서 특히 중요합니다.

4. 클라우드 네이티브 재설계

초기 애플리케이션에서 서비스를 추가 및 교체하기 위해 rearchitect을 수행한 후에는 마이크로서비스 아키텍처(MSA)를 위한 안정적이고 합리적인 디자인으로 다시 설계해야 합니다. Duct 테이프와 와이어는 한동안 작동할 수 있지만, 생산 시스템에서는 안정성이 매우 중요 합니다.

우리가 구상하는 대로 rearchitecting할 때, 모든 기능이 Kubernetes가 구동하는 컨테이너에 있는 마이크로서비스(또는 serverless 기능)에 의해 수행되도록 초기 애플리케이션을 개발 합니다. 여기서, 의사소통이 핵심입니다. 각 마이크로서비스는 필요한 만큼 작으며, 종종 독립적인 팀에 의해 개발된다.

앱이 느슨하게 결합된 통신이 포함된 개별적이고 독립적인 마이크로서비스로 구성될 때 새로운 문제와 심지어 일부 혼란이 불가피하게 발생합니다. 외부 Ingress 문제를 기억하십니까? 이제 Ingress를 필요로 하는 복잡한 서비스 모음을 위해 협업해야 하는 팀이 늘어나고 있습니다.

4-1. NGINX Ingress Controller 및 NGINX Kubernetes Gateway를 사용한 재설계

NGINX Ingress Controller는 표준 Kubernetes Ingress resource에 의존하는 것이 아니라 자체 CRD(사용자 지정 resource 정의)를 지원하여 Kubernetes API의 역할 기반 액세스 제어(RBAC) 기능을 사용한 개체 위임과 같은 광범위한 사용 사례로 NGINX의 성능을 확장합니다.

Kubernetes Gateway API 사양을 구현하는 Controller를 살펴보는 것도 좋습니다. Kubernetes Gateway를 사용하면 인프라 관리를 여러 팀에 위임할 수 있으며 배포 및 관리를 간소화할 수 있습니다. 이러한 Gateway는 Ingress Controller를 대체하지 않지만 사양이 성숙해짐에 따라 많이 선택하는 Solution이 될 수 있습니다. NGINX의 Kubernetes Gateway API 구현인 NGINX Kubernetes Gateway는 Data Plane에서 NGINX 기술을 사용합니다.

Kubernetes Gateway API 사양에 따라, NGINX Kubernetes Gateway는 여러 팀이 앱을 개발하고 제공할 때 입력 구성의 다양한 측면을 제어할 수 있도록 지원합니다. 클라우드 네이티브(Cloud-Native) 환경에서는 개발자와 SRE(사이트 안정성 엔지니어)가 지속적으로 협업 하는 것이 일반적이며, Gateway를 통해 다양한 제어 권한을 해당 팀에 더 쉽게 위임할 수 있습니다. 또한 이 Gateway는 이전에는 사용자 지정 Kubernetes 주석 및 CRD의 일부였던 핵심 기능을 통합하여 클라우드 네이티브(Cloud-Native )환경을 보다 간편하게 구축하고 있도록 지원합니다.

5. 클라우드 네이티브 그리고 오픈 소스

컨테이너와 Kubernetes의 힘으로 구동 되는 monolith에서 클라우드 네이티브(Cloud-Native)로 이동하기 위한 간단한 단계가 있습니다. NGINX Unit과 Kubernetes의 기능을 결합하는 새로운 프레임워크를 구축하면서 초기 앱을 유지하는 것과 같이 사용 사례에 적합한 다른 많은 접근 방식을 찾을 수 있습니다. 또는 hybrid model을 구축할 수도 있습니다. Kubernetes 세계에서 NGINX의 참조 모델을 보고 싶다면 오픈 소스 MARA(Modern App Reference Architecture) 프로젝트를 확인하십시오.

클라우드 네티이브(Cloud-Native)에 대한 어떤 접근 방식을 선택하든 Production 시스템에 원하는 성능과 안정성을 얻으려면 항상 Kubernetes 클러스터에서 제어 및 통신 기능이 필요하다는 점을 명심하십시오. NGINX Enterprise 및 오픈 소스 기술은 보안 및 성능을 염두에 두고 데이터 영역에서 관리 영역에 이르기까지 모든 것을 제공할 수 있도록 지원합니다.

클라우드 네이티브

설치 가이드에서 NGINX Unit을 시작하는 방법에 대해 알아보십시오. NGINX Plus 기반 NGINX Ingress Controller의 향상된 기능을 사용해 보고 싶다면 지금 바로 30일 무료 평가판을 시작하거나 사용 사례에 대해 상담해 주십시오.