Multitenant-based DBaaS architecture and strategy Oracle Database 12c Release 2 オラクル コーポレーションクラウド エバンジェリストトロイ アンソニー (Troy Anthony) Copyright 2016 Oracle and/or its affiliates. All rights reserved.
以下の事項は 弊社の一般的な製品の方向性に関する概要を説明するものです また 情報提供を唯一の目的とするものであり いかなる契約にも組み込むことはできません 以下の事項は マテリアルやコード 機能を提供することをコミットメント ( 確約 ) するものではないため 購買決定を行う際の判断材料になさらないで下さい オラクル製品に関して記載されている機能の開発 リリースおよび時期については 弊社の裁量により決定されます Oracle と Java は Oracle Corporation 及びその子会社 関連会社の米国及びその他の国における登録商標です 文中の社名 商品名等は各社の商標または登録商標である場合があります 2
Oracle Database 12c Release 2 をクラウドで提供 現在提供中 Exadata Express Cloud Service 11 月提供予定 Enterprise Cloud Service Exadata Cloud Service 12 月提供予定 Exadata Cloud Machine 3
It s Still a Journey 4
It is a Journey 機能のステージ 従来のサイロ標準化プラットフォーム統合化プラットフォーム サービス提供プラットフォーム エンタープライズ クラウド プラットフォーム 物理 専用 & ヘテロジニアス ( 異種 ) 静的で分断された分析 ハードウェアとソフトウェア スタックを標準化 標準デプロイメント構成 データベース サービスとサービス レベルのカタログ 共有 & セキュアな中央データ インフラストラクチャ 動的な最適化 & リソース管理 自動システム管理 オンデマンド 弾力 区分を持ったセルフ サービス 迅速なサービス拡張と自動化 計測 自動コスト割当 & チャージバック 完全に動的かつ統合されたリソース プール IT as cloud broker: 調停と仲介 セキュアなハイブリッド クラウド統合 ( ベンダー パートナー など ) サイロ化 標準化 統合化プライベート DBaaS フェデレイティッド DBaaS 低リスク低 OpEx 低 CapEx 高アジリティ完全に最適化 5
ハイブリッド クラウドとは? 6
ハイブリッド クラウドとは? ハイブリッド クラウド オンプレミスクラウド UAT UAT 本番 本番 開発テスト 2 つ以上のクラウドの組み合わせ ワークロードをオンプレミスとパブリック クラウドに跨ぐことができる 7
ハイブリッド デプロイメントの 3 つのタイプ 8
Program Agenda with Highlight 1 2 3 4 5 ハイブリッド クラウドの定義計画デプロイメント操作重要ポイント 9
どのタイプのクラウドを採用すべきか? パブリック? プライベートのみ? ハイブリッド? 10
多くのお客様にとって ハイブリッドが広く普及しているモデル ( 特に企業向けにおいて ) 11
移行 or 変換? vs. 容易 今まで動いていたから今後も動く 減少のメリット 困難 長期 より大きな利点 課題解決のために必要 12
どちらも使えますが 本当に急いでいるのでなければ変換を検討してください 1. 移行ではなく 変換によって多くのコストを削減 2. 変換には標準化 簡素化 縮小が含まれる実際のいくつかのお客様における例 : 300 Oracle ホームを 2 Oracle ホームに 736 データベース ソフトウェア スタックを 10 以下に 9,085 データベースを 5,020 に 3. まず最初に移行を行う必要がある場合には 移行後 適切に合理化が計画されていることを確認してください 13
移行ステージング段階的なワークロードの展開 Low Hanging 新規デプロイメント本番複合ワークロード ミッション クリティカル 1 x 19 制約なし 即時候補となるプラットフォーム 35 37 34 28 26 23 13 10 2 25 3 11 29 24 2 3 4 5 6 7 8 x x x xx x x 20 21 22 23 24 25 26 ) xx 統合された環境へのワークロードの適合性は大きく変化します 簡単に移行できる対象を識別するための明確な基準を定義します 27 12 30 31 9 10 xx 27 28 早期の成功のために計画します 移行の制約 移行の見込みのない 21 7 5 22 17 33 15 32 16 8 9 36 長期的に候補となるプラットフォーム 18 14 4 6 11 12 13 14 15 16 17 18 x ワークロード凡例 29 30 31 32 33 34 35 36 x x x 37 x 移行を段階的にすることでリスクを軽減します 先に行った移行から得た教訓を以後の移行に活かします 複合ワークロードをホストするための柔軟なアーキテクチャを開発します 多くの制約 1 19 20 OLTP OLQP Not Ready プラットフォームの技術的な準備 Very Ready DW /BI Hybrid 14
DBaaS のための最適なデプロイメント モデルは? 15
どのデプロイメントにも長所と短所がある 専用フレックス - サイロ 区分占有 動的にリサイズ可能 カプセル化データベース 1 つの仮想環境内の専用データベース 専用データベース共有 OS 環境内の専用データベース プラガブル データベース共有データベースデプロイメント 統合密度増加 リソースの共有なし CPU ネットワークとストレージ容量を共有メモリをシーケンシャルに共有 OS メモリ リスナー ASM インスタンス GI 全てを共有 メモリ バックグラウンド プロセスを共有書き込みを効率的にバッチ化 16
経験から得た方法 : 可能な限り最も軽量なデプロイメントを使用する 17
統合密度は大きく異なりますか? マルチテナントは少ないリソース要件で最高の統合密度を実現 システム トランザクション CPU 使用率ストレージ IOPS スループットレスポンス時間合計 Physical Reads Physical Writes Redo log Writes 252 non-cdbs +80% 72,600 tps log file sync 7 ms same 68% -30% 36,900 r/s -25% 133,100 w/s -19x 101,400 w/s 252 PDBs 130,300 tps 10 ms 68% 25,400 r/s 100,400 w/s 5,400 w/s フォアグラウンド プロセスバックグラウンド プロセスプロセスプロセス数 CPU 消費プライベート メモリプロセス数 CPU 消費プライベート メモリ 252 non-cdbs 2,688 35% 50 GB 8,387 26% 149 GB +74% -92x -9x -75x 252 PDBs 2,688 60% 50 GB 91 3% 2 GB メモリ SGA PGA 合計データベースごとのメモリ フットプリント Buffer Cache Other Pools Processes Private 合計メモリ Buffer Cache とフォアグラウンドを除く 252 non-cdbs +30% 964 GB -6x 270 GB -4x 199 GB 1,433 GB -8x 1,702 MB 252 PDBs 1,250 GB 49 GB 52 GB 1,351 GB 208 MB 18
ケース スタディ : オーストラリア コモンウェルス銀行 (Commonwealth Bank of Australia) 19
CBA における OaaS の進化 オーストラリア コモンウェルス銀行 Exadata (OaaS v2) エンタープライズ - クラスの Sun サーバーのクラスタ CBA による統合 (CommSee, NetBank) コモディティ - クラスの Sun サーバーのクラスタ CBA により統合 (OaaS v1) 20
オーストラリア コモンウェルス銀行 OaaS イントロダクション 理想的な統合プラットフォーム あらかじめエンジニアリング済み! 事前構築の プラットフォーム サーバー または プライベート クラウド サーバー : 電源を入れるだけ最初の Exadata Machine が 2009 年 12 月に CBA に導入され さらに 2010 年 5 月に第二弾が導入される OaaS v2 へ移行された最初のアプリケーションは Peoplesoft Financials ビルトインの高可用性 : RAC ASM DG アプリケーション側で個々に実装するのはコストが掛かりすぎる OaaS v2 スキーマ統合 OaaS v4 マルチテナント 21
OaaS が運用の経済性を変える 多くの個別データベースを OaaS 上に統合 オーストラリア コモンウェルス銀行 データベース システムを集中管理 一貫性のある 標準化されたプラットフォーム サーバー および関連する運用コストの大幅な削減 運用の DBA 専門チームが アプリケーション データベースではなく OaaS プラットフォームを管理 伝統的なサイロ アプローチ プラットフォーム経済性 グリッド コンピューティング モデル アプリケーション数 22
どこでコスト削減できますか? オーストラリア コモンウェルス銀行 コスト削減エリア どのようにコストが削減されるか ハードウェア オペレーティング システム 3 rd パーティーソフトウェア ハードウェア要件を大幅に削減 : 低コストのサーバーをクラスタ化して 高価なサーバーを削除 その時必要なだけ購入 処理要件が増加した時点でスケール JIT オペレーティング システム ソフトウェア & メンテナンス費用を削減するために一つの OS ビルドを採用 多くの 3 rd パーティー ソフトウェアの必要性を最小限に抑えられるように標準的なデータベース ソフトウェア スタックの機能を活用例設計とソフトウェアを標準化 : システム管理 & 監視 レプリケーション / DR クラスタ ソフトウェア ファイル システム / ボリューム管理 保守 ハードウェア保守の削減 (24x7 サポートへの依存性を軽減 ) ソフトウェア保守の削減 (3 rd パーティ ソフトウェアや OS に対する ) 23
どこでコスト削減できますか? オーストラリア コモンウェルス銀行 コスト削減エリア どのようにコストが削減されるか 運用 管理対象の環境の数を削減 : 標準的な運用環境が運用コストを削減エンタープライズ管理ツール & プロセスの採用 : 手動で実行しているシステム管理タスクを自動化 標準的な運用手順をホストされているアプリケーション全体で活用 環境のガバナンスを改善 データベース 長期的なコスト削減機会 : 高い資産の使用率 => CPU 数の減少 => ライセンス料の削減 Oracle 環境の減少 => 運用タスクの削減 統合環境の管理に必要な FTE の減少 その他 プロジェクト コスト : プロジェクトに対して新しいデータベース環境をはるかに高速にプロビジョニング 新規の開発環境が週 / 月ではなく 数時間以内に利用可能に HA ソリューションはデザイン済み 製品は既に構築済み 24
オーストラリア コモンウェルス銀行 リスク削減 市場投入までの時間を改善 新規プロジェクトに対して : プロジェクトから一つフェーズを削減 あらかじめ最適化されたインフラストラクチャ 設計と構築のために高価 / 不足している SME 資源に対する依存を取り除きます もはや調達に関連するリスクを管理 構築する必要はなし 新たな本番品質環境のインスタンス化に要する時間 : 3 ヶ月 -> 2 分 例 : 私たちのオンライン株式取引プラットフォームへ新しく導入した ISV アプリケーション 2 年後に予測されるワークロードとデータ量という条件の下でパフォーマンスのテストが必要 専用インフラストラクチャ OaaS 実行時間 3-4 ヶ月数時間 プロジェクトのコスト $ 数十万 $ < $10K プロジェクト終了時に使用率の低い資産が残る環境をオフ 25
オーストラリア コモンウェルス銀行 マルチテナント vs スキーマ統合 at CBA クラウド 操作の観点から著しい管理上のメリット スキーマ統合と比べ テナント間のより良い分離性 本番からテストへ高速クローニング 26
PaaS 実装に関する考察 1. ビジネスに必要な正しい技術 / 商用ソリューションを入手するために時間を割く 異なる仮想化技術には異なる密度が 結果として異なる経済に 2. アプリケーション所有者から仕入れなければならない いつ どのようにアプリケーションを移行するか計画する 需要喚起には社内営業の役割が必要 3. 迅速な成功に注力 最も容易なアプリケーションから移行 / 提供する 4. ガバナンスと業務プロセス改善へ投資 技術ソリューションよりもはるかに多く 5. 明確 一貫性 正確な売り込み FUD ( 恐怖 不安 懸念 ) 要因に気を付ける ; 構想の多くが狂うことに 27
アプリケーションへの影響なしで計画メンテナンスを実施 継続的なサービスのため アクティブ / アクティブ構成を使用します 常にアプリケーション サービスを使用します ユーザー エクスペリエンスにフォーカスします スケジュールされたメンテナンスが始まるまでにアプリケーションの作業が完了するようにします アプリケーションへの変更なしで実装可能 サービス レベルでトランザクショナルに切断します 28
親和性およびローカルでのドレイン サイト間スイッチオーバー 本番サイト RAC オンライン ローリング メンテナンス スケーラビリティ サーバー HA RAC One オンライン ローリング メンテナンス サーバー HA Drain within RAC Fast Application Notification イベント通知, フェイルオーバー ロードバランス Application Continuity, Transaction Guard アプリケーション HA Global Data Services クロスサイト配置 スイッチオーバー ADG or GG Drain within RAC レプリカ Active Data Guard 計画スイッチオーバー データ保護 DR クエリ オフロード Data Guard 計画スイッチオーバー データ保護 DR GoldenGate 計画スイッチオーバー アクティブ - アクティブ レプリケーション ヘテロジニアス Sharding 大規模な OLTP 計画スイッチオーバー アクティブ - アクティブ レプリケーション ヘテロジニアス ( 異機種間 ) 29
ドレイン サービス サービスの位置透過性 RAC or RAC One Node 常にオン RAC インスタンス Node 1 Node 2 RAC インスタンス FAN: デフォルトでオン 自動構成 全アプリケーション 常に実行 30
メンテナンス 安全な場所でドレインを実行 事前にサービスを移動 アプリケーションからは透過的に接続を切り替え コネクション プール 接続テスト トランザクション境界 状態をリストアし 新規の接続を使用してトランザクションを継続 31
Keep it simple Stagger draining services # Jobs completed OLTP サービス利用 バッチ サービス利用 Seconds 32
Stagger Draining バッチおよびオンライン サービス 少なくとも二つのアプリケーション サービスを使用 オンラインおよびバッチ / バックグラウンド 最初にバッチに対してドレインを実行 続けてオンラインのドレインを実行 最初のインスタンス オンライン バッチ オンライン シャットダウン オンライン 3 時間の静止バッチ 60 秒間の静止 OLTP 完全なメンテナンス 最後のインスタンス オンライン バッチ オンライン シャットダウン オンライン 33
Application Continuity 実行中トランザクションの継続 リカバリ可能なエラー発生時には 実行中のトランザクションを再実行 ハードウェア ソフトウェア ネットワーク ストレージのエラーやタイムアウトをマスク 12.1 JDBC-Thin UCP WebLogic サーバー 3 rd パーティ Java アプリケーション サーバー RAC RAC One & Active Data Guard 34
Oracle Digital は オラクル製品の導入をご検討いただく際の総合窓口 電話とインターネットによるダイレクトなコニュニケーションで どんなお問い合わせにもすばやく対応します もちろん 無償 どんなことでも ご相談ください 35
36
37