Open Hybrid Cloudを検討すべき理由.pdf

Open Hybrid Cloudを検討すべき理由
2022年6月14日
レッドハット株式会社　チーフテクノロジスト　梅野昌彦
Open Hybrid Cloud Week 2022
1

Copyright 2022 Red Hat K.K.
2
レガシーモダナイズで検討すべき観点
今後ITが業務を支える姿を考えると、今までの考え方を発展させた
アーキテクチャや開発手法等を積極的に採用していく必要があります
1. アプリケーションアーキテクチャ
2. 開発手法
3. 各組織との協業
4. 運用と保守

アプリケーション
アーキテクチャ
3

4
何をするアプリケーションか
写真・映像編集基幹業務生産管理情報収集分析機械学習
パッケージ製品スクラッチ開発
特定の目的に特化したもの
他社とも変わらない業務
他社と異なる自社の事業の中心となる業務
● データ
● ロジック
● プロセス
● 画面
● システム間連携
● ユーザ管理
● セキュリティ
● 整合性
● 負荷対応
● 運用管理
写真・映像編集基幹業務生産管理情報収集分析機械学習

5
企業の一般的な基幹システムのイメージ
お客様
営業部門
製造部門品質管理部門
経理部門
製品開発部門
アクセス数に
偏りがあるWeb
部門独自で設定
されたコード
締日に行われる大量の
バッチ処理
各システムで
共有しているDB
実質的な業務は
Excelで
似たような
ロジックが多い
部門を跨いだ
処理

6
マイクロサービスの考え方
User Interface Service
Process Service
Decision Service
Data Service
Integration Service
Platform Service
Infrastructure Service
画面の入出力
案件の進捗管理
チェック・計算・推論
格納・抽出
サービス連携・システム間連携
サービス稼働環境
物理・仮想環境
新規会員注文受付発送在庫管理営業管理会計
業務機能
ITとしてのサービス　x　ドメイン = マイクロサービス
ITとしての
サービス

7
実際のマイクロサービスの構造例　（受注処理）
契約情報
各業務処理
外部データ
取込
データ
取得
データ
格納
Java Java+
Rule Engine
Java+
Rule Engine
Java
Java
処理
振分け
Java
要求のタイプごとに
Queueに振り分け
処理待ち
リスト
Queue
Java
多重化された業務処理で
スループットを向上
処理待ち
リスト
Queue
外部
サービス
契約情報
処理結果
Queue
参照
サービス
コンテナ
タグ付け
該当タグ
該当タグ
DataBase DataBase
受注データ
マイクロ
サービス

8
アプリケーションとプラットフォームとの関係性
マイクロサービス化されないシステムの場合
Infrastructure
部品展開処理
部品別
バイヤー振分
製品別集計
サプライヤー
別集計
部品別集計
納期算出
見積回答
画面機能
納期回答
画面機能
● 複数の機能が一つのアプリに集約
● 改修負荷は今までと変わらない
● 使うリソースに偏りがある
● 負荷分散が難しい
● HA構成は1+1
● 仮想環境とほぼ変わらない使い方
Worker Node
OpenShift Container Platform
Infra Node Worker Node Worker Node Worker Node
RHEL
Infrastructure

9
アプリケーションとプラットフォームとの関係性
マイクロサービス化されたシステムの場合
マイクロサービス化されたアプリケーションを効率よく開発・稼働させるためには、コンテナ環境が最適です。
特に多重度を上げて性能を確保するような処理の場合、スケールアウト/インを自動で行うことができます。
部品展開処理
Worker Node
OpenShift Container Platform
Infra Node
部品展開処理部品展開処理
部品別
バイヤー振分
製品別集計
サプライヤー
別集計
納期算出
部品別集計
Infrastructure
見積回答
画面機能
見積回答
画面機能
納期回答
画面機能
納期回答
画面機能
Worker Node Worker Node Worker Node
RHEL
Infrastructure

10
エッジコンピューティング
帯域も広くて安い
帯域が狭くて高い
データの発生源近くである程度の処理を行う
Private Cloud
Private Cloud
Private Cloud
Mother Cloud
同一アプリの大量配布・稼働
配布アプリの管理
分析等の力量の多い作業
Hybrid Cloud環境

12
開発手法の選択
ウォーターフォールアジャイル・スクラム
適切な開発方法は無いものか？
何を基準に考えるべきなのか？
● 過去の経験
● 監査基準
● …
● アプリケーションの状態
● プロジェクトの規模
● アプリケーションのアーキテクチャ

