Kubernetes Ingress Controller 보안 적용 고객 사례

이 포스트에서는 이 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다.

의료 기술 분야의 기업에게는 다른 어떤 산업보다 ‘심각한 결과’라는 말이 더 잘 어울리는데, 이 경우 ‘심각한 결과’에는 말 그대로 사망이 포함될 수 있습니다. 최근 전 세계 언제 어디서나 액세스할 수 있는 안전한 디지털 데이터로 의료 기록 관리를 전환하려는 한 기업의 기술 스택을 분석할 기회가 있었습니다. 이러한 데이터는 환자 정보부터 치료 지시서, 생물학적 지표, 의료 분석, 과거 기록, 그리고 의료팀 간에 공유되는 기타 모든 데이터에 이르기까지 다양합니다.

처음부터 이 회사는 단순해 보이는 질문을 해결하기 위해 노력했습니다. “어떻게 하면 의료진이 실시간으로 데이터를 쉽게 기록할 수 있도록 도울 수 있을까?” 그러나 회사가 성장함에 따라 데이터를 확장하고 지속적으로 사용할 수 있도록 해야 할 필요성으로 인해 이 문제를 해결하는 것이 점점 더 복잡해졌습니다.

목차

1. Kubernetes 기술 스택 개요
2. 종이의 문제
3. 차고에서 클라우드, Kubernetes까지의 여정
4. 트래픽 라우팅은 유연하면서도 정확해야 합니다.
5. Here Be Dragons: 모니터링, 관찰 가능성 및 애플리케이션 성능
6. 코스 유지: Kubernetes 고가용성 및 보안에 집중
7. 서프라이즈 퀘스트: 개발자를 위한 Downtime 방지

1. Kubernetes 기술 스택 개요

OS – Linux

컨테이너 오케스트레이션 – Microsoft Azure Kubernetes Service

네트워킹 – Kubernetes, NGINX Plus 기반 NGINX Ingress Controller

소프트웨어 개발 언어/프레임워크 – .Net

모니터링, 관측 가능성 및 알림 – Prometheus

모니터링 대시보드 – Grafana

로깅 – Grafana Loki

데이터베이스 – Azure SQL Service

애플리케이션 서버 – Azure App Service, .Net

메시징 및 스트리밍 – Azure Event Hubs

캐싱 – Redis

보안 – NGINX App Protect

위치 및 인프라 – Availability Zone 2개, Kubernetes 클러스터 2개, 노드 15~20개, Pod 60~100개

DevOps – Azure DevOps Services

다음은 NGINX가 아키텍처에서 어떤 역할을 하는지 살펴봅니다.

2. 종이의 문제

환자 상태와 치료 정보를 정기적으로 캡처하는 것은 의료진의 핵심 업무입니다. 전통적으로 의료진은 환자 정보를 종이에 기록하거나 최근에는 노트북이나 태블릿에 기록해 왔습니다. 여기에는 몇 가지 심각한 단점이 있습니다.

• 의료진은 하루에 수십 명의 환자를 대면하기 때문에 진료를 제공하는 동안 상세한 메모를 작성하는 것은 현실적으로 불가능합니다. 그 결과, 의료진은 근무가 끝날 무렵에야 노트를 작성하게 됩니다. 이때 정신적, 육체적 피로로 인해 일반적인 코멘트만 기록하고 싶은 유혹에 빠지게 됩니다.
• 또한 의료진은 환자 행동에 대한 세부 사항을 기억하는 데 의존해야 합니다. 시간이 지남에 따라 정확하고 일관되게 문서화하면 더 큰 건강 문제를 쉽게 진단할 수 있는 패턴을 부정확한 기억으로 가려버릴 수 있습니다.
• 종이 기록은 응급 구조대, 응급실 직원, 보험 회사 등 다른 기관은 말할 것도 없고 한 부서 내 부서 간에도 쉽게 공유할 수 없습니다. 노트북이나 태블릿이 중앙 데이터 저장소나 클라우드에 연결되어 있지 않다면 상황은 그다지 좋아지지 않습니다.

이러한 문제를 해결하기 위해 환자 정보에 액세스하고 약 조제와 같은 일반적인 이벤트를 기록할 수 있는 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이렇게 쉽게 액세스하고 사용할 수 있으므로 환자 상호 작용이 발생하는 대로 실시간으로 기록할 수 있습니다.

