ハイブリッド・クラウド における 守りのアーキテクチャ エンタープライズ・アーキテクチャ 日本オラクル株式会社 エンタープライズ・アーキテクト本部 エンタープライズ・アーキテクト 小野沢 博文 森 浩徳 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | • 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明する ものです。また、情報提供を唯一の目的とするものであり、いかなる契約 にも組み込むことはできません。以下の事項は、マテリアルやコード、機 能を提供することをコミットメント（確約）するものではないため、購買決定 を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ れている機能の開発、リリースおよび時期については、弊社の裁量により 決定されます。 OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。 文中の社名、商品名等は各社の商標または登録商標である場合があります。 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 2 企業はクラウドに何を期待しているのか？ ～ クラウドを活用したいシステム環境 ～ あらゆる環境への適用の期待が高まっている 本番環境 開発環境 テスト環境 Public (n=246) バックアップ環境 Private (n=308) パフォーマンステスト環境 教育環境 0 20 40 60 100 (%) 80 Note: 対象企業は年商100億円以上、従業員500人以上 出典：ITR, IT需要動向調査（2014年3月調査） Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 3 企業はクラウドに何を期待しているのか？ 企業ITの役割の変化 ビジネス環境の変化 企業変革の推進役 グローバル・ビジネスとカントリー・リスク コスト･プレッシャー 急変する経済環境への対応 IT組織自体も コモディティ化により、 安いもの／安いサービスしか売れない 市場構造の変化 安定成長の市場では 限られたパイの奪い合い。 新興市場では先行者利益獲得競争 より速く、より安く、 そして、失敗の負荷を最小に デバイス／ネットワーク より速く、より安く、よりグローバルへ ビジネスの試行錯誤をサポート より速く、より安く、よりグローバルへ モバイル化の進展、スマート○○、全てのものがネットアタッチへ Hardware, Hypervisor, OS, Database, Middleware → クラウド化を志向した技術の台頭 仮想化、マルチテナント、大容量高速ストレージ、エンジニアード・システム 技術環境の変化 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 4 クラウドに対する懸念 大きな企業リスクになりえる ー どのように守るのか セキュリティ 可用性 拡張性 Public (n=616) 障害切り分け Private (n=615) 運用費用 投資対効果 0 20 40 60 80 100 (%) 対象企業：年商100億円以上、従業員500人以上 出典：ITR, IT需要動向調査（2014年3月調査） Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 5 エンタープライズ・アーキテクチャとクラウド 2005年頃～ 2010年頃～ ビジネス・イノベーション プロセスの標準化 と柔軟性確保 1990年代後半～ 主要アプリケーションが レガシー環境で運用 1980年代～ MDM,DHW クラウドの活用 M&A、グローバリゼーション、 ビジネス環境変化に迅速対応 BPRと グローバル・ビジネス リアルタイム・コントロール DHW 1990年代前半～ 現場業務の効率改善 バックオフィス業務 の電算化 BPM & SOA 変化対応力の 強化を指向 ERP/SCM グローバルレベルで 情報を一元管理 コントロールを指向 各事業、各部門が 個別にシステムを導入 第一次 EAブーム メインフレーム・コンピューティング期 ？ クラウド・コンピューティング期 オープン・システム・コンピューティング期 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 6 第一次EAブームの頃に何がおきていたか？ 2005年頃～ 2010年頃～ ビジネス・イノベーション プロセスの標準化 と柔軟性確保 MDM,DHW 1990年代後半～ 主要アプリケーションが レガシー環境で運用 1980年代～ DHW 1990年代前半～ 現場業務の効率改善 バックオフィス業務 の電算化 BPM & SOA 変化対応力の 強化を指向 ERP/SCM グローバルレベルで 情報を一元管理 コントロールを指向 各事業、各部門が 個別にシステムを導入 主要アプリケーションが レガシー環境で運用 クラウドの活用 M&A、グローバリゼーション、 ビジネス環境変化に迅速対応 BPRと グローバル・ビジネス リアルタイムコントロール グローバル化 を理由に無統制な インスタンス展開 数量的には 最大勢力 暫減するも 今なお残存 第一次 EAブーム 非効率さと 老朽化が IT部門を 苦しめていた Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 7 第一次EAブームの頃に何がおきていたか？ オープン・システムの功罪： ビジネス効果とITのスプロール化（無秩序な拡大） オープン・システムは、 情報システムを劇的に低廉化し、 ビジネスの隅々までIT化が進展。 業務の効率化や、 チャネルの拡大に 大きな効果をもたらした 一方、多種多様なHW・OS・MW・ アプリケーションが企業内に存在し、 運用コストの大幅な増大を招いた Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 8 ビジネスの“スピード”が命のクラウドを統制するべきか？ 無統制なオープン・システムの展開 無統制なクラウドの利用 IaaS SaaS PaaS SaaS PaaS PaaS IaaS PaaS SaaS IaaS IaaS SaaS IaaS SaaS PaaS IaaS PaaS 「つくる」のサイロ化 「つかう」のサイロ化 システムとその構成要素の数と種類からくる複雑さが、 ビジネス・スピードを阻害し、コスト増 サービスの数と種類からくる複雑さが、 結局はビジネス・スピードを阻害し、コスト増 ITガバナンスの一貫としてEA活動を必要とした クラウド利用にもエンタープライズ・アーキテクト の関与が必須である Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 9 エンタープライズ・アーキテクチャとしてのクラウド 実需に基づく Public Cloud の調達を含む、内需向けクラウド・サービス・ポートフォリオと、その利用のアーキテクチャがカギ 社内 外部プロバイダ IT部門 利用者部門 SaaS パッ ケー ジ 需要 IaaS Customer 提供 需要 Customer 提供 S ビジネスサービス ポートフォリオ S PaaS 調達 SaaS (Public Cloud) 調達 PaaS (Public Cloud) 調達 IaaS (Public Cloud) 自社クラウド サービス 提供 クラウドサービス ポートフォリオ S 内製アプ リ (カスタ マイズ) Customer 提供 クラウド・サービス ビジネスITサービス 需要 PaaS IaaS 需要 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 10 エンタープライズ・アーキテクトが押さえるべきこと クラウド化により「コントロールできなくなること」、 「コントロールしにくくなること」を見極める リスクに応じて、これらへの対処を決定する リ ス ク の 発 生 可 能 性 リスク回避 （クラウドを選択しない） リスク低減 （クラウド事業者の選択や何らかのメカニズムで補う） リスク保有 （受容する） リスク移転 （クラウド事業者に移転） リスク発生時の影響度 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 11 クラウド化で自らコントロール可能な範囲は狭まる 従来環境 （非共有） プライベート プライベート パブリック パブリック パブリック IaaS PaaS IaaS PaaS SaaS アプリケーション アプリごとに コントロール 可能 ミドルウェア アプリごとに コントロール 可能 自社で コントロール 可能 自社で コントロール 可能 アプリごとに コントロール 可能 OS ハイパーバイザ ハードウェア アプリごとに コントロール 不可 アプリごとに コントロール 不可 自社で コントロール 不可 自社で コントロール 不可 自社でコント ロール可能 自社で コントロール 不可 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 12 アーキテクチャ上考慮すべき 主要なコントロール・ポイント セキュリティ • 事業者ごとにバラバラなセキュリティ・ポリシーとセキュリティ対策 • 自社ID管理との連携、社内アプリやパブリック・クラウド・アプリとのSSO 可用性 • 事業者ごとにバラバラな可用性レベルと技術方式 • 特にデータ消失への対策 データ連携 • 社内システムとパブリック・クラウドに跨るデータ連携のスパゲティ化 責任分界 • クラウド事業者との責任分界（役割、作業分担、損害発生時の賠償等） ライフサイクル • サービス提供・利用のライフサイクルが相互に連携する構造となり、 自社だけでは完結しない • サービス・ポートフォリオの単純化に不可欠なサービス廃止と利用側へのインパクト Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 13 主要なコントロール・ポイント セキュリティ • 各情報資産の機密性(C)、完全性(I)、可用性(A)に関する 格付けとリスクアセスメントを実施し、セキュリティ要件を明確にする （従来の社内システムと同様） • その上で、「コントロールできなく（しにくく）なること」への対処を検討する ① 情報資産の格付けに応じた十分な対策をクラウド事業者が実施しているか ② 特に、事業者内部の不正対策 ③ 自社ID管理との連携、社内アプリやパブリック・クラウド・アプリとのSSO ID連携とSSO 利用者 安 全 な ア ク セ ス 事業者ごとに異なる セキュリティ・ポリシーと対策 情報資産 機密性: 低 情報資産 機密性: 中 情報資産 機密性: 高 事業者内部の不正対策 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 14 主要なコントロール・ポイント セキュリティ － 事業者内部の不正対策 • 管理者の不正による情報漏洩・改竄のリスクが特に高いが、 クラウド事業者の管理者のモラルはコントロール範囲外 • 特に格付けの高い情報資産に対しては、 管理者によるアクセスを技術的に防止できているかを確認 ネットワーク管理者 サーバ管理者 DBファイルへの 直接アクセス DBの暗号化 盗 聴 暗号化 ア ク セ ス 制 御 情報資産 機密性: 高 完全性: 高 可用性: 高 特 権 者 分 掌 DB Aロールでの SQL発行 DB管理者 監査 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 15 主要なコントロール・ポイント セキュリティ － ID連携とSSO • 利用者の利便性とID管理の一元化／管理負荷軽減を両立するため、 社内アプリとパブリック・クラウド・アプリを跨ったID連携とSSOを検討する 社内システム パブリック・クラウド ID情報 プロビジョニング ID情報 プロビジョニング API ID情報 認証 アサーション 社内アプリ 認証サーバ アプリ 認証 利用 利用 利用者 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 16 主要なコントロール・ポイント 可用性 • 各業務の可用性/事業継続性要件を明確にする（従来の社内システムと同様） • その上で、「コントロールできなく（しにくく）なること」への対処を検討する ① 可用性/事業継続性要件に応じた十分な対策を、クラウド事業者が実施しているか - SLAの数値だけでなく、可能な限り技術方式まで確認 ② 特にデータ消失への対策が重要 ネットワーク二重化 Web/APサーバ ACT-ACT ネットワーク二重化 Web/APサーバ ACT-ACT 同期 or 非同期 DBサーバ ACT-ACT or ACT-SBY DBレプリケーション or ストレージ・レプリケーション DBサーバ ACT-ACT or ACT-SBY ストレージ RAID ストレージ RAID プライマリー・サイト DRサイトの有無 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 17 主要なコントロール・ポイント 可用性 － データ消失への対策 • 主な確認事項 –バックアップ方式 • フル or 増分？ • 取得間隔は？ • バックアップデータの所在は？ –RPO（目標復旧ポイント）は？ –リストア方式 • 任意時点に戻れるか？ –データ破損対策は？ プライマリー・サイト 遠隔地 別筐体 DRサイト 筐体内 × Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 18 主要なコントロール・ポイント データ連携 • 事業者ごとに異なる独自連携APIとアドホックなポイント・ツー・ポイント連携 社内システムとパブリック・クラウドに跨るデータ連携のスパゲティ化 パブリック・クラウド 社内システム Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 19 主要なコントロール・ポイント データ連携 － iPaaSによる連携の簡素化 • パブリック iPaaS という選択 –パブリック・クラウドの 比重が高い企業に有利 • プライベート iPaaS という選択 –社内システムの 比重が高い企業に有利 パブリック iPaaS パブリック iPaaS 社内 社内 iPaaS: Integration Platform as a Service Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 20 主要なコントロール・ポイント ライフサイクル – まずはライフサイクル構造を認識する サービス利用 サービス提供 サービス ポートフォリオ Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 21 サービス・ポートフォリオ、サービス提供のライフサイクル サービス企画～構築フェーズ 需要分析 サービス ポートフォリオ管理 （計画） カタログ管理 設計 構築・テスト モニタリング 請求 サービス レベル管理 サービス提供フェーズ 需要管理 プールに展開 再プール プロビジョン アシュアランス （保守作業・ サービスデスク） サービス ポートフォリオ管理 （廃止管理） 廃止・更新 22 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | サービス利用のライフサイクル 《これまでのITライフサイクル構造》 システム別垂直統合方式 サービス利用のライフサイクル 選択 リクエスト IT投資全般を コントロールする ガバナンス 消費 サービス利用の ライフサイクル （ビジネス案件） 使用 支払 ビジネス 案件 ビジネス 案件 ビジネス 案件 各案件ごとに、アプリ・連携方式・MW・DB・ システムインフラ全体を垂直統合した 単純なライフサイクル構造であった。 各案件（システム）単位で 個別のライフサイクルをもっていた 返却 サービス利用型になると、 ビジネス案件は個別に発注・構築するなどの 手間がなくなり、 オンデマンドで利用が可能となる Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | ライフサイクル構造 利用と提供の間に ・・・ サービスの提供側（IaaS、PaaS ならインフラ側）と、 サービスの消費側（アプリ側）、 廃止管理 さらにサービス・ポートフォリオ（サービスの品揃え）の ライフサイクルは互いに連鎖・協調し、 かつ独立したライフサイクル構造になります。 これらの協調関係が崩れると、大きな一時コストの発生か、 資産・運用の大きなムダのどちらかが発生します。 需要分析 サービス ポートフォリオの ライフサイクル カタログ 管理 需要管理 選択 クラウドを活用するためには、 これらの関係を意識して クラウド・サービス自体の 世代をコントロールして いかなければなりません 計画 プールに展開 リクエスト IT投資全般を コントロールする IT投資全般を 消費 ガバナンス コントロールする サービス利用の ガバナンス ライフサイクル （ビジネス案件） 使用 支払 プロビジョン 構築・テスト アシュアランス サービス提供の ライフサイクル モニタ・請求 強制退去 返却 設計 廃止 再プール 24 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | ライフサイクルコントロール – ①サービス環境戦略配備 PaaSの場合 •テクノロジーライフサイクルを考慮して 同時２世代のプラットフォームを準備することで、 PaaS化に伴うライフサイクル面での課題を軽減する 第1世代 AP1 順次調達型 調達時点で最新バージョンを 組み合わせたプラットフォーム AP2 第2世代 AP3 第3世代 AP4 第4世代 AP5 ① プラットフォームの最長寿命を定義する ② 世代の中では Architecture, Model, Major Versionを １つにする ③ ２－３年ごとに定期的に技術的スタックを検討する ④ 世代間で移行性を考慮する ⑤ メインのプラットフォームを同時２世代で構成する ⑥ 各世代の中ではパッチ適用や テスト効率化のスキームを確立する •ITインフラ集約化をさらに促進するために、 上記の原則をベースとした 全体プラットフォームライフサイクルの検討を進める AP6 第5世代 第6世代 旧技術を利用するリスク 論理的な理想系 第1世代 AP1 AP2 AP3 AP4 第2世代 AP5 AP6 第1世代EOSL時にAP移行が集中 第1世代 AP1 AP2 AP3 現実的な解決策 利用技術の定期活用 第2世代 AP4 AP5 第3世代 AP6 AP移行の時期の分散 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 25 ライフサイクルコントロール – ②戦略的マイグレーション マイグレーションのCoE化 Migration CoE 標準プロセス Common Processes 高スキル人材 Skilled People Platform Process Step 1 Process Step 2 Process Step 1 Process Step 3 Process Step 2 PROCESSED FAILED1 Risk Analyst(s) Process Step 4 COMPLETED FAILED2 Process Step 3 PROCESSED QUALITY PASSED END FAILED1 Process Step 4 COMPLETED FAILED2 QUALITY PASSED END Migration Architect(s) ベンダー 標準ガイド・ルール Product Specialist(s) Migration Staff Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 強 固 な ベ ン ダ ー リ レ ー シ ョ ン ベ ン ダ ー サ ポ ー ト ベ ン ダ ー 開 発 部 隊 26 26 戦略的マイグレーションの進化形 マイグレーションの工場化 Factory アプリケーションは、 プロジェクトの包括的な 管理と可視化を提供 人材: 移行専門家で 構成された 専属チーム 移行プロジェクトにフォーカスした 専属のFactoryチーム 柔軟なオンサイト／オフサイトモデル プロセス: 移行を実行するための プロセス志向な 手法 Migration Factory は、人材、プロセス、 インフラの適切な組み合わせにより、 顧客に最大の性能と価値を 最も低い価格帯とリスクで実現 25年間の移行実績に基づく、自動化され 再利用可能なツール OracleのUnified Method に基づく、 実証済みの手法 インフラ: 質の高いデリバリを担保する包括的 Migration Factory 管理ツール プロジェクトを完全に可視化する リアルタイムの Factory 管理ダッシュボード Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 27 27 Architecture Insight 検討カタログ IT変革の全体戦略・構想策定から、ソリューション・エリアに特化した検討まで、幅広いご支援が可能です IT全体スコープ IT Transformation IT変革の全体戦略・ 構想策定 ソリューション・エリア別 CX & Mobile Customer Experience & Mobile アプリケーション構造の最適化 レガシーアプリケーション刷新 顧客経験価値の最大化 モバイルの活用 Big Data & IoT Big Data & Internet of Things Enterprise Cloud Transformation IT全体戦略 クラウドの全体戦略・ 構想策定 構想策定 情報価値の最大化 ビッグデータの有効活用 EIM Enterprise Information Management 情報マネジメント強化 データ配置の最適化／マスターデータ管理 IT Optimization Enterprise Security IT基盤の統合・最適化・効率化 2015/4/13 Application Modernization 全社セキュリティ適正化 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | Confidential – Oracle Highly Restricted 28 ご質問・ご相談等ございましたら、終了後もお受けしております あなたにいちばん近いオラクル Oracle Direct 0120-155-096 （平日9:00-12:00 / 13:00-18:00） http://www.oracle.com/jp/direct/index.html Oracle Direct 検索 各種無償支援サービスもございます。 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. | 29 Copyright © 2014 Oracle and/or its affiliates. All rights reserved. |
© Copyright 2024 ExpyDoc
