You Don't Need AWS ~お前にAWSは必要ない~

はじめに

タイトルはこちらから拝借しました。この記事は他のパブリッククラウド(Azure, GCP)を薦める記事でもなければ、プライベートクラウドを薦める記事でもありません。また私自身、エンジニアキャリアの中でAWSはたくさん使ってきましたし、今でもソフトウェア開発のわがままに答えてくれる素晴らしいサービスだと思っているので、AWSを貶めるような記事でもありません。むしろ以下に紹介するサービスはAWS上に構築されていることが多く、間接的にもますます世界中の基盤として発展していくはずです。

PaaSアーキテクチャ

前提条件

前提として、現在でも主流なSPAを中心としたフロントエンド、バックエンド、データベースサービスからなるアプリケーションを想定します。

この場合、
フロントエンド　→　CDN + Static Hosting
バックエンド　→　Container Deploy(Auto Scaling)
データベース　→　Serverless DB(Auto Scaling)
を満たせれば、各サービスに特化したPaaSを組み合わせることで、Production用の構成としても十分に機能します。

フロントエンド

基本的にどのサービスもGithubのrepositoryを指定すれば自動でDepolyをしてくれます。(ただしmonorepoに対応しているかはサービス次第です)

サービス名	URL	特徴
Vercel	https://vercel.com/	NextJSの開発元、料金高め
Cloudflare	https://www.cloudflare.com/ja-jp/	料金が安く、個人開発でよく使われる
Netlify	https://www.netlify.com/	GatsbyJSの開発元

バックエンド

https://www.itmedia.co.jp/news/articles/2208/26/news097.html

長らくPaaSとして有名だったHerokuが無料プランを廃止して以降、この領域は様々なサービスが登場するようになりました。こちらもGithubのrepositoryを指定すれば自動でDepolyをしてくれます。

• Render：https://render.com/
• Fly.io：https://fly.io/
• Railway：https://railway.app/
• Koyeb：https://www.koyeb.com/
• Cyclic：https://www.cyclic.sh/
• Deta：https://deta.space/

マシンスペック、料金、ランタイム対応、monorepo対応、日本リージョンの有無　等で使うサービスを選択します。このうち東京リージョンがあるのは、Fly.ioとKoyebになります。

データベース

RDB系、NoSQL系、NewSQL系、ほとんどのジャンルでデータベースに特化したPaaSサービスが展開されています。特に最近はServerlessでAuto Scalingにも対応していて、個人開発から商用利用まで幅広く対応しているものが充実しています。

RDB系

サービス名	URL	特徴
PlanetScale	https://planetscale.com/	MySQLベース
Neon	https://neon.tech/	PostgreSQLベース
Turso	https://turso.tech/	SQLiteベース

NoSQL系

サービス名	URL	特徴
MongoDB Atlas	https://www.mongodb.com/ja-jp/atlas	MongoDBベース
Neo4j	https://neo4j.com/	グラフデータベース

NewSQL系

サービス名	URL	特徴
TiDB Coud	https://pingcap.co.jp/tidb-cloud/	MySQLベースの分散DB
CockroachDB Cloud	https://cockroachlabs.cloud/	PostgreSQLベースの分散DB

その他

上記に挙げた以外にも、AWSの各サービスに対応したPaaS/SaaSサービスが充実しており、代替手段が豊富に用意されています。

サービス	AWS	PaaS
Storage	s3	Cloudflare R2
認証認可	Cognito	Auth0, Clerk
キャッシュサーバ	Elasticache	Upstash
メール	SES	Sendgrid, Resend
GraphQL	AppSync	Hasura Cloud
DWH	Redshift	Snowflake

IaaS lessなアーキテクチャを使ってみて

弊社の場合

弊社の新規開発では、フロントエンドではVercel、バックエンドはKoyeb、データベースはNeonと上記のアーキテクチャを踏襲しています。詳しくは以下の記事を参考にしてください。
https://zenn.dev/ficilcom/articles/2024-modern-frontend
https://zenn.dev/ficilcom/articles/koyeb-neon-introduction

所感

• デプロイが簡単になっているため、フロントエンド・バックエンドエンジニアでも対応可能 → インフラエンジニア/SREが不要
• インフラ基盤が、サービス設計と密接に結びついてしまうことが少ないため、サービスの認知負荷が下がる → 業務のボトルネックになりがちなAWS職人が発生しなくなる
• IaC業務からの解放
• CI/CD業務の簡略化

デメリット

逆に、以下の場合は今まで通りAWSといったIaaSを使った方がいいと思います。

• VPCが必要なとき
• マイクロサービス・モジュラモノリス
• インフラのアーキテクチャがサービスにとって重要/よく変化する場合
• MLの学習/推論といったパイプライン
• GPUサーバが必要な場合
  ※KoyebがServerless GPUを発表しているので(参考)、こちらはまた変わるかも

まとめ

• VPCやAZ,subnetなど、サービスのコアとは無関係のインフラ構築が面倒臭い
  • →お前にAWSは必要ない
• 一度作ったインフラ構成はそう簡単に変更しない
  • →お前にAWSは必要ない
• 開発人数が少なく、今はユーザ機能を作っていくことが重要だ
  • →お前にAWSは必要ない

お前に必要なのは${快適な家}

• お前の家は、建売かマンションで十分快適
• 庶民の家で改築を繰り返してサクラダファミリア化する必要はない

結論：サービスにとってのコア機能に集中しろ