自作ログ収集・分析基盤をゼロから構築するための全体リファレンス

はじめに

これまで、syslog / authlog を収集して、HDFS、Hive、Iceberg、Trino、Grafana、Flink、Elasticsearch へ広げていくログ収集・分析基盤を個別記事として作ってきました。

さらに、自宅 HDFS 上の Iceberg を Source of Truth として残しながら、AWS S3 / Glue Data Catalog / Athena 側へ分析用コピーを作り、QuickSight / Amazon Quick で可視化する構成も追加しました。

この記事では、個別の構築コマンドや設定ファイル全文は再掲せず、どの順番で何を作り、どの記事を参照すれば全体を構築できるかを整理します。

全体アーキテクチャや設計思想から先に確認したい場合は、以下の記事を参照してください。

• Kafka・Iceberg・Flinkで作るsyslog/authlog分析基盤まとめ

詳細手順は各リンク先の記事を正とします。

今回作るもの

今回の最終形は、各 Linux サーバの syslog / authlog を Kafka に集め、HDFS に Raw データとして保存し、Hive で整形し、Iceberg を分析データの正本として管理し、Trino / Grafana / Web アプリ / Elasticsearch / LLM 連携 API から参照できるログ分析基盤です。

さらに必要に応じて、自宅 Iceberg を Source of Truth として残したまま、AWS S3 / Glue Data Catalog / Athena へ分析用コピーを作り、AWS 側のダッシュボードへ広げられます。

まずは以下の基本ログ分析基盤を作ります。

rsyslog / Fluentd
↓
Kafka
↓
Kafka Connect
↓
HDFS Raw
↓
Hive Raw / Curated
↓
Spark / Iceberg
↓
Trino
↓
Grafana

その後、必要に応じて以下を追加します。

• リアルタイム処理: Flink
• 全文検索・高速検索: Elasticsearch / Kibana
• 検索 UI: Elixir 製 Web アプリ
• 自然文分析: Open WebUI / FastAPI / Ollama
• クラウド分析・可視化: AWS S3 / Glue Data Catalog / Athena / QuickSight / Amazon Quick
• 可用性向上: Hadoop、Hive Metastore、Kafka、Trino、Flink、Elasticsearch の複数ノード化

最終的にできること

最終的には、次のような基盤になります。

• syslog / authlog を Kafka に集約できる
• HDFS Raw に元ログを残せる
• Hive Curated で分析しやすい形へ整形できる
• Iceberg を正本として長期分析・再投入・保守ができる
• Trino / Grafana でダッシュボード化できる
• Flink を追加すればリアルタイム明細・1分集計を扱える
• Elasticsearch / Kibana を追加すれば全文検索・ログ調査がしやすくなる
• Web アプリを追加すれば利用者向け検索画面を提供できる
• LLM 連携を追加すれば自然文で件数取得、傾向分析、結果要約ができる
• AWS 分析コピーを追加すれば、S3 / Glue / Athena からサーバーレスに同期済みログを分析できる
• AWS 側の可視化を追加すれば、QuickSight / Amazon Quick でダッシュボード化できる
• 必要に応じて Trino / Flink / Kafka / Hive / Hadoop を段階的に複数ノード化できる

必要となるハードウェアスペック

このリファレンスは、Proxmox などの仮想化基盤上に複数 VM を立てて検証する前提で整理しています。
最初から全コンポーネントを同時に起動する必要はありませんが、Hadoop / Hive / Kafka / Trino / Flink / Elasticsearch / LLM まで広げる場合は、ホスト側のメモリとディスク容量に余裕を持たせておくと進めやすいです。
Proxmox VE 上の検証 VM を Terraform でまとめて作成する場合は、TerraformでProxmox VEにCloud-init対応VMを複数台作成する も合わせて参照します。

物理ホストの目安

用途	CPU	メモリ	ストレージ	GPU
最小検証	4コア以上	32GB以上	SSD 500GB以上	不要
標準検証	8コア以上	64GB以上	SSD 1TB以上	不要
全体検証	8コア以上	96GB以上	SSD 1.5TB以上	LLM をローカル実行する場合のみ推奨

実際に筆者環境では、Core i7-10700、DDR4 96GB、SSD 1.5TB 程度の PC を使う想定で構成しています。
Ollama などでローカル LLM まで動かす場合は、NVIDIA GPU 搭載ホストを別途用意するか、GPU 付きホストへ LLM 系コンポーネントだけ分離すると扱いやすいです。

最小検証について、Ubuntu24.04/AlmaLinix9 VM1台ずつ、メモリ４GBの構成で
一通りの構築もできます。

複数モジュールを導入しても稼働することを確認しています。

VMスペックの基本目安

各手順で個別指定がない場合は、以下を基本スペックとして考えます。

項目	目安
CPU	2 vCPU
メモリ	2GB RAM
ディスク	30GB
OS	Ubuntu 24.04 または AlmaLinux 9

ただし、メモリ使用量が大きいコンポーネントは次のように増やします。

コンポーネント	目安
Flink	2 vCPU / 4GB RAM / 30GB
Trino	2 vCPU / 4GB RAM / 30GB
Elasticsearch	2 vCPU / 6GB RAM / 30GB
Open WebUI / LLM 連携 API	2 vCPU / 4GB RAM 以上
Ollama / ローカル LLM	モデルサイズに応じて増強。GPUパススルー 利用を推奨

HDFS の DataNode については、保存するログ量に応じてディスクを増やします。
小規模検証では 30GB でも流れを確認できますが、継続的に syslog / authlog を蓄積する場合は、DataNode 用に 50GB 以上の追加ディスクを用意する方が安全です。

起動台数の考え方

全記事を一通り構築すると VM 数が多くなるため、常にすべてを起動しておく必要はありません。
まずは Hadoop / Hive / Kafka / Trino までの基本ログ分析基盤を起動し、必要に応じて Flink、Elasticsearch、Web アプリ、LLM 系を追加します。

リソースに余裕がない場合は、以下の順で段階的に進めると確認しやすいです。

1. Hadoop / HDFS
2. Hive / PostgreSQL
3. Kafka / Fluentd / Kafka Connect
4. Spark / Iceberg / Trino
5. Grafana / Zeppelin
6. Flink
7. Elasticsearch / Kibana / Web アプリ
8. Open WebUI / LLM 連携 API / Ollama

システム構成と前提チェック

各記事に進む前に、まず全体で共通する前提を確認します。
特に名前解決、Java バージョン、HDFS / Hive Metastore / Kafka の接続先がずれていると、後続の記事で原因を追いにくくなります。

共通前提

