数億PVを支えるマンガDXアーキテクチャ

![note_OGP.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/31453817-b041-2557-a4c2-7ded17f383ef.png)

# はじめに

皆さん、はじめまして。
マンガDXサービスを運営するコミチ代表のマンディです。

今回は、Web雑誌『[ビッコミ](https://bigcomics.jp)』『[ヤンチャンWeb](https://youngchampion.jp)』『[ヤングアニマルWeb](https://younganimal.com)』『[ヤンマガWeb](https://yanmaga.jp)』『[ベストカーWeb](https://bestcarweb.jp)』や、マンガ投稿サイト『[コミチ](https://comici.jp)』など複数Webサービスを開発・運営するコミチのアーキテクチャをご紹介したいと思います。

マンガDXに興味のあるエンジニアさんの参考になれば嬉しいです！

# コミチとは？

コミチは、『クリエイターと共創し、マンガ体験をDXする』というミッションのもと、マンガ関係のDXツールを提供する会社です。

提供サービスとしては、
 - マンガ雑誌制作ツール『コミチ＋』
 - マンガ投稿サイト『コミチ』

です。

![service_of_comici.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/0005a0ea-fda4-e236-ed9a-8bd6769b022f.png)

コミチはデジタルコンテンツの中でもマンガ販売に特化し、『待つと無料』『無料ポイント』といった機能や、トップカルーセルや特集機能といったインタラクティブな雑誌を作る管理画面など、マンガならではのサービス開発を行っています。

![culturedeck.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/b2fe1b2c-4fd2-ce4e-eadf-3fcce51bab88.png)
参考：[コミチのCulture Deck](https://speakerdeck.com/comici_mandy/komitinoculture-deck)

# コミチのマンガDXを支える技術

コミチが漫画SaaSを実現するために独自で実現している技術は大きく3つあります。

1つ目は、DRMという技術です。
DRMとはコンテンツの不正利用や複製を防ぐ技術で、マンガ画像を守るための技術とも言えます。
例えば、
 - マンガ画像を暗号化した状態で配信し、リアルタイムに復号化する技術
 - マンガ画像の配信URLを定期的に入れ替える技術

などがそれに当たります。

2つ目は、レコメンドエンジンです。
コミチでは、自社開発したレコメンド機能を組み込んでいます。
レコメンド機能は、ユーザーのアクセスログや購買履歴を学習し、利用者の好みに合った作品を推薦しています。
主にPythonを利用して、独自の技術開発を行うことで、自由度の高いR&D環境を確保して開発を進めています。
最新の論文を参考に新しいアルゴリズムを試したり、成果を分析して絶えず改善を追求して、CTR改善を行っています。

3つ目は、ヘッドレスCMSという技術です。
サーバサイドとフロントエンドを分離し、API通信によってフロントエンドを実装しています。
この技術により、
 - 読者のUX向上
 - セキュリティ向上
 - 分業による開発生産性向上

などが実現できます。
こちらの技術はR&D中で、近日公開予定です。

![EngineerHandbook.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/6a64b8b2-b77e-fb39-bf49-460047661a94.png)
参考：[コミチのEngineer Handbook](https://speakerdeck.com/comici_mandy/komitinoengineerhandbook)

# コミチのアーキテクチャ課題

このようにコミチでは独自の技術を開発し、サービスを提供してきたのですが、事業の拡大に合わせて課題が出てきました。

前章でもご説明した通り、コミチの主要プロダクトはSaaSになります。SaaS型のマンガ雑誌は、多種多様な雑誌や漫画を効率よく販売する必要があります。単体のWeb雑誌運用であればシングルテナントでどうにかできます。しかし、SaaS型のサービスを実現するには、そうはいきません。例えば新規の雑誌を追加したとき、サービス当初はトラフィックがないのに、そのレスポンス速度などが他の大規模なサービスに引っ張られてしまいます。大規模なトラフィックを捌き、各サービス独立でユーザー体験を維持するためにも、機能とDBは共通の仕組みを保ちつつ、スケールするためにマルチテナントの設計にする必要があります。

弊社は現在シングルテナントのアーキテクチャになっており、規模が小さいうちは良かったのですが、数億PVを達成し、今後も事業拡大をしていくには、更にマルチテナント対応を進めて行くほかありません。

# コミチがこれから実現したいこと

弊社ではこういった問題を解決するため、事業的にも技術的にも似ている他業界のサービスであるShopifyを参考にしております。Shopifyは言わずと知れたモノのECサイトとして、中小企業から大企業まで、様々な規模のビジネスに対応したサービスを展開しております。

コミチはまさに漫画版のShopifyといえ、その事業の展開の仕方や技術的な課題の性質が似ているためそのため、Shopifyなどのアーキテクチャを日々研究し、マンガに最適化したアーキテクチャを日々研究しております実現しています。

Shopifyで実現しているマルチテナント型アーキテクチャは下図のとおりで、時代によって少しずつマルチテナント型アーキテクチャを実現しています。

2006-2012：リソースを全て共有する方式（Share everything）
2013：Databaseを分離する方式（Database isolation）
2015/2016：サービス単位で分散する方式（Podding）
2016：流量でサーバリソースを分ける方式（Floating capacity）

しかし、コミチではまだShare everything方式までしか実現できていません。

![spectru,.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/c584b827-73d3-cfbe-ab11-9805759cf7b0.png)

参考：[Shopifyのアーキテクチャ](https://www.usenix.org/sites/default/files/conference/protected-files/srecon16europe_slides_weingarten.pdf)

シングルテナントからマルチテナントのアーキテクチャに移行するために、弊社では現在技術検証を進めております。

# エンジニア採用やってます！

コミチは、”100年愛されるマンガづくり”に貢献したいという思いで、メンバー一同サービス開発・運営しています。
事業拡大をしていくにあたり、このマルチテナント型アーキテクチャを一緒に実現してくれるエンジニアさんを大募集しています。

[<img width = 1200 src = "https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3333029/f308dfbe-bead-8f45-e28c-97d1ef475342.png">](https://note.com/daisakku/n/n25909c8d19d5)


もしご興味のある方は、CultureDeckやEngineerHandbookをご覧ください。

**Culture Deck**

https://speakerdeck.com/comici_mandy/komitinoculture-deck

**Engineer Handbook**

https://speakerdeck.com/comici_mandy/komitinoengineerhandbook


まずはカジュアル面談からでもOKです。
お気軽に、私までご連絡ください！

https://beacons.ai/daisakku


**採用サイト**

https://comici.co.jp/recruit