블로그 | NGINX

쿠버네티스 오디세이가 된 미션 크리티컬 환자 케어 사용 사례

NGINX-F5-수평-검정-유형-RGB의 일부
젠 길 썸네일
젠 길
2023년 5월 17일 게시

가동 중지 시간은 심각한 결과를 초래할 수 있습니다.

이러한 말은 대부분의 다른 산업 분야보다 의료 기술 분야의 회사에 더욱 해당됩니다. 이 경우 "심각한 결과"에는 문자 그대로 사망이 포함될 수 있습니다. 최근에 우리는 의료 기록 보관을 펜과 종이에서 언제 어디서나 접근할 수 있는 안전한 디지털 데이터로 전환하려는 회사의 기술 스택을 분석할 기회를 가졌습니다. 이러한 데이터는 환자 정보부터 치료 지침, 생물학적 지표, 의료 분석, 병력 기록 등 의료팀 간에 공유되는 모든 내용을 포함합니다.

회사는 처음부터 겉보기에 간단한 질문에 답하려고 노력했습니다. "간병인이 실시간으로 데이터를 쉽게 기록할 수 있도록 어떻게 도울 수 있을까요?" 그러나 회사가 성장함에 따라 확장하고 데이터를 지속적으로 제공해야 할 필요성이 생겨서 그 과제를 해결하는 것이 점점 더 복잡해졌습니다. 여기서는 회사의 기술 여정이 어떻게 Kubernetes 와 NGINX Ingress Controller를 도입하게 되었는지 설명합니다.

기술 스택을 한눈에 보기

다음은 NGINX가 아키텍처에 어떻게 들어맞는지 살펴보는 것입니다.

NGINX가 아키텍처에 어떻게 들어맞는지 다이어그램으로 표시

종이의 문제

정기적으로 환자 상태와 치료 정보를 파악하는 것은 의료 종사자의 핵심 임무입니다. 전통적으로는 환자 정보를 종이에 기록했지만, 최근에는 노트북이나 태블릿에 기록하기도 합니다. 몇 가지 심각한 단점이 있습니다.

  • 의료 종사자는 하루에 수십 명의 환자와 접촉해야 하므로 치료를 제공하는 동안 자세한 메모를 작성하는 것은 일반적으로 실용적이지 않습니다. 그 결과, 근로자들은 근무가 끝난 뒤에야 메모를 쓰게 됩니다. 그 지점에 도달하면 정신적, 육체적 피로로 인해 일반적인 코멘트만 녹음하고 싶은 유혹이 생깁니다.
  • 근로자들은 또한 환자 행동에 대한 세부 사항을 기억해야 합니다. 시간이 지남에 따라 정확하고 일관되게 기록하면 부정확한 정보가 더 큰 건강 문제를 진단하는 데 도움이 되는 패턴을 가릴 수도 있습니다.
  • 종이 기록은 단일 부서 내의 부서들 사이에서 쉽게 공유할 수 없으며, EMT, 응급실 직원, 보험 회사와 같은 다른 기관들과는 더더욱 그렇습니다. 노트북이나 태블릿이 중앙 데이터 저장소나 클라우드에 연결되지 않았다면 상황은 크게 나아지지 않습니다.

이러한 과제를 해결하기 위해 회사는 환자 정보에 접근하고 약물 분배와 같은 일반적인 이벤트를 기록하는 데 필요한 단축키를 제공하는 간소화된 데이터 기록 시스템을 만들었습니다. 이렇게 쉽게 접근하고 사용할 수 있으므로 환자와의 상호작용을 실시간으로 기록할 수 있습니다.

모든 데이터는 회사가 유지 관리하는 클라우드 시스템에 저장되며, 앱은 다른 전자 의료 기록 시스템과 통합되어 거주자 행동에 대한 포괄적인 종단적 관점을 제공합니다. 이를 통해 간병인은 보다 나은 치료 연속성을 제공하고, 안전한 과거 기록을 생성하며, 다른 의료 소프트웨어 시스템과 쉽게 공유할 수 있습니다.

의사 및 기타 전문가도 환자를 입원시키거나 다른 방식으로 환자와 소통할 때 이 플랫폼을 사용합니다. 환자가 어떤 시설에 가든 선호사항과 개인적 필요사항에 대한 기록이 함께 제공됩니다. 이러한 기술은 환자가 새로운 환경에 편안함을 느끼도록 돕고 회복 기간 등의 결과를 개선하는 데 도움이 될 수 있습니다.

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

차고에서 클라우드로, 그리고 쿠버네티스로의 여행

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

수년간 클라우드에서 운영한 후 회사는 빠르게 성장하면서 확장에 따른 어려움을 겪었습니다. VM을 사용하면 수직이 느리고 비용이 많이 들기 때문에 수평이 아닌 무한대로 확장해야 했습니다. 이러한 요구 사항으로 인해 컨테이너화와 Kubernetes가 가능한 솔루션으로 자연스럽게 이어졌습니다. 컨테이너화를 지지하는 또 다른 이유는 회사 개발자가 중단 위험 없이 애플리케이션과 인프라에 대한 업데이트를 자주 제공해야 한다는 것입니다. 여러 시간대에 걸쳐 환자 기록이 지속적으로 추가되면서, 고객이 즉각적으로 문제를 겪을 위험 없이 프로덕션에 변경 사항을 적용할 수 있는 자연스러운 다운타임이 없습니다.

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

교통 경로는 유연하면서도 정확해야 합니다.

