Cloud Days Tokyo 2016ダウンロード資料

(1)

オラクル・コーポレーション

クラウド・エバンジェリスト

Multitenant-based DBaaS architecture and strategy

Oracle Database 12c

(2)

• 以下の事項は、弊社の一般的な製品の方向性に関する概要を説明する

ものです。また、情報提供を唯一の目的とするものであり、いかなる契約

にも組み込むことはできません。以下の事項は、マテリアルやコード、機

能を提供することをコミットメント（確約）するものではないため、購買決定

を行う際の判断材料になさらないで下さい。オラクル製品に関して記載さ

れている機能の開発、リリースおよび時期については、弊社の裁量により

決定されます。

OracleとJavaは、Oracle Corporation 及びその子会社、関連会社の米国及びその他の国における登録商標です。

(3)

• 現在提供中

–

Exadata Express Cloud Service

• 11月提供予定

–

Enterprise Cloud Service

–

Exadata Cloud Service

• 12月提供予定

–

Exadata Cloud Machine

(4)

(5)

It is a Journey

機能のステージ



物理



専用

& ヘテロジニアス(異種)



静的で分断された分析



ハードウェアとソフトウェア・スタック

を標準化



標準デプロイメント構成



データベース・サービスと

サービス・レベルのカタログ



共有

_{& セキュアな中央データ・}

インフラストラクチャ



動的な最適化

& リソース管理



自動システム管理



オンデマンド、弾力、区分を持った

セルフ・サービス



迅速なサービス拡張と自動化



計測、自動コスト割当

&

チャージバック



完全に動的かつ統合された

リソース・プール



IT as cloud broker: 調停と仲介



セキュアなハイブリッド・クラウド

統合

(ベンダー、パートナー、など)

従来のサイロ

標準化プラットフォーム

統合化プラットフォーム

サービス提供

プラットフォーム

エンタープライズ・

クラウド・プラットフォーム

(6)

(7)

ハイブリッド・クラウドとは

?

2つ以上のクラウドの組み合わせ

オンプレミス

クラウド

ハイブリッド・クラウド

ワークロードをオンプレミスと

パブリック・クラウドに

本番

開発

テスト

UAT

本番

(8)

(9)

Program Agenda with Highlight

ハイブリッド・クラウドの定義

計画

デプロイメント

操作

重要ポイント

1

2

3

4

5

(10)

どのタイプのクラウドを採用すべきか

?

パブリック

?

プライベートのみ

?

ハイブリッド

?

(11)

多くのお客様にとって

…

(12)

移行

or 変換?

vs.

–

容易

–

今まで動いていたから今後も動く

–

減少のメリット

–

困難、長期

–

より大きな利点

–

課題解決のために必要

(13)

どちらも使えますが

… 本当に急いでいるのでなければ

変換を検討してください

1. 移行ではなく、変換によって多くのコストを削減

2. 変換には

標準化、簡素化、縮小

が含まれる

実際のいくつかのお客様における例

:

–

300 Oracle ホームを 2 Oracle ホームに

–

736 データベース・ソフトウェア・スタックを 10 以下に

–

9,085 データベースを 5,020 に

3. まず最初に移行を行う必要がある場合には、移行後、適切に合理化が

計画されていることを確認してください

(14)

移行ステージング

段階的なワークロードの展開

ミッション・クリティカル

Low Hanging

新規デプロイメント

本番

複合ワークロード

移行の制約制約なし xxx 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 xxxx xxxx xxxx xxxx xx xxxx xxxx xxx xxx xx xxx xxx xxx xxx xxx xxx xxx x xxx) xx xxx xxx xxx xxx 26 27 28 29 30 31 32 xxx xxx xxx xxxx xxx xxx xxx 33 34 35 36 xxxx xxx xxxx xxx 37 xxxx 2 3 5 6 8 9 10 11 12 13 14 15 16 17 18 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 37 4 ワークロード凡例即時候補となるプラットフォーム長期的に候補となるプラットフォーム移行の見込みのない



統合された環境へのワークロードの適合性は

大きく変化します



簡単に移行できる対象を識別するための明確な

基準を定義します



早期の成功のために計画します



移行を段階的にすることでリスクを軽減します



先に行った移行から得た教訓を以後の移行に

活かします



複合ワークロードをホストするための柔軟な

アーキテクチャを開発します

(15)

(16)

どのデプロイメントにも長所と短所がある

専用

データベース

専用

フレックス

-サイロ

区分占有、動的に

リサイズ可能

プラガブル・

データベース

統合密度増加

カプセル化

