Modernize Legacy Batch System for Business Inovation

Transcript

1. V0000000 -バッチ版- ビジネス革新に向けた レガシーシステムの最新化

2. V0000000 ビジネスとITの関係 ビジネス データ収集 データ解析 ビジネス データ活用 ビジネス フィードバック

3. V0000000 良くある課題 ビジネス課題 IT課題 ビジネスから
 見たIT課題 すぐ開始できない ビジネスが止まるリスク コストが増加 開発期間が長い


   リリース時期が限定 
 修正範囲の見積りが困難 
 想定より伸びる開発期間 
 他システムとの調整 
 リリース体制構築が困難 一部の障害でも全体が停止 
 結果待ち時間の長時間化 
 単一障害点
 HA構成のスキルが不足 
 バッチ処理時間の長時間化 
 処理フローの再検討 
 構築・維持コスト増
 工数が予想より高い スケールアップのコスト 
 規模拡大で運用作業の増加 
 開発期間延長で工数が増加 
 環境依存の調査コスト 3

4. V0000000 モノリスなアプリとDBのよくある構成 DB AP バッチ システムA システムB システムC システムD W

   R バッチ W R W R API GW R/W バッチ R/W R/W R/W データ分析 データ収集 データ活用

5. V0000000 あるべき姿 ビジネスの
 あるべき姿 解決策 ビジネスをすぐ開始できる 安定してビジネスを稼働 ビジネスに比例のコスト 新機能をすぐリリース 


   ビジネスロジックに集中 
 環境を自動で構築 影響範囲を最小化
 可能な限りビジネスを継続 
 データ量増加に非依存 
 データ増でスケールアップ 
 データ減でスケールイン 
 適材適所のデータストア 
 サービスを疎結合化 
 リリースプロセスを改善 
 最適なフレームワーク 
 システムの自動構築化 障害の局所化
 クラスタ化
 システムの自動運用化 
 小規模からスケールアウト 
 動的にリソースを増減 
 RDBMSだけに頼らない 
 
 
 ITの
 あるべき姿 5

6. アジャイル、近代化、敏感な組織への転換 6 デジタル・リーダーになるチャンスをつかむ ITとビジネスの両方に 対応する新しい方法 協調文化 アジャイルプロセス 新しい協力方法と組織の構築 次世代アーキテクチャ システムとアプリケーションを

   開発、提供、統合する新しい方法

7. V0000000 モダナイズしてビジネスアジリティを向上 DB/KVS コンシューマ システムA システムB システムC システムD W R

   コンシューマ W R W R API GW R/W コンシューマ R/W R/W AP DB/KVS R/W AP ｷｭｰ R R/W R/W DB コンシューマ W W R/W ｷｭｰ コンシューマ コンシューマ データ収集 データ分析 データ活用

8. V0000000 マイクロサービスと 開発プロセス

9. V0000000 密で巨大なバッチを疎結合で小さな処理へ バッチ 処理１ 処理２ 処理３ これまでの方式 これからの方式 これまでの方法： •

   バッチの中に一連の複数の処理を含む。 • 一日分や一月分など一定期間分のデータをまとめて処理 • 1つのプロセスで処理する 課題： • データが貯まって処理されるまでビジネスは停止 • 処理したいデータを問い合せるため、 DBに高負荷 これからの方法： • バッチの中で行う処理を分割してコンシューマとして処理 ◦ バッチで中間データを生成する単位で分割すると良い • データは各処理で並行処理される メリット： • 処理するデータは取り出すだけなので、キューは低負荷 • 分割により処理とデータの流れが明確化しテストも容易 • ビジネス要望を直ぐ実現できるようになる ｷｭｰ ｷｭｰ コンシューマ （処理1） コンシューマ （処理2） コンシューマ（処 理3） 利益 リスク コスト

