ニコニコ漫画のインフラ構成について

あけましておめでとうございます。メディアサービス開発部バックエンド開発グループのフサギコ(髙﨑)です。

これまで子会社の株式会社トリスタに所属していましたが、トリスタが2021年10月に吸収合併されたため株式会社ブックウォーカー所属となりました。

ブックウォーカーのメディアサービス開発部となってからも、Ruby on Railsによるバックエンドの実装運用と、AWSによるサービスインフラの設計構築を中心とした、いわゆるテックリードのような立ち位置で働いています。

トリスタinsideで私の記事をお読みになったことがある皆様は引き続き、そうでない皆様も宜しくお願いします。

本記事は私が株式会社ブックウォーカー所属になってから初めての記事ということで、メディアサービス開発部がトリスタだった頃より引き続き開発運用しているサービスのうち、ニコニコ漫画のサービスインフラの概要について軽くご紹介したいと思います。

ニコニコ漫画について

ニコニコ漫画はニコニコ静画において2010年8月に公開された特設ページを端緒とする、Web漫画連載プラットフォームサービスです。

一般のニコニコユーザーから投稿されるユーザー漫画と、出版各社さまからご連載いただく公式漫画が同一サイトおよびアプリ上で閲覧できること、またニコニコファミリーサービスに恒例の右から左へ流れるコメントを漫画のページ上で行えることが特徴です。

ニコニコ漫画は大きく分けると下記の4つのプロダクトから構成されています。

これらに加え、ドワンゴのニコニコファミリーサービスのいくつかと相互にリクエストを行っており、その関係を概要図に表すと下記のようになっています。

これらのサービスインフラを主にTerraformを用いて構成管理しています。

現行PHPは、元々ニコニコ静画と完全に密結合した状態でドワンゴのデータセンターで動作していたものを、密結合を切り離してAWSへ移設したものです。いわゆるリフト&シフトのうち、リフトが完了した段階と言えます。

完了しているのはリフトまでで、プロビジョニングとデプロイはTerraformで作成したEC2インスタンスに対してansible、 PHPコードをrsyncで配布という昔ながらの方法で行っているので、オートスケーリングなどはできていません。

また、独自フレームワークのためテストの方法があまり確立されておらず、ビジネスロジックの一貫性を保証しきれていないという問題があります。そのため、ビジネスロジックを後述の新バックエンドへと移譲し、プレゼンテーション層のような立ち位置へ移行を進めています。

新バックエンドは、前述した現行PHPのビジネスロジックをテストを書きつつ移植し、ビジネスロジックの一貫性の保証と整理を目指すプロダクトです。

ECS(Fargate)で動作しており、デプロイにはecspressoを用いています。オートスケーリングも設定してあり、繁忙時間帯と閑散時間帯でECSのタスク数が増減してコストと運用負荷を低減しています。

現行PHPからのビジネスロジック移譲が少しずつ進んできており、テストも書かれているためその点は問題ないと言えます。

しかし、図からもわかるようにデータベース(Aurora)は現行PHPと新バックエンドがともに読み書きしている状態です。したがって、ビジネスロジック移譲が済んで現行PHPが読み書きしていないことが少なくともテーブル単位で確定するまでは、DB構造のリファクタリングが難しいです。

いくらかビジネスロジック移譲が進んだことでサービスとして新機能を実装するようなストーリーも少しずつ出てきており、いかにビジネスロジック移譲とバランスを取りながら進めるか、新機能を現行PHPで実装するべきか新バックエンドで実装するべきかの判断が課題です。

ニコニコ漫画には、一部ページにおいてフロントエンド開発グループが実装したReactをマウントして利用している箇所があります。 React向けBFFはそれらへのBFFを担うプロダクトです。

これも新バックエンドと同じくECS(Fargate)で動作しており、デプロイも同様にecspressoを用いています。

現行PHPにはこのBFFが生まれる前に実装されたReact向けAPIが残っており、必要なAPIを新バックエンドに用意できた暁にはこのBFFへ移せればと思っています。

ニコニコ漫画では、スマートフォンアプリにおいてポイントを購入、そしてそのポイントを消費することで、無料公開期間が終了したエピソードの単話販売、ならびに無料公開期間が開始する前のエピソードの先読み販売を行っています。

これも新バックエンドと同じくECS(Fargate)で動作しており、デプロイも同様にecspressoを用い、オートスケーリングも設定してあります。

実際の決済処理などはドワンゴの決済基盤システムにまだ依存しており、それからの脱却が課題となっています。

最後に、ニコニコ漫画のサービスインフラを構成するTerraformそのものについてです。

先述した4つのプロダクトを含むこのTerraformは巨大な規模に成長しており、 dev環境を数回Terraform planしただけでAWSのAPIレートリミットに到達するようになってしまっています。

これを複数のtfstateに整理した形で分割しなければならないことが課題となっています。

本記事では、ニコニコ漫画を構成するいくつかのプロダクトとその関係について概観しました。

いずれも課題を抱えており、それぞれに人の手が必要です。

ブックウォーカーでは物理・電子・Web連載問わず漫画や本が好き、あるいは長年運用されてきたWebサービスを紐解き、より良い形に作り替えていくことに興味があるWebアプリケーションエンジニアを募集しています。

もし興味がありましたらぜひ、ブックウォーカーの採用情報ページからご応募ください。