このサイトについて

目的

• 作った物を、1 つの URL で見せる場所を持つ
• 静的サイトで終わらせず、API・DB・CI/CD・監視まで含めて自分で設計し、運用する
• できるだけ費用を抑え、個人で維持できる構成にする

構成

フロントエンド

Next.js（静的 export）、TypeScript、CSS Modules。記事の Markdown は unified（remark / rehype）で HTML にし、Marp のスライドも表示する

バックエンド

Java 25、Spring Boot 4、Maven。AWS Lambda（arm64、SnapStart）で動かし、API Gateway（HTTP API）から呼ぶ

データベース

Aurora DSQL。IAM 認証で接続し、スキーマは Flyway で管理する

配信

独自ドメイン（Route 53、証明書は us-east-1 の ACM）。CloudFront 1 つで静的サイトと /api/* を同じオリジンに見せ、 セキュリティヘッダーと CSP を付ける。www と以前の URL は apex へ、以前の /blog/ はブログへ 301 で転送する

IaC・CI/CD

AWS CDK（TypeScript）。GitHub Actions から OIDC で AWS のロールを引き受け、長期のアクセスキーを持たない

テスト

backend は Spock と Testcontainers（PostgreSQL）、frontend は node:test、infra は Jest で CloudFormation のテンプレートを検査する

配信の流れ

テストは PR の CI で回し、main にマージすると Deploy が CDK でデプロイする（PR の CI が通っていなければ、Deploy でもテストを通す）。 マイグレーションが先に記事を DB に入れ、その後に frontend をビルドして S3 に置く。 ブログの新着を取り込むため、frontend だけは毎日ビルドし直す。

設計の判断

静的 export とビルド時のデータ取得

記事は DB にあるが、ページはビルド時に API から取得して静的な HTML にする。 閲覧は S3 と CloudFront だけで済み、ページを見るときに API（Lambda）は呼ばれない。 記事を main に入れると、push でデプロイが走ってページを作り直す。

Spring Boot on Lambda（SnapStart）

常時起動のサーバーを持たずに Java を使いたかった。SnapStart は公開したバージョンにだけ効くので、 API Gateway は $LATEST ではなくエイリアスを呼ぶ。arm64 にして x86 より安く動かしている。

Aurora DSQL

サーバーレスで、使っていない時間の費用がほぼかからない。PostgreSQL 互換だが制約も多い （DDL と DML を同じトランザクションに混ぜられない、インデックスは CREATE INDEX ASYNC、 1 トランザクションで変更できる行数に上限がある、など）ので、 SQL は DSQL と PostgreSQL の両方で同じに書き、テストは Testcontainers の PostgreSQL で回す。

記事はリポジトリの Markdown から

作品の記事は content/ に Markdown で置き、PR でレビューしてから入れる。 デプロイ時に migration Lambda が S3 のアセットから読み、DB に upsert する。 リポジトリから消えた記事は削除せず非公開にする。 記事が少ないうちは「公開中の記事が 0 件になる変更」をデプロイ側で止める安全装置も入れた。

ブログは別のサイトに

ブログは最初このサイトに載せていたが、別のサイトに移した。 記事を書くたびにこのサイトの API と DB を通す必要は無く、静的サイトだけで済むため。 API が返すのは作品だけにし、DB に入っていたブログの記事は削除せず非公開で残している。 トップページの「ブログの新着」は、ビルド時にブログのフィードを読んで作る （取れないときは区画を出さず、ビルドは止めない）。以前の /blog/ と /feed.xml の URL は、 CloudFront でブログへ 301 で転送する。

閲覧者の情報を持たない

Cookie もアクセス解析も使わず、データベースには記事しか置かない。 CSP のレポート先も置かず、閲覧者の情報が外へ出る経路を作らない。

つまずいた点

• 記事のアセットを migration Lambda に読ませる権限を Asset.grantRead で付けたら、 CDK のアセット用バケット全体への読み取りになっていた。infra のテストが見つけ、オブジェクト 1 つに絞り直した
• Marp のブラウザ用ヘルパーは読み込んだ時点で HTMLElement を参照するので、 静的 export の事前描画で落ちた。クライアント側の effect の中で動的に import するようにした
• SnapStart のスナップショットには環境変数の値が入るため、SSM のパラメータを更新しても反映されない。 パラメータのバージョンを環境変数に含めて、値を変えたら新しいバージョンが作られるようにした
• DSQL の public スキーマに GRANT USAGE を付けたら、マイグレーションが 0A000 で落ちた。 DSQL の public はシステムのエンティティで、PUBLIC には最初から USAGE があるので、この GRANT は要らなかった
• Lambda の zip を軽くするために tomcat-embed-* を外したら、Jakarta EL の実装（tomcat-embed-el）まで外れ、 Bean Validation のメッセージの組み立てで落ちた。デプロイが 3 回続けて失敗し、外すものを core と websocket に絞った
• GitHub の OIDC トークンの sub が、リポジトリの名前ではなく、所有者とリポジトリの ID を含む形（不変の sub）で届いた。 名前で書いた信頼ポリシーではロールを引き受けられず、最初のデプロイが止まった
• CloudFront に付ける証明書は us-east-1 の ACM にしか置けない。リージョンは東京にそろえたかったので、証明書だけを us-east-1 のスタックに分けた。 スタック間の参照を weak にしていたので、リージョンをまたいでも Fn::GetStackOutput で値を受け渡せ、crossRegionReferences は要らなかった
• 使っていない Lambda の zip を、CI が実行のたびに Artifact に保存していて、GitHub Actions のストレージの月の枠を使い切った。 枠は月の累積で数えるので、消しても戻らない。保存をやめ、CI も PR だけ・1 ジョブにして分数を減らした

結果

• PR でテストを通し、main にマージするだけで、ビルド、マイグレーション、デプロイまで自動で通る
• ページの配信は静的ファイルだけなので、アクセスが増えても API（Lambda と DSQL）の呼び出しは増えない
• 記事は Markdown と PR で管理でき、CMS を別に持たない

ソースコードは今のところ非公開だが、作り方の記録はブログ ↗に書いていく。