オイラ大地のECサイトのマイクロサービス化をVA Linuxが性能分析してみた

A batch job running on Oisixradaichi, an E-commerce site, has been troubled by performance issues. To solve the issue, it is now being re-made as microservices.
Then, a few key perfomance metrics are analyzed to find out possible improvements in job execution strategies.

This presentation is a collaborative work with Kobayashi-san.

Transcript

1. オイラ大地のECサイトの
 マイクロサービス化を
 VA Linuxが性能分析してみた
 岩本俊弘 <iwamoto@valinux.co.jp> 小林弘明 <kobayashi_hiroaki@oisixradaichi.co.jp>
2. これまでのあらすじ • Jaeger とかの tracing かっこいい • システムの負荷とあわせて分析すると何かみえるはず ◦ CNDT2018冬発表 ◦ 人工的に作成した負荷 • オイシックス・ラ・大地さんから話をいただいた • 今日は運用中のサービスでやります
3. 分析するとわかること • グラフを描くとたのしい • ボトルネックがあって性能が出ていなかったり • 無駄にスペックが余ってるともったいないですよね? 実際のサービスの細かい実装を知らずにどこまで分析できるかやってみます
4. 1. 自己紹介・Oisixの紹介
 
 2. これまでのマイクロサービスの取り組み
 
 3. 今回分析したサービスについて
 
 4. マイクロサービス化への試行錯誤1
 
 5. マイクロサービス化への試行錯誤2

5. 小林弘明（こばやし ひろあき）
 自己紹介 オイシックス・ラ・大地株式会社
 　システム本部
 　　システム基盤部
 　　　基盤刷新セクション
 　　　　シニアアーキテクト
 主な担当業務はマイクロサービス推進

7. 略称(弊社公式)

8. 今日はこのブランドの お話になります
9. Oisixは
 2000年創業の
 生鮮食品の
 ネットショップ

10. メインのサービスは「おいしっくすくらぶ」
 献立に悩まない手料理キット「Kit Oisix」をはじめ、
 肉や魚・加工品までOisixがおすすめする
 商品を毎週ご提案いたします。→サブスクリプションモデル
 
 お客様の好みに合わせて商品の入れ替えや数量変更など、
 約4,000種類の取り扱いアイテムから自由にアレンジが可能。
 
 もちろん、お休みやキャンセルも
 WEB上でかんたんにできます。
 

11. 最近の
 ヒット商品は
 Kit Oisix
 (ミールキット)

12. 最近始まったサービスは、
 Oisix Prime Pass

14. ブースで
 お配りしてます!!

15. 1. 自己紹介・Oisixの紹介
 
 2. これまでのマイクロサービスの取り組み
 
 3. 今回分析したサービスについて
 
 4. マイクロサービス化への試行錯誤1
 
 5. マイクロサービス化への試行錯誤2

16. システムは伝統的なモノリシックな構成のた め、近年のECサイトの成長により、
 アプリケーション/インフラの両面で問題が発 生
 
 1. 品質の維持
 2. ローンチスピード
 3. スケーラビリティ
 これまでのマイクロサービスの取り組み

17. 2018年
 モノリシック構成の問題を
 解消するため
 マイクロサービス化に着手
 昨年の状態は詳しくはこちらで 
 
 オイラ大地の18年拡張し続けているECサイトを 
 Spring Bootとk8s on Azureでマイクロサービス化する事例(JJUG 2018 秋) 
 https://www.slideshare.net/hiroakikobayashi1806/18ecspring-bootk8s-on-azure 
 
 ストラングラーパターンによる(JJUG 2019 春) 
 マイクロサービスマイグレーションの勘所 
 https://speakerdeck.com/kawakamitor/jjug-ccc-2019-spring 
 
 これまでのマイクロサービスの取り組み

18. Oisixのマイクロサービス開発環境
 開発マシンはWindowsとMacから開発者が希望する方 IDEもどちらでも Gradleが動けば 言語は JavaかKotlin Spring Bootベースでテンプレートを用意 API定義はSwaggerを使用
19. Kubernetes OisixのCICD GitOps
 Docker Hub Java repo kustomization.yaml manifest repo GitHub CircleCI は 3. PR 4. CI 5. pull 6. push 7. PR CI CD 1. pull 2. push 8. CD GitOps で構成
