マイクロサービス間のデータ 連携を実現するメッセージング ミドルウェア Red Hat K,K. テクニカルサービス本部 2020/06

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


マイクロサービスとは ● 1サービス、1DB ● モノリスに比べ、改修の際の影響範囲を局所化 ● Polyglot: マイクロサービスごとに チームの得意な開発言語を適用することが可能 ○ ただしサービスの属人化が進む ● 必要なサービスのみスケール 可能 ○ モノリスの場合、スケールに伴って不要な機能もスケールされる ● サービスが多数起動し、 複雑化 モノリスと比較すると・・・

マイクロサービスを REST のみで構成した場合の問題点 マイクロサービス ● すべてのサービスが正常に動作していることが前提 ○ どこかのサービスで障害が発生すると機能不全のサービスが下流 に向かって発生しサービス全体が機能不全 ○ 別途サーキットブレーカーの導入が必要 ● 処理途中でエラーとなった際のリトライ処理が複雑化 ● リクエストとレスポンスがセットになっているため、アクセスが集中すると サーバーが高負荷に ● サービスが増加するとサービス間の連携が複雑化 マイクロサービスを REST のみで実現すると・・・ REST REST REST REST

マイクロサービス間を疎結合にするには Messeaging Middleware ● マイクロサービス間のやりとりにはメッセージングミドルウェアを適 用 ● クライアントはメッセージングミドルウェアに書き込み ● At Least Once を保証するため、最低 1回はメッセージが届く ○ メッセージの購読側で重複を排除する処理が必要 ○ Exactly Once なメッセージングミドルウェアも存在 ■ 後述する Apache Kafka は Exactly Once ● 呼び出し先のサービスが障害発生している際もメッセージングミド ルウェアに保存され、永続化 ● メッセージングミドルウェアで高い可用性・スループットを保証 メッセージングミドルウェアをマイクロサービス間に配置

Copyright 2020 Red Hat K.K. REST とメッセージングミドルウェアの比較 6 ● 同期的&一時的 ● 低コンポーザビリティ ● 簡素化されたモデル ● 低い耐障害性 ● ベストプラクティスはRESTに進化 ● 非同期的で永続的、デカップル ● 非常にコンポーザブル ● 複雑なモデル ● 高い耐障害性 ● ベストプラクティスは進化途上 REST メッセージングミドルウェアを適用

マイクロサービスパターンの一つイベントソーシング ● RDBMS にはステートは保存せず、メッセージングミドルウェアにイベントを保存 ● ステートはイベントをリプレイすることで手に入る これにより、RDBMS への保存が不要に ● イベントは事実を伝え、不変である ● メッセージングミドルウェアにより高可用性、高スループットを保証 1. カート作成 2. カートに商品 A を追加 3. カートに商品 B を追加 4. カートから商品 A を削除 イベントを受ける メッセージングミドルウェア イベントの発生順 ● 最終的なカートの中身 (ステート)であ る商品 B が入っているという状態は イベントを順番に実行することで手に 入る ● また、履歴が残るため監査などで役 立てることが可能

イベント駆動型マイクロサービス ← メッセージングミドルウェア

メッセージングミドルウェア Apache Kafka ● 2010にLinkedInで開発され、2011年にオープンソース化された ○ ストリーミングデータのための分散システム ● 非常に高いスループットと低レイテンシーで大量データを処理 ● 容易に水平スケール ● コミットログとしてメッセージを保持 ● データパーティショニング (シャーディング) ● クラスタリングにより高い耐障害性 ● 大量のコンシューマも処理可能 ● LinkedInの開発者がApache Kafka を新たに作ったわけ ○ リアルタイムログのような高いボリュームのイベントストリームをサポートするためのハイスループットを実現したい ○ オフラインシステムからの定期的なデータロードを可能とする大容量バックログを取り扱いたい ○ 伝統的なメッセージングのユースケースを取り扱うために低遅延である必要がある

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 が複数に

イベント駆動マイクロサービス -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 テスト等

linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you.