인그레스 컨트롤러 선택 가이드 2부: 위험 요소와 미래 대비

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를 테스트에서 프로덕션으로 전환하기.

In Part 1 of our guide to choosing an Ingress 컨트롤러 선택 가이드 1부에서는 요구 사항을 파악하는 방법을 설명했습니다. 하지만 아직 제품을 테스트할 단계는 아닙니다! 이 글에서는 잘못된 Ingress 컨트롤러를 선택하면 릴리스 속도가 느려지고 심지어 고객을 잃을 수도 있는 이유를 설명합니다. 다른 도구와 마찬가지로 Ingress 컨트롤러도 위험을 초래하고 향후 확장성에 영향을 미칠 수 있습니다. 득보다 실이 클 수 있는 선택지를 제외하는 방법을 살펴보겠습니다.

Ingress 컨트롤러의 위험 요소

Kubernetes에 트래픽 관리 도구를 도입할 때는 복잡성, 지연 시간, 보안이라는 세 가지 구체적인 위험을 고려해야 합니다. 이러한 문제는 서로 얽혀 있는 경우가 많아 하나가 발생하면 다른 문제도 함께 나타날 가능성이 큽니다. 각 위험은 Ingress 컨트롤러로 인해 발생할 수 있으며, 이를 감수할 수 있는지는 조직에서 판단해야 합니다. 오늘날의 소비자는 변덕스러우므로, 아무리 매력적인 기능을 제공하더라도 디지털 경험을 저해하는 요소가 있다면 받아들여지지 않을 수 있습니다.

복잡성 – 마이크로서비스 아키텍처의 취지를 무색하게 만드는가?

최고의 Kubernetes 도구는 가볍고 단순한 설계라는 마이크로서비스 아키텍처의 목표에 부합하는 도구입니다. 이러한 원칙을 지키면서도 기능이 매우 풍부한 Ingress 컨트롤러를 개발할 수 있지만, 항상 그런 것은 아닙니다. 일부 설계자는 지나치게 많은 기능을 포함하거나 복잡한 스크립트를 사용해 기반 엔진에서 기본적으로 지원하지 않는 기능을 덧붙이며, 그 결과 Ingress 컨트롤러가 불필요하게 복잡해집니다.

그렇다면 이것이 왜 중요할까요? Kubernetes에서 지나치게 복잡한 도구는 애플리케이션 성능에 부정적인 영향을 미치고 배포를 수평으로 확장하는 데 제약을 줄 수 있습니다. 일반적으로 지나치게 복잡한 Ingress 컨트롤러는 크기로 알아볼 수 있습니다. 설치 공간이 클수록 도구가 더 복잡합니다.

지연 시간 – Ingress 컨트롤러가 애플리케이션 속도를 저하시키나요?

Ingress 컨트롤러는 리소스 사용량, 오류 및 시간 초과로 인해 지연 시간을 늘릴 수 있습니다. 정적 및 동적 배포에서 추가되는 지연 시간을 모두 살펴보고 내부 요구 사항에 따라 허용할 수 없는 지연 시간을 유발하는 옵션은 제외하세요. 재구성이 앱 속도에 미치는 영향에 대한 자세한 내용은 블로그의 「동적 Kubernetes 클라우드 환경에서 NGINX Ingress 컨트롤러 성능 테스트」를 참조하세요.

보안 – Ingress 컨트롤러가 해커의 침입을 허용하나요?

오늘날 인터넷에는 공통 취약점 및 노출(CVE)이 만연해 있으며, Ingress 컨트롤러 제공업체가 CVE 패치를 제공하는 데 걸리는 시간에 따라 보안을 유지할 수도, 침해 사고를 당할 수도 있습니다. 조직의 위험 감수 수준에 따라 패치 제공에 며칠 이상(아무리 길어도 몇 주)이 걸리는 솔루션은 제외하는 것이 좋습니다.

