安くWebアプリを作りたい？活用したいプロダクトと裏技のご紹介

作ったアプリがスマートフォン向けであれば、各OSの公式ストアに提出するという決まった手順があり、迷うことはほぼないでしょう。

ですが、Webアプリには決まった手順は特に決まっておりません。

Github Pagesに静的なファイルを置くもよし、VPSでサーバーを借りてWebサーバーを構築して...もありです。

今回は基本的なWebアプリを作るうえで、かかるであろうコストを極力抑えて開発するとしたら...

というお話をしたいと思います。

まず基本的なWebアプリとは何か、ここでは

というアプリケーションを指すことにします。

データベース編

　この章では、アプリケーションを作る際に欠かせない、データベースをどこに配置すると安くサービスを運用できるのか、ということについてお教えします。　

　データベースは、ユーザーからのリクエストをビジネスロジックに従って処理し、そのデータを永続的に管理するための肝となる部分です。　

Planet Scale

Planet Scaleはリレーショナルデータベースを開発者に提供してくれるサービスです。

通常データベースを使う際は、自分でサーバーを借りるなどして、セットアップまで含めて自分で行う必要があります。

あるいはAWS RDSなどの課金が青天井にかかるマネージドデータベースを使うことも挙げられます。

しかしこのPlanet Scaleは無料の料金プランが用意されており、開発者にやさしいサービスとなっています。

また、通常のデータベースにはない機能として”プランチ”という機能があり、Githubのようなブランチを切ることができます。

この機能によって、ほぼゼロタイムでスキーマの変更をすることもできます。（頻繁にスキーマ変更を使うかどうかは議論がありますが。）

supabase

supabase はAlternative Firebaseとも呼ばれています。

FirebaseはBackend as a Serviceというデータストアの提供から認証機能までをフルマネージドで提供するサービスとして有名ですが、supabaseはその機能を代替しています。

またFirebaseはクローズドソースですが、supabaseはオープンソースであり、自分でsupabaseの環境を構築することも可能です。

無料プランでは500MBのデータベースが提供されます。

認証機能などもセットで簡単に開発者がプロダクトに組み込める点がBackend as a Serviceの利点ですので、こちらもぜひご活用ください。

Google SpreadSheet (GAS)

実はGoogleドキュメントのスプレッドシートにはAPIが提供されています。

このAPIをデータベースに見立てて、データの保管や参照を行うことができます。

ただし行数に制限があることや、行ロックなどの実現が難しいので、しっかりロジックを作りこむことや、考慮しなくても大丈夫なサービスを作ることが求められます。

フロントエンド編

　この章では、フロントエンドのアプリケーションをどこに公開すると、安くサービスが運用できるのか、ということについてお教えします。

　フロントエンドのアプリケーションは、ユーザーとビジネスロジックや、その背後に控えるデータストアが対話するためのインターフェースとしての役割を担っています。

　5年ほど前から、ビジネスロジックの適用やデータストアとしての役割を担うサーバーサイドのアプリケーションと、インターフェースの役割を担うフロントエンドのアプリケーションを分離することがトレンドになっています。

　分離されたフロント・サーバーアプリケーションは、REST APIやGraphQLといった技術で、事前に定義されたAPIで互いにコミュニケーションを取り合います。　

　下記でご紹介するSaaSは、サーバーサイドとフロントサイドを分離されていることを前提に提供されているサービスです。

CloudFlare Pages

CloudFlare PagesはCloudFlare社が提供するWebサイトのホスティングサービスです。

ただし、このサービスではWordPressのようなサーバーサイドで描画処理を行うことはできません。

その代わりに、Webページを事前にビルドする、JamStackと呼ばれる静的サイトジェネレーションを使ったWebサイトをデプロイすることができます。

例えばNext.jsのServer Side GenerationやGatsuby.js、Nuxt.js、 Hugoといった静的サイトジェネレーターを使ったサイトのデプロイができます。

また、ただのReactやVueで構築されたプレーンなWebアプリケーションもデプロイすることができます。

今年の3月中旬ごろまで、 サイトの生成が6分ほどかかっていたものが改良されて、2分ほどでサイトがデプロイできるようになりました。

競合サービスのVercelやNetlifyでは営利目的で利用しようとする際に、有料プランへの契約が義務となっていますが、CloudFlare Pagesにはその制約が今のところございません。

その代わりサーバー側で描画処理する機能が使えないという面もあるのですが、サイトの静的生成＋CloudFlareのCDNとしてのパワーが、サイトの高速表示にとても貢献してくれるため、デメリットも帳消しにしてくれることでしょう。

サイトの静的生成を使うのであればぜひおすすめするサービスです。

Vercel

Vercel はVercel社が提供するWebサイトのホスティングサービスです。

