Developer_Summit_2022

レッドハットのミドルウェアでレガシーアプリケーションを段階的にモダナイズする話

Transcript

1. レッドハットのミドルウェアで
   レガシーアプリケーションを
   段階的にモダナイズする話
   レッドハット株式会社
   森　和哉
   1
   セッションID：17-E-7
   ハッシュタグ：#devsumi
   

   View Slide

2. 自己紹介
   2
   製造業にて工場の生産能力改善に長年携わり、
   その後は基幹システム刷新プロジェクトに従事。
   現在はレッドハットのソリューションアーキテクトとして、
   主に業務ロジックを可視化するルールエンジンの導入 の提案などを担当。
   レッドハット株式会社
   スペシャリストソリューションアーキテクト
   森　和哉（Kazuya Mori）
   

   View Slide

3. アプリモダナイズへの関心度は非常に高い
   3
   大幅に増えた保守
   コストを削減したい
   ブラックボックスを見え
   る化したい クラウドへの移行を可
   能にしたい
   他システムとの
   連携を柔軟に
   変更要求に迅速に
   対応したい
   データ量や利用者の
   増加に柔軟に対応したい
   

   View Slide

4. しかし、立ちはだかる壁
   4
   密に結合したシステム、そ
   う簡単に分割できそうもな
   い
   中身がブラックボックス
   化。手のつけようが無い
   気がする。
   マイクロサービスだのコ
   ンテナだのスキルセット
   が足りてない
   巨大なシステムをどう
   やって移行していけば
   良いの？
   組織も文化もウォーターフォール開
   発が前提になっており、
   そう簡単に変えられない
   

   View Slide

5. 昨年のデブサミ(2021/2)では・・・
   5
   ブラックボックス化したレガシーシステムでも
   迅速なモダナイズを可能にする開発手法
   「ルール駆動開発」
   をご紹介しました
   解説マンガもありますの
   でぜひご覧下さい
   

   View Slide

6. ２つの移行方式
   6
   安い トータルコスト 高い
   短い 工期 長い
   高い 難易度/リスク 低い
   完成するまで効果が
   測定できない
   移行効果
   (コスト/業務プロセス)
   小さな効果を確認しつつ
   導入範囲を決定できる
   一括移行 段階的移行
   

   View Slide

7. イベント駆動型アーキテクチャ（EDA）
   アプリケーションやサービスがイベント
   通知の送受信に対してリアルタイムに
   応答するような設計方式
   段階的移行に有効なテクノロジーとデザインパターン
   7
   マイクロサービス
   互いに独立した小さなサービスが連動すること
   で1つのアプリケーションとして
   動作するアーキテクチャやそのアプローチ
   ストラングラーパターン
   特定の機能を新しいアプリケーションやサービ
   スに徐々に置き換えることで
   レガシーシステムを段階的に移行する
   デザインパターン
   コンテナ
   コンテナはアプリケーションとその動作に必要
   なライブラリ、依存関係、ファイルが含まれてお
   り、ホストOS上で独立した
   アプリケーションとして実行される
   

   View Slide

8. マイクロサービス
   8
   マイクロサービスとは
   互いに独立した小さなサービス (機能)が連動することで、
   1つのアプリケーションとして動作するアーキテクチャや
   そのアプローチ
   マイクロサービスの価値
   　Fast Time To Market
   　サービスが小さく、自律的であるため、
   　素早く開発してデリバリーできる
   　Efficiency
   　サービスが小さいため、デリバリーの自動化や
   　モニタリングが容易
   　Scalability
   　細かい粒度でスケーラビリティを制御でき、
   　リソースの利用を最適化しやすい
   

   View Slide

9. コンテナ
   9
   コンテナとは
   コンテナはアプリケーションとその動作に必要なライブラリ、依
   存関係、ファイルが含まれており、ホストOS上で独立したアプリ
   ケーションとして実行される
   コンテナの価値
   Resource Isolation
   　リソースと責任の分離
   Run Anywhere
   　環境を意識しない可搬性
   Immutable Architecture
   　アプリケーションの再現性
   

   View Slide

10. マイクロサービス とコンテナの親和性
    10
    移行戦略：ビッグバンではなく段階的な移行
    現状の課題：ブラックボックスで肥大
    化し改修が困難になっている
    結果：技術が古くノウハウの継承が
    困難で開発コストが高い
    目指す姿：システムの透明性が高く
    改修しやすいアーキテクチャー
    目的：ノウハウの継承が容易で
    開発コストが低い
    アプリケーション視点
    現状の課題：モノリシックなシステム
    に最適化された標準化が定着
    結果：テクノロジーの変化に適した開
    発・運用プロセスではない
    目指す姿：小さい単位で頻繁に改修
    ができる基盤の確立
    目的：ノウハウの継承が容易で
    運用コストが低い
    インフラストラクチャー視点
    マイクロ
    サービス化
    コンテナ基盤
    

    View Slide

