冗長構成なStackStormの運用の注意点
さてStackStormノードが冗長化し、さらにステートレスになるとスケールできて嬉しいのですが、何も考えずにStackStormノードを増やしてゆくと、運用上困った事態が起こります。
どういうことが起こるかを知るために、前節で構築した冗長環境で、StackStormの機能拡張で作成したmypack.DirectorySensorにファイル作成のイベントを検知させます。
st2-nodeもしくはst2-secondaryのどちらかで、以下の操作を行ってください。
$ sudo touch /opt/stackstorm/packs/hoge
すると、それぞれのノードでアクションmypack.output_contextが実行され、両ノードの/tmp/outputに以下のような結果が出力されることが確認できると思います（もしかすると、どちらか一方のノードで2回出力されるかもしれません。その理由は本編の最後で説明します）。
[1480385994.27] (created) /opt/stackstorm/packs/hoge [1480386001.36] (created) /opt/stackstorm/packs/mypack/actions/output_context.pyc
これは、ファイルhogeを作成したイベントをすべてのノードで検知し、それぞれのノードでトリガmypack.changed_fileが引かれ、ルールmypack.mypack_testに従ってアクションを実行したために、このようになりました。以下はこの状況を表した図になります。
ここでの問題は、イベントの発生源が1つにも関わらずアクションが2回実行されたことです。
例ではログにイベントの結果を出力するだけなので大した影響はありませんが、イベントに対してアラートを発報したり、Public Cloudのインスタンスを起動したりするような仕組みの場合には深刻です。またノードが増えるごとにその度合いは増していきます。
StackStormはこの問題を回避する手段としてPartitioning Sensorsという仕組みを提供しています。各ノードでPartitioning Sensorsを設定することで、ノードごとに稼働するセンサを管理・選択できるようになります。これによって、先ほどの状況を以下のようにすることができます。
このようにノードごとにセンサを分離させると、複数のStackStormノードがある環境下で発生したイベントに対して、センサ、トリガ、アクションを一意に紐付けることができるようになります。
Partitioning Sensorsの設定
ここでPartitioning Sensorsを設定し、先の図で示したようにst2-nodeでAWSのイベントを監視するセンサを動かし、st2-secondaryでセンサmypack.DirectorySensorを動かすように設定します。
まず各ノードのStackStorm設定ファイル/etc/st2/st2.confを以下のとおり編集します。
--- etc/st2/st2.conf.orig 2016-12-07 11:58:32.021642436 +0000 +++ /etc/st2/st2.conf 2016-12-07 11:59:51.177201387 +0000 @@ -14,6 +14,8 @@ [sensorcontainer] logging = /etc/st2/logging.sensorcontainer.conf +sensor_node_name = st2-node +partition_provider = name:kvstore [rulesengine] logging = /etc/st2/logging.rulesengine.conf
--- etc/st2/st2.conf.orig 2016-12-07 11:58:46.379088514 +0000 +++ /etc/st2/st2.conf 2016-12-07 11:59:22.409093433 +0000 @@ -14,6 +14,8 @@ [sensorcontainer] logging = /etc/st2/logging.sensorcontainer.conf +sensor_node_name = st2-secondary +partition_provider = name:kvstore [rulesengine] logging = /etc/st2/logging.rulesengine.conf
Partitioning Sensorsの設定は[sensorcontainer]セクション以下で行います。
sensor_node_nameはStackStormノードの識別子で、ノードを一意に特定できれば任意の文字列を指定できます。ここでは、各ノードのホスト名を指定します。
parittion_providerでは、当該ノードで動かすセンサを設定する方法を設定します。ここでは、MongoDBで管理されるデータストアに、どのノードでどのセンサを動作させるかの設定を記述します。この他にも、ファイルで管理する方法などもあります。
設定ファイルでPartitioning Sensorsの設定方法を決めたところで、具体的にどのノードでどのセンサを動作させるかの設定を行います。先に示した図のとおり、st2-nodeでaws packのセンサ（aws.ServiceNotificationsSensorとaws.AWSSQSSensor）を起動させ、st2-secondaryでmypackのセンサ（mypack.DirectorySensor）を起動させるよう、以下のコマンドでデータストアに設定します。
$ st2 key set st2-node.sensor_partition "aws.ServiceNotificationsSensor, aws.AWSSQSSensor" $ st2 key set st2-secondary.sensor_partition "mypack.DirectorySensor"
データストアに設定した内容は、以下のコマンドで確認できます。なお、データストアはどちらもst2-nodeのMongoDBを参照しているため、どちらのノードで実行しても同じ結果が得られます。
最後に、両ノードのStackStormを再起動をさせれば設定は完了です。
$ sudo st2ctl restart
動作確認
それでは、再度センサmypack.DirectorySensorにイベントを通知させます。どちらかのノードで、以下のように先ほど作成したファイルを削除してみてください。
$ sudo rm /opt/stackstorm/packs/hoge
すると、st2-nodeあるいはst2-secondaryのどちらかのファイル/tmp/outputで、以下のような結果が出力されるはずです。
[1480385994.27] (deleted) /opt/stackstorm/packs/hoge
さらにここで注意が必要なのは、センサがファイル/opt/stackstorm/packs/hogeの削除を検知してトリガmypack.changed_fileを引く処理を行うノードはPartitioning Sensorsで設定したst2-secondaryですが、アクションを実行するノードは不定（st2-nodeかst2-secondaryか分からない）ということです。
その理由は、ワーカプロセス（st2actionrunner）がすべてのノードで動作しているためです。StackStormでは以下の図のように、センサプロセスとワーカプロセスが別々に動作しており、それらがMQを介して接続されています。
StackStormの機能拡張で解説した通り、センサはSensorServiceのdispatchメソッドを実行してトリガを引きます。こうして送られた通知はst2rulesengineというプロセスに送られ、トリガに紐付けられたルールがないかを確認します。そして当該トリガに紐付くルールを見つけると、アクションの実行命令（ActionExecution）をワーカプロセスst2actionrunnerにMQを介して送ります。アクション実行命令を受け取ったワーカは、runner_typeに従った形式でアクションを実行します。
このため、アクションが実行されるノードは一意に決まりませんが、逆にこの仕組みによって、アクションを複数のワーカノードで分散できると共に、動的にスケールできるようになります。
おわりに
いかがでしたでしょうか。基本編と併せて、StackStormの使い方から内部の仕組み、運用のポイントまでかなり詳しく解説できたと思います。ここまでの内容を駆使することで、機能拡張から柔軟かつ強固なStackStorm環境の構築、運用が行えるようになると思います。
最後にStackStormのユーザコミュニティを紹介して終わりたいと思います。
StackStormはMLはもちろん、Slackによる開発者を含めた多数のユーザとリアルタイムに情報交換できるチャネルを用意しています。本稿執筆時点では1000人以上が登録しており、常時50～60人くらいが参加しています。
StackStormチームは少ないメンバーにも関わらず、ユーザコミュニティの育成に割と力を入れており、Slackへのコメントに対してプロダクトマネージャーや開発者が丁寧に返答してくれます。活動地域も米国西海岸だけでなく東欧にもメンバーがいるので、比較的どの時間帯でも返答が期待できます。
