2020.03.27

サーバーレス開発を5年続けてきたMMMがサーバーレスのつらさを紹介します

shimo

弊社でシステム開発案件をお受けする際には、お客様のご要件をヒアリングし、最適なアーキテクチャをご提案させていただいております。

その中で、特に運用コストの削減やスケールのしやすさを目的にサーバーレスアーキテクチャをご提案することも多くあり、これまでサーバーレスアーキテクチャをベースした豊富なシステム開発を経験してきました。

しかし、サーバーレスアーキテクチャのシステム開発の中で、サーバーレスのつらさというのも色々と経験してきた部分もあり、今回はサーバーレスのつらみをご紹介していきたいと思います。なお、弊社はAWSのアドバンスドコンサルティングパートナーであり、AWSのサーバーレスに特化している部分が多いことご了承ください。

ビジネス観点でのつらさ、開発・運用観点でのつらさ、の2本立てで書いてみます。

1. ビジネス観点でのつらさ

Contents

運用コストの見積もりにくさ
課金事故の発生しやすさ
ベンダーロックイン
開発環境の構築しにくさ
フレームワーク
各種制限値
障害時の調査のしにくさ
情報の少なさ

運用コストの見積もりにくさ

これまでの経験上、サーバーレスアーキテクチャはサーバー前提としたシステムよりも運用費 (AWS利用料金) が安くなることがほとんどです。ただ、そもそもコストの見積もりがしにくい料金体系になっていることも事実です。例えばサーバーレスの主コンポーネントであるLambdaでいうと、AWS Lambda 料金に記載されているように、リクエストおよび実行時間での課金 (完全な従量課金) となっています。

普通のサーバーの場合の見積もりにおいては、どれくらいのスペックのものを何台用意するかを考えれば自ずと料金も見えてきますが、完全従量課金なサーバーレスアーキテクチャにおいては運用費の見積もりにおいて経験・コツが必要となります。

なお、サーバーレスアーキテクチャの方が安くなることがほとんどと書きましたが、システムの特性によってはサーバー前提のシステムのほうが安くなるケースもありますのでご留意ください。

課金事故の発生しやすさ

サーバーレスアーキテクチャは基本的には無限にスケールします。したがって、システムへの急激なアクセス増にも特に何もせずに耐えられるわけです。

しかし、無限にスケールするがゆえに事故が起きる可能性もあります。弊社での経験談が 10日間でAWS Lambda関数を28億回実行した話に記載されていますが、プログラムのバグによりLambda関数を無限ループで実行してしまった結果、意図せず30万円ほどの請求が発生してしまいました。

もちろんサーバー前提としたシステムにおいても同様の課金事故のリスクはあります。例えばオートスケールにより自動的にサーバーを増やしたり減らしたりするような場合には設定ミスなどにより予期せずサーバーを増やししすぎてしまうなどです。ただ、サーバーレスの場合はより危険性が高いと考えています。

こういった事故を防ぐにはアプリケーションの作り込み時に注意することも大事ですが、課金アラームをある程度低い金額でセットしておき、万が一課金事故につながるバグを作り込んだ場合の影響を最低限に収めることが重要となります。

ベンダーロックイン

サーバーレスにおけるベンダーロックインのリスクはよく言われることではありますが、個人的にはそこまで気にする必要はないのではないかという印象を持っています。

サーバーレスアーキテクチャにおけるプログラムの実行基盤は基本的にはLambdaとなりますが、Lambda単体で見ればそこまでベンダーロックインではありません。一部Lambdaに特化したプログラムになる箇所は出てきますが、基本的にロジックはLambdaで動かす場合とサーバーありで動かす場合で同じコードが使い回せます。

SQS、DynamoDBのようなコンポーネントを組み合わせるとベンダーロックイン色が強くなってきます。ただ、そこまで大規模なシステムでなければある程度の工数は必要とはなりますが、いざとなったら書き直せるのではないでしょうか。