CVE 외에도 일부 Ingress 컨트롤러는 또 다른 잠재적 취약점에 노출될 수 있습니다. 다음과 같은 상황을 생각해 보세요. 온라인 소매업체에서 근무하는 중 오픈 소스 Ingress 컨트롤러의 구성 문제를 해결하는 데 도움이 필요합니다. 상용 지원을 받을 수 없어 Stack Overflow와 같은 포럼에 문제를 게시합니다. 누군가 도움을 주겠다며 Ingress 컨트롤러와 기타 Kubernetes 구성 요소의 구성 파일 및 로그 파일을 살펴보고 문제를 찾아보겠다고 합니다. 문제를 빨리 해결해야 한다는 압박감에 결국 해당 파일을 공유합니다.

이 ‘선의의 조력자’ 덕분에 문제를 해결하지만, 6개월 후 보안 침해가 발생해 고객 기록에서 신용카드 번호가 도난당했다는 사실을 알게 됩니다. 이런. 알고 보니 공유한 파일에 앱 침투에 악용된 정보가 포함되어 있었습니다. 이 시나리오는 조직이 유료 지원을 선택하는 가장 큰 이유 중 하나를 잘 보여 줍니다. 바로 기밀성이 보장된다는 점입니다.

OpenResty 기반 Ingress 컨트롤러에 대한 참고 사항

OpenResty는 LuaJIT, Lua 스크립트 및 타사 NGINX 모듈을 통합하여 NGINX Open Source의 기능을 확장한, NGINX Open Source 기반의 웹 플랫폼입니다. 또한 OpenResty를 기반으로 구축된 여러 Ingress 컨트롤러가 있는데, 이러한 컨트롤러는 NGINX Open Source 및 NGINX Plus 기반의 자사 Ingress 컨트롤러와 비교할 때 잠재적으로 다음과 같은 두 가지 위험을 추가할 수 있다고 판단합니다:

• 시간 초과 – 앞서 언급했듯이 OpenResty는 Lua 스크립팅을 사용하여 상용 NGINX Plus 기반 Ingress Controller에서 제공하는 것과 같은 고급 기능을 구현합니다. 이러한 기능 중 하나인 동적 재구성은 가용성을 저해하는 NGINX Open Source의 요구 사항, 즉 서비스 엔드포인트가 변경될 때 NGINX 구성을 다시 로드해야 하는 요구 사항을 없애 줍니다. OpenResty로 동적 재구성을 구현하기 위해 Lua 핸들러는 요청을 라우팅할 업스트림 서비스를 선택하므로 NGINX 구성을 다시 로드할 필요가 없습니다. 그러나 Lua는 백엔드의 변경 사항을 지속적으로 확인해야 하므로 리소스가 소모됩니다. 수신 요청을 처리하는 데 더 오랜 시간이 걸리면서 일부 요청이 지연되고, 시간 초과가 발생할 가능성이 커집니다. 사용자와 서비스가 늘어날수록 초당 수신 요청 수와 Lua가 처리할 수 있는 요청 수의 격차가 기하급수적으로 벌어집니다. 그 결과 지연 시간과 복잡성이 증가하고 비용이 높아집니다. Lua로 인해 지연 시간이 얼마나 늘어날 수 있는지 알아보려면 동적 Kubernetes 클라우드 환경에서 NGINX Ingress Controller 성능 테스트를 참조하세요.
• CVE 패치 지연 – NGINX의 Ingress Controller와 비교하면, NGINX Open Source를 기반으로 하는 OpenResty 같은 도구에 기반한 Ingress Controller에는 CVE 패치가 적용되기까지 필연적으로 더 오랜 시간이 걸립니다. 다음 글에서 자세히 설명했듯이 NGINX Plus로 보안 취약점을 빠르고 간편하게 완화하기, NGINX에서 CVE가 발견되면 공급업체인 당사는 일반적으로 해당 CVE가 공개되기 전에 통보받습니다. 따라서 CVE가 발표되는 즉시 NGINX Open Source와 NGINX Plus용 패치를 릴리스할 수 있습니다. NGINX Open Source 기반 기술은 그 시점이 되어서야 CVE를 알게 될 수 있으며, 당사의 경험에 따르면 OpenResty 패치는 당사 패치보다 상당히 늦게 제공됩니다. 최근 한 사례에서는 4개월이나 늦었습니다. OpenResty 기반 Ingress Controller용 패치는 필연적으로 더 많은 시간이 걸리므로, 악의적인 공격자가 취약점을 악용할 기회가 충분히 생깁니다.

