Reactive System Meetup / Akka Serverlessについて

この記事について

2021/10/23のReactive System Meetupにて、@jeremypollockさんによるAkka ServerlessというLightbend社のPaaS製品に関する発表が行われました。その名の通り、所謂サーバーレスソリューションの1つとなりますが、リアクティブシステムやマイクロサービスアーキテクチャといったものに対する前提知識がある程度ないと、AWS Lambdaなどとの違いがよくわからなかったりするかもしれないと思ったので、その辺りを踏まえて、発表内容の紹介や所感を書こうと思います。

書いてある内容については発表を受けての期待によるものが多く、悪しからず。(「本当かよ!」と思ったところの検証は各自おねがいします。)

Akka Serverlessとはどのような製品か?

一言でいうと、ステートフルなアプリケーションを作るためのプラットフォームです。また、アプリケーションのアーキテクチャとしてCQRSやイベントソーシングといったものを採用するための機能をプラットフォームが備えています。

ステートフル vs ステートレス

Akka Serverlessの重要なポイントはステートフルなアーキテクチャでアプリケーションを構築する、というところです。これと正反対のアーキテクチャはステートレスです。この違いを抑えることが製品がやろうとしていることを理解する近道だと思います。

アプリケーションがビジネスロジックを実行して、業務の状態(注文ステータスや、発送ステータスといったもの)をRDBMSに保存する、といった一般的なWEBアプリケーションのほとんどはステートレスなアーキテクチャです。アプリケーションとしては状態という概念があるので、これは直観に反するかもしれませんが、ここではアプリケーションが稼働しているコンピューターのメモリに状態を保持するかどうかを問題にします。当然、ステートレスなアプリケーションでも、データベースからデータを取得して何らかのビジネスロジックを実行するときにはメモリにデータを展開するのですが、揮発的です。多くの場合、1つのビジネスロジックを実行した後はメモリから状態は破棄されます。

ステートレスなアーキテクチャでは、アプリケーションとして必要な状態の一貫性を(ほとんどの場合)データベースのトランザクション機能を用いて実現します。データベースのトランザクション機能はアプリケーションの共有リソースをロックするため、ロックが長時間に渡る場合は、アプリケーションのスケーラビリティを低下させます。

一方でステートフルなアプリケーションでは、アプリケーションとして必要な状態の一貫性の管理を全てアプリケーションのメモリ上で行います。メモリ上のデータは揮発的(アプリケーションサーバがクラッシュしたら消滅する)ですが、イベントソーシングというアーキテクチャでは、アプリケーションの状態とは別にイベントをログとして記録し、クラッシュ時(もしくは非活性化された後で再度活性化されたとき)はイベントログから最新の状態を回復します。

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャでは、システムとして正しい振る舞いを行うために、各マイクロサービスが持つデータの一貫性を実現する手段が必要です。ここで、データベーストランザクションを用いると、マイクロサービスアーキテクチャの利点のを多くを失ってしまうため、結果整合性を持つアーキテクチャを採用するモチベーションが生まれます。

マイクロサービスがステートフルなアーキテクチャで構成されていると、Saga Patternなどを使ってデータベースのトランザクション機能を用いずに結果整合性を持つシステムを構築できます。^[1]

AWS LambdaやGoogle Cloud FunctionsなどのFaaSとの違い

AWS LambdaなどのFaaS(Function as Service)は呼び出す関数に状態を保持し続けることはできないため、複数の関数を呼び出すことによって計算処理をスケールすることはできても、状態の一貫性が必要であれば外部のデータベースのトランザクション機能を使わざるを得ません。

したがって、本質的にステートフルなアプリケーション^[2]をFaaSだけを使って構築しようとする場合、この部分がボトルネックになります。実行環境の制約も多いため、実際のところ、FaaSは限定されたビジネスロジックの一部やワークフローの制御などに用いられることが殆どであろうと思います。

一方で、Akka Serverlessはステートフルなコンポーネントをデプロイできるので、業務アプリケーションのステートフルなビジネスロジック全体をスケーラビリティや一貫性を失わずに実装できる、ということが期待できそうです。^[3]

Akka Serverlessに期待できそうなこと

• アプリケーションプラットフォームの保守性向上
  自前のアプリケーションサーバでマイクロサービスを運用する場合、k8sのクラスタの整備やマイクロサービスのアプリケーション基盤のコードの保守など、業務機能以外にもかなりのエンジニアリングリソースを投入する必要があります。このようなところの多くがPaaSの機能として提供されていれば、プラットフォームの維持に必要な人的リソースを抑えられるかもしれません。
• 業務機能の生産性向上
  アプリケーション基盤の多くをPaaSが提供してくれるのなら、アプリケーションエンジニアのリソースをアプリケーション基盤(Akkaのクラスタリングや、メッセージの配信保障の仕組みなど)ではなく業務機能に集中できるようになります。
• アーキテクチャの再利用性
  ここまでに言及していませんでしたが、Akka ServerlessではJavaやScalaの他にPythonやGo、Rustといった言語を使って開発することもできます。
  事業を拡大するために新しいサービスを作るときに、既存のアーキテクチャを再利用するために特定の言語に精通したエンジニアを確保する必要があるとなると、それなりの制約になります。どの言語を使用しても基本的なフレームワークやアーキテクチャはそれほど変わらないのであれば^[4]、ここは言語ではなくDDDやCQRS / ESといったものに通じている^[5]、ということが要件になるので、採れる戦略の幅が広がります。

脚注

1. Saga Pattern自体はマイクロサービス内でRDBを使っていても実現できますが、長時間のロックをしないような設計が必要になると思います。

2. 多くのWEBアプリケーションは本質的にステートフルなアプリケーションをステートレスなアプリケーションにエンコードしている、ということ

3. ここで問題にしているのはあくまでビジネスロジックで、通知機能や3rd Partyとの連携など、システムとして必要な機能の中であまり向かない分野はあるかもしれません。

4. これは本当にそうかはよくわからないけど。

5. 発表では、必ずESしなければならないわけではないと仰っていましたが、これは個人的には必須要件だと思います。