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

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

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

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

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

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

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

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

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

課金事故の発生しやすさ

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

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

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

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

ベンダーロックイン

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

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

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

2. 開発・運用観点でのつらさ

開発環境の構築しにくさ

弊社ではサーバーありきのシステム開発においては、ほぼ各自のマシンにDockerで開発環境を作って開発しています。

しかし、サーバーレスアプリケーションにおいては様々なコンポーネントを組み合わせたアーキテクチャになるため、AWS SAM CLIやDynamoDB localなどはありますが、ローカルマシンに完全な開発環境を作ることはほぼ諦め、実際のAWSの環境で動作確認をしていることが多いです。

Lambda単体のテストはテストコードで担保はするのですが、最終的にシステムとして動作するかはビッグバンテスト的になってしまう部分があるのが少々つらいところです。

フレームワーク

Lambdaは任意の言語で開発ができますが、サーバーレスに特化した形のよいフレームワークは現状ないと思います。
Railsに似せたフレームワークRuby on Jetsは弊社でも試していますが、本格的なサービス構築に利用するには難しいという印象です。

各種制限値

サーバーレスなシステムは基本は無限にスケールするのが基本ではありますが、構成する各種コンポーネントに制限値が設定されているものが多く、意外と引っかかることがあります。特に注意すべき制限値は以下の通りです。

• Lambdaのメモリ
• Lambdaのディスク容量
• Lambdaの実行時間
• API Gatewayのタイムアウト
• DynamoDBのプロビジョンドキャパシティユニット

これらの制限値は設計開発時に考慮に入れる必要があるほか、これらの制限値が障害要因になることも多くありますので注意が必要です。

障害時の調査のしにくさ

サーバーレスシステムの主な障害要因は以下の通りです。

• アプリケーションのバグ
• 前述した各種制限値

サーバーがあるシステムであればサーバーに乗り込んで直接状況証拠を取得したり、再現させて調査をするなどが比較的容易です。サーバーレスシステムにおいては各種メトリクスやアプリケーションが出力するログですべての調査を実施しなければなりません。

したがって、アプリケーションからどういうログを出すかが重要になりますし、調査方法にもコツが必要です。

情報の少なさ

Ruby on Railsをサーバー上で動作させるようなアーキテクチャにおいてはWeb上にいくらでも情報が見つかります。しかし、サーバーレスのシステムを本格的に開発しているケースはまだ少なく、Web上に情報が少なく、手探りで開発していく状況に陥ることが多々あります。

例えばAWS Serverless Application Model (SAM) などのフレームワークを利用するにしても、ブログなどの記事は非常に少ないため、SAM自体のIssueやソースコードを追っていく必要があるケースも発生しますので、気概が必要です。

まとめ

サーバーレスのつらい部分をまとめてみましたが、つらさを上回るメリットがある場合も多々あります。弊社ではお客様のご要件を詳細にヒアリングさせていただき、最適と思われるアーキテクチャをご提案させていただきます。

また、サーバーレスアーキテクチャの開発や保守サポートなども可能です。お気軽にお問い合わせくださいませ。

・お問い合わせ・ご相談

AWS Lambdaを使った最適なアーキテクチャや、メンテナンスコストを考慮したサイトリニューアルについて、以下のページでご案内していますのでぜひご覧ください。

・サーバーレスアーキテクチャ（AWS Lambda）

shimo