미래에도 대비할 수 있는 Ingress Controller

이제 막 Kubernetes를 접하기 시작했더라도 언젠가는 프로덕션 환경에 도입하고자 할 가능성이 큽니다. 시간이 지남에 따라 요구 사항이 커질 가능성이 높은 주요 영역은 인프라, 보안, 지원, 멀티테넌시의 네 가지입니다.

인프라 – 하이브리드 또는 멀티 클라우드 환경에서 Kubernetes를 사용하시겠습니까?

조직이 한 가지 유형의 환경만을 전적으로 영구히 사용하기로 하는 경우는 드뭅니다. 일반적으로 조직은 온프레미스와 클라우드 환경을 함께 사용하며, 여기에는 프라이빗 클라우드, 퍼블릭 클라우드, 하이브리드 클라우드, 멀티 클라우드가 포함될 수 있습니다. (이러한 환경의 차이점을 자세히 알아보려면 멀티 클라우드와 하이브리드 클라우드의 차이점은 무엇인가요?를 참조하세요.)

이 시리즈의 1부에서 언급했듯이, 각 환경에서 기본으로 제공되는 도구를 선택하고 싶을 수 있지만 기본 Ingress 컨트롤러에는 여러 가지 고유한 문제가 있습니다. 모든 단점은 이 시리즈의 3부에서 다루겠지만, 미래 대비와 가장 밀접한 문제는 공급업체 종속입니다. 클라우드별 Ingress 컨트롤러는 모든 환경에서 사용할 수 없기 때문입니다. 클라우드별 기본 도구를 사용하면 다음과 같이 매력적이지 않은 두 가지 선택지만 남게 되어 확장 역량에 영향을 미칩니다.

1. 기존 클라우드로 모든 요구 사항을 충족해 보세요
2. 각각의 새 환경에서 Ingress 컨트롤러에 맞게 로드 밸런싱뿐만 아니라 보안까지 모든 구성을 다시 작성하세요!

첫 번째 대안은 비즈니스상의 이유로 실현하기 어려운 경우가 많으며, 두 번째 대안 역시 도구의 난립을 초래하고 새로운 보안 취약점을 만들며 직원들이 가파른 학습 곡선을 극복해야 하므로 쉽지 않습니다. 세 번째이자 가장 효율적인 대안은 처음부터 인프라에 구애받지 않는 Ingress 컨트롤러를 선택하여 모든 환경에서 동일한 도구를 사용할 수 있도록 하는 것입니다.

인프라와 관련해 고려해야 할 또 다른 요소는 인증입니다. Red Hat OpenShift Container Platform(OCP)을 예로 들어 보겠습니다. OCP 사용자라면 Red Hat Marketplace에서 OCP용 인증 오퍼레이터를 제공한다는 사실을 이미 알고 계실 것입니다. 여기에는 NGINX Ingress Operator도 포함됩니다. Red Hat의 인증 표준 덕분에 해당 도구가 배포 환경에서 제대로 작동한다는 확신을 가질 수 있으며, Red Hat과 공급업체의 공동 지원까지 받을 수도 있습니다. 많은 조직이 보안과 안정성을 위해 인증된 도구를 사용하도록 요구하므로, 현재는 테스트 단계에 불과하더라도 프로덕션 환경에 대한 회사의 요구 사항을 염두에 두는 것이 좋습니다.

보안 – Kubernetes 내부를 어떻게 보호할 것인가?

