왜 이 아키텍처를 주목해야 할까요?

유전체 데이터는 다루기 까다로운 축에 속합니다. 한 명의 whole genome이 압축 상태로도 1GB가 넘고, mega-biobank급 코호트는 수백만 명 단위입니다. 여기에 임상 진단·치료 목적이 얹히면 "빠르게, 안전하게, 싸게"라는 세 마리 토끼를 동시에 잡아야 하죠.

호주 국립과학기관(CSIRO)이 만든 **sBeacon(Serverless Beacon)**은 이 문제를 정면으로 다룹니다. GA4GH(Global Alliance for Genomics and Health)의 Beacon 프로토콜을 그대로 구현한 프로덕션 레디 솔루션인데, 흥미로운 건 스택 구성입니다. 별도의 데이터베이스 클러스터도, GPU 인스턴스도 없습니다. 그냥 Amazon S3 + Lambda + DynamoDB + Athena, 이 네 가지 서버리스 조합으로 끝냅니다.

이 글에서는 sBeacon이 어떻게 이 규모를 감당하는지, 그리고 실무에서 이 아키텍처를 참고할 때 어떤 지점을 주의해야 하는지 짚어보겠습니다. 원문은 AWS Architecture Blog에 게재된 근거자료를 함께 참고하시면 좋아요.

AWS serverless architecture diagram for genomic data querying with Lambda and S3 Software Concept Art

핵심 설계: 데이터를 옮기지 말고, 인덱스만 옮겨라

sBeacon의 가장 중요한 설계 결정은 **"VCF 원본은 절대 복사하지 않는다"**입니다. 대신 tabix 인덱스와 메타데이터만 S3에 별도로 적재해서, 쿼리 시점에 htslib의 HTTP byte-range 요청으로 필요한 구간만 읽어옵니다.

1) 데이터 온보딩 흐름

# sBeacon 데이터 온보딩 의사 코드 (Python/Lambda)
def submit_dataset(request_payload):
    # 1. 사용자가 API Gateway로 VCF 위치 + 메타데이터 위치 전달
    vcf_locations = request_payload["vcfLocations"]  # S3 URI 리스트
    metadata_uri = request_payload["metadataUri"]

    # 2. Lambda가 메타데이터를 ORC 포맷으로 S3에 기록
    write_orc_to_s3(metadata_uri, bucket="sbeacon-metadata")

    # 3. Ontoserver(또는 Ensembl OLS V4)로 온톨로지 인덱스 생성
    ontology_index = build_ontology_index(metadata_uri)
    write_to_s3(ontology_index)

    # 4. Athena CTAS(CREATE TABLE AS SELECT)로 메타데이터 테이블 구축
    athena_ctas("CREATE TABLE ... AS SELECT ... FROM orc_source")

    # 5. 결과 테이블을 S3에 ORC로 재기록 (이후 쿼리용)
    return {"status": "indexed", "vcfLocations": vcf_locations}

핵심은 VCF는 원본 위치 그대로 두고, 메타데이터(질병 상태, 나이, 지역 등)만 인덱싱한다는 점입니다. 사용자는 민감정보가 노출되지 않도록 책임지고 관리해야 하고요.

2) 쿼리 흐름 (Variant Querying Module)

유전체 변이(Variant) 조회는 fan-out 구조로 돌아갑니다.

# Variant Querying Module - fan-out 패턴
async def perform_query(vcf_uri, region, granularity):
    # htslib의 HTTP byte-range로 필요한 구간만 읽음 (~1KB)
    # VCF 전체를 Lambda 메모리에 올리지 않음
    result = bcftools_view(
        vcf_uri,           # S3 URI를 직접 bcftools에 전달
        region=region,     # 예: "chr1:1000000-1010000"
        granularity=granularity  # boolean / count / record
    )
    return result

# Initiator Lambda가 splitQuery -> performQuery 순으로 fan-out
# 결과는 Initiator로 synchronous fan-in

여기서 눈여겨볼 부분은 bcftools에 S3 URI를 그대로 넘긴다는 점입니다. htslib이 내부적으로 Range: bytes=X-Y HTTP 헤더를 붙여서 S3 REST API에 요청하기 때문에, 원본 VCF 바이트는 해당 기관의 S3 버킷을 벗어나지 않습니다. Lambda 메모리에는 결과값(exists 여부, call_count, variant record)만 올라옵니다.

Developer analyzing genomic variant data with cloud-based serverless tools on terminal

성능과 비용, 그리고 한국 생태계에서의 시사점

