Why run OpenShift on Google Cloud

システム更改が好機!!
Google Cloudで始めるレガシーアプリをコンテナ移行する術
Shingo Kitayama
Cloud Specialist Solution Architect
Red Hat K.K.

View Slide

Copyright © 2023 Red Hat K.K. All Rights Reserved.
Introduction
Shingo
Kitayama
Cloud Specialist Solution Architect
Technical Sales
Red Hat K.K.
shkitayama
spchildren

View Slide

12%
28%
19%
22%
19%
レガシーシステムの状況 (日本: n=542)
すでにレガシーシステムはない
一部領域にレガシーシステムが残っている
半分程度がレガシーシステムである
殆どがレガシーシステムである
分からない
いよいよ迫る「2025年の崖」
2025年の崖に対応
・システムのブラックボックス化
・古いシステムの保守・運用コスト
・ IT人材の不足
・製品サポート終了
(End of Service Lifecycle)
引用: 情報処理推進機構「DX白書 2023」図表5-27 レガシーシステムの状況抜粋 (グラフ形式変更)
レガシーシステムを抱える
企業約
80
% 69
%

View Slide

本日のAgenda
クラウド移行、その前に
変化に柔軟なシステムを育てる
クラウドメリットを享受するコンテナ移行

View Slide

クラウド移行、その前に

View Slide

技術的負債
開発者が知るクラウドの「期待」と「現実」
クラウドファースト
アジリティ
(調達、提供速度の向上)
安定性
(安定した自動化)
コスト最適化
(従量課金の活用)
アーキテクチャが複雑化、ブラック
ボックス化していて改修が困難。
クラウド活用への「期待」
技術が老朽化しており、リソースメ
ンテナンスが属人化。
運用・保守に多くのコストが必要で
あり、DXの投資を圧迫する。
インフラリソースの運用がアプリ
開発チームの責務に転換される。
更改タイミングが既存と同じため、
結果利用コストも同じ。
既存アーキテクチャのまま移行し
て運用で苦労している。
変わらない「現実」
レガシーシステムの課題
1
2
3

View Slide

Instance Group
LEGACY Instance
Compute Engine
Multiple Instances
Cloud Load
Balancing
Database Server
Compute Engine
Physical Load
Balancing
Database Server
Physical Server
オンプレミス
Cloud
LEGACY Server
Physical Server
Lift Up
たとえばWeb3層アーキテクチャをそのままクラウドリフト
クラウドへ移ると
「技術的負債」
は解消されるのだろうか!?

View Slide

Instance Group
LEGACY Instance
Compute Engine
Multiple Instances
Cloud Load
Balancing
Database Server
Compute Engine
インフラリソースの固定値
ビジネスロジック
( EJB )
LEGACY Instance
サブプログラム
( EJB )
マクロ
( EJB )
< IN > < OUT >
Action
(Web)
データアクセス
( DAO )
・ Webサーバーとアプリケーション
サーバーが1つのインスタンス内で呼
び出しを行い、分散できない
・サブプログラム呼び出しの順番が
ホストのアドレス固定で決まっている
・決まったバッチ作業がホストごとで
実施されるため、スケールできない
よくあるクラウド移行
既存アーキテクチャのまま移行
1

View Slide

Instance Group
LEGACY Instance
Compute Engine
Multiple Instances
Cloud Load
Balancing
Database Server
Compute Engine
移る責任と移らない権限
LEGACY Instance
・インフラリソースの払い出しはする
けど、ミドルウェアの管理は開発者
側で行う
・マネージドサービスから払い出せ
ば済む話にチーム間連携や多重の
承認フローが必要
・アプリ更新作業には、仮想マシン
の設定変更が必要にもかかわらず
権限がない
OS
Middleware / Libs
Application
開発者に
権限はない
開発者もサービス
責任はある
開発者
アプリ開発チームの責務に転換
2
運用者

View Slide

Instance Group
LEGACY Instance
Compute Engine
Multiple Instances
Cloud Load
Balancing
Database Server
Compute Engine
オンプレミスと変わらないリソース利用
・構築や更新の責任が構築/運用ベ
ンダー側にあるため、スケールは想
定していない
・更改のたびに異なる開発、運用ベ
ンダーに依頼するため、利用率が一
定
・余剰を見込んで構築しているため、
稼働自体はいつも数%を推移してい
る
LEGACY Instance
利用コスト
t (時間)
3年間
更改
更改
更改タイミングが既存と同じ
3
3年間