10. V0000000 ビジネスの速度を高めたい -時間を指定するのではなくニアリアルタイムへ- ｷｭｰ ｷｭｰ これまでの方法： • バッチの結果をファイルや DB経由で次のバッチへ連携 •

    スケジューラがバッチの順序を管理 • ある処理量が一定時間で終わるように最大性能で環境を構築 課題： • 処理されて次のバッチに処理されるまでビジネスは停止 • 処理完了するまで次の処理は進まず、失敗すると停止 • バッチ間の開始時間と終了時間の調整が必要 ｷｭｰ バッチ１の範囲 これまでの方式 これからの方式 ファイル・DB 連係 バッチ１ バッチ２ これからの方法： • 前の処理からデータが来たら直ぐに処理される メリット： • リアルタイムにビジネスが進む • データは流れるので開始時間の調整は不要 • 障害時は他の支流は処理が行われる • 処理が間に合う分の性能で環境を構築 バッチ２の範囲 リアルタイム 連携 コンシューマ コンシューマ コンシューマ コンシューマ 利益 リスク コスト

11. V0000000 新しい機能をすぐにリリース 処 理４ これまでの方式 これからの方式 これまでの方法： • 既存の実装を考慮して開発 •

    更新したい処理だけではなく全体の処理を考慮して開発 • 1つのプロセスで処理する 課題： • 業務変更の影響範囲が広く見積り・開発が困難 • アプリ停止時にシステム全体が止まる これからの方法： • キューから読み込む新たな処理を追加する • 入力のデータ構造だけを考慮して開発 メリット： • 必要なデータを持つキューから読むだけなので他に無影響 • 業務変更の影響範囲を限定でき見積もりやすく開発し易い • ある処理の障害時に他の処理は稼働できる • 処理ごとにスケールできるためリソースの使用効率が高い バッチ 処理１ 処理２ 処理３ ｷｭｰ ｷｭｰ コンシューマ （処理1） コンシューマ （処理2） コンシューマ（処 理3） コンシューマ （処理4） 利益 リスク コスト

12. V0000000 データストア

13. V0000000 データストアを分割 DB AP R/W 購買情報 在庫情報 在庫DB AP R/W

    購買情報 購買DB ｷｭｰ コンシューマ コンシューマ R/W 在庫情報 これまでの方式 これからの方式 これまでの方法： • 全てのデータを1つのDBへ格納 課題： • DBが集中的に負荷上昇 これからの方法： • サービス毎に格納先を分ける（マイクロサービス化） メリット： • 負荷を分散 • 他のサービスの影響を受けない • ビジネス要望を直ぐ実現できるようになる • 小さな範囲でスケールアップができる 利益 リスク コスト

14. V0000000 リレーショナルが不要なデータは別の形式で格納 R/W リレーショナルな情報 非リレーショナルな情報 KVS AP R/W 非リレーショナルな情報 DB

    SDS R/W リレーショナルな情報 これまでの方式 これからの方式 これまでの方法： • データ形式問わず全てを DBへ格納 課題： • 無駄なデータ変換処理が発生 • データベースに負荷が偏る • データベースのスケールアップには限界がある これからの方法： • データ形式に合わせてデータストアを選択 ◦ Key-ValueはKVSへ ◦ JSONなどドキュメントはSDSやドキュメントDBへ メリット： • 適切なデータストアで無駄な処理を削減 • データベースの負荷をオフロードできる DB AP リスク コスト

15. V0000000 システムの都合上必要なデータは保存しない R/W 処理に必要な情報 Write 処理を引き継ぐ情報 R/W 処理に必要な情報 Read 処理を引き継ぐ情報

    処理を引き継ぐ情報 処理に必要な情報 処理に必要な情報 これまでの方式 これからの方式 これまでの方法： • 全てのデータを1つのDBへ格納する • 処理に必要な情報の受け渡しも DB 経由 課題： • 負荷が上昇 これからの方法： • 処理の引き継ぎはキューで行う • マスタデータや最終処理の結果は DBへ読み書きする • 途中結果や他の処理へ引き継ぐ情報はキューへ読み書きする メリット： • DBの負荷が低減 • 無駄なデータの流れが減る • データの生成に対して直ぐに次の処理が行え機敏性が増す AP AP ｷｭｰ コンシューマ DB バッチ DB リスク コスト 利益