실제 벤치마크 (1000 Genomes chr1, 2,504 샘플)

항목수치비고
Ingestion 시간18초1.1GB 압축 VCF, $0.00052
10,000bp 구간 쿼리1.52초400개 variant 반환, $0.00013
월 유지 비용 (idle)$0.03메타데이터 1MB + 인덱스 파일
1000회 쿼리 비용$0.33Lambda + Athena + DynamoDB 합산

쿼리 시간이 variant 개수에 거의 영향받지 않는다는 게 인상적입니다(4개 → 400개 반환해도 1.5초대 유지). fan-out이 병렬로 돌기 때문이죠.

한국 개발 생태계에서의 적용 맥락

국내에서 이런 아키텍처를 참고할 때 주의할 지점이 있습니다.

  • 개인정보보호법·생명윤리법 이슈: 유전체 데이터는 국내에서 "민감정보"로 분류됩니다. sBeacon의 federated 모델(각 기관이 자기 S3 버킷 소유)은 규제 대응에 유리하지만, 국내 병원·연구기관 간 데이터 공유는 별도의 IRB 승인과 가명처리 파이프라인이 필요합니다.
  • 리전 선택: ap-northeast-2(서울) 리전에서 S3·Lambda·Athena 모두 사용 가능하지만, Athena CTAS 비용은 리전별로 다릅니다. 원문은 ap-southeast-2(시드니) 기준이니 국내 비용은 재계산 필요합니다.
  • 국내 SI 환경: 대규모 유전체 프로젝트는 보통 국가 R&D 과제로 진행되는데, Terraform 기반 IaC는 감리 대응에 오히려 유리합니다. 다만 Cognito 사용자 풀은 국내 인증 체계(NICE/KCB)와 통합이 안 되니 별도 브릿지가 필요합니다.

이 아키텍처의 한계와 주의사항

솔직히 말하면, sBeacon은 만능이 아닙니다.

  1. 전체 게놈 범위 쿼리는 타임아웃: API Gateway 레벨에서 걸립니다. chr1만 해도 8%인데, 전체 게놈에 functional operation을 걸려면 아키텍처 자체를 재설계해야 합니다.
  2. 동시성 폭발 위험: 단일 fan-out 쿼리가 수백 개의 Lambda를 스폰합니다. burst 쿼리가 계정 동시성 풀을 고갈시켜 다른 함수를 굶길 수 있으니, ConcurrentExecutions 메트릭을 반드시 모니터링하세요.
  3. Silent failure: 동기 Lambda invoke는 throttle 시 자동 재시도가 없습니다. performQuery에서 429가 나면 결과가 조용히 유실됩니다. Throttles 메트릭에 CloudWatch 알람을 걸어두세요.
  4. 콜드 스타트: idle 후 burst 상황에서 지연이 붙습니다. Provisioned Concurrency로 완화 가능하지만 idle 비용이 올라갑니다.

다음 단계 학습 방향

sBeacon을 실제로 도입하려면 다음 순서를 추천합니다.

  1. terraform-aws-serverless-beacon 리포지토리를 Dev Container로 띄워서 1000 Genomes chr1 샘플로 직접 돌려보기
  2. Beacon API 스펙(GA4GH) 읽고 자체 데이터셋 스키마 매핑
  3. 다기관 federation 시나리오에서 Cognito 그룹 정책 설계
  4. 국내 규제 환경에 맞춘 가명처리 레이어 추가 검토

Cloud infrastructure visualization of distributed genomic database queries on AWS System Abstract Visual

정리하며

sBeacon은 "서버리스로 유전체를 다룬다"는 발상 자체가 신선한 케이스입니다. 데이터를 중앙에 모으지 않고, 원본은 각 기관 S3에 둔 채 인덱스와 메타데이터만 공유한다는 설계는 유전체뿐 아니라 규제가 강한 다른 도메인(의료, 금융)에도 시사하는 바가 큽니다.

다만 fan-out 기반 아키텍처의 동시성·throttle 관리, 전체 게놈 범위 쿼리의 한계는 반드시 인지하고 접근해야 합니다. "월 0.4달러"라는 숫자만 보고 덜컥 도입하면 cold start와 throttle에 발목 잡힐 수 있어요.

함께 보면 좋은 글

본 콘텐츠는 신뢰할 수 있는 출처를 바탕으로 AI 도구를 활용하여 초안이 작성되었으며, 편집자의 검토를 거쳐 발행되었습니다. 전문가의 조언을 대체하지 않습니다.