2023-09-05_OCIJP_まれによくあるマルチクラウドでDB-AP分離構成のこと

マルチクラウドでシステムを作るときに、DB-AP分離構成で検討される例が増えてきています。その際に発生するレイテンシーを軽視するとシステムが繋がらない!!という問題が"まれによくあります"。机上検証でもある程度吸収できますので、考慮ポイントにしてください。
本内容は日本オラクルの見解を示したものではありません。

Transcript

1. まれによくある マルチクラウドでDB-AP分離をやる ※この内容はオラクルの公式⾒解ではありません しの @hk_shino 2023年9⽉5⽇ OCIJP-LT
2. まれによくある話 2 AP DB ネットが繋がればマルチクラウドで ヨシッ!!
3. ハイブリッドクラウド / マルチクラウド 定義の確認 ハイブリッドクラウド接続例 オンプレミスの場所 => クラウド 直列。この距離によって⼤きく変わる。 マルチクラウド接続例 オンプレからクラウドでハイブリット︖ クラウド同⼠でマルチクラウド︖ 3 各クラウドの並列 レイテンシー 3〜9ms ぐらい ※東京 クラウド オンプレ 顧客DC NW-DC 8〜20ms 1.5ms ※掲⽰している数値は⼀例です
4. 同⼀筐体内(シングルクラウド) • 同⼀のサーバーに AP/DBを配置 • レイテンシー影響 なし • スケールアウト・アップの設計には (かなり)考慮が必要 シングル/マルチ クラウド 別筐体(シングルクラウド) • 別のサーバーに AP/DBを配置 • レイテンシー影響 軽微 • APがスケールアウトしやすい設計 ができる マルチクラウド • クラウドサービスをNWで跨ぎ、 AP/DBを配置 • NW的に遠く、レイテンシーの影響 を受けやすい • 各クラウドの特徴を組み合わせた 戦略的なアーキテクチャの構築が できる 4 AP DB AP DB AP DB
5. システム単位︖ AP/DB分ける︖ 5 AP DB AP DB AP DB システム単位でCloudを選択する AP / DB 分離で クラウドを構成する ü レイテンシーを⼩さくすることで、 様々なワークロードを乗せることができる ü AP/DBでそれぞれ強みがあるクラウドサービス を選択することができる
6. データの検索・取得にAP/DB間の処理が発⽣ • OLTP系の処理に発⽣しがち • 応答速度によってDB側に処理待ち • 帯域は関係が無い データの検索少なく、取得データが⼤きい • レイテンシー影響は受けにくい • スループット次第ではシステム影響は少ない ワークロード特性を考えよう(※⼀般論) 6 OLTP レイテンシが⼤きくてもスループットが効く ホップが多く/距離が遠い <20ms 何度も検索 処理待ち 取得 ⼀気に返す OLAP DWH
7. OLAPシステム 通常、分析⽬的のためにデータ ベース内の多くのレコード（または 全レコード）に問い合わせをする。 必要とされる応答時間はOLTPと くらべて桁違いに遅い。 データを⼀切変更しない。通常、 ワークロードは読取り集中型であ る。 データを列形式で保存し、⼤量 のレコードに簡単にアクセスできる ようにする。 データベースのバックアップ頻度を ⼤幅に削減できる。 ⼤量の履歴データを保存するた め、⼀般的に⼤きなストレージ容 量が必要である。 ⼤量のレコードを含む複雑なクエ リを実⾏する。 ワークロード特性を考えよう(※⼀般論) 7 OLTP OLAP DWH レイテンシーへの影響度 OLTPシステム ⼤量のデータベース・トランザク ションを多⼈数でリアルタイムに実 ⾏できる。 迅速なレスポンスが要求される。 少量のデータを頻繁に変更し、 通常は読み込みと書き込みをバ ランスよく⾏う。 索引付けられたデータを使⽤して 応答時間を改善する。 データベースのバックアップを頻繁 に、または同時に⾏う必要がある。 ⽐較的⼩さなストレージ領域で 済む。 通常、1つまたは数個のレコードを 含む簡単なクエリを実⾏する。 迅速なレスポンスが要求される 必要とされるレスポンスは遅くても良い スループットが重視される https://www.oracle.com/jp/database/what-is-oltp/ OLTPとは
8. ワークロード特性を考えた改善のアプローチ (※⼀般論) 8 OLTP OLAP DWH レイテンシーへの影響度 迅速なレスポンスが要求される 必要とされるレスポンスは遅くても良い スループットが重視される AP/DB分離 マルチクラウドへのアプローチ • 通信⽅法の最適化 • バッファサイズ・パケットサイズの⾒直し • フェッチサイズを⼤きくして処理の往復回 数を減らす • 通信レイヤーのチューニング(効果低?) • SQLの⾒直し • 処理は1つのSQLにまとめる • SQL発⾏回数の削減 • バルクDMLやストアド • 密接な実⾏はDB側にて実施 • PL/SQLやPro*CはDBに近いところで 実⾏ • 低レイテンシが要求される、⼀例バッチ サーバーなどはDB側のクラウドサービスの 仮想マシンにのせる