デブサミ2017【17-e-5】エンタープライズにおけるdevopsの実態!cloud native...

エンタープライズにおけるDevOpsの実態!-Cloud Native Application Platformの選択-

Developers Summit 2017 【17-E-5】ハッシュタグ: #devsumiE日本ヒューレット・パッカード株式会社北山晋吾

2

自己紹介

元楽天株式会社所属国際ECサービスのインフラ部門

日本ヒューレット・パッカード株式会社所属テクニカルアーキテクトテクノロジーコンサルティング事業統括クロス・インダストリ・ソリューション統括本部テクノロジーアーキテクト部

好評発売中

http://amzn.asia/ghfpKwi

2016年末「Ansible実践ガイド」執筆

北山晋吾

経歴など

もーど１のかお

shkitayama spchildren

3

本日のAgenda

1. バイモーダルITへの挑戦2. 組織構造の改革3. プラットフォームの改革4. まとめ

4


5

2017年エンタープライズは何が変わったのか!?

Transformto Digital Business

6

2017年デジタルビジネス時代

アイデアエコノミーのビジネストラディショナルなビジネス

バイモーダルITへの対応

サービスコスト効率化・堅牢性重視

顧客主にシステム部門

競合国内大手IT SIer

サービススピード、流動性重視

顧客主に事業部門

競合海外大手クラウドベンダー

デジタル・ビジネスとは、仮想と物理の世界を融合して人／モノ／ビジネスが直接つながり、顧客との関係が瞬時に変化していく状態が当たり前のビジネス形態のこと。

27.3%

11.5%

28.5%

17.6%

13.3%

7参照: https://www.gartner.co.jp/press/html/pr20161118-01.html

日本企業のデジタル・ビジネスの現状

全く取り組んでいない

その他

日本企業のデジタルビジネスへの取り組み出展：ガートナー2016/08 (n=165)

既に一定数の企業がデジタル・ビジネスに取り組んでいるものの、成果が挙がっている企業は一部。

部門レベルでは取り組んでいるが成果は出ていない

全社レベルで取り組んでいるが成果は出ていない

全社レベルで取り組んでおり、成果が挙がっている

部門レベルで取り組んでおり、成果が挙がっている日本企業の約70%がデジタルビジネ

スに取り組んでいるものの、成果が挙がっ

ているのは全体の25%程度。25%

8

バイモーダルITとは

そもそもバイモーダルITとは、企業システムの特性を分けて適切なリソースを配分するための概念

Mode1 従来型の企業ITに不可欠な堅牢性を維持するMode2 ビジネスイノベーションに対応する俊敏性を実現する

Gartnerによるカテゴリ Mode1 Mode2

ジェフリー・ムーア氏の提唱 SoR (System of Record) SoE (System of Engagement)

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

トラディショナルアプリケーション

(Monolithic Architecture)

クラウドネイティブアプリケーション

(Microservice Architecture)

システム特性正確性、安全性、堅牢性迅速性、柔軟性、スケーラビリティ

開発手法ウォーターフォール型アジャイル型

投資判断ポイント投資対効果(ROI)に基づいた投資業務システムの維持とコスト削減

ビジネスチャンスに基づいた投資新たなチャレンジ

顧客提供価値 ITセントリック、効率性ユーザー体験、スピード

人材とスキル信頼性、コスト効率化重視試験的な取り組みを重視

Mode2

9

バイモーダルITの捉え方

Mode1・WebシステムWeb系企業

・基幹システム銀行、通信などSIerが得意とする業界

業界や企業単位で区切ることは、あまり意味がない。

どのサービスにおいても、Mode1の要素とMode2の要素があり、そのリソース配分を設計するための枠組み。

Mode1/Mode2のリソースの分類基準は、ビジネスのスピードとスケールの違い。

Mode2

Mode1 Mode2

Mode1

サービスサービス

企業

サービスが成功すると、安定を優先せざるを得ない(金のなる木事業)

サービスが成功するまでは、スピードと柔軟性に対応(スター事業)

10

バイモーダルITの本質

バイモーダルなシステムを目指すことは重要だが、本質的には組織の問題である。

教科書的な示唆堅牢性と流動性の双方の要素を分けて、バイモーダルITに取り組むべきである。

以下のような価値観は不適切…・Mode1からMode2へ移行しないといけない。(Mode1からMode2に移ることはない。)・Mode2の業界だから、Mode1のシステムは関係無い。

