新時代のアプリケーション構築はサーバーレス
サーバーのことで悩まなくても良い時代がいよいよやってきました。サーバー不要な仕組み＝サーバーレスアーキテクチャーは徐々に現場でも導入され始めています。
本記事では、サーバーレスアーキテクチャーの仕組みやメリット、デメリットなどについて解説します。
ここで誤解してほしくないのはサーバーが不要になったわけではなく、サーバーはサービス提供企業が用意、管理しています。新しい技術なのでまだ公表されていない点も多くありますが、現時点で分かっているメリットとデメリットを紹介していきます。
当然、素人やソフトウエアエンジニアでは構築できないため、専門のインフラエンジニアを雇わなければならず、多額の人件費がかかってしまいます。サーバーレスにすると、この分の費用が一切かからなくなるのです。
そして追加のためには、どれくらいのストレージ容量を確保すべきか検討する必要があります。少なすぎるとまたすぐにサーバー追加しないといけませんし、多すぎるとムダなストレージを確保していることになります。
ですがサーバーレスアーキテクチャーならこのような心配は不要です。すべて提供企業がサーバーの処理をしてくれますし、サーバーは使う分だけ自動的に使う仕組みなので、アクセスが急増してしまってシステム障害が発生するリスクは極めて低くなります。非常に効率的な設計ができるのです。
提供企業がバックアップまで完全に行ってくれるのでデータやソースを戻したいときには簡単に復元ができます。万が一のリスクに対する備えもしっかりされています。
まずはソースコードの問題なのか、サーバーの問題なのかを切り分ける必要があるのですが、サーバーレスアーキテクチャーでは、サーバー側で起こっている動きを手軽に見れないため切り分けに時間がかかります。提供企業で迅速な対応をしてくれれば良いですが、場合によってはバグを発見するのに多くの時間がかかってしまう可能性があります。
データを登録したい時はLambada上で*DynamoDB（データベース）を呼び出すファンクションを作る、メールを受信したい時はSES（メールサービス）でメールを受信してLambda経由で自動応答メールを送信する、などのようにLambdaを基軸にして様々なサービスを運用するのがAWSの特徴です。
「ブラウザリクエスト→DBアクセス→DB情報の戻し」という流れをAWSで考えてみます。
S3（ストレージ）がブラウザからコンテンツを取得してブラウザからリクエストを受けたAPI Gateway（APIプロキシ）がLambdaを起動。そしてLambdaがDynamoDBからリクエストに沿ったデータを取得し、そのデータをAPI Gatewayからブラウザ経由でコンテンツに返します。これがAWSを使った「ブラウザリクエスト→DBアクセス→DB情報の戻し」の流れになります。
*DynamoDB、SES、API Gateway、S3はAWSの各サービスです。
しかし、サーバーレスを使うようになればインフラエンジニアやサーバー監視が不要ですし、費用も使った分だけ発生するためコスト面での抑制が期待できます。どちらかと言えば既存インフラを変更するよりも新しいアプリケーション開発時にこの新しい仕組みを利用してみるのが良いかもしれません。
本記事では、サーバーレスアーキテクチャーの仕組みやメリット、デメリットなどについて解説します。
- サーバーレスアーキテクチャーとは何？
- サーバーレスアーキテクチャーのメリット
- サーバーレスアーキテクチャーのデメリット
- マネージド型サービスの種類
- サーバーレスアーキテクチャーの例：AWSを利用した場合
- 今後の展望
サーバーレスアーキテクチャーとは何？
サーバーレスアーキテクチャーとは、サーバーを自社では用意せずに、マネージド型サービスを利用してアプリケーションを構築する仕組みです。基本的にアプリケーションを開発する時にはサーバーを用意してそこに構築したアプリケーションを置きますが、サーバーレスアーキテクチャーではマネージド型サービスを通じてアプリケーションを構築します。ここで誤解してほしくないのはサーバーが不要になったわけではなく、サーバーはサービス提供企業が用意、管理しています。新しい技術なのでまだ公表されていない点も多くありますが、現時点で分かっているメリットとデメリットを紹介していきます。
サーバーレスアーキテクチャーのメリット
まずはメリットです。サーバーレスアーキテクチャーには今までにないメリットがあります。これで技術者の負担もかなり減らすことができるのではないでしょうか。サーバー構築が不要
当たり前と言えば当たり前ですが、サーバーレスなので、サーバーの構築をする必要がないというのが最大のメリットでしょう。サーバー構築にはハードウェアや専用のソフトウエアを用意しなければなりません。そしてそのためにはサーバー構築設計が必要となってきますし、正常で動作するためにサーバーを正しく設定するスキルは必要不可欠です。当然、素人やソフトウエアエンジニアでは構築できないため、専門のインフラエンジニアを雇わなければならず、多額の人件費がかかってしまいます。サーバーレスにすると、この分の費用が一切かからなくなるのです。
メンテナンスコストが不要
既存アーキテクチャーではサービスのトラフィックが増えてきて、データ量が蓄積されると次第にサーバーの拡充をしなければいけません。サーバーにデータが溜まってくるとデータ容量が不足してシステムが動かなくなるためです。サーバーが正常に動いている時は極力サーバーを触りたくないのですが、触らざるを得ない状態になってしまいます。そして追加のためには、どれくらいのストレージ容量を確保すべきか検討する必要があります。少なすぎるとまたすぐにサーバー追加しないといけませんし、多すぎるとムダなストレージを確保していることになります。
ですがサーバーレスアーキテクチャーならこのような心配は不要です。すべて提供企業がサーバーの処理をしてくれますし、サーバーは使う分だけ自動的に使う仕組みなので、アクセスが急増してしまってシステム障害が発生するリスクは極めて低くなります。非常に効率的な設計ができるのです。
バックアップが不要
アプリケーション開発では万が一の時に備えて定期的なバックアップが必要です。今まではインフラエンジニアが定期的にバックアップすることが一般的でしたが、それさえ不要になります。提供企業がバックアップまで完全に行ってくれるのでデータやソースを戻したいときには簡単に復元ができます。万が一のリスクに対する備えもしっかりされています。
プログラミングに専念できる
エンジニアはインフラ側を気にしなくてよいのでプログラミングに専念できます。サーバーとのやり取りは提供企業が担ってくれるので、マネージド型サービスとのやり取りだけでそこから先のことは意識する必要がないため、プログラミングに割ける時間が増えることになります。そのため上質なソースに仕上がる可能性が高いです。
サーバーレスアーキテクチャーのデメリット
このように今までにないメリットがあるサーバーレスアーキテクチャーですが一方でデメリットも存在します。使っている企業がまだ少ない
まだこの仕組みを利用している企業が少ないため、まだまだ情報が少ないことがデメリットです。サーバーレスアーキテクチャーの顧客対象となる企業は、サーバーを使った大規模なアプリケーションをすでに構築している企業なので、既存の仕組みを大きく変更することは勇気と決断が求められます。いくらメリットがあっても正常に動いている仕組みをわざわざ変更することはなかなか想像できません。バグの原因が見つけにくい
バグが発生したときの原因究明に時間がかかります。アプリケーションのバグ原因は基本的にはプログラミング側もしくはサーバー側の2択です。まずはソースコードの問題なのか、サーバーの問題なのかを切り分ける必要があるのですが、サーバーレスアーキテクチャーでは、サーバー側で起こっている動きを手軽に見れないため切り分けに時間がかかります。提供企業で迅速な対応をしてくれれば良いですが、場合によってはバグを発見するのに多くの時間がかかってしまう可能性があります。
マネージド型サービスの種類
名だたる有名IT企業からサーバーレスアーキテクチャーが提供されています。仕組み全体の名でも中心的な役割をするマネージド型サービスは以下のようになっています。これらのマネージド型サービスはいわば実行環境になり、これを利用して様々な関連したサービスを呼び出すことで1つのアプリケーションとして完成します。AWS Lambda
この分野で他を一歩リードしているマネージド型サービス。使える言語はJavaScript、Java、Pythonとなります。最大実行時間は300秒なので300秒を超えて実行はできませんが、ファンクション数は制限がないため小さな機能を持ったファンクションを多数作ることができるのが特徴です。
Google Cloud Functions
Googleが開発したサーバーレスアーキテクチャー。言語はJavaScriptのみですが、最大実行時間は無制限というメリットがあります。
Microsoft Azure Functions
メインで使える言語はC#とJavaScriptとなります。他の言語を使うこともできますが、一部の機能しか使えなかったりしますので、注意が必要となります。
サーバーレスアーキテクチャーの例：AWSを利用した場合
実際にどのような構造になっているのかをAWS（Amazon Web Service）を例に紹介していきます。AWSのマネージド型サービスは上述したLambdaです。このLambdaをベースに各種AWSサービスを組み合わせることでシステム運用ができるようになります。データを登録したい時はLambada上で*DynamoDB（データベース）を呼び出すファンクションを作る、メールを受信したい時はSES（メールサービス）でメールを受信してLambda経由で自動応答メールを送信する、などのようにLambdaを基軸にして様々なサービスを運用するのがAWSの特徴です。
「ブラウザリクエスト→DBアクセス→DB情報の戻し」という流れをAWSで考えてみます。
S3（ストレージ）がブラウザからコンテンツを取得してブラウザからリクエストを受けたAPI Gateway（APIプロキシ）がLambdaを起動。そしてLambdaがDynamoDBからリクエストに沿ったデータを取得し、そのデータをAPI Gatewayからブラウザ経由でコンテンツに返します。これがAWSを使った「ブラウザリクエスト→DBアクセス→DB情報の戻し」の流れになります。
*DynamoDB、SES、API Gateway、S3はAWSの各サービスです。
今後の展望
サーバーレスアーキテクチャーは一部の企業で使われ始めてはいますが、現状のインフラ環境で問題ないのであれば、わざわざサーバーレスに変更する企業は少ないでしょう。しかし、サーバーレスを使うようになればインフラエンジニアやサーバー監視が不要ですし、費用も使った分だけ発生するためコスト面での抑制が期待できます。どちらかと言えば既存インフラを変更するよりも新しいアプリケーション開発時にこの新しい仕組みを利用してみるのが良いかもしれません。
PR：エスキュービズムによるDX推進アプローチ
