先週は関西で非常に強い台風が猛威を振るい、昨日の未明には北海道で大きな地震が発生し、どちらもいまだに多くの方が被災されています。被害に遭われた皆様には、心よりお見舞い申し上げます。

さくらの DC に停電の影響が出た

北海道の地震では、全道が停電するという非常に大規模な停電が発生しています。それに関連し、北海道にデータセンターを持つさくらインターネットでも影響があったようで、さくらを使用している弊社にも、サーバーダウンの可能性もあるというメールが来ました。

停電中は自家発電装置で凌いでいたものの、燃料が48時間分しか無いとのことで、燃料がなくなった場合にサーバーダウンの可能性があるとのことでした。

結局、各方面の努力の甲斐もあり、無事復旧したようですが、色々と考える契機となりました。

さくらの石狩データセンター、停電によるサービス障害から復旧 – 週刊アスキー

災害大国日本

先週の西日本の台風、昨日の北海道の地震に限らず、日本では自然災害に遭う確率が他の国に比べて高いと思います。主なものは、

  • 地震、津波
  • 台風
  • 火山

といった自然災害ですが、

  • 外国からの攻撃
  • テロ

などの可能性も排除するわけにはいきません。

取り得る対策

中小企業には予算も人員もない

さて、そうした災害が起こることを想定して、どのような対策を取れば良いでしょうか。

例えば、ある程度の規模のシステムを担当したことがあるシステム屋さんであれば、関東と関西にシステムを分散させるなどといったディザスタリカバリのプランなどを検討したことがあるかと思いますが、私は正直なところ、こうした対策は大企業のためのものという思い込みがありました。ただ、ここ最近の身近な災害を目の当たりにして、中小企業だからといってこうした対策をしなくて良いわけでは無いなと思うようになりました。

もちろん、大企業であれば、専門の部署があったりそれなりに予算を付けたりしていると思いますが、中小企業では予算も人員も限られているため、中小企業なりの対策を考える必要があるかなと思います。以下、中小企業でも出来る対策を考えてみます。

（なお、個人でも行うような、水・保存食・防災グッズを用意する等の対策は、今回は扱いません。）

システム面

地域をまたいだ冗長化

先ほど、関東と関西にシステムを分散させるという例を出しました。以前であれば、こうしたことが出来るのは限られた大企業のみでしたが、最近ではクラウドを活用することにより、比較的簡単に実現できます。

AWS や、前述のさくら、あるいは Azure、GCP など、基本的にはどのベンダーでも複数のリージョン感で冗長構成を取ることが出来るようになっています。

以下、参考情報を挙げておきます。

Infrastructure as Code

さきほどの冗長化は、データベースの場合にはよく使われる手段ですが、では web サーバーなども違うリージョンに待機系を用意して置いて、すぐ立ち上げられるようにすべきでしょうか。

web 系のシステムであれば、デプロイ処理時に以下のような処理も含めておくという方法が考えられます。

  • サーバーのイメージファイル（AWS であれば AMI）を作成
  • イメージファイルを別リージョンに転送

ただ、こうした冗長化をどこまで行うのかは要件次第でもあり、単純な web + DB システムであれば、

  • DB は、リージョン間でレプリケーションを設定しておく
  • web は、ツールで簡単にプロビジョニング・デプロイできるようにしておく
  • web サーバーに限らず、インフラは Infrastructure as Code を意識しておく

という簡単な対策でも十分な場合も多いです。あるリージョンで障害が発生した場合には、

  • 別のリージョンのレプリカをマスターに昇格させる
  • 別リージョンに、最新のアプリを素早くデプロイする
  • DNS の設定変更を行う

という作業で、比較的簡単に復旧できます。

業務面

自分たちが管理しているシステム以外でも、色々考慮事項・対策は考えられます。

ツールの冗長化

ソフトウェア関係の仕事をしていると、自分たちが使っているサービスが何らかの理由で止まってしまうと仕事にならない、というケースが良くあります。

例えば、開発者に人気のチャットツールである Slack が落ちたりすると、「本日仕事終了」などといった書き込みが Twitter に溢れたりしますが、これへの対策も、基本的には冗長化だと思います。

弊社の場合、チャットツールであれば、ChatWork も併用していますし、1つのツールにヘビーに依存しないように心がけています。複数のツールを併用することで、1つが落ちても影響が少なくなるからです。

とは言え、さすがに GitHub は落ちてしまうと代えはききづらいのですが、git は分散型のバージョン管理システムのため、push は出来なくてもローカルで開発は継続できますので、何とかなるものです。

色々ツールを使っていると、情報が分散しがちなのですが、それらをまとめる便利なツールを弊社で開発していますので、もし良ければ使ってみて下さい。（と軽く宣伝。）

Track Down Anything on GitHub, Slack or Google Drive | Commet

働く場所の分散化

弊社では、基本的には開発者は全員リモートワークを行っています。偶然の面もあるのですが、地理的にも以下のようにばらけています。

  • 関東周辺
  • 広島
  • 東南アジア
  • ヨーロッパ

従って、どこか1カ所で業務が出来なくても、他の場所で引き継ぐことは可能です。

さきほど「関東周辺」と書きましたが、東京都心に住んでいるメンバーは少なく、都下、埼玉、横浜、川崎とほどよく分散しているため、東京都心で何かあっても弊社の業務という点ではそこまで大きな影響は無いかと思います。（日本というシステム的には甚大な影響があるかと思いますが・・・）

まとめ

日本で活動していると、様々な災害の可能性が考えられます。最近では技術の進歩により、中小企業でも随分多くの対策が取れるようになっています。今回立て続けに発生した災害をかえりみて、自分たちで出来る範囲で地道に対策を打っていく必要があると感じています。

なお、システムの冗長化などのご相談は、お問い合わせフォームよりお願いいたします。

お問い合わせ – もばらぶん