Web APIとアクターの接続
アクターはメッセージを受け取ってから処理を開始するので、基本的に自分から処理を開始しません。処理の起点は多くの場合Web APIなどアクターの外部からの入力か、Akkaのスケジューラーが時間経過によって発生させるメッセージです。
Web APIはクライアントからHTTPリクエストを受け取るので、それをメッセージ型に変換してアクターに送ります。アクターからメッセージが戻ってきたら、今度はそれをHTTPレスポンスに変換してクライアントに返します。
Web API自体はアクターではないので、そのままではアクターからのメッセージを受け取ることができません。そこでAskパターンを用いると便利です。先程紹介した本記事のソースコードを載せたGitHubレポジトリでも、Mainクラス内でAskパターンを用いています。
さらなる要件の追加と設計
ここまでアクターモデルによる設計をソースコードに落とし込む流れを説明しました。現実のチケット販売アプリケーションはもっと複雑ですし、また時間の経過とともに追加要件が出てくることでしょう。要件が複雑になったとしても、状態遷移図、シーケンス図、樹形図を始めとした設計をしっかり行うことによって対応しやすくなります。
例として、チケットのキャンセル処理を考えましょう。チケット在庫アクターやチケット購入者アクターが受け取るメッセージの型として、キャンセルを示すものが加わり、売り切れ状態でキャンセルされると販売中状態に復帰するなど状態遷移図にも影響が出ます。
あるいは別の要件としてチケットを組み合わせて買うことを可能にする場合、不正な組み合わせの購入リクエストを拒否する必要があるかもしれません。その場合はチケット在庫管理アクターではなく、親子関係の中でひとつ上のレベルのイベントアクターがチケット購入リクエストの処理を担うべきでしょう。これは設計上非常に大きな変更であり、ソースコードを書く前にしっかりと設計を行うことで、こういった変更の影響度を早い段階で検討できます。
まとめ
アクターモデルが有効なアプリケーションの例としてオンラインチケット販売アプリケーションを紹介しました。適切な設計を行えばソースコードに落とし込みやすいAkkaは、言い換えれば正しい設計を促してくれます。シーケンス図、状態遷移図、樹形図などを使って、アクターモデルらしい設計を行いましょう。
歴史的にWeb APIとデータベースにはしっかりとした設計指針がありました。Web APIではRESTが広く知られており、近年ではgRPCやGraphQLなどのツールが普及したことで、よりAPIを設計しやすい環境が整ってきました。データベースも、最も広く用いられるリレーショナルデータベースにおいては、正規化やリレーショナル代数にもとづく理論があります。しかし、Web API層とデータベース層をつなぐアプリケーション層においては、Web API層やデータベース層の都合に引っ張られる形で設計されるケースが多かったのではないでしょうか？ アクターモデルが有効に使える領域では、それがしっかりとした設計指針となります。Web API層とデータベース層、アプリケーション層それぞれで適切な設計を行えば、長期にわたって保守しやすく、実装に移ったときの手戻りが少ないアプリケーションができるでしょう。
次回の記事ではイベント・ソーシングとCQRSパターンを紹介します。アクターモデルとデータベースを接続する際にはメリットが多数あるパターンで、これらのサポートはAkkaの特徴的な機能でもあるので、記事一本を使ってしっかり紹介いたします。
