JAWS DAYS 2020 メディアドゥスポンサーセッション/jaws-days-2020-mediado

by kent-hamaguchi

Slide 1

Slide 1 text

AWSを用いた書店システムの大規模改修 JAWS DAYS 2020 メディアドゥスポンサーセッション

Slide 2

Slide 2 text

本セッションの内容 ● 拡張に対して硬直状態のシステムへ、大幅な改修にどう対応したのか ● 活用したAWSのサービス、事例・設計パターン

Slide 3

Slide 3 text

メディアドゥについて

Slide 4

Slide 4 text

株式会社メディアドゥ ● 電子書籍の取次事業の国内シェア No1 ● 東証一部上場 ○ メディアドゥホールディングスが東証一部上場企業 ● エンジニアは約100名

Slide 5

Slide 5 text

株式会社メディアドゥ最先端のテクノロジーにより電子書籍の流通事業を推進し、電子書籍市場、ひいては出版市場の拡大を目指しています。

Slide 6

Slide 6 text

6 作者電子書店読者情報の集積出版社電子書籍の取次事業

Slide 7

Slide 7 text

自己紹介

Slide 8

Slide 8 text

濱口賢人 ● 2012年メディアドゥ新卒入社 ● 担当業務 ○ 基幹システムの開発と保守 ● 開発チーム(6人程)のリーダー

Slide 9

Slide 9 text

濱口賢人 ● 開発手法 ○ スクラム ○ Clean Architecture, DDD ● 技術スタック ○ C, Java, PHP, Go, Python ○ クラウド, 主にAWS ○ オンプレミス運用, 監視など ○ バックエンド, フロントエンド ● 趣味 ○ システム開発, ギター, ゲーム

Slide 10

Slide 10 text

濱口賢人組織・事業の拡大に伴い、電子書店を運用するための自社システム(Java, PHP)を AWSとGo中心の作りへ改善中。

Slide 11

Slide 11 text

セッション内容について

Slide 12

Slide 12 text

流れ ● システムの統合 ● AWS活用方法・設計パターン ● 最終的なアーキテクチャ ● 今後のこと

Slide 13

Slide 13 text

システムの統合

Slide 14

Slide 14 text

システムの統合 - 背景 ● 取次を行う流通システム以外に、電子書店を運営するシステムがある ○ 取次システムとして基幹システムあり ○ 取次システムに依存する形で、書店システムあり ● 会社の統合により、基幹システムを2つ抱えることになった ○ メディアドゥがもともと持っていた基幹システムを基幹システム Aとする ○ 会社の統合により、基幹システム Bの運用も一緒に運営することに ● 今後の事業展開のために、基幹システムAから基幹システムBへ運用を統合 ○ それにより、書店システムは依存先を基幹システム Bへ移すことへ...

Slide 15

Slide 15 text

基幹システムA 基幹システムB 書店システム作品情報や、キャンペーン情報の連携購入やダウンロードなどの連携これを繋ぎ変えたい

Slide 16

Slide 16 text

システムの統合 - 課題 ● 書店システムで稼働している電子書店は多数 ○ 基幹システムの切替が電子書店分だけ発生する、どうやって両立させるのか？ ● 書店システムが稼働しているのはオンプレ、複雑なソフトウェア ○ 物理的(サーバ)にも論理的(ソースコード)にも追加の改修が難しい状態 ○ 変更に弱く、その影響が見えない ● 全社的にはオンプレ → クラウド(AWS)へ移行の方針 ○ オンプレへのリソース追加の余幅は乏しい ○ 容易にはコンピューティングリソースは確保できない

Slide 17

Slide 17 text

● 書店システムには直接手を入れず、中間システムを新規に作ることにした ○ 基幹システムAと同じ会話で基幹システム Bを扱うための、書店システム向けのもの ● 新規に作るので環境はクラウド(AWS)にした ○ オンプレのリソースに直接アタッチする部分だけオンプレで動かす ● 開発言語もPHP、JavaからGoへ変更した ○ チームが若手中心なのでキャッチアップしやすい言語が良い ○ Dockerで動かすならポータビリティの観点で Goが有利、パフォーマンスも出る ○ Infrastructure as Code(IaC)はTypeScript(AWS CDKのため) ○ DevOpsはPython (AWS Lambdaでサッと作りたいため ) システムの統合 - 解決方法

Slide 18

Slide 18 text

基幹システムA 基幹システムB 書店システム基幹システムAと同じ内容で基幹システム Bを扱う ● HTTPで会話する部分はAPI仕様を踏襲中間システム ● 外部仕様を踏襲 ● 内部ロジックも必要箇所は踏襲書店システムの内部仕様に合わせてバッチ処理 ● DBへのデータ登録 ● ストレージへのファイル配置

