LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

mruby + ngx_mrubyでアプリケーションを実装するという選択肢

はじめまして、技術基盤部の相原(kaihar4)です!

今回は、アプリケーションのクラウドサービスへの移行の一環で、 Amazon S3から取得した画像URLを含むファイルを元に、そのURLの外部画像を取得して返す機能mrubyで書き直してAWSに移行した話をしていきたいと思います。

この機能は元々モノリシックなアプリケーションの一機能として動いていたもので、これを切り出してAWSに移行するというのが今回私に与えられたミッションでした。 このアプリケーションは歴史が長く、その間ほとんどメンテナンスされていませんでした。 ディストリビューションは古くPHPのバージョンも4系、したがってそのまま持っていくという選択肢はなく、AWS上に新規にインスタンスを構築することになります。 弊社にはAPI部分をPHPからRubyに移行する方針があるということもあり、Amazon Linux上にRubyで書き直したこの機能を移行するというのが妥当な線でした。 しかしアプリケーションの性質上Unicornはプロセスモデル的に適さないですし、そもそもこれだけの機能のためにアプリケーションサーバを用意するということにも違和感がありました。

そこであがってきたのが、mrubyでこの機能を実装しngx_mrubyで動かすという選択肢です。 mrubyであればRubyと(ほぼ)同じシンタックスで実装することができ、それをngx_mrubyで動かすことでウェブサーバがそのままアプリケーションサーバとして振舞うことができます。 開発者を多く確保できるmrubyと弊社での運用実績があるnginx、これらを使う旨を運用チームへ相談の末、このプランで行くことに決まりました。

このように置き換わるイメージです。 元々キャッシュをするように作られていなかったので、この機会にRedisによるキャッシュも入れました。 f:id:nextdeveloper:20160810122507p:plain ロゴ: Amazon S3, redis

ここからはmrubyngx_mrubyについてと、いかにこれらでこの機能を実装したかについて書いていきます。 本エントリを通してmruby + ngx_mrubyでアプリケーションを実装するという選択肢の現実味を感じていただければと思います。

続きを読む