こんにちは。
システムチーム プログラマー / マネージャーのＡです。
前回に続き、サーバー増強に関する話です。
今回は改修の中身について話をします。
たまったツケを返す仕事
品の無い表現になってしまいますが
今回の改修は、たまったツケを返すような内容でした。
まず前提として、
サーバーやミドルウェアの状態は、
ユーザーにとって、基本的に関係の無いものです。
どのサーバーで動いていようが
どの言語のプログラムで動いていようが、
ユーザーからすればどうでもいい。望み通り動けばいい。
デキテルで言えば
お客さまへの利益の還元が重要であって、
他の概念や機能は、その数値を増やすための手段でしかない。
商用システムは、プログラマーの自己満足を体現するものではない。
だから、
アクセス数やCV数と、関係が薄い部分は後回しになる。
自分はマネージャー兼エンジニアですが、
この発想で自然だし、この発想であるべきだと思います。
システムへの愛があるのでバランスは難しい。
でも、基本的にはこの発想であるべきです。
ただし
後回しにすることによる、
システムへの負債の蓄積が無視できなくなってきた。
負債を返す必要が出てきた。
情勢的には
担当者は自分しかいなかったですし、
責任者の移行も控えていましたから、
システムへの負債の完済を決心しました。
その完済の様子を、５段階に分けてお話しします。
①ロードアベレージ値の削減
2021年6月頃、
デキテルに繋がらなくなる現象が発生しました。
原因は
処理待ちが大量に発生していたこと。
基準として「ロードアベレージ」という値がありますが、
推奨値は8 ~ 10未満に対して、
その頃のロードアベレージが「10 – 12」。
凶悪な量のプロセスが、処理を待っていました。
当時、何とか対応をして「2 – 3」まで下げました。
ちなみに今の数値は「0.5 – 0.8」。更に下がっています。
② 公開サーバーの追加
マーケチームの尽力があり、
幸いなことに、契約者さまの数は年々増えています。
同時に、公開画面を管理するサーバーの負荷も年々増えています。
公開画面そのものの負荷を減らすことは難しく、
サーバーを増やす、物量的な対応を取るしかなかった。
サーバーを分けるという概念を
デキテルにインストールする改修でした。
ちなみに、
契約者さまの数がいくら増えたとしても、
直ぐにサーバーを追加できる仕組みにしてあります。
公開画面に関しては永遠に大丈夫です。
③ ミドルウェアの最新化
デキテルに関連するミドルウェアを全て最新化しました。
今のデキテルは、最新のPHP8に対応しています。
本改修中で、最難関の開発でした。
とにかく、時間内に収めることが大変だった。
「PHP8とPHP5系の違いは？」
とよく聞かれますが
「なんとなく書いたコード」が動くか否か だと思います。
例えばPHP8では
カウント出来ない変数の count() => Fatal Error !
非static 関数の static 呼び出し => Fatal Error!
未定義の定数の呼び出し => Fatal Error!
string型を使った四則演算 => Fatal Error!
…
という感じ。厳しいですね。
最速で、最も安全なリライト方法を四六時中考えていました。
「何とか工夫出来ないか・・・」と。
もし、
思考停止して、愚直に、全て対応した場合、
プロジェクトは確実に破綻していました。
見積りに収まるわけがない。遅延確定だったと思います。
④ ボトルネックの解消
デキテルには、速度面での小さなボトルネックが多くありましたが、
それらの最適化も行いました。
例えば、
編集画面TOPに関してはSQL発行を数百回削減しています。
1つ1つは微小なコードだったので、根気の必要な作業でした。
あとは時間との兼ね合い。
・ボトルネック解消に必要な時間
・解消される事で、ユーザーに与えられる時間
の勘定は、常に行っていました。
⑤ 編集機能サーバー移転
間違いなく、過去最大の改修です。
システムを全部持って引っ越したんだから、当然。
悩ましかったのは、その引っ越し先（サーバー）。
CPU, メモリ, リージョン, OS, 利用ミドルウェア, 解放ポート…
選択肢は無数にあるのに、誰も正解を定義してくれない。
「何がデキテルにとって正解なんだろう？」
ずっと、頭の中から離れない、難しい問いでした。
ダウンタイム０で改修しきった
今回の改修を通して、
何よりも価値があるのは「見積り通り完了した」こと
次点で、「ダウンタイム０で改修しきった」ことだと思います。
※
ダウンタイムとは「システムを止める時間」のこと。
サイトにアクセスしたとき、
「メンテナンス中です」的な文言を見たことがあると思います。その時間です。
先述の通り
今回の改修は
ユーザーにとっては効果の分かり辛い改修ですし、
コスト・リスク・リターン面で、改修に関して負い目があった。
だから、ダウンタイムを出したくなかった。
物凄くテクニカルで、
話すことは沢山あるんですが、
技術的な要素が多く入ってるので、
次の記事で内容を詳しく書きます。
次→https://syde.jp/w/archives/11550.html