13
アプリケーションの状態
新しいアプリケーションを作成・デプロイ
　どんな方法でも構いませんが、要件が初めから全確定して変更など無いよう
なアプリは無いはずなので、繰り返し型開発が適切
旧来動いていたシステムのリニューアル
• 使用していないソースコードまで持っていくのでは、なんのためのリニューア
ルなのかわからないので、使う分だけ持っていかないと、費用が高騰する
• 仕様をソースコードから取捨選択することは事実上不可能
• 機械学習では実データを使ってロジックを見つけ出す。同じように、実データ
を使って人間がロジックをあぶり出す方法で必要最小限のロジックを移行する
• 繰り返し型で開発することで品質を高めながら開発
• 適切なテスト方法・移行方法でデータの移行を行う

14
プロジェクトの規模
巨大なシステムであれば細部までの見積もりは現実的にできない
ならば、業務単位で切り出して、見通せるくらいの小さいプロジェク
トを複数立ち上げていく
品質の向上を目的として、繰り返し型開発を行う
● 「作らなくても良いもの」は削減
● 性能問題等の課題を早い段階での解決
● 成功体験の展開でよりリスクを少なく
● それぞれの開発拠点(SIer)が使いやすいクラウド環
境を利用し、コンテナ環境としては統一的に使える
環境を用意する
https://www.redhat.com/ja/enga
ge/successful-legacy-modernizati
on-s-202201280548

15
アプリケーション・アーキテクチャ
● モノリシックアーキテクチャの場合は、テストを行うタイミン
グが後ろの工程になりがちだが、繰り返し型開発も可能
● マイクロサービスアーキテクチャの場合は、各サービス単位で
繰り返し型での設計・開発・テストが可能
いずれのアーキテクチャでも繰り返し型開発は可能であ
り、品質を高めることを優先すべき

16
アプリケーションモダナイゼーション　アプリ観点相関図
イテレーション
開発
テスト駆動
開発
マイクロ
サービス
ルール
駆動
開発
UI Service
Process Service
Decision Service
Data Service
Integration Service
Platform Service
ドメインの整理
ITサービス
定義
FAT DB化の抑制
Agile
Scrum
アプリの
ビルド
静的解析
単体
テスト
コンテナ
イメージ
ビルド
イメージ
Push
DEV環境
デプロイ
動的解析
結合
テスト
STAGING
デプロイ
継続的インテグレーション(CI) 継続的デリバリー(CD)
現行アプリ
処理結果
新アプリ
処理結果
NG:ロジック/データが足りない / 間違い
現行アプリ
投入データ
現行アプリ新アプリ
ｷｭｰ
ｷｭｰ
非同期化・多重処理化・脱バッチ化
データパイプライン化
コンテナ環境
コンテナ環境
Quarkus
サーバーレス稼働
注力すべき点が明確・業務側と相談して解決
ルール駆動開発
コンテナ環境
&
API化
API管理
移行計画
API化
営
業
在
庫
会
計
過去N年分　or
事前に定義したデータ
開発粒度の適正化
新規ビジネス
の創出

17
開発方法で最適なのは繰り返し型開発
マイクロサービス型で小規模の業務を実装する
● 全体の概要設計（幹となる部分）を決める
● データ、ロジック、画面、連携等を担当毎にそれぞれ開
発・テストを行う
● 枝葉の部分に拡大しながら実装を完了させる
● 統一した開発環境・稼働環境・テスト環境が必要
繰り返し型開発にはコンテナ環境が適している

18
それでもウォーターフォールにこだわる理由は？
● 新しい技術・手法がリスクに感じられる
● 要件の追加による混乱を抑えたい
● 会計検査基準が完成品のみが対象である
● 過去のプロジェクトでの分析ができていない
● 失敗をすると出世に響く...
責任を(過度に)追求せず、
苦労や原因を知識として学習できる文化に変える
急激な変化ではなく、緩やかな変化をも許容する

20
組織間の関係
業務部門
IT部門
システムインテグレーター
隙間が
齟齬を生む上下関係が
責任問題を生む
典型的な例
● 関与できる階層は一つ下まで
● IT部門は中間管理職扱い
● 上下関係が生じ、不条理なリクエストをも受
けざるを得ない
● 自分の役割以外に助言などが出しにくい
● システムインテグレータでの多重請負が発生
● 問題発生時に伝言ゲームになり、解決まで時
間がかかる
● アーキテクチャや開発手法が遵守されず、動
けばよいだけのアプリが作られる
などなど...

