【レポート】AWS Summit Tokyo 2017: [集英社] 読書アプリクイックスタートガイド:AWSを活用したアプリ事業開発事例とデジタルコミックス制作フロー #AWSSummit

aws-summit-tokyo-2017-longlogo

『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。

当エントリでは、導入事例トラック 3のセッション、「 [集英社] 読書アプリクイックスタートガイド:AWSを活用したアプリ事業開発事例とデジタルコミックス制作フロー」をレポートしたいと思います。

セッション概要

当セッションの登壇者及び概要は以下の通りです。

スピーカー: 大村 嘉範

株式会社集英社 デジタル事業部 デジタル事業1課 副課長

出版関係者の皆様へ弊社が取り組む、AWS を活用したデジタルコミックスの制作フローや事業リスクマネージメント、サービスの事業開発事例を紹介し、読書アプリを自社開発する上で役立つヒントをご提供します。

発表者

  • 大村 嘉範
  • デジタル事業部 所属
    • 集英社は漫画、文字、雑誌がメイン
    • 当初はコンテンツのオフィシャルサイトの管理
    • 前者2つに関する電子書籍、読書アプリ
  • 技術カテゴリーを担当
    • データ分析
    • AWSの構築/運用

スマホ端末からのコンテンツ体験

  • コミック・雑誌・書籍がスマホで読まれることが多くなった
  • 1,2ヶ月に1つぐらいのペースで自社アプリを立ち上げ

ウェブとアプリの違い

書籍アプリはウェブに比べて

  • 表現が柔軟
  • 購買処理の介入が柔軟
    • 定期購読
    • 話販売
    • 体力課金
    • レンタルモデル
  • 新たな読者を生み出し、素晴らしい作品を生み出す土壌になっている
  • プッシュ通知
    • 読者のエンゲージメントを高める

読書アプリについて

  • マーケットプレイスが細分化
  • アニメのオンデマンド配信
  • 出版事業としては逆風
  • クロスメディア戦略には活用し易い

多くの自社サービスを運営し、横串で、総合的に読者にインセンティブを与えることが大事と考えている

読書アプリ

  • 開発手法・プラットフォーム・ライブラリーと電子書籍事業は成熟しつつある
  • 集英社のサービスはライトウェイトなもの

今回の発表について

  • 最近ローンチした幾つかの事業の事例を紹介
    • 出版社の方は自社アプリを作れるように
    • ディベロッパーの方はプラットフォームの整備・参入につながるように

マイジャンプの紹介

  • 2016/8/8 サービススタート
  • あなただけのジャンプを創刊できる
  • 「話」の単位で構成できる
  • 「ジャンプの編集長」になれる
  • サブスクリプションモデル

マイジャンプの課題

コンテンツ管理に関する課題

  • いままで「巻」の単位で管理
  • デジタルのフローは複雑
  • 底本からデジタルデータを作成
  • 基礎情報が正しいか
  • これを 「話」の単位でチェック→面倒

サービス立ち上げに伴う課題

  • コミックビューアーを一から開発
  • サービスの盛り上がりが読めない
  • サイジングが難しい

インフラの観点から

  • 本番
  • ステージング → バージョンアップ時の内部公開、本番障害の検証
  • 開発

環境の複製について

  • AWSはスナップショット管理が簡単
    • 環境のコピーがかんたん
    • バックアップにもなる

コンテンツのデータサイズが非常に大きい

  • 配信データが非常に多い
  • 36TB程度ある
  • いまは数時間で検証環境ができる

アプリのテスト

アプリのテストは以下を利用

  • testflight
  • deploygate

システムは2つある

  • ユーザー系
    • 複数のコンテンツ・アプリから利用される
  • コンテンツ・アプリ系

ライフサイクル、データ管理が大きく異なるのでVPCを分けている

データベース

  • Amazon Auroraを利用
  • マイジャンプでは、事前サイジングが難しかった。シームレスにスケールアップ可能であることが求められた
  • 障害テストのシミュレーションが充実していて便利

クラウドフロント・コンテンツビューワについて

  • 読者が選んだ好きな作品を週刊誌として定期購読するビジネス
  • ユーザー x コンテンツ分のデータが毎週作成される
  • 雑誌的なUIを実現
    • 目次からジャンプ
    • 次の話に飛ぶ

