【AWS】個人ブログ構築してみた 技術選定編
こんにちは。
今回は、運営している個人ブログの技術選定についてまとめます。
技術選定では、主にコスト面・CI/CD面を重点的に考慮しました。
この記事では、選んだ構成やその理由について具体的に紹介します。
システム構成の全体像
ブログのシステム構成をざっと図で表すと以下のイメージです。
① Hugoでコンテンツをビルド
② GitHub Actionsで自動デプロイ
③ S3 + CloudFront (+ ACM)でホスティング
④ ユーザはHTTPS通信でブログにアクセス
という流れになります。
静的サイト (S3 + CloudFront) を選んだ理由
ブログのホストサーバーには、EC2常時起動やFargate等の選択肢もありましたが、S3単体で非常に安価にホスティングできる という点で静的サイトを選択しました。
ホストサーバー側および独自ドメインでは、200~300円程度/月で運用できる試算です。
・S3（Standard, Tokyo）料金 - 誤差レベル
・通信料金 - 誤差レベル
・Cloudfront料金 - 誤差レベル
・ホストレコード - 約80円(0.55USD)/月
・ドメイン費用 - 約100円/月
※S3+通信料金+Cloudfront<=100円と仮定。
Hugoを選んだ理由
他の静的サイトジェネレーターの選択肢も検討しましたが、最終的にHugoを採用しました。
・テーマが豊富で、すぐに着手できる
→ ウェブコーディングの知見があまりなかったので、ブログに合うテーマ（デザインモックのようなもの）から選択したいなと考えました。テーマを決め、そこから微調整することで素早く開発可能です。
参照：Theme - Hugo
・コミュニティが活発でトラブルに対応しやすい
→ GitHubのIssueやトラブルシューティング記事も割と上がっていたため、Hugoであれば自走できると判断しました。
GitHub Actionsを選んだ理由
ローカルからS3への静的サイトファイルのデプロイには、Github Actionsを使用していますが、Hugoプロジェクト管理とデプロイを並行して行うためです。
ブログの更新にあたり、S3へのデプロイと並行して、Hugo最新プロジェクトファイルは必ずGitHubにプッシュする運用にしています。
GitHub Actions上でプッシュとデプロイと管理してしまえば、最新版の管理とS3への反映を一元化できます。
これにより、いつ・どのバージョンをデプロイしたのかをGitHubの履歴で厳格に追跡でき、かつ最新プロジェクトのプッシュ漏れも防げます。
終わりに
特に個人ブログの場合、運用や固定コストが大きく負担となります。
だからこそ「なるべく管理しなくて済む」、「一元化する」仕組みを選ぶことが重要となります。
まだまだ改善の余地がありますが、今後さらにシステムの効率化が出来ればいいなと思っています。
この記事のように本ブログでは、特に運用面、コスト面、どのようにシステム選定したか、裏側のプロセスも紹介していきます。
それでは。
Tags