Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
Empfohlen
Empfohlen (20)
クラウドネイティブ化に向けて今あるレガシーシステムをどうする
- 5. オンプレ クラウド 5 プラットフォーム特性 即応性 アジャイル (1-2週） 長期的なサービス提 供が保証されない H/W保守 長期的な費用計画 変動料金 自社主導でシステム ライフサイクル策定 (塩漬け含め) H/W調達の リードタイム サービス利用 ウォーターフォール （月、年） API 所有から 利用へ 長期計画が 根本的に変 わる 待ちゼロで サービス開 始 継続的 デリバリ 費用が変動 分散システ ム前提
- 6. DBサーバ COBOLCOBOLCOBOLAPインスタンス1 統合APサーバ Webサービス Webサービス Webサービス 数十のサービス登録 APインスタンス2 Webサービス Webサービス Webサービス APサーバ3 U/I とある現行システム 課題点 RDB COBOL COBOL COBOL APサーバ1 統合APサーバ Webサービス Webサービス Webサービス : n個のインスタンス APサーバ2 Webサービス Webサービス Webサービス APサーバ1 COBOLCOBOLCOBOLAPインスタンス1 統合APサーバ Webサービス Webサービス Webサービス : n個のインスタンス APサーバn Webサービス Webサービス Webサービス APサーバ2 Webアプリ L/B SOAP + XML モノリシックなアプリケーション構造 サービス数が多くAP サーバー更新時の時 間・工数 ・更新タイミングに制約 ・工数増 ・今後の拡張性に足かせ 3 １つの改修要求に全てのコンポーネント改修が必要 1 サービス呼出が SOAP + XML ・N/Wトラフィック増大 ・レスポンスの課題 ・今後の拡張性に足かせ 2 複数システム配布・ 管理が手動 ・変更・管理工数の増大 ・今後の拡張性に足かせ 5 モノリス前提のアプリ構造 ・固有技術 ・インフラとの密結合 4 6
- 7. レガシー・アプリケーション・モダナイズ方法論 • Java,phpなどオープン系言語資産 ・Webアプリをファクタリングしマイクロサービス化→REST化→コンテナ化 ✓ ・呼出I/F（RPC, SOAP）をRESTに変更 • 非オープン系言語資産 • COBOLなどレガシー言語アプリは呼出しI/FをREST化 ✓COBOLバッチプログラムにREST I/F追加 ✓エミュレーター利用のアプリケーションは画面I/Fを除外しバッチPGM化、 またはエミュレーター画面をRESTラッピング • 新規開発 • Python, Node-js, Node-RED他OSSで新規開発 • クラウドネイティブ、コンテナ化前提で開発 7
- 8. DBサーバ COBOLCOBOLCOBOLAPインスタンス1 統合APサーバ Webサービス Webサービス Webサービス 数十のサービス登録 APインスタンス2 Webサービス Webサービス Webサービス APサーバ3 U/I とあるシステム 改善方針 RDB COBOL COBOL COBOL APサーバ1 統合APサーバ Webサービス Webサービス Webサービス : n個のインスタンス APサーバ2 Webサービス Webサービス Webサービス APサーバ1 COBOLCOBOLCOBOLAPインスタンス1 統合APサーバ Webサービス Webサービス Webサービス : n個のインスタンス 多数のサービス登録 APサーバn Webサービス Webサービス Webサービス APサーバ2 Webアプリ L/B SOAP + XML 多数のサービス登録 マイクロサービス化 コンテナ化ハイブリッドクラウド化 OS固有機能を排し OSSで標準化 ・APサーバをOSSベースに ・コンテナ化 ・クラウド前提の管理ツール 3 マイクロサービス化を進める 1 最新I/Fに刷新 SOAP → REST XML → JSON 2 オンプレ・クラウド で管理を統一 ・DevOps準拠 ・運用管理の標準化・自動化 5 レガシーアプリのモダナイズ API対応 サービス化 4 受注データを 分離 WEB受注用データを クラウドに切出し 4 ベンダーロックイン 排除 プライベートクラウド基盤化 N/Wトラフィック減 アプリ管理 標準化・省力化 分散DB環境 アプリ可搬性 アジャイル、CI/CD前提 クラウドネイティブ・レディ CI/CD 不安・・ ・サイジング、パフォーマンス、問題判別、運用管理項目、セキュリティ8
- 9. サー ビス サー ビス サー ビス サービ ス サービスサービス サービス サービス TO BEモデル論理図 オンプレ基盤クラウド基盤 業務（モノリスアプリ）を サービスと して再定義 最適な基板上に再配置 （配置先は可変する） N個のクラウドとオンプレに分散 サービス管理をOpenShiftで一元化 OPENSHIFT kubernetes アプリ更改時の運 用課題解決 ベンダーロックイン 排除 インフラ基盤のモダ ナイゼーション実現 アプリ配置柔軟性 高速開発 運用管理標準化 9 インフラ柔軟性 管理標準化・簡素化CI/CD k8s DBサーバ RDB APサーバ サービス サービス REST JDBC k8s マイクロサービス マイクロサービス ノード REST REST ノード サービス化 COBOL サービス化 COBOL サービス化 COBOL レガシー COBOLサービス SOAP クラウド基盤1 k8s マイクロサービス マイクロサービス REST REST table k8s クラウド基盤2 k8s マイクロサービス マイクロサービス REST REST table 業務拡大時のN/W 帯域確保 モノリスアプリの 弊害除去 既存環境から低リス クで移行
- 10. ハイブリッド・クラウド化のインフラ的新要件は？ • 分散環境コンピューティングへの移行 ➢ 稼働時間、N/Wレイテンシー、セキュリティ維持 ➢ 即応性、柔軟性、拡張性（デプロイ、スケールアウト、無停止ロールアウト） • 非機能要件全般が変化 • インフラ-アプリの境界 • 24/365での業務運用前提 • N/W要件 • ロードバランサーの一部機能はコンテナ（アプリ層）に移行 • コンテナアプリのユーザーデータを永続化するためのストレージ ➢ 物理ストレージ装置、SDS、クラウドサービス • 分散DB環境 ➢ DB連携の必要性 • 新しいOSS ➢ k8s, NoSQL • 運用管理要件 • アジャイル、CI/CD（１～2週のイテレーションサイクル） • 問題判別 • メータリング・課金体系10
- 11. これから、 インフラ担当者が考えるべきことは・・ ・インフラのビッグピクチャーをつくる （アプリチーム・LOBと協業で） ・非機能要件全般の再検討 （ハイブリッドクラウド前提） ・アプリ・インフラ境界線の再定義 （インフラ・アプリチームの境界線） ・運用管理の再構築 （クラウド・オンプレで共通化） ・マイクロサービス前提のストレージ （SDSなど） ・データ連携手法の検討 （複数データレイク間） ・セキュリティ （ハイブリッド・クラウド前提） ・DevOps （ツール導入など） ・人材育成、組織変革 （CI/CD、DevOpsの定着） 11