Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション

レッドハット株式会社 
シニアソリューションアーキテクト　松田　絵里奈 
Cloud Nativeを見据えた 
アプリケーションアーキテクチャと 
レガシーモダナイゼーション 
1

Copyright 2020 Red Hat K.K.2
本セッションでお話すること 
レガシーアプリケーションを 
クラウドネイティブなアプリケーションに移行する際の 
重要なポイントとおすすめの移行方法

Copyright 2020 Red Hat K.K.
クラウドネイティブ・アプリケーションとは 
3
● 疎結合された小型の独立したサービスの集合 
● アプリケーション構築とアップデートを迅速化し、ビジネスニーズに素早く対応可能 
素早くデプロイシンプルなコード
スケーラブル迅速なアプリケーション開発

立ちはだかる壁 
● モノリシックなアプリケーションをどう分割するか？ 
● 長きにわたるメンテナンスによりコードがスパゲティ状態 
● ドキュメント未整備のためブラックボックス化 
● ウォーターフォール開発から脱却しなければとは思うが、経験がない 
 
 
　　　　さて、どうする？

レガシーアプリモダナイズ上の検討事項 
● どのようなアーキテクチャにすべきか 
● 製品・ツールの選定 
● 開発方法・開発体制の変更 
● 移行方法の検討（画面、データ、ロジック） 
● 移行スケジュールの検討（移行単位、一括か逐次か等）

レガシーアプリモダナイズ上の検討事項 
● どのようなアーキテクチャにすべきか 
● 製品・ツールの選定 
● 開発方法・開発体制の変更 
● 移行方法の検討（画面、データ、ロジック） 
● 移行スケジュールの検討（移行単位、一括か逐次か等） 
 
本日の注目ポイント 
 
（残りは別の回にて）

7
“ルール駆動開発”のおすすめ

“ルール駆動開発”の３つの特長 
● ルール（ロジック）とデータアクセスを完全分割 
● 業務目線でルールを整理し、そのまま実装 
● 小さく作ってはテストを繰り返す、イテレーション開発

モノリシックなシステムの分割指針 
どのようなアーキテクチャにすべきか
9

マイクロサービス化とは言うけれど・・・ 
What is
MICROSERVICE？

画面
ロジック
フロー
データ
アプリケーション
連携
ロジックプロセス
データ
アクセス
他シス連
携
画面
データ
モノリシックで 
スパゲッティ 
画面・ロジック・プロセス・データアクセスという役割ごとにサービス化し、そ
れらをサービス連携するアーキテクチャにする 
画面・ロジック・プロセス・データを分離
することで 
 
✔ スパゲッティの解消 
✔ メンテナンス性の向上 
✔ Water Fallから繰返し開発方式へ 
✔ 開発生産性の向上 
✔ 分散環境に対応 
11
役割ごとにサービス化する

ロジックとデータアクセスの混在がスパゲティ化の原因 
ロジックとデータアクセスが混在する従来のプログラム例 
DB参照を繰り返しながら、ロ
ジックが走る。

デシジョンサービス 
データサービス 
13
ロジックはデシジョンサービスとして分離する 
ルール
連携サービス 
社員
給与
データ 
取得
ルール 
実行 
データ
格納 
チェック 
勤務時間計算 
休日深夜出勤 
 
• デシジョンサービスで必要な
データは、あらかじめDBに問
合せをしてデータを取得し、呼
び出し時に一括で渡す。 
 
• デシジョンサービスからはDBを
直接参照させない。 
 
画面
画面
申請
シフト
休日データ
結果

ルールエンジンを利用する 
ルール駆動開発に欠かせないツール
14

ルール駆動開発にはルールエンジンの利用が最適 
 
 
 
 
 
● BRMS(Business Rule Management System)、ルールベースAI 
● ロジック（ルール）をアプリケーションから分離し別管理 
● 複雑なロジックをシンプルに記述可能 
● 業務担当者にも理解可能な、直感的なルール実装が可能 
● ルールをすぐにRESTサービスとして実行できるサーバ機能を提供

Rete アルゴリズム (since 1974〜) がベース。 
ルール条件に一致するデータを高速で検索（パターンマッチング）し、一致したルールをアジェンダに登
録し、自動的に実行する。 
 
 
 
 
 
 
 
 
 
 
 
 
Red Hat Decision Managerのアルゴリズム 
ルールエンジン 
パターン 
マッチング
アジェンダ登録
ルール 
ルール 
ルール 
データ  データ 
データはJavaオブジェ
クトとして渡す
条件
　　○○ならば
アクション
　　△△する
実行

