Modernize On Premis and Monolith Application Platform

Transcript

1. V0000000 レッドハット株式会社 テクニカルセールス部 オンプレモノリスからの モダナイゼーション
2. V0000000 近代化： モダナイゼーション これまでの方式 これからの方式 アプリは変えず可用性と 性能効率を高めたい アプリは変えず敏捷性を高めた い 開発の負荷を下げたい ビジネスの敏捷性を高めたい ビジネスの速度を高めたい 運用の負荷を下げたい オンプレ 運用 バッチ アプリ オンプレモノリスからのモダナイゼーション
3. V0000000 これからの方式 アクション アプリは変えず可用性と性能効率を高めたい EAP から Runtimes へ移行（同価格） アプリは変えず敏捷性を高めたい EAP と OpenShift を導入 ビジネスの敏捷性を高めたい EAP から Runtimes へ移行（同価格） ビジネスの速度を高めたい Integration を導入 運用の負荷を下げたい Middleware (個別も可) と OpenShift を導入 開発の負荷を下げたい OpenShift を導入 モダナイゼーションの例
4. V0000000 アプリは変えず可用性と性能効率を高めたい -セッション情報の可用性を高める- これまでの方式 これからの方式 これまでの方法： • セッション情報はアプリのメモリ上にある 課題： • アプリが停止するとセッション情報は消える • ユーザ増によりセッション情報が増えメモリを逼迫する • メモリを逼迫すると性能低下や停止する可能性がある • アプリのスケールアウトをしても可用性は向上できない • ノード数は処理量かセッション情報量の大きい方にあわせる これからの方法： • セッション情報はデータグリッドに冗長化されて格納 メリット： • アプリが停止してもセッション情報を維持 • ユーザが増えたらデータグリッドを増やして格納量を増強 • アプリはステートレスになるためスケールアウトが容易 • データグリッドのノード間で複製を持つため高い耐障害性 • アプリがセッション情報のキャッシュを持つため性能も担保 • アプリのノード数は処理量にあわせる リスク コスト データグリッド データグリッド データグリッド データグリッド セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 EAP 4 プロセス、Red Hat Data Grid 4 プロセス EAP 4 プロセス アプリ アプリ アプリ アプリ アプリ アプリ アプリ アプリ サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ
5. V0000000 アプリは変えず敏捷性を高めたい -Fastモノリス化とCI/CDを導入- これまでの方式 これからの方式 これまでの方法： • 全ての変更機能を一度に開発・試験・リリース • 事前に見積もられたオンプレ環境でアプリを試験・稼働 課題： • 機能を一括でリリースするためバグ発生時に切り分けが困難 • 検証や試験で環境を手配する調整が必要 • リリース時に本番環境を止める必要がある これからの方法： • 変更機能ごとに開発・試験・リリース • コンテナ環境で試験・稼働 メリット： • ビジネス要望を直ぐ実現できるようになる • バグ発生時に原因となる変更範囲が狭く、切り分けが容易 • 必要な時に必要な分だけコンテナ環境を自動構築 • リリース時に旧環境を残したまま新環境へ切り替えられる 本番環境 開発 コンテナ・オーケストレーション 本番環境a ・・・ 本番環境b 試験環境 A 試験環境Z 試験環境 結合試験 総合試験 リリース 開発 CI CD 開発 CI CD デプロイ・試験 デプロイ デプロイ リスク コスト 利益
6. V0000000 ビジネスの敏捷性を高めたい -変更要求の多い業務を切り出す- 業務A 業務B 業務C これまでの方式 これからの方式 これまでの方法： • 全ての業務を 1 つのアプリに実装 • アプリを 1 つだけ動かす 課題： • 業務変更の影響範囲が広く見積り・開発が困難 • アプリ停止時にシステム全体が止まる • スケールすると不要な業務のリソースも消費してしまう これからの方法： • ビジネス要求の頻度毎に業務を切り出して稼働する メリット： • ビジネス要望を直ぐ実現できるようになる • 業務変更の影響範囲を限定でき見積もりやすく開発し易い • アプリの障害時に他のアプリは稼働できる • アプリごとにスケールできるためリソースの使用効率が高い アプリ 業務A 業務B 業務C A, Bより変更要 求が多い リスク コスト 利益
7. V0000000 ビジネスの速度を高めたい -時間を指定するのではなくニアリアルタイムへ- ｷｭｰ ｷｭｰ これまでの方法： • バッチの結果をファイルや DB経由で次のバッチへ連携 • スケジューラがバッチの順序を管理 • ある処理量が一定時間で終わるように最大性能で環境を構築 課題： • 処理されて次のバッチに処理されるまでビジネスは停止 • 処理完了するまで次の処理は進まず、失敗すると停止 • バッチ間の開始時間と終了時間の調整が必要 ｷｭｰ バッチ１の範囲 これまでの方式 これからの方式 ファイル・DB 連携 バッチ１ バッチ２ これからの方法： • 前の処理からデータが来たら直ぐに処理される メリット： • リアルタイムにビジネスが進む • データは流れるので開始時間の調整は不要 • 障害時は他の支流は処理が行われる • 処理が間に合う分の性能で環境を構築 バッチ２の範囲 リアルタイム 連携 コンシューマ コンシューマ コンシューマ コンシューマ 利益 リスク コスト
8. V0000000 運用の負荷を下げたい -可視化によるリスク低減- これまでの方式 これからの方式 これまでの方法： • アプリの監視項目を自前で開発して監視 • ミドルウェアの監視項目を必要な項目だけ選定して監視 • ログを溜めてエラーメッセージだけを監視 課題： • 事前に想定した問題のみに対処し、他の問題は対処できない • 設計者のスキルレベルによって監視のレベルが決まる • 全てを監視してないためシステム全体の傾向監視ができない これからの方法： • アプリやミドルウェアの監視項目は自動で公開 • モニタツールは自動で構築 • モニタツールが監視項目を自動で収集 • ログの傾向の変化を監視 メリット： • 欲しい時に欲しい情報が取れ、様々な問題に対応可能 • システム全体の傾向監視ができる • 作り込みの必要はほとんど無い APサーバ、 アプリの情報 可視化 ログ出力 リスク コスト
9. V0000000 開発の負荷を下げたい -開発環境のコンテナ化- これまでの方式 これからの方式 これまでの方法： • 長時間を掛けてPCに開発環境を構築 • 様々なソフトウェアを同時に稼働させる 課題： • サーバやIDEなどによる開発用PCのリソース逼迫 • 有識者が物理的に近い距離にいないと相談できない これからの方法： • IDE、サーバ、DBなどのコンテナを構築 • 開発者はコンテナを起動するのみ • ブラウザで IDE や各種サーバへアクセス メリット： • 環境の準備に時間が掛からない • 開発用PCはブラウザだけがあれば良い • 有識者へ URL を伝えると環境を共有できる IDE サーバ DB コンテナ・オーケストレーション IDE サーバ DB IDE サーバ DB IDE アクセス リスク コスト
10. V0000000 linkedin.com/company/red-hat youtube.com/user/RedHatVideos facebook.com/redhatinc twitter.com/RedHat Thank you