映えないObservability

Transcript

1. Observability Conference 2025 株式会社MonotaRO Platform Engineering部門 SRE Kazuki Iwanaga 映えないObservability © 2025 MonotaRO Co., Ltd.
2. 2/54 自己紹介 岩永 一希 / Kazuki Iwanaga 株式会社MonotaRO Platform Engineering部門 SRE 2023年入社 レガシーな基幹システムのO11y改善に取り組んでいます！
3. 3/54 このセッションをひとことで モダンな手法が適用できない環境であっても Observabilityで扱う問題領域を明確にして 小さく計装＆課題解決をすることを大事にしたい という話
4. 4/54 目次 1. 会社紹介 2. モノタロウの「映える」Observability 3. モノタロウの「映えない」Observability 4. 事例紹介 5. 直近取り組んでいること 6. まとめ
5. 会社紹介
6. 6/54 モノタロウとは BtoB 向けに 間接資材 を販売するEC事業
7. 7/54 モノタロウが扱うのは？ 間接資材 = 製品原材料以外の全て ・工具、消耗品 ・カー用品 ・事務用品 ・化学用品 etc...
8. 8/54 モノタロウが扱う「間接資材」の特徴 間接資材の調達には ロングテール × 多品種 × 複雑な購買プロセス という性質がある → 買う頻度は少ないのに探すのも買うのも手間！ 多 少 購 入 量 ・ 全 額 企業の購買品の構成イメージ ヘッド ・購入プロセスの効率化がしやすい ・商品データ登録済 ・有利な条件で購入 ロングテール ・リピート購入がない ・都度購入品 ・拠点別購入品 ・商品データ未登録 ・メンテが困難 ・見える化ができない ヘッド商品とロングテール商品の割合 ［ヘッド］ ［ロングテール］ 80% 20% 20% 20% 80% 80% 手袋 テープ 工具 ナット 例えば… 金額 品目 手間
9. 9/54 モノタロウの成長 MonotaRO統合報告書2025 https://corp.monotaro.com/ir/upload_file/m005-m005_11/MonotaRO_IntegratedReport_2025_ja.pdf
10. 10/54 EC事業のモデル 利便性 時間節約 購買体験 売上 すぐ 見つかる すぐ届く 取り扱い がある
11. 11/54 EC事業の成長モデル 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. System:受発注, 在庫管理, etc. すぐ 見つかる すぐ届く 取り扱い がある
12. 12/54 EC事業の成長モデル 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない 品揃え改善 商品採用へ (省略) すぐ 見つかる すぐ届く 取り扱い がある
13. 13/54 EC事業の成長モデル 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 購買行動 受 発 注 ・ 入 出 荷 実 績 品揃え改善 商品採用へ (省略) すぐ 見つかる すぐ届く 取り扱い がある どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意
14. 14/54 モノタロウの強み 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 品揃え改善 商品採用へ (省略) 間接資材 在庫しづらい ロングテール ビジネス要求を 反映しやすい 内製システム 蓄積した 購買行動や実績 のデータ 受 発 注 ・ 入 出 荷 実 績 どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意
15. 15/54 もっと詳しく知るには... MonotaRO統合報告書2025 https://corp.monotaro.com/ir/upload_file/m005-m005_11/MonotaRO_IntegratedReport_2025_ja.pdf Est. 12:17
16. モノタロウの「映える」Observability
17. 17/54 モノタロウの複雑性 事業成長 ↓ レコード増加 商品, 顧客, サプライヤ数, etc. トランザクション増加 ドメインロジック増加 ↓ 複雑化 すぐ 見つかる すぐ届く 取り扱い がある
18. 18/54 ドメインモデリングやシステムモダナイゼーションの動機 長年のビジネス/組織の拡大によって生じた不要な複雑性が付随し、 本来取り組むべき課題、複雑性に集中できなくなっていることが問題 → これを取り除き、業務とシステムの変更容易性を再び取り戻すことが必要 っっｘ 取り組むべ き課題 不必要な複雑性、 煩雑さ 以前 現状 現状 現状 未来 っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ っっ ｘ 不必要な複雑性が増え た結果、本来取り組むべ き課題に集中できない 課題を分割すること、不必要な煩雑さ を減らすことで、本来取り組むべき課 題に向き合える状態になる
19. 19/54 システムモダナイゼーション 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 受 発 注 ・ 入 出 荷 実 績 品揃え改善 商品採用へ (省略) どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意 ビジネス要求を より早く反映できる 変更容易性がほしい ↓ ドメインモデリング マイクロサービス化 など
20. 20/54 ドメインモデリングの詳細はこちら https://speakerdeck.com/monotaro/ye-wu-li-jie-noshen-hua-to shi-jian-domeinmoderingudeji-gan-sisutemuwozhuo-eru
21. 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~現在)
22. 22/54 マイクロサービス化に伴う課題 マイクロサービス化が進み、ネットワークをまたぐシステム間の繋がりが増えてきた → モノリス時代の「1台だけAPMを有効化すれば十分」という状況から変わった サイトの全体像を把握しづらくなってきた中で、サイト全体に影響する障害が多発し てしまった → 障害発生時に発生箇所の特定が大変というよくある課題 → 耐障害性を高めるために整備する流れに！
23. 23/54 分散トレーシングの整備 トレースのcontext propagationやsamplingの設定を見直し、大幅に改善 映え映え〜
24. 24/54 サイトの分散トレーシングに関する取り組みの詳細はこちら https://speakerdeck.com/monotaro/microservice-observability-datadog-20250730 Est. 12:22
25. モノタロウの「映えない」Observability
26. 26/54 ここからはPlatform Engineering部門の立場で話します Platform Engineering部門はインフラ・データ・開発運用プロセスの面でサイトや基 幹システムの開発者を支援する組織
27. 27/54 レガシーな基幹システムの負荷 サイト側はマイクロサービス化や分散トレーシング整備など進んでいる 一方でモノタロウの基幹システムは大部分がレガシーで運用負荷を抱えたまま 例 バッチがcronのピタゴラスイッチで動いている ログがprintデバッグのようなものしかない → 歴が長い人やテックリードがエラー時刻からバッチや原因を推定したりする これらはマイクロサービス化・イベント駆動化等のモダナイズで解消されるはず ......でもそれって何年後？
28. 28/54 あえて「映えない」Observabilityを モノタロウでは開発チームの方もSREやObservabilityに積極的に取り組んでくれる → 映える(モダンな)Observabilityは勝手に進んでいく → そのおかげでPlatform側は映えない(レガシーな)方面を攻めることができる しかしモノタロウの基幹システムは制約が多くできることが限られている環境 分散トレーシングのような汎用的な解法が存在しない・使えない → どうやって切り崩すのか？
29. 29/54 大事にしていること Observabilityで解決しようとしている具体的な課題を明らかにすること ≒ Observabilityのユースケースを絞ること
30. 30/54 Observabilityのユースケースを絞ること 例えば理想的にはマイクロサービスやイベント駆動など「システムの単位 = ビジネス 的あるいは技術的な関心ごとの単位」になっていて、ネットワークやイベントの出入 りを見るだけでさまざまな疑問に答えられると良い でもレガシーな基幹システムではそうはいかず、モダンなObservabilityを適用する前 提条件の時点ですでにギャップがある 加えてシステム的な制約も多く、できることが限られている そこで、Observabilityで扱う問題領域を小さく具体的なものに絞ることで、実現可能 かつ実際に使ってもらえるものを作ることができると考えている → 自分たちに合ったObservabilityが少しずつできていく
31. 31/54 Observabilityのユースケースを絞ること モダンなO11y モダンな環境 実現可能 疑問の集合 O11yで答えられる範囲 システム的な制約(破線)
32. 32/54 Observabilityのユースケースを絞ること レガシーな環境 モダンなO11y モダンな環境 前提にギャップがある e.g., 巨大なモノリス 実現可能 × 疑問の集合 O11yで答えられる範囲 システム的な制約(破線)
33. 33/54 Observabilityのユースケースを絞ること レガシーな環境 モダンなO11y モダンな環境 ユースケースを 制限したO11y 前提にギャップがある e.g., 巨大なモノリス 実現可能 × 疑問の集合 O11yで答えられる範囲 システム的な制約(破線)
34. 34/54 モノタロウの場合 レガシーな環境 基幹システム モダンなO11y 分散トレーシング correlation モダンな環境 ECサイト ユースケースを 制限したO11y 前提にギャップがある e.g., 巨大なモノリス 実現可能 × 疑問の集合 O11yで答えられる範囲 システム的な制約(破線) マイクロサービス化が進んでいる Datadog APMやOtelも導入可 オンプレに大量のモノリスなバッチ 例えば、頻出する特定の問合せや エラー対応の改善に絞ってログを仕込む 帯域幅上限 手動テスト 環境差異多すぎ ライブラリ制限 ローカル開発不可 etc.
35. 35/54 ユースケースを絞るには とにかく開発チーム(O11yの当事者)と過ごす時間・対話する機会を作ること 朝会でもPJ定例MTGでもなんでもいいからまずは入って名前を覚えてもらう (最初は所属組織名「PEさん」から始まって「◯◯さん」になっていきます！) どういう言葉・用語が使われているのか できたら自分も同じ言葉を喋れるように努める、ファミリー感を作ってく タスクを巻き取りながら開発チームと同じ目線に立つことで、 「頻繁に来る問合せ(慣れていると何とも思わない)」などの狙い目を見つけていく Est. 12:28
36. 事例紹介 受注在庫引当パッケージの内製移行PJ
37. 37/54 受注在庫引当 ユーザーの注文を「いつまでに」「どの倉庫から」「どの配送業者で」出荷するか決める処理 配送コスト・納期・物流キャパシティ等を考慮 注文入力 （受注情報作成） 受注在庫引当 「いつまでに」 「どの倉庫から」 「どの配送業者で」 保留解除 出荷指示 発注 入荷 入荷在庫引当 在庫 保留 取寄・欠品・直送 発注依頼 受注 （引当済み） 受注 （未引当）
38. 38/54 受注在庫引当パッケージの内製移行PJ 受注在庫引当処理をパッケージから内製バッチに移行する(戻す)プロジェクト 当時マイクロサービス化の事例ができた頃で、内製に戻して自力で改善していく展望が見えてきた パッケージ 連携(内製) 受注在庫引当 パッケージ DB (パッケージ) 受注在庫引当 バッチ(内製) DB 受注 基幹システム(内製) パッケージ 15% 100% 85% 0% 前 後
39. 39/54 課題 = Observabilityのユースケースの発見 定例MTGやスクラムイベントに参加することから始めて具体的なユースケースを探った 移行先の古い内製バッチにはパフォーマンス(時間あたり処理件数)に懸念があるのが分かった 受注在庫引当が遅延すると当日出荷機能に影響が出る可能性があるため許容できない → 問題ないことをどう検証すればよいか？ _ 17時(15時)直前の受注を 締時刻までに捌く必要がある 平日の受注数の例 17時
40. 40/54 Observabilityによる解決 受注在庫引当バッチの処理時間を計測＆可視化 → 過去のピーク受注件数と照らし合わせることで 　 当日出荷を維持できるか見積もることができた また、集計値でなく分布そのものを見るようにした → 小さな傾向の変化や異常を視覚的に追えるように 内製のバッチが処理する受注量を増やしたところ
41. 41/54 システム制約 • 外部ライブラリを追加しづらい問題 → OpenTelemetryは当然使えない... • オンプレ帯域幅問題 → テレメトリがdropや他サービス影響の可能性 • トレース巨大すぎ問題 ◦ 多い時は一度に100受注以上まとめて処理するモノリスな巨大バッチ ◦ 受注・在庫・発注・倉庫など多くの基幹DBを触るためトレースが巨大 ◦ datadogで表示できなかったのでDBのspanを削除... • リリースタイミングが限られている問題 ◦ 実際の受注データを大量に流して機能・非機能面で問題がないかシミュレー ションしてから本番リリースをしていた ◦ 手動対応が必要かつ時間がかかるものだったためいつでもできるというわけ ではなく、あらかじめ決められたタイミングでのみリリースが可能だった
42. 42/54 文化の話 Webサイト側に比べて基幹システムで重視されていると感じたのは 業務やビジネスへの影響がないかどうか レガシーな基幹バッチがエラーを吐くことは日常茶飯事で(よくないけど)、 どうリカバリして受注や在庫などの状態(DB)の整合性の維持できるかが大事 問合せのあった特定の処理をN=1で追えるかどうか ここからサンプリングしづらい問題も生じている システム的に正常終了しても業務的に正常でない可能性がある e.g., 発注処理としては正常終了したが数量を入力ミスしている
43. 43/54 振り返ると... トレースの計装など色々試したが結局うまくいかなかった 最終的に残ったのはシンプルな処理時間の計装 しかし、 当日出荷機能に影響がないかパフォーマンス(とそのモニタリング)で懸念がある ため、事前に・リリース後に問題がないことを確認したい という具体的な課題 ≒ Observabilityのユースケースを絞ったことで、制約が多い環 境下でも成果につなげることができたのだと思う Est. 12:32
44. 直近取り組んでいること
45. 45/54 EC事業の成長モデル(再掲) 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 受 発 注 ・ 入 出 荷 実 績 品揃え改善 商品採用へ (省略) どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意
46. 46/54 モノタロウの成長モデル(再掲) 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 品揃え改善 商品採用へ (省略) 間接資材 在庫しづらい ロングテール ビジネス要求を 反映しやすい 内製システム 蓄積した 購買行動や実績 のデータ 受 発 注 ・ 入 出 荷 実 績 どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意
47. 47/54 いわゆるObservability 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 品揃え改善 商品採用へ (省略) システムが正しく 動作し、価値提供 を行えているか 引当の事例もそう 受 発 注 ・ 入 出 荷 実 績 どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意
48. 48/54 目指したいObservability(?) 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 品揃え改善 商品採用へ (省略) 「ビジネスの成長 サイクルが正しく 回せているか？」 という疑問に 答えるためのO11y 受 発 注 ・ 入 出 荷 実 績 どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意 Q. いつ誰のどの 最適化(自動・手 動)の効果は どれくらいだった か(ABテスト風)
49. 49/54 直近の取り組み 利便性 時間節約 購買体験 売上 System:サイト構造, 推薦枠, etc. 取扱商品数 増 System:受発注, 在庫管理, etc. DS: 発注点計算, 在庫判断, etc. DS: 検索・推薦, SEO, 広告, etc. すぐ 見つかる すぐ届く サイトが複 雑で探しづ らい 物流キャパ は有限なの で全部は在 庫できない パラメータ 最適化 パラメータ 最適化 取り扱い がある 購買行動 品揃え改善 商品採用へ (省略) 受 発 注 ・ 入 出 荷 実 績 どの商品やユーザーに何を適用するかを最適化 Systemは最適化に使える選択肢を用意 需要予測を元にした 在庫判定・発注点など が正しく基幹システム に反映されているか？ 手動で修正した場合な ども追跡できるか？ 基幹システムだけでなく Supply Chain Managementの部門も含 めて定期的に議論中 Est. 12:36
50. 50/54 映えないObservabilityの先にあるもの Observabilityで解決したい問題を明確にすること 曖昧なunknown unknownのままにしないこと → 「いわゆるObservability」ではない領域への応用の可能性 　 制約のある環境・レガシーな環境や純粋なシステムでないものなど 例えば、開発生産性向上の取り組み 開発・運用プロセスに関するObservabilityと改善活動 モダンなシステムや文化がない(=前提条件のギャップ)と Four Keysを見てもアクションにつながらなかったりする(実体験) → 個々のチームの具体的な課題と向き合う 　 e.g., レビュー待ちが長い, そもそもボトルネックが何か分からない
51. まとめ
52. 52/54 まとめ 具体的な課題を見つけてユースケースをあえて絞ることで、レガシーな環境 であってもObservabilityを活用して課題解決を行えることを紹介しました モダンな環境でなくても小さく泥臭くできることはあるはず！ そんな「映えない」取り組みを大事にしていきたいです！ 感想・相談・質問なんでもWelcomeです Ask the speakerでお待ちしております！ Est. 12:38
53. 採用情報 https://mid-career.monotaro.com/EngineeringIT © 2025 MonotaRO Co., Ltd.
54. © 2025 MonotaRO Co., Ltd.