サーバーレスアーキテクチャー

2020年4月27日

クロアのロードバイク乗り

 

CACクロアの“ロードバイク乗り”です。春まで雪が積もるような土地に住んでいますので、冬は外を走れません。その間は室内でバーチャルサイクリングを楽しんでいます。バーチャルサイクリングを知らない方は検索窓に「ZWIFT」と入力してみてください。


さて本稿では、最近耳にすることが多いサーバーレスアーキテクチャーについてご説明いたします。昔からソフトウエア構築に携わっていた者にとって、当初は想像すらできなかったアーキテクチャーです。

そもそもサーバーレスアーキテクチャーとは何なのか?

Amazon(AWS)、Google、Microsoftといった名だたるクラウドベンダーが「クラウドサービス」と呼ばれるインターネットを利用した情報基盤を提供する前は、各企業がインフラ(サーバーなど)とソフトウエアを個々に所有し、コンピューターシステムを構築していました。


しかし現在では、このクラウドサービスを使ってシステムを構築することにより、企業は社内にインフラ(サーバーなど)を所有しなくてもよくなりました。
さらにクラウド上のサーバーは、ベンダーによる冗長化によりハードウエア的にサーバーがダウンする確率が大幅に下がり、サーバー管理に必要な人員の削減にも成功しています。


また、クラウドサービスには利用者が管理するべき範囲と、クラウドベンダーが負うべき責任範囲によっていくつかの種類が存在し、いずれもユーザーが使い方を自由に選べるようになっています。

 

 

クラウドサービスの種類と責任範囲

 

IaaS(Infrastructure as a Service)

IaaSは社内にあったサーバーやソフトウエアをクラウドサービス上の仮想環境サーバーに置き換えることで、社内にサーバーを置かずに、システムが構築できるようになるサービスです。
クラウドベンダーは、クラウドサービス上の仮想環境の基盤部分のみを担当し、クラウドサービス上の仮想環境サーバーの管理は、利用者自らが行います。

PaaS(Platform as a Service)

PaaSは前述のIaaSを一歩進めて、アプリケーションの構築、実行基盤までをクラウドベンダーの責任・担当範囲とするものです。
ここまでくるとクラウド利用者がクラウドサービス上の仮想環境サーバーを用意することがないため、サーバーレスと呼べそうですが、実際はPaaS上に構築された開発ツールや管理ツールの管理運用はクラウド利用者に委ねられています。

FaaS(Function as a Service)

FaaSは、2014年11月に行われたAWSによるAWS Lambdaの発表で始まったと言われています。その頃はFaaSなどという言葉はなく、後になってその使われ方からFaaSと呼ばれるようになりました。

 

アプリケーションが実際に動作するには(ミクロ的な視野でみると)ファンクション(関数、またはメソッド)と呼ばれる処理を大量に実行することでアプリケーションが動いています。このファンクションを動かすためにIaaS、PaaSなどがあったのですが、AWSは純粋にこのファンクションのみをクラウドサービスとして提供することを思いつきAWS Lambdaを作成しました。

 

Lambdaでは、作成したファンクションの実行環境はクラウドベンダーの責任・担当範囲になり、これによりシステム開発者はファンクションの作成だけを考えればよくなりました。ここで初めてクラウド利用者がサーバーという存在を意識することがなくなりました。

 

現在では主にこのFaaSを使ったシステムアーキテクチャーのことを「サーバーレスアーキテクチャー」と呼称するようになりました。

サーバーレスアーキテクチャーの特徴

前述のように、FaaSを使えばサーバーの存在を意識しなくてもよくなりますが、実際にサーバーがなくなったわけではありません。

 

仕組みとしては、ファンクションを利用する段階になると、そのファンクションを動かすための仮想サーバーが用意され、ファンクションの実行が完了すると仮想サーバーも消滅します。つまり処理実行時に限り、裏で仮想サーバーが毎回作られているのです。

 

この仮想サーバーは、必要なだけいくらでも用意ができるため、開発者はシステムを構築する際、利用者数(この場合はファンクションを同時に実行する数ともいえる)を考慮にいれなくてもよくなりました。

さらにAWS Lambdaはファンクションの実行時間に対して課金されるため、処理が行われていない時間は料金も発生しません。そのためインフラに対するコストの削減も可能となりました。

 

またサーバーレスアーキテクチャーのもうひとつの特徴として、ソリューション(システムの処理部品といったもの)が分散される傾向にあるため、変化に強く柔軟なシステムの構築が可能となります。

 

 

では欠点はないのか?といえば、何ごとにも裏表があるように欠点も存在します。「ファンクションを実行するときのみサーバーが存在する」ということは、システム構築の際にステートレスに設計しなければならないということです。ステートレスとは、簡単にいいますと現在の状態(データなど)を保持せず、ユーザーの入力内容だけで処理が完結する方式です。


サーバーレスアーキテクチャーを採用しない場合は、常に稼働しているサーバーに状態を保存することができるため、ステートフル(ステートレスの反義語)にでき、前回の入力状態を利用できるシステムを構築することができます。システム技術者にとってステートレスにシステムを作成するには、ステートフルなシステムでは考慮しなくてよいさまざまな事柄を解決する技術力が要求されます。


また、サーバーレスアーキテクチャーのソリューション分散は、それらの管理方法や各ソリューションの接続などといったサーバーレスアプローチ固有の問題を引き起こします。
その他にも、ベンダーロックイン(他のベンダーへの乗り換えが困難となること)や低レイテンシー(低遅延)を要求するシステムには向かないなどがあります。

サーバーレスアーキテクチャーの主な利点

  • 稼働率が増えれば自動的にスケールアウトする
  • 実行時間に対して課金される
  • 柔軟なシステムを構築できる

サーバーレスアーキテクチャーの主な欠点

  • システムをステートレスに構築するための技術力が必要
  • 分散されたソリューションの管理など、サーバーレスアプローチ固有の問題の発生
  • ベンダーロックイン
  • 低レイテンシー(低遅延)のシステムに不向き

 

サーバーレスアーキテクチャーを実際に採用してみて

最後に、実際にAWS Lambdaなどのサーバーレスアーキテクチャーを使って、システムを構築してみた感想を申し上げます。ステートレスにシステムを構築しなければならないことに加え、いろいろな制限があることが判明し、その制限の中でシステムを構築していくにはある程度の経験と試行錯誤が必要であると感じました。

 

ファンクションはステートレスかつ30秒以内でクライアント側へデータを返信しなくてはならないし、NoSQL データベースを使っての一覧表示処理が意外と難しい…など、技術者にとってはチャレンジングな内容ばかり。しかし、システムに興味がある人にとっては問題が散在するのは楽しい面もあるのではないかと想像します。


また各ソリューションが分散されていることによるメリットも感じられました。管理方法を間違えなければ、変更に対してはソリューションを組み換えることで柔軟な対応が可能となり、かつ分散されているため、不具合の影響範囲も小さく、修正も容易だと思います。


利用回数増やデータ容量増加といった心配すべき点も、クラウドベンダーによるシステムの自動スケールアップにまかせることで利用者が意識する必要もなく、さらには使った分のみ料金が請求されるので経費の削減にもつながりました。まだまだ多くの課題はあるものの、これからはサーバーレスアーキテクチャーがますます進化しシステム構築の主流になるだろうと予感しています。

 

最後までお読みいただきありがとうございました。

 

 

※記載されている情報は2020年4月時点のものです。


TOP