Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
エンタープライズにおけるDevOpsの実態!
-Cloud Native Application Platformの選択-
Developers Summit 2017 【17-E-5】
ハッシュタグ: #devsumiE
日本ヒューレット・パ...
2
自己紹介
元楽天株式会社 所属
国際ECサービスのインフラ部門
日本ヒューレット・パッカード株式会社 所属
テクニカルアーキテクト
テクノロジーコンサルティング事業統括
クロス・インダストリ・ソリューション統括本部
テクノロジーアーキテクト...
3
本日のAgenda
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
4
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
5
2017年
エンタープライズは何が変わったのか!?
Transform
to 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
日本企業のデジタル・ビジネスの現状
全く取り組んでいない
その...
8
バイモーダルITとは
そもそもバイモーダルITとは、企業システムの特性を分けて適切なリソースを配分するための概念
Mode1 従来型の企業ITに不可欠な堅牢性を維持する
Mode2 ビジネスイノベーションに対応する俊敏性を実現する
Gart...
Mode2
9
バイモーダルITの捉え方
Mode1
・Webシステム
Web系企業
・基幹システム
銀行、通信などSIer
が得意とする業界
業界や企業単位で区切ることは、
あまり意味がない。
どのサービスにおいても、Mode1の要素とMod...
10
バイモーダルITの本質
バイモーダルなシステムを目指すことは重要だが、本質的には組織の問題である。
教科書的な示唆
堅牢性と流動性の双方の要素を分けて、バイモーダルITに取り組むべきである。
以下のような価値観は不適切…
・Mode1から...
11
バイモーダルITで再分配すべきリソース
いままでと同様のリソース配分で投資を行っていては、バイモーダルの特徴を活かすことができず、プロ
ジェクトが進まない。
アプリケーションから
生成されたデータを、
自社のITのために利用
すべきか、顧...
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
12
これまでのビジネスを支える開発プラットフォーム
これまでは、仮想化環境の上で業務システムの安定稼働とコスト削減を図ることがITのあるべき姿。
ITI...
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
13
バイモーダルを支える開発プラットフォーム
ビジネスの迅速性にあわせてプラットフォームを選択できる柔軟な設計が必要。
DevOps
Micro Ser...
14
バイモーダルITにおける課題
もちろんバイモーダルに対応するためには、適切なリソース配分(組織体系とプラットフォーム)が必要と
なる。
Biz
(事業部門)
SIer
正確性
安全性
堅牢性
SIer
安全性
迅速性
開発 & 運用
(シ...
15
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
16
組織構造とシステムアーキテクチャ
Mode1とMode2のシステムに対して適切にリソースを展開するためには、システムリソースに合わせた組
織構造をとる必要がある。
コンウェイの法則 (Melvin Conway)
システムを設計するあらゆ...
40.6%
29.4%28.1%
17参照: https://www.gartner.co.jp/press/html/pr20160601-01.html
バイモーダルを推進する組織構成
新組織の立ち上げ
組織としての責任/権限を設定できる一...
18
既存のIT組織からバイモーダル対応の組織構造へ
バイモーダルにおけるシステムは、信頼性だけでなく、スピードや柔軟性を重視しているため、運用チー
ムに求められる役割が大きく変わる。
Mode1 (SoR)
チーム
Mode2 (SoE)
チ...
19
プラットフォームチームに必要な人材とは?
20
プラットフォームチームのメンバーに求められる能力
たとえば…。
・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用
・高速なレスポンスを実現するためのアプリケーション、ミドルウェアの...
21
プラットフォームチームのメンバーに求められる能力
たとえば…。
・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用
・高速なレスポンスを実現するためのアプリケーション、ミドルウェアの...
22
SRE(Site Reliability Engineer)とは
Google のプロダクトやサイトを安定運用する役割り。オペレーションチームによって行われた作業をソフ
トウェアを利用し、手作業を自動化に代えていくことが求められる。
つま...
23
SREへのステップアップ
いままでオペレーターだった人たちが、急にSREになれるわけではない。
ソフトウェア化を推進する中で、価値を生み出し役割りの幅を広げることが重要。
Mode1の延長 Mode2への対応
キャズムの壁
オペレーター ...
24
運用チームの意識変化
バイモーダル対応の組織では、アプリケーションの迅速性が求められると同時に、
運用チームの意識の変化が鍵となる。
Mode1 (SoR)
チーム
Mode2 (SoE)
チーム
事業部門
Mode1 (SoR)
チーム...
25
組織構造の改革のまとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
バイモーダルを推進する組織構成は、既存組織のメン
バーから構成されることが多い。
既存組織のメンバーから構成する場合は、システム運用
者の...
26
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
27
バイモーダルに対応するプラットフォーム
これらを迅速かつ、柔軟に提供できるプラットフォームがあれば、ビジネスは飛躍的向上する。
Cloud Native Application Platformでは、従来のアプリケーションよりも運用工数を...
開発プロセス
アプリケーション
アーキテクチャ
アプリケーション
開発基盤
クラウド基盤
28
バイモーダルを支える開発プラットフォーム
Cloud Native Application Platformの選択肢は、「Platform as a...
Cloud Native Application Platformの機能
29
PaaS
コンテナをマルチノード上でスケーラブルに立ち上げるコンテナ管理ツール
コンテナで機能するアプリケーションを管理するためには、インテリジェントに
クラスタ管...
30
Private Cloud Public CloudHybrid Cloud
PaaSの導入環境とプロダクト
PaaSは独自技術が多くそれぞれ特徴があるが、移植性と相互運用性を提供しはじめている。
商標: それぞれのロゴは、各社/組織団体...
Technology Stack
31
Private Cloud Public Cloud
Dockerコンテナ自体がポータビリティがあるため、色が付けづらくソリューションが複雑化している。
Container Orchestrationの導...
32
Cloud Native Application Platformを導入検討する際のポイント
根本的には、クラウドを選択する際と代わりはないが、間違えて選択するとアプリケーション開発のボト
ルネックとなってしまう。
運用も含め、社内のケ
...
33
(補足) Container Orchestrationの利用状況
Container Orchestrationは、Kubernetesの利用の人気が高まっている。
参照: https://clusterhq.com/assets/pd...
34
Today, the community is seeing widespread
adoption of Kubernetes, a system with origins at
Google that is becoming the ...
35
PaaSとContainer Orchestrationはどう使い分けるの ?
開発成果物
(Artifact)
36
アプリケーションエンジニアの開発成果物
ソースコードの
アップロード
言語、フレーム
ワークの選定
ミドルウェアの
設定
アプリパッケージ
の作成
パッケージを
デプロイ
(Build Pack)
通常、...
デプロイ テスト
37
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリケーション
Infrastructure
as code
アプリケーション
エンジニア
SRE
アプリケーション開発
構成管理の自動化
コードのコ...
デプロイ テスト
38
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリパッケージ
コンテナイメージアプリケーション
エンジニア
SRE
アプリケーション開発
PaaS / Container Orchestratio...
デプロイ テスト
39
バージョン
管理システム
開発成果物
管理システム
チェックアウト
アプリパッケージ
コンテナイメージアプリケーション
エンジニア
SRE
アプリケーション開発
PaaS / Container Orchestratio...
40
Cloud Native Application Platformの選択
PaaS
Container
Orchestration
CIパイプラインにおける現状の責務によって、プラットフォームを選択すると導入が行いやすい。
現状の責務 導...
41
コードレポジトリ
・GitHub Enterprise
・Bitbucket
・GitLab
CIツール
・Jenkins
・Circle CI
・Travis CI
・Concourse CI
成果物レポジトリ
・Jfrog Artif...
42
プラットフォームの改革のまとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
バイモーダルのうちMode2を支えるプラットフォームは、
「PaaS」と「Container Orchestration」が主流。...
43
1. バイモーダルITへの挑戦
2. 組織構造の改革
3. プラットフォームの改革
4. まとめ
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
44
組織構造の改革
(トップダウン)
プラットフォームの改革
(ボトムアップ)
2017年デジタルビジネスが加速し、バイモーダルITへの
対応が必然となる。
SREの育成と現状のプロセスにあったプラットフォーム
の選択が必要。
自社の業務やシ...
45
はじめるには、何からすればいいの?
46
バイモーダルITへのステップ
バイモーダルへのステップは、DevOps導入のステップと同じ。
メンバーの構成
現状分析
ゴールの設定
POCの実施
フィードバック
まずは組織、プラット
フォームにおける課題
を見つけ、そのボトル
ネックを...
47
Appendix
- HPEのバイモーダルソリューション -
商標: それぞれのロゴは、各社/組織団体の登録商標です。
HPEのクラウド戦略
Hybrid management
HPE Helion and HPE Partner Professional Services
Traditional workload orchestration cloud-nat...
49
開発成果物の管
理形態
中心となるソフトウェ
ア
特徴 対応するインフラ
PaaS アプリケーショ
ンパッケージ
HPE Helion Stackato • 多様なアプリケーションフレームワークに対応するBuildpack
によりソースコ...
50
Helion Stackato 4のアーキテクチャ
51
HPEが提供するプロフェッショナルサービス
52
一緒に、デジタルビジネス時代を楽しみましょう。
Thank you
54
参考文献
CONTAINER MARKET ADOPTION SURVEY A Joint Production of: 2016
https://clusterhq.com/assets/pdfs/state-of-container-...
Upcoming SlideShare
Loading in …5
×

デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択

5,417 views

Published on

デブサミ2017発表資料
【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択

資料のお問い合わせは以下まで。
shingo.kitayama@hpe.com

北山 晋吾
http://event.shoeisha.jp/devsumi/20170216/session/1315/

デブサミ2017資料
http://codezine.jp/article/detail/9999

Published in: Technology
  • Be the first to comment

デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択

  1. 1. エンタープライズにおけるDevOpsの実態! -Cloud Native Application Platformの選択- Developers Summit 2017 【17-E-5】 ハッシュタグ: #devsumiE 日本ヒューレット・パッカード株式会社 北山 晋吾
  2. 2. 2 自己紹介 元楽天株式会社 所属 国際ECサービスのインフラ部門 日本ヒューレット・パッカード株式会社 所属 テクニカルアーキテクト テクノロジーコンサルティング事業統括 クロス・インダストリ・ソリューション統括本部 テクノロジーアーキテクト部 好評発売中 http://amzn.asia/ghfpKwi 2016年末「Ansible実践ガイド」執筆 北山晋吾 経歴など もーど1のかお shkitayama spchildren
  3. 3. 3 本日のAgenda 1. バイモーダルITへの挑戦 2. 組織構造の改革 3. プラットフォームの改革 4. まとめ
  4. 4. 4 1. バイモーダルITへの挑戦 2. 組織構造の改革 3. プラットフォームの改革 4. まとめ
  5. 5. 5 2017年 エンタープライズは何が変わったのか!? Transform to Digital Business
  6. 6. 6 2017年デジタルビジネス時代 アイデアエコノミーのビジネストラディショナルなビジネス バイモーダルITへの対応 サービス コスト効率化・堅牢性重視 顧客 主にシステム部門 競合 国内大手IT SIer サービス スピード、流動性重視 顧客 主に事業部門 競合 海外大手クラウドベンダー デジタル・ビジネスとは、仮想と物理の世界を融合して人/モノ/ビジネスが直接つながり、顧客との関 係が瞬時に変化していく状態が当たり前のビジネス形態のこと。
  7. 7. 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. 8. 8 バイモーダルITとは そもそもバイモーダルITとは、企業システムの特性を分けて適切なリソースを配分するための概念 Mode1 従来型の企業ITに不可欠な堅牢性を維持する Mode2 ビジネスイノベーションに対応する俊敏性を実現する Gartnerによるカテゴリ Mode1 Mode2 ジェフリー・ムーア氏の提唱 SoR (System of Record) SoE (System of Engagement) アプリケーション アーキテクチャ トラディショナルアプリケーション (Monolithic Architecture) クラウドネイティブアプリケーション (Microservice Architecture) システム特性 正確性、安全性、堅牢性 迅速性、柔軟性、スケーラビリティ 開発手法 ウォーターフォール型 アジャイル型 投資判断ポイント 投資対効果(ROI)に基づいた投資 業務システムの維持とコスト削減 ビジネスチャンスに基づいた投資 新たなチャレンジ 顧客提供価値 ITセントリック、効率性 ユーザー体験、スピード 人材とスキル 信頼性、コスト効率化重視 試験的な取り組みを重視
  9. 9. Mode2 9 バイモーダルITの捉え方 Mode1 ・Webシステム Web系企業 ・基幹システム 銀行、通信などSIer が得意とする業界 業界や企業単位で区切ることは、 あまり意味がない。 どのサービスにおいても、Mode1の要素とMode2 の要素があり、そのリソース配分を設計するた めの枠組み。 Mode1/Mode2のリソースの分類基準は、ビジネスのス ピードとスケールの違い。 Mode2 Mode1 Mode2 Mode1 サービス サービス 企業 サービスが成功する と、安定を優先せざ るを得ない (金のなる木事業) サービスが成功する までは、スピードと 柔軟性に対応 (スター事業)
  10. 10. 10 バイモーダルITの本質 バイモーダルなシステムを目指すことは重要だが、本質的には組織の問題である。 教科書的な示唆 堅牢性と流動性の双方の要素を分けて、バイモーダルITに取り組むべきである。 以下のような価値観は不適切… ・Mode1からMode2へ移行しないといけない。(Mode1からMode2に移ることはない。) ・Mode2の業界だから、Mode1のシステムは関係無い。 本質的な示唆 自社の業務やシステムのMode1 / Mode2の比率に合わせて、組織構造(人的リソース)やプラット フォーム(システムリソース)の割合を調整するべきである。
  11. 11. 11 バイモーダルITで再分配すべきリソース いままでと同様のリソース配分で投資を行っていては、バイモーダルの特徴を活かすことができず、プロ ジェクトが進まない。 アプリケーションから 生成されたデータを、 自社のITのために利用 すべきか、顧客満足度 向上のために利用すべ きかで、異なるノウハ ウが必要になる。 Mode1では、堅牢性、 正確性を重視した開発 プロセスに対し、 Mode2ではスピードを 重視した柔軟な開発プ ロセスが必要となる。 スケールアップ型のト ラディショナルアプリ ケーションと、スケー ルアウト型のクラウド ネイティブアプリケー ションの設計が必要に なる。 オンプレミスな環境だ けでなく、パブリック クラウドと連携した、 ハイブリッド環境を設 計することが必要にな る。 年度予算ではなく、経 営戦略の方針変更に伴 い、突然のプロジェク トへの予算を確保でき る仕組み(予算のア ジャイル化)が必要に なる。 Knowledge Process Technology ArchitectureCost
  12. 12. 開発プロセス アプリケーション アーキテクチャ アプリケーション 開発基盤 クラウド基盤 12 これまでのビジネスを支える開発プラットフォーム これまでは、仮想化環境の上で業務システムの安定稼働とコスト削減を図ることがITのあるべき姿。 ITIL Monolithic Services Virtual Machine Cloud Biz (事業部門) 開発&運用 (システム部門) SIer System 正確性 安全性 堅牢性 Mode1(SoR) Platform Mode1
  13. 13. 開発プロセス アプリケーション アーキテクチャ アプリケーション 開発基盤 クラウド基盤 13 バイモーダルを支える開発プラットフォーム ビジネスの迅速性にあわせてプラットフォームを選択できる柔軟な設計が必要。 DevOps Micro Services Containers Cloud ITIL Monolithic Services Virtual Machine Cloud Mode1 Mode2 SIer Biz (事業部門) 開発 & 運用 (システム部門) Biz (事業部門) Mode1 (SoR) Mode2 (SoE) System 安全性 迅速性 柔軟性 スケーラブル 正確性 堅牢性 Platform
  14. 14. 14 バイモーダルITにおける課題 もちろんバイモーダルに対応するためには、適切なリソース配分(組織体系とプラットフォーム)が必要と なる。 Biz (事業部門) SIer 正確性 安全性 堅牢性 SIer 安全性 迅速性 開発 & 運用 (システム部門) Biz (事業部門) Biz (事業部門) 柔軟性 スケーラブル 正確性 堅牢性 Mode1 (SoR) Mode2 (SoE) System Platform 開発&運用 (システム部門) System Mode1(SoR) Platform 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ)
  15. 15. 15 1. バイモーダルITへの挑戦 2. 組織構造の改革 3. プラットフォームの改革 4. まとめ 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ)
  16. 16. 16 組織構造とシステムアーキテクチャ Mode1とMode2のシステムに対して適切にリソースを展開するためには、システムリソースに合わせた組 織構造をとる必要がある。 コンウェイの法則 (Melvin Conway) システムを設計するあらゆる組織は、必ずその組織のコミュニケーション構造に模倣した構造 を持つ設計を生み出す。 参照: 「System of Record と System of Engagement」 by Naoya Ito Mode1 (SoR) チーム Mode2 (SoE) チーム プラットフォームチーム 事業部門 Mode1チーム 標準化して、安定稼働していくことが目標。 Mode2チーム トライアンドエラーで迅速性を高めることが 目標。 プラットフォームチーム 両者の技術基盤を支えていく。
  17. 17. 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. 18. 18 既存のIT組織からバイモーダル対応の組織構造へ バイモーダルにおけるシステムは、信頼性だけでなく、スピードや柔軟性を重視しているため、運用チー ムに求められる役割が大きく変わる。 Mode1 (SoR) チーム Mode2 (SoE) チーム プラットフォームチーム 事業部門 Mode1 (SoR) チーム システム運用 チーム 事業部門 •利用方法についての問い合わせ業務 •決まったオペレーションを実施する定常業務 •障害対応 •システムの管理業務 (構成管理やキャパシティー管理など) •システムの安定性だけでなく、迅速性のあるシステム基盤を設計 •運用管理の自動化の仕組みを設計・構築 •標準化されたポリシーやルールの整備 バイモーダル対応の組織 運用チームの変化 既存のIT組織
  19. 19. 19 プラットフォームチームに必要な人材とは?
  20. 20. 20 プラットフォームチームのメンバーに求められる能力 たとえば…。 ・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用 ・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善 ・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用 ・デプロイや各種オペレーション自動化ツールの開発、運用 ・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用 ・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用 ・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用 などなど ・サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務 ・システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用 参照: https://www.mercari.com/jp/jobs/sre/
  21. 21. 21 プラットフォームチームのメンバーに求められる能力 たとえば…。 ・20,000 req/secのAPIトラフィックを安定して処理するためのバックエンドシステムの開発、運用 ・高速なレスポンスを実現するためのアプリケーション、ミドルウェアのパフォーマンス改善 ・テラバイトスケールのデータベースのパフォーマンス最適化、監視、バックアップなどの運用 ・デプロイや各種オペレーション自動化ツールの開発、運用 ・データ分析を迅速に行うためのログ収集・分析基盤の構築、運用 ・障害検知やキャパシティプランニングのためのモニタリング環境の構築、運用 ・プロダクトの開発、QA,CIを安定かつ迅速に行うための環境の構築、運用 などなど サーバ・ネットワークの構築・運用、システムの自動化や障害対応などのシステム管理者的な業務。 システムのパフォーマンスや信頼性、スケーラビリティを向上させるためのソフトウェアの開発・運用。 参照: https://www.mercari.com/jp/jobs/sre/ 実は、これmercariさんの採用情報...
  22. 22. 22 SRE(Site Reliability Engineer)とは Google のプロダクトやサイトを安定運用する役割り。オペレーションチームによって行われた作業をソフ トウェアを利用し、手作業を自動化に代えていくことが求められる。 つまり、『すべてがソフトウェアの問題として扱われる』というアプローチを取って作業を行うエンジニア。 サーバー管理者としての役割り ・インフラの自動化 ・障害対応 ・システムの維持 ソフトウェアエンジニアとしての役割り ・サイトのパフォーマンスを改善 ・可用性、スケーラビリティを向上 参照: https://landing.google.com/sre/book.html
  23. 23. 23 SREへのステップアップ いままでオペレーターだった人たちが、急にSREになれるわけではない。 ソフトウェア化を推進する中で、価値を生み出し役割りの幅を広げることが重要。 Mode1の延長 Mode2への対応 キャズムの壁 オペレーター 構成管理の自動化 クラウド基盤の管理 アプリケーション 開発基盤の管理 アプリ改善 既存のシステムをAnsibleやChefなど の構成管理ツールを利用して、自動 化を図り、手作業の工数を削減。 APIを利用したハイブリッドクラウド環 境のコントロール。また、OpenStackな どの統合管理ソリューションの利用。 アプリケーションのパフォーマンス改善、 オートスケール、動的障害復旧などの サービス品質の向上。 Dockerコンテナの管理やアプリケー ションパッケージのトラブルシュー ティングなどのサービス管理
  24. 24. 24 運用チームの意識変化 バイモーダル対応の組織では、アプリケーションの迅速性が求められると同時に、 運用チームの意識の変化が鍵となる。 Mode1 (SoR) チーム Mode2 (SoE) チーム 事業部門 Mode1 (SoR) チーム 事業部門 運用チームの変化 他のチームと共通人材プール。 つまり、SREメンバーを増やす と、必然的に開発チームの稼 動を減らせることが期待。 SREへのステップ オペレーター 構成管理の自動化 クラウド基盤の管理 アプリケーション 開発基盤の管理 アプリ改善 Site Reliability Engineering システム運用 チーム バイモーダル対応の組織既存のIT組織
  25. 25. 25 組織構造の改革のまとめ 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ) バイモーダルを推進する組織構成は、既存組織のメン バーから構成されることが多い。 既存組織のメンバーから構成する場合は、システム運用 者の役割りが変わることを意識する必要がある。 既存のシステム運用者が、いきなりSREになれるわけでは なく、徐々に対応範囲を広げていくことが求められる。 組織構造の改革には時間がかかるが、これらを変えずにバイモーダルを実践することはできない。 SREの育成
  26. 26. 26 1. バイモーダルITへの挑戦 2. 組織構造の改革 3. プラットフォームの改革 4. まとめ 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ)
  27. 27. 27 バイモーダルに対応するプラットフォーム これらを迅速かつ、柔軟に提供できるプラットフォームがあれば、ビジネスは飛躍的向上する。 Cloud Native Application Platformでは、従来のアプリケーションよりも運用工数を減らし、開発工数を上げ ていくことが求められる。 HWやOSのセットアップ ランタイムのビルド ライブラリの管理 アプリケーション開発基盤 - Cloud Native Application Platform -
  28. 28. 開発プロセス アプリケーション アーキテクチャ アプリケーション 開発基盤 クラウド基盤 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 ※パブリッククラウドかオンプレミスかは別の話。 - 構成管理の自動化
  29. 29. Cloud Native Application Platformの機能 29 PaaS コンテナをマルチノード上でスケーラブルに立ち上げるコンテナ管理ツール コンテナで機能するアプリケーションを管理するためには、インテリジェントに クラスタ管理する必要があり、そのためのオーケストレーションが必要。 Infrastructure Private Cloud / Public Cloud Cloud Native Application Platform アプリケーションライフサイクル基盤のプラットフォーム アプリケーション実行環境の提供に加え、システム開発におけるソースコードの 保存から、リリースまでの一連の流れを含むサービス。コードをリポジトリに登 録しておくと、チェックアウト、ビルド、アプリケーションサーバーへのデプロ イまでを実行してくれる。 両者が提供する機能 ・マルチホストコンテナ環境 ・ルーティングなどの付加サービス ・オートスケール、障害検知の仕組み ・デプロイ(CI)機能 両者のプロダクト背景は異なるが、機能だけ見ると似ているところに収束している。 Availability (可用性) オートスケール アクセスルーティング 自動リカバリ Security (セキュリティ) テナント管理/分離 アプリのアクセス制御 Maintainability (運用/保守性) 継続的デリバリ(CI)機能 バージョン管理 障害検知 Container Orchestration
  30. 30. 30 Private Cloud Public CloudHybrid Cloud PaaSの導入環境とプロダクト PaaSは独自技術が多くそれぞれ特徴があるが、移植性と相互運用性を提供しはじめている。 商標: それぞれのロゴは、各社/組織団体の登録商標です。 Technology Stack (Open PaaS) Solution Stack (Proprietary PaaS) Proprietary Technology
  31. 31. Technology Stack 31 Private Cloud Public Cloud Dockerコンテナ自体がポータビリティがあるため、色が付けづらくソリューションが複雑化している。 Container Orchestrationの導入環境とプロダクト Hybrid Cloud 商標: それぞれのロゴは、各社/組織団体の登録商標です。 Solution Stack
  32. 32. 32 Cloud Native Application Platformを導入検討する際のポイント 根本的には、クラウドを選択する際と代わりはないが、間違えて選択するとアプリケーション開発のボト ルネックとなってしまう。 運用も含め、社内のケ イパビリティだけで補 える技術なのか、外部 に委託するのか。 プラットフォーム導入 の重視したい点が、ア プリケーション開発の 迅速化なのか、コスト 削減なのか。 独自の技術で構成され ているのか、もしくは ポータビリティのある デファクトスタンダー ド技術で構成されてい るのか。 オンプレ上だけでなく、 パブリッククラウド上 でハイブリッド展開が 可能か。 CAPEXとOPEXが妥当な のか。オンプレ製品で もOPEXがかかるもの もある。 Knowledge Process Technology ArchitectureCost デプロイ環境の確認 依存性の確認導入目的の確認ケイパビリティの確認費用対効果の確認
  33. 33. 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. 34. 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. 35. 35 PaaSとContainer Orchestrationはどう使い分けるの ?
  36. 36. 開発成果物 (Artifact) 36 アプリケーションエンジニアの開発成果物 ソースコードの アップロード 言語、フレーム ワークの選定 ミドルウェアの 設定 アプリパッケージ の作成 パッケージを デプロイ (Build Pack) 通常、アプリケーションデプロイのフローでは開発成果物(Artifact)に違いがでてくる。 ソースコードの アップロード 言語、フレーム ワークの選定 ミドルウェアの 設定 コンテナイメージ の作成 Dockerイメージ をデプロイ (Docker Image) PaaS Container Orchestration ※ただし、近年Docker型のPaaSも増えてきている。 アプリケーション エンジニア アプリケーション エンジニア
  37. 37. デプロイ テスト 37 バージョン 管理システム 開発成果物 管理システム チェックアウト アプリケーション Infrastructure as code アプリケーション エンジニア SRE アプリケーション開発 構成管理の自動化 コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト Continuous Integration CIツール 開発成果物の展開 機能/結合テスト アプリケーション 単体テスト application code ビルド/テスト 自動化ツール IaaS アプリエンジニアは、アプリのデプロイ SREは、VMのデプロイ Mode1のCIパイプラインと役割り イメージ化 VMテンプレートの管理
  38. 38. デプロイ テスト 38 バージョン 管理システム 開発成果物 管理システム チェックアウト アプリパッケージ コンテナイメージアプリケーション エンジニア SRE アプリケーション開発 PaaS / Container Orchestration コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト 開発成果物の展開 機能/結合テスト アプリケーション 単体テスト application code ビルド/テスト 自動化ツール PaaS Container Orchestration Mode2のCIパイプラインと役割り Continuous Integration CIツール NoOps ※ソフトウェアによる可用性、スケーラビリティ向上に専念 アプリエンジニアは、アプリのデプロイ
  39. 39. デプロイ テスト 39 バージョン 管理システム 開発成果物 管理システム チェックアウト アプリパッケージ コンテナイメージアプリケーション エンジニア SRE アプリケーション開発 PaaS / Container Orchestration コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト 開発成果物の展開 機能/結合テスト アプリケーション 単体テスト application code ビルド/テスト 自動化ツール PaaS Container Orchestration Mode2のCIパイプラインと役割り Continuous Integration CIツール NoOps ※ソフトウェアによる可用性、スケーラビリティ向上に専念 アプリエンジニアは、アプリのデプロイ Containerの管理は誰の責任?
  40. 40. 40 Cloud Native Application Platformの選択 PaaS Container Orchestration CIパイプラインにおける現状の責務によって、プラットフォームを選択すると導入が行いやすい。 現状の責務 導入後の責務 アプリケーション エンジニア インフラ エンジニア アプリケーション エンジニア Site Reliability Engineering - アプリデプロイ - VMの実行管理 - リリース作業 - 開発成果物の作成 (コンテナイメージ) - コンテナの実行管理 - リリース作業 - アプリデプロイ - VMの実行管理 - リリース作業 - VMの払い出し - リソース監視 - 開発成果物の作成 (コンテナイメージ.ア プリパッケージ) - リリース作業 - コンテナ/アプリの 実行管理 - 運用の完全自動化 - アプリパフォーマン ス改善 Dev vs Opsなチーム DevOpsなチーム アプリエンジニアに デプロイの操作権限 を付与していく
  41. 41. 41 コードレポジトリ ・GitHub Enterprise ・Bitbucket ・GitLab CIツール ・Jenkins ・Circle CI ・Travis CI ・Concourse CI 成果物レポジトリ ・Jfrog Artifactory ・Github Enterprise コンテナイメージレ ポジトリ ・Docker Trusted Repository PaaS ・Cloud Foundry ・Heroku ・Bluemix Container Orchestration ・Docker Datacenter ・Mesosphere ・Kubernetes 構成管理の自動化 ・Ansible ・Chef ※凡例 手動タスク 自動化タスク 機能テストツール ・UFT ・Selenium ・Appium ・JMeter コードのコミット ビルド 単体テスト 開発成果物の管理 デプロイ 機能テスト開発環境 CI環境 ステージング環境 QA環境 本番環境 利用ツール例 デプロイ 機能テスト コード 反映 コード 反映 デプロイ リリース Issue Tracking ・JIRA ・Redmine Promote Promote 開発成果物の管理 開発成果物の管理 CI/CDのプラットフォーム選択 プラットフォームの選択が一番CI/CDのプロセスに影響を及ぼす。 アプリケーションのアーキテクチャおよ び非機能要件/運用要件によって選択
  42. 42. 42 プラットフォームの改革のまとめ 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ) バイモーダルのうちMode2を支えるプラットフォームは、 「PaaS」と「Container Orchestration」が主流。 PaaSとContainer Orchestrationの機能は似ているが、 提供可否はベンダーに寄って色があるため、目的にあっ たものを選択する。 PaaSとContainer Orchestrationは、既存のCIパイプラ インの役割りによって導入を選択する。 プラットフォームの選択次第でアプリケーションのアーキテクチャやプロセスが変わる。 現状のプロセスにあった プラットフォームの選択
  43. 43. 43 1. バイモーダルITへの挑戦 2. 組織構造の改革 3. プラットフォームの改革 4. まとめ 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ)
  44. 44. 44 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ) 2017年デジタルビジネスが加速し、バイモーダルITへの 対応が必然となる。 SREの育成と現状のプロセスにあったプラットフォーム の選択が必要。 自社の業務やシステムのMode1/Mode2の比率に合わせ て、組織構造とプラットフォームの割合を戦略的に配置 できた企業が競争優位性を築くことができる。 デジタルビジネス時代で生き残る組織 戦略的リソース配置 (逆コンウェイの法則)
  45. 45. 45 はじめるには、何からすればいいの?
  46. 46. 46 バイモーダルITへのステップ バイモーダルへのステップは、DevOps導入のステップと同じ。 メンバーの構成 現状分析 ゴールの設定 POCの実施 フィードバック まずは組織、プラット フォームにおける課題 を見つけ、そのボトル ネックを探す。 あるべきCIのパイプラ インや役割り、システ ムの構成を計画する。 ・チーム体制 ・スケジュール ・アーキテクチャ ゴールに近づけるか否 かを判断する材料を集 める。 ・スピード開発 ・事業部門予算で対応 POCの成功可否で実 サービスへの展開を判 断 ・継続的プロセス改善 ・CI/CDの導入 やるべきことに優 先順位をつける この時点で標準化 しない 組織構造の改革 (トップダウン) プラットフォームの改革 (ボトムアップ) ユーザーが主導 ベンダーと共創
  47. 47. 47 Appendix - HPEのバイモーダルソリューション - 商標: それぞれのロゴは、各社/組織団体の登録商標です。
  48. 48. HPEのクラウド戦略 Hybrid management HPE Helion and HPE Partner Professional Services Traditional workload orchestration cloud-native orchestration Amazon Web Services Microsoft Azure Cloud Service Providers Eucalyptus HPE Helion OpenStack® Azure Stack HPE Synergy, HPE ConvergedSystem, HPE CloudSystem, HPE ProLiant Private or managed clouds Emerging Platforms (Mesos, etc.) vSphere Public cloud Public cloud Legacy Existing HPEのクラウド戦略は、マルチベンダー&ハイブリッド化。 Mode1でもMode2でもクラウド層を安定化させることは変わらない。
  49. 49. 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な ど) Container Orchestration 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. 50. 50 Helion Stackato 4のアーキテクチャ
  51. 51. 51 HPEが提供するプロフェッショナルサービス
  52. 52. 52 一緒に、デジタルビジネス時代を楽しみましょう。
  53. 53. Thank you
  54. 54. 54 参考文献 CONTAINER MARKET ADOPTION SURVEY A Joint Production of: 2016 https://clusterhq.com/assets/pdfs/state-of-container-usage-june-2016.pdf Gartner https://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

×