2025年1月18日（土）に開催された東京Ruby会議12で、GMOペパボの@buty4649、@yumu、@kenchanが登壇しました！
本記事では、発表の内容を振り返りつつ、当日十分に説明しきれなかった部分の補足や、後日談についてお話しします。
- @yumu Ruby×AWSで作る動画変換システム
- @buty4649 mrubyでワンバイナリなテキストフィルタツールを使った
- Regional.rb and the Tokyo Metropolis
- おわりに
@yumu Ruby×AWSで作る動画変換システム
発表の概要
発表では、minneにおける動画投稿機能の裏側で動作している動画変換システムについて、以下の3つの観点からお話ししました。
- 技術選定：SaaSではなく自前実装を選んだ理由
- 実装方法：RubyとAWSの各サービスを組み合わせたシステム構築
- 開発・運用：ローカル開発環境の整備から本番環境での安定運用まで
特に、Streamio FFMPEGとShoryukenという2つのgemを中心に、FFmpegを使った動画変換処理とAWS SQSを使った非同期処理の実装について詳しく説明しました。
内容の補足
発表後、いくつか質問をいただきました。ここでは、それらの質問について回答します。
アプリケーション側から、動画の変換が完了したかどうかをどうやって判別しているの？
変換後の動画の判別には、Active Storageの仕組みを活用しています。ActiveStorage::Blobで生成されるユニークなkeyを基にして、以下のような命名規則でファイルを管理しています。
original/ # オリジナルファイル
└── {key}
large/ # 変換後ファイル・高画質版
└── {key}
small/ # 変換後ファイル・軽量版
└── {key}
この命名規則により、アプリケーション側では元の動画のkeyから各バージョンの動画パスを容易に特定できます。また、オリジナルのファイルにはタグとしてステータス（ウイルススキャン完了、変換完了など）を付与しており、これをアプリケーション側から参照することで変換状態の確認も可能です。
別の似たライブラリと比べて、Shoryukenを選んだ理由は何？
aws-activejob-sqs-rubyの開発に関わっている方から、Shoryukenの選定理由について質問をいただきました。
今回の動画変換システムは本体のRailsアプリケーションから独立した形で構築したかったため、ActiveJobに依存しないShoryukenを選択しました。SidekiqもActiveJobに依存しませんが、発表でも触れた通り、インフラをAWSに統一したかったのでShoryukenを採用しています。
なお、動画変換システムとは別の機能で、ActiveJobのバックエンドとしてShoryukenを使用しているものもあります。
HLS変換はどうやって実現するの？
HLS（HTTP Live Streaming）への対応は今後の重要な課題の1つとして認識しています。すでにStreamio FFMPEGを利用して動画変換システムを構築していることから、HLSの実装でも引き続きこのgemを活用していく予定です。実際に以下のようなコードでHLS形式への変換が可能です。
require 'streamio-ffmpeg'
movie = FFMPEG::Movie.new('sample.mp4')
options = {
video_codec: 'libx264', # H.264コーデックを使用
audio_codec: 'aac', # AACコーデックを使用
custom: [
'-bsf:v', 'h264_mp4toannexb', # HLSに必要なストリームフォーマット
'-f', 'segment', # セグメント分割の指定
'-segment_format', 'mpegts', # セグメントフォーマットをMPEG-TSに設定
'-segment_time', '5', # 各セグメントの長さを5秒に設定
'-segment_list', File.join('stream', 'playlist.m3u8') # m3u8プレイリストの出力先
]
}
transcoder_options = { validate: false }
output_path = File.join('stream', 'a%03d.ts')
movie.transcode(output_path, options, transcoder_options)
ただし、HLS形式への変換は通常の動画変換よりも処理時間が長くなることが予想されます。そのため、処理の進捗状況をより細かく把握・通知できる仕組みの実装や、長時間処理に対応するためのワーカーの設定調整などの工夫が必要そうです。
後日談：Shoryuken gemの復活と今後の展開
発表時点で、Shoryuken gemはアーカイブされていたのですが、発表時に「Shoryukenアーカイブされちゃったの！？」という声をたくさんいただき、gem作者の方に直接コンタクトを取ってみました。その結果、アーカイブが解除され、現在は開発が再開されています！
私自身もcontributorとして開発に参加させていただき、テストの改善のためにlocalstackを導入するなど、日々改善を進めています。
動画変換システムを作ってみて、RubyとAWSを組み合わせると複雑な機能もスムーズに実装できることを実感しました。また、これまでgemを使う側だった自分が、開発する側としても関われるようになったのは大きな成長につながったと感じています。
これからも、minneの動画機能の改善と、Shoryukenの開発の両面でRubyコミュニティに貢献していけたらと思います。
@buty4649 mrubyでワンバイナリなテキストフィルタツールを使った
本発表では、mrubyでワンバイナリなCLIツールを作るということをメインテーマに実例と開発手法について紹介しました。 実例においては、私がOSSとして開発しているテキストフィルタツールのrfコマンドを紹介しました。rfコマンドはgrepやsedやawk、jqやyqといったツールと同等の処理を、Rubyで書けてそして少ないタイピング数で実現することを目標に開発しています。もし本発表で気になったらぜひインストールしフィードバックをいただけたら幸いです。
開発手法の紹介は、rfコマンドの開発で得られた知見をもとにmrubyを使ったCLIツール開発のいろはについて解説しました。具体的には、mrubyを使った開発の始め方や、CLIツールを作るためのノウハウやバイナリのマルチプラットフォーム対応、そしてGitHub Actionsを使ったCI環境の構築手法やVSCodeのおすすめ設定といった内容でした。 本発表を通じて、mrubyへの関心やCLIツール作成の魅力を感じていただけたら幸いです。
Regional.rb and the Tokyo Metropolis
Shibuya.rbを代表して登壇した@kenchanです。本セッションは、合計16個のRubyコミュニティの代表が登壇し、それぞれのコミュニティの成り立ちや、印象に残っている出来事などを話し、その後会場からの質問に答えるという流れで進んでいきました。
各コミュニティからの発表で一番興味深かったのは、Tokyu.rbとAsakusa.rbという2つのコミュニティについてです。日本でSeattle.rbのようなコミュニティを作りたいと立ち上がった2つのコミュニティが、今はまったく別のものになっているということと、その理由としてTokyu.rbはみんなに求めらていることを探していった結果であるという点はとてもおもしろかったです。コミュニティとしてマーケットインを徹底した結果とも言えるのではないでしょうか。
さて、今回は時間の関係もあって、Shibuya.rb担当として会場からの質問に答えることができなかったので、この場を借りて回答できそうなものに勝手に回答しようと思います。
Q. コミュニティを長く続けるコツは？
自分は「長く続けている」と言えるほど続けられていませんが、Shibuya.rb自体は「代替り」が何度か行なわれているコミュニティです。会場での回答でも「無理をしない」というお話がありましたが、オーガナイザーのエネルギーも無限ではないですし、休みたくなることもあると思います。オーガナイザーは困っていたら困っていると言う、コミュニティが続いて欲しい人はオーガナイザーに突撃する、そういう意識や行動がコミュニティが長く続くことに繋がるのではないかと思います。
Q. コミュニティを立ち上げたいと思っている人は何からするといい？
運営を一緒にできる仲間を募りましょう。一人ではじめるよりも仲間で始めたほうが、運営そのものも楽める可能性が高いと思います。また、既にあるコミュニティに参加して、オーガナイザーや運営の仲間を作るのもオススメです。
おわりに
発表を聞いてくださった皆さん、東京Ruby会議12の運営の皆さん、本当にありがとうございました。これからも、様々な関わりを通じてRubyコミュニティを盛り上げていきたいと思います。