Akkaらしいアプリケーションの設計
記事を読みすすめる上で、いったん伝統的な3層アーキテクチャ、つまりWeb API層、アプリケーション層、データベース層という構成は一度忘れてください。3層アーキテクチャでよくある「アプリケーション層で処理を行う際、常にデータベース読み出し・書き込みを意識する」作り方ではなく、アクターモデルの思想に沿った「アクター同士がメッセージを送り合い協調して動作する」アプリケーションの作成を学びます。
もちろんAkkaにとってWeb APIやデータベースは非常に重要です。現在Akkaはサーバーサイドやバックエンドと呼ばれる領域で多く利用され、それらの領域ではWeb APIやデータベースとの接続が必須と言っても過言ではありません。しかし、アクター同士の協調動作を実装する際には、Web APIやデータベースとの密結合を避け、それらを忘れた上で実装するのがよいでしょう。
アクターモデルを使うアプリケーション例
ここでアクターモデルが有効な例をいくつか紹介しましょう。最初に下図のようにアクターから外部HTTP APIを叩いて、失敗したらリトライする仕組みを考えます。
単純なリトライ機能を持つHTTP APIクライアントを使うだけなら、アクターを利用する必要はありません。さまざまなHTTPライブラリがアクターより単純な機構でリトライの仕組みを提供しています。しかしリトライ要件の複雑化が予見できるときは、アクターが有効な選択肢になります。複雑な要件の例としてはAPIの時間あたり利用制限（例: GitHub APIがこのような制限を持ちます）、タイムアウト処理、割り込みリクエスト、レスポンスが2回返ってくる、レスポンスを受け取った後に、APIの別エンドポイントを叩いてサーバー処理が完了したか確認する必要がある等々です。
こういった複雑な要件があれば、アクターを使ってモデリングすると、複雑な要件を複雑すぎない実装に落とし込めます。この際、アクターはメッセージの受信によってのみ動作を開始するので、APIからのレスポンスはアクターに送るメッセージに変換した上で送信する必要があります。
また、大量のリクエストをAPIに対して投げるときはAkkaのルーター機能を使って複数のアクターを並列に走らせ処理を高速化できます。
他のアクターモデルを使ったアプリケーションの例として、証券取引用アプリケーションの事後処理を考えましょう。証券取引の事後処理は複雑で、段階的に取引オブジェクトに情報を付加し、付加された情報をもとに正しい取引内容を保持しているかチェックが行われます。取引成立（約定）前に全てをチェックするのは難しく、致命的でない一部のチェックは事後に行います。
証券取引では取引口座の選択や決済日の設定、口座ごとの取引可能商品など、複雑で多岐にわたるルールで取引内容をチェックします。アクターの状態遷移で取引成立後の情報追加と複雑なチェックのフローをモデリングするのがよいでしょう。
さらに別のアプリケーション例として、与信機能を伴うオンライン取引アプリケーションもアクターで実装できます。多くのECサイトはクレジットカードによる支払いを受け付けますが、近年は後払いやツケ払いなどそれ以外の決済手段を合わせて提供するECサイトが増えています。単純にユーザーごとに利用上限額が決まっているクレジットカードと違い、一部の後払いやツケ払いなどの決済サービスでは、買い物一件一件に対して顧客の情報や購入商品の分類をもとに与信の可否をリアルタイムに判断します。
これらのサービスでは機械学習などのアルゴリズムで与信判断の精度を上げる場合もあります。決済事業者にとって後払い・ツケ払い取引は手数料収入の機会ですが、不払いによる損失は手数料収入に比べ金額が大きいので、与信判断の精度がサービスの収益力と継続性を左右します。与信判断のため社内・社外サービスに問い合わせる場合でも、問い合わせ結果をアクターの内部状態としてキャッシュできれば応答を高速化できます。
最後の例としてIoTアプリケーションを考えます。IoTアプリケーションでは、IoTデバイスからリアルタイムでイベントがサーバーに送信され、サーバー側でそれぞれのデバイスの状態を把握するといった構成がよくあります。
デバイスから送信するイベントの一つ一つをアプリケーション内でアクターへのメッセージとして変換し、そのメッセージ列を処理し、アクターの内部状態を変化させます。このときIoTデバイスとアプリケーションはネットワーク越しの接続になるので、メッセージの順番が前後する、メッセージが欠落するといった状況に対応できるようアクターを実装する必要があるでしょう。