21
従来型組織における、繰り返し型開発の課題
業務部門と会話が難しい
　→　そんなの知っているでしょ？と言われる
　→　見えない強烈な上下関係が存在していて遠慮してしまう
　→　自分の仕事以外で時間を取られることにメリットを感じないと言われる
　→　全部でいくら掛かるかを先に出して …
IT部門との会話が難しい
　→　専門的な用語で説明されてもわからない
　→　パッケージ入れればよいのでは？特別なことはしていないし（自社で
行っていることは世間の常識と思いこんでいる）
　→　Excelでやればすぐできるのに、なぜそんなに時間が掛かる？
　→　要件を出せと言われても、今の仕組みが前提での要件しか思いつかない

22
組織間の関係
業務部門
IT部門
システムインテグレーター
業務部門
IT部門
システム
インテグレーター
理想的な例
繰り返し型開発を少しずつ進めることで、理想的な形へ少しずつ進められる
典型的な例

23
弊社の経験より
業務担当者による
勉強会
要件ヒアリング
図式化
実装・テスト
確認・要望
リリース
● 勉強会で業務の概略を掴む
● データとロジックを図式化する
● 実装・テスト・結果考察をする
ソースコードを見たのは最後の最後
工数の最小化と品質の最大化を達成
業務側に協力の要請

24
組織と役割
● 思い切って第三者にお願いする
● IT側が業務側へ同等の立場として「提案」すること
● 業務・ITで小さなグループを作り、とりあえず作ってみる→テスト
→議論→作ったものを修正→… を繰り返す
● 変更要求に強いアーキテクチャ・ツール・環境が必要
● 機能や負荷テストを作ってすぐ実データでできる環境
● コンテナでかつオンプレミスとクラウドの両方でデータやアプ
リの流通ができる環境
関係者が自然と集まり、協力しあえる体制になる

26
コンテナによる統一した開発環境の速やかな提供
世界中のどこからでも、ライブラリーのバージョンまでもが
同じ開発環境が提供される
● 環境の違いによる動作違いの検証が少なくなる
リクエストして整備されるのを数日待つのではなく、
セルフサービスで準備される環境が提供される
● 環境作成待ち時間の減少
● 負荷テスト時の待ち時間減少
● Blue / Green Test や Canaria Release等、より高度に品質を確認できるテストが可能
● 限界性能の見通しが立ちやすくなる

27
マイクロサービスによる耐障害性の向上
処理待ち
リスト
Queue
Java
… 処理待ち
リスト
Queue
Java
… 処理待ち
リスト
Queue
処理待ち
リスト
Queue
エラー
データ
Queue
Java
…
多重化による高速化
ポータビリティによる稼働
箇所による障害の回避

28
プラットフォームとの関係性
本番環境テスト環境
BCP環境
一つの環境に依存すると、
その環境で障害が起きると全てが止まる！
複数のクラウド環境で同じように動かせるコンテナ環境が必要
Open Hybrid Cloud 環境が最適

30
まとめ
マイクロサービス
繰り返し型開発
オンプレ・クラウド環境
の活用
業務・ITの協力体制
イベントドリブンな
開発・テストの繰返し
CI / CD
要件の優先順位
テスト結果の考察
業務シミュレーション
開発体制 / BCP /
障害再現
開発手法
各組織との協業
運用と保守
アプリケーションの開発保守
コンテナ
Hybrid Cloud
コンテナ
コンテナ
コンテナ
Hybrid Cloud

31
これからのアプリケーションやプラットフォームについて、
開発だけではなく運用まで考えると、行き着く先は
Hybrid Cloud 環境
レッドハットは Open Hybrid Cloudを推進しています。

linkedin.com/company/red-hat
youtube.com/user/RedHatVideos
facebook.com/redhatinc
twitter.com/RedHat
THANK YOU
Red Hat is the world’s leading provider of enterprise
open source software solutions. Award-winning
support, training, and consulting services make
Red Hat a trusted adviser to the Fortune 500.

Open Hybrid Cloudを検討すべき理由.pdf

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Open Hybrid Cloudを検討すべき理由.pdf

Ähnlich wie Open Hybrid Cloudを検討すべき理由.pdf (20)

Mehr von Masahiko Umeno

Mehr von Masahiko Umeno (15)

Open Hybrid Cloudを検討すべき理由.pdf