Slide 19

Slide 19 text

● システム自身をクラウドリフトするのは別途対応予定 ● 今回はオンプレの既存システムに求められるシステム改修に対する部分システムの統合 - 解決方法

Slide 20

Slide 20 text

AWSの活用方法

Slide 21

Slide 21 text

● スケーラブルな設計を随所で見るので、それをやってみる ○ オンプレが受けきれるレベルがシステム全体の処理性能の上限ではある ○ 1からの開発になるので、今後の知見としてもマネージドサービスの活用事例を作る目的 ● ECS(Fargate)、Lambda、DynamoDB、S3、Personalizeを利用した ● その他、CI/CDでCodeBuild、CodePipelineを利用した AWSの活用方法

Slide 22

Slide 22 text

AWSの活用方法マスタデータ連携パターン

Slide 23

Slide 23 text

直面した問題 ● 数百万の作品データ(メタデータ)を基幹システムBから取り寄せる ● 電子書店サービスが数十あるため、スケールできる必要がある ○ オンプレの既存処理ではかなり時間がかかっていた ○ 時間がかかる処理は開発・テストの速度も鈍化させるので、素早くしたい ● オンプレのDBを活かしつつ、どうやって新しいデータを大量に取り込むのか AWSの活用方法: マスタデータ連携パターン

Slide 24

Slide 24 text

基幹システムA 書店システムバッチ PHP 基幹システムA ストレージ変更前作品データ配置取得書店システム DB PostgreSQL データ変換、記録最終的にDBのレコードが期待する形に更新されていれば良い

Slide 25

Slide 25 text

基幹システムB 変更後作品データ取得 (基幹システムAとは、内容がかなり異なる ) 書店システム DB PostgreSQL 中間システムバッチ AWS ECS(Fargate) 中間システムストレージ AWS S3 データ変換、配置中間システムバッチオンプレ Docker動く変換結果取得記録中間システムデータストア DynamoDB データの違いを調整つけるためのデータを登録 (後述のWebAPIで使う)

Slide 26

Slide 26 text

解決法 ● ロジックが集約され、かつスケールが必要な箇所はFargateを利用 ● オンプレに直接通信が必要な箇所はオンプレにDocker用のサーバを立てた ○ 実行するプログラム自体は ECRから都度pullする ○ そのため、CodeBuildなどを通してECRに上がった最新イメージを使うことができる ○ オンプレDBへVPN越しにAWSから直接データ更新をかけるのは速度が出なかった ○ オンプレDBの処理性能の上限があるので、ここは過剰にスケールする必要がない AWSの活用方法: マスタデータ連携パターン

Slide 27

Slide 27 text

ポイント ● Fargateなどリソースを即調達できる部分に処理を集中させる ● S3に処理結果を配置して、オンプレ側がそれを読み取るのみ ○ メタデータだけでなく、書籍の表紙画像などの保存先にも利用 ● ECRにアプリケーションを集約し、オンプレではDocker runさせるのみ ● データ量に対して性能劣化しにくいDynamoDBをDBとした AWSの活用方法: マスタデータ連携パターン

Slide 28

Slide 28 text

AWSの活用方法オンライン処理パターン

Slide 29

Slide 29 text

直面した問題 ● 数十の電子書店の購入や書籍ダウンロードのリクエストに対応する ● 変更前と変更後でHTTP通信の経路が増えるが、応答が送れないようにする ○ 応答遅延は防ぎたい、できる限り高速に対応するように ● キャンペーンなどアクセスがスパイクする際にも対応できる形へ ● 購入履歴などのデータは随時溜まる、性能劣化しないデータストアが良い AWSの活用方法: オンライン処理パターン

Slide 30

Slide 30 text

基幹システムA 書店システム WebAPI Java 変更前ダウンロード権限付与書店システム DB PostgreSQL 作品やユーザの照合売上記録書籍購入書籍本体を閲覧してよいか元締めは基幹システムが担当

Slide 31

Slide 31 text

基幹システムB 書店システム WebAPI Java 変更後ダウンロード権限付与 (基幹システムAと、同じI/F仕様) 書店システム DB PostgreSQL 作品やユーザの照合売上記録 (既存のまま) 書籍購入リクエスト中間システム WebAPI AWS ECS(Fargate) 中間システムデータストア DynamoDB 新規開発した部分で、追加で必要なデータ照合ダウンロード権限付与

Slide 32

Slide 32 text