11. ストラングラーパターン
    11
    Monolith
    在庫 通知
    配送
    注文
    決済
    Monolith
    在庫
    配送 決済
    Monolith
    通知
    決済
    Step0
    ストラングラーファサード
    ストラングラーファサード
    Step1 Step2 Step3
    注文

    MS

    通知
    注文

    MS

    在庫

    MS

    配送

    MS

    在庫

    MS

    注文

    MS

    配送

    MS

    通知

    MS

    決済

    MS

    特定の機能を新しいアプリケーションやサービスに徐々に置き換えることでレガシーシステムを段階的に移行
    既存システムの前段にファサードを設置し新旧にデータを振り分け、ユーザは新旧を意識せずにシステムを利用
    

    View Slide

12. マイクロサービス間のデータ連携について
    12
    マイクロサービス
    ● すべてのサービスが正常に動作していることが前提
    ○ どこかのサービスで障害が発生すると機能不全のサービスが下流
    に向かって発生しサービス全体が機能不全
    ○ 別途サーキットブレーカーの導入が必要
    ● 処理途中でエラーとなった際のリトライ処理が複雑化
    ● リクエストとレスポンスがセットになっているため、アクセスが集中すると
    サーバーが高負荷に
    REST
    REST
    REST
    REST
    障害時の対応(リトライ、巻き戻し)が複雑化
    REST(同期通信)のみで構成した場合
    

    View Slide

13. イベント駆動型アーキテクチャ(EDA)
    13
    受注
 発送
 決済

    注文
 配送
 決済

    在庫
 通知

    ポイント

    注文

    イベント

    発送

    イベント

    決済

    イベント

    サービスのAPI呼び出しで連携するのではなく、あるサービスが発行した状態の変化(イベント)をその変化に興味がある
    サービスが反応することで結果的に連携が行われる

    イベントバス

    

    View Slide

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

    View Slide

15. CQRS: Command Query Responsibility Segrigation
    （コマンド-クエリ責任分離）
    15
    イベント駆動を利用したマイクロサービスデザインパターンのひとつ

    注文サービス

    create, update

    delete

    配送サービス

    create, update

    delete

    注文

    イベント
    

    発送イベント
    

    注文履歴サービス

    query

    Query API
    

    Event Handler 

    注文テーブル 

    配送テーブル 

    検索用 注文/配送 

    JOINテーブル 

    C,U,D
    

    C,U,D
    

    C,U,D
    

    R

    CQRSの基本動作：

    • 検索用に予め必要なデータ要素を全て

    含むJOINテーブルを用意する

    • 更新系要求はサービス個別のDBを更新しつ
    つ、更新イベントを検索サービスに送信する

    • 検索サービスは更新イベントを拾い、

    順次検索用JOINテーブルを更新する

    

    利点：

    • 検索の応答性能向上

    • サービス間の非依存性(separation of
    concerns)の向上

    

    欠点：

    • 一時的にデータの一貫性が損なわれる

    (結果整合性の許容)

    メッセージ

    ブローカー
    

    ex. kafka

    

    View Slide

16. CDC: Change Data Capture
    16
    DBトリガをイベントに変換するミドルウェアを使用することでイベント駆動型サービス間連携を簡単に実現

    注文サービス

    create, update

    delete

    配送サービス

    create, update

    delete

    注文履歴サービス

    query

    Query API
    

    Event Handler 

    コミットロ
    グ

    検索用 注文/配送 

    JOINテーブル 

    C,U,D
    

    C,U,D
    

    C,U,D
    

    R

    DBのコミットログ

    • MySQL: binlog

    • Postgresql: write-ahead log

    • MongoDB: op-log

    トランザクションログ 

    マイナー

    イベント

    発行

    https://www.redhat.com/en/topics/integration/what-is-change-data-capture 

    

    View Slide

17. CDC: Change Data Capture
    17
    Debezium
    チェンジデータキャプチャ プラットフォーム
    ● Kafka Connectを使用した
    チェンジデータキャプチャ (CDC) のコネクタ
    ○ コネクタが指定されたデータベースに接続
    し、トランザクションログを読み取り、そ
    れをKafkaメッセージとしてパブリッシュ
    ● データベースに発生した Create / Update /
    Delete のイベントを他データソースへ伝播さ
    せ反映
    ○ キャッシュ
    ○ RDBMS
    ○ Object Storage
    ○ ファイル
    

    View Slide

