Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

LiBRA 12.2018 / インフラ・ストラクチャー編

497 views

Published on

https://libra.netcommerce.co.jp/

Published in: Technology
  • Be the first to comment

  • Be the first to like this

LiBRA 12.2018 / インフラ・ストラクチャー編

  1. 1. 最新のITトレンドとビジネス戦略 インフラ&プラットフォーム編 2018年12月版
  2. 2. ご案内 2 知識の定着は、ネットを眺め、資料を読むだけでは不十分です。実際に第三者 を相手に自分の言葉で説明してみるのが最も効果的です。 また、本プレゼンテーションは、ロイヤリティ・フリーです。ご自身の資料と して、加工編集して頂いても構いません。 知識の確かな定着と仕事の生産性向上のために、ご活用下さい。 ネットコマース株式会社 斎藤昌義 http://libra.netcommerce.co.jp/ 最新のアップデートは、「ITビジネス・プレゼンテーション・ライブラリー/LiBRA」にて随時更新しております。
  3. 3. 3 モバイルとウェアラブル
  4. 4. クライアント (=PC) の誕生 メインフレーム クライアントサーバー 巨大な計算機に全てのリソースを持たせ、 全ての処理を実行する。 クライアントは文字の入力と結果の表示 をするだけのダム・ターミナル。 一定の計算能力と記憶能力を持った高 機能なクライアント (PC) が中規模の サーバーと処理を分担し、高度なUIと操 作性を実現。 クライアント≒Windows PC
  5. 5. 新しいクライアントの出現 メインフレーム クライアントサーバー クラウド IoT PC Smart Phone IoT Internet 1980 2000 2020 少 ----------- クライアント数 ---------- 多 ビジネスユーザー モノ コンシューマ
  6. 6. コレ一枚でわかるモバイルとウェアラブル PDA モバイルウエアラブル PCアプリケーション 自社ネットワーク Webブラウザー インターネット クラウド サーバー 2007年以前 2007年以降
  7. 7. パソコン 使うときに電源を入れる スマートフォンとタブレット 常に電源が入っている 移動できない 移動できる 使うときにネットワークに繋ぐ 常にネットワークに繋がっている 使うにはある程度の知識が必要 直感的に操作できる クラウドは必須では無い クラウドとの連携が前提 スマートフォンとタブレット
  8. 8. メインフレーム、クライアントサーバー、クラウド メインフレーム クライアントサーバー クラウド 巨大なサーバーに計算機能・記憶 能力の全てのリソースを持たせ、 プログラムを実行する。 クライアントは文字の入力と結果の 表示のみのダム・ターミナル。 ある程度の計算機能と記憶能力を 持った高機能なクライアント (≒Windows PC) がサーバーと処 理を分担し、高度なUIと操作性を 実現。 サーバー側のプログラムをWeb標 準技術をベースに構築 (Webアプリ /Webサービス) し、クライアントの Webブラウザからアクセスして様々 な機能をサービスとして利用。 一社独占技術 独占技術+標準技術 標準技術のみ ダム・ターミナル WindowsPC Webブラウザ
  9. 9. クライアントに与えた影響 クラウドの技術的特徴 クラウドの技術的特徴とクライアント サービス化 脱プロプライエタリ 標準化・オープン化 機能をWebサービスとして提供 特定の企業に依存しない 技術の採用 標準化による相互接続性/ 運用性の確保 大半の処理をサーバー (クラウド)側で処理 汎用クライアント (ブラウザー) の利用 オープン化の徹底による 独自技術の排除 柔軟性・スケーラビリティ の向上 使用技術は全て インターネット標準 様々なネットワークを介して クライアントと接続 PC スマホ・タブレット 1999年~ 2007年~ クライアントサーバーから クラウドへ移行 最初からクラウド対応 Windows + ブラウザー フル機能ブラウザー
  10. 10. ガラケーとiPhone ガラケー iPhone 1999~ 2007~ 日本固有の仕様 全世界共通仕様 サービスとUIの一体開発/徹底したUX キャリアが開発を主導 Appleが開発 2007年当時最も進んだ エコシステムを実現 最初は「失敗する」と 言われた 高機能な携帯電話 PCの小型化 機能制限付きブラウザ (CHTML/JavaScript) PCと同等の フル機能ブラウザー
  11. 11. クラウド・クライアントとしてのモバイルデバイス クラウド クライアント 無線通信インフ ラの高速化 クラウドによる 分散処理 アプリの サービス化 フルブラウザー のサポート デバイスの進化 (UI/センサー)
  12. 12. モバイルデバイスが変えた IT利用シーン
  13. 13. クラウド GPS(Global Positioning System) 位置情報 位置情報を使った新たなサービス 地図/ナビ タクシー配車 鉄道・バスの運行情報 SNS投稿への 位置情報付加 天気予報 Pockemon GO 渋滞情報 乗換案内 防災情報 行動履歴
  14. 14. ユーザーの爆発的増加 PC出荷台数 2億5000万台(2016年) 2億7000万台(2007年) スマートフォン出荷台数 14億5000万台(2016年) 2億9700万台(2010年) これまでインターネットとは無縁だったユーザーがクラウドにアクセスするようになった
  15. 15. ブラウザ センサー情報UGC/UGM ユーザーからの簡便な情報発信 ≑ 情報収集 SNS ブログ 位置情報画像/動画 生体情報 趣味・嗜好 思想・信条 関心事 行動 パターン 信仰・宗教 健康状態 旅行予定 移動経路 行動範囲 検索 閲覧履歴 いつでも どこからでも 即座に
  16. 16. ユーザーからの簡便な情報発信と共有 16 ビッグ・データ クラウド UGM User Generated Media SNS Social Network Service
  17. 17. ウェアラブル=身体に密着するデバイス ラスト・ワン(1)・フィートを 乗り越えることで生まれる 新しい可能性 1フィート (30cm) モバイル 2フィート (60cm) デスクトップ 0 (ゼロ) フィート ウエアラブル
  18. 18. ウェアラブルデバイスの進化 18 モバイル通信ネットワークの進化 HW技術の進化 (小型化・高機能化・省電力化) センサー技術の進化 クラウドの進化 (バックエンド処理) 入力方法の進化 (音声認識、タッチスクリーン) スマートフォンの普及 (通信中継デバイスとして)
  19. 19. 眼鏡 腕時計 指輪 ベルト 靴 帽子 衣服 コンタクトレンズ パーソナルアシスタンス 【画像】 メール・メッセージ 動画・静止画・地図 設計図・マニュアル 【音声】 通話・音楽 【振動】 通知・ナビ ・・・ ウェアラブル・デバイスの種類と使われ方 医療・健康 【生体情報】 血圧・心拍・体温・脳 波・呼吸・睡眠状態・疲 労度・血糖値・会話量・ 活動量・紫外線量など 身体密着 常時携帯 常時接続
  20. 20. 加速度センサ 温度センサ GPS ジャイロセンサ 照度センサ 地磁気センサ圧力センサ 近接センサ 回転センサ 脳波センサ 近接センサ GPS 眼球運動センサ 加速度センサ 回転センサ心拍センサ 発汗センサ 体温センサ モバイル デバイス ウェアラブル デバイス インターネット ビッグ・データ アナリティクス 洞察、知見、ノウハウの発見・抽出 モバイル・ウェアラブルとクラウドとの関係 クラウド 近接通信 BluetoothやNFCなど モバイル通信 携帯電話網やWiFiなど
  21. 21. AI アンビエント・コンピューティング これからのクライアントを占うキーワード ウェアラブル/VR/AR/MR 音声認識/合成デバイス ビーコン/RFID/各種センサー (IoT) クラウド スマートフォン 5G/LPWA
  22. 22. ユビキタスからアンビエントへ ユビキタス アンビエント ケータイ スマホ テレビ スマホ/音声認識デバイス M2M IoT 様々なモノがシステムに接続 され、人間からそれらに働き かけ、情報を得る システムが人間を見えない 形で取り巻き、必要に応じて 情報を提供 2G/電灯線ネットワーク 4G/5G/WiFi/光 クラウド無し クラウド前提 電話 ゲートウェイ 機械間通信 特徴 ネットワーク クラウド
  23. 23. 接続 デバイス ノートパソコン PDA 電子手帳 第1世代 スマートフォン 入力 パソコンとの連携 メール・Web 有線 通信カード(低速) 有線 通信カード(低速) 携帯電話回線 (低速) キーボード 手書き文字認識 キーボード キーボード テンキー 可能 スケジュールなど 不可 可能 限定的 非常に限定的 携帯性 △ ○ ◎ モバイル・デバイスの歴史
  24. 24. 良い点 当時の日本の携帯電話 当時の海外の携帯電話 全世界で端末仕様を統一サービスと端末の一体開発 高品質なサービス 多彩な機能 悪い点 プレイヤーが多く一貫した サービスを提供できない 行き過ぎた高機能化 日本でしか通用しない 高コスト体質 iPhone 全世界で端末仕様を統一 サービスと端末の一体開発 高品質なサービス 多彩な機能 高品質なサービスの欠如 iPhoneの成功とその理由 当時世界の先端を走っていた 日本のモデルをうまく取り入れ、 世界規模に展開することでコ ストダウンとアプリ開発者の取 込みに成功。 低コスト 低コスト 機能限定
  25. 25. クラウドとモバイルの関係 Windows 自社ネットワーク Webブラウザー インターネット クラウド サーバー クライアント・サーバー クラウド
  26. 26. クライアントの変遷 Windows クライアント サーバー Webシステム リッチ・インターネット クライアント(RIC) ブラウザー ブラウザー + プラグイン サーバー Webサーバー サーバー Webサーバー サーバー 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 管理コストの増大 ベンダーロックイン ブラウザの機能不足 マルチプラットフォーム対応 プラグインによる ブラウザの機能強化 マルチプラットフォーム対応 テキスト端末 集中処理システム メインフレーム (他にもオフコン/ミニコン) テキスト 表示 テキスト 表示 テキスト 表示 業務個別 プログラム 業務個別 プログラム 業務個別 プログラム 文字だけの表示・低い表現力 ベンダーロックイン
  27. 27. PC/AT Mac Windows Linux MacOS クライアント毎に専用のプログラム (ネイティブアプリ) を用意する必要があり、開発効率が良くない クライアント・プラットフォームの変遷 PC/AT Mac Windows Linux MacOS RIA/Ajax ひとつのプログラムコードで全てのプラットフォームに対応、コストを最少化して売上を最大化できる
  28. 28. 1990年 2000年 クライアントの機能 端末 クライアント/サーバーメインフレーム RIC/RIAとクラウド クライアント ブラウザ Flashなどの プラグイン Ajax Webシステム Ajaxの登場
  29. 29. Ajax (エイジャックス) とは 非同期の JavaScript サーバーからダウンロードされ ブラウザ上で実行される スクリプト言語 eXtensible Markup Language ユーザー独自の拡張が可能なマー クアップ言語 Asynchronous JavaScript + XML = Ajax Flashなどのプラグインを使わず、 Web ブラウザ単独で、PCにインストールされた アプリケーション並みの操作性を実現
  30. 30. 昔の地図サイト 昔の地図 サービス
  31. 31. Ajax を使った地図サイト
  32. 32. Ajax の意義 標準のWeb ブラウザで 独立アプリ並みの操作 性を実現できる クライアントアプリやプラグイン無し で高度な対話型の システムを構築可能 クラウド コンピューティング Webシステム/Webアプリ/WebサービスのUI を劇的に改善 クラウドのクライアントとしての Web ブラウザーの重要性が増大
  33. 33. Mozilla Firefox Apple Safari Google Chrome Opera Software OPERA Microsoft Internet Explorer JavaScript実行速度の向上 Ajaxの操作性と快適さを向上 ブラウザーの進化とAjax
  34. 34. クラウドとモバイルが変えたこととは ハード ウェア ハード ウェア ハード ウェア OS OS OS ミドル ミドル ミドル アプリ アプリ アプリ PC/AT ハード ウェア Windows OS ミドル ミドル ミドル アプリ アプリ アプリ ハード ウェア ハード ウェア ハード ウェア OS OS OS ミドル ミドル ミドル W e b ア プ リ ハード ウェア ハード ウェア ハード ウェア OS OS OS ミドル ミドル ミドル W e b 技 術 W e b ブ ラ ウ ザ サーバー クライアント Webプロトコル クラウド クライアント ベンダー独自技術を隠蔽し、標準技術でI/Fを実現
  35. 35. Google が狙うもの 「新しいコンピューティング・サービスは、どこかの雲の中 にあるサーバーから始まる。PC、Mac、携帯電話など、 どのようなデバイスからでも適切なアクセス手段があれ ば利用できる。」 Google CEO エリック・シュミット 2006年8月のスピーチ 適切なアクセス手段 Web ブラウザー 2008年、Google Chrome を発表 2009年、Chrome OSを発表 マルチプラットフォーム対応 最速の JavaScript 実行速度 クライアントを標準化し インターネットの利用を加速させる 無 料 広告収入
  36. 36. HTML5
  37. 37. 1990年 2000年 クライアントの機能 端末 クライアント/サーバーメインフレーム RIC/RIAとクラウド クライアント ブラウザ Flashなどの プラグイン Ajax Webシステム Ajaxの登場
  38. 38. HTML5(1) 38 ウェブサーバー ブラウザー ウェブサーバー ブラウザー 通 信 プ ロ ト コ ル 通 信 プ ロ ト コ ル HTML4 文字や写真のような 動きのない情報を対象 HTML5 動画や音声など 次代に即した情報を対象 現状に即した 大幅な改訂 ウェブ プラグイン・ソフト ウェア Flash、Silverlightなど もはや限界! 1997年〜 2014〜
  39. 39. HTML5(2) 39 狭義のHTML5 ウェブの標準化団体W3C が規格を策定した 次世代のマークアップ言語 通信 プロトコル デバイス 連携 オフライン ストレージ 3D グラフィックス 広義のHTML5 次世代アプリケーション・プラットフォーム
  40. 40. HTMLの歴史と現状 HTML 1.0 (1993年) HTML 2.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. 41. HTML5 (+Ajax)でできるようになること ブラウザ間の互換性・相互運用性の確保 Webアプリケーションの開発を容易にするための新機能や 新しい要素を追加 (クラウド対応) フォームの拡張 ドラッグ&ドロップ クライアントサイドストレージ オフラインキャッシュ (オフラインWebアプリケーション) ベクターグラフィックス 3次元グラフィックス オーディオ・ビデオ 位置情報 これまでプラグインなどを必要としていた処理が HTML5+Ajaxで実現できる
  42. 42. PC PCでなければできないこと 縮小 モバイル +ウェアラブル モバイル モバイルでなければできないこと 増加 どこでもいつでも位置情報・センサー PC モバイル・デバイスの利用 を前提とした設計 モバイルファースト モバイルシフト モバイルファースト・モバイルシフトの波
  43. 43. これからのクライアント プラットフォーム
  44. 44. HTML5 ネイティブ 開発コスト ○ △ マルチプラットフォーム対応 ◎ × UX/UI △ ◎ 機能・速度 △ ◎ アプリ配信の容易さ ◎ ○ 収益化 △ ○ ユーザーの囲い込み × ◎ Web(HTML5)アプリとネイティブ(各社独自)アプリ HTML5の進化により今後改 善されていく可能性がある
  45. 45. Windows Phone Xbox OS ?Windows WindowsRT Windows Kernel Windows10 Mac OS iOS Macintosh iPhone/iPad AppleTV AppleTV Software (iOS) Smart Phone Xbox TVPC ARM Tablet Chrome Windows/Mac/Linux Android Chromebook MacOSアプリ iOSアプリ TVアプリ Windowsアプリ RTアプリ WPアプリ Webサービス (HTML5) ユニバーサルWindowsアプリ 各社が目指すクライアントプラットフォーム Continuity プラットフォーム毎の ネイティブアプリ データとUXを共有 Windowsプラットフォー ム共通の ネイティブアプリ Web (HTML5) アプリ
  46. 46. Windows Phone Xbox OS ?Windows WindowsRT Windows Kernel Windows10 Mac OS iOS Macintosh iPhone/iPad AppleTV AppleTV Software (iOS) Smart Phone Xbox TV Continuity PC ARM Tablet Chrome Windows/Mac/Linux Android Chromebook Webサービス (HTML5) ユニバーサルWindowsアプリ 各社が目指すクライアントプラットフォーム Webサービスなら、Webブ ラウザさえあればあらゆる デバイスに対応可能 MacOSアプリ iOSアプリ TVアプリ Windowsアプリ RTアプリ WPアプリ
  47. 47. Google が狙うもの 「新しいコンピューティング・サービスは、どこかの雲の中 にあるサーバーから始まる。PC、Mac、携帯電話など、 どのようなデバイスからでも適切なアクセス手段があれ ば利用できる。」 Google CEO エリック・シュミット 2006年8月のスピーチ 適切なアクセス手段 Web ブラウザー 2008年、Google Chrome を発表 2009年、Chrome OSを発表 マルチプラットフォーム対応 最速の JavaScript 実行速度 クライアントを標準化し インターネットの利用を加速させる 無 料 広告収入
  48. 48. 「デバイスとサービスの会社を目指す」 →ソフト会社のままではApple/Googleと闘えない 2008 Yahoo!買収提案 2009 Yahoo!と提携 2011 WindowsのARMサポートを発表 2012 Windows8, RT, Surface出荷開始 2013 組織改革, バルマーの引退発表 2010 Azureサービス開始 2013 Nokiaの携帯事業を買収 2014 新CEOにサティア・ナデラを指名 「プロダクティビティソリューション」と「プラットフォーム」の2つが マイクロソフトの新たなコア (2014.10)
  49. 49. Microsoftの新戦略 Microsoft技術のオープンソース化 (.Net, VisualStudio) Active Directory クラウドへのシフト ハードウェア事業の強化 (Surface, Xbox, Mobile) Windowsの無償化 (小型デバイス, Win10アップグレード) Microsoftの強みを生かしたクラウドサービス Office (Office365, マルチデバイス対応) ビジネスモデル 新たな差別化 ポイント オープン化 AzureでのOSSサポート (Linux, Hadoop, Docker) Linuxとの歴史的和解 Windows サーバーからモバイル/ゲームまでを統合
  50. 50. Win32アプリが動くARM版Windows10を発表 (2016.12) Intel Windows Windows アプリ Windows アプリ Windows アプリ ARM WindowsRT Windows アプリ Windows RTアプリ Windows RTアプリ ARM ARM版Windows10 Windows アプリ Windows アプリ Windows RTアプリ Intelエミュレータ Qualcommと共同でARMベースのPC/サーバーを開発
  51. 51. 補足資料
  52. 52. Microsoft Edge 52 Internet Explorer Microsoft Edge MSHTML HTML5 ActiveX/VBscript 高速化 独自仕様からWeb標準へ
  53. 53. ブラウザの系譜 1990年 2000年 Mosaic KHTML/KJS Gecko Firefox Tizen Blackberry Palm Adobe AIR Chrome Android Safari Webkit (Apple) Internet Explorer NetScape Trident
  54. 54. BlinkがWebkitから、EdgeがTridentからフォーク 1990年 2000年 Mosaic KHTML/KJS Gecko Firefox Tizen Blackberry Palm Adobe AIR Chrome Android Safari Webkit (Apple) Internet Explorer NetScape Trident Blink (Google) Edge
  55. 55. 55 ITインフラと仮想化
  56. 56. 仮想化とは
  57. 57. 仮想 virtual 表面または名目上はそうでないが 実質的には本物と同じ 本来の意味 「仮想化」の本当の意味 本来の意味 仮想化 Virtualization 実質的には本物と同じ ことをできるようにする仕組み 日本語での語感 虚像の〜 実態のない〜 It was a virtual promise. (約束ではないが)実際には約束も同然だった。 He was the virtual leader of the movement. 彼はその運動の事実上の指導者だった。
  58. 58. 仮想化とは何か 58 コンピュータのハードやソフト 物理的実態 実質的機能 自分専用の コンピュータ・システム 周りの風景や建造物と 重ね合わされた情報 3Dで描かれた地図や 障害物や建物の情報 仮想マシン/仮想システム 仮想現実 仮想3Dマップ 仮 想 化 を 実 現 す る ソ フ ト ウ エ ア
  59. 59. 物理資源・物理機械 サーバーの仮想化 ストレージの仮想化 Java仮想マシン データベースの仮想化 パーティショニング 分 割 アグリゲーション 集 約 エミュレーション 模 倣 仮想化 (Virtualization) ひとつの物理資源を 複数の仮想資源に分割 複数の物理資源を ひとつの仮想資源に分割 ある物理資源を 異なる資源に見せかける 仮想化の3つのタイプ
  60. 60. 「インフラのソフトウエア化」の意味・仮想化の役割 物理的実態(バードウェアや設備)と実質的機能(仮想化されたシステム)を分離 物理的な設置・据え付け作業を必要とせず、ソフトウエアの 設定だけで、必要とするシステム構成を調達・変更できる。 ユーザーは柔軟性とスピードを手に入れる 標準化されたハードウェアやソフトウエアを大量に調達 してシステムを構成し、運用を自動化・一元化する。 運用管理者はコスト・パフォーマンスを手に入れる *「抽象化」とは対象から本 質的に重要な要素だけを抜き 出して、他は無視すること。
  61. 61. 仮想化の役割 61 必要とされるシステム(機能)構成A 必要とされるシステム(機能)構成B 必要とされるシステム(機能)構成C 分割 集約 模倣 仮想化 実質的機能 使用目的に応じて必 要とされるシステム を調達・構成する。 物理的な設置・据え付 け作業を必要とせず、 ソフトウエアの設定だ けで、必要とするシス テム構成を調達・変更で きる。 柔軟性とスピード 演算 データ管理 ネットワーキング サーバー ストレージ システム資源 ネットワーク機器 物理的実態  ハードウェア  プラットフォーム  設備 標準化されたハード ウェアやソフトウエア を大量に調達してシス テムを構成し、運用を 自動化・一元化する。 コスト・パフォーマンス 物理時実態から 実質的な機能や 性能を取り出す
  62. 62. 仮想化の役割 62 必要とされるシステム(機能)構成A 必要とされるシステム(機能)構成B 必要とされるシステム(機能)構成C 仮想化物理時実態から 実質的な機能や 性能を取り出す 実質的機能 使用目的に応じて必 要とされるシステム を調達・構成する。 物理的な設置・据え付 け作業を必要とせず、 ソフトウエアの設定だ けで、必要とするシス テム構成を調達・変更で きる。 柔軟性とスピード サーバー ストレージ システム資源 ネットワーク機器 物理的実態  ハードウェア  プラットフォーム  設備 標準化されたハード ウェアやソフトウエア を大量に調達してシス テムを構成し、運用を 自動化・一元化する。 コスト・パフォーマンス 物理的実態の持つ機能や性能を抽象化*し それらの組合せや変更などの操作を物理的実態から分離して 操作の自由度を高め柔軟性とスピードを向上させる *「抽象化」とは、対象か ら本質的に重要な要素だけ を抜き出して、他は無視す ること。
  63. 63. タイムシェア(Time Share) モニター(Monitor) “見かけ上” 同時使用できる 仮想化の誕生(1) コンピューターを共同利用する技術 高価なコンピューター(物理資源) バッチ(Batch) 前の処理が終わるまで 待たなくてはならない
  64. 64. タイムシェア(Time Share) モニター(Monitor) “見かけ上” 同時使用できる コンピューター(物理資源) 個別の資源 個別の資源 個別の資源 個別のOS 個別のOS 個別のOS “見かけ上” 別々の資源として 使用できる 仮想化の誕生(2) コンピューターを共同利用する技術 仮想化ソフトウェア ハイパーバイザ (hypervisor)
  65. 65. 仮想化の歴史 HW HW HW 分 散 ~1964 HW HW HW OS OS OS AP AP AP 分 散 1980年代~ 安価なハード 運用負担の増大 TCOの増大 高価なハード 運用負担の増大 コストの増大 AP: Application / OS: Operating System / VM: Virtual Machine / HV: Hypervisor / HW: Hardware HW OS AP AP AP 集 中 1964~ 高価なハード 資源の制約・競合 障害時の影響拡大 IBM S/360 HW HV OS OS OS AP AP AP VM VM VM 分割を目的とした 集 中 1967~ 高価なハード 自由度の制約 コストの増大 S/360 CP-40/67 HW HV OS OS OS AP AP AP VM VM VM 集約を目的とした 集 中 1999~ ハードの高性能化 管理対象の増大 インフラ負担の増大 VMware OS AP 専用 SW OS AP 専用 SW OS AP 専用 SW
  66. 66. 利用形態の歴史的変遷 66 OS OS AP AP AP AP AP AP 3 2 1 OS AP AP AP OS OS VM VM VMOS AP AP AP OS OS OS AP AP AP OS OS VM VM VM OS AP 設定 AP 設定 AP 設定 コンテナ コンテナ コンテナ 1950年代~/バッチ 1960年代~/タイムシェアリング 1970年代~/仮想化(仮想マシン) 1980年代~/分散化 2000年代~/仮想化(仮想マシン) 2015~/コンテナ メインフレーム メインフレーム ミニコン メインフレーム ミニコン ミニコン PCサーバー PCサーバー クラウド (IaaS) PCサーバー クラウド (PaaS)
  67. 67. 仮想化からSDIへ
  68. 68. SDI(Software-Defined Infrastructure) 68 ビジネス・スピードの加速 アプリケーション開発・変更への迅速な対応 eXtreme Programing,Scrum,Test Driven Development など 本番環境への迅速な移行・継続的デリバリー Chef,Jenkis,Hashicorp など インフラ環境の迅速な調達・構築・変更 OpenStack,vCloud Air,Azure Stack など アジャイル開発 Agile Development DevOps Development/Operation SDI Software Defined Infrastructure
  69. 69. SDI(Software-Defined Infrastructure) 69 WAN高速化装置 ファイヤウォールスイッチ ロードバランサ ルーター SDI(Software Defined Infrastructure) 仮想化 物理的なシステム資源 システム構成や構築には設置や接続などの物理的な作業が必要 ソフトウェアによる操作や設定でシステム構成や構築を実現する ソフトウェアによる操作や設定でシステム構成や構築を実現する  物理的な構成や機能を理解し、そこから「仮想的=実質的」にシス テムを構成して必要な性能や機能を調達する。  物理的な構成や機能を理解していなくても、「ポリシー=目標値・ 制約事項」を設定すれば必要な性能や機能を調達する。 物理的システムイメージ 利用目的・利用イメージ
  70. 70. SDI(Software-Defined Infrastructure) 70 WAN高速化装置 ファイヤウォールスイッチ ロードバランサ ルーター 組織・企業 組織・企業 組織・企業 ポリシーで機能や性能を管理 処理能力、対障害性能、セキュリティなど SDI(Software Defined Infrastructure) 「抽象化」とは、思考に おける手法のひとつで、 対象から注目すべき要素 を重点的に抜き出して他 は無視する方法である。 仮想化されたシステム資源 物理的なシステム資源 システム資源 機能や性能 抽象化 抽象化 仮装化されたシステム資源で構 成や運用を管理 物理的なシステム資源で構成や 運用を管理
  71. 71. 物理的なシステム資源を個別に構築 SDI(Software-Defined Infrastructure)/物理システム 71 組織・企業 組織・企業 組織・企業 組織・企業 ユーザーの要望に応じて物理資源を個別に調達・構成 運用管理者が個別にシステム資源を構成・調達
  72. 72. DMZ FWスイッチ 負荷分散装置 ルーターネットワーク仮想化 サーバー仮想化 ストレージ仮想化 SDI(Software-Defined Infrastructure)/仮想システム 72 組織・企業 組織・企業 組織・企業 組織・企業 仮想化されたシステム資源から、ユーザーの要望に応じて運用管理者が個別に構成・調達 運用管理者が個別にシステム資源を構成・調達 物理的なシステム資源をプール(リソース・プール)
  73. 73. SDI(Software-Defined Infrastructure) 73 DMZ FWスイッチ 負荷分散装置 ルーター 物理的なシステム資源をプール(リソース・プール) 組織・企業 組織・企業 組織・企業 組織・企業 仮想化されたシステム資源から、ユーザーの要望に応じて自動で構成・調達 ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ ポリシー • 処理能力 • 対障害性能 • セキュリティ SDIを構築し運用するソフトウエア プロビジョニング Provisioning ネットワーク仮想化 サーバー仮想化 ストレージ仮想化
  74. 74. 仮想化されたシステムの構成 74 物理システム  製品ベースでの調達・運用  物理性能・物理構成・物理作業 仮想システム  実質ベースでの調達・運用  実質性能・実質構成・ソフトウェア設定 サーバー ストレージ ネットワーク メモリ容量 CPU性能 ディスク容量 ネットワーク機能 ネットワーク接続 仮想サーバー 仮想ストレージ 仮想ネットワーク オーケストレーション  ポリシーベースでの調達・運用  規則・条件・基準による設定 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 01 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 02 ポリシー • 処理能力 • 対障害性能 • セキュリティ システム構成 03 コントロール  パターンやルール・ベースでの運用管理・調達管理  構成管理・稼働管理・問題解決 監視 自動/自律制御 制 御
  75. 75. 運 用 の 自 動 化 仮想マシン、ミド ルウェア、アプリ ケーションの稼働 状況を監視し、運 用パターンに沿っ て設定を調整する 監 視 監 視 コントローラー セルフ・サービス ポータル 仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者運用パターン 調 達 の 自 動 化 APIを介し、コン トローラーやセル フポータルの操作 に従って、プロビ ジョニングを行う  ハード・ソフト構成の管理  システムの稼働監視  アラートから異常の兆候を検知  異常の原因を解析  解決策の選定  解決策適用による影響範囲を確認  設定の変更やリソースの追加で対応 運用 パターン SDI(Software-Defined Infrastructure)/全体の仕組み プロビジョニング 仮想化ソフト 仮想化ソフト 仮想化ソフト 仮 想 化 物理リソースを管 理し、ソフトウェ アによる定義に 従って仮想リソー スを提供する リソース プール オーケストレーター 操作 操作 操作 API
  76. 76. 監 視 監 視 コントローラー セルフ・サービス ポータル仮想リソース ミドルウェア アプリケーション 操作 操作 運用管理者運用パターン プロビジョニング 仮想化ソフト 仮想化ソフト 仮想化ソフト リソース プール オーケストレーター 操作 操作 操作 API 運 用 の 自 動 化 調 達 の 自 動 化 SDI(Software-Defined Infrastructure)/SDIとIaaS 仮 想 化 IaaS PaaS
  77. 77. Infrastructure as a Code
  78. 78. Infrastructure as Code 仮想サーバー 物理サーバー 仮想ストレージ 物理ストレージ 仮想ネットワーク 物理ネットワーク 使用するシステム構成 リソース・プール(物理リソース)プログラムによる定義 Infrastructure as Code 全てのシステム構成をソフトウェアで定義できる インフラの構築や運用管理での属人化による「暗黙知」をなくし ノウハウの蓄積や自動化を容易にする
  79. 79. Infrastructure as Code 業務処理ロジックの プログラミング 日本語などの自然言語で 運用手順書の作成 人手による 運用管理 日本語などの自然言語で システム構成図作成 人手による システム構築 従来の手順  属人化による「暗黙知」化  人手の介在によるミスやスピードの制約 業務処理ロジックの プログラミング 運用手順の プログラミング システム構成の プログラミング 運用管理の 自動化 システム構成 の自動化 これからの手順  全手順のコード化によるノウハウの継承  開発~本番の高速化と変更の俊敏性
  80. 80. Infrastructure as Code 開発・運用・構築の関係や役割が大きく変わる Infrastructure as Code 人間が作業に関与することに比べ 運用・構築の高速化 + ヒューマン・エラーの排除 + 人的作業負担の消滅 稼働中のサーバー停止や新規サーバー稼働 を同時に行う事ができる 開発・テストと本番で全く同じ環境が使える 稼働中のサービスを停止することなく 設定や構成の変更ができる 開発・テスト環境から本番環境へ 自動的に移行できる Immutable Infrastructure、DevOps、Agile Development…
  81. 81. Infrastructure as Codeの特徴(1) 81 環境構築手順書 ① 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-  手作業で作業ミスが心配  変更を繰り返すと管理が大変  実際の環境と履歴が一致しない  対象が増えると管理しきれない  設定に手間がかかる  テスト・確認が複雑
  82. 82. Infrastructure as Codeの特徴(2) 82 変更履歴 ① XXXXXXXXX ② XXXXXXXXX ③ XXXXXXXXX ・・・ クラウド個別システム × × システム資源が物理的に固定さ れるので、インフラ構築はその 制約の下で行われる。 物理サーバーを構成変更しなが ら使い続ける。 システム資源が仮想化されるの で、インフラ構築に物理的な制 約をうけることはない。 仮想サーバーの追加・破棄を頻 繁に繰り返すことができる。 変更履歴を管理 動作している状態を管理 構成は不変 Imutable Infrastructure構成は変化し続ける
  83. 83. Infrastructure as Codeを実現するソフトウェア 83 仮想マシン 仮想マシン 仮想マシン Orchestration: 複数サーバーの管理を自動化 Configuration: OSやミドルウェアの設定を自動化 Bootstrapping: OSの起動を自動化 OS OS OS Virturization: 仮想マシンの構築・起動 ミドルウェア アプリケーション OSや仮想化ソフトウェアのインストール/設定作業を自動化 データベースサーバ/Webサーバ/監視エージェントなどのミドル ウエアのインストールやバージョン管理、OSやミドルウエアの設定 ファイルや、OSのファイアウォール機能などの設定などを自動化 複数台のサーバ群を監視し、新しいサーバをシステムに登録したり、 障害のノードをシステムから取り除いたり、サーバへのアプリケー ションのデプロイをサポート KickStart
  84. 84. 仮想化の種類
  85. 85. 仮想化の種類(システム資源の構成要素から考える) 仮想化 サーバーの仮想化 クライアントの仮想化 ストレージの仮想化 ネットワークの仮想化 デスクトップの仮想化 アプリケーションの仮想化 仮想LAN(VLAN) SDN(Software-Defined Networking) ブロック・レベルの仮想化 ファイル・レベルの仮想化 画面転送方式 ストリーミング方式 アプリケーション方式 ストリーミング方式 ハイパーバイザー方式 コンテナ方式/OSの仮想化 仮想PC方式 ブレードPC方式
  86. 86. サーバー仮想化 86 OS サーバー (ハードウェア) ミドルウェア アプリ OS ミドルウェア アプリ OS ミドルウェア アプリ OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ CPU メモリ CPU メモリ CPU メモリ CPU メモリ サーバー (ハードウェア) サーバー (ハードウェア) CPU メモリ CPU メモリ CPU メモリ 物理システム 仮想システム
  87. 87. サーバー仮想化とコンテナ 87 OS ハードウェア ハイパーバイザー 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ OS 仮想サーバー ミドルウェア アプリ サーバー仮想化 ハードウェア コンテナ管理ソフトウエア OS ミドルウェア アプリ ミドルウェア アプリ ミドルウェア アプリ コンテナ コンテナ コンテナ コンテナ ライブラリ 環境変数 ライブラリ 環境変数 カーネル カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 隔離されたアプリケーション実行環境を提供する 実行イメージのスナップショットをパッケージとしてファイルにして保存できる アプリケーションに加えて仮想マシン・OS の実行イメージを持つ必要がある アプリケーションとOSの一部 の実行イメージを持つ必要がある デプロイするサイズ 大きい 起動・停止時間 遅い デプロイするサイズ 小さい 起動・停止時間 早い 異なるOS 可 異なるOS 不可 メモリーやディスクの消費量が大きい = リソース効率が悪い メモリーやディスクの消費量が大きい = リソース効率が良い 構成の自由度が高い 異なるOS・マシン構成を必要とする場合など 軽量で可搬性が高い 実行環境への依存が少なく異なる実行環境で稼働させる場合など
  88. 88. 仮想マシンとコンテナの稼働効率 88 ハードウェア 仮想マシン ミドルウェア アプリケーション OS 仮想マシン OS 仮想マシン OS ミドルウェア アプリケーション ミドルウェア アプリケーション ハードウェア OS コンテナ管理機能 カーネル ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ ミドルウェア アプリ ライブラリ 環境変数 コンテナ カーネル カーネル カーネル ライブラリ 環境変数 ライブラリ 環境変数 ライブラリ 環境変数 コンテナ仮想マシン
  89. 89. デスクトップ仮想化とアプリケーション仮想化 89 ネットワーク 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 メモリーストレージ ハイパーバイザー PC用OS (Windows7など) プロセッサー 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 クライアントPC 文書作成 画面表示 仮想PC サーバー PC用OS (Windows7など) 文書 作成 表 計算 プレ ゼン ・・・ 仮想PC メモリーストレージ OS プロセッサー サーバー ターミナル・モニター 文書 作成 表 計算 プレゼン ・・・ 入出力操作 通信 クライアントPC 文書作成 表計算 プレゼン ・・・ デスクトップ画面 入出力操作 通信 クライアントPC 文書作成 画面表示 デスクトップ仮想化 アプリケーション仮想化
  90. 90. シンクライアント 90 ネットワーク 入出力操作 通信 シンクライアント 文書作成 表計算 プレゼン ・・・ 画面表示 メモリーストレージ ハイパーバイザー PC用OS (Windows7など) プロセッサー PC用OS (Windows7など) PC用OS (Windows7など) 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 文書 作成 表 計算 プレ ゼン ・・・ 入出力操作 通信 シンクライアント 文書作成 表計算 プレゼン ・・・ 画面表示 仮想PC 仮想PC 仮想PC サーバー ストレージ 文書作成 表計算 プレゼン ・・・ 入出力操作 通信 アプリケーション PC / Windows・Mac OS など 画面表示 データとプログラムの保管 プログラムの実行 は、PC内にて処理 データとプログラムの保管 プログラムの実行 は、サーバー内にて処理 シンクライアントは 画面表示と入出力操作
  91. 91. Chromebook 91 インターネット データ 文書作成 表計算 プレゼン ・・・ ブラウザ 画面表示・入出力操作 通信 画面表示・入出力操作 通信 オフィス・アプリ データ 文書作成 表計算 プレゼン ・・・ オフィス・アプリ クラウドサービス Google Apps for workなど ブラウザ 文書作成 表計算 プレゼン ・・・ PC / Windows・Mac OS など Chromebook / Chrome OS
  92. 92. クライアント仮想化 92 クライアントの仮想化 (アプリケーション方式) 仮想化 ソフトウェア ハードウェア クライアントPC オペレーティング・システム (ホストOS) アプリケーション OS (ゲストOS) アプリケーション クライアントの仮想化 (ハイパーバイザー方式) 仮想化ソフトウェア (ハイパーバイザー) ハードウェア クライアントPC アプリケーション OS アプリケーション OS 仮想マシン仮想マシン仮想マシン CPU メモリ CPU メモリ
  93. 93. ストレージ仮想化 ストレージの業界団体であるSNIA(Storage Network Industry Association) による 「ストレージ仮想化技術の分類」  Disk Virtualization (ディスクの仮想化)  Block Virtualization (ブロックの仮想化)  File System Virtualization (ファイル・システムの仮想化)  File Virtualization (ファイルの仮想化)  Tape Virtualization(テープの仮想化)
  94. 94. ストレージ仮想化 2TB 実データ 3TB 実データ 5TB 実データ 10TB 10TB 10TB 仮想ストレージ ブロック仮想化 10TB 実データ 30TB ストレージ(ハードウェア) 8TB 7TB 5TB 未使用領域 20TB ボリュームの仮想化 10TB 10TB 10TB 仮想ストレージ シンプロビジョニング 10TB 実データ 30TB ストレージ(ハードウェア) 容量の仮想化 未使用領域 0TB 必要な時に 追加 2TB 実データ 3TB 実データ 5TB 実データ 8TB 7TB 5TB 仮想ストレージ 重複排除 ストレージ(ハードウェア) データ容量の削減 D A B C E F A B ファイル 2 ファイル1 D A B C E F重複データ を排除
  95. 95. SDNとNFV QoS・セキュリティ 機 能 制 御 パケットの種類に応じて設定 物理構成に依存 機器ごとに個別・手動制御 物理 ネットワーク A 物理 ネットワーク B 物理 ネットワーク C 従来のネットワーク アプリケーションに応じて設定 物理構成に関係なく、ソフトウエア設定で機能を構成 機器全体を集中制御・アプリケーション経由で制御可能 仮想化 仮想 ネットワーク A 仮想 ネットワーク B 仮想 ネットワーク C 物理 ネットワーク 集中制御 SDN(Software Defined Networking)
  96. 96. SD-WAN(Software-Defined Wide Area Network) 96 IP-VPN インターネットVPN (IPsec VPN) 4G LTE専用回線 ソフトウェアによって統合・一括管理された仮想的なWAN 負荷分散、セキュリティ管理、アプリケーションによるネットワークの振り分けなど 一括管理  コントロール  オーケストレーション SD-WANソリューション 拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN 拠点LAN エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末 エッジ端末 GUI
  97. 97. ネットワークに求められる要件 97 定義項目 要件 オンデマンドセルフサービス オンデマンドかつセルフサービスで利用開始、条件変更、利用停止が可能。 多種多様な回線およびデバイスをサポート 種々のアクセス回線やネットワークサービス、種々のデバイス(IoT 含 む)により利用可能。 リソースプール ネットワークがリソースプール化されている。世界中にPOP(接続拠点) や制御拠点を有し、可用性、利用帯域などのネットワーク特性がPOPの場 所に依存しない。 オートスケール 自動的にネットワーク帯域のスケールアウト/スケールインができる。 サービス利用状況の計測/レポート サービス利用状況(サービス品質保証、帯域、遅延値、利用率、セキュリ ティ状況など)を自動的に測定し、レポートで提供。 プログラム可能なインフラ 企業ネットワーク構築/運用/保守のためのAPIを提供し、外部システム からプログラム制御できる。 従量課金 リソース(サービス品質保証、ネットワーク帯域など)の利用量に応じた 課金。 ITR説明資料 http://techtarget.itmedia.co.jp/tt/news/1811/12/news05.html?fbclid=IwAR07tuvcHBxtl9eUw_6kw8g929l47Rm2rLF2LxPyFX_VV5M9VFaI2FPhx8I
  98. 98. サーバーの仮想化 そのメリットと課題
  99. 99. サーバー仮想化による3つのメリット 99 仮想マシン Virtual Machine 物理マシンの集約  機械購入費用の抑制  電気代・CO2の削減  データセンター使用料の削減 ソフトウェア定義  調達・変更の迅速化  稼働中での構成変更  迅速で柔軟な構成変更 設定 障害時に正常に稼働して物理マシンに 仮想マシンを移動させサービスを継続 複雑なクラスタリング構成と 対応のためのソフトウエア ライブマイグレーション  保守時のサービス停止回避  障害時のサービス停止回避  物理マシンの負荷の分散
  100. 100. サーバーの仮想化/物理的資源の削減 CPU 使用率 サーバー 集約 スペース活用の効率化 設置スペースが削減され、土地や建物 に関わるコストを削減できる 消費電力の削減 サーバーの冷却に必要な空調装置、 サーバー本体の電力消費・CO2を削減 できる サーバーの稼働率向上 購入するサーバー台数を、減らすことが できる 物理的資源の削減
  101. 101. サーバー仮想化が変えたサーバー利用の常識(1) 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. サーバー仮想化が変えたサーバー利用の常識(2) 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 障害時 正常時 仮想サーバーAとBは、 見かけ上稼働し続けることができ ユーザーは影響を受けない
  103. 103. サーバーの仮想化 / BCP対策・仮想マシン・レプリケーション VM A VM B 物理 マシン 仮想化ソフトウェア データ AP AP 仮想マシン・イメージ のレプリケーション データの レプリケーション ネットワーク VM A VM B 物理 マシン 仮想化ソフトウェア データ AP AP クラウド基盤へのレプリケーション VM A VM B 物理 マシン 仮想化ソフトウェア データ AP AP 個別基盤へのレプリケーション
  104. 104. サーバーの仮想化/課題 サーバー サーバー ネットワーク 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン 仮想 マシン ストレージ サーバー・スプロール 未使用の仮想マシンの乱立。管理の複雑化とシステム資源の圧迫。運用ルール、管理方法 により対応。 ストレージ設計 ライブマイグレーション、ストレージ共有、ランダムアクセ スの増大によりI/0ボトルネックが発生しやすくなる。フ ラッシュ・ストレージなどI/Oの高速化やボトルネックの生 じにくい設計により対応。 ポリシー管理 サーバーとネットワークが 物理的に対応している場合 は、ポリシーも管理しやす いが、それぞれが仮想化し 追加や変更が頻繁に起こ る場合、対応が複雑化。ク ラウドOSや自動化ツールに より対応。 物理システムを前提とし たシステム設計とは考慮点 が異なる点が多い。 フラッシュ・ストレージ、SDN、 クラウドOSなど仮想化環境 を最適化できるテクノロ ジーの活用を組み合わせ た構築が必要。
  105. 105. サイバー・セキュリティ Cyber Security
  106. 106. サイバー攻撃がなぜなくならないのか 106 1425% サイバー犯罪の投資対効果(ROI) Payload: $3000 ランサムウェア等マルウェアの購入費。 Infection Vector: $500 マルウェアに感染させるための手法の使用料。 Traffic Acquisition: $1800 マルウェア配布サイトの使用料。 Daily Encryption: $600 マルウェアを検知されにくくするための暗号化を使う費用。 経費:$5,900 出典:2015 Trustwave Global Security Report 訪問者数 20,000人/日 感染率 10% → 2,000人/日 支払率 0.5% → 10人/日 支払額 $300/人 期間 30日 収益:$90,000 クラウド・サービスとして提供
  107. 107. ビジネスとしてのランサムウェア 107  ボットネットレンタル : 60ドル/日、400ドル/週  ランサムウェアキット : 1,000ドル/月  サーバー侵入代行 : 3~5ドル(コマンドインターフェイス)、 10~25ドル(リモートデスクトップ接続)  エクスプロイトキット(リース) : 50ドル/日~1,800ドル/月  クレジットカード番号(所有者詳細情報つき): 30ドル  ヘルスケア情報(米国医療保障制度番号10件): 4,700ドル DARKReading:Cybercrime: A Black Market Price List From The Dark Web Ransomware as a Service 利用料金 クラウド・サービス として取引されている サイバー犯罪の多くは金銭目的 オンラインバンキングではアカ ウント情報を窃取し不正送金を 行い、ランサムウェアはWebマ ネーやビットコインを要求する。 個人のスキルに依存したビジ ネスから組織的ビジネスある いは分業化されたビジネスへ
  108. 108. セキュリティ対策対象の変化 108 LAN ファイヤー ウォール LAN ファイヤー ウォール インターネット 特定&少数の通信相手 特定・不特定&多数の通信相手 自社の所有するシステム資産を守ることにより 経営、業務、データ、個人を守ることができた ユーザー認証や暗号化、セキュアなプログラムなどで 経営、業務、データ、個人を守らなくてはならない 複 雑 さ と 範 囲 の 拡 大
  109. 109. 自分たちのシステム 「セキュリティが不安でパブリック・クラウドは使えない」は本当か? 109 脅威 脆弱性 対策可能対策不可能 ウイルスや不正ア クセスなどの攻撃 バグや組合せの 不具合などの弱点 完全な対策は不可能 「見える化」対策 システムの利用状況や 動作を常時監視し不審 な動きがあれば直ちに 件して対策する セキュリティ・リスク
  110. 110. 経営とガバナンス
  111. 111. そもそも、私たちは何のために仕事をするのか? 111 自分で自分を評価し自己満足しているだけでは対価は手に入らない! 評価されるため × その対価はお金 誰に評価されれば仕事の対価を手に入れられるか?
  112. 112. 評価の仕組み 112 承認された手順 指示 承認 参照 進捗を記入 進捗を確認 報連相 評価 経営者・管理者 従業員
  113. 113. 何を評価するのか 113  ルール通りに作業はできている。しかし・・・  このやり方でビジネス・スピードに追従できているか?  生産性は向上しているのか?  だれかが「遅くまで仕事をする」ことで、効率の悪さが帳消しに なっていないか?  締め切りを遅らせる「コミュニケーション」が多すぎないか?  無駄な会議、無駄なメールのやり取りなど・・・  確かに「作業」はしている。しかし・・・  評価の「指標」が明確になっているか?  「目的」は何か  その目的を達成するための「目標」は明確か  「目標」達成にはどれだけのことをやらなければならないのか  誰がやればどれくらいで終わらせることができるか  全体の作業工数は明確になっているか  「目的」は達成されたか?
  114. 114. 目的の達成にはガバナンスが必要 114 目的 目標 プロセス 進捗 結果 ガバナンスができている 「目的」を達成するために  全てが見えている  改善・変更できる  実行・停止を指示できる
  115. 115. 評価は報告の連鎖、報告連鎖の仕組みが組織 115 ステークホルダー 経営者 管理職 従業員 業務 業務 報告 報告 報告 要望 把握 改善のサイクル 最終的な責任を経営者に委譲する仕組み
  116. 116. サイバー・セキュリティ
  117. 117. サイバーセキュリティ対策とは 117 情報資産・システム資産を守る 安心・安全が保証された業務プロセスを作る・維持する 説明責任を果たす 個人のIDに紐付けられた全ての行動を記録する 認 可認 証識 別 マルウェア・ウイルス 不正侵入 システム破壊 従業員に負担をかけず、安全・安心に業務ができる環境を提供する セキュリティに関わる事故や不正の責任から従業員を解放する 従業員 業績向上 効率よく効果的に 業務を遂行し 事業の成果に貢献する 的確な経営判断 経営状況が正確 かつタイムリーに 報告・見える化される 手段 手段 目的 脆 弱 性 対 策 認 証 管 理 対 策
  118. 118. リスクマネージメントの相関図 118 事故の発生 事故の影響 受容 脅威 ぜい弱性 機密性 完全性 可用性対策 受容レベル 保証×説明 コスト 影響 どこまでやればよいのかを?  対策コスト負担  3項目への影響  業務の受容レベル 最適な組合せ 情報セキュリティの3項目 機密性:情報を盗まれない。 完全性:情報をデタラメな内容に書き換えられない。 可用性:システムを停止・破壊され業務継続を妨げられない。
  119. 119. 脆弱性対策 業務設計・実装(Development) 事故対応(Security)運用・保守(Operations) 業務 ITサービス・システム 既存のリスク 新規リスク 補修・改善 復旧 封じ込め 原因究明 運用・保守 監視・検知 補修改善が終わるまでの対応補修・改善 できるだけ上流(Development)で対策するのが効果的 DevSecOps:このプロセスを確実に実施して行くための取り組み
  120. 120. セキュリティ対策は何を評価するのか 120 セキュリティの評価 ① 安全か ② 安心か ③ 効率や利便性は高まったか ④ ビジネスは成長したか 誰が評価するか IT担当者 IT担当者 利用者 経営者
  121. 121. こんなことになってはいないだろうか? 121  情報セキュリティ対策が効率や利便性の向上の障害に なっていないか?  ノートPCを購入した → 危ないので持ち出し禁止  Office 365を契約した → 危ないので外部からの利用禁止  当初の導入目的は何だったのか。それが満たされているか  利用者に負担をかけない対策を行っているか?  不審なメールは開かない → 開いた人の責任  複雑なパスワードを定期変更する → パスワードをつけた人の責任  IT利用によってビジネスは成長しているか?  導入前と導入後で業績は変わらない  期待していた効果が得られない  業務効率は低下している  突発的な損失が起こる可能性を想定しているか?  セキュリティ事故や社内不正によって突発的な事故が起きた時の影響 について分からない、検討していない  事故対応(インシデントレスポンス)の準備はしていない
  122. 122. セキュリティ対策の狙いと手段 122  従業員の「判断」を最小化する  創造性の高い業務とそうでない業務を明確に分ける  創造性の必要ない業務における従業員の判断を最小化するため に業務の効率化・自動化を行う  従業員に創造性の高い業務をさせる  業務改善のため、従業員保護のためにできること  セキュリティの判断を従業員にさせない  なにかあった時に従業員を護ることができるように「継続的な 監視(Continuous Monitoring)」を行う  そのために「IDとログ(記録)の一元管理」が必要
  123. 123. 認証基盤 123 識別 Identification 認証 Authentication 認可 Authorization 説明責任 Accountability R ------ W ------ X ------ 識別:ユーザーを識別できるようにそれぞれに固有のユーザーアカウント(ID)を割り当てる。 例えば社員番号やメールアドレスなど。 認証:そのユーザーが本人であることを確認する。一般的な運用では、そのユーザーしか知りえ ないパスワードによる認証が中心。 認可:そのユーザーの属性に応じてアクセスできる範囲を確認する。たとえば、人事部のみアク セスできるファイルやフォルダーには人事部ユーザーだけがアクセスできるようにする。 認証基盤
  124. 124. 認証基盤 124 説明責任 ローカルシステム IDを統合することでローカルとクラウドを両方を管理できる 外部の把握だけではなく、既存のシステムからも同様に情報を 取得する必要があり、これも統合基盤に加える。クラウドサー ビスを利用して、情報を管理し、それを社内の情報管理システ ムと統合していくことが重要
  125. 125. 認証に関わる課題 125  デバイス管理では穴だらけ  デバイスが圧倒的に増えているため、利用周期が短くなってい るためにデバイス管理ではリスクマネジメントが難しくなって きた  ユーザモニタリングを行うことで責任を明確に  誰がなにをしたのかを正しく判断することで、従業員も会社も 護ることができる  共通基盤を作れば、責任をインフラ側に客観視してもらうこと ができ、責任をより明確化できる
  126. 126. シングルサインオンとフェデレーション 126  急速なクラウド普及により、セキュリティ 対策 および利便性向上の両面において、 改めてシングルサインオンの需要が急増。  認証連携(フェデレーション)を利用する ことで パブリック・クラウドへもセキュア なアクセス/シングルサインオンを実現。
  127. 127. サイバー・セキュリティ対策の目的 127  どのような「心配事」があるかをリストアップする。  「リスク需要レベル」を明確にし、関係者と合意する。  重要度・緊急度を明確にして優先順位を決め対策する。 ITを最大限に活用するための最小限のセキュリティ ITを活用する上での心配事を解消し業務の効率や利便性を高めること サイバー・セキュリティの目的は「情報資産の保護」ではない。 リスクを適正に管理し業務の効率や利便性を高めること。  機密性:情報を盗まれないようにすること。  完全性:情報をデタラメな内容に書き換えられないようにすること。  可用性:システムを停止・破壊され業務継続を妨げられないようにすること。 安心・安全に、便利に効率よく仕事ができるようにする取り組み  問題を回避する対策:USBメモリー使用禁止  目的を達成する対策:安心・安全なファイル共有・交換サービスを提供 ファイルを受け渡したい
  128. 128. サイバー・セキュリティ対策の範囲 128 1.攻撃を食い止める 不正な行為や攻撃の狙い目となる情 報システムの弱点(脆弱性)を無く す対策 脅威 脆弱性 2.被害を拡大させない 3.事故を繰り返さない 説明 仮に攻撃がすり抜けても、直ちに検 知し関係者に周知できる仕組みや体 制を構築する対策 被害状況を関係者に告知するととも に善後策をとれるルールや法的対応、 組織体制を整備する対策 ITを最大限に活用するための最小限のセキュリティ ITを活用する上での心配事を解消し業務の効率や利便性を高めること 技術的対策 業務的対策 教育・意識改革
  129. 129. 垂直統合システム
  130. 130. 統合システムの分類 130 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)
  131. 131. コンバージド・システムとハイパーコンバージド・システム 131 Converged System (Integrated Infrastructure) Hyper-Converged System (Hyper-Converged Infrastructure) サーバー ネットワーク ストレージ(SAN/NAS) CPU NW 機能 CPU NW 機能 CPU NW 機能 追加 拡張 スケール アウト コンポーネントが多く管理が大変 スケールアップの限界 ストレージの複雑化  ハードや仮想化ソフトなどの複雑な設計  複雑な運用管理、管理者間の分散  性能拡張の限界  ネットワークのボトルネック  ボリューム、LUN、ファイルシステム単位  サーバーはVMや仮想デスク単位で管理 独立サーバを 複数連結し 簡単・無制限に 拡張できる
  132. 132. 従来システムとハイパーコンバージド・システムとの違い 132 サーバー+仮想化 ネットワーク・スイッチ ストレージ(SAN/NAS) サーバー ネットワーク・スイッチ ストレージ サーバー機能 ネットワーク機能 ストレージ機能 運用管理 構成管理 仮想化 物理機器 従来までのシステム ハイパーコンバージド・システム 個別に構成・運用管理・拡張 一括して構成・運用管理・拡張  ハードや仮想化ソフトなどの複雑な設計  複雑な運用管理、管理者間の分散  個々に対応が必要なため性能拡張が難しい  ハードや仮想化ソフトなどが予め統合  一括・一元的に運用管理  スケールアウトで性能拡張・自動で構成 複数連結し簡単・無制限に拡張できる 2Uサイズの筐体 システム機能を 一体・集約化
  133. 133. ハイパーコンバージド・システムのメリット 133 簡単・迅速にセットアップ  サーバやストレージを個別に組み上げ る必要がない  セットアップはソフトウェアで簡単・ 自動  統合された管理画面からサーバとスト レージを統合・一元的に管理 ユニット追加でスケールアウト  拡張に伴う構築や設定作業はソフト ウェアにより自動化  内部ストレージを仮想ストレージ (仮想SAN)として使用することで、 容量・性能を柔軟に拡張。  煩雑な初期サイジングは不要 物理スペースの削減 従来システム  仮想SANを利用することで、スト レージ専用機は不要
  134. 134. CPU/メモリ 重視型モデル ストレージ 重視型モデル ハイパーコンバージド・システムの拡張 134 CPU/メモリ ストレージ容量
  135. 135. ハイパーコンバージドの仕組みと特徴 CPU NW 機能 CPU NW 機能 CPU NW 機能 ネットワーク  共有ストレージを使わずローカルストレージを使う  SDS機能により共有ストレージとして使う  システム導入や設定、追加・拡張はソフトウェアで自動化 SDS: Software-Defined Storage  導入や運用管理の容易さから中小規模ユーザーのインフラ  容易にスケールアウトで拡張できることからVDI  パブリック・クラウド移行の過渡期的用途としてインフラ 仮想システム SAN ストレージ・エリア・ネットワーク ネットワーク ネットワーク  ネットワークスイッチが別途必要(Cisco製品は統合)  インフラの仕組みが異なるためアプリケーション性能や運用方法の確認、見直しが必要  拡張の柔軟性に制約あり 考慮すべき点 仮想 サーバー 仮想 サーバー 仮想 サーバー サイロ型システム 外部ストレージ共有システム 仮想ストレージ共有システム
  136. 136. ハイパーコンバージドの仕組みと特徴 仮想化ハイパーバイザー 仮想 サーバー 仮想 サーバー ストレージ コントロール システム ・・・ ストレージ 仮想化ハイパーバイザー 仮想 サーバー 仮想 サーバー ストレージ コントロール システム ・・・ ストレージ 仮想化ハイパーバイザー 仮想 サーバー 仮想 サーバー ストレージ コントロール システム ・・・ ストレージ ローカルストレージに書き込むデータを同時にネットワーク経由でほかの 複数のサーバーのストレージにも書き込むことで、 障害の回避、仮想サーバーの移動にも柔軟に対応 ストレージ仮想化技術の進化 ハードウェアの価格低下と性能向上 特にフラッシュストレージ TCO削減 導入/拡張作業・運用管理・ラックスペース・消費電力 システム構成 の シンプル化  迅速導入  運用管理の効率化  スモールスタート  拡張性 適用範囲が拡大
  137. 137. コンバージド・システムとハイパーコンバージド・システム 137 Converged System Hyper-Converged System  メーカーのお墨付き構成  迅速な実装  カスタマイズはできない  高い拡張性  簡単に導入  構成や運用の自動化 NXシリーズ Evo RAIL VxRACK VSPEX BLUE HyperFlex System
  138. 138. Hyper-Converged System  高い拡張性  簡単に導入  構成や運用の自動化 NXシリーズ Evo:RAIL VxRACK VSPEX BLUE HyperFlex System コンバージド・システムとハイパーコンバージド・システム 標準化されたモジュール サーバー、ネットワーク、ストレージで1単位のモジュール構成 全てをソフトウエアで設定・構成 システム全体の構成をソフトウエアの設定で行える 自己修復 障害の検知、切り分け、分散処理で自動的に修復 データとサービスを分散 データの管理とアプリケーション・サービスを分散処理 APIと自動化 アプリケーションや管理ツールと連携して運用や調達を自動化
  139. 139. ITインフラの変革で変わる 新しい常識
  140. 140. ITで変わるこれからのワークスタイル ネットワーク (インターネット) ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ ~~~~ ~~~~ ~~~~ ~~~ 140 自宅 カフェ オフィス Web 会議 電子 ワークフロー オフィス ファイル 共有 従来のワークスタイル 新しいワークスタイル 外出先
  141. 141. ITで変わる働き方 141 Web会議室 営業支援 システム 議事録 ~~~~~~~ ~~~~~~~ ~~~~~~~ 決算情報 時事ニュース 新製品情報 取引履歴 提案事例 人工知能 仕事の効率と品質を高め 人間の創造性や人間同士の対話に時間を使えるようにする 場所や時間、道具の難しさに制約されない働き方
  142. 142. コンピューターをつなげる 142 Job#2 Job#1 コンピュータ ネットワーク ネットワーク (インターネット) 1950〜1960年代 1970〜1990年代 1990年代後半〜
  143. 143. 人をつなげる 143 共有による 告知 1 to N メッセンジャー 電子メール 掲示板 ブログ ライブラリー ソーシャル メディア 共感による 拡散 N to N ルーチンワーク 大量・繰り返しの自動化 ワークフロー 業務の流れを電子化 コラボレーション 協働作業 カリキュレーション 大規模計算 オペレーション コミュニケーション Facebook Twitter グループウェア 送付による 伝達 1 to 1
  144. 144. 常識が変わるPCの使い方 144 インターネット データ 文書作成 表計算 プレゼン ・・・ ブラウザ 画面表示・入出力操作 通信 画面表示・入出力操作 通信 オフィス・アプリ データ 文書作成 表計算 プレゼン ・・・ オフィス・アプリ クラウドサービス 文書作成 表計算 プレゼン ・・・ 一般的なPC クライアントPC ブラウザ
  145. 145. データベース
  146. 146. データベースとは?
  147. 147. データベースとは? 「データベース(Database)」の語源 1950年頃アメリカ国防省において、複数に点在する資料保管場所を一箇所に集約し、 そこに行けば全てのデータを得ることが出来るように効率化を図る目的で誕生した。資 料が一箇所に集約された場所を、情報(Data)の基地(Base)と呼び、これが今日のデータ ベースの語源とされている。
  148. 148. データベース管理システム (DBMS) 紙からデジタルへ デジタルデータのメリット データモデルの定義 同時アクセス 検索・更新 デジタルデータの業務活用 =複数のユーザーやシステムでデータを利用・処理 データの一貫性を保証 アクセス制御 対障害性 高速処理 検索 再利用・複製
  149. 149. デジタルデータベースのデータ構造 ツリー構造 (1960年代~) ネットワーク構造 (1960年代~) リレーショナル構造 (1970年代~) 木構造 データ構造に制限 木構造を拡張 表構造 開発生産性が低い 柔軟なデータ構造 開発生産性が低い 非常に柔軟なデータ 構造 開発生産性が高い 一定のリソースが必 要 SQL言語の整備 リソースをそれほど 必要としない リソースをそれほど 必要としない 大規模データの高速 処理 CODASYL規格 HTML XML 1980年 代以降 主流に
  150. 150. リレーショナル・データベースの系譜 1961年 IMS(Information Management System)/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年オラクルに買収
  151. 151. リレーショナル・データベースの革新性 151 SELECT 社員名 FROM 社員 WHERE 年齢 < 30; 使いやすいデータ構造 テーブル 使いやすいユーザー・インターフェイス SQL  データを格納する方法が直観的にイメージしやす い。こうした二次元表によるデータ管理は、 Excelなどのソフトが登場する前から一般的な方 法だったため、RDBが登場した当時の人々にとっ ても受け入れやすいものだった。  「データの位置」という概念を一切排除した。あ るデータが何行目であるとか何列目であるという アドレスやポインタといった扱いの難しい位置表 現を使わなくてもデータを操作できる。  SQLは英語に似せた構文を持っているため、特に英 語を母国語とする人々にとっては、日常言語でデー タを操作できるような感覚を持つ。  ループを排除し、記述の難しさやトラブルを無くす よう工夫されている。データのアドレスをポインタ や配列の添え字で操作したり、ループ処理を記述す ることにともなうバグを引き起こしやすいといった 弊害を無くすように考えられている。
  152. 152. リレーショナル・データベースの限界 152 性能と信頼性のトレードオフ データモデルの限界 グラフ構造 非循環グラフ構造 グラフ構造データの扱いが苦手 非構造化データの扱いが苦手 ドキュメント スケールアウトが難しい データを一元管理し、厳密なトランザクション管理 をするためにストレージを共有する構成を取る必要 があり、ストレージがシングル・ボトルネックポイ ントになってしまうから。 SQLの柔軟性 SQLの表現力が強力で柔軟であるため、かえって複 雑な処理を実行できてしまうこと。特に結合やサブ クエリといった複雑な処理を大規模なデータに実行 することで大規模なスローダウンを引き起こすこと がある。 近年、データは増大の一途をたどり、 開発さ れた当初には想定していなかったデータ量を扱 うには、処理速度が原理的な限界に達している。
  153. 153. 増えるRDBMS「以外の」データベース RDBMS 何でもできる優等生 正確性が求められるミッションクリティカルから住所録まで対応 定型データに強い 最初に厳密な設計が必要 オーバーヘッドが大きい 分散処理しづらい NoSQL 万能では無いが、特定用途に強い 得意なことはめちゃくちゃ得意 非定型データを扱える 分散処理に向く ビッグデータ 非定型データ 分散処理 KVS DocumentDB GraphDB カラム型/列指向 RDBMS DWHに蓄積した大量のデータをBI ツールなどで解析しやすいように 高速に読み出す
  154. 154. 多様化するデータベース 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
  155. 155. RDBMSの ACID特性と高速化
  156. 156. リレーショナルデータベース (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年に発表したデータ関係モ デルについての論文が元になっている 扱うデータは正規化された定型 データ 複数のテーブルを関連付けする ことができる テーブルを横断してデータを検 索したり操作できる 複数のテーブルから見たい列と行を取り出して新たな テーブルを作成(クエリー)
  157. 157. RDBMSが追求してきたACID特性 ACID Atomicity 処理を一部残すなど、中途半端な状態を許さない Consistency データの整合性を保証 Isolation 一連の処理を他の処理から隔離 Durability 処理が完了した時点で結果は保存され失われない 複数のユーザが同時に同一のデータを参照・更新した場合でも、矛盾なく正常に処 理をこなすことができる どの時点でもデータは絶対に正しいことを保証 →金融取引などの「トランザクション」処理に必須 データを常に正しく保つ データを失わない 障害に耐える
  158. 158. ACIDを実現するための機能の例 (1) データベース 表(テーブル) データベース 表(テーブル) DBMS 排他制御(ロック) 一つのプロセス/トランザクションがある データの更新を行っている間、処理が完 了するまで他のプロセス/トランザクション はそのデータにアクセスすることはできな いようにする仕組み。 →処理のオーバーヘッドとなる データベース言語 問い合わせ言語 SQL Xquery等
  159. 159. ACIDを実現するための機能の例 (2) トランザクションロ グ データベース ロールバック=トランザクションが正常に終了しなかった場合に元に戻す ロールフォワード=データベースが破損した場合にログを元に再構築する トランザクション (一連のデータベース操作) 正常終了 異常終了 COMMIT ROLLBACK 障害からの復旧のためにログを残すことが必要 =さらなるオーバーヘッドを産む
  160. 160. DBMS高速化への要求と取り組み トランザクションの増加 データ量の増加 (ビッグデータ) 単体能力の強化 (Scale Up) 集計・分析処理の 高速化 分散処理 (Scale Out) 列指向 RDBMS クラスタ Shared Nothing Sharding I/O分散 キャッシング インメモリ
  161. 161. コンピュータシステムの処理能力を上げる方法 コンピューター単体の能力を強化する (プロセッサの強化、メモリ、I/O) ハードウェアにコストがかかる 性能強化には限界がある クラスタによる分散処理 (効率が高いが高価) 安価なマシンを大量に使う分散処理 (効率は劣るが拡張性が高く低コスト) SCALE UP SCALE OUT RDBMSは SCALE OUTしにくい
  162. 162. RDBMSの高速化手法と問題点 データの分割/同期が必要 単体能力の向上 ストレージ共有 クラスタ 分散システム シェアドナッシング オーバーヘッドが少ない 用途を限定 (Webなど) 最大数百台程度まで ハードウェアコストが高い 最大でも数十台程度まで トランザクションに向かないI/Oがネックになる スケールアップ スケールアウト DB側の対応は必要無し ハードウェアコストが高い 性能に上限がある I/Oがネックになる
  163. 163. デメリットと課題 特徴とメリット RDBMSの特徴 正規化された定型データ 正確かつ安全 厳密な設計、柔軟な運用 フォーマットの揃った「お行儀の良い」データを取り扱うため、処理 の効率化や記憶容量の縮小を実現 ACIDによるデータの一貫性、可用性を保証 設計時にスキーマを使った厳密なモデルが必要だが、運用時の データ操作は柔軟に行える オーバーヘッドが大きい スケールアウトしにくい 非定型データが苦手 ACIDを実現するために様々な処理が必 要 スケールアウトによる性能向上をしづら い ドキュメントや画像・音声などの取扱い には一工夫必要 パフォーマンス 柔軟性
  164. 164. データ分析用に進化した 列指向 (カラム型) RDBMS
  165. 165. 列指向(カラム指向/カラム型) 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) 向け 行 列
  166. 166. 列指向RDBMSの得意分野 ~ 集計 顧客名 住所(県) 住所(市町村) 売上金額 顧客名 住所(県) 住所(市町村) 売上金額 売上金額の集計 行指向 列指向 1レコードずつ読み出して集計 売上金額の列のみを読み出して集計
  167. 167. 列指向RDBMSの得意分野 ~ 分析 顧客名 住所(県) 住所(市町村) 売上金額 顧客名 住所(県) 住所(市町村) 売上金額 顧客の都道府県分布の分析 行指向 列指向 1レコードずつ読み出して集計 都道府県の列のみを読み出して集計 データの圧縮率を上げられる
  168. 168. 列指向RDBMSの不得意分野 ~ 挿入 顧客名 住所(県) 住所(市町村) 売上金額 顧客名 住所(県) 住所(市町村) 売上金額 顧客レコードを挿入 行指向 列指向 レコードの挿入が容易 各列にレコードを挿入
  169. 169. NoSQL
  170. 170. 新たな要求 検索 EC/Webサービス SNS/オンラインゲーム IoT/M2M 機械学習 大量デー タ・高速・多 頻度・リアル タイム 正規化され ていない多 様な非定型 データ サービスの 進化によっ て変わる データ構造 パフォーマンス これまでとは桁違いの処理能力 スケーラビリティ 大規模分散処理 フレキシビリティ 非定型(非構造化)データへの対応 スキーマレスの柔軟な設計 まったく新しい DBMSが必要 NoSQL (Not only SQL = SQL だけじゃない) SQLを使わない (RDBMS では無い) データベース
  171. 171. RDBMSとKey Value Store (KVS) RDBMS KVS データ形式 テーブル キー+バリュー (値) データ構造 正規化・構造化データ 構造化/非構造化データ 設計の柔軟性 事前にスキーマを定義 スキーマレス (変更が容易) 処理の柔軟性 複雑な検索や集計が可能 シンプルな操作のみ データの整合性確保 ◎ (ACID) △ (BASE) 分散処理 △ ◎ トランザクション処理 ◎ △ SQLサポート ◎ △ RDBMS KVS
  172. 172. ACIDからBASEへ BASE Basically Available 「基本的に」利用可能 Soft-state 状態の厳密性を追求しない Eventually consistent 最終的に一貫性が保たれれば良い 厳密な一貫性やデータの即時反映などをあきらめる代わりに、 スケーラビリティや柔軟性を得ることができる ACID Atomicity 処理を一部残すなど、中途半端な状態を許さない Consistency データの整合性を保証 Isolation 一連の処理を他の処理から隔離 Durability 処理が完了した時点で結果は保存され失われない 絶対確実 概ね確実 CAP定理 = 分散システムではACIDを達成できない
  173. 173. ワイドカラムストア型 Amazon DynamoDB Apache Cassandra Amazonが提供するフ ルマネージドのNoSQL サービス DynamoDBをベースに Facebookが開発し、 オープンソースとして 公開 大規模にスケールアウト可能。ノードを増やすとリニアに性能を向上させることができる。 データの一貫性を保証 Google BigTable Apache HBase Googleが開発した拡張 KVS Googleの論文を元に Javaで実装し直した オープンソース 結果整合性 (遅延とのトレードオフで一貫性レベルを設定可能) 可用性は保証されない (3つのノードにレプリカを作成) 可用性を保証 柔軟なデータモデル (スキーマレス)
  174. 174. 様々なNoSQL キーバリュー型 (KVS) ワイドカラム ストア型 (列指向) ドキュメント型 グラフ型 Riak Redis Google BigTable Apache Hbase 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
  175. 175. ドキュメント指向データベース ドキュメントA ドキュメントB ドキュメントC JSON/BSON、XMLなどを 使い、Webサービスと相 性が良い スキーマレス データ構造が柔軟 後から変更可能 様々なデータをそのまま の形で扱える Webサービスと連携 データ構造が柔軟非定型データに対応
  176. 176. ドキュメント指向データベース MongoDB BSON (JSONのバイナリ版) ド キュメントを格納 大規模にスケールアウト可能 ノードを増やすとリニアに性能を向上させることができる 高可用性 Cauchbase KVSのValueとしてJSONドキュ メントを格納 SQLライクなクエリ言語を備え、開発生 産性が高い Webサービスで標準的に使われているJSON形式のデータをそのまま取り込める 柔軟なデータモデル (スキーマレス) で、後からの変更も容易なため、 Webサービスやアジャイル型開発と相性が良い
  177. 177. ドキュメント型データベース http://japan.zdnet.com/article/35061825/
  178. 178. ドキュメント型データベース MongoDB BSON (JSONのバイナリ版) ド キュメントを格納 大規模にスケールアウト可能。ノードを増やすとリニアに性能を向上させることが できる 高可用性 Cauchbase KVSのValueとしてJSONドキュ メントを格納 SQLライクなクエリ言語を備え、開発生 産性が高い Webサービスで標準的に使われているJSON形式のデータをそのまま取り込める 柔軟なデータモデル (スキーマレス) で、後からの変更も容易なため、 Webサービスやアジャイル型開発と相性が良い
  179. 179. グラフ型データベース 関係性を表現する データモデル ノード リレーション プロパティ ノード プロパティ ノード プロパティ ノード プロパティ ノード プロパティ ノード プロパティ リレーション SNS ノード間の関係だけで無く、 ノードに属性(名前や役割 など)を持たせ、リレーショ ンにも属性や方向性を持 たせることができる ネットワーク管理 最適ルート探索 電力グリッド管理 組織図/アクセス権 ペイメントグラフ Neo4j, Giraph Oracle Spatial and Graph
  180. 180. 実際のシステムは適材適所で ECショップ 商品検索 = KVS 決済処理 = RDBMS 金融取引・決済 RDBMS ワイドカラム グラフ 検索・SNS ドキュメント 文書管理
  181. 181. クラウドデータベース
  182. 182. クラウドデータベース (マネージド/DBaaS) Amazon Azure Google 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をサポート
  183. 183. 大規模分散処理 MapReduceとHadoop

×