解決法 ● WebはMulti-AZで冗長性を持たせ、スケールできるようにFargateを選択 ○ Lambdaも検討したがリクエストスパイクへの対応等検討してコンテナを選択 ○ リクエストが想定よりも少なければタスク数を減らすことでコストカットできる ● ユーザの購入履歴など随時追加されるデータストアにDynamoDBを利用 ○ 1千万レコード、容量 1GBを超えた現在も数ミリ秒での応答を実現 ○ データで大量登録が必要なシーンはプロビジョニングしてキャパシティユニットを取る ○ 以降はオンデマンドに切り替えるなどの方法で、リソース・コストを柔軟に対応できる AWSの活用方法: オンライン処理パターン

Slide 33

Slide 33 text

ポイント ● Fargate+DynamoDBの力で求めていた応答速度とスケーラビリティを実現 ○ アプリケーション部分が Goであることも起因 ● リクエストに応じた柔軟なリソース調達・コストカットが可能に AWSの活用方法: オンライン処理パターン

Slide 34

Slide 34 text

AWSの活用方法レコメンド

Slide 35

Slide 35 text

直面した問題 ● 基幹システムAは購入履歴を元にオススメ作品を出す機能を提供していた ○ レコメンド機能 ● 基幹システムBにはレコメンド機能が存在せず、自作する必要が出た ● レコメンドの自作はハードルが高い AWSの活用方法: レコメンド

Slide 36

Slide 36 text

基幹システムA レコメンド WebAPI 変更前購入履歴に基づいてレコメンド情報を作成書店システム WebAPI Java 電子書店閲覧レコメンド取得オススメコーナーにレコメンド結果を表示

Slide 37

Slide 37 text

変更後書店システム WebAPI Java 電子書店閲覧オススメコーナーにレコメンド結果を表示中間システム WebAPI AWS ECS(Fargate) レコメンド取得 (基幹システムAと、同じI/F仕様) AWS Personalize 類推結果取得中間システムバッチオンプレ Docker動く書店システム DB PostgreSQL 作品データ、購入履歴取得機械学習実行 AWS S3 データ配置中間システムバッチ AWS Lambda 参照

Slide 38

Slide 38 text

解決法 ● レコメンドを提供するマネージドサービスのPersonalizeを利用する ○ 機械学習を用いたレコメンドに特化したサービス ○ 学習ルールのアルゴリズムなどを用途に合わせて選択可能 ● Personalizeに命令を出すだけの簡素なバッチはLambdaで運用する ○ aws-cliのコマンドでも良かったけど、運用ルールも絡むため Goで実装した ■ aws-sdk-go-v2を使用した ○ Dockerイメージの管理が必要ない分運用が楽 AWSの活用方法: レコメンド

Slide 39

Slide 39 text

ポイント ● レコメンドの内部ロジックを、一切実装すること無く機能を作成 ● Personalizeはスケーラビリティもある ○ 事前にRPSに基づいてリソース確保できるが、利用料が増えたらその分スケールされる ■ 料金は最大RPSに基づいて計算される、詳細はドキュメントを参照 ● Personalizeへの命令をLambdaで実装 ○ aws-cliで都度コマンドを実行するよりも、プログラム化してサービス要件を埋め込んだ ○ 学習レシピや類推結果のキャンペーン情報などの作成を自動化した AWSの活用方法: レコメンド

Slide 40

Slide 40 text

AWSの活用方法: レコメンド aws-sdk-go-v2を活用したPersonalizeの処理は、弊社エンジニアが執筆した技術書で紹介しています！「Tech Do Book第3巻を執筆しました【電子版DLリンクあり！】」 https://techdo.mediado.jp/entry/2020/03/24/090000

Slide 41

Slide 41 text

最終的なアーキテクチャ

Slide 42

Slide 42 text

AWS オンプレ DB Web (既存Java) バッチ (既存PHP) バッチ (Docker) Batch Web 登録参照登録 pull 分散 HTTPS pull 参照

Slide 43

Slide 43 text

今後のこと

Slide 44

Slide 44 text

● 運用フェーズに入ったら効率化を図りコストカットを目指す ● 現在はオンプレとAWSのハイブリッド、最終的にはクラウドリフトを予定今後のこと

Slide 45

Slide 45 text

メディアドゥの紹介

Slide 46

Slide 46 text

MISSION 著作物の健全なる創造サイクルの実現 VISION ひとつでも多くのコンテンツを、ひとりでも多くの人へ

Slide 47

Slide 47 text

情報発信 Twitter https://twitter.com/mediado_dev エンジニアブログ https://techdo.mediado.jp/

Slide 48

Slide 48 text

We’re Hiring ! ● Engineer ● Engineering Manager ● Product Owner https://recruit.mediado.jp/

Slide 49

Slide 49 text

No content