Home

技術日記Lamblog
フルサーバレスCMS: Lamblog 開発中Edit

概要

  • 一番安いコースのさくらのレンタルサーバーでずっと動かしていたWordPressを撤収した
  • 安いサーバーで動かすWordPressは動作が重くて使いたくならないね
  • ブログ以外の自分のサイトを、静的なサイトとしてFirebase上に置いたまま放置していた
  • git管理してコマンド一発で更新できるようにしたんだけど、やっぱりオンラインで更新できないと面倒くさいね
  • 何が欲しいのか考えてみた
    • サーバー管理したくない→サーバレスがいい
    • オンラインで気軽に更新したい→CMSにする
    • 重いのはいや→軽快に動作する環境を選ぶ
    • どうせ大してアクセスなんてないんだから0円スタート無料枠ありの従量課金がいい
  • というものを作って自分のサイトを移行することにした

Lamblogの構成

構成イメージ

AWS Lambda with Ruby 2.5

実行環境はAWS Lambdaです。

ちょっと前までは、周辺のミドルウェアが一通りセットになっていて、無料スタートしやすいFirebase押しだったんですが、Firebase Functionsは(日本から使うと)微妙に重いし、ちょっと古いnode.jsが標準でそれ以外を使おうとするとさらに制約が上乗せされるし、深く使おうとするとFirebaseからはみ出てGCP側のコンソールでごにょごにょする感じが分かりにくいし、その辺にうんざりして一押しから脱落しました。

一方のAWS Lambdaはいろいろな言語(特にRuby)が使えるし、(ちゃんとメモリを割り当てれば)日本で使っても軽快な動作だし、Firebase Functionsみたいに中途半端な隠蔽がないし(その分、最初からフルセットで見えているから初めて扱うときの敷居は高そう)、いまいち使いにくいAPI GatewayのREST API以外に、ALB直接マウントやAPI GatewayのHTTP API(beta)とか使いやすいHTTPマウントの方法が揃ってきて、だいぶ重しが取れました。

Rubyはまだまだ初心者に毛が生えた程度な習熟度なんですが、普通に動くコードを書けるくらいには使えるようになったんで、まあ練習がてら。

API Gateway HTTP API

LambdaをHTTPで公開するのに一番便利なのは、ALBに直接マウントしちゃうやり方だと思うんですよね。

ただ、ALBを作っちゃうと時間制の利用料金が発生しちゃって、個人でお手軽に運用するにはちょっとなーというのが唯一の欠点でした。まあALB 1個動かしたところで、月2〜3000円程度しか発生しなかった気はするし、1個のALBで複数のサービスをマウントできるから、税金的に払ってしまうのも悪くはないんですが。

API Gateway REST APIはAPI向けなんで普通のサイトをあの上で無理矢理公開する気にはまったくなれなかったんですが、最近HTTP APIというのが(betaだけど)でているんですね。で、ちょっと触ってみたらかつてのREST APIの欠点がだいぶなくなっていて、これなら個人が気軽にHTTP APIをサーバレスで公開するためのミドルウェアとして使いやすそう。

ただ問題は、API Gateway HTTP APIはHTTPSのサイトしか運用できないっぽいんですよね。まあ普通はそれで全然問題ないんですけど、過去のサービスとかを移行する場合とか、HTTPでのアクセスがあることもある程度想定しておかなければならないんで、せめてHTTP to HTTPSのリダイレクタくらいは仕込んでおきたいじゃないですか。ALBなら一瞬なのに。

CloudFront

というところで思いついたのがCloudFront。

Lambda+API Gateway HTTP API構成ならば、個人レベルではまったく問題ないレベルのハイパフォーマンス&スケーリング能力を持っているから、CloudFrontなんていらないよねーと思っていたんですが、こいつってHTTP/HTTPS両対応な上にバックエンド側へHTTP/HTTPS振り分けする能力も持っている。しかもCDNとしても使える(ついでかよ)。

CloudFrontも無料枠があるんで基本無料+従量課金で使えるから、こいつを使えばいいんじゃね。

と思ったら、実はCloudFrontの無料枠は最初の1年だけだった。くそー、この最初の1年だけ無料枠があるやつ分かりにくいなー。まあ完全従量課金でも個人レベルではたいした額にならないからいいんだけど。

あと、Lambda→API Gateway HTTP API→CloudFrontは、最終的には思った通りに動いたんだけど、結構はまりどころが多かった。ポイントとしては、

  • API Gateway HTTP APIのちょっとバギーな挙動に気をつける
  • CloudFrontの裏側は全体的にHTTPSで正しくつながるようにセットアップする
  • セッションCookieとかを維持するためにはCloudFront、API Gateway HTTP API、Lambdaまで正しくドメイン名(HTTP_HOST)が伝わらないといけない

というあたり。

Amazon S3

コンピューティング能力の話ばかり語ってきましたが、CMSとか使う際にはもう一つ重要なリソースがありますよね。もう一つというか、場合によってはコンピューティング能力よりも重要かも知れない。そう、データベース。

が、今回はデータベースは使っていません。だって個人のサイトで必要なデータなんて、今どきのコンピューティングパワーを考えれば、専用のデータベースアプリケーションが必要なほど複雑で巨大なデータなんて使わないし。

というわけで、データストレージはAmazon S3を使い、そこにすべてのデータを置いておくことにしました。ただ、さすがに毎回記事ファイル一つ一つをS3 APIごしになめて検索したのでは、ネットワーク的なスピードに問題が出そうなので、普段は1ファイルにまとめたインデックスファイルを使って必要な記事を検索し、その後詳細な記事ファイルを取得する感じにしておきました。これなら個人のサイトが扱う程度のデータ量ならば余裕で捌けるでしょう。

ちなみに私はむかーしむかし、PHPでブログツールを作る書籍を出したんですが、そのときもデータベースを使わずに、ローカルファイルシステム上に記事ファイルとインデックスファイルを置いて捌く構成にしました。三つ子の魂百までってやつですね(?)。ちなみにローカルファイルシステム上だったら、インデックスファイルなんてなくてもかなりのスケールまで動くとは思いますが。

ドッグフード食べながら開発してみます

ひとまず大まかに動くようになったんで、

の3サイトをlamblogに入れ替えてみました。

特にここは過去のwordpressからエクスポートしたデータをインポートして、全部で3000記事くらい突っ込んであるんで、負荷テスト的にもちょうどいいんじゃないでしょうかね。

そういえばかつてブログツールと言えば、RSS、Trackbackとかついているのが普通でしたけど、今更あんなの作る必要あるんでしょうかね。なんか別になくてもいいかなー感。

ソースコードは、 https://github.com/heavymoons/lamblog のdevelopブランチに公開しています。ドキュメントは全然まとめていないし、周辺ツール類もまだ作りかけなんで、私以外がセットアップするのはかなり難易度が高いとは思いますが。

Published At2019-12-31 01:07Updated At2020-01-01 03:44