表紙を作ることも可能

  • 表紙もパーソナライズ可能
  • コンテンツはS3上に設置
  • 暗号化・難読化されたデータを隠蔽されたURLで CloudFront 経由で配信
    • 難読化→画像をジグソーパズルのように分割してS3に設置。クライアントでピースを合体する

デジタルコミックス製作フロー

  1. 書誌作成
  2. EPUB作成依頼
  3. EPUBをオーサリング会社から納品
  4. 目次作成
  5. 検品
  6. ストア(Kindle, マイジャンプ)に入稿

大容量のコンテンツ

  • コンテンツ作成のたびに、いろんな元データが作成される
  • 元データを縮小してコンテンツデータを作成している
  • ストアによって解像度も異なる
  • バリエーションが多く、配信コンテンツのデータサイズが膨れ上がる
  • 入稿データをとっておくのが大変

データセンターに移行プロジェクトが始まる前

ストレージ

  • オンプレに80TBのNASを構築
    • 障害時の対応が面倒。
    • 保守・運用費用が膨大
  • S3に移行した

底本

  • 重版訂正
    • 単純な訂正
    • 時代の変化に伴う表現の変更
  • 底本から複数のファイルが生成される
    • 期間限定ファイル
    • 話単位ファイル
    • 1/2 分冊ファイル
  • 各ファイルで個別に重版訂正するのは現実的ではない
  • デジタル底本を修正すると、派生ファイルも連動して変わるようにして対応

効率よい製作フロー

  • 効率よく
    • 製作
    • 確認
    • 入稿
  • する仕組みが必要
  • 自社でこれらのフローを簡略化するシステムを作成
  • システム上でプレビュー可能

デジタルコミック冊数

  • S3を使わないとコストが嵩む
  • 当初は5年で8000冊想定でオンプレを構築
  • 実際は21000冊を超えている

冊数が多い理由はバリエーションの多さ

当初は予想していなかった販売形態の細分化

  • 期間限定ファイル
  • 話単位の配信
  • キャンペーン

ストレージコストの最適化

3種類のストレージを用意

  • NAS on EC2
    • 即時にアクセスが必要なコンテンツ
    • EPUBデータ
    • ソースコード
    • など
  • Storage Gateway/S3
    • 業務の中でまれに必要だが頻繁なアクセスは不要なコンテンツ
    • S3をファイルシステムとして使う
  • Glacier
    • 触らないが、保全のために必要なアーカイブデータ
    • S3のライフサイクル設定でGlacierに移動
    • コミックデータのPhotoshopの元データ
    • 原稿のスキャンデータな
    • Photoshopのカラーリングの元データ
    • S3のバックアップ
    • EC2のスナップショットのバックアップ

DMP環境

  • 主なデータはS3経由でRedshiftに投入している
  • セールスデータがいろいろなところから生成される

データの流れ


SQL Server -> S3                         -> Redshift -> Tableau Server
               `-> EC2/Pythonで加工 -> S3 -/
  • Tableau Serverを通じて、売上の推移が瞬時にわかる
    • 昨日までにキングダムはどれだけ売れたのか?
    • テレビの芸人の紹介などでの売上がどのくらい変わったのか?
  • Athena 移行も考えている

アプリを開発する上での課題

  • 実装上のインフラの利用率がクライアント企業(集英社側)からは判断しにくい
  • ベンダーロックインは避けたい
  • 一つのシステムを複数社に実装してもらう
    • バージョンごとにベンダーを変えて対応
    • 発注元(集英社)は修正箇所を指示できない
    • 競合にあたるベンダー同士をうまく繋げないといけない

プロジェクト管理

システムごとの複数ベンダーの管理に利用しているサービス

  • Redmine(ITS)
  • subversion(VCS)
  • teampass(パスワード管理)
  • メールディーラーで連絡

AWS リソースの権限管理

  • 複数ベンダーが同じAWSアカウントでリソース操作する
  • インスタンスを起動したIAM ユーザーによって、Lambda でタグを適切に設定
  • そのユーザーしかインスタンスの変更・停止をできないようにする

運用と監視

  • 複数ベンダーが関わって運営 − アプリ開発とインフラ会社が別
  • アプリケーションが正常に動いていることの担保・問題の切り分けを運用/監視側が行えるような工夫が必要

感想

普段は見聞きすることの少ない電子書籍の製作フローについて話が聞けて貴重でした。

ストレージシステムを複数用意し、コンテンツのアクセスパターンに応じてストレージを使い分けるアイデアは、電子書籍に限らず、サービスの運用者にとって、参考になるのではないでしょうか。