はやつ〜
フランケンPHP以外ですね、リスの開発で活用されている技術で、なんか差し支えのない範囲で私とかを伺えるといいなと思ってるんですけども。
私が個人的に興味があるのが、そのCloudflareっていうサービスがあると思うんですけども、なんかその辺とか伺えると嬉しいんですけど。
jkondo
そうですね、CloudflareはDNS兼キャッシュというか、CDN的な使い方ができるんで、
結構そちらで静的なファイルを配信には使い始めてますね。
何がいいかというと、無料で使える枠が結構大きいというか、結構無料で使えちゃうっていうのもあって。
今だとそうですね、画像とかRSSファイルとかはCloudflareを使ってますね。
はやつ〜
そうですね。
jkondo
一旦そのDNSのホストでキャッシュをしてくれて、CDN化してくれるんですけど、ないものは裏側に取りにくるんで、
そちらでさらに、例えば画像とかですと、今トップページとか、リストのトップページとか、いろんなところにポッドキャストの画像って出ますけど、
その表示のサイズに応じていろんなサイズの画像が欲しくなるんで、自動的にこのサイズの画像が欲しいっていうリクエストが来たら、
バックエンドでその画像をそのサイズで生成してどんどん返すっていうのをやって、
例えばトップページにたくさんのポッドキャストのアートワークが並びますけど、
あれだけの数を全部、元のポッドキャストのアートワークって規格上3000ピクセル四方なんで、すごい大きいんですよね、サイズが。
で、それを当初はオリジナルサイズで配信してたんですけど、すごく画像のサイズだけでもたくさんになってしまって、
割とスマホとかだとなかなか表示されないとか、ギガがすぐになくなるみたいなこともあって、
割とちょっと軽量化したかったんで、最低限表示に必要なサイズのものをどんどん用意して、
いろんなサイズ、今だと4種類から5種類ぐらいのサイズの画像があちこちで使われてるんですけど、っていうのがあって、
で、それをあらかじめ事前に準備するとなるとすごい大変なので、
動的に生成しながら返すっていうのをやりつつ、そのCDNでキャッシュするっていう感じで、
だから、クラウドフレイヤーのCDNが前面にあって、その後ろにリバースプロキシがあって、
で、そのリバースプロキシからさらに画像変換サーバーが2個ぐらい立ち上がっていて、
そちらにリクエストを分散しながら投げて、裏側で、そこでもちょっとキャッシュをしてますけど、
ないものはその場で生成して返すみたいな、3、4段ぐらいの構成になってる、
たりしますね。
はやつ〜
確かに、最初リスンを始めて番組いっぱい作ってた時に、画像ファイルでかいとめっちゃ通信重いなって思ったことがあって、
私の番組のやつは片っ端から超あらあらの画像に変えた記憶がありますけど、
jkondo
変えて頂いてたんですか、わざわざ、すみません。
はやつ〜
自分のやつを書いても大したあれはないんですけど、
jkondo
それが今はサービスの方でいい感じにして頂いているということなんですけど、
そこのサイズをいい感じにするのは、リスンの方の処理、プログラムを書かれた内容がやってるんですか?
はやつ〜
そうですね、フォーマットはかなりAV-1を対応してまして、軽量の画像フォーマットも最近WebPとか、
jkondo
いろいろあると思うんですけれど、一番最新の、一番しく率の高いのがAV-1っていう、
AV-1じゃない、AV-1は画像ですね。失礼しました。AVIFですね。AVIFファイルっていう、
AV-1の動画のエンコーディングがあると思うんですけど、そのフォーマットを元に画像版として作られているのがAVIFで、
使えそうなところはできるだけそれを使ってます。
で、ちょっとエンコーディングの方に負荷がかかるんですけど、めっちゃちっちゃくなるみたいな特性があるんで、多少そのCPUが使うんですけれど、
その画像変換サーバーのシステムもいろいろあって、いくつかパフォーマンス比べながら探して、探してというか比較したんですけど、
今、イメージプロキシーっていうやつを使ってますね。かなり早いです。
はやつ〜
なるほど。
jkondo
はい。興味ある方がいるかどうかは知らないですけれど。
はやつ〜
いやいやいやいや、めちゃめちゃ勉強になります。ありがとうございます。
jkondo
ちなみに、温度社は、リッスン以外に物件ファンとか、いぶきとか、他のウェブサービスも提供してるんですけど、
以前はそちらの、例えば物件ファンって月間で200万以上のアクセスがあって、かなりアクセスが多いんですけど、
そちらはそちらで別の画像変換サーバーを自分たちで立ててやってたんですけど、
今はそのリッスン側の、先ほどのイメージプロキシーの性能がかなりいいんで、物件ファンといぶきの画像変換も全部まとめてやり始めてます。
はやつ〜
そうなんですね。
jkondo
はい。
はやつ〜
リッスン単体での開発だけではないってことですよね。いろんなサービスをやられてて、
そこの水平展開というか、別のサービスへも展開することで、より効率化が行われてるっていうことで。
jkondo
そうですね。会社の中でのコスト削減というか、コスト圧縮ができるんで、
今、物件ファンのトップページとか見ていただいたら、ずらーっと物件のサムネイル画像が写真で並ぶと思うんですけど、
そのサムネイルのアドレスとか見ていただくと、リッスンの画像サーバーのアドレスになってる。
はやつ〜
ああ、そうなんですね。
jkondo
はい。
実は、実は。
はやつ〜
わかりました。ありがとうございます。
jkondo
今はちょっと画像の話を深掘りしてお伺いしたんですけども、
はやつ〜
クラウドフレアのDNS兼CDNっていう話でしたけども、
なんかね、CDNって昔は赤マイとかっていうのがすごい有名だったなというふうに記憶があってですね。
はい。
そういうエンタープライズ級というか、そういうサービスなのかなと思ってたところが、
最近はすごいCDNサービスがいくつか出てて、すごい勢いがあって、結構その利用されるようになってきてるなっていうのを感じててですね。
なんか逆にそのすごい利用されることによって、また最適なアーキテクチャが変わってくるというかですね。
なんかCDN、私の中ではそのCDNとかCacheとかっていうのはその静的なところはいけるけれども、
ウェブサービスみたいな感じでこう動的に内容作るとかってなったら、
結局オリジナルサーバーに聞きに行かないといけないから、あんまりメリット、弱くなってくるのかなって思うんですけれども、
そこをなんかそのあの手この手でいい感じにできるように進化してきているんでしょうか。
jkondo
そうですね。世の中の流れを語るほど僕は詳しくないですけど、
Listenとかでやっているのは基本的にそのURLが同じであれば同じファイルになるようにっていう。
だから例えばPodcastのエピソードのアートワークを画像を変えて再アップロードしたら、ファイル名がどんどん変わっていくようにしていて、
で、そうすればその何ですか、さっきおっしゃったその例えばエピソードID.jpgみたいなファイル名だとキャッシュされると困ったことになりますけど、
まあそういうのもどんどん変わっていくんで、新しいURLでアクセスしたら新しい画像が来るっていうことで、