メリットが保証されるわけではない

サーバレスに飛び付く前にやるべきたった1つの作業

サーバレスコンピューティングは誤解されやすい概念であり、全ての企業がメリットを享受できるわけではない。サーバレスが役立つのか否か。導入する前に絶対やっておくべきこととは？

公開 2018年06月19日 08時00分

著者

Stuart Burns

[Computer Weekly]

印刷する連載新着通知を受け取る

　「サーバレスコンピューティング」という言葉が最近不用意に使われている。クラウドリソースを活用する超効率的な方法とみられているが、他にも多くの意味合いがある。

Computer Weekly日本語版　6月6日号無料ダウンロード

本記事は、プレミアムコンテンツ「 Computer Weekly日本語版　6月6日号 」（PDF）掲載記事の抄訳版です。本記事の全文は、同プレミアムコンテンツで読むことができます。

Computer Weekly日本語版　6月6日号：Google Pixelbook長期試用レビュー

なお、同コンテンツのEPUB版およびKindle（MOBI）版も提供しています。

　サーバレスという考え方は、実際には10年ほど前から存在する。このプロセスの先駆けになった企業が忘れ去られるほど前のことだ。残念ながら、当時は優れた成果を残せなかったため、その後廃れてしまった。とはいえ、全ての事柄がそうであるように、古いものは再び新しく生まれ変わる。

　それでも、サーバレスに対する最適な考え方はある。仮想インフラや物理インフラにとらわれずに、サービスを継続的に手に入れる最新の手段であるという考え方だ。だが、インフラが必要なことは間違いない。

　サーバレスは「コードであり、コードにすぎない」という考え方もある。サーバレスでは、基盤となるホストとの依存関係やパッチの適用が不要になるためだ。

　つまり、開発者はコードが実行されるホストのメンテナンスやセキュリティ、パッチの適用を気に掛ける必要はない。ただし、このホストを管理し、パッチを適用するシステム管理者は依然存在するだろう。

サーバレスの定義

　「サーバレス」コンピューティングという言葉が使われる場合、2つの意味のいずれかを示している。1つは、コンテナ、マイクロサービスなどの抽象概念を（間違って）示している場合。もう1つは、（より正確に）「Function as a Service」（FaaS）を指す場合だ。

　サーバレスは、主に短時間しか行われない相互作用を対象に設計されている。事実、多くのサーバレスプロバイダーは、5分を超えて続行するスレッドを終了する。そのため、サーバレスは明らかに従来のWebサーバにはあまり向いていない。

　サーバレスでは、アプリケーションが構成コンポーネントに分解され、全てがコードやAPI呼び出しに細分化される。例えば、独自のアプリケーション認証サーバを構築してユーザーの認証を行うのではなく、サードパーティープロバイダーの機能を利用する。

　他のコンポーネントについても同じことがいえる。アプリケーションとサードパーティーの認証システム間のAPI呼び出しとメッセージングの使用に基づいて、同じ機能を提供することになる。各認証インスタンスが独立して実行され、認証プロセスの間だけ実行されて終了する。通常、数秒未満しか存続しない。

　一見、非常に高価な方法のように思えるかもしれない。だが、各API呼び出しのコストがおよそ1000分の1セントだと考えると、非常に安価になる。

　恐らくもっと重要なのは、水平方向の柔軟なスケーリングが極めて簡単になることだ。当たり前のことを承知で言えば、永続データをどこかに保存する必要があるためだ。

コストの削減

　インフラのコストを削減すれば、Webスケールアプリケーションを提供する全体コストも削減される。明らかに何らかの課金メカニズムは必要だ。サーバレスでは、そのメカニズムがアプリケーションの呼び出しごとに変わる。実際には、モデルを利用した分だけ支払うことになる。

　課金には、利用するハードウェアのコストも含まれる。そのため、「サーバレス」という言葉が少々誤解を招くことになる。ただし、待機しているだけの余分なハードウェアを抱えるよりもはるかに安価で済む。通常は、ハードウェアを使用してもしなくてもその料金を支払わなければならない。サーバレスアーキテクチャではその点が異なる。

　このアプローチを説明する最善の方法は、重要なビジネスロジックを社内に保持して第三者の目に触れないようにしつつ、「日常をアウトソーシングする」ことだ。

　コストの問題を簡単に説明する。「Amazon Web Services」（AWS）の仮想マシン（VM）を使用すると、VMごとに毎月数十ドルかかる。同じことをサーバレスで（妥当な使い方で）行うと、料金を約3分の2にできる。有用性が大きく異なるため、全てに適合する明確な良しあしはない。

　これはメリットだ。だが、全てがAPI呼び出しで行われるため、プログラムと呼び出しが全て正しいことを保証することに大きく依存するのがデメリットになる。