AWSサーバーレスで2,504人のゲノムを1.5秒で検索？CSIROのsBeaconアーキテクチャを徹底解説

なぜこのアーキテクチャに注目すべきか

ゲノムデータの取り扱いは、一般的なWebアプリケーションとは根本的に異なります。1人のwhole genomeは圧縮状態でも1GBを超え、mega-biobank規模のコホートは数百万人単位です。さらに臨床診断・治療目的が加わると、「高速・安全・低コスト」の3つを同時に満たす必要があります。

豪州国立科学機関（CSIRO）が開発した sBeacon（Serverless Beacon） は、この課題に正面から取り組んだソリューションです。GA4GH（Global Alliance for Genomics and Health）のBeaconプロトコルを本番運用レベルで実装しており、興味深いのはそのスタック構成です。専用のデータベースクラスタも、GPUインスタンスも使いません。Amazon S3 + Lambda + DynamoDB + Athena というサーバーレス4種の組み合わせのみで完結させています。

本記事では、sBeaconがどのようにこの規模を処理しているのか、そして実務でこのアーキテクチャを参考にする際の注意点を整理します。原文はAWS Architecture Blogに掲載された根拠資料を併せて参照してください。

核心設計：データを移動せず、インデックスのみを移動する

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）のみが載ります。

性能・コスト、そして日本での適用文脈

実測ベンチマーク（1000 Genomes chr1、2,504サンプル）

クエリ時間がvariant数にほとんど影響されない点は印象的です（4件→400件返却でも1.5秒台を維持）。fan-outが並列動作するためです。

日本での適用文脈

日本でこのアーキテクチャを参考にする際の注意点を整理します。

• 個人情報保護法・次世代医療基盤法: ゲノムデータは日本でも「要配慮個人情報」に該当します。sBeaconのfederatedモデル（各機関が自身のS3バケットを所有）は規制対応に有利ですが、国内医療機関・研究機関間のデータ共有には別途倫理審査と匿名加工処理パイプラインが必要です。
• リージョン選択: ap-northeast-1（東京）リージョンでS3・Lambda・Athenaはすべて利用可能ですが、Athena CTASのコストはリージョンごとに異なります。原文はap-southeast-2（シドニー）基準なので、国内コストは再計算が必要です。
• 国内SI環境: 大規模ゲノムプロジェクトは通常、国の研究開発事業として進行します。TerraformベースのIaCは監査対応に有利ですが、Cognitoユーザープールは国内認証基盤と統合できないため、別途ブリッジが必要です。

このアーキテクチャの限界と注意事項

正直に言えば、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. 多機関連携シナリオでのCognitoグループポリシー設計
4. 国内規制環境に合わせた匿名加工レイヤーの追加検討

まとめ

sBeaconは「サーバーレスでゲノムを扱う」という発想自体が新鮮なケースです。データを中央集約せず、原本は各機関のS3に置いたままインデックスとメタデータのみを共有する設計は、ゲノムに限らず規制の厳しい他ドメイン（医療、金融）にも示唆に富みます。

ただし、fan-outベースのアーキテクチャにおける同時実行数・throttle管理、全ゲノム範囲クエリの限界は必ず認識した上で臨むべきです。「月0.4ドル」という数字だけを見て安易に導入すると、cold startとthrottleで足をすくわれる可能性があります。

併せて読みたい記事

• データサイエンス行動面接、技術力だけでは落ちます — 実務面接官が教える3つの合格戦略
• Reactの未来が変わる 独立財団の設立と新しい技術ガバナンス