NGW Linux版
2026年度、NGW は動作環境を Linux（Ubuntu）へ移しました。 アプリケーションはこれまでと同じものですが、サーバの作り方を全面的に見直しています。 ここでは、何がどう変わったのかをご説明します。
Linux版で変わったこと
-
サーバを2台1組に
NGWメインとNGWクローンの2台構成にします。片方が故障しても、手順に沿って業務を継続できます。
-
高度な排他制御
500人規模で同時接続している場合でも、データベースの排他制御により正確な値を登録します。
-
表示が速くなった
一覧や検索の重い処理を見直し、画面の表示速度を改善しています。
-
バックアップを作り直した
日次・週次の多世代バックアップを持ち、「取れているか」ではなく「戻せるか」で運用しています。
NGW のデータベースは MySQL（InnoDB）です。1つの更新はトランザクションとして扱われ、 最後まで通ったときにコミット（確定）されます。書きかけの状態が他の職員から見えることはなく、 異常が起きたときは取り消されて、中途半端なデータが残りません。
ただし、トランザクションが守るのは1つ1つの更新の確実さです。 「先に読んだ値をもとに書く」処理が同時に走ることまでは防げません。 受発番号の採番がこれにあたり、2人が同じ最大値を読めば、同じ番号が振られてしまいます。
そこで NGW では、番号を決める区間だけをロックで囲み、1人ずつ順番に通します。 ロックは年度×文書記号ごとに分かれているので、別の文書記号の登録は待たされません。 番号が決まった時点で解放するため、そのあとの処理も待たせません。 負荷試験では、この対策の前に3,493件中869件あった番号の重複が、対策後は0件になりました。 処理量は 39.9件/秒 → 39.2件/秒 で、ほとんど変わっていません。
- 排他制御とは
- 同じデータを複数の人が同時に触ったときに、順番を決めて1人ずつ通す仕組みです。 取り合いになる場所（NGW では受発番号の採番）だけを囲むので、 関係のない登録が待たされることはありません。
- トランザクション・コミットとは
- いくつかの書き込みを「ひとまとまりの更新」として扱うことをトランザクション、 それを確定させることをコミットといいます。 確定するまでの書きかけは他の職員から見えず、途中で異常が起きれば取り消されます。
2台1組の構成
クローン機は常時起動しています。ハード故障のときは、決められた手順で切り替えます。
データベース
MySQL のレプリケーションで、メインの更新をクローンへ準リアルタイムに反映します。負荷が低く、実質的な DB のミラーになります。
文書・添付ファイル
起案の添付書類、共有文書、回覧板の添付など、実ファイルは5分ごとに同期します。
アプリケーション
プログラムは両機に同じものを配置します。更新は同じ手順で両方に適用されます。
データベースは更新のたびにクローンへ流れます。職員が登録した文書は、ほぼ同時に向こうにも入ります。 添付ファイルの実体は5分ごとにまとめて同期します。 切り替えが必要になったとき、失う可能性があるのは直前5分以内に上がった添付ファイルだけで、 文書の登録内容そのものは残ります。
- 準リアルタイムとは
- 「常に完全に同じ」ではなく、ごく短い遅れを認めたうえで追いつかせるやり方です。 完全に同じ状態を保とうとすると、本番はクローンへ書き終わるまで待つことになり、日々の操作が遅くなります。 NGW は本番を待たせない側を選び、データベースは更新のたび、ファイルは5分ごとに追いつかせています。
自動フェイルオーバーは、誤作動でメインとクローンが同時に動く事故（スプリットブレイン）を招きます。 NGW では手動の切替スクリプトを用意し、①メインの停止確認 → ②クローンの昇格 → ③アドレスの付け替え → ④メイン側の同期遮断、という順序で確実に切り替えます。
- フェイルオーバーとは
- 本番の機械が止まったときに、待機している機械へ役割を移して業務を続けることです。 人が手順に沿って移すやり方と、機械が自分で判断して移すやり方（自動フェイルオーバー）があります。 NGW は前者です。
- スプリットブレインとは
- 本番と待機の2台が、互いに「相手は落ちた」と思い込んで、どちらも本番として動いてしまう状態です。 両方に別々の登録が入るため、あとから1つにまとめられなくなります。 ネットワークが一時的に切れただけでも起こりうるので、NGW は自動での切り替えをしていません。
クローンはハード故障（可用性）を守りますが、誤削除やデータの破損はクローンにも即座にコピーされます。 「過去に戻る」手段は、バックアップの世代管理から復元できます。
- レプリケーションとは
- データベースの更新を、もう1台へそのまま流して同じ状態に保つ仕組みです。 メインで登録した文書は、ほぼ同時にクローンにも入ります。 速さが利点ですが、間違えて消したことも同じ速さで伝わります。 だからバックアップとは役割が別で、両方が必要です。
バックアップ
論理事故（誤削除・破損・巻き戻し）への備えです。冗長構成とは役割が別で、両方が必要です。
| 種別 | 取得 | 世代 |
|---|---|---|
| 日次バックアップ | 1日4回（早朝・昼・夕方・夜間） | 曜日ごとに保持 |
| 週次バックアップ | 週1回 | 約90日（13世代程度） |
添付ファイルを多く扱う団体では、データ量が加速度的に増えていきます。 DB のダンプよりも、実ファイルの容量のほうが先に効いてきます。 バックアップは「取れていること」ではなく「実際に戻せること」を確認しながら運用しています。
機器構成
Mac ＋ UTM の仮想環境、または Linux 機での運用になります。想定する接続ユーザー数から実機を選びます。
| 接続ユーザー数 | 100 | 200 | 300 | 500 | 1000 |
|---|---|---|---|---|---|
| CPU（物理コア） | 4 | 4 | 8 | 8 | 8〜16 |
| メモリ | 16 GB | 16 GB | 16 GB | 32 GB | 32 GB |
| 内蔵SSD | 500 GB | 500 GB | 500 GB | 1 TB | 1 TB |
| 外付けSSD（保存先・各機に1台） | 1 TB | 1 TB | 1 TB | 1 TB | 2 TB |
| データベースの目安（開始時） | 0.3 GB | 0.5 GB | 0.8 GB | 1.3 GB | 2.5 GB |
| 同（7年後の想定） | 1 GB | 1.5 GB | 2.5 GB | 4 GB | 8 GB |
新しく組む機器を選ぶための目安で、稼働中の団体の実測から余裕を見た値です。 8団体（データベース合計 11 GB）が載っている機体が4コア・8 GB で動いており、 200人規模なら M4 の MacBook Air（16 GB）で足りることも実測しています。 それでもこの表より落とさないのは、メモリを削ると MySQL がデータをメモリに載せきれず、 表示が急に遅くなるためです。
2台のスペックを揃えます
切り替えたあとは、クローンがそのまま本番を担い続けます。待機側は「いつ本番になってもよい機体」である必要があるため、同じ型で揃えるのがいちばん簡単です。
外付けSSDは各機に1台
バックアップは、本番にディスクの負荷をかけないようクローン側で取ります。役割が入れ替わると取り手も入れ替わるので、両方に同じ場所で常設しておきます。障害の最中にケーブルを挿し替えずに済みます。
2台は同じLANに置きます
クローンはメインのデータベースへ接続してレプリケーションを受けます。庁内ネットワークの中で完結し、外へは出ません。
動作環境
サーバ
| OS | Ubuntu Server 26.04 LTS |
|---|---|
| Web | Apache 2.4 |
| PHP | PHP 8.5 |
| DB | MySQL 8.4 |
| 構成 | NGWメイン／NGWクローンの2台1組（1台構成も可） |
| ネットワーク | LGWAN 閉域を前提とした庁内設置 |
クライアント
| ブラウザ | Microsoft Edge / Google Chrome |
|---|---|
| OS | Windows 10 / Windows 11（64bit） |
| 追加ソフト | 不要（Java・ActiveX 等のインストールは要りません） |
| 通知ツール | オプションで常駐通知ツール「NgwNotifire」を追加できます。新着の回覧板・未処理の決裁案件を Windows の通知（トースト）で受け取れます |
| 帳票 | すべて PDF。印刷前に画面でプレビューできます |
| 配色 | 利用者ごとに画面配色を選べます |
※ 規模の目安として、職員数 200〜500人規模の団体での運用実績があります。詳しい構成はお問い合わせください。
Linux版を作った記録を公開しています
Linux への移行、2台1組の同期、無人運用、バックアップの作り直し、負荷試験で見つかった不具合。 開発の途中で分かったことを、開発ブログに書いています。