모든 데이터는 회사에서 관리하는 클라우드 시스템에 저장되며, 애플리케이션은 다른 전자 의료 기록 시스템과 통합되어 레지던트 행동에 대한 포괄적인 종합 정보를 제공합니다. 이를 통해 간병인은 더 나은 치료 서비스를 제공하고, 안전한 진료 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.

의사와 기타 전문가도 환자를 입원시키거나 다른 방식으로 진료할 때 이 플랫폼을 사용합니다. 환자가 어떤 시설로 이동하든 선호도와 개인적 요구 사항에 대한 기록이 있습니다. 이러한 기록은 환자가 새로운 환경에서 편안함을 느낄 수 있도록 도와 회복 시간 등의 결과를 개선하는 데 사용될 수 있습니다.

기업이 환자 데이터를 얼마나 오래 보관해야 하는지에 대한 엄격한 법적 요건이 있습니다. 이 회사의 개발자들은 일반 클라우드 애플리케이션보다 훨씬 뛰어난 가동 시간 SLA를 통해 매우 높은 가용성을 제공하도록 소프트웨어를 구축했습니다. 환자 파일이 로드되지 않아 구급차를 계속 기다리게 하는 것은 선택 사항이 아닙니다.

3. 차고에서 클라우드, Kubernetes 까지의 여정

많은 스타트업과 마찬가지로 이 회사도 처음에는 공동 창업자의 집에 있는 서버에서 첫 번째 개념 증명 애플리케이션을 실행하여 비용을 절감했습니다. 아이디어가 실현 가능성이 있다는 것이 분명해지자 데이터 센터에서 하드웨어를 관리하는 대신 인프라를 클라우드로 이전했습니다. Microsoft를 사용했기 때문에 Azure를 선택했습니다. 초기 아키텍처는 Microsoft의 IIS 웹 서버를 실행하는 관리형 애플리케이션 제공 서비스인 Azure App Service의 기존 가상 머신(VM)에서 애플리케이션을 실행했습니다. 데이터 저장 및 검색을 위해 이 회사는 VM에서 실행되는 Microsoft의 SQL Server를 관리형 애플리케이션으로 사용하기로 했습니다.

몇 년 동안 클라우드를 운영한 후, 회사는 빠르게 성장하면서 확장에 어려움을 겪고 있었습니다. 가상 머신을 사용하면 속도가 느리고 비용이 많이 들기 때문에 수직이 아닌 수평으로 무한히 확장해야 했습니다. 이러한 요구사항은 자연스럽게 컨테이너화와 Kubernetes를 가능한 솔루션으로 이끌었습니다. 컨테이너화를 선호하는 또 다른 이유는 회사의 개발자들이 애플리케이션과 인프라에 대한 업데이트를 중단 위험 없이 자주 제공해야 한다는 점입니다. 여러 시간대에 걸쳐 환자 메모가 지속적으로 추가되기 때문에 고객이 결함으로 인해 즉각적인 영향을 받을 위험 없이 자연스럽게 Downtime없이 Production에 변경 사항을 적용할 수 있습니다.

이 회사의 논리적 출발점은 Microsoft의 관리형 Kubernetes 제품인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사한 결과, AKS의 Node 및 Pod에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하기 위해 Kubernetes 클러스터 앞에서 실행되는 것이 필요하다는 것을 깨달았습니다.

4. 트래픽 라우팅은 유연하면서도 정확해야 합니다.

팀은 AKS의 기본 Ingress Controller를 테스트했지만 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 전달하지 못한다는 사실을 발견했습니다. 예를 들어 동일한 이벤트에 대해 한 의료진에게는 주황색 플래그가 표시되고 다른 의료진에게는 빨간색 플래그가 표시되는 등 모호하거나 상충되는 정보가 표시될 여지가 없어야 합니다. 따라서 특정 조직의 모든 사용자는 동일한 버전의 애플리케이션을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 도전 과제입니다. 고객을 새 버전으로 전환할 수 있는 자연스러운 시간이 없기 때문에 서버 및 네트워크 수준에서 규칙을 사용하여 서로 다른 고객을 서로 다른 애플리케이션 버전으로 라우팅할 수 있는 방법이 필요했습니다.