そしてVercel社はなんとNext.jsの開発元でもあります。

Next.jsはオープンソース化されており、どのホスティングサービスでもデプロイすることが可能です。

しかし、Next.jsの重要な機能がVercel向けに最適化されていることはご存じでしょうか。

それは画像の最適化です。

Next.jsには通常のimgタグに加えて、Imageタグが使えます。

一見どちらも画像を表示するタグなのですが、Imageタグを使うと画像サイズを最適化し、WebPという種類の圧縮をかけてくれます。

このWebPは優れモノで、Webページにおいて重たいとされるコンテンツである画像をそれほど劣化させずに圧縮してくれます。

また、GoogleがWebPをおすすめしていることもあり、一部のサイトではSEOに効果があったと述べているサイトもあります。 （参考: https://www.1st-net.jp/blog/about-webp/)

これほど重要な機能にもかかわらず、通常のWebホスティングサービスではImageタグを使うことができない場合がございます。

どんな場合かと申し上げると、サーバーサイドで処理することができない、完全に静的生成サイトのみに対応している場合です。

画像の最適化をアクセスが来たタイミングで実行するため、サーバー側での処理が必要になりますが、静的生成サイトの公開のみに対応しているサービスではサーバー側でアクセス時の処理が行えず、Imageタグ機能が実現できないためです。

この点、VercelにデプロイしたNext.jsのサイトであれば、サーバー側での処理が可能なため、Imageタグも難なく使うことができます。

ただし営利目的でこのサービスを使う際は、有料プランへの格上げが必要なので注意してください。

バックエンド編

この章では、バックエンドを構成するアプリケーションをどこで実行すれば、安く運用することができるのか、ということについてお教えします。

バックエンドを構成するアプリケーションは、そのアプリケーションの主要となるロジックの定義をし、場合によっては認可認証の機能を提供します。

例えばメモアプリケーションのバックエンドを構成するアプリケーションには、メモの取得、作成、更新、削除といったロジックを定義し、ユーザーのログインとログアウト機能を提供する必要があります。

Heroku

言わずと知れた、Heroku社が提供するPlatform as a Service、 Herokuです。

このサービスは時間制限があるものの、無料でJava や Golangで作ったWebアプリケーションをデプロイできます。

無料でMySQLやRedisをプラグイン形式で追加して利用することができます。

またユーザーとのやり取りにはHTTPS化されたリンクが自動で発行されるため、安全に通信を行うことができます。

無料プランで使う場合、1アカウントあたり750時間/月までの制限がつく他、様々な制限がありますが、その環境下でうまくシステムが動くように設計できれば、無料で運用することが可能です。

Cloud Run (Google Cloud Platform)

このサービスはGoogle Cloud Platformが提供するContainer as a Serviceという種類のサービスです。

ここ数年のトレンドとしてコンテナ仮想化がありますが、そのコンテナを外部からアクセスできるようにしてくれるサービスです。

コンテナの知識が必要になりますが、Dockerfileを使ってWebアプリケーションを起動できるようにすれば、あなたがしなければならないサーバー側の作業はほとんどありません。

GCPとGithubアカウントを連携して、リポジトリを読み込み、イメージをコンテナ化すれば完了です。

個人開発でクラウド？お金大丈夫かな？と思いましたでしょうか。

私もこのサービスを使うときはそう思っていましたが、設定を工夫すれば月40円ほどで運用することができました。

その設定とは、リクエストがどれだけ飛んできたとしても、起動するコンテナの最大数を1、 最小のコンテナ数を0にすることです。

またこのサービスはアクセスがないと起動しているコンテナを終了させてリソースを節約します。

つまり、この設定では起動しているコンテナがゼロになってしまい、再びリクエストが来て処理を開始するまでに時間がかかってしまいます。（コールドスタート状態になってしまう）

最小のコンテナ数を1にすると、常時起動分の課金が発生してしまいます。

なので”常時起動”を避けつつ、コールドスタートも避ける方法が必要です。

それは15分に1回アクセスをしてコンテナが完全にダウンするのを防ぐという方法です。

公式情報ではないものの、私の実験として15分に1回アクセスがあればコンテナの完全なダウンがされない、コールドスタートにならないことがわかりました。

また課金はアクセスを裁くために使ったCPU時間であるため、常時起動よりもお金を節約することができます。

この方法によって、お金を節約しながら、高速レスポンスなWebアプリを作ることができます。

まとめ

いかがだったでしょうか。

後半はプロダクト紹介というよりも、裏技の紹介に近いものになってしまいましたが、私が実際にプロダクトを作った際に使った方法も含めてございます。

皆様のWebアプリ開発・プロダクト開発がより豊かになることを願って締めたいと思います。

C4Cではプログラミングに関する質問を受け付けております。

ぜひご活用ください。