View Slide

続・技術的負債
更改タイミングで「変化に柔軟なシステム」を育てていく
既存アーキテクチャが
クラウドに合わない
既存プロセスに合わせて
クラウドをカスタマイズ
属人的にクラウドの
保守/運用を行う
シン・2030年の崖
爆誕
変化に柔軟なシステム
アーキテクチャを
クラウドに寄せる
クラウドネイティブ
クラウドに適した
運用プロセスに変える
レガシーシステム
更改

View Slide

Overview
Like many organizations in the tourism industry, Studiosus relied on decades-old technology.
Its COBOL (Common Business-Oriented Language) system was difficult to maintain without
affecting operations—and COBOL talent is both rare and costly. Red Hat® Enterprise Linux®
and Red Hat OpenShift® has helped the company adopt a modular, microservices-based
architecture for its IT systems. Studiosus can now launch new services to market—or make
changes to existing services—in less time.
How have the business and technical environment changed for Studiosus?
“Flight reservations were easy 15 years ago. You went to the airport, bought a ticket, and that
was it. Nowadays, flight reservations, especially for groups, have become a very complex task.
You must reserve a seat in one of your plane’s 10-15 service classes. Also, a difficult three
years has left a lot of tourism companies in a serious financial situation, making strategic
planning more important than ever.”
Why open source?
“We decided on an open source approach because of the availability of experienced
personnel. We first adopted Oracle Linux but found some licensing problems. We then tried
CentOS. I was reasonably happy but quickly discovered that we needed additional support. I
met some Red Hat people at a DevOps event, and they suggested I try out the free Red Hat
Enterprise Linux developer edition.”
Adopting an enterprise
Kubernetes solution:
● Appreciated the advantages
of a fully maintained
enterprise solution.
● Red Hat enterprise solutions
are tried and tested, stable,
and reliable.
● Having built-in security and
a strong vendor is a huge
advantage.
Source: Red Hat Q&A. Studiosus replaces monolithic COBOL system with agile, microservices-based approach. July 2023.
COBOLをOpenShiftに移行した事例です。
事例公開制限のため、以下より資料をDLください。
https://www.redhat.com/en/resources/studiosus-customer-qa

View Slide

技術的負債
「変化に柔軟なシステム」を選んでクラウドを活用
回復性
(常にあるべき状態を保つ)
管理力
(自律運用と統制)
可観測性
(必要に応じたスケール)
アーキテクチャが複雑化、ブラック
ボックス化していて改修が困難。
技術が老朽化しており、リソースメ
ンテナンスが属人化。
運用・保守に多くのコストが必要で
あり、DXの投資を圧迫する。
レガシーシステムの課題
クラウドファースト
アジリティ
(調達、提供速度の向上)
安定性
(安定した自動化)
コスト効率化
(従量課金の活用)
クラウド活用への「期待」

View Slide

It is not the most intellectual of the species that survives; it is not the
strongest that survives; but the species that survives is the one that is
able best to adapt and adjust to the changing environment in which it
finds itself.
- Charles Darwin
唯一生き残るのは、
変化に適応できるものである。

View Slide

変化に柔軟なシステムを育てる

View Slide

変化に対応し続るためには
仮説 / 検証の仕組み
企業文化醸成、人材育成
回復性管理性可観測性
要求要求要求
変化しやすい
変化しにくい
クラウドへ移行したときの人材育成
・常に更新し続けられる人を育てていく
・新しい技術の人材はどこでも希少
ビジネス要求に対応できる能力
既存の運用から移行できる能力
「変化に柔軟なシステム」は育てていくもの

View Slide

既存の運用を ”無理なく” クラウドへ移行する
あらかじめクラウド運用を見越した機能が備わっていることを重視する。
回復性
管理力
可観測性
たとえ障害が起きても、動的に回復し、引き続きサービスを継続できる機能
多くの異なるプラットフォームやサービスを簡単かつ一元的に管理できる機能
複雑なシステムやユーザーの操作に対するシステムの動作を常に把握できる機能