本質的な示唆自社の業務やシステムのMode1 / Mode2の比率に合わせて、組織構造(人的リソース)やプラットフォーム(システムリソース)の割合を調整するべきである。

11

バイモーダルITで再分配すべきリソース

いままでと同様のリソース配分で投資を行っていては、バイモーダルの特徴を活かすことができず、プロジェクトが進まない。

アプリケーションから生成されたデータを、自社のITのために利用すべきか、顧客満足度向上のために利用すべきかで、異なるノウハウが必要になる。

Mode1では、堅牢性、正確性を重視した開発プロセスに対し、Mode2ではスピードを重視した柔軟な開発プロセスが必要となる。

スケールアップ型のトラディショナルアプリケーションと、スケールアウト型のクラウドネイティブアプリケーションの設計が必要になる。

オンプレミスな環境だけでなく、パブリッククラウドと連携した、ハイブリッド環境を設計することが必要になる。

年度予算ではなく、経営戦略の方針変更に伴い、突然のプロジェクトへの予算を確保できる仕組み(予算のアジャイル化)が必要になる。

Knowledge Process Technology ArchitectureCost

開発プロセス


アプリケーション開発基盤

クラウド基盤

12

これまでのビジネスを支える開発プラットフォーム

これまでは、仮想化環境の上で業務システムの安定稼働とコスト削減を図ることがITのあるべき姿。

ITIL

Monolithic Services

Virtual Machine

Cloud

Biz(事業部門)

開発＆運用(システム部門)

SIer

System

正確性

安全性

堅牢性

Mode1(SoR)

Platform

Mode1

開発プロセス



クラウド基盤

13

バイモーダルを支える開発プラットフォーム

ビジネスの迅速性にあわせてプラットフォームを選択できる柔軟な設計が必要。

DevOps

Micro Services

Containers

Cloud

ITIL

Monolithic Services

Virtual Machine

Cloud

Mode1 Mode2

SIer

Biz(事業部門)

開発& 運用(システム部門)

Biz(事業部門)

Mode1(SoR)

Mode2(SoE)

System

安全性

迅速性

柔軟性

スケーラブル

正確性

堅牢性

Platform

14

バイモーダルITにおける課題

もちろんバイモーダルに対応するためには、適切なリソース配分(組織体系とプラットフォーム)が必要となる。

Biz(事業部門)

SIer

正確性

安全性

堅牢性

SIer

安全性

迅速性

開発& 運用(システム部門)

Biz(事業部門)

Biz(事業部門)

柔軟性

スケーラブル

正確性

堅牢性

Mode1(SoR)

Mode2(SoE)

System

Platform

開発＆運用(システム部門)

SystemMode1(SoR)

Platform

組織構造の改革(トップダウン)

プラットフォームの改革(ボトムアップ)

15




16

組織構造とシステムアーキテクチャ

Mode1とMode2のシステムに対して適切にリソースを展開するためには、システムリソースに合わせた組織構造をとる必要がある。

コンウェイの法則 (Melvin Conway)

システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に模倣した構造を持つ設計を生み出す。

参照: 「System of Record と System of Engagement」 by Naoya Ito

Mode1 (SoR)チーム

Mode2 (SoE)チーム

プラットフォームチーム

事業部門Mode1チーム

標準化して、安定稼働していくことが目標。Mode2チーム

トライアンドエラーで迅速性を高めることが目標。

プラットフォームチーム両者の技術基盤を支えていく。

https://speakerdeck.com/naoya

40.6%

29.4%28.1%

17参照: https://www.gartner.co.jp/press/html/pr20160601-01.html

バイモーダルを推進する組織構成

新組織の立ち上げ組織としての責任／権限を設定できる一方で、予算やリソースを別途確保する必要がある。

従来のIT組織に専門チームを設立取り組みやすさがある一方で、事業部門にプロジェクトの価値や成果をダイレクトに伝えにくい。

タスクフォースの結成事業部門との協業は進む一方で、成果物やゴールが曖昧になりやすい。

従来のIT組織とは別の新組織

従来のIT組織内の専門チーム

事業部門とのタスクフォース

その他

「バイモーダル」なIT組織の構成出展：ガートナー2016/05 (n=160)

バイモーダルを推進する組織構成の多くは、以下の3構成から成り立っている。

