はてなブックマーク

はじめに こんにちは、データシステム部推薦基盤ブロックの寺崎（@f6wbl6）と佐藤（@rayuron）です。 私たちは2024年10月14〜18日にイタリアのバーリにて開催されたRecSys 2024(18th ACM Conference on Recommender Systems)に現地参加しました。本記事では現地でのワークショップやセッションの様子をお伝えすると共に、気になったトピックをいくつか取り上げてご紹介します。 RecSysとは RecSysとは米国計算機学会（ACM）が主催する推薦システムに関する国際的なカンファレンスです。今回で18回目の開催となるRecSys 2024は2024年10月14〜18日にイタリアのバーリで開催されました。 recsys.acm.org RecSysでは推薦システムに関わる各国の大学の研究チームや、Google、Amazon、Netflix

はじめに こんにちは、計測システム部SREブロックの@TAKAyuki_atkwskです。普段はZOZOMATやZOZOGLASS、ZOZOMETRYなどの身体計測サービスの開発・運用に携わっています。 最近公開されたZOZOMETRYですが、正式ローンチに至るまでにチーム間のサイロ化によるデリバリー速度の低下という課題が見えてきました。そこで、モブプログラミング（モブプロ）を通してチーム間のコラボレーションを促進し、課題の解決を試みている事例をご紹介します。 目次 はじめに 目次 背景・課題 モブプロを試してみる 私たちのモブプロのやり方 事前準備 モブプロの流れ モブプロをやってみて 改善点 まとめ 背景・課題 私の所属する計測システム部では以下の組織図の通り、SRE、バックエンド、フロントエンド、研究開発の4つのチームが存在しています1。さらに、複数のプロジェクトが並行して進むことが

はじめに こんにちは。計測プラットフォーム開発本部SREの纐纈です。最近はZOZOMETRYという法人向け計測業務効率化サービスの開発・運用に携わっています。今回ZOZOMETRYが正式に公開されることとなったので、合わせてこの記事を書くことになりました。 biz.zozometry.com 現在はパフォーマンスも良好なZOZOMETRYですが、ローンチ当初はパフォーマンスが良くなく、改善のために様々な検証をしました。今回はその経緯と検証内容を中心に、ZOZOMETRYのパフォーマンス改善についてお話ししたいと思います。 一般的にも、Lambdaを使ったサーバーレスアーキテクチャの構築やSQSを使った非同期処理の設計など、参考になる部分があるかもしれません。ぜひ最後までお付き合い頂ければ幸いです。 ZOZOMETRYの機能と構成紹介 まずは、ZOZOMETRYの機能と構成について簡単に紹介

はじめに こんにちは。計測プラットフォーム開発本部バックエンドチームの佐次田です。普段はZOZOMATやZOZOMETRYなどの計測技術に関わるシステムの開発、運用に携わっています。 本記事では計測システムにおける計測データの管理方法を進化させた点についてご紹介します。 目次 はじめに 目次 計測プラットフォーム開発本部 バックエンドチームとは ユビキタス言語 3Dデータ 計測箇所 計測値 ZOZOMETRYとは ZOZOMETRYのコア機能 計測箇所のカスタマイズに関する課題 計測処理をサーバーが担当する解決アプローチ システム構成図 既存プロダクトのシステム構成 ZOZOMETRYにおけるシステム構成 システム構成の変更点 計測セットを元に計測箇所をカスタマイズする 計測セットのドメインモデル 計測シーケンスの概要 3Dデータと計測値の保存先を分離する 3DデータをAPIサーバーで管理