View Slide

クラウド運用を見越した回復性
回復性
Operator
Custom
Resource
開発者
< change >
< watch >
< adjust >
Container
( Stateful )
< modify >
< use >
Kubernetes Operator
アプリケーションやミドルウェアなどのサービスを
人間の代わりに運用管理する機能
・ Custom Resourceに必要なリソースを定義
・ミドルウェアの特徴を考慮して動的に回復
・マネージドサービスのような利用
・ OpenShift上の機能の多くはOperator
・ Red HatやEcosystem Partnerによってサポート
・ OperatorHub(カタログ)を提供
Kubernetes Operator

View Slide


View Slide

クラウド運用を見越した管理力
管理力
Pipelines
Operator
開発者
Red Hat Developer Hub
開発を行うときに必要なサービスを1つのポータル
上から管理できる機能
・ CNCFにも登録されたBackstageを活用
・開発に必要な機能をポータルに統合
・コンテナを意識せずにサービスを活用
・数多くのPluginからOperatorのInterfaceに接続
・ OperatorによりDeveloper Platformを構築
Red Hat Developer Hub
GitOps
Operator
SSO
Operator
Pipelines with
Tekton
GitOps with
Argo CD
Authn and
Authz
IDP : Internal Developer Portal
< use >

View Slide


View Slide

クラウド運用を見越した可観測性
可観測性
OpenShift Monitoring / Logging
コンテナの稼働状況やユーザーアクセスにおけ
るシステム全体の状態を把握できる機能
・ OpenShift MonitoringはPrometheus Operator
・あらかじめアラート(Alertmanager)が設定
・ CRD(ServiceMonitor)にてカスタマイズ可能
・ OpenShift Loggingは内部/外部が利用可能
・既存のログシステムに転送(Vector)
・ OpenShiftではLoki Operatorも使用可能
Cloud
Logging
開発者
Collector
Outputs
< use >
App
Container
Monitoring
Operator
OpenShift Monitoring/Logging

View Slide


View Slide

クラウドネイティブの“引き立て役”
OpenShiftは、開発者がクラウドのメリットを得られるよう、あらかじめクラウドに適した運用を補助してくれるツール
回復性管理力可観測性
Data Center

View Slide

クラウドメリットを享受するコンテナ移行

View Slide

開発視点におけるコンテナ移行アプローチ
クラウド移行による
運用課題
コンテナ移行アプローチソリューション
アーキテクチャの実装
Migration Toolkit for
Applications
アプリ開発チームの
責務に転換
クラウドに適した権限分離 Universal Base Images
更改タイミングが
既存と同じ
常に更新し続けられる
システム
Google Cloud
Marketplace
既存アーキテクチャ
のまま移行

View Slide

シン・2030年の崖
爆誕
アプリケーションの移行戦略
のまま移行
Refactor
Replatform
Rehost
レガシーシステムの更改
技術的負債の
対応を検討
業務プロセスの
更新を検討
業務プロセスを含めた
アーキテクチャの改善
業務プロセスを維持した
クラウドへの適用
移行コストだけをみて
リフトしたシステム
継続的に
ビジネスの仮説 / 検証

View Slide

クラウドに適したアーキテクチャの実装
ビジネスロジック
( EJB )
サブプログラム
( EJB )
マクロ
( EJB )
< IN > < OUT >
Action
(Web)
データアクセス
( DAO )
- コードベースでの継続的デリバリ
- クラウドプラットフォームに適した
アーキテクチャ(依存関係の分離)
- 動的な環境変数の活用
- 開発手法を大幅に変更することなく
スケールアップ
引用: The Twelve-Factor App 抜粋
のまま移行
構成情報の
環境変数化
ローカル
呼び出しの変更
Port
バインディング
ログの
標準出力
ランタイム起動時間
の調整
目的に応じた
プロセスの分離

View Slide

Migration Toolkit for Applications
アプリケーションのコンテナ化やJBoss
EAPのアップグレード、ベンダー固有のア
プリケーションサーバーからの移行を支援
するツール
Applications
Oracle WebLogic > JBoss EAP
IBM WAS > JBoss EAP
Apache Camel 2 > Apache Camel 3
Spring Boot > OpenJDK / Quarkus
…etc
のまま移行
< Supported Runtimes >

