BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース サーバレスであっても"状態"は必要だ

サーバレスであっても"状態"は必要だ

ブックマーク

原文(投稿日:2019/04/18)へのリンク

今日のエンタープライズアーキテクチャは、サーバレスアーキテクチャへと大きく移行している。Jonas Bonér氏はブログ記事で、サーバレスへの動きを強く支持しながらも、プログラミングモデルではステートレス関数のみを重視すべきではない、サポートするユースケースの幅が狭くなるからだ、と論じている。

Akkaの開発者でLightbendの創設者でもあるBonér氏は、自身の経験を元に、ファンクション・アズ・ア・サービス(FaaS)がサーバレスと混同されやすい点を述べた上で、サーバレスがユーザエクスペリエンス(UX)を扱うものであるのに対して、FaaSはその多くの実装の第1歩に過ぎない、と指摘する。

入力と出力を明確に定義することにより、関数をより大きな関数に組み上げることが可能になる。Bonér氏はこれをLegoに例える — 関数はLegoブロックであって、より大きなものを組み立てることができる、ということだ。ただし氏は、関数はデータ処理に優れてはいるが、その意図したスコープを越えて使用すると、厳しい制約や制限を受けることになる、とも指摘する。

その制限のひとつが、FaaS関数は短命かつステートレスでなければならない、というものだ。パフォーマンスとレイテンシの立場で言うならば、処理コンテキストが失われることは、毎回バックエンドストレージから状態の読み出しと保存をしなければならないため、コストがかかりすぎる。Bonér氏の考えるもうひとつの制限は、直接的なアドレス指定が不可能であることだ。通信はすべてパブリッシュ/サブスクライブを通じなければならず、すべてのデータが比較的低速かつ高価なストレージメカニズムを通る必要がある。イベント駆動のユースケースではこれでうまくいくかも知れないが、汎用的な分散コンピューティング問題においては、レイテンシが高過ぎる。

関数は素晴らしいツールだが、もしもサーバレスが、データ中心のリアルタイムアプリケーション構築の可能性を保ちながら、Ops Lessな世界の期待とビジョンを満たすためのものであるならば、分散システムにおける最も困難な問題 — 状態管理に対処できなければならない、とBonér氏は指摘する。これは同時に、サーバレスにとって最も興味深い機会だと、氏が考えるものでもある。サーバレスのムーブメントはインフラストラクチャの自動化に偏り過ぎており、状態の扱いを無視している、というのが氏の見解だ。状態はアプリケーションレイヤの外部に移動されるが、アプリケーションがよりデータ中心でデータ駆動になれば、これはソリューションとして無効なものになる。ほぼリアルタイムでデータを継続的に処理し、データストリームからナレッジを抽出しなければならない多くのアプリケーションにとって、要求毎にデータストレージを取得するというラウンドトリップを持つことは、あまりにも高くつくのだ。これは"Data At Rest"から"Data In Motion"への移行であり、分散システム処理とイベント駆動マイクロサービスを基盤とするアーキテクチャへと、多くの企業を移行させる理由になっている。

Bonér氏にとって、サーバレスのバージョン1.0とはステートレス関数であった。2.0はステートに注目して、サーバレスのアドバンテージによるメリットと、分散型の汎用目的アプリケーションの構築を両立するものでなければならない。エンドツーエンドの正確性、一貫性、および安全性の持つ意味は、サービスによって異なり、ユースケースに依存する。従って、安定したシステムこそがアプリケーションの責務であり、次世代のサーバーレス実装は最も重要な問題 — クラウド内において、データをどのようにして大規模かつ高い信頼性で管理するか、という点に対処する必要があるのだ。

Serverless NYC 2018で行ったプレゼンテーションで、ConfluentGwen Shapira氏は、ステートレスインフラストラクチャにおいてデータ処理アーキテクチャを構築する場合の課題について論じた。我々が行いたいことの大半は状態を必要としている、と氏は言う。従って状態管理は、サーバレスの世界でも重要なのだ。関数は拡張性が高いので、ストレージを使用する関数に合わせて、データベースは極めて高速であると同時に、同じような従量制課金モデルであることが必要となる。しかしながら、氏の調べた選択肢には、期待するような自動スケール機能を備えたデータベースも、従量制モデルを採用したものも存在しない。氏はまた、FaaSモデルが、ストリーム処理モデルとイベント駆動設計の両方に類似点を持つ点に注目している。すなわち、一方のパターンを他方に適用することが可能であり、我々の持つ経験の多くが引き続き価値を持つのだ。行動を表現する関数にのみ注目するのではなく、アプリケーションの本当のニーズを考慮して、より現実世界を反映すると考えられるイベントを使用するべきだ、と氏は主張する。

SymphoniaMike Roberts氏は、サーバレスアーキテクチャを論じた以前のブログ記事で、FaaS関数はローカル状態に関して制限されている、と記している。状態は存在するが、複数の呼び出し、あるいは同じ関数の異なる呼び出しに対して、持続するという保証はない。このため、ステートレスであると説明されることが多いが、永続化の必要な状態は関数外でなければならない、と言った方がより正確なのだ。高速なNoSQLデータベースやオブジェクト、あるいはある種のファイルストアなどの選択肢はあるが、これらはいずれも、メモリ内やサーバ上のローカルな永続化よりもはるかに遅い、と氏は指摘する。これがアプリケーションアーキテクチャに大きく影響する可能性がある。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

BT