インタビュー

個人でも参考になる「災害とITの向き合い方」~サーバーのプロは災厄とどう向き合っているのか?~

この道20年のプライベートクラウド事業者に聞いてみた

ジャストプレイヤー株式会社 代表取締役CEO兼CTOの瀧 康史氏

 テレワークの急速な伸長で、様々なIT機器やクラウドサービスが急速に普及しているが、一方で気になるのが、そうしたサービスの「安全性」。

 台風や地震が起きたら、データやシステムはどうなるのか?事前に対策するにはどうしたらいいのか? これらは、「リスクマネジメント」として既に体系化されているが、「紙+会社」で常識だったやり方と、「電子データ+IT機器」での常識はやはり違う。

 また、コロナ禍で言われ始めているのは「少しでも事前に対策できていたか?」の違いで、結果に大きな差ができたこと。

 そこで今回は、2001年に創業、20年近くレンタルサーバーやプライベートクラウド事業を手掛け、災害に対する事前対策にも経験が深いというジャストプレイヤー株式会社の代表取締役CEO兼CTOの瀧 康史氏に、「災害との向き合い方」を聞いてみた。

 サーバーのプロが、災害とどう向き合い「何をポイントと考えるのか?」を様々な側面でお伺いしてみた。同社のサービスを普段使うようなプロの方から、個人としての災害対策を考えるヒントが欲しい方まで、参考にできるお話をお伺いしたので、気になる方は是非参考にしてほしい。


2009年からプライベートクラウドサービスを提供東日本大震災を契機に災害対策にも注力

同社の主要事業。プライベートクラウドを中心にVPNやクラウドストレージなども展開している
コネクティビティサービスでは、特に災害対策にフォーカスしている
コンシューマー向けのクラウドストレージサービス「TeraCLOUD」も展開。昨今の需要にあわせて、ファイル共有の仕組みを改良するなど、現在も改良が続けられている

――まず、ジャストプレイヤーさんの事業内容を教えてください

[瀧氏]主に、B2Bのプライベートクラウドや企業・データセンター間ネットワークを中心として、企業の情報インフラを支えています。起業は2001年で、初手は小規模のビジネス向けのサーバーサービスを2002年からです。当時はクラウドという言葉はありませんでしたが。2009年にはSolarisを利用して本格的にプライベートクラウドサービスを始めました。変わり種としては、2014年からは、TeraCLOUDというコンシューマー向けのクラウドストレージサービスを開始していますね。

――Solarisというのがユニークですね

[瀧氏]2000年頃、規模が大きいところではSolarisが使われていましたね。ちょうどLinuxへの移行が進んでいた時期でしたが、2002年ごろは、われわれも小さい規模であればLinuxを使ったり、大規模なものはSolarisを使ったりしていて、「新興企業でSolarisが使えるところは少ない」ということでアドバンテージになっていました。

 その後の2005年、Solaris 10で無料版が公開されたましたが、それをきっかけに、私もユーザーとして再び触ってみました。ZFSファイルシステムや、コンテナ、リソース管理など、Linuxと比べて秀でている面がありましたし。そうしてSolarisに回帰してみて「悪くないんじゃないか」と思い、Solarisのユーザー会にも参加して活動しました。

――そこからSolarisを利用したプライベートクラウドサービスを始めたわけですね

[瀧氏]最初はサーバーサービスと呼んでいましたが、クラウドという言葉が出てきて呼び方を変えました。

 当時はビジネスの分野で、「わからないところに会社のデータを持っていくのが怖い」という声があり、パブリッククラウドでも自社のサーバールームでもないところにワンクッションを設けることを考えました。わりと近くてなんとなくわかっている、たとえば国内の東京などであれば、心理的な障害が少ないんじゃないか。そして、そのネットワークをプライベートネットワークに延伸する。それをプライベートクラウドと呼びました。最初はレジ会社と協業して、POSレジのデータを扱っていました。

