EC2になんでもかんでもやらせることのデメリット

Posted at 2024-04-18

前提とか能書き

まず前提として、AWSにおいて2024年現在のクラウド界隈、特に対顧客のブラウザやアプリなどと向かい合うインフラはセオリーともいえるべき構成や手法が確立されています。

多くのプロダクトがこの構成を採用していて、もっともホットなジャンルであるため、対応するAWSのサービスが生み出されて洗練されていったんだと推測します。

その中身を紐解くと、こんなかんじでしょうか

2009年くらいまでは古のオンプレミスなプラットフォームにおけるLAMP(Linux, Apache, MySQL, Perl/PHP)構成という鉄板構成がありました。
それらは全て一つあるいは役割を分割した複数の物理的なサーバ筐体構成されて、ネットワークで結合されていました。

いまやその機能の大部分はもろもろひっくるめてAWSのサービスとして置換されています。
かんたんにどう置換されていったかを説明します。

ミドルウェアやアプリケーションが動作するOSとしては変わっていないです。
AWS上ではオンプレのサーバとしての機能が分割されているくらいでしょうか。

nginxの場合もあるんでしょうけど、かなりの部分はCloudFrontで事足りるはずです。
CloudFrontは本質的にはコンテンツを配るためのもの(CDN)で、そのキャッシュ機構や配信できる能力は強力です。

この部分だけでも可用性や抗堪性の観点から運用が超絶楽になっています。

カスタマイズという観点ではapacheやnginxにまだ利があるのですが、そのためにEC2とか維持する？って考えるとちょっと
まあ、受け口をCloudFront、パスごとにEC2とか共存する道はありますが、なんでもかんでもapacheという思想は現状にそぐわないですね。

ただ、クライアント証明書としてTLSの証明書を扱う場合が問題で、これは既存のAWSのどのサービスでも無理だったはずです。(2年くらい前の調査であるため、今はなにかしらあるかも・・といってもVPN使うケースがほとんどでしょうけど）

PostgreSQLも含めかわってないです。
プラットフォームがRDSになり管理が超絶ラクになりました、この辺の事情はApacheの節と変わらず。

また、検索機能の一部はElasticSearch。
データの永続化はmongodbなどのNoSQLという選択肢も生まれておりそれぞれホスティングされています。

言語を使っていて処理していた２つの内容。

これらのうちViewやViewを生成する機能はSPAとして実装され、SSGまたはSSRとしてCloudFrontやAmplifyに移されています。

ビジネスロジックはコンテナの中でAPIとして提供され、BFFを置くというアーキテクチャもSSRに一部食われてたりするのかなあ・・といった現在進行的な時代の流れもあったりなかったりします。

コンテナに載るということを前提にしている以外ではあまり変わってませんね。

ところでみなさん perl ってご存知ですか？ CGIとか・・・・・え、知らない・・そうですよねハハハ・・・

さてこれらを全部EC2で作るとなぜダメなのかについて私の考えを述べます。

EC2やFargateなどの決められたスペックで24時間365日動き続けるものでは、時間あたりに処理できる計算量が一定です。

オートスケーリングという技法を使って必要な時動的にマシンリソースを増やして運用できるようになりましたが、スパイクと呼ばれる瞬間的なアクセス増というか数の暴力には完全な対抗策がないように見えます。

だからといって常時マシンリソースを張るとそれはそれでコストです。
また、起動やアプリケーションの更新などのメンテナンスもイメージ化されたコンテナよりもめんどくさく、きちんと構築、運用されていなければデプロイやローテーションも面倒です。

この点はサーバレスに軍配があがります。

管理がとことんだるい 構成を動かしづらい。
EC2周りのコンソールの複雑さが全てを物語っているような気がしています。

CDK等のIaCで構築するのであれば、細かい設定をしなければ１０行くらいなんですけどね。

何かを処理させるプラットフォームとしてつるしでEC2を立てるんだったら、もっと簡易に扱えるECSの方が良い。

戦略的かつ機動的にマイクロサービスを運用するのであればkubernetesも視野に入る。

もろもろ便利なサービスがリリースされている中、私はt3.nanoかmicroあたりで動く踏み台サーバくらいにしかEC2を単体で運用するメリットを見いだせないです。