項目	前提
OS	主に Ubuntu 24.04。Flink と PostgreSQL pgpool は AlmaLinux 9
名前解決	各 VM 間で hostname による名前解決ができる
時刻同期	全ノードで時刻が大きくずれていない
ネットワーク	HDFS / Hive / Kafka / Trino / Flink などの通信ポートに到達できる
ユーザー	Hadoop 系サービス用ユーザーと SSH 方針を決めている
ストレージ	HDFS DataNode 用ディスク容量を確保している
操作端末	HDFS / Hive / Kafka などの管理コマンドを実行する操作ホストを用意する

現行構成の前提値

既存記事から読み取れる現行前提は以下です。
自分の環境でホスト名や nameservice を変える場合は、各記事中の設定値もあわせて読み替えてください。

項目	現行値・方針
Hadoop	3.3.6（BigTop）
HDFS nameservice	cluster1
Hive	3.1.3
Hive Metastore	hive1:9083, hive2:9083
PostgreSQL HA	pgpool 版を推奨、repmgr 版は参考
Kafka	3.7.1、KRaft 構成
Kafka bootstrap	kafka1:9092,kafka2:9092,kafka3:9092
Kafka topic	syslog, authlog
Spark	3.5.8
Iceberg catalog	hive_prod
Iceberg warehouse	hdfs://cluster1/warehouse/iceberg
バッチ正本テーブル	syslog_iceberg, authlog_iceberg
Flink	2.0.1
Flink リアルタイム明細	syslog_events, authlog_events
Flink 1分集計	syslog_host_1m, authlog_host_1m
Trino	476
Trino catalog	hive, iceberg
Elasticsearch	Iceberg から投入する検索用データストア
LLM 連携	Open WebUI / FastAPI / Ollama
AWS 分析・可視化	S3 / Glue Data Catalog / Athena / QuickSight / Amazon Quick

Java バージョンはコンポーネントごとに異なります。

コンポーネント	Java
Hadoop / Hive	Java 8
Spark	Java 11
Kafka / Flink	Java 17
Trino	Temurin 24

Java バージョンが混ざると詰まりやすいため、検証環境ではコンポーネントごとに VM を分ける構成が扱いやすいです。
手順上では同じ OS 上で複数コンポーネントを動かしている箇所もありますが、OS や Java の前提が違うコンポーネントは分けて構築してください。

記事間の依存関係

途中の記事から作業する場合は、先に必要なものができているか確認します。

進む記事・工程	先に必要なもの
Hive / PostgreSQL	Hadoop / HDFS
Kafka Connect HDFS Sink	Kafka / HDFS
authlog 収集追加	Kafka / Fluentd / Kafka Connect
Hive Raw / Curated	HDFS Raw データ / Hive
Spark / Iceberg	Hive Metastore / HDFS
Trino	Hive Metastore / Iceberg
Grafana / Zeppelin	Trino / Hive
Flink リアルタイム拡張	Kafka / HDFS / Iceberg
Elasticsearch / Kibana	Iceberg または Hive / Spark
検索 Web アプリ	Elasticsearch / Trino
LLM 連携 API	Trino / 分析対象テーブル
HA / 複数ノード化	単体構成での動作確認

全体アーキテクチャ

現行構成を統合すると、全体像は以下になります。

この構成で一番大事なのは、Iceberg を分析データの Source of Truth として扱うことです。

Elasticsearch は Iceberg の代替ではありません。Elasticsearch は全文検索やログ調査を高速化するための検索用データストアとして追加します。壊れても Iceberg から再投入できる位置づけにしておくと、運用が分かりやすくなります。

AWS 側の S3 / Glue / Athena も、自宅 Iceberg の代替ではありません。自宅 HDFS 上の hive_prod.logs.syslog_iceberg / hive_prod.logs.authlog_iceberg を Source of Truth として残し、AWS 側には Athena 分析用のコピーを作ります。さらに QuickSight / Amazon Quick を追加すると、同期済みログを AWS 側でも Dashboard として確認できます。

データの流れ

リアルタイム拡張を入れる場合は、Kafka から Flink が直接読み取り、Iceberg のリアルタイム明細テーブルや1分集計テーブルへ書き込みます。

構築前に理解しておきたい役割分担

コンポーネント	役割
rsyslog	各ホストからログを転送する入口
Fluentd	rsyslog で受けたログを整形し、Kafka topic へ投入する
Kafka	ログイベントの受け皿。後段停止時のバッファにもなる
Kafka Connect	Kafka のログを HDFS Raw 領域へ継続保存する
HDFS	Raw ログ、Hive データ、Iceberg データ、Flink checkpoint / savepoint の保存先
ローカルAPTリポジトリ	Hadoop / Spark / Flink などのパッケージ取得を安定化し、再現性を高める補助基盤
操作ホスト	HDFS / Hive / Kafka などの管理コマンドを集約して実行する運用端末
PostgreSQL / Hive Metastore	Hive / Iceberg のメタデータ管理
Hive	Raw JSON を読み、Curated Parquet へ整形する
Spark	Hive Curated から Iceberg へ投入し、Iceberg の保守も担当する
Iceberg	分析データの正本。履歴分析、再投入、保守の中心
Trino	Iceberg / Hive を SQL で高速に参照するクエリエンジン
Grafana	Trino 経由でダッシュボードを作る
Zeppelin	Hive / Trino などに対してノートブック形式で探索・確認する
Flink	Kafka からリアルタイムに読み、Iceberg へ明細・集計を書き込む拡張
Elasticsearch	Iceberg のデータを検索しやすくする検索用データストア
Kibana / Web アプリ	Elasticsearch や Trino を使ったログ検索 UI
Spark Export Job	自宅 Iceberg から AWS 側 Iceberg へ日次複製する
Amazon S3	AWS 側 Iceberg warehouse と Athena query result の保存先
AWS Glue Data Catalog	AWS 側 Iceberg テーブルを Athena から参照するための catalog
Amazon Athena	S3 上の Iceberg テーブルをサーバーレスに SQL 分析する
QuickSight / Amazon Quick	Athena 上のログを BI dashboard として可視化する
IAM	Spark から S3 / Glue へ最小権限でアクセスするための認可
Knox / LDAP	Hadoop 系 Web UI への認証・SSL を追加する運用強化
Open WebUI	自然文でログ分析を依頼するチャット UI
LLM 連携 API	質問分類、SQL テンプレート選択、安全化、Trino 実行、結果整形を行う制御層
Ollama / ローカル LLM	自然文の意図解釈や分析結果の要約を担当する

