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