はじめに こんにちは、ZOZOTOWN企画開発部・企画フロントエンド1ブロックのゾイです。 ZOZOTOWNトップでは、セール訴求や新作アイテム訴求、未出店ブランドの期間限定ポップアップ、著名人コラボなどの企画イベントが毎日何かしら打ち出されています。私はそのプラットフォームとなる企画LPをメインに実装するチームに在籍しています。 今まで実装した企画LPをアーカイブするプロジェクトにも参加しているので、チームの特性や企画LPの詳細は下記の記事をご覧いただければと思います！ techblog.zozo.com 目次 はじめに 目次 背景・課題 仕様・技術選定 1. 型の定義と入力データのバリデーション 2. 入力フォームの実装 3. URLの生成 ユーザーの反応 終わりに 背景・課題 ZOZOTOWNではカルセールバナーなど、アプリとWeb共通で表示させるコンテンツにはURLを分ける必要があ

はじめに こんにちは、WEARバックエンド部バックエンドブロックの塩足です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 WEARのバックエンドでは、これまで自動テスト環境としてCircleCIを使用していましたが、運用保守の改善を目的にGitHub Actionsへ移行しました。 今回は、GitHub Actionsへ移行する際に取り組んだ以下の3点について紹介します。 効率的にテストを分割してテストを並列実行する方法 失敗したテストのみを再実行する仕組みの構築 GitHubのCheck annotationsを活用して、失敗したテスト情報を表示 また、最後に今回行ったテストカバレッジのレポーティングとGitHub Pagesでのホスティングの方法について紹介します。 目次 はじめに 目次 背景 なぜ自動テスト環境をCircleCIからGitHub Acti

はじめに こんにちは、データシステム部MLOpsブロックの薄田（@udus122）です。 この記事ではFour Keysなどの指標を活用して、定量的な根拠に基づきチームの開発生産性を改善する考え方とふりかえり手法を紹介します。 Four Keysとはデプロイ頻度、変更のリードタイム、変更障害率、平均修復時間の4つの指標からなるソフトウェアデリバリーや開発生産性の指標です。 Four Keysなど開発生産性の指標を計測し、定期的にふりかえっているけれど、なかなか具体的な改善につながらない。 そんな悩みはないでしょうか？ 実際に私たちのチームで抱えていた開発生産性の改善に関する課題と解決策を紹介します。皆さんのチームで開発生産性を改善する際のご参考になれば幸いです。 目次 はじめに 目次 開発生産性の改善に取り組んだ背景 チームの改善に取り組む上での課題 Four Keysの考え方に対する理解

はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 ZOZOTOWNリプレイスが順調に進む中始まった「カート決済機能」のリプレイス。第5回では、始動の経緯と、システムの安定稼働につながる大きな改善をもたらしたキューイングシステムの導入について解説します。 目次 はじめに 目次 ZOZOTOWNカート決済リプレイスの始動 体制変更 カート決済サービスの将来像 ジレンマと優先順位 スケールアップ戦略だけでは防ぎきれなくなった障害 キューイングシステムの導入 Kinesis Data Streamsの採用理由 First In First Outでのキャパシティ Kinesis Client Libraryを利用した開発工数の削減 本システムのポイント 過熱商品専用のKDSを作成 既存

はじめに こんにちは！　WEARバックエンド部バックエンドブロックの小島（@KojimaNaoyuki）です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 10周年を迎えたWEARは2024年5月9日に大規模なアプリリニューアルを行いました。アプリリニューアルに伴い負荷試験を行ったので、本記事ではどのように負荷試験を実施したか事例をご紹介します。 記事は計画編と実施編の2部構成で、本記事は後編の実施編です。前編の計画編は「WEARアプリリニューアルにおける負荷試験事例（計画編）」で公開していますので、まだ閲覧していない方はぜひご覧ください。 techblog.zozo.com 目次 はじめに 目次 背景 負荷試験の要件 使用した負荷試験ツール 負荷試験シナリオ作成 コード例 解説 ファイル構成について 仮想ユーザー（VU）について executorについて c