バイモーダルを推進するチームの40%は既存のIT組

織から構成されている。

18

既存のIT組織からバイモーダル対応の組織構造へ

バイモーダルにおけるシステムは、信頼性だけでなく、スピードや柔軟性を重視しているため、運用チームに求められる役割が大きく変わる。



プラットフォームチーム

事業部門


システム運用チーム

事業部門

•利用方法についての問い合わせ業務•決まったオペレーションを実施する定常業務•障害対応•システムの管理業務（構成管理やキャパシティー管理など）

•システムの安定性だけでなく、迅速性のあるシステム基盤を設計•運用管理の自動化の仕組みを設計・構築•標準化されたポリシーやルールの整備

バイモーダル対応の組織

運用チームの変化

既存のIT組織

19

プラットフォームチームに必要な人材とは?

20

プラットフォームチームのメンバーに求められる能力

たとえば…。

・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用・デプロイや各種オペレーション自動化ツールの開発、運用・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用

などなど

・サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務・システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用

参照: https://www.mercari.com/jp/jobs/sre/

21

プラットフォームチームのメンバーに求められる能力

たとえば…。

・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用・デプロイや各種オペレーション自動化ツールの開発、運用・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用

などなど

サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務。システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用。

参照: https://www.mercari.com/jp/jobs/sre/

実は、これmercariさんの採用情報...

22

SRE(Site Reliability Engineer)とは

Google のプロダクトやサイトを安定運用する役割り。オペレーションチームによって行われた作業をソフトウェアを利用し、手作業を自動化に代えていくことが求められる。つまり、『すべてがソフトウェアの問題として扱われる』というアプローチを取って作業を行うエンジニア。

サーバー管理者としての役割り

・インフラの自動化・障害対応・システムの維持

ソフトウェアエンジニアとしての役割り

・サイトのパフォーマンスを改善・可用性、スケーラビリティを向上

参照: https://landing.google.com/sre/book.html

23

SREへのステップアップ

いままでオペレーターだった人たちが、急にSREになれるわけではない。ソフトウェア化を推進する中で、価値を生み出し役割りの幅を広げることが重要。

Mode1の延長 Mode2への対応

キャズムの壁

オペレーター構成管理の自動化クラウド基盤の管理アプリケーション

開発基盤の管理アプリ改善

既存のシステムをAnsibleやChefなどの構成管理ツールを利用して、自動化を図り、手作業の工数を削減。

APIを利用したハイブリッドクラウド環境のコントロール。また、OpenStackなどの統合管理ソリューションの利用。

アプリケーションのパフォーマンス改善、オートスケール、動的障害復旧などのサービス品質の向上。

Dockerコンテナの管理やアプリケーションパッケージのトラブルシューティングなどのサービス管理

24

運用チームの意識変化

バイモーダル対応の組織では、アプリケーションの迅速性が求められると同時に、運用チームの意識の変化が鍵となる。



事業部門


事業部門

運用チームの変化

他のチームと共通人材プール。つまり、SREメンバーを増やすと、必然的に開発チームの稼動を減らせることが期待。

SREへのステップ

オペレーター構成管理の自動化クラウド基盤の管理アプリケーション

開発基盤の管理アプリ改善

Site Reliability Engineeringシステム運用

チーム

バイモーダル対応の組織既存のIT組織

25

組織構造の改革のまとめ



バイモーダルを推進する組織構成は、既存組織のメンバーから構成されることが多い。

既存組織のメンバーから構成する場合は、システム運用者の役割りが変わることを意識する必要がある。

既存のシステム運用者が、いきなりSREになれるわけではなく、徐々に対応範囲を広げていくことが求められる。

組織構造の改革には時間がかかるが、これらを変えずにバイモーダルを実践することはできない。

SREの育成

26




27

バイモーダルに対応するプラットフォーム

これらを迅速かつ、柔軟に提供できるプラットフォームがあれば、ビジネスは飛躍的向上する。Cloud Native Application Platformでは、従来のアプリケーションよりも運用工数を減らし、開発工数を上げていくことが求められる。

HWやOSのセットアップ

ランタイムのビルドライブラリの管理


- Cloud Native Application Platform -

開発プロセス



クラウド基盤

28

バイモーダルを支える開発プラットフォーム

Cloud Native Application Platformの選択肢は、「Platform as a Service(PaaS)」または「Container Orchestration」の2つが主流。

