@huntchr
TypeSafeのひと。
- リアクティブマイクロサービス
Play & Akkaによるマイクロサービスのりアクティブ化
30人17カ国で仕事してる
- テクノロジーの分散型だけではなくHRでも分散
- 6人がアジア系
- 4人がシドニー
- NZにも人がいる
http://www.reactivemanifesto.org/ja
リアクティブマニフェスト
4つの要素のうち、2つをとりあげる
- レジリエンス(耐障害性) ここが最も重要
弾力性
耐障害性がなければ他の要素は意味がなかった
- 障害発生時の即応性
- システム開発をやる以上障害は避けて通れない
- 複数のインスタンスが走っている
- ネットワークパーティション
- スプリットブレインの問題
- 思っている以上に障害は起きる
- どこかのタイミングでスプリットブレインの問題が発生する
- reactive revealed 3000人のアンケート
- リアクティブ宣言で何が一番重要なのかということを調査したところ、弾力性が飛び抜けて重要であるという結果が得られた
- マシンを増やすことで弾力性が高まった
- やはり耐障害性とくらべると…という問題はある
- 耐障害性(Resiliency)を確実にしていきたい
- 飛行機の予約システム/銀行など、何日もオフラインになるのはつらい
- 耐障害性を持っておきたい 障害対応に時間をさかれることもなくなる
- 顧客マイクロサービス データストアの永続化 ローカルキャッシング 値のキャッシングもいける
- データベースを毎回毎回取りに行くのはコスト キャッシングをすることが重要
Play Framework 2.4での例
- サービスのinject
- HTTP関連での処理
- HTTPサービス 別のメッセージングシステムのサポート
- findAll/insertのメソッド(戻り値はJSON)
- カスタマーサービスが2つのメソッドを提供する
- 情報をべつのところへうつす
- 2つのシーケンスを持ってくる
カスタマーサービスのステートアクター
GetCustomer
- カスタマーの情報をアクターに入れる
- すべてのカスタマーを入れる
このときにキャッシュをつかって入れ込む(時間の値)
キャッシュオブジェクトを使わないで、アクターを使う
CustomerRepository
- SQLとかの振る舞いをSlickを使ってカスタマーについてretrieveをかけてる
シングルインスタンスで起動してる
curlで情報をfindしたりinsertしたりする簡単なサービス
でもこのシステムはリアクティブなのか…？
- シングルインスタンスでいいのか(データも永続的なのか JDBCのシリアル)
- スケーラビリティはあるのか(横展開できるのか ステートをデータベースに当てはめてサービスはステートレス、というふうにしている)
- キャッシュマネジメント(inMemoryな表現がいくつかある)
Noです。
ソリューション
- デフォルトでクラスタリングできるようなDB たとえばPostgres BDRを使う (マスタースレーブの関係)
- 複数ノード " 複数ノードで走らせる たとえばConduct Rにデプロイする conductrはTypeSafeの商品
- キャッシュ更新のシグナル 例: Akka Data Replication
ConductR
- リアクティブなアプリケーションのデプロイと管理が出来る
- 最終的な全体像は本番稼働しないと分からなかったりする
- コンパイル時点ではそれが分からない
- DevOpsの役割を担っている
- Opsの部分がインスタンスの数などを管理している
- HA(分散型コンピューティング)
- こういう課題があるためにConductRを使おう作ろうとした
- たとえばNetflixでもConductRを使っている
- ConductRの目的はAkkaを見てもわかるように、ActorSystemの延長線上にいる
Make This Reactive!
- マシンを立ち上げる
- visualizer
- conductr-elasticsearch
- postgres-bdr
- インスタンスはひとつだけどマイクロサービスアーキであるといえる
- まずはログの統合が必要(これがconductRでやっている)
- サービスをクラスタにロードする 非常に短期間でスケールアップスケールアウトが出来る
- サービスのスタートは自分自身で
- bundleのハッシュ
- 毎回curlを叩くためにproxyを通り、conductRを保管して、ラウンドロビンしてくれる
- シグナルがクラスタ間で展開され、変更/削除がクラスタ間で反映される
- これができていないとクラスタ別にデータが違うということになってしまう
- bundle sbtのコンソール上でいろいろ出来る
- conductr-bundleit
- シードとなる情報をconductRが持っている
- riak redis cassandraなどでも使えることを紹介したかったんだけれども。
- RDBではなくNoSQLで紹介したかった
強力な一貫性を実現するのは大変なので、最初は最適化にリソースを割いたほうがいい
サービスをReactiveにするだけで耐障害性が保たれる
まとめ
- 耐障害性
- 弾力性
- キャッシュ管理
