Amazon Personalizeの導入における知見と注意点 - ZOZO TECH BLOG
こんにちは、ZOZO NEXTでウェブエンジニアを担当している木下です。先日、弊社が運営するオウンドメディアのFashion Tech Newsにおいて、記事リストのパーソナライズを行いました。本記事ではパーソナライズ導入における、要件定義、レコメンドエンジンの比較、実装での知見や注意点についてまとめます。 fashiontechnews.zozo.com 背景 解決方法の検討 課題の分析 パーソナライズ手法の検討 レコメンド方式について サービスの比較 Amazon Personalizeの実装 実装の流れ アーキテクチャ 実装での工夫点 採用したアルゴリズム アイテムデータの更新頻度 ユーザーの識別 注意点 AWS Personalizeのサンプルリポジトリが古い データの収集には時間がかかる まとまった料金が発生する まとめ 背景 「Fashion Tech News」とは、2018
スクラムを導入してチーム状態を可視化し持続可能なチームを目指す - ZOZO TECH BLOG
こんにちは、計測プラットフォーム開発本部システム部SREブロックの市橋です。2021年4月に新たに発足したチームで未経験ながらリーダーを任され、気づけば約2年が経過していました。これまでを振り返ってみると、まっさらな状態から安定したチームができてきたと感じています。今回は新米リーダーとして試行錯誤する中で、チーム状態を可視化して健全なチーム運営を目指した話を紹介します。 チーム状態の可視化を考えたきっかけ リーダーを任された当初、チーム運営上の課題が色々あるのは認識していましたが、どこから手をつけるべきかが自分の中で判然としませんでした。メンバーの時に一個人として感じていた課題も、チーム全体を俯瞰して見た時にどれから優先的に取り組むべきか自信を持って判断できませんでした。まるで大海原のど真ん中にいきなり放り出された感覚でした。 そんな悩みを抱えていた時、全社に導入されているWevoxのアン
ZOZOTOWN Androidチームで実践した多人数チームにおけるマネジメント施策 - ZOZO TECH BLOG
ZOZOTOWN開発本部 ZOZOTOWNアプリ部 Androidブロックの山田です。現在、私を含めた10名チームのブロック長としてZOZOTOWN Androidアプリの開発に取り組んでいます。 私がチームのマネジメント業務に携わったのは2019年4月からです。それ以降、常に7名以上のチームでマネジメント業務を務めてきました。経営学の用語で「スパン・オブ・コントロール」というものがありますが、そこにおいては「1人のマネージャー管理できる人数は5〜7人が適切」とされています。私個人の感覚では7名でも正直多く、5名ぐらいが適切のように感じています。 ともあれ、その状況を2年以上続けてきました。この経験を通し、多人数チームのマネジメントにおいて存在する課題が2つ見えてきました。 各個人に対するコミュニケーション時間減少に伴う、フィードバック量の低下と評価の難しさ チーム全体のパフォーマンス向上
Rubyを用いてGoogle Sheetsからリリースノートを取得しGoogle Play Consoleに自動アップロードする取り組み - ZOZO TECH BLOG
はじめに こんにちは、ブランドソリューション開発本部 フロントエンド部 WEAR Androidブロックの武永です。普段はファッションコーディネートアプリWEARのAndroidアプリを開発しています。 リリースノートを手動で毎回入力するのが面倒 WEARは多言語対応をしています。Google Play Consoleへアップロード後、Google Sheetsからテキストを4言語分コピーしたのち、申請画面でテキストを貼り付ける作業が面倒でした。誤って違う言語のリリース文言を記述してしまうリスクもあったので、検討した結果リリースノートもアプリと同じタイミングでアップロードすることにしました。 導入方法 今回はGitHub ActionsでRubyをセットアップし、Rubyのファイルを実行してリリースノートのテキストを取得します。それをテキストファイルとしてダウンロードします。使用するライブ
CodeDeployで構築するAutoScalingに追従可能なデプロイ環境 - ZOZO TECH BLOG
こんにちは。新事業創造部インフラチームの光野（kotatsu360）です。 先日、VASILY時代1から長らく使われていたCapistranoによるデプロイを見直し、CodePipeline+CodeDeployによるデプロイフローを導入しました。 CodeDeployはEC2 AutoScalingとよく統合されており、この新しいデプロイフローによって最新のアプリケーションコードをどう反映するかという悩みから開放されました。この記事ではそのフローについて設計と運用を交えつつ紹介します。 AWS CodePipeline / AWS CodeDeploy CodePipeline AWS CodePipelineはアプリケーションのCI/CDパイプラインを作るためのサービスです。 Source、 Build、 Test、 Deployの4ステージに対して1つ以上のアクションを割り当てること
Combineの非同期処理をSwift Concurrencyのasync/awaitで書き換えてみた - ZOZO TECH BLOG
こんにちは、FAANS部の中島 (@burita083) です。2021年10月に中途入社し、FAANSのiOSアプリの開発を行なっています。 FAANSの由来は「Fashion Advisors are Neighbors」で、「ショップスタッフの効率的な販売をサポートするショップスタッフ専用ツール」です。現在正式リリースに向けて、WEARと連携したコーディネート投稿機能やその成果を確認できる機能など開発中です。 はじめに FAANS iOSでは非同期処理にCombineを利用しています。Combine自体は本記事では詳しく解説をしませんが、RxSwiftを利用したことがある方なら特に違和感なく使えるかと思います。全く馴染みがない場合だと覚えることも多く、難しいところもあるかと思いますので、Swift Concurrencyを利用する方が理解しやすいかもしれません。ただし、ViewとPr
WEARにおけるSLOを用いた信頼性改善の取り組み - ZOZO TECH BLOG
こんにちは、WEAR部バックエンドブロックの小山とSREブロックの繁谷です。 WEARでは日々システムの信頼性を向上させるため改善に取り組んでいます。今回はその中でもSLOに基づいた改善について紹介いたします。 WEARリプレイスの歩み WEARでは2019年から本格的にリプレイスを開始しましたが、当初は専属のSREはおらずインフラ構築など緊急度の高いものをバックエンドのエンジニアや、プロダクト横断のSREが担っていました。 WEARのSREとして活動に割ける時間も短かったためSLI(Service Level Indicator)1やSLO(Service Level Objective)2の指標もありませんでした。WEARにおけるリプレイスの変遷についてはこちらのスライドに詳しく載せられているため、ご興味のある方は是非ご覧ください。 WEARの組織における課題 WEARでは2021年4
コードレビューを通じたチームパフォーマンス向上のための取り組み - ZOZO TECH BLOG
こんにちは。ECプラットフォームサービスSREチームリーダーの川崎（@yokawasa）です。本記事では、コードレビューを通じたチームのパフォーマンス向上のための取り組みについてご紹介します。なお、コードレビューそのもののテクニックに関する話はしないので、あらかじめご了承ください。 目次 目次 はじめに コードレビューはチーム全体のパフォーマンス向上のため 複数ユニット、複数チームで行う 活動状況を定量的に評価する コードレビュー体験を向上させる レビュアーの負担を減らす 同期・非同期コミュニケーションを使い分ける 参加しやすい雰囲気を作る 1. 心理的な安全性を高める 2. チームの共通目標にする さいごに はじめに まずはじめに、我々はGitHubのPull Request（以下、PR）機能を活用してコードレビューをしています。下記の記事でも書いているようにIaCとCI/CDを基本ルー
カスタムmitmproxy入門 - ZOZO TECH BLOG
VASILYのiOSエンジニアにこらすです！ 今回はプロキシツールmitmproxyのカスタムスクリプト機能について説明したいと思います。 モバイル開発をする際にAPIリクエストのデバッグツールとして mitmproxy はとても役に立ちます！ カスタムスクリプトを使うと何ができるか カスタムスクリプトを書くと、mitmproxyの動作をプログラムでカスタマイズすることができます。 モバイルデバイスのリクエストやレスポンスを書き換えたり、通信を遅延させたりできます。 どうやってスクリプトを書くか mitmproxyはPythonで実装されているので、カスタムスクリプトもpythonで実装することになります。 mitmproxyにはいろいろなイベントがありますが、各イベントをオーバーライドするメソッドを書くことができます。 例えば、script_name.py というPythonファイルにオ
オンプレDWHをBigQueryに移行した話 - ZOZO TECH BLOG
はじめに こんにちは。MA部MA施策・運用改善チームの辻岡です。MA部では、ZOZOTOWNのメルマガ・アプリPUSH通知などの配信・分析等の用途で約数十TBのデータを運用しています。今回は長年MAのデータ基盤として利用してきたオンプレDWHをBigQueryに移行したおはなしをします。 この記事はこんな方におすすめ オンプレDWHからBigQuery移行を検討・実施してる方 ジョブ・スケジューラ、ETLツールの移行を検討・実施してる方 概要 オンプレDWHからBigQuery移行する前後の構成イメージを元に、今回の移行の話について概要を説明します。 次の図が移行前の構成図です。オンプレ環境のWindowsサーバ上でジョブ・スケジューリングと実行を基盤処理として、データウェアハウス（以後オンプレDWH）に対してデータ生成や外部システムとの連携をしていました。 今回、以下を目的にオンプレDW
リアルタイムなプッシュ通知を可能にした配信基盤の紹介 - ZOZO TECH BLOG
※2022-06-07 システムアーキテクチャの画像を修正しました。 はじめに こんにちは、MA部MA基盤ブロックの齋藤（@kyoppii13）です。 ZOZOTOWNではアプリ向けのキャンペーンやセール情報などの配信でプッシュ通知を利用しています。プッシュ通知で配信するキャンペーンはセグメントに向けたマス配信のみで、ユーザごとにパーソナライズして配信するためのパーソナライズ配信には利用していませんでした。また、パーソナライズ配信の中にはリアルタイム性が求められるキャンペーン配信も含まれます。そこで、リアルタイムキャンペーンでプッシュ通知するための配信基盤を作成しました。 本記事では、リアルタイムなプッシュ通知を実現するために作成したシステムの紹介と、安定した配信を実現するために行った工夫について紹介します。 はじめに 従来のプッシュ通知と課題 従来のプッシュ通知 問題点 導入した配信基盤
登壇者を5倍に増やした秘策 - iOSDC Japan 2020に向けたZOZOテクノロジーズの取り組み - ZOZO TECH BLOG
こんにちは！ ZOZOTOWNのiOSアプリ開発をしている林と松井です。先日、9/19から9/21までの3日間iOSDC Japan 2020が開催されました。 ブログを書くまでがiOSDC！#didyoublog? 今年はコロナ禍でオンライン開催となり、現地の盛り上がりを体感できませんでしたが、ニコニコ生放送の弾幕などオンラインならではの楽しみがありましたね。また、例年通り素晴らしい発表が盛り沢山でした！ オンライン開催においても弊社はスポンサーとして協賛し、10名を超えるメンバーが参加しています。うち5名はスピーカーとしての参加でした。この記事ではiOSDC Japan 2020で登壇するために行った弊社の取り組みと、登壇した社員の発表をご紹介いたします。 採択率向上と登壇内容ブラッシュアップのための取り組み iOSDC Japan 2019ではZOZOテクノロジーズの登壇者が1名のみ
ZOZOTOWNの監視にモダンなツール（Datadog、PagerDuty、Sentry）を導入した話 - ZOZO TECH BLOG
こんにちは。カート・決済チームの濱砂です。 今回はZOZOTOWNのサーバーサイドの監視方法や取り組みについて紹介します。 はじめに 監視の課題 1. 可視化 2. アラートの検知 3. エラーの管理 改善後 1. Datadogで可視化 Sample Script DSL DatadogのDashboard 2. DatadogとPagerDutyでエラー検知 DatadogのSlack通知 DatadogのAlertの設定 PagerDutyのスケジュール設定 3. Sentryでエラーの管理 Sample Script Sentryに送られたエラー一覧 まとめ 最後に はじめに 現在、ZOZOTOWNでは現行のシステム基盤や開発プロセスをリプレイスするプロジェクトが進んでいます。 リプレイスは順調に進んでいますが、未だ多くは現行のまま動いており、在庫管理を行う基幹システムやバッチ処理
ZOZOTOWNアプリHome画面再設計の軌跡~10年以上歴史を持つアプリはどのようにして生まれ変わったのか~ - ZOZO TECH BLOG
はじめに こんにちは、ZOZOアプリ部でZOZOTOWN iOSアプリを開発している小松です（@tosh_3）。 気づけば、ZOZOテクノロジーズに新卒入社して1年が過ぎていました。オフィスの近くに引っ越したのですが、オフィスに出社する前に、オフィスが移転しました。 さて突然ですが、最近ZOZOTOWNに大きな変化があったことをみなさんお気づきでしょうか。2021年3月18日よりZOZOTOWN全体が大幅リニューアルされ、コスメモールがオープンされるなどの大きな変化がありました。アプリも7.0.0とメジャーバージョンの更新を行い、ほとんど全ての画面が新デザインになりました。 そこで、本記事ではHome画面のリニューアルを担当した私が、そこで使用した技術とその背景について触れながら、ZOZOTOWN iOSアプリのHome画面リニューアルの裏側をお伝えします。 ZOZOTOWNアプリの新旧デ
ZOZOTOWN検索機能のマイクロサービス化への取り組み - ZOZO TECH BLOG
はじめに こんにちは、検索基盤部 検索基盤チームの可児（@KanixT）です。以前は通勤に片道2時間ほどかかっていましたが、フルリモートワークの環境になり空いた時間で生後4か月の娘の子育てに奮闘中です。 本記事では、検索基盤チームが取り組んだZOZOTOWN検索機能のマイクロサービス化の事例・工夫点を紹介します。これから検索機能のマイクロサービス化にチャレンジする方の参考になれば幸いです。 目次 はじめに 目次 背景と課題 検索機能に特化したマイクロサービスの構築 どのように構築したか 構築時にやったこと APIの実装 静的解析 ヘルスチェックの実装 複数エンドポイントのヘルスチェック 単一エンドポイントのヘルスチェック 各種バージョンアップ Java Swagger OSSのライセンスチェック 外部サービス リリース リリース時にやったこと 得られた効果 開発速度の向上 検索機能に特化し
Aurora MySQLからCloud SQLへのレプリケーション構築における注意すべき2つのポイント - ZOZO TECH BLOG
こんにちは、MA部でエンジニアをしている田島です。 以前に弊社の塩崎が「Amazon AuroraのデータをリアルタイムにGoogle BigQueryに連携してみた」という発表を行いました。 こちらの発表では、Amazon Aurora MySQLのデータをGoogle BigQueryへリアルタイムにデータ連携する方法を紹介しています。リアルタイムデータ連携を実現するために、Aurora MySQLをレプリケーションソースとしてGoogle Cloud SQLへレプリケーションします。そして、BigQueryのFederated Query機能を利用してリアルタイムにデータを参照できるようにしています。 本記事ではその中の、Aurora MySQLからCloud SQLへのレプリケーション部分にフォーカスします。Aurora MySQLがマネージドサービスだからこそ発生する大きな注意ポ
EC2 Image Builderを用いたRedashの運用改善 - ZOZO TECH BLOG
こんにちは、SRE部の谷口（case-k）です。 本記事では、EC2 Image Builderを使いRedashの運用改善を行った事例をご紹介します。運用しているRedashについてご紹介し、その後、Redashの運用課題に対してEC2 Image Builderでどのように解決したかTipsも踏まえご紹介します。 余談ですが全国どこでも働けるようになったので沖縄に住めています(感謝！) https://press-tech.zozo.com/entry/20210118_zozotechpress-tech.zozo.com 目次 目次 運用しているRedashの紹介 役割 インフラ構成 クエリ実行の流れ EC2インスタンス起動時の処理 Redashの運用課題 EC2 Image Builderによる課題解決 EC2 Image Builderの紹介 各リソースのTips 事前準備 コ
ZOZOTOWNのPUSH配信基盤をFCMにシームレスに移行するための考慮ポイント - ZOZO TECH BLOG
こんにちは、MA基盤チームの田島です。ZOZOTOWNでは、ユーザコミュニケーションの手段としてLINE、MAIL、アプリへのPUSH通知を利用しユーザへのお知らせを実現しています。 その中でも、現在ユーザへのコミュニケーション強化の一環としてアプリPUSH通知（以降、PUSH通知）の強化をしようと考えています。ZOZOTOWNのPUSH通知は今まで、とある外部SaaS（本記事で出てくるSaaSはすべてこの外部SaaSを表します）を利用していました。しかし、PUSH通知チャネルの強化をする上で、利用していたSaaSでは要件を満たせない部分がありました。そこでPUSH通知のためのツールとしてFirebase Cloud Messaging（FCM）に移行しました。 本記事ではPUSH配信基盤の紹介並びに、移行時に行ったことを紹介します。PUSH配信基盤の構成や、PUSH配信ツール移行時の参考
テレワーク環境下における数式とソースコードを交えた輪講の実践 - ZOZO TECH BLOG
ZOZO研究所の森下（@IshyMore）です。本記事では、数式とソースコードを含む教材を用いてテレワーク環境下で輪講を実施した際に、スムーズに輪講を進められるよう工夫した点について紹介します。 目次 目次 輪講の目的 教材の選定理由 内容が基本的で、応用範囲が広い 数式に対応したソースコードが載っている 演習問題が大量にある 輪講の進め方 輪講運用のための仕組みづくり Jupyter Notebookによる統一 Jupyter Notebook用diffツールの採用 ライセンスの明記 演習問題ごとにファイルを新規作成 Pythonの環境構築 フォーマッタの検討 フォーマットチェックの自動化 コミュニティへの貢献 参加者への事後アンケート まとめ おわりに 輪講の目的 ZOZO研究所では日々の研究開発の傍ら、論文の輪読会、興味・関心事を紹介する勉強会、研究者を招待しての講演会など行っていま
High Level Rest ClientによるElasticsearch本番運用ガイド - ZOZO TECH BLOG
こんにちは。ZOZOテクノロジーズZOZOTOWN部 検索チーム 兼 ECプラットフォーム部 検索基盤チームの有村(@paki0o)です。 ZOZOTOWNではこれまで度々紹介してきた通り、検索エンジンとしてElasticsearchを利用しています。リクエスト元のサーバーサイドのアプリケーションはJava（Spring Boot）で書かれており、クライアントにはHigh Level Rest Client（以下、HLRC）を使用しています。 www.elastic.co techblog.zozo.com HLRCを実際にプロダクション環境で運用していく中で、サービスのSLAを満たすために安定稼働させるための設定や、効率的に通信するための設定などを細かく指定しました。現在の設定にたどり着くまで、ドキュメント上で表現されていなかったり機能が用意されていなかったり等様々な苦労があったので、ま
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
