Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Developer_Summit_2022
Search
kamorisan
February 17, 2022
1
6.2k
Developer_Summit_2022
レッドハットのミドルウェアでレガシーアプリケーションを段階的にモダナイズする話
kamorisan
February 17, 2022
Tweet
Share
More Decks by kamorisan
See All by kamorisan
Using Change Data Capture for Stack Modernization
kamorisan
1
3.1k
red-hat-process-automation-7.9-product-update
kamorisan
0
530
AS_NL_202010_OptaPlanner_Week_Satish_Kale
kamorisan
0
480
AS_NL_202010_OptaPlanner_Week
kamorisan
0
450
red-hat-process-automation-7.8-product-update
kamorisan
0
390
Developer_Webinar_Series_2020_Digest
kamorisan
0
630
Featured
See All Featured
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
9
680
BBQ
matthewcrist
85
9.3k
How to Ace a Technical Interview
jacobian
275
23k
Ruby is Unlike a Banana
tanoku
96
11k
Designing for Performance
lara
604
68k
Typedesign – Prime Four
hannesfritz
39
2.4k
Learning to Love Humans: Emotional Interface Design
aarron
272
40k
Scaling GitHub
holman
458
140k
For a Future-Friendly Web
brad_frost
175
9.4k
How STYLIGHT went responsive
nonsquared
95
5.2k
Build The Right Thing And Hit Your Dates
maggiecrowley
32
2.4k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
25
1.8k
Transcript
レッドハットのミドルウェアで レガシーアプリケーションを 段階的にモダナイズする話 レッドハット株式会社 森 和哉 1 セッションID:17-E-7 ハッシュタグ:#devsumi
自己紹介 2 製造業にて工場の生産能力改善に長年携わり、 その後は基幹システム刷新プロジェクトに従事。 現在はレッドハットのソリューションアーキテクトとして、 主に業務ロジックを可視化するルールエンジンの導入 の提案などを担当。 レッドハット株式会社 スペシャリストソリューションアーキテクト 森 和哉(Kazuya
Mori)
アプリモダナイズへの関心度は非常に高い 3 大幅に増えた保守 コストを削減したい ブラックボックスを見え る化したい クラウドへの移行を可 能にしたい 他システムとの 連携を柔軟に
変更要求に迅速に 対応したい データ量や利用者の 増加に柔軟に対応したい
しかし、立ちはだかる壁 4 密に結合したシステム、そ う簡単に分割できそうもな い 中身がブラックボックス 化。手のつけようが無い 気がする。 マイクロサービスだのコ ンテナだのスキルセット
が足りてない 巨大なシステムをどう やって移行していけば 良いの? 組織も文化もウォーターフォール開 発が前提になっており、 そう簡単に変えられない
昨年のデブサミ(2021/2)では・・・ 5 ブラックボックス化したレガシーシステムでも 迅速なモダナイズを可能にする開発手法 「ルール駆動開発」 をご紹介しました 解説マンガもありますの でぜひご覧下さい
2つの移行方式 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 ありがとう ございました