Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Tech deepdive#2 datastore_180317_share

2,979 views

Published on

Tech Deep Dive #2 in Osaka
https://techdeepdive.connpass.com/event/79096/
2018/03/17

アプリケーションを動かしてて、データベースが遅くなったり壊れてしまった際に、どのように対処したらいいのかと、お困りの方は少なくないのではないでしょうか。そんな時に備えて、データベースの設計方式や実装方法をご紹介します。

Published in: Software
  • Be the first to comment

Tech deepdive#2 datastore_180317_share

  1. 1. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | もしもみなみんが アプリケーション開発者だったら 南野 英梨子(Eriko Minamino) @minamin96 日本オラクル株式会社 クラウドプラットフォームソリューション統括 Tech Deep Dive #2 in Osaka https://connpass.com/event/79096/
  2. 2. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 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
  3. 3. 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. 4. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 1.概要 4
  5. 5. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | インフラ 5 よくあるシステムの構成 Data StoreAP Server アプリケーション
  6. 6. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | インフラ 6 システムによくある問題 Data StoreAP Server アプリケーション インフラを使い切れ ないアプリ 可用性 性能限界 開発者 運用が大変で開発に 注力できない! 問題を分析・改善で きない
  7. 7. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 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. 8. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 横に並べて冗長化 別リージョンへ複製して冗長化 8 可用性を意識したよくあるアーキテクチャ例 リージョンA リージョンB AP Server Standby Data Store AP Server Read Replica Read Replica
  9. 9. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | リージョンB リージョンA Read Replica Data Store AP Server Read Replica Standby AP Server 性能と可用性を意識したアーキテクチャの具体例 読み込みをオフロード シャーディングも可能 障害に備えて 書込に専念 9 ユーザ 開発者 データ同期 データ同期 どちらかから読み取る
  10. 10. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | リージョンB リージョンA Read Replica Data Store AP Server Read Replica Standby AP Server よくある問題例 参照が遅い 作るの大変 書込が遅い 10 ユーザ 開発者 データ同期 データ同期 制御が難しい 運用が大変で開発に 注力できない!
  11. 11. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | リージョンB リージョンA Read Replica Data Store AP Server Read Replica Standby AP Server こんなアーキテクチャ欲しくないですか? チューニング案を提示してくれ て運用者は決定するだけ。 効果の確認も簡単にできる 11 ユーザ 開発者 データ同期 データ同期 毎日定時で帰れる! このシステム、 すごい安定感! 接続先を意識しない。 障害時もアプリに通知 なく自立的に切替 別リージョンへ 冗長化 足りなければ スケールアウト
  12. 12. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 2.なにを気にしないといけないのか? 12
  13. 13. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | スケールアップ – スケールアウト/イン • 特に更新系 – スケールアップ/ダウン – スレッド、コネクション • スケールアウトは注意 13 可用性 – データストアの可用性 – 障害時の復旧時間 インフラで気にすること Data Store AP Server Active AP Server Standby スケールアウト Data Store AP Server AP Server 性能
  14. 14. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | インフラの性能で気にすること • スケールとリソース – スケールアップしてリソースを増やす • リソース数を増やすのは限界があるので注意 (CPU数やメモリには上限ある) – スケールアウトしてリソースを増やす • 他のインスタンスのリソースを使い切ってしまう可能性があるので注意(コネクションなど) 14 Data Store AP Server 機能的にスケールアウトできない Data Store AP Server AP Server これ以上スケールアップできない 相手のリソースが 枯渇する
  15. 15. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | インフラの可用性で気にすること • アプリにインフラを極力意識させない – インフラの構成とアプリの設計を分離(疎結合) • 高可用性構成の切替時間を短くする – 自動で検知 – 自動で切り替え (必要に応じて) – 切替が短時間で完了 • オペレーションミスのリカバリ – 様々なリカバリ方法を準備 – ミスのレベルにあわせて方法を選択 15 Active AP Server Standby AP Server アプリはどちらへ 接続するか意識しない 瞬時に切り替え Read Replica Read Replica
  16. 16. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 性能 • パラレル – パラレル処理の必要のないトランザクショ ンやシステム全体の影響を及ぼさない • I/O削減 – 効率的なI/Oを意識したSQL • スケールアウト – Data Storeがスケールアウトした際 アプリが持つ接続が再分散する 可用性 • スケールイン – データストアに障害が落ちた場合に、落ち たデータストアへのコネクションを全て破棄 し、業務ロジックへの影響を及ぼさない 16 アプリケーションで気にすること
  17. 17. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | パラレル • 適切な並列度と処理分散をする スケールアウト • Data Storeがスケールアウトした際 アプリが持つ接続が再分散する 17 アプリケーションの性能で気にすること AP Server 瞬時に検知して分散する Read Replica Read Replica AP Server Read Replica Read Replica 他の処理に影響を 及ぼさない並列度 データ配置や処理量を 意識した分散 新規に追加
  18. 18. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | アプリケーションの可用性で気にすること • スケールイン – フレームワークで対応が必要 – データストアに障害が落ちた瞬間に落ちたことを検知する – 落ちたデータストアへのコネクションを全て破棄する – 業務ロジックへ極力影響を及ぼさないようにする – アプリがコネクションを使っている場合には 気付かれないように正常なコネクションへ交換する 18 AP Server 瞬時に検知して 切断・破棄する Read Replica Read Replica
  19. 19. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3.よくある問題と解決策 19
  20. 20. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | オペレーションミス 更新系の性能 20 スケールアウト 性能問題 今回紹介する例
  21. 21. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 21 1.オペレーションミスのよくある問題 Update文のWhere句を 間違えた! 間違って表を消してしまっ た!! メンテナンス用バッチの 実行順序を間違えた! 原因不明でDBが止まった!! rmコマンドでデータファイルを 消してしまった! 接続先をまちがえて、 別環境で実行してしまった!
  22. 22. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 1.オペレーションミスに対するよくある解決方法 22 • Data Storeを停止して、バックアップからリカバリする • 正常稼働しているスタンバイがある場合は、切り替える よくある解決方法の例 • バックアップから戻すには時間がかかる • バックアップから戻そうとしても戻せない • スタンバイ側も使えない • バックアップもスタンバイも作成が難しくて躊躇 実際、こんなことありませんか?
  23. 23. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | • 影響を最小限にするため、 ミスの種類ごとの適切なリ カバリ方法 – トランザクション単位 – テーブル単位 – Data Store全体 • 簡単に取得できて、きちん と戻せるバックアップ – 停止せずにバックアップを取得 (オンライン・バックアップ) – 戻せるバックアップかの確認 23 • 簡単に構築できて、切り替 え後にもきちんと使えるス タンバイ – データを意識したレプリケーショ ンによるスタンバイ – 異常停止を自動検知・自動 切り替え 1.オペレーションミスに対する理想的な解決方法 Active AP Server Standby 自動検知・ 自動切り替え AP Server Data Store Backup 止めずに取得 バックアップの 検査 AP Server Data Store
  24. 24. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 2.更新系のよくある問題 24 Data StoreAP Server 2.更新の性能限界 AP Server AP Server1.リクエストが増えるため スケールアウト ・ ・ ・ ・ ・ ・
  25. 25. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 2.更新系に対するよくある解決方法 25 Read Replica Data StoreAP Server 参照処理をオフロード インスタンスサイズを スケールアップ 参照はこちらを見る Data Store シャーディング
  26. 26. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 2.更新系に対する理想的な解決方法 26 • オフロード出来る処理には限界がある • リードレプリカへの伝播が遅れて業務エラーが発生 • シャーディングの範囲変更によるシステム停止 • スケールアップには限界がある よくある解決方法の結果、ぶつかる課題 そもそもこれらを考えたくない・・・ • 更新系に強いアーキテクチャや製品を採用 理想的な解決方法
  27. 27. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 27 3.スケールアウトのよくある問題 AP Server Read Replica Read Replica スケールアウトしたノードに 処理が分散しない 処理が特定のノードに 偏ってしまう ノード停止時に コネクションが残ってしまう 毎回接続するDBが異なるため キャッシュが効かない Read Replica
  28. 28. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 3.スケールアウトに対するよくある解決方法 28 • DNS に複数ホストを登録して負荷分散する • APにセッションアフィニティをかける よくある解決方法の例 上記では解消できない問題もある
  29. 29. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | • あるユーザは毎回同じDBインスタンスへ 繋がる • インスタンスの負荷を見て負荷が分散される • インスタンスの停止を瞬間的に検知してコ ネクションを無効化する • インスタンスが停止してもAPはエラーを返 さずに継続して処理をする • 停止したインスタンスへのコネクションは新 規リクエストに渡さない 29 3.スケールアウトに対する理想的な解決方法 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.エラーを返さ ず再実行
  30. 30. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 30 4.性能問題のよくある問題 AP Server Read Replica Read Replica インフラのリソースを 使いきれない 分析できない 性能問題の分析・改善に時間を 費やして、開発に注力できない チューニングできない
  31. 31. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 4.性能問題のよくある解決策 31 • H/Wリソース増強 • スペシャリストの採用 • 事前テストの自動化 よくある解決方法の例 • コストがかかる • 単純なH/Wリソース増強では解決しない • チューニング案を試せない、自動テストができる環境がない 実際、こんなことありませんか?
  32. 32. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 4.性能問題に対する理想的な解決方法 • ベターな解決策 1. 分析に必要な情報の収集を自動的にやってくれる 2. 高精度な分析により問題を特定する 3. 幅広い改善案の中から確信に近い改善案を決定/適用する • 基本的な考え方: 時間↓= 処理量↓/(速度 * 並列度)↑ 4. 本番データを使った自動性能テストを実施する • ベストな解決策 1. システムが改善案を提示 2. 人間はボタンを押すだけで改善案を適用 3. 本番データを使った自動性能テストを実施する 32
  33. 33. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 4.これらの問題を解決してみましょう 33
  34. 34. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | こんなシステム、使えたらうれしくないですか? 34 高性能簡単 高効率
  35. 35. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | ユーザー・エラーからの 早急かつ容易な復旧 Flashback Technologies • データベース論理障害から復旧 • 特定時点に戻すことが可能 • 変更されたブロックのみをリストア するのでDB全体のリストア不要 • 過去データの参照可能 影響範囲を最小限に抑え た復旧が可能 Recovery Manager (RMAN) • 最小はブロック単位でのリストアが 可能(オンライン) • 表単位(12c~)、データファイ ル単位、データベース単位を選択 可能 • 正常なバックアップか評価可能 35 自動データ同期によるデー タ保護・迅速な切り替え Data Guard • 更新履歴情報を利用したリアルタ イム・データベース複製 • トランザクションの順次保証 • ブロック破損コピーの防止 • 1コマンドでの切り替え可能(Data Guard Broker有効にした場合) • 自動検知・自動切り替え機能あり Oracleでの解決策 1.オペレーションミス Backup Database Primary Standby Database 指定時点 現在 バックアップを 利用した復旧 Flashback 同期 バックアップ 迅速な切り替え REDO Database DB Backup
  36. 36. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Active-Activeなシェアードエブリシング・クラスタ Real Application Clusters • サーバー数を増やしてスケールアウト • ノード間の一貫性担保、シングル同様に利用できる透過性 スタンバイを参照系として利用可能 Active Data Guard • スタンバイ側に参照系処理をオフロード 36 データを複数のデータベースに分散配置 Sharding  複数データベースでのスケールアウト  適切な分散配置によるデータベース間の影響を削減 Active-Active なレプリケーション GoldenGate  異なるデータベース/OS/バージョン間での連携可能  データベース全体・表・列単位など様々な単位で連携可能 Oracleでの解決策 2.更新系 Application Application Primary Standby Application Read/Write Read Only Application Read/Write 同期 同期 Read/Write GoldenGate スケール アウト Database GoldenGate
  37. 37. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Oracleでの解決策 3.スケールアウト:接続性 37 Oracle Clusterware WebLogic Server Active GridLink Real Application Clusters 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. 38. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Oracleでの解決策 3.スケールアウト:可用性 38 Oracle Clusterware WebLogic Server Active GridLink Real Application Clusters 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. 39. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Oracleでの解決策 4.性能問題 39 パラレル化で複数CPUコアを利用 Parallel Query データ圧縮でI/O量削減 Compression パーティション化で処理量削減 Partitioning パーティション表 インメモリ化でディスクI/O削減、 列指向で演算処理の高速化 Database In-Memory I/Oや処理量の削減 並列度や高速化 Database
  40. 40. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | パフォーマンス・ボトルネッ クの把握 Diagnostics Pack  パフォーマンス監視と診断、 自動稼働情報取得、 データベース診断レポートなど パフォーマンス管理機能 Tuning Pack リアルタイムSQL監視、 自動SQLチューニング、 アドバイザ機能など 40 性能問題の未然防止 Real Application Testing Oracleでの解決策 4.性能問題 Database
  41. 41. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Oracleでの解決策 4.性能問題 GUIでの管理・運用ツール Enterprise Manager 見える化→自動診断→分析→アドバイス→適用 41 問題の発見 • データベース特有の指標 から性能問題を発見 解決方法の発見 • データベース/SQLのチューニング アドバイスを取得、実装 問題の解決 • 定期レポートで経過観察 要因の分析 • 現在のセッションを分析し、遅延の原因に なっているセッションやSQLを即座に特定 • データベース総合診断結果を参照し、 ボトルネック発生個所や影響範囲を把握
  42. 42. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | ここまでの内容を 検討したり実装するのもなかなか大変・・・ 42
  43. 43. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | こんなデータベース、使えたらうれしくないですか? 予め構成・最適化 ・テスト済み 自動的にスケール 自動的に オンラインでパッチ適用 自動的に セキュアな構成 自動的に モニタリング 自動的にバックアップ 自動的に障害回避 自動的に パフォーマンス診断 自動的に最適化 自動的にテスト 自動的に エラーハンドリング 自動的に 移行とデータロード 43
  44. 44. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | 自律型データベースに対するオラクルのビジョン Self-Driving (自動稼働) - コスト削減し生産性を向上 –人手を介さずに構築、チューニング、バックアップ・リカバリを実現 Self-Securing (自動保護) – リスクの最少化 –外部攻撃と悪意のある内部ユーザから保護 –ダウンタイムなしでセキュリティ・パッチを自動適用 Self-Repairing (自動復旧) - 高い可用性の確保 –全てのダウンタイムからの自動的な保護 –最大99.995%のSLA。1ヶ月のダウンタイム2.5分以内 44
  45. 45. Copyright © 2018, Oracle and/or its affiliates. All rights reserved. | Autonomous Data Warehouse Cloud データウェアハウスのための自律型データベース・クラウド 簡単な設定ですぐにDBが構築、利用可能に チューニングが不要でデータ管理に人手をかけない パッチ適用やバックアップの自動化 - DBA工数の削減簡単に使える Exadataのテクノロジーを最大限活かした高速性能 大規模な同時アクセスにも対応 パフォーマンス 初期投資不要、使った分だけの課金 CPUやストレージは稼働中に拡張・縮退可能 ピーク時にリソースを増やす、不要時に停止など柔軟柔軟性 45

×