View Slide

クラウドに適した権限分離
開発者側で必要なライブラリやミドルウェアの管理が可能
- 不要なLibraryによるセキュリティ脆弱性を回避
- アプリケーション更新時も運用者への調整不要
VM Instance
OS
Middleware / Libs
Application
開発者に
権限はない
OS
Middleware / Libs
Application
責任はある
Container Image
責任はある
開発者に
権限がある
責務に転換

View Slide

Universal Base Images
Middleware / Libs
Application
Container Image
OS
Universal
Base Images
Red Hat Core OS
(RHCOS)
Open Container Initiative(OCI) に準拠し、
自由に再配布できるコンテナのベースイ
メージです。
OpenShiftやRHEL上で実行することでサ
ポートが受けられます。
Universal Base Images
Python
OpenJDK / Quarkus
PHP
Ruby …etc
責務に転換
Nginx
PostgreSQL
Redis
MySQL …etc
< Supported Runtimes >
開発者は
開発に専念

View Slide

品質、パフォーマンステスト
脆弱性検査、侵入検査
Bugなどの課題管理
SDL*プラクティスの導入
Red Hatエンジニアリング
による課題修正とQA判断
Red Hatのソフトウェア提供プロセス
責務に転換
コミュニティ
プロジェクト
Red Hat
サポート提供
Red Hatの
QAプロセス
引用: Red Hat’s Secure Development Lifecycle (SDL) practices
https://access.redhat.com/articles/red_hat_sdl

View Slide

We’re a Google Cloud
Technology Partner of the Year.
(Infrastructure - Compute)
Google Cloud Next 2023
Red Hat and Google Cloud simplify your cloud journey with flexible,
proven, and innovative hybrid solutions.

View Slide

常に更新し続けられるシステム
LEGACY Instance
利用コスト
t (時間)
3年間
更改
更改
利用コスト
t (時間)
ビジネスの必要に応じて適したリソースを利
用することによって得られるコストメリット
・従量課金モデルのサブスクリプション
・年間契約ではなく時間単位の契約
・オンプレと同様のサポート
更改更改
既存と同じ

View Slide

Google Cloud Marketplace
Google Cloud
Marketplace
既存と同じ
年間契約のSelf-Managedサブスクリプ
ションが、Google Cloud Marketplaceを
利用することで、従量課金に!!
Google Cloud Marketplace
- 時間単位でOpenShiftを利用
- Google Cloudで契約が可能
- Red Hatのサポートが受けられる

View Slide

従量課金の使いどころはスケールイン
既存と同じ
既存開発拡張利用
一時的な負荷試験
パフォーマンステスト終了時にインフラリソースを縮退
ポイントは拡張よりも、用途に応じた
縮退
拡張
縮退
機能開発/バグ修正用の開発環境
サービス開発期間が終わるとリソースを縮退
クラスタ更新時のB/G環境
安全なバージョンアップのための切り戻し環境

View Slide

開発視点におけるコンテナ移行アプローチ
クラウド移行による
運用課題
コンテナ移行アプローチソリューション
アーキテクチャの実装
Applications
責務に転換
クラウドに適した権限分離 Universal Base Images
既存と同じ
常に更新し続けられる
システム
Google Cloud
Marketplace
のまま移行

View Slide

まとめ

View Slide

システム更改が好機!!
技術的負債
レガシーシステムの課題クラウド活用への「期待」
変化に適応できる環境をコンテナで育てていく

View Slide

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.

View Slide

Assets

View Slide

具体的な対策としては「クラウド活用」!?
引用: 情報処理推進機構「DX白書 2023」図表1-30 ITシステムの開発手法・
技術の活用状況（開発技術）抜粋
「パブリッククラウド」の活用/検討されて
いる利用者は半数以上
51.5%
「コンテナ運用自動化」の活用/検討され
ている利用者は1/4以上
25.3%

View Slide

Why run OpenShift on Google Cloud

Why run OpenShift on Google Cloud

Shingo.Kitayama

More Decks by Shingo.Kitayama

Other Decks in Technology

Featured

Transcript