はじめに こんにちは。会員基盤ブロックの小原田です。弊社では、ZOZOTOWNという大規模なモノリシックシステムをマイクロサービスへリプレイスする取り組みを進めています。私が所属する会員基盤ブロックでは、ZOZOTOWNの会員情報を扱うマイクロサービスの開発と運用を担当しています。 会員基盤ブロックでは、開発生産性の向上を目指し、約半年間にわたり様々な取り組みを行ってきました。本記事では、会員基盤ブロックが開発生産性の向上のために実施してきた施策と、その成果について紹介します。 目次 はじめに 目次 開発生産性の向上に関する取り組みの背景 Findy Team+を用いた調査 会員基盤ブロックが抱える開発生産性の課題 サイクルタイム短縮の取り組み PRの変更行数を100行以下にする レビューを優先する仕組みの整備 ブレスト会の実施 品質向上についての取り組み Goガイドラインの策定 テストカ

はじめに こんにちは。データシステム部/推薦基盤ブロックの佐藤 (@rayuron) です。私たちはZOZOTOWNのパーソナライズを実現する推薦システムを開発・運用しています。推薦システムごとにKPIを策定していますが、データの欠損やリリース時の不具合によってKPIが意図しない値を取ることがあるため定常的に確認する必要があり、これをKPIのモニタリングと呼んでいます。 先日、推薦システムの実績をLookerでモニタリングするというテックブログで推薦システムのKPIをモニタリングする方法を紹介しましたが、運用していく中でいくつかの課題が見えてきました。本記事では、より効率的かつ効果的なKPIのモニタリングを実現するための取り組みについて詳しくご紹介します。 はじめに 改善の背景と課題 背景 課題 トレンドを考慮した異常検知が不可能 モニタリングの設定が面倒 アラート対応フローが不明確 サマ

はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上にモックリソースをサクッと構築する「モック構築ツール」を紹介します。ZOZOの事例をもとにした説明となりますが、Kubernetesクラスター上での負荷試験やフロントエンド開発などの効率化において広く一般的に活用できるツールのため、OSSとして公開しています。GitHubリポジトリは以下です。 github.com 本ツールは、私個人のOSSとして管理しています。ZOZOでは、社員がOSS活動しやすいように、「業務時間中に指示があって書いたソフトウェアでも著作権譲渡の許諾によって個人のものにできる」というOSSポリシーがあります。ありがたいです。 techblog.zozo.com 目次 はじめに 目次 モック構築ツールとは 開発のきっ

こんにちは、MA部MA開発ブロックの@gachi-muchi-engineerです。 私の所属するMA部で7月に開発合宿を実施しました。一般的に、開発合宿は開発者が集まって新しいサービスや機能を開発しますが、今回の開発合宿では開発しない開発合宿という形で実施しました。本記事では、今回行った開発合宿の目的と結果を紹介します。 開発合宿をおこなうことになった経緯 MA部ではシステム運用での課題がありました。その課題の原因を紐解くと人的な要因（システム理解や意識の問題）が大きく関わっていることがわかりました。そのため、メンバー全員が集まり、課題に取り組むことで、システム理解を深め、意識を統一することを目的に開発合宿を実施することにしました。 システム運用での課題とは MA部では日々の業務の中でアラート対応業務を行っています。アラート対応は、システムエラーなどの異常を検知し、ユーザー影響が出る前に

こんにちは、DevRelブロックのikkouです。2024年8月22日の夕方から24日の3日間にわたり「iOSDC Japan 2024」が開催されました。ZOZOは昨年同様プラチナスポンサーとして協賛し、スポンサーブースを出展しました。 technote.zozo.com 本記事では、前半は「iOSエンジニアの視点」から、ZOZOから登壇したセッションとiOSエンジニアが気になったセッションを紹介します。そして後半は「DevRelの視点」から、ZOZOの協賛ブースの様子と各社のブースコーデのまとめを写真多めでお伝えします。 登壇内容の紹介 LT: 全力の跳躍を捉える計測アプリを作る ポスターセッション: Haptic Feedbackでクセになるユーザー体験を提供しよう！ ZOZOのiOSエンジニアが気になったセッションの紹介 Server-Driven UI入門: 画面のStateを直

