イントロダクション

モチベーション

今日わたしたちがインターネット上のサービスを利用する際、連続的なデータのダウンロードやアップロード、そしてピアツーピアのデータ通信を扱うことが増えてきています。データを全体としてではなく、連続した要素(ストリーム)として捉えることは非常に有用です。これはコンピュータが TCP などを経由してデータの送受信を行うやり方と一致しています。さらにデータセットがあまりにも巨大になり、それをひとかたまりのものとして処理できない場合、ストリームという考え方は欠かせなくなります。我々は計算処理や分析を巨大なクラスタ上に展開しそれを「ビッグデータ」と呼んでいます。ここでは複数の CPU を通して、データをシーケンシャルに、ストリームとして流しこむことがデータ処理の基本原則となっています。

アクターも同様にストリームを扱うものとして捉えることができます。何故ならアクターは知識(あるいはデータ)をある場所から別の場所へ移すために、一連のメッセージを送受信しているからです。しかしアクター間のストリーミングの安定化を実現するには、メッセージの送受信に加えて処理中のバッファやメールボックスがオーバーフローを起こさないよう対処しなければいけません。その実装は厄介で、エラーを引き起こしがちなものとなってしまいます。それに加えて、アクターのメッセージは消失することがあるため、受信側に穴あきのストリームが発生しないような再送信の仕組みが必要です。さらに、決められた型をもつ要素のストリームを扱う場合、アクターは現在のところ、正しい型でメッセージの送受信が行われているかを静的に保証する術を持っていないのです。ここではより厳密な型安全が求められます。

そういったわけで、我々はこれらの問題に対するソリューションを Akka Stream API として統合することにしました。Akka Stream API は、ストリーム処理に必要な機構を、直感的かつ安全なやり方で構築する仕組みを提供します。この仕組みのもとで、ストリーム処理を効率的に、そして限られたリソースのもとで実行することができるのです。もはや OutOfMemoryErrors の心配をする必要はありません。これを実現するために、ストリームはそのバッファリングを制御する必要があります。つまり消費者側が処理しきれないような場合に生産者側がスピードを落とすことができないといけないのです。この仕組みはバックプレッシャーと呼ばれ、Akka が設立メンバーである Reactive Streams イニシアチブの核ともなっています。そういった意味では、バックプレッシャーをどう伝播しそれに応答するかという困難な問題は、Akka Stream の設計の中にすでに組み込まれているため、課題は一つクリアされたとも言えるでしょう。また、Reactive Stream のインターフェースがインターオペラビリティをもった SPI である一方で、その実装の一つとして Akka Stream が使い勝手の良いユーザー API を提供しています。つまり Akka Stream は他の全ての Reactive Stream 実装とシームレスに相互運用が可能なのです。

ドキュメンテーションの読み方

ストリーミング処理はアクターモデルや Future 合成とは異なったパラダイムであり、その道具立てや技術に慣れるまでは、ある程度の学習を要することになると思われます。そのための手助けとしてドキュメンテーションを用意していますが、こを十二分に役立てるためには、以下の指針を参考にされると良いでしょう。

• ストリームがどのようなものであり、何ができるようになるかを大まかに把握したい方は、:ref:`stream-quickstart-scala`を読んでください。

• 順番に物事を理解してゆきたい方には、Design Principles behind Akka Streams を精読することをお勧めします。

• 実践から理解してゆきたい方には、Streams Cookbook に一通り目を通しておくのが良いかもしれません。

• 標準プロセシングステージの概要を把握したい場合は、Overview of built-in stages and their semantics の表を参照してください。

• その他のセクションは順番に読んでも、必要に応じて読んでいってもどちらでも構いません。各セクションでは特定のトピックについて掘り下げてゆきます。