20. 監視系 Oisixのクラウド構成
 AKS(k8s) Azure Storage Queue Azure MySQL Azure Redis Cache ブラウザ iPhone App Android App Log Analytics Monitor WWW VM オンプレミス API Management IDCF Cloud
21. Oisixのマイクロサービスの方針
 ストラングラーパターン
 
 IDCF CloudとAzureを使用した
 マルチクラウド構成
 
 共有データベースの
 段階的な分離
 1.
 
 2.
 
 
 3.
22. 1. 自己紹介・Oisixの紹介
 
 2. これまでのマイクロサービスの取り組み
 
 3. 今回分析したサービスについて
 
 4. マイクロサービス化への試行錯誤1
 
 5. マイクロサービス化への試行錯誤2

23. 今回分析したサービス
 「おいしっくすくらぶ」
 を支える、
 ECサイトシステムでは
 最大規模のバッチ
 「定期ボックス作成バッチ」

24. 今回のお題「定期ボックス作成バッチ」
 第n-1週
 木曜日
 毎週木曜日は定期ボックスが切り替わる変わる1日。
 契約いただいているお客様1人1人に、
 専用のカート(=定期ボックス)をご用意し、
 サイト上で自由にお買い物をしていただく準備をします。
 第n週
 木曜日

25. 準備する定期ボックスの数は数十万件。
 この準備を「定期ボックス作成バッチ」で
 一気に作成しています。
 定期ボックス作成バッチ 
 今回のお題「定期ボックス作成バッチ」
 第n-1週
 木曜日
 第n週
 木曜日

26. 前週カートの確定情報を
 配送センターへ送信
 受注確定バッチ
 配送センターのシステムも巨大でい ろいろ面白いですが、コンテナ化は これからなので今日は割愛。 
 海老名配送センター 
 (全国へ出荷)
 木曜日は「定期ボックス作成バッチ」
 の前後でも、バッチとオペレーションでタイ ムテーブルがぎっしり。
 今回のお題「定期ボックス作成バッチ」
 Webサイト
 開始の準備
 定期ボックス作成バッチ 
 第n-1週
 木曜日
 第n週
 木曜日
 開始のお知らせ
 バッチ
 etc

27. 前週カートの確定情報を
 配送センターへ送信
 受注確定バッチ
 配送センターのシステムも巨大でい ろいろ面白いですが、コンテナ化は これからなので今日は割愛。 
 海老名配送センター 
 (全国へ出荷)
 今回のお題「定期ボックス作成バッチ」
 Webサイト
 開始の準備
 定期ボックス作成バッチ 
 第n-1週
 木曜日
 第n週
 木曜日
 開始のお知らせ
 バッチ
 etc
 昨年の夏頃、お客様数の増加によ り、
 「定期ボックス作成バッチ」が不安 定化。
 モノリス・1インスタンス構成により
 バッチ中はシステム全体が遅くなり、
 社内業務にも支障をきたす状態に。

28. 1. 自己紹介・Oisixの紹介
 
 2. これまでのマイクロサービスの取り組み
 
 3. 今回分析したサービスについて
 
 4. マイクロサービス化への試行錯誤1
 
 5. マイクロサービス化への試行錯誤2

29. 受注確定バッチ
 マイクロサービス化への試行錯誤1
 定期ボックス作成バッチ 
 それ以外の
 ECサイトの販売にかかわる 
 社内システムの大部分 
 ESサイトの社内システムは
 モノリシックな状態。
 実行時も1サーバー1インスタン
 で処理。
 Webサイト
 開始の準備
 開始のお知らせ
 バッチ
 etc

30. とりあえずリフトアンドシフト
 Azure AKS
 (k8s)
 VMで動作していた
 モノリス一式を
 弊社のコンテナ基盤である
 Azure上のAKSに移動
 VM IDCF
31. とりあえずリフトアンドシフト
 Azure AKS
 (k8s)
 データセンターの
 DBはOracle。
 そのままAzureに
 シフトするのは
 無理。
 オンプレミス 無理 VM IDCF
32. とりあえずリフトアンドシフト
 Azure AKS
 (k8s)
 アプリケーションだけ 移すと応答時間が かかりすぎる
 
 →リフトアンドシ フトは断念
 ネットワー ク的に遠い
 オンプレミス VM IDCF
