AWSにはフルマネージドなNFSファイルシステムを提供するEFSがありますが、AWS Lambdaからマウントできるようになりました。
これをうまく使うと、ファイルシステムへの保存を前提とした古いアプリケーションを楽にクラウドにリフト（移行）することができます。
というわけで、さっそく、前世紀からインターネットで遊んでいた人でお世話にならなかった人は居ないであろうCGI RESCUE様のminibbs.cgiこと簡易ＢＢＳをサーバーレスに動かしてみました。みんなminibbs.cgiの書き換えでPerl覚えましたよね？
動いているもの
df6mbqlkt7.execute-api.ap-northeast-1.amazonaws.com
※インターネット老人会の治安が悪いので注意
※ここはそのうち忘れないうちに落とします。
レポジトリ
しくみ
まず、今回の新機能を使うためにEFSのボリュームを作ります。この手順は上のページに書いてあるそのままで大丈夫です。完全に同じ手順でやると /mnt/msg にマウントされるので、その下にデータファイルが置かれるように設定します。この当時のCGIスクリプトなので、minibbs.cgiを直接編集して上の方で変数に設定します。
$tmp_dir = '/mnt/msg';
これで、あとはこのminibbs.cgiをAWS Lambdaで動くようにすれば良いわけです。
そしてこのPerlのCGIスクリプトを動かすにはいくつかの道具を組み合わせていきます。
- カスタムランタイムでPerlを動かす AWS::Lambda
- AWS LambdaのインターフェースをPerl標準のPSGIに変換する AWS::Lambda::PSGI
- PSGIをCGIインターフェースに変換する Plack::App::WrapCGI
この3段階をハンドラ関数としてまとめたものが、上のレポジトリにあるhandler.plです。
use utf8;
use warnings;
use strict;
use AWS::Lambda::PSGI;
use Plack::App::WrapCGI;
my $app = Plack::App::WrapCGI->new(script => "$ENV{'LAMBDA_TASK_ROOT'}/minibbs.cgi", execute => 1)->to_app;
my $func = AWS::Lambda::PSGI->wrap($app);
sub handle {
$ENV{'TZ'} = "JST-9";
return $func->(@_);
}注意事項として、正しく動かすためには以下の設定も必要です。
- minibbs.cgiに実行権限が必要なので、
chmod +x minibbs.cgiしてからZIPファイルでデプロイが必要（コンソールからの編集不可） - 1行目のshebangが配布状態だと
/usr/local/bin/perlになっているので、/usr/bin/perlに変更する - URLをminibbs.cgi内に設定する必要があるので、先にAPI Gatewayを設定する（運用でカバー）
- あらかじめ空のデータファイルが必要なので、初回だけhandler.plで
touch /mnt/msg/data.cgiとかやっておく（運用でカバー その2）
このあたりをクリアすると、前世紀に普通に使っていたminibbs.cgiを、ほぼそのまま一般的な設定項目以外いじることなく、令和時代のサーバーレス環境AWS Lambda上で実行することができました。
運用でカバーした2点も、minibbs.cgi自体を少し直せばもちろん対応できるわけですが、今回はそういったプログラム本体の修正を一切せずに、そのままAWS Lambda上で動かす事ができるというデモンストレーションなので、上で紹介したperlのパスと変数以外は一切変更していません。
おそらく性能もさほどでないと思われますし、古いアプリケーションをそのまま動かしているので脆弱性対応は依然として必要ですが、まずは手軽に今動いているサーバ環境の運用コストを下げるために、このようなサーバーレス＋共有ディスクの構成は極めて有用です。あくまで「リフト＆シフト」のリフト策として、クラウドシフトのためのリソースをひねり出すために使うのが望ましいですが、カードの一つとしてこういったことがすぐに実現できるんだ！という紹介でした。
宣伝
