Mais conteúdo relacionado Semelhante a デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択 (20) Mais de Shingo Kitayama (8) デブサミ2017【17-E-5】エンタープライズにおけるDevOpsの実態!Cloud Native Application Platformの選択22. 22
SRE(Site Reliability Engineer)とは
Google のプロダクトやサイトを安定運用する役割り。オペレーションチームによって行われた作業をソフ
トウェアを利用し、手作業を自動化に代えていくことが求められる。
つまり、『すべてがソフトウェアの問題として扱われる』というアプローチを取って作業を行うエンジニア。
サーバー管理者としての役割り
・インフラの自動化
・障害対応
・システムの維持
ソフトウェアエンジニアとしての役割り
・サイトのパフォーマンスを改善
・可用性、スケーラビリティを向上
参照: https://landing.google.com/sre/book.html
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
Private Cloud Public CloudHybrid Cloud
PaaSの導入環境とプロダクト
PaaSは独自技術が多くそれぞれ特徴があるが、移植性と相互運用性を提供しはじめている。
商標: それぞれのロゴは、各社/組織団体の登録商標です。
Technology Stack
(Open PaaS)
Solution Stack
(Proprietary PaaS)
Proprietary
Technology
31. Technology Stack
31
Private Cloud Public Cloud
Dockerコンテナ自体がポータビリティがあるため、色が付けづらくソリューションが複雑化している。
Container Orchestrationの導入環境とプロダクト
Hybrid Cloud
商標: それぞれのロゴは、各社/組織団体の登録商標です。
Solution Stack
32. 32
Cloud Native Application Platformを導入検討する際のポイント
根本的には、クラウドを選択する際と代わりはないが、間違えて選択するとアプリケーション開発のボト
ルネックとなってしまう。
運用も含め、社内のケ
イパビリティだけで補
える技術なのか、外部
に委託するのか。
プラットフォーム導入
の重視したい点が、ア
プリケーション開発の
迅速化なのか、コスト
削減なのか。
独自の技術で構成され
ているのか、もしくは
ポータビリティのある
デファクトスタンダー
ド技術で構成されてい
るのか。
オンプレ上だけでなく、
パブリッククラウド上
でハイブリッド展開が
可能か。
CAPEXとOPEXが妥当な
のか。オンプレ製品で
もOPEXがかかるもの
もある。
Knowledge Process Technology ArchitectureCost
デプロイ環境の確認 依存性の確認導入目的の確認ケイパビリティの確認費用対効果の確認
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
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
40. 40
Cloud Native Application Platformの選択
PaaS
Container
Orchestration
CIパイプラインにおける現状の責務によって、プラットフォームを選択すると導入が行いやすい。
現状の責務 導入後の責務
アプリケーション
エンジニア
インフラ
エンジニア
アプリケーション
エンジニア
Site Reliability
Engineering
- アプリデプロイ - VMの実行管理
- リリース作業
- 開発成果物の作成
(コンテナイメージ)
- コンテナの実行管理
- リリース作業
- アプリデプロイ
- VMの実行管理
- リリース作業
- VMの払い出し
- リソース監視
- 開発成果物の作成
(コンテナイメージ.ア
プリパッケージ)
- リリース作業
- コンテナ/アプリの
実行管理
- 運用の完全自動化
- アプリパフォーマン
ス改善
Dev vs Opsなチーム
DevOpsなチーム
アプリエンジニアに
デプロイの操作権限
を付与していく
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のプロセスに影響を及ぼす。
アプリケーションのアーキテクチャおよ
び非機能要件/運用要件によって選択
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
開発成果物の管
理形態
中心となるソフトウェ
ア
特徴 対応するインフラ
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
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