AWS 側 Iceberg コピーの対象テーブルは、日次同期または明示的な手動バッチ以外では更新しない前提です。
同じ dt に対する通常同期、手動再実行、AWS コピーからの復旧用リストアは同時に実行せず、1つずつ完了させます。
この前提であれば、双方向同期のような競合解決を持ち込まずに運用できます。

構築順序

最小構成で作る場合

最初からすべてを作る必要はありません。

まずログ分析基盤として成立させるなら、以下の順番で十分です。

Hadoop / HDFS
↓
Hive Metastore / Hive
↓
Kafka
↓
rsyslog / Fluentd
↓
Kafka Connect
↓
Hive Raw / Curated
↓
Spark / Iceberg
↓
Trino
↓
Grafana

この最小構成でできることは以下です。

• syslog / authlog を集約できる
• Kafka によって後段停止時のバッファを持てる
• HDFS Raw にログを保存できる
• Hive Curated で分析しやすい形に整形できる
• Iceberg を正本として管理できる
• Trino / Grafana で可視化できる

Flink、Elasticsearch、Kibana、検索 Web アプリ、LLM 自然文分析、AWS 分析用コピー・可視化、完全 HA 化は後から追加できます。

拡張していく場合

最小構成ができた後は、目的別に拡張します。

目的	追加するもの	参照記事
秒から分単位で可視化したい	Flink	syslog/authlogをリアルタイム解析できるようにする
Grafana を軽くしたい	Flink 1分集計テーブル	Apache Flink + Iceberg で syslog/authlog の1分集計テーブルを作り、Trino/Grafana を高速化する
全文検索したい	Elasticsearch / Kibana	ログ分析基盤に Elasticsearch / Kibana を追加してみる（構築編）
利用者向け検索 UI がほしい	Elixir 検索アプリ	【実践編】GitHubから取得してすぐ使える！Elixir製ログ検索サイトでElasticsearchを検索する
Iceberg を直接検索したい	Trino 経由 Web アプリ	【実践編】GitHubから取得してすぐ使える！Elixir製ログ検索サイトでIcebergを検索する
自然文でログ分析したい	Open WebUI / FastAPI / Ollama	LLM連携による自然文ログ分析環境を構築してみた
AWS側でもAthena分析したい	S3 / Glue / Athena 分析用コピー	自宅HDFS上のApache IcebergをAWS S3へ複製してAthenaで分析する構成を考える【設計編】 / 構築編
AWS側でも可視化したい	QuickSight / Amazon Quick	AWS S3上のApache IcebergをAthena経由で可視化する【発展編】
AWS側コピーから自宅Icebergへ戻したい	Iceberg リストア	AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】
ノートブックでSQLを試したい	Zeppelin	HadoopクラスタにZeppelinを導入してみた。
Trino の処理を分散したい	Trino Worker	Trino を複数台構成にしてみた。
Flink の処理を分散したい	TaskManager 追加	Apache Flinkを1台構成から3台クラスタへ移行してみる（JobManager 1台・TaskManager 3台）
Flink 制御面を HA 化したい	JobManager HA	Apache Flink Standalone の JobManager HA を ZooKeeper + HDFS で構築してみる
Hadoop 管理画面を保護したい	Knox / LDAP	Hadoopクラスタにknox/ldapを導入してみた。

1. Hadoop / HDFSを構築する

ここで作るもの

ログや分析データの保存先となる Hadoop / HDFS クラスタを構築する。

このコンポーネントの役割

Kafka Connect、Hive、Iceberg、Flink から利用する共通ストレージ。現行構成では HDFS nameservice は cluster1。

この段階で必要な前提

• Linux サーバ準備済み
• ホスト名解決済み
• Hadoop 用ユーザーや SSH の方針を決めている

構築手順

詳細な構築方法は以下の記事を参照。

• hadoopをクラスタ化してみた。

外部 APT リポジトリに依存せず、複数台を同じパッケージ構成で作りたい場合は以下も先に用意しておくと扱いやすいです。

• Ubuntu 24.04でローカルAPTリポジトリサーバを構築し、Hadoopクラスタの再現性を高める

まず1台で試す場合は以下も参考。

• シングルノードhadoopを構築してみた。
• ansibleでHadoop/hive/zeppelinシングルノードを構築する

完了の目安

• NameNode / DataNode / JournalNode が正常起動している
• hdfs://cluster1 に対してファイル作成・参照ができる
• 後続ホストから HDFS へ名前解決できる

次に進む工程

Hive Metastore と Hive を構築する。

2. PostgreSQL / Hive Metastore / Hiveを構築する

ここで作るもの

HiveServer2、Hive Metastore、Metastore 用 PostgreSQL を構築する。

このコンポーネントの役割

HDFS 上の Raw / Curated テーブルを SQL で扱えるようにし、Iceberg catalog のメタデータ管理にも利用する。

この段階で必要な前提

• Hadoop / HDFS が構築済み
• HDFS nameservice cluster1 が使える
• Hive Metastore の接続先方針を決めている

構築手順

現行の推奨は pgpool 版です。

• HadoopクラスタにHiveクラスタを導入してみた。(pgpool版)

参考として、repmgr 版とシングルノード版もあります。

• HadoopクラスタにHiveクラスタを導入してみた。(repmgr版)
• シングルノードhiveを構築してみた。

完了の目安

• Hive Metastore が起動している
• HiveServer2 に接続できる
• HDFS 上の Hive warehouse を利用できる
• 後続の Spark / Trino から Metastore へ接続できる

次に進む工程

Kafka クラスタを構築する。

3. Kafkaを構築する

ここで作るもの

ログイベントを受ける Kafka クラスタと Kafka Connect 実行基盤を構築する。

このコンポーネントの役割

rsyslog / Fluentd から受けた syslog / authlog を topic に保持し、Kafka Connect や Flink から読み出せるようにする。

この段階で必要な前提

• Hadoop / HDFS が構築済み
• Kafka Broker、Controller、Connect 用ホストの名前解決ができる
• HDFS Sink から HDFS へ接続できる

構築手順

クラスタ構成の推奨記事はこちら。

• Kafkaをクラスタ化してsyslogを収集してみた。

1台 PoC として試す場合はこちら。

• 各ホストのsyslogを収集して、bigtop基盤で可視化してみた。

完了の目安

• Kafka Broker が起動している
• syslog topic を作成できる
• Kafka Connect が起動している
• Connect 用 internal topic が作成されている

次に進む工程

rsyslog / Fluentd から Kafka へログを送る。

4. rsyslogからKafkaへログを送る

ここで作るもの

各 Linux サーバから log relay へ rsyslog で転送し、Fluentd で JSON 化して Kafka へ投入する経路を作る。

