映えないObservability

by MonotaRO

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2/54 自己紹介岩永一希 / Kazuki Iwanaga 株式会社MonotaRO Platform Engineering部門 SRE 2023年入社レガシーな基幹システムのO11y改善に取り組んでいます！

Slide 3

Slide 3 text

3/54 このセッションをひとことでモダンな手法が適用できない環境であっても Observabilityで扱う問題領域を明確にして小さく計装＆課題解決をすることを大事にしたいという話

Slide 4

Slide 4 text

4/54 目次 1. 会社紹介 2. モノタロウの「映える」Observability 3. モノタロウの「映えない」Observability 4. 事例紹介 5. 直近取り組んでいること 6. まとめ

Slide 5

Slide 5 text

会社紹介

Slide 6

Slide 6 text

6/54 モノタロウとは BtoB 向けに間接資材を販売するEC事業

Slide 7

Slide 7 text

7/54 モノタロウが扱うのは？間接資材 = 製品原材料以外の全て・工具、消耗品・カー用品・事務用品・化学用品 etc...

Slide 8

Slide 8 text

8/54 モノタロウが扱う「間接資材」の特徴間接資材の調達にはロングテール × 多品種 × 複雑な購買プロセスという性質がある → 買う頻度は少ないのに探すのも買うのも手間！多少購入量・全額企業の購買品の構成イメージヘッド・購入プロセスの効率化がしやすい・商品データ登録済・有利な条件で購入ロングテール・リピート購入がない・都度購入品・拠点別購入品・商品データ未登録・メンテが困難・見える化ができないヘッド商品とロングテール商品の割合［ヘッド］［ロングテール］ 80% 20% 20% 20% 80% 80% 手袋テープ工具ナット例えば… 金額品目手間

Slide 9

Slide 9 text

9/54 モノタロウの成長 MonotaRO統合報告書2025 https://corp.monotaro.com/ir/upload_ﬁle/m005-m005_11/MonotaRO_IntegratedReport_2025_ja.pdf

Slide 10

Slide 10 text

10/54 EC事業のモデル利便性時間節約購買体験売上すぐ見つかるすぐ届く取り扱いがある

Slide 11

Slide 11 text

11/54 EC事業の成長モデル利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. System:受発注, 在庫管理, etc. すぐ見つかるすぐ届く取り扱いがある

Slide 12

Slide 12 text

12/54 EC事業の成長モデル利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. サイトが複雑で探しづらい物流キャパは有限なので全部は在庫できない品揃え改善商品採用へ (省略) すぐ見つかるすぐ届く取り扱いがある

Slide 13

Slide 13 text

13/54 EC事業の成長モデル利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. サイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化購買行動受発注・入出荷実績品揃え改善商品採用へ (省略) すぐ見つかるすぐ届く取り扱いがあるどの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意

Slide 14

Slide 14 text

14/54 モノタロウの強み利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動品揃え改善商品採用へ (省略) 間接資材在庫しづらいロングテールビジネス要求を反映しやすい内製システム蓄積した購買行動や実績のデータ受発注・入出荷実績どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意

Slide 15

Slide 15 text

15/54 もっと詳しく知るには... MonotaRO統合報告書2025 https://corp.monotaro.com/ir/upload_ﬁle/m005-m005_11/MonotaRO_IntegratedReport_2025_ja.pdf Est. 12:17

Slide 16

Slide 16 text

モノタロウの「映える」Observability

Slide 17

Slide 17 text

17/54 モノタロウの複雑性事業成長 ↓ レコード増加商品, 顧客, サプライヤ数, etc. トランザクション増加ドメインロジック増加 ↓ 複雑化すぐ見つかるすぐ届く取り扱いがある

Slide 18

Slide 18 text

18/54 ドメインモデリングやシステムモダナイゼーションの動機長年のビジネス/組織の拡大によって生じた不要な複雑性が付随し、本来取り組むべき課題、複雑性に集中できなくなっていることが問題 → これを取り除き、業務とシステムの変更容易性を再び取り戻すことが必要っっｘ取り組むべき課題不必要な複雑性、煩雑さ以前現状現状現状未来っっｘっっｘっっｘっっｘっっｘっっｘ不必要な複雑性が増えた結果、本来取り組むべき課題に集中できない課題を分割すること、不必要な煩雑さを減らすことで、本来取り組むべき課題に向き合える状態になる

