프로덕션급 Kubernetes로 복잡성 줄이기

Jenn GileNGINX 제품 마케팅 총괄

편집자 – 이 글은 10부작 시리즈의 일부입니다:

1. 프로덕션급 Kubernetes로 복잡성 줄이기(이 게시물)
2. 고급 트래픽 관리로 Kubernetes의 복원력을 향상하는 방법
3. Kubernetes에서 가시성을 개선하는 방법
4. 트래픽 관리 도구를 사용하여 Kubernetes를 보호하는 6가지 방법
5. 인그레스 컨트롤러 선택 가이드 1부: 요구 사항 파악하기
6. 인그레스 컨트롤러 선택 가이드, 2부: 위험 요소와 미래 대비
7. 인그레스 컨트롤러 선택 가이드 3부: 오픈 소스 vs. 기본 제공 vs. 상용
8. 인그레스 컨트롤러 선택 가이드, 4부: NGINX 인그레스 컨트롤러 옵션
9. 서비스 메시를 선택하는 방법
10. 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트

전체 블로그 모음을 무료 eBook으로 다운로드할 수도 있습니다. Kubernetes를 테스트에서 프로덕션으로 전환하기.

2020년은 우리 중 누구도 쉽게 잊지 못할 한 해였습니다. 학교와 기업, 공공 서비스가 갑작스럽게 문을 닫으면서 우리는 순식간에 공동체로부터 고립되었고, 안전과 재정적 안정에 대한 불확실성에 내몰렸습니다. 이제 잠시 이런 일이 2000년, 아니 2010년에 일어났다고 상상해 보십시오. 무엇이 달랐을까요? 기술입니다. 의료 서비스, 스트리밍 동영상, 원격 협업 도구처럼 우리가 당연하게 여기는 고품질 디지털 서비스가 없었다면 팬데믹은 전혀 다른 경험이었을 것입니다. 2020년의 기술은 무엇 때문에 이전 수십 년과 그토록 달랐을까요? 컨테이너와 마이크로서비스입니다.

마이크로서비스 아키텍처는 일반적으로 컨테이너와 Kubernetes를 활용하며, 디지털 경험의 출시 기간을 단축하여 비즈니스 성장과 혁신을 촉진합니다. 기존 아키텍처와 함께 사용하든 독립적으로 사용하든, 이러한 최신 애플리케이션 기술은 뛰어난 확장성과 유연성, 더 빠른 배포는 물론 비용 절감까지 가능하게 합니다.

2020년 이전에도 대부분의 고객이 디지털 트랜스포메이션 전략의 일환으로 마이크로서비스를 도입하기 시작한 것으로 나타났지만, 팬데믹은 애플리케이션 현대화를 크게 가속화했습니다. 2020년 설문조사에서 NGINX 사용자 중 응답자의 60%가 프로덕션 환경에서 마이크로서비스를 사용하고 있는 것으로 나타났습니다. 이는 2019년의 40%보다 증가한 수치이며, 컨테이너는 다른 최신 애플리케이션 기술보다 두 배 이상 널리 사용되고 있습니다.

Kubernetes는 컨테이너화된 앱을 관리하기 위한 사실상의 표준입니다. 이는 Cloud Native Computing Foundation(CNCF)의 2020년 설문조사에서도 확인할 수 있는데, 응답자의 91%가 Kubernetes를 사용하고 있으며 그중 83%는 프로덕션 환경에서 사용하고 있는 것으로 나타났습니다. Kubernetes를 도입할 때 많은 조직은 대대적인 아키텍처 변화에는 대비하지만, 최신 앱 기술을 대규모로 운영하면서 발생하는 조직 차원의 영향에는 예상치 못한 어려움을 겪습니다. Kubernetes를 운영하고 있다면 다음과 같은 비즈니스 핵심 장벽 세 가지를 모두 경험했을 가능성이 높습니다:

• 문화
  애플리케이션 팀이 애자일 개발 및 DevOps와 같은 현대적인 접근 방식을 도입하더라도, 대개 콘웨이의 법칙의 영향을 받습니다. 이 법칙은 “조직은 자체 커뮤니케이션 구조를 반영하는 시스템을 설계한다”고 설명합니다. 즉, 분산 애플리케이션은 독립적으로 운영되면서도 리소스를 공유하는 분산된 팀에 의해 개발됩니다. 이러한 구조는 팀이 빠르게 움직일 수 있도록 하는 데 이상적이지만, 사일로 형성을 부추기기도 합니다. 그 결과 소통 부재(이는 또 다른 문제를 초래함), 보안 취약점, 도구의 난립, 일관성 없는 자동화 관행, 팀 간 충돌 등이 발생합니다.
