この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。
当エントリでは、導入事例トラック 3のセッション、「 [集英社] 読書アプリクイックスタートガイド：AWSを活用したアプリ事業開発事例とデジタルコミックス制作フロー」をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
スピーカー：
大村 嘉範
株式会社集英社 デジタル事業部 デジタル事業１課 副課長
出版関係者の皆様へ弊社が取り組む、AWS を活用したデジタルコミックスの制作フローや事業リスクマネージメント、サービスの事業開発事例を紹介し、読書アプリを自社開発する上で役立つヒントをご提供します。
発表者
- 大村 嘉範
- デジタル事業部 所属
- 集英社は漫画、文字、雑誌がメイン
- 当初はコンテンツのオフィシャルサイトの管理
- 前者2つに関する電子書籍、読書アプリ
- 技術カテゴリーを担当
- データ分析
- AWSの構築/運用
スマホ端末からのコンテンツ体験
- コミック・雑誌・書籍がスマホで読まれることが多くなった
- 1,2ヶ月に1つぐらいのペースで自社アプリを立ち上げ
ウェブとアプリの違い
書籍アプリはウェブに比べて
- 表現が柔軟
- 購買処理の介入が柔軟
- 定期購読
- 話販売
- 体力課金
- レンタルモデル
- 新たな読者を生み出し、素晴らしい作品を生み出す土壌になっている
- プッシュ通知
- 読者のエンゲージメントを高める
読書アプリについて
- マーケットプレイスが細分化
- アニメのオンデマンド配信
- 出版事業としては逆風
- クロスメディア戦略には活用し易い
多くの自社サービスを運営し、横串で、総合的に読者にインセンティブを与えることが大事と考えている
読書アプリ
- 開発手法・プラットフォーム・ライブラリーと電子書籍事業は成熟しつつある
- 集英社のサービスはライトウェイトなもの
今回の発表について
- 最近ローンチした幾つかの事業の事例を紹介
- 出版社の方は自社アプリを作れるように
- ディベロッパーの方はプラットフォームの整備・参入につながるように
マイジャンプの紹介
- 2016/8/8 サービススタート
- あなただけのジャンプを創刊できる
- 「話」の単位で構成できる
- 「ジャンプの編集長」になれる
- サブスクリプションモデル
マイジャンプの課題
コンテンツ管理に関する課題
- いままで「巻」の単位で管理
- デジタルのフローは複雑
- 底本からデジタルデータを作成
- 基礎情報が正しいか
- これを 「話」の単位でチェック→面倒
サービス立ち上げに伴う課題
- コミックビューアーを一から開発
- サービスの盛り上がりが読めない
- サイジングが難しい
インフラの観点から
- 本番
- ステージング → バージョンアップ時の内部公開、本番障害の検証
- 開発
環境の複製について
- AWSはスナップショット管理が簡単
- 環境のコピーがかんたん
- バックアップにもなる
コンテンツのデータサイズが非常に大きい
- 配信データが非常に多い
- 36TB程度ある
- いまは数時間で検証環境ができる
アプリのテスト
アプリのテストは以下を利用
- testflight
- deploygate
システムは2つある
- ユーザー系
- 複数のコンテンツ・アプリから利用される
- コンテンツ・アプリ系
ライフサイクル、データ管理が大きく異なるのでVPCを分けている
データベース
- Amazon Auroraを利用
- マイジャンプでは、事前サイジングが難しかった。シームレスにスケールアップ可能であることが求められた
- 障害テストのシミュレーションが充実していて便利
クラウドフロント・コンテンツビューワについて
- 読者が選んだ好きな作品を週刊誌として定期購読するビジネス
- ユーザー x コンテンツ分のデータが毎週作成される
- 雑誌的なUIを実現
- 目次からジャンプ
- 次の話に飛ぶ
表紙を作ることも可能
- 表紙もパーソナライズ可能
- コンテンツはS3上に設置
- 暗号化・難読化されたデータを隠蔽されたURLで CloudFront 経由で配信
- 難読化→画像をジグソーパズルのように分割してS3に設置。クライアントでピースを合体する
デジタルコミックス製作フロー
- 書誌作成
- EPUB作成依頼
- EPUBをオーサリング会社から納品
- 目次作成
- 検品
- ストア(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 でタグを適切に設定
- そのユーザーしかインスタンスの変更・停止をできないようにする
運用と監視
- 複数ベンダーが関わって運営 − アプリ開発とインフラ会社が別
- アプリケーションが正常に動いていることの担保・問題の切り分けを運用／監視側が行えるような工夫が必要
感想
普段は見聞きすることの少ない電子書籍の製作フローについて話が聞けて貴重でした。
ストレージシステムを複数用意し、コンテンツのアクセスパターンに応じてストレージを使い分けるアイデアは、電子書籍に限らず、サービスの運用者にとって、参考になるのではないでしょうか。
14