Slide 19

Slide 19 text

19/54 システムモダナイゼーション利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動受発注・入出荷実績品揃え改善商品採用へ (省略) どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意ビジネス要求をより早く反映できる変更容易性がほしい ↓ ドメインモデリングマイクロサービス化など

Slide 20

Slide 20 text

20/54 ドメインモデリングの詳細はこちら https://speakerdeck.com/monotaro/ye-wu-li-jie-noshen-hua-to shi-jian-domeinmoderingudeji-gan-sisutemuwozhuo-eru

Slide 21

Slide 21 text

21/54 モノリスからマイクロサービスへ (ECサイト側) nginx BFF FEアプリA FEアプリB Product Search Customer Recommend Order Cart Product microservice FEアプリA FEアプリB nginx API① API② モノリス期（~2023）マイクロサービス化過渡期(2023~現在)

Slide 22

Slide 22 text

22/54 マイクロサービス化に伴う課題マイクロサービス化が進み、ネットワークをまたぐシステム間の繋がりが増えてきた → モノリス時代の「1台だけAPMを有効化すれば十分」という状況から変わったサイトの全体像を把握しづらくなってきた中で、サイト全体に影響する障害が多発してしまった → 障害発生時に発生箇所の特定が大変というよくある課題 → 耐障害性を高めるために整備する流れに！

Slide 23

Slide 23 text

23/54 分散トレーシングの整備トレースのcontext propagationやsamplingの設定を見直し、大幅に改善映え映え〜

Slide 24

Slide 24 text

24/54 サイトの分散トレーシングに関する取り組みの詳細はこちら https://speakerdeck.com/monotaro/microservice-observability-datadog-20250730 Est. 12:22

Slide 25

Slide 25 text

モノタロウの「映えない」Observability

Slide 26

Slide 26 text

26/54 ここからはPlatform Engineering部門の立場で話します Platform Engineering部門はインフラ・データ・開発運用プロセスの面でサイトや基幹システムの開発者を支援する組織

Slide 27

Slide 27 text

27/54 レガシーな基幹システムの負荷サイト側はマイクロサービス化や分散トレーシング整備など進んでいる一方でモノタロウの基幹システムは大部分がレガシーで運用負荷を抱えたまま例バッチがcronのピタゴラスイッチで動いているログがprintデバッグのようなものしかない → 歴が長い人やテックリードがエラー時刻からバッチや原因を推定したりするこれらはマイクロサービス化・イベント駆動化等のモダナイズで解消されるはず ......でもそれって何年後？

Slide 28

Slide 28 text

28/54 あえて「映えない」Observabilityをモノタロウでは開発チームの方もSREやObservabilityに積極的に取り組んでくれる → 映える(モダンな)Observabilityは勝手に進んでいく → そのおかげでPlatform側は映えない(レガシーな)方面を攻めることができるしかしモノタロウの基幹システムは制約が多くできることが限られている環境分散トレーシングのような汎用的な解法が存在しない・使えない → どうやって切り崩すのか？

Slide 29

Slide 29 text

29/54 大事にしていること Observabilityで解決しようとしている具体的な課題を明らかにすること ≒ Observabilityのユースケースを絞ること

Slide 30

Slide 30 text

30/54 Observabilityのユースケースを絞ること例えば理想的にはマイクロサービスやイベント駆動など「システムの単位 = ビジネス的あるいは技術的な関心ごとの単位」になっていて、ネットワークやイベントの出入りを見るだけでさまざまな疑問に答えられると良いでもレガシーな基幹システムではそうはいかず、モダンなObservabilityを適用する前提条件の時点ですでにギャップがある加えてシステム的な制約も多く、できることが限られているそこで、Observabilityで扱う問題領域を小さく具体的なものに絞ることで、実現可能かつ実際に使ってもらえるものを作ることができると考えている → 自分たちに合ったObservabilityが少しずつできていく

Slide 31

Slide 31 text

31/54 Observabilityのユースケースを絞ることモダンなO11y モダンな環境実現可能疑問の集合 O11yで答えられる範囲システム的な制約(破線)

Slide 32

Slide 32 text