はじめに 技術評論社様より発刊されているSoftware Designの2024年5月号より「レガシーシステム攻略のプロセス」と題した全8回の連載が始まりました。 ZOZOTOWNリプレイスプロジェクトで採用したマイクロサービス化のアプローチでは、安全かつ整合性のとれたデータ移行が必須となりました。第4回では、このマスタDBの移行について紹介します。 目次 はじめに 目次 はじめに マスタDB移行 マスタDB移行について 要件と課題 テーブル構成を再設計したうえでデータ移行を実施する ダウンタイムなしでデータ移行を実施する 方針 異なるDBおよびデータスキーマ間で移行を実施するためEmbulkを使用する ダブルライトをリリースし、データ移行中に発生するDBへの書き込みを両DBにアトミックに実施する データを一時DBに格納し、一時DBから移行先DBにデータを移行する BulkloadとBac

はじめに こんにちは。基幹システム本部・物流開発部の上原です。昨年度に中途入社しまして、現在はZOZO基幹システムのリプレイスを担当しています。前職では、SESエンジニアとしてリプレイスプロジェクトに上流工程から参画し、大規模なシステムの言語リプレイスを経験してきました。さて私の紹介はこの辺りにして本題に入ります。 基幹システムリプレイスは既に進行しており、本年度には発送領域の機能を発送マイクロサービスとして切り出してリリースしました。それに続いて、入荷領域の機能をマイクロサービス化ではなくモジュラーモノリスに移行するリプレイスも進んでおり、こちらは細かく区切った単位でリリースをしています。 本記事では、自動テストによる「等価比較」を本番環境で実施しながら言語リプレイスを進めた事例を紹介します。この事例では、「言語間での処理の等価性を保証し、安心・安全にリプレイスをする」ということを目的と

はじめに こんにちは。株式会社ZOZOのSRE部プラットフォームSREチームに所属しているはっちーと申します。 本記事では、Kubernetesクラスター上で自動カナリアリリース機能を提供するFlaggerが導入済みのマイクロサービスにおいて、手動カナリアリリースを実施する方法について紹介します。一見、矛盾するように思えるかもしれません。しかし、時にはそのような要件も発生することがあります。また、手動カナリアリリースで運用している状態からFlaggerの導入を検討している場合、導入後も念のために現行の手動カナリアリリースができるのか、という点は気になるかと思います。すでにFlaggerを導入している、これからの導入を検討している、という方の参考になりましたら幸いです。 目次 はじめに 目次 前提知識（Flagger） Manual Gatingの基本 Manual Gatingとは Man

はじめに こんにちは、ZOZOMO店舗在庫取り置きというサービスの開発を担当している、ZOZOMO部OMOブロックの木目沢です。 皆様のチームでは定期的に振り返りをしていますか？ 弊ブロックではZOZOMO店舗在庫取り置きサービスをスクラムで開発しています。スプリント期間は1週間で、スプリントの終わりには毎週振り返り（スクラムの用語では「スプリントレトロスペクティブ」）をしています。 今回はなぜ振り返りが欠かせないか、毎週振り返りを行ってきた成果や数々のプラクティスやワークと共に紹介します。 目次 はじめに 目次 なぜスクラムでは振り返りが必要なのか？ 振り返りが続かない・活かされない理由 チームとしての振り返りになっていない チームとしての場ができていない 振り返りのプラクティスやチームのワークを紹介 KPT as ART チームコンピテンシーマトリックス デリゲーションポーカー おわり

はじめに こんにちは、WEARフロントエンド部Webブロックの新です。普段はWEARのWebサイトのリプレイス開発を担当しています。リプレイスを進める中で、不具合やリプレイス前後での変化にいち早く気づくため、Lighthouse CIによる日々の記録を可視化し定期的に通知する仕組みを作りました。本記事ではその取り組みについて詳しくご紹介します。 目次 はじめに 目次 背景・課題 Lighthouse CI とは やったこと 1. GitHub Actionsでページ毎にLighthouse CIを実行し、結果をGoogleスプレッドシートに保存 2. GoogleスプレッドシートをデータソースとしてLooker Studioでグラフ化 3. Looker StudioからGoogle Apps Scriptを使用するアカウントへメール配信 4. Google Apps ScriptでLoo

