Akkaは、Scalaで書かれたライブラリで、アクターモデルを使って、耐障害性のある、非常にスケーラブルなアプリケーションをJavaとScalaで書くことを簡単にする。 Carl Hewitt氏によって1973年に始めて提案されたアクターモデルは、Erlangのような言語に採用されて成功した。電気通信業会では、非常に高可用性のある、非常にスケーラブルなシステムが普通である。
Scala言語の生みの親である Martin Odersky氏が言うには、
Akkaアクターは、欲しい物をたくさん備えている。非常にスケーラブル、高パフォーマンスで、分散システムで非常に良く機能する。
プロジェクト リードの Jonas Boner氏が今日、Akkaは、1.0マイルストーンに到達した、とアナウンスした。InfoQは、氏にプロジェクトについてより詳しく聞いた。
InfoQ: アクターモデルは、メッセージ（JMSタイプ）システムにおける基本的な"fire-and-forget"パターンと比べていくつもの眼を見張るような並行性を持っています。そのことがメッセージング ベースのシステムに対してどのような利点をもっているのでしょうか？
一つ目が並行性と分散コンピューティングの両方に対する統一された単一の抽象である、ということです。アクターは、ロケーション透過で、あなたが握っているアクター参照がイン・プロセスのアクターなのか他の物理的なマシン上のアクターを指しているのかはどうでもいいことです。このことは、開発者とランタイムの両方にとって、非常に強力です。ランタイムは、これを使って、クラスタを再バランシングしたり、参照の局所性を最適にするためにアクターを動かします。
二番目がアクターは、その動作を実行時に再定義できることです。HotSwapとしても知られています。これは、非常に強力で、ステートマシンあるいはステート依存の動作を実装する時にですね。後者の場合には、アクター自身がコンテキストを基にその動作をアップデートできます。また外部から（リモートからでも）アクターをアップデートできます。システムを停止することなく、バグを修正したり、コードをアップデートしたりできます。
InfoQ: エラーによってアクターが死にかかっている場合、メッセージはどうなりますか？「有害メッセージ」タイプの場合、どう処理するのですか？
2つのシナリオがあります。
- もしメッセージがアクターのメールボックスにあり、アクターが処理するために、メールをメールボックスからまだ取り出していない場合には、メッセージはメールボックスにそのままです。アクターとメールボックスは、切り離されているので、ランタイムは、クラッシュしたアクターを再スタートできます。死んだアクターを捨てて、新しいインスタンスを生成するわけです。メールボックスの方は、手付かずで残ります。 Cloudy Akkaの商用のアドオン モジュールは、また永続的なメールボックスのセットを追加して、ノード クラッシュを延命します。例えば、ファイル ベースのジャーナル化したトランザクションのログは、信頼性を増すために使うことができます。
- もしメッセージがアクターによって、メールボックスから取り出され、処理されていて、その後に、もしアクターがクラッシュしたら、メッセージは消え、再配送されません。これは設計方針です。これは、Erlangも含めて、ほとんどのアクターベースのシステムがそうなってます。しかし、Akka 1.1では、ローカルとリモートの両方のアクターにメッセージ配送の保証を追加します。
InfoQ:アクター モデルは、一般に電気通信分野で使われています。他の業界やプロジェクトでAkkaが使われいる例をあげてくれますか？
Akkaは、幾つもの様々な業界の数多くの会社で、デプロイされ、稼動しています。その業界には、金融と銀行、賭けとゲーム、電気通信、シミュレーション、テレビとメディア、eコマース、そしてソーシャル メディア サイトがあります。これら全ての業界での共通のテーマは、彼らが使うシステムは、トランザクションが頻繁で、高いスループット、短い待ち時間、キャリア級の可用性（5ナインもしくはそれ以上）を必要とします。例えば、トランザクション処理システム、信用サービスシステム、エンタープライズ統合、イベント駆動アーキテクチャ、 CQRS とイベント ソーシング、複雑なイベント ストリーム処理、グリッド コンピューティング、大規模データセットの分析、バッチ処理です。
InfoQ: Akkaは、JavaとScalaのAPIを提供しています。現在、あなたがたのユーザーは、ScalaとJavaのどちらを使って、開発してますか？
Akkaは、Scalaで書かれており、Scalaコミュニティから生まれました。なので自然と、Scalaユーザに多く採用されています。しかし、Akka 1.0のリリースで、確実にJavaAPIは、ScalaAPIと同程度にいいですし、フィーチャも完全に備わっています。もっと多くのJava開発者がAkkaを使っているのを知っています。AkkaのSpringモジュールとTyped Actorによって、Javaから使うのが非常に簡単になりました。
InfoQ: どうやってAkkaは、他のライブラリやフレームワークを統合するのですか？
Akkaは小さなコアと広範囲のアドオン モジュールでできており、Akka モジュール プロジェクトの一部として、他のライブラリやフレームワークとの統合を提供しています。幾つかの例がSpring, Google Guice, Apache Camel, AMQP そして多くの NOSQL データベース用のモジュールです。特に、 Akka Camelモジュールは、よく見る価値があります。なぜかというと、それを使うとAkkaがESBとなり、80以上の様々なエンドポイント ドライバを持ち、決まりきったアクター スタイルの方法で、あらゆる種類の他のシステムやリソースと、通信できます。
InfoQ:我々が昨年記事にしたリリース0.7と比べて、どんな新しいフィーチャが加わったのですか？
0.7は、ほぼ1年前のものです。それ以来、大きく改善されました。ほとんど完全に違う製品です。それ以来、何百というフィーチャや改善を加えました。重要なものを以下に列記します。
- シリアライズ可能、不変な、ネットワーク対応したActorRefは、アクター インスタンスから分離された
- アクターのシリアライズ:
- 深いシリアライズ（メイルボックスを含んで）、アクターをクラスタ内で動かすことができる
- ActorRef シリアライズ、参照を至る所に送ることができ、参照は、その元のアクター インスタンスを覚えていて、使う
- JTA対応のSTMトランザクション
- リモーティングに関する膨大な改善:
- RemoteClientとRemoteServerイベント サブスクリプションAPI
- 新しいずっと効率のよい、リッチなネットワーク プロトコル
- 開発者が将来に、(0MQ, AMQP や他の）違うトランスポートをプラグインできるようにする新API
- セッション限りのリモート アクター
- リモート アクター用のセキュアなクッキー ハンドシェイク
- 信頼できないクライアントに使うUntrustedモード
- 書き直されたスーパーバイザー管理、 ActorRefを使って、アクター インスタンスを本当に殺して、元のノードで置き換える
- 大幅に改善されたJava API。Scala APIと（ほとんど）同じくらい豊富になった
- 新しいアクター： UntypedActor とTypedActorによって、 JRuby と Groovyのような他の言語からインターフェースできるようになった
- パフォーマンスとスケーラビリティの改善、短くなった待ち時間とメモリの使用量を小さくした
氏は、また Camel と AMQPモジュールの改善についても述べた。アクター当たりのメモリ使用量が減ったので、同じハードでアクターを25％増やすことができるようになった。Akkaは、また JTA と OSGiをサポートし、NoSQLデータベースもサポートする。他にも非常に多くの調整と変更を行った。完全なリストは、リリースノートにある。
InfoQ:1.0リリース後の計画を教えてください。
1.0リリース後すぐに1.1をリリースする計画で、以下のフィーチャが入ります。
- ゼロ依存性Akkaアクター モジュール/JAR
- HTTPモジュールを改善して、WebSocket のサポートやその他
- ローカルとリモートのアクター（リピータを使う冪等）へのメッセージ送信に対する保証配信
- Akkaのデフォルト ディスパッチャのパフォーマンスとスケーラビリティが更に改善される
- STMが更に改善される。完全に再設計することで、パフォーマンスとスケーラビリティを改善し、もっとAPIが豊富になる
- より豊富な将来用のAPI
- Scalazライブラリのサポート
- そしてもっと
1.1の後には、分散STM、そしてクラスタリング、管理/モニタリング、プロビジョニング用に、商用の Cloudy Akkaアドオン スィートをリリースします。
Akkaは、オープンソースで、Apache 2 ライセンスの下で入手できる。ソースコード(コア, モジュール)は githubからダウンロードできる。