미션 크리티컬 환자 진료 활용 사례가 쿠버네티스 대장정이 되기까지

Jenn GileNGINX 제품 마케팅 총괄

다운타임은 심각한 결과를 초래할 수 있습니다.

이 말은 다른 대부분의 산업보다 의료 기술 분야의 기업에 더욱 절실하게 와닿습니다. 이들에게는 "심각한 결과"가 말 그대로 죽음을 의미할 수도 있기 때문입니다. 최근 저희는 종이와 펜에 의존하던 의료 기록 관리를 전 세계 어디서나 언제든 접근할 수 있는 안전한 디지털 데이터로 전환하려는 한 기업의 기술 스택을 면밀히 살펴볼 기회를 얻었습니다. 이러한 데이터에는 환자 정보부터 진료 지침, 생체 지표, 의료 분석 자료, 과거 기록을 비롯해 의료진 간에 공유되는 모든 정보가 포함됩니다.

처음부터 이 회사는 겉보기에는 단순한 질문, 즉 “의료진이 실시간으로 데이터를 손쉽게 기록하도록 어떻게 도울 수 있을까?”에 대한 해답을 찾고자 했습니다. 하지만 회사가 성장하면서 확장성과 데이터의 상시 가용성을 확보해야 할 필요성이 커졌고, 이 과제를 해결하는 일은 점점 더 복잡해졌습니다. 여기에서는 이 회사가 기술 여정을 거치며 Kubernetes와 NGINX Ingress Controller를 도입하게 된 과정을 설명합니다.

한눈에 보는 기술 스택

• 운영체제 – Linux
• 컨테이너 오케스트레이션 – Microsoft Azure Kubernetes Service
• 네트워킹 – Kubernetes, NGINX Ingress Controller 기반 NGINX Plus
• 소프트웨어 개발 언어/프레임워크 – .Net
• 모니터링, 관측 가능성 및 알림 – Prometheus
• 모니터링 대시보드 – Grafana
• 로깅 – Grafana Loki
• 데이터베이스 – Azure SQL Service
• 애플리케이션 서버 – Azure App Service, .Net
• 메시징 및 스트리밍 – Azure Event Hubs
• 캐싱 – Redis
• 보안 – NGINX App Protect
• 위치 및 인프라 – 가용 영역 2개, Kubernetes 클러스터 2개, 노드 15~20개, 파드 60~100개
• DevOps – Azure DevOps Services

NGINX가 이들의 아키텍처에서 어떤 역할을 하는지 살펴보겠습니다:

종이 문서의 문제점

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

• 의료 종사자는 하루에도 수십 명의 환자를 응대할 수 있기 때문에 환자를 돌보는 동안 상세한 기록을 작성하기란 대개 현실적으로 어렵습니다. 그 결과 근무가 끝날 무렵에야 기록을 작성하게 됩니다. 이때는 정신적·육체적 피로로 인해 구체적인 내용 대신 일반적인 의견만 기록하기 쉽습니다.
• 또한 의료 종사자들은 환자 행동에 관한 세부 사항을 기억에 의존해야 합니다. 부정확한 기록은 장기간에 걸쳐 정확하고 일관되게 문서화했을 경우 더 큰 건강 문제를 진단하는 데 도움이 될 수 있는 패턴을 가릴 수 있습니다.
• 종이 기록은 한 기관 내 부서 간에도 쉽게 공유할 수 없으며, 응급구조대원, 응급실 직원, 보험사 같은 외부 기관과 공유하기는 더더욱 어렵습니다. 노트북이나 태블릿도 중앙 데이터 저장소나 클라우드에 연결되어 있지 않다면 상황은 크게 다르지 않습니다.

이러한 문제를 해결하기 위해 회사는 환자 정보에 빠르게 접근하고 투약과 같은 일반적인 상황을 간편하게 기록할 수 있는 간소화된 데이터 기록 시스템을 개발했습니다. 접근성과 사용 편의성이 향상되어 환자와의 상호작용을 발생 즉시 실시간으로 기록할 수 있습니다.

모든 데이터는 회사가 관리하는 클라우드 시스템에 저장되며, 이 앱은 다른 전자의무기록 시스템과 연동되어 입소자의 행동을 장기적이고 종합적으로 파악할 수 있도록 합니다. 이를 통해 돌봄 제공자는 치료의 연속성을 높이고 안전한 과거 기록을 구축할 수 있으며, 해당 기록을 다른 의료 소프트웨어 시스템과 손쉽게 공유할 수 있습니다.

의사와 기타 전문 의료진도 환자를 입원시키거나 진료할 때 이 플랫폼을 사용합니다. 환자의 선호 사항과 개인적 필요에 관한 기록은 환자가 어느 시설로 이동하든 함께 전달됩니다. 이러한 정보는 환자가 새로운 환경에서 편안함을 느끼도록 도와 회복 기간 등의 치료 결과를 개선할 수 있습니다.

