インタビュー
「“RAID全滅”があり得るように、“クラウドなら絶対安全”もない」、クラウド時代の「データ置き場の考え方」とは？
「クラウドがなぜ落ちるのか？」をテラクラウドに聞いてみた
2021年1月27日 06:55
テレワークをはじめ、クラウドの重要性が増している昨今だが、パブリッククラウドやデータセンターがダウンする障害が時折おきている。「ダウンしていてシステムが使えない」という経験をしている人も多いだろう。
しかし、「今、使えない」よりも、より深刻になる可能性があるのが、データの問題。ダウン前後のデータに不整合が生じたり、消えたりすると、データ確認のために、多数の利用者に問い合わせをする必要が出てきたり、データを諦めて信頼を失うことにもなりかねない。
もちろん、どの事業者も信頼性向上に力を入れているから、手元でデータを保管するよりは安全なはず。だが、それでも障害が発生しているのはなぜだろうか？「クラウドといっても絶対は無い。サービスは必ずダウンする理由があるのです」と警告するのが、テラクラウド株式会社（1月18日にジャストプレイヤー株式会社から社名変更）の代表取締役CEO兼CTOの瀧康史氏。
同社は、20年近くレンタルサーバーやプライベートクラウド事業を手掛け、災害対策などの物理障害やソフトウェアトラブルなどの論理障害にも経験が深い。そんな同社の視点で見ると、「例えばRAIDのような高信頼のストレージでも、確率論的に“RAID全滅”のようなトラブルが発生してしまうように、どんなクラウドでも“確率的にいつかトラブルが起きる”という本質は変わらない」「そして、クラウドは皆さんが思っているよりもよく落ちている」（同氏）という。
そんな同社が重要と考えるのは「クラウドを妄信せず、“データの内容・性質に基づいて置き場所を考えること”」。そこで、そんな同氏に「データの置き場所」や「設計に関する考え方」などを聞いてみた。
パブリッククラウドは「落ちるもの」電源、回線、性能不足など、理由はさまざま
――最近、パブリッククラウドが落ちるニュースが多いように思いますが、これってこういうものなのでしょうか。
[瀧氏]そうですね。最近は、パブリッククラウドが落ちる話をよく聞きます。
背景としては、テレワークなどでクラウドが注目されたり、負荷が高くなった側面もあるのですが、実は、その前から一定程度落ちています。言ってしまえば、パブリッククラウドといっても、「AmazonやGoogle、Microsoftがやっているデータセンター」ではあるわけで、データセンターに障害があれば、クラウドサービスも当然落ちます。
「頻度がどの程度なのか」というのは、あまり明言しにくいのですが、コロナ禍の前の話として「年に数回、どこかは落ちる」といったイメージです。大小さまざまな事業者で、メジャーなところも、何かに特化したところも落ちていますし、障害規模も大きなものから小さなものまで、色々です。
事例をお探しでしたら、サービス名と「障害」で検索していただければ、なんとなくのイメージはつかめると思います。
――意外と見えない部分ですね。原因はどういうものなのでしょうか？
[瀧氏]そうですね……。結局、「各社がやっているデータセンター」なので、理由は色々ですね。
例えば、大規模障害になりやすいのは、データセンターの電源障害です。これは、どうしても復旧が難しく、時間がかかります。もちろん、良いデータセンターは2つの電源会社から電力の供給をうけ、自家発電装置や巨大なUPS（的なもの）など、様々な方法で電源冗長を図っています。しかし、それでも問題が起きてしまう事は時にありますし、電源で問題が起きてしまうと、どうしても復旧に時間がかかりがちです。
また、データセンターの引き込み回線に障害が起きることもあります。物理的な回線障害もあれば、回線すべてが輻輳することもありますし、外部と接続するルーターなどの設定ミスで論理的な障害になる、ということも実際に起きています。
小さな障害は、性能不足でシステムが正常動作せず、そのまま齟齬が発生してしまうとか、設定ミスなどのオペレーションミスが多いと思います。ただ、この前も認証システムのQuotaの問題で大規模クラウドがダウンしていましたし、「小さな障害」と言えない問題になることもあります。
サービス形態で見ると、メールなどのアプリケーションまで提供するSaaSのシステムでは、いろいろな要素がシステムに影響し、複雑になります。一見、小さな問題なのに、システムの様々な部分とぶつかって、結果、システム障害になってしまう、というのもよくあります。
このほか「本番環境でしか起きない問題」もあります。本番とまったく同じ負荷を作るのは実験環境ではできないので、いくら負荷テストをしても見つからないのです。そして、実験環境では設定値が正しいように見えても、実際に本番投入すると、ネットワークではトラフィックの、ストレージではI/Oの量が全然違うので、「その設定じゃだめだった」というがしばしば起きていたりします。
これは弊社の例ですが、最近、TeraCLOUDストレージサービスの新機能として、フォルダ共有機能をリリースした際、事前に想定していたアクセスパターンとは違うパターンで大きくアクセスが増えまして、繋がりにくい事象が発生していました。しかも、データベースへのアクセス量がリリース前の数倍、というレベルで注目がありまして。増えることは予測していましたが、それが想定以上だったため、飽和してしまったのです。まあ、平たく言うと、とあるノードが「暫く落ちた」んですが。
また、全然違う話ですが、とあるデータセンターの話で「新型コロナの感染者が出たため、利用企業がサーバールームに（一時的に）入室できなくなった」といった事例を聞きました。世の中、何があるかわからないものです。
「データの安全」をどう維持するか？ただし、一挙に解決できる「銀の弾丸」はない
――なるほど………では、たとえば、データセンター自体の障害を避けるために、リージョンやゾーンを分ければ回避できるのではないでしょうか
[瀧氏]そうですね、複数のデータセンターを使い分けてリージョンやゾーンを分けるのは一定の効果があると思います。
「関東と関西」とか「アメリカと日本」とかで分ければ、安定して使える可能性はありますし、マルチリージョンにすればいいのにという意見もよくあります。
すると今度は「データをどう分散するか」を設計する必要が出てきます。そして、ここで考慮すべきは、ソフトウェアやオペレーションが起因する障害ですね。
複数のリージョンやゾーンを束ねるシステムがあっても、そのシステムにバグがあったら目もあてられない。操作ミスで「マルチリージョンすべてに対してデリートを実行してしまいました」とか。これはリージョンやゾーンを分けても回避できないので、これに対応するには、使っているOSとかミドルウェアとか、それこそクラウド自体をわけないといけないことになってしまう。すると、「どうやって同じデータを保存するか」という問題になります。
たとえばハードディスクをミラーリングし、2つのディスクに同時に書き込めば冗長化されます。こうした形になるのが安全性としてはベストですが、現在、「マルチクラウド」や「ハイブリッドクラウド」と言われる際は、「それぞれ得意とする機能を使う」という話になりがちで、そうすると結局、両クラウドの機能をそれぞれ使うことになり、「両方のクラウドがないとサービスが提供されない」という、いわばストライピングのような状態になっていることが多いように思います。
いずれにせよ、複数のクラウドに同一のデータを持つことができれば安全になりますが、それを実現するのはとても難しい状態だと思います。
――たとえば1つのクラウドをメインにして、別のクラウドにバックアップでデータを保存するという方法はいかがでしょうか
[瀧氏]それはいい方法だと思います。ただ、そこで出てくるのがRPO（Recovery Point Objective、目標復旧時点）とRTO（Recovery Time Objective、目標復旧時間）の問題です。
RPOは、1日1回とか1時間1回とか、定期的にバックアップを取って、障害が起きてもそこまで戻れるということです。これはみな考えていると思います。
ただし実際にバックアップからリカバリをするときには、どのぐらいの時間でリカバリできるかというRTOも問題になります。数十TBのクラスとなると、リカバリにも数日から数週かかるケースも多くなります。
現実の作業を考えると、数十TBのデータをリストアするときには、当然、リカバリー時のデータ整合性チェックも走るじゃないですか。これは結構遅いです。結果、うっかりすると、本気で「全社業務システム」が1週間とか2週間とか、1ヶ月とかとまるわけです。すると株価は下がるし、毎日、色んな部署の人達からいつ治るのか？あるいは僕らのデータは本当に戻ってくるのか？という質問が来るわけです。データが無いとコンピュータが使えないので、そうすると「1からやり直そう」という人が出てきたり、経営層が事業転換まで考えはじめたり………、まぁ、色々おきてきます。いや、胃が痛くなるからこの話はやめましょう、僕も経営者なので（苦笑
また、サーバなどのインフラだけをクラウドで使うIaaS（Infrastructure as a Service）を利用し、アプリケーションは自分たちで動かしているのならバックアップもとりやすいですが、PaaSやSaaSなどのデータになると困難が増えますよね。
たとえば、「マネージドデータベースに障害があったとき、ほかのクラウドで動かし続けることができるか」というと、けっこう大変ですし、SaaSを使っていると、バックアップは難しい。そうしたデータをどうするか、考えないといけないと思っています。
――パブリッククラウド事業者がバックアップを取っていたりはしないでしょうか
[瀧氏]バックアップを取るということは、リカバリ時に必ず巻戻る、つまりデータロスが発生すると言うことですよね？ リカバリによって障害が起こることもあるので、「利用者に断りなく勝手にリカバリできない」という状況だったりします。
例えば、これはオンプレミスで知られている過去の事例ですが、とあるクレジットカード会社で、RAID6のディスク3本に同時に障害が起き、請求データの一部が消えたということがありました。その例では、バックアップからリカバリしたのですが、バックアップはある時点のデータでしかないわけです。バックアップ作成時より後で支払われていたために、二重請求になってしまったり、逆に請求漏れになってしまったりしたということがありました。
利用者が多いのに、そのような話を聞かないのは、そういうことかな、とは思っています。
――ほかのクラウドやリージョンにレプリケーション（複製）する場合はどうでしょうか
[瀧氏]ディスクのミラーと同じように、クラウドでも2箇所に書き込むことで、データを冗長化できます。ただし、データの整合性を取って完全性を保つには、遅いほうの応答を待ってから処理を完了とみなします。そうすると、書き込む速度が遅くなってしまいます。
もし遅い方を待たないようにすると、途中でメインシステムが止まることにより、データの一貫性は崩れてしまいます。ですからデータの一貫性が必要なシステムでは、このような方法は使われません。
一方、分散KVS系ストレージで、データを緩く伝搬するアーキテクチャの場合、反応が早くできるかわりに、非同期でデータが転送されるため、データを受け取ったノードが転送前に不幸にも壊れると、そのデータは必ず欠損します。このように特性が変わってきますから、自分が使用しているインフラがどういうアーキテクチャで作られているのか、知っておいたほうがいいと思います。
いずれにしても、クラウドだからデータが安全ということはなくて、データが失われる可能性はあります。会社によっては、データが消えると会社がつぶれるほどのインシデントとなります。情シスの人間は、そこまで責任をとることはできませんから、自分の仕事の範囲として「データの保管方法をきちんと考える」ことが大事だと思うのです。
いずれにせよ、データの問題は、一挙解決できる「銀の弾丸」はないのが実際のところです。
大事なことは「データの内容や性質にあわせ、しっかり設計すること」
――なかなか難しいですね。では、「どうすればよい」と考えられているのでしょうか？
[瀧氏]そうですね。まず、一番重要なのは「データの重要性やその置き場所」をしっかり考えることだと思っています。
どういうデータは「どうしても守る必要がある」もので、どのデータは「そこまででもない」ものなのか。ここまでは考えやすいでしょうけれど、実際は、「時系列で考えて、1秒たりとも失ってはいけない」のか、それとも「最悪どのぐらい巻戻ってもいい」のか。
たとえば、月次処理が終わったところでデータを固めておけば、来月まで更新がほとんど無いシステムもあるでしょう。それぞれで最適な考え方は変わると思います。
弊社もクラウドサービスをしている会社ですから、お客様の作りたいシステムの内容を聞いて、一緒に考えて設計をしたりしています。
弊社の話はひとまず置いておいて、論点を先にご提示したいのですが、たとえば、クラウドを使う際、1つのクラウドにまとめることはよくあります。しかし、その環境でデータロスが発生すると不幸な事故がおきる可能性もあります。
どこまで責任を持てるのか明確にしておく必要があるんじゃないかと思います。データがどう保存されているか、レプリケーションされているかなど、システムを運用する人間が契約する段階で意識する必要があると思います。クラウドを盲信しないということも含めて。
そうしたことをいろいろ考慮した結果、アメリカのグローバル企業では、制御のしやすいオンプレミスと、ある程度ダウンすることも覚悟した部分をクラウドとして利用するのを組み合わせるようになっていると思います。
たとえばBIで、元データがオンプレミスに存在して、そのデータをクラウドのBIに流すということになっていれば、めったにあることではありませんが最悪クラウドのデータが失われても、元データから復元すれば会社が傾くことにはならないだろうと。
そのクラウドが飛んだときに自分の会社に何が起きるかを考えてシステムを選定するのがいるんじゃないかと思います。SaaSのアプリケーションはとても便利ですが、「データが飛んだらどうなるんだろう」という視点ですね。
――SaaSだと、マルチクラウドで対策するといったことも難しいですよね
[瀧氏]対策できないですよね。マルチクラウドにするのは相当難しい。あるアプリケーションをSaaSで使っていて、何かあったときには、同じカテゴリーの別のアプリケーションを使うかというと、現実的ではない。両方にデータを同時に入力することはできないので。
それを避けるとすると、自分のところでソフトを買って、自分の管理できるオンプレミスでやるしかないかもしれないですね。
――SaaSの事業者はバックアップを取っているものでしょうか？
[瀧氏]「とってない」ということはないでしょうけど、リアルタイムに近いバックアップを取るのは相当難しいと思います。
もちろんサービスにもよる部分はありますが、ある程度とっていたとしても、リカバリ時の不整合の問題をどう解決するか、という問題が出てきます。もしも何かのミス、たとえば利用者側の運用ミス、事業者の過失、あるいは契約上の問題などでクラウドのデータが消えた場合、何をすればどこまで復元できるかなど、情シスは確認しておかなくてはならないでしょう。
たとえば「月1でデータをダンプしておき、それを保存しておけば、何かあってもそこまでは戻れるだろう」というようにです。
ただ、さきほどのBIの例のように、元データが手元にあれば「何かあっても会社が傾くことはないだろう」と考えることはできます。「これがなくなったら会社が飛ぶ」というデータは、何らかの方法で復元できる手段を、SaaSでも考えておかないと危険な気がします。
ほとんどのクラウドでは約款に、「データが飛んでも責任は持てません」と書いてあったり、せいぜい、使えなくなった時間の利用料金を返金するぐらいしか書いていないでしょう。また、訴訟をするにしても、訴訟は何年、何ヶ月とかかかるので、それを待っていられない、というのも現実問題として起きてきます。
ですので、会社の生命線となるデータは「いざというときにどうするか」を考えておく必要があるでしょう。
「これは数日以内には復元しないといけない」とか、「すぐに復元するのは無理だが何ヶ月後には」とか、「復元をあきらめる」とか、位置づけがあるじゃないですか。最後にどこに落とすかという落としどころが設計では必要になります。
実は最近、弊社も基幹システムをリプレースしようとしているところで、「クラウド屋がクラウド屋を信用しなくてどうする！」っていう意識のもと、クラウドを検討しているのですが、なかなか難しくて。
同業である以上「絶対はない」というのを知っているので、「せめて、月次のまとめでデータをダンプする機能がクラウド型のSaaSにも欲しいなぁ………」と思うんですよね。それさえ手元に残しておけば、大障害が起きても、いざシステムが復旧したらリストアしたときに戻せるじゃないですか。
でも、そういう「障害が起きた場合の対策」が視野に入っているサービスはあまり無いんですよね。
――なるほど……SaaSは難しいとして、クラウドでサーバを使うとか、ストレージを使う場合はどうしたら良いでしょうか？
[瀧氏]そうですね。
弊社では、ハイブリッドクラウドを提案しています。
例えば、弊社がご提案する場合は、データの重要性や性質に合わせて、適切な扱い方や置き場所を一緒に考えて提案させていただくことが多いのですが、大まかに2つのハイブリッドクラウドがあると考えています。
1つは、パブリッククラウドとプライベートクラウドの組み合わせ、もう1つはオンプレとプライベートクラウドの組み合わせです。
まず、パブリッククラウドとプライベートクラウドの組み合わせですが、パブリッククラウドには便利な機能が多々あり、日進月歩で進んでいますから、使えるところは意欲的に使っていきたい気持ちは良く理解できます。そして、データの分散を考えると、2ヵ所にデータを保存するパブリッククラウド＋プライベートクラウドの組み合わせは合理的ですし、パブリッククラウドはどうしてもコストが高くなりがちなので、そのコストダウンにも大きな効果があります。
また、今までオンプレを中心としたお客様には、オンプレミス＋プライベートクラウドにどうしてもフォーカスが当たります。パブリッククラウドのSaaS機能は強力なものもありますから、データのタイプによっては、オンプレミス＋プライベートクラウド＋パブリッククラウドなどの提案をする事もあります。
何かの問題でデータが失われる可能性は、どんなシステムでもゼロではないと考えています。ですから、データをどう保持するかだけでなく、データの更新頻度などを考えて、運用プランを考える必要があります。ただ、その「重要性や性質に関する考え方」は、やはりデータや災害対策のプロでないと難しい部分があるので、そこはお手伝いさせていただく、という基本姿勢です。
我々はプライベートクラウドをオンプレミスのように貸し出すことができる会社です。パブリッククラウドのようなインスタンスタイプの貸出もしています。多くのクラウド事業者と同じように、マルチリージョン、弊社では関東、中部、関西があって、それぞれをうまく組み合わせ、定期的にデータを同期する仕組みを提供していたりもします。
しかし、そのように運用していたとしても、たとえばレプリケーションソフトウェアや、分散データベースのソフトウェアにバグがある可能性は否定できないですから、クラウド業者の提供するソリューションに絶対はないのです。
「クラウドは完璧」ではないからこそ、「データの置き場」を考えてほしい4つのキーポイント
――最後に一言お願いします
[瀧氏]テラクラウドでも、大手のAmazonでも、Googleでも、Microsoftでも、みんなお客様のデータを守ろうとしているけれど、失うときは失ってしまう。残念ながら、クラウドベンダーが銀の弾丸を持っているわけではないのです。
例えば過去、RAIDのような高信頼のストレージが普及して「これで安心だ」と思った時代もありましたが、それが広く普及した現在では「RAIDが全滅した」という話も時々聞くようになってしまいました。とても低い確率だとしても、起きる可能性があるものはいつか起きてしまいますし、世間で普及してくればなおさらです。そして、今回お話させていただいたように、クラウドは皆さんが思っているよりは完璧ではないのです。
つまり、自分がいつ、”ハズレくじ”を引いても大丈夫なようにしないとなりません。
ですから「データをどこに置き、どうレプリケーションし、どうバックアップし、どうリカバリするか」は、ストーリーとして1本立てておかなくてはいけない。最近は、コロナ禍でのテレワークやクラウド各社のトラブルなど、話題がどうしても増えました。また、ちょうど東日本大震災から10年の年でもあるので、「大きなインシデントが起きたときにどうなるか」を意識していただきやすいと思います。
最後になりますが、こうしたことを考える際は、4つのキーポイントを考えていただくと良いと思っています。
1. データの重要性、更新頻度を考えて、置き場を考える。
2. データは複数の場所に置く。1つのクラウドだけに置かない。
3. メインサイト(クラウド)が壊れた時のリカバリ方法やリカバリタイム(RTO)を想定しておく。
4. データを失ったとき、どのようなインパクトがあるかは、社内で十分、コンセンサスを取っておく。
こうしたことを考えられた結果、弊社をご利用いただければとてもありがたいですが、そうでなかったとしても「クラウドが本当に全盛になった今、“データの置き場所をどう設計するか”」について、考えるきっかけになれば幸いだと思います。
――ありがとうございました。
（協力：テラクラウド）