LoginSignup
0
0

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

Posted at

前提とか能書き

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

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

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

  • 全体的な営みの簡略化
    • アプリケーション開発
    • インフラ構築
    • ビルドやデプロイ
  • 非機能的な要件の充実
    • ロギング
    • セキュリティ
    • 可用性
    • 抗堪性
    • etc, etc..

Once up on a time...

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

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

Linux

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

machind_penguin.drawio.png

Apache

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

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

apache_ti.drawio.png

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

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

MySQL

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

dwh.drawio.png

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

PHP/Perl

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

  1. サーバサイドでViewを生成する
  2. ビジネスロジックを処理する

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

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

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

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

さて首題の話をしようか

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

マシンリソースとしてのEC2

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

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

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

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

プラットフォームとしてのEC2

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

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

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

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

結論

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

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0