기업이 환자 데이터를 보관해야 하는 기간에는 엄격한 법적 요건이 적용됩니다. 이 회사의 개발자들은 일반적인 클라우드 애플리케이션보다 훨씬 우수한 가동 시간 SLA와 매우 높은 가용성을 제공하도록 소프트웨어를 구축했습니다. 환자 파일이 로드되지 않는다는 이유로 구급차를 대기시킬 수는 없습니다.

차고에서 클라우드를 거쳐 Kubernetes로 향한 여정

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

클라우드에서 몇 년간 운영한 후 회사는 빠르게 성장하면서 확장성 문제를 겪기 시작했습니다. 무한한 확장이 필요했으며, VM에서는 수직 확장이 느리고 비용이 많이 들기 때문에 수직이 아닌 수평으로 확장해야 했습니다. 이러한 요구 사항에 따라 컨테이너화와 Kubernetes가 자연스럽게 가능한 해결책으로 떠올랐습니다. 또한 회사의 개발자들이 서비스 중단 위험 없이 애플리케이션과 인프라 업데이트를 자주 배포해야 한다는 점도 컨테이너화의 또 다른 장점이었습니다. 여러 시간대에서 환자 기록이 지속적으로 추가되기 때문에, 결함으로 인해 고객이 즉시 영향을 받을 위험 없이 변경 사항을 프로덕션 환경에 배포할 수 있는 자연스러운 비가동 시간대가 없습니다.

이 회사가 가장 먼저 고려한 합리적인 선택지는 Microsoft의 관리형 Kubernetes 서비스인 Azure Kubernetes Services(AKS)였습니다. 팀은 Kubernetes 모범 사례를 조사한 결과, AKS의 노드와 파드에서 실행되는 트래픽과 애플리케이션을 효과적으로 관리하려면 Kubernetes 클러스터 앞단에서 실행되는 Ingress 컨트롤러가 필요하다는 사실을 알게 되었습니다.

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

팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만, 이 컨트롤러의 트래픽 라우팅 기능만으로는 회사가 요구하는 방식으로 고객에게 업데이트를 제공할 수 없다는 사실을 확인했습니다. 환자 치료에서는 모호하거나 상충되는 정보가 있어서는 안 됩니다. 예를 들어 동일한 상황에 대해 한 돌봄 종사자에게는 주황색 플래그가 표시되고 다른 종사자에게는 빨간색 플래그가 표시되는 것은 용납할 수 없습니다. 따라서 한 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드 시 큰 과제가 됩니다. 고객을 새 버전으로 전환하기에 적절한 시점이 따로 없기 때문에, 회사는 서버 및 네트워크 수준의 규칙을 사용하여 고객별로 서로 다른 앱 버전에 트래픽을 라우팅할 방법이 필요했습니다.

이를 위해 이 회사는 한 조직 내 모든 사용자에게 동일한 백엔드 플랫폼을 제공하며, 조직 내부의 인프라 계층을 분할하는 멀티테넌시는 지원하지 않습니다. Kubernetes에서는 가상 네트워크 경로와 브라우저 쿠키를 세부적인 트래픽 규칙과 함께 사용해 트래픽을 분할할 수 있습니다. 그러나 이 회사의 기술팀은 AKS의 기본 Ingress 컨트롤러가 트래픽을 비율에 따라서만 분할할 수 있을 뿐, 필요한 것처럼 고객 조직이나 개별 사용자 수준에서 작동하는 규칙을 적용할 수는 없다는 사실을 확인했습니다.

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

위험 구간: 모니터링, 옵저버빌리티 및 애플리케이션 성능

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

NGINX Ingress Controller는 세분화된 지속적 모니터링에 대한 회사의 요구 사항도 충족합니다. 의료 분야에서는 애플리케이션 성능이 매우 중요합니다. 지연이나 다운타임은 성공적인 임상 진료를 저해할 수 있으며, 특히 생사가 걸린 상황에서는 더욱 그렇습니다. Kubernetes로 이전한 후 고객들은 회사가 인지하지 못했던 다운타임을 보고하기 시작했습니다. 회사는 곧 문제의 원인을 파악했습니다. Azure App Service가 샘플링된 데이터에 의존하고 있었던 것입니다. 샘플링은 평균과 전반적인 추세를 파악하는 데는 적합하지만, 거부된 요청이나 누락된 리소스 같은 문제는 전혀 포착하지 못합니다. 또한 의료진이 환자 상태를 확인하고 환자 데이터를 기록하는 과정에서 흔히 30분마다 발생하는 사용량 급증도 보여 주지 못합니다. 이로 인해 회사는 지연 시간, 오류 원인, 잘못된 요청, 서비스 중단에 대해 불완전한 정보만 파악하고 있었습니다.

