Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

Kenta Kosugi

June 16, 2020
Tweet

More Decks by Kenta Kosugi

Other Decks in Technology

Transcript

  1. Copyright 2020 Red Hat K.K. 1. マイクロサービスとは 2. マイクロサービスをすべて REST

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

  2. マイクロサービスとは • 1サービス、1DB • モノリスに比べ、改修の際の影響範囲を局所化 • Polyglot: マイクロサービスごとに チームの得意な開発言語を適用することが可能 ◦

    ただしサービスの属人化が進む • 必要なサービスのみスケール 可能 ◦ モノリスの場合、スケールに伴って不要な機能もスケールされる • サービスが多数起動し、 複雑化 モノリスと比較すると・・・
  3. マイクロサービスを REST のみで構成した場合の問題点 マイクロサービス • すべてのサービスが正常に動作していることが前提 ◦ どこかのサービスで障害が発生すると機能不全のサービスが下流 に向かって発生しサービス全体が機能不全 ◦

    別途サーキットブレーカーの導入が必要 • 処理途中でエラーとなった際のリトライ処理が複雑化 • リクエストとレスポンスがセットになっているため、アクセスが集中すると サーバーが高負荷に • サービスが増加するとサービス間の連携が複雑化 マイクロサービスを REST のみで実現すると・・・ REST REST REST REST
  4. マイクロサービス間を疎結合にするには Messeaging Middleware • マイクロサービス間のやりとりにはメッセージングミドルウェアを適 用 • クライアントはメッセージングミドルウェアに書き込み • At

    Least Once を保証するため、最低 1回はメッセージが届く ◦ メッセージの購読側で重複を排除する処理が必要 ◦ Exactly Once なメッセージングミドルウェアも存在 ▪ 後述する Apache Kafka は Exactly Once • 呼び出し先のサービスが障害発生している際もメッセージングミド ルウェアに保存され、永続化 • メッセージングミドルウェアで高い可用性・スループットを保証 メッセージングミドルウェアをマイクロサービス間に配置
  5. Copyright 2020 Red Hat K.K. REST とメッセージングミドルウェアの比較 6 • 同期的&一時的

    • 低コンポーザビリティ • 簡素化されたモデル • 低い耐障害性 • ベストプラクティスはRESTに進化 • 非同期的で永続的、デカップル • 非常にコンポーザブル • 複雑なモデル • 高い耐障害性 • ベストプラクティスは進化途上 REST メッセージングミドルウェアを適用
  6. マイクロサービスパターンの一つイベントソーシング • RDBMS にはステートは保存せず、メッセージングミドルウェアにイベントを保存 • ステートはイベントをリプレイすることで手に入る これにより、RDBMS への保存が不要に • イベントは事実を伝え、不変である

    • メッセージングミドルウェアにより高可用性、高スループットを保証 1. カート作成 2. カートに商品 A を追加 3. カートに商品 B を追加 4. カートから商品 A を削除 イベントを受ける メッセージングミドルウェア イベントの発生順 • 最終的なカートの中身 (ステート)であ る商品 B が入っているという状態は イベントを順番に実行することで手に 入る • また、履歴が残るため監査などで役 立てることが可能
  7. メッセージングミドルウェア Apache Kafka • 2010にLinkedInで開発され、2011年にオープンソース化された ◦ ストリーミングデータのための分散システム • 非常に高いスループットと低レイテンシーで大量データを処理 •

    容易に水平スケール • コミットログとしてメッセージを保持 • データパーティショニング (シャーディング) • クラスタリングにより高い耐障害性 • 大量のコンシューマも処理可能 • LinkedInの開発者がApache Kafka を新たに作ったわけ ◦ リアルタイムログのような高いボリュームのイベントストリームをサポートするためのハイスループットを実現したい ◦ オフラインシステムからの定期的なデータロードを可能とする大容量バックログを取り扱いたい ◦ 伝統的なメッセージングのユースケースを取り扱うために低遅延である必要がある
  8. 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 が複数に
  9. イベント駆動マイクロサービス -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 テスト等