Akka.NET 1.1が最近リリースされ、新機能を提供しパフォーマンス改善を行った。InfoQは、Akka.StreamsとAkka.Clusterについてさらに学ぶために、Akka.NETのメンテナであるAaron Stannard氏に連絡を取った。Stannard氏は、AkkaのJVM実装と関連して、ロードマップがどのように計画されているかを説明している。
InfoQ: 今回のリリースのハイライトは何か?
Aaron Stannard氏: Akka.NET 1.1の主な目標は、ベータパッケージだったAkka.ClusterをRTM (正式版) パッケージとしてリリースすることです。これは、Akka.NETクラスタを本番環境で実行する際に起こりうる多数のさまざまなネットワークシナリオをカバーする、テストツールを備えています。
この取り組みがどれだけ大きなものだったかは、軽視できません。Akka.Clusterの最初のベータは、2014年8月にリリースされました。つまり、我々は、Akka.Clusterの開発と本番ユーザからのフィードバック収集に、約2年 (!) を費やしたのです。1.1の最後の追い込みは、可用性の高いワークロードで使えるように、クラスタリングシステムの信頼性と速度を改善することでした。銀行、医療機関、エネルギー生産者、車両管理企業、SaaS企業など、多数のユーザが既に本番環境でAkka.NETを使っています。Akka.Clusterは、これらのユーザがリリースして欲しいと考えている機能のトップでした。
1.1リリースのもう1つの大きなハイライトは、Akka.Streamsの最初のベータです。このモジュールは、相互接続と再利用が可能な高度なストリーム処理グラフとして一連の非同期操作を表現できるようにすることで、Akka.NETでリアクティブアプリケーションを構築する全く新しい方法を導入します。ドキュメントで、Akka.Streamsのグラフがどのようなものかを示すいくつかの図を見ることができます。
InfoQ: Akka.NET 1.1でのパフォーマンス改善は、どのようなものか?
Stannard氏: 最も注目に値するパフォーマンス改善は、次のものです。
- 全てのアクタのメモリフットプリントを34%削減。
- 各Akka.Remote (Akka.Clusterのネットワーク接続を支えるサブシステム) の接続あたりのスループットを500%向上。
- いくつかの箇所、特にロギングシステムで過剰なメモリ使用を除去。我々は一貫してAkka.NETのパフォーマンスを計測、テスト、改善し続けていますが、パフォーマンスは実は今回のリリースの目標ではありませんでした。Akka.NETのいくつかの内部機能を実装するためのさらに堅牢な方法を探した結果として、パフォーマンス改善が達成されました。
InfoQ: 今回のリリースで、あなたの好きな機能は何か?
Stannard氏: 奇妙なことですが、1.1リリースで私が好きなのは、私が全く関係していない機能であるAkka.Streamsです。
Akka.Streamsで本当に注目に値することは、Akka.Streamsによって、ユーザが、バックオフやスロットリングといった従来は難しかった並行プログラミングの問題を含む複雑なワークフローを、わずか数行のコードで簡潔に表現できることです。私は昨日、Akka.Streamsライブラリを使う事前の経験なしに、Akka.Streamsを使って、Akka.ClusterのWebCrawlerデモの重要な部分を数時間で書き直しました。そして、我々がWebCrawlerのコードベースで何年間も抱えていたスロットリングの問題を解決するために、組み込みのいくつかのバッファリングフローを使うことができました。初めてAkka.Streamsを使ったことによって、初めてアクタを使った時と同じ快感を得ました。それまでの方法とは違う完全に新しいプログラミングの方法を手に入れた、と実感したのです。
InfoQ: Akka.NETのロードマップはどうなっているか?
Stannard氏: Akka.NETの現在のロードマップは、多数の要素によって動かされています。Akkaの元のJVM実装との対称性は、大きな要素です。我々は、JVM実装の経験やそのユーザのバグ報告から恩恵を受けているので、JVM実装に忠実であることには多大な利点があります。
InfoQ: AkkaのJVM実装の足跡をたどることから、どのように恩恵を受けているか?
Stannard氏: 開発者は、本番環境での時間が、コードベースとその考えの健全性を評価するための最も有益なメトリックであることを、決して軽視してはなりません。数千台のサーバ上で24時間365日実行している数千のユーザを持つ、巨大なオープンソースプロジェクトは、プロプライエタリで特異な業務アプリケーションよりもはるかに長い本番環境での時間を得ることになります。これは、より早くより頻繁に、より多くのバグ、設計上の欠陥、生産性の改善点が見つかることを意味しています。これは、何年間も発見されなかったひどいコード爆弾に関するThe Daily WTFの事実上全ての記事が、広く使われているOSSではなく、使い捨てのプロプライエタリなコードから生じていることの説明に役立ちます。これが、我々がJVM実装の考えに忠実であろうと試みている理由です。JVM実装の設計は、JVM実装が本番環境で使われてきた長い時間からの情報に基づいています。
InfoQ: どのような点で、Akka.NETのロードマップはJVM向けのAkkaと異なっているか?
Stannard氏: Akka.NET自体は、長い間正式版をリリースしています。我々は、我々のユーザからの独自の生産性の改善、バグ、異なる考えを取り込んできています。また、.NETとJVMのエコシステムの間にはいくつかの大きな違いがあり、我々はそれをロードマップに組み込まなければなりません。例えば、.NET開発者はDI (依存性注入) フレームワークに夢中になっていますが、Scalaではそこまでではありません。これが、DIサポートをプラグインではなく標準機能にすることといった、我々が今後JVMから分岐する何かを設計する際の選択に影響を与えています。
また、JVMが持っているが我々が移植にそれほど興味を持っていない、いくつかのモジュールがあります。例えば、Apache Camel統合です。私は、Apache Camelを使っている.NETユーザをまだ見つけていません。また、何年間も取り組まれてきたモジュールの怪物である、Akka.HTTPもあります。Akka.HTTPは、我々が現在ユーザに提供している他のものに比べて比較的価値が低いので、近いうちにAkka.HTTPを移植する予定はありません。
一般に、我々のユーザはサーバサイドアプリケーションでAkka.NETを使う傾向があります。こういったユーザが本当に求めているものは、Akka.Cluster、Persistence、Streams、ShardingといったHA (高可用性) モジュールの全てが、Linux上の.NET Core上で動作することです。そこで、我々のロードマップを方向付ける次の大きな取り組みは、Akka.NETの.NET Coreサポートの初期段階になりそうです。
InfoQ: Akka.NETは主にC#だが、F# APIも持っている。実装の中でF#を使っているか?
Stannard氏: 個人的には私は大したF#ユーザではありませんが、それを変えようとしています。私は、FAKEを使ってF#で書かれた我々のビルドシステムを保守しています。私は、ここでF#の実践のほとんどをしています。私は、間もなくPetabridge社向けのいくつかの社内アプリケーションを構築しようとしており、それ向けにMicrosoft Azure Service Fabric上でSuaveとAkka.Clusterを使うことを検討しています。Akka.NETは、私にとって確かにFP (関数型プログラミング) への入門でした。パターンマッチングやストリームイテレーションといった、FPに欠かせない概念の多くは、アクタシステムによって本質的な部分です。F#は、.NET開発者のキャリアにおいて、Akka.NETからの自然な次の一歩です。
Akka.NETは、GitHubでホストされているオープンソースプロジェクトである。Akka.NETのWebサイトで、詳細なドキュメントを入手可能である。