NGW Linux版
— 動作環境を Ubuntu へ移しました —

NGW の動作環境を Linux（Ubuntu）へ移しました。アプリケーションはこれまでと同じものですが、サーバの作り方を全面的に見直しています。

これまでの Mac ＋ MAMP から、Ubuntu ＋ Apache ＋ MySQL の構成へ。Mac ＋ UTM の仮想環境、または純粋な Linux 機での運用になります。

主な変更点

サーバを2台1組で構成できます

NGWメインとNGWクローンの2台構成にします。データベースは MySQL のレプリケーションで準リアルタイムに反映し、起案の添付書類・共有文書・回覧板の添付といった実ファイルも同期します。プログラムは両機に同じものを置き、更新は同じ手順で両方に適用します。1台構成のままでも動きます。

ハード故障のときは、決められた手順で切り替えます。

1. メインが止まっていることを確認する
2. クローンを昇格する
3. アドレスを付け替える
4. メイン側の同期を遮断する

切り替えは自動にしていません。自動フェイルオーバーは、誤作動でメインとクローンが同時に動いてしまう事故（スプリットブレイン）を招くためです。

レプリケーションはバックアップではありません。クローンが守るのはハード故障で、誤って消したデータはクローンにも同じように反映されます。「過去に戻る」手段は、バックアップの世代管理から復元できます。

高度な排他制御

500人規模で同時接続している場合でも、データベースの排他制御により正確な値を登録します。

受発番号は、これまで「現在の最大値を読んで1を足す」方式で採番していました。この作りでは、同じ年度・文書記号の登録が同時に走ったときに、2人が同じ最大値を読んで同じ番号を振ってしまいます。実際に負荷試験で確かめたところ、収受文書 3,493件のうち 869件が、他の文書と同じ受発番号を持ちました。

現在は、年度×文書記号を単位にしたロックで、採番の読み取りから書き込みまでを直列化しています。同じ試験で重複は0件になりました。処理量は 39.9件/秒 → 39.2件/秒 とほとんど変わりません。ロックは文書記号ごとに分かれているので、別の記号の登録が待たされることもありません。

実運用で受発番号が重複したという報告はありませんでした。ただし、文書記号によっては1日に86件の登録がある団体も実在します。「まだ起きていない」は直さない理由にならないと考えて、作り直しています。

同じ試験では、朝の一斉ログインも測りました。待ち時間ゼロで392名が同時にログインしても、全員成功し、失敗は0件です。ログイン自体は最大13.7秒待たされますが、ログイン後のホーム画面は392名同時でも中央値0.15秒で表示します。

この試験は、実際に職員が流したリクエストの記録をそのまま流し直す方式で行いました。くわしくは開発ブログの 負荷試験で壊れたのは、性能ではなく発信番号だった に書いています。

表示速度を改善しました

一覧や検索の重い処理を見直しています。ログイン直後のホーム画面は、決裁待ちの一覧が全件走査になっていたため、テスト用のIDでは表示に6秒かかっていました。索引を足して0.15秒になっています。

この遅さは、メモリに余裕のある Mac では表面に出ていませんでした。非力な Linux の1台に載せたことで見つかったものです（速いマシンは、優しい嘘をつく）。

バックアップを作り直しました

日次・週次の多世代バックアップを持ちます。

2台の状態は監視画面で見ています。到達性・鮮度・最終結果・ディスクの空き・レプリケーションの5つです。「取れているか」ではなく「戻せるか」を確認しながら運用します（バックアップは「取った」ではなく「戻せる」）。

画面の変更

• サブシステムメニューが、系統ごとのバーから共通バー＋ホバーで開くパネルに変わりました。
• 起案画面の4つめのタブが、決裁に回したあとは「決裁状況」になりました（新規のうちは従来どおり「決裁経路設定」）。

動作環境

くわしくは Linux版のページ をご覧ください。