More Related Content
![【図解】コレ１枚でわかる最新ITトレンド [増強改訂版]](https://cdn.slidesharecdn.com/ss_thumbnails/170403ittrend2-170413083829-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to LiBRA 06.2021 /インフラとプラットフォーム
LiBRA 06.2021 /インフラとプラットフォーム
- 1.
- 2.
- 3.
- 4. クライアント (=PC) の誕生 メインフレームクライアントサーバー 巨大な計算機に全てのリソースを持たせ、 全ての処理を実行する。 クライアントは文字の入力と結果の表示 をするだけのダム・ターミナル。 一定の計算能力と記憶能力を持った高 機能なクライアント (PC) が中規模の サーバーと処理を分担し、高度なUIと操 作性を実現。 クライアント≒Windows PC
- 5. 新しいクライアントの出現 メインフレーム クライアントサーバー クラウドIoT PC Smart Phone IoT Internet 1980 2000 2020 少 ----------- クライアント数 ---------- 多 ビジネスユーザー モノ コンシューマ
- 6.
- 7. パソコン 使うときに電源を入れる スマートフォンとタブレット 常に電源が入っている 移動できない 移動できる 使うときにネットワークに繋ぐ 常にネットワークに繋がっている 使うにはある程度の知識が必要直感的に操作できる クラウドは必須では無い クラウドとの連携が前提 スマートフォンとタブレット
- 8. メインフレーム、クライアントサーバー、クラウド メインフレーム クライアントサーバー クラウド 巨大なサーバーに計算機能・記憶 能力の全てのリソースを持たせ、 プログラムを実行する。 クライアントは文字の入力と結果の 表示のみのダム・ターミナル。 ある程度の計算機能と記憶能力を 持った高機能なクライアント (≒WindowsPC) がサーバーと処 理を分担し、高度なUIと操作性を 実現。 サーバー側のプログラムをWeb標 準技術をベースに構築 (Webアプリ /Webサービス) し、クライアントの Webブラウザからアクセスして様々 な機能をサービスとして利用。 一社独占技術 独占技術＋標準技術 標準技術のみ ダム・ターミナル WindowsPC Webブラウザ
- 9. クライアントに与えた影響 クラウドの技術的特徴 クラウドの技術的特徴とクライアント サービス化 脱プロプライエタリ 標準化・オープン化 機能をWebサービスとして提供 特定の企業に依存しない 技術の採用 標準化による相互接続性/ 運用性の確保 大半の処理をサーバー (クラウド)側で処理 汎用クライアント(ブラウザー) の利用 オープン化の徹底による 独自技術の排除 柔軟性・スケーラビリティ の向上 使用技術は全て インターネット標準 様々なネットワークを介して クライアントと接続 PC スマホ・タブレット 1999年～ 2007年～ クライアントサーバーから クラウドへ移行 最初からクラウド対応 Windows + ブラウザー フル機能ブラウザー
- 10. ガラケーとiPhone ガラケー iPhone 1999～ 2007～ 日本固有の仕様全世界共通仕様 サービスとUIの一体開発/徹底したUX キャリアが開発を主導 Appleが開発 2007年当時最も進んだ エコシステムを実現 最初は「失敗する」と 言われた 高機能な携帯電話 PCの小型化 機能制限付きブラウザ (CHTML/JavaScript) PCと同等の フル機能ブラウザー
- 11.
- 12.
- 13. クラウド GPS（Global Positioning System） 位置情報 位置情報を使った新たなサービス 地図/ナビ タクシー配車 鉄道・バスの運行情報 SNS投稿への 位置情報付加 天気予報Pockemon GO 渋滞情報 乗換案内 防災情報 行動履歴
- 14.
- 15. ブラウザ センサー情報 UGC/UGM ユーザーからの簡便な情報発信 ≑情報収集 SNS ブログ 位置情報 画像/動画 生体情報 趣味・嗜好 思想・信条 関心事 行動 パターン 信仰・宗教 健康状態 旅行予定 移動経路 行動範囲 検索 閲覧履歴 いつでも どこからでも 即座に
- 16.
- 17.
- 18.
- 19.
- 20.
- 21.
- 22. ユビキタスからアンビエントへ ユビキタス アンビエント ケータイ スマホ テレビスマホ/音声認識デバイス M2M IoT 様々なモノがシステムに接続 され、人間からそれらに働き かけ、情報を得る システムが人間を見えない 形で取り巻き、必要に応じて 情報を提供 2G/電灯線ネットワーク 4G/5G/WiFi/光 クラウド無し クラウド前提 電話 ゲートウェイ 機械間通信 特徴 ネットワーク クラウド
- 23. 接続 デバイス ノートパソコン PDA 電子手帳 第1世代 スマートフォン 入力 パソコンとの連携 メール・Web 有線 通信カード（低速） 有線 通信カード（低速） 携帯電話回線 （低速） キーボード 手書き文字認識 キーボード キーボード テンキー 可能 スケジュールなど不可 可能 限定的 非常に限定的 携帯性 △ ○ ◎ モバイル・デバイスの歴史
- 24.
- 25.
- 26.
- 27. PC/AT Mac Windows LinuxMacOS クライアント毎に専用のプログラム (ネイティブアプリ) を用意する必要があり、開発効率が良くない クライアント・プラットフォームの変遷 PC/AT Mac Windows Linux MacOS RIA/Ajax ひとつのプログラムコードで全てのプラットフォームに対応、コストを最少化して売上を最大化できる
- 28.
- 29. Ajax (エイジャックス) とは 非同期の JavaScript サーバーからダウンロードされ ブラウザ上で実行される スクリプト言語 eXtensibleMarkup Language ユーザー独自の拡張が可能なマー クアップ言語 Asynchronous JavaScript + XML = Ajax Flashなどのプラグインを使わず、 Web ブラウザ単独で、PCにインストールされた アプリケーション並みの操作性を実現
- 30.
- 31.
- 32. Ajax の意義 標準のWeb ブラウザで 独立アプリ並みの操作 性を実現できる クライアントアプリやプラグイン無し で高度な対話型の システムを構築可能 クラウドコンピューティング Webシステム/Webアプリ/WebサービスのUI を劇的に改善 クラウドのクライアントとしての Web ブラウザーの重要性が増大
- 33. Mozilla Firefox Apple Safari GoogleChrome Opera Software OPERA Microsoft Internet Explorer JavaScript実行速度の向上 Ajaxの操作性と快適さを向上 ブラウザーの進化とAjax
- 34.
- 35. Google が狙うもの 「新しいコンピューティング・サービスは、どこかの雲の中 にあるサーバーから始まる。ＰＣ、Ｍａｃ、携帯電話など、 どのようなデバイスからでも適切なアクセス手段があれ ば利用できる。」 Google CEOエリック・シュミット 2006年8月のスピーチ 適切なアクセス手段 Web ブラウザー 2008年、Google Chrome を発表 2009年、Chrome OSを発表 マルチプラットフォーム対応 最速の JavaScript 実行速度 クライアントを標準化し インターネットの利用を加速させる 無 料 広告収入
- 36.
- 37.
- 38.
- 39.
- 40. HTMLの歴史と現状 HTML 1.0 (1993年) HTML2.0 (1995年) HTML 3.2 (1997年) HTML 4.0 (1997年) HTML 4.01 (1999年) HTML 5 (2014年) HTML は元々インターネット上の情報をレイアウトして見やすい ようにするために考案されたもので、静的なコンテンツを前提に している。 HTML は1999年の4.01以降アップデートされておらず、マルチ メディアやWebアプリケーションへの対応が難しい状態が続いて きた。 このためプラグインを使ってブラウザの機能を拡張する方法がと られ、Flashなどが普及した。 MicrosoftはIE5/6でHTMLに独自の拡張を行い、ブラウザの機能 を拡張したが、インターネットコミュニティからは反発を受けた。 15年ぶりの新バージョン 民間ベンダーが共同でHTMLの拡張を行い、 W3CにHTML5とし て採用するよう働きかけた。
- 41. HTML5 (+Ajax)でできるようになること ブラウザ間の互換性・相互運用性の確保 Webアプリケーションの開発を容易にするための新機能や 新しい要素を追加 (クラウド対応) フォームの拡張ドラッグ＆ドロップ クライアントサイドストレージ オフラインキャッシュ （オフラインWebアプリケーション） ベクターグラフィックス 3次元グラフィックス オーディオ・ビデオ 位置情報 これまでプラグインなどを必要としていた処理が HTML5+Ajaxで実現できる
- 42.
- 43. Microsoft Edge 43 Internet ExplorerMicrosoft Edge MSHTML HTML5 ActiveX/VBscript 高速化 独自仕様からWeb標準へ
- 44.
- 45.
- 46.
- 47.
- 48. 仮想 virtual 表面または名目上はそうでないが 実質的には本物と同じ 本来の意味 「仮想化」の本当の意味 本来の意味 仮想化 Virtualization 実質的には本物と同じ ことをできるようにする仕組み 日本語での語感 虚像の〜 実態のない〜 It was avirtual promise. （約束ではないが）実際には約束も同然だった。 He was the virtual leader of the movement. 彼はその運動の事実上の指導者だった。
- 49.
- 50. 物理資源・物理機械 サーバーの仮想化 ストレージの仮想化 Java仮想マシン データベースの仮想化 パーティショニング 分 割 アグリゲーション 集約 エミュレーション 模 倣 仮想化 (Virtualization) ひとつの物理資源を 複数の仮想資源に分割 複数の物理資源を ひとつの仮想資源に分割 ある物理資源を 異なる資源に見せかける 仮想化の3つのタイプ
- 51. ソフトウェア化とはどういうことか（１） 掃除 機能 掃除 機械 レンジ 機能 レンジ 機械 テレビ 機能 テレビ 機械 作表 機能 文書作成 機能 会計管理 機能 汎用機械 オペレーティング・システム（OS） 家電製品 コンピュータ 専用一体 専用一体専用一体 ソフトウェア Software ハードウェア Hardware
- 52.
- 53.
- 54. 仮想化 や ソフトウエア化のための仕組み 使いたい機能や性能の組合せや変更の自由を実現 ソフトウェア化された情報システムの機能や性能を使うサービス 簡単・便利・いつでも／どこでもITの機能や性能をサービスとして使える仕組み 実質的に使える機能や性能 ネットワーク 専門的な スキルや ノウハウ 大規模・集中化・一元化・標準化 自動化などを駆使して、魅力的な コストパフォーマンスを実現する 物理的なハードウェアや設備 インフラストラクチャー プラットフォーム アプリケーション 運用管理者 特定の業務処理 を行うためのソフトウェア アプリケーションで共通に使う機能 を提供するソフトウエア オペレーティングシステム データベース管理システム など 販売管理システム 会計管理システム など ソフトウエアを動かすための ハードウェアや設備
- 55.
- 56.
- 57.
- 58. 仮想化の役割 58 必要とされるシステム（機能）構成A 必要とされるシステム（機能）構成B 必要とされるシステム（機能）構成C 分割集約 模倣 仮想化 実質的機能 使用目的に応じて必 要とされるシステム を調達・構成する。 物理的な設置・据え付 け作業を必要とせず、 ソフトウエアの設定だ けで、必要とするシス テム構成を調達･変更で きる。 柔軟性とスピード 演算 データ管理 ネットワーキング サーバー ストレージ システム資源 ネットワーク機器 物理的実態 ハードウェア プラットフォーム 設備 標準化されたハード ウェアやソフトウエア を大量に調達してシス テムを構成し、運用を 自動化・一元化する。 コスト･パフォーマンス 物理時実態から 実質的な機能や 性能を取り出す
- 59. 仮想化の役割 59 必要とされるシステム（機能）構成A 必要とされるシステム（機能）構成B 必要とされるシステム（機能）構成C 仮想化 物理時実態から 実質的な機能や 性能を取り出す 実質的機能 使用目的に応じて必 要とされるシステム を調達・構成する。 物理的な設置・据え付 け作業を必要とせず、 ソフトウエアの設定だ けで、必要とするシス テム構成を調達･変更で きる。 柔軟性とスピード サーバーストレージ システム資源 ネットワーク機器 物理的実態 ハードウェア プラットフォーム 設備 標準化されたハード ウェアやソフトウエア を大量に調達してシス テムを構成し、運用を 自動化・一元化する。 コスト･パフォーマンス 物理的実態の持つ機能や性能を抽象化*し それらの組合せや変更などの操作を物理的実態から分離して 操作の自由度を高め柔軟性とスピードを向上させる ＊「抽象化」とは、対象か ら本質的に重要な要素だけ を抜き出して、他は無視す ること。
- 60.
- 61. タイムシェア（Time Share） モニター（Monitor） “見かけ上” 同時使用できる コンピューター（物理資源） 個別の資源 個別の資源個別の資源 個別のOS 個別のOS 個別のOS “見かけ上” 別々の資源として 使用できる 仮想化の誕生(2) コンピューターを共同利用する技術 仮想化ソフトウェア ハイパーバイザ (hypervisor)
- 62. システム利用形態の歴史的変遷 OS OS AP AP AP APAP AP 3 2 1 1950年代～／バッチ 1960年代～／タイムシェアリング メインフレーム メインフレーム ミニコン OS AP AP AP OS OS VM VM VM 1970年代～／仮想化（仮想マシン） メインフレーム ミニコン OS AP AP AP OS OS 1980年代～／分散化 ミニコン PCサーバー OS AP AP AP OS OS VM VM VM 2000年代～／仮想化（仮想マシン） PCサーバー クラウド (IaaS) OS AP 設定 AP 設定 AP 設定 コンテナ コンテナ コンテナ 2015～／コンテナ PCサーバー クラウド (PaaS) メインフレームの時代 オープン・システムの時代 クラウドの時代
- 63.
- 64. SDI（Software-Defined Infrastructure） 64 ビジネス・スピードの加速 アプリケーション開発・変更への迅速な対応 eXtreme Programing,Scrum,TestDriven Development など 本番環境への迅速な移行・継続的デリバリー Chef,Jenkis,Hashicorp など インフラ環境の迅速な調達・構築・変更 OpenStack,vCloud Air,Azure Stack など アジャイル開発 Agile Development DevOps Development/Operation SDI Software Defined Infrastructure
- 65. SDI（Software-Defined Infrastructure） 65 WAN高速化装置 ファイヤウォール スイッチロードバランサ ルーター SDI（Software Defined Infrastructure） 仮想化 物理的なシステム資源 システム構成や構築には設置や接続などの物理的な作業が必要 ソフトウェアによる操作や設定でシステム構成や構築を実現する ソフトウェアによる操作や設定でシステム構成や構築を実現する 物理的な構成や機能を理解し、そこから「仮想的=実質的」にシス テムを構成して必要な性能や機能を調達する。 物理的な構成や機能を理解していなくても、「ポリシー=目標値・ 制約事項」を設定すれば必要な性能や機能を調達する。 物理的システムイメージ 利用目的・利用イメージ
- 66. SDI（Software-Defined Infrastructure） 66 WAN高速化装置 ファイヤウォール スイッチロードバランサ ルーター 組織・企業 組織・企業 組織・企業 ポリシーで機能や性能を管理 処理能力、対障害性能、セキュリティなど SDI（Software Defined Infrastructure） 「抽象化」とは、思考に おける手法のひとつで、 対象から注目すべき要素 を重点的に抜き出して他 は無視する方法である。 仮想化されたシステム資源 物理的なシステム資源 システム資源 機能や性能 抽象化 抽象化 仮装化されたシステム資源で構 成や運用を管理 物理的なシステム資源で構成や 運用を管理
- 67. 物理的なシステム資源を個別に構築 SDI（Software-Defined Infrastructure）/物理システム 67 組織・企業 組織・企業組織・企業 組織・企業 ユーザーの要望に応じて物理資源を個別に調達・構成 運用管理者が個別にシステム資源を構成・調達
- 68. DMZ FW スイッチ 負荷分散装置ルーター ネットワーク仮想化 サーバー仮想化 ストレージ仮想化 SDI（Software-Defined Infrastructure）/仮想システム 68 組織・企業 組織・企業 組織・企業 組織・企業 仮想化されたシステム資源から、ユーザーの要望に応じて運用管理者が個別に構成・調達 運用管理者が個別にシステム資源を構成・調達 物理的なシステム資源をプール（リソース・プール）
- 69. SDI（Software-Defined Infrastructure） 69 DMZ FW スイッチ負荷分散装置 ルーター 物理的なシステム資源をプール（リソース・プール） 組織・企業 組織・企業 組織・企業 組織・企業 仮想化されたシステム資源から、ユーザーの要望に応じて自動で構成・調達 ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ SDIを構築し運用するソフトウエア プロビジョニング Provisioning ネットワーク仮想化 サーバー仮想化 ストレージ仮想化
- 70. 仮想化されたシステムの構成 70 物理システム 製品ベースでの調達・運用 物理性能・物理構成・物理作業 仮想システム 実質ベースでの調達・運用 実質性能・実質構成・ソフトウェア設定 サーバー ストレージ ネットワーク メモリ容量 CPU性能 ディスク容量 ネットワーク機能 ネットワーク接続 仮想サーバー 仮想ストレージ 仮想ネットワーク オーケストレーション ポリシーベースでの調達・運用 規則・条件・基準による設定 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 01 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 02 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 03 コントロール パターンやルール・ベースでの運用管理・調達管理 構成管理・稼働管理・問題解決 監視 自動/自律制御 制 御
- 71. 運 用 の 自 動 化 仮想マシン、ミド ルウェア、アプリ ケーションの稼働 状況を監視し、運 用パターンに沿っ て設定を調整する 監 視 監 視 コントローラー セルフ･サービス ポータル 仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者 運用パターン 調 達 の 自 動 化 APIを介し、コン トローラーやセル フポータルの操作 に従って、プロビ ジョニングを行う ハード・ソフト構成の管理 システムの稼働監視 アラートから異常の兆候を検知 異常の原因を解析 解決策の選定 解決策適用による影響範囲を確認 設定の変更やリソースの追加で対応 運用 パターン SDI（Software-Defined Infrastructure）/全体の仕組み プロビジョニング 仮想化ソフト 仮想化ソフト 仮想化ソフト 仮 想 化 物理リソースを管 理し、ソフトウェ アによる定義に 従って仮想リソー スを提供する リソース プール オーケストレーター 操作 操作 操作 API
- 72. 監 視 監 視 コントローラー セルフ･サービス ポータル 仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者 運用パターン プロビジョニング 仮想化ソフト 仮想化ソフト仮想化ソフト リソース プール オーケストレーター 操作 操作 操作 API 運 用 の 自 動 化 調 達 の 自 動 化 SDI（Software-Defined Infrastructure）/SDIとIaaS 仮 想 化 IaaS PaaS
- 73.
- 74. Infrastructure as Code 仮想サーバー 物理サーバー 仮想ストレージ 物理ストレージ 仮想ネットワーク 物理ネットワーク 使用するシステム構成リソース・プール（物理リソース） プログラムによる定義 Infrastructure as Code 全てのシステム構成をソフトウェアで定義できる インフラの構築や運用管理での属人化による「暗黙知」をなくし ノウハウの蓄積や自動化を容易にする
- 75. Infrastructure as Code 業務処理ロジックの プログラミング 日本語などの自然言語で 運用手順書の作成 人手による 運用管理 日本語などの自然言語で システム構成図作成 人手による システム構築 従来の手順 属人化による「暗黙知」化 人手の介在によるミスやスピードの制約 業務処理ロジックの プログラミング 運用手順の プログラミング システム構成の プログラミング 運用管理の 自動化 システム構成 の自動化 これからの手順 全手順のコード化によるノウハウの継承 開発～本番の高速化と変更の俊敏性
- 76. Infrastructure as Code 開発・運用・構築の関係や役割が大きく変わる Infrastructureas Code 人間が作業に関与することに比べ 運用・構築の高速化 + ヒューマン・エラーの排除 + 人的作業負担の消滅 稼働中のサーバー停止や新規サーバー稼働 を同時に行う事ができる 開発・テストと本番で全く同じ環境が使える 稼働中のサービスを停止することなく 設定や構成の変更ができる 開発・テスト環境から本番環境へ 自動的に移行できる Immutable Infrastructure、DevOps、Agile Development…
- 77. Infrastructure as Codeの特徴（１） 77 環境構築手順書 ①AをBする。 ② CをDにする。 ③ FをGにする。 ・・・ +#!/bin/sh+yum install -y httpd httpd- devel php php- mbstring php-pdo php-mysql mysql- インフラ設定 インフラ構築手順作成 環境構築手順書 1 ① AをBする。 ② CをDにする。 ③ FをZにする。 ・・・ 環境構築手順書 2 ① AをBXする。 ② CをDYにする。 ③ FをZにする。 ・・・ 環境構築手順書 3 ① AをBXする。 ② CをDYにする。 ③ FをGZにする。 ・・・ +#!/bin/sh+yum install -y httpd httpd- devel php php- mbstring php-pdo php-mysql mysql- 手作業で作業ミスが心配 変更を繰り返すと管理が大変 実際の環境と履歴が一致しない 対象が増えると管理しきれない 設定に手間がかかる テスト・確認が複雑
- 78. Infrastructure as Codeの特徴（２） 78 変更履歴 ①XXXXXXXXX ② XXXXXXXXX ③ XXXXXXXXX ・・・ クラウド 個別システム × × システム資源が物理的に固定さ れるので、インフラ構築はその 制約の下で行われる。 物理サーバーを構成変更しなが ら使い続ける。 システム資源が仮想化されるの で、インフラ構築に物理的な制 約をうけることはない。 仮想サーバーの追加・破棄を頻 繁に繰り返すことができる。 変更履歴を管理 動作している状態を管理 構成は不変 Imutable Infrastructure 構成は変化し続ける
- 79. Infrastructure as Codeを実現するソフトウェア 79 仮想マシン仮想マシン 仮想マシン Orchestration: 複数サーバーの管理を自動化 Configuration: OSやミドルウェアの設定を自動化 Bootstrapping: OSの起動を自動化 OS OS OS Virturization: 仮想マシンの構築・起動 ミドルウェア アプリケーション OSや仮想化ソフトウェアのインストール／設定作業を自動化 データベースサーバ／Webサーバ／監視エージェントなどのミドル ウエアのインストールやバージョン管理、OSやミドルウエアの設定 ファイルや、OSのファイアウォール機能などの設定などを自動化 複数台のサーバ群を監視し、新しいサーバをシステムに登録したり、 障害のノードをシステムから取り除いたり、サーバへのアプリケー ションのデプロイをサポート KickStart
- 80.
- 81.
- 82.
- 83. サーバー仮想化とコンテナ OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア OS 仮想サーバー ミドルウェア サーバー仮想化 ハードウェア コンテナ管理ソフトウエア OS ミドルウェア アプリ ミドルウェア アプリ ミドルウェア アプリ コンテナ コンテナ コンテナ コンテナ ライブラリ 環境変数 ライブラリ 環境変数 カーネルカーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 隔離されたアプリケーション実行環境を提供（クラッシュの分離、独自のシステム管理とユーザー・グループ） 実行イメージのスナップショットをパッケージとしてファイルにして保存できる アプリケーションに加えて仮想マシン・OS の実行イメージを持つ必要がある アプリケーションとOSの一部 の実行イメージを持つ必要がある デプロイするサイズ 大きい 起動・停止時間 遅い デプロイするサイズ 小さい 起動・停止時間 早い 異なるOS 可 異なるOS 不可 メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い 構成の自由度が高い 異なるOS・マシン構成を必要とする場合など 軽量で可搬性が高い 実行環境への依存が少なく異なる実行環境で稼働させる場合など サンド・ボックス化 Sand Box アプリケーション アプリケーション アプリケーション
- 84. 仮想マシンとコンテナの稼働効率 ハードウェア 仮想マシン ミドルウェア OS 仮想マシン OS 仮想マシン OS ミドルウェア ミドルウェア ハードウェア OS コンテナ管理機能 カーネル ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ カーネル カーネルカーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 コンテナ 仮想マシン アプリケーション アプリケーション アプリケーション ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ
- 85.
- 86. コンテナ・オーケストレーションとは ハイパーバイザー 開発・実行環境 ミドルウェア オペレーティング システム サーバー （ハードウェア） 仮想マシン アプリケーション コンテナ管理システム コンテナ 物理マシン 仮想マシン コンテナコンテナ オーケストレーション 分散・大規模なシステム・リソースを使い ひとつのシステム（サービス）を実現する
- 87.
- 88. モビリティの高いコンテナ 88 デバイス エッジ サーバー オンプレミス サーバー クラウド ハードウェアやOSに依存することなくソフトウェア機能を配置・移動できる コンテナをRaspberry Piで動かすサービス Amazon ECS（ElasticContainer Service）互換を 実現するAmazon ECS Anywhereと、Amazon EKS （Elastic Kubernetes Service）互換を実現する Amazon EKS Anywhereをリリース（予定）
- 89. デスクトップ仮想化とアプリケーション仮想化 89 ネットワーク 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 メモリー ストレージ ハイパーバイザー PC用OS （Windows7など） プロセッサー 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 クライアントPC 文書作成 画面表示 仮想PC サーバー PC用OS （Windows7など） 文書 作成 表 計算 プレ ゼン ・・・ 仮想PC メモリー ストレージ OS プロセッサー サーバー ターミナル・モニター 文書 作成 表 計算 プレゼン・・・ 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 入出力操作 通信 クライアントPC 文書作成 画面表示 デスクトップ仮想化 アプリケーション仮想化
- 90. シンクライアント 90 ネットワーク 入出力操作 通信 シンクライアント 文書作成 表計算 プレゼン ・・・ 画面表示 メモリー ストレージ ハイパーバイザー PC用OS （Windows7など） プロセッサー PC用OS （Windows7など） PC用OS （Windows7など） 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 シンクライアント 文書作成表計算 プレゼン ・・・ 画面表示 仮想PC 仮想PC 仮想PC サーバー ストレージ 文書作成 表計算 プレゼン ・・・ 入出力操作 通信 アプリケーション PC / Windows・Mac OS など 画面表示 データとプログラムの保管 プログラムの実行 は、PC内にて処理 データとプログラムの保管 プログラムの実行 は、サーバー内にて処理 シンクライアントは 画面表示と入出力操作
- 91. Chromebook 91 インターネット データ 文書作成 表計算 プレゼン ・・・ブラウザ 画面表示・入出力操作 通信 画面表示・入出力操作 通信 オフィス・アプリ データ 文書作成 表計算 プレゼン ・・・ オフィス・アプリ クラウドサービス Google G Suite、Office365など ブラウザ 文書作成 表計算 プレゼン ・・・ PC / Windows・Mac OS など Chromebook / Chrome OS
- 92.
- 93. ストレージ仮想化 ストレージの業界団体であるSNIA（Storage Network IndustryAssociation） による 「ストレージ仮想化技術の分類」 Disk Virtualization （ディスクの仮想化） Block Virtualization （ブロックの仮想化） File System Virtualization （ファイル・システムの仮想化） File Virtualization （ファイルの仮想化） Tape Virtualization（テープの仮想化）
- 94. ストレージ仮想化 2TB 実データ 3TB 実データ 5TB 実データ 10TB 10TB 10TB 仮想ストレージ ブロック仮想化 10TB 実データ 30TB ストレージ（ハードウェア） 8TB7TB 5TB 未使用領域 20TB ボリュームの仮想化 10TB 10TB 10TB 仮想ストレージ シンプロビジョニング 10TB 実データ 30TB ストレージ（ハードウェア） 容量の仮想化 未使用領域 0TB 必要な時に 追加 2TB 実データ 3TB 実データ 5TB 実データ 8TB 7TB 5TB 仮想ストレージ 重複排除 ストレージ（ハードウェア） データ容量の削減 D A B C E F A B ファイル ２ ファイル１ D A B C E F 重複データ を排除
- 95.
- 96. SD-WAN（Software-Defined Wide AreaNetwork） 96 IP-VPN インターネットVPN (IPsec VPN) 4G LTE 専用回線 ソフトウェアによって統合・一括管理された仮想的なWAN 負荷分散、セキュリティ管理、アプリケーションによるネットワークの振り分けなど 一括管理 コントロール オーケストレーション SD-WANソリューション 拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末 GUI
- 97. ネットワークに求められる要件 97 定義項目 要件 オンデマンドセルフサービス オンデマンドかつセルフサービスで利用開始、条件変更、利用停止が可能。 多種多様な回線およびデバイスをサポート 種々のアクセス回線やネットワークサービス、種々のデバイス（IoT含 む）により利用可能。 リソースプール ネットワークがリソースプール化されている。世界中にPOP（接続拠点） や制御拠点を有し、可用性、利用帯域などのネットワーク特性がPOPの場 所に依存しない。 オートスケール 自動的にネットワーク帯域のスケールアウト／スケールインができる。 サービス利用状況の計測／レポート サービス利用状況（サービス品質保証、帯域、遅延値、利用率、セキュリ ティ状況など）を自動的に測定し、レポートで提供。 プログラム可能なインフラ 企業ネットワーク構築／運用／保守のためのAPIを提供し、外部システム からプログラム制御できる。 従量課金 リソース（サービス品質保証、ネットワーク帯域など）の利用量に応じた 課金。 ITR説明資料 http://techtarget.itmedia.co.jp/tt/news/1811/12/news05.html?fbclid=IwAR07tuvcHBxtl9eUw_6kw8g929l47Rm2rLF2LxPyFX_VV5M9VFaI2FPhx8I
- 98.
- 99. サーバー仮想化による３つのメリット 99 仮想マシン Virtual Machine 物理マシンの集約 機械購入費用の抑制 電気代・CO2の削減 データセンター使用料の削減 ソフトウェア定義 調達・変更の迅速化 稼働中での構成変更 迅速で柔軟な構成変更 設定 障害時に正常に稼働して物理マシンに 仮想マシンを移動させサービスを継続 複雑なクラスタリング構成と 対応のためのソフトウエア ライブマイグレーション 保守時のサービス停止回避 障害時のサービス停止回避 物理マシンの負荷の分散
- 100.
- 101. サーバー仮想化が変えたサーバー利用の常識（１） 101 OS 仮想サーバー A ミドルウェア アプリ OS 仮想サーバー B ミドルウェア アプリ OS 仮想サーバーC ミドルウェア アプリ CPU メモリ CPU メモリ CPU メモリ ハードウェア CPU メモリ ホスト名 A CPU XXX メモリ XXX IP XXX ホスト名 B CPU XXX メモリ XXX IP XXX ホスト名 C CPU XXX メモリ XXX IP XXX 設定ファイル ハイパーバイザー システム管理者は、「設定ファイル」 を作成・複製・変更することで、仮想 サーバーの調達や構成変更できる。 ハイパーバイザーは、「設定ファイ ル」に記述された内容に従って、必要 なシステム資源の割り当てを行う ハイパーバイザーから割り当てられ たシステム資源に相当する能力・機 能を持った仮想マシンが稼働する
- 102. サーバー仮想化が変えたサーバー利用の常識（２） 102 仮想サーバー A CPU メモリ 仮想サーバー B CPU メモリ 仮想サーバー X CPU メモリ 設定 ファイ ル A 設定 ファイ ル A 設定 ファイ ル X 相互に稼働しているかどうかを監視 共用ストレージ ハイパーバイザー サーバー 01 CPU メモリ サーバー 02 CPU メモリ ハイパーバイザー 仮想サーバー A CPU メモリ 仮想サーバー B CPU メモリ 仮想サーバー X CPU メモリ 設定 ファイ ル A 設定 ファイ ル A 設定 ファイ ル X 共用ストレージ ハイパーバイザー サーバー01 CPU メモリ サーバー 02 CPU メモリ ハイパーバイザー サーバー 01 障害時 正常時 仮想サーバーＡとBは、 見かけ上稼働し続けることができ ユーザーは影響を受けない
- 103. サーバーの仮想化 / BCP対策・仮想マシン・レプリケーション VMA VM B 物理 マシン 仮想化ソフトウェア データ AP AP 仮想マシン・イメージ のレプリケーション データの レプリケーション ネットワーク VM A VM B 物理 マシン 仮想化ソフトウェア データ AP AP クラウド基盤へのレプリケーション VM A VM B 物理 マシン 仮想化ソフトウェア データ AP AP 個別基盤へのレプリケーション
- 104.
- 105.
- 106.
- 107. サイバー・セキュリティ対策とは サイバー・セキュリティ：IT機器やソフトウェア、ネットワークなどのサイバー領域に おいて、下記の「情報セキュリティの3要件（CIA）」を確保すること。 機密性 (Confidentiality):情報へのアクセスを認められた者だけが、その情報にア クセスできる状態を確保すること 完全性 (Integrity): 情報が破壊、改ざん又は消去されていない状態を確保すること 可用性 (Availability): 情報へのアクセスを認められた者が、必要時に中断すること なく、情報及び関連資産にアクセスできる状態を確保すること インシデント発生の抑制 インシデント発生時の被害最小化 インシデント サイバー領域において、 企業や組織を脅かす行為 サイバー・セキュリティ対策 3要件（CIA）を確保する対策
- 108.
- 109.
- 110.
- 111. 攻撃サービスの低価格化と攻撃機会の増加 Ransomware: Zero-days: Breaching services on aper job basis: Exploit kits: Loads (compromised device): Spearphishing services: Compromised accounts: Denial of Service: Highest average price
- 112. リスク・マネージメントの考え方 112 事故の発生 事故の影響 受容 脅威ぜい弱性 機密性 完全性 可用性 対策 受容レベル 説明責任 コスト 影響 どこまでやればよいのかを？ 対策コスト負担 3要件への影響 業務の受容レベル 最適な組合せ 情報セキュリティの３項目 機密性：情報を盗まれない。 完全性：情報をデタラメな内容に書き換えられない。 可用性：システムを停止・破壊され業務継続を妨げられない。
- 113.
- 114.
- 115.
- 116.
- 117.
- 118. 共有パスワードを使った暗号化にトラストはない × Zipファイルを展開すると平文に戻ってしまう × 安全かどうかをソフトウエアで確認できない ×ファイルと鍵を転送されてしまう × ファイルは総当たり攻撃でいつか開かれてしまう × 仲介者による開封、改ざんに気がつくことができない × パスワードが漏れてしまったときにパスワードの変更ができない
- 119. ゼロ トラスト ネットワークとは何か トラストネットワーク ファイアウォールで守られたローカル・ネットワーク／VPN 信頼できなくなりました・・・ 理由その1：ファイアウォールはIPアドレスとポート番号でフィルタリングしている 理由その2：攻撃はウェブやメール経由で行われている 理由その3：VPN経由で内部に侵入することが難しくなくなってきた ゼロ
- 120.
- 121.
- 122.
- 123.
- 124.
- 125.
- 126.
- 127.
- 128. ゼロトラスト・アーキテクチャーの7原則 情報システムやサービスに於いて 正確なアクセス許可を行う際の不 確かさを低減・排除するために設 計された概念やアイデアの集合体 疑わしさを受け入れつつも できるだけ不確かさを排除 「ゼロ・トラスト」の考え方 リスクはゼロにはならない 1. 全データ・計算資源をリソースとして識別 2.ネットワークの場所に関係なく全ての通信の安全を確保 3. 個々のリソース・アクセスはセッション単位 4. リソースのアクセスは動的ポリシーにて決定 5. 全ての所有機器見・アプリの安全状態を常に監視・測定 6. アクセスを許可する前に動的・厳格に認証・認可 7. 機器・インフラ・通信状態の情報収集と安全面での改善 ゼロトラスト・アーキテクチャーの7原則
- 129. 認証基盤 129 識別 Identification 認証 Authentication 認可 Authorization 説明責任 Accountability R ------ W ------ X------ 識別：ユーザーを識別できるようにそれぞれに固有のユーザーアカウント（ID）を割り当てる。 例えば社員番号やメールアドレスなど。 認証：そのユーザーが本人であることを確認する。一般的な運用では、そのユーザーしか知りえ ないパスワードによる認証が中心。 認可：そのユーザーの属性に応じてアクセスできる範囲を確認する。たとえば、人事部のみアク セスできるファイルやフォルダーには人事部ユーザーだけがアクセスできるようにする。 認証基盤
- 130.
- 131. ユーザーに意識させない・負担をかけないセキュリティ Security Orchestration AutomationResponse SOAR セキュリティ製品間の連携 手動 → 自動 自動調査＆対処 自動化 いつでも／どこでも 安心・安全にITの利便性を享受 ユーザーに 意識させない・負担をかけない
- 132. サイバーセキュリティ対策の構造 132 情報保護：情報資産・システム資産を守る 安心・安全が保証された業務プロセスを作る・維持する 説明責任：あらゆる行動を説明する 個人のIDに紐付けられた全ての行動を記録する 認 可 認 証 識別 マルウェア・ウイルス 不正侵入 システム破壊 従業員に負担をかけず、安全・安心に業務ができる環境を提供する セキュリティに関わる事故や不正の責任から従業員を解放する 業績向上 効率よく効果的に 業務を遂行し 事業の成果に貢献する 的確な経営判断 経営状況が正確 かつタイムリーに 報告・見える化される 手段 手段 目的 脆 弱 性 対 策 認 証 管 理 対 策 事業継続：事業を止めない／被害を限定する
- 133. パスワード認証のリスク 133 ID／パスワードによる認証： 利用している本人が本人であることを証明するための仕組み ID/パスワードを搾取 ファイヤ ウォール 社内 ネットワーク VPN 1. 複雑なパスワードを使う 文字数を長くする。 文字の種類を増やす。英字（大文字、小文 字）、数字、特殊文字を組み合わせる。 2. 定期的に変更する 3カ月に一度変更する。 3. 一度使ったパスワードは使わない 過去3回までに使ったパスワードは使えない。 一度使ったパスワードは二度と使えない。 「複雑なパスワード」と「定期的なパスワード変更」は意味がない ID/パスワードが簡単にる 人間の記憶力に依存しまた再利用が可能なため 一人当たり平均27個のオンラインアカウントを保持 している それぞれのアカウントのパスワードを複雑化し、全 てのアカウントに紐づいているパスワードを違うも ので設定し、覚えておくということができない。 毎日アクセスするために、「覚えやすい簡単なパス ワードにする」「同じパスワードを使い回す」「メ モを書いておく」 ID/パスワード・VPN・ ファイヤウォールが役立たない
- 134. 本人認証の方法 知識認証 What you know? 所持認証 Whatyou have? 生体認証 What you are? ID/パスワード など ICカード ワンタイムパスワード用トークン 携帯電話（デバイス）認証 など 指紋認証 顔認証 静脈パターン認証 虹彩認証 声紋認証 網膜認証 など 認証方式 方法例 組合せの例 1234 暗証番号 銀行カード 静脈認証
- 135. クラウド・サービス シングル・サインオン（SSO）システム 1/2 ID PW ID PW ID PW ID PW ID PW ID PW ユーザーIDとパスワードが増加。利用ログはクラウド・サービスに依存し、管理者が掌握できない。 認証の強度がクラウド側に依存し、多要素認証などの導入に制限がある。 利用場所や端末を制限する機能もクラウド側に依存し、柔軟な制御が行えない。
- 136. シングル・サインオン（SSO）システム 2/2 クラウド・サービス SSO システム サインオン サインオン サインオン フェデレーション（認証連携） サインオンは1種類だけ。全ての利用サービスについてのログが収集・掌握できる。 SSOシステムへの認証を強化すればクラウドサービスの認証も強化でき、多要素認証などの導入も容易。 SSOシステムにアクセス可能な範囲がクラウドサービスが利用可能な範囲となり、場所や端末による制限が柔軟にできる。
- 137.
- 138. FIDO2とSSO 138 FIDO2認証デバイス 認証サーバー クラウド・サービス AzureADなど リスク軽減 パスワードの盗用という不正な手口が利用できなくなり、また生体情報などで本人確認の厳密化を行う ため、リスクが軽減する。 コスト削減 「パスワードを覚える」「パスワードを複雑化する」「パスワードを絶えず変更する」「パスワード忘 れによる新しいパスワードの設定」などが不要となる。パスワードレスになれば、人がかける時間を削 減、漏洩による損害がなくなる。 ユーザーエクスペリエンス向上 「普段利用している端末ブラウザーでパスワードを保存しているため、他のPC端末やスマートフォンか らサービスにアクセスしようと思ってもパスワードが思い出せない」「サービスごとに文字種別や桁数 の規則が違うため、何のサービスにどのパスワードを設定しているかすぐに忘れてしまう」「定期的な 変更で違うパスワードを設定したのはいいが、それを思い出せない」などがなくなり、利便性が向上し、 業務の生産性も向上する。
- 139. ゼロ・トラスト・ネットワーク 境界型セキュリティの限界 139 内部の脅威に対して弱い 外部サービスの活用が困難 生産性改善に制約 使用可能 サービス 少数限定 インターネット 直接アクセス は原則禁止 オフィス開発室 文書 管理 ソースコード 管理 インターネット 直接アクセス は禁止 出し入れ 台帳管理 使用可能 サービス 少数限定 インターネット 直接アクセス は原則禁止 ベンダー 専用端末 低スペック or VDI端末 専用端末 低スペック or VDI端末 物理的分離・隔離、人的負担を前提としたセキュリティ・モデル 特定ベンダーに限定
- 140. ゼロ・トラスト・ネットワーク セキュリティと生産性の両立 140 働く人の自由を担保 クラウド利用の制約を排除 セキュリティを担保しながら高い生産性を維持 オフィス自由な場所 ベンダー 自分の端末 高スペック 使いたい機種 全てを検査・人的負担なく動的認証・認可を前提としたセキュリティ・モデル 文書 管理 ソースコード 管理 自分の端末 高スペック 使いたい機種 多彩なクラウド・サービスを利用 内部の脅威に対応 働きやすいところで開発 多様なベンダーと連携 IDに紐付けされた全トラフィックを検査・動的に認証認可
- 141. Microsoft 365Security Centerでの対応 141 標的型メール受信 未知のマルウェア、フィッシング PC への 侵入行為 ID の窃取 侵入範囲の拡大 偵察 情報への 不正アクセス 被害発覚 PC への侵入検知・隔離 Microsoft Defender ATP 標的型メールの検出と排除 Office 365 ATP 自動的な分類・保護・追跡 Azure Information Protection メールからの保護 デバイスの保護 ID の保護 (オンプレミス) ID の保護 (クラウド) 機密情報の保護（監視） 機密情報の保護 なりすまし検知・防止 (クラウド) Azure Active Directory Premium なりすまし検知・防止 (オンプレミス) Azure ATP 未許可アプリ、不正な操作の監視 Cloud App Security セキュリティ統合監視：Microsoft 365 Security Center
- 142. Microsoftのセキュリティ・プラットフォーム Azure AD Azure Sentinel AzureSentinel : SIEM（Security Information and Event Management）。Office 365 ATP、Windows Defender ATP、Azure AD、Azure ATP、Microsoft Cloud App Security、Azure Security Centerなどの脅威検知エンジンで収集したログ、サードパーティのセキュリティソリューションのログ、Deviceログ、Emailロ グなどを1つに集め、ビルトインされた機械学習モデルやAIを使って脅威の検知を行う Azure ADなどの様々なログから、機械学習モデル やAIを使って脅威の検知を行う ID およびアクセス管理サービス。様々なリソースへのサイ ンインとアクセスを管理し、シングルサインオン環境を提供 Azure AD : ID およびアクセス管理サービスであり、リソースへのサインインとアクセスを支援。Microsoft Office 365、Azure portal、その他何千という SaaS アプ リケーションなど、外部リソース。企業ネットワークとイントラネット上のアプリや、自分の組織で開発したクラウド アプリなどの内部リソース。 AD（オンサイト） Microsoft Defender ATP （オンサイト） Microsoft Defender ATP （モバイル） インターネット クラウド・サービス Microsoft Defender ATP（Advanced Threat Protection） : 企業のネットワークによる高度な脅威の防止、検出、調査、および応答を支援するために設計された プラットフォーム。 フェデレーション（認証連携） 同期
- 143.
- 144.
- 145.
- 146.
- 147. 何を評価するのか 147 ルール通りに作業はできている。しかし・・・ このやり方でビジネス・スピードに追従できているか？ 生産性は向上しているのか？ だれかが「遅くまで仕事をする」ことで、効率の悪さが帳消しに なっていないか？ 締め切りを遅らせる「コミュニケーション」が多すぎないか？ 無駄な会議、無駄なメールのやり取りなど・・・ 確かに「作業」はしている。しかし・・・ 評価の「指標」が明確になっているか？ 「目的」は何か その目的を達成するための「目標」は明確か 「目標」達成にはどれだけのことをやらなければならないのか 誰がやればどれくらいで終わらせることができるか 全体の作業工数は明確になっているか 「目的」は達成されたか？
- 148.
- 149.
- 150.
- 151. セキュリティ対策は何を評価するのか 151 セキュリティの評価 ① 安全か ② 安心か ③効率や利便性は高まったか ④ ビジネスは成長したか 誰が評価するか IT担当者 IT担当者 利用者 経営者
- 152. こんなことになってはいないだろうか? 152 情報セキュリティ対策が効率や利便性の向上の障害に なっていないか？ ノートPCを購入した→ 危ないので持ち出し禁止 Office 365を契約した → 危ないので外部からの利用禁止 当初の導入目的は何だったのか。それが満たされているか 利用者に負担をかけない対策を行っているか？ 不審なメールは開かない → 開いた人の責任 複雑なパスワードを定期変更する → パスワードをつけた人の責任 IT利用によってビジネスは成長しているか？ 導入前と導入後で業績は変わらない 期待していた効果が得られない 業務効率は低下している 突発的な損失が起こる可能性を想定しているか？ セキュリティ事故や社内不正によって突発的な事故が起きた時の影響 について分からない、検討していない 事故対応（インシデントレスポンス）の準備はしていない
- 153. セキュリティ対策の狙いと手段 153 従業員の「判断」を最小化する 創造性の高い業務とそうでない業務を明確に分ける 創造性の必要ない業務における従業員の判断を最小化するため に業務の効率化・自動化を行う 従業員に創造性の高い業務をさせる 業務改善のため、従業員保護のためにできること セキュリティの判断を従業員にさせない なにかあった時に従業員を護ることができるように「継続的な 監視（Continuous Monitoring）」を行う そのために「IDとログ（記録）の一元管理」が必要
- 154. 認証基盤 154 識別 Identification 認証 Authentication 認可 Authorization 説明責任 Accountability R ------ W ------ X------ 識別：ユーザーを識別できるようにそれぞれに固有のユーザーアカウント（ID）を割り当てる。 例えば社員番号やメールアドレスなど。 認証：そのユーザーが本人であることを確認する。一般的な運用では、そのユーザーしか知りえ ないパスワードによる認証が中心。 認可：そのユーザーの属性に応じてアクセスできる範囲を確認する。たとえば、人事部のみアク セスできるファイルやフォルダーには人事部ユーザーだけがアクセスできるようにする。 認証基盤
- 155.
- 156. 認証に関わる課題 156 デバイス管理では穴だらけ デバイスが圧倒的に増えているため、利用周期が短くなってい るためにデバイス管理ではリスクマネジメントが難しくなって きた ユーザモニタリングを行うことで責任を明確に 誰がなにをしたのかを正しく判断することで、従業員も会社も 護ることができる 共通基盤を作れば、責任をインフラ側に客観視してもらうこと ができ、責任をより明確化できる
- 157. シングルサインオンとフェデレーション 157 急速なクラウド普及により、セキュリティ 対策 および利便性向上の両面において、 改めてシングルサインオンの需要が急増。 認証連携（フェデレーション）を利用する ことで パブリック・クラウドへもセキュア なアクセス/シングルサインオンを実現。
- 158. サイバー・セキュリティ対策の目的 158 どのような「心配事」があるかをリストアップする。 「リスク需要レベル」を明確にし、関係者と合意する。 重要度・緊急度を明確にして優先順位を決め対策する。 ITを最大限に活用するための最小限のセキュリティ ITを活用する上での心配事を解消し業務の効率や利便性を高めること サイバー・セキュリティの目的は「情報資産の保護」ではない。 リスクを適正に管理し業務の効率や利便性を高めること。 機密性：情報を盗まれないようにすること。 完全性：情報をデタラメな内容に書き換えられないようにすること。 可用性：システムを停止・破壊され業務継続を妨げられないようにすること。 安心・安全に、便利に効率よく仕事ができるようにする取り組み 問題を回避する対策：USBメモリー使用禁止 目的を達成する対策：安心・安全なファイル共有・交換サービスを提供 ファイルを受け渡したい
- 159.
- 160.
- 161. ISP ISP ISPISP インターネットの構造 海底ケーブル バックボーン バックボーン ラストマイル
- 162. CDN（Contents Delivery Network） ISPISP ISP ISP 海底ケーブル バックボーン Cache Cache Cache バックボーン ラストマイル
- 163.
- 164.
- 165.
- 166. 統合システムの分類 166 CPU NW 機能 CPU NW 機能 CPU NW 機能 サーバー サーバー ネットワーク ストレージ（SAN/NAS） アプリケーション開発用ソフト ウェア、データベース、テスト ツールや統合ツール、業務アプ リケーションなど ⇒ インフラストラクチャーをソフト ウェアに最適化 用途を限定せず 用途を限定せず インテグレーテッド プラットフォーム （アプライアンス） インテグレーテッド インフラストラクチャー (コンバージド・システム) ハイパーコンバージド インフラストラクチャー (ハイパーコンバージド・システム) インテグレーテッド・システム （コンバージド・システム） Oracle Exadata Database Machine PureData System for Analytics（旧Netezza） 各社Firewall・セキュリティアプライアンス Oracle Exalogic Elastic Cloud Vblock Infrastructire Package HP CloudSystem Matrix Nuwtanix NXシリーズ VCE VxRail HP Hyper Converged System IDCの定義による分類（一般的な分類） ネットワーク ストレージ（SAN/NAS）
- 167. コンバージド・システムとハイパーコンバージド・システム 167 Converged System (Integrated Infrastructure) Hyper-ConvergedSystem (Hyper-Converged Infrastructure) サーバー ネットワーク ストレージ（SAN/NAS） CPU NW 機能 CPU NW 機能 CPU NW 機能 追加 拡張 スケール アウト コンポーネントが多く管理が大変 スケールアップの限界 ストレージの複雑化 ハードや仮想化ソフトなどの複雑な設計 複雑な運用管理、管理者間の分散 性能拡張の限界 ネットワークのボトルネック ボリューム、LUN、ファイルシステム単位 サーバーはVMや仮想デスク単位で管理 独立サーバを 複数連結し 簡単・無制限に 拡張できる
- 168. 従来システムとハイパーコンバージド・システムとの違い 168 サーバー＋仮想化 ネットワーク・スイッチ ストレージ（SAN/NAS） サーバー ネットワーク・スイッチ ストレージ サーバー機能ネットワーク機能 ストレージ機能 運用管理 構成管理 仮想化 物理機器 従来までのシステム ハイパーコンバージド・システム 個別に構成・運用管理・拡張 一括して構成・運用管理・拡張 ハードや仮想化ソフトなどの複雑な設計 複雑な運用管理、管理者間の分散 個々に対応が必要なため性能拡張が難しい ハードや仮想化ソフトなどが予め統合 一括・一元的に運用管理 スケールアウトで性能拡張・自動で構成 複数連結し簡単・無制限に拡張できる 2Uサイズの筐体 システム機能を 一体・集約化
- 169. ハイパーコンバージド・システムのメリット 169 簡単・迅速にセットアップ サーバやストレージを個別に組み上げ る必要がない セットアップはソフトウェアで簡単・ 自動 統合された管理画面からサーバとスト レージを統合・一元的に管理 ユニット追加でスケールアウト 拡張に伴う構築や設定作業はソフト ウェアにより自動化 内部ストレージを仮想ストレージ （仮想SAN）として使用することで、 容量・性能を柔軟に拡張。 煩雑な初期サイジングは不要 物理スペースの削減 従来システム 仮想SANを利用することで、スト レージ専用機は不要
- 170.
- 171. ハイパーコンバージドの仕組みと特徴 CPU NW 機能 CPU NW 機能 CPU NW 機能 ネットワーク 共有ストレージを使わずローカルストレージを使う SDS機能により共有ストレージとして使う システム導入や設定、追加・拡張はソフトウェアで自動化 SDS: Software-Defined Storage 導入や運用管理の容易さから中小規模ユーザーのインフラ 容易にスケールアウトで拡張できることからVDI パブリック・クラウド移行の過渡期的用途としてインフラ 仮想システム SAN ストレージ・エリア・ネットワーク ネットワーク ネットワーク ネットワークスイッチが別途必要（Cisco製品は統合） インフラの仕組みが異なるためアプリケーション性能や運用方法の確認、見直しが必要 拡張の柔軟性に制約あり 考慮すべき点 仮想 サーバー 仮想 サーバー 仮想 サーバー サイロ型システム 外部ストレージ共有システム 仮想ストレージ共有システム
- 172.
- 173. コンバージド・システムとハイパーコンバージド・システム 173 Converged System Hyper-ConvergedSystem メーカーのお墨付き構成 迅速な実装 カスタマイズはできない 高い拡張性 簡単に導入 構成や運用の自動化 NXシリーズ Evo RAIL VxRACK VSPEX BLUE HyperFlex System
- 174. Hyper-Converged System 高い拡張性 簡単に導入 構成や運用の自動化 NXシリーズ Evo:RAIL VxRACK VSPEX BLUE HyperFlex System コンバージド・システムとハイパーコンバージド・システム 標準化されたモジュール サーバー、ネットワーク、ストレージで1単位のモジュール構成 全てをソフトウエアで設定・構成 システム全体の構成をソフトウエアの設定で行える 自己修復 障害の検知、切り分け、分散処理で自動的に修復 データとサービスを分散 データの管理とアプリケーション・サービスを分散処理 APIと自動化 アプリケーションや管理ツールと連携して運用や調達を自動化
- 175.
- 176.
- 177.
- 178.
- 179. 人をつなげる 179 共有による 告知 1 to N メッセンジャー 電子メール 掲示板 ブログ ライブラリー ソーシャル メディア 共感による 拡散 Nto N ルーチンワーク 大量・繰り返しの自動化 ワークフロー 業務の流れを電子化 コラボレーション 協働作業 カリキュレーション 大規模計算 オペレーション コミュニケーション Facebook Twitter グループウェア 送付による 伝達 1 to 1
- 180. 常識が変わるPCの使い方 180 インターネット データ 文書作成 表計算 プレゼン ・・・ブラウザ 画面表示・入出力操作 通信 画面表示・入出力操作 通信 オフィス・アプリ データ 文書作成 表計算 プレゼン ・・・ オフィス・アプリ クラウドサービス 文書作成 表計算 プレゼン ・・・ 一般的なPC クライアントPC ブラウザ
- 181.
- 182.
- 183.
- 184. データベース管理システム (DBMS) 紙からデジタルへ デジタルデータのメリット データモデルの定義 同時アクセス検索・更新 デジタルデータの業務活用 ＝複数のユーザーやシステムでデータを利用・処理 データの一貫性を保証 アクセス制御 対障害性 高速処理 検索 再利用・複製
- 185.
- 186. リレーショナル・データベースの系譜 1961年 IMS（Information ManagementSystem）/IBM 階層型データベース。NASAのアポロ計画で、最終製品を構成するBOM（Bill of Materials）を管理 1970年 Edgar F. Codd(IBMの研究者)が論文を発表 A Relational Model of Data for Large Shared Data Banks（大規模共有デー タバンク用データのリレーショナル・モデル） 1973年 Michael StonebrakerらがIngresの開発に着手 後にPostgreSQL前身、Postgresを開発者（PostgreS＝Post＋Ingres） 1983年 IBMがDB2をリリース 1979年 Lawrence J. EllisonがOracleをリリース 1984年 Robert EpsteinらがSybaseを設立 Ingressの開発に参加したひとり 1987年 SybaseがSQL Serverをリリース 1980年 Informix設立 2001年IBMが買収 1979年 Teradata設立 1989年 MicrosoftがSQL Serverをリリース 1988年から1993年までIngresがマイクロソフト社と技術提携 1989年 カリフォルニア大学がPostgresをリリース 1997年 PostgreSQLへ改名 1995年 MySQL ABがMySQLをリリース 2008年サンマイクロ → 2010年オラクルに買収
- 187. リレーショナル・データベースの革新性 187 SELECT 社員名 FROM社員 WHERE 年齢 < 30; 使いやすいデータ構造 テーブル 使いやすいユーザー・インターフェイス SQL データを格納する方法が直観的にイメージしやす い。こうした二次元表によるデータ管理は、 Excelなどのソフトが登場する前から一般的な方 法だったため、RDBが登場した当時の人々にとっ ても受け入れやすいものだった。 「データの位置」という概念を一切排除した。あ るデータが何行目であるとか何列目であるという アドレスやポインタといった扱いの難しい位置表 現を使わなくてもデータを操作できる。 SQLは英語に似せた構文を持っているため、特に英 語を母国語とする人々にとっては、日常言語でデー タを操作できるような感覚を持つ。 ループを排除し、記述の難しさやトラブルを無くす よう工夫されている。データのアドレスをポインタ や配列の添え字で操作したり、ループ処理を記述す ることにともなうバグを引き起こしやすいといった 弊害を無くすように考えられている。
- 188. リレーショナル・データベースの限界 188 性能と信頼性のトレードオフ データモデルの限界 グラフ構造 非循環グラフ構造 グラフ構造データの扱いが苦手 非構造化データの扱いが苦手 ドキュメント スケールアウトが難しい データを一元管理し、厳密なトランザクション管理 をするためにストレージを共有する構成を取る必要 があり、ストレージがシングル・ボトルネックポイ ントになってしまうから。 SQLの柔軟性 SQLの表現力が強力で柔軟であるため、かえって複 雑な処理を実行できてしまうこと。特に結合やサブ クエリといった複雑な処理を大規模なデータに実行 することで大規模なスローダウンを引き起こすこと がある。 近年、データは増大の一途をたどり、開発さ れた当初には想定していなかったデータ量を扱 うには、処理速度が原理的な限界に達している。
- 189.
- 190. 多様化するデータベース RDBMS NoSQL クラウド DB IaaS Cassandra, HBASE, redis,memCached, mongoDB, Couchbase/CouchDB, Neo4j, Oracle NoSQL マ ネ ー ジ ド Amazon Azure Google 商用 Oracle, DB2, SQL Server OSS MySQL, Postgres, MariaDB IBM RDBMS RDS SQL Database Cloud SQL DB2 Aurora Compose NoSQL DynamoDB DocumentDB Cloud Datastore Cloudant Table Storage Cloud Bigtable Graph BigData Redshift SQL DataWarehouse BigQuery DashDB オンプレミスDBをIaaS上でサポート サーバーレス AWS Lambda Azure Functions Azure Service Fabric Google App Engine Google Cloud Functions
- 191.
- 192. リレーショナルデータベース (RDBMS) 社員番号 氏名住所コード 通勤手段 S001 大越 章司 J101 鉄道 S002 斎藤 昌義 J302 鉄道 S003 山田 太郎 J201 バス S004 山本 次郎 J401 鉄道 住所コード 乗車駅 通勤手当 J101 柏 38,000 J201 浅草 12,000 J302 国立 34,000 J401 横浜 43,000 社員通勤表 通勤手当表 テーブル (リレーション) 社員番号 氏名 通勤手当 S001 大越 章司 38,000 S002 斎藤 昌義 34,000 S004 山本 次郎 43,000 鉄道通勤者の通勤手当表 関連づけ（リレーションシップ） IBMのエドガー・F・コッドが1969年に発表したデータ関係モ デルについての論文が元になっている 扱うデータは正規化された定型 データ 複数のテーブルを関連付けする ことができる テーブルを横断してデータを検 索したり操作できる 複数のテーブルから見たい列と行を取り出して新たな テーブルを作成（クエリー）
- 193. RDBMSが追求してきたACID特性 ACID Atomicity 処理を一部残すなど、中途半端な状態を許さない Consistency データの整合性を保証 Isolation一連の処理を他の処理から隔離 Durability 処理が完了した時点で結果は保存され失われない 複数のユーザが同時に同一のデータを参照・更新した場合でも、矛盾なく正常に処 理をこなすことができる どの時点でもデータは絶対に正しいことを保証 →金融取引などの「トランザクション」処理に必須 データを常に正しく保つ データを失わない 障害に耐える
- 194.
- 195.
- 196. DBMS高速化への要求と取り組み トランザクションの増加 データ量の増加 (ビッグデータ) 単体能力の強化 (Scale Up) 集計・分析処理の 高速化 分散処理 (ScaleOut) 列指向 RDBMS クラスタ Shared Nothing Sharding I/O分散 キャッシング インメモリ
- 197.
- 198. RDBMSの高速化手法と問題点 データの分割/同期が必要 単体能力の向上 ストレージ共有 クラスタ 分散システム シェアドナッシング オーバーヘッドが少ない 用途を限定 (Webなど) 最大数百台程度まで ハードウェアコストが高い 最大でも数十台程度まで トランザクションに向かない I/Oがネックになる スケールアップスケールアウト DB側の対応は必要無し ハードウェアコストが高い 性能に上限がある I/Oがネックになる
- 199.
- 200.
- 201. 列指向(カラム指向/カラム型) RDBMS カラム型 RDBMS RDBMS+ カラム処理 SybaseIQ, Netezza,Verticaなど SQL Server ColmunStore Index, Oracle 12c, Oracle Exadata Hybrid Columnar Compression, HANAなど DWH向け 集計・分析処 理を高速に 実行 通常のRDBMSが取り扱う「行」単位ではなく、「列」単位で処理 顧客名 住所（県） 住所（市町村） 売上金額 「列」指向の特長 ・蓄積したデータから特定の列を高速に読込む ・データの追加、削除、更新には向かない ・BI/DHW (OLAP) 向け 「行」指向(通常のRDBMS)の特長 ・行毎にデータを追加、削除、更新 ・ランダムアクセス、頻繁な更新に向く ・トランザクション処理 (OLTP) 向け 行 列
- 202. 列指向RDBMSの得意分野 ～ 集計 顧客名住所（県） 住所（市町村） 売上金額 顧客名 住所（県） 住所（市町村） 売上金額 売上金額の集計 行指向 列指向 1レコードずつ読み出して集計 売上金額の列のみを読み出して集計
- 203. 列指向RDBMSの得意分野 ～ 分析 顧客名住所（県） 住所（市町村） 売上金額 顧客名 住所（県） 住所（市町村） 売上金額 顧客の都道府県分布の分析 行指向 列指向 1レコードずつ読み出して集計 都道府県の列のみを読み出して集計 データの圧縮率を上げられる
- 204. 列指向RDBMSの不得意分野 ～ 挿入 顧客名住所（県） 住所（市町村） 売上金額 顧客名 住所（県） 住所（市町村） 売上金額 顧客レコードを挿入 行指向 列指向 レコードの挿入が容易 各列にレコードを挿入
- 205.
- 206.
- 207. RDBMSとKey Value Store(KVS) RDBMS KVS データ形式 テーブル キー＋バリュー (値) データ構造 正規化・構造化データ 構造化/非構造化データ 設計の柔軟性 事前にスキーマを定義 スキーマレス (変更が容易) 処理の柔軟性 複雑な検索や集計が可能 シンプルな操作のみ データの整合性確保 ◎ (ACID) △ (BASE) 分散処理 △ ◎ トランザクション処理 ◎ △ SQLサポート ◎ △ RDBMS KVS
- 208. ACIDからBASEへ BASE Basically Available 「基本的に」利用可能 Soft-state状態の厳密性を追求しない Eventually consistent 最終的に一貫性が保たれれば良い 厳密な一貫性やデータの即時反映などをあきらめる代わりに、 スケーラビリティや柔軟性を得ることができる ACID Atomicity 処理を一部残すなど、中途半端な状態を許さない Consistency データの整合性を保証 Isolation 一連の処理を他の処理から隔離 Durability 処理が完了した時点で結果は保存され失われない 絶対確実 概ね確実 CAP定理 = 分散システムではACIDを達成できない
- 209. ワイドカラムストア型 Amazon DynamoDB ApacheCassandra Amazonが提供するフ ルマネージドのNoSQL サービス DynamoDBをベースに Facebookが開発し、 オープンソースとして 公開 大規模にスケールアウト可能。ノードを増やすとリニアに性能を向上させることができる。 データの一貫性を保証 Google BigTable Apache HBase Googleが開発した拡張 KVS Googleの論文を元に Javaで実装し直した オープンソース 結果整合性 (遅延とのトレードオフで一貫性レベルを設定可能) 可用性は保証されない (3つのノードにレプリカを作成) 可用性を保証 柔軟なデータモデル (スキーマレス)
- 210. 様々なNoSQL キーバリュー型 (KVS) ワイドカラム ストア型 (列指向) ドキュメント型 グラフ型 Riak Redis Google BigTable ApacheHbase Amazon DynamoDB Apache Cassandra Couchbase MongoDB Neo4j キー (Key) と値 (Value) のみのシンプルなデー タ構造 KVSを拡張して複数の バリューを持たせたも の KVSよりも柔軟で複雑 なデータ構造に対応で きる グラフ理論にデータ同 士の関係をグラフとし て表す 「元祖」NoSQL KVS以外でもキーとバリューを使うDBは多く、広い意味では全てKVSとも言える Key Value 001 山田太郎 002 中村一郎 Key Value 001 山田太郎 002 管理部 中村一郎 財務部 係長 氏名 所属 氏名 所属 役職 管理部 財務部 顔写真 係長 顔写真 中村一郎 山田太郎 Document 1 Document 2
- 211.
- 212.
- 213.
- 214.
- 215.
- 216. 実際のシステムは適材適所で ECショップ 商品検索 = KVS 決済処理= RDBMS 金融取引・決済 RDBMS ワイドカラム グラフ 検索・SNS ドキュメント 文書管理
- 217.
- 218. クラウドデータベース (マネージド/DBaaS) Amazon AzureGoogle IBM Graph Graph BigData Redshift SQL DataWarehouse BigQuery DashDB Document DynamoDB DocumentDB KVS DynamoDB Table Storage Cloud Datastore Cloudant Cloud Bigtable RDBMS RDS SQL Database Cloud SQL DB2 Aurora Cache ElastiCache Redis Cache * Amazon RDSはAurora, MySQL, MariaDB, Postgres, Oracle, SQL Serverをサポート
- 219.
- 220.
- 221.
- 222. Hadoop 非構造化 テキスト 動画 音声 ビッグデータ ビッグデータ の分割処理 （MAP処理） 演算結果 の集約処理 (REDUCE処理) コンピューター1計算処理 コンピューター2 計算処理 コンピューター3 計算処理 コンピューターn 計算処理 知見（インテリジェンス）やノウハウ アドバイス、ガイド、制御、最適化などのために使用 ・ 多数のコンピューターによる並列分散処理 半構造化 XML 構造化 JSON 業務データ GPS センサー 文書 NoSQLデータベース 関係データベース HDFS（分散ファイルシステム） Hadoop Distributed File System MapReduce アナリティクスなどのアプリケーション
- 223. Hadoop2 YARN (Yet AnotherResource Negotiator) 層を追加 ジョブスケジューリングとリソース管 理を行う MapReduce以外の分散処理アプリ ケーションをサポート
- 224. Hadoopの業務データ・バッチ処理への適用 CPU 使い切れない ディスク装置 メモリー バッチデータ 単一PCサーバー & RDBMS 単一I/Oパス&単一 CPUノードでは処理 の多重度も限界 CPU 使い切れる ディスク装置 メモリー CPU 使い切れる ディスク装置 メモリー CPU 使い切れる ディスク装置 メモリー 複数PCサーバー & Hadoop 処理ノードを分散、I/Oパスも分 散することでI/Oボトルネックを 解消 CPU 使い切れる ディスク装置 メモリー チャネル サブシステム I/O専用プロセッサー メインフレーム &RDBMS 複数I/Oパス &I/O専用プ ロセッサーを 持つことで I/Oボトル ネックを回避 し高い多重 度を実現
- 225. BigQueryとCloud Dataflow 高度にスケーラブル 地球規模でレプリカ BigTable MapReduce GFS Spanner FlumeJava MillWheel GFS BigQueryCloud Dataflow SQLライクな関数 超並列クエリ 並列パイプライン処理 大規模ストリーム処理 関数型プログラミング バッチとストリーム
- 226. The Apache SoftwareFoundation オープンソースソフトウェアのプロジェクトを 対象に、ハードウェアやコミュニケーション 手段などのビジネスインフラを提供 特定の拠点を持たないバーチャル な組織 WebサーバーのApacheを作った グループが設立 Hadoop、Sparkを始め、300以上の オープンソースプロジェクトを管理
- 227.
- 228.
- 229.
- 230. 構造化データと非構造化データ 非構造化 データ 半構造化 データ 構造化 データ 構造やサイズの決まっているデータ 見積書・納品書・在庫管理 顧客リスト・部品リスト など 構造・サイズが概ね決まっているデータ 営業日報・ブログ・SNS など 構造・サイズが決まっていないデータ 企画書・提案書・Webサイト ビデオ・画像・音声など ファイル サーバー グループ ウェア RDBMS RDBMSは構造化データの処理に向い ている 現実世界では非構造化データが大半 を占める 今後Web/SNS/モバイル/IoTの普及で データ量が爆発的に増える 大量の非構造化データを効率的に処理する必要 RDBMSではない 新しいDBMSが必要
- 231.
- 232. ブリュワーのCAP定理 *CAP定理は特定の条件下でのみ成立するという議論も有り A C P C+A 一貫性と可用性を選択するとネット ワークの分断に対応できない(しづら い)。 A+P 可用性とネットワーク分断耐性を選 択すると、一貫性が(一時的に)失わ れる。 C+P 一貫性とネットワーク分断耐 性を選択すると、可用性が (一時的に)失われる。 Availability 可用性:クライアントが、常にサービスにアクセス (読 込みも、書込みも) できることを保証 Consistency 一貫性:データ更新したら続いてアクセスする 全クライアントが必ず更新されたデータを取得 できることを保証 Partition Tolerance ネットワーク分断耐性:ノード (物理・仮想サー バ) がひとつ壊れたとしてもシステム全体が問 題なく動作し続けることを保証 分散システムにおいては、 CAPのうち同時に２つの要件しか満 たすことができない トレードオフ RDBMS NoSQL
- 233. ブリュワーのCAP定理 分散システムにおけるデータの複製においては、C (Consistency), A(Availability), P (Partition Tolerance) のうち、同時に２つの要件しか満たすことができない 分散DBシステムにおいて、ノード間の接続が失われた場合にもDBが動作し続けることを望む場合 (Partition Tolerance) データの一貫性と可用性のどちらかをあきらめなければならない 一貫性が一時的に失われることを許容 「いいね！」がすぐに反映されないなど - Eventually Consistent - 可用性が一時的に失われることを許容 サービスが一時的に使えないことがあるなど - Basically Available - Pを諦める (分散させない) 場合 には、データの一貫性と可用性を同時に達成でき る - ACID (RDBMS) -
- 234. 何を重視するか？ A+Pの例 Facebook Cassandra Amazon Dynamoなど 一貫性が一時的に失われる 「いいね！」がすぐに反映されないなど - Eventually Consistent - C+Pの例 Google BigTable Hadoop Hbaseなど 可用性が失われる場合がある サービスが一時的に使えないことがあるなど - Basically Available - C+Aを重視する例 Oracle MySQLなど ネットワークの分断に弱い 整合性を保つ仕組みが必要 - ACID -
- 235. Contents1 Contents2 Contents3 Contents1 Contents2 Contents3 Google BigTable 数千台～数万大規模の 分散処理が可能 (安価なIAサーバーを利用) 機能はミニマム サーバーの冗長化によ る高い可用性 (同時に3台以上のサーバーに データを保持) 無制限のスケーラビリ ティ (データが増えてもレスポンスが遅 くならない) Value Contents1 Anchor1AAnchor1B Contents2 Anchor2A Anchor2B Contents3 Anchor3A Anchor3B URL2 URL3 Key URL1 キーに基づく行のCRUD (追加・取得・更新・削除) ACIDを保証 キーに基づくスキャン キーの前方一致検索もしくは範囲指定検索に より、複数の行を一括取得 BigTableのデータモデル (例) http://static.googleusercontent.com/media/research.google.com/ja//archive/bigtable-osdi06.pdf を参考に再構成 アプリケーションの設計・実装が困難 プログラマに負担
- 236.
- 237.
- 238. 現実のビジネスや業務で発生するデータは不定型 Copyright © 2012CyberTech Corporation. All rights reserved.
- 239. RDBMS ～情報の一部分を抜き出して高速処理～ Copyright ©2012 CyberTech Corporation. All rights reserved. 必要な部分を正規化 ・トランザクション処理 ・演算処理 表に入れるのに都合の良いデータ お行儀の良いデータ＝正規化可能なデータ＝構造化データ
- 240. RDBMSで扱いづらいデータ Copyright © 2012CyberTech Corporation. All rights reserved. 基幹系（定型データ） ・会計 ・生産管理 情報系（不定型データ） ・ドキュメント ・ナレッジ ・コンテンツ情報
- 241. Not Only SQL= NoSQL キーバリュー 型 Key Value Store (KVS) キー (Key) と値 (Value) の単純な組み合わせ 機能はミニマム 大規模データの分散処理に向く ソート済み カラム指向 KVSのValueを列方向に拡張 KVSよりも複雑なデータを持つことができる 非構造化データも取扱い可能 大規模データの分散処理に向く ドキュメント 指向 木構造のデータに向く RDBMSで必須のスキーマが必要無い データ構造が柔軟で、追加・変更が簡単 非構造化データに向く 分散処理しやすい Dynamo Riak Redis Cassandra HBase MongoDB CouchDB XMLDB
- 242. データベース高速化へのニーズの高まり 242 これまでとは桁違いのデータ量 非構造化データへの対応 RDBMSの高速化 新しいデータベース インメモリ NoSQL(Not Only SQL) カラム型RDBMS SSD I/O強化 ドキュメントDB KVS トランザクションの増加・高速化 データ解析ニーズの増大 (BI)
- 243.
- 244. Data Lake 非構造化データ／オブジェクトストア データ量の爆発的増大 244 ETL 解析に必要なデータ を選別・抽出 DWH Data Warehouse アナリティクス BI BusinessIntelligence 全てのデータを収集 業務アプリケーション Webアプリケーション IoTアプリケーション AI Artificial Intelligence Data Lake(Big Data)を解析し 規則や構造、関係性を探索
- 245. HDD （磁気ディクス） SSD （NAND フラッシュ・メモリ） メモリ （DRAM） HDD （磁気ディクス） メモリーとストレージの階層構造 245 SSD （NAND フラッシュ・メモリ） SSD (3DXpointなど) 高速キッシュ・メモリ (SRAM) メモリ （DRAM） 高速キッシュ・メモリ (SRAM) HDD （磁気ディクス） SSD （NAND フラッシュ・メモリ） SSD (3D Xpointなど) SSD (MRAMなど) メモリ （DRAM） 高速キッシュ・メモリ (SRAM) プロセッサー プロセッサー プロセッサー SCM Storage Class Memory 過去 現在 近未来 速い 小さい 遅い 大きい 速 度 速 度 SATA/SAS PCIe NVMe/NVMe-oF ストレージ データ転送 プロトコル
- 246. メモリーとストレージの関係 246 L1キャッシュ L2キャッシュ コア0 L1キャッシュ L2キャッシュ コア1 L1キャッシュ L2キャッシュ コア2 L1キャッシュ L2キャッシュ コアX メモリー･コントローラー 入出力コントローラー L3キャッシュ CPU（Central ProcessingUnit） SRAM Static Random Access Memory メモリー DIMM Dual Inline Memory Module ストレージ SSD(Solid State Drive) Storage Array HDD(Hard Disk Drive) Server-Side Flash Storage Flash Storage Flash Storage Array 不揮発性 揮発性 揮発性 DRAM Dynamic Random Access Memory 速度：速 容量：小 単価：高 速度：遅 容量：大 単価：低
- 247. 不揮発性 容量と速度の違い 247 容量 速度 SSD HDD Server-Side Flash Storage Flash Storage DRAM SRAM （CPU内キャッシュ） KB MB GB TB ナノ秒マイクロ秒 ミリ秒 揮発性 ← SATA/SAS → ← PCIe/NVMe →
- 248. ストレージ構成の変遷 248 DAS Direct Attached Storage DAS Direct Attached Storage SAN NAS StorageArea Network Network Attached Storage SDS Software Defined Storage 大容量化と負荷分散のため 本体からストレージを分離 ハードディスクドライブの低価格化と安 価なハードディス クドライブを冗長化す るRAID（Redundant Arrays of Inexpensive Disk）技術により信頼性 が 向上、ディスクアレイはさらに低コスト かつ大容量化 サーバーをストレージのコントローラ として使用し、ソフトウェアだけで ディスクアレイを実現
- 249. アーキテクチャーから見るストレージの違い コントローラー コントローラー コントローラー 性 能 性 能 CTL CTL CTL CTLCTL CTL CTL CTL CTL CTL CTL スケールアップ・アーキテクチャ スケールアウト・アーキテクチャ CTL 249 容量 容量 CTL CTL CTL CTL CTL CTL 共有メモリー サーバー・アクセス 密結合型スケールアウトアーキテクチャー 「基礎から学べる！最新ストレージ技術と選択ガイド」を参考に作成 http://itpro.nikkeibp.co.jp/atclact/active/14/100700086/ コントローラー性能が ボトルネック
- 250. アーキテクチャーから見るストレージの違い 250 要件／方式 スケールアップ スケールアウト 密結合型 疎結合型 拡張方式ディスクドライブの増設 ノード単位の増設(*1) 容量と性能が同時に拡 張可能 ノード単位の増設 容量と性能が同時に拡 張可能 性能上限 コントローラ性能が上限 ノード数の上限 ノード数の上限 性能特性 レスポンスタイムが短い ランダムI/Oに強い レスポンスタイムが短 い ランダムI/Oに強い レスポンスタイムが長 い シーケンシャルI/Oに強 い コントローラー 障害時影響 50％の性能低下 1/Nの性能低下 （N=コントローラ 数） 1/Nの性能低下 （N=ノード数） 容量規模 中規模（目安：数百テラバイ ト） 大規模の対応が可能 大規模の対応が可能 適用シーン データベース、仮想環境、 ファイルサーバー、グループ ウェアなど多目的での利用が 可能 ミッションクリティカ ル基幹業務 大規模ファイルサー バー、デジタルメディ アコンテンツ保管、ビ デオサーベランスなど 「基礎から学べる！最新ストレージ技術と選択ガイド」を参考に作成 http://itpro.nikkeibp.co.jp/atclact/active/14/100700086/
- 251. サーバー・ベースド・ストレージ 251 専用 ストレージ デバイス 論理 ストレージ デバイス 汎用サーバーのストレージを束ねて ひとつの共有ストレージとして扱う ストレージ・アレイなどの専用デバイスで 共有ストレージを実現する 専用デバイスによる共有ストレージ サーバーベースド・ストレージ 高価だが高速 安価で低速だが拡張性が高い 「基礎から学べる！最新ストレージ技術と選択ガイド」を参考に作成http://itpro.nikkeibp.co.jp/atclact/active/14/100700086/
- 252. アクセス方式の違いから見るストレージ 252 ブロック・ストレージ ファイル・ストレージ ファイル単位 オブジェクト・ストレージ ID IDID ID ブロック単位 オブジェクト単位 ストレージの拡張性：〇 レスポンスタイム ：◎ 主な用途 ： データベース 仮想環境 基幹業務システムなど ストレージの拡張性：〇 レスポンスタイム ：〇 主な用途 ： ファイルサーバー（NAS） 仮想環境 データアーカイブなど ストレージの拡張性：◎ レスポンスタイム ：△ 主な用途 ： デジタルコンテンツ保存 オンライン・ストレージ データアーカイブなど NFS,CIFS,SMB FC,FCoE,iSCSI HTTP/HTTPS IPネットワーク IPネットワーク 高速ネットワーク (SANなど) 「基礎から学べる！最新ストレージ技術と選択ガイド」を参考に作成 http://itpro.nikkeibp.co.jp/atclact/active/14/100700086/
- 253. ブロック・ストレージ アクセス方式の違いから見るストレージ 253 ファイル・システム ブロック単位（4KB/8KB）で区分し、 ファイル・システムでファイルとブロッ クを紐付け。 ローカル・ストレージと同様に高速でア クセスできることを目的とする。 ファイル・ストレージ 認証サーバー介し権限を確認 プロトコルの違いを変換 ブロック・ストレージに比べオーバー ヘッドが大きくアクセスに時間はかかる。 複数ユーザーとのファイル共有（NAS） を目的に使われる。 253 オブジェクト・ストレージ オブジェクトID HTTP/HTTPSでオブジェ クトをストレージへ送信 メタデータ ノード追加により容易に容量を追加でき、 非常に拡張性が高い。階層構造がないた め制限なく無数のコンテンツを保管する ことができる。変更頻度が少ないデータ や膨大なデータ保管に向いている。アー カイブ（長期保存）には最適。 ファイル名 ファイルサイズ 作成日付 患者名 患者ID 診療科 主治医など 「基礎から学べる！最新ストレージ技術と選択ガイド」を参考に作成http://itpro.nikkeibp.co.jp/atclact/active/14/100700086/
- 254. ストレージ性能の推移／1台当たりの容量 2008 2009 20102011 2012 2013 2014 2015 2016 2017 1980 5 6 7 8 9 10 11 12 13 14 5MB 容 量 倍 速 度 ４ 倍 14 アクセス性能 1.2倍 3600 rpm 15000 rpm T byte
- 255. ストレージ･コストの推移 255 Seagate HDD PricesBy Size Backblaze Average Cost per Drive Size https://www.backblaze.com/blog/hard-drive-cost-per-gigabyte/ 劇的な価格低下が進む データ保有コスト ストレージ容量を 意識することからの解法
- 256. CPUとストレージのパフォーマンス 2008 2009 20102011 2012 2013 2014 2015 2016 2017 10 20 30 40 50 60 70 80 90 100 CPU性能×100倍 ストレージ性能×1.2倍 パ フ ォ ー マ ン ス ・ ギ ャ ッ プ 両者のギャップを埋める手段として注目される フラッシュ・ストレージ ナノ秒 ミリ秒
- 257. 物理マシン 仮想化の普及によるストレージ能力の限界 257 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン ハイパーバイザ 物理マシン上で多数の仮想マシンが稼働しストレージはさらに複数の物理マシン間で共有ストレージとしてシェアされる。 それぞれの仮想マシンがハイパーバイザ経由で共有ストレージに対して勝手にI/O要求を発行するので、共有ストレージに 対して、かなりランダム性の高いアクセスが集中してしまう。 高度にランダム化されたアクセスは共有ストレージにとって大変な負荷になり、ストレージの性能限界によってシステム 全体の性能やサーバーの統合が制限されてしまう問題が頻繁に発生する。 仮想サーバーの数は物理サーバーの台数をはるかに上回る伸び率で増加している。 HDD SATAやSASなどの HDD用インターフェイス 速度の制約
- 258. フラッシュ･ストレージ／今後の展開とその分類 大容量化の限界 高速化の限界 低消費電力化の限界 サーバーサイド・フラッシュ (PCIeフラッシュ) オールフラッシュ・ストレージ・アレ ハイブリッド・ストレージ・アレイ サーバー内のPCIe（PCI Express）ポートに直接接 続する、ボード型のフラッシュストレージ製品。 「ホストフラッシュ」と呼ばれることも。サーバー内 のPCIeポートに直接接続するので、他のサー バーとの共用はできない。 ストレージアレイ内の記憶装置が、すべてフ ラッシュメモリで構成されたフラッシュストレー ジ製品。 ストレージアレイ内の記憶装置が、フラッシュメモ リとHDDの混在状態で構成されたフラッシュスト レージ製品。HDDと混在することでオールフラッ シュアレイよりもデータ容量を増やせる。 フラッシュ・ストレージ 長期・大容量保存 高速IO性能 HDD互換・PC
- 259. フラッシュ･ストレージ／性能比較と用途 SRAM キャッシュ DRAM ミリ秒(10-3) マイクロ秒(10-6) ナノ秒(10-9) 3桁の違い 百IOPS 数万IOPS 数百万IOPS メモリー速度に近いIO速度 仮想化 (サーバーやデスクトップ) データ分析 デーベース処理
- 260. ストレージアレイ（HDD／SSD／フラッシュストレージ） 260 CPU SSD コントローラー RAID コントローラー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー PCIe SAS CPUHDD コントローラー RAID コントローラー HDD HDD HDD HDD HDD HDD PCIe SAS HDD（Hard Disk Drive） SSD（Solid State Drive） CPU フラッシュ メモリー 専用 コントローラー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー フラッシュ メモリー PCIe/NVMe フラッシュストレージ 高 速 物理的スピードと電子的スピードの違い HDD代替を前提とした設計か フラッシュメモリーの性能に最適化された専用設計かの違い SATA:Serial Advanced Technology Attachment SAS:Serial Attached SCSI PCIe:Peripheral Component Interconnect Express NVMe：Non-Volatile Memory Express
- 261. フラッシュストレージの最新動向 261 フラッシュメモリーの高密度化 データ転送規格の高速化対応 セルサイズの縮小 現状15nmの物理限界に達している セル当たりのビット密度向上 • 1ビット SLC/Single Level Cell • 2ビット MLC/Multi Level Cell • 3ビット TLC/Triple Level Cell • 4ビット QLC/Quad Level Cell ビット数が増える事に書き換え可能数が減少 3次元積層化 現在、64層の製品が登場している HDDやテープ時代の規格を流用 SATA(Serial Advanced Technology Attachment) SAS(Serial Small Computer System Interface) 高速ストレージに対応した規格 NVMe(Non-Volatile Memory express) • PCIe接続(PCIe baced NVMe) • 光ファイバー接続(NVMe over Fabric) 3D XPoint Technology インテルとマイクロンによって発表された不揮発性メモリの技術。 DRAMの凡そ半分の価格、NANDフラッシュに比較すれば4・5倍。 NANDフラッシュと比較した場合、レイテンシは1/10、書き込み寿命は3倍、書き込み 速度は4倍、読み込み速度は3倍に改善され、消費電力は30%に軽減される。
- 262.
- 263. フラッシュメモリ インラインでの重複排除／圧縮 NVRAM Non-Volatile RAM 不揮発性ランダムアクセスメモリ ASIC Application SpecificIntegrated Circuit 特定用途向け集積回路 重複排除／圧縮 コンピュータ OS アプリケーション コンピュータ OS アプリケーション コンピュータ OS アプリケーション スピードを犠牲にすることなく 論理的なよう両端かを下げる。
- 264.
- 265. フラッシュストレージが注目される理由 年率30%〜40%の容量単価 信頼性・可用性の向上 （99.9999%＝31秒停止／年） ＊960GBのSSDが24000円を切る製品が登場（@25円/GB） 性能＝10倍／運用管理コスト＝1/3 設置面積 5ラック（210U＝42Ux5）→3U 消費電力 大幅低減（機械稼働→半導体） 発熱量・消費電力が少ないため高密度化が可能 I/Oボトルネックの解消 バッチ処理時間の大幅低減 ユーザー・レスポンスの改善（EC、オンライン・トレードなど） DBライセンスの削減（契約CPUコアをフル利用）
- 266. フラッシュ･ストレージ／ 普及の背景 大量アクセス+高速応答 フラッシュの容量当たり単価が 高くHDDとの差がなかなか縮 まらなかった。 フラッシュストレージの特性に 起因する信頼性が問題視された。 HDDのIF(ATA,SATAなど)が普 及しフラッシュの特性を活かし た仕組みの普及が阻害されてい た。 エラー訂正や障害対策の機能が ソフトウェア、ファームウェア で対応できるようになり、書き 換え回数上限や耐障害性の懸念 がほぼ払拭 コンシューマー市場での普及に より容量単価が大きく低下 インラインによる重複排除／圧 縮の採用と性能の向上 高速 HDDの1000倍 高密度 設置面積 低消費電力
- 267. ソフトウェアとして提供される場合と アプライアンスとして提供される場合 ハードディスクなどの不揮発性媒体である 二次記憶（ストレージ）にリアルタイムで データの永続化を行わない リセットや電源が切断されても ログとスナップショットからデータを復元 インメモリー・データベース DBMS 揮発性メモリー(DRAM) スナップ ショット ログ データ更新 定期的 セーフ ポイント SAP HANA, IBMsolidDB Oracle TimeTen, Altibase ・・・ DRAMなどの揮発性メモリーの 一次記憶（主記憶装置）に データを保持・処理 データ
- 268. 揮発性メモリー(DRAM) DBMS データ In-Memory デュアル･フォーマット・データベース Database 12c リアルタイム統合データベース 基幹業務(ERP)+分析業務(BI) 行単位で処理 列 単 位 で 処 理 行指向 データベース (一般的なRDB) 列指向 データベース (DWH) 業務トランザクション処理 OLTP (OnlineTransaction Processing) 頻繁にデータを追加・更新 分析・レポーティング処理 OLAP (Online Analytic Processing) 大量にデータを検索・集計 自動同期 データ ストレージ
- 269.
- 270.
- 271.
- 272. CPU コンピュータの５大機能 制御装置 演算装置 記憶装置 入力装置 出力装置 プログラムやデータ を格納 数値演算、論理演 算を実行 演算結果を外部へ 出力 プログラムやデータ、 人間からの指示を 入力 プログラムの読み 込みやデータの読 み書きを制御 ノイマン型 (プログラム内蔵型)のデジタルコンピュータでは、プログラムやデータを 記憶装置に格納して順次読み込みながら処理を行う
- 273. 記憶装置の進化 CPU DRAM 磁気テープ/カード CPUDRAM SSD/HDD プログラム・データ プログラム・データ プログラム・データ プログラム・データ 処理 処理 ファイル
- 274. 外部記憶装置が不要に!? CPU DRAM CPU 不揮発性メインメモリ プログラム・データ プログラム・データ プログラム・データ 処理 処理 SSD/HDD 3DXpoint 高速化 パラダイムシフト プログラミングが変わる OSの役割が変わる ファイルが無くなる?
- 275.
- 276. 1G 2G 3G4G 5G 音声 テキスト データ 動画 あらゆるモノがつながることを前提とした 社会課題の解決 通信・コミュニケーションの性能向上 移動体通信システムの歴史 1979～ 1993～ 2001～ 2012～ 2020〜 9.6Kbps 28.8～384Kbps 2.4～14.4Mbps 0.1～1Gbps 10Gbps～
- 277. 5Gのビジネスの適用領域 データ量超増大 × 即時性向上 1通信あたりのデータの嵩が増える リッチ化する：高精細や高音質になり臨場感、没入感 が増す 多角化する：同時に取り扱える情報の選択肢が増える 1通信あたりのデータの種類が増える 制御用の情報（センサーやカメラからの情報）が増え る：自動○○が実現する 参考可能な情報（ログ情報）が増える：パーソナライ ズのパターンが増える、レコメンドの精度が向上する、 対象への理解が深まる タイムラグがほぼ無くなる 距離の制約が消える：各地に散らばる人たち同士で同 時に何かやる、今やった/起きたことをすぐに取り込 んですぐ活かす 社会（利便性）向上系 医療分野 超高信頼低遅延通信の実現で移動中や遠隔地の高度診療が可能になり、 医療格差が解消される 農林水産分野 超大量端末同時接続の実現で作物や家畜などの状況を把握するセン サーと散水・薬剤散布や給餌を実施するロボットやドローンの制御が 可能になり、減少する従事人口を補える 土木建築分野 超大量端末同時接続と超高信頼低遅延通信の実現によって遠隔制御が 可能になり、危険度が高い高所・鉱山・災害地などの現場での安全な 作業が確保でき、またドローンの活用による高精度測量などの精度が 向上する 生活分野 自動運転と遠隔制御によって、細分化された公共交通が実現する センサー情報を駆使して状況を把握する店舗運営が可能になる 遠隔授業や家庭教師の実現によって、学習格差が解消される 大量センサーと自動判定AIによって、防災・防犯・減災力が向上 VRオフィスとテレワークが実現する コンテンツ向上系 スポーツの場合⇒体験が深くなる 自動制御が可能になってカメラ台数を一気に増やせることで、多地 点・ドローンなどによる多角度撮影ができるようになる 取得データの種類が増え分析できる情報が増えることで、選手のバイ タルデータ・顧客のバイタルデータ・環境データが取得できるように なる AIが発達することでデータの有効活用レベルが上がり、多角的な分析 結果を提示できるようになる エンタメの場合⇒現実を超える仮想実現へ 即時性が向上することで出演者の居場所を問わない制作環境を実現さ せることや、同時多人数対応の参加型体験の提供ができるようになる スポーツ＆エンタメに共通 1通信あたりの送信データの嵩が増え、高画質・高音質・8K360°リ アルタイムな高臨場感映像が提供できるようになり、また視聴者に合 わせた多種多様な映像・情報を提供できるようになる 生活者データ・ドリブン・マーケテイィング通信より https://seikatsusha-ddm.com/article/10129/
- 278.
- 279. コレ１枚でわかる第５世代通信 279 1G 2G 3G 4G 高速・大容量データ通信 10G～20Gbpsのピークレート どこでも100Mbps程度 大量端末の接続 現在の100倍の端末数 省電力性能 超低遅延・超高信頼性 1m秒以下 確実な通信の信頼性担保 5G 音声 テキスト データ 動画 IoT 多様なサービスへの適用を可能にする 異なる要件のすべてを1つのネットワークで実現する。 各要件をに応じてネットワークを仮想的に分離して提供する（ネットワーク・スライシング）。 1984年～ 1994年～ 2001年～ 2010年～ 2020年代～
- 280.
- 281. 5Gの普及段階 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 高速 eMBB 低遅延 URLLC 多接続 mMTC 4G（LTE） 4Gコアネットワーク LTE 基地局 4Gコアネットワーク LTE 基地局 NR 基地局 マクロセル スモールセル 既存周波数帯 新しい周波数帯 NSA NSA: Non-Standalone 5Gコアネットワーク LTE NR 基地局 既存周波数帯新しい周波数帯 SA SA: Standalone マクロセル スモールセル NR ユーザー情報 制御情報 ユーザー情報 ユーザー情報 制御情報 SA LTE: Long Term Evolution NR: New Radio 5G初期 5G普及期 2010〜 2020〜 2022〜
- 282.
- 283. 5Gの3つの特徴 先送り 高速・大容量 大量端末接続 超低遅延・高信頼性 100万台/k㎡ 1ミリ秒 20Gビット/秒 1Gビット/秒 10万台/k㎡10ミリ秒 20 倍 5G 4G URLLC： Ultra-Reliable and Low Latency Communications mMTC： massive Machine Type Communications eMBB： enhanced Mobile Broadband リアリティの再現 光ファイバーの代替／補完 高精細／高分解能な デジタル・ツインの構築 時空間の同期 リアルタイム連携
- 284. 5Gの３つの特性 284 URLLC：Ultra-Reliable andLow Latency Communications／超低遅延・超高信頼性 eMBB：enhanced Mobile Broadband／高速大容量通信 ＊標準化が先行 mMTC：massive Machine Type Communications／大量端末接続
- 285. 第５世代通信の適用例 285 高速・大容量データ通信 10G～20Gbpsのピークレート どこでも100Mbps程度 大量端末の接続 現在の100倍の端末数 省電力性能 超低遅延・超高信頼性 1m秒以下 確実な通信の信頼性担保 5G 多様なサービスへの適用を可能にする 異なる要件のすべてを1つのネットワークで実現する。 各要件をに応じてネットワークを仮想的に分離して提供する（ネットワーク・スライシング）。 2020年代～ ２時間の映画を ３秒でダウンロード ロボット等の 精緻な遠隔操作を リアルタイムで実現 自宅内の約100個のモノ がネットに接続 (現行技術では数個) 現在の移動通信システムより 100倍速いブロードバンドサー ビスを提供 利用者がタイムラグを意識 することなく、リアルタイ ムに遠隔地のロボット等を 操作・制御 スマホ、PCをはじめ、身の 回りのあらゆる機器がネッ トに接続
- 286.
- 287.
- 288. 第５世代通信におけるネットワーク・スライス 288 高速・大容量データ通信 大量端末の接続 超低遅延・超高信頼性 5G ネットワーク・スライシング SIM SIM SIM 閉域網 閉域網 閉域網 SIM SIM SIM(subscriberidentity moduleもしくはsubscriber identification module/SIMカード)とは、電話番号を特定するための固有のID番号が記録された、 携帯やスマートフォンが通信するために必要なICカードのこと。
- 289.
- 290.
- 291.
- 292. これからのオフィス・インフラ 292 自宅 カフェ オフィス 仮想 データセンター （NPOやコミュニ ティ） 従来のオフィス・インフラ新しいオフィス・インフラ 外出先 5Gネットワーク 仮想 データセンター （所属する企業） SaaS/PaaSなど パーソナル・デスクトップ パーソナル ストレージ コーポレイト ストレージ クラウド・コンピューティング クラウド・コンピューティング SaaS コミュニケーション コラボレーション SaaS/PaaSなど コーポレイト ストレージ ネットワーク 機器 LAN インターネット／専用線 プログラム プログラム プログラム オフィス 通信速度：10Gbps 遅延時間：5ms 信頼性：99.999%
- 293.
- 294.
- 295.
- 296.
- 297.