【パブリッククラウド提案力強化研修】パブリック・クラウドを味方にする方法
•
2 gostaram•2,679 visualizações
http://libra.netcommerce.co.jp/
Recomendados
Mais conteúdo relacionado
Destaque
Destaque (19)
Semelhante a 【パブリッククラウド提案力強化研修】パブリック・クラウドを味方にする方法
Semelhante a 【パブリッククラウド提案力強化研修】パブリック・クラウドを味方にする方法 (20)
Mais de Masanori Saito
Mais de Masanori Saito (20)
Último
Último (11)
【パブリッククラウド提案力強化研修】パブリック・クラウドを味方にする方法
- 2. ご参考まで 2
- 3. 最新のITトレンドを図解で俯瞰する l ネットをながめても、テクノロジーのトレンド、 意味や価値は見えてきません。 l 難しい技術用語を並べられていても、専門知 識がなければ理解できません。 l 製品説明をつなぎ合わせても、テクノロジー の背景や本質は、分かりません。 本書は、約100枚のわかりやすい図表と平易な解説で、そんなお 悩みを解決します。さらに、本書に掲載されている全ての図表は、 ロイヤリティ・フリーのパワーポイントでダウンロードできます。 http://amzn.to/1AQtPXz
- 4. 4 クラウドの基本
- 9. 「自家発電モデル」から「発電所モデル」へ 9 工場内・発電設備 v 設備の運用・管理・保守は自前 v 需要変動に柔軟性なし 電力供給が不安定 自前で発電設備を所有 工場内・設備 電 力 電力会社・発電所 大規模な発電設備 低料金で安定供給を実現 v 設備の運用・管理・保守から解放 v 需要変動に柔軟に対応 工場内・設備 送電網 データセンター 大規模なシステム資源 低料金で安定供給を実現 v 設備の運用・管理・保守から解放 v 需要変動に柔軟に対応 システム・ユーザー デ タ インターネット
- 13. システム資源のECサイト 見積書 契約書 調達手配 導入作業 メーカー ベンダー サイジング 調 達 費 用 数週間から数ヶ月 数ヶ月から数年を想定 現物資産またはリース資産 従来の方法 セルフ･サービス・ポータル l 調達・構成変更 l サービスレベル設定 l 運用設定 l ・・・ 数分から数十分 直近のみ・必要に応じて増減 経費・従量課金／定額課金 クラウド オンライン･リアルタイム
- 15. v 徹底した標準化 v ⼤量購⼊ v 負荷の平準化 v APIの充実・整備 v セルフサービス化 v 機能のメニュー化 クラウド・コンピューティングのビジネス・モデル 15 クラウド・コンピューティング オンデマンド 従量課⾦ ⾃動化・⾃律化 システム資源 の共同購買 サービス化 低コスト 俊敏性 スケーラビリティ SDI (Software Defined Infrastructure)
- 16. IT活用適用領域の拡大 難しさの隠蔽 システム資源 エコシステム クラウドがもたらしたITの新しい価値 16 クラウド・コンピューティング IT利用のイノベーションを促進 ビジネスにおけるIT価値の変化・向上 新たな需要・潜在需要の喚起 モバイル・ウェアラブル ソーシャル 人工知能 ビッグデータ IT利用者の拡大 IoT ロボット 価格破壊 サービス化
- 19. クラウドの定義／サービス・モデル (Service Model) アプリケーション ミドルウェア オペレーティング システム ハードウェア PaaS Platform as a Service IaaS Infrastructure as a Service Software as a Service SaaS Salesfoce.com Google Apps Microsoft Office 365 Microsoft Azure Force.com Google App Engine Amazon EC2 IIJ GIO Cloud Google Cloud Platform アプリケーション ミドルウェア&OS マシン プ ラ ッ ト フ ォ ム
- 20. ハイブリッド・クラウド 複数企業共⽤ パブリック・クラウド クラウドの定義／配置モデル (Deployment Model) プライベート・クラウド 個別企業専⽤ 個別･少数企業 不特定・複数企業／個⼈ LAN LAN インターネット 特定企業占有 ホステッド・プライベート・クラウド 固定割当て LAN 専⽤回線・VPN LAN
- 21. プライベートクラウド（１） 21 http://www.idcjapan.co.jp/Press/Current/20150909Apr.html 国内プライベートクラウド市場 配備モデル別⽀出額予測 2014年〜2019年 v オンプレミス・プライベートクラウド v ホステッド・プライベートクラウド Ø デディケイテッド・プライベート・クラウド Ø コミュニティ・プライベート・クラウド プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ü ユーザー企業構内に設置 ü ⾃社資産 ü ⾃社運⽤・管理 ü サービス事業者施設内に設置 ü サービス事業者の資産 ü 定額利⽤料⾦／従量課⾦ パブリック・クラウドの⼀部を ユーザー（テナント）に占有使⽤ ユーザー（テナント）毎のプライ ベート・クラウドを管理・運⽤
- 22. プライベートクラウド（２） 22 プライベート・クラウド ホステッド プライベート・クラウド オンプレミス プライベート・クラウド デディケイテッド プライベート・クラウド コミュニティ プライベート・クラウド ユーザー企業に システム資源を 占有・割り当て パブリック・クラウド ユーザー企業・⾃社構内 データセンタ・占有借⽤施設内 クラウド・サービス事業者 ⾃社専⽤ クラウド環境 予め⽤意された 標準仕様を組合せ ユーザー企業毎に 個別仕様で クラウドを提供 ユーザー企業の資産 クラウド・サービス事業者の資産 運⽤管理責任は⾃社 運⽤管理責任は事業者 運⽤管理責任は事業者 リースまたは減価償却 サブスクリプション サブスクリプション+初期費⽤ l OpenStack（OSS） l Microsoft Azure Stack l Vmware vSphere など l AWS Virtual Private Cloud l Microsoft Virtual Network l IBM Blumix Dedicated など l NTT コム Enterprise Cloud l NSSOL absonne l CTC CUVICmc2 など
- 23. ハイブリッド・クラウド モバイル連携 使い分け 災害対策 負荷調整 SaaS連携 ピーク対応 柔軟対応 PublicPrivate PublicPrivate PublicPrivate PublicPrivatePublicPrivate PublicPrivate PublicPrivate パブリックで モバイル・ア プリケーショ ンと連携 プライベート で基幹業務系 の処理 業務ごとに両 者を使い分け 通常時はプラ イベート 災害時にはパ ブリックに切 り替え プライベート で負荷をまか ないきれない ときにパブ リックを追加 リソースとし て使⽤ パブリックで SaaSを使⽤ そのデータを プライベート の業務システ ムで処理する 通常はプライ ベートで処理 するがピーク 時はパブリッ クにリソース を拡⼤する 業務状況に応 じて業務や データを両者 で柔軟に使い 分ける （単⼀リソース） 業 務 業 務 業 務 業 務 業務 業務 業務 業務 負荷調整 業務 SaaS 業務 業務 業 務 業 務 業 務 業 務 対象とする業 務アプリケー ションへのア クセス⽅法 業務の配置と 統合監視・管 理⽅法 データやアプ リケーション 同期の⽅法や タイミング サイト切り替 え法 統合監視・管 理⽅法 ネットワーク 帯域・設定 振り分けが⾃ 動か⼿動で難 易度が変わる SaaS/API連携 の⽅法 データやアプ リケーション 同期の⽅法や タイミング サイト切り替 え法 統合監視・管 理⽅法 データやアプ リケーション 同期の⽅法や タイミング サイト切り替 え法 統合監視・管 理⽅法 低 低 中 ⾼ ⾼ ⾼+ ⾼+
- 24. ハイブリッド・クラウド（３） 同⼀のアーキテクチャー リソース Ａ リソース Ｂ リソース Ｃ パブリック・クラウド プライベート・クラウド クラウド基盤 仮想基板 セルフサービス・ポータル リソース Ａ リソース Ｂ リソース Ｃ ユーザー・ビュー パブリックと プライベートが ひとつの リソース プール 標準化の主導権争い
- 25. ハイブリッド・クラウド 25 Cloud Stack AWS OpenStack Cloud Stack vmware vCloud Air vmware vCloud Suites Azure Azure Stack Google Cloud Platform なし Cloud Foundry Google App Engine Elastic Beans Talk Lambda など IBM Bluemix BlueMIx Dedicated 互換API OpenStack Cloud Foundry IBM Bluemix Local プライベート・クラウド パブリック・クラウド PaaS IaaS PaaS IaaS SQL Server Visual Studio .Net など
- 27. ハイブリッド・クラウドとマルチ・クラウド 27 クラウド管理プラットフォーム Prime Cloud Controller (SCSK) / RightScale (RightScale) / vRealize Suite (Vmware) など オンプレミス（自社構内） データセンタ（自社設備） データセンタ（他社設備） コロケーション／ホスティング パブリック・クラウド パブリック・クラウド バーチャル プライベート クラウド ハイブリッド・クラウド マルチ・クラウド インターネット／ＶＰＮ／専用線 (SDN : Software-Defined Network) 個別専用システム ハイブリッド・クラウド マルチクラウド
- 30. 日米の企業文化の違いとクラウドへの期待IPA人材白書・2012／日経SYSTEMS 2012/8を参考に作成 ITエンジニア の人数 ユーザー 企業 ITベンダー企業 75% ユーザー企業 72% ITベンダー 企業 ITベンダー企業の生産性向上 + ベンダーがリスクを背負わされる ユーザー企業の生産性向上 + ユーザーが自らリスクを担保 エンジニアリング・ワークの生産性が劇的に向上 運用の自動化 ＋ 調達の自動化 ＝ エンジニアの調達・運用管理負担の軽減 約100万人 約300万人
- 32. パブリック・クラウドへ移行すればコストを削減できるか？ 32 現行システム（オンプレミス）の構成や運用をそのままに移行しても コスト削減は難しい l サーバー台数 Ø サーバー台数が多いとシステムが複雑になり、構築・インテグレーション費用が増加する Ø 販売代理店（SI事業者など）に任せると台数に応じて販売マージンや手数料が必要となる Ø 管理対象のサーバー台数が多いと保守・サポート費用が増加する l サーバー稼働時間 Ø 使わないサーバー・インスタンスが停止されずに動いている Ø 割引が効くはずの年額一括にしたが、全てを使われずに無駄な費用を払ってしまう Ø 常時稼働が前提のオンプレミスと同じ運用方法で料金が嵩んでしまう l サービス・レベル Ø パックアップ Ø 冗長化構成 Ø その他、サポートオプションの契約 l データ転送コスト Ø ダウンロードデータ転送（外部へのデータ持ちだし） Ø 外部ネットワーク回線費用（閉域網、国際回線等） l 社員人件費 Ø 運用管理などに関わる社員の人件費はクラウドに機能が移管してもそのまま残存 SI事業者によっては、サーバー台数 を増やそうとする場合がある！
- 34. クラウドサービスのコスト構造 34 サーバー ストレージ データ転送 内部ネットワーク 外部ネットワーク 能⼒×時間 容量／⽉ 転送量（GB） ダウンロード 定額／⽉ 転送量 ポート速度100Mビット秒 オプション機能 FW、LBなど オプション単位 インスタンスの能⼒に よって料⾦は異なる。 外部へのデータ転送量 に応じて課⾦される。 サービスによって異な る。 セグメント数、外部 ネットワークとの接続 に伴うデータ転送量に 応じて課⾦される。 専⽤線などの閉域網、 海外DCとの国際回線の 費⽤などが必要となる。 サービスによっては標 準機能として提供され る場合もある。 ü 冗⻑化構成を減らす ü 変動／固定を動的に組合せる ü 必要なインスタンスのみ稼働させる ü 運⽤を⾃動化する ü ベンダーを通さず直接契約にする ü データ・ライフサイクルを⾒直し ホット/コールドデータを分けて保管 ü 容量無制限のファイルサーバーと組 み合わせる アクセス速度に応じて サービス・料⾦が異な る。 ü アプリケーション設計の⾒直し ü 同⼀セグメント内での転送 ü 運⽤⽅法の⾒直し ü セグメント内で完結するような設計 ü 国際回線を多⽤する場合は回線料⾦ が組み込まれたサービスを選定 ü 不要なオプションは設定しない オ ン プ レ ミ ス を そ の ま ま に 移 ⾏ せ ず 構 成 ・ 運 ⽤ を 再 設 計
- 35. 料金の削減のポイント（１） 35 必 要 能 ⼒ 調達するサーバー能⼒ 必 要 能 ⼒ 調達するサーバー能⼒ 運⽤⾃動化ツールの活⽤ よく似た運⽤パターン・グループ に集約しインスタンスを削減
- 36. 移管の考え方 36 IaaS PaaS SaaS オンプレミス・システム 1. コスト 5年間のTCO 2. BCP 遠隔多重化構成など 3. バックアップ／アーカイブ 電⼦メール、業務データなど 4. ユーザー利便性 応答時間、グローバル対応など 5. ガバナンス ⾒える化、管理機能など そのまま移⾏すれば ü オンプレミスよりもコストが嵩む ü 運⽤管理負担が増える ü 機能⾯で利⽤部⾨のニーズに応えられない ü サービスレベルが低下する ü セキュリティが担保できない Ø 上記、組合せの最適解を考える Ø クラウド前提のアーキテクチャーに⾒直す Ø 情報システム部⾨の役割を再構築する
- 37. 移管に関する考慮事項 37 システム・アーキテクチャー変更にともなう ü スループットやレスポンスなどの影響度 分析やリスク検証 ü 投資を正当化するため、オンプレミスと の⽐較における投資対効果の明確化 ü ⾮機能要件の⾒直し セキュリティポリシーや個⼈情報保護⽅針との適合性や システム監査への対応要件を満たすかどうかなど ü 運⽤⽅法の変更 ü パブリッククラウドの提供機能やセ キュリティポリシーなどの評価 既存業務システム （オンプレミス） パブリッククラウドへの移管 仮想サーバーの パブリッククラウドへの移管 パブリッククラウドでの 新規システム構築 海外システムのクラウド化 ü 越境データ規制 ü 個⼈情報保護規定 ü 犯罪捜査権 など
- 39. システムデザイン勘所 39 Design for Failure 障害発⽣を前提とし、 障害が発⽣しても問題なく運⽤できるような設計を⾏うこと システム機器ではなくサービスとしての健全性を保つこと ü 全体の可⽤性の担保が最重要 ü SPOF（Single Point of Failur：単⼀障害点）を作らない構成 多様な監視⽅法を組み⼊れること ü 外からの監視：反応があるか、ないか ü 内からの監視：受けられるか、受けられないか ü サービスからの報告：サービス⾃⾝の健全性の主張 データを収拾し、閲覧する体制を作る ü いつでも、増やせる、削除できる仕組みとする ü データを集積し、利⽤状況を分析する ü 分析結果を踏まえてブラッシュアップを継続する ⾃動化する ü いつ起きるか分からないことへの対応を⾃動化で対処する ü 検知、報告、対応までの⾃動化を⽬指す 監視 ログ 収集 通知 復旧 改善 分析
- 40. 実演
- 41. シナリオ１：クラウドで仮想サーバーを調達 41 Google Cloud Platformで仮想の発注 → リソース変更 Ø AWS、Azure、Google Cloud Platform、SoftLayerの中で最も最速で仮想マシンが ⽴ち上がると評判（※）のGoogle Cloud Platformで仮想マシンを発注してみます。 ※現時点のものです。使⽤者が増えたり、サービスの改定で変わります。 動画デモ
- 42. シナリオ２：クラウドでベアメタルサーバーを調達 42 SoftLayerでベアメタの発注→仮想に変換→リソースの変更 Ø AWS、Azure、Google Cloud Platform、SoftLayerの中で、唯⼀、物理サーバー （ベアメタルサーバー）を提供しているSoftLayerでベアメタルサーバーを発注して みます。 Ø ベアメタルサーバーのイメージテンプレートから、仮想マシンを作成する（使⽤する シチュエーションの例） ü ベアメタルで作ったけど、テスト⽤に同じ構成で仮想マシンを作っておきたい。 ü ベアメタルで構築したが、リソースをそんなに作っていないので仮想マシンに置き換えたい 動画デモ
- 43. シナリオ３：クラウドでリモートデスクトップを作成 43 AzureでRemoteAppの発注 Ø RemoteAppとは？ はリモート デスクトップ サービス経由で、リモートサーバーの 上のアプリを、あたかもローカルで実⾏しているかのようにみせる技術です。 Ø RemoteApp プログラムは、ローカルのアプリケーションと同様に表⽰されますが、 プログラムはリモートサーバー上で稼動しています。 動画デモ
- 46. 実践のステップ 46 検討 調達 構築 運⽤ 1. 試算するコストの漏 れ抜けに注意 2. 利⽤の繁忙期、閑散 期を意識してサイジ ング 3. ⾃前で構築すべきか どうかを⾒極める 4. ライセンスはクラウ ド対応かどうかを確 認 1. 費⽤の⽀払⽅法 2. ベンダー選定 1. 各種⼿続きのリード タイム 2. クラウドのオーダー 3. パフォーマンス 4. 監視 5. 権限設定 6. セキュリティ 7. そのほか 1. 費⽤の⽀払⽅法 2. ベンダー選定
- 47. 検討
- 48. 検討時の考慮事項 ü 試算するコストの漏れ抜けに注意 ü 利⽤の繁忙期、閑散期を意識してサイジング ü ⾃前で構築すべきかどうかを⾒極める ü ライセンスはクラウド対応かどうかを確認 48
- 49. 検討１：目に見えないコストにも注意する 49 オンプレでのサーバー更改があり、オンプレのサーバー費⽤の⾒積が 1500万円なんですが、クラウドにしたらいくらですか？ クラウドは安いというイメージ「Amazon EC2」が0.02ドル〜/h ⽬に⾒えない費⽤も含まれている。これらを含めて、⽐較しないと同条件 での⽐較にはならない。普段は意識しない、既存の⾃社データセンターや サーバールームの維持費とランニングコストも含め⽐較する必要がある。 サーバー（HW）費⽤、サーバー保守費、電源・空調費⽤、場所代、ハイパーバイザーの冗⻑化、 LiveMigration機能、SnapShot機能、Storage領域の3冗⻑、24h365dでインフラ環境の保守要員 常駐費⽤など ※クラウドプロバイダーによって、条件は異なる よくやってしまう⽐較 オンプレのサーバー（HW）費⽤ vs クラウド費⽤（オンプレと同台数＆同スペック） 〇 オンプレのサーバー（HW）費⽤ ローエンドモデルのPCサーバー:¥100,000／台 → ¥15,000,000/150台 〇 クラウド費⽤（オンプレと同台数＆同スペック） ローエンド程度のスペックのインスタンス → ¥26,360,640/150インスタンス/年 ※ $1,464.48/インスタンス＝¥175,738/インスタンス（1ドル＝120円）
- 50. 検討２：サーバーの使用率や利用時期を洗い出す 50 オンプレミスと同じ使い⽅をしようとすると、コストを下げられない？ クラウドは必要な時に必要な分だけ⽤意できる。その特性を活かすことで、コスト削 減ができる。 Ø ひと⽉しか使わない → ひと⽉だけ使う 年間で12分の1にコスト削減 Ø 使⽤率が低い → 超ロースペックで発注 オンプレと同スペックなら$0.16/h→超ロースペックなら$0.02/h 年間で8分の1にコスト削減 Ø ⼀定の時期だけスペックが必要 → 通常時はロースペック、必要な時だけスペックを増やす 年間で？分の１にコスト削減 既に所有しているシステムは構成を変えることはできない。追加するにも時間も⼿間もかかり、 ⼀旦資産となったら使い切らなくてはならない。
- 51. 検討３：各サーバー（システム）の利用シーンを洗い出す 51 オンプレミスと同じ使い⽅をしようとすると、コストを下げられない？ 各サーバー（システム）の利⽤シーンの洗い出しを⾏って、以下を検討する。 ØSaaS → PaaS → IaaSの順で検討する ü ファイルサーバー代替として、SaaSのBOXやDropbox、PriveDrive（国産）な どのオンラインストレージを使うことも可能。SaaSであれば、すぐに使え、構 築⼯数が削減できる。 ü Active Directoryもサービスが使えるのでIaaSで作る必要はない（Azureのみ） Ø接続はポータビリティを求めるか？セキュアな通信を求めるか？ üCRMやカタログなど外出先から簡単にアクセスして使いたいシステムの場合は、 インターネット経由（VPNや端末認証）で利⽤できる環境にする。 ü⼈事データなど社内から安全に通信したいシステムの場合は、お客様環境とクラ ウドサービスの間に専⽤ネットワーク回線をひいてセキュア通信環境にする。 Azure ： ExpressRoute AWS ： Direct Connect SoftLayer ： DirectLink 通常データ ： BOXやPrimeDirve等のインターネット経由で利⽤できるサービス 機密データ ： IaaSでファイルサーバーを構築、専⽤ネットワーク回線で接続
- 52. 検討４：移行対象を見極める（１） 52 全てをパブリッククラウドに移⾏すべきだろうか？ ソフトウェアライセンスが仮想サーバーに適合できているか？ → Oracle製品の場合、AWS、Azureに関してはCPUライセンスを認めている http://www.oracle.com/jp/store/cloud-lic-170290-ja.pdf 適合できていない場合は、代替案の検討 ü 適合しているソフトウェアに変更が可能か？（変更に伴って発⽣する費⽤を考慮） ü SoftLayer等、物理サーバーが利⽤できるクラウドにするか？ ü オンプレ環境に残すか？
- 53. 検討４：移行対象を見極める（２） 53 全てをパブリッククラウドに移⾏すべきだろうか？ MACアドレスと紐づくアプリケーションは無いか（例：CAD製品）？ → MACアドレスなどのハードウェアの固有の情報は維持し続けることは出来ないこ とが多いので要注意 例）Azureの場合 仮想マシンの MAC アドレスは、いくつかの原因で変化する可能性があります。VM を停⽌ (割り当て解除) 状態にする場合や、仮想マシンのサイズを変更する場合、ま たはホスト サーバーのサービス修復や計画済みのメンテナンスを実施する場合は、 MAC アドレスは維持されません。 https://msdn.microsoft.com/ja-jp/library/azure/dn133803.aspx 例）AWSの場合 可能。 http://aws.typepad.com/aws_japan/2011/12/new-elastic-network- interfaces-in-the-virtual-private-cloud.html
- 54. シナリオ４：クラウドでDB/HAサーバーを構築 54 AWSのPaaS：Amazon RDS for Oracle Ø AWSのPaaSを使って、OracleのHA構成をあっという間に構築します。 動画デモ
- 55. 補足）Databaseのクラウドへの移行考慮点 55 PaaS→IaaSの順で検討 PaaSを選択する場合、業務に適しているかを確認 Azure SQL Database Ø ポイントインタイム リストアで、データベースを 35 ⽇間分遡って以前の状態に戻すことができる （Editionにより遡れる⽇数が異なる） Ø データベースをホストしているデータ センターで障害が発⽣した場合は、別のリージョンにあるデータ ベース レプリカにフェールオーバーことができる Ø レプリカを使⽤して、アップグレードまたは異なる地域への再配置を⾏うことができる Ø 最新のプログラムにアップデートされる。 Ø 制限事項について確認する ü Windows 認証はサポートされない ü TCP/IP 接続のみが許可 ü 分散トランザクション (複数のリソースに影響するトランザクション) をサポートしていない など ü 詳細は以下のURLを参照 https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-general-limitations/ https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-performance-guidance/#service- tier-capabilities-and-limits https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-resource-limits/ https://azure.microsoft.com/ja-jp/documentation/articles/sql-database-security-guidelines/ データ量を確認 データ元がオンプレミス環境にあり、データ量が⼤量の場合、クラウド環境へデータをアップロードしなく てはならないが、それがボトルネックになる可能性があり 通信量の確認 アップロード、ダウンロードなどの通信で費⽤が発⽣する（各クラウドベンダーで費⽤の掛かり⽅が異な る）ので、DBのアップロード、ダウンロードの量も含めて検討する
- 56. 補足）クラウドの利用料金を下げる（１） 56 スモールスタートで始める クラウドは必要な分スペックが増やせるので、最初から⼗分なリソースを割り当てるのではなく、リソー スの利⽤状況を⾒ながら増やす。 ※オンプレの時の感覚が抜けず、リソースを多めに割りあてる場合がよくある。 マルチクラウドにする AWSで運⽤したが、しばらく運⽤しているとネットワーク通信量が⼤変なことに。通信量の多いサービス をネットワーク通信費を固定できるクラウドへ移⾏して、コスト削減を実現。 使わない時は課⾦されないように⼯夫する Ø 使わない時は停⽌して、使う時のみ起動する。AWSの場合は停⽌（インスタンスは課⾦されないが、 EBSは課⾦される）。 http://docs.aws.amazon.com/ja_jp/AWSEC2/latest/UserGuide/Stop_Start.html Ø Azureの場合は停⽌＆割当解除 http://blogs.msdn.com/b/dsazurejp/archive/2015/01/09/azure-virtual-machine-billing- architecture.aspx Ø SoftLayerは削除（サーバー停⽌しても費⽤がとられるので、テンプレート化しておいてサーバ削除） Storageの選択はデータの⽤途別 各クラウド業者でStorage種類を複数提供しているので、データに適したストレージを選択する ü AWSの場合 スタンダードストレージ標準／低頻度アクセスストレージ／Glacier ストレージ ü GCPの場合 Standard Storage／Durable Reduced Availability（DRA）Storage／Nearline Storage
- 57. 補足）クラウドの利用料金を下げる（２） 57 CDNサービスの活⽤ Webサイトで静的コンテンツへのアクセスが多い場合、インスタンスのスケールアウトをするより、オブ ジェクトストレージ＋CDNサービスを活⽤することで費⽤が下がる。また、CDNは全世界にあるキャッ シュサーバから配信がされるためWebサイトの⾼速化も期待できる。 ü AWSの場合 S3 + CloudFront ü SoftLayerの場合 ObjectStroge+CDNサービス ü Azureの場合 BLOBストレージ+Azure CDN リザーブドインスタンスの活⽤ Ø AWSでは⻑期(1年 or 3年)利⽤をコミットすることで最⼤ 75%オフで利⽤。費⽤削減だけでなくキャ パシティ予約ができる(予約分のインスタンスを起動できる保証)メリットもある。 Ø Microsoft Azureでは、Enterprise Agreementという先払い式で価格表が変化する⽀払い形態がある。 これは全てのリリースに適⽤される。 プリエンプティブルVMの活⽤ GCPでは連続稼働保証がなく、クラウド側の都合によっていつでも停⽌させられるプリエンプティブルVM がある。プリエンプティブルVMは連続稼働保証がない点を除けば、性能や可⽤性などは通常のVMと同じ。 最⼤70%安くなる。 国内のリージョンを変えて費⽤を抑える Azureは東⽇本リージョンと⻄⽇本リージョンでは時間あたりの料⾦が異なる。例えば、A7インスタンス (Windows)の場合(⽉額従量料⾦は、連続使⽤ 744 時間として⾒積もり) Ø 東⽇本は〜 ¥106,284/⽉ Ø ⻄⽇本は〜 ¥ 94,146/⽉
- 58. 検討時の考慮事項 – まとめ ü 試算するコストの漏れ抜けに注意 – データセンター費⽤、電気代、空調費など チェックリストを活⽤して漏れ抜け防⽌ ü 利⽤の繁忙期、閑散期を意識してサイジング – 閑散期に縮退できるシステムは積極的に検討し、 クラウドの利点を活⽤ ü ⾃前で構築すべきかどうかを⾒極める – SaaS, PaaSを活⽤して管理コスト削減 ü ライセンスはクラウド対応かどうかを確認 – 移⾏できない場合あり。事前の調査が重要 58
- 59. 調達
- 61. 契約方法 61 ü クレジットカードで申込むとすぐに環境が使えるようになるので、SIer の作業開始の前⽇に登録を⾏った。しかし、何故かクレジットカードの 審査が通らないという。同カードは、別件で正常に使えているのに。 ü クラウドベンダーとの英語でのやりとりで、なかなか進展せず、SIerに アカウント情報を渡さないといけないのにもう間に合わない。 ü 夜中にリモートで申込みして、会社にかかってきた確認の電話に出れな かった など クラウド環境にサーバーを構築する前にやるべきこと → クラウドサービスに申し込んで、アカウントを取得する」 準備するもの ü 会社のクレジットカード情報 ü 電話で英語対応可能な⼈（SoftLayerの場合） 確認すること ü 会社はクレジットカードでの⽀払いが問題ないか？ ü ドル請求は対応可能か？（Azureは円も対応） ü 電話での確認／問合せに英語で対応できる⼈がいる？（SoftLayerの場合） → 上記が⼀つでもNGな場合は、「請求代⾏サービス」を利⽤する。 ü 請求書の円払い、⽉末締めで処理したい場合は、このサービスで対応してくれる。
- 62. ベンダー選定 62 ü A社と詰めていた内容をB社に伝えて相⾒積もりをお願いした。B社 の⽅が⼤幅に安いのでB社に発注。 ü B社構築後、A社と合意していた内容までやっていないことが、納品 後に発覚。 ü B社に確認したところ、それは別⾒積とのこと。実は、トータルでA 社の⽅が安かった。 何を基準にベンダーを選定すれば良いのか Ø 検討の段階から⽀援してくれるか？ Ø クラウド環境の構築経験があるか？ ü 4⼤クラウドのいずれかの経験があれば、他のクラウドもほとんど対応可能。 ü 実績がないSIerに依頼する時は、SIerの事前調査費⽤（お勉強費⽤）やリス ク費⽤までのせられないように気を付ける。 ü ⼿間ではあるが、3社くらいに相⾒積もりをとって判断する。 ※（クラウドに限った話ではないが）相⾒積もりの場合、⾒積の範囲が異なる場合があるので 要注意。作業詳細をもらい、作業内容を⽐較する。
- 63. ベンダー選定（参考） 63 A社 ： 600万円 B社 ： 490万円 ファイルサーバー移⾏作業⼀式 Ø Active Directory導⼊ Ø ファイルサーバー単純移⾏ （ディレクトリ構成は現状維持） Ø ⽤途別にファイルサーバーを分割 Ø バックアップサーバー導⼊ Ø 共有フォルダのボリュームシャド ウコピー機能導⼊ Ø WSUSサーバー移⾏ （グループポリシーによる⾃動設定） Ø ディレクトリ構成の再設計 Ø 変更後の構成へのデータ移⾏ （フォルダ移動） ファイルサーバー移⾏作業⼀式 実は、以下の2項⽬は対象外 後から 追加依頼したら ＋240万円 Ø ディレクトリ構成の再設計 Ø 変更後の構成へのデータ移⾏ （フォルダ移動） 合計： 710万円
- 64. 調達時の検討事項 – まとめ ü費⽤の⽀払⽅法 – 会社のクレジットカードが利⽤可能か – クレジットカードの登録は余裕をもって – 英語の対応がある可能性あり – 請求代⾏サービスの検討 üベンダー選定 – SOW（statement/Scope of work / 作業範 囲記述書）をしっかり – 合⾒積の場合は提案レベルの差に注意 64
- 65. 調達時の検討事項 SOW(Statement/Scope of Work)の例 65 作業内容 担当 期間 基本設計 A社 詳細設計 A社 クラウドのオーダー ⾃社（担当：XXさん） ネットワーク設定 ロードバランサー/ファイアーウォール VPN B社 B社 OS設定 OS ミドルウェア/アプリケーション A社 C社 ストレージ設定/データベース設定 A社 バックアップ A社 システムテスト A社/⾃社
- 66. 構築
- 67. 構築時の注意事項 ü 各種⼿続きのリードタイム ü クラウドのオーダー ü パフォーマンス ü 監視 ü 権限設定 ü セキュリティ ü そのほか 67
- 68. 早めの社内申請や付帯手続き 68 ü T担当者「本社のIT部⾨が管理（または外部へ委託）していて、今⽇ 申請したんですが、数⽇かかります。」 ü SIer「切替作業できませんよ。」 ※DNS設定実施⽇が⽉2回の固定という会社もある。 今までの感覚でやっていると構築作業に間に合わない オンプレでは発注してからハードウェアが届く間の2週間〜1ヶ⽉という期間が、クラ ウドになると0⽇になる。 Ø DNSの切替 ü DNS申請に関して事前に把握しておく p DNSの管理者 p 申請⽅法 p 申請から実施までの⽇数 Ø SSL証明書 ü SSL証明書は事前に検討＆購⼊準備をしておく p SSL証明書の価格は提供元によって違うので、⽐較して選定しておくのがお勧め。 p クラウドベンダーでSSL証明書を有償オプションで提供しているところもあるが、 安くはない。 SIer「サーバーに設定するのでSSL証明書の情報ください。」 IT担当者「あー、これから買います。ちなみに今はいくらくらいで買え ますか？どこで買うのがお勧めですか？」 SIer「https設定＆接続確認作業は後⽇で・・・」 ※検討＆購⼊申請に数⽇かかる会社もある。
- 72. 監視設計 72 監視機能はクラウドサービスが提供する標準監視だけで⼤丈夫？ クラウドサービスに標準監視はついているが・・・ クラウドサービスの標準監視 Ø 標準でPING監視などついているが、品質がよくないクラウドベンダーもあるため 通知がしっかりと機能するか確認する Ø 重要なシステムには個別で監視システムを検討する ※クラウドサービス標準監視以外の拡張した監視はインターネット経由でないと監視ができない ※従来のデータセンター内部の専⽤ネットワークからの監視は対応していない Ø DirectLinkなどで専⽤回線経由での監視を検討する。その際、監視ベンダーへも回 線をひく必要ある。
- 74. セキュリティを考慮 74 とんでもない請求額が来たので、確認したら通信料がすごいことに。 → サーバーを乗っ取られて、⼤量の通信が発⽣していた。 クラウド環境はパブリックからアクセスできて便利だが・・・ アクセス制御 Ø インスタンスオーダー後、アクセス制御は個別設定する必要がある。 Ø SoftLayerはフルオープン、その他のクラウドも22番が空いているのでアクセス元 制御をかける必要あり。 Ø 多くのパブリッククラウドでは、課⾦が⼀定額以上に達したらメール通知する機能 ある為、設定をしておくと安⼼。 Ø SoftLayerでは、アタックされた費⽤は請求されない様にする保険（$5）を設定す ることが可能。 テスト⽤なのであまりセキュリティを気にせず、アクセス元制御をかけ ていなかった。 → 「DNS Amp Attack」の踏み台にされてしまい、攻撃を受けて いる会社からクレームが来てしまった。
- 76. 構築時の注意事項 – まとめ ü各種⼿続きのリードタイム – 社内外ともに、⼿続きに時間を要するものがある。 事前に確認、余裕をもって対応 üクラウドのオーダー – オーダー後すぐに利⽤できないサービスもあり。 事前に確認 – オーダー内容と構成が異なる可能性あり。事前調 整が必要なものもある üパフォーマンス – 達成すべきパフォーマンス要件を満たせない場合 は占有型の検討を 76
- 77. 構築時の注意事項 – まとめ ü監視 – 死活監視、リソース監視を意識しよう。死活監視 はクラウド側で標準提供のものもある – サービスによっては独⾃に監視を構築 ü権限設定 – 誤操作防⽌ üセキュリティ – クラウドはインターネットに接続されていること を意識し、適切に対策しよう üそのほか – クラウド標準のインターフェイスは変わる可能性 あり 77
- 79. 運⽤
- 80. 早めの社内申請や付帯手続き 80 ハイパーバイザーの脆弱性対応で、再起動祭り。SoftLayerは、データ センターごとに再起動がかかる。 各クラウドに合わせた冗⻑構成を検討 クラウド環境はハイパーバイザーが冗⻑化されているなど、なるべく停⽌しない作り になっているが、100％とまらないわけではない Ø SoftLayerの場合 ：データセンターをわける Ø Azureの場合 ：可⽤性セットというグループ化をすることで、サーバーが同 時に落ちない様に設定可能、更にBCP対策が必要な場合は、更にリージョンを分け ることも可能 Ø AWSの場合 ：複数のAZにインスタンスを設置する Ø GCPの場合 ：複数のAZにインスタンスを設置する ネットワークのメンテナンスで、⼀時的にサーバー使⽤停⽌になった。
- 81. 運用に関する補足事項 停⽌のたびにIPが変更される → 固定IPアドレスのサービスが提供されているので、別途購⼊する。 開発の⽅にテストサーバーを次々建てられて、とんでもない⾦額になる → サーバーを建てられるアカウント権限を制限する 不要になったテストサーバー削除のためにインスタンスは消したけど、付随するサー ビスの消し忘れで余計な課⾦が発⽣（Storage、Public IP） → オーケストレーションツールを⼊れる → 教育の徹底
- 83. クラウドSierとしての⼼得
- 84. クラウドSIerとしての心得 • まずは提案するサービスに精通する → 従来型のSIと変わらない。各種トレーニングを活⽤ → クラウドベンダーによっては認定資格を設けているところもある → ただし「クラウドができます」だけでは仕事は来ない。 SIベンダならでは魅⼒の訴求は必要。 • 短納期に慣れる → 通常3ヶ⽉程度で案件クローズ。短い場合は１ヶ⽉の場合も → ⽇々の状況整理が重要 → 朝会、⼣会、チケットシステム、カンバンなどでできるだけメンバーの負荷軽減を • アジャイル型のプロジェクト運営に慣れる → 契約としては準委任契約が⼀般的 → ただし書籍にあるようなアジャイルでは返って緩すぎてお客様の不審を招く 従来のSIのように定例会、成果物を意識しながら柔軟な要件の変化に対応する
- 89. 短納期に慣れる 89 【用語解説】 ○ プロダクトオーナー： 製品（もしくはプロジェクト）に責任を持つ立場 お客様と接する立場であるが営業とは異なる。 ○ スクラムマスター： プロジェクトの進行に責任を持つ
- 90. 短納期に慣れる 90 • 短納期に慣れる → 通常3ヶ⽉程度で案件クローズ。短い場合は１ヶ⽉の場合も → ⽇々の状況整理が重要 → 朝会、⼣会、チケットシステム、カンバンなどでできるだけメンバーの負荷軽減を 朝会(デイリー・スタンドアップ)の例： ○ 毎日必ず定時に開始 ○ 昨日の作業結果、今日の作業予定 ○ 短い時間で終了 ○ 問題点の共有
- 91. 短納期に慣れる 91 • 短納期に慣れる → 通常3ヶ⽉程度で案件クローズ。短い場合は１ヶ⽉の場合も → ⽇々の状況整理が重要 → 朝会、⼣会、チケットシステム、カンバンなどでできるだけメンバーの負荷軽減を かんばんの例：
- 92. 短納期に慣れる 92 • アジャイルは既にWeb企業だけの手法ではない – KDDI株式会社 http://www.slideshare.net/KDDI_official/2015-47850795 – Microsoft http://simplearchitect.hatenablog.com/entry/2016/08/22/ 080010 – 国内でも大手製造業などでトライアルプロジェクトが進行 中 • メリットは“納期の短縮”。 • いままで1年の開発期間->3ヶ月に
- 93. 短納期に慣れる 93 • ではどうするか – MS Officeを捨ててください • Google AppsもしくはOffice 365 を使ってください – 社内のファイルサーバを捨ててください • Google Drive/BOX/Dropboxを使ってください – メールを捨ててください • Skype/Slackを使ってください – Excel/MS Projectのプロジェクト管理を捨ててください • Redmine/Atllasian Confluenceを使ってください – 社内のソースコード管理サーバを捨てて下さい • GitHub/Bitbucketを使ってください – 社内検証サーバを捨ててください • パブリッククラウドを使ってください – 私用のスマートフォンで”どこでも”仕事をさせてください 上記を実現するために、ルールを変えてください
- 94. まとめ
- 95. 予算はどう変わるのか 95 データセンター or ⾃社のサーバールーム 「資産」から「経費」への転換 l プログラム・ライセンス（経費） l プログラム・サポート（経費） l 運⽤管理/派遣（経費） l システム開発（資産） l ハードウェア資産（資産） l サブスクリプション（経費） l システム開発（資産） l マネージド・サービス（経費） 経費は⼯夫と改善で 継続的に削減可能
- 96. クラウド時代の情報システム人材の活かし方 96 戦略・企画 業務分析 システム設計 アプリケーション開発 インフラ プラットフォーム構築 保守 運⽤管理 ヘルプデスク 現場サポート 戦略・企画 業務分析 システム設計 アプリケーション開発 「攻めのIT活⽤」拡⼤ インフラ・プラットフォーム構築 保守 運⽤管理 ヘルプデスク 現場サポート Ø 情報システム部⾨の機能と役割を再定義 Ø 経営企画や業務戦略スタッフとの⼈材交流 Ø 業務部⾨との⼈材交流 Ø アジャイル開発 Ø ⾼速開発ツールやPaaSの活⽤ Ø SaaSの活⽤ Ø シチズン・デベロッパーの育成 Ø ホステッド・プライベートクラウド Ø ⾃動化 Ø DevOps Ø ⾼速開発ツールやPaaSの活⽤ Ø SaaSの活⽤ システム・アーキテクト ビジネス・アーキテクト ビジネス価値を明らかにし、最適なビジネス・プロセ ス描き、それを実現するシステムをデザインする。 テクノロジーやサービスに精通し、それらを⽬利きで き、最適なシステムをデザインする。
- 97. 97 これからのビジネス戦略
- 100. UBERとTaxi 100 Taxi l タクシー資産 l コールセンター運営経費 l 施設維持管理 l 事務・管理経費 など ドライバー収⼊ 運賃 UBER l アプリ開発・保守費 l クラウド利⽤量など ドライバー収⼊ 機械を前提とした ビジネスプロセス の最適化 ⼈間を前提とした ビジネスプロセス の最適化
- 101. ハブ型社会からメッシュ型社会へ 101 メッシュ型社会 ハブ型社会 l 情報の⾮対称性・権⼒の偏在 l 情報伝達に伴うタイムラグの拡⼤ l 仲介による情報伝達コストの増加 l 情報の双⽅向性・権⼒の分散 l 情報伝達に伴うタイムラグが発⽣せず l 仲介を無くすことで情報伝達コストが低減 シェアリング・エコノミー ホスティング・エコノミー 安い社会コストとフラット化 ⾼い社会コストと階級化
- 102. ビジネスの変⾰を牽引するビジネス・トレンド 2016 ク ラ ウ ド ・ ネ イ テ ィ ブ アンビエントIT デジタル トランス フォーメーション デジタル ディスラプション サーバーレス ⾃動化・⾃律化 Internet of Things DevOps サイバー・セキュリティ & ガバナンス 様々なアクティビティをデ ジタルで捉え、アナログな 現実正解を動かす仕組み ⼈⼯知能やロボッ トにより、⼈間の 知的・⾁体的労働 を代替する仕組み コンテナやAPIエコノミー など、サーバの存在を意識 させない開発・実⾏環境 運⽤管理の⾃動化、PaaSや 超⾼速開発ツールを駆使し た開発と運⽤の新たな関係 の構築 クラウドやIoT、モバイルや ウェアラブルなど、社内外 の境界を越えた利⽤環境を 前提とした統合認証基盤や 上流から考えるアプリケー ション・セキュリティなど の視点を重視 テクノロジーで既存のビジネス・プロセスを変⾰ 効率化のためのITから差別化のためのITへのパラダイムシフト
- 103. お問い合わせ 103 クリエーションライン株式会社 http://www.creationline.com/ info@creationline.com ネットコマース株式会社 http://www.netcommerce.co.jp/ saito@netcommerce.co.jp l 情報システム部門の戦略策定支援 l ITベンダーの事業戦略策定支援 l テクノロジーや営業スキル育成研修 など l クラウドインテグレーション l クラウドプラットフォームの構築 l OSS等を活かしたシステム開発 など