サーバーレスをオススメする理由

こんにちは、中山（ @k1nakayama ) です。

弊社では、お客様に対しサーバーレスでの構築・運用をオススメしております。
今回は、なぜサーバーレスがオススメなのかをご説明いたします。

サーバーレスの特徴

サーバー管理不要

柔軟なスケーリング

高可用性の自動化

価値に対する支払い

サーバー管理不要

サーバーレスアーキテクチャでは、「サーバーレスとは」で説明したとおり、従来のオンプレミス環境やEC2等の仮想サーバー環境では当たり前だった、サーバースペックの考慮などの構築時に必要な管理をはじめ、各種パッチ適用やバックアップ管理などの日々の運用におけるサーバー管理等は、AWSなどのクラウドベンダーに任せることができるため、サーバー管理不要でアプリケーションの開発や運用に集中することができます。

柔軟なスケーリング

オンプレミスでは、1年間で最も負荷が高くなるであろう時期を想定し、予めその最大需要に耐えられるようにサーバーを運用することをしており無駄の多い体制となっていました。EC2に移行することでオートスケーリングによって、これらの負荷状態の増減に合わせてインスタンス数をスケーリングさせることが出来るようになりましたが、EC2のオートスケーリングの場合、新たなインスタンスが立ち上がるまでに数分間を要することや、適切なスケーリング設定を行えていない場合、オートスケーリングを使用していても需要に応じることが出来ない状態が発生してしまいます。
サーバーレスでは、これらのスケーリングについても自動化がされているため、需要に合わせて瞬時にスケールアウトが行われ、必要がなくなればスケールインします。また、ストレージサービスの場合、使用量に応じて自動的に使用可能なストレージが拡張され、ストレージ容量を気にしながら運用する必要がありません。

高可用性の自動化

オンプレミスやEC2の場合、サーバーが正常に稼働しているかを常時サーバー監視し、インシデントが発生したらサーバーの復旧作業を行うことが必要でした。EC2でロードバランサとオートスケーリングとの組み合わせによるオートヒーリング機能を活用することで、より高い可用性を求めることが可能となりますが、アベイラビリティーゾーン全体で障害が発生している場合など、より高度なリカバリ対策を行っておくことが必要となります。
サーバーレスでは、これらの高可用性についても自動化がされており、ユーザーが意識せずに高度なリカバリ対策が実装されているため、仮にホストサーバー上でインシデントが発生していても、ユーザーにはほとんど気づかない形で対処がされます。

価値に対する支払い

クラウドは原則として「使ったら使った分だけの従量課金での支払い(Pay as you go)」となります。しかし、EC2などの仮想サーバーサービスにおいては、「使った」という考え方は「ユーザーの要求に応じてサーバーを起動させていた」という考え方となり、実際にはサーバーを起動させていたものの、CPUリソースをほとんど使っていない状態でも時間当たりのコストを支払うこととなります。
サーバーレスの場合、基本的にはイベント課金となることが多く、実行回数や実際に実行するためにリソースを使用した時間（ミリ秒など）、使用した容量などで課金が行われ、本来のクラウドを利用する目的（価値）に対して課金が行われます。

本来の業務に注力することができる

さて、本題のオススメする理由について1つ目に挙げられることは、「サーバーレスを採用することで、他社との差別化に繋がらない業務から開放され、本業に注力することが出来る」という点となります。

サーバー管理や運用の委託を受けているMSP業務を提供する事業者や、サーバー自体の提供を行っているホスティング事業者などは当然として、一般的にインターネット上でサービスを提供している企業や、インターネットを介して商品の販売等を行っている企業にとっても、これまでサーバー管理を何らかの形で行うことは必然でした。
しかし、このような企業にとって、どれだけサーバー管理業務に力を入れても、サービスの品質向上や機会損失を減らすことにはつながっても、それ自体によって売上が向上することはありません。寧ろ、これらサーバー管理業務に力をいれれば入れるほど、管理コストや外注費、人件費等が嵩むという問題が大きかったかと思います。
そのため、サービス等について他社との差別化には繋がらない、大きなコストとなっていました。

