Akkaの主要な使い方
この連載ではAkkaのアクター機能を中心に紹介してきました。Akkaはアクターを中心としつつも、それだけではなくさまざまなモジュールで構成されたツールキットです。Akkaを構成するモジュールを用途に応じて組み合わせることで、多様なアプリケーションに対応できますが、よく使われる代表的なモジュールの選択例として以下の3つがあります。
-
アクターを中心としたモジュール群
- イベント・ソーシング用モジュール（akka-persistence）
- CQRS用モジュール（akka-persistence-query）
- クラスターとクラスター・シャーディング用モジュール
- HTTPサーバー用モジュール（akka-http）
- ストリーミング処理用モジュール （akka-streamsやAlpakka）
より大規模なアプリケーションでは、1、2、3の全てを組み合わせる場合もあるでしょう。この連載では2、3は取り上げませんでしたが、1のアクターを中心としたモジュール群について紹介してきましたので、今回の記事では1についての使い所と、アンチパターンを紹介します。
Akkaはどんなアプリケーションに対して有効なのか
Akkaの使い所を知るためには、Akkaの背景にある思想を理解するのが有効です。そのために、やや抽象度の高い概念になるのですが、リアクティブ宣言を紹介しましょう。リアクティブ宣言は、2014年にAkka OSSプロジェクトの主要コミッターの他に、LMAX DisruptorやAeronの開発で有名なマーティン・トンプソン氏などが共同で発表したものです。
宣言が発表された当時の時代背景として、それまでは数十台のマシンで構成され、レスポンスが数秒以内で返ってくるアプリケーションが普通でした。そこから数年程度の短い期間で、クラウドやモバイルが当たり前になり、システムを構成するマシンが数千台規模に、レスポンス要求が数ミリ秒で、99.9...％の信頼性が求められるアプリケーションが珍しくなくなってきていました。
リアクティブ宣言は、そういった高い要求水準を満たす大規模アプリケーションが備えるべき特性をまとめたもので、以下の4つを挙げています。
- 即応性 （Responsive）
- 耐障害性 （Resilient）
- 弾力性 （Elastic）
- メッセージ駆動 （Message Driven）
アクターは状態を内包しているので即応性に秀でています。また、第2回で紹介したとおり、Akkaはベンチマークにおいて、1台のマシンで1秒に5000万メッセージを処理するなど、パフォーマンスが高いです。さらに、アクターの親子関係による監視とイベント・ソーシングによって高い耐障害性をもち、クラスター機能によって数千台規模のシステムも構成可能な弾力性を持っています。そしてメッセージ駆動はアクターにおける中核的な設計指針です。
以上を踏まえると、Akkaがどんなアプリケーションに対して有効なのか見えてきます。まず最初に自分たちが作ろうとしているアプリケーションに、リアクティブ宣言で求められている即応性、耐障害性、弾力性が求められるのかを確認しましょう。ユーザーが数ミリ秒以内のリアルタイムな応答を要求し、マシンがダウン、あるいはデータセンターに障害が発生してもシステム全体は稼働し続け、需要の増加や負荷のピークに合わせてクラスターの規模を拡大する必要があるシステムなら、Akkaは有効な選択肢となり得ます。
ただ、これだけでは大まかな指針にしかならないので、Akkaを用いるべきかそうでないかという、より細かい判断基準は、次項のアンチパターンとともに紹介していきましょう。
