クラウド技術を活用したシステム開発が当たり前となった今、サーバー管理に費やすコストをいかに削減するかは、多くの企業が抱える共通の課題です。
そこで注目されているのが「サーバーレスアーキテクチャ」。サーバーの構築や運用管理をクラウド事業者に委ねることで、エンジニアは開発に集中できるようになります。
ここでは、サーバーレスアーキテクチャの基本的な概要やメリット・デメリット、代表的な活用シーン、主要サービスなどを解説します。
まずは、サーバーレスアーキテクチャの概要と特徴から解説します。
サーバーレスアーキテクチャとは、その名の通り、サーバーを使わずにシステムを構築する手法のことを指します。アプリケーションやサービスを動かすうえで必要なサーバーの準備・管理をクラウド事業者に委ねます。
サーバーレスというと、あたかも物理的なサーバーが存在しないように感じられますが、実際にはクラウド内にサーバーは存在します。開発者がサーバー管理をする必要がないことから「サーバーレス」と呼ばれるわけです。
開発者は主に、イベントをトリガーにしたコード(関数など)を書き上げることに集中できるため、新機能の実装やサービス改善に時間と労力を集中させることができる仕組みとして利用されるケースが増えています。
サーバーレスアーキテクチャの大きな特徴として「イベント駆動型」という点があります。これは、ファイルのアップロードやデータベースの更新、あるいは特定のAPIリクエストなど、何らかのイベントが発生したときに初めてコードが起動して処理を行う仕組みです。
これにより、処理が行われていない状態ではサーバーを起動する必要がなくなるため、従量課金制のクラウドサーバーでも無駄なコストがかかりません。
また、自動的にスケールアウトやスケールインを行うこともサーバーレスの特徴です。一般的なサーバーの場合、突発的なアクセス増には新たなインスタンスを立ち上げる設定や、負荷分散の設定などを手動で行わなくてはいけませんが、サーバーレスの場合はサービス提供事業者に任せられます。
サーバーレスアーキテクチャには、いくつものメリットがあります。ここでは代表的な3つのメリットを紹介します。
サーバーレスアーキテクチャの最大の利点として、物理サーバーや仮想サーバーの構築・運用を自社で行う必要がなくなることが挙げられます。
これまでは、システムを構築する際は、サーバーにOSやミドルウェアのインストールを行い、セキュリティパッチやライブラリのバージョン管理なども自社や開発チームで行わなければなりませんでした。しかしサーバーレスアーキテクチャであれば、それらの作業をユーザーが直接行わずに済むため、インフラ面のオペレーションを大幅に簡略化できます。
また、パッチの適用などを都度チェックし、脆弱性への対応が遅れないよう注意を払う必要がなくなるほか、障害が起きたときに原因調査や復旧に追われることもほとんどなくなります。
こうしたメリットにより、インフラ担当者の負担が大幅に軽減されるほか、細かなサーバーの設定やチューニングに振り回されることも減り、より少ない人員で、開発やサービス改善のサイクルを高速化できるようになるのです。
サーバーレスアーキテクチャを採用することで、従来の物理サーバーや仮想マシンに比べコストを抑えられます。これは、サーバーレスアーキテクチャが「イベント駆動型」であり、利用した分だけ課金される仕組みが採用されているためです。
従来のサーバー運用では、ピークに合わせたリソースを常に確保しておく必要があり、稼働していない時間帯もランニングコストがかかっていました。
しかし、サーバーレスアーキテクチャであれば、アクセスがあったときだけリソースを消費するので、アイドル時にはほぼ料金がかかりません。そのため、季節要因などトラフィックの変動が大きいビジネスでは特に効率的です。
従来のサーバー運用では、負荷が増えた場合には手動でサーバー台数を増やすか、あらかじめ自動スケーリングのルールを設定するなどの対応が必要でした。
しかし、サーバーレスアーキテクチャは、イベントやリクエスト数の変化に応じてスケールアウト・インを自動的かつ迅速に行う仕組みを備えているため、手間をかけずにスケーラビリティが向上します。
これにより、複雑な設定作業がなくなるうえ、過不足を見誤って無駄なコストを支払うことや、システム障害を引き起こすリスクも抑えられます。必要最小限の運用工数で、高い可用性を確保できるため、設備投資を気にすることなく、サービスの拡張や新規導入を行えます。
サーバーレスアーキテクチャは、具体的にどういったシーンで長所が活かされるのでしょうか。ここでは代表的な活用シーンについて解説します。
イベント駆動型であるサーバーレスアーキテクチャにとって、画像ファイルのアップロードをトリガーとした各種処理は代表的な活用例といえます。
例えば、ユーザーがクラウドストレージに写真やイラストなどの画像ファイルをアップロードすると、そのイベントを検知した関数が起動し、必要に応じて画像のリサイズや圧縮、サムネイルの生成などを行います。また、こうした処理が完了したら、結果を別のストレージに保存してフロントエンドで利用できるようにする…といったワークフローもスムーズに組めます。
こうした仕組みを従来のサーバーで運用する場合、常時ピーク時を想定したリソースを確保しておく必要がありましたが、サーバーレスならアップロードされたタイミングだけ処理を行えばよく、無駄なコストがかかりません。
IoT(モノのインターネット)では、多数のデバイスがさまざまなセンサー情報をクラウドへ送信し、それらのデータをリアルタイムに処理・解析します。こうしたIoTのデータ処理基盤の構築でも、サーバーレスアーキテクチャは活躍します。
例えば、IoTデバイスからデータが送られたことを検知した時点でサーバーレス関数が起動し、センサー値のフィルタリングや集計などを行ったうえでデータベースに保存することが可能になります。また、大量のデバイスから不規則にデータが送られてきても、自動スケーリングによって負荷に応じて処理能力を拡大・縮小できるため、ピークを予測する必要もありません。
こうした特性から、IoT分野で求められるリアルタイム性や可用性を高いレベルで確保しやすいのがサーバーレスアーキテクチャの強みとなります。
ここでは、サーバーレスアーキテクチャサービスを提供する代表的な事業者(ベンダー)を紹介します。
https://aws.amazon.com/jp/lambda/
AWS Lambdaは、サーバーレスアーキテクチャが普及するきっかけとなったサービスの一つです。AWS(Amazon Web Services)が2014年にリリースし、「イベント発生時に自動でコードを実行する」ことが革新的と注目を浴びました。
LambdaはAWS内の他サービスとの相性が非常によく、トリガーイベントを設定して非同期的に動かせます。Node.jsやPython、Javaなど複数の言語に対応しており、近年はコンテナイメージをベースにしたデプロイもサポートされています。
料金はリクエスト数と実行時間に基づいた従量課金制で、一定の無料利用枠も設けられているため、小規模な実験から大規模な本番環境まで多様な用途で利用可能です。
https://azure.microsoft.com/ja-jp/products/functions
Azure Functionsは、Microsoft Azureが提供するサーバーレス実行環境で、こちらもメジャーなサーバーレスアーキテクチャサービスです。開発者はC#やJavaScript、Pythonなどの言語の使用が可能で、Microsoftのクラウドサービスとの連携がしやすくなっています。
Azure FunctionsもAWS Lambdaと同様、従量課金制となっていて、実行時間や呼び出し回数によって請求額が決定する仕組みです。Azureのサービス群をすでに導入している企業にとっては、スムーズに統合しやすい利点があります。
https://cloud.google.com/functions
Google Cloud Functionsは、Google Cloudが提供するサーバーレスコンピューティングサービスです。主にNode.jsやPython、Goといった言語に対応しており、Google Cloudが提供する各サービスとの連携に強みがあります。
料金は、他社サービス同様にリクエスト数と実行時間に応じた従量課金制で、小規模なワークロードでは無料枠内で運用できるケースもあることが特徴です。
Googleの機械学習APIなどとの連携を考えている場合、データ分析の前処理やイベントハンドリングにGoogle Cloud Functionsを活用するケースも多くなっています。特に、Googleサービスと一体的にクラウドを活用したい企業にとって魅力的な選択肢となるでしょう。
サーバーレスアーキテクチャには課題も存在します。ここでは代表的な2つの課題について解説します。
サーバーレスアーキテクチャでは、実行基盤をサービス提供事業者(ベンダー)に一任するため、どうしても特定のサービスへの依存度が高まります。この状況を「ベンダーロックイン」と呼びます。
特定のサービス固有の仕組みを活用するほど、他社クラウドへ移行する際のコストと難易度が上昇します。そのため、マルチクラウド戦略をとりたい企業にとってはマイナス要素となる可能性があるでしょう。
また、サービス提供事業者側で障害が発生した場合、自社でコントロールしきれない部分が多く、サービスが利用不能になるリスクも否めません。
サーバーレス環境では、コードが実行される時間が非常に短く、かつ自動スケールの裏側で複数のインスタンスが動的に立ち上がるため、トラブルシューティングや詳細なデバッグの難易度が上がります。
ローカル環境で同じ状況を再現しようとすると、クラウドサービスと同じリソースやイベントトリガーを用意しなければなりません。また、実行基盤がブラックボックス化しやすいため、遅延やタイムアウト、アクセス権の問題などが発生した際に、どの部分で障害が起きているのか判別しにくいこともあります。
各サービス提供事業者は、ログ出力やモニタリングツールを提供していますが、マイクロサービス的に関数が分散配置されていると、ログを集約・分析するための仕組みづくりが必要になります。
また、サーバーレス特有の問題として、初期起動遅延があり、普段は問題なく動いているように見えても、長期間呼び出されなかった関数だけが遅延を起こすケースも存在します。
これらを踏まえ、サーバーレスに対応したデバッグの手法を導入していくことが重要です。
サーバーレスアーキテクチャは、高い拡張性と運用効率を実現できる手法として利用が広がっています。特に、不規則なトラフィックが発生するサービスやアプリケーションでは、大きなコスト削減や運用負担の軽減が期待できるでしょう。
一方で、サービス提供事業者への依存度が高くなるベンダーロックインや、デバッグが難しいといった課題もあるため、導入の際は自社の要件や、開発・管理の体制を見極めることが重要です。
今後もクラウドの利用が拡大していくなかで、サーバーレスアーキテクチャは、ビジネスのスピード感を支える選択肢としてますます存在感を高めていくでしょう。