entry-header-eye-catch.html
entry-title-container.html

entry-header-author-info.html
Article by

レポートpixiv MANGA Night 2

こんにちは!コミック事業部エンジニアのKNRです。

先日、「インフラコストを根本から削減する」株式会社DELTA様との共同でイベントを実施したため、その模様をレポートします!

pixiv MANGA Nightとは?

ピクシブの4つのマンガに関係するプロダクト(「pixiv」、「pixivコミック」、「pixivコミックインディーズ」、「Palcy」の裏側について、ユーザーやエンジニアの皆様に知っていただけるよう開催しているイベントです!前回は第1回として4つのプロダクトから4人のエンジニアが登壇し、それぞれのプロダクトの裏側について発表させていただきました。前回の模様に関してはこちらを御覧ください。 inside.pixiv.blog

今回は第2回として「Palcy」のAWSについてピックアップし発表させていただきました。「Palcy」は講談社様とともに提供しております、女性・少女マンガアプリでiOS/Android両スマホプラットフォームで配信しています。バックエンドはRuby on RailsとAWSを利用しており、ピクシブのサービスの中では珍しくオンプレ環境ではなく完全にクラウドの環境で構築されています。

www.youtube.com

第一部 Palcyのコスト削減プロジェクトについて

第一部では今回のメインとなるPalcyのコスト削減について株式会社DELTAの馬場様とともに発表を行いました。株式会社DELTA様では「CTO Booster」という「サーバー代削減のための調査・検証・作業をまるっと代行」するサービスを提供しており、弊社は増大するインフラ費用の削減を「CTO Booster」で実施しておりました。このセクションでは、そこで行った3つの施策について発表がありました。

ECSへの施策

1つめの内容はECSへの施策でした。PalcyではコンテナのマネジメントサービスAmazon ECSをAmazon Fargateを用いてピーク時・ピークアウト時の調整を実施しています。このECSにおいて確保するリソースが過大な部分があって遊んでいるリソースが存在している状態でした。そこでこのリソースを適切なサイズに変更することで、40%のコスト削減を実現しました。

この施策の提案はかなりはじめの方に行われたのですが、私は「いきなりヘビーな話を…!」と感じたことを覚えています。とはいえPalcyのデプロイフローにおいてはG/Bデプロイを採用しているのでECS自体が全く動かなくなることや、失敗した場合でも切り戻しは可能であったこと、また開発環境で十分に検証できたことで特にダウンタイムなくリリースができること、また現行のアプリケーションへの影響がないことを確認できたため、本施策を本番リリースしました。本件に関して馬場様とKNRの間で綿密に連絡を取り合いながら施策を進めました。

Log出力への施策

2つめの内容はCloudWatch Log出力への施策でした。具体的にはヘルスチェックAPIの起動・終了時に出力されるログが大量に出力されている状態であったものの、アクセス状況やレスポンス時間はCloudWatchのメトリクスですでに監視できる状態にありさらに、ログ自体は直接見ているわけではありませんでした。なので、この無駄になってしまっているログ出力を抑えてコストカットを行う施策を実施しました。

実装時にこのログに対する意識があまりなかったので、無駄になっているということが提案いただくまで気づかずなるほど…!となりました。基本的に出力されたログは開発時には1つ1つみていますが、安定運用に入った段階で例外などの文字列をトリガーとして自動的にSlackに発報する仕組みをとっているため完全に誰も見返すことのない無駄なログになっていました。

データ通信量への施策

最後の内容は、データ通信量への施策でした。Palcyはスマートフォンアプリであるため、モバイルアプリとWebアプリケーションの通信は予め定義した内容のJSONをWebAPIでモバイルに渡します。ただこのJSONファイルの内容がかなり大きく、最大で1MBを超える場合もありAWSの通信料もユーザーさんの”ギガ”も使ってしまう状況にありました。しかし、汎用的なモデルを使いまわしていたこともあり、APIから返された内容がすべてモバイル上で使われているわけではなかったためモデルの最適化を行いレスポンスの内容を60%程度削減しました。

この施策はPalcyチームで元々計画をしていたものでしたが、日々の開発や突発的に発生するバグなどの対応に追われチームとして足並みを揃えてこの対応を行うことが難しいなかでDELTA様に対応していただきました。対応に当たってiOS、Android、Webの3つを対応していただけたことは大きかったと思います。また同時にiOS/Android間でのデザインのズレにも気が付き同時に対応していただきました。

プロジェクトを通して

プロジェクト全体を通して費用削減額として約$5,000/月の大きな成果を上げていただきました。これは予想していたよりも大きな金額だったと思います。

KNRからは下記2点セキュリティ観点上の理由から難しかったこと

  • 2社間でのGitを使ったコード共有が難しく、この点の解決に時間がかかってしまったこと
  • 必要十分なIAM権限の付与のため、何度かやりとりを往復しなければ行けなかったこと

と、良かった下記2点

  • 「CTO Booster」は料金の削減額に応じて支払額が決めるため、弊社としてのメリットが大きかったこと
  • 仕様を伝える上で過大に資料を作って渡す必用がなく負荷が少なかったこと

をプロジェクト全体を通して感じたこととしてお伝えしました。

Palcyでは、まだまだアーキテクチャ等で改善をしていきたいと考えている事があり、例えば

  • RDSからDynamoを活用する形にできないか
  • 様々な画像や作品を取り扱うことをメインとしているため転送量が大きくなりがちなため、これらの転送量をどう減らすべきか
  • サーバレスアーキテクチャをもっと導入できないか

など将来のお話をさせていただき、このセクションを〆とさせていただきました。

第二部 pixivの開発者たちが今取り組んでいる挑戦について

第二部では「pixivコミック」、「pixivコミックインディーズ」、「Palcy」を束ねるコミック事業部のマネージャーであるtenと「pixiv」マンガのマネージャーであるuchienより各プロダクトで今挑戦していること、また開発している技術の話をしました。

コミック事業部

tenからは、多数の出版社と提携した商業連載プラットフォーム「pixivコミック」、pixiv投稿作品を編集者に見てもらえるマッチングサービス「pixivコミックインディーズ」の紹介を行いました。ピクシブが展開するマンガサービスでは、クリエイターの皆様の活躍の場をつなげるために複数のサービスを展開しています。そのうち「pixivコミック」、「Palcy」は商業作品としての発表の場として、「pixivコミックインディーズ」は商業へとつなげる場としてサービスを展開しております。

「Palcy」を含めたプロダクトではエンジニアを募集しており、「pixivコミック」ではフロントエンドをReact/Next.js、バックエンドをRuby on Rails、「pixivコミックインディーズ」ではフロントエンドをReact/Next.js/vite、バックエンドをPHPのエンジニアをそれぞれ募集しております。

pixivマンガチーム

uchienからは、pixivマンガチームにおいてUIの開発のお話や、創作コミュニティ盛り上げのために行った「学生マンガデイ」(https://www.pixiv.net/special/gakuseimanga/)、「サークルスペースメーカー」(https://www.pixiv.net/special/circlespacemaker/)など関連したイベントやプロダクトの紹介を行いました。

マンガチームではフロントエンドはVue/React/Next.js、バックエンドはPHPを使っており、両エンジニアを募集しております。

第三部 まとめ、pixivの今後の展望について

最後に本日のまとめとして、第一部・第二部のふり返りを行い、最後にピクシブ全体でエンジニア、特にAWSやクラウドエンジニアをどう捉えているかのお話をさせていただきました。 pixivのイメージとして古くはベニヤ板サーバーの時代などオンプレのイメージが強いかと思います。しかし「Palcy」を始めとしてクラウドを活用を進めております。例えばこちらの「GitLab GCPに 移行した(前編)」(https://inside.pixiv.blog/2022/11/29/110000)など、クラウドエンジニアの活躍の場は増えております。

ぜひ我こそは!という方は下記コーポレートサイトより応募をしていただければと思います。

https://www.pixiv.co.jp/

KNR
2019年中途入社で前職ではモバイルアプリの立ち上げ、サーバーサイド運用などを経験。 現在はRails&AWSをメインにPalcyに関わっています。好きなAWSサービスはAWS Lambda。