文字起こし基盤の信頼性

Transcript

1. ⽂字起こし基盤の信頼性 2026/07/23 Tamachi.sre#5 SRE NEXT After Party Special abnoumaru, IVRy Inc.
2. ⾃⼰紹介 id: abnoumaru Engineering Manager, SRE - - 経歴 - 2024年10⽉⼊社 - 2025年1⽉からSREのリーダー - 2026年からSREのEngineering Manager 最近ハマってること - setlog 2
4. プロダクト IVRとAIであらゆる電話対応を効率化 「アイブリー」 4
5. もくじ 1. ⽂字起こし基盤について 2. 壊れにくくする 3. 直しやすくする 5
6. ⽂字起こし基盤について 6
7. 通話⽂字起こし 通話後の⾳声をテキスト化 活⽤の例 - 聞き逃しや認識のズレを防⽌ - 電話対応の振り返りやフィードバック - ⽂字起こしされたデータは分析にも活⽤ 7
8. 既存の⽂字起こし基盤の課題 可⽤性、復旧しやすさ、柔軟性の課題が顕在化しはじめていた - キューの持ち⽅ - 失敗した処理の把握と復旧作業の複雑さ - 機能追加の難しさ 8
9. 刷新の機運 とある機能を追加する機会があった SREとして基盤の刷新をしながら既存の課題を機能追加する選択をした 詳細はAdvent Calendar 2025 に記載 👉 https://note.com/abnoumaru/n/n745d03624421 9
10. 新しい⽂字起こし基盤の⽅針 AWS Step Functionsを利⽤して、 実⾏状態を管理しやすく柔軟に機能追加できるパイプラインを⽬指した いまならAWS Lambda Durable Functionsも選択肢 10
11. 新しい基盤の特徴 - ⾒やすさ - パイプライン全体を視覚的に理解 - 実⾏状態の管理と把握ができる - 直しやすさ - Redriveがデフォルトで備わっている - ログ改善によるトレーサビリティの向上 - 柔軟性 - 新しい機能を分岐で追加しやすい - 処理毎にLambdaの⾔語を選択できる 11
12. イメージ図 12
13. 壊れにくくする 13
14. 外部のAIサービスを利⽤するということ Pros 😆 Cons 😭 ⾃分たちでリソース管理することなく ⼤量のリソースが必要な処理を APIのリクエストで実現できる こちらの都合とは関係なく 不安定になることもある 14
15. 運⽤しながら挙動を把握してきた ⽂字起こし基盤ではAzureのSpeech-to-Textを利⽤ IVRyでは他にも様々な外部のAIサービスを利⽤している サービスに組み込んで使いながら そしてEmbedded SREがプロダクトと向き合うことで 失敗したときの挙動を把握し対処法を模索してきた 15
16. 素朴なリトライは⼤事 外部のAIサービスの不調の⼤半は⼀時的なもの(429/5xx/タイムアウト) こうした⼀時的な不調の多くはリトライで解消されている リトライはアプリレイヤーとインフラレイヤーで層を分ける⽅針 例えば - アプリ層はhttpx gemの:rate_limiter plugin Retry-Afterに従いリトライ インフラ層はStep FunctionsのリトライはLambda等のエラー インフラ層でアプリのエラーは原則リトライしない 16
17. フォールバックも選択肢 リトライで回復しない場合もあるのでフォールバック先の⽤意も⼤事 Azureもプライマリとセカンダリのリージョンでリソースを⽤意して エラーが継続する場合切り替える⼿法を推奨している ref: https://learn.microsoft.com/en-us/azure/ai-services/speech-service/resiliency-and-recovery-plan 17
18. 直しやすくする 18
19. 壊れたときの検知と直すスピードも重要 リトライやフォールバックも無限にできるわけではない このため壊れたときにどうするかも重要 異常に気づきやすい仕組み、そして直しやすい仕組みがあると便利 19
20. ジョブを直す難しさ Redrive で⽂字起こしのジョブに関しては再実⾏する⼿段が⼿に⼊った それでもジョブの再実⾏は難しい - 検知も復旧⽅法もバラバラだと職⼈技になりがち - ジョブを再実⾏したほうが良いか？というコンテキストも⼤事 - 単純にリトライしても直らない場合さらに情報が必要 20
21. 共通のジョブ基盤があると嬉しい 検知‧通知‧復旧⼿順...をジョブごとに整備するのは⼤変 ちょうど⽂字起こし基盤の開発中に IVRy社内で共通のジョブ実⾏基盤が作られた 旧基盤からの切り替え時に⽂字起こし基盤もここに載せることになった 21
22. IVRyのジョブ実⾏基盤 IVRyにはDSLでジョブを定義できるジョブ実⾏基盤がある 失敗時は通知が⾏われ、再実⾏に必要な情報はポータルから確認できる 情報の例 - ビジネス影響 依存関係 冪等性やリトライの情報 復旧⼿順 ジョブに関する情報がまとまり、通知や再実⾏の仕組みが整っている 22
23. ジョブ実⾏基盤の画⾯ 23
24. まとめ 壊れにくくする仕組みと直しやすくする仕組みで 信頼性を維持しやすくしている - 外部のAIサービスは不安定になる前提で うまく付き合う⽅法をみんなで運⽤しながら育ててきた - 共通のジョブ基盤に載せることで 失敗時の認知負荷を下げて素早く復旧できる仕組みを整えている 24
25. We are Hiring! 25