응급실을 위한 DynamoDB 설계 (액세스 패턴 우선)

저는 Amazon DynamoDB와 Vercel을 사용하여 응급실을 위한 AI 네이티브 환자 접수 및 분류(triage) 앱인 Solace를 구축했습니다. 이 포스트는 실수하기 쉬운 부분인 데이터 모델(data model)에 관한 내용입니다.

응급실(ED)에 DynamoDB를 사용하는 이유

응급실은 DynamoDB 워크로드의 교과서적인 사례입니다. 트래픽은 급증하거나 예측할 수 없습니다(조용하다가, 갑자기 구급차 6대가 오고, 다시 조용해지는 식입니다). 환자 대기열은 새로운 환자가 도착할 때마다 새로고침되며 의료진이 이를 계속 주시해야 하므로, 읽기(Read) 작업은 한 자릿수 밀리초(single-digit-millisecond) 이내에 완료되어야 합니다. 또한 액세스 패턴(access patterns)은 사전에 알려져 있습니다: ID로 환자 조회, 병원별 대기열 조회, 환자별 진료 기록(encounter) 조회 등입니다. 이것이 바로 DynamoDB가 설계된 형태이며, 관계형 데이터베이스(relational database)가 부하가 걸렸을 때 성능 저하로 벌을 주는 바로 그 형태입니다.

스키마보다 액세스 패턴 우선

저는 정규화된 관계형 스키마(normalized relational schema)를 DynamoDB에 그대로 집어넣지 않았습니다. 제품이 실제로 수행하는 모든 읽기 작업을 나열한 다음, 이를 중심으로 의도적인 멀티 테이블(multi-table) 설계를 구축했습니다. 약 30개의 테이블을 만들었으며, 모두 온디맨드(PAY_PER_REQUEST) 방식으로 설정하여 용량을 계획할 필요가 없도록 했고, 모두 하나의 고객 관리 KMS 키로 암호화했습니다.

가장 중요한 테이블은 다음과 같습니다:

• solace-patients: 파티션 키(partition key)는 patient_id이며, hospital_id(해시)와 created_at(범위)에 대한 GSI(Global Secondary Index)가 추가되어 있습니다.

이 단일 GSI가 실시간 대기열 역할을 합니다. 병원별로 쿼리(query)하고 도착 시간순으로 정렬하여 밀리초 단위로 결과를 얻습니다. 의료진용 콕핏(cockpit)은 새로고침될 때마다 이를 읽어옵니다.

중요했던 세 가지 결정

1. 트랜잭션 없는 정확히 한 번(Exactly-once) 입력. 연결이 불안정한 대기실 네트워크를 사용하는 환자는 데이터를 중복 제출할 수 있습니다. 분산 트랜잭션(distributed transaction) 대신, 클라이언트는 안정적인 멱등성 키(idempotency key)를 전송하고 저는 이를 TTL이 설정된 solace-idempotency 테이블에 저장합니다. 동일한 키가 들어오면 단 한 번만 처리되며, 재시도 시에는 캐시된 응답을 반환합니다. TTL은 24시간 후에 레코드를 삭제하므로 별도의 정리 작업(cleanup job)이 필요 없습니다.

2. 자동 만료되는 세션. solace-intake-nonces는 DynamoDB의 TTL을 세션 수명으로 사용합니다. 데이터베이스가 곧 가비지 컬렉터(garbage collector) 역할을 합니다.

3. Hot 및 Cold 데이터로 구분된 추가 전용(Append-only) 감사 로그. solace-audit-log는 쓰기 전용(write-only)이며, Hot 액세스를 위해 90일의 TTL을 가집니다. 또한 모든 레코드는 CMK로 암호화된 JSONL 형식으로 S3에 아카이브되며, Glacier로의 라이프사이클 전환(lifecycle transition)을 통해 HIPAA의 6년 보관 요구 사항을 충족합니다.

Vercel 측면

환자 접수용 SPA와 의료진용 터미널은 Vercel에 정적 에지 캐싱(edge-cached)된 셸(shell) 형태로 배포되어 AWS 백엔드(DynamoDB 앞단의 Lambda 기반 FastAPI)와 통신합니다. 병원의 불안정한 Wi-Fi 환경에서도 로딩이 빠르며, 브랜치 기반의 원자적 배포(atomic branch-based deploys)가 가능합니다.

결과적으로: 실시간 대기열과 EHR 매치 결과가 용량 계획(capacity planning) 없이도 한 자릿수 밀리초 내에 반환되며, 이 설계는 아키텍처를 재설계할 필요 없이 파티션(partition)을 추가하는 것만으로 하나의 응급실에서 여러 병원으로 확장할 수 있습니다.

이 콘텐츠는 H0: Hack the Zero Stack 해커톤 참가를 목적으로 제작되었습니다. #H0Hackathon