はじめに こんにちは！　WEARバックエンド部バックエンドブロックの高久です。普段は弊社サービスであるWEARのバックエンド開発・保守を担当しています。 10周年を迎えたWEARは2024年5月9日に大規模なアプリリニューアルを行いました。アプリリニューアルに伴い負荷試験を行ったので、本記事ではどのように負荷試験を計画したか事例をご紹介します。 記事は計画編と実施編の2部構成で、本記事は前編の計画編となります。後編の実施編は近日、公開予定です。 目次 はじめに 目次 背景 計画の重要性 計画の策定 目的の整理 目標値の設定 スループット レイテンシ 試験方針 試験環境・データ 対象範囲 取得情報・確認観点の整理 負荷シナリオ 実施方法 リスク リリースしてみたらユーザ数が予想を超えてしまい性能問題が発生する 試験対象外とした箇所に性能問題が発生する 本番環境での試験時に性能問題が発生しユー

こんにちは、ZOZOTOWN開発本部でZOZOTOWN iOSの開発を担当しているらぷらぷです。 2024年8月現在、ZOZOTOWN iOSチームは正社員と業務委託の方をあわせて全14人で構成されてます。 組織上、ZOZOTOWNのiOSチームは開発1部と開発2部の2チームに分かれています。しかし、リリースバージョンの計画・開発フロー・技術課題・その他チームに関わる課題意識はiOSチームメンバー全員で共有しながら改善を進めています。 そのような共有・議論がここ数ヶ月、週次イベントとして固定化してきたので、各イベントの振り返りも兼ねて皆さまにZOZOTOWNのiOSチームを支えるチーム運用の数々を紹介します。 1つのバージョンがリリースされるまで まずはこちらの図をご覧ください。 ざっくりですが開発期間を省いてQA準備からリリースまでの流れを描きました。今年から毎週金曜に定期的にQA配布す

はじめに こんにちは、ZOZOTOWN開発2部Androidブロックの小林（@kako_351）です。普段はZOZOTOWN Androidアプリの開発を担当しています。今年の3月に入社して機能改修や既存機能の調査などの業務に携わってきました。その中でZOZOTOWN Androidアプリについて知見を持っていないため、調査や開発の際に学習コストがかかるといった課題が見えてきました。本記事ではAndroidアプリの実装を把握するアプローチをご紹介します。 目次 はじめに 目次 背景 実装を把握するアプローチの全体像 ドキュメントの把握 目的 アプローチ モジュール構成や画面遷移などの全体構造の把握 目的 モジュール構成 画面遷移 アーキテクチャの把握 目的 アプローチ ライブラリや使用技術の把握 目的 アプローチ ビルドやデプロイなどCI/CD環境の把握 目的 アプローチ テストの把握 目

はじめに こんにちは、ZOZOMO部SREブロックの蔭山です。普段はFulfillment by ZOZOやZOZOMOのSREを担当しています。 今回ZOZOMOで提供しているサービスの1つである「ブランド実店舗の在庫確認・在庫取り置き」のマイクロサービス（通称realshop-api）にてMySQLにアクセスできる運用ユーザーの権限管理の最適化を行いました。本記事でその取り組みについてご紹介いたします。 目次 はじめに 目次 なぜ権限管理を最適化したのか 権限管理が複雑化してきた 秘密情報を閲覧できるメンバーを制限する必要がでてきた どのように最適化したか ロール機能を使った権限の標準化 秘密情報の保護自動化 秘密情報カラムの管理 秘密情報カラムへの権限剥奪を自動化 秘密情報カラムを除いたVIEWの自動作成 実施した結果 まとめ なぜ権限管理を最適化したのか realshop-apiで