이를 위해 조직의 모든 사용자를 위해 동일한 Backend 플랫폼을 실행하고 조직 내 인프라 계층에서 세그먼테이션을 통한 Multi Tenancy를 제공하지 않습니다. Kubernetes 를 사용하면 브라우저의 가상 네트워크 경로와 쿠키를 사용하여 트래픽을 세부 트래픽 규칙과 함께 분할할 수 있습니다. 그러나 AKS의 기술팀은 AKS의 기본 Ingress Controller는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 단위로만 트래픽을 분할할 수 있다는 사실을 발견했습니다.

기본 구성에서 NGINX Open Source 기반의 NGINX Ingress Controller는 동일한 한계를 가지고 있기 때문에 세분화된 트래픽 제어를 지원하는 엔터프라이즈급 제품인 NGINX Plus 기반의 고급 NGINX Ingress Controller로 전환하기로 결정했습니다. 높은 수준의 유연성과 제어를 기반으로 Microsoft와 Kubernetes 커뮤니티에서 NGINX Ingress Controller를 추천한 것이 선택의 확고한 근거가 되었습니다. 이 구성은 기존 트래픽 관리와 달리 Pod 관리에 대한 회사의 요구를 더 잘 지원하여 Pod가 적절한 Zone에서 실행되고 트래픽이 해당 서비스로 라우팅되도록 보장합니다. 트래픽이 내부적으로 라우팅되는 경우도 있지만, 대부분의 사용 사례에서는 가시성을 위해 NGINX Ingress Controller를 통해 다시 라우팅됩니다.

5. Here Be Dragons: 모니터링, 관찰 가능성 및 애플리케이션 성능

기술팀은 NGINX Ingress Controller를 통해 개발자 및 최종 사용자 경험을 완벽하게 제어할 수 있습니다. 사용자가 로그인하여 세션을 설정하면 즉시 새 버전으로 라우팅하거나 이전 버전으로 되돌릴 수 있습니다. 패치는 조직의 모든 사용자에게 거의 즉각적으로 동시에 Push할 수 있습니다. 이 소프트웨어는 DNS Propagation나 클라우드 플랫폼 전반의 네트워킹 업데이트에 의존하지 않습니다.

또한 세분화되고 지속적인 모니터링에 대한 회사의 요구 사항도 충족합니다. 애플리케이션 성능은 의료 분야에서 매우 중요합니다. 지연 시간이나 Downtime은 특히 생사가 달린 상황에서 성공적인 임상 치료를 방해할 수 있습니다. Kubernetes로 전환한 후, 고객들은 회사에서 미처 발견하지 못했던 Downtime을 보고하기 시작했습니다. 회사는 곧 문제의 원인을 발견했는데, 바로 Azure App Service가 샘플링된 데이터에 의존한다는 사실이었습니다. 샘플링은 평균과 광범위한 추세에는 적합하지만 거부된 요청이나 누락된 리소스와 같은 것을 완전히 놓칩니다. 또한 간병인이 체크인하고 환자 데이터를 기록할 때 일반적으로 30분마다 발생하는 사용량 급증을 보여주지 않습니다. 이 회사는 지연 시간, 오류 원인, 잘못된 요청, 사용할 수 없는 서비스에 대한 불완전한 정보만 얻을 수 있었습니다.

문제는 여기서 멈추지 않았습니다. 기본적으로 Azure 앱 서비스는 저장된 데이터를 한 달 동안만 보존하는데, 이는 많은 국가의 법률에서 요구하는 수십 년의 보존 기간에 훨씬 못 미칩니다. 더 오래 보존하기 위해 필요한 만큼 데이터 저장소를 확장하려면 엄청난 비용이 들었습니다. 또한 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 볼 수 없습니다. NGINX Ingress Controller는 Layer 4 및 Layer 7 트래픽을 처리하기 때문에 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.

성능 모니터링 및 통합 가시성을 위해 이 회사는 Grafana 시각화 엔진 및 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus 및 Grafana와의 통합은 NGINX 데이터 및 Control Plane에 미리 준비되어 있으며, 기술팀은 모든 트래픽이 Prometheus 및 Grafana 서버를 통과하도록 약간의 구성 변경만 수행하면 되었습니다. 또한 이 정보는 로그를 더 쉽게 분석하고 소프트웨어팀이 시간이 지남에 따라 데이터를 더 잘 제어할 수 있도록 Grafana Loki 로깅 데이터베이스로 라우팅되었습니다.

