Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Ähnlich wie Engineer LT #2 高負荷サービスを改善した軌跡
Ähnlich wie Engineer LT #2 高負荷サービスを改善した軌跡 (20)
Mehr von 賢 秋穂
Engineer LT #2 高負荷サービスを改善した軌跡
- 1. 高負荷サービスを改善した軌跡 Engineer LT #2 サーバーサイド 〜Webサービスの裏側〜 株式会社U-NEXT R&D部 秋穂 賢
- 2. JavaやGolangを使ったサーバAPI開発 作品やエピソードなどのメタデータを管理する システムがメイン担当 自己紹介 氏名 秋穂 賢（あきほ すぐる） @ken-aio 所属 株式会社U-NEXT R&D部 仕事
- 5. ○ システムの歴史 ○ 地道な改善 ○ Varnish ○ アーキテクチャの再考 ○ 脱MySQL ○ 今後の展望 目次
- 6. ○ 2015年01月 U-NEXTへ入社 ○ 2015年10月 Videoサービスリニューアル □ 時間がない中のカオスな開発 □ 地道な改善が大きな効果 ○ 2019年01月 Bookサービスリニューアル □ Videoの反省を活かした構成変更 ○ 2019年12月 脱MySQL ○ 202x年xx月 アーキテクチャの一新 歴史
- 10. Slow Query exists -> in 作品 - ワンピース - こち亀 エピソード - 1話 - 2話 … 1 N ワンピースの商品をください 商品 - 見放題 - ポイント … 1 N
- 11. select * from product where exists ( select * from episode where episode.id = product.episode_id and exists ( select * from sakuhin where sakuhin.id = episode.sakuhin_id and sakuhin.code = ‘SID0042235’ – ワンピース ) ) Slow Query exists -> in 作品 - ワンピース - こち亀 エピソード - 1話 - 2話 … 1 N 商品 - 見放題 - ポイント … 1 N
- 12. select * from product where exists ( select * from episode where episode.id = product.episode_id and exists ( select * from sakuhin where sakuhin.id = episode.sakuhin_id and sakuhin.code = ‘SID0042235’ – ワンピース ) ) Slow Query exists -> in 作品 - ワンピース - こち亀 エピソード - 1話 - 2話 … 1 N 商品 - 見放題 - ポイント … 1 N 3000ms
- 13. select * from product where product.episode_id in ( select id from episode where episode.id = product.episode_id and episode.sakuhin_id ( select id from sakuhin where sakuhin.id = episode.sakuhin_id and sakuhin.code = ‘SID0042235’ – ワンピース ) ) Slow Query exists -> in 作品 - ワンピース - こち亀 エピソード - 1話 - 2話 … 1 N 商品 - 見放題 - ポイント … 1 N 50ms
- 14. ○ existsの内側が絞り込めていて、外側が絞り込まれ ていない状態 □ 激しいSlow Query ○ existsの場合に外側から実行される ○ Inを使うことで内側から実行されるようになる ○ 結果、SQLで大きな改善に ○ 「当社比100倍」のキーワードで改善 Slow Query exists -> in
- 15. ○ 重いSQLの結果はRedisにキャッシュ ○ MySQLに入っているマスターデータの一部は Java起動時にメモリにキャッシュ ○ N+1 QueryやN+1のAPIリクエストをバッチロー ド/リクエストに ○ システム負荷の高いサービス仕様をPOと話し て別の仕様に変更 その他改善 地道な改善の結果 負荷要因によるサービス障害の頻度が下がる APMを利用
- 16. Varnish BFF (PHP) Varnish Java API 1000ms 1000ms 初回リクエスト BFF (PHP) Varnish Java API 1~10ms 2回目以降のリクエスト キャッシュにあれば バックエンドリクエスト にいかない サービス特性上、Varnishがフィットした （VODのメタデータはマスターデータの塊）
- 17. アーキテクチャ変更
- 18. ○ それから数年後にBookリニューアルのPJ ○ BFF → バックエンドAPIで並列呼び出しをしたい ケースが多々 ○ BFFがPHPで言語的に並列呼び出しがやりづ らかった □ それでもある程度はやっていた ○ もっと並列実行が得意なものを使いたい Bookリニューアル BFFレイヤーにGolangを採用
- 21. どこにいれるか BFF (PHP) Varnish Java API Golang ○ 平均ResponseTimeが大幅に改善 ○ アプリケーションの構成も変えて保守性も向上 （静的型の恩恵も大きい） □ PHPはUnitTestがないがgolangではUnitTestも導入
- 23. ○ ユーザ情報を格納していたMySQLがとにかく 重い □ 特に視聴履歴のデータは爆発 ○ Bookリニューアルのタイミングで別のソリュー ションないか探した ○ 色々と試行錯誤した結果（詳細省略） Cassandraをユーザ情報のDBとして利用 脱MySQL part 1
- 24. ○ NoSQLデータベースでインスタンスを追加する とリニアにスケールするシステム ○ Netflixでも大々的に採用されていた ○ U-NEXTでも採用することに ○ ただし、結果整合性やNoSQL独自の仕組みで 使いづらい部分も多々ある Cassandra 結果 パフォーマンス向上し、Cassandra起因での障 害なく安定稼働
- 25. ○ BookはCassandraを採用してある程度うまく いった ○ 一方、VideoはMySQLのまま ○ そこで、MySQL互換のNewSQLであるTiDB を採用 脱MySQL part2
- 27. ○ いくつかMySQLのSQLを修正したが、基本的にア プリケーションは何も変えずにMySQLからTiDBに 切り替えが完了 □ ユーザ情報を格納するDBに外部キーが少なく、テーブル間 の関連が少なかったことが大きい ○ MySQLよりパフォーマンス、安定性が向上 ○ なにより使い慣れたMySQL周辺ツールが使えるメ リットは大きい 脱MySQL part2 TiDBがU-NEXTの実質標準に
- 28. さらにその先へ
- 29. ○ 色々改善をしてきたけど、メタデータ管理は MySQLのまま —---------------------------------- ○ あたらしい世界はGraphDBやTiDB □ サービスではMySQLは利用しない ○ BFFはGraphQL（node）を採用 ○ サーバ間通信はgRPCを採用 ○ デプロイはk8s ○ 絶賛開発中 マイクロサービス を進める
- 30. 最後に