先日書いた AWS の勉強方法をまとめた記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）で、「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書きました。その中で、
今まで経験したり今いるところはどこもオンプレばかりでAWSとかのクラウドの知識が全くつかないからどこかで勉強したいし個人サービス運用とかしたいんだけど、1年過ぎるといきなりコストがドカンとかかりそうで……
や
「２）簡単なWebサービスをAWSで運営する」は誰もが考えることだが、最初の無料期間1年間以外、AWSで個人ブログなりを運用するのはコスト悪すぎだろ…。
というような利用料金が気になってしまう、、というコメントを幾つかいただきました。
この気持ちとても分かります！業務で使う分にはサーバー何台立てようが気になりませんが（は言い過ぎですがｗ）、個人でサービスを運営する場合はそうはいきません。例えば、
t2.microの Web サーバを2台- その 2台の Web サーバをぶら下げる ELB
- RDS は Master-Slave 構成で
db.t2.micro2台分 - 取得したドメインを Route53 に登録してサービス公開だ！
とした場合、ざっくり計算で月々約1.5万円となります。この費用以上の広告収入を得られるサービスに育てるまでには、それなりの期間が必要です。勉強のためとはいえ、私のようなお小遣い制エンジニアには、月次でこのコストは痛すぎます。（実は、これがサーバレスの勉強を始めたモチベーションの一つだったりしますｗ）
では、先の記事で書いた「簡単なWebサービスをAWSで運営することで AWS の勉強をしよう」は難しいのでしょうか？決してそんなことはありません。上の構成は可用性を意識した王道パターンです。王道パターンを理解した上で、あえてコストを優先した構成でまずはサービス運用してみればいいと思います。ほとんどお金を掛けずに AWS 上でサービス／プロダクトを動かすことも可能です。お金だけを理由に諦めるのはもったいないです。
この記事では、王道パターンからコスト優先パターンまで、5つのアーキテクチャを紹介しようと思います。また、それぞれのアーキテクチャを、私の独断と偏見で4つの軸で評価してみたいと思います。
- 技術獲得面：たくさんの技術要素を学べるかどうか。学べるものほど、★を多くします。
- 実用面：実務で使える可用性を担保したアーキテクチャかどうか。実務で採用できるものほど、★を多くします。
- 手早さ面：サービスインまでにどれくらいのリードタイムがかかるか。勉強しないといけないことが少ないほど、★を多くします。
- 費用面：月額のコストを安く抑えることができるか。安いほど、★を多くします。
こんな形で評価してみたいと思います。★が少ないからダメというわけではありません。「手早さ面」の場合は、じっくり勉強したい人にとっては★が低くても別に問題ないはずです。あくまで「自分の想いにあっているものはどれか」「初手としてまずは何をやろうかな」を考えるヒントになればという意図で、評価軸を作ってみました。
１）王道Webパターン
技術獲得面：★★★★★ 実用的面：★★★★★ 手早さ面：★★★☆☆ 費用面：★☆☆☆☆
まずは王道パターンです。上でも紹介した、可用性もしっかり担保したパターンです。これに加えて、静的コンテンツを S3 から配信したり、ELB の前段に CloudFront を挟んだり、セッション情報を ElastiCache でキャッシュさせたりといった応用も効きやすいです。実務でもこのパターンが基本となるはずですので「実務に近いアーキテクチャを構築する力を得る」という意味ではこのパターンが最もいいと私は思います。
また、この王道パターンで運用することで、運用してみて初めて分かる知見が得られると思います。複数のサーバに分散してしまったログをどのように管理するか、RDSの片系がトラブった時に副系に切り替えるためにはどのような設定が必要か、などを経験できるのがとてもいいと思います。
ただし、前述のように費用はそれなりにかかってしまいます。このパターンを安価にするとしたら、例えば RDS の Master-Slave 構成をやめて Single 構成にする、Web サーバを1台にするなどが挙げられます。可用性を減らす構成にすることで、得られる知見はやや少なくなるかもしれませんが、それでも十分勉強になると思います。冒頭にも書きましたが、「理想的な設計はわかった上で、金額のために妥協をする」のであれば全然問題ないと思います。
手早さ面はそれなりに扱うサービスが多いので★３つとしました。
２）シングルEC2インスタンスでスモールサービス運用パターン
技術獲得面：★★★☆☆ 実用的面：★★☆☆☆ 手早さ面：★★★★★ 費用面：★★★☆☆
サーバありミニマムパターンです。AWS を使い始めた頃、最初に採用したアーキテクチャは実はこれでした。サーバの上に WordPress をインストールし、MySQL を腹持ちさせ、ブログ運用していました。AWS の勉強方法記事で「簡単なWebサービスをAWSで運営するといい勉強になるよー」と書いたときも、まずはこのパターンでもいいので始めてみては？という意図でした。
当時は t2.nano がなかったため、t2.micro で運用していましたが月2,000円弱くらいの費用感だったと記憶しています。t2.nano であれば半分くらいになるでしょうか。このパターンでも十分勉強になります。何故か落ちる MySQL プロセスを監視するために CloudWatch Logs の設定をしたり、Python SDK（boto3）を使って日次で AMI を取るスクリプトを書いたりした記憶が懐かしいです。これらの経験は今でも血肉になってると思っています。
また、思い立ったらすぐに始められるのもいいと思います。なんせ EC2 と Route 53 の知識だけで（厳密には IAM とか VPC とかありますが、、）運用を開始できます。まずは作って、日々発生する様々な問題に対応する中でナレッジを貯め、十分収益性を得られるサービスになったら王道パターンに移るのもいいと思います。お、移行の練習もできますね。素晴らしい。
勉強にはなるものの、実務で Web サーバに DB を腹持ちさせることはまぁ少ないと思います。そういう意味で勉強できることの幅は少し狭まってしまうと言えるでしょう。（繰り返しますが、それでも勉強になることは非常に多いです。）また、費用が月1,000円から2,000円発生します。ブログを運用するだけであれば、他のサービスを使った方が安いことが多いでしょう。
３）ネイティブアプリ + サーバレスAPIパターン
技術獲得面：★★★★★ 実用的面：★★★★☆ 手早さ面：★★☆☆☆ 費用面：★★★☆☆
私は２）の方法で AWS を始めましたが、今はサーバレスなアーキテクチャにチャレンジするのもいいでしょう。特に、ネイティブアプリは書けるけど、バックエンドの知見がない方にはこのパターンが向いているかもしれません。フロント部分はアプリに任せ、API 部分を AWS 側に構築するパターンです。API は API Gateway + Lambda + DynamoDB で構築し、API の利用制限をかけるために Cognito を利用します。サーバレスな API アーキテクチャの王道パターンですので、非常に勉強になると思います。
実用面を★４つとしたのは、間違いなく実務で使えるアーキテクチャではあるものの、サーバありなアーキテクチャを採用するシーンの方がまだ多いと思うためです。決して、実務で使えないという意味ではありません。すぐに役に立つ可能性は２）の方が高いかな、くらいのイメージです。
また、AWS の観点で言うと費用は非常に安価です。リクエストの頻度やデータ量にも寄りますが、ローンチ直後は２）よりも安価になることが多いでしょう。ただし、★３つとしているのは、iOS のネイティブアプリをリリースするには年次で費用がかかってしまうので、これも含めると２）と同じくらいかなーと思っています。手早さ面を★２つとしているのは、冒頭に書いたようにネイティブアプリの知見がある人からすると問題ないのですが、そうでない方にとっては「AWS を使えるようになる」以上の技術取得が必要になるからです。もちろんエンジニアとして知見が増えるのは良いことですが、サービスローンチまでに時間がかかるという意味で★２つとしました。
４）サーバレスSPAパターン + サーバレスAPIパターン
技術獲得面：★★★★★ 実用的面：★★★★☆ 手早さ面：★★☆☆☆ 費用面：★★★★★
続いて、フロントを SPA で提供するパターンです。私はこのパターンが大好きです。まさにこのパターンでプライベートでサービス開発しています。何と言っても費用面がお安いです。３）のパターンと異なり、年間の費用も発生しません。また、３）と同じ理由で実用面を★４つとしたものの、技術獲得面、実用面ともに良いナレッジが手に入ると思います。
手早さ面が少し低いのは、Vue.js や React といったフロントサイドのフレームワークの習得が必要だからです。３）と同じで、元々フロントサイドが得意で、AWS も得意になりたい方からすると、ここは問題ではないでしょう。
５）Twitterボット + サーバレスバッチパターン
技術獲得面：★★★☆☆ 実用的面：★★☆☆☆ 手早さ面：★★★★★ 費用面：★★★★★
最後に、Twitter をユーザーインターフェースとして利用するパターンです。このパターンも私の好みです。1年前のツイートをするレトロボット（ketancho_retro (@ketancho_retro) | Twitter）や、仮想通貨の裁定取引情報を流すボット（Twitter / Account Suspended）などを運用しています。Lambda が主体となるアーキテクチャなので、利用料金はほとんどかかりませんし、簡単に構築することができます。
他のリッチな構成と比べると、AWS サービスの一部しか触ることができませんが、S3 や DynamoDB といった主要サービスの理解が深められることは有意義だと思います。また、実務でこのような Twitter ボットを開発することは稀だと思いますが、この構成から得たナレッジは Lambda を使うシーンにおいて必ず役に立つと思います。
まとめと構築時の参考資料おすすめ
５つのパターンを考えてみました。このパターンでないとだめというわけではなく、各パターンをベースに「勉強したいこと」「作りたいプロダクト要件」を鑑みてアレンジしていただければと思います。最初は４）のフロント SPA パターンで安価に始め、プロダクトとして人気が出てきたり（≒インフラ投資できる収入を得られる）、現状のアーキテクチャでは作りにくい追加機能が出てきたりしたタイミングで１）の王道パターンに移行するのもいいと思います。その時々に応じて、最適なパターンを探してみてください。
最後に、それぞれのパターンを構築する際に、参考になるであろう情報や参考書を紹介して終わりたいと思います。
まず、１）や２）のパターン（サーバありパターン）を採用する場合は、下記のふたつをおすすめします。
Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版
- 作者: 玉川憲,片山暁雄,今井雄太,大澤文孝
- 出版社/メーカー: 日経BP社
- 発売日: 2017/04/13
- メディア: 単行本
- この商品を含むブログを見る
Amazon Web Services 業務システム設計・移行ガイド (Informatics&IDEA)
- 作者: 佐々木拓郎,林晋一郎,瀬戸島敏宏,宮川亮,金澤圭
- 出版社/メーカー: SBクリエイティブ
- 発売日: 2018/01/20
- メディア: 単行本
- この商品を含むブログ (1件) を見る
紫本は、別の記事（AWSを学ぶ上でやってよかった勉強法５選 - log4ketancho）でも紹介していますが、ハンズオン形式で基本を学ぶことができるのがいいところです。水色本は自署で恐縮ですが、基本となるアーキテクチャパターンの紹介やネットワークの詳しい話、オンプレとの連携、移行や運用監視にまつわる話を解説しています。幅広く実用的なナレッジを得たい方におすすめです。
３）から５）のサーバレスな構成を学びたい方は、こちらの本がおすすめです。
Amazon Web Servicesを使ったサーバーレスアプリケーション開発ガイド
- 作者: 西谷圭介
- 出版社/メーカー: マイナビ出版
- 発売日: 2018/03/16
- メディア: 単行本（ソフトカバー）
- この商品を含むブログを見る
こちらの記事（サーバーレスことはじめには「サーバーレスアプリケーション開発ガイド」がおすすめ - log4ketancho）でも紹介しましたが、実際に手を動かしやすい形で情報がまとめられています。元々、４）のパターンで Vue.js + Python を使ってサービスを作っていた私ですが、それでも Lambda Function を書く際のお作法であったり、ファイルアップロード方式であったり、かなり学びの多い書籍でした。
また、本ブログでもサーバレス周りの記事が増えてきましたので、こちらもご参照いただければと思います。
