Tech deepdive#2 datastore_180317_share

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. |
もしもみなみんが
アプリケーション開発者だったら
南野英梨子（Eriko Minamino)
@minamin96
日本オラクル株式会社
クラウドプラットフォームソリューション統括
Tech Deep Dive #2 in Osaka
https://connpass.com/event/79096/

Safe Harbor Statement
The following is intended to outline our general product direction. It is intended for
information purposes only, and may not be incorporated into any contract. It is not a
commitment to deliver any material, code, or functionality, and should not be relied upon
in making purchasing decisions. The development, release, and timing of any features or
functionality described for Oracle’s products remains at the sole discretion of Oracle.
2

Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3
• Oracle Database/PaaS製品担当
• ・主に社内外の技術支援
• ・得意領域は高可用性
• ・現在は、主にOracle Database関連クラウド・サービスを担当
• 『もしもみなみんがDBをクラウドで動かしてみたら』
• http://www.oracle.com/technetwork/jp/database/articles/mina
min-cloud/index.html
• Twitter:@minamin96
自己紹介

１．概要
4

インフラ
5
よくあるシステムの構成
Data StoreAP Server
アプリケーション

インフラ
6
システムによくある問題
Data StoreAP Server
アプリケーション
インフラを使い切れ
ないアプリ
可用性
性能限界
開発者
運用が大変で開発に
注力できない！
問題を分析・改善で
きない

Read Replicaによるオフロードキャッシュによる高速化
7
シャーディングスケールアウト
性能を意識したよくあるアーキテクチャ例
AP
Server
Cache
AP
Server
AP
Server
AP
Server
処理によって
接続先を変える
処理によって
接続先を変える
同じデータストアを
複数並べる
取るデータ毎に
DBを変える
Data Store
(A-N)
Read
Replica
Read
Replica
Read
Replica
Data
Store
Data
Store
Data Store
(O-Z)

横に並べて冗長化別リージョンへ複製して冗長化
8
可用性を意識したよくあるアーキテクチャ例
リージョンA
リージョンB
AP
Server
Standby
Data
Store
AP
Server
Read
Replica
Read
Replica

リージョンB
リージョンA
Read Replica
Data Store
AP Server
Read Replica
Standby
AP Server
性能と可用性を意識したアーキテクチャの具体例
読み込みをオフロード
シャーディングも可能
障害に備えて
書込に専念
9
ユーザ
開発者
データ同期
データ同期
どちらかから読み取る

リージョンB
リージョンA
Read Replica
Data Store
AP Server
Read Replica
Standby
AP Server
よくある問題例
参照が遅い
作るの大変
書込が遅い
10
ユーザ
開発者
データ同期
データ同期
制御が難しい
運用が大変で開発に
注力できない！

リージョンB
リージョンA
Read Replica
Data Store
AP Server
Read Replica
Standby
AP Server
こんなアーキテクチャ欲しくないですか？
チューニング案を提示してくれ
て運用者は決定するだけ。
効果の確認も簡単にできる
11
ユーザ
開発者
データ同期
データ同期
毎日定時で帰れる！
このシステム、
すごい安定感！
接続先を意識しない。
障害時もアプリに通知
なく自立的に切替
別リージョンへ
冗長化
足りなければ
スケールアウト

２．なにを気にしないといけないのか？
12

スケールアップ
– スケールアウト/イン
• 特に更新系
– スケールアップ/ダウン
– スレッド、コネクション
• スケールアウトは注意
13
可用性
– データストアの可用性
– 障害時の復旧時間
インフラで気にすること
Data
Store
AP
Server
Active
AP
Server
Standby
Data
Store
AP
Server
AP
Server
性能

インフラの性能で気にすること
• スケールとリソース
– スケールアップしてリソースを増やす
• リソース数を増やすのは限界があるので注意 (CPU数やメモリには上限ある)
– スケールアウトしてリソースを増やす
• 他のインスタンスのリソースを使い切ってしまう可能性があるので注意（コネクションなど）
14
Data
Store
AP
Server
機能的にスケールアウトできない
Data
Store
AP
Server
AP
Server
これ以上スケールアップできない
相手のリソースが
枯渇する

インフラの可用性で気にすること
• アプリにインフラを極力意識させない
– インフラの構成とアプリの設計を分離（疎結合）
• 高可用性構成の切替時間を短くする
– 自動で検知
– 自動で切り替え（必要に応じて）
– 切替が短時間で完了
• オペレーションミスのリカバリ
– 様々なリカバリ方法を準備
– ミスのレベルにあわせて方法を選択
15
Active
AP
Server
Standby
AP
Server
アプリはどちらへ
接続するか意識しない
瞬時に切り替え
Read
Replica
Read
Replica