문제는 여기서 끝나지 않았습니다. Azure App Service는 기본적으로 저장된 데이터를 한 달 동안만 보존하는데, 이는 여러 국가의 법률에서 의무화한 수십 년의 보존 기간에 크게 못 미칩니다. 장기 보존 요건을 충족하도록 데이터 저장소를 확장하려면 감당하기 어려울 정도로 많은 비용이 들었습니다. 또한 Azure 솔루션은 Kubernetes 네트워킹 스택 내부를 들여다볼 수 없습니다. NGINX Ingress Controller는 레이어 4 및 레이어 7 트래픽을 처리하면서 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.

이 회사는 성능 모니터링과 관측성을 위해 Grafana 시각화 엔진 및 대시보드와 연동된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus 및 Grafana와의 통합 기능은 NGINX 데이터 플레인과 컨트롤 플레인에 기본으로 내장되어 있어, 기술팀은 모든 트래픽이 Prometheus 및 Grafana 서버를 통과하도록 간단한 구성 변경만 하면 되었습니다. 또한 로그를 더 쉽게 분석하고 소프트웨어 팀이 시간 경과에 따른 데이터를 더욱 효과적으로 관리할 수 있도록 해당 정보를 Grafana Loki 로깅 데이터베이스로도 전송했습니다.

이 구성은 문제 해결 및 버그 수정을 위해 매우 빈번하게 대량의 데이터를 샘플링해야 하는 장애에도 향후 대비할 수 있도록 해줍니다. 대부분의 대형 클라우드 기업이 제공하는 애플리케이션 모니터링 시스템으로 이러한 유형의 장애에 대응하려면 비용이 많이 들 수 있지만, 이 사용 사례에서 Prometheus, Grafana, Loki의 비용과 관리 부담은 미미합니다. 세 제품 모두 안정적인 오픈 소스 제품으로, 일반적으로 초기 튜닝 후에는 패치 적용 외에 별다른 관리가 필요하지 않습니다.

기조 유지: 고가용성과 보안에 집중

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

최고 수준의 가용성을 확보하기 위해 기술팀은 단일 장애 지점 없이 완전한 이중화를 구현하는 액티브-액티브, 다중 영역 및 다중 지역 분산 인프라 설계를 적용합니다. 또한 서로 다른 두 지역에 이중 Kubernetes 클러스터를 배치한 N+2 액티브-액티브 인프라를 운영합니다. 각 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 배포되어 다운타임 위험을 줄이고, 인프라의 어느 계층에서든 장애가 발생할 경우에 대비합니다. 어피니티 및 안티어피니티 규칙을 통해 사용자와 트래픽을 정상 실행 중인 파드로 즉시 재라우팅하여 서비스 중단을 방지할 수 있습니다.

보안을 위해 팀은 악성 요청과 공격자로부터 보호하는 웹 애플리케이션 방화벽(WAF)을 배포합니다. OWASP Top 10에 대한 보호는 대부분의 WAF가 기본적으로 제공하는 기능입니다. 앱을 개발하면서 팀은 Azure 네이티브 WAF와 ModSecurity를 비롯한 여러 WAF를 검토했습니다. 최종적으로 팀은 인라인 WAF와 분산 서비스 거부(DDoS) 방어 기능을 갖춘 NGINX App Protect를 선택했습니다.

NGINX App Protect의 큰 장점은 NGINX Ingress Controller와 함께 배치되어 중복 지점을 없애고 지연 시간을 줄일 수 있다는 것입니다. 다른 WAF는 Kubernetes 환경 외부에 배치해야 하므로 지연 시간과 비용이 증가합니다. 아주 미미한 지연(예: 요청당 1밀리초 추가)도 시간이 지나면 빠르게 누적됩니다.

뜻밖의 부가 성과: 개발자 다운타임 제로

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

회사의 보안 및 애플리케이션 성능 팀은 상세한 Grafana 대시보드와 통합 알림 시스템을 갖추게 되어, 여러 시스템을 일일이 확인하거나 서로 다른 프로세스에서 발생하는 경고 문자와 전화에 대한 트리거를 구현할 필요가 없어졌습니다. 이제 개발 및 DevOps 팀은 코드와 인프라 업데이트를 매일, 심지어 하루에도 여러 번 배포할 수 있으며 매우 세분화된 블루-그린 패턴을 사용할 수 있습니다. 이전에는 일주일에 한두 번 업데이트를 배포하면서 사용량이 적은 시간대에 맞춰야 했기 때문에 상당한 부담이 따랐습니다. 이제는 코드가 준비되는 즉시 배포되며, 개발자는 애플리케이션의 동작을 관찰하여 그 영향을 직접 모니터링할 수 있습니다.

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

작성자 소개

Jenn GileNGINX 제품 마케팅 총괄

Jenn Gile의 다른 블로그 게시물