サーバーレスでは、前述の特徴で示したとおり、日々のサーバー管理業務やアクセス増等に対するスケーリングの管理・対応、可用性に対する対応など、これまでサーバー管理業務として行ってきた多くの業務をAWSなどのクラウドベンダーに委ねることができます。
そのため、これらの対応を行っていた外注費等削減し、本来のアプリケーション開発等の他社との差別化を行っていく部分に注力することができます。

コスト最適化がしやすい

2点目は、サーバーレスで構築することにより、「コスト最適化が行いやすい」という点です。

ここでは、Webサーバーを例に考えてみたいと思います。
従来のシステム構成で企業がサービスを提供するために、EC2などの仮想サーバー（IaaS）を使用して運用しているとしましょう。このシステムは、EC2上にWebサーバー機能とアプリケーション機能、DBの全てを持ったスタンドアローンな最小構成で動いています。（そもそも、このような構成で本番ワークロードを運用することは、オススメできませんが、イメージがしやすいようにしております）
このサーバー構成で運用した際、Webサイトの特性上いつアクセスが行われるか分からないため、必然的に24時間365日常時稼働させておくことが必要となります。
そのため、この構成の際の運用コストは、EC2インスタンス1台分の約730時間分の費用が毎月固定的に発生します。

このサイトへのトラフィックが仮に全く無かったとしても、このシステムでは固定的な運用コストが発生してしまい、1台のインスタンスでは受けきれないトラフィックに増加してきた際には、スタンドアローンの構成を見直し、少なくとも2層の構成でWebサーバーやDBサーバーの負荷を分散出来る構造にしていくことが必要であり、そのようにスケールさせた際は、更に多くのコストが発生してきます。

では、サーバーレスアーキテクチャで構成されたWebアプリケーションの場合どうでしょうか？
AWS上のサーバーレスアーキテクチャで、動的なWebサイトを構成する場合、オーソドックスな構成としては、下記のようにシングルページアプリケーションをCloudFront経由で配信し、APIからデータを受け取ってサイトを表示するものになります。

S3上に配置したSPA用コンテンツの容量分のコストは固定的に発生しますが、それ以外のコストは原則としてイベント発生毎にのみ発生するものとなります。
そのため、仮に全くアクセスが無かった場合は、コストが発生せず、サイトへアクセスがあったら、そのアクセス数にほぼ比例した形でコストが発生していきます。

このように、サーバーレスアーキテクチャで構成されたアプリケーションは、原則としてイベント発生毎の課金発生となるため、価値（サイトへのアクセス）に対する支払いとなり、コスト最適化がしやすい構造となります。

ちなみに、EC2インスタンスをm5.largeの1台で運用した場合と、API Gateway（HTTP API）+ Lambda(512MBメモリ、平均300ms）、DynamoDB（オンデマンドキャパシティ、書き込み：読み込み= 20%:80%)といった想定で試算した際に、月間約2,000万リクエストがAPIに対して行われると概ねEC2と同じコストになりました。
そのため、1台で2,000万PV（1PV 1APIリクエストとして）以上を捌ける構成にした上で、毎月同様の安定したアクセスがある場合を除いて、サーバーレスアプリケーションのほうが、安く安定したワークロードを運用することが出来ることが分かります。

プログラマーだけでも本格的なアプリケーションを構築できる

上記2点は、どちらかというと経営層やプロダクトオーナーなどにとって有益となりやすい理由を挙げてきましたが、3点目に挙げる理由は、エンジニアを目指している方や、エンジニアとしてキャリアアップを目指す方、更にはCTOなどのエンジニアを取りまとめているポジションの方に、共感してもらえると思う理由です。
サーバーレスアーキテクチャにおいては、「主にプログラミングを勉強してきた方だけでも、本番のワークロード全体を構築することが出来る」という点です。

