マイクロサービス間のデータ連携を実現するメッセージングミドルウェア

Transcript

1. マイクロサービス間のデータ 連携を実現するメッセージング ミドルウェア Red Hat K,K. テクニカルサービス本部 2020/06
2. Copyright 2020 Red Hat K.K. 1. マイクロサービスとは 2. マイクロサービスをすべて REST で実現すると 3. マイクロサービス間を疎結合にするには 4. REST とメッセージングミドルウェアの比較 5. マイクロサービスパターンの一つイベントソーシング 6. イベント駆動マイクロサービス 7. メッセージングミドルウェア Apache Kafka 8. イベント駆動マイクロサービス - Knative Eventing - アジェンダ

3. マイクロサービスとは • 1サービス、1DB • モノリスに比べ、改修の際の影響範囲を局所化 • Polyglot: マイクロサービスごとに チームの得意な開発言語を適用することが可能 ◦ ただしサービスの属人化が進む • 必要なサービスのみスケール 可能 ◦ モノリスの場合、スケールに伴って不要な機能もスケールされる • サービスが多数起動し、 複雑化 モノリスと比較すると・・・
4. マイクロサービスを REST のみで構成した場合の問題点 マイクロサービス • すべてのサービスが正常に動作していることが前提 ◦ どこかのサービスで障害が発生すると機能不全のサービスが下流 に向かって発生しサービス全体が機能不全 ◦ 別途サーキットブレーカーの導入が必要 • 処理途中でエラーとなった際のリトライ処理が複雑化 • リクエストとレスポンスがセットになっているため、アクセスが集中すると サーバーが高負荷に • サービスが増加するとサービス間の連携が複雑化 マイクロサービスを REST のみで実現すると・・・ REST REST REST REST
5. マイクロサービス間を疎結合にするには Messeaging Middleware • マイクロサービス間のやりとりにはメッセージングミドルウェアを適 用 • クライアントはメッセージングミドルウェアに書き込み • At Least Once を保証するため、最低 1回はメッセージが届く ◦ メッセージの購読側で重複を排除する処理が必要 ◦ Exactly Once なメッセージングミドルウェアも存在 ▪ 後述する Apache Kafka は Exactly Once • 呼び出し先のサービスが障害発生している際もメッセージングミド ルウェアに保存され、永続化 • メッセージングミドルウェアで高い可用性・スループットを保証 メッセージングミドルウェアをマイクロサービス間に配置
6. Copyright 2020 Red Hat K.K. REST とメッセージングミドルウェアの比較 6 • 同期的&一時的 • 低コンポーザビリティ • 簡素化されたモデル • 低い耐障害性 • ベストプラクティスはRESTに進化 • 非同期的で永続的、デカップル • 非常にコンポーザブル • 複雑なモデル • 高い耐障害性 • ベストプラクティスは進化途上 REST メッセージングミドルウェアを適用
7. マイクロサービスパターンの一つイベントソーシング • RDBMS にはステートは保存せず、メッセージングミドルウェアにイベントを保存 • ステートはイベントをリプレイすることで手に入る これにより、RDBMS への保存が不要に • イベントは事実を伝え、不変である • メッセージングミドルウェアにより高可用性、高スループットを保証 1. カート作成 2. カートに商品 A を追加 3. カートに商品 B を追加 4. カートから商品 A を削除 イベントを受ける メッセージングミドルウェア イベントの発生順 • 最終的なカートの中身 (ステート)であ る商品 B が入っているという状態は イベントを順番に実行することで手に 入る • また、履歴が残るため監査などで役 立てることが可能
8. イベント駆動型マイクロサービス ← メッセージングミドルウェア
9. メッセージングミドルウェア Apache Kafka • 2010にLinkedInで開発され、2011年にオープンソース化された ◦ ストリーミングデータのための分散システム • 非常に高いスループットと低レイテンシーで大量データを処理 • 容易に水平スケール • コミットログとしてメッセージを保持 • データパーティショニング (シャーディング) • クラスタリングにより高い耐障害性 • 大量のコンシューマも処理可能 • LinkedInの開発者がApache Kafka を新たに作ったわけ ◦ リアルタイムログのような高いボリュームのイベントストリームをサポートするためのハイスループットを実現したい ◦ オフラインシステムからの定期的なデータロードを可能とする大容量バックログを取り扱いたい ◦ 伝統的なメッセージングのユースケースを取り扱うために低遅延である必要がある
10. Broker Node2 Broker Node3 Broker Node4 Broker Node5 Broker Node1 Apache Kafka 全体像 ① Topic1 Topic2 ② ① ② ① : Replication Factor ② : Partitions リーダーレプリカ フォロワーレプリカ Brokers Consumer Group 2: (例) Object Storage Consumer Consumer Group 1: (例) リアルタイム処理 MirrorMaker 異なる DC へ ミラーリング Partition0 Partition1 Consumer Group1: (例) リアルタイム処理 Partition0 Partition1 Partition2 Producer1 Producer2 Producer はラウンドロビンか、任意のハッシュキーを使用 して単一の Partition を選択するか選べる Consumer 数は≒ Partition 数にすると並列度が 上がり効率的に処理可能 Consumer < Partition になると 1 Consumer で処 理する Partition が複数に
11. イベント駆動マイクロサービス -Knative Eventing - Configuration Revision 1 Revision 2 Revision 3 Application (Knative Service) Routes Directs traffic Traffic splitting Event Source Event channel Subscription ※ Knative Eventing は 2020/06/01 現在 Tech Preview のステータスです。Red Hat から正 式なサポートは提供できません。Knative Serving はリリース済みでサポートを受けることがで きます。 Kafka に何かしらのメッセージが格納された際にベンダー非依存な CloudEvents を発行して Knative Serving アプリケーションを発火させるイベント駆動なアプリ ケーションを構築可能(KafkaSources) イベントの永続化(Channel)領域として KafkaChannel を利用することも可 Knative Serving コンポーネント • オートスケール • 0までのスケールを可能に • トラフィック分割による A/B テスト等
12. linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you.