ドワンゴのサイバー攻撃被害、すぐに「ニコニコ動画（Re:仮）」を公開できた理由：「2024年3月に完了していた配信基盤のAWS移行」が結果的に功を奏す

大手出版事業者のKADOKAWAがランサムウェアを含む大規模なサイバー攻撃の被害に遭った。子会社であるドワンゴの動画配信サービス「ニコニコ動画」が停止し大きく話題となる中、「被害を受けなかった動画システムやデータ」を基にした「ニコニコ動画（Re:仮）」が公開された。仮サービスをいち早くリリースできた背景にあるのが、2024年3月に完了していた動画配信基盤のAWS移行だ。2024年6月に開催された「AWS Summit Japan」では、ドワンゴの久保田陽介氏が、動画配信基盤のAWS移行に踏み切った背景や作業過程、移行から得られたメリットを解説した。

[柴田克己，＠IT]

　大手出版事業者のKADOKAWAが、グループのデータセンター内のサーバを標的としたランサムウェアを含む大規模なサイバー攻撃を受けた。被害の拡大を防ぎデータを保全するため、データセンター内のサーバをシャットダウンする対応を採った。その結果、KADOKAWAの出版事業に影響が出た他、子会社であるドワンゴの動画配信サービス「ニコニコ動画」はサービスが利用できない状態に陥った。中でもニコニコ動画のサービス停止は、インターネットユーザーを中心に大きく話題となった。

　攻撃判明後の2024年6月14日、YouTubeの「ニコニコ公式チャンネル」で公開された動画では、ニコニコのサービス群は「クラウドベンダーが提供するパブリッククラウドと、グループ企業が運営するプライベートクラウドに配備されたシステムの組み合わせで提供されており、プライベートクラウド内の相当数のサーバがランサムウェアの影響で利用不能になった」と説明された。執拗（しつよう）な攻撃に「データセンター内に設置されたサーバの電源や通信ケーブルを物理的に抜いて対抗した」と切迫した状況だったことも明かされている。

　KADOKAWAグループのプライベートクラウドには、ニコニコサービスやKADOKAWAの他事業、業務関連のシステムが置かれていた。プライベートクラウド内の全てのサーバを使用不可としたため、前述した通り、事業への影響は甚大なものとなった。ドワンゴは2024年7月26日、8月5日にニコニコサービスの再開と、サービス停止に伴う補償を実施する旨を発表している。

「ニコニコのサービス停止に関するお詫びと今後について」（YouTube ニコニコ公式チャンネル）から。

　一方、サービス停止の説明と同タイミングで「被害を受けなかった動画システムやデータ」を基に、ニコニコ動画の開発チームが急きょ作成したという「ニコニコ動画（Re:仮）」がリリースされた。「ニコニコ動画（Re:仮）」は、動画視聴やコメントといった、ニコニコ動画開始初期（2006年）の基本機能のみを備えたサービスとなっている。

　同サービスで使用された「被害を受けなかったシステムやデータ」とは、パブリッククラウドであるアマゾン ウェブ サービス（AWS）で構築あるいは保存されていたものだ。実は、長くオンプレミスで運用してきた動画の配信基盤について、2023年からパブリッククラウドへの移行を開始し、2024年3月に完了していた。結果論だが、サイバー攻撃被害の3カ月前に終えていたAWS移行が、ニコニコ動画の重要なシステムやユーザーコンテンツをランサムウェアの被害から守り、復旧に向けた取り組みで、仮サービスの迅速な立ち上げに貢献したというわけだ。

ドワンゴ ニコニコサービス本部DMS 開発部第一セクション マネジャー 久保田陽介氏

　ニコニコ動画はなぜ動画配信基盤のAWS移行を進めていたのか。2024年6月下旬に開催された「AWS Summit Japan」では、ドワンゴの久保田陽介氏（ニコニコサービス本部DMS 開発部第一セクション マネジャー）が、ニコニコ動画の動画配信基盤をAWSに移行したいきさつや、作業の過程で得られた知見などを紹介した。

