Contenu connexe Similaire à LiBRA 07.2021 / クラウド (20) Plus de Masanori Saito (20) LiBRA 07.2021 / クラウド24. 徹底した標準化
大量購入
負荷の平準化
APIの充実・整備
セルフサービス化
機能のメニュー化
クラウド・コンピューティングのビジネス・モデル
24
クラウド・コンピューティング
オンデマンド
従量課金
自動化・自律化
システム資源
の共同購買
サービス化
低コスト 俊敏性 スケーラビリティ
SDI (Software Defined Infrastructure)
29. SIビジネスの常識を覆す動き
29
オラクル「Oracle Autonomous Data
Warehouse Cloud」正式公開。機械学習を用
いて全自動で運用、チューニング、パッチ適用な
ど実現
2018年3月28日
機械学習によって人手を介さずにバックアップやパッ
チの適用、チューニング、スケールイン/スケールア
ウトなどの日常的な運用業務を自律的に行うクラウド
サービス。
人手を介さず自律的に稼働することで運用にかかるコ
スト削減だけでなく、ヒューマンエラーも起きない安
全な運用が可能になり、計画停止も含めたSLA
99.995%を約束。
日本ユニシスとマイクロソフト、「BankVision
on Azure」実現に向け共同プロジェクトを開始
2018年3月23日
日本ユニシス株式会社と日本マイクロソフト株式会社
は23日、日本ユニシスのオープン勘定系システム
「BankVision」の稼働基盤として、Microsoft Azureを
採用するための取り組みを推進するため、共同プロ
ジェクトを4月から開始すると発表した。
33. 政府の基盤システム Amazonへ発注
33
人事・給与や文書管理など各省共通
の基盤システムをAWSに発注。
整備・運用にかかる費用は2026年度
までで300億円を超える見通し。
政府は各省庁のシステムについて4〜
8年で原則クラウドにする方針を打ち
出している。
目的は、コストの大幅減と、最新の
デジタル技術の取り込みにつなげる
ため。
自前で管理する手間が減り、人員の
効率的な配置など生産性の向上も見
込める。
https://www.nikkei.com/article/DGXMZO55498840R10C20A2MM8000/
2020.02.12
43. クラウド・コンピューティングの起源 ~ シュミットの対談
What's interesting [now] is that there is an emergent new model, and you all are here
because you are part of that new model. I don't think people have really understood
how big this opportunity really is. It starts with the premise that the data services and
architecture should be on servers. We call it cloud computing – they should be in a
"cloud" somewhere. And that if you have the right kind of browser or the right kind of
access, it doesn't matter whether you have a PC or a Mac or a mobile phone or a
BlackBerry or what have you – or new devices still to be developed – you can get
access to the cloud. There are a number of companies that have benefited from that.
Obviously, Google, Yahoo!, eBay, Amazon come to mind. The computation and the
data and so forth are in the servers.
Eric Schmidt, 6.Mar.2006, “Search Engine Strategies Conference @ San Jose, CA
“(新しいモデルは) データサービスとアーキテク
チャはサーバー上にあるべきだという前提から
始まる。これをクラウドコンピューティングと
呼ぼう - 「クラウド」のどこかにあるべきなの
だ。適切なブラウザ、あるいは適切なアクセス
手段があれば、PC、Mac、携帯電話、ブラック
ベリー、その他あらゆるものから - あるいは、
まだ開発されていない新しいデバイス - クラウ
ドにアクセスできる。”
「クラウド」上のサーバー
適切なアクセス手段
開発中の新しいデバイス
49. クラウド・サービスの区分
自社所有 IaaS
仮想マシン
CaaS PaaS FaaS
ユーザー企業が管理
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
SaaS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
ハードウェア
仮想マシン
コンテナ
管理機能
ミドルウェア
アプリケーション
OS
ランタイム
データ
IaaS
ベアメタル
クラウドサービス事業者が管理
連携機能
CaaS PaaS FaaS SaaS
56. ハイブリッド・クラウド
モバイル連携 使い分け 災害対策 負荷調整 SaaS連携 ピーク対応 柔軟対応
Public
Private Public
Private Public
Private Public
Private
Public
Private Public
Private Public
Private
パブリックで
モバイル・ア
プリケーショ
ンと連携
プライベート
で基幹業務系
の処理
業務ごとに両
者を使い分け
通常時はプラ
イベート
災害時にはパ
ブリックに切
り替え
プライベート
で負荷をまか
ないきれない
ときにパブ
リックを追加
リソースとし
て使用
パブリックで
SaaSを使用
そのデータを
プライベート
の業務システ
ムで処理する
通常はプライ
ベートで処理
するがピーク
時はパブリッ
クにリソース
を拡大する
業務状況に応
じて業務や
データを両者
で柔軟に使い
分ける
(単一リソース)
業
務
A
業
務
B
業
務
C
業
務
D
業務 業務 業務 業務
負荷調整
業務 SaaS 業務 業務
業
務
A
業
務
B
業
務
C
業
務
D
対象とする業
務アプリケー
ションへのア
クセス方法
業務の配置と
統合監視・管
理方法
データやアプ
リケーション
同期の方法や
タイミング
サイト切り替
え法
統合監視・管
理方法
ネットワーク
帯域・設定
振り分けが自
動か手動で難
易度が変わる
SaaS/API連携
の方法
データやアプ
リケーション
同期の方法や
タイミング
サイト切り替
え法
統合監視・管
理方法
データやアプ
リケーション
同期の方法や
タイミング
サイト切り替
え法
統合監視・管
理方法
構築の難易度 低 低 中 高 高 高+ 高+
60. ハイブリッド・クラウドとマルチ・クラウド
60
クラウド管理プラットフォーム
Prime Cloud Controller (SCSK) / RightScale (RightScale) / vRealize Suite (Vmware) など
オンプレミス(自社構内)
データセンタ(自社設備)
データセンタ(他社設備)
コロケーション/ホスティング
パブリック・クラウド パブリック・クラウド
バーチャル
プライベート
クラウド
ハイブリッド・クラウド
マルチ・クラウド
インターネット/VPN/専用線
(SDN : Software-Defined Network)
個別専用システム ハイブリッド・クラウド マルチクラウド
63. 仮想化とクラウド(IaaS)との違い
仮想化
運 用
管 理
調 達
インフラに関わるシステム資源を
ソフトウェアの定義・設定により調達、構成変更
調達機能と
運用管理機能の
連携と自動化
個別対応
自動化/人的作業
システム資源の利用効率向上
人的作業の負担軽減
調達・変更の俊敏性と生産性向上
仮想化 クラウド(IaaS)
67. データセンター
データセンター
ASPとSaaSの違い – マルチテナント
サーバー サーバー サーバー
アプリ アプリ アプリ
サーバー サーバー
仮想化
顧客 顧客 顧客
アプリ アプリ アプリ データセンター
サーバー
アプリケーション
顧客 顧客 顧客
パッケージをそのまま使用
複数企業での共有を前提とした設計
データの分離、セキュリティに配慮
メンテナンスコストが低い
リソースの利用効率が高い
または
マルチテナントDB
ASP SaaS
69. Force.comのターゲットマーケット
消費者
全社
部門
グループ
コンテンツ データ プロセス トランザクション
アプリケーションのタイプ
ユーザーのタイプ
Excel 以上、全社システム以下
全社規模の基幹システムであればコ
ストをかけてシステムを開発できる
部門レベルでは、コストをかけられな
い一方で変化の速度が速いため、改
修が頻繁に起こるため、IT部門もSIer
も対応しにくい。
このためユーザーが自分で作る必要
があるが、一から作るのは大変なた
め、何からのツールが必要。
→ Notesのマクロ
→ Excel/Access
73. データセンター
データセンター
ASPとSaaSの違い – マルチテナント
サーバー サーバー サーバー
アプリ アプリ アプリ
サーバー サーバー
仮想化
顧客 顧客 顧客
アプリ アプリ アプリ データセンター
サーバー サーバー サーバー
アプリケーション
仮想化
顧客 顧客 顧客
パッケージをそのまま使用
複数企業での共有を前提とした設計
データの分離、セキュリティに配慮
メンテナンスコストが低い
リソースの利用効率が高い
または
マルチテナントDB
ASP SaaS
75. マッシュアップ開発の部品としてのWebサービス
クラウドサービス API
クラウドサービス API
クラウドサービス API
マッシュアップ開発
IT の深い知識がなくても、既存
のWebサービスAPIを組み合わ
せて、短期間でアプリケーション
開発を行うこと。新しい開発技法
として注目されている。
様々なWebサービスやBaaSなど
のサービス、豊富なOSSなどによ
り、新たなプログラミングをせず
にアプリケーションを開発するこ
とが可能になってきた
マッシュアップ
自社サービス
Application Programming Interface
外部からプログラムの機能やデータにアクセス
するための手順やデータ形式
85. SOA
SOA (2000年前後)
ビジネスプロセスをサービス化
クラウドへの対応
ビジネスプロセスを
サービスとして実装
既存システムを相互接続して統合
EAI (1990年代末)
ばらばらに開発された業務システ
ムをプロトコル変換などで統合
従来は部分最適な業務システム
個別にシステム設計開発
現場の仕事をそのままシステム化
「その時点」での技術を使って開発
他システムとの連携は必要に応じて設計・
実装
全社的最適化という視点はない
全社最適化手法
EA Enterprise Architecture
BPR Business Process Re-engineering
ERP Enterprise Resource Planning
88. Webサービス (Web Service)
XMLでデータ交換できるインターフェイスを持つアプ
リケーション・システム。SOAを実現する技術とも言
える。インターネット上で、Webサービスが、XMLを
使って相互にデータを交換し、連携することで・・・
単体のWebサービスだけではできない、利便性
や機能の高いアプリケーションを構築できる
Webサービスの組合せを固定化させず、柔軟な
アプリケーションを構築できる
組合により多様なアプリケーションが展開できる
SOAとクラウドの関係
88
SOA (Service Oriented Architecture/ サービス指向開発)
業務全体のプロセスをこれ以上分解できない業務処理の単位(サービス)
にまで分解し、そのプロセス単位毎に対応したプログラムを「標準部品」と
して用意する。これを組み合わせ、ネットワーク上で連携させて、システム
全体を実現するシステム構築手法。
XML (eXtensible Markup Language /拡張可能なマーク付け言語)
プラットフォームに依存しない、システム間でデータ交換を可能にするため
の言語、または、データを記述する書式。
PaaS(Platform as a Service)
IaaS(Infrastructure as a Service)
仮想化基盤は必須ではない
SaaS(Software as a Service)
アプリケーションをサービスとしてインターネット上で提供する仕組み
Webサービスとして構築され、他のWebサービスと相互連携が容易
カスタマイズ機能がある
オンデマンド(必要な時、いつでも)インターネット / ネットワークを介し)利用
1990年代
1998年
2000年頃
89. SOAとクラウドの関係
89
販売管理の業務に沿ったビジネス・プロセス
受注 請求 入金 出荷
SOAをベースにした販売管理プロセス
受注 請求 入金 出荷
ビジネスプロセスの変更にも柔軟に対応可能
受注 出荷
請求 入金
プロセスの各業務単位(サービス)に合わせて
ソフトウェアを作ってあるので、後でプロセス
が変わっても柔軟に対応できる
サービス間でやりとりするデータの種類、
フォーマットをXMLで決めて標準化
各ソフトをWebアプリ (Webサービス)にしておく
と、柔軟性が高まる
従来型のシステム構築手法による販売管理システム
受注
請求・入金
出荷
ビジネス・プロセスに合わせてシステムを構築
していない場合、後で変更するのが大変
他のシステムとの連携を考えていない場合(イ
ンターフェースの標準化が行われていない)、
後から付け加えるのは大変な作業になる
要求仕様
プロセス単位で
サービス化
伝票のフローに沿ったシステム
情報のフローに沿ったシステム
サービス
業務上の1処理に相当する機能
94. Googleのクラウド・セキュリティ対策
94
Denial of Service (DoS) Protection DoS攻撃の防御
マルチティア、マルチレイヤにわたるDoS攻撃からの防御によって、GFEの背後で稼働している
サービスをDoSから守る。
バックボーンを通じて届く通信は、何層かのハードウェアおよびソフトウェアのロードバランサーを通
過する。ロードバランサーは通信の情報をインフラ上で稼働する中央DoSサービスへ報告。中央
DoSサービスがDoS攻撃の開始を検知すると、DoSの通信を破棄もしくは絞るようにロードバラン
サーを制御する。
GFEインスタンスもアプリケーションレイヤにおける情報を中央DoSサービスへ報告し、ここでも
DoSが検知されればGFEインスタンスが通信を破棄するように制御される。
User Authentication ユーザー認証
Dos攻撃からの防御に続いての防御は中央アイデンティティサービスによる。ユーザー名やパス
ワードを確認した上で、同一のデバイスや同一ロケーションからのログインかどうかなどの追加情
報を基にしてユーザーからの脅威があるかどうかをインテリジェントに判断する。
Safe Software Development 安全なソフトウェア開発
中央コードリポジトリや関係者のレビューなどに加えて、開発者がXSSといったセキュリティ関連の
バグを組み込まないよう、ライブラリを提供しており、またコードの静的解析ツール、Webセキュリ
ティスキャナーなどを用意している。
最終チェックとしてマニュアルでのセキュリティレビューを行っている。これはWebセキュリティ、暗
号化、OSセキュリティなどの専門家による、些細なリスクの判断から深刻な設計や実装レビューま
で行われている。
さらに脆弱性を発見したものに対する脆弱性報奨金プログラムを行っており、これまでに数百万ド
ル(数億円)を支払った。
Keeping Employee Devices and Credentials Safe 従業員
のデバイスとクレデンシャルの安全性確保
従業員を対象にした洗練されたフィッシングがこれまで行われてきており、フィッシング可能なOTP
second factors(ワンタイムパスワード2要素認証)をU2F-compatible Security Keys(ユニ
バーサル2要素認証互換なセキュリティキー)に置き換えた。
従業員がインフラを操作するために用いるクライアントデバイスのモニタリングにも膨大な投資を
行っている。これらクライアントデバイスのOSに最新のセキュリティパッチがあたっているかを確認
し、インストール可能なアプリケーションを管理している。さらにインストールされたアプリ、ダウン
ロードされたファイル、ブラウザ拡張、ブラウジングされたWebページなどをスキャンするためのシ
ステムも備えている。
Reducing Insider Risk 内部リスクの低減
インフラにアクセス可能な従業員の行動はつねにモニタされ、同時に強く制限されている。またより
安全な作業を実現するために、徹底的な自動化によって特権的なアクセスを可能な限り排除する
ようにしている。
Intrusion Detection 侵入検知
インフラの多数のデバイスからのモニタリング情報やシグナルから、ルールおよびインテリジェント
な方法で侵入インシデントの可能性があった場合に警告が行われる。調査およびインシデント対応
チームが24時間365日、これに対応する。
Encryption at Rest 保存されるデータの暗号化
暗号化キーを用いてストレージのデータにアクセス
ハードディスクやSSDのレベルでの暗号化も利用
Deletion of Data データの削除
計画的な消去により、ユーザーの操作ミスあるいはバグやエラーなどによる意図しないデータ削
除にもデータの復旧が可能
Google Front End Service Googleのフロントエンド・サービス
サービスがインターネットで利用可能になるために、サービスが自身をインフラが提供する
Google Front End(GFE)に登録できる。GFEはTLSコネクションが適切に終了することや、
perfect forward secrecyといったセキュリティのベストプラクティスに沿った通信を実現する。
GFEはさらに、DoS攻撃からの防御も行う。
100. パブリック・クラウド適用のリスク
100
管理主体の違い
事業者によるシステム設計と運営管理
投資の内容や優先順位の判断
セキュリティやサービスレベルの維持などの統制活動
障害や情報漏えいなどのインシデント発生時の情報連携
インシデントに関する情報開示範囲や原因究明作業に対するユー
ザー関与に制約
インシデントの全体像や根本原因の特定が不十分な恐れ
自社のシステム環境の移植性の問題
サービス終了時にデータの引き継ぎに制約が生じる恐れ
サービス品質に対して実施するリスク管理の有効性について、
ユーザーが期待するレベルまで実施されていない、また、実施さ
れていても情報開示の制約でユーザーが確認できない恐れ
情報開示の限界
セキュリティ管理ルールの十分性や運営実態について、情報開示
範囲に制約
契約で合意した内容の履行状況に関してユーザー側の確認が撮り
にくい
ベンダーの情報開示情報と自社のセキュリティポリシーなどとの
整合性を十分の確認が困難
機能やサービス内容の制約
個別カスタマイズの制約
ユーザー固有のカスタマイズが実現できないため業務影響の見極
めや対策について検討が必要
サービスに関する意思決定権
事業戦略の変更や破綻などにより、一方的にサービスの終了や変
更、また、サポート停止により、ユーザーの業務継続や顧客への
サービス提供に影響を及ぼす恐れ
サービスの多様化・グローバル化
データの所在
データセンター設置国の法令への遵守
海外の現地規制当局の強制執行などによるデータ閲覧やデータ収
集、通信傍受により業務継続に支障、情報漏えいの恐れが
ベンダーのグローバル化
本社拠点(各種意思決定機能)を海外に置くベンダーも多く、
サービス内容や提供価格、契約条件などの調整がスピード感を
もって推進できない恐れ
ベンダーの本社が海外にあることで、係争時の管轄裁判所が海
外となり、海外の係争への対応が必要となる恐れ
インシデント発生時に時差や言語の問題から、ベンダー、ユー
ザー間のコミュニケーションに支障をきたす恐れ
役割分担や責任範囲の多様化
責任や役割の固定化
ユーザーの個別要求事項を前提とした諸条件の調整が困難
自社のニーズをふまえた「融通」が利きにくく、ユーザー側で追
加の対応手続きやリソース手配などが必要となる恐れ
マルチベンダーで一つのITサービスを実現する場合情報連携に混
乱や支障をきたす恐れ
導入に伴うハードルの低下
簡単迅速なサービス導入
ユーザー部門が自社のセキュリティポリシーやシステム化方針な
どへの影響確認を十分に実施せずに単独で導入してしまい、全社
的なシステム統制に影響を及ぼす恐れ
http://japan.zdnet.com/article/35063430/
117. クラウド移行の方向
117
リフト
シフト シフト
インテグレーション
シフト
クラウド クラウド クラウド
既存システムの一部移管
SaaSの利用
ハイブリッド・クラウド
による連係運用・一元管理
オール・イン・クラウド
への全面移行
Webスケール/クラウド技術
を使ったハードやソフト
各社HCI、Azure Stack、AWS Outposts、Google On-Premなど
IoT/エッジ・コンピューティング
リアルタイム・コンピューティング
オンプレミス・コンピューティング
個別専用システム
シフト
ドロップ
118. クラウドに吸収されるITビジネス
118
アプリケーション・ビジネス
• ビジネス開発
• システムの企画
• システム設計
• プログラム開発・テスト
• 開発・テスト環境の構築
• 本番実行環境の構築
• セキュリティ対策
• 運用管理
• トラブル対応
ネットワーク・ビジネス
• ネットワークの設計
• ネットワーク機器の導入・設定
• セキュリティ対策
• 監視・運用管理
• トラブル対応
インフラ・ビジネス
• インフラの設計
• インフラ機器の導入・設定
• セキュリティ対策
• 監視・運用管理
• トラブル対応
クラウド・データセンター内
ネットワーク
クラウド・データセンター間
バックボーンネットワーク
5G通信網のタイムスライス
SIMによる閉域網
ローコード開発
Salesforce.com Lightning Platform
Microsoft PowerApps
AWS Honeycod
サーバーレス/FaaS・PaaS
コンテナ運用・管理マネージドサービス
SaaS
Oracle Dedicated Region @Cloud
AWS Outposts
Microsoft Azure Stack Hub
オンプレミス型マネージド・システム
アジャイル
開発
DevOps
OutSystems
Mendix
GeneXus
ローコード開発ツール
119. クラウド・ネイティブへのシフトが加速する
Oracle Dedicated Region @Cloud
AWS Outposts
Microsoft Azure Stack Hub
IBM Cloud Paks
Google GKE on-prem
Microsoft Azure Ark
IBM Cloud Satellite
Google Anthos
オンプレミス環境にパブリック・クラウドと
同等の環境を構築する製品やサービス
オンプレミスとパブリック・クラウドを
一元的に運用管理するサービス
ハイブリッド・クラウド
マルチ・クラウド
122. AWS Outposts の仕組み
VPC Subnet Subnet Subnet
AZ AZ AWS Outposts
Nitro Hypervisor
Amazon EC2、EBS、
ECS、EKS、EMR、
Amazon RDS for
PostgreSQL / MySQL、
Amazon S3
ネットワーク(Direct Connect)
AZ(Availability Zone):設備の構成単位。各AZは一つあるいは複数のデータセンタから成り、AZ同士は地震や台風などで同時に被災しにくいよう
に、ある程度距離を離して設置。AWSの東京リージョンは4つのAZで構成する。
AWSコンソールから構成パ
ターン・カタログから注文する
と2週間程度で24インチラック
に収めた機器一式が届けられる。
AWSのスタッフがラックを設
置し、電源とネットワークを接
続すれば、使い始められる。
AWSがリモートで
運用。ソフトの
アップグレードや
パッチ適用は基本
的に無停止。仮想
マシンの再起動が
必要な場合は、そ
の旨の通知
マネージメント
コンソール
低遅延処理
ローカルでの
大量データ処理
AWS Region(地域の単位 例:東京)
Vmware Cloud for AWS
Outopsts もある
126. 異なる文化の2つのクラウド戦略
コスト削減のためのクラウド 競争力強化のためのクラウド
生産性向上・納期短縮・コスト削減
投資負担の軽減
運用管理負担の軽減
高い運用品質の維持
コスト削減
資産固定化の回避
最新技術の活用
俊敏性の実現
投資対効果
差別化・競争力・変化への即応力
既存システムのIaaS移行
運用管理の自動化
開発と運用の順次化
コンテナ×Kubernetes
PaaS×サーバーレス
開発と運用の同期化
クラウド・リフト
戦略
クラウド・ネイティブ
戦略
守りの文化 by 情報システム部門 攻めの文化 by 事業部門・経営直下
予算と人材と戦略の一体化と適切な配分
スピード×アジリティ×スケール
新しいテクノロジーをいち早く活用
コスト×自動×安定
ヒト・モノ・カネの投資削減
129. クラウドのメリットを経営層にどう伝えるか
129
自社で所有することの限界
ガバナンスとセキュリティ
災害対応(Disaster Recovery)
グローバル展開
利用状況の徹底した見える化
システム利用の状況やリスクを把握しやすい
必要な対策を事実に基づいて行える
高度なセキュリティ認証に対応している(高度なスキル・高額なコスト)
少ない投資コストでの災害対応
高度な災害対応を施した施設にて運用
複数の独立したアベイラビリティゾーン
国内外の分散レプリケーション可能、しかもアップロードコストは不要
フラットなグローバルサービス
世界中にデータセンター
世界中で同一のアーキテクチャ
マルチクラウド化によりさらなるリスク分散