勉強の記録
Bootcampの概要
Lesson1: Why use the actor model
なぜアクターモデルを使うのか？
- 手動でスレッドを管理しなくても良くなる。
- 全てをアクターとして考えるため、高いレベルでの抽象化が可能。
- RAMなどをサーバに追加した際、ソースコードを変えなくても自動で垂直スケーラビリティ(スケールアップ)がなされる。
- 複数の物理サーバにタスクを分散することができる(水平スケーラビリティ)
- 耐障害性やエラーハンドリングの恩恵を何もせずに受けることができる。
- ハンドリングできないエラーが発生した場合、アクターを再起動して自己再生システムが動く。
Lesson2: Types of applications for which actors are suitable
アクターモデルを適用するアプリケーションの種類
- トランザクションアプリケーション。金融系、統計、ブクマ、オンラインゲームなど。
- パッケージアプリケーション。利用可能なハードウェアリソースで分散処理が可能。
- REST, SOAPウェブサービスや、SIサービス。
- マルチプレイヤーゲーム。
- 運輸管理。乗り物と宅配業者の位置を管理するなど。
- 数的処理。BIやデータマイニングアプリにアクターは最適。
- IoT。センサからの外向きデータストリームをアクターで表現したり。
Lesson3: Use of Proto.Actor in different types of applications
どんなタイプのアプリケーションでProto.Actorで使用できるのか。
サーバサイド
- サーバレスバックエンド(WEB API)
- WEB APIからのリクエストをアクターモデルにリダイレクトする。
- Web App
- Windows Service
クライアントサイド
- コンソールアプリケーション
- WPFアプリケーション
- このタイプのアプリでは、GUIからのユーザリクエストをアクターシステムにリダイレクトする。これによって、リアクティブでパラレルなアプリを作ることができる。
Lesson4: The Reactive Manifesto
Proto.Actorはリアクティブプログラミングマニフェストの原則に従っている。
リアクティブプログラミングマニフェストの原則とは、おそらくこれのことだと思われる。
上記の原則に書かれているのは大体こんな感じのこと
- Stay Responsive(レスポンシブであれ)
- Accept Uncertainty(不確実性を許容せよ)
- Embrace Failure(障害を受け入れよ)
- Assert Autonomy(自立性を確立せよ)
- Tailor Consistency(一貫性をカスタマイズせよ)
- Decouple Time(時間を分離せよ)
- Decouple Space(空間を分離せよ)
- Handle Dynamics(ダイナミクスを制御せよ)
この原則に従って作られたシステムは、開発や変更が簡単で、障害の影響を受けにくく簡潔に障害対応が可能とのこと。
リアクティブアプリケーション
メリアムウェブスター辞典では、reactiveは「外部イベントに対応対応する準備ができている状態」と定義している。
これは、コンポーネントが常にアクティブであり、いつでもメッセージを受け取ることができる準備ができていることを意味している。
イベントに焦点を当てる(Focun on events)
なぜ重要なのか
- 非同期モデルを使用したアプリケーションは、疎結合を提供するのに優れている。
- 非同期通信を受け取る側はメッセージを受信するまで動作しない。->メッセージの受信者が同じスレッドで作業が可能。
重要な構成要素
- イベント駆動型アプリではデータが利用可能になった時点で、クライアントにデータをプッシュすることで、リソースの無駄使いを減らしている。
スケーラビリティ(Scalability)
なぜ重要なのか
- メリアムウェブスター時点によると、スケーラブルとは「容易に拡張や近代化ができること」と定義されている。
- 需要に応じたシステムの伸縮をアプリを書き換えることなく実現できるので、コストの削減になる。
- また、過剰、あるいは少なすぎるハードウェアリソースを持つことのリスク管理を行うことも可能。
重要な構成要素
- 非同期メッセージ受け渡しに基づいたイベント指向システムはスケーラビリティの基礎。
- 非同期メッセージ受け渡し(asynchronous message passing)は、送信者と受信者の間に待ち時間が発生しない通信。簡単にいうと、家にいるかわからないが荷物を勝手に送りまくるような状態。
- 新しくノードを追加するとシステムのスループットが向上するが、実装面で考えるとコア数を増やすこととノードを増やすことに違いはないはず。
- そのため、アプリケーショントポロジーは、システム負荷を監視する構成やランタイムアルゴリズムをの問題となる(おそらく、コア数やノード数を考えるのではないと言いたいのだと思われる)
耐障害性(Fault tolerance)
なぜ重要なのか
- 障害はビジネスをぶち壊す要因の一つ。
- 障害はキャッシュフローに穴をぶち開ける。
- 評判が悪くなったり、クライアントからの不満がたまることで、ビジネスをぶち壊す。
- リアクティブアプリでは耐障害性を最優先事項として扱うため、システムが自力で回復したり修正するようになる。
- 従来の方法だと、障害に対して適切なレベルで対処できない仕組みなので、自力での回復や修正が困難。
重要な構成要素
- 障害が他の正常な部分に影響しないように、システムを分割することで問題を個別に解決する。
- これによってシステムは自身で障害部分を治療し、自動で復旧することができる。
- イベント駆動型であり、位置透過性があることがとても強力。
応答性(Responsiveness)
なぜ重要なのか
- メリアムウェブスター辞典によると、応答性とは「素早く、あるいは適切に応答すること」と定義されている。
- レスポンシブアプリはGoogle Docsのような共有アクセスを提供するリアルタイムアプリケーション。
- アプリケーションは障害発生時も時間通りにイベントに対して応答する必要がある。
- 例えば、オンラインショッピングストアにおいては、応答が遅いと売れたはずの商品が売れなくなってしまう。
重要な構成要素
- 複数のユーザが同じモデルで同時作業を行う場合、変更内容はリアクティブに同期され、モデルをロックする必要がなくなる。
- モデルをロックするというのは、他のユーザの干渉を防ぐために一時的にデータを編集不可能にすること。
- 負荷プロファイルに依存せずにレイテンシを維持する戦略はいくつかある。例えば、キューを流量によって制限したり、キューの長さをリトルの法則に従って決定するなど。
- リトルの法則については、こちらの記事などがわかりやすいです:参考1, 参考2
Lesson5:Key features of the Proto.Actor
Proto.Actorはこんな機能を提供している。
- 簡単なマルチスレッディング(並行性)と非同期性
- 簡単な分散処理
- ハイパフォーマンス
- 耐障害性
- 一つのアプリで複数の言語の使用
並行性と非同期性
- Proto.Actorはアクターやメッセージなど高い抽象度で並列処理を行うため、スレッドや共有しロースのブロックなどの低レベル処理を行う必要がない。
- 例：アクターが別のアクターからの応答を待つ間に、待っているアクターがブロックされることがない。
分散処理
- Proto.Actorにおいて、個々のアクターインスタンスが同じマシン上に合っても、別のマシン上にあっても関係ない(位置透過性)。
ハイパフォーマンス
- メモリ1GBあたり約250万インスタンスのアクターを想定している。
- ロードバランシングやアクターの複数の子インスタンスへのメッセージルーティング機能もある。
耐障害性
- Proto.Actorはスーパーバイザー層を用いた自己修復システムを持っている。
- 障害が発生した場合、該当箇所を切り離して自己修復する方法をシステムに提示することが可能。
一つのアプリで複数の言語の使用
- gRPCのおかげで、異なる言語で書かれたアクターはメッセージのやり取りを行うことができる。
- 例：クライアントパートをASP.NET Coreで書き、サーバをPythonで書く。