【要約】消えた通話をKinesis Video Streamsから救出する ― SQSを留守番電話にする設計 [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
開発者がAmazon ConnectとKVSを用いた通話録音・文字起こし基盤を構築中、サーバー再起動によりアプリ側の管理データが消失する問題に直面した。録音データ自体は残っているものの、どの音声がどの通話（ContactId）に属するかという紐付け情報が失われたことが致命的であった。
- ・永続化機能の実装前に、通話履歴の管理データが消失した。
- ・サーバーの停止により、処理中のイベント情報が失われた。
- ・アプリ側の記録とKVSの音声データの対応付けが困難になった。
// Approach
開発者は、アプリ側の記録が失われても「原本」であるConnectの履歴とKVSのアーカイブが残っていることに着目し、これらを突き合わせることで復旧を図った。また、再発防止策として、シグナリングとメディアの保持期間を一致させる設計を採用した。
- ・
SearchContactsAPIを用いて、Connectから正確なContactIdと開始時刻を取得した。 - ・KVSの
ListFragmentsとGetMediaForFragmentListを用いて音声素材を抽出した。 - ・フラグメント間の
ProducerTimestampの空白（20秒以上）を境界として、通話区間を特定した。 - ・特定した区間の時刻とConnectの情報を照合し、録音ファイルを再生成した。
- ・SQSのメッセージ保持期間を、KVSの保持期間（24時間）に揃える設定変更を行った。
// Result
設計の見直しにより、サービス停止時でもデータが失われない堅牢な基盤を実現した。録音を「原本」、文字起こしを「派生」と定義したことで、障害復旧の対象を最小限に抑えることに成功している。
- ・録音を「原本」と割り切り、復旧作業を「音声を置き直す」作業に縮退させた。
- ・SQSが「留守番電話」として機能し、サービス停止中の呼も起動時に自動処理されるようになった。
- ・SQSの保持期間を86400秒に設定し、KVSの音声保持期間との整合性を確保した。
Senior Engineer Insight
> 分散システムにおける「保持期間の不整合」という本質的な課題を突いている。シグナリング（SQS）とデータ本体（KVS）のTTLを揃える設計は、極めて実践的だ。リトライロジックの複雑化を避け、インフラの特性を活かして「留守番電話」化する判断は、運用コストと信頼性のバランスにおいて非常に優秀である。実戦では、各コンポーネントの生存期間の整合性を設計段階で厳格に定義すべきだ。