このコンポーネントの役割

ログ収集の入口。後続の HDFS 保存、Flink リアルタイム処理、検索拡張は、ここで Kafka に入ったログを起点にする。

この段階で必要な前提

• Kafka が起動済み
• log relay ホストから Kafka Broker へ接続できる
• 収集対象ホストから log relay へ TCP/UDP 514 などで到達できる

構築手順

• Kafkaをクラスタ化してsyslogを収集してみた。
• 各ホストのsyslogを収集して、bigtop基盤で可視化してみた。

完了の目安

• 収集対象ホストから送った syslog が log relay に届く
• Fluentd 経由で Kafka の syslog topic にメッセージが入る

次に進む工程

Kafka Connect で HDFS Raw へ保存する。

5. Kafka ConnectでHDFSへ保存する

ここで作るもの

Kafka topic のログを HDFS Raw 領域へ保存する HDFS Sink Connector を構築する。

このコンポーネントの役割

Kafka 上のログを消費し、再処理可能な Raw データとして HDFS に残す。ここがバッチ分析ルートの入口になる。

この段階で必要な前提

• Kafka topic にログが入っている
• Kafka Connect が起動済み
• Connect ホストに Hadoop 設定が配置済み
• HDFS hdfs://cluster1 へ書き込める

構築手順

• Kafkaをクラスタ化してsyslogを収集してみた。
• 各ホストのsyslogを収集して、bigtop基盤で可視化してみた。

完了の目安

• HDFS の /data/kafka/syslog 配下に Raw ログが保存される
• Kafka Connect の lag が大きく増え続けない
• HDFS 上のファイルを Hive Raw から読める準備ができている

次に進む工程

authlog を追加する場合は authlog 収集へ進む。syslog のみで試す場合は Hive Raw / Curated へ進む。

6. authlog収集を追加する

ここで作るもの

syslog とは別に authlog を収集し、Kafka topic と HDFS 保存先を分ける。

このコンポーネントの役割

認証ログを独立した分析対象として扱えるようにする。Flink、Iceberg、Grafana でも syslog と authlog を別テーブルとして扱う。

この段階で必要な前提

• syslog 収集経路が動作済み
• Kafka クラスタが稼働済み
• log relay / Fluentd の設定を変更できる

構築手順

• Hadoop収集対象にauth.log追加してみた

完了の目安

• Kafka の authlog topic に認証ログが入る
• HDFS の authlog 用 Raw 領域にデータが保存される
• syslog と authlog を別々に確認できる

次に進む工程

Hive で Raw ログを整形する。

7. HiveでRawログを整形する

ここで作るもの

HDFS Raw JSON を Hive Raw テーブルとして読み、分析しやすい Hive Curated Parquet テーブルへ変換する。

このコンポーネントの役割

Raw ログを保存用データから分析用データへ整える。Iceberg へ投入する前段として、型、日付、時刻、ホスト、プログラム、メッセージなどを整理する。

この段階で必要な前提

• HDFS Raw に syslog / authlog が保存済み
• HiveServer2 / Hive Metastore が稼働済み
• 運用ホストまたは Zeppelin から Hive SQL を実行できる

構築手順

• 列指向データ作成,ローテーションスクリプト作成してみた
• Hadoop収集対象にauth.log追加してみた
• ログ収集・解析システムのテーブル設計/運用をまとめてみた。
• Kafka / Spark / Flink / Iceberg で時刻(ts)の扱いを統一する設計

Hive SQL を実行する端末やノートブック環境を分ける場合は以下も参照します。

• bigdata基盤操作ホスト作成してみた
• HadoopクラスタにZeppelinを導入してみた。

完了の目安

• Hive Raw テーブルから HDFS Raw JSON を読める
• Hive Curated テーブルに Parquet データが作成される
• 日付パーティション単位で件数確認できる
• ts の扱いが後続の Spark / Iceberg / Trino / Grafana と矛盾しない

次に進む工程

Spark / Iceberg を構築し、分析用の正本テーブルを作る。

8. Icebergへ分析用データを作る

ここで作るもの

Spark クラスタと Iceberg catalog を構築し、Hive Curated から Iceberg テーブルを作成する。

このコンポーネントの役割

HDFS 上の Parquet ファイル群を、スナップショットやメタデータを持つ分析用テーブルとして扱えるようにする。現行構成では Iceberg warehouse は hdfs://cluster1/warehouse/iceberg、catalog 名は hive_prod。

この段階で必要な前提

• Hive Curated テーブルが作成済み
• Hive Metastore へ接続できる
• Spark ホストから HDFS / Hive 設定を参照できる

構築手順

• ログ収集・解析基盤にSpark/Icebergを構築してみた
• 自宅ラボの syslog/authlog 基盤を Iceberg / Trino / Grafana まで拡張してみた
• Kafka / Spark / Flink / Iceberg で時刻(ts)の扱いを統一する設計

完了の目安

• hive_prod.logs.syslog_iceberg を参照できる
• hive_prod.logs.authlog_iceberg を参照できる
• Hive Curated と Iceberg の件数比較ができる
• Iceberg の snapshot / files を確認できる

次に進む工程

Trino から Iceberg を参照する。

補足として、AWS 側に Athena 分析用コピーを作る場合も、この段階で作成した hive_prod.logs.syslog_iceberg / hive_prod.logs.authlog_iceberg をコピー元にします。

AWS 側へ連携する場合は、HDFS 上の Iceberg warehouse を S3 へ単純コピーするのではなく、Spark + Iceberg で glue_prod.logs.syslog_iceberg / glue_prod.logs.authlog_iceberg へ書き直します。

• 自宅HDFS上のApache IcebergをAWS S3へ複製してAthenaで分析する構成を考える【設計編】
• 自宅HDFS上のApache IcebergをAmazon S3へ複製しAthenaから分析してみる【構築編】
• AWS S3上のApache IcebergをAthena向けに運用する【運用編】
• AWS S3上のApache IcebergをAthena経由で可視化する【発展編】
• AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】

9. TrinoからIcebergを参照する

ここで作るもの

Trino を構築し、Hive catalog と Iceberg catalog を設定する。

このコンポーネントの役割

Grafana、Zeppelin、Web アプリなどから Iceberg / Hive を SQL で参照するためのクエリエンジン。

この段階で必要な前提

• Iceberg テーブルが作成済み
• Trino ホストに Hadoop 設定を配置済み
• Hive Metastore へ接続できる

構築手順

• Grafana&Trino&Zeppelinを使用してログ解析基盤から情報を可視化する。

完了の目安

