Lightbend Academyでリアクティブシステムの基礎を学ぼう - JJUG LT

Transcript

1. Lightbend Academyで リアクティブシステムの基礎を学ぼう 1 2020-08-26 JJUGナイトセミナー 「おうちで！ビール片手にLT大会！」
2. 自己紹介 辻 陽平（Yohei TSUJI） Chatwork株式会社 開発本部 コアテクノロジー開発部 @大阪 2020年5月にChatworkに入社。 Scalaエンジニアやってます。 @crossroad0201
3. もくじ 1. Lightbend社 と Akka 2. Lightbend Academyとは 3. Architecture トレーニングパスの紹介 4. まとめ
4. Lightbend社 • リアクティブシステムの推進とそれを支援するプロダクトを開発。 • Scala向けなイメージが強いが、Javaもけっこうサポートしてる。
5. Akka • リアクティブシステムの構築を支援するフレームワーク、ライブラリ群。 ◦ 高度な並列処理 ◦ 複数ノードでの分散実行 ◦ 高い耐障害性、回復性 • Scala用とJava用、２つのDSLをサポート 。 • アクターモデルがベースになっている。
6. Lightbend Academy • Lightbend 社が提供しているオンライントレーニングプログラム。 • 同社のエンタープライズ向け有償サービス「Lightbend Subscription」で提供され るプログラムのうちのひとつ。（サブスクリプションの価格は要問合せ...） • 現在、無償で受講できる。（Through Summer 2020 っていつまでだろう...） https://www.lightbend.com/academy/register/0010h00001eEJDIAA4
7. コース • 30のコース（2020年8月時点） • 受講時間は1コース4〜8時間くらい。 • 動画・スライドによる解説、途中の確認テスト、最終テスト。 ◦ 最終テストは1度しか受験できないことに注意！！！
8. トレーニングパス 各コースは任意の順に受講できるが、目的に応じて体系的に学習するためのトレーニン グパスが提案されている。 1. Architecture 2. Scala Language 3. Akka Microservices 4. Logom Mictoservices 5. Data Engineering
9. Architecture トレーニングパス リアクティブシステムとは何なのか、その背景にある要求とそれを解決するための理論 を体系的に学ぶことができるトレーニングパス。 6つのコースから構成されている。 1. Introduction to Reactive 2. Domain Driven Design 3. Reactive Microservices 4. Building Scalable Systems 5. Distributed Messaging Patterns 6. CQRS & Event Sourcing
10. 1.Introduction to Reactive • なぜ今リアクティブシステムなのか？ ◦ 社会生活の中でWebサービスが果たす役割はどんどん大きくなっている。 ◦ 必要なときに使えなければ、ユーザーの信頼を失ってしまう。 ◦ 目的は技術的課題の解決ではなく、ユーザーの期待に応えること。 • リアクティブ宣言（https://www.reactivemanifesto.org/ja）を満たしたシステム。 • リアクティブプログラミング をしたからと言って、リアクティブシステムになるわ けではない。
11. 2.Domain Driven Design • リアクティブシステムの構築にも、ドメイン駆動設計の考え方が役に立つ。 • 一貫性は可用性やスケーラビリティにトレードオフな影響を与える。 ビジネス視点から一貫性を保証する単位を決める必要がある。 ◦ Akka を使う場合は「集約ルート」がアクターの候補になる。 • ドメイン駆動設計の「境界づけられたコンテキスト」が、マイクロサービスの有効 な分割単位になる。
12. 3.Reactive Microservices • リアクティブマイクロサービスでは、マイクロサービス間の通信はすべて非同期／ ノンブロッキングにおこなわれる。 • ４つの観点でマイクロサービスを隔離する。 ◦ 状態：他のマイクロサービスの内部状態に依存しない。 ◦ 空間：他のマイクロサービスがどこにデプロイされているかに依存しない。 ◦ 時間：他のマイクロサービスの処理を待たない。 ◦ 障害：他のマイクロサービスの障害の影響を受けない。 • 隔離の方法。 ◦ サーキットブレーカー。 ◦ メッセージ駆動による非同期／ノンブロッキング通信。 ◦ データコピーの保持。
13. 4.Building Scalable Systems • システムに求められる「一貫性」「可用性」「スケーラビリティ」にはトレードオ フな関係があり、ビジネスの優先度からバランスを取らなければならない。 ◦ 一貫性を広く／強く保とうとすると、スケーラビリティが下がる。 ◦ 可用性を高くしようとすると、複製のコストがかかる。 ◦ CAP定理のバランスを取る。 • バランスを取るテクニック。 バランス テクニック スケールの方法 デメリット 一貫性と スケーラビリティ シャーディング シャードを増やすことで スケールできる。 可用性がやや犠牲に なる。 可用性と スケーラビリティ CRDT Conflict-free Replicated Data Type レプリカを増やすことで スケールできる。 一貫性は結果整合性 になる。
14. 5.Distributed Messaging Patterns • メッセージ駆動は、リアクティブシステムの基礎となる技術。 • メッセージ駆動では応答を待たないので、リソースの占有を最小限にできる。 ◦ 応答もメッセージとして非同期に返却される。 • メッセージ駆動ではRDBMSのトランザクションは使えない。 替わりに「Sagaパターン」のような長期トランザクションを実現するテクニックを 使う。 • メッセージを”1回だけ確実に配信する”ことは不可能。 ◦ At most once：最大1回配信。欠損する可能性あり。 ◦ At least once：欠損しないが、2回以上配信される可能性あり。 • マイクロサービス間のメッセージングは、Pub/Subパターンを基本とする。
15. 6.CQRS & Event Sourcing • 書き込み と 読み取り に求められる要件はまったく異なるので、同じモデルを使っ て両方をサポートすることには限界がある。 • CQRS（Command Query Responsibility Segregation） ◦ 書き込み（Command）と読み取り（Query)で別のモデルを使う。 ◦ モデルをわけることで、求められる要件にそれぞれ最適化できる。 ◦ 書き込みは一貫性重視、読み取りは可用性重視。 • ステートソーシング と イベントソーシング。 ◦ イベントソーシングでは過去の履歴がすべて残るので、システム運用開始後に 新しく発生したビジネス要件にも対応しやすい。 • CQRS も イベントソーシング も開発／運用コストがかかるので、ビジネス要件か ら本当に必要かどうかを検討する。
16. まとめ • これからリアクティブシステムが必要となる場面は増えていくと思います。 • リアクティブシステムの構築は必要に迫られてからすぐには難しいです。 求められる性質とその関係、ビジネス要件から適切な設計判断をする知識やノウハ ウが必要です。 • Lightbend Academy は、今すぐリアクティブシステムを構築しなくても受講して おくと設計の幅が広がると思います。
17. 求ム Chatworkでは Scala エンジニア を募集中です！！ https://hrmos.co/pages/chatwork/jobs/1020001
18. 働くをもっと楽しく、創造的に