概要

本ブログのバックエンドの構成を紹介する。

EC2

リソース

バックエンドサーバとして t3.nano の EC2 インスタンスを使用している。 ec2-user のホームディレクトリにはバックエンドリポジトリの next-blog-app-backend をクローンしている。

$ tree next-blog-app-backend/ -I node_modules
next-blog-app-backend/
├── README.md
├── index.js
├── package-lock.json
├── package.json
└── posts
    ├── 1.md
    ├── 10.md
    ├── 11.md
    ├── 12.md
    ├── 13.md
    ├── 14.md
    ├── 2.md
    ├── 3.md
    ├── 4.md
    ├── 5.md
    ├── 6.md
    ├── 7.md
    ├── 8.md
    └── 9.md

投稿記事は DB ではなくマークダウンファイルで管理している。 記事を更新したときには

git pull

でファイル更新をしている。

プロセス

node index.js

を実行するプロセスをサービスとして登録する方法を記載する。

1. サービスファイルを作成する

サービスに登録するためにユニットファイルを作成する。

$ cat /etc/systemd/system/next-blog-app.service
[Unit]
Description=Next Blog Backend and API Application
After=network.target

[Service]
ExecStart=/home/ec2-user/.nvm/versions/node/v20.17.0/bin/node /home/ec2-user/next-blog-app-backend/index.js
Restart=always

[Install]
WantedBy=multi-user.target

2. デーモンをリロードする

ユニットファイルに変更を加えたらデーモンをリロードする。

sudo systemctl daemon-reload

3. サービスを起動する

サービスを起動するために次のコマンドを実行する。

sudo systemctl start next-blog-app.service

4. サービスを有効化する

サーバ起動時にサービスが起動するように設定を行う。

sudo systemctl enable next-blog-app.service

ALB

バックエンドへの HTTP リクエストを TLS 化するために ALB を使用している。

リスナールール

リスナールールはポート 443 のみ。

証明書とカスタムドメイン

証明書を ACM でリクエストし、Route53 のホストゾーンにエイリアスレコードを登録している。

ターゲットグループ

ヘルスチェックは常に失敗しているが、次の仕様によりルーティングは行われる。

ターゲットグループに異常な登録済みターゲットのみが含まれている場合、そのヘルスステータスにかかわらず、ロードバランサーはそれらすべてのターゲットにリクエストをルーティングします。

参考：https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/application/target-group-health-checks.html

料金

これだけなのに高い。Lambda に切り替えれば安くなると思う。 でもサーバを触ったり ALB を使ったりドメインの設定をしたいがためにこの構成を選んでいる。 いろいろ触りたいのでサーバーレスに頼りたくない。

一時期 $100 あったクレジットも底を尽きた。 これだけしかインフラ使っていないのに高すぎるし 1 円も入ってこないしやめたいけどやめたらつまらないから続けている。

まとめ

DB を使わずマークダウンファイルを置いておくなど課題はあるが面倒くさいのでとりあえず今のままでいく。