18. 典型的な共有データベース型システム
    18
    DBの性能が限界
 DBの性能を上げるにはハード
    ウェアのコスト増が問題に

    データ量が徐々に増加し、

    バッチ処理の処理時間も長くなる。

    夜間バッチのスケジュールも限界に

    RDBMS

    ETL
 DWH

    API

    JDBC

    → データの利用側

    データの生成側 ←
    

    巨大な共有DB

    バッチ処理型 

    データパイプライン 

    

    View Slide

19. 共有データベースを利用する理由
    19
    ● シンプルなインターフェース
    ● RDBMS の強力なトランザクション機能により Consistency の担保が容易
    データの Consistency(一貫性) を担保するのが容易
    データのConsistencyは以下の要素に分解できる
    • Integrity (整合性): 永続化されたデータに破損や矛盾がないこと
    • Timeliness (即時性): 参照されたデータが常に最新であることを保証すること
    Timeliness に対する制約を緩和 (結果整合性を許容)すれば、
    トランザクションを使わずにConsistencyを実現できる
    

    View Slide

20. CDCとストリームプロセシングの採用
    20
    RDBMS

    API

    → データの利用側 

    データの生成側 ← 

    トランザクション
    ログ

    マイナー

    Kibana

    インメモリキャッシュ

    Elasticsearch

    DWH

    ▸ ワークロードに応じたデータソースを選択 

    ▸ なんでもかんでも RDBMS を使用しない 

    ストリーミング 

    プラットフォーム 

    ▸ ストリーミングプラットフォームによる 

    データパイプラインの構築 

    ▸ ストリーミングプラットフォームにより ETL が不要に 

    ▸ クレンジングを実施しながらリアルタイム連携 

    ▸ トランザクションログテーリングで RDBMS
    からチェンジイベント生成 

    ▸ インテグレーションアプリが 

    プロトコル&データ変換し 

    参照用のリードモデルへリプレイ 

    CDC

    データパイプラインはバッチではなく、リアルタイム処理に

    

    View Slide

21. 共有DBを廃止してイベント駆動型データ連携システムへ
    21
    データハブとなっていた巨大なRDBMSは不要に

    RDBMS

    トランザクショ
    ンログ

    マイナー 

    ストリーミング 

    プラットフォーム 

    → データの利用側 

    データの生成側 ← 

    ▸ トランザクションが必要なサービスのみ 

    RDBMS に対する書き込みを続ける 

    ▸ イベントに置き換え可能なサービスはイ
    ベントを書き込むように変更 

    API

    Kibana

    インメモリキャッシュ 

    Elasticsearch 

    オブジェクト 

    ストレージ 

    ▸ オブジェクトストレージに置き換え 

    SQL on Spark /
    Hadoop 

    API
    Gateway

    ▸ API Gateway 

    パターンを適用 

    オンライン利用

    オフライン利用

    イベントバス

    

    View Slide

22. 22
    ここで、少しデモを
    見て頂こうと思います
    

    View Slide

23. デモ
    23
    データパイプラインはバッチではなく、リアルタイム処理に

    RDBMS

    API

    → データの利用側 

    データの生成側 ← 

    トランザクショ
    ンログ

    マイナー 

    Kibana

    インメモリキャッシュ

    Elasticsearch

    DWH

    ▸ ワークロードに応じたデータソースを選択 

    ▸ なんでもかんでも RDBMS を使用しない 

    ストリーミング 

    プラットフォーム 

    ▸ ストリーミングプラットフォームによる 

    データパイプラインの構築 

    ▸ ストリーミングプラットフォームにより ETL が不要に 

    ▸ クレンジングを実施しながらリアルタイム連携 

    ▸ トランザクションログテーリングで RDBMS
    からチェンジイベント生成 

    ▸ インテグレーションアプリが 

    プロトコル&データ変換し 

    参照用のリードモデルへリプレイ 

    CDC

    

    View Slide

24. デモ
    24
    Web
    アプリ
    レガシーアプリ
    CDC
    ストリーミング・
    プラットフォーム
    データ
    形式変換
    データ
    編集
    注文の受付
    を行う
    CDCの出力から、後
    続の処理に必要な部
    分を抽出
    レガシーにない項目を新
    しく編集して追加
    - 合計金額
    - 送料 etc
    

    View Slide

25. 本日のまとめ
    25
    ● モノリシックなレガシーアプリケーションをマイクロサービス化して小さな機能単位に分割
    し、ストラングラーパターンで徐々に置き換えることで段階的な移行を実現する
    ● イベント駆動型アーキテクチャと、
    CQRS＋CDCのデザインパターンを適用し、
    巨大な共有DBを解体すると共に、バッチ連携ではなくリアルタイムにデータ連携をするよう
    なシステムに転換する
    

    View Slide

26. 26
    ありがとう
    ございました
    

    View Slide