DevOps

Micro Services

Containers

Cloud

ITIL

Monolithic Services

Virtual Machine

Cloud

Mode1 Mode2

Cloud Native Application Platformの選択

- PaaS- Container Orchestration

※パブリッククラウドかオンプレミスかは別の話。

- 構成管理の自動化

Cloud Native Application Platformの機能

29

PaaS

コンテナをマルチノード上でスケーラブルに立ち上げるコンテナ管理ツールコンテナで機能するアプリケーションを管理するためには、インテリジェントにクラスタ管理する必要があり、そのためのオーケストレーションが必要。

InfrastructurePrivate Cloud / Public Cloud

Cloud Native Application Platformアプリケーションライフサイクル基盤のプラットフォームアプリケーション実行環境の提供に加え、システム開発におけるソースコードの保存から、リリースまでの一連の流れを含むサービス。コードをリポジトリに登録しておくと、チェックアウト、ビルド、アプリケーションサーバーへのデプロイまでを実行してくれる。

両者が提供する機能・マルチホストコンテナ環境・ルーティングなどの付加サービス・オートスケール、障害検知の仕組み・デプロイ(CI)機能

両者のプロダクト背景は異なるが、機能だけ見ると似ているところに収束している。

Availability (可用性)オートスケールアクセスルーティング自動リカバリ

Security (セキュリティ)テナント管理/分離アプリのアクセス制御

Maintainability (運用/保守性)継続的デリバリ(CI)機能バージョン管理障害検知

Container Orchestration

30

Private Cloud Public CloudHybrid Cloud

PaaSの導入環境とプロダクト

PaaSは独自技術が多くそれぞれ特徴があるが、移植性と相互運用性を提供しはじめている。

商標: それぞれのロゴは、各社/組織団体の登録商標です。

Technology Stack(Open PaaS)

Solution Stack (Proprietary PaaS)

ProprietaryTechnology

Technology Stack

31

Private Cloud Public Cloud

Dockerコンテナ自体がポータビリティがあるため、色が付けづらくソリューションが複雑化している。

Container Orchestrationの導入環境とプロダクト

Hybrid Cloud


Solution Stack

32

Cloud Native Application Platformを導入検討する際のポイント

根本的には、クラウドを選択する際と代わりはないが、間違えて選択するとアプリケーション開発のボトルネックとなってしまう。

運用も含め、社内のケイパビリティだけで補える技術なのか、外部に委託するのか。

プラットフォーム導入の重視したい点が、アプリケーション開発の迅速化なのか、コスト削減なのか。

独自の技術で構成されているのか、もしくはポータビリティのあるデファクトスタンダード技術で構成されているのか。

オンプレ上だけでなく、パブリッククラウド上でハイブリッド展開が可能か。

CAPEXとOPEXが妥当なのか。オンプレ製品でもOPEXがかかるものもある。

Knowledge Process Technology ArchitectureCost

デプロイ環境の確認依存性の確認導入目的の確認ケイパビリティの確認費用対効果の確認

33

(補足) Container Orchestrationの利用状況

Container Orchestrationは、Kubernetesの利用の人気が高まっている。

参照: https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2016.pdf

Container Market Adoption出展: DevOps.com & ClusterHQ 2016/04 (n=218)

Container Orchestrationを検討している企業の

30%はKubernetesを利用している。

34

Today, the community is seeing widespread adoption of Kubernetes, a system with origins at Google that is becoming the de facto standard for open source container orchestration.

現在コミュニティは、オープンソースコンテナオーケストレーションのデファクトスタンダードになっているGoogleのKubernetesの普及を目の当たりにしています。

(補足) Container Orchestrationのデファクトスタンダード

CoreOSがfleetの開発を終了し、代わりにKubernetesを採用することとなった。(February 7, 2017)

参照: https://coreos.com/blog/migrating-from-fleet-to-kubernetes.html

35

PaaSとContainer Orchestrationはどう使い分けるの ?

開発成果物(Artifact)

36

アプリケーションエンジニアの開発成果物

ソースコードのアップロード

言語、フレームワークの選定

ミドルウェアの設定

アプリパッケージの作成

パッケージをデプロイ

(Build Pack)

通常、アプリケーションデプロイのフローでは開発成果物(Artifact)に違いがでてくる。

ソースコードのアップロード

言語、フレームワークの選定

ミドルウェアの設定

