はじめに
Qiita 向けに書いてきた Markdown を数え直したところ、手元の記事数は 96 本になっていました。
この記事では、これまで作ってきたもの・試してきたものを 96 記事時点で横断的に振り返ります。
単に「記事数が増えた」という話ではなく、過去記事を見直してみると、
- Docker で開発環境を再現する
- Terraform やクラウドでインフラを作る
- Web アプリや API を作る
- Hadoop / Kafka / Hive / Iceberg / Trino / Grafana でデータ基盤を組む
- PostgreSQL や Hadoop 系コンポーネントをクラスタ化する
- Elasticsearch / Kibana や LLM 連携まで広げる
- 自宅 HDFS のデータを AWS S3 / Glue / Athena へ接続する
- AWS 側 Iceberg コピーから自宅 HDFS Iceberg へ特定日データを戻す
- HDFS 上の raw ログを S3 へ退避し、必要に応じて戻せるようにする
というように、単発の検証が少しずつ別の検証の前提になっていました。
本記事では、過去記事全体を棚卸ししながら、個人技術検証としてどのような方向へ広がっていったのかを整理します。
記事群を棚卸しして見えた技術分野
まず、手元の Markdown 記事をタイトル・タグ・見出しから大まかに分類しました。
こうして並べると、特定の製品だけを深掘りしたというより、アプリケーション、インフラ、データ基盤、運用、AI 連携を行き来しながら検証してきたことが分かります。
最初は「環境を作る」記事が多かった
初期の記事群で目立つのは、Docker を使った開発環境構築です。
Elixir/Phoenix、Rails、Laravel、Angular、Vue/React、WordPress、Java Servlet、Terraform などを Docker / docker-compose で立ち上げる記事が複数あります。
この時点での主眼は、まず手元で動かせることでした。
- 必要なミドルウェアをコンテナに閉じ込める
- DB や Web サーバを docker-compose でまとめる
- 起動・停止・コンテナログインなどの操作を記事内に残す
- 別の言語やフレームワークでも同じように検証できる形にする
この流れは、その後の Web アプリ検証にもつながっています。
たとえば JSON パーサー API は、Laravel、Rails、Phoenix、AWS Lambda + API Gateway、Azure Functions と、複数の実装方式で試しています。
- PHP/LaravelでJSONパーサーAPIを作ってみる。
- Ruby on RailsでJSONパーサーAPIを作ってみる。
- Elixir/PhoenixでJSONパーサーAPIを作ってみる。
- AWS Lambda+API GatewayでJSONパーサーAPIを作ってみる。
- Azure FunctionでJSONパーサーAPIを作ってみる。
同じ題材を複数の技術で作ることで、フレームワークやクラウドサービスごとの違いを比較しやすくしていたと言えそうです。
IaC とクラウド検証へ広がった
Docker でローカル環境を作る流れの次に、Terraform やクラウドインフラの検証が増えています。
特に Terraform 系の記事では、AWS、Azure、GCP、OCI を対象に、ネットワークやサーバ、GKE などを作る記事が並んでいます。
- Terraformをdocker環境で立ち上げてみる。
- Terraformにて、実践的なAWSサイトインフラを作成する。
- Terraformにて、実践的なAzureサイトインフラを作成する。
- terraformでGKEを立ち上げてみた。
- Terraformを使用してECS環境構築し、Laravelサイトを立ち上げてみた。
ここでは、アプリケーションを作るだけでなく、そのアプリケーションを動かすインフラもコードで作る方向へ関心が広がっています。
また、Kubernetes 関連では Raspberry Pi での K8S クラスタ、GKE、Laravel on Kubernetes、GitLab を含む自宅 CI/CD 環境の記事があり、ローカル・クラウド・自宅ラボの境界をまたいで検証しています。
データ基盤は単体構築からクラスタ構成へ進んだ
Hadoop 系の記事を見ると、最初は単体コンポーネントの構築から始まり、徐々に複数台構成や周辺機能へ広がっています。
- シングルノードhadoopを構築してみた。
- シングルノードhiveを構築してみた。
- ansibleでHadoop/hive/zeppelinシングルノードを構築する
- hadoopをクラスタ化してみた。
- HadoopクラスタにZeppelinを導入してみた。
- Hadoopクラスタにknox/ldapを導入してみた。
流れとしては、まず Hadoop / Hive を単体で動かし、その後にクラスタ化、Zeppelin 追加、Knox / LDAP 追加、操作ホスト、HDFS 容量監視、ローカル APT/YUM リポジトリへと進んでいます。
このあたりから、記事の性質が「とりあえず起動する」から「あとで使い続けるためにどう構成するか」へ変わってきています。
特にローカルリポジトリ系の記事は、直接ログ分析をするものではありませんが、Hadoop クラスタを再現しやすくするための土台として書かれています。
- Ubuntu 24.04でローカルAPTリポジトリサーバを構築し、Hadoopクラスタの再現性を高める
- Ubuntu 24.04 の公式リポジトリをローカルAPT/YUMサーバへ追加する
- AlmaLinux 9 の公式リポジトリをローカルAPT/YUMサーバへ追加する
代表テーマとして育ったログ収集・分析基盤
過去記事全体の中で、最も大きく育ったテーマの一つが syslog / authlog のログ収集・分析基盤です。
ただし、これは単独のシステムというより、Hadoop、Kafka、Hive、Spark、Iceberg、Flink、Trino、Grafana、Elasticsearch、Kibana、Elixir、LLM 連携といった検証結果が合流したものです。
過去記事から確認できる全体像は、おおむね次のような構成です。
この構成に関する記事は、次のように段階化されています。
このテーマで特徴的なのは、毎回新しい部品を足して終わりではなく、以前の記事で作った構成を後の記事が前提にしている点です。
Kafka に集めたログを HDFS へ保存し、Hive で整形し、Spark / Iceberg へ渡し、Trino / Grafana で可視化し、さらに Flink でリアルタイム化し、Elasticsearch / Kibana や Web アプリ、LLM 連携へ広げています。
96記事時点では、ここに AWS 側の分析コピー、AWS 側 Iceberg コピーからの復旧、raw ログ退避も加わりました。
自宅 HDFS 上の Iceberg は Source of Truth として残しつつ、AWS 側には S3 + Glue Data Catalog + Athena の分析用コピーを作ります。
さらに、Iceberg テーブルとしての複製とは別に、HDFS 上の raw ログを hadoop distcp で S3 へ退避する手順も整理しました。
自宅 HDFS + Iceberg
↓
Spark + Iceberg
↓
AWS S3 + Glue Data Catalog + Athena
↓
QuickSight / Amazon Quick
AWS S3 + Glue Data Catalog + Athena
↓
Spark + Iceberg
↓
自宅 HDFS + Iceberg
Kafka
↓
HDFS raw
↓
hadoop distcp
↓
Amazon S3
1つ目は Athena から分析しやすくするためのコピーで、2つ目は AWS 側 Iceberg コピーから自宅側の特定日データを戻すための復旧手順です。
3つ目は raw ログを別の場所にも置いておくための軽い退避です。
AWS 側 Iceberg コピーは正本ではありませんが、自宅側の特定日データを壊した場合の復旧元としても使えるようになりました。
raw ログを S3 に保管しておけば、必要に応じて HDFS の検証用パスへ戻し、既存処理を再実行して Hive curated や Iceberg を再生成する用途にも使えます。
その過程で、時刻設計、テーブル運用、systemd 自動起動、savepoint / checkpoint、HDFS 再取り込み、MirrorMaker2、HDFS 容量監視など、運用寄りの記事も増えています。
- Kafka / Spark / Flink / Iceberg で時刻(ts)の扱いを統一する設計
- ログ収集・解析システムのテーブル設計/運用をまとめてみた。
- Flink SQL ジョブを systemd で自動起動させた
- Flink SQL ジョブをsavepoint&checkpointを用いた運用へ安全に載せ替える
- HDFS同士のデータコピーをやってみた。
- Hadoop distcpでHDFSのrawログをAmazon S3へバックアップしてみる
- AWS S3上のApache Icebergコピーから自宅HDFS Icebergへリストアする【復旧編】
- Kafka MirrorMaker2によるHadoopクラスタ間レプリケーションやってみた。
HA・クラスタリングの記事が増えた
ログ基盤と並行して、PostgreSQL や Hadoop 系コンポーネントの高可用性・クラスタリングも大きなテーマになっています。
PostgreSQL では repmgr、pgpool、keepalived、pg_dump、pg_rman を扱っています。
- postgresクラスターを構築してみた。(repmgr)
- postgresクラスターを構築してみた。(pgpool)
- repmgrからpgpoolへデータ復元してみた。(pg_dump)
- repmgrからpgpoolへデータ復元してみた。(pg_rman)
Hadoop / Hive / Kafka / Trino / Flink についても、単体構成だけでなく複数ノード構成の記事があります。
- HadoopクラスタにHiveクラスタを導入してみた。(repmgr版)
- HadoopクラスタにHiveクラスタを導入してみた。(pgpool版)
- Trino を複数台構成にしてみた。
- Apache Flinkを1台構成から3台クラスタへ移行してみる（JobManager 1台・TaskManager 3台）
- Apache Flink Standalone の JobManager HA を ZooKeeper + HDFS で構築してみる
ここでも、単なる構築手順だけではなく、停止時の挙動、再起動順序、バックアップ、リストア、戻し方といった運用観点が記事に入るようになっています。
AI / LLM は単体利用から既存基盤との連携へ
AI / LLM 系の記事も、最初は単体で ChatGPT API や Stable Diffusion API を使う検証として始まっています。
- 1時間という爆速でchatgpt応答pythonプログラム作ってみた。
- ChatGPTとやり取りするWebアプリ作ってみた。
- StableDiffusion APIから画像生成してみる。
- 画像生成AIから画像作成するWebサイト作ってみた。
- LLM介してAWSからサービス最新情報を引き出すアプリ作ってみた。
その後、既存のログ分析基盤とつなげる形で、Open WebUI / FastAPI / Ollama / Trino / Iceberg を組み合わせた自然文ログ分析の検証に進んでいます。
ここは、AI を単体で試す段階から、既に作ったデータ基盤の利用インターフェースとして使う段階へ進んだ部分です。
個人利用できるサイトの開発
Laravelによるつぶやきサイトも作成し、実際に利用できるアプリも開発しました。
記事を書きながら変わったこと
過去記事を横断して見直すと、変化は大きく 5 つあります。
1. 手元で動かすだけでなく、再現性を意識するようになった
Docker、docker-compose、Terraform、Ansible、ローカルリポジトリなどの記事が増えていることから、検証環境を作るだけでなく、再現しやすくする方向へ進んでいます。
特に Hadoop 系の検証では、OS パッケージ、ホスト構成、ユーザー、systemd、設定ファイル配置などを細かく残す記事が増えています。
2. 単体検証から、複数コンポーネントの組み合わせへ進んだ
最初は「Laravel を Docker で動かす」「Terraform で AWS リソースを作る」「Hadoop をシングルノードで動かす」といった単体検証が中心でした。
その後は、Kafka、HDFS、Hive、Spark、Iceberg、Trino、Grafana、Flink、Elasticsearch、LLM のように、複数の技術を接続する記事が増えています。
単体で理解した技術を、後続の記事で部品として使い直しているのが特徴です。
3. 「収集」から「検索・可視化・運用」へ広がった
ログ基盤では、最初の関心は syslog / authlog を集めて保存することでした。
そこから、Hive で整形し、Iceberg で管理し、Trino / Grafana で可視化し、Elasticsearch / Kibana で検索し、Flink でリアルタイム化し、LLM で自然文分析するところまで広がっています。
データを集めるだけではなく、後からどう使うか、障害時にどう戻すか、テーブルをどう保守するかに関心が移っています。
4. 記事自体も管理対象になった
qiita記事をGithubでコンテンツ管理してみた。 やこれまで提示した記事のインデックスがあるように、記事そのものも GitHub 管理やインデックス化の対象になっています。
合わせて、これらの記事をQiita記事をElasticsearchへ取り込み、検索Webアプリで参照できるようにするのように、自前Webアプリで参照できるようにもしました。
検証した内容を記事として残し、その記事群をまた整理して次の検証へつなげる、という循環ができてきています。
5. 自宅ラボとクラウドを使い分けるようになった
最初は手元や自宅ラボの中で完結する検証が中心でした。
96記事時点では、自宅 HDFS / Iceberg をメイン環境として残しながら、AWS S3 / Glue Data Catalog / Athena 側に分析用コピーを作る構成も加わっています。
また、AWS 側 Iceberg コピーから自宅 HDFS Iceberg へ対象日データを戻す復旧手順や、Iceberg テーブルとしての分析コピーとは別に HDFS 上の raw ログを S3 へ退避し、必要に応じて HDFS へ戻せるようにする記事も増えました。
自宅側で継続運用し、クラウド側は分析・可視化・退避先として使う、という使い分けが見えてきました。
今ならどう考えるか
96 記事時点で振り返ると、個人検証でも、次の順番を意識するとシステムとして育てやすいと感じます。
- まず単体で動かす
- Docker や IaC で再現性を持たせる
- 複数台構成や外部コンポーネントと接続する
- データの保存形式・時刻・パーティションを整理する
- 検索・可視化・Web UI など利用側を作る
- systemd、バックアップ、再取り込み、監視など運用面を足す
- 必要に応じてクラウド側の分析環境や退避先へ接続する
- 最後にまとめ記事やリファレンス記事で全体像を整理する
最初から完成形を作ろうとすると重くなりますが、記事単位で小さく検証していくと、後から組み合わせられる部品が増えていきます。
今回見直してみて、ログ分析基盤が大きくなったのも、最初に Hadoop、Hive、Kafka、Docker、Web アプリ、Terraform などを個別に試していたからだと分かりました。
96記事時点で増えた観点
96記事時点で大きく増えたのは、自宅ラボ内で完結していたログ分析基盤を、AWS 側の分析環境、復旧元、退避先へ接続する観点です。
自宅側では HDFS / Iceberg / Trino を継続利用し、AWS 側では S3 / Glue Data Catalog / Athena を分析用コピーとして使います。
AWS へ全面移行するのではなく、自宅側をメイン環境として残したまま、必要なときにクラウド側のサーバーレス分析環境も使えるようにする位置づけです。
さらに、AWS 側 Iceberg コピーから自宅 HDFS Iceberg へ対象日単位で戻す復旧手順も追加しました。
これは双方向同期ではなく、自宅側を Source of Truth とする前提を維持したまま、同期済みデータを復旧元として使うための手順です。
対象テーブルは日次または手動バッチでだけ更新する運用にしているため、通常同期、手動再実行、復旧処理の時間帯を分ければ競合リスクを低くできます。
そのため、単に S3 へファイルを置くだけではなく、Iceberg metadata、snapshot、partition pruning、Athena のスキャン量、S3 保存容量、S3 request、Glue Data Catalog の扱いも意識するようになりました。
一方で、raw ログ退避の記事では、そこまで大きな分析コピー構成にはせず、HDFS 上の syslog / authlog raw ログを hadoop distcp で Amazon S3 へコピーし、必要に応じて HDFS へ戻すところに絞っています。
96記事時点では「作る」「つなぐ」「可視化する」に加えて、元データや分析コピーをどう残して戻せるようにしておくか、という少し地味だけれど大事な運用寄りの検証も増えてきました。
おわりに
96 記事を振り返ると、作ってきたものは大きく 1 つの分野に閉じていたわけではありませんでした。
Docker 開発環境、Web アプリ、クラウド / IaC、Kubernetes、Hadoop 系データ基盤、ログ分析、HA、AI / LLM と、別々に見える検証が少しずつつながっていました。
特にログ収集・分析基盤は大きなテーマに育ちましたが、それだけではなく、周辺の開発環境、インフラ構築、DB クラスタ、Web UI、AI 連携の検証があったことで、全体として一つの自宅ラボ的な技術検証になってきたと感じます。
次に記事を書くときも、単発の検証で終わらせず、過去に作ったものとどう接続できるかを意識して進めていきたいと思います。