32/54 Observabilityのユースケースを絞ることレガシーな環境モダンなO11y モダンな環境前提にギャップがある e.g., 巨大なモノリス実現可能 × 疑問の集合 O11yで答えられる範囲システム的な制約(破線)

Slide 33

Slide 33 text

33/54 Observabilityのユースケースを絞ることレガシーな環境モダンなO11y モダンな環境ユースケースを制限したO11y 前提にギャップがある e.g., 巨大なモノリス実現可能 × 疑問の集合 O11yで答えられる範囲システム的な制約(破線)

Slide 34

Slide 34 text

34/54 モノタロウの場合レガシーな環境基幹システムモダンなO11y 分散トレーシング correlation モダンな環境 ECサイトユースケースを制限したO11y 前提にギャップがある e.g., 巨大なモノリス実現可能 × 疑問の集合 O11yで答えられる範囲システム的な制約(破線) マイクロサービス化が進んでいる Datadog APMやOtelも導入可オンプレに大量のモノリスなバッチ例えば、頻出する特定の問合せやエラー対応の改善に絞ってログを仕込む帯域幅上限手動テスト環境差異多すぎライブラリ制限ローカル開発不可 etc.

Slide 35

Slide 35 text

35/54 ユースケースを絞るにはとにかく開発チーム(O11yの当事者)と過ごす時間・対話する機会を作ること朝会でもPJ定例MTGでもなんでもいいからまずは入って名前を覚えてもらう (最初は所属組織名「PEさん」から始まって「◯◯さん」になっていきます！) どういう言葉・用語が使われているのかできたら自分も同じ言葉を喋れるように努める、ファミリー感を作ってくタスクを巻き取りながら開発チームと同じ目線に立つことで、「頻繁に来る問合せ(慣れていると何とも思わない)」などの狙い目を見つけていく Est. 12:28

Slide 36

Slide 36 text

事例紹介受注在庫引当パッケージの内製移行PJ

Slide 37

Slide 37 text

37/54 受注在庫引当ユーザーの注文を「いつまでに」「どの倉庫から」「どの配送業者で」出荷するか決める処理配送コスト・納期・物流キャパシティ等を考慮注文入力（受注情報作成）受注在庫引当「いつまでに」「どの倉庫から」「どの配送業者で」保留解除出荷指示発注入荷入荷在庫引当在庫保留取寄・欠品・直送発注依頼受注（引当済み）受注（未引当）

Slide 38

Slide 38 text

38/54 受注在庫引当パッケージの内製移行PJ 受注在庫引当処理をパッケージから内製バッチに移行する(戻す)プロジェクト当時マイクロサービス化の事例ができた頃で、内製に戻して自力で改善していく展望が見えてきたパッケージ連携(内製) 受注在庫引当パッケージ DB (パッケージ) 受注在庫引当バッチ(内製) DB 受注基幹システム(内製) パッケージ 15% 100% 85% 0% 前後

Slide 39

Slide 39 text

39/54 課題 = Observabilityのユースケースの発見定例MTGやスクラムイベントに参加することから始めて具体的なユースケースを探った移行先の古い内製バッチにはパフォーマンス(時間あたり処理件数)に懸念があるのが分かった受注在庫引当が遅延すると当日出荷機能に影響が出る可能性があるため許容できない → 問題ないことをどう検証すればよいか？ _ 17時(15時)直前の受注を締時刻までに捌く必要がある平日の受注数の例 17時

Slide 40

Slide 40 text

40/54 Observabilityによる解決受注在庫引当バッチの処理時間を計測＆可視化 → 過去のピーク受注件数と照らし合わせることで　当日出荷を維持できるか見積もることができたまた、集計値でなく分布そのものを見るようにした → 小さな傾向の変化や異常を視覚的に追えるように内製のバッチが処理する受注量を増やしたところ

Slide 41

Slide 41 text

41/54 システム制約 ● 外部ライブラリを追加しづらい問題 → OpenTelemetryは当然使えない... ● オンプレ帯域幅問題 → テレメトリがdropや他サービス影響の可能性 ● トレース巨大すぎ問題 ○ 多い時は一度に100受注以上まとめて処理するモノリスな巨大バッチ ○ 受注・在庫・発注・倉庫など多くの基幹DBを触るためトレースが巨大 ○ datadogで表示できなかったのでDBのspanを削除... ● リリースタイミングが限られている問題 ○ 実際の受注データを大量に流して機能・非機能面で問題がないかシミュレーションしてから本番リリースをしていた ○ 手動対応が必要かつ時間がかかるものだったためいつでもできるというわけではなく、あらかじめ決められたタイミングでのみリリースが可能だった