16. V0000000 トランザクションではなく取り消し処理 トランザクション開始 更新処理 ロールバック 更新処理 取り消し処理 これまでの方式 これからの方式 これまでの方法：

    • 失敗時は全てをロールバックして元へ戻す • 正常に終わった処理も戻される 課題： • 一部処理の問題が処理全体に影響を及ぼす これからの方法： • 失敗した処理は取り消し処理を実行 メリット： • 正常終了した処理はそのまま処理を継続 • トランザクションに必要なリソースが減る • データが直ぐに反映されるようになる DB AP AP ｷｭｰ コンシューマ 利益 リスク コスト

17. V0000000 リソース不足時に動的にリソースを追加 バッチ バッチ これまでの方式 これからの方式 これまでの方法： • インスタンスサイズを大きくする •

    スケールアップのアプローチ • オンプレでは別のHWを用意 課題： • クラウドでは2倍・4倍・8倍となる • コストが非常に高い これからの方法： • 不足分だけインスタンス数を追加 • スケールアウトのアプローチ • 小さいインスタンスを並べる メリット： • コストの増加は微増 ｷｭｰ ｷｭｰ コンシューマ （処理1） コンシューマ （処理2） コンシューマ（処 理3） コスト

18. V0000000 リソースの有効活用 これまでの方式 これからの方式 これまでの方法： • 必要な最大処理量に合わせてサーバを構成 課題： • 1つだけサーバが稼働し遊休リソースが多い

    ◦ バッチが処理中はDBは負荷がない ◦ DBが処理中はバッチが負荷がない これからの方法： • 1日に行う処理量に合わせてサーバを構成 メリット： • 小さい処理が並列に実行されるため遊休リソースは僅か ◦ バッチA1がSQL待ちの時にバッチA2はCPUを使える • 時間に間に合わなくなったらコンシューマを追加 DB バッチ DB AP AP コンシューマ リスク コスト

19. V0000000 オーケストレーション

20. V0000000 手動による構築から自動による構築へ これまでの方法： • H/W(or VM)上にアプリやミドルウェアを構築 • ツールを駆使し手動で環境を構築 課題： •

    可用性や拡張は事前に検討が必要で、後からの変更は困難 • 完全に同一な環境作成は困難 • 正しい構築には十分に高いスキルが必要 これまでの方式 これからの方式 これからの方法： • コンテナ上にアプリやデータストアを構築 • Operatorにより構築と運用を自動化 メリット： • 可用性や拡張の仕組みを含んだ構成が導入される • 完全に同一な環境を容易に構築可能 • 正しい構築には十分に高いスキルは不要 コンテナ・オーケストレーション オペレータ コンテナ コンテナ 導入・管理 アプリ DB キュー リスク コスト

21. V0000000 障害時には影響範囲を狭く、期間を短くする これまでの方式 これからの方式 これまでの方法： • 一部の処理による障害でもアプリ全体に及ぶ • バッチを手やスケジューラで再起動 •

    検知する仕組みを作り込む 課題： • なかなか検知ができない • 仕組みの構築に工数が掛かる • 正しい運用の方法を構築できない これからの方法： • オペレータとオーケストレーションによる構築・運用 メリット： • いくつかのコマンドだけで構築・運用できる • エキスパートによる導入・運用知識が適用される • 検知と再起動は自動で行われる コンテナ・オーケストレーション オペレータ 検知 起動し直し リスク

22. V0000000 Why Red Hat

23. APIs マイクロサービス コンテナ CI/CD ハイブリッド クラウド 最新のクラウドサービス、インフラストラクチャ、およびテクノロジーを 活用しながら、最新のアプリケーション開発フレームワークの採用を 支援する適切な製品とテクノロジーを選択する。 アプリケーション開発のための

    新しいパターンと手法の採用 23

