Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Modernize Legacy Batch System for Business Inovation

Chihiro Ito
November 24, 2020

Modernize Legacy Batch System for Business Inovation

Chihiro Ito

November 24, 2020
Tweet

More Decks by Chihiro Ito

Other Decks in Technology

Transcript

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

    View full-size slide

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

    View full-size slide

  3. V0000000
    良くある課題
    ビジネス課題
    IT課題
    ビジネスから

    見たIT課題
    すぐ開始できない ビジネスが止まるリスク コストが増加
    開発期間が長い

    リリース時期が限定 

    修正範囲の見積りが困難 

    想定より伸びる開発期間 

    他システムとの調整 

    リリース体制構築が困難
    一部の障害でも全体が停止 

    結果待ち時間の長時間化 

    単一障害点

    HA構成のスキルが不足 

    バッチ処理時間の長時間化 

    処理フローの再検討 

    構築・維持コスト増

    工数が予想より高い
    スケールアップのコスト 

    規模拡大で運用作業の増加 

    開発期間延長で工数が増加 

    環境依存の調査コスト
    3

    View full-size slide

  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
    データ分析
    データ収集
    データ活用

    View full-size slide

  5. V0000000
    あるべき姿
    ビジネスの

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

    ビジネスロジックに集中 

    環境を自動で構築
    影響範囲を最小化

    可能な限りビジネスを継続 

    データ量増加に非依存 

    データ増でスケールアップ 

    データ減でスケールイン 

    適材適所のデータストア 

    サービスを疎結合化 

    リリースプロセスを改善 

    最適なフレームワーク 

    システムの自動構築化
    障害の局所化

    クラスタ化

    システムの自動運用化 

    小規模からスケールアウト 

    動的にリソースを増減 

    RDBMSだけに頼らない 



    ITの

    あるべき姿
    5

    View full-size slide

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

    View full-size slide

  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
    キュー
    コンシューマ
    コンシューマ
    データ収集
    データ分析 データ活用

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  10. V0000000
    ビジネスの速度を高めたい
    -時間を指定するのではなくニアリアルタイムへ-
    キュー
    キュー
    これまでの方法:
    ● バッチの結果をファイルや
    DB経由で次のバッチへ連携
    ● スケジューラがバッチの順序を管理
    ● ある処理量が一定時間で終わるように最大性能で環境を構築
    課題:
    ● 処理されて次のバッチに処理されるまでビジネスは停止
    ● 処理完了するまで次の処理は進まず、失敗すると停止
    ● バッチ間の開始時間と終了時間の調整が必要
    キュー
    バッチ1の範囲
    これまでの方式 これからの方式
    ファイル・DB
    連係
    バッチ1 バッチ2
    これからの方法:
    ● 前の処理からデータが来たら直ぐに処理される
    メリット:
    ● リアルタイムにビジネスが進む
    ● データは流れるので開始時間の調整は不要
    ● 障害時は他の支流は処理が行われる
    ● 処理が間に合う分の性能で環境を構築
    バッチ2の範囲
    リアルタイム
    連携
    コンシューマ
    コンシューマ
    コンシューマ
    コンシューマ
    利益 リスク コスト

    View full-size slide

  11. V0000000
    新しい機能をすぐにリリース

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

    View full-size slide

  12. V0000000
    データストア

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  17. V0000000
    リソース不足時に動的にリソースを追加
    バッチ
    バッチ
    これまでの方式 これからの方式
    これまでの方法:
    ● インスタンスサイズを大きくする
    ● スケールアップのアプローチ
    ● オンプレでは別のHWを用意
    課題:
    ● クラウドでは2倍・4倍・8倍となる
    ● コストが非常に高い
    これからの方法:
    ● 不足分だけインスタンス数を追加
    ● スケールアウトのアプローチ
    ● 小さいインスタンスを並べる
    メリット:
    ● コストの増加は微増
    キュー
    キュー
    コンシューマ
    (処理1)
    コンシューマ
    (処理2)
    コンシューマ(処
    理3)
    コスト

    View full-size slide

  18. V0000000
    リソースの有効活用
    これまでの方式 これからの方式
    これまでの方法:
    ● 必要な最大処理量に合わせてサーバを構成
    課題:
    ● 1つだけサーバが稼働し遊休リソースが多い
    ○ バッチが処理中はDBは負荷がない
    ○ DBが処理中はバッチが負荷がない
    これからの方法:
    ● 1日に行う処理量に合わせてサーバを構成
    メリット:
    ● 小さい処理が並列に実行されるため遊休リソースは僅か
    ○ バッチA1がSQL待ちの時にバッチA2はCPUを使える
    ● 時間に間に合わなくなったらコンシューマを追加
    DB
    バッチ DB
    AP
    AP
    コンシューマ
    リスク コスト

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  21. V0000000
    障害時には影響範囲を狭く、期間を短くする
    これまでの方式 これからの方式
    これまでの方法:
    ● 一部の処理による障害でもアプリ全体に及ぶ
    ● バッチを手やスケジューラで再起動
    ● 検知する仕組みを作り込む
    課題:
    ● なかなか検知ができない
    ● 仕組みの構築に工数が掛かる
    ● 正しい運用の方法を構築できない
    これからの方法:
    ● オペレータとオーケストレーションによる構築・運用
    メリット:
    ● いくつかのコマンドだけで構築・運用できる
    ● エキスパートによる導入・運用知識が適用される
    ● 検知と再起動は自動で行われる
    コンテナ・オーケストレーション
    オペレータ
    検知
    起動し直し
    リスク

    View full-size slide

  22. V0000000
    Why Red Hat

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  25. PROCESS
    AUTOMATION
    RUNTIMES INTEGRATION
    最高クラスのランタイム、フレーム
    ワーク、言語; EAPとQuarkusを含

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

    View full-size slide

  26. RED HAT RUNTIMES の利点
    26
    柔軟性、移行性、オープン性、コスト効率に優れたアプリケーションを作成し、ビジネスの
    成果と成功を維持する
    適切なツールを
    選択できる柔軟性
    チーム間の
    コラボレーション
    アプリケーション開
    発の効率化
    革新による
    効率性の向上
    アプリケーションの
    市場導入を短縮

    View full-size slide

  27. RED HAT MIDDLEWARE & OPENSHIFTによる包括的な品ぞろえ
    27
    OpenSHIFTおよびKubernetesサービスとのネイティブ統合による開発の合理化
    セルフサービ
    スによる提供
    構築と導入の
    自動化
    CI/CD
    パイプライン
    一貫性のある
    環境
    構成管理
    アプリログとメト
    リック

    View full-size slide

  28. お客様との出会い
    28

    View full-size slide

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

    View full-size slide

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

    View full-size slide

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

    View full-size slide

  32. OpenJDKを使用してデスクトップ、
    サーバ、およびクラウドでJavaを標準化
    • 開発者のデスクトップ、データセン
    ター、およびクラウドで使用される
    Javaプラットフォームの違いを排除
    • RHELおよびWindowsの本番
    • ワークロードを完全にサポート
    • 革新のスピードに合わせた長いラ
    イフサイクル
    • Red HatはOpenJDKの主要な開
    発者で貢献者
    エンタープライズ全体で使用できるRed
    Hat Enterprise LinuxおよびWindows向
    けJavaプラットフォームの無償かつオー
    プン・ソースの実装
    32

    View full-size slide

  33. メモリ内に分散されたデータで
    アプリケーションのパフォーマンスを向上
    • コンテナ最適化、クラスタ対応、
    • クロスデータセンター
    • オンプレミス、Web、クラウド、ビッグ
    データ、IoTアプリに理想的
    • ほとんど手間をかけずにデータ駆動
    型アプリのパフォーマンスを向上
    • Java開発者向けの使い慣れたAPI
    • レガシーアプリの拡張が可能
    アプリケーションデータ用の分散型
    インメモリデータ管理システム。
    複数のシステム間でデータを同期し、
    データへの高速アクセスを実現。
    33

    View full-size slide

  34. Red Hat AMQでアプリケーションを疎結合
    • 最新のアプリケーションに対応する、信
    頼性と耐久性に優れたメッセージング
    バックボーン。
    • 非同期メッセージングは分散マイクロ
    サービスにとって素晴らしいソリューショ
    ンです。
    • 複数の標準プロトコルのサポート。
    • Spring Apps用のRabbitMQの代替とし
    て完全にサポートされる。
    • IoTアプリケーションで特に有用(Red
    Hat IoTアーキテクチャとの互換性)
    エンタープライズ、クラウド、
    IoT向けの柔軟な標準ベースの
    メッセージング。
    34

    View full-size slide

  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

    View full-size slide

  36. RED HATと共に既存のアプリケーションをクラ
    ウドへ移行する
    • レガシーアプリケーションを現代の
    世界に移行するための制御された
    方法
    • 移行プロジェクト開始前のROI予測
    • アプリケーションサーバ、統合プラッ
    トフォーム、クラウド対応など、様々
    なソースおよびターゲットプラット
    フォームをサポート
    • 広範なアプリケーション状況の視覚
    化と移行の見積り
    独自仕様または旧式のミドルウェア
    プラットフォームから、最先端の軽量、モ
    ジュール式、クラウド対応
    ミドルウェアアプリケーション
    インフラストラクチャへの移行。
    36

    View full-size slide

  37. https://www.youtube.com/watch?v=LymzLHRbQdk
    運用自動化が必須のクラウドネイティブ
    従来型の運用体制のままでは、結局コンテナ化したところでリソース把握や管理に追われる
    コンテナやKubernetesの運用を個別に対応する時代は終焉
    IT Operation
    (Manual)
    Kubernetes運用に必要な作業
    コンテナやクラスタシステムを管理するには、
    管理者の負担が大きくなりがち
    ・異常を継続的にチェック
    ・人による障害復旧オペレーション
    ・手動のコンテナ変更作業
    ・アプリケーションごとの設定管理
    ・ビジネス変化に応じた適切なリソース調整

    View full-size slide

  38. ステートフルなアプリケーション運用
    ステートフルな運用には、管理者によって手動オペレーションが必要だった
    Container Operations on Multi Cloud
    正常稼働
    障害検知
    状態確認
    復旧作業
    正常確認
    正常稼働
    障害検知
    動的復旧
    Container
    Orchestration
    不具合修正
    or 再構築
    正常確認
    自己修復
    (Self-Healing)
    個別対応
    (Customize)
    ステートフル

    Stateful Application
    ステートレス

    Stateless Application
    これまでステートフルなアプリケーションのコンテナ化は避けられていた


    View full-size slide

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

    View full-size slide

  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

    View full-size slide

  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

    View full-size slide

  42. RED HAT MIDDLEWARE の付加価値
    42
    独自のペースでの
    革新、最適化、およ
    び近代化
    柔軟性
    より迅速な開発を
    促進する共同作業
    のためのツールと
    手法
    協調
    より迅速な開発を促進
    する共同作業のため
    のツールと手法
    最適された統合
    ポートフォリオ全体の機
    能と再利用機能を活用し
    てスピードアップ
    市場への投入時間
    革新と競争力の維
    持により多くの時間
    を費やす
    生産性

    View full-size slide

  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

    View full-size slide

  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 の付加価値
    表彰

    View full-size slide

  45. V0000000
    まとめ

    View full-size slide

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

    View full-size slide

  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
    キュー
    コンシューマ
    コンシューマ
    データ収集
    データ分析 データ活用

    View full-size slide

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

    View full-size slide