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

Modernize On Premis and Monolith Application Platform

Chihiro Ito
November 18, 2020

Modernize On Premis and Monolith Application Platform

Chihiro Ito

November 18, 2020
Tweet

More Decks by Chihiro Ito

Other Decks in Technology

Transcript

  1. V0000000 近代化: モダナイゼーション これまでの方式 これからの方式 アプリは変えず可用性と 性能効率を高めたい アプリは変えず敏捷性を高めた い 開発の負荷を下げたい

    ビジネスの敏捷性を高めたい ビジネスの速度を高めたい 運用の負荷を下げたい オンプレ 運用 バッチ アプリ オンプレモノリスからのモダナイゼーション
  2. V0000000 これからの方式 アクション アプリは変えず可用性と性能効率を高めたい EAP から Runtimes へ移行(同価格) アプリは変えず敏捷性を高めたい EAP

    と OpenShift を導入 ビジネスの敏捷性を高めたい EAP から Runtimes へ移行(同価格) ビジネスの速度を高めたい Integration を導入 運用の負荷を下げたい Middleware (個別も可) と OpenShift を導入 開発の負荷を下げたい OpenShift を導入 モダナイゼーションの例
  3. V0000000 アプリは変えず可用性と性能効率を高めたい -セッション情報の可用性を高める- これまでの方式 これからの方式 これまでの方法: • セッション情報はアプリのメモリ上にある 課題: •

    アプリが停止するとセッション情報は消える • ユーザ増によりセッション情報が増えメモリを逼迫する • メモリを逼迫すると性能低下や停止する可能性がある • アプリのスケールアウトをしても可用性は向上できない • ノード数は処理量かセッション情報量の大きい方にあわせる これからの方法: • セッション情報はデータグリッドに冗長化されて格納 メリット: • アプリが停止してもセッション情報を維持 • ユーザが増えたらデータグリッドを増やして格納量を増強 • アプリはステートレスになるためスケールアウトが容易 • データグリッドのノード間で複製を持つため高い耐障害性 • アプリがセッション情報のキャッシュを持つため性能も担保 • アプリのノード数は処理量にあわせる リスク コスト データグリッド データグリッド データグリッド データグリッド セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 セッション 情報 EAP 4 プロセス、Red Hat Data Grid 4 プロセス EAP 4 プロセス アプリ アプリ アプリ アプリ アプリ アプリ アプリ アプリ サーバ サーバ サーバ サーバ サーバ サーバ サーバ サーバ
  4. V0000000 アプリは変えず敏捷性を高めたい -Fastモノリス化とCI/CDを導入- これまでの方式 これからの方式 これまでの方法: • 全ての変更機能を一度に開発・試験・リリース • 事前に見積もられたオンプレ環境でアプリを試験・稼働

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

    全ての業務を 1 つのアプリに実装 • アプリを 1 つだけ動かす 課題: • 業務変更の影響範囲が広く見積り・開発が困難 • アプリ停止時にシステム全体が止まる • スケールすると不要な業務のリソースも消費してしまう これからの方法: • ビジネス要求の頻度毎に業務を切り出して稼働する メリット: • ビジネス要望を直ぐ実現できるようになる • 業務変更の影響範囲を限定でき見積もりやすく開発し易い • アプリの障害時に他のアプリは稼働できる • アプリごとにスケールできるためリソースの使用効率が高い アプリ 業務A 業務B 業務C A, Bより変更要 求が多い リスク コスト 利益
  6. V0000000 ビジネスの速度を高めたい -時間を指定するのではなくニアリアルタイムへ- キュー キュー これまでの方法: • バッチの結果をファイルや DB経由で次のバッチへ連携 •

    スケジューラがバッチの順序を管理 • ある処理量が一定時間で終わるように最大性能で環境を構築 課題: • 処理されて次のバッチに処理されるまでビジネスは停止 • 処理完了するまで次の処理は進まず、失敗すると停止 • バッチ間の開始時間と終了時間の調整が必要 キュー バッチ1の範囲 これまでの方式 これからの方式 ファイル・DB 連携 バッチ1 バッチ2 これからの方法: • 前の処理からデータが来たら直ぐに処理される メリット: • リアルタイムにビジネスが進む • データは流れるので開始時間の調整は不要 • 障害時は他の支流は処理が行われる • 処理が間に合う分の性能で環境を構築 バッチ2の範囲 リアルタイム 連携 コンシューマ コンシューマ コンシューマ コンシューマ 利益 リスク コスト
  7. V0000000 運用の負荷を下げたい -可視化によるリスク低減- これまでの方式 これからの方式 これまでの方法: • アプリの監視項目を自前で開発して監視 • ミドルウェアの監視項目を必要な項目だけ選定して監視

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

    課題: • サーバやIDEなどによる開発用PCのリソース逼迫 • 有識者が物理的に近い距離にいないと相談できない これからの方法: • IDE、サーバ、DBなどのコンテナを構築 • 開発者はコンテナを起動するのみ • ブラウザで IDE や各種サーバへアクセス メリット: • 環境の準備に時間が掛からない • 開発用PCはブラウザだけがあれば良い • 有識者へ URL を伝えると環境を共有できる IDE サーバ DB コンテナ・オーケストレーション IDE サーバ DB IDE サーバ DB IDE アクセス リスク コスト