1.コンテナプラットフォームの戦略的選択

Transcript

1. コンテナプラットフォームの戦略的選択 コンテナ情報戦国時代から平和な世界に 1
2. SIOS Technology, Inc. 講師紹介 2 - 講師紹介 Name ：前田周哉 Company ：サイオステクノロジー株式会社 Dept ：DX Product & Integration Service Line Task 主にOpenShift等のコンテナプラットフ ォーム関連の技術担当
3. SIOS Technology, Inc. SIOSDX コンテナの窓口 OSSの技術力やナレッジ、海外拠点を保有する強みを活かし、 コンテナビジネスに特化した「コンテナ・プラットフォーム事業」を2019年11月に立ち上げ DX推進におけるコンテナ技術について、なんでも相談できる窓口となることを旗印としています 日本のDXが他国に比べ進まぬ理由 ❖ まだ人が働いていてソフトウェアが働いていない ❖ データの活用がビジネスになっていない 要するにソフトウェアが動作するインフラ基盤が整っていない 3
4. SIOS Technology, Inc. 現状はコンテナ情報戦国時代 コンテナにかかわる情報は多く出ています。たくさんの兵器（商材）が出現して は消えていき、いろんな国（EKS、GKE、IBMクラウド。。。。,OpenShift）が、 我は我はと競い合っています。世はまさにコンテナ情報戦国時代です。 はたして、この戦国時代に争うのが正しいのでしょうか？ 争わないで正しくルールや指標を決めて競い合うのが、平和への道筋なのではな いのでしょうか？ コンテナ 4
5. SIOS Technology, Inc. 平和への道筋 コンテナプラットフォームの平和な世界に至るためには、 いろいろなルールや基準、規格を作ればいいのではと考えました。 ここでは平和な世界を作るために下記モデルを理解していき、コンテナプラット フォームの選択ができるようになりましょう • Kubernetes成熟度のモデル ◦ クラウドネイティブ ◦ Cloud Native Trail Map ◦ マイクロサービス成熟度 ◦ SaaS成熟度モデル 5
6. SIOS Technology, Inc. Red Hat OpenShift は、エンタープライズ向けオープンソースのコンテナ・オーケストレーション・プラットフォーム • コンテナの関係性 ◦ OpenShift(コンテナプラットフォーム『CP』)はKubernetes(コンテナオーケストレーション）を内包 ◦ Kubernetesはコンテナを内包 コンテナプラットフォームとは？ OpenShiftを例に考える コンテナ （プログラムの部品） Kubernetes コンテナオーケストレ ーション (コンテナ自体を運用） OpenShift コンテナプラットフォ ーム (商用運用するためのいろ いろな機能を内包） 6 • コンテナプラットフォームは ◦ クラウド、ベアメタルという 基準はありません。 ◦ マネージド、セルフマネージ ド両方あります。 • CPのわかりやすい一例 ◦ Kubernetesにはコンテナを保管する コンテナレジストリが存在しません ◦ CPにはコンテナレジストリがあり ます
7. SIOS Technology, Inc. Kubernetesとは？ • Kubernetesはコンテナオーケストレーションのデファクトスタンダード ◦ コンテナオーケストレーションはなぜ必要か？ ▪ コンテナの数が10個程度であれば、死活監視やバックアップも従来通り手動 で管理可能、しかし10万以上のコンテナを俗人的に管理することは、運用コ スト等の観点で現実論として難しい ◦ コンテナオーケストレーションはコンテナを動的に管理するツール ▪ 概要：運用者の負担を減らし、コンテナを素早くサービスとして提供 ▪ 機能：コンテナのスケジューリング、インフラの抽象化、コンテナのセルフ ヒーリング 7
8. SIOS Technology, Inc. Kubernetesに対応した製品と主な形式 8 • マネージドサービス型のKubernetes ◦ 代表的な製品: GKE,AKS,EKS,IBM Cloud Kubernetes Service ▪ 主な特徴 ▪ アベイラビリティゾーンなどを利用することでマスターノードの可用性が動的に担保される ▪ GUIを使用して、ノードを簡単にスケールアップできる ▪ 従来のパブリッククラウドのマネージドサービスと連携したサービス提供ができる • セルフサービス型のKubernetes ◦ 代表的な製品: Red Hat OpenShift ▪ 主な特徴 ▪ Kubernetes上でコンテナを開発運用するための支援ツールが同梱されている ▪ GUIを利用してKubernetesの運用管理やアプリケーション開発が行える ▪ どの環境でも同じ手順でアプリケーションの開発や展開が行える • Kubernetes クラスタ管理 ◦ 代表的な製品: Rancher, Mesophere ▪ 主な特徴 ▪ 複数の環境下におけるKubernetesのリソース利用状況を統合的に把握することができる。 ▪ GUIを利用してクラスタの追加や、リソースの提供が行える ▪ 主にKubernetes のリソース状況管理に特化している
9. どのようにCPを選択していくのか？ ~Kuberenetes成熟度から考察~ 9
10. SIOS Technology, Inc. Kubernetes成熟度モデル Kubernetes成熟度モデルはFairwinds社が出している７つのフェイズに別れてい るモデル、Kubernetesを採用時の複雑化による迷走を防ぐためのモデルの一つ 期待される効果 • エンジニアの作業の明確化 • クラウドネイティブの段階把握 • Kubernetes環境の改善 利用 • 段階的に対応 10 図 Kubernetes成熟度モデル
11. SIOS Technology, Inc. Kubernetes成熟度モデルの７つのフェーズ 段階 状態 わかりやすい段階 簡易内容 0 準備 学習段階 コンテナの価値やコンテナオーケストレーションの価値を考える状態で、コンテナの基本コマンドが可能に なること、ビジネスメリットを把握すること 1 変換（コンテナ化） 概念検証段階 アプリケーションのコンテナ化を行いKubernetes環境にデプロイする段階 2 展開 オープンテストの段階 kubenetesのデプロイ環境を情報共有、CI/CD等のデプロイプロセスの実装やモニタリングの実装 3 標準化 商用利用の段階 商用運用における非機能要件の安定化、セキュリティやキャパシティの管理を行う 4 改善 複数組織利用開始の段階 複数組織としてKubernetesを利用する段階で、安定したCI/CDの利用、Kubernetesを使ったリソースの有効 活用 5 コントロール 複数組織で標準利用と管 理の段階 ワークロードの安定化、ネットワークポリシー,セキュリティ、権限の標準化 6 自動化 最高の環境段階 デプロイ設定ミスの自動監査や監視障害対応を自動化、例）operatorを使った自動化 11
12. SIOS Technology, Inc. 考察 Kubernetes成熟度モデルの関係マトリックス フェーズ 状態 関係規模 アプリケーシ ョン数 おすすめコンテナ基盤 0 準備 個人 0 触りやすい環境ならどれでもよい 1 変換（コンテ ナ化） 1チーム 1 minikube等の自作サーバ クラウドマネージドサービス 2 展開 複数のチーム 少数 クラウドマネージドオーケストレー ションサービス 3 標準化 組織 複数 IBM Cloud KuberneteやCocktail Cloud等のベンダーマネージドサー ビス 4 改善 複数の組織 多い OpenShift 5 コントロール 複数の組織 とても多い OpenShiftとクラスター管理サービ ス 6 自動化 ∞ とても多い OpenShiftもしくセルフコンテナプ ラットフォーム 12
13. Kubernetes成熟度モデル フェーズ０の考察 13
14. SIOS Technology, Inc. 成熟度モデル フェーズ０についての考察 • フェーズ０は『準備』の段階 ◦ フェーズ０の状態 ▪ どこから始めればいいのか、誰にたのむのか、どのように価値を証明するか を考える ◦ 目標 ▪ 『クラウド ネイティブ』と 『Kubernetes』 がビジネス目標と技術目標の推 進にどのように役立つか、さらにコストと組織全体の目標について合意 • クラウドネイティブ、コンテナ、Kubernetesの価値を理解する • この価値をビジネスリーダーに説明できる • チーム、リーダー、組織全体から賛同を得る 14
15. フェーズ０ 準備段階について（フェーズから） • 前提条件 ◦ Kubernetesの有用性を理解 ◦ OSSを使う利点と知見 ◦ Kubernetesに関しては時間とお金への投 資の必要性を理解 • 達成するには ◦ クラウドネイティブの有効性の理解 ◦ コンテナの理解 ◦ Kubernetesの理解 ◦ IACの理解 ◦ 文化とビジネスの変化を理解 • 成果 ◦ 成功のためビジネス側やリーダー側の賛同 ◦ 文化的かつ機能横断的なワークフローの変更を認識 ◦ 多額の投資と新しいテクノロジーへの信頼が必要性 を認識 ◦ クラウドネイティブにおけるOSSの役割と力を理解 ◦ 取得したい価値を考慮し定義する必要があると理解 ◦ ビジネスの優先順位で判断が必要と理解 ◦ セキュリティ、効率、信頼性に関する必要性を理解 15
16. SIOS Technology, Inc. フェーズ０ クラウドネイティブの定義と比較 クラウドネイティブとは • CNCFのクラウドネイティブの定義 ◦ 回復性、管理力、および可観測性のある疎結合システムと、堅牢な自動 化を組み合わせることにより、システム変更を最小限の労力で、頻繁か つ予測通りに行う設計思想 • クラウドファーストではない ◦ クラウドファーストとは ▪ システムを構築する際に独自のインフラ構築やアプリケーション開発を極力おさえ、事業 者が提供するパブリッククラウドサービスであるSaaSやIaaS、PaaSを利用することを第 一に考えること 16
17. SIOS Technology, Inc. フェーズ０ クラウドネイティブ考察 クラウドネイティブではない状態 • ただクラウド技術を使っているだけ ◦ 仮想マシンやストレージの払い出しツールとしてクラウドを利用している状態 • クラウド特性を設計や運用に反映してない ◦ クラウド特性を理解しないまま、各クラウドの機能に対してオンプレミスでできる 設計と比較する状態 • 役割と運用プロセスが変わらない ◦ アプリ開発者とインフラ運用者が、従来のデリバリプロセスと役割のままクラウド 化することでかえって管理対象が増える状態 • 手作業の運用プロセスに依存 ◦ クラウドのAPI等を利用した自動化を行わずに、手作業プロセスから離れられずク ラウド管理の俗人化や、人手不足を招いている状態 17
18. フェーズ0 Cloud Native Trail Mapから考察 参照元:Cloud Native Trail Map CNCFが進めるクラウドネイティブに至る道筋 1. コンテナ化 2. CI/CD 3. オーケストレーション＆アプリケーショ ン定義 4. 可観測性と分析 5. サービスプロキシ、ディスカバリ＆メッ シュ 6. ネットワーク＆ポリシー 7. 分散データベース/分散ストレージ 8. ストリーミング＆メッセージング 9. コンテナレジストリ＆ランタイム 10. ソフトウェアディストリビューション Trailmap 18
19. SIOS Technology, Inc. フェーズ０ クラウドネイティブからの考察 • 考察結果 ◦ 変化に優れた形にはKubernetesは有用 ▪ 従来の作りきりモデルではなく、クラウドネイティブの変化に優れた形にす るためにはKubernetesは有用です ◦ 早めからKubernetesの利用をおすすめ ▪ KubernetesはTrail mapでは３番目のオーケストレーションであるため、ある 程度早い段階からオーケストレーションを使う必要が出てきます ◦ 考慮が多い ▪ クラウドネイティブな状況を作るには、現在以上に多くの考慮観点が必要で す ◦ コスト計算は、ランニングコスト以外も計算が必要 ▪ 長い道のりのため、学習コストの考慮が必要。自分で全部学んで用意し運用 するか、他のアプリケーションを利用するかは考慮する必要があります 19
20. マイクロサービス成熟度について • マイクロサービス成熟度とは ◦ モノリスな環境からマイクロサービス環境 への成熟していく段階を示したもの ◦ 全部で7段階 ◦ 参照元 日経SYSTEMS2019年4月 • マイクロサービスとは ◦ ソフトウェア開発の技法の1つであり、１ つのアプリケーションをビジネス機能に沿 った複数の小さいサービスの疎に結合され た集合体として構成するサービス思考アー キテクチャの一つ 20 モノリス 大きなビジネスロジックで すべての処理を行う マイクロサービス ビジネスロジックを組み合 わせて処理を行う モノリス すべて同一サーバ上に配置 それぞれ自由にサーバー上 に配置 マイクロサービス
21. SIOS Technology, Inc. 抜粋 マイクロサービス成熟度 レベル 項目 概要 1 モノリス 機能間は蜜結合しており、一つの塊として管理されている、機能の変更には膨大な時間がかか る 2 API連携 変更にスピードを求められる機能がサービスとして切り出されており、別インスタンスで稼働 し、API連携している。データベースは共有しており、一部の変更には時間がかかる 3 いくつかのサービス 認証認可やログなどの基盤が整備され、一部ではCI/CDによる自動デプロイも行われている 4 マイクロサービス 新しい機能はサービスとして作られており、データベースの分離が実現されている。非同期メ ッセージングやブルーグリーンデプロイメントを利用することでシステム全体が無停止を担っ ている 5 高度なマイクロサービス コンテナオーケストレーションを利用し、数十～数百のサービスを管理している 6 先進的なマイクロサービス 数百～数千のマイクロサービスを運用し、非同期ストリーミング、サービスメッシュ、イベン トソーシングなどが行われている 7 世界最先端のマイクロサービ ス 自社でマイクロサービスを運用するためのソフトウェアを開発し、それによって高度な運用を 実現している 21
22. SIOS Technology, Inc. 考察 マイクロサービス成熟度における コンテナオーケストレーションの必要性 レベル 項目 概要 1 モノリス 機能感は蜜結合しており、一つの塊として管理されている、機能の変更には膨大な時間がかか る 2 API連携 変更にスピードを求められる機能がサービスとして切り出されており、別インスタンスで稼働 し、API連携している。データベースは共有しており、一部の変更には時間がかかる 3 いくつかのサービス 認証認可やログなどの基盤が整備され、一部ではCI/CDによる自動デプロイも行われている 4 マイクロサービス 新しい機能はサービスとして作られており、データベースの分離が実現されている。非同期メ ッセージングやブルーグリーンデプロイメントを利用することでシステム全体が無停止担って いる 5 高度なマイクロサービス コンテナオーケストレーションを利用し、数十～数百のサービスを管理している 6 先進的なマイクロサービス 数百～数千のマイクロサービスを運用し、非同期ストリーミング、サービスメッシュ、イベン トソーシングなどが行われている 7 世界最先端のマイクロサービ ス 自社でマイクロサービスを運用するためのソフトウェアを開発し、それによって高度な運用を 実現している コンテナオーケストレーション必須 コンテナオーケストレーションなしでも可 22
23. SIOS Technology, Inc. 考察 マイクロサービス成熟度別おすすめ基盤 レベル 項目 概要 おすすめの基盤 1 モノリス 機能感は蜜結合しており、一つの塊として管理されている、機能の変 更には膨大な時間がかかる VMや仮想サーバ、ECS等のコンテナマネージド, IBM Cloud Code Engine等のコンテナサーバレス 2 API連携 変更にスピードを求められる機能がサービスとして切り出されており、 別インスタンスで稼働し、API連携している。データベースは共有して おり、一部の変更には時間がかかる APIGWサービスとの連携した環境、VMや仮想サーバ、ECS等のコン テナマネージド、EKS等のマネージドオーケストレーションサービス 3 いくつかのサー ビス 認証認可やログなどの基盤が整備され、一部ではCI/CDによる自動デプ ロイも行われている EKS等のマネージドオーケストレーションサービス、IBM Cloud Kubernetes ServiceやCocktail Cloud等のベンダーマネージドサービ ス,OpenShiftマネージドサービス 4 マイクロサービ ス 新しい機能はサービスとして作られており、データベースの分離が実 現されている。非同期メッセージングやブルーグリーンデプロイメン トを利用することでシステム全体が無停止を担っている OpenShiftマネージドサービス(Red Hat OpenShift on IBM Cloud)、 Cocktail Cloud等のベンダーマネージドサービス、EKS等のマネージド オーケストレーションサービス 5 高度なマイクロ サービス コンテナオーケストレーションを利用し、数十～数百のサービスを管 理している OpenShiftマネージドサービス、OpenShiftセルフマネージド、 Cocktail Cloud等のベンダーマネージドサービス 6 先進的なマイク ロサービス 数百～数千のマイクロサービスを運用し、非同期ストリーミング、サ ービスメッシュ、イベントソーシングなどが行われている OpenShiftマネージドサービス、OCPやkubernetsのセルフマネージド kubernetsをカスタマイズした物 7 世界最先端のマ イクロサービス 自社でマイクロサービスを運用するためのソフトウェアを開発し、そ れによって高度な運用を実現している OCPやkubernetsのセルフマネージドkubernetsをカスタマイズした物 23
24. SIOS Technology, Inc. SaaS成熟度モデルから （参照） SaaS成熟度モデルとは • SaaSアプリケーションを、複数のお客様が利用するときのアプリケーショ ン構成の成熟度を表したモデル ◦ Dharmesh氏が提唱 ◦ 全部で5段階 • SaaS成熟度モデルを把握すると ◦ コンテナ化の移行方式がわかりやすくなる 24
25. SIOS Technology, Inc. フェーズ０ SaaS成熟度モデルから SaaSアーキテクチャの成熟度モデルについて記載されたもの 参照元 レベル 段階 説明 0 Chaos 新規の顧客を追加するたびにソフトウェアの新規のインスタンスを追加する 1 Managed Chaos 全顧客が単一バージョンのソフトウェアで実行し構成を通じてカスタマイズされる 2 Multi-Tenant,Highrise 全顧客が単一のバージョンのソフトウェアで実行し、原則的に1つの「インスタンス」で実行し ている 3 Multi-Tenant,Build-Out 複数のテナントがあり、ソフトウェアモデルの単一バージョン。しかし、スケールアウト可能 4 Utopia レベル3のようなものである。ただし様々な「インスタンス」で様々なバージョンのソフトウェ アを実行する効率的な方法を見だしている 25
26. SIOS Technology, Inc. コンテナにおけるアプリ移行戦略 移行手法 説明 課題 リホスト（リフト＆シフ ト） 基本はコードの修正は行わず、既存のアプリを そのまま新しいプラットフォームに移行 移行後に、根本的なアーキテクチャ 改善が必要になる リライト ビジネスロジックは維持し、ツールを活用して ソースコードを置き換える。または再設計する ツール対応できない場合など、移行 にコストがかかる可能性がある リプレース パッケージシステムやSaaSなどを利用して、 既存アプリを全面刷新する 従来のシステムと異なるため機能面 の制約が生じる リビルド すべて１から作り直す 時間とコストがとてもかかる 26
27. SIOS Technology, Inc. フェーズ０ SaaS成熟度モデルから それぞれのマイグレーション戦略を考察 レベル 段階 説明 コンテナ効果の即効性 マイグレーション戦略 0 Chaos 新規の顧客を追加するたびにソフトウェアの新規 のインスタンスを追加する 高 リホスト（リフト＆シフト） 1 Managed Chaos 全顧客が単一バージョンのソフトウェアで実行し 構成を通じてカスタマイズされる 高 リホスト（リフト＆シフト） 2 Multi- Tenant,H ighrise 全顧客が単一のバージョンのソフトウェアで実行 し、原則的に1つの「インスタンスで」で実行し ている 低 リホスト（リフト＆シフト） リライト リプレイス リビルド 3 Multi- Tenant,B uild-Out 複数のテナントがあり、ソフトウェアモデルの単 一バージョン。しかし、スケールアウト可能 低 リライト リプレイス リビルド 4 Utopia レベル3のようなものである。ただし様々な「イ ンスタンス」で様々なバージョンのソフトウェア を実行する効率的な方法を見だしている 低 リライト リプレイス リビルド 27
28. SIOS Technology, Inc. 余談 ビックバン方式の移行は避けましょう • クラウドネイティブでコンテナ化を考えるとき ◦ ビッグバン方式 ▪ 必要な機能を一括で変更する方式 • 不幸になるのでやめたほうがよい ◦ 部分マイクロサービス化 ▪ 一部のサービスをマイクロサービス化して、最終的に全体をマイクロサービ ス化する方式 • マイクロサービスの粒度をきめるのも難しい • マイクロサービスは試行錯誤で作っていくもの 28
29. SIOS Technology, Inc. フェーズ０の複数の観点からまとめてみる • コンテナ化＝コンテナオーケストレーション利用ではない ◦ コンテナ化（開発時にコンテナ環境利用）しても、昔ながらのモノリス 形態の場合はクラウドネイティブ化されていないため今後の変更対応が 難しい • コンテナ化とマイクロサービス化の両面で進めたほうが良い ◦ コンテナ化とマイクロサービス化の両方を進めた場合にコンテナオーケ ストレーションとクラウドネイティブの価値はでてきます • クラウドネイティブにふさわしい体制がある ◦ 既存プロセスが自動化されていくため、既存の組織体系や運用プロセス を変える必要があります • Kubernetesを成熟させていくには時間と費用がかかる ◦ 複数のことを考慮して決めていくため、成熟させていくためには時間と 費用がかかるります 29
30. SIOS Technology, Inc. 余談 変更の対応が早いのが全部よいか？ • クラウドネイティブが万能というわけでもない ◦ モード２で使うにいい構成がでてきたというだけ、ビジネスに会った対 応を考える必要がある。 ▪ 安定なら既存のモード１であるITILのほうがよい ▪ 速度重視ならモード２のほうがよい 30 Mode１ Mode2 システムのタイプ SoR SoE 方向性 安定性重視 速度重視 サービス変更管理 ITIL DevOps 変更の数 少な目 多め
31. SIOS Technology, Inc. フェイズごとに必要な商材を考えて、 商用運用しながら順次考えていく 段階 状態 わかりやすい段階（日本 向け） 簡易内容 0 準備 学習段階 コンテナの価値やコンテナオーケストレーションの価値を考える状態で、コンテナの基本コマ ンドの可能になること、ビジネスメリットを把握すること 1 変換 （コンテナ化） 概念検証段階 アプリケーションのコンテナ化を行いKubernetes環境にデプロイする段階 2 展開 オープンテストの段階 kubenetesのデプロイ環境を情報共有、CI/CD等のデプロイプロセスの実装やモニタリングの実 装 3 標準化 商用利用の段階 商用運用における非機能要件の安定化、セキュリティやキャパシティの管理を行う 4 改善 複数組織利用開始の段階 複数組織としてKubernetesを利用する段階で、安定したCI/CDの利用、Kubernetesを使ったリ ソースの有効活用 5 コントロール 複数組織で標準利用と管 理の段階 ワークロードの安定化、ネットワークポリシー,セキュリティ、権限の標準化 6 自動化 最高の環境段階 デプロイ設定ミスの自動監査や監視障害対応を自動化、例）operatorを使った自動化 31
32. SIOS Technology, Inc. Kubernetes成熟度モデルを考えるに • フェーズ0以降もそれぞれで考慮と対処が必要 ◦ フェーズごとに改善点を段階的に考慮しましょう ◦ 簡単に次のフェーズにいけないことを考慮しましょう ▪ フェーズ0でも多くのことを考えますが、それぞれのフェーズでもたくさん 考慮します。 • ビジネス目的を明確にすることが必要 ◦ 単純な開発から、運用＆リリースしながら開発する前提のモデル ◦ ビジネス目標のためにいろんな費用といろんな方法から考える必要 ▪ 最初からフェーズ６を満たす環境を構築していくのかどうか？ ▪ 自分たちのチームだけで行うのか、ほかの専門家と協力して行うのか？ ▪ 導入するためのビジネス優先順位は何か、リリース速度？低コスト？ 32
33. 最後に 33
34. SIOS Technology, Inc. コンテナプラットフォームの戦略的選択 34 • コンテナプラットフォームの戦略的選択 ◦ 下記を考慮する必要があります。 ▪ アプリケーションの更新や変更頻度 ▪ アプリケーションのクラウドネイティブの状態 ▪ コンテナプラットフォームで取り扱うサービスの数 ▪ 既存のモノリスアプリケーションからの移行 ▪ 自動化等を含んだ体制の選択 ◦ 最初に全部決めていくのは難しいためビジネス戦略的な選択が必要にな ります。エンジニアのみに任せて選択するのは難しく、エンジニア以外 の考慮を優先させていく必要があります。
35. SIOS Technology, Inc. コンテナプラットフォームの規格・・・ 35 平和な世界のためにコンテナプラットフォームの規格を考えようとしました • コンテナプラットフォームを選択するには一面から選択は難しい ◦ サービスの数、今後の可能性まで考慮が必要 • 残念ながらコンテナプラットフォームの規格化まではまだ時間が必要 ◦ 考慮点が多く、安定した規格化ができるのは先のことです ◦ 更新や変更も多いため、安定するのを待つのは得策ではない • 変更が前提の考え方で対応 ◦ 安定したものではなく、変更が前提という考え方をビジネス面、技術面で対応するこ とがよい ◦ いろんなモデルを参考にしながら、優先順位を決めて段階的に対応していく ◦ コンテナプラットフォームを一度選択しても、状況で変更があるという前提で進む
36. サービス紹介 36
37. SIOS Technology, Inc. SIOSDXコンテナプラットフォームコンサルティングサービス ご支援に関する3形態のサービスをご用意 37 インシデント型 問い合わせサービス コンサル型技術支援 サービス コンテナエンジニア育成 トレーニングサービス コンテナ化行う上での情報支援をQA対応 数・対応時間に合わせたインシデント形式 でご支援を行います。 こちらのサービスでは一般的な技術情報や 構成にベストプラクティスなどの 問い合わせをメインのスコープ としております。 コンテナ化行う上でのよりサービスに 準じた技術検証やアーキテクチャの ご支援を行います。 こちらのサービスではプリセットとして 存在するコンテナ環境の導入やサービス の性質に有ったコンテナ検証環境の構築 をメインのスコープとしております。 コンテナを扱うエンジニアの育成を目的と したトレーニング(docker,k8s) のご支援を行います。 こちらのサービスでは1~2ヶ月を目途とし た期間で(docker,k8s)それぞれのコンテナ 技術習得を目的としたトレーニングを提供 させていただきます 短期～中期 短期～中期 中期〜長期 コンテナ化対応時期イメージ
38. SIOS Technology, Inc. DXSLが企画運営するSIOSDXサイトにて最新 情報を発信中です。 ビジネストピックスから技術トピックスま でDXとコンテナに関わるあらゆる情報を発 信していきます。 公演や執筆の依頼についても承りしており ますので、お気軽にご相談ください。 SIOSDX URL：https://container.sios.jp/ ポータルサイト SIOSDXのご紹介
40. 紹介サービス情報（発表参照情報） 40
41. SIOS Technology, Inc. もしCPに悩んだら 41 IBM協創センター無料枠を利用して触ってみるのがおすすめ • マネージドサービス ◦ RedHatOpenShift on IBM Cloud おすすめ ◦ IBM Cloud Kubernetes Service ◦ IBM Cloud Code Engine • 知らない人がCPのメリットを直観するには ◦ OpenSfhitのカタログを使って、数クリックでデプロイできる環境を試し てみるのが一番おすすめな方法です。 ◦ CP学習するときにはいろんな方法がありますがメリットを直観するには カタログを使ってみることをおすすめします。 ▪ コンテナの基礎理解ー＞アプリケーションのコンテナ化ー＞マニフェストの 理解 ▪ カタログやオペレーターからのデプロイ-> マニフェスト修正
42. SIOS Technology, Inc. 42
43. SIOS Technology, Inc. Sysdig Secure DevOps Platform 43 Sysdig Secure DevOps Platformとは セキュリティとコンプライアンス をパフォーマンスおよびキャパシ ティモニタリングと統合すること によって、セキュアな DevOps ワークフローを実現します
44. SIOS Technology, Inc. 補足 参考サービス 44 • アプリケーションのパフォーマンス最適化 ◦ StormForge • kubernetesプラットフォーム ◦ Cocktail Cloud • コンテナプラットフォーム ◦ Red Hat OpenShift • セキュリティ・モニタリングプラットフォーム ◦ Sysdig SecureDevOps Platform