データベース

1つの仮想環境内の

専用データベース

共有

OS 環境内の

専用データベース

共有データベース

デプロイメント

CPU、ネットワークと

ストレージ容量を共有

OS メモリ、リスナー、

ASM インスタンス、

メモリ、バックグラウ

(17)

経験から得た方法

:

(18)

統合密度は大きく異なりますか

?

マルチテナントは少ないリソース要件で最高の統合密度を実現

システム

トランザクション

CPU 使用率

ストレージ

IOPS

スループット

レスポンス時間

合計

Physical Reads

Physical Writes

Redo log Writes

252 non-CDBs

72,600 tps

7 ms

68%

36,900 r/s

133,100 w/s

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

252 PDBs

2,688

60%

50 GB

91 3%

2 GB

メモリ

SGA

PGA

合計

データベースごとのメモリ・フットプリント

Buffer Cache

Other Pools

Processes Private

合計メモリ

_{Buffer Cache とフォアグラウンドを除く}

+80%

same

-30%

-25%

-19x

-92x

-9x

+74%

-75x

(19)

ケース・スタディ

:

オーストラリア・コモンウェルス銀行

(20)

CBA における OaaS の進化

エンタープライズ

-クラスの

Sun サーバーのクラスタ、

CBA による統合

(CommSee, NetBank)

コモディティ

-クラスの

Sun サーバーのクラスタ、

CBA により統合

(OaaS v1)

Exadata

(OaaS v2)

オーストラリア・コモンウェルス銀行

(21)

OaaS イントロダクション

理想的な統合プラットフォーム

– あらかじめエンジニアリング済み!

事前構築の

“プラットフォーム・サーバー” または “プライベート・クラウド・サーバー”: 電源を入れるだけ

最初の

Exadata Machine が 2009年12月に CBA に導入され、さらに 2010年5月に第二弾が導入される

OaaS v2 へ移行された最初のアプリケーションは Peoplesoft Financials

ビルトインの高可用性

: RAC、ASM、DG – アプリケーション側で個々に実装するのはコストが掛かりすぎる

OaaS v2

OaaS v4

(22)

OaaS が運用の経済性を変える

• 多くの個別データベースを

OaaS 上に統合

–

データベース・システムを集中管理

–

一貫性のある、標準化されたプラットフォーム

–

サーバー、および関連する運用コストの大幅な削減

–

運用の

DBA 専門チームが、アプリケーション・データベースではなく、OaaS プラット

フォームを管理

–

プラットフォーム経済性

¥

伝統的なサイロ・アプローチ

グリッド・コンピューティング・モデル

オーストラリア・コモンウェルス銀行

(23)

どこでコスト削減できますか

?

ハードウェア

ハードウェア要件を大幅に削減

_:

• 低コストのサーバーをクラスタ化して、高価なサーバーを削除

• その時必要なだけ購入、処理要件が増加した時点でスケール、

JIT

オペレーティング・システム

オペレーティング・システム・ソフトウェア

& メンテナンス費用を削減するために

一つの

_{OS ビルドを採用}

コスト削減エリア

どのようにコストが削減されるか

3 rd

_{パーティー}

ソフトウェア

多くの

₃

rd

_{パーティー・ソフトウェアの必要性を最小限に抑えられるように標準的なデータベース・ソ}

フトウェア・スタックの機能を活用

例設計とソフトウェアを標準化

:

• システム管理

_{& 監視}

• レプリケーション

_{/ DR}

• クラスタ・ソフトウェア

オーストラリア・コモンウェルス銀行

(24)

どこでコスト削減できますか

?

コスト削減エリア

どのようにコストが削減されるか

運用

管理対象の環境の数を削減

:

• 標準的な運用環境が運用コストを削減

エンタープライズ管理ツール

_{& プロセスの採用:}

• 手動で実行しているシステム管理タスクを自動化

• 標準的な運用手順をホストされているアプリケーション全体で活用

• 環境のガバナンスを改善

データベース

長期的なコスト削減機会

:

• 高い資産の使用率

=> CPU 数の減少 => ライセンス料の削減

• Oracle 環境の減少 => 運用タスクの削減

• 統合環境の管理に必要な

FTE の減少

プロジェクト・コスト

_:

オーストラリア・コモンウェルス銀行

(25)

リスク削減、市場投入までの時間を改善

• 新規プロジェクトに対して

:

–

プロジェクトから一つフェーズを削減

– あらかじめ最適化されたインフラストラクチャ

–

設計と構築のために高価

/不足している SME 資源に対する依存を取り除きます

–