팀은 AKS의 기본 Ingress 컨트롤러를 테스트했지만 트래픽 라우팅 기능이 회사 고객에게 필요한 방식으로 업데이트를 제공할 수 없다는 것을 발견했습니다. 환자 치료에 관해서는 모호함이나 상충되는 정보에 대한 여지가 없습니다. 예를 들어, 한 간병인은 같은 사건에 대해 주황색 깃발을 보고 다른 간병인은 빨간색 깃발을 보는 것은 용납할 수 없습니다. 따라서 주어진 조직의 모든 사용자는 동일한 버전의 앱을 사용해야 합니다. 이는 업그레이드와 관련하여 큰 과제를 제시합니다. 고객을 새로운 버전으로 전환할 자연스러운 시점은 없으므로 회사에서는 서버 및 네트워크 수준의 규칙을 사용하여 다양한 고객을 다양한 앱 버전으로 라우팅할 방법이 필요했습니다.

이를 달성하기 위해 회사는 조직의 모든 사용자를 위해 동일한 백엔드 플랫폼을 실행하며 조직 내 인프라 계층에서 세분화된 다중 테넌시를 제공하지 않습니다. 쿠버네티스를 사용하면 브라우저의 가상 네트워크 경로와 쿠키를 사용하여 트래픽을 분할하고 세부적인 트래픽 규칙을 적용할 수 있습니다. 그러나 회사의 기술 팀은 AKS의 기본 Ingress 컨트롤러는 필요에 따라 고객 조직 또는 개별 사용자 수준에서 작동하는 규칙이 아닌 백분율 기준으로만 트래픽을 분할할 수 있다는 것을 발견했습니다.

NGINX 오픈 소스를 기반으로 하는 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는 저장된 데이터를 1개월 동안만 보존합니다. 이는 많은 국가의 법률에서 요구하는 수십 년에 훨씬 못 미치는 기간입니다.  보존 기간을 늘리기 위해 필요에 따라 데이터 저장소를 확장하는 데는 엄청난 비용이 들었습니다. 또한 Azure 솔루션은 Kubernetes 네트워킹 스택의 내부를 볼 수 없습니다. NGINX Ingress Controller는 Layer 4 및 Layer 7 트래픽을 처리하면서 인프라와 애플리케이션 매개변수를 모두 모니터링할 수 있습니다.

성능 모니터링과 관찰을 위해 회사는 Grafana 시각화 엔진과 대시보드에 연결된 Prometheus 시계열 데이터베이스를 선택했습니다. Prometheus와 Grafana와의 통합은 NGINX 데이터 및 제어 평면에 미리 내장되어 있으므로 기술 팀은 모든 트래픽을 Prometheus 및 Grafana 서버를 통해 전달하기 위해 작은 구성 변경만 하면 되었습니다. 이 정보는 Grafana Loki 로깅 데이터베이스로 라우팅되어 로그 분석을 보다 쉽게 만들고 소프트웨어 팀이 시간이 지남에 따라 데이터를 보다 효과적으로 제어할 수 있게 되었습니다. 

이러한 구성은 문제 해결 및 버그 수정을 위해 매우 빈번하고 방대한 양의 데이터 샘플링이 필요한 사고에도 대비할 수 있습니다. 대부분 대형 클라우드 기업이 제공하는 애플리케이션 모니터링 시스템을 사용하여 이러한 유형의 사고를 해결하는 데는 비용이 많이 들 수 있지만, 이 사용 사례에서 Prometheus, Grafana, Loki를 사용하는 비용과 오버헤드는 최소한입니다. 세 가지 모두 안정적인 오픈소스 제품으로, 초기 조정 후 패치 작업 외에는 일반적으로 별다른 작업이 필요하지 않습니다.

코스를 유지하세요: 고가용성 및 보안에 중점을 둡니다.

이 회사는 항상 두 가지에 중점을 두었습니다. 가장 민감한 데이터 중 하나를 보호하기 위한 보안과 앱을 필요할 때마다 사용할 수 있도록 보장하기 위한 고가용성 입니다. Kubernetes로 전환하면서 두 가지 기능을 모두 강화하기 위해 몇 가지 변경 작업을 수행했습니다.

최고 수준의 가용성을 위해 기술 팀은 완전한 중복성과 단일 장애 지점이 없는 액티브-액티브, 다중 영역, 다중 지역 분산 인프라 설계를 구축합니다. 이 팀은 서로 다른 두 지역에 두 개의 Kubernetes 클러스터를 두고 N+2 액티브-액티브 인프라를 유지 관리합니다. 각 지역 내에서 소프트웨어는 여러 데이터 센터에 걸쳐 구축되어 가동 중지 위험을 줄이고 인프라의 모든 계층에서 장애가 발생할 경우 대응 범위를 제공합니다. 친화성 및 반친화성 규칙은 서비스 중단을 방지하기 위해 사용자와 트래픽을 즉시 실행 중인 Pod로 다시 라우팅할 수 있습니다. 

보안을 위해 팀은 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 팀은 이제 매일 또는 하루에 여러 번 코드와 인프라 업데이트를 제공하고 매우 세부적인 블루-그린 패턴을 사용할 수 있습니다. 예전에는 일주일에 한두 번씩 업데이트를 보내야 했고, 사용량이 적은 시간대에 업데이트를 보내야 해서 스트레스가 많았습니다. 이제 코드는 준비되면 제공되고 개발자는 애플리케이션 동작을 관찰하여 영향을 직접 모니터링할 수 있습니다.

결과는 전반적으로 긍정적입니다. 소프트웨어 개발 속도가 빨라지고, 개발자들의 사기가 향상되고, 생명이 더 많이 구해졌습니다.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."