★デシジョンテーブルを利用したルール実装例
17
わかりやすいルール記述が可能 
If (member.getRank() == “C”
|| member.getRank)) == “D”
|| memer.getRank() == “E”) {
If (cart.getAmount() >= 3000) {
cart.setDiscountRate(0.05) ;
}
} Else If (member.getRank() == “A” ||
member.getRank() == “B”) { 
cart.setDiscountRate(0.08);
}
If (cart.getAmount() >= 100000 {
cart.setDiscountRate(0.1);
cart.setShippingFee(0); 
}
・・・ 
通常プログラミングの例
• わかりやすい！ 
• ルールが可視化！ 
• メンテナンスが容易！
※Red Hat Decision Managerの技術詳細は、以下のURLのトレーニング資料を参照ください。 
 
http://redhat.lookbookhq.com/rhdm_handson2019/

ロジックの移行を無駄なく迅速に行う
方法 
ロジックの移行方法と開発方法
18
？

現行コードの解析から始めるのはNG 
現行プログラムコードにありがちな罠 
▸ 継ぎ足し継ぎ足し、秘伝のタレ状態 
･その場しのぎの改修 
･リファクタリングされていない冗長なコード 
 
▸ 不要なゴミコードの山 
･不要かどうかはコードからは不明 
･ゴミの移行に時間とお金をかけることに 
40%
60%

知ってる人に聞くのが一番の近道 
• 知りたいことは業務用件＝業務ルール 
 
• １から１０まで聞く必要はない 
（そもそも知っている人はいない） 
 
• 誰でも知ってる基本的なルールから 
 
• 業務マニュアルや業務フロー図など、設計書とは別に業務
がわかる資料があることもある

キャンペーン割
引判定
カート情報
会員ランク
値引率判定
キャンペーン情報
受注金額計算
値引額算出
商品価格マスタ
手数料算出
請求金額算出
送料算出
判定ロジック
データ
21
ヒアリング内容をDMNで整理 
DMN(Decision Model and Notation)
業務ルールの国際記法
手数料マスタ
業務用語で書くこと！

キャンペーン割
引判定
カート情報
会員ランク
値引率判定
キャンペーン情報
受注金額計算
値引額算出
商品価格マスタ
手数料算出
請求金額算出
送料算出
22
一連の業務ルールを”サービス”として切り出す 
「請求金額算出」デシジョンサービス 
 
<インプット>
• 商品価格マスタ 
• カート情報 
• 会員ランク 
• キャンペーン情報 
 
<アウトプット>
• 請求金額（手数料、送料、値引額） 
 
途中の判定で必要になるデータは、あらかじめ
取得して渡すようにする

ルール詳細を実装していく 
ルールは「〇〇ならば、▲▲する」という条件とアクションのみを記述する。 
処理の順序やデータの並び替えなどは、基本的に記述の必要がないため、業務ルールにフォーカスしたシンプルかつわかりやすい実装が
可能になる。 
値引率判定
受注金額計算
送料算出

小さく作ってテストを繰り返しながらルールを育てていく 
 
 
誰でも知ってる基本ルールをまず
実装してテスト 
不一致箇所について、調査し
ルールを追加してテスト 
必要なルールがすべて揃った状
態 
まず根幹を形作る。そして本当に必要なルールだけを追加していく。

業務ルール 
業務ナレッジ  ルールの作成 
入力データ 
（過去の入力） 
期待値 
（過去の出力） 
実行結果 
テスト結果 
業務担当者 
テスト 
25
ルールのイテレーション開発 
デシジョンサービス単位で、新旧一致テストを繰り返し、ルールの精度を高速にあげていくテスト手法 
フィードバック

イテレーション開発の例 
要件把握 
新アーキテ
クチャ設計 
プロトタ
イプ実装
イテレーション開発
解析・要件定義設計・開発テスト
ウォーターフォール開発  
● 現行システムの概
要把握
● 現行業務の概要把
握
● 現行ソースの詳細
解析は行わない
● サービス分割した新アーキ
テクチャに落とし込む
● 一部機能について、プロトタ
イピングを実施。新アーキテ
クチャの実現可能性を確認
● 開発効率の測定
● 性能基礎値の測定
● 開発標準の策定　など
イテレーション開発 
● 数週間のスプリントで、各サービス単
位に開発/テスト/ユーザレビューを
繰り返しながら進めていく。
● 進むにつれて対象範囲を広げ、それ
ぞれのサービスを結合しながらテス
トとフィードバックを繰り返す

正しいルール駆動開発 
   
 
• システム担当と業務担当が協同で行う 
 
• 現行コードは見ない 
 
• 業務担当者が理解できる形式で実装 
 
• 幹となるルールから抽出 
 
• テストおよびユーザレビューを繰り返しながら
品質向上 
 
• システム担当だけで行う 
 
• 現行コードや設計書から読み解く 
 
• システム担当がコードで実装 
 
• 現行の全ての要件を最初に抽出 
 
• ユーザレビューはユーザテストの時まで行われな
い 
 
正しい間違い

項目名 Red Hat 製品名
アプリケーションロジック Red Hat Decision Manager
業務プロセスの進捗管理 Red Hat Process Automation Manager
分散環境におけるデータの管理 Red Hat A-MQ
システムの並行稼動
(データの分流・新旧データ突合)
Red Hat Fuse
Red Hat Decision Manager
サービス連携におけるトランザクション管理 Red Hat Fuse
API管理によるアクセス制御 Red Hat 3Scale API Management
Web Application Server Red Hat JBoss EAP
コンテナ化したアプリケーションのデプロイ・運用の簡素化 Red Hat OpenShift Container Platform
大量バッチ処理の高速化 Red Hat JBoss Data Grid
シングルサインオン環境 Red Hat Single Sign-On
技術支援 Global Professional Service
28
移行におけるRed Hat製品の役割例

Red Hat製品マッピング例 
連携
ロジック
プロセス
データ
アクセス
他シス連
携
画面
データ
Red Hat Fuse
Red Hat Decision
Manager
Red Hat Process
Automation Manager
Red Hat A-MQ
Red Hat Data Grid
Red Hat OpenShift Container Platform

まとめ 
レガシーアプリのモダナイズには“ルール駆動開発” 
● データアクセスとルールを完全分離。改修コストが下がり、ビジネスアジリティが向上。スケーラブルでクラウ
ドネイティブなアーキテクチャに。 
● 現行コードからではなく業務ルールからのアプローチで、無駄を省いたロジックの移行が可能 
● ルールエンジンの利用により、複雑なロジックがシンプル化。 
● 実装→テストを繰り返す開発により、ソフトウェアの品質向上。

Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション

Similar a Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション (20)

Cloud Nativeを見据えたアプリケーションアーキテクチャとレガシーモダナイゼーション