自らの勉強のためにも、このブログを週一ぐらいでは書きたいなぁと思いつつ、書けていません。
まぁ下書きのほうにばっかり書きかけが溜まっていってるんですけどね。
まぁそれはそれとして小規模システムを受託開発するにあたって、システム構成を考える必要があるわけですが、その時に私が頭に入れていることを書きたいと思います。
想定している小規模システムとは以下のようなもので、受託開発以外にも趣味で作るようなものも含めています。
小規模システムの要件
- 発注サイドにエンジニアがいない
- よって開発人員は私ひとり（個人受託なので）
- 処理量(アクセス量など)は多くない
- ただし要件(ビジネスロジック)が単純とは限らない
気を付けていること
- 構成ミドルウェアを最小にする
- 導入ライブラリはシンプル実装優先
- ダウンタイムはラフに考える
- DB設計は念入りに
- パフォーマンスチューニングは後回し
- ドキュメントは最小限
細かい内容説明
構成ミドルウェアを最小にする
サーバ上ではApache+MySQLだけが動いている、とかが好ましいです。
パフォーマンスを出すためにmemcachedやredisを立ち上げたり、ジョブキューサーバを立てたり、いろいろと便利なものを立ち上げるたびに障害点が増えていきます。
なるべく単純なファイルキャッシュなどで対応して、ソフトの数を増やさないようにすると、どこかのプロセスが落ちてたから死亡みたいなことを減らせるので寝る時間が増えます。
最近はレコメンドの機能を入れるにあたって、商用APIは価格感が折り合わず、またオープンソースのエンジンを入れるにも別途プロセスを起動する必要があるものが多く（学習処理が重い場合があるので分からんではない）、いまいちでした。
なので単純なもの（100行にも満たない）ながら自前実装したことで、運用の手間を増やさずに対応できました。
ファイルのバックアップにrsync(+lsyncd)を使ったりするのも、同様なので、aws s3にぶち込んで終わりにできるならそのほうが楽なケースが多いです。
何が言いたいかというと、小規模システムではマイクロサービス的な設計より、モノリシックな構成のほうが有効(というか、後が楽)だということ。
導入ライブラリはシンプル実装優先
あとはサポートが長持ちしそうか。
時流に見捨てられてもサポートは続きます。
なるべくシンプルな実装になっているもののほうが、後から手を入れるにも、ほかのものに乗せ換えるにも簡単便利です。
ダウンタイムはラフに考える
業務量の総量（注文数）がさほどでもないので、ダウンタイムの経済的インパクトがそこまででもないです。
サーバ業者がデータ吹っ飛ばす級のアクシデントなら、数時間～1日とまっても許してもらえるでしょう。
なので、ホットスタンバイを用意しておくとか、自動切り替えとかは要りません。
それらの準備や、普段の監視コスト、アップデートの手間の増加、ちゃんとフェイルオーバーが働くことの定期確認などのコストのほうがよほどでかいです。
普段は安全地点にデータを逃がしておき（コールドバックアップ）、いざというときはサーバを立て直すと決めているほうが楽です。
多少のデータロストが発生する設計でもいいと思いますが、まぁそこはトレードオフですね。また、いざというときに手作業でカバーできるように業務フローを直しておくと災害時対策になります。
DB設計は念入りに
小規模システムは逆に言うと成長余地を残しているシステムです。
ガンガン機能拡張されていくことが割と予想されるので、初期のDB設計的には拡張の余地を目いっぱい取っておくことが好ましいです。
拡張の余地を取っておくとは、つまり教科書的に設計(正規化)しておくということです。
ダウンタイムはラフに考えられるので、後からテーブルに追加カラムを足すことは難しくありません。
なので、たまーに見かける（見たくない）、後で何かに使えるように・・みたいな予備カラムを作っておかないように。
非正規化してパフォーマンスチューンとか、後の後の後でいいです。むしろ業務システムにはほぼ要らない。
パフォーマンスチューニングは後回し
処理量が大したことないので、意外とコンピューターのパワー任せで重い処理もぶん回ります。
そして多少重くなったところで、全体処理数が少ないので、しばらく待つ（重いのを耐える）こともできます。
本当につらくなってきてから考えましょう。
すくなくとも、ここ将来的に重くなりそうだから設計を・・みたいな小技は使わないように。もちろん「最初からチューニングしないとまともなパフォーマンスが出ないとわかりきっている場合」は別。
『賢いデータ構造と間抜けなコードのほうが、その逆よりずっとまし。』（伽藍とバザールより）
ドキュメントは最小限
あんまりここにお金が出ないので（お金を引っ張れたり、発注者の強い要望がある場合は別）、自分が死んだときに最悪他業者が引き継いだとして、システムの全容を解析するのに必要な最低限の情報をまとめておくことから始めましょう。
構成図とか、ER図とかね。
ていうかこれすらないシステムの引継ぎとか、たまにあるけどマジ死ねってぐらいめんどくさい。
コメント