33. 昨年夏頃
 しかし
 可及的速やかに
 問題の解決が必要

34. VM
 定期ボックス
 作成バッチ
 それ以外
 VM
 定期ボックス
 作成バッチ
 それ以外
 可及的速やかな解決策(コンテナ成分ゼロ)
 モノリスをOSごと丸々複製。
 
 モノリス2号機が誕生。
 
 2号機は定期ボックス作成専用にし VMのスペックをあげまくる。
 
 問題にお金で対応して、急場をとり あえずしのげる状態にシステムを 回復させる。
 丸々 COPY モノリス1号
 モノリス2号
 2号機は高いので バッチの時間だけVMを起こす。
35. 1. 自己紹介・Oisixの紹介
 
 2. これまでのマイクロサービスの取り組み
 
 3. 今回分析したサービスについて
 
 4. マイクロサービス化への試行錯誤1
 
 5. マイクロサービス化への試行錯誤2

36. 根本的な解決のため、
 改めて
 マイクロサービス化に挑戦
 マイクロサービス化への試行錯誤2

37. 弊社のマイクロサービス化
 戦略は
 
 ストラングラーパターン
 マイクロサービス化への試行錯誤2

38. モノリスでボトルネックとなっている箇所を調査
 「定期ボックス作成バッチ」はざっくりいうと、
 Oracleに大きめのSQLをいくつも投げる前半部分と、
 その結果を元にスレッドで数十万件の定期ボックスを作る後半部分 の2部構成。不安定になるのは後半に入ってから。
 それ以外の大小 様々な機能
 定期ボックス作成バッチ 前半 後半

39. モノリスでボトルネックとなっている箇所を調査
 それ以外の大小 様々な機能
 定期ボックス作成バッチ 前半 後半
 ここだけ
 マイクロサービスに
 切り出す

40. VM
 定期ボックス作成バッチ 「定期ボックス作成バッチ」のマイクロサービス化
 Azure モノリスの定期作成処理 だけをSpringBootにリメイ クしてAzureのk8sで本番 運用を開始
 AKS
 (k8s)
 前半 後半 IDCF 9 Node 7 Pod
41. 大量データのバッチ処理をk8s上でやるにあたり、
 ノウハウのないクラスタ上での処理計測を
 VA Linuxの岩本さんにお願いすることに。
 
 以下、VA Linuxさんのパートに続きます。