• Trino で hive catalog と iceberg catalog が見える
• iceberg.logs.syslog_iceberg を参照できる
• iceberg.logs.authlog_iceberg を参照できる

次に進む工程

Grafana で可視化する。

10. Grafana / Zeppelinで可視化・探索する

ここで作るもの

Grafana から Trino datasource を利用し、Iceberg テーブルをダッシュボード表示する。必要に応じて Zeppelin から Hive / Trino に接続し、ノートブック形式で探索・確認できるようにする。

このコンポーネントの役割

ログ件数、ホスト別件数、時系列推移などを可視化する。Grafana は日次・時間単位の傾向把握、Zeppelin はSQLの試行や調査メモを残しながらの探索に向いている。

この段階で必要な前提

• Trino が稼働済み
• Grafana から Trino に接続できる
• Zeppelin を使う場合は HiveServer2 または Trino へ接続できる
• Iceberg テーブルにデータが入っている

構築手順

• Grafana&Trino&Zeppelinを使用してログ解析基盤から情報を可視化する。
• HadoopクラスタにZeppelinを導入してみた。
• ログ収集・解析システムのテーブル設計/運用をまとめてみた。

完了の目安

• Grafana datasource として Trino を登録できる
• Zeppelin から HiveServer2 または Trino に接続できる
• syslog / authlog の時系列グラフを表示できる
• 表示時刻が意図したタイムゾーンと一致している

次に進む工程

ここまでで基本ログ分析基盤として成立します。以降は必要に応じて Flink、Elasticsearch、Web アプリ、LLM 自然文分析、AWS 分析用コピー・可視化、HA 化へ進みます。

11. Flinkでリアルタイム処理を追加する

ここで作るもの

Flink を追加し、Kafka から syslog / authlog を読み、Iceberg のリアルタイム明細テーブルや1分集計テーブルへ書き込む。

このコンポーネントの役割

バッチ中心の構成に、秒から分単位のリアルタイム処理を追加する。Flink は必須ではなく、Grafana へ素早く反映したい場合の拡張。

この段階で必要な前提

• Kafka の syslog / authlog topic が稼働済み
• Iceberg warehouse と Hive Metastore が利用可能
• Trino / Grafana から Iceberg を参照できる
• checkpoint / savepoint 用 HDFS 領域を設計している

構築手順

設計を確認してから、1台構成、集計、運用、複数ノード化の順に進めると分かりやすいです。

• Hadoop + Kafka + Iceberg 環境に Flink を追加してリアルタイム可視化する設計
• syslog/authlogをリアルタイム解析できるようにする
• Flink SQL ジョブを systemd で自動起動させた
• Apache Flink + Iceberg で syslog/authlog の1分集計テーブルを作り、Trino/Grafana を高速化する
• Flink SQL ジョブをsavepoint&checkpointを用いた運用へ安全に載せ替える

完了の目安

• Flink Web UI で SQL ジョブが RUNNING になっている
• Iceberg の syslog_events / authlog_events にデータが入る
• syslog_host_1m / authlog_host_1m を Grafana から参照できる
• checkpoint / savepoint の運用方針が決まっている

次に進む工程

全文検索が必要な場合は Elasticsearch を追加する。Flink の可用性が必要な場合は TaskManager 分散と JobManager HA へ進む。

12. Elasticsearchで検索機能を追加する

ここで作るもの

Iceberg のログデータを Elasticsearch Data Stream へ投入し、Kibana で検索・調査できる環境を作る。

このコンポーネントの役割

全文検索、フィールド検索、Discover による調査を高速化する。Iceberg は正本、Elasticsearch は検索用データストアとして分けて考える。

この段階で必要な前提

• Iceberg に syslog_iceberg / authlog_iceberg が作成済み
• バッチ実行ホストから Iceberg を読める
• Elasticsearch / Kibana 用ホストを用意している

構築手順

• ログ分析基盤に Elasticsearch / Kibana を追加してみる（設計編）
• ログ分析基盤に Elasticsearch / Kibana を追加してみる（構築編）
• ログ分析基盤に Elasticsearch / Kibana を追加してみる（実践編）
• ログ分析基盤に Elasticsearch / Kibana を追加してみる（運用編）

別 Hadoop / Hive の Parquet データを投入する場合はこちら。

• 別Hadoop Hive ParquetデータをElasticsearch Data Streamへ追加投入する

完了の目安

• Elasticsearch に logs-syslog-* / logs-authlog-* が作成される
• Kibana Discover からログ検索できる
• Elasticsearch 障害時は Iceberg から再投入できる設計になっている

次に進む工程

Kibana 以外の検索 UI が必要な場合は Web アプリを追加する。

13. Webアプリから検索できるようにする

ここで作るもの

Elasticsearch または Trino / Iceberg を検索する Web アプリを構築する。

このコンポーネントの役割

Kibana より軽量な利用者向け検索画面を提供する。運用担当者向けの検索ポータルとして使える。

この段階で必要な前提

• Elasticsearch 版は Elasticsearch が稼働済み
• Iceberg 版は Trino から Iceberg を参照可能
• Docker / Docker Compose を使える

構築手順

• 【実践編】GitHubから取得してすぐ使える！Elixir製ログ検索サイトでElasticsearchを検索する
• 【実践編】GitHubから取得してすぐ使える！Elixir製ログ検索サイトでIcebergを検索する

Qiita 記事検索の用途では以下も参考になります。

• Qiita記事をElasticsearchへ取り込み、検索Webアプリで参照できるようにする

完了の目安

• ブラウザからログ検索できる
• host / program / message / 時刻範囲などで絞り込める
• Elasticsearch 版と Iceberg 版の使い分けができている

次に進む工程

自然文でログ分析したい場合は LLM 連携を追加する。可用性が必要な場合は HA 化・複数ノード化を進める。

14. LLMで自然文ログ分析できるようにする

ここで作るもの

Open WebUI、FastAPI の LLM 連携 API、Ollama / ローカル LLM を追加し、利用者が自然文で syslog / authlog を分析できる環境を作る。

このコンポーネントの役割

SQL を直接書かなくても、件数取得、日別・時間別推移、ホスト別分析、SSH ログイン成功/失敗などを自然文で問い合わせられるようにする。

LLM は Iceberg や Trino を置き換えるものではありません。既存の Iceberg テーブルを Trino 経由で参照し、利用者の質問を安全な SQL パターンへ変換したり、結果を日本語で要約したりする補助レイヤーとして追加します。

この段階で必要な前提