従来のアプリケーション開発・運用においては、アプリケーション本体の開発を行うことが出来るプログラマーはもちろんですが、彼らだけでは十分なワークロードを構築することは困難でした。
それは、構築したアプリケーションを動かすための箱となる、サーバー構築やネットワーク周りの構築を行うことが必要であり、それらを運用し続けるための知識や経験を持ったエンジニアが不可欠でした。
エンジニアが大勢いる企業などでは、アプリケーション開発を行う部門と、サーバー周りの構築や運用を行う基盤チームなどに分かれていることもしばしばあるかと思います。また、そのような専門性をもったエンジニアを抱えることが難しいスタートアップ等の企業の場合、いわゆるフルスタックエンジニアが1名は在籍していて、その方がアプリケーション開発以外の必要となる構築を担っているケースも多く見受けられます。

EC2などのIaaSを使ってアプリケーションを構築する場合も、この点においては同様で、EC2上のミドルウェアのインストールや、VPC等を含むネットワーク構成について知識を持ったエンジニアが構築を行うことが求められます。

では、サーバーレスにおいてはどうかというと、これまでお伝えしてきたとおり、サーバーレスアーキテクチャは、フルマネージドなサービスを組み合わせ、自らが提供しようとしているアプリケーション部分を開発し、それらのフルマネージドサービスの上で動くように構成することで、ワークロードを構成することができます。
ネットワーク環境などの管理や、サーバー等のインスタンス管理、その上のミドルウェアのインストールや日々の運用等は一切不要です。
サーバーレスアプリケーションを動かすためには、サーバーレスアプリケーションを構成する各種サービスを選定し、それらのサービスに対する設定を行い、それらサービスをつなぎ合わせるためのアプリケーションコードを開発するだけで構築することが可能です。

つまり、サーバー構築や運用、ネットワークについての深い知見を持ったエンジニアが不在でも、PythonやJavaScript等のアプリケーションコードを書くための知識を持ったプログラマーさえ居れば、サーバーレスアプリケーションを構築することができます。

もちろん、サーバーレスアプリケーションを構成する各種AWSサービスなどの知識を付けることは必要となりますが、それらは基本的にユーザーが与えた設定に従って適切に動くようにAWS側で管理されて提供されているものですので、複雑な知識は不要です。
また、今後このブログでも紹介していきたいと思いますが、サーバーレスアプリケーションにおいては、上記のWebアプリケーションの構成例のように、ある程度のデザイパターンと呼ばれる構成パターンが存在します。アプリケーションエンジニアは、これらのデザインパターンに沿ってサービスを組み合わせ、それらをつなぎ合わせるためのコードのみ用意すればよいのです。

このように、プログラマーのみでも本格的なアプリケーションを構築することができます。つまり、彼らはワークロードを構成する全てを1人で対応することが出来るわけですから、従来のフルスタックエンジニアに相当する役割を担うことができます。

そして更に言えば、サーバーレスアプリケーションを構成するアプリケーションコードでは、WEBアプリケーションフレームワークなどを使用せず構築されることが大半です。そのため、それらの知識も不要であるため、プログラミングスクールでプログラムの基礎を勉強した駆け出しエンジニアなどでも、十分に構築を行うための役割を担うことが可能です。
現に、弊社では未経験エンジニアの採用をこれまで多く行ってきており、そのようなエンジニアであっても、数ヶ月で本番ワークロードで稼働するアプリケーションを、ほぼ1人で構築することが出来るようになっています。

まとめ

今回は、サーバーレスをオススメする理由についてお伝えしてきました。
いかがでしょうか？この記事をお読みいただいている方が、少しでもサーバーレスについて興味を持っていただき、今後の取り組みの参考になれば幸いです。

また、今後は実際にサーバーレスアプリケーションを開発していく、サーバーレスエンジニアを目指したい！という方のために、様々なサーバーレス開発に必要なノウハウを共有していきたいと思います。