　冒頭、久保田氏は「今回の講演内容はニコニコ動画における動画配信基盤のクラウド移行に関する内容であり、サイバー攻撃と今後の復旧見込みに関する情報は、ドワンゴのプレスリリースを参照してほしい」と述べて講演をスタートした。

複数の「深刻な課題」を抱えていたオンプレミスの動画配信基盤

　ニコニコ動画がスタートした2006年は、インターネット上の動画配信サービスそのものが黎明（れいめい）期だった。当時はYouTubeの日本語版サービスも始まっていない時期であり、ユーザーが作ったコンテンツをユーザーが視聴し、画面を流れるように表示されるコメント機能で視聴者のフィードバックが得られるといったコミュニケーションスタイルの目新しさは、日本のインターネットユーザーに広く受け入れられた。

　2007年には、ライブ配信サービスの「ニコニコ生放送」もスタートした。外資系を含む多数の動画配信サービスが提供されている現在も、「ニコニコ」という愛称で多くのクリエイターや配信者、インターネットユーザーに支持されている。

　ニコニコ動画とニコニコ生放送の旧配信基盤は、2016年にオンプレミスで構築されていた。ドワンゴでは「配信基盤」の機能を「動画ファイルの受け付け」「動画ファイルの変換および保存」「リクエストに応じた配信」をするものと定義しており、コメント表示などをするフロントエンド部分は含まれていない。この旧配信基盤は、安定して稼働していた一方で、特に開発と運用の両面で深刻な課題を抱えていたという。

（久保田氏の講演資料より）

　開発面での課題は、主に動画と生放送の配信が同じシステム上にあるというアーキテクチャに由来するものだ。性質の異なるサービスを、同じシステム上で扱うようにした理由の一つに、コンピューティングリソースの有効活用があった。動画配信は保存したデータを読み出すためディスクI/O（Input/Output）の負荷が高く、生放送配信はリアルタイムでのエンコードが必要なためCPUの負荷が高くなる。配信する動画のフォーマットやコーデックを共通化することで、ハードウェア上のリソースを有効活用できるという見込みがあったという。

　「この仕組みには利点もあった一方で、リソースの有効活用という点では当初の意図通りにはいかなかった。結果として、モノリシックなアーキテクチャ上に複雑なシステムが残ることになり、メンテナンスがしづらく、開発のスピードや効率も悪化していた」（久保田氏）

　こうしたアーキテクチャは、運用面の課題にもなっていた。旧配信基盤は1000台を超える仮想サーバ（VM）のクラスタ構成で運用されており、常に稼働し続けることが求められる配信サービスの特性もあり、システムの更新リリースやハードウェア故障などへの対応が非常に難しいものになっていたという。

　「生放送の変換中には処理を止められないため、放送終了を待ってデプロイするような複雑な手順が必要だった。結果として、生放送とは直接関係のない動画機能の更新も阻害されるケースがあった。プロビジョニングツールには『Ansible』を利用し、ある程度の自動化はしていたものの、複雑な構成に対応するため、標準的な使用方法から外れた複雑なスクリプトを組み合わせて使用しており、スクリプトのメンテナンスにも手間がかかっていた。そのため、更新が月に1回程度しかできず、タイムリーなリリースができない状況だった」（久保田氏）

　配信基盤がオンプレミスにある制約も大きかったという。動画や生放送へのアクセスのピークは夜の時間帯に集中するため、必要なリソース量は大きく変動する。しかし、調達の際にはピーク時の負荷を基準に機材を購入する必要があった。突発的なイベントなどで想定するピークを超えるアクセス集中があった場合の対応も難しい。結果として、リソース調達のコスト面での非効率性が増したり、機会損失を招いたりといったことが増えたという。