性能
• パラレル
– パラレル処理の必要のないトランザクショ
ンやシステム全体の影響を及ぼさない
• I/O削減
– 効率的なI/Oを意識したSQL
• スケールアウト
– Data Storeがスケールアウトした際
アプリが持つ接続が再分散する
可用性
• スケールイン
– データストアに障害が落ちた場合に、落ち
たデータストアへのコネクションを全て破棄
し、業務ロジックへの影響を及ぼさない
16
アプリケーションで気にすること

パラレル
• 適切な並列度と処理分散をする
• Data Storeがスケールアウトした際
アプリが持つ接続が再分散する
17
アプリケーションの性能で気にすること
AP
Server
瞬時に検知して分散する
Read
Replica
Read
Replica
AP
Server
Read
Replica
Read
Replica
他の処理に影響を
及ぼさない並列度
データ配置や処理量を
意識した分散新規に追加

アプリケーションの可用性で気にすること
• スケールイン
– フレームワークで対応が必要
– データストアに障害が落ちた瞬間に落ちたことを検知する
– 落ちたデータストアへのコネクションを全て破棄する
– 業務ロジックへ極力影響を及ぼさないようにする
– アプリがコネクションを使っている場合には
気付かれないように正常なコネクションへ交換する
18
AP
Server
瞬時に検知して
切断・破棄する
Read
Replica
Read
Replica

３．よくある問題と解決策
19

オペレーションミス更新系の性能
20
スケールアウト性能問題
今回紹介する例

１．オペレーションミスのよくある問題
Update文のWhere句を
間違えた！
間違って表を消してしまっ
た！！
メンテナンス用バッチの
実行順序を間違えた！原因不明でDBが止まった！！
rmコマンドでデータファイルを
消してしまった！
接続先をまちがえて、
別環境で実行してしまった！

１．オペレーションミスに対するよくある解決方法
22
• Data Storeを停止して、バックアップからリカバリする
• 正常稼働しているスタンバイがある場合は、切り替える
よくある解決方法の例
• バックアップから戻すには時間がかかる
• バックアップから戻そうとしても戻せない
• スタンバイ側も使えない
• バックアップもスタンバイも作成が難しくて躊躇
実際、こんなことありませんか？

• 影響を最小限にするため、
ミスの種類ごとの適切なリ
カバリ方法
– トランザクション単位
– テーブル単位
– Data Store全体
• 簡単に取得できて、きちん
と戻せるバックアップ
– 停止せずにバックアップを取得
(オンライン・バックアップ)
– 戻せるバックアップかの確認
23
• 簡単に構築できて、切り替
え後にもきちんと使えるス
タンバイ
– データを意識したレプリケーショ
ンによるスタンバイ
– 異常停止を自動検知・自動
切り替え
１．オペレーションミスに対する理想的な解決方法
Active
AP
Server
Standby
自動検知・
自動切り替え
AP
Server
Data
Store
Backup
止めずに取得
バックアップの
検査
AP
Server
Data
Store

２．更新系のよくある問題
24
Data StoreAP Server
2.更新の性能限界
AP Server
AP Server1.リクエストが増えるため
・
・
・
・
・
・

２．更新系に対するよくある解決方法
25
Read Replica
Data StoreAP Server
参照処理をオフロード
インスタンスサイズを
スケールアップ
参照はこちらを見る
Data Store
シャーディング

２．更新系に対する理想的な解決方法
26
• オフロード出来る処理には限界がある
• リードレプリカへの伝播が遅れて業務エラーが発生
• シャーディングの範囲変更によるシステム停止
• スケールアップには限界がある
よくある解決方法の結果、ぶつかる課題
そもそもこれらを考えたくない・・・
• 更新系に強いアーキテクチャや製品を採用
理想的な解決方法

３．スケールアウトのよくある問題
AP
Server
Read
Replica
Read
Replica
スケールアウトしたノードに
処理が分散しない
処理が特定のノードに
偏ってしまう
ノード停止時に
コネクションが残ってしまう
毎回接続するDBが異なるため
キャッシュが効かない
Read
Replica

３．スケールアウトに対するよくある解決方法
28
• DNS に複数ホストを登録して負荷分散する
• APにセッションアフィニティをかける
上記では解消できない問題もある

• あるユーザは毎回同じDBインスタンスへ
繋がる
• インスタンスの負荷を見て負荷が分散される
• インスタンスの停止を瞬間的に検知してコ
ネクションを無効化する
• インスタンスが停止してもAPはエラーを返
さずに継続して処理をする
• 停止したインスタンスへのコネクションは新
規リクエストに渡さない
29
３．スケールアウトに対する理想的な解決方法
AP
Server
Read
Replica
Read
Replica
Read
Replica
User A
User B CPU
60%
CPU
20%
AP
Server
Read
Replica
Read
Replica
Read
Replica
1.クリーン
アップ
ユーザ
3.新規コネクション
は張らない
1.同じ接続先へ
2.負荷状況に
応じた接続
2.エラーを返さ
ず再実行

