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特徴
Vercelhttps://vercel.com/NextJSの開発元、料金高め
Cloudflarehttps://www.cloudflare.com/ja-jp/料金が安く、個人開発でよく使われる
Netlifyhttps://www.netlify.com/GatsbyJSの開発元

バックエンド

長らくPaaSとして有名だったHerokuが無料プランを廃止して以降、この領域は様々なサービスが登場するようになりました。こちらもGithubのrepositoryを指定すれば自動でDepolyをしてくれます。
マシンスペック、料金、ランタイム対応、monorepo対応、日本リージョンの有無 等で使うサービスを選択します。このうち東京リージョンがあるのは、Fly.ioとKoyebになります。

データベース

RDB系、NoSQL系、NewSQL系、ほとんどのジャンルでデータベースに特化したPaaSサービスが展開されています。特に最近はServerlessでAuto Scalingにも対応していて、個人開発から商用利用まで幅広く対応しているものが充実しています。
RDB系
サービス名URL特徴
PlanetScalehttps://planetscale.com/MySQLベース
Neonhttps://neon.tech/PostgreSQLベース
Tursohttps://turso.tech/SQLiteベース
NoSQL系
サービス名URL特徴
MongoDB Atlashttps://www.mongodb.com/ja-jp/atlasMongoDBベース
Neo4jhttps://neo4j.com/グラフデータベース
NewSQL系
サービス名URL特徴
TiDB Coudhttps://pingcap.co.jp/tidb-cloud/MySQLベースの分散DB
CockroachDB Cloudhttps://cockroachlabs.cloud/PostgreSQLベースの分散DB

その他

上記に挙げた以外にも、AWSの各サービスに対応したPaaS/SaaSサービスが充実しており、代替手段が豊富に用意されています。
サービスAWSPaaS
Storages3Cloudflare R2
認証認可CognitoAuth0, Clerk
キャッシュサーバElasticacheUpstash
メールSESSendgrid, Resend
GraphQLAppSyncHasura Cloud
DWHRedshiftSnowflake

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

弊社の場合

弊社の新規開発では、フロントエンドではVercel、バックエンドはKoyeb、データベースはNeonと上記のアーキテクチャを踏襲しています。詳しくは以下の記事を参考にしてください。 https://zenn.dev/ficilcom/articles/2024-modern-frontendhttps://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は必要ない
お前に必要なのは${快適な家}
  • お前の家は、建売かマンションで十分快適
  • 庶民の家で改築を繰り返してサクラダファミリア化する必要はない
結論:サービスにとってのコア機能に集中しろ