　こうした状況を改善するための検討と作業は継続的に行われていたものの、稼働し続けている配信基盤の構造を変えることは難しく、技術チームも疲弊しつつあった。そこで、これらの根本的な解決策として、パブリッククラウドであるAWS上に、新しい配信基盤を構築することを決断するに至ったという。

「クラウドリフト」ではなく「クラウドシフト」で課題解決を図る

　AWS移行を進める上では、同社では旧基盤が抱えていた「開発」「運用」「オンプレミスでの制約」といった全ての課題を解決することを目指した。旧基盤の持つ古いアーキテクチャをそのまま移行（クラウドリフト）するのではなく、クラウドネイティブ技術を活用したアーキテクチャへ刷新（クラウドシフト）する必要があった。

（久保田氏の講演資料より）

　まず、システムの複雑化を抑えるため、旧基盤で一体化していた「動画」と「生放送」の配信基盤を分離。マイクロサービスアーキテクチャを採用することで、各サービス内で発生する問題への個別対処を容易にすることを目指した。

　配信基盤のベースとなる「動画変換」「データ保存」「動画配信」といった各機能は独自のものを作らず、できる限りAWSのマネージドサービスを利用することで運用をシンプルにし、サービス提供に必要なリソースを削減する方針を採った。具体例としては、動画変換に「AWS Elemental MediaConvert」、データ保存のストレージに「Amazon Simple Storage Service（Amazon S3）」、コンテンツ配信に「Amazon CloudFront」を採用している。

　「システムリソースの使用量は、旧動画配信基盤には1万の論理CPUコアが使われていた。AWSの新配信基盤では動画部分で約300コアとなっており、実に97％の削減を実現している」（久保田氏）

（久保田氏の講演資料より）

　運用面についても、クラウドの恩恵を最大限に受けられるような仕組み作りを目指した。管理対象となるホストの多さに対応するため、アプリケーションはコンテナ化し、プロビジョニングには「AWS Cloud Development Kit（AWS CDK）」、コンテナオーケストレーションには「Amazon Elastic Kubernetes Service（Amazon EKS）」、継続的デリバリー（Continuous Delivery）には「Argo CD」を採用した。

　「これらのマネージドサービスやオープンソースソフトウェア（OSS）を利用するようにしたことで、アプリケーションの更新は、以前と比べて極めてシンプルになった。以前は、準備に1〜2週間、更新作業に1〜10時間ほどかかっていたものが、準備は1時間以下、更新作業は数分にまで短縮できた。デプロイ頻度も大幅に上がり、現在では1日1回以上のリリースが可能になっている」（久保田氏）

（久保田氏の講演資料より）

　クラウドネイティブな開発、運用スキームの採用で、アクセス数のピークに合わせた自動スケーリングも実現している。突発的なアクセス増に対応するためのリソース増も柔軟にできるようになり、調達コストの削減、機会損失の極小化に貢献しているという。

（久保田氏の講演資料より）

最も難しかったのは「コスト試算」

　動画配信基盤の刷新は、旧基盤の開発運用チームが中心となり進めてきた。その過程で最も課題となったことは「新アーキテクチャでのコスト試算」「技術面での挑戦」「既存動画をどうマイグレーションするか」の3点に集約されると久保田氏は振り返った。

　1つ目の「コスト試算」の難しさは、インフラからアプリケーション、そのアーキテクチャに至るまで、システム全体の構成を一新したことが原因の一つだった。完全な新規構築となるため、設計段階からクラウドでのコストを試算する必要があったものの、オンプレミスとコスト構造が根本から異なることもあり、算出にはかなりの手間と時間が必要だったという。

　「まず、AWS上で必要な機能を実現するためのアーキテクチャを設計し、PoC（概念実証）の段階から旧配信基盤で取得した計測データを当てはめて試算した。例えば、送信データ量にかかる費用の場合、オンプレミスでは帯域に対する回線費用だが、クラウドでは送信データの総量に費用がかかる。クラウドのコスト項目を100以上に細分化し、それぞれにどのデータが対応するかを考えながら、一つずつ当てはめていった」（久保田氏）

