Citus Health가 AWS를 사용하여 안전한 실시간 가상 환자 진료를 제공하는 방법

작성자: AWS Associate Startup Solutions Architect Vincent Zheng, AWS Startup Solutions Architect Manager Christine Samson

Citus Health의 공동 설립자이자 CEO인 Melissa Kozak은 Citus Health를 설립하기 전 8년 동안, 환자에게 정맥 주사 또는 피하 약물을 투여하는 가정 내 주사 요법 치료를 받는 환자들을 직접 치료했습니다. 간호사로 근무하는 동안 Kozak은 궁금한 점이 있거나 문제가 발생할 때마다 환자가 의료 서비스 제공자와 직접 연락할 도구가 부족하다고 느꼈습니다. Kozak은 환자의 IV 펌프에서 밤새 경고음이 울리던 순간을 회상했습니다. 당시, 당직 서비스에 연락했는데 세 번 착신 전환된 후 연결이 끊겨 투여 시간을 놓치게 되었습니다. Citus Health의 공동 창립자인 Shadid Shah는 디지털 의료 분야의 사고 리더로서 경력을 쌓으면서 다수의 전자 의료 기록 시스템을 구축하고 배포했던 경험을 바탕으로, 환자 중심의 커뮤니케이션 도구와 리소스에 대한 아이디어를 실현할 수 있었습니다.

운영 방식

Citus Health는 의료 서비스 제공자의 재무 실적에 긍정적인 영향을 미치면서 최상의 환자 경험을 제공하기 위해 의료 팀, 파트너 및 가족 간의 실시간 보안 협업을 지원하는 디지털 의료 혁신 스타트업입니다. 웹 및 모바일에서 액세스할 수 있는 이 애플리케이션은 환자와 의료 제공자에게 안전한 양방향 통신, 중앙 집중식 간호 기록, 문서, 일정 관리, 비디오 세션 등의 기능을 제공합니다. 또한 Citus Health는 기업이 AWS에서 실행되는 Citus Health의 마이크로서비스와 다른 애플리케이션을 통합할 수 있는 서드 파티 시스템 통합을 지원합니다. 예를 들어 전문 제약 회사가 Citus Health의 플랫폼과 통합하면 환자 본인 및 의료 서비스 제공자 모두와 문서 및 중요한 환자 정보를 주고받을 수 있으므로, 환자에게 필요한 약물을 보다 원활하고 쉽게 제공할 수 있습니다.

Citus Health에서 AWS를 활용하는 방법

Citus Health의 애플리케이션은 PHP, NodeJS, Angular 및 Ionic의 조합을 사용하여 구축됩니다. 이들 플랫폼은 AWS 인프라에서 실행되는 마이크로서비스와 API를 통해 상호 작용합니다. Citus Health의 웹 사이트와 마이크로서비스는 Elastic Compute Cloud (Amazon EC2) 시작 유형을 사용하여 Amazon Elastic Container Service(Amazon ECS)에서 호스팅됩니다. 애플리케이션이 성장함에 따라 이러한 컨테이너를 배포, 구조 및 확장을 관리하기가 갈수록 복잡해집니다. ECS의 컨테이너 오케스트레이션 기능은 구성 옵션을 간소화하는 동시에 어려운 작업을 처리하는 것을 목표로 개발되었습니다.

Citus Health는 실시간 메시징, 보안 인증 및 등록과 같은 기능을 제공하는 다중 마이크로서비스에 컨테이너를 활용합니다. Amazon ECS는 도커와 함께 사전 설치된 상태로 제공되는 Amazon EC2 클러스터에서 이러한 컨테이너의 배치 작업을 처리합니다. 또한 AWS Management Console을 통해 이러한 인스턴스의 확장, 모니터링 및 관리를 간소화합니다. 이러한 컨테이너가 있는 인스턴스와 Amazon ECS 간의 통신은 클러스터 내 EC2 인스턴스에 사전 설치된 ECS 컨테이너 에이전트를 통해 이루어집니다. Amazon EC2 시작 유형을 활용하면 이러한 마이크로서비스 컨테이너가 위치할 인스턴스 패밀리 및 크기와 같은 세부 옵션을 보다 효과적으로 제어할 수 있습니다. 인스턴스 패밀리, 크기 및 기타 구성 세부 정보를 Citus Health가 결정할 수 있으므로, 컨테이너 오케스트레이션의 이점을 활용하는 동시에 애플리케이션에 필요한 적절한 리소스와 용량을 확보하는 데 필수적인 인프라 관리의 특정 측면을 제어할 수 있습니다.