경계 보안만으로 애플리케이션과 고객을 안전하게 보호할 수 있었던 시대는 지났습니다. Kubernetes 애플리케이션은 인증과 권한 부여를 비롯한 보안 기능을 애플리케이션 가까이에 배치할 때 가장 효과적으로 보호할 수 있습니다. 또한 점점 더 많은 조직이 종단 간 암호화를 의무화하고 Kubernetes 내에서 제로 트러스트 네트워크 모델을 도입함에 따라, 향후 서비스 메시가 필요해질 수 있습니다.

이 모든 것이 Ingress 컨트롤러와 무슨 관련이 있을까요? 아주 밀접한 관련이 있습니다! Ingress 지점에서 보안(인증, 권한 부여, DoS 방어, 웹 애플리케이션 방화벽)을 중앙 집중화하는 것은 비용과 효율성 측면에서 매우 합리적입니다. 대부분의 서비스 메시를 대부분의 Ingress 컨트롤러와 통합할 수 있지만, 어떤 방식으로 통합되는지가 매우 중요합니다. 보안 전략에 부합하는 Ingress 컨트롤러를 사용하면 애플리케이션 개발 과정 전반에서 발생할 수 있는 큰 골칫거리를 예방할 수 있습니다.

클라우드 네이티브 앱 제공의 위험에 대해 자세히 알아보려면 속도 저하 없이 클라우드 네이티브 앱 보호하기를, 보안 도구를 배치할 최적의 위치를 결정하는 요인에 대해 자세히 알아보려면 Kubernetes에서 애플리케이션 서비스 배포하기, 2부를 읽어보세요.

지원 – 어느 정도까지 “스스로” 감당할 수 있습니까?

팀이 Kubernetes를 이제 막 시험해 보는 단계라면 커뮤니티든 기업이든 지원을 최우선으로 고려하지 않는 경우가 많습니다. 팀이 자체적인 해결책과 우회 방법을 마련할 시간이 충분하다면 괜찮지만, 프로덕션 환경으로 전환한 후에는 지속 가능한 방식이 아닙니다. 현재는 지원이 필요하지 않더라도 향후 지원을 추가할 수 있거나, 규모가 커짐에 따라 업그레이드할 수 있는 저렴한 지원 요금제를 제공하는 Ingress 컨트롤러를 선택하는 것이 현명할 수 있습니다.

멀티테넌시 – 여러 팀과 앱이 컨테이너 환경을 안전하게 공유하려면 어떻게 해야 할까요?

처음에는 하나의 팀과 하나의 앱이 있었습니다… 모든 이야기는 이렇게 시작하지 않나요? 이후 그 팀이 하나의 Kubernetes 앱을 성공적으로 개발하고, 이를 계기로 조직이 Kubernetes에서 더 많은 서비스를 운영하게 되는 경우가 많습니다. 물론 서비스가 많아질수록 팀도 많아지고 복잡성도 커집니다.

효율성을 극대화하기 위해 조직은 멀티테넌시를 도입하고, 비즈니스 프로세스에 필요한 액세스 및 격리를 지원하는 동시에 운영자에게 필요한 관리 편의성과 제어 기능을 제공하는 Kubernetes 모델을 채택합니다. 일부 Ingress 컨트롤러는 여러 Ingress, 클래스, 네임스페이스, 역할 기반 액세스 제어(RBAC) 설정을 지원하는 범위 지정 리소스 등 다양한 기능과 개념을 통해 클러스터를 분할할 수 있도록 지원합니다.

다음 단계: 선택지 좁히기

요구 사항, 위험 감수 수준, 미래 대비 방안을 검토했으므로 이제 매우 다양한 Ingress 컨트롤러 중에서 선택지를 좁혀 나갈 수 있는 충분한 정보를 갖추었습니다. 이를 범주별로 나누면 이 단계를 빠르게 진행하는 데 도움이 됩니다. 이 시리즈의 3부에서는 Ingress 컨트롤러를 세 가지 범주로 나누어 각각의 장단점을 살펴보겠습니다.

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물