クラウドとは何か / what is cloud computing (1.4 / 2017.07)

What is
“Cloud”?
CC BY 4.0 arichika.taniguchi (@arichika)
今だからこそ再確認
クラウドとブームに見る目指す価値
1.4（2017.07）
1

３つのクラウドサービスモデル
• クラウドといえばNISTの定義なのだけど…
• このNIST定義さえも既に (遺産 || 負債) になってる状態
オン
プレミス
アプリケーション
OS/ミドルウェア
ハードウェア
データセンタ
IaaS
ハードウェア
データセンタ
PaaS
ハードウェア
データセンタ
SaaS
ハードウェア
データセンタ
自社で運用管理
クラウドはこういう区分が
あるよね、とNISTが
2009年に定義してみたけど
2

簡単に “クラウド” と言いますが
“クラウド“ という言葉は（発言者の）背景で論点が変わる
• クラウドの時代≒柔軟な○○の時代言い換えてみる
– 予算に対して柔軟な基盤の時代⇒ 高度な IaaS
– スケールアウト設計に対して柔軟な基盤の時代⇒ PaaS 視野に
– 競争力関係無いので汎用サービスで良い… ⇒ SaaS 提供を受ける
– 柔軟に技術領域の人材を活用したい⇒ 派遣クラウド
– ITよくわからんのでとりあえずよろしく⇒ 丸投げクラウド
• 達成しようとしている「柔軟な○○」は見えてますか？
– 勘定科目を通して企業会計にも影響を与えるのがクラウド
– クラウドでコストカット！という短絡は間違いの元。
3

オン
プレミス
サーバー
所有型
ほとんど自分
または
丸投げ
OS 自由
非機能要件
＝人間力
セキュリティ
≒書類上
IaaS
Cloud
仮想サーバー
貸し
いろいろ
自分
OS 静的
非機能要件
インフラ
自分
セキュリティ
自分で
Container
Cloud
仮想プロセス
貸し
デプロイ改善に
フォーカス
OS 動的
非機能要件
インフラ
自分
セキュリティ
自分で
PaaS
Cloud
実行基盤
OS管理あり
+OS運用にも
フォーカス
OS 動的
非機能要件
インフラ
基盤側が主
OS
セキュリティ
基盤任せ
PaaS
Cloud
実行基盤
OS管理なし
アプリコードに
専念
結果色々楽に
OS 隠ぺい
見えるけど
非機能要件
インフラ
基盤側が主
アプリ作りに
セキュリティは
集中する
BaaS
ASP
ミドル向け
アプリ売り
クラウドEUC
業務コード専念
OS 知らんね
非機能要件
基盤側に
お任せ
クラウドの
VBA だと
あえて言いたい
SaaS
ASP
機能AP売り
業務というか
場合により
仕事そのもの
OS知らん
非機能要件
基盤側に
お任せ
ID管理＝
セキュリティ
対策よね
IaaS/PaaS/SaaSは既に無理がある
• 何をオフロードするかで選択肢は激しく増加拡大中！
↑ハード作っちゃう人たちの楽しげな世界/FPGA↑
↑トラディショナルなASPから怪しげなSaaSまで↑
CC BY 4.0 arichika.taniguchi (@arichika) 4
”Serverless” の
概念が2016年に出てきて、
当局勉強会で
紹介される時代に！
進んでるね！

完全
自前主義
業務に特化した動作
業務で汎用的な動作
実装プログラム
分散処理向けの
最適組み合わせ
ミドルウェア群
OS
サーバーH/W
ネットワークH/W
データセンター管理
仮想
マシン
IaaS
OS
サーバーH/W
PaaS
OS展開型
OS
サーバーH/W
PaaS
OS隠蔽型
OS
サーバーH/W
BaaS
（使うための実装PG）
OS
サーバーH/W
SaaS
(ライセンス管理含む)
OS
サーバーH/W
＝情報セキュリティ3要素の観点は、採用クラウドでまるで別ものになる
クラウド形態とシステム基盤の位置づけ
CC BY-SA 4.0 5
”Serverless” 概念は2016年頃明確化！

得るモノ捨てるモノ適用範囲例
迅速な機能の低コスト導入
汎用的なサービスレベル
機能の自由度
（≒つまり競争力を捨てる）
会計システム
間接系基礎業務
基盤環境セットアップ
重厚長大な開発環境の設定運用
OS依存の動作仕様/基盤自由度
軽量なクラウドサービスAPI
連携用システム
開発生産性の向上
スケールアウト耐性
ミドル以下自社運用不要
PG設計自由度（≒利点でもあり）
ミドル以下は自社改良が不可
（≒高負荷の場合技術力が必要）
情報系ビジネス
ベンチャー系
ハイブリッドクラウド
環境構築の自動化
影響範囲の限定化
コンテナ管理（OSより難しい）
CPU性能の使い倒し
開発環境のデプロイ
CI環境や本番でのフロント
H/Wリードタイム短縮
H/W以下自社運用不要
構成や運用設計の自由度において一定の制限あ
り
（≒長期稼働の償却利点の減少）
ハード依存AP運用
イベント系Webサイト
ベンチャー系・小規模
サービス廃止リスク低減
日本的商習慣の融通
業務含めた全体最適への道程
技術主導イノベーション
自社でシステムを構築していない
企業
最高の自由度
全て自分達で決めるのでコスト高
（≒人材採用コストでもある）
超大規模
（GOOG.FB.AMZN.MSFT.）
機密性が高い業務
コスト換算が出来ればなんでもござ
れ（≒責任回避とも言う）
通常は金銭面コストと将来におけるビジネスの
変革と自由度
なんでもOK！
旧来型金融など
クラウド化≒実は複雑化≒適材適所

