More Related Content Similar to リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi (20) リアクティブ・アーキテクチャ ~大規模サービスにおける必要性と課題〜 #devsumi3. 公開してる OSS
• finagle-kafka (https://github.com/okapies/
finagle-kafka)
• sircuit (https://github.com/okapies/sircuit)
• rx-process (https://github.com/okapies/rx-
process)
4. 書き物
• 翻訳:
• リアクティブ宣言 v2.0
• Effective Scala 日本語版
• 命令型のコールバック、関数型のプロミス
• ブログ記事 (http://okapies.hateblo.jp/):
• 非同期ストリーム処理の標準化を目指す "Reactive Streams" とは
• 関数型プログラマのための Rx 入門
• マイクロサービスが Scala を選ぶ3つの理由
23. Reactive Manifesto
• Reactive Systems への支持を呼びかける文書
• 社(Scala/Akka 開発元)が主導
• 他に Dave Farley (”継続的デリバリー”の著者)
や Martin Thompson (元 LMAX CTO) など
• アクターモデル、特に Erlang/OTP や Akka のプ
ラクティスを念頭に置いている
賛同者数
13,000 人超え
34. MSA ⊂ リアクティブシステム
• マイクロサービスは、リアクティブシステムの
実例の一つと考えることができる
• マイクロサービスは、リアクティブシステムの
4つの性質を備えているとより良い、と言え
る
40. 補足: 位置透過性
• 全ては分散コンピューティングである
• メッセージパッシングにおいて、単体ノード(マル
チコア)と複数ノードにコンセプトの違いはない
• コンポーネントが任意の場所に配備できるなら、
ローカル通信は最適化に過ぎない
• メッセージパッシングは RPC ではない
• ネットワーク関連の障害を明示的に扱う
45. 補足: Let it crash
• 故障したコンポーネントはその場でクラッシュさせ
て、監督者 (Supervisor) に回復処理を任せる
• 「予期しない障害は必ず起きるし、人為的には防
げない」という実世界のシステムに対する観察
• Erlang 発祥の概念で、極めて高い信頼性が求められ
るシステム(電話交換機など)で可用性を確保する
のが目的
47. 弾力性 (elasticity)
• 弾力性 = Scale Out + Scale In
• シャーディングやレプリケーションによって
コンポーネント間で入力を分散し、スケーラ
ビリティを確保(c.f. 位置透過性)
• 同期の競合やボトルネックの原因になるので、
メモリの共有はしない(メッセージ駆動)
48. マイクロサービスとの比較
• マイクロサービス ⊂ リアクティブコンポーネント
• 強固なモジュール境界: 同期呼出ではなく非同期呼出に
• 独立した配備: レジリエントなシステムは〈障害を考慮し
た設計〉と〈進化的設計〉を満たす
• 技術的多様性: 非同期処理やメッセージ駆動ミドルウェア
を重視(HTTP 等でも実現は可能)
• メッセージ送信はバッチ化(RPC 粒度の課題を解決)
50. 国内事例
• LINE のメッセージング基盤は、Akka Actor を
活用したリアクティブな設計になっている
• 「Akka ActorとAMQPでLINEのメッセージ
ングパイプラインをリプレースした話」
• TIS が Akka を使ったデモを GitHub で公開し
ている
https://github.com/tech-sketch/reactive-solar-farm-monitor/
51. Reactive Solar Farm Monitor デモ
https://github.com/tech-sketch/reactive-solar-farm-monitor/blob/master/README.ja.md
52. Reactive Solar Farm Monitor デモ
http://www.slideshare.net/yugolf/typesafe-reactive-platformreactive-system/35
54. データフローの決壊
• Publisher は Subscriber へメッセージを送る
Publisher Subscriber
…
3 msgs/sec 3 msgs/sec
メッセージバッファ
処理能力
送信能力
=
61. 経緯
• Reactive Manifesto の発表 (2013年9月)
• Typesafe の主導で、非同期ストリーム技術を
開発するベンダー各社の間で、フロー制御の技
術課題の解決策を話し合うコミュニティが発足
• GitHub に reactive-streams グループを作成。
正式に共同で仕様策定を始める (2014年初頭)
63. 主な参加者
• Doug Lea
• JSR 166 (java.util.concurrent)
の Specification Lead
• 「Java 並行処理プログラミング」
の著者の一人
• JDK での標準化は氏の主導で進められている
http://www.amazon.co.jp/dp/4797337206/
65. SPI のインタフェース
public interface Publisher<T> {
public void subscribe(Subscriber<? super T> s);
}
public interface Subscriber<T> {
public void onSubscribe(Subscription s);
public void onNext(T t);
public void onError(Throwable t);
public void onComplete();
}
public interface Subscription {
public void request(long n);
public void cancel();
}
すべて戻り値なし=非同期
語彙は RxJava がベース
67. 準拠実装
• Akka Streams (Typesafe)
• Ratpack
• Reactor (Spring)
• RxJava (Netflix)
• Vert.x 3.0 (Red Hat)
68. DB アクセスライブラリの準拠実装
• Slick 3.0 a.k.a “Reactive Slick” (JDBC)
• ReactiveMongo
• Reactive Rabbit (AMQP)
• Reactive Kafka
• etc…
78. Finagle
Twitter の Finagle は、(Tumblr が) Scala を採用した抗し難い要
因だ。Finagle は、分散トレース、サービスディスカバリやサー
ビス登録といった分散の課題のほとんどに対処してくれる。
• Finagle は、Tumblr や SoundCloud などが自社のマイクロサー
ビスへの Scala 導入に踏み切る大きな要因になっている
• 解説記事書いてます: 「マイクロサービスが Scala を選ぶ3
つの理由」
Tumblr Architecture - 15 Billion Page Views a Month and Harder to Scale than Twitter
81. Finagle による分散処理
val userAndTweets = Future.join(
userService.findByUserId(userId),
tweetService.findByUserId(userId)
)
find
find
userId userAndTweets
User
Service
Tweet
Service
http://www.slideshare.net/knoldus/finagle-by-twitter-engineer/16
join
他のマイクロサービスへクエリ
を投げ、全ての応答が ったら
非同期に集約してタプルにする
82. What と How の分離
Input
Input
Output(2) ランタイム
(1) プログラミングモデル (DSL)
(how を実行する = メッセージ配送)
(what を記述する = データフロー)
関数型プログラミングなどの
宣言的なプログラミングモデルと親和性が高い
88. ログ指向アーキテクチャ
• Kafka のようなログ指向の分散 MQ に、他コンポー
ネントへの全メッセージを書き込んで永続化
• 全てのコンシューマがメッセージを同じ順序で認
識することを保証する(書き込み順序は不定)
• 大規模なマイクロサービスでは一般的?
• Twitter の Cassandra 後継の分散 DB
“Manhattan” も同様のアイデアを採用している
90. CRDT
• Conflict-Free Replicated Data Types
• 順序に関係なく収束するデータ型と演算の組に
ついて、分散ノード間で協調動作なしで強い結
果整合性を保ったデータ共有を実現する仕組み
• Set, Counter, Register, Flag, Map, Graph 等
• できないこともあるので注意(ユニーク ID の
発行など)
91. CRDT の利用例
• League of Legends のチャットサーバ
• Riak 上に実装している
• フレンドリスト管理の分散化など
• https://engineering.riotgames.com/news/chat-
service-architecture-persistence
• Akka でも利用できる (Akka Distributed Data モ
ジュール)
92. 参考: LASP
• Erlang + Riak Core ベースの分散処理言語
• Basho の Christopher Meiklejohn 氏が開発中。Oz
言語で有名な Peter Van Roy 氏が指導教官?
• “Coordination-Free Computations”
• “Coordination-Free Designs for Mobile Gaming”
93. 参考: Coordination free
• 協調動作 (coordination) をしなくても一貫性が
保証できる不変条件を定式化しようという研究
• Peter Bailis, “Coordination Avoidance in
Database Systems” (スライド)
• GitHub にある OSS を解析したら 86.9% はテ
ストをパスしたとか