――今でいう「クラウドサービス」を、その名前になる前から手掛けられていたわけですね。災害対策やその準備について、経験が多いとお伺いしましたが、それはどうしてなんでしょうか?

[瀧氏]そうですね。我々は、災害時などに事業を継続するための計画である「BCP」(business continuity plan)や、災害からの復旧に関わるディザスターリカバリー(DR=disaster recovery)について、多くの経験があると思っています。

 まず、そもそも、我々はお客様の事業の根幹を支えるエンタープライズ系サーバーやデータをお預かりしているわけなので、「何かあった場合、どう回復し、続けていくか」というところから無縁ではいられません。「データセンターが地震で倒れる」といったことはなかなかないにしても、「東京 - 大阪間の回線のどこかが不通になる」とか「機材の不具合でサーバーが止まる」、あるいは設定ミスなどの論理的な問題で、システムは停止してしまいます。それをどう継続していくか?というのは、やはりいつも考えている部分ですね。

――きっかけなどはあったのでしょうか?

[瀧氏]やはり2011年3月11日の東日本大震災ですね。3.11以降、われわれは、BCP、DRをまじめに考えなくてはならなくなりました。正直なところ、それ以前は、「大地震が起きたら、もうみんな生きてないかも知れないし、ITシステムとか言っている暇はないのではないか?」といった考えだったのですが、実際に起きてみるとむしろその逆でした。

 企業さんが、災害からの復旧を必死にしていく中、ITシステムも当然それを支えていかなくてはなりませんし、それができるだけ楽になるように、事前の計画(BCP)が必要になるわけです。

 そこから、データセンターやコネクティビティサービスをすべて見直して、DRやBCPに本格的に取り組んできました。当時は、DRというとデータをテープに記録して遠方に送るのが定番の時代でした。そこから、「どう保護してどう戻すか」を考えながら、真剣に取り組んできました。

 来年で3.11から10年です。いろいろ技術や経験を積み重ねてきて、お客様からもDRの相談が増えました。


ITは災害とどう向きあうか

――では、その災害対策(DR)について、どういった技術をお持ちなのでしょうか?

[瀧氏]DRの基本は「2つの場所にサーバーやデータを持っておく」ということなのですが、すぐに出てくる課題が「ある時点のデータをどのようにメインサイトとセカンダリーで同期するか」ということです。

 災害時に切り替える際、どのようなタイミングでメインとセカンダリーを切り替えるか(ほぼリアルタイムなのか、切り替えに数時間かかってよいのかなど)によって、使う技術が変わってきます。特にリアルタイムに近い形で切り替えるのであれば、遅延を少なくすることがとても重要です。それを実現するために、ストレージの遠距離レプリケーションと、ネットワークの接続の2つについて技術を積み重ねました。

 ストレージについては今もいろいろなものを試していて、ZFSのレプリケーションがいま比較的うまく動いています。たとえば、弊社のVMware Private Cloudサービスでは、DR構成で契約していただくと、メインサイトにあるストレージがDRサイトに定期的に同期されます。障害時に復元するときには、VMwareのイメージが何世代か前まで復元できます。これをVMwareの力を借りずにやっているのが面白いところです。

 また、我々のお客さまでは、東日本と西日本にメインとセカンダリーをお持ちの方が多いのですが、それを繋ぐネットワークとして、東海道ルートや中央道ルートなど複数の経路を利用しています。例えば、東海道沿線は、安くていい回線が引かれていますが、高潮などの影響を受ける箇所があり、実は数年に1度切れることがあります。そういうときには、自動的に中央道ルートに切り換えます。

