また技術話です😅
サマリー
音声ファイルのアップロードを速くするための改善が行われ、特にリッスンサービスでの音声データの処理方法が改良されます。この変更により、アップロード速度が向上し、ユーザーの利便性が高まります。
音声ファイルアップロードの背景
おはようございます。1月25日土曜日の朝です。 土曜日になりましたね。
今日は奈良県の 南の
飛鳥村の方で 四部隊100っていうレースが
始まります。 そちらも息吹を使ってもらっていて、
桑原くんが昨日から習い入りして現地に行ってますけど、
ちょっと今回は桑原くんにお願いをして、 僕は京都で
過ごしております。 そしてですね、今朝はちょっと朝から不具合の対応をしてまして、
昨日ね、リッスンのエピソード作成画面のファイルのアップロードの高速化っていうのを
この何日かずっと取り組んでまして、 それでだいぶ高速化できたかなということで
変更を本番にアップデートしたんですけど、 その影響で
ファイルのアップロードの方は大丈夫だったんですけど、 一部の環境のスマホ、iPhoneとかかな、一部の環境の
ブラウザ録音した音声が、 なんかアップロードされてるはずが再生されないみたいな
状態になってまして、 皆さんにちょっとご迷惑をおかけしてしまいました。
アップロード速度の改善
すみませんでした。 いろいろご指摘いただきまして
ありがとうございます。 まあちょっとね、そういう
不具合もあったんですけど、 だいぶ高速化は
できたと思います。 早くなったんじゃないかな。
ちょっとね、今日この 僕が今収録してるやつも
WAVファイル、WAVファイルのままで アップロードして
どれぐらい早くなったかなっていうのを 実際に試してみたいと思いますけれども
まあ結構、高速化できたんじゃないかなと 思っています。
今年はね、アプリソフトウェアをどんどん変えて、 新機能をつけていくっていうよりも、ちょっと下のレイヤーといいますか
なんかそのインフラレイヤーの作業を 結構やってまして
本当なんか、年初にね、パソコン組み立ててみたいな そのハードウェアをいじり出したっていうのも
歓喜してるかもしれないですけど、 ネットワークとかね、いろいろそういう
どこにデータを置いて、どういうふうに 高速化するかみたいなことを
ちょっと取り組んでまして、表向きは サービス使っている分にはそんなに変わらないんですけど
裏側では実は別の場所にファイルが 保存されるようになったりとか、別の回線を使って
ファイルがやり取りされるようになったりして、 そのおかげでちょっと早くなったりとか
スケールできるようになっていくというような 基盤を整えようという取り組みをしています。
今回のアップロードの高速化なんですけども まぁちょっとまたね技術的な話にはなってしまいますけれど
基本的にね、リッスンの音声ファイルとか そういうファイルっていうのは
ストレージサーバーみたいなところに置くんですよね。 これがオブジェクトストレージと言われるような
ストレージサーバーで。 基本的にはというか、よく使われるのが
AmazonのS3、シンプルストレージサービスなのかな。 S3っていうのがありまして、これが結構
メジャーなんですけど、そのAmazonに限らず いろんな会社がそのS3互換
ストレージみたいなものを提供していまして。 リッスンの場合もS3も一部使ってますが、別のね
さくらさんのストレージも使っているという形で、 いくつかのストレージを使っています。
今回の改善っていうのはちょっと解説すると、 普通はね、音声ファイルをアップロードしようと思ったら
一旦そのリッスンのサーバーに音声のデータを アップロードして、それを受け取ったサーバーが
その音声ファイルのデータをそのストレージサーバーというところに さらにコピーをして
で、そちらの方で配信が始まるというような感じになるんですけども
これをですね、どうにか、結構エピソード作成画面待つじゃないですか。 しかも1回ファイルを選択したら勝手に1回アップロードが始まって
一旦サーバー側にファイルが送られるんですけど、その後公開ボタンとか 押すともう1回同じくらい待たされるっていう
のがあって、あれをどうにかできないかなと前から思ってたんですけど あれは何が行われているかというと、一旦あの
ファイルを選んだ 時点でデータがサーバー側に自動的に送られるんですけど
その送られたデータをそのストレージサーバーの方にさらに サーバー側で送っているということで、ファイルの
転送というかデータの送信が2回発生しちゃっていたんですよね まあ構造上ある程度仕方ない、その
ファイル置き場としてね、その受け取っている web アプリケーションが動いているサーバーじゃなくてストレージサーバー
っていうところに ファイルを置く以上ある程度仕方ないとはいえ
どうにかできないかなと思って
やってたんですけど 今回それをね、どうにかしてというか
そのブラウザーから音声ファイルを選択した瞬間に自動的に
データが送信され始めますけど、いきなりそのストレージサーバーに直接クライアント、クライアントというかブラウザから
送信が行われるという風にすれば まあもういきなりね最終のその公開される
保存先のところにデータが置かれて その置かれたデータの情報をサーバー側で受け取って
ここに置かれているのでということで、ちょっと公開に必要な操作をちょこちょこやって
そのままでパッと処理を終えるっていうことをすればね
だいぶ高速化できるんじゃないかということで 取り組んでいたんですけれども
まあまあ大変で、そうですよねそのブラウザーが通信している相手と
ファイルの置き場所というか送信先が変わるっていうことで
まあそのこと自体もちょっと
まあちょっと難しさがありますし さらにね1回その音声ファイルっていうのは
ちょっと解析をしてね 例えば再生時間は何分何秒ですとか
ファイルサイズはこれぐらいですとか ビットレートはこれぐらいですかみたいなことを調べたりとか
あとはノーマライズのフィルターをかけたりとか そういういろいろな処理が走るので
結局もう1回そのサーバーに音声ファイルを持って行って 変換処理を行ってもう1回ストレージにアップし直すとか
まあいろいろ処理が割と複雑な処理が後ろ側で
走っていまして まずはあの最初のアップしたそのままのファイルをストレージに置いて
一旦ブラウザーはさっさと 画面が映ると次の画面に映るっていうことをやっておきながら
後ろ側で必要な処理を 順番に
走らせていくという非同期でね 行うというようなことをそれは今までもやってたんですけど
そこの処理のプロセスとかもちょっと 進み方が変わるのと
これまで 受け取った側でやってたことも新しい場所であったりとか
ありまして まあ登場人物がとにかく多いんですよねそのブラウザーと受け取っているサーバーと
ストレージサーバーとさらに非同期処理を行うサーバー
ワーカーのプロセスが走っているサーバーとって4つぐらいのサーバーが連携して
動いているような構成になっているんで その処理をね
ちょっと情報の流れというかデータの流れを ごろっと変えるっていうのが
今後の展望
まあまあ結構 大変でして
大変というのもあるしその検証が難しいんですよね あの自分のパソコンでテストしたらうまくいってても
本番環境で サーバー
出てくるサーバーがね4つになるとちょっと思わぬことが起きたりとか いろいろありまして
まあちょっと苦労しましたけど 無事動いたんじゃないですかね
はいちょっとねあの昨日は不具合もあってご迷惑おかけしましたけど
今のところ動き出したのかなと 思ってます
早くなってたらいいなっていうのと 本当ねこういうのって
あのもともとはね不具合なく動いていたので 何もしなければね別に不具合は発生することはあんまりないので
まあ新しいことをやろうとするとこうやって不具合がちょっと残ってしまったりして ご迷惑をおかけして
うーってなって 何があかんのやろみたいな感じでね
まあちょっと 早朝から
辛い思いをしながら どこだどこだと思って探して直したりみたいなことがあったりするんで
まあしんどいこともありますけど ただね
何もしなければ改善はしていかないんで やっぱり
新しいことを そのしんどいことが起きるかもっていうので躊躇するっていうのもなんか
違うなと思うんで 本当は不具合なんかないほうが一番いいんですけど
あのはいどんどんどんどん良くしていくっていうのを まとめないようにはしたいと思ってますので
お付き合いいただければと 思います
今年入ってね1月入って まずはダウンロード側の音声を再生する方の改善を結構やりまして
ちょっとその 音声配信サーバーの変更とか増強とか高速化とかを行って
あと画像ですね 画像ファイルの表示の高速化とかも行って まずはそのダウンロード側
音声や画像をダウンロードする環境を だいぶ整備してきたんですけど
次はそのアップロード側ですね 今回その音声ファイルと あと同時に画像ファイルもなんですけど
アップロードを早くして さらに快適に使ってもらうようにしたいということで
やってきてます 変化をもし感じられたら教えてください
はい ということで
ちょっと不具合もありましたけど 音声ファイル
アップロードが早くなりましたっていうのと ちょっとねその裏側の
工夫と言いますか こんな仕組みなんですっていう
お話でした 今日はねちょっと
僕の方は お客さんが
来る予定なので この後ちょっとお会いして
お話をするのを楽しみにしています それではまた
12:33
スクロール