42. ログについて もらったのはテキスト形式。各行に • タイムスタンプ • Pod名 • スレッドID • ログイベント ◦ 定期受注作成開始 ◦ 定期受注作成終了 • 受注を特定するID
43. [POD名] [タイムスタンプ] [ログレベル] [スレッドID] [Javaのクラス] [メッセージ] ログのイメージ(実際のログを色々加工しています ) oisix[oisix-club-order-create-service-648cc97c6f-hxx8b] 2019-06-06 12:56:07.306 INFO 1 [io-exec-74 j.c.o.o.s.[Boot的な ServiceA] 定期受注作成開始：[fooId=XXXX,xxxInd=1] oisix[oisix-club-order-create-service-648cc97c6f-q6mvb] 2019-06-06 12:56:07.114 INFO 1 [io-exec-79] o.o.s.i.[Boot的な ServiceB] fooId:aaa,xxxInd:1,Week:mmm,startDate:2019-06-06T10:00:00.0,bazId[00000004,]
44. バッチ処理なので… 最終的に興味があるのは全体の処理時間 • 時間あたりの処理件数 (r) • 1件あたりの処理にかかる時間 (t) • 並列処理数 (p) ◦ r = p / t • これらの性能指標に影響を与えているパラメータがあるか? といった風に細かく見ていきます
45. まずは処理レート 空白がおおいですね この辺のんびり動いてる
46. モノリス側の振り分け処理 ブロック1 今まで(2009年バージョン) ・・・ 1 2 n ・・・ 1 2 n ・・・ 1 2 n ・・・ 2) 一定数の スレッドに あらかじめ 定期ボックス を均等に 割り振る 1) 数十万件の定期ボックスを 300件ずつにグループ化 改定後(2019年バージョン) ブロック2 ・・・ スレッド1 スレッド2 スレッドn モノリス側の振り分け処理 ブロック1 2) 一定数のス レッドにあらか じめ定期ボッ クスを割り振 る 1) 数十万件の定期ボックスを 300件ずつにグループ化 ブロック2 ・・・ スレッド1 スレッド2 スレッドn ・・・ 1 2 3 ・・・
47. 改善後の処理レート この辺が改善した
48. 応答時間 (バッチ1件あたり処理時間) 左→右で処理件数は 20倍くらいになった けど、1件あたり所要 時間はあまり変化な し
49. 同時処理件数 vs. 応答時間 (1) 並列処理中の件数が増 えたら遅くなりそうなもの ですが、 よくわかりませんね 拡大します
50. 同時処理件数 vs. 応答時間 (zoomed)
51. 同時処理件数 vs. 応答時間 (2) Pod側がボトルネックなら 左の図で正の相関 モノリス側なら右の図でな るはず ジョブ数が少ないものが遅 い→遅いジョブが終わる頃 には他のは終わってる？
52. R=0.108*o+0.800 とかそんな感じ 外れ値の処理は悩むと ころ 注文件数で回帰
53. 応答時間 (調整済み) いわゆる回帰残差 • 注文件数が応答時間をよく説明している(だ けどscoreは0.42くらい) • ほとんどが予想値±0.5秒に入る ◦ 90%値 0.58秒 (0.71秒(別の日)) ◦ 99%値 2.47秒 (2.20秒) • よく見ると50秒くらいかかるものも
54. 応答時間 (調整済み) (1)の調整済みバージョン (ここ数枚のスライドとは別の 日のログ) 遅くなってる時間帯(開始直 後や13:20など)がみえる
55. 応答時間 (調整済み) (2) はっきり遅くなってジョブも投 入できてない時間帯が見える system metricsも見てみたが 原因ははっきりせず
56. 同時処理件数 vs. 応答時間 (3) 懲りずに回帰します 関連が見えるか?
57. 同時処理件数 vs. 応答時間 (4) 注文件数が平均値のとこ ろの切断面 …平均で見て見えないも のはやっぱりだめっぽい 傾きが負だったりするし 説明変数(縦軸)が最大値 のほうに偏ったデータだと いう問題もある(かも)
58. 分析おまけ(1) 回帰スコア
59. 分析おまけ(2) 遅い日と速い日がある ~\_(ツ)_/~ 同時処理件数以外にうまい説明変数も 見付からず… 全体をpoolして回帰するのは怖いから やってません
60. 分析おまけ(3) 相関係数: [応答時間, 注文件数, 並列度(per-Pod), 並列度(total)] 日によって結構違う値になる 1 .717 -.006 -.050 .717 1 -.008 -.040 -.006 -.008 1 .259 -.050 -.040 .259 1
61. 処理レートの低下要因は? 単純化して 200000件*2秒/件/100並列 = 4000秒 遅くなる理由(として考えられるもの): • 並列度が十分高くない • 遅い処理(外れ値)が影響している これらの寄与をみつもります
62. 本来100並列(この数字も実は…)なので、それより低くて損してる時間を積算 1400秒くらい 同時処理件数
63. 注文件数から予想される処理時間との差(積算) 遅い方1割で余計にか かってる時間が30000秒く らい 実際に効いてくるのは並 列度で割った値
64. まとめ 分析したらわかったこと • 処理レートグラフ -> スレッドへのジョブの振り分けを改善 • 応答時間 -> 遅い時間帯がみつかったけどよくわからない • 応答時間が同時処理件数の影響を受けている感じではない⇒k8s ノードの性能は まだ余裕あるはず • 同時処理件数は改善の余地がありそう 運用する側からの感想 • モノリスのどこをマイクロサービス化するのかの見極めが重要 • せっかく問題箇所を教えてもらったのに、モノリス側の改修に時間がかかってすみ ません • 今後はお客様に使っていただいているフロント側のシステムもマイクロサービス化 していくので、そこも分析をお願いします
65. OSS開発エンジニア募集中！
 世界各国の OSS エンジニアとコミュニティを通じて 
 OSS 開発をしたいという方、是非ご応募ください。 
 お待ちしています! https://www.valinux.co.jp/recruit/ • KubeConやOpenStack Summit をはじめ様々な 
 テクノロジーイベントに参加しています。 
 エンジニアリングで
 食卓と畑を変える仲間を募集中！
 https://recruit.oisixradaichi.co.jp/engineer/