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

JAWS DAYS 2020にて、株式会社メディアドゥとしてスポンサーセッションで後悔したスライドです。

Transcript

1. AWSを用いた 書店システムの大規模改修 JAWS DAYS 2020 メディアドゥスポンサーセッション
2. 本セッションの内容 • 拡張に対して硬直状態のシステムへ、大幅な改修にどう対応したのか • 活用したAWSのサービス、事例・設計パターン
3. メディアドゥについて
4. 株式会社 メディアドゥ • 電子書籍の取次事業の 国内シェア No1 • 東証一部上場 ◦ メディアドゥホールディングスが 東証一部上場企業 • エンジニアは約100名
5. 株式会社 メディアドゥ 最先端のテクノロジーにより 電子書籍の流通事業を推進し、 電子書籍市場、ひいては 出版市場の拡大を目指しています。
6. 6 作 者 電 子 書 店 読 者 情報の集積 出 版 社 電子書籍の取次事業
7. 自己紹介
8. 濱口賢人 • 2012年 メディアドゥ新卒入社 • 担当業務 ◦ 基幹システムの開発と保守 • 開発チーム(6人程)のリーダー
9. 濱口賢人 • 開発手法 ◦ スクラム ◦ Clean Architecture, DDD • 技術スタック ◦ C, Java, PHP, Go, Python ◦ クラウド, 主にAWS ◦ オンプレミス運用, 監視など ◦ バックエンド, フロントエンド • 趣味 ◦ システム開発, ギター, ゲーム
10. 濱口賢人 組織・事業の拡大に伴い、 電子書店を運用するための 自社システム(Java, PHP)を AWSとGo中心の作りへ改善中。
11. セッション内容について
12. 流れ • システムの統合 • AWS活用方法・設計パターン • 最終的なアーキテクチャ • 今後のこと
13. システムの統合
14. システムの統合 - 背景 • 取次を行う流通システム以外に、電子書店を運営するシステムがある ◦ 取次システムとして基幹システムあり ◦ 取次システムに依存する形で、書店システムあり • 会社の統合により、基幹システムを2つ抱えることになった ◦ メディアドゥがもともと持っていた基幹システムを基幹システム Aとする ◦ 会社の統合により、基幹システム Bの運用も一緒に運営することに • 今後の事業展開のために、基幹システムAから基幹システムBへ運用を統合 ◦ それにより、書店システムは依存先を基幹システム Bへ移すことへ...
15. 基幹システムA 基幹システムB 書店システム 作品情報や、キャンペーン情報の連携 購入やダウンロードなどの連携 これを繋ぎ変えたい
16. システムの統合 - 課題 • 書店システムで稼働している電子書店は多数 ◦ 基幹システムの切替が電子書店分だけ発生する、どうやって両立させるのか？ • 書店システムが稼働しているのはオンプレ、複雑なソフトウェア ◦ 物理的(サーバ)にも論理的(ソースコード)にも追加の改修が難しい状態 ◦ 変更に弱く、その影響が見えない • 全社的にはオンプレ → クラウド(AWS)へ移行の方針 ◦ オンプレへのリソース追加の余幅は乏しい ◦ 容易にはコンピューティングリソースは確保できない
17. • 書店システムには直接手を入れず、中間システムを新規に作ることにした ◦ 基幹システムAと同じ会話で基幹システム Bを扱うための、書店システム向けのもの • 新規に作るので環境はクラウド(AWS)にした ◦ オンプレのリソースに直接アタッチする部分だけオンプレで動かす • 開発言語もPHP、JavaからGoへ変更した ◦ チームが若手中心なのでキャッチアップしやすい言語が良い ◦ Dockerで動かすならポータビリティの観点で Goが有利、パフォーマンスも出る ◦ Infrastructure as Code(IaC)はTypeScript(AWS CDKのため) ◦ DevOpsはPython (AWS Lambdaでサッと作りたいため ) システムの統合 - 解決方法
18. 基幹システムA 基幹システムB 書店システム 基幹システムAと同じ内容で基幹システム Bを扱う • HTTPで会話する部分はAPI仕様を踏襲 中間システム • 外部仕様を踏襲 • 内部ロジックも必要箇所は踏襲 書店システムの内部仕様に合わせてバッチ処理 • DBへのデータ登録 • ストレージへのファイル配置
19. • システム自身をクラウドリフトするのは別途対応予定 • 今回はオンプレの既存システムに求められるシステム改修に対する部分 システムの統合 - 解決方法
20. AWSの活用方法
21. • スケーラブルな設計を随所で見るので、それをやってみる ◦ オンプレが受けきれるレベルがシステム全体の処理性能の上限ではある ◦ 1からの開発になるので、今後の知見としてもマネージドサービスの活用事例を作る目的 • ECS(Fargate)、Lambda、DynamoDB、S3、Personalizeを利用した • その他、CI/CDでCodeBuild、CodePipelineを利用した AWSの活用方法
22. AWSの活用方法 マスタデータ連携パターン
23. 直面した問題 • 数百万の作品データ(メタデータ)を基幹システムBから取り寄せる • 電子書店サービスが数十あるため、スケールできる必要がある ◦ オンプレの既存処理ではかなり時間がかかっていた ◦ 時間がかかる処理は開発・テストの速度も鈍化させるので、素早くしたい • オンプレのDBを活かしつつ、どうやって新しいデータを大量に取り込むのか AWSの活用方法: マスタデータ連携パターン
24. 基幹システムA 書店システム バッチ PHP 基幹システムA ストレージ 変更前 作品データ配置 取得 書店システム DB PostgreSQL データ変換、記録 最終的にDBのレコードが 期待する形に更新されていれば良い
25. 基幹システムB 変更後 作品データ取得 (基幹システムAとは、 内容がかなり異なる ) 書店システム DB PostgreSQL 中間システム バッチ AWS ECS(Fargate) 中間システム ストレージ AWS S3 データ変換、配置 中間システム バッチ オンプレ Docker動く 変換結果取得 記録 中間システム データストア DynamoDB データの違いを調整つける ためのデータを登録 (後述のWebAPIで使う)
26. 解決法 • ロジックが集約され、かつスケールが必要な箇所はFargateを利用 • オンプレに直接通信が必要な箇所はオンプレにDocker用のサーバを立てた ◦ 実行するプログラム自体は ECRから都度pullする ◦ そのため、CodeBuildなどを通してECRに上がった最新イメージを使うことができる ◦ オンプレDBへVPN越しにAWSから直接データ更新をかけるのは速度が出なかった ◦ オンプレDBの処理性能の上限があるので、ここは過剰にスケールする必要がない AWSの活用方法: マスタデータ連携パターン
27. ポイント • Fargateなどリソースを即調達できる部分に処理を集中させる • S3に処理結果を配置して、オンプレ側がそれを読み取るのみ ◦ メタデータだけでなく、書籍の表紙画像などの保存先にも利用 • ECRにアプリケーションを集約し、オンプレではDocker runさせるのみ • データ量に対して性能劣化しにくいDynamoDBをDBとした AWSの活用方法: マスタデータ連携パターン
28. AWSの活用方法 オンライン処理パターン
29. 直面した問題 • 数十の電子書店の購入や書籍ダウンロードのリクエストに対応する • 変更前と変更後でHTTP通信の経路が増えるが、応答が送れないようにする ◦ 応答遅延は防ぎたい、できる限り高速に対応するように • キャンペーンなどアクセスがスパイクする際にも対応できる形へ • 購入履歴などのデータは随時溜まる、性能劣化しないデータストアが良い AWSの活用方法: オンライン処理パターン
30. 基幹システムA 書店システム WebAPI Java 変更前 ダウンロード権限付 与 書店システム DB PostgreSQL 作品やユーザの照合 売上記録 書籍購入 書籍本体を閲覧してよいか 元締めは基幹システムが担当
31. 基幹システムB 書店システム WebAPI Java 変更後 ダウンロード権限付与 (基幹システムAと、 同じI/F仕様) 書店システム DB PostgreSQL 作品やユーザの照合 売上記録 (既存のまま) 書籍購入リクエスト 中間システム WebAPI AWS ECS(Fargate) 中間システム データストア DynamoDB 新規開発した部分 で、追加で必要な データ照合 ダウンロード権限付与
32. 解決法 • WebはMulti-AZで冗長性を持たせ、スケールできるようにFargateを選択 ◦ Lambdaも検討したがリクエストスパイクへの対応等検討してコンテナを選択 ◦ リクエストが想定よりも少なければタスク数を減らすことでコストカットできる • ユーザの購入履歴など随時追加されるデータストアにDynamoDBを利用 ◦ 1千万レコード、容量 1GBを超えた現在も数ミリ秒での応答を実現 ◦ データで大量登録が必要なシーンはプロビジョニングしてキャパシティユニットを取る ◦ 以降はオンデマンドに切り替えるなどの方法で、リソース・コストを柔軟に対応できる AWSの活用方法: オンライン処理パターン
33. ポイント • Fargate+DynamoDBの力で求めていた応答速度とスケーラビリティを実現 ◦ アプリケーション部分が Goであることも起因 • リクエストに応じた柔軟なリソース調達・コストカットが可能に AWSの活用方法: オンライン処理パターン
34. AWSの活用方法 レコメンド
35. 直面した問題 • 基幹システムAは購入履歴を元にオススメ作品を出す機能を提供していた ◦ レコメンド機能 • 基幹システムBにはレコメンド機能が存在せず、自作する必要が出た • レコメンドの自作はハードルが高い AWSの活用方法: レコメンド
36. 基幹システムA レコメンド WebAPI 変更前 購入履歴に基づいてレコメンド情報を作成 書店システム WebAPI Java 電子書店閲覧 レコメンド取得 オススメコーナーに レコメンド結果を表示
37. 変更後 書店システム WebAPI Java 電子書店閲覧 オススメコーナーに レコメンド結果を表示 中間システム WebAPI AWS ECS(Fargate) レコメンド取得 (基幹システムAと、 同じI/F仕様) AWS Personalize 類推結果取得 中間システム バッチ オンプレ Docker動く 書店システム DB PostgreSQL 作品データ、購入履歴取 得 機械学習実行 AWS S3 データ配置 中間システム バッチ AWS Lambda 参照
38. 解決法 • レコメンドを提供するマネージドサービスのPersonalizeを利用する ◦ 機械学習を用いたレコメンドに特化したサービス ◦ 学習ルールのアルゴリズムなどを用途に合わせて選択可能 • Personalizeに命令を出すだけの簡素なバッチはLambdaで運用する ◦ aws-cliのコマンドでも良かったけど、運用ルールも絡むため Goで実装した ▪ aws-sdk-go-v2を使用した ◦ Dockerイメージの管理が必要ない分運用が楽 AWSの活用方法: レコメンド
39. ポイント • レコメンドの内部ロジックを、一切実装すること無く機能を作成 • Personalizeはスケーラビリティもある ◦ 事前にRPSに基づいてリソース確保できるが、利用料が増えたらその分スケールされる ▪ 料金は最大RPSに基づいて計算される、詳細はドキュメントを参照 • Personalizeへの命令をLambdaで実装 ◦ aws-cliで都度コマンドを実行するよりも、プログラム化してサービス要件を埋め込んだ ◦ 学習レシピや類推結果のキャンペーン情報などの作成を自動化した AWSの活用方法: レコメンド
40. AWSの活用方法: レコメンド aws-sdk-go-v2を活用したPersonalizeの処理は、 弊社エンジニアが執筆した技術書で紹介しています！ 「Tech Do Book第3巻を執筆しました【電子版DLリンクあり！】」 https://techdo.mediado.jp/entry/2020/03/24/090000
41. 最終的なアーキテクチャ
42. AWS オンプレ DB Web (既存Java) バッチ (既存PHP) バッチ (Docker) Batch Web 登録 参照 登録 pull 分散 HTTPS pull 参照
43. 今後のこと
44. • 運用フェーズに入ったら効率化を図りコストカットを目指す • 現在はオンプレとAWSのハイブリッド、最終的にはクラウドリフトを予定 今後のこと
45. メディアドゥの紹介
46. MISSION 著作物の健全なる創造サイクルの実現 VISION ひとつでも多くのコンテンツを、ひとりでも多くの人へ
47. 情報発信 Twitter https://twitter.com/mediado_dev エンジニアブログ https://techdo.mediado.jp/
48. We’re Hiring ! • Engineer • Engineering Manager • Product Owner https://recruit.mediado.jp/