もはや調達に関連するリスクを管理、構築する必要はなし

–

新たな本番品質環境のインスタンス化に要する時間

: 3 ヶ月 -> 2 分

• 例

: 私たちのオンライン株式取引プラットフォームへ新しく導入した ISV アプリケーション

–

2年後に予測されるワークロードとデータ量という条件の下でパフォーマンスのテストが必要

専用インフラストラクチャ

OaaS

実行時間

3-4 ヶ月

数時間

オーストラリア・コモンウェルス銀行

(26)

マルチテナント

vs スキーマ統合 at CBA

• 「クラウド」操作の観点から著しい管理上のメリット

• スキーマ統合と比べ、テナント間のより良い分離性

• 本番からテストへ高速クローニング

(27)

PaaS 実装に関する考察

1. ビジネスに必要な正しい技術

/商用ソリューションを入手するために時間を割く

–

異なる仮想化技術には異なる密度が

– 結果として異なる経済に

2. アプリケーション所有者から仕入れなければならない

–

いつ、どのようにアプリケーションを移行するか計画する

–

需要喚起には社内営業の役割が必要

3. 迅速な成功に注力

–

最も容易なアプリケーションから移行

/ 提供する

4. ガバナンスと業務プロセス改善へ投資

–

技術ソリューションよりもはるかに多く

(28)

アプリケーションへの影響なしで計画メンテナンスを実施

• 継続的なサービスのため、アクティブ

/アクティブ構成を使用します

• 常にアプリケーション・サービスを使用します

• ユーザー・エクスペリエンスにフォーカスします

• スケジュールされたメンテナンスが始まるまでにアプリケーションの作業が完了する

ようにします

–

アプリケーションへの変更なしで実装可能

–

サービス・レベルでトランザクショナルに切断します

(29)

親和性およびローカルでのドレイン

–

サイト間スイッチオーバー

Active Data Guard

– 計画スイッチオーバー

– データ保護、

DR

– クエリ・オフロード

Data Guard

– 計画スイッチオーバー

– データ保護、

DR

GoldenGate

–

計画スイッチオーバー

–

アクティブ

-

アクティブ・

レプリケーション

–

ヘテロジニアス

Sharding

レプリカ

Fast Application Notification

– イベント通知

, フェイルオーバー、ロードバランス

Application Continuity, Transaction Guard

– アプリケーション

HA

Global Data Services

– クロスサイト配置

RAC

– オンライン・ローリング・メンテナンス

– スケーラビリティ

– サーバー

HA

RAC One

– オンライン・ローリング・メンテナンス

– サーバー

HA

本番サイト

Drain within RAC

スイッチ

オーバー

(30)

ドレイン・サービス

“常にオン”

“常に実行”

RAC or RAC One Node

Node 1

RAC インスタンス

Node 2

RAC インスタンス

サービスの位置透過性

FAN: デフォルトでオン、自動構成、全アプリケーション

(31)

メンテナンス

– 安全な場所でドレインを実行

事前にサービスを移動

アプリケーションからは透過的

に接続を切り替え



コネクション・プール



接続テスト



トランザクション境界

状態をリストアし、新規の接続

を使用してトランザクションを

(32)

Keep i

t s

impl

e

–

St

ag

ger

dr

ai

ni

ng

ser

vi

ces

completed

# Jobs

バッチ・

サービス利用

OLTP

(33)

Stagger Draining – バッチおよびオンライン・サービス

• 少なくとも二つのアプリケーション・サービスを使用

– オンラインおよびバッチ/

バックグラウンド

• 最初にバッチに対してドレインを実行

• 続けてオンラインのドレインを実行

最初の

インスタンス

シャ

ット

ダウ

ン

オンライン

3時間の静止バッチ…

60秒間の静止 OLTP

完全なメンテナンス

オン

ライン

オンライン

バッチ

(34)



リカバリ可能なエラー発生時には、実行中

のトランザクションを再実行



ハードウェア、ソフトウェア、ネットワーク、

ストレージのエラーやタイムアウトをマスク



_{12.1 JDBC-Thin、UCP、WebLogic サーバー、}

3 rd

_パーティ

_{Java アプリケーション・}

サーバー



_{RAC、RAC One & Active Data Guard}

実行中トランザクションの継続

(35)

Oracle Digitalは、オラクル製品の導入をご検討いただく際の総合窓口。

電話とインターネットによるダイレクトなコニュニケーションで、どんなお問い合わせにもすばやく対応します。

もちろん、無償。どんなことでも、ご相談ください。

(36)

(37)

(38)