夢とガラクタの集積場

落ちこぼれ三流エンジニアである管理人の夢想＝『夢』と、潰えた夢＝『ガラクタ』の集積場です。

Stormクラスタのコンテナ化に向けて通信周りを整理してみる

Storm

こんにちは。

最近Dockerをはじめとしたコンテナを用いたアプリケーションの運用が広まっている・・・
ということで、Stormクラスタをコンテナのオーケストレーションツールで
構築できないか、と考えています。

出来るようになれば、よりStormがお手軽に使えるようになりますし、
CPUを多く使い、メモリはそれなり、ディスクアクセスはあまりないということで、
Storm自体がコンテナとの相性が良さそう、というのもあります。

そんなわけで、まずはStormが通信に使用しているポートと、
どのホストと通信が行われるかをまとめ、基情報にしようと思います。

1.Stormの構成プロセス

Stormの構成プロセスはZooKeeper含めて下記の7個になります。
ですが、現状Workerプロセスは「Supervisorプロセスが自分がいるマシン内で起動する」
という動作となるため、必ずSupervisorプロセスと同じコンテナ上で起動する形になります。

  • Nimbus
  • UI
  • Supervisor
  • DRPCServer
  • LogViewer
  • Worker（Supervisorと同コンテナ）
  • ZooKeeper

現状存在しているStormのDockerfileを見てみましたが、
Workerを起動する際に別のコンテナを起動してそこに配置する・・ということは行っていないようです。

2.Stormの各プロセスが使用するポート一覧

各プロセスがデフォルトで使用しているポート番号は下記です。
コンテナ上で動作させるという時点でポート番号の重複は考えなくていいため、
デフォルト値をそのまま使用することにします。
また、「外部からアクセスされるか？」「Stormクラスタ内部のみのアクセスか？」で
コンテナ群からどう設定するかが変わってくるでしょうから、それも併せて記述します。

  • Nimbus
    • 6627(TopologySubmit等の通信待ち受けポート。外部からアクセスあり)
  • UI
    • 8080(画面表示用ポート。外部からアクセスあり）
  • DRPCServer
    • 3772(DRPCリクエスト受付用ポート。外部からアクセスあり)
    • 3773(DRPCリクエストをWorkerプロセスが受信するためのポート)
    • 3774(DRPCに対してHTTPでアクセスするためのポート。外部からアクセスあり)
  • Supervisor
    • (公開ポートなし）
  • LogViwer
    • 8000(ログ閲覧用ポート。外部からアクセスあり)
  • Worker
    • 6700〜6703（Worker同士の通信用ポート）
  • Zookeeper
    • 2181(クライアントアクセス用ポート)
    • 2888(トランザクション情報送受信用ポート)
    • 3888(リーダー選出通信用ポート)

また、その他の制約として下記があります。

  • Supervisorプロセスが動作するマシンにおいてSupervisorのホスト名からIPアドレスを引ける必要がある。

これはSupervisorがZooKeeperに自分のホスト情報を登録する際に
IPアドレスではなくローカルで取得したホスト名を用いているからのようです。

その上で、この中でLogViewerについては使用しない方針とします。
何故なら、LogViewer自体がローカルのログをHTTPアクセスで確認するためものであり、
fluentdやkafkaでログ自体を収集してしまえば使用する必要はないプロセスだからです。

すると、Stormクラスタをコンテナで表現する場合の
ポート利用構成は下記の図のようになります。

NimbusとUI、DRPCの一部ポートだけ外部公開すればStormクラスタの機能は一通り満たせそうですね。

では、次回以降実際にStormクラスタをコンテナで運用できないか試してみます。

とはいえ、コンテナ同士を接続するのを手動でやるのは困難ですので、
k8sを使うことを前提としますかねぇ・・・