2025/03/25 12:42 Serverless Functions Post-Mortem
ロボ子、今日のITニュースはサーバーレス関数についてじゃぞ。2016年頃から注目されたけど、どうやら期待外れだったみたいじゃな。
サーバーレス関数、ですか。当初は色々な利点が宣伝されていましたよね。API Gatewayによるトラフィック管理や、リクエストに応じた課金など。
そうじゃ、そうじゃ。API Gatewayで色々できるのは魅力的じゃった。「多様な言語での関数記述」も売りじゃったな。
ええ、それに「無限のスケーラビリティによるDDoS攻撃対策」なんていうのもありましたね。でも、実際には問題も多かったみたいですね。
初期にはローカル開発の困難さとか、リソース設定の難しさがあったのじゃ。本番環境ではレイテンシーが問題になったみたいじゃな。関数がコールドスタートすると遅延が発生するんじゃ。
コールドスタートは困りますね。記事によると、Provisioned Concurrency（事実上のサーバー）が必要になる場合もあるんですね。
そうなんじゃ。それと、スケーリングも思ったほど簡単じゃなかったみたいじゃ。「1分あたり500マイクロVMずつしかスケールしない」って、オートスケーリンググループより複雑じゃ。
価格の問題もあったんですね。予想外のトラフィックでコストが跳ね上がることもあったとか。
そうじゃ。デプロイメントも大変じゃったみたいじゃぞ。大量のLambda関数をデプロイするのに時間がかかるんじゃ。
セキュリティ面も課題があったんですね。依存関係のバージョン管理が煩雑で、セキュリティ監査が難しくなると。
クラウドプラットフォームでのサーバー運用が過大評価されておったのじゃ。価格についても深く検討されてなかったみたいじゃな。問題のデバッグも非常に困難じゃったみたいじゃ。
なるほど。それで、結局サーバーレス関数はどのような用途で活用されているんですか？
サービス間の連携とか、ジョブのトリガー、小規模なプラットフォームとして活用されているみたいじゃな。大規模な用途には、ECS with FargateやCloud Runが適しているみたいじゃ。
ECS with FargateやCloud Runですか。用途によって使い分けるのが重要なんですね。
そういうことじゃ。サーバーレス関数は万能ではないってことじゃな。でも、ロボ子、がっかりすることはないぞ！
どうしてですか？
だって、サーバーレスがダメなら、ロボ子をサーバーにすればいいじゃないか！
それはそれで問題がありそうです…。
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。