24. アプリの構築と移行 アプリの統合と組立 ビジネスプロセスの 合理化と自動化 オンプレミス、クラウド、またはハイブリッド アーキテクチャ向けの従来型および クラウドネイティブのアプリケーションの 作成、実行、および保守 物理 仮想

    プライベート クラウド パブリック クラウド Red Hat Middleware 自分のペースで近代化と革新を実現 24

25. PROCESS AUTOMATION RUNTIMES INTEGRATION 最高クラスのランタイム、フレーム ワーク、言語; EAPとQuarkusを含 む 近代化・最適化への取り組み インメモリデータグリッドと

    標準ベースのエンタープライズメッ セージング SSO認証 パターンベースの統合エンジン コネクタとデータ形式の包括的な セット 外部および内部に分散されたAPI へのアクセスを管理および保護 ストリーミングおよび相互接続メッ セージング ビジネスアプリケーションを 作成および変更するための 一貫した開発モデル マイクロサービス・レベルでのプロ セスの自動化と意思決定 ビジネス・ユーザーおよび 開発者が自動化を実現するための 独自のプラットフォーム ルールおよびプロセス中心の アプリケーションの管理 Runtimes, Integration and Process Automation 25

26. RED HAT RUNTIMES の利点 26 柔軟性、移行性、オープン性、コスト効率に優れたアプリケーションを作成し、ビジネスの 成果と成功を維持する 適切なツールを 選択できる柔軟性 チーム間の

    コラボレーション アプリケーション開 発の効率化 革新による 効率性の向上 アプリケーションの 市場導入を短縮

27. RED HAT MIDDLEWARE & OPENSHIFTによる包括的な品ぞろえ 27 OpenSHIFTおよびKubernetesサービスとのネイティブ統合による開発の合理化 セルフサービ スによる提供 構築と導入の

    自動化 CI/CD パイプライン 一貫性のある 環境 構成管理 アプリログとメト リック

28. お客様との出会い 28

29. RED HAT RUNTIMES 現代の企業アプリケーション開発の基盤

30. マイクロサービスやサーバレスのような高度に分散したクラウドネイティブなアーキテクチャのための軽量な ランタイムとフレームワークを提供し、高速なデータアクセスのための分散インメモリキャッシュ、認証と承認のためのシング ルサインオン、既存と新規アプリケーション間の信頼性の高いデータ転送のための永続的な メッセージングを提供する。 • 最高の組み合わせのランタイム、フレームワーク、言語 • OpenShiftとKubernetesサービスのネイティブ統合 • 近代化・最適化への取り組み

    • ミドルウェア技術の確立(EAP) • インメモリデータグリッド • 標準ベースのエンタープライズ・メッセージング • SSO認証 30 サービスを起動 SSO CLOUD-NATIVE RUNTIMES

31. 簡素なTOMCAT JAVASCRIPT の順応性 SPRING アプリケーション リアクティブ・システム JAVA マイクロサービス エンタープライズJAVA ランタイムと言語の選択指針

    31

32. OpenJDKを使用してデスクトップ、 サーバ、およびクラウドでJavaを標準化 • 開発者のデスクトップ、データセン ター、およびクラウドで使用される Javaプラットフォームの違いを排除 • RHELおよびWindowsの本番 • ワークロードを完全にサポート

    • 革新のスピードに合わせた長いラ イフサイクル • Red HatはOpenJDKの主要な開 発者で貢献者 エンタープライズ全体で使用できるRed Hat Enterprise LinuxおよびWindows向 けJavaプラットフォームの無償かつオー プン・ソースの実装 32

