Slide 1

Slide 1 text

パイプラインの 
 並行化により音量正規化を 
 8倍高速化した話 
 2023/7/5 千田 航己 


Slide 2

Slide 2 text

© Voicy, Inc. 自己紹介
 ● 千田 航己 (せんちゃん)
 SRE/バックエンドエンジニア 
 ■ リソース管理 ● AWS ● Kubernetes ■ モニタリング ● Datadog ■ 基盤システム開発 ● 通知配信基盤 ● 音声処理基盤 ■ CI/CD ● CircleCI ● Argo CD

Slide 3

Slide 3 text

© Voicy, Inc. 自己紹介
 ● 千田 航己 (せんちゃん)
 SRE/バックエンドエンジニア 
 ■ リソース管理 ● AWS ● Kubernetes ■ モニタリング ● Datadog ■ 基盤システム開発 ● 通知配信基盤 ● 音声処理基盤 ■ CI/CD ● CircleCI ● Argo CD

Slide 4

Slide 4 text

© Voicy, Inc. はじめに
 ● 前提
 ○ Voicyではアップロードされた音源をサーバー側で加工している 
 ● 問題点
 ○ サービス規模の拡大に伴い処理が遅れるようになってきた 
 ○ 配信音源の品質に関わるため高速化したい 
 ● 対応
 ○ 並行に処理することで高速化 
 音量正規化処理が混雑していたので高速化した 


Slide 5

Slide 5 text

© Voicy, Inc. Voicyについて 
 音声プラットフォーム 
 Voicy
 サーバー
 パーソナリティが
 専用アプリで収録
 Voicy Recorder
 リスナーが
 専用アプリで聴取
 Voicy


Slide 6

Slide 6 text

© Voicy, Inc. 音量正規化とは 
 音量を一定程度にするための処理 
 小さい音
 大きい音
 ちょうどいい音量
 ちょうどいい音量


Slide 7

Slide 7 text

© Voicy, Inc. 従来のアーキテクチャ 
 ● 収録音源がアップロードされると、DBの対応するレコードのフラグが立つ
 オーディオ処理をバッチで定期実行 
 Batch Server (EC2) audio- processor DB ① 処理対象を取得
 ② 音量正規化
 をリクエスト
 HLS変換など
 処理対象のデータは
 フラグが立っている
 ③ 後続処理へ
 同期API


Slide 8

Slide 8 text

© Voicy, Inc. 従来のアーキテクチャの課題 
 混雑時に非常に遅い 
 Batch Server (EC2) audio- processor DB ① 処理対象を取得
 ② 音量正規化
 をリクエスト
 HLS変換など
 処理対象のデータは
 フラグが立っている
 ③ 後続処理へ
 1件ずつ直列に リクエストを送信 同期API


Slide 9

Slide 9 text

© Voicy, Inc. 従来のアーキテクチャの課題 
 混雑時に非常に遅い 
 Batch Server (EC2) audio- processor DB ① 処理対象を取得
 ② 音量正規化
 をリクエスト
 HLS変換など
 処理対象のデータは
 フラグが立っている
 ③ 後続処理へ
 短時間に大量の音 源がアップロードされ ることがある 1件ずつ直列に リクエストを送信 同期API
 処理が遅い音源があ ると待ちが長くなる

Slide 10

Slide 10 text

© Voicy, Inc. 解決策
 並行処理 & 処理状況をキューで管理 
 audio- processor ① 処理対象
 を取得
 ② 音量正規化
 をリクエスト
 HLS変換など
 ③ 後続処理へ
 Amazon SQS
 job-handler 同期API
 ● 処理中ステータスの管理 ● タイムアウト ● リトライ ● goroutineで並行処理

Slide 11

Slide 11 text

© Voicy, Inc. 負荷テストとキャパシティプランニング 
 ● audio-processorの負荷が上がるのでキャパシティの再設計が必要
 ○ job-handler
 ■ 並行数
 ○ audio-processor
 ■ Pod数
 ■ CPU
 ■ Memory
 処理速度とコストのバランス 
 audio- processor job-handler

Slide 12

Slide 12 text

© Voicy, Inc. 負荷テストとキャパシティプランニング 
 ● audio-processorの負荷が上がるのでキャパシティの再設計が必要
 ○ job-handler
 ■ 並行数 → できるだけ増やしたい 
 ○ audio-processor
 ■ Pod数 → 並行数に対応する数 
 ■ CPU → ひとつのオーディオファイルを処理するのに使用する最大数 
 ■ Memory → 用意したインスタンスの上限 
 処理速度とコストのバランス 
 audio- processor job-handler

Slide 13

Slide 13 text

© Voicy, Inc. むすび
 ● 前提
 ○ Voicyではアップロードされた音源をサーバー側で加工している 
 ● 問題点
 ○ サービスの成長に伴い処理の完了が遅れるようになってきた 
 ■ 直列処理
 ■ 時間がかかる音源があると後続の音源の待ちが長くなる 
 ● 対応
 ○ 並行に処理することで高速化 
 ○ 負荷テストとキャパシティプランニング 
 パイプラインの並行化によりオーディオ処理を高速化 


Slide 14

Slide 14 text

© Voicy, Inc. おまけ
 お気軽にフォロー/ご連絡ください 
 ぼくのTwitter: @thousan_da
 Voicyエンジニアによる音声配信
 voi-chord: https://voicy.jp/channel/1305


Slide 15

Slide 15 text

音声×テクノロジーでワクワクする社会をつくる