ニコニコ及びKADOKAWAのシステム障害に関する雑感(2024年6月13日)
2024年6月、ニコニコ動画などのWebコンテンツの配信サービスを提供しているニコニコがサービス停止した。
今回の記事はニコニコと、関連するKADOKAWAで発生したシステム障害に関する雑感である。なお私はニコニコ及びKADOKAWAの関係者ではなく、ニコニコのプレミアム会員である1エンドユーザーに過ぎない。また今回の記事を最後まで読んでも、現在発生しているシステム障害の解決策や改善策がわかるわけでもない。創作と同様の類の読み物だと思って読み進めてもらえれば幸いである。
今回の記事の概要
ニコニコの運営が公式ウェブサイトでニコニコのサービス利用者に向けて「当社サービスへのサイバー攻撃に関するご報告とお詫び」を対外的にリリースしているが、今回の障害においては運営はどちらかというと顧客・利用者側であり、障害の被害者側である、ということをIT業界の構造を踏まえて紹介する。
IT業界の外の世界に暮らす人や、これからIT業界に進もうと志している人の参考になればと思ってまとめたのが今回の記事である。
今回発生したシステム障害とは
今回の記事の執筆のきっかけとなったのは、2024年6月14日15時にリリースされた「当社サービスへのサイバー攻撃に関するご報告とお詫び」である。
この報告内容によると2024年6月14日15時時点で判明しているのは以下の通りである。
・ニコニコを運営する株式会社ドワンゴが所属するKADOKAWAグループでは、自社データセンターで稼働するプライベートクラウドと、パブリッククラウドを組み合わせたハイブリッドクラウドでインフラを構築している。
・今回のシステム障害はプライベートクラウドでランサムウェアの被害に遭い、サービスが稼働している仮想マシンが暗号化されて使用できなくなった。
・ニコニコ動画のデータはパブリッククラウドにあるためロストしていない。
プライベートクラウド、パブリッククラウド、ハイブリッドクラウドについて知らない方にざっくりイメージを言うと、自社で購入して電源入れて動かしているパソコンと、インターネット上で借用手続きしてインターネット上でのみ利用できるファイル置き場を組み合わせて使っている、という感じである。こんな例えをするとIT業界関係者から「パソコンじゃない、物理サーバ上に構築した仮想マシンだ」「ファイル置き場じゃない、仮想マシンだ」とかお叱りを受けるだろうが、すごくざっくりとした言い回しだということでご容赦いただきたい。
KADOKAWAグループのプライベートクラウド
さて上記報告によるとニコニコのサービス自体の不具合というより、サービスが稼働しているKADOKAWAグループのプライベートクラウドに問題が起きて、プライベートクラウドに乗っかっているニコニコのサービスが影響を受けた、というのが適切だと思われる。
ここで「KADOKAWA プライベートクラウド」でググってみると検索結果上位に株式会社 KADOKAWA CONNECTEDというキーワードが出てくる。事業紹介によるとKADOKAWAグループのクラウドサービスの開発・運用を担当している企業らしい。
おそらくはこの株式会社 KADOKAWA CONNECTEDが、今回のKADOKAWAグループのプライベートクラウドに係るキーマンと思われる。
KADOKAWAグループとランサムウェア
https://x.com/youhei_red/status/1801555248726921379
前述の「当社サービスへのサイバー攻撃に関するご報告とお詫び」によるとプライベートクラウドでランサムウェアの被害に遭ったとのことなので「KADOKAWA CONNECTED ランサムウェア」でググってみると検索結果上位に株式会社 KADOKAWA CONNECTEDでRubrikを導入したというノックス株式会社の事例が出てくる。この事例を読むと「ランサムウェア対策にも有効」と記載があり、また事例は2021年10月の取材内容をもとにしたとのこと。Rubrikの詳細は後述するが、IT機器は運用開始後に致命的な不具合がなければ3~5年間は使い続けるのが一般的で、それ以降は同等機能を持つ後継機種にリプレースすることが常である。2024年6月時点ではランサムウェア対策にも有効なRubrikが稼働しているものと思われるが、対策をとっているのならば容易に復旧できるのでは、という疑問が残る。その疑問についてのフォローを後述する。
IT業界のサプライチェーン
前述のRubrikについて触れる前に予備知識として、ニコニコのサービスを含めて一般的にWebサービスと呼ばれるものが、私を含めたサービス会員にどのように提供されているのかをまとめた図を紹介する。今回の記事の執筆にあたりPowerPointで描いた、IT業界でおなじみのポンチ絵と呼ばれる類の図である。
すごくざっくり紹介すると、ニコニコなどのWebサービスが提供されるバックボーンには
・メーカー(サーバーやソフトウェアなどのIT製品を開発する企業や部署)
・サプライヤー(メーカーからIT製品を仕入れて、その製品を活用することでどんなメリットが得られるかをソリューションとしてインフラエンジニアに提案する企業や部署)
・インフラエンジニア(サプライヤーから提供されたソリューションを組み合わせて、高性能(処理にかかる時間が短い)で、堅牢(セキュリティ対策が充分)で、低コスト(IT製品の購入および運用にかかる金額が少ない)なシステムを設計、構築、運用する企業や部署)
・サービスエンジニア(インフラエンジニアから提供されたシステム上で稼働するWebサービスを設計、構築、運用する企業や部署)
・エンドユーザー(Webサービスのアカウント登録したり課金したりして利用する個人や法人)
の5層構造が形成されている。
そして上記の図で矢印でつながった間でのみ商取引(金銭や物品の授受)が発生し、基本的には矢印でつながっていない間でやりとりが発生することはほとんどない。
なお実際には図でいうところのメーカーの左側に、さらに部品(サーバーのガワだとかネジだとかCPUだとか)を提供する部品メーカーがいたり、システムの運用を請け負う保守部門がいたり、メーカーに資金援助するベンチャーキャピタルがいたり、という具合で状況は複雑である。今回はだいぶ簡略化した図を用いている。
前述のノックス株式会社の事例をあてはめると下記のような感じである。
メーカー:Rubrik社
サプライヤー:ノックス株式会社
インフラエンジニア:KADOKAWAグループのプライベートクラウドを運営する株式会社 KADOKAWA CONNECTED
サービスエンジニア:ニコニコを運営する株式会社ドワンゴ
エンドユーザー:ニコニコの会員(私を含む)
ニコニコの会員はもし関係者と話す機会があるとしても、せいぜい株式会社ドワンゴの関係者だけだろう。Rubrik社の社員から「お世話になってます」と言われても、誰やあんたって話である。
今回はKADOKAWAグループのプライベートクラウドのランサムウェア被害が原因のようなので、責任分界点としてはインフラエンジニアの管轄で、ニコニコを運営する株式会社ドワンゴはインフラエンジニアの顧客、いわば被害者側に該当すると思われる。これが冒頭の「今回の記事の概要」で触れた話題である。でも対外的(エンドユーザー向け)にはサービスを管轄する株式会社ドワンゴの社名を掲げて「ニコニコのサービスが停止してすみません」とお詫びを出さなければならない、俺ら被害者なのになんで頭下げとるんや、というのは社会の構造が生み出した悲しき不条理である。
なおIT業界のサプライチェーンと銘打って上記の5層構造を紹介したが、似たような構造はIT業界に限らず日常生活にごく普通に存在する。ビール会社の営業マンがスーパーマーケットでレジ打ちすることはないし、自家用車を買うにしても車をつくっている工場には行かず、最寄りのディーラーへ行くだろう。メーカーが自社製品をワールドワイドに拡販しようと思ったら、世界各地のサプライヤーに協力を仰ぐのはどの業界でもごく自然なことである。
またこれからIT業界に足を踏み入れようと志している人は、IT業界のエンジニアといっても様々で、個々人の有するスキルに応じてどの階層で働くのが向いているかは異なるのだ、というのを念頭に置いていただきたい。パソコンを分解したり機械いじりをするのが趣味であればメーカーが向いているし、UNIX/Linuxのコマンドやスクリプトに詳しければインフラエンジニア、ブラウザゲームを開発したりするのが趣味であればサービスエンジニア、という具合で個々人で変わってくるのだ。また手を動かすより見知らぬ人とおしゃべりして喜んでもらうのが好きだということであれば、どこかの階層の営業マンとして働く選択肢もある。
Rubrikとは
ノックス株式会社の事例に出てきたRubrikに話を戻そう。まずメーカーであるRubrik社の公式ウェブサイトを紹介する。
続いてサプライヤーであるノックス株式会社の公式ウェブサイトを。
検索してみたらRubrikのサプライヤーはノックス株式会社の他に富士ソフトやネットワールドも該当するようだ。
さてではRubrikがなにものかというとデータバックアップに特化した製品(アプライアンス)の製品名およびメーカーの企業名である。海外のメーカーには製品名をそのまま企業名にしている企業が多く、Rubrikもその中の1社である。
Rubrikはざっくり言うと下記2つを組み合わせたような製品である。
・ものすごく容量の大きなデータを効率よく圧縮して保管するストレージ
・上記ストレージに手動もしくは自動で、業務で使っているデータを格納するソフトウェア
仕掛けは単純で、大きなバケツと、バケツに物を放り込む機能があって、バケツに放り込んだものをぎっちぎちに押し込んで、入れた物を必要に応じて取り出して活用しましょうね、というだけのことである。大枠はそんな感じで、あとは細かい処理で競合メーカーと差別化を図っているのである。
実はこのような製品はRubrikだけでなく、日本国内のサーバーやストレージをラインナップに揃えているようなメーカー企業であれば、どこも似たようなものを商品として扱っている。上記の通り細かい処理を省いて仕掛けをざっくり言うと単純で製品化しやすいからである。
このような製品を導入するとどんなメリットがあるかというと、業務のデータ(たとえばニコニコ動画の動画ファイルとか、ニコニコのサービスで稼働する仮想マシンとか)をデータ作成直後や毎日定刻にバックアップして、業務のデータが壊れて使い物にならなくなったときに、バックアップしたものを使って復元できる、というメリットがある。バックアップしたものは業務のデータが壊れない限り使われることはないので、その置き場所の確保・運用にかかるコストをなるべく抑えるようにストレージ内で容量を圧縮して保管しますよ、低コストで障害対策できてハッピーですね、というのがこの手の製品の謳い文句である。このような商品のメーカーやサプライヤーのウェブサイトではデータ保護だのデータ利活用だのどーだすごいだろとばかりにかっこよくアピールしているが、要はある時点の業務のデータを本体とは別のところに保管するのでそれを使えば役に立つことがあると思いますよ、というだけの話である。
そしてRubrikをはじめ、このような製品はランサムウェア対策に使えるとアピールしている。これも単純な話で、業務のデータなり仮想マシンなりがランサムウェアで暗号化されて使えなくなっちゃったら、過去にバックアップしておいた暗号化されてないデータをRubrikから取り出して、業務のデータを上書きしてサービス復旧すればいいでしょ、というだけの話である。理論上はその通りだけど実際にサービス復旧できるかは実機でテストしてみないと保証できないだろーが、絵空事の綺麗事並べて悦に入ってるんじゃねーぞ、テストに要するコストもメーカーとサプライヤーが負担しやがれこんちくしょー、というのがインフラエンジニアとサービスエンジニアの決して表に出ない愚痴である。
余談だがRubrikに限らず、海外メーカー発の製品はメーカーの公式ウェブサイトを見るよりサプライヤーの公式ウェブサイトを見た方がどんな製品なのか理解しやすい。海外メーカーの中には製品がどでかいハードウェアなのかサーバー上で動作するソフトウェアなのかもはっきりせず、理想論や夢物語を並べて「弊社製品が著名な◯◯社様に導入されました!」「ベンチャーキャピタルから◯◯ドル調達しました!」「ガートナーのマジック・クアドラントでリーダーに選ばれました!今後も弊社は業界のトップリーダーとしてどーたらこーたら、今後も弊社は飛躍的に伸びるぞどーだすごいだろえっへん」という感じの企業もあり、それこそ絵空事の綺麗事並べて悦に入ってるんじゃねーぞ、と愚痴りたくなることもある。御社の業績を飛躍的に伸ばすソリューション、とか銘打っていざ実物を見てみたらLinuxサーバーとbashスクリプトの詰め合わせでした、なんてこともありうるのでIT業界は魔境である。
対策とってるなら復旧すればいいじゃない
さて実際のところ、KADOKAWAグループのプライベートクラウドは私からすればブラックボックスなので詳細は不明だが、ランサムウェア対策に使えるRubrikを運用してるならそこから復旧すればいいじゃない、という話である。この話についてもフォローを入れておこう。
インフラエンジニアの現場でよくある会話である。
A「◯◯システムが✕✕の被害を受けて停止しました。どうします?」
B「あらかじめ✕✕のリスク対策として△△を導入していたでしょ?だったら△△を使って◇◇すればいいじゃない」
この会話自体はせいぜい1分もかからず終わったとしても、この◇◇を実機でやるには数日から数週間、1ヶ月以上かかることもあるよ、とフォローを入れておく。
上記会話のBの立場になったことがある人からすれば、
なんで?方針は明確じゃん。遅すぎじゃね?
と思われるかもしれないが、たいていこの手の会話の◇◇に入るものは方針や全体像の概略に過ぎない。ぶっちゃけシステム運用を担当してシステムの全体像を把握している者であれば◇◇に入るものなんて容易に想像がつくのである。
実機、それも業務データがある本番系業務システムに手を加えるとなると下記を考慮しなければならない。
・◇◇を実現するためのIT機器固有の詳細な操作方法、コマンド1つ1つの粒度にまで落とし込んだ手順を確立しなければならない。その手順はシステム統括責任者をはじめ、誰が見ても誤りがないことが明確でなければならない。
・現状の被害をさらに拡大させることは絶対にあってはならない。
・失敗は許されない。もし失敗したとしてもシステムに手を加える前段階に即座に切り戻しができなければならない。
要は現状から更に悪化したら被害の補償額が莫大になったり顧客から訴訟を起こされたりする恐れがあるから、一般家庭に置いてあるパソコンみたいに挙動が怪しいのでケーブル抜いたり再起動したりします、なんて軽はずみにできないのである。
なので現場の最前線ではどうするかというと、コマンド1つ1つの粒度にまで落とし込んだ手順書を作成して、疑似障害を起こしたテスト環境で想定通りの動作するか確認してエビデンスを採取し、品質を磨き上げるために有識者を交えて手順書をレビューして、システム統括責任者に説明して「絶対大丈夫だよね?」と釘を差されても涼しい顔でかわして承認を得て、インフラエンジニアは該当システムに載っているWebサービスのサービスエンジニア全員に「この日時に復旧作業するのでサービスが正常動作するか確認してちょ」と協力を仰ぎ、関係者全員の合意を得てようやくシステムに触る、という具合なのである。必要に応じて事前・事後にエンドユーザー向けのプレスリリースを出すためのコストが必要になったりもする。まあコスト云々はおいといて、なんとなく1日程度じゃ終わらないだろうな、という空気感が伝われば幸いである。
2024年6月15日加筆:さらにフォローしてみる
今回の記事を執筆後、Rubrikがあってもすべての仮想マシンをランサムウェア対策しているとは限らない、という可能性もあるなと。
つまるところクラウドは形があって場所を取るハードウェア(サーバー、ハードディスク、バックアップ装置及びバックアップソフト、など)をインターネット上の仮想的な機器(仮想マシン、ストレージ、バックアップサービス)に置き換えたに過ぎないので、KADOKAWAのプライベートクラウドのサービスメニューはわからないが、仮想マシンを運用してもランサムウェア対策はしないような構成をとる、という選択肢もあるのではないかと。
具体的には、インフラエンジニアからサービスエンジニア向けに、以下のようなサービスメニューが用意されている可能性があるのでは、という話である。
仮想マシン1台1ヶ月◯万円
CPU増設◯万円(別料金のオプション)
メモリ増設◯万円(別料金のオプション)
ストレージ増設◯万円(別料金のオプション)
バックアップサービス(別料金のオプション)
仮想マシンのクラスタリングサービス(別料金のオプション)
仮想マシンのBC/DRサービス(別料金のオプション)
要はハードウェアでいうところのサーバーは構築するけどバックアップはしない、というのがオプションで選べるようなメニューで、オプションのバックアップサービスを有効にすればRubrikなどにバックアップしてランサムウェア対策ができる、という構成である。
今回の記事では「インフラエンジニアの責任範囲での不具合でサービスエンジニアは被害者」という論調で進めてきたが、もし上記のようなメニューが用意されているのであれば話は変わってくる。というのもこのメニューだとインフラエンジニアは充分なランサムウェア対策を用意していたことになり、それを別料金を払って利用するかどうかはサービスエンジニアの判断に委ねられることになるからだ。
一般的にクラウドサービスではインフラエンジニアはサービスエンジニアからの様々な要望に応えられるように豊富な構成パターンを組めるサービスメニューを用意し、サービスエンジニアはWebサービスの特性に合致する構成を選定する、という責任分界点になる。インフラエンジニアの言い分としては「ランサムウェア対策したければオプションメニューを用意するけど、追加料金を払ってそれを使うかどうかはサービスエンジニア次第」というのが成り立つのだ。
という感じで可能性の1つを書いてインフラエンジニアをフォローしてみたが、実際のところKADOKAWAのプライベートクラウドがどんなサービスメニューなのかわからないので、あくまで可能性の1つとして語るに留めておく。
最後に
以上、長々と駄文を並べたが、ニコニコ及びKADOKAWAのシステム障害を通じて、IT業界の外の人、IT業界を志している人に、大変なんだな、というのがなんとなく伝われば幸いである。
まあ、かくいう私も今ではIT業界の外の人だけどね。単なるニコニコのプレミアム会員に過ぎない。
そんなオチを付けて今回の記事を〆とする。
何か得たものがあったなーと思った読者は私のプロフィールから私のウェブサイトを見たり、投げ銭したり、どうぞよろしく。
投げ銭を入れるカゴはこちら。どうぞどうぞ遠慮なく。