33. メモリ内に分散されたデータで アプリケーションのパフォーマンスを向上 • コンテナ最適化、クラスタ対応、 • クロスデータセンター • オンプレミス、Web、クラウド、ビッグ データ、IoTアプリに理想的 •

    ほとんど手間をかけずにデータ駆動 型アプリのパフォーマンスを向上 • Java開発者向けの使い慣れたAPI • レガシーアプリの拡張が可能 アプリケーションデータ用の分散型 インメモリデータ管理システム。 複数のシステム間でデータを同期し、 データへの高速アクセスを実現。 33

34. Red Hat AMQでアプリケーションを疎結合 • 最新のアプリケーションに対応する、信 頼性と耐久性に優れたメッセージング バックボーン。 • 非同期メッセージングは分散マイクロ サービスにとって素晴らしいソリューショ

    ンです。 • 複数の標準プロトコルのサポート。 • Spring Apps用のRabbitMQの代替とし て完全にサポートされる。 • IoTアプリケーションで特に有用(Red Hat IoTアーキテクチャとの互換性) エンタープライズ、クラウド、 IoT向けの柔軟な標準ベースの メッセージング。 34

35. Enhance Security By Leaving Credential Management To The Experts •

    認証と承認に関する最新のセキュリ ティ標準をサポート • Red Hat ランタイム用アダプタ • OpenShift用に最適化 • 既存の記録のシステム(SoR)との • 統合(LDAP、ADなど) • データ・グリッドとの統合により、デー タ・センター間のセキュリティを確保 • 統合およびプロセス自動化プロジェ クトを確実にするための基盤 安全なWebアプリケーションと、SAML 2.0、OpenID Connect、OAuth 2.0など の一般的な標準に基づく シングル・サインオン機能を提供。 SSO 35

36. RED HATと共に既存のアプリケーションをクラ ウドへ移行する • レガシーアプリケーションを現代の 世界に移行するための制御された 方法 • 移行プロジェクト開始前のROI予測 •

    アプリケーションサーバ、統合プラッ トフォーム、クラウド対応など、様々 なソースおよびターゲットプラット フォームをサポート • 広範なアプリケーション状況の視覚 化と移行の見積り 独自仕様または旧式のミドルウェア プラットフォームから、最先端の軽量、モ ジュール式、クラウド対応 ミドルウェアアプリケーション インフラストラクチャへの移行。 36

37. https://www.youtube.com/watch?v=LymzLHRbQdk 運用自動化が必須のクラウドネイティブ 従来型の運用体制のままでは、結局コンテナ化したところでリソース把握や管理に追われる コンテナやKubernetesの運用を個別に対応する時代は終焉 IT Operation (Manual) Kubernetes運用に必要な作業 コンテナやクラスタシステムを管理するには、 管理者の負担が大きくなりがち

    ・異常を継続的にチェック ・人による障害復旧オペレーション ・手動のコンテナ変更作業 ・アプリケーションごとの設定管理 ・ビジネス変化に応じた適切なリソース調整

38. ステートフルなアプリケーション運用 ステートフルな運用には、管理者によって手動オペレーションが必要だった Container Operations on Multi Cloud 正常稼働 障害検知 状態確認

    復旧作業 正常確認 正常稼働 障害検知 動的復旧 Container Orchestration 不具合修正 or 再構築 正常確認 自己修復 (Self-Healing) 個別対応 (Customize) ステートフル
 Stateful Application ステートレス
 Stateless Application これまでステートフルなアプリケーションのコンテナ化は避けられていた


39. What’s Operator An Operator is a method of packaging, deploying

    and managing a Kubernetes application Container Operations on Multi Cloud Kubernetes Applications 運用の知見をコード化し、アプリケーションの運用を自動化する アプリ運用における運用の知見をコード化し、パッ ケージ化したもの。 アプリケーション運用に必要な以下のような 作業を自動的に行う。 ・インストール ・リソーススケーリング ・バックアップ ・アップデート 運用の知見をコード化

