はじめに
個人開発でWebアプリを作ること自体は、かなりやりやすくなってきたと思います。
フロントエンド、バックエンド、DB、認証、決済なども、便利なフレームワークやサービスが増えていて、以前よりもかなり少ない人数で形にできるようになりました。
一方で、いざ作ったアプリをインターネット上に公開しようとすると、アプリケーションのコードとは別のところで詰まることがあります。
特にAWSで公開しようとすると、最初に考えることが多いです。
- VPC
- Subnet
- EC2
- ALB
- ACM
- Route53
- Security Group
- IAM Role
- SSM Session Manager
- CloudWatch
アプリはできているのに、公開環境を作る段階で手が止まる。
これは個人開発ではかなりもったいないと感じました。
そこで、個人開発アプリをAWSに公開するためのTerraform Packを作りました。
サービス名は「ヒトリ開発」です。
この記事では、作ったもの、想定している利用者、構成で意識したこと、今後の展開について書きます。
作ったもの
今回作ったのは、個人開発アプリをAWS上に公開するためのTerraform Packです。
ざっくり言うと、Webアプリを公開するために必要なAWSリソースをTerraformでまとめたものです。
最初の構成では、EC2を中心にした公開環境を想定しています。
主な構成要素は以下です。
- VPC
- Public Subnet
- Private Subnet
- Internet Gateway
- Route Table
- Security Group
- EC2
- ALB
- ACM
- Route53
- IAM Role
- SSM Session Manager
- CloudWatch
最初からECSやEKSにするのではなく、まずはEC2構成から始めています。
理由は、個人開発者が最初にWebアプリを公開する段階で、コンテナやKubernetesまで一気に扱うのは学習コストが高いと考えたからです。
もちろんECSやEKSは便利です。
ただ、最初の目的が「まず自分のアプリを公開すること」であれば、EC2構成から始める方が分かりやすいケースも多いと思っています。
想定している利用者
このTerraform Packは、主に以下のような人を想定しています。
- Webアプリは作ったが、AWS公開で詰まっている人
- 個人開発アプリを独自ドメインで公開したい人
- TerraformでAWS構成を管理したい人
- まずはEC2構成で公開したい人
- ECSやEKSに行く前に、AWS公開の基本構成を押さえたい人
- VPC、ALB、ACM、Route53あたりで手が止まっている人
逆に、最初から大規模な本番環境やマルチAZの高可用構成、複雑なマイクロサービス構成を作りたい人向けではありません。
あくまで、個人開発や小規模サービスが最初の公開環境を作るための土台です。
AWS公開で詰まりやすいところ
個人開発でAWS公開をしようとすると、アプリケーションとは別に考えることが一気に増えます。
例えば、HTTPS化するだけでも以下のような要素が絡みます。
- ドメインを取得する
- Route53でHosted Zoneを作る
- ACMで証明書を発行する
- DNS検証を通す
- ALBに証明書を設定する
- HTTPからHTTPSへリダイレクトする
- Route53からALBへ向ける
これだけでも、初めてだとかなり大変です。
さらに、EC2を安全に運用しようとすると、Security Group、IAM Role、ログイン方式、監視なども考える必要があります。
特に個人開発では、
- SSHポートを開けたままにしてよいのか
- 秘密鍵をどう管理するのか
- ALBとEC2のSecurity Groupをどう分けるのか
- CloudWatch Logsはどこまで見るべきか
- NAT Gatewayのコストは許容できるのか
といったところで迷いやすいと思います。
そのため、最初から「個人開発で使いやすい公開構成」をTerraformでまとめておけば、公開までのハードルを下げられるのではないかと考えました。
今回の構成
今回の基本構成は、EC2を中心にしたシンプルなWebアプリ公開構成です。
イメージとしては以下です。
Internet
↓
Route53
↓
ALB
↓
EC2
HTTPS化にはACMを使います。
ドメイン管理にはRoute53を使います。
EC2への接続は、基本的にSSM Session Managerを使う想定です。
SSHで直接入る構成にすると、秘密鍵管理や22番ポート開放の扱いが必要になります。
個人開発の初期構成であっても、不要なSSH公開は避けたいと考えました。
そのため、EC2にはIAM Roleを付与し、SSM経由で接続する構成にしています。
Terraform Packに含めたもの
Terraform Packでは、AWS公開環境に必要なリソースをできるだけまとめています。
主に意識したのは以下です。
1. ネットワークの土台
VPC、Subnet、Route Table、Internet Gatewayなど、公開環境のベースになる部分です。
AWS公開を初めて触る人にとって、ネットワーク周りは最初の大きな壁になりやすいです。
そのため、最初から公開用の構成として使える形を用意しています。
2. HTTPS公開
ALB、ACM、Route53を使って、独自ドメインでHTTPS公開できる構成を想定しています。
個人開発であっても、外部に見せるならHTTPS化はほぼ必須だと思っています。
3. SSM接続
EC2への接続はSSM Session Managerを使う想定です。
SSH鍵を配布したり、22番ポートを開けたりしない構成にしたかったためです。
4. 最低限の監視
CloudWatchを使って、最低限のログやメトリクスを確認できるようにする想定です。
個人開発では、監視を作り込みすぎると重くなります。
ただし、公開環境として最低限の確認ができる状態にはしておきたいと考えました。
あえてEC2構成から始めた理由
最初からECSやEKSにしなかった理由は、学習コストです。
ECSを使う場合、アプリケーションのコンテナ化が前提になります。
そのため、以下のような知識が必要になります。
- Dockerfile
- ECR
- Task Definition
- ECS Cluster
- ECS Service
- ALBとの連携
- CloudWatch Logs
- IAM Role
EKSの場合は、さらにKubernetesの知識も必要になります。
- Deployment
- Service
- Ingress
- ConfigMap
- Secret
- ServiceAccount
- Node Group
- AWS Load Balancer Controller
もちろん、これらは本格的に運用していくうえでは重要です。
ただ、個人開発者が最初にWebアプリを公開する段階では、いきなりここまで扱う必要がないケースも多いと思っています。
まずはEC2で公開する。
必要になったらDockerやECSへ進む。
さらに必要になったらEKSへ進む。
このように、段階的に構成を育てられる方が、個人開発には合っていると考えました。
Free / Standard の考え方
ヒトリ開発では、FreeとStandardを分けています。
考え方としてはかなりシンプルです。
個人利用・学習・検証・友人内での利用 → Free
商用利用・外部公開・顧客提供・事業利用 → Standard
個人利用や検証目的であれば、Freeで十分な場合もあります。
無理にStandardを使う必要はありません。
一方で、売上の有無に関わらず、外部ユーザーに公開する場合や、事業・集客・顧客対応に使う場合はStandardをおすすめする方針です。
特に以下のようなケースでは、Standardを想定しています。
- SNSなどで不特定多数に公開する
- 顧客が触るフォームや管理画面がある
- 店舗や事業のWebアプリとして使う
- 将来的に課金や継続運用を考えている
- 落ちると困る用途で使う
逆に、自分だけで使う、友人に見せる、学習や検証で使う、といった用途ならFreeから始めるのが自然だと思っています。
また、FreeからStandardへ移行するためのドキュメントも用意しています。
最初から大きくしすぎず、必要になったら次の構成へ進めるようにしたいと考えています。
今後の予定
今後は、以下のような拡張を考えています。
Standard + DB
WebアプリではDBが必要になるケースが多いため、DB付き構成も整備予定です。
ただし、提供するのはあくまでインフラとDBの土台までです。
テーブル設計やスキーマ設計は、利用者側で行う想定です。
Free EC2 + Docker
ECSに進む前段階として、EC2上にDocker Engineを入れたFree版も考えています。
これは、Docker前提のアプリをAWS上で試したい人向けです。
実態としてはECSではなく、EC2上でDockerコンテナを動かす構成です。
将来的にECSへ移行しやすい導線として整備したいと考えています。
ECS
コンテナ運用向けの構成として、ECS版も予定しています。
Free EC2 + Dockerで小さく始めて、必要になったらECSへ移行する、という流れを作れるとよいと考えています。
EKS
EKSはさらに上位の構成として検討しています。
ただし、個人開発の初期公開には少し重い構成でもあるため、ECS版の後に必要性を見ながら進める予定です。
作ってみて感じたこと
個人開発では、作りたいものがどんどん増えます。
アプリ本体だけでなく、公開基盤、決済、サポート、ダッシュボード、学習支援、ドキュメントなど、考えることがかなり多いです。
ただ、最初から全部やろうとすると確実に重くなります。
そのため、ヒトリ開発では以下の考え方を大事にしています。
最初から大きくしすぎない。
必要になったら段階的に育てる。
これはAWS構成にも、サービス設計にも言えることだと思っています。
最初からEKSまで用意するのではなく、まずはEC2で公開する。
必要になったらDBを追加する。
Dockerが必要になったらEC2 + Dockerへ進む。
コンテナ運用が必要になったらECSへ進む。
このように、個人開発者が段階的に進める構成を作りたいと考えています。
まとめ
個人開発でWebアプリを作ることは、以前よりもかなりやりやすくなりました。
一方で、AWSで公開する段階では、まだまだ考えることが多いです。
VPC、EC2、ALB、ACM、Route53、SSM、CloudWatchなど、公開に必要な要素を最初からすべて理解して構築するのは、個人開発者にとって大きな負担になることがあります。
その負担を少しでも減らすために、個人開発アプリをAWS公開するためのTerraform Packを作りました。
まずは小さく公開する。
必要になったらStandard、DB、Docker、ECSへ進む。
そういう段階的な公開基盤にしていきたいと思っています。
補足
今回の構成イメージやプラン差分は、以下にまとめています。