DR対応システムの実例。「メインサイトの関西リージョンと、セカンダリサイトの関東リージョンを統合。データを持たないアプリケーションサーバは東西で同時に動き、データベースはマスタースレーブで非同期レプリケーション(西から東に逐次同期)している」とのこと。このシステムに8000人を超える社員がアクセスしているという。

 また、DRって、個別のサーバーでは十分対策していても、「システムでは災害時に機能しない」なんてことがたまにあります。これは、ネットワークなどの設定や状況が影響するからです。

 たとえば、「システムの物理的な場所」を思い出していただきたいのですが、「お客様のオフィス」、「そこにあるサーバールーム」、「プライマリデータセンター」、「プライマリのプライベートクラウド」、「セカンダリーのプライベートクラウド」、「セカンダリーのデータセンター」など、さまざまな場所があると思います。これらが一部だけ壊れたり、機能不全になるわけです。

 ここからDRが機能するわけですが、これだけ違う場所に色々おいてあると、普通はIPアドレスはもちろん、ネットワークセグメントも違っていて、いろいろな理由で通信できない場合が出てきます。例えばこうした場合、同じネットワークセグメントを割り振ることで、回復が容易になります。例えば、サーバーの場所を移動したり、仮想マシンをDRサイトで起動しなおしたりするときも、シームレスにできたりします。

 当社のプライベートクラウドでは、オフィスにあるサーバー内の仮想マシンインスタンスをプライマリのプライベートクラウドや、地理的に離れた拠点にあるセカンダリーのプライベートクラウドに移動できたりします。

 ………と、一言でいうと簡単なのですが、それを実現するには、様々な技術の組み合わせが必要です。

 例えば、「JPクラウドコネクト」でお客様拠点をレイヤー2で接続し、「インターリージョナルファブリック」で関東/関西/中部という弊社が持つ3つのリージョン間をそれぞれ高速に接続する。ルーティングをUTMで行うために、ネットワークアプライアンスサービスがあったり、オフィスの拠点間接続をする。これらが東日本、西日本どちらかにしかないと、たとえサーバーがあっても接続ができませんよね。サーバーから様々なレイヤーのネットワークが統合しているから、できることです。

 そうしたネットワークやストレージの技術を全部織りなしているから、当社では「クラウドファブリック」という言い方をしています。

同社の「クラウドファブリック」

――DRはオプションサービスでしょうか、また、反応などはいかがでしょうか?

[瀧氏]ジャストプレイヤーの関東リージョン、関西リージョン、中部リージョンのうち、複数リージョンで何台か契約することで、DRのオプションが付いてくるという形です。

 また、反応は「安心できる」とよく言われます。例えば、今言ったような構造だと、天変地異だけでなく、設定ミスや操作ミス、ランサムウェアなど、論理障害によって特定サーバーがダウンしても、それだけをどこかで動かすことができればいいわけです。すべてのサーバーをDRサイトに移すには2倍の実行リソースが必要になるので、実行リソース=コストや手間の節約にもなります。


災害対策の「ありがちな問題」は企業の規模で違う大規模、中規模、小規模の企業では?

――DRやBCPで問題になりがちな「ありがちなこと」があると思います。実際の例として、どのようなことがあるでしょうか。

[瀧氏]そうですね。会社の規模を、大規模、中規模、小規模に分けて考えてみましょうか。

●大企業:経営層の「災害対策」と、現場の「災害対策」で意識が違う……

 まず大規模の企業では、一番多いのは経営層と現場のミスマッチですね。経営層は「災害対策できている」と思っているけど、現場はできていると実は思っていない。災害対策って、「こういう場合は対策できているけど、こういう場合は難しい」となりがちなのですが、経営側は「災害対策できている」と思う一方、現場は「こういう時はダメ」というのがわかっているので。社内のコミュニケーションがしっかりしていないと、見過ごされてしまうところだと思います。

 具体的には、「プライマリサイトのデータ量やデータ更新度と、DR側との間のデータ流量とかを見ると、トラフィックに耐えられるはずないよね」とか、「DR側のリソースがこんなに少ないはずはないよね」とか。そうすると、何か起きたときに苦労します。

 また、IT部門って、最小限の人数で運用されていることが多いんですよね。すると、何かあった場合、「IT部門がボトルネックになって、他の部門が待ちになる」ということが簡単に起きます。「設定が終わるまで待ってください」とか、よくありますよね? IT部門から見ると、「その設定は5分で終わるけど、ほかの仕事があるので3時間待ってて」という。DRやBCPを適用するような事態では、こういうことが起きがちですし、「実はそもそも恒常的にIT部門がボトルネックになっている」という会社さんも世の中多いように思います。

 余談ですが、僕はこの「IT部門がボトルネックになっている状態」は、会社にとって見えづらく、しかも大きなマイナスがあることだと思っています。昨今、様々な部署で人材不足が言われていて、個別の部署での「人材不足」は可視化されやすいのですが、実はIT部門に投資すれば、解決することも結構あるだろうな、と。

 IT部門の人を増やすのが難しいとしても、負荷を下げる機材・ソフトを買ったり、サービスを導入するなど、やり方はいろいろあるかと思います。

