サーバレスってサーバが無いの？
答え「有ります」
では、何がレスかというと「使わない時はサーバが無い」のです。
もう少し言うと「サーバを管理する必要が無い」のです。
しばらく前回の投稿から時間が空いてしまいました。
その間に「クラウドBOT®」のBOT機能をサーバレス化しました。というリリースを出しました。
そこで、今回はサーバレスについて書いてみたいと思います。
主に上記リリース記事に書いてある通りなのですが、もう少し突っ込んだ話をしたいと思います。
サーバレスでは、ハードウェア・OS・ミドルウェア等の管理をする必要がありません。なので、実際にはサーバ管理レスと言う方が適切なのかも知れません。もしくは、システム管理者からサーバが見えなくなるという意味でサーバレスなのかも知れません。
現在、大手のクラウドサービス事業者から様々なサーバレスサービスが提供されています。
しかし、今回はその中でも「サーバレスコンピューティング」、いわゆるAWSのLambdaやGoogleのCloud Functionsのような「FaaS」(Function as a Service)に絞って書いていきたいと思います。
サーバレスコンピューティングと言えば、AWSのLambdaです。
そのLambdaがリリースされたのが2014年11月。
発表から6年目に入ったLambdaは、それほど目新しいサービスでも無く、既に色々なクラウドシステム(SaaS)で活用されています。
それでも、今回クラウドBOT®のサーバレス化をあえてリリース発表したのは、サーバレスによって劇的にクラウドBOTの可能性が広がるという事と、その可能性を広く知ってもらいたいと考えた為です。
サーバレスとは
クラウドコンピューティングが普及する前は、自社のサーバルームや自社管理のデータセンタに自社所有のサーバを設置していました。
これをオンプレミスと言います。
セキュリティや安定運用の観点から、現在でもオンプレミスを採用している企業は数多くあります。
オンプレミスでは、物理的なハードウェアを全て自前でメンテナンスする体制を構築し、故障時のリスクも自社で担保する必要があります。
サーバ機を購入する場合も「5年間は使用するので5年後にどれほどの処理負荷になるか、故障した時の為に予備機を何台購入するべきか」といった計画を立てる必要があります。
これに対して、クラウド上でサーバを立ち上げる事ができるクラウドコンピューティング、いわゆるIaaS(Infrastructure as a Service)は、必要な時に必要な性能のサーバを必要な期間立ち上げる事ができます。
故障した場合も、自動的に正常なハードウェアが割り当てられるので自前で予備機を準備しておく必要はありません。
このように、サーバ運用会社は物理的なハードウェアの管理から開放されてOS以上のソフトウェアだけを管理すればよくなりました。
サーバの調達からネットワークの構築、ソフトウェアのセットアップまで全てキーボードとマウスの操作だけで出来てしまうという非常に画期的なサービスです。
まさにサービスとしてのインフラ「Infrastructure as a Service」です。
さらに、OSやミドルウェア等のプラットフォームも含めてサービスとして提供されるPaaS(Platform as a Service)というサービスも有ります。
これで必要な時に必要サーバを「瞬時」に立ち上げる事ができるようになりました。
しかし、「瞬時」と言っても実際にはサーバの起動指示をしてから利用者が使えるようになるまで数分かかります。
物理サーバのようにサーバ機器を発注してから納品、設置、セットアップまで少なくとも1週間はかかるという感覚からすれば一瞬ですが、システム利用者がシステムにアクセス要求してから応答するまで数分間も待たせる事はできません。
通常、システム利用者がキーボードやマウスを操作してから応答が返るまで３秒かかるとちょっと遅いなと感じます。 10秒以上かかると結構待たされていると感じます。
この事から、システムを快適に利用してもらう為には、いつアクセスしてくるか分からない利用者の為に常にサーバを起動しておく必要があるのです。
ほとんどアクセスが無い時間帯であっても、1件でもアクセスの可能性があるならばサーバを立ち上げておく必要があります。
これに対してサーバレスとは、上図の通りアプリケーション以外は全てクラウドサービスに任せてしまうという仕組みになります。
アプリケーションは関数として事前に登録しておきます。
関数を実行していない間、サーバは割り当てられていません。
そのため、実行されるまでサーバ料金は一切発生しません。
そして、いざアプリケーションの実行が必要になった「瞬間」に、僅か１秒程で関数を実行する為のサーバが割り当てられ、処理が実行されます。
この時、アプリケーションの実行開始〜終了まで100ミリ秒単位でサーバ利用料が課金されます。
サーバレスは安いのか？
使い方によります。
AWSサービスの場合、サーバレス(Lambda)の料金単価は、常設用サーバ(ec2)に対して時間あたり約3倍の料金単価が設定されています。
つまり、常設用サーバを1日24時間稼働する場合と、サーバレスで1日8時間実行する場合でほぼ同じ料金になるのです。
そのため、同じ負荷状態で連続的に処理をし続ける場合は常設用サーバの方が安くなります。
WEBサイトも1日8時間以上、一定のアクセス負荷が発生するような場合、サーバレスを導入する事でむしろコストが上がる可能性があります。
また、１日の特定時間だけ大量のバッチ処理を実行するようなケースも、実行するタイミングが予測可能であれば、その時間帯だけec2のサーバを起動してバッチ終了後にサーバを停止する方がサーバレスより安くなったりします。
逆に、サーバレスの方が安くなるケース。
さらには、サーバレスが最も有効に活用できるケースはというと、
実行タイミングが予測できず、瞬間的に大量の負荷が発生するケース
です。
例えば、
1日あたり約10分、散発的にサーバ1000台規模の負荷が発生するケース
の場合を考えてみましょう。
その大量負荷がいつ発生するか予測できません。
しかし、ユーザが指示した瞬間に要求を実行する必要があります。
ec2のサーバで対応する場合、いつ来るか分からない実行要求に備えて1000台のサーバを常時配置しておく必要があります。
その場合の費用は、サーバ1台の料金が月額1万円とすると1000台で月額1000万円の金額になります。
もし、これをサーバレスで対応した場合、1日10分×30日で月間5時間(300分)の稼働になります。
24時間稼働するec2は24時間×30日で月間720時間の稼働です。
サーバレスの稼働時間はec2の144分の1、サーバレスの単価が3倍なので
1000万円÷144×3＝約20万円
の月額費用となります。約50分の１のコストです。
一般的なWEBサービスでは、予測できないタイミングで瞬間的に大量負荷が発生するケースはそれ程多く無いと思います。(特定記事がバズったり、事件やニュース等で大量負荷が発生するといった場合はあるかも知れませんが)
しかし、クラウドBOT®のようなBOTサービスは、まさにそういったケースに該当するのです。
クラウドBOT®の負荷特性
クラウドBOT®は、ユーザが作成したBOTを全てクラウド上で実行します。
そもそも、BOTの作成自体もクラウド上で行います。
全てをクラウド上で処理する事によって、利用者はどのパソコンやタブレット・スマフォからでもBOTの作成や実行が可能になるのです。
先日、BOTの作り方をご紹介した記事の、BOT作成画面で見えていたGoogleのページは、実はクラウド上で動いている仮想ブラウザの画面をリアルタイムにパソコン上のブラウザ上に映し出していたものなのです。
Windowsのリモートデスクトップを利用された事がある方はイメージしやすいかも知れませんが、簡単に言うと、クラウド上の仮想のブラウザを遠隔操作する事でBOTの作成や実行を実現しているのです。
クラウド上で仮想ブラウザの操作を自動記録してBOTを作ったり、BOTに記録された手順通りに仮想ブラウザを動かして自動操作しているのです。
この仮想ブラウザを安定動作させる為には1GB程度のメモリを確保する必要があります。さらに仮想ブラウザを制御する処理等も考慮して、例えば１つのBOTに1.5GBのメモリを割り当てるとします。
この場合、4GBのメモリが搭載されたサーバで何個のBOTを同時実行できるでしょうか。
OSやミドルウェア等に1GBのメモリを割り当てると考えると、残りは3GB。
ちょうどBOT２つ分ですね。
もし、BOTを３つ動かした場合は１BOTあたりのメモリ量は1GBになります。４つ動かした場合は0.75GBです。
１サーバで同時実行するBOT数を増やせば、１BOTあたりのコストは減りますが、同時に１BOTに割り当て可能なメモリ量も減っていくので、安定性も低下してしまうのです。
上記では分かりやすいようにメモリで説明しましたが、CPU処理能力についても同様の事が言えます。
このBOTはいつ実行されるか、同時に何個実行されるか予想がつきません。
利用者が実行したい時に実行するからです。
このようにクラウド上でブラウザを実行するクラウドBOT®のようなサービスは
いつ大量の負荷が発生するか分からないし、発生しないかも知れない
という特性があると言えます。
これは、前段でサーバレスを最も有効に活用できると説明したケースと一致します。サーバレスは、まさにクラウドBOT®のようなサービスに最適な仕組みなのです。
先程、通常のサーバでは、同時実行するBOTを増やせば増やす程、割り当てメモリが減少し不安定になると説明しましたが、サーバレスの場合は実行する毎に所定のメモリとCPUが割り当てられます。
しかも、BOT実行ごとに専有のサーバリソースが割り当てられる為、他のBOTが重い処理を行っていても影響を受ける事はありません。
BOTの安定実行とは、ただダウンしたり遅くならないという事だけではありません。想定よりも早くなり過ぎないという事も安定性の一つです。
いつ実行しても都度所定のサーバリソースが割り当てられて、同じ処理性能で実行する事で安定したBOT動作が可能になるのです。
サーバレスの高可用性とは
高可用性という言葉ご存知でしょうか。
ITエンジニアの方であれば当たり前の言葉かと思いますが、
ハイ・アベイラビリティ(High Availability)
とも言われます。
可用性とはサービス提供し続けられる性質の事です。その性質が高い「高可用性」とは、「サービスが停止しにくい事」とも言えます。
一般的に、この高可用性を確保する為の仕組みとして「冗長化」という手段が取られます。
簡単に言うと、サーバを複数設置して２重化、３重化する事で、いずれかのサーバがダウンしても残りのサーバで動き続ける仕組みです。
「もしもの時の為のサーバ」を確保しておくので、１台止まっても残りのサーバで全ての処理をこなせるように性能に余裕を持ってサーバを配置する必要があります。この余裕を持つ事自体もコストとなります。
これに対してサーバレスの場合はどうでしょうか。
サーバレスの場合、常時動いてるサーバは有りません。
つまり停止するサーバが無いのです。
サーバレスの場合、
BOTを実行する瞬間に「動いているサーバ」が割り当てられます。
実行時に、壊れていない稼働中のサーバ（誰も使っていないサーバ）を随時割り当ててくれるので、当社のようなサービス提供会社が冗長化を意識しなくても見えない所で高可用性を実現してくれいているとも言えます。
最後にセキュリティ
ここまでお話すると、セキュリティに対する耐性についてもご想像がつくかも知れません。
処理を実行している時しかサーバが動かない
という特性上、外部からサーバ内に入り込む余地が少なくなります
サーバ環境は１実行ごとに割り当てられる
という事から、サーバ何に万が一悪意のある何かが仕込まれたとしても、次回実行時には新たに別のサーバ環境が割り当てられます。（正確には一定時間同じサーバが割り当てされる場合もありますが、メモリは割り当て毎に初期化されます）
他ユーザ、他BOTとメモリやCPUが共有されない
これは、共有サーバでは悪意ある他ユーザから何らかの影響を受ける可能性が考えられますが、１実行毎に専有リソースが割り当てられるので他の影響を受けにくいと言えます。
サーバレス内のネットワークは閉じている
これはLambdaの特性かも知れませんが(他は調べてません)、サーバレスとして起動したプログラムはネットワーク経由で外部からのアクセスを受け付ける事ができません。
これは、外部のインターネットから社内PCにアクセスできないのと同じ様に、Lambdaも内から外向きの一方向の通信しか許されていないという事です。
つまり、外部ネットワークからの攻撃に晒されるリスクが低いと言えます。
サーバレスをまとめると
ここまで、長々と書いてきた内容をまとめると、クラウドBOT®はサーバレス方式を採用した事により
維持費が安くなり、サービスも廉価に提供できるようになった
BOTを大量実行されても安定動作が可能になった
BOTサーバがダウンするリスクが無くなり、可用性が高まった
BOT毎に隔離された領域で動作する為、セキュリティ耐性が高まった
という事が言えます。
１点、サーバレスのデメリットも最後に書いておくと
サーバレスを採用する場合、システム開発において様々な制約を受ける事になります。
AWS等のサーバレス事業者側の立場に立って考えると、サーバを使った時間だけ課金するという事は、いつ使われるか分からない、どれだけ使われるか分からない中、使われていないサーバを維持するリスク（コスト）を全てサーバレス事業者が負担するという事になります。
そのため、使われないサーバリソースは、他のサービス用に再配置したり、使用しない間は電源を止めたり、稼働率の低い複数の物理サーバを１台に集約したり、様々な最適化を行う事でそのロスを最小化します。
その最適化をより効果的にする為に、サーバレスサービスの利用者（開発者）にもシステム開発上の制約を課しているのです。
逆に考えると、我々はそれら制約事項に対応してサーバレスに適したシステムを開発する事でサーバレスのメリットを享受できるとも言えます。
正式サービス開始まであと少し
クラウドBOT®の正式サービス開始は４月に予定しています。
正式サービスを提供する為の基盤も整い、今後は順次機能の強化も進めていく予定です。
正式サービス開始時には有料サービスの提供を予定しています。
正式サービス以降も無料プランの提供を予定していますが、β期間中の無料プランと内容が異なる可能性があります。
ご興味のある方は、是非今のうちに無料プランを登録して触ってみて下さい。
β期間中にお申し込み頂いたプランは、正式サービス以降もそのままのプラン内容でご利用継続が可能です。
それでは、長々と記事を読んで頂きありがとうございました。
noteのコメントやTwitter宛でも良いので感想等も頂ければ幸いです。
この記事が気に入ったらサポートをしてみませんか？