• 복잡성
  엔터프라이즈급 마이크로서비스 기술을 구현하려면 조직은 가시성, 보안 및 트래픽 관리를 제공하는 핵심 구성 요소들을 조합해야 합니다. 일반적으로 팀은 이러한 요구를 충족하기 위해 인프라 플랫폼, 클라우드 네이티브 서비스 및 오픈 소스 도구를 사용합니다. 이러한 전략은 각각 적합한 용도가 있지만, 복잡성을 가중할 수 있는 단점도 있습니다. 또한 한 조직 내의 여러 팀이 동일한 요구 사항을 충족하기 위해 서로 다른 전략을 선택하는 경우가 너무 많으며, 이는 ‘운영 부채’로 이어집니다. 더 나아가 팀은 특정 시점에 프로세스와 도구를 선택한 후, 컨테이너를 사용하는 최신 마이크로서비스 기반 애플리케이션의 배포 및 운영과 관련된 요구 사항이 변화하더라도 계속해서 이를 사용합니다. CNCF 클라우드 네이티브 인터랙티브 랜드스케이프는 마이크로서비스 기반 애플리케이션을 지원하는 데 필요한 인프라가 얼마나 복잡한지를 잘 보여줍니다. 조직은 서로 이질적인 광범위한 기술에 능숙해져야 하며, 그 결과 인프라 종속, 섀도 IT, 도구 난립, 그리고 인프라 유지 관리를 담당하는 인력의 가파른 학습 곡선과 같은 문제가 발생합니다.
• 보안
  보안 요구 사항은 클라우드 네이티브 앱과 기존 앱에서 크게 다릅니다. Kubernetes에서는 경계로 둘러싸는 보안과 같은 전략이 효과적이지 않기 때문입니다. 방대한 에코시스템과 컨테이너화된 앱의 분산 특성으로 인해 공격 표면이 훨씬 넓어지며, 외부 SaaS 애플리케이션에 의존하기 때문에 직원과 외부인이 악성 코드를 삽입하거나 정보를 유출할 기회도 훨씬 많아집니다. 또한 문화 및 복잡성 영역에서 언급한 문제, 특히 도구의 난립은 최신 앱의 보안과 복원력에 직접적인 영향을 미칩니다. 에코시스템 전반에서 동일한 문제를 해결하기 위해 서로 다른 도구를 사용하는 것은 비효율적일 뿐만 아니라, 각 구성 요소를 올바르게 구성하는 방법을 익혀야 하는 SecOps 팀에도 큰 부담을 줍니다.

솔루션: 프로덕션급 Kubernetes

대부분의 조직 문제와 마찬가지로, Kubernetes의 과제를 극복하려면 기술과 프로세스를 함께 활용해야 합니다. 이 글의 나머지 부분에서는 기술적 요소에 초점을 맞추겠지만, 향후 프로세스 및 기타 주제를 다룰 블로그 글도 기대해 주세요.

Kubernetes는 오픈 소스 기술이므로 구현 방법이 다양합니다. 일부 조직은 기본 Kubernetes를 직접 구축하는 방식을 선호하지만, 많은 조직은 Amazon Elastic Kubernetes Service(EKS), Google Kubernetes Engine(GKE), Microsoft Azure Kubernetes Service(AKS), Red Hat OpenShift Container Platform, Rancher 등의 서비스가 제공하는 유연성, 명확한 지침, 지원의 조합에서 가치를 찾습니다.

Kubernetes 플랫폼을 사용하면 손쉽게 시작하고 운영할 수 있지만, 이러한 플랫폼은 서비스의 깊이보다는 폭에 중점을 둡니다. 따라서 필요한 모든 서비스를 한곳에서 이용할 수는 있어도, 대규모 환경에서 실제 프로덕션 운영에 필요한 기능 세트를 제공하지 못할 가능성이 큽니다. 특히 고급 네트워킹과 보안에 중점을 두지 않으며, 바로 이 부분에서 Kubernetes가 많은 고객의 기대에 미치지 못하고 있습니다.

Kubernetes를 프로덕션 환경에서 사용할 수 있는 수준으로 만들려면 다음 세 가지 구성 요소를 순서대로 추가해야 합니다:

1. 클러스터 안팎으로 트래픽을 전달하기 위한 확장 가능한 인그레스·이그레스 계층
   이는 인그레스 컨트롤러를 통해 구현됩니다. 인그레스 컨트롤러는 Kubernetes 네트워킹의 복잡성을 추상화하고 Kubernetes 클러스터 내부의 서비스와 외부 서비스를 연결하는 특수 로드 밸런서입니다. 이 구성 요소는 복원력을 높이는 기능(예: 고급 상태 확인 및 Prometheus 메트릭), 빠른 확장성을 지원하는 기능(동적 재구성), 셀프서비스를 지원하는 기능(역할 기반 액세스 제어[RBAC])을 갖추면 프로덕션급이 됩니다.
   