――大規模の企業の問題はどう解決すればよいでしょうか

[瀧氏]経営者はもっと現場の……情シスの人の言うことを聞いてもらえればと思います。情シスの人って、実は「言いにくい」と思っていることがいっぱいあるんですよね(苦笑

 でも、ITは企業の神経系統のようなものですから、それが詰まるとたいていロクでもないことが起きる。

 情シスの負荷を下げる投資の話も、これに関連します。工場で「クリティカルパスに投資しよう」というのと同じで、情シスに投資するとほかの部門が速くなる、というのは実はよくある話です。実際、我々のサービスも、情シスの方の負荷を下げられるように設計していますし、DRのオプションも、災害時の情シスの方々の負担を減らせるものと自負しています。

●中堅企業:パブリッククラウドが落ちた時、どうするか?

――続いて、中規模の企業はどうでしょうか

[瀧氏]中規模の企業は、成長中のところが多いので、パブリッククラウドを使うところも多いのですが、意外とそのパブリッククラウドが落ちることを想定している会社さんは少ないですね。

 現場では「落ちたらしかたない」と思っている場合も多いですが、経営層は「落ちない前提」で事業を作っていたりする。

 ただ、大手パブリッククラウドでも年に数回、障害を起こしていますから、障害の起き方や長さによっては「回復する手段がない」ということになる場合もあり得ます。

 ネットワークはまだ直れば元に戻りますが、ストレージ障害だとデータが元に戻らない可能性があります。「パブリッククラウドはバックアップをとっているから大丈夫」と思うかもしれませんが、実は、バックアップを取ってないパブリッククラウドもたくさんあります。また、そもそも「いつのスナップショットであればバックアップといえるのか?」という問題があります。適当なタイミングでとって、意味があるものなのか、わからない部分もあるわけなので。さらに、「どのトランザクションが失われるか」という問題もあります。

――中規模の企業の問題はどう解決すればよいでしょうか

[瀧氏]決定的な解決先はありませんが、障害が起きたときにどうするか、どう復元するかは意識する必要があります。

 パブリッククラウドのPaaSやSaaSのサービスが便利なので、うまく使って開発工数を削減するというのはありだと思います。ただ、ある段階で「ロックインされている」というのは意識する必要があると思います。たとえばマネージドデータベースは便利ですが、障害で落ちるだけならいいのですが、データが失われると取り戻せません。それをどう復元するか、復元できなくてもデータだけは担保するなど、どの程度までやるかを意識する必要があると思います。

 また、パブリッククラウドに頼る構造になっている以上、「パブリッククラウドが落ちた場合、ウチは何もできない」ということを、事前に経営陣と共有しておくのもリスク管理として良いでしょう。

●小企業:バックアップをどう復元するか?

――最後に、小規模の企業はどうでしょうか

[瀧氏]小規模の企業になると、予算の問題も大きくなりますから、「データをどこかに預けて終わり」になっている場合が多いですね。「最小のコスト・手間でなんらかの災害対策を」という観点ではいいと思うのですが、同期の頻度に問題があったり、「障害が起きた際、どうやってそこにアクセスするか」が検討できていない場合も多いように思います。

 データだけならともかく、システムをお持ちの場合は、障害が起きたときにバックアップから復元できないんじゃないか、という例が多いようにも思います。

――小規模の企業の問題はどう解決すればよいでしょうか

[瀧氏]小規模の企業の場合は難しいのですが、「どう復元するか」は一度は考えないといけません。単に通信回線だけの問題ではなく、同期の頻度が少なかったら「同期できていないデータをどうするか?」も考える必要がありますし、最終的に「どうやって日常業務に復帰するか」まで一度考えておくといいでしょう。

 ちなみに、弊社のプライベートクラウドのサービスは安くて大容量なので、ぜひ検討していただければと(笑。クラウドストレージのTeraCLOUDをバックアップに使ってもらっている例もあるようです。

復元の手順やトリアージをあらかじめ考えておく

――「復元を考えることが重要」という言葉が何度も出てきました

[瀧氏]災害対策は、どのようなサイズの企業でも、

1) どの時点までのデータを復元するか(RPO=Recovery Point Objective)
と、
2)どのぐらいの時間をかけて復元するか(RTO=Recovery Time Objective)
が重要です。

 DRを検討されていない会社さんですと、まず、RTOが「不明」になります。「バックアップからの復旧に想像以上に時間がかかった」という話も多く聞きますし、パブリッククラウドがいつ復旧するか、というのはその時次第です。

 RTOは、災害対策でとても重要で、単に「お客さんにお待ちいただく時間」というだけでなく、「復旧に時間をかけてでも正確さを重視するのか」あるいは「とにかくサービスを再開して停止時間を短くするのか」など、サービスの内容によって重視すべき点が変わってきます。「いざ!」という時に、事前に考えてあるのと、そうでないのとでは、大きな違いが出るのは想像してもらえると思います。

 また、実際の時間についても、大きな会社はデータが大きく、たとえば数十TBのデータがあると、転送もそう簡単に終わりません。コピー1つとっても、同一サイトで一晩かかる可能性があるわけです。それらが何個もあると、1つ1つ復旧して確認したら、何週間かかるんでしょう………というところです。また、それだけ長くなると最初と最後でタイムラグも出てきます。

 さらに、部門がたくさんあるような会社だと、情シスには「ウチのシステムはまだか!」というオファーがどんどん来て、対応に追わることになります。

 そのために最初にしておくことが、データ復元のためのトリアージ、優先順位づけです。事業としての重要度を考慮するのはもちろんですが、ITシステムとしての依存関係もあるわけなので、あらかじめ決めておく必要があります。ガッチリじゃなくても、なんとなく。

 最後に、復旧手順をきちんと作っておくことも重要です。大きな会社のシステムは、ソフトウェアのデプロイ(*1)まで業者が行っていることがあります。これをDRサイトで復旧するときに、ソフトのインストールしなおしが必要だったり、デプロイした業者への依頼が必要になったりします。災害時にそうした依頼を行うのって、結構厳しいですよ。こうした手順は、予行演習しておけば、スムーズに行くのですが、現実には「なかなか忙しくて………」ということも多いですね。