• Trino から iceberg.logs.syslog_iceberg / iceberg.logs.authlog_iceberg を参照できる
• Open WebUI / FastAPI 用の Docker ホストを用意している
• Ollama 用ホストを用意している
• GPU を使う場合は NVIDIA ドライバ / CUDA を事前に導入している
• Trino には read-only ユーザーを用意する

構築手順

まず構想を確認し、その後に実装記事へ進むと流れが分かりやすいです。

• LLM連携による自然文ログ分析の構想
• LLM連携による自然文ログ分析環境を構築してみた

完了の目安

• Open WebUI からログ分析用のチャットを開ける
• FastAPI が Trino へ接続できる
• 「昨日の authlog 件数」「過去7日の syslog ホスト上位」などの定義済み質問に回答できる
• 回答に使われた SQL を確認できる
• 任意 SQL 実行やテーブル変更系の操作ができないよう制限されている

次に進む工程

AWS 側でも Athena から分析したい場合は、S3 / Glue / Athena への分析用コピーを追加する。ダッシュボード化したい場合は QuickSight / Amazon Quick を追加する。可用性が必要な場合は HA 化・複数ノード化を進める。

15. AWS S3 / Glue / Athenaへ分析用コピーを作る

ここで作るもの

自宅 HDFS 上の Iceberg テーブルを Source of Truth として残し、AWS 側に分析用 Iceberg コピーを作る。必要に応じて、Athena で分析できるデータを QuickSight / Amazon Quick から可視化する。
対象テーブルは日次または手動バッチでのみ更新する前提とし、同じ dt に対する通常同期、手動再実行、復旧用リストアは並列実行しない。

このコンポーネントの役割

Athena からサーバーレスにログ分析できるようにする。自宅側の Iceberg を置き換えるのではなく、同期済み範囲を AWS 側でも参照できるようにする。

さらに可視化を追加すると、Athena の SQL 結果を毎回手動で確認するだけでなく、BI dashboard やログ時系列 dashboard として確認できる。

自宅:
hive_prod.logs.syslog_iceberg
hive_prod.logs.authlog_iceberg

AWS:
glue_prod.logs.syslog_iceberg
glue_prod.logs.authlog_iceberg

この段階で必要な前提

• hive_prod.logs.syslog_iceberg / hive_prod.logs.authlog_iceberg が作成済み
• Spark から自宅側 Iceberg を参照できる
• AWS 側に S3 bucket / Glue database / IAM 権限を用意できる
• Spark に Iceberg AWS integration を追加できる
• AWS credential を記事や GitHub に直接書かない運用にしている

構築手順

• 自宅HDFS上のApache IcebergをAWS S3へ複製してAthenaで分析する構成を考える【設計編】
• 自宅HDFS上のApache IcebergをAmazon S3へ複製しAthenaから分析してみる【構築編】
• AWS S3上のApache IcebergをAthena向けに運用する【運用編】
• AWS S3上のApache IcebergをAthena経由で可視化する【発展編】
• AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】

完了の目安

• S3 に warehouse/logs/syslog_iceberg / warehouse/logs/authlog_iceberg が作成される
• Glue Data Catalog に logs.syslog_iceberg / logs.authlog_iceberg が登録される
• Athena から SELECT count(*) を実行できる
• 同一日付で自宅側 Iceberg と AWS 側 Iceberg の件数が一致する
• 同じ DT を再実行しても重複登録されない
• 必要に応じて、QuickSight / Amazon Quick から Athena dataset として参照できる

次に進む工程

ローカル基盤全体の可用性が必要な場合は HA 化・複数ノード化を進める。

16. HA化・複数ノード化する

ここで作るもの

PoC として動いた基盤を、複数ノード化・冗長化していく。

このコンポーネントの役割

単一障害点を減らし、ログ量やクエリ負荷の増加に対応する。

この段階で必要な前提

• 最小構成が一通り動いている
• どのコンポーネントがボトルネックか把握している
• いきなり全コンポーネントを HA 化せず、効果の大きいところから進める

構築手順

• Hadoop Worker 追加・HDFS HA: hadoopをクラスタ化してみた。
• Hive / Metastore HA: HadoopクラスタにHiveクラスタを導入してみた。(pgpool版)
• Kafka / Connect 複数ノード: Kafkaをクラスタ化してsyslogを収集してみた。
• Trino Worker 追加: Trino を複数台構成にしてみた。
• Flink TaskManager 分散: Apache Flinkを1台構成から3台クラスタへ移行してみる（JobManager 1台・TaskManager 3台）
• Flink JobManager HA: Apache Flink Standalone の JobManager HA を ZooKeeper + HDFS で構築してみる
• Elasticsearch 運用・将来拡張: ログ分析基盤に Elasticsearch / Kibana を追加してみる（運用編）
• Hadoop Web UI 認証・SSL: Hadoopクラスタにknox/ldapを導入してみた。

完了の目安

• Worker 追加後も既存の Grafana / Zeppelin / Web アプリの接続先が整理されている
• 障害時の再起動順序と復旧確認ポイントが決まっている
• Kafka lag、Flink checkpoint、HDFS 容量、Trino クエリ負荷を監視できる

次に進む工程

運用監視、再投入、テーブル保守を整える。

運用時に必要になる記事

運用を始めると、構築そのものよりも、テーブル保守、再投入、時刻、容量、ジョブ運用が大事になります。

• ログ収集・解析システムのテーブル設計/運用をまとめてみた。
• Kafka / Spark / Flink / Iceberg で時刻(ts)の扱いを統一する設計
• 列指向データ作成,ローテーションスクリプト作成してみた
• HDFS容量監視を実施してみた。
• bigdata基盤操作ホスト作成してみた
• Ubuntu 24.04でローカルAPTリポジトリサーバを構築し、Hadoopクラスタの再現性を高める
• Hadoopクラスタにknox/ldapを導入してみた。
• Flink SQL ジョブを systemd で自動起動させた
• Flink SQL ジョブをsavepoint&checkpointを用いた運用へ安全に載せ替える
• ログ分析基盤に Elasticsearch / Kibana を追加してみる（運用編）
• AWS S3上のApache IcebergをAthena向けに運用する【運用編】
• AWS S3上のApache IcebergをAthena経由で可視化する【発展編】
• AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】
• Hadoop distcpでHDFSのrawログをAmazon S3へバックアップしてみる

AWS 側へ Iceberg コピーを作る場合は、Athena の Data scanned、S3 保存容量、Glue Data Catalog、S3 request、Iceberg metadata / snapshot の保守も運用項目に入ります。QuickSight / Amazon Quick で可視化する場合は、Dashboard 更新によって Athena query が繰り返し実行される点も確認します。