또한 이 구성은 문제 해결과 버그 수정을 위해 매우 빈번하고 대량의 데이터 샘플링이 필요한 인시던트에 대한 미래 대비책이기도 합니다. 대부분의 대형 클라우드 회사에서 제공하는 애플리케이션 모니터링 시스템으로 이러한 유형의 인시던트를 해결하려면 비용이 많이 들 수 있지만, 이 사용 사례에서 Prometheus, Grafana, Loki의 비용과 오버헤드는 최소화됩니다. 세 가지 모두 안정적인 Open Source 제품이며 일반적으로 초기 튜닝 후 패치만 적용하면 됩니다.

6. 코스 유지: Kubernetes 고가용성 및 보안에 집중

이 회사는 항상 가장 민감한 유형의 데이터 중 하나를 보호하기 위한 보안과 필요할 때 언제든 애플리케이션을 사용할 수 있도록 보장하는 고가용성에 두 가지 초점을 맞춰 왔습니다. Kubernetes로 전환하면서 두 가지 역량을 모두 강화하기 위해 몇 가지 변경 사항을 적용했습니다.

가용성을 극대화하기 위해 기술팀은 Active-Active, Multi-Zone, Multi-Geo 분산 인프라 설계를 배포하여 단일 장애 지점이 없는 완벽한 이중화를 구현합니다. 이 팀은 두 개의 서로 다른 지역에 이중 Kubernetes 클러스터를 사용하여 N+2 Active-Active 인프라를 유지 관리합니다. 각 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 Downtime 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 커버리지를 제공합니다. 선호도 및 반선호도 규칙은 사용자와 트래픽을 가동 중인 Pod로 즉시 리다이렉션하여 서비스 중단을 방지할 수 있습니다.

보안을 위해 팀은 웹 애플리케이션 방화벽(WAF)을 배포하여 잘못된 요청과 악의적인 행위자로부터 보호합니다. 대부분의 WAF가 제공하는 OWASP Top 10에 대한 보호는 Table Stake입니다. 애플리케이션을 만들면서 팀은 기본 Azure WAF와 ModSecurity를 비롯한 여러 WAF를 조사했습니다. 결국 팀은 Inline WAF와 분산 서비스 거부(DDoS) 보호 기능을 갖춘 NGINX App Protect를 선택했습니다.

NGINX App Protect의 가장 큰 장점은 중복 지점을 없애고 지연 시간을 줄여주는 NGINX Ingress Controller와 공동 배치된다는 점입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 작은 지연(예: 요청마다 1MS 추가)도 시간이 지남에 따라 빠르게 누적됩니다.

7. 서프라이즈 퀘스트: 개발자를 위한 Downtime 방지

대부분의 애플리케이션 및 네트워킹 인프라에 대해 AKS로의 전환을 완료한 이 회사는 개발자 경험(DevEx)도 크게 개선했습니다. 이제 개발자는 거의 항상 고객이 문제를 알아차리기 전에 문제를 발견합니다. 전환 이후 오류에 대한 지원 요청이 약 80% 감소했습니다!

이 회사의 보안 및 애플리케이션 성능 팀은 상세한 Grafana 대시보드와 통합된 알림을 통해 여러 시스템을 확인하거나 여러 프로세스에서 오는 경고 문자 및 호출에 대한 트리거를 구현할 필요가 없습니다. 이제 개발 및 DevOps팀은 매일 또는 하루에 여러 번 코드 및 인프라 업데이트를 배포하고 매우 세분화된 Blue-Green 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 배포하고 사용량이 적은 기간에 맞춰 업데이트를 배포해야 했기 때문에 스트레스가 많았습니다. 이제 코드가 준비되었을 때 배포되며 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.

그 결과 소프트웨어 개발 속도가 빨라지고, 개발자의 사기가 향상되며, 더 많은 생명을 구할 수 있게 되는 등 모든 면에서 긍정적인 결과를 얻었습니다.

NGINX Plus 및 NGINX API를 직접 사용해 보거나 테스트해 보려면 지금 30일 무료 평가판을 신청하거나 사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.