それぞれのクラウドで考えるコトの例
忘れがちなコト対策例よくある間違い
ユーザーのアカウント管理
データ保護（論理破壊対策）
SSOサービスでID一元管理
パスワード変更管理規約を作成して現場のISO運用はカ
バーしたが不便だなぁ。
業務レベルの耐障害設計
操作情報のロギング
API Gateway を別途運用
サーバーがなくてもシステムが動くんだ！
いや、そういう話ではない。
ミドルウェア・N/Wなどでのピーク
I/O性能の担保
データ保護（発想の転換）
業務レベル性能の監視
データ運用管理は自前で
ハイブリッド化
ミドル・H/Wの性能を額面通りに信じてみたけどやは
りピーク性能出ない。
CPU負荷を監視して○%以下に抑える。
リソース共有型なので性能問題あり
負荷分散含む設計はPG責任
PG側とインフラ側のデザイン
パターンで要件カバー
コンテナ型は仮想マシンを置き換えるはずだ
リソースが限定されてるので高いセキュリティだ
スケールアウト耐性PG設計
データ保護（自前対策視野）
ミドルのセキュリティ対策
開発要件に含める
PaaS へシフトする
運用管理費をさらに出す
とにかく怒鳴ってなんとかさせる。
うちは感染しないと信じてみる。
うちは壊れないと信じてみる。
誰かがどこかで、やっぱりがんばって
いるという事実
知らないフリを決め込む
”ごめんなさいもうしません”と書いてある改善報告書
の提出で指導したよフラグ。
運用開発の壁が無く、仕組みを維持すること
が出来るだけの技術力あってこそのオンプレ
技術者賃金の引き上げ
自己啓発推奨と現場理解
ここ、社内からの SNS 禁止だし、そもそもでウェブア
クセス禁止だし。困ったときに情報が調べられないっ
て。
「形あるものはいつか壊れる」という
基礎的な概念
供給者訪問やITパスポート試
験、まず自社を知る事
お金で未来の課題を解決することが出来るのであれば、
まだ楽な話です。

クラウドは
捨てるもの得るものの選択
＝
組織設計さえも変えてしまう
＝
組織論でもある

On-Premises
Hosting
IaaS
aPaaS / Serverless
“クラウド” の実態
横軸：
非機能要件（性能・運
用・一貫性）の実装
領域の依存傾向
＝スケール耐性
事業者依存
縦軸：スケールに対する
運用コスト相関・構造＝コスト耐性
H/W 依存実装コード依存OS/ミドル依存
Cloud Services
Blob/xSQL
iPaaS(ESB) SaaS
ASP
右上の傾向を示すキーワード
サイエンス
インハウス
ソーシャル
LOB
アウトソース
勘定系
左下の傾向を示すキーワード
指数的に増加
伸び率が低減

負荷傾向とサービスモデル
 負荷変動は穏やか
 サービス変更は希
 負荷変動が激しい
 サービス変更は頻繁
 負荷変動が激しい
 サービス変更は希
 負荷変動が穏やか
 サービス変更は頻繁
10

各種クラウドモデルのポジション
オン
プレ
利用者は自身が狙うポジションと競争力を踏まえ、
変化の方向（目的）とその変化を支える技術の理解と
人材の確保（内製外注問わず）が必要。
状態の遷移が下向きになったら改革の失敗。
大規模 IaaS /
パブリック
クラウド
大規模 PaaS /
パブリック
クラウドプライベート
クラウド
（日本型）中小
IaaS クラウド
11

技術論でのクラウドシフトの背景

クラウド背景・設計意図とその変遷
性能・負荷を事前に定
義, 壊れないシステム
を指向する.
構成変更し易い基盤構
成で負荷バランスを
ノード間で変える柔軟
なシステムを指向する。
運用自動化, 分散処理
系設計開発手法の導入
で, 直ちに変えられる
戻せる回復しやすいシ
ステムを指向.
～以前 2012年頃～2000年頃～
予期せぬ負荷に対応しようとコスト高なシステム構成に.
落ちないための検証/テストの繰り返しで時間観点でも足枷.
実際に負荷問題が発生, それは時既に遅しの合図.
過度な仮想化に旧来の運用体制維持で運用負荷は下がらず.
頻繁な構成変更に耐えるメンテナンス性が高いPG構造の設計はハイスキル.
API連携により外部システムに依存することになった負荷見積もり制御も高度な運用.
復元力(Resilience)
2006年頃～