2. 클러스터 전체의 위협을 방어하는 기본 제공 보안
   클러스터 외부에서는 ‘개략적인’ 보안으로 충분할 수 있지만, 클러스터 내부에서는 ‘세분화된’ 보안이 필요합니다. 클러스터의 복잡성에 따라 유연한 웹 애플리케이션 방화벽(WAF)을 배포해야 할 수 있는 위치는 Ingress 컨트롤러, 서비스별 프록시, Pod별 프록시의 세 곳입니다. 이러한 유연성 덕분에 결제와 같은 민감한 앱에는 더 엄격한 제어를 적용하고, 위험이 낮은 곳에는 더 완화된 제어를 적용할 수 있습니다.
   
3. 클러스터 내 트래픽을 최적화하는 확장 가능한 동서 트래픽 계층
   이 세 번째 구성 요소는 Kubernetes 애플리케이션의 복잡성과 규모가 기본 도구로 처리할 수 있는 수준을 넘어섰을 때 필요합니다. 이 단계에서는 서비스 메시가 필요합니다. 서비스 메시는 클러스터 내 애플리케이션 서비스에 더욱 세분화된 트래픽 관리 및 보안을 제공하는 오케스트레이션 도구입니다. 일반적으로 서비스 메시는 컨테이너화된 애플리케이션 간의 애플리케이션 라우팅을 관리하고, 서비스 간 상호 TLS(mTLS) 정책을 자율적으로 제공 및 적용하며, 애플리케이션의 가용성과 보안에 대한 가시성을 제공합니다.
   

이러한 구성 요소를 선택할 때는 이식성과 가시성을 우선시하세요. 플랫폼에 구애받지 않는 구성 요소를 사용하면 팀이 익히고 보호해야 할 도구가 줄어 복잡성이 낮아지고 보안이 강화되며, 비즈니스 요구 사항에 따라 워크로드를 더 쉽게 이전할 수 있습니다. 가시성과 모니터링의 중요성은 아무리 강조해도 지나치지 않습니다. Grafana 및 Prometheus와 같은 널리 사용되는 도구와 통합하면 인프라를 하나의 화면에서 통합적으로 파악할 수 있어, 고객이 문제를 발견하기 전에 팀에서 먼저 감지할 수 있습니다. 또한 프로덕션급 Kubernetes에 반드시 필요한 것은 아니지만 현대적인 앱 개발에 필수적인 보완 기술도 있습니다. 예를 들어 조직에서 기존 앱을 현대화할 준비가 되었다면 첫 단계 중 하나는 API 게이트웨이를 사용하여 마이크로서비스를 구축하는 것입니다.

NGINX가 제공하는 지원

당사의 Kubernetes 솔루션은 플랫폼에 구애받지 않으며, 프로덕션급 Kubernetes를 구현하는 데 필요한 세 가지 구성 요소를 포함합니다. 즉, 인그레스-이그레스 계층으로 NGINX Ingress Controller, WAF로 NGINX App Protect, 이스트-웨스트 계층으로 NGINX Service Mesh를 제공합니다.

이러한 솔루션은 다음 네 가지 핵심 영역을 지원하여 Kubernetes를 최고의 동반자로 만들어 줍니다:

• 자동화 – 애플리케이션을 더 빠르고 안전하게 출시하세요
  NGINX Ingress Controller의 트래픽 라우팅 및 애플리케이션 온보딩 기능과 NGINX Service Mesh의 NGINX Plus 사이드카 자동 배포 기능을 함께 활용하여 애플리케이션을 배포, 확장, 보호 및 업데이트하세요.
• 보안 – 기존 및 새롭게 등장하는 위협으로부터 고객과 비즈니스 보호
  클러스터 내 어디서나 NGINX App Protect를 배포하고 NGINX Service Mesh와 NGINX Ingress Controller를 사용하여 서비스 간 종단 간 암호화를 관리하고 적용함으로써 잠재적인 장애 지점을 줄일 수 있습니다.
• 성능 – 고객과 사용자가 기대하는 디지털 경험 제공
  다른 WAF, Ingress 컨트롤러 및 로드 밸런서보다 뛰어난 성능을 제공하는 NGINX 솔루션으로 성능 저하 없이 트래픽 급증과 보안 위협에 손쉽게 대응하세요.
• 인사이트 – 비즈니스를 발전시키고 고객에게 더 나은 서비스 제공
  NGINX Ingress Controller와 NGINX Service Mesh에서 앱 성능 및 가용성에 관한 맞춤형 인사이트를 얻고, 상세한 추적 정보를 통해 마이크로서비스 앱 전반에서 요청이 처리되는 방식을 파악할 수 있습니다.

NGINX로 프로덕션 환경 준비하기

NGINX Ingress Controller는 30일 무료 평가판으로 제공되며, 컨테이너화된 앱을 보호하는 NGINX App Protect가 포함되어 있습니다. 평가판을 최대한 활용하려면 항상 무료로 제공되는 NGINX Service Mesh를 추가하는 것이 좋습니다. NGINX Service Mesh는 다운로드할 수 있습니다: f5.com. 현재는 원하는 클라우드에 기존 보유 라이선스(BYOL)를 적용할 수 있습니다.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물