2022/7 本ブログサイトをサーバレス化しました
以前、MariaDBからDynamoDBへの移行について紹介しましたが、今回は脱Lightsailしサーバーレスへ移行が成功したので紹介させていただきます。
なぜ脱Lightsail
ありがたいことに弊社ブログのアクセス数は右肩上がりで、最低価格のLightsailではいずれ捌き切れないことが見えていました。スケールアップさせても良いのですが、Lightsailのメンテナンスやリリース作業も若干ながらずっと手間がついてまわるのが気がかりでした。
そんな中、昨今流行りのサーバレス化に挑戦してみたいという欲が出てきました。 早速、雑に料金試算してみたところ、アクセス数が10倍になっても150円程度と今よりも安くなりそうでした。
他に懸念もなかったので、負荷・料金・技術(挑戦)的な理由から脱Lightsailに挑戦することにしました。
サーバレス化
サーバレスとは本当にサーバがなくなるという意味ではなく、サーバのOSや物理的な構築・メンテナンスなどの管理が減るアーキテクチャの俗称です。
今回は図のようにAPI Gateway, Lambda, Dynamo, S3で構成しました。 図の水色の部分が、ブログサイトとして根幹となる部分です。セキュリティを高める目的で、記事を執筆するライター向け画面は別API Gatewayとしました。
図の水色以外の部分は、バックアップや監視といった保守用の仕組みになります。 個人的には、こういった図を起こせばCRONや通知の仕組みも可視化しやすいところが、サーバレスのいいところだなと思いました。
また、Lightsailの時にはSSHログインしてデプロイしていましたが、今回CDKを導入しGithub経由でデプロイできるようにもしました。
本番と開発で気をつけたこと
上記でお伝えした構成は本番用の構成で、開発時の構成は別途検討が必要でした。 パターンとして、以下の３つを検討しました。
- 本番同様に、全てAWSに開発用のものを構成する
- 一部はAWS上に構成し、他はローカルで構築する
- 全てローカルで構築する
今回は「一部はAWS上に構成し、他はローカルで構築する」とするようにしました。
理由としては、根幹となるLambda部分とDynamoDB部分はローカルで動作できるようにしたかったからです。毎回Lambdaにデプロイするのは開発効率が下がりますし、DBを他の人と共有すると思い切った動作確認ができず品質に影響すると思ったからです。
また、Lightsailの時にはNode.jsのExpressフレームワークを使っていたこともあり、Lambdaはserverless-expressを使うようにしました。簡単にはいきませんでしたが、無事搭載できました。ExpressベースだとLambdaの起動・処理時間が長すぎて使い物にならないかとすごく心配していましたが、それなりの速度が出たので安心しました。
結果
5月までLightsailを利用していて、6月から脱Lightsailしました。
LambdaやS3等の料金は想定の範囲内でしたが、CDKデプロイにKMSが使われるようで、KMS費用が想定外でした。 それでも、Lightsailよりも1/4程度のコストに削減することができました。 開発している間、見積もり誤りしていてクラウド破産しないか？という不安がどこかにありましたが、一安心です。
最後に、脱Lightsail直後は、画像が表示されなかったり、サイトマップ考慮漏れてたりとトラブルもありましたが、その後は安定して稼働しています。 今回の対応は個人的に実績のない構成だったので大きな挑戦でした。不安や苦労もありましたが無事に乗り切れ、本当によかったです。