40. Operatorの仕組み Observation, Analysis, Actionの役割をコード化する What’s Operator Observation プロセスの観察 Analysis プロセス状態の判断

    Action プロセス復旧作業 Observation アプリケーションの現在の状態を判断する。 (例) Application Cluster is running 2 Processes - application-0001 - application-0002 Analysis アプリケーションの現在の状態とアプリケーションの予想される状態を比 較する。 (例) Differences from desired config - 3Processes should be running instead of 2 Action アプリケーションの実行状態を期待状態に一致させるための処理を実行 します。 (例) How to get desired config - Start new Process - Add new node to the existing cluster - Trigger data rebalancing etc

41. OpenShift対応Operatorの提供(予定) Upstream Project (operatorhub.io) Product (OperatorHub on OpenShift) runtimes integration

    other Q4 Q1 CY2019 DELIVERED CY2020 BROKER (phase II) 8 Halkyon BROKER runtimes integration automation other 7 Interconnect Streams https://www.openshift.com/learn/topics/operators

42. RED HAT MIDDLEWARE の付加価値 42 独自のペースでの 革新、最適化、およ び近代化 柔軟性 より迅速な開発を

    促進する共同作業 のためのツールと 手法 協調 より迅速な開発を促進 する共同作業のため のツールと手法 最適された統合 ポートフォリオ全体の機 能と再利用機能を活用し てスピードアップ 市場への投入時間 革新と競争力の維 持により多くの時間 を費やす 生産性

43. RED HAT MIDDLEWARE の付加価値 43 数字による Source: (1) https://www.redhat.com/en/resources/business-value-jboss-eap-idc-whitepaper (2)

    https://www.redhat.com/en/resources/value-red-hat-integration-products (3) https://www.redhat.com/cms/managed-files/mi-business-value-process-automation-idc-analyst-paper-f14406bf-201810-en.pdf 481% 520% 556% Red Hat Integration2の 3年間の ROI JBoss EAP1の 3年間の ROI Red Hat Process Automation3の 3年間の ROI

44. 44 Source: 1 https://www.developerweek.com/awards/ 2 https://quarkus.io/blog/quarkus-wins-devies-award/ 3 https://stevieawards.com/aba/product-management-new-product-awards#BusinessTechnology 2020 Stevie

    Bronze award for Best Software Development Solution for Quarkus3 202 Best Innovation In Code Frameworks/Libraries for Quarkus2 2019 Best Innovation for Node.js1 RED HAT MIDDLEWARE の付加価値 表彰

45. V0000000 まとめ

46. V0000000 技術を駆使することでビジネス課題を解決 ビジネス課題 • 新しいビジネスをなかなか始められず利益が得られない • ビジネスが止まってしまうリスク • ビジネスに必要なITコストの増加 IT課題

    • 新しい機能の実装箇所が不明瞭で開発に長い期間がかかる。 • 新機能をリリースできるタイミングが限られている。 • 一部分の障害時にその影響がシステム全体に及ぶことがある。 • バッチの実行時間が延び、実行順序の整合性が保てないことがある。 • システムの初期構築や維持管理に多大なコストがかかる。 • システムの開発に必要な工数が予測より高くなっていく。 ITのあるべき姿 • 新しいビジネスをすぐに始められる • システムの停止時間を限りなく短くし、安定してビジネスを稼働 • ビジネス規模に比例し、なだらかなコスト増加 解決策 • 役割ごとにマイクロサービス化と開発プロセスを見直す • データストアを使い分けオフロードとスケールアウトを実現する • オーケストレーションの導入する 解決技術 • マイクロサービス • DevOps • オーケストレーション • ミドルウェア • クラスタ • クラウド • オペレータ

47. V0000000 Red Hatとビジネスのアジリティを高めましょう DB/KVS コンシューマ システムA システムB システムC システムD W

    R コンシューマ W R W R API GW R/W コンシューマ R/W R/W AP DB/KVS R/W AP ｷｭｰ R R/W R/W DB コンシューマ W W R/W ｷｭｰ コンシューマ コンシューマ データ収集 データ分析 データ活用

48. THANK YOU plus.google.com/+RedHat linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHatNews