1.
自社にあったハイブリッドクラウドの選び方
小川 大地
日本ヒューレット・パッカード
Jan 24, 2019 @ ハイブリッドクラウド研究会 第2回

2.
2
自己紹介
経歴
HPE で、クラウドプラットフォーム製品のビジネス開発をしています。
ストレージの製品開発やサーバー・仮想化・VDI などのプリセールスを経て、
現職。
小川 大地
Daichi Ogawa
Microsoft MVP - Azure
SE 時代のコミュニティ活動
• 個人ブログ 仮想化でプリセールスしてるSEの一日
• ITmedia 小川大地の 『ここが変だよ!? 日本の IT インフラ』
• 技術書の執筆・連載 （@IT, ITpro, 日経BP, 翔泳社, インプレス）

3.
各機関が 「顧客の多くがハイブリッドに向かう」 との調査結果
3
Traditional IT Virtual and automated Private clouds Public cloudsManaged clouds
On-premises
Build/Consume
Off-premises
Consume
77%
23%
Yes No
73%
27%
Yes No
73%
Organizations want a hybrid
cloud architecture and not simply
to adopt cloud in an ad hoc way
Percentage of respondents
that say they are pursuing
Hybrid IT
63%
25%
12%
Yes No Don't know
63%
60%
40%
Yes No
60%
Percentage of respondents
implementing Hybrid
environment
Organizations are
employing hybrid cloud
approaches
77%

4.
ハイブリッドクラウドの誤解
提案と導入の現場から・・・

5.
まずは “誤解” から・・・
5

6.
「ハイブリッド・クラウド」 のよくある誤解
A. 仮想マシンが行き来している
パブリック
オンプレミス
パブリック
オンプレミス
B. 双方を跨ぐようにシステムを作る
App
Data
人事システム

7.
「ハイブリッド・クラウド」 のよくある誤解
A. 仮想マシンが行き来している
パブリック
オンプレミス
パブリック
オンプレミス
B. 双方を跨ぐようにシステムを作る
App
Data
発注システム
こんな使い方は “映画の世界だけ” くらいレア
技術レベル 300～400

8.
え、そうなの？
ベンダーにそんな事例を紹介されましたよ！
「稀に見るすごい案件」 だからこそ、事例化して自慢するんです
• 事例化作業は、取材 ・ Web 掲載 ・ カタログ化 ・ 印刷で百万円以上のプロモーション予算が掛かります
• 事例は基本 “盛られる” ものです。 残念ながら、それが “マーケティング ・ プロモーション” の世界のようです
• ベンダーの使う用語にも注意： 「ユースケース」 ＝ 使い道 （理論上）、 「事例」 ＝ 実際の実績 （公開できるもの）
技術レベルが高いということは、費用も高い
内製での実現は正直かなりキツイ
• 難易度が高いということは、誰でもできない → 「スーパーエンジニアのアサイン」 が必要
• 製品・設備以上に、予想をはるかに超えるコンサル費用と構築作業費が発生します
• 想定されている 「ハードウェア・ソフトウェア」 と 「構築費用」 の比率を大幅に超過するかもしれません
8

9.
「ハイブリッドクラウド」 の難易度
レベル 100 （はじめてはこちら）
• クラウドバックアップ
レベル 200 （メインストリーム）
• クラウドDR （バックアップ拠点をクラウド上に）
• システム単位で配備先を選ぶ
レベル 300 （難易度：高）
• 繁忙期のみクラウドを借りる
• 常時仮想マシンが行き来する
• オンプレとクラウドを跨いだ三層システム
パブリック
オンプレミス
人事システム
勤怠システム
受発注システム
ここにメインデータが
流れるほど、難易度が高い

10.
事例からみる
ハイブリッドクラウドの方針策定

