0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

インフラ費を極限まで抑えてWebアプリを構築した話

Last updated at Posted at 2025-01-26

Webアプリを作りたいけどどうしてもインフラ費がかかる。
だけど費用を意識しすぎると、本番運用に耐えられないくらい脆弱になってしまう。
ということで、極力インフラ費を抑えつつ、なんとか本番運用にも耐えれるよう工夫して、Webアプリの開発をしました。
費用について実質かかっているのは、お名前.comで発行したドメインの維持費(1年間で1700円くらい)のみ。

作ったものとコストの抑え方、インフラ構成について紹介させてください。

執筆者について

  • 都内のWeb系企業のバックエンドエンジニア。今回はバックエンドを担当
  • 都内の自社開発企業のエンジニア(開発リーダー)。今回はフロントエンドを担当

の2名。大学からの友人。

発端

友人との以下の会話が発端。

休日暇すぎるよね〜
→ じゃあ何か一緒に制作しようよ!
→ ついでに仕事にも活かせるといいよね〜
→ ついでに小銭も稼げると嬉しいな
→ じゃあWebアプリ作ろうよ!

作ったもの

"ratee(レイティー)"というWebアプリを作りました。(使ってみてくれたら嬉しいです)
https://ratee.nam-club.com/

rateeは、アカウント作成不要で誰でも気軽にアンケートを使って世の中の意見を探す・見る・集めることができるアプリです。

もちろん、モバイル版もあります。

サイトの説明はここまでにして、早速どのような工夫をしたのか紹介させてください。

開発方針

極力料金を抑える これに尽きます。
都内住みひよっこエンジニアにはAWSを贅沢に使う資金はありません。
抑えた上で、ユーザが増えた時にスケールできるよう考慮もしました。

使用技術・構成

バックエンド

項目 内容
クラウドサービス AWS
リソース管理 CloudFormation + SAM
API API Gateway + Lambda
DB DynamoDB
CI/CD GitHubActions
言語 Python
DNS お名前.com + AWS CertificateManager

フロントエンド

項目 内容
クラウドサービス Netlify
フレームワーク Nuxt3
DNS お名前.com + Netlify

システム構成

かなりシンプルな、API Gateway, Lambda, DynamoDBを使ったサーバレスの構成。

デプロイのフロー

GitHubへのPushをトリガーにGitHubActionsを動かし、swagger(S3にyamlを配置)とCloudFormationスタックの更新をする構成。
コードの記述を減らすために、API Gatewayはswaggerを読み込んでエンドポイントの定義を作成します。(参考

じゃあどうやってコストを抑えたの?

AWS無料アカウントを毎年作り直す

AWSにはサービスによっては1年間の無料枠というものがあります。
利用開始から1年が経つと使えなくなる無料枠です。
休日開発でなかなか時間も作れないので、当初から1年以上開発に時間がかかることは想定していました。
1年後もずっとその枠を使い続けるには、1年経ったタイミングで、一度アカウントを退会し、新たに作り直す必要があります。
しかし、退会した直後にそのアカウントが再度1から作り直せるわけではありません。90日間、閉鎖されたアカウントとして保持されています。
そこで、GMailのエイリアス機能を使います。
(通常のメールアドレスに加えて、hoge+エイリアス@gmail.comのような形で+エイリアスを付与することで別のメールアドレスとして使える機能です。「メールアドレス エイリアス」などで検索してみてください)

  1. 無料期限が切れそうになると、そのアカウントは退会する
  2. メールエイリアスを使ってアカウントを作り直し(例えばhoge+dev2@gmail.com

といった手順で既存アカウントの削除・新規アカウントの作成を行います。
もちろん、本番運用がスタートした後は、そのアカウントで上記手順を実施するとデータが消えてしまうため、行いません。あくまで駆け出し期間中のみ行う手順です。

開発期間中は1年経つ前にこまめに作り直しをおこなっており、いかにその手順を簡単に行えるかは重要でした。
そのため、必要は手順を全てREADME.mdに起こしました。
最終的に、アカウントの開設からWebアプリデプロイまでが、20分かからずできるようになりました。(実務で使うこはほとんどないであろうスキル。。)

無料枠が用意されているサービスを使用

API Gateway, Lambda, DynamoDB, GitHubActions, Netlifyは、どれも無料枠があり、個人開発環境での利用においては十分な枠があります。
唯一無料枠では無いのが、独自ドメインを作る際に必要なDNS。
AWS Route53お名前.comの2択で、料金はどっこいどっこいでしたが、駆け出し期間中はアカウントを頻繁に作り直すことを考えて、AWSとは独立しているため作り直しが不要で、管理が簡単そうなお名前.comを選択。

お金の話だけしてもアレなので・・

エンジニアっぽく、システム的にイケてる(と思う)対応をした部分も紹介します。

イケてるポイント 内容
CI/CD dev, stg, prodブランチを用意し、それぞれのブランチへのPushをトリガーに、別々の環境へのデプロイを行うGitHubActionsが走る。
IaC(Infrastructure as Code) ほぼ全てCloudFormationで管理。WebアプリをデプロイするためにAWSコンソール等で必要な作業はほぼゼロに。
スケーリングの対応 サーバレスサービスを採用。(LambdaやDynamoDB)
ユーザの増加にも柔軟に対応
生成AIの活用法 基本的に、頭の中で設計ができたら、簡単に文字に起こして、ChatGPTに投げ、最初の叩きを作ってもらいます。もちろんデバッグなどにもフル活用。Cursor, GitHub Copilot, Perplexity等々、極力生成AIを活用し時間短縮を図りました。

おわりに

もちろん、1年以上本番運用をしている場合や、アクセスが増えた時には無料枠では収まりません。
本稿のほぼコストをかけない手法は、それに当てはまらないときにだけ使えます。
もしそのような状況になれば、当然それはアプリを使ってもらえているということなので、スケールのしやすさというサーバレスのメリットを使い、サービス維持のためにコストをかけるつもりでいます。

また、コストに対する意識は、本業でも活かせるのかなと思いました。
ただ、コストを節約する比重をかなり高めにしシステムの品質を犠牲にした部分もあったので、コストと品質のバランスも大事だと改めて思ったところです。

今後

Webサービスだけ公開してもユーザは集まりにくそうなので、スマホアプリも作ろうかなと思っています。
iOSは審査が厳しく費用もかかるので、まずはAndroidアプリをリリースする予定。
P.S. Androidアプリは、20人のテスターを集めないとリリースはできないとのこと・・(他の方の記事: 怒ってます。Androidの新リリース基準酷すぎる

0
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?