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

by IWAMOTO Toshihiro

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

これまでのあらすじ ● Jaeger とかの tracing かっこいい ● システムの負荷とあわせて分析すると何かみえるはず ○ CNDT2018冬発表 ○ 人工的に作成した負荷 ● オイシックス・ラ・大地さんから話をいただいた ● 今日は運用中のサービスでやります

Slide 3

Slide 3 text

分析するとわかること ● グラフを描くとたのしい ● ボトルネックがあって性能が出ていなかったり ● 無駄にスペックが余ってるともったいないですよね? 実際のサービスの細かい実装を知らずにどこまで分析できるかやってみます

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

略称(弊社公式) 

Slide 8

Slide 8 text

今日はこのブランドのお話になります

Slide 9

Slide 9 text

Oisixは  2000年創業の  生鮮食品の  ネットショップ 

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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     これまでのマイクロサービスの取り組み 

Slide 18

Slide 18 text

Oisixのマイクロサービス開発環境  開発マシンはWindowsとMacから開発者が希望する方 IDEもどちらでも Gradleが動けば言語は JavaかKotlin Spring Bootベースでテンプレートを用意 API定義はSwaggerを使用

Slide 19

Slide 19 text

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 で構成

Slide 20

Slide 20 text

監視系 Oisixのクラウド構成  AKS(k8s) Azure Storage Queue Azure MySQL Azure Redis Cache ブラウザ iPhone App Android App Log Analytics Monitor WWW VM オンプレミス API Management IDCF Cloud

Slide 21

Slide 21 text

Oisixのマイクロサービスの方針  ストラングラーパターン    IDCF CloudとAzureを使用した  マルチクラウド構成    共有データベースの  段階的な分離  1.    2.      3.

Slide 22

Slide 22 text

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

とりあえずリフトアンドシフト  Azure AKS  (k8s)  VMで動作していた  モノリス一式を  弊社のコンテナ基盤である  Azure上のAKSに移動  VM IDCF

Slide 31

Slide 31 text

とりあえずリフトアンドシフト  Azure AKS  (k8s)  データセンターの  DBはOracle。  そのままAzureに  シフトするのは  無理。  オンプレミス無理 VM IDCF

Slide 32

Slide 32 text

とりあえずリフトアンドシフト  Azure AKS  (k8s)  アプリケーションだけ移すと応答時間がかかりすぎる    →リフトアンドシフトは断念  ネットワーク的に遠い  オンプレミス VM IDCF

Slide 33

Slide 33 text

昨年夏頃  しかし  可及的速やかに  問題の解決が必要 

Slide 34

Slide 34 text

VM  定期ボックス  作成バッチ  それ以外  VM  定期ボックス  作成バッチ  それ以外  可及的速やかな解決策(コンテナ成分ゼロ)  モノリスをOSごと丸々複製。    モノリス2号機が誕生。    2号機は定期ボックス作成専用にし VMのスペックをあげまくる。    問題にお金で対応して、急場をとりあえずしのげる状態にシステムを回復させる。  丸々 COPY モノリス1号  モノリス2号  2号機は高いのでバッチの時間だけVMを起こす。

Slide 35

Slide 35 text

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

VM  定期ボックス作成バッチ「定期ボックス作成バッチ」のマイクロサービス化  Azure モノリスの定期作成処理だけをSpringBootにリメイクしてAzureのk8sで本番運用を開始  AKS  (k8s)  前半後半 IDCF 9 Node 7 Pod

Slide 41

Slide 41 text

大量データのバッチ処理をk8s上でやるにあたり、  ノウハウのないクラスタ上での処理計測を  VA Linuxの岩本さんにお願いすることに。    以下、VA Linuxさんのパートに続きます。 

Slide 42

Slide 42 text

ログについてもらったのはテキスト形式。各行に ● タイムスタンプ ● Pod名 ● スレッドID ● ログイベント ○ 定期受注作成開始 ○ 定期受注作成終了 ● 受注を特定するID

Slide 43

Slide 43 text

[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,]

Slide 44

Slide 44 text

バッチ処理なので… 最終的に興味があるのは全体の処理時間 ● 時間あたりの処理件数 (r) ● 1件あたりの処理にかかる時間 (t) ● 並列処理数 (p) ○ r = p / t ● これらの性能指標に影響を与えているパラメータがあるか? といった風に細かく見ていきます

Slide 45

Slide 45 text

まずは処理レート空白がおおいですねこの辺のんびり動いてる

Slide 46

Slide 46 text

モノリス側の振り分け処理ブロック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 ・・・

Slide 47