「壊れないシステム」の設計
• 全ての機器, 部品を物理的に多重化, 全てのシステム構成要
素に対して, 可能な限り負荷を計算し推測する.
– 突発的なアクセス増や二次曲線的な利用者増が無かった時代.
– 業務要件の変化が穏やか故, システム変更の頻度も多くない.
– システム開発と運用, 改良も同じ企業が引き受ける.
• 適用イメージ
– メインフレーム, H/Aクラスタ, VRRP, V字開発, RAID
• 壊れさえしなければ “保守費は利益” のビジネスモデル

「柔軟なシステム」の設計
• 仮想化によるOSとハードウェアの分離, ネットワークのソフ
トウェア実装, 疎結合サブシステムで柔軟に.
– 仮想化がH/W由来による性能制限を緩和.
– 同時に, 仮想化に合わせたネットワーク構成変更の自由度向上.
– API指向, RESTful ブームでのサブシステム連携の一般化.
– IA分散, グリッド, 広域L2/FPGA/ASIC, アジャイルスクラム
• インフラ設計ノウハウ高度化, 不景気背景に仮想化売り出し
戦略は低コスト指向強く迷走.

この時代あたりまでは
非機能要件
インフラ側の設計運用により
まずまず吸収出来ていた.
16

非機能要件は（コスト代替で）
コード側での実装が必須に.
⇒ でも2017年には
IaaS 高度化 / PaaS 便利化
Serverless ブーム到来
17

今は「回復しやすいシステム」設計が必要
• 安価H/Wを活用する故の低コスト, システム変更頻度を引き
上げる自動構成・自動運用, 世界規模サービスでデータ急増
– サーバーは突然落ちるもの.
– 単一ハードウェアには性能上限があるもの.
– バックアップ・復元が不可能なデータ量.
– パブリック・クラウド, SDN, Cloud Design Pattern.
• セキュリティ更新プログラムの頻繁な適用, プログラムの変
更作業が円滑になった.

システム設計のトレンド比較
～以前, 2000年前半 2006年～ 2012年～
冗長化 H/A A/A, グリッドクラウド分散処理
負荷分散 L7パーシステント指向 L7ステートレス指向ラウンドロビン指向
可用性日時のメンテナンスでシ
ステムを停止する
臨時メンテナンスでシス
テムを停止する
オンラインでシステムを
変更する
負荷マネジメント負荷を検証して準備する負荷にあわせて要因を
ノード間で移動する
負荷を細分化・分解し負
荷に応じたSLAを定義
SLA基準システム全体ユーザー毎機能毎
バックアップ日々取得するリアルタイムで取得する取得が困難、仕組みと細
分化により担保
システム設計業務単位アクター単位コード構造単位
開発プロセス V字開発アジャイル・スクラム＋DevOps (+ユーザ)
システム運用開発者が兼任運用担当が専任機械による自動化
システム変更頻度 1年間に数回 1ヶ月に数回 1日に数回
非機能要件の扱い H/W側に分業要件定義に書き出したコード実装→基盤側へ

設計思想の変遷完全個→不完全多へ
クラウド大変安価で壊れても直さないしジョブだけ再実行
xSQL・メモリﾘｱﾙﾀｲﾑ＋個別バッチ SOA＋ﾗｯｸ・ｼﾞｵ分散壊れても放置
オープンシステム比較的安価で壊れたら切り替えて再実行
RDBMS・ディスク OLTP＋全体バッチスケールアウト壊れたら保守
メインフレーム高価だがシステムが壊れにくいし壊れても動き続ける
ファイル・テープｵﾝﾗｲﾝ⇒全体バッチスケールアップ壊さないために保守

処理量と処理時間、障害復旧時間の変化

たとえば
実装負荷が高い非機能要件は
PaaS 側で極力カバー
例：Azure Web Sites / Functions
Amazon Lambda
クラウドの“お作法”を外部に頼る.
22

復元力＝Resilience
• 従来オンプレミスでは Robust 指向＝壊れにくい
– 信頼性の高い部品を組み合わせ冗長化
– OSがダウンしないように手厚く/平均故障時間など指標管理
• クラウド（グリッド以降）は Resilience 指向=回復し易い
– 信頼性はアルゴリズムの実装で担保
– OSはミドルウェアよりもさらに汎用的な部品に
– 部分的に壊れサービスレベルは一層フラグメント化
• 大規模クラウドの力がオンプレに逆流
– Azure Stack / 分散処理系OSS もろもろ
– 設計の前提が変わる＝従来の設定チェックシートに意味がない

クラウド化は
見ること見ないことの選択
＝
仕事の模範さえも変えてしまう
＝
善悪の哲学でもある

まず考えよう。言葉にしよう。ディスカッションしよう。
What is
“Cloud”?

クラウドとは何か / what is cloud computing (1.4 / 2017.07)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a クラウドとは何か / what is cloud computing (1.4 / 2017.07)

Similar a クラウドとは何か / what is cloud computing (1.4 / 2017.07) (20)

Más de Arichika TANIGUCHI

Más de Arichika TANIGUCHI (8)

クラウドとは何か / what is cloud computing (1.4 / 2017.07)