또한 Citus Health는 보안 인증, 보안 메시징 및 등록과 같은 작업을 처리하는 마이크로서비스가 포함된 프라이빗 서브넷과 같은 도구를 활용합니다. 이러한 API 서비스는 API가 다른 AWS 리소스 및 인터넷과 상호 작용하는 동시에 AWS 클라우드 외부의 외부 연결을 차단할 수 있도록 하는 Network Address Translation(NAT) 게이트웨이의 배후에 배치됩니다. 다른 프라이빗 서브넷에는 RDS에서 실행되는 PostgreSQL 데이터베이스가 있으며, 이 데이터베이스는 애플리케이션에서 생성된 데이터를 저장하는 데 사용됩니다. 네트워크 액세스 제어 목록(NACL)은 원치 않는 연결을 필터링하도록 모든 서브넷의 전면에 배치됩니다.

얻은 교훈

Citus Health가 AWS로의 마이그레이션을 처음 평가할 당시, 두 가지 주요 우려 사항이 있었습니다. 그 중 하나는 캐나다에 있는 고객 중 하나가 PIPEDA 규정을 준수하도록 하기 위한 데이터 주권 문제였고, 다른 하나는 관리형 서비스 제공업체(MSP) Rackspace에서 AWS로 마이그레이션하는 가장 쉬운 방법을 찾는 문제였습니다. 데이터 주권 문제의 경우 Citus Health는 어카운트 팀과 협력하여 PIPEDA를 준수할 방법을 결정했습니다. 규정 준수 및 보안에 대한 공동 책임 모델이 Citus Health에게 있어서 새로운 것은 아니었지만, PIPEDA가 AWS에서 구체적으로 어떻게 작용하는지에 대한 더 명확한 설명이 필요했습니다. Citus Health는 HIPAA 비즈니스 제휴 계약(BAA)이 PIPEDA를 포함하는지, 또는 PIPEDA를 준수하기 위해 어느 당사자(Citus Health 또는 AWS)가 더 많은 조치를 취해야 하는지 확신하지 못했습니다. 이에 Citus Health는 AWS 어카운트 팀 및 규정 준수 전문가와 만나 이 문제에 대해 논의했습니다. 이를 통해 공동 책임 모델이 여전히 적용되며, AWS가 클라우드의 보안 및 규정 준수를 담당하고, 클라우드에서의 보안 및 규정 준수는 Citus Health가 담당한다는 것을 알게 되었습니다. 또한 AWS Artifact를 사용하여 PIPEDA 규정 준수 표준과 관련한 보고서를 생성하고 AWS로부터 BAA를 받는 방법도 배웠습니다. 하지만 AWS가 고객 데이터를 옮기지 않는다는 내용이 어디에 있는지 알고 싶었습니다. 어카운트 팀, 규정 준수 전문가 및 Citus Health의 자체 변호사들이 협의한 결과, 서명한 AWS 이용계약 페이지에 해당 내용이 명시되어 있다는 사실을 알게 되었습니다.

또한 Citus Health는 데이터가 SNS를 통해 다른 리전으로 전송되거나 이러한 메시지가 저장된 휴대폰을 다른 국가로 가져갈 경우, 데이터가 어디로 이동하게 되는지 알아야 한다는 사실도 깨달았습니다. 아울러 이러한 시나리오를 고려하고 데이터를 캐나다 내에 유지하기 위해 어떤 서비스를 사용해야 하는지도 알아야 합니다.

마이그레이션 문제의 경우, Rackspace는 AWS에서 실행되며 고객을 위해 인프라만 관리합니다. 어카운트 팀과 협의한 Citus Health는 Rackspace에서 AWS로 데이터와 서버를 마이그레이션할 때 일반적인 방법을 사용할 필요가 없다는 사실을 알게 되었습니다. Rackspace는 AWS에서 실행되기 때문에 Citus Health는 Rackspace가 관리하는 AWS 계정 ID를 이미 가지고 있습니다. 어카운트 팀의 조언에 따라 Citus Health는 Rackspace에 직접 연락하여 계정 소유권을 Rackspace에서 AWS로 직접 이전함으로써 계정이나 플랫폼 간에 실제로 마이그레이션할 필요가 없도록 할 수 있는지 물었습니다. Rackspace는 이러한 작업이 가능하므로 초기 시작 단계에서 마이그레이션을 가속화하고 고객 측에서의 작업을 줄이는 데 도움이 될 수 있습니다.

Citus와 AWS의 협업