　ニコニコ動画のような大規模サービスの場合、各項目でのわずかな計算誤差が、全体では大きなコスト差として現れてしまう。同社では、試算の信頼性に不安を感じながらコストの算出作業を進めていたというが、AWSジャパンによる支援が非常に役立ったという。

　「移行の検討を始めた当初から担当者をアサインしてもらい、アーキテクチャからコスト試算まで、詳細に踏み込んで支援してもらえた。結果、旧配信基盤よりも低コストで動画配信基盤の移行を実現でき、試算したコストも約97％の精度で着地できた」（久保田氏）

　AWSジャパンによる支援は、メンバーが初めて取り組んだKubernetesやGo言語による「クラウドネイティブ」な開発運用をスムーズに進める上でも心強いものだったとする。

　「初めての取り組みが多いプロジェクトで、メンバーは新しい技術へのキャッチアップと、設計開発を同時に進行させる必要があった。当初は完全に手探りで、不安なシーンも多々あったが、AWS主催の社内勉強会への参加や個別の支援、メンバー間での設計共有などの施策を通じて、やり遂げることができた。クラウド初心者であるわれわれには非常にありがたいもので、これがなければプロジェクトの完遂は難しかったと感じている」（久保田氏）

　3つ目のポイントである「既存動画のマイグレーション」は、オンプレミスのストレージに蓄積された動画ファイルを、どのようにAmazon S3へ移行するかという問題だった。ニコニコ動画には、動画数にして2160万、総時間数にして500万時間、容量で5PB以上の膨大な動画データが存在していた。配信基盤をAWSへ切り替えるに当たり、これらのデータ形式を変換する必要があったという。

　「最も簡単な方法は再エンコードだが、それには大量のコンピューティングリソースが必要になる。さらに、100倍速のスピードで変換したとしても、完了までに2000日を要する計算になり、非現実的だった」（久保田氏）

　そのため、専用のマイグレーションシステムを開発して対応したという。このシステムでは「トランスマックス」と呼ばれる、圧縮コーデックへのデータ変換をせずに、データの中身だけを別のメディアフォーマットに詰め替える処理をする。このシステムが機能したことにより、わずか3台のホストで、述べ約3カ月（約90日）の短期間でマイグレーションを完了できたという。

（久保田氏の講演資料より）

配信基盤のクラウドシフトがサービス復旧後の光明に

　ニコニコ動画の新配信基盤への移行は2024年3月に完了しており、それに伴うユーザー体験の改善も進んでいたという。Amazon CloudFrontにより、動画取得の速度改善や、サービスのIPv6対応といったメリットを生んでいた。その他にも、オンプレミスの制約がなくなったことで、一般会員とプレミアム（有料）会員間で視聴品質に差を設けていた「エコノミータイム」や、長尺動画の高画質での配信を制限する施策も段階的に撤廃していたという。

　現在は、サービス停止以前の状態への復旧が最優先される状況ではあるものの、クラウドネイティブなアーキテクチャによって、従来の基盤が抱えていた開発、運用に関わる多くの課題を解消できたことはニコニコ動画やニコニコ生放送などのニコニコサービス全体の展開にとって光明と言える。

　「配信基盤のクラウドによる刷新は、今後新しい施策を展開していく上でもメリットになると考えている。生放送の配信基盤も現在刷新を進めている他、並行して新しい動画配信基盤の改善も進め、さらなるコスト最適化を進めていきたい。コスト最適化を進めることで、さらなるユーザー体験の向上や新機能の追加など、ユーザーの皆さまに還元するためのリソースを確保できるようになる。まだまだ、できることはたくさんある。皆さまにニコニコをより楽しんでいただくためにも、継続して改善に取り組んでいきたい」（久保田氏）