こんにちは。ZOZO Researchの研究員の古澤・川島・平川、ZOZOのデータサイエンティストの荒木・小林です。2024年8月6日（火）から8月9日（金）にかけて熊本で開催された画像の認識・理解シンポジウムMIRU2024に参加しました。この記事では、MIRU2024でのZOZO Research・ZOZOのメンバーの取り組みやMIRU2024の様子について報告します。 目次 目次 MIRU2024 企業展示 全体の動向 招待講演・インタラクティブセッション [IS2-35] The Niau Dataset: A Comprehensive Resource for Fashion Image Recognition [IS2-126] 大規模視覚言語モデルを用いた「似合う」の自動評価法 [IS-2-097] Moon & SpencerのAesthetic Measureを用いたフ

はじめに こんにちは、計測プラットフォーム開発本部SREブロックの山本です。普段はZOZOMATやZOZOGLASSなどの計測技術に関わるシステムの開発、運用に携わっています。 我々のチームは、複数サービスを運用する中で障害対応の経験不足や知見共有の難しさといった課題に直面していました。そこで、半年ほど前にカオスエンジニアリングの導入を開始しました。 本記事では、カオスエンジニアリングを一過性のものではなくチームの文化として根付かせ、継続的な改善サイクルを生み出すための導入から運用まで、我々のチームでの実践から得られた具体的な方法をお伝えします。 これからカオスエンジニアリングを始めようとしている方はもちろん、すでに導入しているものの効果的な運用に悩んでいる方の参考になれば幸いです。 目次 はじめに 目次 背景・課題 カオスエンジニアリング導入の流れ 1. 目標とKPIの設定 1.1 目標

はじめに こんにちは、ブランドソリューション開発本部でWEAR by ZOZOのiOSアプリの開発を担当している山田（@gamegamega_329）です。 2024年の5月、WEARはAIを活用したファッションジャンル診断などの新たな機能やコンテンツを導入し「WEAR by ZOZO」（以下、WEAR）としてリニューアルしました。私が入社してからすぐにWEARアプリのリニューアルに取り組んできました。 当時、私は業務経験の浅い新卒1年目であり、リニューアルにおいてどのようにチームに貢献できるか不安を抱えていました。しかし、業務経験が未熟な中でも、自分の力で挑戦できるタスクを見極め、それに取り組み解決することでチームに貢献しました。 本記事では、大規模リニューアルプロジェクトに参画する中で私が直面した課題と、その課題を解決するための取り組みをご紹介します。業務に対して不安を感じる新卒iOS

はじめに こんにちは。ZOZOTOWN開発本部フロントエンドの菊地（@hiro0218）です。 現在、ZOZOTOWNではWebフロントエンド技術のリプレイスプロジェクトが進行しています。以前の記事ではCSS in JSの技術選定をした際の背景や課題について紹介しました。 techblog.zozo.com その後、「ZOZO Tech Meetup - Web フロントエンド」でおよそ1年後の状況を簡単に共有させて頂きました。 speakerdeck.com 今回はZOZO Tech Meetupでお話した内容に加えて、CSS in JS導入から2年後の現状を改めて紹介したいと思います。 CSS in JS導入後の運用状況 ZOZOTOWNの開発体制は、Webフロントエンドだけでも5つのチームが存在し、さらに外部の業務委託メンバーも加えると、開発に携わるメンバーは執筆時点でのべ50名を超

はじめに こんにちは。技術本部ECプラットフォーム部マイグレーションブロックの小原です。 本記事では、Spring BootのApplicationRunnerインタフェースを活用したバッチアプリケーション（CLIアプリケーション）の構築方法について解説します。 バッチ処理の実装において、SpringフレームワークはSpring Batchという強力なツールを提供しています。しかし、比較的単純なバッチ処理の場合、Spring Batchの使用はオーバーエンジニアリングとなる可能性があります。 そこで、軽量なアプローチとしてApplicationRunnerを利用した実装方法を説明します。この方法は、シンプルなバッチ処理に適しており、Spring Bootの機能を活用しつつ、必要最小限の実装で効率的なバッチアプリケーションを構築できます。 なお、本記事は下記の環境にて検証しました。 Java