また、Iceberg テーブルとは別に HDFS 上の raw ログを S3 へ退避しておくと、必要に応じて HDFS の検証用パスへ戻し、既存処理から Hive curated や Iceberg を再生成する用途にも使えます。

データ移行関連記事

再取り込みやデータ移行、旧環境からの補完が必要になった場合は以下を参照します。

• HDFS同士のデータコピーをやってみた。
• Hadoop distcpでHDFSのrawログをAmazon S3へバックアップしてみる
• HDFSデータ比較・再取り込みシェルを作成してみた
• Kafka MirrorMaker2によるHadoopクラスタ間レプリケーションやってみた。
• 別Hadoop Hive ParquetデータをElasticsearch Data Streamへ追加投入する

HDFS 同士のデータコピーや Kafka MirrorMaker2 は、Hadoop クラスタ間の補完・移行に使う記事です。Iceberg を AWS S3 / Glue / Athena へ連携する場合は、HDFS 上の Iceberg ディレクトリを単純コピーするのではなく、Spark + Iceberg で AWS 側 Iceberg テーブルとして書き直します。

HDFS依存の削減とAWSマネージドサービスへの移行

基本構成を一通り構築した後、HDFS依存を段階的に減らしたい場合や、Kafka以降の処理をAWSマネージドサービスへ移したい場合は、次の記事を参照します。

HDFSからS3へ段階移行する

記事	概要
【導入編】HDFSログ分析基盤をAWS S3へ段階移行する全8編の構成を紹介する	HDFS Raw、Hive、Iceberg、Flink、Trinoなどの依存関係を整理し、既存のS3 RawバックアップとS3 Icebergを利用しながらHDFSを段階的に縮小する全体方針をまとめています。
【第1編】Hiveの中間テーブルを廃止してHDFSからApache Icebergへ直接取り込んでみる	Hive Curatedの中間テーブルを減らし、SparkでHDFS RawからIcebergへ直接ロードする構成へ変更します。旧方式との件数・時刻・集計結果を比較してから切り替えます。
【第2編】HDFSのrawログとApache IcebergをローカルS3へ移行してみる	Apache OzoneのS3 Gatewayを使い、Rawログはobjectとしてコピーし、Icebergは新しいtableへ論理コピーする手順を扱います。AWSへ移す前にS3互換環境で検証したい場合の任意工程です。
【第3編】Apache OzoneのローカルS3からAWS S3へrawログとIcebergを移行してみる	既存のS3 RawバックアップとS3 Icebergを標準経路として引き継ぎます。既存データを利用できない場合は、OzoneのRawログをS3へコピーし、IcebergをGlue Data CatalogとS3へ論理移行する代替手順も扱います。
【第4編】Apache FlinkからAWS S3上のApache Icebergへリアルタイムに書き込んでみる	KafkaのsyslogとauthlogをFlinkで処理し、AWS Glue Data Catalogで管理するS3上のIcebergへ直接ストリーミング書き込みする構成を作ります。batch用とは別のリアルタイムtableを使用します。
【第5編】ログ分析基盤に残るHDFS依存をAWS S3へ移行してみる	Kafka Connect、Spark、Flink、Hive、Trino、運用scriptなどに残るHDFS依存を棚卸しし、Raw、Iceberg、checkpoint、参照先をS3とGlueへ切り替えます。
【第6編】AWS S3移行後にHDFSを安全に停止・撤去してみる	S3への移行完了後にHDFSへの書き込みを止め、最終同期と停止観察を行います。Hadoopライブラリなど他サービスが使う依存関係を残しながら、不要なHDFSモジュールとデータ領域を段階的に撤去します。
【第7編】Amazon S3のrawログとApache Icebergに保持期間とメンテナンスを設定する	S3 Raw、batch Iceberg、Flink realtime Icebergへ用途別の保持期間を設定します。S3 LifecycleとIcebergのDELETE、snapshot期限切れ、compaction、orphan file削除を使い分けます。
【第8編】検証で作成したAWS S3・Glue・IAM環境を安全に削除してみる	継続利用する既存バックアップを保護しながら、検証専用のS3、Glue、IAM、KMSなどを依存関係の逆順で削除します。account、resource名、共有利用の有無を固定してから撤去する手順を扱います。

既存のS3 RawバックアップとS3 Icebergを利用できる場合は、Ozoneへの再コピーは必須ではありません。Rawの確認にはhome-rawlog-backup、Icebergの同期・参照にはhome-aws、AWS resourceの管理操作にはhome-aws-admin profileを使用します。

AWSマネージドサービスへ移行する

記事	概要
【導入編】オンプレのログ分析基盤をAWSマネージドサービスへ移行する全体設計	既存のS3 RawバックアップとS3 Icebergを初期データとして利用し、Kafka、Spark、Flink、TrinoをMSK、EMR Serverless、Managed Service for Apache Flink、Athenaへ移す全体構成を整理しています。
【第1回】オンプレFluentdからAmazon MSKへsyslogとauthlogを送信する	オンプレのFluentdからAmazon MSKへsyslogとauthlogを送信します。TLS、SASL/SCRAM、接続元制限を設定し、旧Kafkaへ戻せる状態で疎通を確認します。
【第2回】Amazon MSKのsyslogとauthlogをMSK ConnectでS3へRaw保存する	MSK ConnectとS3 Sink Connectorを使い、既存Rawバックアップの続きへ新しいログを保存します。新規bucketは作成せず、切り替え時刻、prefix、object数を確認しながらHDFS Sinkから移行します。
【第3回】S3 Rawログの日次Spark処理をEMR Serverlessへ移行する	オンプレSparkの日次batchをEMR Serverlessへ移し、既存のS3 Rawを入力にして処理結果を既存Iceberg tableと比較します。検証後はMSK Connect切り替え後の日付だけを追加します。
【第4回】バックアップ済みApache IcebergとAWS Glue Data Catalogを引き継ぐ	既存のS3 IcebergとGlue Data Catalogを作り直さず、EMR ServerlessとManaged Service for Apache Flinkから安全に参照・更新するための権限、catalog設定、整合性確認を整理します。
【第5回】TrinoのIceberg分析をAmazon Athenaへ移行する	Glueに登録済みのS3 Icebergを既存Athena workgroupから参照し、Trinoで使用していた基本queryを移行します。件数や集計結果を比較しながら参照先を切り替えます。
【第6回】Flink 2.0.1のログ処理をManaged Service for Apache Flinkへ移行する	オンプレFlinkのKafka Source、Iceberg Sink、1分集計をManaged Service for Apache Flinkへ移します。既存のS3 Iceberg tableを引き継ぎ、runtime差分やMSK認証、checkpointを確認しながらwriterを切り替えます。
【第7回】EMR ServerlessとEventBridge SchedulerでIcebergメンテナンスを定期実行する	Icebergの保持期間管理とmaintenanceを行うPySpark jobをEMR Serverlessへ配置し、EventBridge Schedulerから毎日実行します。DELETE、compaction、snapshot期限切れ、orphan file削除を自動化します。
【最終回】AWSマネージドサービス移行結果を確認して検証環境を削除する	オンプレとAWSのログ件数、時刻範囲、集計、checkpointなどを比較して移行完了を判定します。既存のRawバックアップやIcebergを保護し、PoC専用resourceだけを依存関係の逆順で削除します。