コンテナイメージの作成

Dockerイメージをデプロイ

(Docker Image)

PaaS

Container Orchestration

※ただし、近年Docker型のPaaSも増えてきている。

アプリケーションエンジニア


デプロイテスト

37

バージョン管理システム

開発成果物管理システム

チェックアウト

アプリケーション

Infrastructureas code


SRE

アプリケーション開発

構成管理の自動化

コードのコミットビルド

単体テスト開発成果物の管理デプロイ機能テスト

ContinuousIntegrationCIツール

開発成果物の展開機能/結合テスト

アプリケーション単体テスト

applicationcode

ビルド/テスト自動化ツール

IaaS

アプリエンジニアは、アプリのデプロイSREは、VMのデプロイ

Mode1のCIパイプラインと役割り

イメージ化

VMテンプレートの管理


38




アプリパッケージコンテナイメージアプリケーション

エンジニア

SRE


PaaS / Container Orchestration





applicationcode


PaaSContainer Orchestration



NoOps※ソフトウェアによる可用性、スケーラビリティ向上に専念

アプリエンジニアは、アプリのデプロイ


39




アプリパッケージコンテナイメージアプリケーション

エンジニア

SRE


PaaS / Container Orchestration





applicationcode


PaaSContainer Orchestration



NoOps※ソフトウェアによる可用性、スケーラビリティ向上に専念

アプリエンジニアは、アプリのデプロイ

Containerの管理は誰の責任?

40

Cloud Native Application Platformの選択

PaaS

ContainerOrchestration

CIパイプラインにおける現状の責務によって、プラットフォームを選択すると導入が行いやすい。

現状の責務導入後の責務


インフラエンジニア


Site ReliabilityEngineering

- アプリデプロイ - VMの実行管理- リリース作業

- 開発成果物の作成(コンテナイメージ)

- コンテナの実行管理- リリース作業

- アプリデプロイ- VMの実行管理- リリース作業

- VMの払い出し- リソース監視

- 開発成果物の作成(コンテナイメージ.アプリパッケージ)- リリース作業- コンテナ/アプリの実行管理

- 運用の完全自動化- アプリパフォーマンス改善

Dev vs Opsなチーム

DevOpsなチーム

アプリエンジニアにデプロイの操作権限を付与していく

41

コードレポジトリ・GitHub Enterprise・Bitbucket・GitLab

CIツール・Jenkins・Circle CI・Travis CI・Concourse CI

成果物レポジトリ・Jfrog Artifactory・Github Enterprise

コンテナイメージレポジトリ・Docker Trusted Repository

PaaS・Cloud Foundry・Heroku・BluemixContainer Orchestration・Docker Datacenter・Mesosphere・Kubernetes構成管理の自動化・Ansible・Chef

※凡例

手動タスク

自動化タスク

機能テストツール・UFT・Selenium・Appium・JMeter


単体テスト開発成果物の管理デプロイ機能テスト開発環境

CI環境

ステージング環境QA環境

本番環境

利用ツール例

デプロイ機能テストコード反映

コード反映

デプロイリリース

Issue Tracking・JIRA・Redmine

Promote

Promote

開発成果物の管理

開発成果物の管理

CI/CDのプラットフォーム選択

プラットフォームの選択が一番CI/CDのプロセスに影響を及ぼす。

アプリケーションのアーキテクチャおよび非機能要件/運用要件によって選択

42

プラットフォームの改革のまとめ



バイモーダルのうちMode2を支えるプラットフォームは、「PaaS」と「Container Orchestration」が主流。

PaaSとContainer Orchestrationの機能は似ているが、提供可否はベンダーに寄って色があるため、目的にあったものを選択する。

PaaSとContainer Orchestrationは、既存のCIパイプラインの役割りによって導入を選択する。

プラットフォームの選択次第でアプリケーションのアーキテクチャやプロセスが変わる。

現状のプロセスにあったプラットフォームの選択

43




44



2017年デジタルビジネスが加速し、バイモーダルITへの対応が必然となる。

SREの育成と現状のプロセスにあったプラットフォームの選択が必要。

自社の業務やシステムのMode1/Mode2の比率に合わせて、組織構造とプラットフォームの割合を戦略的に配置できた企業が競争優位性を築くことができる。

デジタルビジネス時代で生き残る組織

戦略的リソース配置(逆コンウェイの法則)

45

はじめるには、何からすればいいの?

