読者です 読者をやめる 読者になる 読者になる

プロマネブログ

とあるSIerでプロマネやっているオッサンです。主にシステム開発ネタや仕事ネタ、気になった三面記事ネタの解説なんかしてたりします。

システム開発における「俺の屍を越えてゆけ」

テクノロジー

東日本大震災がおきてからもう早4年がたちました。

震災を経て、家族関係や生活観など、影響をうけたものは幾つもあります。

家族と少しでも長い時間一緒に入られるようにしようとか、家族で避難場所を決めておこうとか。 

 

 

ソフトウェアの耐災害対策についてもそうです。色々考えるようになりました。

 

ソフトウェアの耐災害性

 

4年前の大震災の日、たまたま金曜日ということもあり、休日の僅かな業務を維持できれば良い状態でした。

週明けの月曜日からは、ミッションクリティカルなシステムが万一にも停止したら日本経済がストップしてしまう、ということで24時間の張番が必要だ、みたいな形で交代制で待機体制を用意してたりもしました。

 

その当時はあまり深く考えてなかったのですけど、これって結構恐ろしい話ですね。

 

実は、昔から災害対策(DR)に備えコールドスタンバイ・マルチサイト運営みたいな施策自体はあったものの、実際の災害を目にして動作シミュレーションを考えた場合に問題が発生するってことに気づきました。

 

ソフトウェアをDRに耐えうる形にするためには「冪等性」「エラー忘却型アーキテクチャ」「人をシステムに組み込まない」って3つが必要と考えております。

 

冪等性

DRが発生しサイト切替が行われた場合、データベースの内容などは同期が取られていることも多いのですけど、丁度災害が発生した際に処理中だったアプリケーションのメモリ情報まで引き継げることは保証できなかったりする場合があります。

となると、直前のチェックポイントから再スタートするわけなんですけど、この時に災害前の中途半端なデータベース更新等があると、正しく処理ができない場合があります。

例えば、

  • データインクリメントを行っている
  • insertやappendを伴う処理を実行している
  • ファイルを削除している

など。こういった処理が行われている時、再実行時にトラブルとなることもままあります。

 

こういった問題を解決するために、アプリケーションに冪等性を持たせることが必要です。

いろんな方法がありますが、基本は「入力されたデータ(データベース内容など)の内容を更新しない」「冪等性がない処理とは分離する」など。

とにかく、単純に再実行して同じ結果が保証できるようにするってことですね。

 

エラー忘却型アーキテクチャ

エラー忘却型コンピューティングの半分パクリですが。

 

昔の独立したシステムならともかく、現在のシステムは複数のシステム間接続を行った複雑な構造となっております。災害規模のトラブルが発生した場合、自システム内であればデータの整合性がとれたりもするのですけど、他所のシステムまでデータの保証がとれるか、そもそもデータの連携すらない場合だって考えられます。

完全な状態でのサイト切替後の処理継続ができることを保証できないわけですね。

 

つまり、ある程度は「データがない」「データが不正」な状態を許容して処理が出来るような設計が必要なわけです。

 

ミッションクリティカルなシステムだって、100%のデータ整合性が必要な機能(クリティカル系)もあれば、99%の整合性でなんとかなる機能(非クリティカル系)だってあります。

クリティカル系で必要な機能でデータのトラブル等が発生した場合は、不正データの対処を行い、処理継続とする反面、非クリティカル系では、エラー忘却型コンピューティング同様にデータ不正があった場合はロギング、ないしはメッセージ通知を行い処理を優先するような仕組みを考えておく、みたいな感じです。

 

こういった機能のフローの中でクリティカル系、非クリティカル系を上手く整理したアーキテクチャを考えておくことが必要かなと。

 

人をシステムに組み込まない

前述の2つは震災前もある程度考えておりましたが、震災後特に考えたのが「人をシステムに組み込まない」です。

 

よく、DRマルチサイト設計を行う場合「データセンタに隕石が落ちても大丈夫な設計」みたいに語られることがあります。「データセンタが吹っ飛んでも、別サイトに切り替えてシステム稼働を継続させる」みたいな。

これだと「データセンタだけが被災した場合」の想定となるのかな。

 

しかし、この前の震災で学んだことは、データセンタだけが壊滅する、なんて生やさしい話ではなく、「データセンタと同時に自分も吹っ飛んだ場合はどうするのか」ってことだと思います。

つまり、自分が死んでもシステムは動き続けられるのか、と。

 

これ達成するためには、自動切り替え・再ランを行うツール等の活用やハンド作業が不要なDR対策の構築といった災害発生時の考慮もちろんのこと、ノウハウの形式知化(ドキュメント化など)など災害発生後に備えて普段の開発活動だって気をつけることは山積みです。

 

これは結構しんどい。一つ一つ行動する都度、「本当にこれは自分がいなくてもシステムを継続できるように考慮されているか」を考え続けなければならないわけで。

 

まとめ

まあ、色々書きましたが、東日本大震災を経て得たシステム開発に対する思いとしては「自分が死んでもシステムは生きろ」ってことですね。

 

俺の屍を越えてゆけって。

 

責任者が死んだらシステムは維持出来ません、なんてのはシステムの復元性を損なってしまうわけで、そういうのはせっかく有効な技術を使いこなせていることにならないかな。なんで、プロマネならそこまで気をつけたいなあと思ってます。

 

 

 

まあ、人間の知能をコンピュータで再現できるようになれば、こんな考慮も要らなくなるのかもしれませんけど。

 

 

以上

 

 

俺の屍を越えてゆけ (通常版)

俺の屍を越えてゆけ (通常版)

 

 

 

広告を非表示にする