Más contenido relacionado

Presentaciones para ti(20)

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

Último(20)

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

  1. レッドハット株式会社
 シニアソリューションアーキテクト 松田 絵里奈
 Cloud Nativeを見据えた
 アプリケーションアーキテクチャと
 レガシーモダナイゼーション
 1
  2. Copyright 2020 Red Hat K.K.2 本セッションでお話すること
 レガシーアプリケーションを
 クラウドネイティブなアプリケーションに移行する際の
 重要なポイントとおすすめの移行方法

  3. Copyright 2020 Red Hat K.K. クラウドネイティブ・アプリケーションとは
 3 ● 疎結合された小型の独立したサービスの集合
 ● アプリケーション構築とアップデートを迅速化し、ビジネスニーズに素早く対応可能
 素早くデプロイ シンプルなコード スケーラブル迅速なアプリケーション開発
  4. Copyright 2020 Red Hat K.K.4 立ちはだかる壁
 ● モノリシックなアプリケーションをどう分割するか?
 ● 長きにわたるメンテナンスによりコードがスパゲティ状態
 ● ドキュメント未整備のためブラックボックス化
 ● ウォーターフォール開発から脱却しなければとは思うが、経験がない
 
 
     さて、どうする?

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

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

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

  9. モノリシックなシステムの分割指針
 どのようなアーキテクチャにすべきか 9
  10. Copyright 2020 Red Hat K.K.10 マイクロサービス化とは言うけれど・・・
 What is MICROSERVICE?
  11. Copyright 2020 Red Hat K.K. 画面 ロジック フロー データ アプリケーション 連携 ロジック プロセス データ アクセス 他シス連 携 画面 データ モノリシックで
 スパゲッティ
 画面・ロジック・プロセス・データアクセスという役割ごとにサービス化し、そ れらをサービス連携するアーキテクチャにする
 画面・ロジック・プロセス・データを分離 することで
 
 ✔ スパゲッティの解消
 ✔ メンテナンス性の向上
 ✔ Water Fallから繰返し開発方式へ
 ✔ 開発生産性の向上
 ✔ 分散環境に対応
 11 役割ごとにサービス化する

  12. Copyright 2020 Red Hat K.K.12 ロジックとデータアクセスの混在がスパゲティ化の原因
 ロジックとデータアクセスが混在する従来のプログラム例
 DB参照を繰り返しながら、ロ ジックが走る。
  13. Copyright 2020 Red Hat K.K. デシジョンサービス
 データサービス
 13 ロジックはデシジョンサービスとして分離する
 ルール 連携サービス
 社員 給与 データ
 取得 ルール
 実行
 データ 格納
 チェック
 勤務時間計算
 休日深夜出勤
 
 • デシジョンサービスで必要な データは、あらかじめDBに問 合せをしてデータを取得し、呼 び出し時に一括で渡す。
 
 • デシジョンサービスからはDBを 直接参照させない。
 
 画面 画面 申請 シフト 休日データ 結果
  14. ルールエンジンを利用する
 ルール駆動開発に欠かせないツール 14
  15. Copyright 2020 Red Hat K.K.15 ルール駆動開発にはルールエンジンの利用が最適
 
 
 
 
 
 ● BRMS(Business Rule Management System)、ルールベースAI
 ● ロジック(ルール)をアプリケーションから分離し別管理
 ● 複雑なロジックをシンプルに記述可能
 ● 業務担当者にも理解可能な、直感的なルール実装が可能
 ● ルールをすぐにRESTサービスとして実行できるサーバ機能を提供

  16. Copyright 2020 Red Hat K.K.16 Rete アルゴリズム (since 1974〜) がベース。
 ルール条件に一致するデータを高速で検索(パターンマッチング)し、一致したルールをアジェンダに登 録し、自動的に実行する。
 
 
 
 
 
 
 
 
 
 
 
 
 Red Hat Decision Managerのアルゴリズム
 ルールエンジン
 パターン
 マッチング アジェンダ登録 ルール
 ルール
 ルール
 データ
 データ
 データ
 データ
 データ
 データ
 データはJavaオブジェ クトとして渡す 条件   ○○ならば アクション   △△する 実行
  17. Copyright 2020 Red Hat K.K. ★デシジョンテーブルを利用したルール実装例 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. ロジックの移行を無駄なく迅速に行う 方法
 ロジックの移行方法と開発方法 18 ?
  19. Copyright 2020 Red Hat K.K.19 現行コードの解析から始めるのはNG
 現行プログラムコードにありがちな罠
 ▸ 継ぎ足し継ぎ足し、秘伝のタレ状態
 ・ その場しのぎの改修
 ・ リファクタリングされていない冗長なコード
 
 ▸ 不要なゴミコードの山
 ・ 不要かどうかはコードからは不明
 ・ ゴミの移行に時間とお金をかけることに
 40% 60%
  20. Copyright 2020 Red Hat K.K.20 知ってる人に聞くのが一番の近道
 • 知りたいことは業務用件=業務ルール
 
 • 1から10まで聞く必要はない
 (そもそも知っている人はいない)
 
 • 誰でも知ってる基本的なルールから
 
 • 業務マニュアルや業務フロー図など、設計書とは別に業務 がわかる資料があることもある

  21. Copyright 2020 Red Hat K.K. キャンペーン割 引判定 カート情報 会員ランク 値引率判定 キャンペーン情報 受注金額計算 値引額算出 商品価格マスタ 手数料算出 請求金額算出 送料算出 判定ロジック データ 21 ヒアリング内容をDMNで整理
 DMN(Decision Model and Notation) 業務ルールの国際記法 手数料マスタ 業務用語で書くこと!
  22. Copyright 2020 Red Hat K.K. キャンペーン割 引判定 カート情報 会員ランク 値引率判定 キャンペーン情報 受注金額計算 値引額算出 商品価格マスタ 手数料算出 請求金額算出 送料算出 22 一連の業務ルールを”サービス”として切り出す
 「請求金額算出」デシジョンサービス
 
 <インプット> • 商品価格マスタ
 • カート情報
 • 会員ランク
 • キャンペーン情報
 
 <アウトプット> • 請求金額(手数料、送料、値引額)
 
 途中の判定で必要になるデータは、あらかじめ 取得して渡すようにする
  23. Copyright 2020 Red Hat K.K.23 ルール詳細を実装していく
 ルールは「〇〇ならば、▲▲する」という条件とアクションのみを記述する。
 処理の順序やデータの並び替えなどは、基本的に記述の必要がないため、業務ルールにフォーカスしたシンプルかつわかりやすい実装が 可能になる。
 値引率判定 受注金額計算 送料算出
  24. Copyright 2020 Red Hat K.K.24 小さく作ってテストを繰り返しながらルールを育てていく
 
 
 誰でも知ってる基本ルールをまず 実装してテスト
 不一致箇所について、調査し ルールを追加してテスト
 必要なルールがすべて揃った状 態
 まず根幹を形作る。そして本当に必要なルールだけを追加していく。
  25. Copyright 2020 Red Hat K.K. 業務ルール
 業務ナレッジ
 ルールの作成
 入力データ
 (過去の入力)
 期待値
 (過去の出力)
 実行結果
 テスト結果
 業務担当者
 テスト
 25 ルールのイテレーション開発
 デシジョンサービス単位で、新旧一致テストを繰り返し、ルールの精度を高速にあげていくテスト手法
 フィードバック
  26. Copyright 2020 Red Hat K.K.26 イテレーション開発の例
 要件把握
 新アーキテ クチャ設計
 プロトタ イプ実装 イテレーション開発 解析・要件定義 設計・開発 テスト ウォーターフォール開発 
 ● 現行システムの概 要把握 ● 現行業務の概要把 握 ● 現行ソースの詳細 解析は行わない ● サービス分割した新アーキ テクチャに落とし込む ● 一部機能について、プロトタ イピングを実施。新アーキテ クチャの実現可能性を確認 ● 開発効率の測定 ● 性能基礎値の測定 ● 開発標準の策定 など イテレーション開発
 ● 数週間のスプリントで、各サービス単 位に開発/テスト/ユーザレビューを 繰り返しながら進めていく。 ● 進むにつれて対象範囲を広げ、それ ぞれのサービスを結合しながらテス トとフィードバックを繰り返す
  27. Copyright 2020 Red Hat K.K.27 正しいルール駆動開発
 
 
 
 • システム担当と業務担当が協同で行う
 
 • 現行コードは見ない
 
 • 業務担当者が理解できる形式で実装
 
 • 幹となるルールから抽出
 
 • テストおよびユーザレビューを繰り返しながら 品質向上
 
 • システム担当だけで行う
 
 • 現行コードや設計書から読み解く
 
 • システム担当がコードで実装
 
 • 現行の全ての要件を最初に抽出
 
 • ユーザレビューはユーザテストの時まで行われな い
 
 正しい 間違い
  28. Copyright 2020 Red Hat K.K. 項目名 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製品の役割例

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