４．性能問題のよくある問題
AP
Server
Read
Replica
Read
Replica
インフラのリソースを
使いきれない
分析できない
性能問題の分析・改善に時間を
費やして、開発に注力できない
チューニングできない

４．性能問題のよくある解決策
31
• H/Wリソース増強
• スペシャリストの採用
• 事前テストの自動化
• コストがかかる
• 単純なH/Wリソース増強では解決しない
• チューニング案を試せない、自動テストができる環境がない
実際、こんなことありませんか？

４．性能問題に対する理想的な解決方法
• ベターな解決策
1. 分析に必要な情報の収集を自動的にやってくれる
2. 高精度な分析により問題を特定する
3. 幅広い改善案の中から確信に近い改善案を決定/適用する
• 基本的な考え方: 時間↓= 処理量↓/(速度 * 並列度)↑
4. 本番データを使った自動性能テストを実施する
• ベストな解決策
1. システムが改善案を提示
2. 人間はボタンを押すだけで改善案を適用
3. 本番データを使った自動性能テストを実施する
32

４．これらの問題を解決してみましょう
33

こんなシステム、使えたらうれしくないですか？
34
高性能簡単高効率

ユーザー・エラーからの
早急かつ容易な復旧
Flashback
Technologies
• データベース論理障害から復旧
• 特定時点に戻すことが可能
• 変更されたブロックのみをリストア
するのでDB全体のリストア不要
• 過去データの参照可能
影響範囲を最小限に抑え
た復旧が可能
Recovery Manager
(RMAN)
• 最小はブロック単位でのリストアが
可能（オンライン）
• 表単位（12c~）、データファイ
ル単位、データベース単位を選択
可能
• 正常なバックアップか評価可能
35
自動データ同期によるデー
タ保護・迅速な切り替え
Data Guard
• 更新履歴情報を利用したリアルタ
イム・データベース複製
• トランザクションの順次保証
• ブロック破損コピーの防止
• 1コマンドでの切り替え可能(Data
Guard Broker有効にした場合)
• 自動検知・自動切り替え機能あり
Oracleでの解決策
１．オペレーションミス
Backup
Database
Primary Standby
Database
指定時点現在
バックアップを
利用した復旧
Flashback
同期
バックアップ
迅速な切り替え
REDO
Database DB Backup

Active-Activeなシェアードエブリシング・クラスタ
Real Application Clusters
• サーバー数を増やしてスケールアウト
• ノード間の一貫性担保、シングル同様に利用できる透過性
スタンバイを参照系として利用可能
Active Data Guard
• スタンバイ側に参照系処理をオフロード
36
データを複数のデータベースに分散配置
Sharding
 複数データベースでのスケールアウト
 適切な分散配置によるデータベース間の影響を削減
Active-Active なレプリケーション
GoldenGate
 異なるデータベース/OS/バージョン間での連携可能
 データベース全体・表・列単位など様々な単位で連携可能
２．更新系
Application
Application
Primary Standby
Application
Read/Write Read Only
Application
Read/Write
同期
同期
Read/Write
GoldenGate
スケール
アウト
Database GoldenGate

３．スケールアウト:接続性
37
Oracle Clusterware
WebLogic Server
Active GridLink
Service
lsnr lsnr lsnr
SCAN lsnr
Active GridLink for RAC
• WebLogic ServerのReal Application
Clusters(RAC)連携機能
• RAC側から状態を通知する仕組み
• 適切なインスタンスへの接続を制御
ランタイム接続・ロード・バランシング
• RACの負荷状況を考慮した実行時接続ロード
バランシング
• アプリ接続要求時にRACの負荷状況を判断
Webセッション・アフィニティ
• インスタンス、クライアント・アプリケーションまたは
障害イベントによって解放できるOracle RACイ
ンスタンスへのアフィニティ
• 同じHTTPユーザーのリクエストは毎回同じイン
スタンスに振り分ける
Single Client Access
Name(SCAN)
• 接続リクエストに対するリダイレクトの役割
• 接続リクエストを送る先を意識する必要がなく、サー
バー追加の際に接続先情報を編集する必要がな
い
データベース・サービス
• 自動ワークロード管理機能
• サービスに対して接続することで、ノード数や起動/
停止しているかも意識する必要がない
Automatic Storage Management
• ディスク構成の仮想化技術で、ストレージのパフォー
マンス改善を自動化
• 複数のストレージに対し、ストライピング・ミラーリン
グ・データ分散配置/再配置を自動的に行い、複
数ストレージでのI/O処理の効率化
Automatic Storage
Management
AP Server
DB Server
DatabaseJava

