見出し画像

修行のために何かを作る話(AWSサービス検討)

この話の続き

今回はAWSでブログを公開するために必要なコンピューターリソースの検討と、それを実現するためにAWSのなんのサービスを使うのか、という話。

ブログを何で作るか

仕事では主にRuby on Railsを使っているので、当初はRailsを利用してブログwebサービスを作って行く。

今後については後段でまとめるが、フロントエンドを分離したりRailsから離れて行くことを考えているが、まずは慣れた方法で作っていく。

この場合、Ruby on Railsを動かすコンピューターリソースが必要になる。
他にはデータベース、ストレージあたりがさしあたって必要だろう。
コンピューターリソース以外で言うと、インターネットに公開するためのドメインとサービスを紐付けるあたりが必要か。

最低限その辺りがあればいったんはサービスが動くはずなので、目標はこれらが最低限動かせる構成とする。

構成の検討

ベストプラクティス何もわからんと思い「AWS webサービス 構成」で検索したら公式サイトがヒットした。

目的別に構成例と料金を出してくれるらしい。これは便利。

今回はこの画像の一番左が該当。

スクリーンショット 2021-02-04 0.58.44

さてお見積もりは…。

スクリーンショット 2021-02-04 1.00.09

$760/month。キッツい。

とは言えさっき考えた最小構成よりはだいぶ頑張っている感じがするので削って行く。

最小構成へ

見積もりの内訳を見てみよう。

スクリーンショット 2021-02-04 1.02.03

なるほど。
コストがかかってる点を見ると以下のようなあたりだ。

まずEC2(Railsを動かすコンピューターリソース)がマルチAZの二台構成になっている。
もちろん商用サービスなら可用性の観点からこうするが、これは個人のブログなのでとりあえずそんなものは要らない。
次にm5.largeというインスタンスの種類が指定されているが、これもブログには過剰な気がする…が、インスタンスの種類は膨大なので別サイトを参考に確認してみる。
2019年のAWS SUMMIT TOKYOの資料が有用そうだった。

スクリーンショット 2021-02-04 1.20.03

スクリーンショット 2021-02-04 1.20.55

この辺を見ると、t3a.microあたりで良いのではないだろうか。
あとストレージも100GBも要らんと思うので30GB、スナップショットも当面なしで良い。

次にDBであるRDSも高い。
マルチAZが不要で、あとはまたインスタンスタイプを選ぼう。

db.t3.microとかで良いんじゃないかな…。
正直勘所が分からないし、実際トラフィックが発生してみないと性能の足りる足りないの判断なんてできっこないので、まあ小さめで始めましょう。

あとはNATゲートウェイが高い。
そもそもNATゲートウェイが必要か?と言う議論があって、外部サービスと連携したいとかがない限り特段必要ないんじゃないかなと思っている。
この辺の資料を参照。

感覚的にはEC2はパブリックに置いて、入ってくるインバウンドトラフィックは(一応)ELBを通してEC2へ、出て行くアウトバウンドトラフィックはそのままNATを介さず出て行けば良いんじゃないかな。
RDSはプライベートNWに置くだろうけど、それも別に必須ではない。
最初の時点でNATゲートウェイは不要かな。

最小構成見積もり

こんな感じ。

スクリーンショット 2021-02-04 1.41.11

$57.75/month。まあ趣味なら妥当な金額。だよね?

構成がシンプルな分学びは少なくなっちゃうけど、これは修行を兼ねた趣味なので。
プラモを作ったり盆栽を弄ったりするようなものです。
コロナ禍で登山も旅行も酒盛りも写真撮影も封印した中年エンジニアが見つけた新しい趣味なのです。

今後の構想

今回の構成は「サーバーサイドからHTMLの生成までを全部Railsでやる構成」になってる。
今後の発展の方向性としては以下のようなものがある。

【フロントをNuxt.jsなどに移行】
最近のwebアプリケーションはフロントとバックは疎結合で動的なデータはAPIでやりとりがまあ普通だと思う。
これをするようにすると、フロント側をどう作るか次第だけどまた構成が変わる。
SSG+CSRみたいな構成ならS3+Cloudfront、SSRならNodeが動くサーバーがいるかも。
その場合API Gatewayが出てくるかもしれない。
あとは自分以外が記事を投稿されても困るので、CognitoなどでAPIに認証を入れて行く必要が出そう。
…いや、別に自分以外が勝手に記事を書いても良いか…。

【Railsの役割縮小 or 廃止】
複雑なビジネスモデルが登場しないならRailsは過剰と言える。
そうするといわゆるサーバーレス(サーバはある)が視野に入る。
機能単位でAPIを作って、APIの裏側はLambdaで作る。
最近はRDSもLambda対応したので、基本的な機能はこれでも作れるはず。

今後どんな機能追加で遊んでみたくなるか次第だけど、この二つの構成はそのうちやりたい。


今回はこんなところ。
ドメインに金を払ったまでしか具体的な活動をしてないけどゆっくり行こう。

この記事が気に入ったらサポートをしてみませんか?