LiBRA 09.2020 / クラウド・コンピューティング
•
0 gefällt mir•823 views
https://libra.netcommerce.co.jp/
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie LiBRA 09.2020 / クラウド・コンピューティング
Ähnlich wie LiBRA 09.2020 / クラウド・コンピューティング (20)
Mehr von Masanori Saito
Mehr von Masanori Saito (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (8)
LiBRA 09.2020 / クラウド・コンピューティング
- 8. プラットフォームの変遷 8 オペレーティング・システム ハードウェアを無駄なく・効率よく動かす アプリケーションからハードウェアを簡単に使う ハードウェア ハード ウェア アプリケーションで共通に使う機能 ミドルウェア ハードウェア ハード ウェア ハード ウェア 共通で使う機能 オペレーティング・システム ハードウェアを無駄なく・効率よく動かす アプリケーションからハードウェアを簡単に使う ハードウェアを 制御する機能 1950年代〜 1960年代〜 1970年代〜 アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション アプリケーション
- 11. インターネットとWebサイト 11 <title>ネットコマース株式会 社</title><link rel="shortcut icon" href="http://www.netcomme rce.co.jp/cms/wp- content/uploads/2013/08/fav icon1281.png" /><link rel="apple-touch-icon" sizes="144x144" http://netcommerce.co.jp / document.html ウエブ・サーバーの名称 文書の名前 ウエブ・サーバー ハイパー・リンク インターネット ブラウザー 世界中のウエブ・サーバー Httpまたはhttps プロトコル HTMLファイルを送り届ける通信手順 URL uniform resource locator
- 14. ネットワーク インターネットや専用回線 コレ一枚でわかるクラウド・コンピューティング 14 インフラストラクチャー プラットフォーム アプリケーション 計算装置 記憶装置 ネットワーク データ ベース 運用管理 プログラム 実行環境 プログラム 開発環境 認証管理 電子 メール SNS 新聞 ニュース ショッピング 金融取引 財務 会計 施設や設備
- 15. 「自家発電モデル」から「発電所モデル」へ 15 工場内・発電設備 設備の運用・管理・保守は自前 需要変動に柔軟性なし 電力供給が不安定 自前で発電設備を所有 工場内・設備 電 力 電力会社・発電所 大規模な発電設備 低料金で安定供給を実現 設備の運用・管理・保守から解放 需要変動に柔軟に対応 工場内・設備 送電網 データセンター 大規模なシステム資源 低料金で安定供給を実現 設備の運用・管理・保守から解放 需要変動に柔軟に対応 システム・ユーザー デ ー タ インターネット
- 22. クラウドはシステム資源のECサイト 見積書 契約書 調達手配 導入作業 メーカー ベンダー サイジング 調 達 費 用 数週間から数ヶ月 数ヶ月から数年を想定 現物資産またはリース資産 従来の方法 セルフ･サービス・ポータル 調達・構成変更 サービスレベル設定 運用設定 ・・・ 数分から数十分 直近のみ・必要に応じて増減 経費・従量課金／定額課金 クラウド オンライン･リアルタイム
- 24. 徹底した標準化 大量購入 負荷の平準化 APIの充実・整備 セルフサービス化 機能のメニュー化 クラウド・コンピューティングのビジネス・モデル 24 クラウド・コンピューティング オンデマンド 従量課金 自動化・自律化 システム資源 の共同購買 サービス化 低コスト 俊敏性 スケーラビリティ SDI (Software Defined Infrastructure)
- 25. IT活用適用領域の拡大 難しさの隠蔽 システム資源 エコシステム クラウドが生みだすパラダイムシフト 25 クラウド・コンピューティング IT利用のイノベーションを促進 ビジネスにおけるIT価値の変化・向上 新たな需要・潜在需要の喚起 モバイル・ウェアラブル ソーシャル 人工知能 ビッグデータ IT利用者の拡大 IoT ロボット 価格破壊 サービス化
- 26. クラウドがもたらすビジネス価値 構築や運用からの解放 最新テクノロジーの早期利用 資産から経費へのシフト アプリケーションの質的向上にリソースをシフトできる ビジネス・スピードの加速に迅速柔軟に対応できる 試行錯誤が容易になってイノベーションを加速する テクノロジーの進化をいち早くビジネスに取り込める 初期投資リスクが削減でき、IT活用範囲を拡大できる ビジネス環境の変化に柔軟に対応できる
- 27. クラウドを使うことの狙い 27 構築や運用からの解放 最新テクノロジーの早期実装 資産から経費へのシフト アプリケーションの質的向上にリソースをシフトできる ビジネス・スピードの加速に迅速柔軟に対応できる 試行錯誤が容易になってイノベーションを加速する テクノロジーの進化をいち早くビジネスに取り込める 初期投資リスクが削減でき、IT活用範囲を拡大できる ビジネス環境の変化に柔軟に対応できる ビ ジ ネ ス の 成 果 に 直 接 貢 献 す る
- 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月から開始すると発表した。
- 30. 銀行システムにおけるクラウド活用の動き 30 日本ユニシスとマイクロソフト、「BankVision on Azure」実現に向け共同プロジェクトを開始 2018年3月23日 日本ユニシス株式会社と日本マイクロソフト株式会社 は23日、日本ユニシスのオープン勘定系システム 「BankVision」の稼働基盤として、Microsoft Azureを 採用するための取り組みを推進するため、共同プロ ジェクトを4月から開始すると発表した。 いかに費用を抑え、最新技術も取り入れた上で短期間 でのシステム開発を行うかという課題に対応するため、 クラウドを選択。現在はクラウド最大手の米アマゾン ウェブサービスと組み、業務システムの一部から移行 を進めている。 5年間で100億円のコスト削減 1000超のシステムの約半分をクラウド化 週刊ダイヤモンド 2017.5.17 https://diamond.jp/articles/-/128045
- 32. クラウド・バイ・デフォルト原則 32 政府情報システムにおけるクラウドサービスの利用に係る基本方針 クラウド・バイ・デフォルト原則（クラウドサービスの利用を第一候補） 政府情報システムは、クラウドサービスの利用を第一候補として、その検討を行う 情報システム化の対象となるサービス・業務、取扱う情報等を明確化した上で、メリット、開発の規模及び経費等を基に検討を行う https://cio.go.jp/sites/default/files/uploads/documents/cloud_%20policy.pdf Step0：検討準備 クラウドサービスの利用検討に先立ち、対象となるサービス・業務及び情報といった事項を可能な限り明確化する。 Step1：SaaS（パブリック・クラウド）の利用検討と利用方針 サービス・業務における情報システム化に係るものについて、その一部又は全部が SaaS（パブリック・クラウド）により提供されてい る場合（SaaS（パブリック・クラウド）の仕様に合わせ、サービス・業務内容を見直す場合も含まれる。）には、クラウドサービス提 供者が提供する SaaS（パブリック・クラウド）が利用検討の対象となる。 Step2：SaaS（プライベート・クラウド）の利用検討 サービス・業務における情報システム化に係るものについて、その一部又は全部が、府省共通システムの諸機能、政府共通プラット フォーム、各府省の共通基盤等で提供されるコミュニケーション系のサービスや業務系のサービスを SaaS として、当該サービスが利用 検討の対象となる。 Step3：IaaS/PaaS（パブリック・クラウド）の利用検討と利用方針 SaaS の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、民間事業者が提供する IaaS/PaaS（パブリック・クラウド）が利用検討の対象となる。 Step4：IaaS/PaaS（プライベート・クラウド）の利用検討 IaaS/PaaS（パブリック・クラウド）の利用が著しく困難である場合、又は経費面の優位性その他利用メリットがない場合については、 サーバ構築ができる政府共通プラットフォーム、各府省独自の共通基盤等を IaaS/PaaS として、当該サービスが利用検討の対象となる オンプレミス・システムの利用検討
- 33. 政府の基盤システム Amazonへ発注 33 人事・給与や文書管理など各省共通 の基盤システムをAWSに発注。 整備・運用にかかる費用は2026年度 までで300億円を超える見通し。 政府は各省庁のシステムについて4〜 8年で原則クラウドにする方針を打ち 出している。 目的は、コストの大幅減と、最新の デジタル技術の取り込みにつなげる ため。 自前で管理する手間が減り、人員の 効率的な配置など生産性の向上も見 込める。 https://www.nikkei.com/article/DGXMZO55498840R10C20A2MM8000/ 2020.02.12
- 35. メガクラウド・ベンダーの内製化支援プログラム FastTrack for Azureのサポート対象ソリューション AWS Cloud Adoption Framework（CAF）
- 39. 誤解２：ガバナンスが効かない？ 39 インフラ プラットフォーム 運用管理 アプリケーション 業務対応 自社対応 クラウド 自社所有 IaaS PaaS SaaS 責任分界点が変わる：運用管理 × セキュリティ対応
- 42. クラウド・コンピューティングの起源 ～ シュミットの対談 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、携帯電話、ブラック ベリー、その他あらゆるものから - あるいは、 まだ開発されていない新しいデバイス - クラウ ドにアクセスできる。” 「クラウド」上のサーバー 適切なアクセス手段 開発中の新しいデバイス
- 43. ネットワーク （インターネット） 巨大なコンピューター・システム群向 こ う 側 こ ち ら 側 クラウド・コンピューティングの起源とGoogleの定義 利用する側：自分専用のシステム 提供する側：世界中の複数拠点に分散配置 43 Google CEO エリック・シュミット 6.Mar.2006, “Search Engine Strategies Conference @ San Jose, CA データもプログラムも、サーバー群の上に置いておこう・・・そういったものは、ど こか “雲（クラウド）”の中にあればいい。必要なのはブラウザーとインターネットへ のアクセス。パソコン、マック、携帯電話、ブラックベリー、とにかく手元にあるど んな端末からでも使える・・・データもデータ処理も、その他あれやこれやもみんな サーバーに、だ。 http://www.google.com/press/podium/ses2006.html
- 45. クラウドの定義／サービス・モデル (Service Model) アプリケーション ミドルウェア オペレーティング システム インフラストラクチャ PaaS Platform as a Service Infrastructure as a Service Software as a Service SaaS Salesfoce.com Google Apps Microsoft Office 365 Microsoft Azure Force.com Google App Engine Amazon EC2 IIJ GIO Cloud Google Cloud Platform アプリケーション ミドルウェア & OS 設備 & ハードウェア プ ラ ッ ト フ ォ ー ム IaaS
- 46. クラウドの定義／サービス・モデル (Service Model) アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 サーバー ストレージ ネットワーク アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 (必ずしも使わない) サーバー ストレージ ネットワーク アプリケーション データ ランタイム ミドルウェア オペレーティング システム 仮想化 (必ずしも使わない) サーバー ストレージ ネットワーク アプリケーション（アドオン） IaaS PaaS SaaS ア プ リ ケ ー シ ョ ン 利 用 す る 企 業 の 責 任 ク ラ ウ ド 事 業 者 の 責 任 プ ラ ッ ト フ ォ ー ム イ ン フ ラ ス ト ラ ク チ ャ ー
- 47. ＸaaSについて a a S s ervice サービス としての 〜 効用や満足などを提供する 形のない労働や役務のこと 〜 物理的実態／形あるモノの提供を伴わなわずに 機能や性能を提供して対価を受け取るビジネス IaaS PaaS SaaS Software（アプリケーションのこと） の機能や性能を提供するサービス Platform（OSやミドルウェアのこと） の機能や性能を提供するサービス Infrastructure（ハードウェアや設備のこと） の機能や性能を提供するサービス DaaS Desktop（PC画面／PCでできること） を提供するサービス MaaS Mobility（移動する） ための手段を提供するサービス CaaS Communication（会議やチャットのこと） の機能を提供するサービス サブスクリプション または従量課金など サービス設備や機材は サービス事業者の資産 オンライン・サービス ／クラウド・サービス
- 48. クラウド・サービスの区分 自社所有 IaaS 仮想マシン CaaS PaaS FaaS ユーザー企業が管理 ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS SaaS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ ハードウェア 仮想マシン コンテナ 管理機能 ミドルウェア アプリケーション OS ランタイム データ IaaS ベアメタル クラウドサービス事業者が管理 連携機能 CaaS PaaS FaaS SaaS
- 49. クラウドの定義／サービス・モデル (Service Model) プラットフォーム 開発や実行に必要なソフトウエア 実行と運用管理 アプリケーション 業務遂行に必要なソフトウエア 実行と運用管理 インフラストラクチャー プロセッサー、メモリー、ストレージ、 ネットワークなどのシステム資源、施設 実行と運用管理 サービス 事業者 サービス 事業者 サービス 事業者 PaaS IaaSSaaS ユーザー 自社所有 ユーザー ユーザー
- 50. ふたつのタイプのIaaS （日本の個別事情） 運用管理 構築（作成） 起動/シャットダウン バックアップ 仮想マシンの複製 リソースの変更や監視 運用サービス設定など システム資源 プロセッサー メモリー ストレージ デスクトップ ネットワーク データセンター設備など サービス事業者 標準化されたシステム構成、運 用管理メニューを提供。調達・ 運用管理の自動化を徹底。 ユーザー セルフサービス・ポータルを 使って自社要員で必要な管理・ 設定を行う。 サービス事業者 ユーザーの個別の要望に応じて、 サービス事業者がシステムの構 築、運用設計を実施。それに応 じた運用サービスを提供する。 割安。継続的なサービスや機能 の拡充、コスト低減などを享受 できる。 割高。サービスや機能は固定化 または変更に手間はかかる。継 続的なコスト低減は難しい。 セルフサービス型 IaaS フルサービス型 IaaS AWS,SoftLayer,cloudnなど 国内SI事業者に多い NISTの定義に該当
- 51. ハイブリッド・クラウド 複数企業共用 パブリック・クラウド クラウドの定義／配置モデル (Deployment Model) プライベート・クラウド 個別企業専用 個別･少数企業 不特定・複数企業／個人 LAN LAN インターネット 特定企業占有 ホステッド・プライベート・クラウド 固定割当て LAN 専用回線・VPN LAN
- 52. マルチテナント方式の課題を解決する選択肢 52 アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS アプリ ケーション ミドルウェア OS ハードウェア アプリケーション ミドルウェア OS 仮想マシン 仮想マシン 仮想マシン 仮想マシン 仮想マシン 仮想マシン A社 C社B社 A社 A社 仮想化 Hypervisor ハードウェア 仮想化 Hypervisor ハードウェア マルチテナント方式 シングルテナント方式 ベアメタル方式 ホステッド・プライベート・クラウド 【リスク1】クラウドベンダー都合でのメンテナンス停止が発生する（ユーザー側都合での調整はできない） 【リスク2】高可用性を担保するアーキテクチャ設計の難易度が上がる 【リスク3】性能を完全に保証するには懸念がある （同一ハードウェア内で他のユーザーの区画も動作しており、他ユーザーが大量にコンピュートリソースを消費するようなことがあると影響を受ける懸念がある）
- 53. プライベートクラウド（１） 53 http://www.idcjapan.co.jp/Press/Current/20150909Apr.html 国内プライベートクラウド市場 配備モデル別支出額予測 2014年〜2019年 オンプレミス・プライベートクラウド ホステッド・プライベートクラウド デディケイテッド・プライベート・クラウド コミュニティ・プライベート・クラウド プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ユーザー企業構内に設置 自社資産 自社運用・管理 サービス事業者施設内に設置 サービス事業者の資産 定額利用料金／従量課金 パブリック・クラウドの一部を ユーザー（テナント）に占有使用 ユーザー（テナント）毎のプライ ベート・クラウドを管理・運用
- 54. プライベートクラウド（２） 54 プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ユーザー企業に システム資源を 占有・割り当て パブリック・クラウド ユーザー企業・自社構内 データセンタ・占有借用施設内 クラウド・サービス事業者 自社専用 クラウド環境 予め用意された 標準仕様を組合せ ユーザー企業毎に 個別仕様で クラウドを提供 ユーザー企業の資産 クラウド・サービス事業者の資産 運用管理責任は自社 運用管理責任は事業者 運用管理責任は事業者 リースまたは減価償却 サブスクリプション サブスクリプション+初期費用 OpenStack（OSS） Microsoft Azure Stack Vmware vSphere など AWS Virtual Private Cloud Microsoft Virtual Network IBM Blumix Dedicated など NTT コム Enterprise Cloud NSSOL absonne CTC CUVICmc2 など
- 55. ハイブリッド・クラウド モバイル連携 使い分け 災害対策 負荷調整 SaaS連携 ピーク対応 柔軟対応 PublicPrivate PublicPrivate PublicPrivate PublicPrivatePublicPrivate PublicPrivate PublicPrivate パブリックで モバイル・ア プリケーショ ンと連携 プライベート で基幹業務系 の処理 業務ごとに両 者を使い分け 通常時はプラ イベート 災害時にはパ ブリックに切 り替え プライベート で負荷をまか ないきれない ときにパブ リックを追加 リソースとし て使用 パブリックで SaaSを使用 そのデータを プライベート の業務システ ムで処理する 通常はプライ ベートで処理 するがピーク 時はパブリッ クにリソース を拡大する 業務状況に応 じて業務や データを両者 で柔軟に使い 分ける （単一リソース） 業 務 Ａ 業 務 Ｂ 業 務 Ｃ 業 務 Ｄ 業務 業務 業務 業務 負荷調整 業務 SaaS 業務 業務 業 務 Ａ 業 務 Ｂ 業 務 Ｃ 業 務 Ｄ 対象とする業 務アプリケー ションへのア クセス方法 業務の配置と 統合監視・管 理方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 ネットワーク 帯域・設定 振り分けが自 動か手動で難 易度が変わる SaaS/API連携 の方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 データやアプ リケーション 同期の方法や タイミング サイト切り替 え法 統合監視・管 理方法 構築の難易度 低 低 中 高 高 高+ 高+
- 57. ハイブリッド・クラウド（３） 同一のアーキテクチャー リソース Ａ リソース Ｂ リソース Ｃ パブリック・クラウド プライベート・クラウド クラウド基盤 仮想基板 セルフサービス・ポータル リソース Ａ リソース Ｂ リソース Ｃ ユーザー・ビュー パブリックと プライベートが ひとつの リソース プール 標準化の主導権争い
- 59. ハイブリッド・クラウドとマルチ・クラウド 59 クラウド管理プラットフォーム Prime Cloud Controller (SCSK) / RightScale (RightScale) / vRealize Suite (Vmware) など オンプレミス（自社構内） データセンタ（自社設備） データセンタ（他社設備） コロケーション／ホスティング パブリック・クラウド パブリック・クラウド バーチャル プライベート クラウド ハイブリッド・クラウド マルチ・クラウド インターネット／ＶＰＮ／専用線 (SDN : Software-Defined Network) 個別専用システム ハイブリッド・クラウド マルチクラウド
- 60. クラウドの分類と関係 60 個別システム ホステッド プライベート クラウド SaaS（Software as a Service） PaaS（Platform as a Service） IaaS（Infrastructure as a Service） SaaS PaaS IaaS プライベート・クラウド パブリック･クラウド／クラウド事業者資産を使用 オンプレミス・システム／自社資産として所有 ハイブリッド･クラウド プライベートとパブリックの連係･組合せ マ ル チ ・ ク ラ ウ ド 複 数 の パ ブ リ ッ ク を 連 係 ・ 組 合 せ
- 61. 仮想化とクラウド(IaaS)との違い 仮想化 運 用 管 理 調 達 インフラに関わるシステム資源を ソフトウェアの定義・設定により調達、構成変更 調達機能と 運用管理機能の 連携と自動化 個別対応 自動化/人的作業 システム資源の利用効率向上 人的作業の負担軽減 調達・変更の俊敏性と生産性向上 仮想化 クラウド（IaaS）
- 63. PaaS
- 64. ASPからSaaSへ、ホスティングからIaaSへ オンプレミス アプリケーション ミドルウェア OS/ハードウェア サービスプロバイダ ASP Application Service Provider ネットワーク上のサー バーにパッケージソフトを 搭載してネットワーク越し に提供 Hosting/Housing データセンターの サーバーを ネットワーク越しに提供 クラウド SaaS IaaS SaaS Software as a Service (1999〜) マルチテナント対応アプリ ケーションを「サービス」と して提供し、従量課金 PaaS (2007〜) IaaS (2006〜) サービスとして 提供従量課金
- 65. データセンター データセンター ASPとSaaSの違い – マルチテナント サーバー サーバー サーバー アプリ アプリ アプリ サーバー サーバー 仮想化 顧客 顧客 顧客 アプリ アプリ アプリ データセンター サーバー アプリケーション 顧客 顧客 顧客 パッケージをそのまま使用 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い または マルチテナントDB ASP SaaS
- 66. PaaSの誕生 Salesforce (1999) Salesforce Database Workflow Other User App User App Salesforceの顧客から、Salesforce が持っているデータベース、ワーク フローなどの機能を使ってCRM以 外のアプリを作成したいという要望 が高まった APIを整備して公開 (2007.7) → Force.com (2007) → database.com (2010) マルチテナントDB
- 67. Force.comのターゲットマーケット 消費者 全社 部門 グループ コンテンツ データ プロセス トランザクション アプリケーションのタイプ ユーザーのタイプ Excel 以上、全社システム以下 全社規模の基幹システムであればコ ストをかけてシステムを開発できる 部門レベルでは、コストをかけられな い一方で変化の速度が速いため、改 修が頻繁に起こるため、IT部門もSIer も対応しにくい。 このためユーザーが自分で作る必要 があるが、一から作るのは大変なた め、何からのツールが必要。 → Notesのマクロ → Excel/Access
- 68. アプリ開発基盤としての Lotus Notes グループウェア＝グループ内での情報共有、コミュニケーション、コラボレーションを支 援するソフトウェアスイート 様々なコミュニケーション機能をワンパッケージ化 電子メール BBS 電子会議室 ライブラリ スケジューラ ワークフロー （電子決裁） グループウェアのアイ デアは1960年代末か らあった PCの普及により情報量 が増大し、情報の効率 的共有へのニーズが 増した 1989＝インターネット普及前 当時Lotus Notesが 大企業に受け入れ られた理由 細い回線でも効率的にレプリ ケーションを行うことができ、複数 の拠点を持つ大企業にとって使 い勝手が良かった 強力で柔軟なスクリプトにより、 ワークフローを比較的簡単に作り 込むことができた インターネット の商用利用開 始は1988年
- 71. データセンター データセンター ASPとSaaSの違い – マルチテナント サーバー サーバー サーバー アプリ アプリ アプリ サーバー サーバー 仮想化 顧客 顧客 顧客 アプリ アプリ アプリ データセンター サーバー サーバー サーバー アプリケーション 仮想化 顧客 顧客 顧客 パッケージをそのまま使用 複数企業での共有を前提とした設計 データの分離、セキュリティに配慮 メンテナンスコストが低い リソースの利用効率が高い または マルチテナントDB ASP SaaS
- 72. Oracle 12cのマルチテナントアーキテクチャ コンテナデータベース(CDB)上 にプラガブルデータベース (PDB)を作成 ひとつのインスタンスで複数の スキーマを運用 スキーマ統合を課題を解決
- 73. マッシュアップ開発の部品としてのWebサービス クラウドサービス API クラウドサービス API クラウドサービス API マッシュアップ開発 IT の深い知識がなくても、既存 のWebサービスAPIを組み合わ せて、短期間でアプリケーション 開発を行うこと。新しい開発技法 として注目されている。 様々なWebサービスやBaaSなど のサービス、豊富なOSSなどによ り、新たなプログラミングをせず にアプリケーションを開発するこ とが可能になってきた マッシュアップ 自社サービス Application Programming Interface 外部からプログラムの機能やデータにアクセス するための手順やデータ形式
- 75. SOA SOA (2000年前後) ビジネスプロセスをサービス化 クラウドへの対応 ビジネスプロセスを サービスとして実装 既存システムを相互接続して統合 EAI (1990年代末) ばらばらに開発された業務システ ムをプロトコル変換などで統合 従来は部分最適な業務システム 個別にシステム設計開発 現場の仕事をそのままシステム化 「その時点」での技術を使って開発 他システムとの連携は必要に応じて設計・ 実装 全社的最適化という視点はない 全社最適化手法 EA Enterprise Architecture BPR Business Process Re-engineering ERP Enterprise Resource Planning
- 76. SOAは思想であり考え方 • SOAの定義（Wikipedia） – 業務上の一処理に相当する単位でソフトウェアが構成されていること。SOAにおけるサービスとは、 その構成単位のことである。プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会 する」などの単位で一つのサービスとすることが求められる。どの程度の規模（粒度）を一つのサー ビスとするが良いのかについては様々な議論がある。 – オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従っ た呼び出し、応答が可能であること。その技術的基盤として、Webサービスの使用が事実上必須と なっている。 – サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。この段階にいたる までには、先の二つの条件が必須となる。さらに、サービスを単位として業務処理の流れを記述す る技術や、その記述通りにシステム連携を実行する技術も必要となる。 SOAとは、ビジネスプロセスに沿って業務システムを構築することであり、システム構築 の手法（思想）といえる。 SOAという製品は存在しない。SOAという考え方に基づいて、大規模なシステムを個々 のプロセスに対応するサービスの集まりとして構築する。 実装方法としてWebサービスが使われることが多いが、Webサービス＝SOAではない。 WebアプリケーションサーバーやSOAPなどはSOAによるシステム構築のための技術的 要素に過ぎない。 クラウドと親和性が高い
- 78. Webサービス (Web Service) XMLでデータ交換できるインターフェイスを持つアプ リケーション・システム。SOAを実現する技術とも言 える。インターネット上で、Webサービスが、XMLを 使って相互にデータを交換し、連携することで・・・ 単体のWebサービスだけではできない、利便性 や機能の高いアプリケーションを構築できる Webサービスの組合せを固定化させず、柔軟な アプリケーションを構築できる 組合により多様なアプリケーションが展開できる SOAとクラウドの関係 78 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年頃
- 79. SOAとクラウドの関係 79 販売管理の業務に沿ったビジネス・プロセス 受注 請求 入金 出荷 SOAをベースにした販売管理プロセス 受注 請求 入金 出荷 ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷請求 入金 プロセスの各業務単位（サービス）に合わせて ソフトウェアを作ってあるので、後でプロセス が変わっても柔軟に対応できる サービス間でやりとりするデータの種類、 フォーマットをXMLで決めて標準化 各ソフトをWebアプリ (Webサービス)にしておく と、柔軟性が高まる 従来型のシステム構築手法による販売管理システム 受注 請求・入金 出荷 ビジネス・プロセスに合わせてシステムを構築 していない場合、後で変更するのが大変 他のシステムとの連携を考えていない場合（イ ンターフェースの標準化が行われていない）、 後から付け加えるのは大変な作業になる 要求仕様 プロセス単位で サービス化 伝票のフローに沿ったシステム 情報のフローに沿ったシステム サービス 業務上の１処理に相当する機能
- 80. IaaS Webサービスを組み合わせてシステムを構築 SoftLayer Gmail ML Docs Google EC2 Aurora Lambda Amazon サービス 自社サーバー サービスの部品化により クラウドの活用範囲が拡大 クラウド上のサービスを 組み合わせてシステムを構築
- 81. SOAの実装としてのESB SOAをベースにした販売管理プロセス 受注 請求 入金 出荷 ビジネスプロセスの変更にも柔軟に対応可能 受注 出荷請求 入金 受注 請求 入金 出荷 ESB その他のサービス レガシーシステムなど 小規模なシステムな らWebサービスベー スでも可 大規模なシステムで はESBが有効
- 84. Googleのクラウド・セキュリティ対策 84 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攻撃からの防御も行う。
- 86. クラウドで実現するガバナンス 86 ガバナンスを担保するためには・・・ 効率 利便性 コスト リスク ガバナンス Governance 状 況 が 見 え る 状 況 が 調 整 ・ 変 更 で き る 一元管理され、利用状況を計測でき、利用ログを把握できる。 必要な時に必要な機能／性能／資源をプロビジョニングできる。 管理の対象を減らすことができる。 クラウドで できること
- 88. 日米の企業文化の違いとクラウドへの期待IPA人材白書・2012／日経SYSTEMS 2012/8を参考に作成 ITエンジニア の人数 ユーザー 企業 ITベンダー企業 75% ユーザー企業 72% ITベンダー 企業 ITベンダー企業の生産性向上 + ベンダーがリスクを背負わされる ユーザー企業の生産性向上 + ユーザーが自らリスクを担保 エンジニアリング・ワークの生産性が劇的に向上 運用の自動化 ＋ 調達の自動化 ＝ エンジニアの調達・運用管理負担の軽減 約100万人 約300万人
- 89. クラウドの価値を引き出すための戦略 TCOの削減 変更変化への 柔軟性と迅速な対応 資産の削減 人員の削減 既存資産の償却 社会思想・企業文化の問題 ファイナンスの問題 スピード スケール アジャイル 戦略価値への期待 グローバル化の進 展 ビジネス・ライフサイ クル の短命化 顧客嗜好の多様化 効率・コストへの期待 ビジネス環境の変革に対応
- 90. パブリック・クラウド適用のリスク 90 管理主体の違い 事業者によるシステム設計と運営管理 投資の内容や優先順位の判断 セキュリティやサービスレベルの維持などの統制活動 障害や情報漏えいなどのインシデント発生時の情報連携 インシデントに関する情報開示範囲や原因究明作業に対するユー ザー関与に制約 インシデントの全体像や根本原因の特定が不十分な恐れ 自社のシステム環境の移植性の問題 サービス終了時にデータの引き継ぎに制約が生じる恐れ サービス品質に対して実施するリスク管理の有効性について、 ユーザーが期待するレベルまで実施されていない、また、実施さ れていても情報開示の制約でユーザーが確認できない恐れ 情報開示の限界 セキュリティ管理ルールの十分性や運営実態について、情報開示 範囲に制約 契約で合意した内容の履行状況に関してユーザー側の確認が撮り にくい ベンダーの情報開示情報と自社のセキュリティポリシーなどとの 整合性を十分の確認が困難 機能やサービス内容の制約 個別カスタマイズの制約 ユーザー固有のカスタマイズが実現できないため業務影響の見極 めや対策について検討が必要 サービスに関する意思決定権 事業戦略の変更や破綻などにより、一方的にサービスの終了や変 更、また、サポート停止により、ユーザーの業務継続や顧客への サービス提供に影響を及ぼす恐れ サービスの多様化・グローバル化 データの所在 データセンター設置国の法令への遵守 海外の現地規制当局の強制執行などによるデータ閲覧やデータ収 集、通信傍受により業務継続に支障、情報漏えいの恐れが ベンダーのグローバル化 本社拠点（各種意思決定機能）を海外に置くベンダーも多く、 サービス内容や提供価格、契約条件などの調整がスピード感を もって推進できない恐れ ベンダーの本社が海外にあることで、係争時の管轄裁判所が海 外となり、海外の係争への対応が必要となる恐れ インシデント発生時に時差や言語の問題から、ベンダー、ユー ザー間のコミュニケーションに支障をきたす恐れ 役割分担や責任範囲の多様化 責任や役割の固定化 ユーザーの個別要求事項を前提とした諸条件の調整が困難 自社のニーズをふまえた「融通」が利きにくく、ユーザー側で追 加の対応手続きやリソース手配などが必要となる恐れ マルチベンダーで一つのITサービスを実現する場合情報連携に混 乱や支障をきたす恐れ 導入に伴うハードルの低下 簡単迅速なサービス導入 ユーザー部門が自社のセキュリティポリシーやシステム化方針な どへの影響確認を十分に実施せずに単独で導入してしまい、全社 的なシステム統制に影響を及ぼす恐れ http://japan.zdnet.com/article/35063430/
- 91. パブリック・クラウド 移行の勘所
- 92. パブリック・クラウドへ移行すればコストを削減できるか？ 92 現行システム（オンプレミス）の構成や運用をそのままに移行しても コスト削減は難しい サーバー台数 サーバー台数が多いとシステムが複雑になり、構築・インテグレーション費用が増加する 販売代理店（SI事業者など）に任せると台数に応じて販売マージンや手数料が必要となる 管理対象のサーバー台数が多いと保守・サポート費用が増加する サーバー稼働時間 使わないサーバー・インスタンスが停止されずに動いている 割引が効くはずの年額一括にしたが、全てを使われずに無駄な費用を払ってしまう 常時稼働が前提のオンプレミスと同じ運用方法で料金が嵩んでしまう サービス・レベル パックアップ 冗長化構成 その他、サポートオプションの契約 データ転送コスト ダウンロードデータ転送（外部へのデータ持ちだし） 外部ネットワーク回線費用（閉域網、国際回線等） 社員人件費 運用管理などに関わる社員の人件費はクラウドに機能が移管してもそのまま残存 SI事業者によっては、サーバー台数 を増やそうとする場合がある！
- 97. クラウドサービスのコスト構造 97 サーバー ストレージ データ転送 内部ネットワーク 外部ネットワーク 能力×時間 容量／月 転送量（GB） ダウンロード 定額／月 転送量 ポート速度100Mビット秒 オプション機能 FW、LBなど オプション単位 インスタンスの能力に よって料金は異なる。 外部へのデータ転送量 に応じて課金される。 サービスによって異な る。 セグメント数、外部 ネットワークとの接続 に伴うデータ転送量に 応じて課金される。 専用線などの閉域網、 海外DCとの国際回線の 費用などが必要となる。 サービスによっては標 準機能として提供され る場合もある。 冗長化構成を減らす 変動／固定を動的に組合せる 必要なインスタンスのみ稼働させる 運用を自動化する ベンダーを通さず直接契約にする データ・ライフサイクルを見直し ホット/コールドデータを分けて保管 容量無制限のファイルサーバーと組 み合わせる アクセス速度に応じて サービス・料金が異な る。 アプリケーション設計の見直し 同一セグメント内での転送 運用方法の見直し セグメント内で完結するような設計 国際回線を多用する場合は回線料金 が組み込まれたサービスを選定 不要なオプションは設定しない オ ン プ レ ミ ス を そ の ま ま に 移 行 せ ず 構 成 ・ 運 用 を 再 設 計
- 98. 料金の削減のポイント（１） 98 必 要 能 力 調達するサーバー能力 必 要 能 力 調達するサーバー能力 運用自動化ツールの活用 よく似た運用パターン・グループ に集約しインスタンスを削減
- 99. 移管の考え方 99 IaaS PaaS SaaS オンプレミス・システム 1. コスト 5年間のTCO 2. BCP 遠隔多重化構成など 3. バックアップ／アーカイブ 電子メール、業務データなど 4. ユーザー利便性 応答時間、グローバル対応など 5. ガバナンス 見える化、管理機能など そのまま移行すれば オンプレミスよりもコストが嵩む 運用管理負担が増える 機能面で利用部門のニーズに応えられない サービスレベルが低下する セキュリティが担保できない 上記、組合せの最適解を考える クラウド前提のアーキテクチャーに見直す 情報システム部門の役割を再構築する
- 100. 移管に関する考慮事項 100 システム・アーキテクチャー変更にともなう スループットやレスポンスなどの影響度 分析やリスク検証 投資を正当化するため、オンプレミスと の比較における投資対効果の明確化 非機能要件の見直し セキュリティポリシーや個人情報保護方針との適合性や システム監査への対応要件を満たすかどうかなど 運用方法の変更 パブリッククラウドの提供機能やセ キュリティポリシーなどの評価 既存業務システム （オンプレミス） パブリッククラウドへの移管 仮想サーバーの パブリッククラウドへの移管 パブリッククラウドでの 新規システム構築 海外システムのクラウド化 越境データ規制 個人情報保護規定 犯罪捜査権 など
- 102. システムデザイン勘所 102 Design of Failure 障害発生を前提とし、 障害が発生しても問題なく運用できるような設計を行うこと システム機器ではなくサービスとしての健全性を保つこと 全体の可用性の担保が最重要 SPOF（Single Point of Failur：単一障害点）を作らない構成 多様な監視方法を組み入れること 外からの監視：反応があるか、ないか 内からの監視：受けられるか、受けられないか サービスからの報告：サービス自身の健全性の主張 データを収拾し、閲覧する体制を作る いつでも、増やせる、削除できる仕組みとする データを集積し、利用状況を分析する 分析結果を踏まえてブラッシュアップを継続する 自動化する いつ起きるか分からないことへの対応を自動化で対処する 検知、報告、対応までの自動化を目指す 監視 ログ 収集 通知 復旧 改善 分析
- 104. クラウドへの移行を成功させるための7原則 104 1. 既存システムの移行をゴールとしない、クラウド･ネイティブの実現を目指す 2. 絶対に今まで通りでなければならない、という要件を排除する 3. クラウドならではの作法、考え方を許容する 4. ユーザー自身で運用管理する。そのためのスキル獲得予算を確保する 5. クラウド・インテグレーションにスキルのあるIT企業に参画してもらう 6. クラウドにあるサービスを割り切って使用する 7. ビジネスのデジタル化を実現する前提として、IT利用の在り方を見直す “なぜ「不毛なクラウド議論」がなくならない？ 論外なIT部門7つの特徴”を参考に作成
- 105. クラウド移行の方向 105 リフト シフト シフト インテグレーション シフト クラウド クラウド クラウド 既存システムの一部移管 SaaSの利用 ハイブリッド･クラウド による連係運用・一元管理 オール･イン･クラウド への全面移行 Webスケール／クラウド技術 を使ったハードやソフト 各社HCI、Azure Stack、AWS Outposts、Google On-Premなど IoT／エッジ･コンピューティング リアルタイム・コンピューティング オンプレミス･コンピューティング 個別専用システム シフト ドロップ
- 106. クラウドに吸収されるITビジネス 106 アプリケーション・ビジネス • ビジネス開発 • システムの企画 • システム設計 • プログラム開発・テスト • 開発・テスト環境の構築 • 本番実行環境の構築 • セキュリティ対策 • 運用管理 • トラブル対応 ネットワーク・ビジネス • ネットワークの設計 • ネットワーク機器の導入・設定 • セキュリティ対策 • 監視・運用管理 • トラブル対応 インフラ・ビジネス • インフラの設計 • インフラ機器の導入・設定 • セキュリティ対策 • 監視・運用管理 • トラブル対応 クラウド・データセンター内 ネットワーク クラウド・データセンター間 バックボーンネットワーク 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 ローコード開発ツール
- 107. クラウド・ネイティブへのシフトが加速する 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 オンプレミス環境にパブリック・クラウドと 同等の環境を構築する製品やサービス オンプレミスとパブリック・クラウドを 一元的に運用管理するサービス ハイブリッド・クラウド マルチ・クラウド
- 108. クラウド利用の推移 108 SaaS 汎用業務の移管 アプリケーション 独自業務の移管 仮想マシン クラウド･ネイティブでの構築 コンテナ&サーバーレス 仮想マシンによるハイブリッド・クラウド クラウド技術で作られたオンプレ製品 コンテナによるハイブリッド&マルチ･クラウド サーバーレスによるクラウドネイティブ 独自性の高い業務は個別専用システム 独自性の低い汎用業務はSaaS IaaS PaaS Office365 G-Suite Box など Amazon Outposts Microsoft Azure Stack Google GKE-On-Prem AWS EKS Google GKE Microsoft AKS
- 109. オンプレとパブリック・クラウドの関係の推移 109 SaaS SaaS IaaS SaaS PaaS IaaS 個別業務システム 個別業務 システム クラウド アプライアンス 物理と仮想の混在環境 コモディティはクラウド 主に仮想環境 一部IaaSに移管 基本はクラウド 低遅延が求められる システムはオンプレ PaaS/CaaS/FaaS 主流 AWS Outposts Azure Stack HCI Google On-prem など Vmware ESXi Microsoft Hyper-v KVM など Vmware ESXi Microsoft Hyper-v KVM など CaaS FaaS パブリック クラウド オンプレミス
- 110. 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 もある
- 113. クラウドへの移行が難しい場合 113 モノリシックなシステム： オンプレミスで実行する必要のあるアプリケーションと緊密に結びついており、そのアプリケーション と関連するデータベースと統合され、特定のランタイムや特定のバージョンのデータベースサーバに合 わせてチューニングされている場合。 パフォーマンスや信頼性を確保するために、特定のプラットフォームの特定のバージョンのデータベー スにチューニングされている場合。 頻繁なデータ出力： パブリック・クラウドは、データのアップロードは無料だが、出力には料金を課している。データ出力 が頻繁に発生する場合、課金が高額になる場合がある。 複雑なデータ構造： データ構造が複雑で、公開されても構わないデータと外部に流出するリスクを冒すことが絶対に許され ないデータが混在している場合。 低レイテンシ： オンプレミスとクラウド･データセンター間の回線の制約から、大量のデータをデータセンターからク ラウドに移動させるには、数時間、あるいは数日かかる場合。 リアルタイムのユーザーデータのやりとり、高速なアナリティクス、パーソナライゼーション、レコメ ンデーションなどを利用するモダンなアプリケーション。 モノのインターネット（IoT）。ローカルのIoTデバイスから速いペースでデータを収集しているので あれば、クラウドに直接データを送信するのでは時間がかかりすぎる可能性がある。オンプレミスデー タベースおよびエッジ・サーバーが合理的。 Zdnetの記事を参考に編集：https://japan.zdnet.com/article/35132951/
- 114. 異なる文化の２つのクラウド戦略 コスト削減のためのクラウド 競争力強化のためのクラウド 生産性向上・納期短縮・コスト削減 投資負担の軽減 運用管理負担の軽減 高い運用品質の維持 コスト削減 資産固定化の回避 最新技術の活用 俊敏性の実現 投資対効果 差別化・競争力・変化への即応力 既存システムのIaaS移行 運用管理の自動化 開発と運用の順次化 コンテナ×Kubernetes PaaS×サーバーレス 開発と運用の同期化 クラウド・リフト 戦略 クラウド・ネイティブ 戦略 守りの文化 by 情報システム部門 攻めの文化 by 事業部門・経営直下 予算と人材と戦略の一体化と適切な配分 スピード×アジリティ×スケール 新しいテクノロジーをいち早く活用 コスト×自動×安定 ヒト・モノ・カネの投資削減
- 116. クラウドを利用する目的 投資コスト（CapEX）の削減 運用コスト（OpEX）の削減 ベストミックスの実現 コスト削減から競争力の強化へ 保有（資産化）から利用（サービス化） 変更に伴うリスク回避 利用サービスの選別 自動化の促進 標準化・共通化（プラットフォーム化） ハイブリットクラウド マルチクラウド サービス間の連携 守りのITから攻めのITへ テクノロジーを活かした事業の差別化 自社で所有することの限界 ガバナンスとセキュリティ 災害対応（Disaster Recovery） グローバル展開 利用状況の徹底した見える化 少ない投資コストでの災害対応 フラットなグローバルサービス
- 117. クラウドのメリットを経営層にどう伝えるか 117 自社で所有することの限界 ガバナンスとセキュリティ 災害対応（Disaster Recovery） グローバル展開 利用状況の徹底した見える化 システム利用の状況やリスクを把握しやすい 必要な対策を事実に基づいて行える 高度なセキュリティ認証に対応している（高度なスキル・高額なコスト） 少ない投資コストでの災害対応 高度な災害対応を施した施設にて運用 複数の独立したアベイラビリティゾーン 国内外の分散レプリケーション可能、しかもアップロードコストは不要 フラットなグローバルサービス 世界中にデータセンター 世界中で同一のアーキテクチャ マルチクラウド化によりさらなるリスク分散
- 118. クラウドのメリットを経営層にどう伝えるか 118 投資コスト（CapEX）の削減 保有（資産化）から利用（サービス化） 初期投資が抑制される 資産を経費化できる 変更に伴うリスク回避 使用量に応じた従量課金 アプリケーション機能の変更や負荷の変動に柔軟に追従できる
- 119. クラウドのメリットを経営層にどう伝えるか 119 運用コスト（OpEX）の削減 利用サービスの選別 低コストのデータセンターで運用されるためコスト削減が行いやすい 最適なサービスを選択し組み合わせることができる 目的や予算などの条件 利用スキルの習熟度 サービス・レベル 自動化の促進 広範な自動化ツールを利用できる 運用監視 構成管理 変更管理など 標準化・共通化（プラットフォーム化） 運用管理や開発・実行環境の運用コストが削減できる システムの調達・構築や変更のコストが削減できる PaaSを活用することで開発や保守のコストが削減できる
- 120. クラウドのメリットを経営層にどう伝えるか 120 ベストミックスの実現 ハイブリットクラウド プライベートクラウド コンプライアンス レイテンシー 運用管理の自由度など パブリッククラウド コスト サービス機能 グローバル対応 など マルチクラウド サービス機能やコストなどの特性に応じた使い分け サービス間の連携 EBS（Enterprise Service Bus）による疎結合 セルフサービスポータルや統合管理ツール（オーケストレーター）
- 121. クラウドのメリットを経営層にどう伝えるか 121 コスト削減から競争力の強化へ 守りのITから攻めのITへ 最新のテクノロジーを活かした事業の差別化ができる グローバル展開が容易に、迅速にできる 構築や保守のスピードが早く、ビジネス環境の変化に即応できる テクノロジーを活かした事業の差別化 新しいサービスモデルを構築できる 最新のテクノロジーがクラウドから提供される
- 122. 予算はどう変わるのか 122 データセンター or 自社のサーバールーム 「資産」から「経費」への転換 プログラム・ライセンス（経費） プログラム・サポート（経費） 運用管理/派遣（経費） システム開発（資産） ハードウェア資産（資産） サブスクリプション（経費） システム開発（資産） マネージド・サービス（経費） 経費は工夫と改善で 継続的に削減可能
- 123. クラウド時代の情報システム人材の活かし方 123 戦略・企画 業務分析 システム設計 アプリケーション開発 インフラ プラットフォーム構築 保守 運用管理 ヘルプデスク 現場サポート 戦略・企画 業務分析 システム設計 アプリケーション開発 「攻めのIT活用」拡大 インフラ・プラットフォーム構築 保守 運用管理 ヘルプデスク 現場サポート 情報システム部門の機能と役割を再定義 経営企画や業務戦略スタッフとの人材交流 業務部門との人材交流 アジャイル開発 高速開発ツールやPaaSの活用 SaaSの活用 シチズン・デベロッパーの育成 ホステッド・プライベートクラウド 自動化 DevOps 高速開発ツールやPaaSの活用 SaaSの活用 システム・アーキテクト ビジネス・アーキテクト ビジネス価値を明らかにし、最適なビジネス・プロセ ス描き、それを実現するシステムをデザインする。 テクノロジーやサービスに精通し、それらを目利きで き、最適なシステムをデザインする。
- 124. 運用技術者からSREへ 124 ITの実務上の利用方法について問い合わせを受けて対応する 窓口業務 定められたオペレーションを繰り返し実施する定常業務 ITに関するトラブルに対応する障害対応業務 インフラ（ネットワークやOS・ハードなどの基盤部分）に関 する管理業務（構成管理やキャパシティ管理など） 積極的にソフトウェアで 置き換えていく クラウド・サービス 自動化ツール ビジネスもアプリも要件がどんどん 変わっていくので、継続的に改善、 手作業をソフトウェアに置き換えて いく必要がある 変更への即応性や信頼性の高いシステム基盤を設計 運用管理の自動化/自律化の仕組みを設計・構築 開発者が利用しやすい標準化されたポリシーやルールの整備 運用技術者 Operator / Operation Engineer SRE Site Reliability Engineer 組織横断的なインフラ整備 作業者から ソフトウェアエンジニア への変身！ http://japan.zdnet.com/article/35090649/ http://torumakabe.github.io/post/bookreview_site_reliability_engineering/ 参考になる記事：
- 127. クラウド・コンピューティング登場と発展の歴史 127 インターネット・クラウドの登場 エンタープライズ・クラウドへの派生 エンタープライズ・クラウドの自立 Webスケールの多数の一般ユーザーを対象として、 彼らにインターネットを通じて 大規模なサーバーおよびデータセンター・サービスを提供 コモディティ化したマシンを多数並べて並列動作させるという画期的なScale-outアーキテクチャ GFS、MapReduce、BigTableというGoogleの大規模分散技術 エンタープライズ（企業ユーザー）を対象とする 大規模なサーバーおよびデータセンター・サービスの提供 ECサイト運営の経験から膨大なリソースを合理的に管理する方法を編み出す。 開発者が調達・運用管理・保守などから開放し、本来集中すべき仕事に集中させる仕組みを構築。 エンタープライズ（企業ユーザー）を対象とし クラウドとオンプレミスとの境界を取り払った シームレスなリソース・プールを実現 Windows Azure Platform と Windows Serverの互換性 両者を統一的に管理する「クラウドOS」の登場 http://thinkit.co.jp/article/1024/1 「クラウド創世記（丸山不二夫著）」を参考に作成 2004〜 2006〜 2008〜 ユ ー ザ ー 範 囲 年代 クラウド・コンピューティング ＝Webスケールに対応できるサービス
- 130. クラウドによるコスト改善例
- 132. 132 店舗入力 ダウンロード イベント ログイン画面 店頭用入力画面 集計ファイル作成画面 ダッシュボード画面 イベント用入力画面 Write Write Read Read 認証されたユーザのみ アクセス可能なページ 評価対象としたアプリケーション／処理フロー よ く あ り が ち な webシステム
- 133. クラウド・サービスの「作り方」による費用の違い サーバー（物理マシン）×9台 ＋データベース等のライセンス ＋インフラ、DBなどの環境構築 ＋運用管理業務 ＋設置場所（場所+電源+空調等） 購入費用 ：数千万円 年間保守料 ：数百万円 年間運用量 ：数百万円 年間使用料 ： ー ハードウェアを所有 クラウド・サービスを使用 サーバー（仮想マシン）×9台 ＋データベース等のライセンス ＋インフラ、DBなどの環境構築 ＋運用管理業務 × 設置場所（場所+電源+空調等） 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：254,980円 ハードウェアを所有する場合と変 わらないシステム構成と運用方法 実行環境を移行しただけ システムの構成や運用方法などの設計・方式は同じ まったく異なる設計・方式 アンケート入力・集計・レポートのサービスとして、できることは同じ サーバー（仮想マシン）×4台 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：198,691円 × データベース等のライセンス △インフラ、DBなどの環境構築 △ 運用管理業務 × 設置場所（場所+電源+空調等） 無償のDNSや監視、低料金のデー タベースなどのサービスを利用 一部をクラウドのサービスに代替 サーバーの構築・運用は不要 購入費用 ： ー 年間保守料 ： ー 年間運用量 ： ー 年間使用料 ：907円 × データベース等のライセンス × インフラ、DBなどの環境構築 × 運用管理業務 × 設置場所（場所+電源+空調等） サーバーレス方式と言われるまっ たく異なる実行方式を採用 クラウド・ネイティブで再構築 ハードウェアを所有し、設置場所 とその運営も自社責任
- 134. 構築事例：従来型のWebアプリケーション・アーキテクチャ 134 EC2 Internet クライアント Elastic Load Balancing EC2 冗長化 EC2 EC2 EC2 EC2 EC2 冗長化 冗長化EC2 EC2 Web AP DB死活監視 DNS DNSのセットアップが必要 APはそのまま移行。ただし、セッション管理等、一部改修が 必要な場合がある。 ミドルウェアが必要 （Oracle、 SQLServer、死活監視ソフト等の購入） DBMSのセットアップが必要 EC2：1台 365日24時間稼働：$175.2 EC2：9台 365日24時間稼働：$1576.8 ELB：1台 365日24時間稼働：$236.52+α ELB：2台 365日24時間稼働：$473.04+α リージョン:東京 ＜EC2＞ インスタンスタイプ：t2.micro （最少） 料金：$0.020/1時間 ＜ELB＞ 料金：$0.027/1時間 +$0.008/1GB 年間：約$2049.84 約254,980円 ※2015/3/20時点
- 135. 構築事例：AWSサービスを活かしたアーキテクチャ 135 EC2 Internet クライアント Elastic Load Balancing EC2 冗長化 EC2 EC2 冗長化 Web AP DB DNS Route 53に 設定するのみ 死活監視のソフトウェア不要 基本的に無料／アラーム設定でメール通知 ＤＢＭＳはインストール不要 Ｏｒａｃｌｅ、ＳＱＬＳｅｒｖｅｒ等のライセンス料込 ＥＣ２の接続先を変更するだけ 冗長構成はＭｕｌｔｉ-ＡＺを選択するのみ EC2：4台 365日24時間稼働：$700.8 ELB：2台 365日24時間稼働：$473.04+α RDS： 365日24時間稼働：$455.52 Route53： 1年間：$26.4（最少） リージョン:東京 ＜EC2＞ インスタンスタイプ：t2.micro （最少） 料金：$0.020/1時間 ＜ELB＞ 料金：$0.027/1時間 +$0.008/1GB ＜RDS＞ インスタンスタイプ： t2.micro （最少） 年間：約$1655.76 約198,691円 Cloud Watch Route 53 RDS(Master) RDS(Slave) DynamoDB セッション 管理 ※2015/3/20時点
- 136. 構築事例：AWSサービスを最大限活かしたアーキテクチャ 136 Internet クライアント Cloud Front 画面表示は、 クライアント側 アプリ メールサーバー不要 冗長構成、拡張・データ再配置 はAWS任せ リージョン:東京 ＜S3＞ 料金：$0.0330/GB +リクエスト数+データ転 送量 ＜CloudFront＞ 料金：$7.2/年 （試算した結果） <Lambda> 料金：$0 ＜DynamoDB＞ 料金：$0 （試算した結果） 年間：約$7.56 約907円 Cloud Watch JavaScript 入力ページ（HTML） コンテンツ 非公開コンテンツ Log等 S3 DynamoDB Lambda Node.js テーブル Cognito Webサーバー機能 3箇所以上で自動複製、容量無制限 キャッシュ SSL証明書 任意のタイミングで処理実行 負荷分散、障害対策はAWS任せ AWS認証 アプリ認証 SignedURL発行 サーバ側アプリ ※2015/3/20時点 ※条件によって料金は異なります
- 137. 「クラウド･ネイティブ」とは 137 開発者は他社と差別化できるビジネスロジックに集中したいのに 付加価値を生み出さない作業で負担を強いられる ミドルウェアの設定 インフラの構築 セキュリティ・パッチの適用 キャパシティ・プランニング モニタリング システムの冗長化 アプリケーションの認証・認可 APIスロットリング など この負担から開発者を解放 DevOps マイクロ・サービス アーキテクチャ コンテナ サーバーレス／FaaS(Function as a Service) アプリケーションを継続的・高速にアップデートし ビジネス・ニーズに即座に対応