*1 インストールや設定を行って動作するようにすること

災害との向き合い方には段階がある

CAP定理の図
同社サイトにあるCAP定理の解説

――災害対策には障害規模や対策などについて、いくつかの段階があると思いますが、ジャストプレイヤーさんとしての考え方というのはありますでしょうか

[瀧氏]段階はいっぱいあります。

 データセンターの電源ロストや全コネクテビティロストもありますし、データセンターがつぶれることもあります。ちなみに、電源ロストは検索するとたまに起こっているようです。

 そしてそこからどうどう復元するか、が重要なのですが、結局、究極的にはCAP定理に行きつきますね。

 CAP定理とは、一貫性(C=Consitency)、可用性(A=Availability)、分断耐性(P=Partition-tolerance)の3つを同時に保証できないという定理で、少なくともどれか1つ、犠牲にする必要が出てきます。CAP定理と、そこから導き出される解については、弊社のサイトに詳しく書いたので、気になる方はぜひ参考にしていただければと思います。

 さて、これを現実に即してみると、例えばプライマリとセカンダリーを同期するとして、両者の距離が離れるほど同期に時間(レイテンシ)がかかります。なので、(データの一貫性を維持するためには)「大阪は大阪のサーバーをみて、東京は東京のサーバーをみる」という構成をすることは通常なく、どちらかをプライマリにする構成になるでしょう。

 そうした状況で、たとえばOracleデータベースを非同期的に同期するActive Data GuardとGSLB(Global Server Load Balancing、広域負荷分散)を使い、東京が壊れても、データベースのプライマリの切り替えで少し前のトランザクションに戻れるという構成も考えられます。

 「そこまでいかない、データベースの同期はゆっくりでいい、なにかあれば東か西に寄せる」というのも一つの解決法です。例えば1日1回とか。これだと、回線のコストを抑えることができるでしょう。

 いずれにせよ、2か所の離れた拠点を同時にうまく使うのが、われわれがご提案する方法です。そうした2拠点を使ったうえで、プライマリは仮想マシン4台、セカンダリーは3台など小さいセットにしておくと、コストも抑えることができたりします。セカンダリーでは必要なサーバーだけ動かすようにして規模を縮小するわけです。

 また、実際のDR構成では、東西で分けるより、セカンダリーをパブリッククラウドに置く構成が多いです。ただその場合、それを前提としたシステム改修が必要ですし、さきほど説明したように特定のサーバーだけ移すような使い方はしないほうがいいでしょう。

 そしてDRのいちばん最初の段階としては、ちゃんとバックアップとりましょう、リカバリする手段を考えましょうということになります。


