Voicyのシステムアーキテクチャ
riddle_tec
アーキテクチャ選択の背景や意図
アプリケーションロジックはAWS、データ分析基盤はGCPを採用しています。
データ分析基盤でGCPを採用している理由はBigQueryを利用したかったからです。
アプリケーションロジックはサービス初期から変遷を繰り返し現在の形になっております。
プロダクトの立ち上げ時期はAWS Elastic Beanstalkを採用してJavaで実装されていました。その後開発生産性を上げるためにGCPのGoogle Kubernetes Engineにサービスを移し始めたのですが、途中で担当者の退職により移行プロジェクトが頓挫しました。
AWSとGCPの両方を運用してた時代を経て、メインのコンピューティングをAmazon Elastic Kubernetes Service に移すことを意思決定して、途中でJavaをGoでの実装に変更しながら、現在のインフラの状態になりました。
またデータベースはしばらくAmazon Auroraを利用していましたが、今後のスケール性とコストパフォーマンスのメリットがありTiDBに移行しました。
現在のアーキテクチャの課題と今後の改善予定
現在のアーキテクチャの課題は複数のサービスが同一のデータベースに接続しており、似たロジックを複数のサービスで実装しなければならず、スピードや品質面で問題がありました。
また中途半端にマイクロサービスを取り入れてしまったため、複数サービスに跨る実装時にオーバーヘッドが存在しており、開発生産性も低くなっていました。
それらの課題を解決するために、現在はモジュラーモノリスへの大型リファクタリンクを実施しており、アプリケーションのコアロジックを集約し、開発生産性をあげて、開発スピードや品質を上げようとしています。
riddle_tecAWS Elastic Beanstalkを採用してJavaで実装されていました。その後開発生産性を上げるためにGCPのGoogle Kubernetes Engineにサービスを移し始めたのですが、途中で担当者の退職により移行プロジェクトが頓挫しました。
あるある
riddle_tec基礎知識
はーん、ということはリアルタイム配信なのかな？
いやでも録音してるのかなあ？？？
気になったこと
1. TiDB なのか
Voicy って長いサービスの認識だったけど TiDB って移行したのかな？
ツール導入前の課題
・データベースにかかる金銭的なコストが高かった
・効果的な負荷軽減を実施できておらず、インスタンスのスペックを上げることでトラフィックを捌いていた
2023年4月 PoCを開始
2023年6月 PoCを終え、採用を決定
2023年8月 移行設計開始
2023年10月 移行作業開始
2024年4月 移行完了
Amazon Aurora MySQL からの移行だった様子。
何年続いているサービスかわからないが、auto increment key から移行したのはすごいな〜。
2. そもそも Voicy の音声交換はどうやってうごいてるんだ？
届いたものを音声変換して保存して配信しているとのこと。
ストリームで処理しているわけじゃなくて、収録したものを保存してくれるものっぽい。
触ってみようと思ったけどそもそも選考があるらしい
riddle_tecうーん、アーキテクチャ周りの資料があまり見つからないなあ。
あと音声系はコア機能だからなのか情報が全然ない