Citus Health의 여정 전반에서, 이 회사는 다양한 도구와 서비스를 활용하여, 회사의 고객과 비즈니스를 최대한 효과적으로 보호하는 방법을 배웠습니다. 보안은 항상 최우선 과제로 두어야 합니다. 내부적으로 Citus Health는 Bastion Host가 있는 별도의 VPC를 활용하여 원치 않는 연결을 확인하고 차단하는 동시에 승인된 연결을 허용하여 Bastion Host를 연결합니다. Bastion Host를 이용하여 DevOps 팀과 개발자는 VPC 피어링을 통해 기본 VPC의 리소스에 접근할 수 있습니다. 두 개의 개별 VPC로 리소스를 분리하면 리소스를 격리하고 또 다른 보호 및 분리 계층을 추가할 수 있습니다. 각 VPC의 가상 방화벽 역할을 하는 보안 그룹이 설정되었습니다. 애플리케이션은 승인된 API 호출을 통해 Citus Health의 마이크로서비스와 통신하면서 원치 않는 연결을 차단할 수 있습니다. NACL은 보안 그룹과 함께 작동하여 보안 계층을 추가합니다. 보안 그룹은 인스턴스 수준에서 작동하여 연결이 VPC 내 리소스에 도달하는 것을 방지하며, NACL은 이러한 리소스가 배치된 서브넷으로 들어오는 연결을 필터링합니다. 또한 NACL을 사용하면 연결을 명시적으로 거부할 수 있지만, 보안 그룹에서는 허용 규칙만 구현할 수 있습니다. 아울러 NACL은 무상태 방식으로 작동하이므로 명시적으로 허용하도록 정의되지 않는 한 트래픽이 거부됩니다. 또한 CloudTrail 및 IAM Analyzer와 같은 모니터링 도구는 누가 어떤 리소스에 액세스하는지 추적하는 데 도움이 되며, Citus Health가 외부 기관과 공유하는 리소스 및 역할을 추적할 수 있도록 합니다. 이 모든 기능은 환자와 환자의 정보를 보호하는 동시에, Citus Health의 서비스를 이용하는 다른 의료 서비스 회사도 보호되도록 보장합니다.

지속적인 성장에 맞추어 Citus Health는 고객의 요구를 충족할 수 있도록 리소스를 확장해야 합니다. 처음에 Citus Health는 Rackspace에서 관리하던 기능들을 AWS로 이전한 후, 트래픽을 분산하기 위한 Elastic Load Balancer (ELB)와 함께 Amazon EC2 인스턴스만 설정했습니다. Citus Health가 가동한 용량은 현재 트래픽 및 수요를 지원하기에 충분했습니다. Citus Health는 처음에는 미국에만 배포되었으며 규모가 커지기 시작하면서 결국 캐나다 리전으로 확장되었습니다. 이러한 성장에 따라 원활한 경험을 지속적으로 고객에게 제공할 수 있도록 추가 용량을 늘리기 위한 수단으로 AutoScaling 기능을 구현해야 했습니다. 또한 Citus Health는 캐나다 리전 내에서 Amazon ECS를 활용하기 시작했으며, 애플리케이션을 분리하고 컨테이너 오케스트레이션을 활용하기 위한 방법으로 애플리케이션을 마이크로서비스로 분할했습니다.

또한 재해 복구를 지원하는 Amazon Relational Database Service(RDS) 인스턴스의 다중 AZ 환경도 설정했습니다. 데이터는 프라이머리 인스턴스 간에 동기식으로 복제되며, 프라이머리 RDS 인스턴스에 장애가 발생할 경우, Amazon RDS가 관리자의 개입 없이 예비 인스턴스로의 자동 장애 조치를 시작합니다. 환자에게 의료 서비스 제공자와 커뮤니케이션할 수 있는 방법을 제공할 때, 탄력성은 원활한 경험을 보장하며 가용성은 환자가 연결 상태를 유지하도록 하고 필요한 리소스에 대한 커뮤케이션 통로를 열어 줍니다.

결론

Startup은 매우 빠른 속도로 성장하며, 제품이나 서비스를 최대한 빨리 출시하고 싶어 하기 때문에 보안, 탄력성 및 가용성과 같은 세부적인 부분에 소홀하기 쉽습니다. Citus Health는 AWS를 통해 내장된 도구와 서비스를 활용함으로써 회사의 환경을 보호하고 서비스의 가용성과 복원력을 유지할 수 있었습니다. 보안 그룹, NACL, 로드 밸런서, AutoScaling, 다중 AZ 설정 등이 적절하게 구성되면 애플리케이션의 가용성과 보안을 유지하는 데 도움이 되므로, 장기적으로 고객에게 최대한 원활한 경험을 제공할 수 있습니다.