なぜWordpressでデモが便利なのか？を考えてみる。
しかし、ぶっちゃけWordpressでなくても良くない？という気がしないでもない。多分、Wordpressでデモをしている人は大きく分けて、インフラ屋さんか、良さげだから使っているの２通りではないかと感じる。
さて、Wordpressの構造を考えてみると。。。
以下のようにWebとDBが分かれている。
言い換えると。。。
そうWordpressを使うユースケースって、APサーバとDBサーバのデモ、つまり複数サーバのデモで便利じゃんということになる。しかし、インフラ屋さんは、ここまでみているかもしれない。
ロードバランサーが入っている形式。これを3Tier構成という。（業界違うと３Tierの意味が全く違う。その定義もしないで、ドヤ顔でいきなり「3Tierでぇ」と言われると、実はめっちゃくちゃイラッときていたりする。例えるなら「C言語で変数の宣言もしないでいきなり変数に値を入れて、しバグを量産するのか。」とい感じ。まぁそういう人は、実際仕事でも潜在的なバグを結構量産する。。。）
ここまで、考えられると。。。やはりオートスケールとなる。APサーバ、DBサーバの複数サーバのデモだけと比べるとかなり実用的になる。前者が製品の機能や仕様をドキュメントなどでなぞるだけの職業エンジニアのデモだとすると、現実に使おうとしている現場のエンジニアのデモとも言える。
以前の仕事で、AWSでオートスケールのデモをやっていたのだが、まさしくこの形式。ただオートスケールって、単にサーバを増やしたり減らしているわけではなく、メトリックに応じて増やしたり減らしたりしなければならないので、実は、クラウドインフラ単体でやるのは難しい。（以前AWSでやっていたときは、メトリックをAWSで提供していなかったので、自分がいた会社の製品が全部やっていた。）
閑話休題
上記のデモをKubernetesでやってみたいと思う。
利用したwordpressは、以下で紹介されているwordpress.
https://kubernetes.io/ja/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/
wordpressのバージョンが古すぎるので、5.6.2にして利用している。5.7以降だとこのパラメータじゃ動かない。
Horizon pod Autoscalerの使い方はここに書いてある。
https://kubernetes.io/ja/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/
以上。とすると怒られるので、もう少し詳しいデモ手順を書いてみた。
まず、wordpressを展開する前に以下のようにリソースのリミットを書いてみた。（正解かどうかは調整してみてほしい）
- image: wordpress:5.6.2-apache
name: wordpress
resources:
requests:
memory: "128Mi"
cpu: "10m"
limits:
memory: "256Mi"
cpu: "100m"
要は、音を上げやすくしているだけ。要らないかもしれないが。
Horizon Pod Autoscalerは、以下のコマンドで簡単に定義ができる。
kubectl autoscale deployment wordpress --cpu-percent=50 --min=1 --max=10
状態の確認は以下のコマンドで行う。
kubectl top pod ; kubectl get hpa,pod
出力例（少しだけ待って実行しないとhpaの値が取れない。）
負荷はかかってなくてレプリカも１つだけ。なのでPodも１つ。50%がスレッショルドで10%しかつかっていない。
ちなみにkubectl topで表示させると、podのCPUとメモリの消費が一覧で出せる。環境によってはmetric serverを事前にデプロイしておく必要がある。（職業エンジニア様だと、ドキュメントに必要と書いていないとデプロイをしたがらないので注意。どうやらマニュアルを読むだけでロケットで宇宙へ行って、間違えなく帰ってこれると信じているらしい。）
負荷をかけるコマンドは、apache benchが便利。負荷をかけるサーバで以下を実行するとインストールされる。ちなみに、ノードサーバとかにapache benchをインストールとかしないように。（いないと思うが。）また、ネットワーク経路とかエンドポイントとかで問題のない環境でやること。
sudo apt install apache2-utils
ベンチは以下のコマンドでかけられる。
ab -n 1000 -c 1000 -r http://＜kubectl get svcで出てくるExternal IP＞/
値の調整をしてかけるべき。いきなりフルバーストだったら大きくかければいい。大きくかけるとベンチマークを動かすホストの負荷があがるのも言うまでもない。
状態の確認をまた実行
kubectl top pod ; kubectl get hpa,pod
バンバンpodが作成されているのがわかる。podのAgeでいつできたかがわかる。
負荷が終わってもなかなか減らないので、急いで減らしたい場合は、パッチで最大値を落としてしまう。少しすると不要なPodはTerminateされていく。
kubectl patch hpa wordpress -p '{"spec":{"maxReplicas": 1}}'
で、もとに戻しても、負荷がかかっていないので、増えることはないはず。
Horizon Pod Autoscalerを停止させるには、削除をする。
kubectl delete hpa wordpress
これで終わり。
こういったデモは、「単に設定して動きました。」というレベルや、「シナリオ通りにやりました。」というレベルだと、側から見ると「単に設定作業しているやつ」となってしまう。これが職業エンジニアたる所以。前提となる定義と必要な背景を入れないといけない。（必要性を理解するにはかなり時間がかかるかもしれないが）
と言いつつ、AWSでデモをしていたときは、いきなり「オートスケールがクラウドできるって言うけど、見たことある人、やったことある人居ますか？」と聞いて誰も手をあげないので、いきなりデモをして、後で↑を説明していた。当時やってたデモはこれだけで近隣のブースからクレームが出まくるくらい大入だった。。。
多分、Horizon Pod Autoscalerでここにくる人には不要な話が多かったかもしれないが。以上。