プログラムを組んでいると、最終的には性能問題をいかに解決するのかという点に悩むようになります。処理時間を最適化しなければならないということです。

プログラムの最適化は3種類あります。

1.処理性能を改善する
2.プログラムの全体構成を見直す
3.コードをクリーンにする

この3つは相互に絡み合っています。

プログラム単体の処理性能を改善するなら1です。アルゴリズムの見直しをしただけで処理時間が減らせたという経験はあるかなと思います。

2のプログラムの全体構成を見直しても効果が出るケースもあります。たとえば、インターフェースの見直して処理量を減らしたり、結合される処理の順序を工夫し、待ち時間を減らしたりするようなことができます。

3のコードをクリーンする方法でも処理時間を減らすことができるケースもあります。整理されていないコードは無駄な演算をしていることが少なくないからです。

インフラチームの事情

システム開発をしていると、プログラマだけがシステムの最適化をしたいわけではないことに気づきます。

たとえば、インフラ整備をするチームではできるだけI/Oボトルネックを作りたくないわけです。

なるべく高速な読み書きができるハードディスクを使っていますが、もっともっと速くしたい。

そこで物理的なディスクをわけ、アクセスを分散できるような環境を構築してくれます。

ディレクトリ構成

次の2つのディレクトリ構成を見比べてください。なにが違うのか、わかりますか？

環境変数${seq}には、実行ごとにインクリメントされる処理通番が入ります。

/data/${seq}/userdata
/data/${seq}/temp
/data/${seq}/log

/data/userdata/${seq}
/data/temp/${seq}
/data/log/${seq}

前者は処理通番ごとに作成されたデータを格納するために、実行されてから/data/${seq}配下に必要なディレクトリを作って、そこにデータやログを格納する方式です。

後者はデータやログを格納するためのディレクトリはあらかじめ作成されています。その配下に処理通番を名前に持つディレクトリを作って、データやログを格納する方式です。

それぞれの視点

2つのディレクトリ構造は、プログラマ視点で見ると前者が扱いやすいと感じると思います。しかし、インフラ視点で見ると後者でお願いしたいわけです。

後者のディレクトリ構成にしておけば、/data/tempと/data/logをそれぞれ別の物理ディスクに割り当ててマウントすることができるようになります。

物理ディスクが異なるということは、ディスクIOが分散できるということになります。ディスクの分散アクセスをプログラム側で制御するのはかなり手を焼くと思います。

運用チームの事情

データやログなど、ファイルの種類ごとに物理ディスクをわけておくメリットは他にもあります。

それは、tempディレクトリなどに存在する、いらないデータを一括で消すことができるようになります。

逆を言えば、必要なディレクトリだけを対象としてバックアップを取得できるようになるということです。

前者のディレクトリ構成では、/data/配下からtempデータだけを抜いてバックアップするということが簡単にはできなくなります。

すべての${seq}/tempディレクトリ配下のデータを削除して、tempできるようにそのものも削除しなければならないためです。

後者のディレクトリ構成であれば、userdataディレクトリとlogディレクトリだけバックアップ対象に指定すれば済みます。

これは運用チームにとっては大きなメリットです。

おわりに

このようにシステム開発は大規模になってくると、各チームの事情が絡んでくることがあります。

データベースが乗っているシステムだと更にインフラチームは高度化のためにやることが増えたりします。

プログラマはただプログラムだけの面倒を見ていればいいわけではないということが少しでも伝われば幸いです。