11.
オンラインゲームのサービス基盤
1. リリース: オンプレ or パブリック
• 開発・運用プラットフォームが共通化されており、
それによって IaaS 系か PaaS 系かに分かれる
• 最初からパブリックを選ぶケースも増えてきている
2. ヒット中: パブリック
• パブリックのオートスケール技術はやはりすごい
• あまりにヒットしすぎると、コスト理由でオンプレに戻るケースも
3. その後: オンプレ
• 大手会社の場合、ブームが去ってもサービスはサクッと辞められない
• オンプレに戻してサービス終了まで塩漬ける （言葉選び難しいですがホスピス的な・・・）
11
Case 1 大手ゲーム会社 （国内）
OR
• 大ヒットを約束されているナンバリングタイトルではなく、
一般的なゲームタイトルでの運用事例

12.
オンラインゲームのサービス基盤
この事例の特長
• オンプレとパブリックの “同時利用” はしない
• フェーズを分けて適材適所を選ぶ
この事例から分かること
• 同時利用するとネットワーク設計が複雑になる
• ブームが来ると、リソース消費は日々の増減が激しい
– バブリックの 「使った分だけ」 課金は非常に助かる
• 24 時間 365 日運転、かつリソース消費が一定に近づくほど、
基本的にはオンプレの方が安い
– インスタンスを上げたり下げたり、リソース増減しない前提
12
Case 1 大手ゲーム会社 （国内）

13.
13
iMOKO
ニュージーランドの医療団体
use case：ハイブリッドクラウド
皮膚や咽頭炎といった生命維持に影響ない
感染症への遠隔診断。タブレットが接続する
Microsoft Azure と、患者情報を格納した
HPE Azure Stack は Revera 社のツールで
シームレスに一元管理。
www.public.imoko.com
HEALTHCARE

14.
iMoko 社 - 難易度高いですが、これこそ “The 事例”
スマホ・タブレット端末を用いた遠隔医療
• 主に、医師の居る病院まで遠かったり、感染の危険性のある患者が利用
• 日々の病状や患部写真をスマホでアップロードしたり、医師とのビデオチャットができる遠隔医療システム
• 介護事業者との協業も進み、ビジネスを伸ばしているらしい
Azure と Azure Stack を併用
14
Case 2 ヘルスケア （海外）
インターネット
• 個人識別 ID
• 病状、患部写真
• ビデオチャット Azure
閉域網
Azure Stack
パブリック オンプレ
• カルテ実データ
• 実個人情報

15.
iMoko 社 - 難易度高いですが、これこそ “The 事例”
この事例の特長
• 1 つのシステムでオンプレとパブリックの “同時利用” している
• 「デバイス」 「パブリッククラウド」 「オンプレ」 の特性を
きちんと把握し、適材適所を選んでいる
この事例から分かること
• スマホやタブレットは LTE / WiFi 通信から 「インターネット」 に近い
• パブリッククラウドも 「インターネット」 に近い
– インターネットにつなぐなら、オンプレミスよりコスト・運用面で有利
– 逆に、1 つの設定ミスが会社を倒産に追い込むほどのリスクもある
• オンプレミスは簡単に インターネットから遠ざけることができる
– コンプライアンスデータを安全・安心して保管できる
– 「データ 10 年保管」 などの業界ルールに対してコスト的にも有利
15
Case 2 ヘルスケア （海外）

16.
設計指針
• 基本は システム単位
• パブリックとオンプレを同時利用するシステムは、価格も技術も超ハイレベル
16
ここまでのまとめ
オンプレミスへの配備
• 24時間運転 ×数年間継続するなら安価
• インターネットから遠ざけられるので
コンプライアンスデータに対する
リスクヘッジ になる （保身もできる）
• インターネットへのサーバー公開は面倒
• 塩漬け運用や 「データ 10 年保管」 などの
業界規制に低コストで対応できる
パブリッククラウドへの配備
• ビジネスの急激な変化に追随する
使った分だけ の課金とオートスケール
• 辞めたい時に辞められる、
止めたい時に止められる
• インターネットに近い
• オンプレミスよりも外敵に強いが、
設定ミスが事故・責任問題 になり得る

17.
製品の選択肢と選び方
日本国内向け