AWS CLIのprofileは操作端末で使用するものであり、MSK ConnectなどのAWSサービスへaccess keyやcredentials fileを配布するものではありません。AWSサービスからS3やGlueへ接続するときは、サービスごとの実行IAM roleへ必要最小限の権限を付与します。

既存記事の整理

ログ基盤に直接関係する記事は、以下のように整理しました。

記事	対象技術	位置づけ	現行構成での扱い
hadoopをクラスタ化してみた。	Hadoop / HDFS	保存基盤	必須
HadoopクラスタにHiveクラスタを導入してみた。(pgpool版)	Hive / PostgreSQL / pgpool	Metastore / Hive HA	必須
Kafkaをクラスタ化してsyslogを収集してみた。	Kafka / Connect / Fluentd	ログ収集	必須
Hadoop収集対象にauth.log追加してみた	authlog / Kafka	authlog 追加	必須
列指向データ作成,ローテーションスクリプト作成してみた	Hive / Parquet	Raw から Curated	必須
ログ収集・解析基盤にSpark/Icebergを構築してみた	Spark / Iceberg	分析正本	必須
Grafana&Trino&Zeppelinを使用してログ解析基盤から情報を可視化する。	Trino / Grafana	可視化	必須
HadoopクラスタにZeppelinを導入してみた。	Zeppelin / Hive	ノートブック探索	必須
bigdata基盤操作ホスト作成してみた	Hadoop / Hive / Kafka	操作ホスト	必須
TerraformでProxmox VEにCloud-init対応VMを複数台作成する	Terraform / Proxmox VE / Cloud-init	検証 VM 作成	オプション
Ubuntu 24.04でローカルAPTリポジトリサーバを構築し、Hadoopクラスタの再現性を高める	Ubuntu / aptly / Apache	構築再現性	オプション
syslog/authlogをリアルタイム解析できるようにする	Flink	リアルタイム明細	オプション
Apache Flink + Iceberg で syslog/authlog の1分集計テーブルを作り、Trino/Grafana を高速化する	Flink / Iceberg	リアルタイム集計	オプション
ログ分析基盤に Elasticsearch / Kibana を追加してみる（設計編）	Elasticsearch / Kibana	検索設計	オプション
ログ分析基盤に Elasticsearch / Kibana を追加してみる（構築編）	Elasticsearch / Kibana	検索構築	オプション
ログ分析基盤に Elasticsearch / Kibana を追加してみる（実践編）	Kibana	検索実践	オプション
ログ分析基盤に Elasticsearch / Kibana を追加してみる（運用編）	Elasticsearch	検索運用	オプション
LLM連携による自然文ログ分析の構想	LLM / Trino / Iceberg	自然文分析設計	オプション
LLM連携による自然文ログ分析環境を構築してみた	Open WebUI / FastAPI / Ollama	自然文分析構築	オプション
Trino を複数台構成にしてみた。	Trino	性能拡張	オプション
自宅HDFS上のApache IcebergをAWS S3へ複製してAthenaで分析する構成を考える【設計編】	S3 / Glue / Athena	AWS分析コピー設計	オプション
自宅HDFS上のApache IcebergをAmazon S3へ複製しAthenaから分析してみる【構築編】	Spark / S3 / Glue / Athena	AWS分析コピー構築	オプション
AWS S3上のApache IcebergをAthena向けに運用する【運用編】	Iceberg / Athena / S3	AWS分析コピー運用	オプション
AWS S3上のApache IcebergをAthena経由で可視化する【発展編】	QuickSight / Amazon Quick	AWS可視化	オプション
AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】	Spark / Iceberg / S3	AWSコピーからの復旧	オプション
Hadoop distcpでHDFSのrawログをAmazon S3へバックアップしてみる	HDFS / S3 / distcp	rawログ退避	オプション
Apache Flinkを1台構成から3台クラスタへ移行してみる（JobManager 1台・TaskManager 3台）	Flink	TaskManager 分散	オプション
Apache Flink Standalone の JobManager HA を ZooKeeper + HDFS で構築してみる	Flink / ZooKeeper	JobManager HA	オプション
Hadoopクラスタにknox/ldapを導入してみた。	Knox / LDAP	Web UI 認証・SSL	オプション

他に記事掲載してる Docker 開発環境、Terraform、各クラウドの JSON API、Laravel / Rails / Phoenix の一般開発記事などは、今回のログ収集・分析基盤の通常構築ルートには入れていません。

参考: 過去に試した構成

通常の構築ルートには入れませんが、検証や比較として価値がある記事です。

• シングルノードhadoopを構築してみた。
• シングルノードhiveを構築してみた。
• ansibleでHadoop/hive/zeppelinシングルノードを構築する
• 各ホストのsyslogを収集して、bigtop基盤で可視化してみた。
• HadoopクラスタにHiveクラスタを導入してみた。(repmgr版)
• postgresクラスターを構築してみた。(pgpool)
• postgresクラスターを構築してみた。(repmgr)
• repmgrからpgpoolへデータ復元してみた。(pg_dump)
• repmgrからpgpoolへデータ復元してみた。(pg_rman)

まとめ

ログ収集・分析基盤は、最初から全部入りで作ろうとするとかなり大きく見えます。

ただし、順番を分けると構成は整理できます。

1. HDFS に保存先を作る
2. Hive で Raw / Curated を扱えるようにする
3. Kafka にログを集める
4. Kafka Connect で HDFS に残す
5. Spark / Iceberg で分析用の正本を作る
6. Trino / Grafana で見る
7. Flink、Elasticsearch、Web アプリ、LLM 連携、AWS 分析用コピー・可視化を足す
8. 負荷や可用性の要求に応じて HA 化する

まずは最小構成(1. ~ 6.)を完成させ、その後にリアルタイム処理、検索 UI、LLM 連携、AWS 分析用コピー・可視化、複数ノード化を足していくのが進めやすいです。

この記事は、各詳細記事へ進むための地図として使ってください。