見出し画像

EBt を災害時の情報共有で使ってもらいたい

巨大地震の不安が強くなってきた中、EBt をサーバーなしでも動くような形で実装した理由も含めてこの辺の意図をちょっと説明したいと思います。

EBt でクラウドを使わない方針とした理由の一つは東日本大震災でした

理由は当然一つではない。ただ、その理由の中の一つで結構大きいのが東日本大震災だったということです。地震後、インターネットは問題なく使えましたし、別にクラウドサービスは結構頑健だなぁなんて思ったりもしました。

とはいえ、インターネットはちゃんと動いているにもかかわらず、どうにも情報伝達がうまく出来ていなかった。結局、データをうまくやりとりするための仕組みはインターネットとは別のところにあると感じました。

また、今回はまだ良かったけど、インターネットという仕組みが大して頑健ではないということも忘れてはいけません。最悪の事態は、インターネットも使えなくなって情報伝達の仕組みが消えてしまう状態。これは何としても避けないといけない。

EBt はこのような要求に耐えられることを目指した設計にしています。

通信が途絶した環境でのデータ共有のあり方について

私はこう考えました。インターネット(WAN)は途絶したが、LAN は何とか生き残っている可能性が高い。だから、LAN が使える前提は残しておこう。でも、WAN は使えないことを想定しよう。
すると、ルーターの提供する名前解決サービスは使えるが、インターネットを使ったやりとりは出来ない。つまり、ルーターの外側との通信が断絶した状態です。

この場合、まず LAN 内でのデータ共有が出来ることが大前提です。もちろん、こんな状況ではサーバーに期待することは正直困難。だから、サーバーレスで動作可能な P2P をベースとした通信手段を一番の基本としました。とはいえ、無制限のデータアクセスはそれはそれで問題があるので、権限として許可されているデータのみを受信するような制限も同時につけています。

通信が P2P ベースになり、しかも、サーバーが存在しない。つまり、全ての EBt はサーバーでありクライアントであるということが必要になります。

そして、ここで更に新しい条件をつけます。それはPC上に全てのデータがあるわけではない。必要ならば、近隣のPCからデータをもらうです。
これを実現するために、データ更新で多発する衝突がまず起きないような DB を作りました。簡単に言うと、内部はオブジェクト指向DBなのですが、DB内の更新管理はテーブルで言うところの行ではなく、セル単位で行うようにしました。そしてセル単位で更新日付を持つことと、セルデータの欠損が起きてもエラーにならないようなアプリケーション構成にすることで、部分的にデータが更新された状態でもアプリケーションが動くようにしました。こうすることで、データの同期処理の途中でもデータアクセスでエラーが起きないようにしています。また、IDについても、UUID を更に発展させたようなものを使っているので、IDの衝突が起きる可能性はほぼ無いという形になっています。そのため、IDもいわゆる数値ではなく、数値や文字列、何だったら IDとIDを組み合わせて更にIDを作るような形になっています。

とはいえ、データの更新を誰も知らないと困るので、データ閲覧・更新時はこんな動きをします。

  • データ閲覧時は、自分のデータを知っているPCに送付。及び、知っているPCにデータ送信を依頼。

  • データ更新時は、更新したデータを知っているPCに送付。

つまり、ネットワーク上での更新は、黙っていてもその時点で稼働しているPCに共有されます。そして、データ送信は常に知っているPC全てが対象です。だから、何人かで使っていると、それらの人たちの閲覧したデータがどんどん共有されるようになります。さらに、データ要求時は、リンクにして一つ先のデータまで要求するので、データを取得すれば、関連データも自動的に取得できます。

ここまでやれば、以下の条件が満たせるようになります。

  • ID の発番のためにサーバーを配置する必要がない。

  • リアルタイムのデータ同期を行う必要がない。

  • データ更新の更新順序はない。出来るところからやっていけば良い。

  • 通信相手は自分で見つけるので、サーバーを明示する必要はない。

  • 利用者が閲覧したデータとその近隣データは常に共有する。

さて、ここまでのシステムが出来ました。では、災害時の運用はどうするべきか?という話に移ります。

災害時の運用について

基本的には、ノートPCを持ってうろつくという形になります。いろんな人がノートPCを持って拠点間をうろつき、そこでデータを見ながら作業をしていくことで、別の拠点に勝手にデータが共有されていきます。だから、改めて同行するというわけではなく、みんなが自分のPCを移動先の拠点のネットワークに参加させるだけで、どんどんデータが共有されていきます。

もっと確実にやりたければ

サーバーをインストールした PC を定期的に拠点間で移動させていって下さい。
運用としては、例えば一番の拠点(本部がある所とか)に行く人がいれば、その人にサーバー(ノートPCにインストールしていれば良い)を託します。
拠点に着いたら、そこでサーバーを起動し、ほったらかしておきます。それだけで同期が始まります。
※但し、セキュリティの都合で信頼したサーバーにしかデータを送付しないようになっているので、拠点の人たちは全てのサーバーを信頼しておいてください。
そして、拠点から帰るときに、サーバーを終了して自分の拠点に持ち帰る。これで、データの共有が出来ます。
もちろん、本部以外にいくときにも持ち歩いてもいい。サーバーはいつ動かしてもいつ止めても特に問題はないので、拠点ごとに「本部との往復用サーバー」「他拠点にいく問いに持っていくサーバー」「自拠点のデータをとりまとめているサーバー」の3つを動かしていれば良いです。実際のところ、自拠点のサーバーはなくても良いのですが、全員どこかに出掛けちゃうと困るんで、作っておいた方が良いかなとは思います。

ネットワークが復旧したら

その場合は、本部でサーバーを動かし、VPNで拠点のサーバーを本部のサーバーに接続という形にすれば普通の運用が出来ます。

わかるかと思いますが、本部と拠点のサーバーは通常時も運用しておきます。で、異常時には、拠点で稼働している予備サーバーでデータを運搬する。そんなイメージです。
どこかのクラウドにサーバーを置くというのも良いですが、非常時にアクセスできなくなるという問題はかなり致命的です。だからオンプレのサーバーにという流れも出てきているのかもしれません。まぁ、最近のオンプレ回帰の理由はもっと違うところにあるみたいですが…

実際のところ

災害とかこんな運用をしないといけない事態なんか起きないに越したことはありません。ただ、念ための備えがあるかないかという話で考えると、備えは当然あった方が良い。

あと、別に個人レベル(例えば、知り合いネットワーク)とかでも問題なく使えますよ。サーバーは、近々 Ubuntu 版も公開予定です。
さすがに、x64 は要求しちゃいますけど…(だから、ラズパイとかはダメ…)

というわけで

EBt がそんな備えの一つとして使っていただけることを願っています。
ただ、EBt はまだ実績の少ないソフトウェアです。色々と使って問題を洗い出していくことはやっていきたいと思っています。何せマイナーソフト、まだバグがいっぱいあります。

なお、自治体や非営利組織で試してみたい場合は、私まで連絡頂ければプロモーションコードを発行します。
簡単に言えば、1年分の無料利用権です。まぁ、1ライセンス200円/年ですけど。そんなにたくさん発行枠があるわけではないのですが、30日の無償利用期間で評価が終わらない場合はご連絡くださいませ。

この記事が気に入ったらサポートをしてみませんか?