18.
本コミュニティの中心となっている
「クラウドとアーキテクチャが互換」 なハイブリッドクラウド製品
製品の選択肢
18
もう 1 つの誤解。
Microsoft
Azure Stack
VMware Cloud
on AWS
VMware Cloud
Foundation
AWS Outposts
（発表のみ）

19.
有名どころだけでもたくさんあります
19
そんなことありません！
• Microsoft Azure Stack • AWS Outposts (a)
• Stratoscale
• Eucalyptus
• Google GKE On-Prem
• Cisco Hybrid Cloud
Platform
for Google Cloud
• IBM Cloud Private • VMware Cloud Foundation
/ VMware Cloud on AWS
• AWS Outposts (v)
• VMware HCX & Hosted
• VMware virtualization on Azure
Microsoft Azure 系 Amazon AWS 系 Google GCP 系
IBM Cloud 系 VMware SDDC 系 VMware Legacy 系
緑： パブリック技術の移植・互換 紫： オンプレ技術をベース・互換

20.
なぜ知られていない？ 流行っていない？
ローカライズされていないから
但し、日本語化といった 「言語」 の話ではありません
• 確かに i18n とか l12n とか、画面やドキュメントの日本語化も重要ですが・・・
“ビジネスのローカライズ” がされていない
• 日本のユーザーの利用形態にマッチしていない
• 日本のユーザーの成熟度にマッチしていない
• 日本のユーザーの規模感にマッチしていない
• 日本のユーザーの購買スタイルに合わせていない （カード決済？）
• 日本向けの販売体制が整っていない （Channel）
• 日本向けのシステム導入体制が整ってしていない （SIs）
• 日本向けの保守サポート体制が整っていない （故障時交換）
20
オンプレなので
特に重要

21.
“ビジネスのローカライズ” が
済んでいる、代表例を 2 つ
21

22.
22
① Microsoft Azure Stack （AzS）

23.
クラウド生まれのサービスを移植し、IaaS はもちろん PaaS も充実
23
① Microsoft Azure Stack （AzS）
• 仮想マシン
• 仮想マシンスケールセット
• Linux コンテナ
• Windows コンテナ
• 仮想ネットワーク
• ロードバランサー
• VPN ゲートウェイ
• BLOB
• テーブル
• キュー
• キー
• シークレット
仮想マシン コンテナ ネットワーク ストレージ Key Vault
App Service Kubernetes Service Fabric Functions Cloud Foundary
• Web Apps
• Mobile Apps
• API Apps
• コンテナの開発、
配置、管理
• スケーラブルな
分散アプリ
• サーバーレス
コンピューティング
• オープンソース
プラットフォーム
PaaS
プリインストール
必要なサービスを
選択して組み込み
IaaS

24.
マーケットプレイス - スマートフォンのようにワンクリックで機能を追加
24
① Microsoft Azure Stack （AzS）
Azure のエコシステムをそのまま利用
Azure に認定済みのアプリケーションとサービスは
Azure Stack 上でも稼働可能
（ISV ベンダーによってサポートルールは異なります）

25.
全てのデータセンターリソースを含んだ、統合ハイブリッドクラウド・プラットフォーム
25
② VMware Cloud Foundation （VCF）

26.
広がる 「VCF アライアンス」 - 既存の VMware 環境を “無理なく” マルチクラウド化
26
② VMware Cloud Foundation （VCF）

27.
27
今回、例に挙げた 2 つの使い分け
Microsoft Azure Stack VMware Cloud Foundation
仮想マシンではなく 「IaaS / PaaS」
（既存のオンプレ仮想化環境からの移行は少し大変）
既存は一旦捨てて as-a-Service 型に刷新
シングルベンダー でより密に
IaaS / PaaS ではなく 「仮想マシン / コンテナ」
刷新はせず、既存運用のまま クラウド化
（IP アドレスすら変更不要、vCenter で管理）
複数のクラウド事業者を 選べる
技術
運用
スタイル

28.
Thank you