V0000000 レッドハット株式会社 テクニカルセールス部 オンプレモノリスからの モダナイゼーション

V0000000 近代化： モダナイゼーション これまでの方式 これからの方式 アプリは変えず可用性と 性能効率を高めたい アプリは変えず敏捷性を高めた い 開発の負荷を下げたい ビジネスの敏捷性を高めたい ビジネスの速度を高めたい 運用の負荷を下げたい オンプレ 運用 バッチ アプリ オンプレモノリスからのモダナイゼーション

V0000000 これからの方式 アクション アプリは変えず可用性と性能効率を高めたい EAP から Runtimes へ移行（同価格） アプリは変えず敏捷性を高めたい EAP と OpenShift を導入 ビジネスの敏捷性を高めたい EAP から Runtimes へ移行（同価格） ビジネスの速度を高めたい Integration を導入 運用の負荷を下げたい Middleware (個別も可) と OpenShift を導入 開発の負荷を下げたい OpenShift を導入 モダナイゼーションの例

V0000000 アプリは変えず可用性と性能効率を高めたい -セッション情報の可用性を高める- これまでの方式 これからの方式 これまでの方法： ● セッション情報はアプリのメモリ上にある 課題： ● アプリが停止するとセッション情報は消える ● ユーザ増によりセッション情報が増えメモリを逼迫する ● メモリを逼迫すると性能低下や停止する可能性がある ● アプリのスケールアウトをしても可用性は向上できない ● ノード数は処理量かセッション情報量の大きい方にあわせる これからの方法： ● セッション情報はデータグリッドに冗長化されて格納 メリット： ● アプリが停止してもセッション情報を維持 ● ユーザが増えたらデータグリッドを増やして格納量を増強 ● アプリはステートレスになるためスケールアウトが容易 ● データグリッドのノード間で複製を持つため高い耐障害性 ● アプリがセッション情報のキャッシュを持つため性能も担保 ● アプリのノード数は処理量にあわせる リスク コスト データグリッド データグリッド データグリッド データグリッド セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 EAP 4 プロセス、Red Hat Data Grid 4 プロセス EAP 4 プロセス アプリ アプリ アプリ アプリ アプリ アプリ アプリ アプリ サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ

V0000000 アプリは変えず敏捷性を高めたい -Fastモノリス化とCI/CDを導入- これまでの方式 これからの方式 これまでの方法： ● 全ての変更機能を一度に開発・試験・リリース ● 事前に見積もられたオンプレ環境でアプリを試験・稼働 課題： ● 機能を一括でリリースするためバグ発生時に切り分けが困難 ● 検証や試験で環境を手配する調整が必要 ● リリース時に本番環境を止める必要がある これからの方法： ● 変更機能ごとに開発・試験・リリース ● コンテナ環境で試験・稼働 メリット： ● ビジネス要望を直ぐ実現できるようになる ● バグ発生時に原因となる変更範囲が狭く、切り分けが容易 ● 必要な時に必要な分だけコンテナ環境を自動構築 ● リリース時に旧環境を残したまま新環境へ切り替えられる 本番環境 開発 コンテナ・オーケストレーション 本番環境a ・・・ 本番環境b 試験環境 A 試験環境Z 試験環境 結合試験 総合試験 リリース 開発 CI CD 開発 CI CD デプロイ・試験 デプロイ デプロイ リスク コスト 利益

V0000000 ビジネスの敏捷性を高めたい -変更要求の多い業務を切り出す- 業務A 業務B 業務C これまでの方式 これからの方式 これまでの方法： ● 全ての業務を 1 つのアプリに実装 ● アプリを 1 つだけ動かす 課題： ● 業務変更の影響範囲が広く見積り・開発が困難 ● アプリ停止時にシステム全体が止まる ● スケールすると不要な業務のリソースも消費してしまう これからの方法： ● ビジネス要求の頻度毎に業務を切り出して稼働する メリット： ● ビジネス要望を直ぐ実現できるようになる ● 業務変更の影響範囲を限定でき見積もりやすく開発し易い ● アプリの障害時に他のアプリは稼働できる ● アプリごとにスケールできるためリソースの使用効率が高い アプリ 業務A 業務B 業務C A, Bより変更要 求が多い リスク コスト 利益

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

V0000000 運用の負荷を下げたい -可視化によるリスク低減- これまでの方式 これからの方式 これまでの方法： ● アプリの監視項目を自前で開発して監視 ● ミドルウェアの監視項目を必要な項目だけ選定して監視 ● ログを溜めてエラーメッセージだけを監視 課題： ● 事前に想定した問題のみに対処し、他の問題は対処できない ● 設計者のスキルレベルによって監視のレベルが決まる ● 全てを監視してないためシステム全体の傾向監視ができない これからの方法： ● アプリやミドルウェアの監視項目は自動で公開 ● モニタツールは自動で構築 ● モニタツールが監視項目を自動で収集 ● ログの傾向の変化を監視 メリット： ● 欲しい時に欲しい情報が取れ、様々な問題に対応可能 ● システム全体の傾向監視ができる ● 作り込みの必要はほとんど無い APサーバ、 アプリの情報 可視化 ログ出力 リスク コスト

V0000000 開発の負荷を下げたい -開発環境のコンテナ化- これまでの方式 これからの方式 これまでの方法： ● 長時間を掛けてPCに開発環境を構築 ● 様々なソフトウェアを同時に稼働させる 課題： ● サーバやIDEなどによる開発用PCのリソース逼迫 ● 有識者が物理的に近い距離にいないと相談できない これからの方法： ● IDE、サーバ、DBなどのコンテナを構築 ● 開発者はコンテナを起動するのみ ● ブラウザで IDE や各種サーバへアクセス メリット： ● 環境の準備に時間が掛からない ● 開発用PCはブラウザだけがあれば良い ● 有識者へ URL を伝えると環境を共有できる IDE サーバ DB コンテナ・オーケストレーション IDE サーバ DB IDE サーバ DB IDE アクセス リスク コスト

V0000000 linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you