プロセスを全てSupervisordで集約させてカオスエンジニアリングの準備をする
4 min read
こんにちは、無能です。
皆さんいかがお過ごしでしょうか。
私は昨日合計6時間、途中友達と合流しつつサイクリングに出てました。
ジャズ・フェスだったので、音楽聴きながら街を散策しましたが年配の方の服装は面白いものが多く刺激があります。
街に出て、直接見る外に出ている人たちのリアルさはストリートスナップ等よりも真実です。
そして、友達の家で友達がボロネーゼパスタを作ってくれるということだったので、業務スーパーに行って「PRAI ネストパスタ」とかいう極太麺で作ってみようということで一緒に作ってたらめちゃくちゃうまい。
そんなこんなで古着屋行ったりプロジェクトミライに行った感想と最適輸送と自然言語処理のこと教えてもらったりと深夜2時位まで喋ってそのまま帰りの数十キロをピストバイクで走り去った一日です。
はじめに
最近、自宅インフラ環境を整え直している理由に前から気になっていたカオスエンジニアリングのテスト環境として使いたいのでやっています。
前にNetflixが最初に公開したChaosMonkeyなるものがあり、それは結局そのフォークされた猿たちはもう絶滅危惧種になっているようです。
なんだお前ら、仮想通貨か？というレベルの速度で消え去っていますがそんな中リアルタイムで更新されているChaosBladeというOSSがあります。これを実行したいのです。
これは、中国のAlibaba Cloudが導入しているものでどこで実際に導入しているかは、Issuesにまとめられているものがあります。
Who is using ChaosBlade
日本の情報がほとんど無いですが、ドキュメントもそれなりにしっかり作られていることとリアルタイムでコミットされているので使えるでしょう。
詳細は実際に手をつけ始めてから行おうと思います。
Supervisord移行前のデーモン起動
まさか、こんな長く続けているとは思わなかったものが多数あり。
実際はサーバーのrc.local内に記述しスタートアップで立ち上げるスクリプトをラッパーした形で起動していました。
具体的には、
rc.local
$ sudo cat /etc/rc.local
[sudo] haturatu のパスワード:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
#echo never > /sys/kernel/mm/transparent_hugepage/enabled
[ -d /etc/boot.d ] && run-parts /etc/boot.d
/root/serverboot.sh &
こんな感じでrootのホームディレクトリに雑に作ったserverboot.shにそれぞれのアプリケーションを立ち上げるようにして起動させてました。
ぶっちゃけただスクリプト起動させているだけなので、果たしてこれをラッパーと言って正解かどうかは置いておいて。
しかし、お気づきでしょうがこれだとプロセスが落ちたりログファイルも個別に出力されるものではありません。
そのため、全てSupervisordで管理しました。
その後
これでもし、なにかの拍子でプロセスが落ちても勝手にSupervisorが立ち上げてくれるのとそれぞれに設定したログとして出力されます。
合計8プロセス分になりました。
作業時間1時間もかからなかったのでさっさとやればよかった、となるんですがこうなるのはしょうがない。だってにんげんだもの。
他にやらねばいけないこと
HA Proxyでロードバランサをするとか、そのためにはもう一個サーバーを用意しないといけないんだがその二号機を家にもう一個とかあまりに意味が無さすぎるのでなんとか格安VPSを探す必要がある。
なぜかというと結局自宅環境のリスクは停電だとか、そういう環境的リスクが高いので全く別の場所にあるサーバーを２号機にしたほうが良い気がする。
なぜよりそう思うかというと、これは自宅サーバー環境下だけの話だけではなく確か2021年頃にAWSのUSリージョンの大規模障害があった記憶がある。その間Binanceだとかの取引所が落ちていたことを追っていたら原因がAWSだった。
同じリージョンで冗長構成をとってら結局意味がない。
電力障害とか、米国のGoogle DCをYoutubeとか確か中もGoogle Mapだかで見学できた記憶あるけど見れば絶対にあり得なさそうなことではあるんだけども絶対に無いということは無い。
HA ProxyではなくてNginxでロードバランサすれば良いのでは？と言われるかもしれないが過去にこれを見ていた記憶があった。
負荷分散に nginx を絶対に使用してはいけない理由
追加で、ウェブサーバとロードバランサが同じソフトウェアで起動させているとややこしくなるのでHA Proxyを使ったほうが明示的で分かりやすいと思う。
でも、現状で本当に冗長構成をする意味があるか？と言われれば完全にNOで、ChaosMonkeyみたいなソフトウェアでクラウド上の無駄なリソースを使うことで迷惑が掛かりそうだしDNS単位でやるとなるとそれもまた。
もう少し考えてみてから、ChaosBladeは実行しようと思います。
まだそのカオスエンジニアリング中のサーバー内の情報をGetする準備もできていないので、ある意味続編的に続きます。
それでは。またよろしくお願いします。