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

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

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

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

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

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

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

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

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

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

ストラングラーパターン 11 Monolith 在庫 通知 配送 注文 決済 Monolith 在庫 配送 決済 Monolith 通知 決済 Step0 ストラングラーファサード ストラングラーファサード Step1 Step2 Step3 注文
 MS
 通知 注文
 MS
 在庫
 MS
 配送
 MS
 在庫
 MS
 注文
 MS
 配送
 MS
 通知
 MS
 決済
 MS
 特定の機能を新しいアプリケーションやサービスに徐々に置き換えることでレガシーシステムを段階的に移行 既存システムの前段にファサードを設置し新旧にデータを振り分け、ユーザは新旧を意識せずにシステムを利用

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

イベント駆動型アーキテクチャ(EDA) 13 受注
 発送
 決済
 注文
 配送
 決済
 在庫
 通知
 ポイント
 注文
 イベント
 発送
 イベント
 決済
 イベント
 サービスのAPI呼び出しで連携するのではなく、あるサービスが発行した状態の変化(イベント)をその変化に興味がある サービスが反応することで結果的に連携が行われる
 イベントバス


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

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


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 


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

典型的な共有データベース型システム 18 DBの性能が限界
 DBの性能を上げるにはハード ウェアのコスト増が問題に
 データ量が徐々に増加し、
 バッチ処理の処理時間も長くなる。
 夜間バッチのスケジュールも限界に
 RDBMS
 ETL
 DWH
 API
 JDBC
 → データの利用側
 データの生成側 ← 
 巨大な共有DB
 バッチ処理型 
 データパイプライン 


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

CDCとストリームプロセシングの採用 20 RDBMS
 API
 → データの利用側 
 データの生成側 ← 
 トランザクション ログ
 マイナー
 Kibana
 インメモリキャッシュ
 Elasticsearch
 DWH
 ▸ ワークロードに応じたデータソースを選択 
 ▸ なんでもかんでも RDBMS を使用しない 
 ストリーミング 
 プラットフォーム 
 ▸ ストリーミングプラットフォームによる 
 データパイプラインの構築 
 ▸ ストリーミングプラットフォームにより ETL が不要に 
 ▸ クレンジングを実施しながらリアルタイム連携 
 ▸ トランザクションログテーリングで RDBMS からチェンジイベント生成 
 ▸ インテグレーションアプリが 
 プロトコル&データ変換し 
 参照用のリードモデルへリプレイ 
 CDC
 データパイプラインはバッチではなく、リアルタイム処理に


共有DBを廃止してイベント駆動型データ連携システムへ 21 データハブとなっていた巨大なRDBMSは不要に
 RDBMS
 トランザクショ ンログ
 マイナー 
 ストリーミング 
 プラットフォーム 
 → データの利用側 
 データの生成側 ← 
 ▸ トランザクションが必要なサービスのみ 
 RDBMS に対する書き込みを続ける 
 ▸ イベントに置き換え可能なサービスはイ ベントを書き込むように変更 
 API
 Kibana
 インメモリキャッシュ 
 Elasticsearch 
 オブジェクト 
 ストレージ 
 ▸ オブジェクトストレージに置き換え 
 SQL on Spark / Hadoop 
 API Gateway
 ▸ API Gateway 
 パターンを適用 
 オンライン利用
 オフライン利用
 イベントバス


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

デモ 23 データパイプラインはバッチではなく、リアルタイム処理に
 RDBMS
 API
 → データの利用側 
 データの生成側 ← 
 トランザクショ ンログ
 マイナー 
 Kibana
 インメモリキャッシュ
 Elasticsearch
 DWH
 ▸ ワークロードに応じたデータソースを選択 
 ▸ なんでもかんでも RDBMS を使用しない 
 ストリーミング 
 プラットフォーム 
 ▸ ストリーミングプラットフォームによる 
 データパイプラインの構築 
 ▸ ストリーミングプラットフォームにより ETL が不要に 
 ▸ クレンジングを実施しながらリアルタイム連携 
 ▸ トランザクションログテーリングで RDBMS からチェンジイベント生成 
 ▸ インテグレーションアプリが 
 プロトコル&データ変換し 
 参照用のリードモデルへリプレイ 
 CDC


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

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

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