46

バイモーダルITへのステップ

バイモーダルへのステップは、DevOps導入のステップと同じ。

メンバーの構成

現状分析

ゴールの設定

POCの実施

フィードバック

まずは組織、プラットフォームにおける課題を見つけ、そのボトルネックを探す。

あるべきCIのパイプラインや役割り、システムの構成を計画する。・チーム体制・スケジュール・アーキテクチャ

ゴールに近づけるか否かを判断する材料を集める。・スピード開発・事業部門予算で対応

POCの成功可否で実サービスへの展開を判断・継続的プロセス改善・CI/CDの導入

やるべきことに優先順位をつける

この時点で標準化しない



ユーザーが主導ベンダーと共創

47

Appendix- HPEのバイモーダルソリューション -


HPEのクラウド戦略

Hybrid management

HPE Helion and HPE Partner Professional Services

Traditional workload orchestration cloud-native orchestration

AmazonWeb

Services

Microsoft Azure

Cloud Service

Providers

EucalyptusHPE Helion OpenStack®

Azure Stack

HPE Synergy, HPE ConvergedSystem, HPE CloudSystem, HPE ProLiant

Private or managed clouds

Emerging Platforms

(Mesos, etc.)vSphere

Publiccloud

Publiccloud

Legacy

Existing

HPEのクラウド戦略は、マルチベンダー&ハイブリッド化。Mode1でもMode2でもクラウド層を安定化させることは変わらない。

49

開発成果物の管理形態

中心となるソフトウェア

特徴対応するインフラ

PaaS アプリケーションパッケージ

HPE Helion Stackato • 多様なアプリケーションフレームワークに対応するBuildpackによりソースコードからアプリケーションランタイムを自動ビルド

• ルーティング、ロードバランス、ログ集約などエンタープライズアプリケーションに必要な機能を統合

• バックエンドサービス（DBなど）に接続するためのサービスブローカー

• CIツール（Helion Code Engine）が付属し、シンプルなCI/CDがこれだけで完結

• vSphere,AWS,OpenStack• Azureにも対応予定• CloudFoundry準拠のパブリックPaaS

とのアプリケーション互換性（IBM

Bluemix, NTT-com ECL/Cloudn, Pivotal Web Service, 富士通 K5, GE Predixなど）

ContainerOrchestration

Dockerイメージ Docker Datacenter • Docker Engineの基本機能に、クラスタ管理機能（Swarm）を統合

• Docker社が提供するツールのみでシンプルなコンテナオートメーションが実現できるため導入と管理が容易

• HPE ハードウェア製品（OneView, Synergy）との統合• エンタープライズサポートあり（HPEから販売可能）

• オンプレミス（物理、仮想、プライベートIaaS）

• パブリックIaaS上の仮想マシンインスタンスをホストとして構築することも可能

Mesosphere DC/OS • OSSのApache Mesosを中心に管理ツールを統合し、エンタープライズ向けアプリケーション実行環境としてパッケージング

• パブリックIaaSへの対応にも力を入れており、大規模ハイブリッドクラウド環境に最適

• エンタープライズサポートあり（HPEから転売可能）

• オンプレミス（物理、仮想、プライベートIaaS）

• パブリックIaaS上の仮想マシンインスタンスをホストとして構築することも可能

• パブリックIaaS上のマネージドサービスとしても利用可能

Kubernetes • Google社のアプリケーションプラットフォーム（Borg）のアーキテクチャをOSS化。現在Cloud Native Computing Foundationが強力に推進

• Pokemon Goで実証されたスケーラビリティ• OSS（各Linuxディストリビューションのサブスクリプションサ

ポート）

• 各種Linux OS上でOSSとして利用可能• ホストのオーケストレーションツー

ル（Terraformなど）と統合するとさらにソリューションを強化できる

HPEが提供するのCloud Native Application Platform

50

Helion Stackato 4のアーキテクチャ

51

HPEが提供するプロフェッショナルサービス

52

一緒に、デジタルビジネス時代を楽しみましょう。

Thank you

54

参考文献

CONTAINER MARKET ADOPTION SURVEY A Joint Production of: 2016https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2016.pdf

Gartnerhttps://www.gartner.co.jp/press/html/pr20160601-01.html

System of Record と System of Engagement by Naoya Ito

https://speakerdeck.com/naoya/system-of-record-to-system-of-engagement