めもおきば 技術同人誌と記事のアーカイブ
About

Digital Appendix

『AIエージェントが見つけたサーバーレス』のデジタル付録

A-DATA-01 版 0.11.0

状態ストア、接続、長命ゲートウェイ

状態ストア、接続、長命ゲートウェイ

対象本文

第7章のdata model、database connection、connection proxy、auto-pause、streaming responseと長命connectionの置き場所を補います。

収集方法

2026年7月10日に、各社のmanaged database catalogではなく、選択と復旧に効く提供仕様だけを確認しました。具体的な接続上限はengine、size、region、accountで変わるため掲載せず、公式quotaと実測へ戻る入口を記録しています。

現在の答え

状態ストアはdata形式ではなく仕事で選びます。

仕事必要な要件代表的なmanaged分類
1件を整合的に更新transaction、constraint、isolation、復旧relational / transactional database
keyで大量に読み書きpartition key、conditional write、hot key対策key-value / document store
大きい生成物を保管immutable object、version、retention、lifecycleobject storage
全件・履歴を分析columnar scan、partition、batch/stream ingestionwarehouse / lakehouse
意味の近さで検索embedding version、index再構築、filter、recall評価vector index / search
変化を下流へ渡すordering、retention、replay、consumer offsetlog / stream / change stream

四社ともこれらの役割をmanaged serviceへ分解する方向に進みましたが、transaction、global distribution、serverless capacity、index、streamを一製品へ束ねる範囲は違います。製品数の少なさより、正本、派生物、再構築可能性、退出形式を先に決めます。

接続は有限な状態

FaaSやsandboxは急に増えますが、databaseのconnectionはmemory、process、transaction stateを持つ有限資源です。次の順で守ります。

  1. applicationのconcurrency上限をdatabaseの安全な接続席から逆算する。
  2. connection pool/proxyで短いtransactionを多重化する。
  3. session variable、temporary table、prepared statement等がbackend connectionをpinする条件を測る。
  4. timeout、retry、circuit breaker、credential refreshを復旧試験に含める。

Amazon RDS Proxyは、session stateへ依存しないtransactionほどbackend connectionを再利用しやすく、pinningが多重化を弱めると説明します。Google Cloud SQL connectors/Auth Proxy、Azureのdriver pooling・gateway、Cloudflare Hyperdrive等も接続確立やpoolingを助けますが、transaction semanticsと上限を消しません。

Aurora Serverless v2は、対応engine/versionでminimum capacityを0 ACUにすると、user connectionがない期間にauto-pauseし、接続要求でresumeできます。ただしRDS Proxyが関連付くとproxyがconnectionを維持し、auto-pauseを妨げる条件になります。pause可能なdatabaseとconnection proxyは、常に相性がよいわけではありません。

長命connectionは別の寿命へ

WebSocketや長いstreaming connectionを短命functionへ直接抱えさせると、request lifetime、deployment、scale-inに引きずられます。gatewayまたはstateful endpointがconnectionを持ち、functionはmessage単位で仕事をします。例はAPI Gateway WebSocket、Azure Web PubSub、Cloud Run WebSockets、Cloudflare Durable Objects WebSocket Hibernationです。ただしconnection duration、reconnect、ordering、backpressureは各サービスで異なります。

一次資料

記入例——生涯と再送の境界(参照アーキテクチャ)

書籍第7章7.5の状態台帳のうち、データの生涯と再送の境界に関する記入例です。問い合わせを読み、社内資料を検索し、返信案を作り、承認後にチケットへ書き戻す参照アーキテクチャを対象とし、法域・保持の値は参照例です。実案件では契約とデータ分類から置き換えます。

状態保持期限・削除責任暗号化・法域・機微度重複判定キー
問い合わせ・会話顧客契約に従い、会話ストア所有者が削除顧客データ。保存・転送時暗号化、顧客法域request_id
限定委任文脈短い有効期間。ID基盤が失効署名付き最小文脈。原トークンは保存しないrun_id
検索資料・返信案実行と承認の保持方針に従い、エージェント基盤が削除社内資料を含むため問い合わせと同じ境界run_id + step_id + version
承認監査方針に従い、承認基盤が削除承認者と対象のダイジェストを保護approval_id + subject_digest
書き戻し結果チケットの保持方針に従い、業務システムが削除結果本文は正本へ、履歴には参照を置くrun_id + writeback_step
ローカルな導出状態環境の破棄と同時。資格実体はスナップショットへ保存しないテナント境界外へ持ち出さない正本ではないため不要

記入用の雛形——状態台帳(空欄版)

書籍第7章7.5の状態台帳を自分の状態で書き出すための空欄版です。一状態につき一組を複製して使います。

状態名:
種類(永続/セッション/導出・一時):
正本の所在:
再生成可能性・費用:
整合性要件:
保持期限・削除責任:
暗号化・法域・機微度:
再送時の重複判定キー:
戻ってよい時点・待たせてよい時間:
バックアップの間隔と保存先の障害境界:
消失時の復旧手順:
最終復元試験の日付・所要時間・判定:

既知の未知

変更履歴

付録索引へ戻る / 書籍サポートへ戻る