Slide 47 text

改善後の処理レートこの辺が改善した

Slide 48

Slide 48 text

応答時間 (バッチ1件あたり処理時間) 左→右で処理件数は 20倍くらいになったけど、1件あたり所要時間はあまり変化なし

Slide 49

Slide 49 text

同時処理件数 vs. 応答時間 (1) 並列処理中の件数が増えたら遅くなりそうなものですが、よくわかりませんね拡大します

Slide 50

Slide 50 text

同時処理件数 vs. 応答時間 (zoomed)

Slide 51

Slide 51 text

同時処理件数 vs. 応答時間 (2) Pod側がボトルネックなら左の図で正の相関モノリス側なら右の図でなるはずジョブ数が少ないものが遅い→遅いジョブが終わる頃には他のは終わってる？

Slide 52

Slide 52 text

R=0.108*o+0.800 とかそんな感じ外れ値の処理は悩むところ注文件数で回帰

Slide 53

Slide 53 text

応答時間 (調整済み) いわゆる回帰残差 ● 注文件数が応答時間をよく説明している(だけどscoreは0.42くらい) ● ほとんどが予想値±0.5秒に入る ○ 90%値 0.58秒 (0.71秒(別の日)) ○ 99%値 2.47秒 (2.20秒) ● よく見ると50秒くらいかかるものも

Slide 54

Slide 54 text

応答時間 (調整済み) (1)の調整済みバージョン (ここ数枚のスライドとは別の日のログ) 遅くなってる時間帯(開始直後や13:20など)がみえる

Slide 55

Slide 55 text

応答時間 (調整済み) (2) はっきり遅くなってジョブも投入できてない時間帯が見える system metricsも見てみたが原因ははっきりせず

Slide 56

Slide 56 text

同時処理件数 vs. 応答時間 (3) 懲りずに回帰します関連が見えるか?

Slide 57

Slide 57 text

同時処理件数 vs. 応答時間 (4) 注文件数が平均値のところの切断面 …平均で見て見えないものはやっぱりだめっぽい傾きが負だったりするし説明変数(縦軸)が最大値のほうに偏ったデータだという問題もある(かも)

Slide 58

Slide 58 text

分析おまけ(1) 回帰スコア

Slide 59

Slide 59 text

分析おまけ(2) 遅い日と速い日がある ~\_(ツ)_/~ 同時処理件数以外にうまい説明変数も見付からず… 全体をpoolして回帰するのは怖いからやってません

Slide 60

Slide 60 text

分析おまけ(3) 相関係数: [応答時間, 注文件数, 並列度(per-Pod), 並列度(total)] 日によって結構違う値になる 1 .717 -.006 -.050 .717 1 -.008 -.040 -.006 -.008 1 .259 -.050 -.040 .259 1

Slide 61

Slide 61 text

処理レートの低下要因は? 単純化して 200000件*2秒/件/100並列 = 4000秒遅くなる理由(として考えられるもの): ● 並列度が十分高くない ● 遅い処理(外れ値)が影響しているこれらの寄与をみつもります

Slide 62

Slide 62 text

本来100並列(この数字も実は…)なので、それより低くて損してる時間を積算 1400秒くらい同時処理件数

Slide 63

Slide 63 text

注文件数から予想される処理時間との差(積算) 遅い方1割で余計にかかってる時間が30000秒くらい実際に効いてくるのは並列度で割った値

Slide 64

Slide 64 text

まとめ分析したらわかったこと ● 処理レートグラフ -> スレッドへのジョブの振り分けを改善 ● 応答時間 -> 遅い時間帯がみつかったけどよくわからない ● 応答時間が同時処理件数の影響を受けている感じではない⇒k8s ノードの性能はまだ余裕あるはず ● 同時処理件数は改善の余地がありそう運用する側からの感想 ● モノリスのどこをマイクロサービス化するのかの見極めが重要 ● せっかく問題箇所を教えてもらったのに、モノリス側の改修に時間がかかってすみません ● 今後はお客様に使っていただいているフロント側のシステムもマイクロサービス化していくので、そこも分析をお願いします

Slide 65

Slide 65 text

OSS開発エンジニア募集中！  世界各国の OSS エンジニアとコミュニティを通じて   OSS 開発をしたいという方、是非ご応募ください。   お待ちしています! https://www.valinux.co.jp/recruit/ ● KubeConやOpenStack Summit をはじめ様々な   テクノロジーイベントに参加しています。   エンジニアリングで  食卓と畑を変える仲間を募集中！  https://recruit.oisixradaichi.co.jp/engineer/