まずは「2ヵ所に置いておく」ところから、はじめて欲しい

――デジタルデータの重要性が増す中、災害対策を気にする企業も増えていると思いますが、どのようなことを気にされている企業が多いのでしょうか?

[瀧氏]経営者目線では、台風、地震、洪水など、どれもみなさん気にされています。特に東京の会社は、3.11のときにけっこう揺れて警戒体制になったそうで、災害対策をしっかり考えている会社さんが比較的多いですね。

 一方、情シス目線では、論理破損をいちばん気にされています。作業のトラブルやランサムウェアなど、論理的な事故も大きなリスクです。RAIDをリビルドするたびに枕を高くして眠れない人がいます。そこで、いざというときに使えるバックアップや予備マシンが関西にあればなんとかなるかも、というわけです。

――最後にメッセージをお願いします

[瀧氏]DRやBCPは、考えることがいろいろあって、経験がないと考えるのが困難です。小さい会社では「考えるのも面倒」という人も多いかと思います。

 ですが、社会が変わっていく中で、「デジタルデータで仕事をする」側面はどんどん強くなっていますから、最小限でも考えてほしいと思っています。

 今回お話しさせていただいた内容も「結構難しい」と感じる方も多いと思いますが、まずは、「データやシステムを遠くにも置いておく」「(少なくとも)2ヵ所に置いておく」ということだけでも、はじめていただければと思います。例えば、オフィスとクラウドや、プライベートクラウドとパブリッククラウドのように。

 また、何か具体的なサービスをご検討されるのであれば、是非、弊社のサービスをご検討ください。

 我々は、3.11から10年間、何かあったときにどうするか、けっこう本気で考えてきましたし、相当な投資をしてきました。

 天災もそうですし、設定ミスのようなディザスターもけっこうあります。「本当に壊れたときしか使えない」DRも世の中には結構多いと思うのですが、我々は、もうすこしライトなところから使えるDRを目指し、提供できていると自負しています。弊社のサービスは、手軽なところでは、プライベートクラウドのサービスからありますので、まずはさわっていただき、それで理解していただければと思います。パブリッククラウドと同じように使えますし、固定料金なので使いすぎて高額になることもありません。

 我々としては、こうしたサービスから始めていただき、必要次第でDRやBCPの専門的なサービスも検討していただくことで、今後も起きうる災害に対して、みなさまのお力になれる、と考えていますので、よろしくお願いいたします。

――ありがとうございました

(協力:ジャストプレイヤー)