３．スケールアウト:可用性
38
Oracle Clusterware
WebLogic Server
Active GridLink
Service
lsnr lsnr lsnr
SCAN lsnr
Active GridLink for RAC
• WebLogic ServerのReal Application
Clusters(RAC)連携機能
• RAC側から状態を通知する仕組みにより、
DBサーバー側の障害を素早く検知し、適切
なインスタンスへ接続
Fast Connection Failover
• コネクションプールとの連携機能
(UCP,ODP.NET,OCIセッションプール etc)
• DOWN/UPイベントや負荷ステータスを通知する
FANイベントを受信
• 障害ノードとの間で確立している無効な接続を能
動的にすべて破棄
Application Continuity
• インスタンス障害時にアプリケーションのデータベース
処理のフェイルオーバーを透過的に実行
• 残存インスタンスにコネクションも含めフェイルオー
バーし、クライアント側でのエラーなく処理を継続
Automatic Storage Management
• 共有ストレージとしてどのDBサーバからも同一データ
がアクセス可能
• ミラーリングと自動修復による可用性
FAN
Automatic Storage
Management
AP Server
DB Server
DatabaseJava

４．性能問題
39
パラレル化で複数CPUコアを利用
Parallel Query
データ圧縮でI/O量削減
Compression
パーティション化で処理量削減
Partitioning
パーティション表
インメモリ化でディスクI/O削減、
列指向で演算処理の高速化
Database In-Memory
I/Oや処理量の削減
並列度や高速化
Database

パフォーマンス・ボトルネッ
クの把握
Diagnostics Pack
 パフォーマンス監視と診断、
自動稼働情報取得、
データベース診断レポートなど
パフォーマンス管理機能
Tuning Pack
リアルタイムSQL監視、
自動SQLチューニング、
アドバイザ機能など
40
性能問題の未然防止
Real Application
Testing
４．性能問題 Database

４．性能問題
GUIでの管理・運用ツール Enterprise Manager
見える化→自動診断→分析→アドバイス→適用
41
問題の発見
• データベース特有の指標
から性能問題を発見
解決方法の発見
• データベース/SQLのチューニング
アドバイスを取得、実装
問題の解決
• 定期レポートで経過観察
要因の分析
• 現在のセッションを分析し、遅延の原因に
なっているセッションやSQLを即座に特定
• データベース総合診断結果を参照し、
ボトルネック発生個所や影響範囲を把握

ここまでの内容を
検討したり実装するのもなかなか大変・・・
42

こんなデータベース、使えたらうれしくないですか？
予め構成・最適化
・テスト済み
自動的にスケール
自動的に
オンラインでパッチ適用
自動的に
セキュアな構成
自動的に
モニタリング
自動的にバックアップ自動的に障害回避自動的に
パフォーマンス診断
自動的に最適化自動的にテスト自動的に
エラーハンドリング
自動的に
移行とデータロード
43

自律型データベースに対するオラクルのビジョン
Self-Driving (自動稼働) - コスト削減し生産性を向上
–人手を介さずに構築、チューニング、バックアップ・リカバリを実現
Self-Securing (自動保護) – リスクの最少化
–外部攻撃と悪意のある内部ユーザから保護
–ダウンタイムなしでセキュリティ・パッチを自動適用
Self-Repairing (自動復旧) - 高い可用性の確保
–全てのダウンタイムからの自動的な保護
–最大99.995%のSLA。1ヶ月のダウンタイム2.5分以内
44

Autonomous Data Warehouse Cloud
データウェアハウスのための自律型データベース・クラウド
簡単な設定ですぐにDBが構築、利用可能に
チューニングが不要でデータ管理に人手をかけない
パッチ適用やバックアップの自動化 - DBA工数の削減簡単に使える
Exadataのテクノロジーを最大限活かした高速性能
大規模な同時アクセスにも対応
パフォーマンス
初期投資不要、使った分だけの課金
CPUやストレージは稼働中に拡張・縮退可能
ピーク時にリソースを増やす、不要時に停止など柔軟柔軟性
45

Tech deepdive#2 datastore_180317_share

Tech deepdive#2 datastore_180317_share

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Tech deepdive#2 datastore_180317_share

Similaire à Tech deepdive#2 datastore_180317_share (20)

Plus de オラクルエンジニア通信

Plus de オラクルエンジニア通信 (20)

Tech deepdive#2 datastore_180317_share