検索性能に配慮した複製による分散ログ管理 / DPS-185

第185回DPS研究発表会(情報処理学会)
https://ipsj.ixsq.nii.ac.jp/records/208946

Transcript

1. 検索性能に配慮した 複製による分散ログ管理 東京工科大学コンピュータサイエンス学部 クラウド・分散システム研究室 小山智之 串田高幸 1
2. はじめに • ログはソフトウェアから出力されるメッセージである． • メッセージはOSやミドルウェア，アプリケーションから個別に独自のテ キスト形式で出力され，テキストファイルとして保管される． • ログ管理手法の1つに分散配置する方式がある． • ソフトウェアから出力されたログを複数ノードに分散して配置 • 分散配置によりログの処理で発生する負荷を分散 2
3. 課題(1) • 分散方式ではログが複数ノードに分散して配置される． • ログを分散配置するノードを増やすほど，1件の検索クエリでアクセスす るノード数は増加する． →複数台のノードへの検索クエリ発行と検索結果の集約に時間がかかる． 3
4. 課題(2) • 全体の検索の応答時間は，最も遅い応答時間の影響を受ける． →ノードが増えると，ノード1台の遅延が全体の遅延になる． • 検索時の応答速度の高速化は，システム管理者のトラブルシュートに費や す時間を削減する． 4
5. 関連研究(1) • A Dynamic Distributed Replica Management Mechanism Based on Accessing Frequency Detecting [Xu, Z., Xianliang / 2004) • 収集したアクセス頻度に基づきレプリカを動的に再配置 • 再配置によりメッセージ通信量の最適化を行うことにより，システム の性能の向上 • 利用頻度の高い検索条件であっても初期状態ではレプリカが最適な配 置にならず，検索の応答速度に課題 5
6. 関連研究(2) • Policies for Using Replica Groups and Their Effectiveness over the Internet [Morgan, G. / 2000] • グループ志向特性によるポリシーをサポートするタスクフレームワー クを実装 • グループ化されたサーバの呼び出しとレプリカ管理用の属性を連携さ せることで障害が発生したときの応答速度を改善 • レプリカの内容に応じた配置が配慮されずログに適用した場合に検索 の応答速度に課題 6
7. 提案(1) 概要 • 検索時の応答速度に配慮した分散ログ管理手法を提案 • 検索に伴う通信とその結果の集約に要する時間を削減 • ログを分散させるノード数を減らす →複数ノードへのアクセスに伴う遅延を削減 • 検索シナリオを想定したログの分割と配置(ログ配置ルール) →検索の応答速度を改善 • ログの分散配置を工夫することで，ログの検索における応答速度を高速化 7
8. 提案(2) ログ配置ルール • 検索によるアクセス頻度の高いログを同一ノードに集約す ることで，ログ検索における応答速度を高速化する． • 検索クエリで使用される条件として以下を想定 • ログの期間(例: 10/10 0:00 – 10/20 0:00) • ログの種類(例: Nginx) • ノードごとにログを検索クエリを想定した単位に分割 • ログの内容(例: Nginxのaccess.log) • ログの期間(例: 1時間毎 14:00-15:00) • ログの内容と期間ごとにグループを作成 • グループごとに全ノードから選んだ1台にログの複製を転 送 8 Day 1 Day 2 Day 3 Nginx Log 分割 Nginx Log Day 1 Day 2 Day 3 分割 グループ化 Day 1 Day 1 Day 2 Day 2 Day 3 Day 3 NodeA NodeB NodeA NodeB 転送
9. 提案(3) ログ配置ルールの作成 • システム管理者はシステム構成情報をマスターノードへ入力 • IPアドレス，ノード名，ログファイル名，分割単位 • マスターノードでは，システム構成情報と検索シナリオ(事前に定義)をソ フトウェアにより統合する． • その結果，ログ配置ルールが生成される． 9 マスターノード システム 管理者 システム 構成情報 入力 検索シナリオ ログ配置 ルール システム構成情報 生成
10. 提案(4) ノードの役割 • 次の2種類のノードから構成される． • マスターノード: 一般ノードを管理す る． • ログ配置ルールに基づきログ複製要求を 一般ノードへ送信， ログ検索の取りまとめ • 一般ノード: 分散ログ配置を構成する． • ログの転送/受信，保管，検索 • 1台のマスターノードで複数台の一般ノード のログ配置を管理する． • 一般ノード同士でマスターノードの要求に基 づきログを互いに転送する． 10 ログ配置 ルール 一般ノード 一般ノード 一般ノード マスターノード 複製 要求 複製 要求 複製 要求 転送 転送 転送 読み込み
11. 提案(5) ログの検索 • システム管理者はマスターノード のSearcherへ検索クエリを入力 • Searcherはログ配置ルールに基づ きログの配置された一般ノードを 選択し，検索を実行する． • Searcherは一般ノードから取得し た結果を集約しシステム管理者に 結果を返答する． 11
12. 実装(1) 概要 • マスターノード • Searhcer(検索)とReplication Manager(一般ノード管理)を新たに実装 • 設定ファイル: システム構成情報, ログ配置ルール • 一般ノード • Replication Agent(ログ転送)とLogGenerator(ログ生成)を新たに実装 • 既存ソフトウェアであるLokiとFluentdを利用 12 一般ノード Replication Agent Fluentd Loki マスターノード Replication Manager Log Generator Searcher システム 構成情報 ログ配置 ルール
13. 実装(2) 設定ファイル • システム構成情報: システム管理者が入力する． IPアドレス，ノード名，ログファイル名を含む． • ログ配置ルール: Replication Managerが出力す る．ログ転送元，転送先，ファイル名，期間を 含む． 13 loadbalancer: logfile_basename: "access_log" nodes: - ipaddr: 10.1.0.8 name: replica-agent-dep-b79d4d6dc-55shn - ipaddr: 10.1.0.15 name: replica-agent-dep-b79d4d6dc-9gm68 - ipaddr: 10.1.0.14 name: replica-agent-dep-b79d4d6dc-dt7cn システム構成情報(arch.yaml) [ { "srcAddr": "10.1.0.8", "destAddr": "10.1.0.11", "logFilename": "access_log", "logDate": "20201121" }, { "srcAddr": "10.1.0.15", "destAddr": "10.1.0.13", "logFilename": "access_log", "logDate": "20201121" }, { "srcAddr": "10.1.0.14", "destAddr": "10.1.0.9", "logFilename": "access_log", "logDate": "20201121" } ] ログ配置ルール(rule.json)
14. 実装(3) マスターノード • 新たに次のソフトウェアを作成 • Searcher: • 検索クエリの受け取り • ログ配置ルールに基づく一般ノー ドへの検索要求の発行 • Replication Manager: • 検索シナリオとシステム構成情報 をもとにログ配置ルールを作成 • 一般ノードへの複製要求を発行 14 マスターノード Replication Manager システム 構成情報 Searcher 検索シナリオ ログ配置 ルール 入力 読み込み 出力 読み込み 検索 要求 複製 要求 検索 クエリ 一般 ノード システム管理者
15. 実装(4) 一般ノード • 新たに次のソフトウェアを作成 • Log Generator: • 既存のWebアクセスログを拡張し ファイルへ出力 →Applicationの代替 • Replication Agnt: • ログ転送処理の受信， ログファイルへの書き込みの監視・転送 • 次の既存ソフトウェアを利用 • Fluentd(ログシッパー): • 転送されたログの受信，ファイル保管， Lokiへの追加 • Loki(インメモリDB): • 受信したログを格納，検索機構を提供 15 一般ノード Log Generator Log File 出力 保管 監視 Replication Agent Fluentd 追加 Loki 受信 転送 受信(転送先情報)
16. 検証環境 • Replication AgentとReplication Managerをコンテナ化 • ノード3台から構成されるKubernetesクラスタにデプロイ • 初期状態では，マスターノード(Manager) 1台と一般ノード(Agent) 10台を 配置した． • Log Generatorで一般ノードごとに 5日分のWebアクセスログを生成し配置 16 23.92.36.0 - - [27/Oct/2020:20:23:11 +0900] "GET / HTTP/1.1" 200 612 "-" "Java/1.8.0_265" ログの例
17. 評価方法 • マスターノードで動作するSearcherに検索クエリを発行 • 検索結果の応答までにかかる時間を計測し，ランダム配置と提案配置で比 較 • 検索条件: 3日分の全サーバWebサーバのアクセスログから”GET”を含む • 実験A • 一般ノード数を10[台]として，生成するログ件数を1000～10000[件/ 台]で1000件ごとに増加させ検索の応答速度を計測 • 実験B • 生成するログ件数を1000[件/台]として，一般ノード数を10～50[台]で 10台ごとに増加させ検索の応答速度を計測 17
18. 評価結果(1) 実験A • 生成するログの件数を1000～ 10000[件/台]で1000件ごとに 増加させ検索の応答速度を計測した． • 検索クエリをログの件数ごとに10回 発行し，応答速度の平均を算出した． • 提案配置はランダム配置に比べ， 最大 3.78 倍早い． (ログ件数=10000) • 提案配置はログ件数が増加しても 応答速度を一定に保っている． 18 ログの配置されたノード数の少なさによるも の 提案配置: 3台(3日分) ランダム配置: 10台(3日分) → 10/3 ≈ 3.33 [倍] 0.36 1.38
19. 評価結果(2) 実験B • 一般ノード数を10～50[台]で 10台ごとに増加させ検索の応答速度を計 測した． • 検索クエリをノード数ごとに10回発行し， 応答速度の平均を算出した． • 提案配置はランダム配置に比べ， 最大11.67倍早い． (一般ノード数=50) • ランダム配置は一般ノード数が 増えるにつれ応答速度も増加する． • 提案配置は一般ノード数が増えても 応答速度を一定に保っている． 19 ログの配置されたノード数の少なさによるも の 提案配置: 3台(3日分) ランダム配置: 最大 50台(3日分) →50 / 3 ≈ 16.6 [倍] →35 / 3 ≈ 11.6 [倍] (推定) 0.33 3.96
20. 議論 • ログの分割単位 • ログの分割単位を小さくするほど，検索期間の狭いログ検索における 応答速度が早くなる． →分割することで検索すべきログファイルが減るため • ログの分割単位を大きくするほど，検索期間の広いログの検索におけ る通信量が削減できる． →一般ノードへの検索要求をまとめられるため • ログの内容や出力頻度，利用目的により検索クエリは異なる． 20
21. まとめ • 課題: ログの分散配置における検索の応答速度の低下 • 提案: 検索シナリオを想定したルールに基づくログの転送と配置 • 評価: ランダム配置と提案配置での検索の応答速度をログ件数， ノード数を変えて計測 • 結果: ログ件数を変更した場合，ログ件数 10000[件/台]で3.78倍早い． ノード数を変更した場合，ノード数 50[台] で11.67倍早い． • 貢献: 提案により検索性能に配慮した分散ログ管理を実現 検索の応答速度を向上により，システム管理者の作業時間を削減 21
23. Appendix 23
24. 実験の様子 :: K8s上にコンテナをデプロイ 24
25. 実験の様子 :: ログ配置ルール(ランダム)を可 視化 25
26. 実験の様子 :: ログ配置ルール(提案)を可視化 26