Slide 42

Slide 42 text

42/54 文化の話 Webサイト側に比べて基幹システムで重視されていると感じたのは業務やビジネスへの影響がないかどうかレガシーな基幹バッチがエラーを吐くことは日常茶飯事で(よくないけど)、どうリカバリして受注や在庫などの状態(DB)の整合性の維持できるかが大事問合せのあった特定の処理をN=1で追えるかどうかここからサンプリングしづらい問題も生じているシステム的に正常終了しても業務的に正常でない可能性がある e.g., 発注処理としては正常終了したが数量を入力ミスしている

Slide 43

Slide 43 text

43/54 振り返ると... トレースの計装など色々試したが結局うまくいかなかった最終的に残ったのはシンプルな処理時間の計装しかし、当日出荷機能に影響がないかパフォーマンス(とそのモニタリング)で懸念があるため、事前に・リリース後に問題がないことを確認したいという具体的な課題 ≒ Observabilityのユースケースを絞ったことで、制約が多い環境下でも成果につなげることができたのだと思う Est. 12:32

Slide 44

Slide 44 text

直近取り組んでいること

Slide 45

Slide 45 text

45/54 EC事業の成長モデル(再掲) 利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動受発注・入出荷実績品揃え改善商品採用へ (省略) どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意

Slide 46

Slide 46 text

46/54 モノタロウの成長モデル(再掲) 利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動品揃え改善商品採用へ (省略) 間接資材在庫しづらいロングテールビジネス要求を反映しやすい内製システム蓄積した購買行動や実績のデータ受発注・入出荷実績どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意

Slide 47

Slide 47 text

47/54 いわゆるObservability 利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動品揃え改善商品採用へ (省略) システムが正しく動作し、価値提供を行えているか引当の事例もそう受発注・入出荷実績どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意

Slide 48

Slide 48 text

48/54 目指したいObservability(?) 利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動品揃え改善商品採用へ (省略) 「ビジネスの成長サイクルが正しく回せているか？」という疑問に答えるためのO11y 受発注・入出荷実績どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意 Q. いつ誰のどの最適化(自動・手動)の効果はどれくらいだったか(ABテスト風)

Slide 49

Slide 49 text

49/54 直近の取り組み利便性時間節約購買体験売上 System:サイト構造, 推薦枠, etc. 取扱商品数増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ見つかるすぐ届くサイトが複雑で探しづらい物流キャパは有限なので全部は在庫できないパラメータ最適化パラメータ最適化取り扱いがある購買行動品揃え改善商品採用へ (省略) 受発注・入出荷実績どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意需要予測を元にした在庫判定・発注点などが正しく基幹システムに反映されているか？手動で修正した場合なども追跡できるか？基幹システムだけでなく Supply Chain Managementの部門も含めて定期的に議論中 Est. 12:36

Slide 50

Slide 50 text

50/54 映えないObservabilityの先にあるもの Observabilityで解決したい問題を明確にすること曖昧なunknown unknownのままにしないこと → 「いわゆるObservability」ではない領域への応用の可能性　制約のある環境・レガシーな環境や純粋なシステムでないものなど例えば、開発生産性向上の取り組み開発・運用プロセスに関するObservabilityと改善活動モダンなシステムや文化がない(=前提条件のギャップ)と Four Keysを見てもアクションにつながらなかったりする(実体験) → 個々のチームの具体的な課題と向き合う　 e.g., レビュー待ちが長い, そもそもボトルネックが何か分からない

Slide 51

Slide 51 text

まとめ

Slide 52

Slide 52 text

52/54 まとめ具体的な課題を見つけてユースケースをあえて絞ることで、レガシーな環境であってもObservabilityを活用して課題解決を行えることを紹介しましたモダンな環境でなくても小さく泥臭くできることはあるはず！そんな「映えない」取り組みを大事にしていきたいです！感想・相談・質問なんでもWelcomeです Ask the speakerでお待ちしております！ Est. 12:38