こんにちは、基幹システム部の伊藤です。 私は現在ZOZOのバックオフィスのシステム開発をしていますが、以前はZOZOBASEの入荷セクションで勤務していました。本稿では物流とエンジニアの両視点からZOZOBASEを支える仕組みの一部を紹介します。 ZOZOBASEについて知りたい方は、 物流倉庫の実績集計を自動化して現場の負担を軽減したはなし をご覧ください。 はじめに 弊社物流プラットフォームであるZOZOBASEは、お客様宅への配送以外、物流に関わる全てを自社で行っている強みを生かすことで年間取扱高3000億を超える国内最大のアパレル物流拠点になりました。2020年の秋には新しい物流センターの本格稼働を目指しており、私たちは日々ZOZOの成長を感じています。ZOZOBASEでは多くの従業員が日々ものすごい物量をさばいているのですが、ブランド様と色々なデータを連携することで、ZOZOBASEの様々な作業の効率化を実現しています。 今回はその中の「出荷データ連携」にフォーカスし、データ連携をすることで、ZOZOBASEのどういった作業にどのようなメリットがあるか説明していきたいと思います。 出荷API 出荷データ連携の機能はAPIとして提供しており、ブランド様から商品情報とZOZOBASEへの出荷情報をまとめて受け取るAPIです。商品がZOZOTOWN上に出るまでにはブランド様による 商品登録 → ZOZOBASEでの荷受 → 検品 → 採寸 → 撮影 → 棚入れ というステップを踏むのですが、この出荷APIはステップ上流の「 商品登録 → 荷受 → 検品 」を効率化するための仕組みになります。 次に、作業毎にデータ連携の有無によってどれくらい作業内容に違いが出てくるのかを説明します。 1. ブランド様による商品登録 2. ZOZOBASEでの荷受作業 3. ZOZOBASEでの入荷作業 1.ブランド様による商品登録 ZOZOTOWNで販売する商品情報の登録はブランド様が行います。商品情報は主に以下の様な内容で構成されています。 商品データ（商品単位） 商品名 ブランド品番 商品カテゴリID 商品単価 商品の素材 原産国 商品説明文 品番 性別タイプ 商品データ（カラー・サイズ単位） カラーID サイズID 商品バーコード これらは商品を構成する情報の一部ではありますが、1つの商品に対してもこれだけの情報の登録が必要になります。 データ連携を行っていない場合、以下の課題が常に付きまとうことになります。 管理画面から手入力で商品情報を登録するため、手間・コストが大きい 商品登録ミスが発生しやすい 販売までのリードタイムが長くなることによる販売機会ロスが発生する 管理画面からの定型データのアップロードによる一括で商品登録を行う機能も提供していますが、取扱商品数の多いブランド様だと毎日のように新商品が発売されるので、その運用すら煩雑です。 また、ZOZOBASEの荷受時のマスト条件として商品情報が登録済みであることです。商品の登録作業に時間が掛かることで、ZOZOBASEへの出荷が遅れ、販売開始までに時間を要することで販売機会を逃してしまうかもしれません。 データ連携を行う場合、以下のように、手動登録で生じる可能性のある課題がデータ連携により解決できます。 仕組み化してしまえば自動で商品登録が行われる 人の手を介さないため登録ミスがほとんど起きない 手動登録で要していたリードタイムを大幅に削減できる 出荷データ連携によりこういったメリットが生まれますが、開発に合わせてブランド様にやっていただく準備があります。 商品登録時に必要な情報として、ZOZOのカテゴリID・カラーID・サイズIDといったものがあるのですが、こちらとブランド様の各種マスタIDをマッピングデータという形で定義していただく作業です。 ブランドA社の、 カラー：ホワイト（ID:001） = ZOZOのカラー：ホワイト（ID:4） カテゴリ：Tシャツ（ID:384） = ZOZOのカテゴリ：Tシャツ（ID:7411） といったような変換テーブルのようなイメージです。 マッピングするデータはカテゴリ・カラー・サイズなど5,6種類、レコード総数で10000件を超えるブランド様もあります。はじめにマッピングテーブルを作る作業は苦労されている印象ですが、我々は今まで数十社との連携の実績がありますので、必要に応じて弊社からもアドバイスをしながら作成の支援をさせていただいています。 また、商品登録と同時にZOZOTOWNでサイズ検索を可能にする検索タグの登録を行っています。検索タグを登録することでお客様が「SサイズのTシャツ」を検索した際、サイズ名が「S」や「SMALL」の商品だけでなく「7号」や「36」など、そのブランドのSサイズに相当する商品を検索結果に表示することが可能になります。 こちらもマッピングで実現しており、 A社のサイズ36 = ZOZOの検索サイズの「S」 B社のサイズ36 = ZOZOの検索サイズの「M」 といったブランド様毎のマッピングテーブルをZOZO側で保持して、商品登録時にそこを参照しながらサイズ検索用のデータを作成しています。こちらのマッピングデータは、ブランド様が弊社の管理画面から自由に編集することが可能です。 このように、APIで受け取った商品情報を自動で登録する仕組みにより、手動登録の課題をほぼすべて解決できています。 ブランド様に連携の仕組みを整えていただく必要はありますが、10年以上前から徐々に連携ブランドを拡大し、今ではZOZOで販売される商品の約4割がデータ連携で登録されています。 2.ZOZOBASEでの荷受作業 次はZOZOBASEでの物流のスタート地点である荷受作業になります。ここからは出荷APIで商品情報と同時に受け取ったZOZOBASEへの出荷情報を活用します。荷受作業ではブランド様から納品された荷物を受け取り、同梱されている紙の納品書をデータ化する作業を行っています。納品書に記載されている情報は主に以下の項目です。 納品書情報 納品書番号 納品書日付 品番 カラー サイズ 納品数量 データ連携を行っていない場合は紙媒体の納品書に記載されているブランド品番から事前に 1. でブランド様が登録した商品データを参照し、納品書番号や数量の入力をしていきます。紙の納品書を見ながらの手入力となるため、入力ミスが発生しやすく作業に時間を取られることで、ここでもリードタイムがかかり販売機会ロスにつながります。 データ連携を行う場合、出荷APIでは 1. の商品情報の登録と同時に出荷情報を活用して、荷受作業で人の手で行っている納品書のデータ化を自動で行っているので、上記の荷受作業を完全にスキップできます。データ連携されているブランドの商品は着庫後直ぐに荷受の次の工程である入荷作業へ移行でき、荷受作業で発生するリードタイムを丸ごとカットできます。 3.ZOZOBASEでの入荷作業 最後は入荷作業です。入荷作業には2種類あり、データ連携をしていない商品を入荷する場合は目検で数量確認を行い、データ連携をしている商品を入荷する場合は商品タグに記載のバーコードの読み取りによる数量確認をしています。弊社では前者を「通常検品」、後者を「バーコード検品」と呼んでいます。 <通常検品> 通常検品は納品書と商品に付いた商品タグの情報を照らし合わせ、品番や数量などに間違いがないかをチェックし、商品管理シールを貼って入荷を行う方法です。この照らし合わせ作業が目視による作業となるため、どうしても作業時間が掛かってしまいます。数量のチェックが必須なため、複数人で行う必要があることから生産性が良くありません。 また、ここでも入力ミスが課題で、それによる過剰入荷（商品は3点しかないのに4点として在庫計上してしまう）なども起こりえます。その状態のまま販売開始の処理がされると在庫数以上に注文を受けてしまいお客様にご迷惑をおかけする原因にもなります。 こういった作業の特性から、ある程度作業の経験を積まないと円滑な作業が行えないことも難点です。 <バーコード検品> バーコード検品は商品に付いているブランドタグのバーコードをスキャナーで読み込み、在庫の計上と商品管理シールを発行する仕組みです。 通常検品と比較したときのメリットとして、以下の点があげられます。 作業が簡単で熟練度による作業量のばらつきが少ない バーコードを読む度に、事前に連携された出荷情報と突合することで商品タグや数量の目視確認が不要 入荷数を入力する作業がないので入力ミスが発生しない この入荷方法は、1.の段階で登録された「商品バーコード」情報と、同時に連携された出荷情報を活用して実現しています。「商品バーコード」情報は、商品に付いているタグに記載のバーコードと同じもので、スキャンしたタグのバーコードをあらかじめ連携された出荷情報内のバーコードと突合し入荷すべき商品であるかのチェックを行い、同時に在庫を1点計上しています。目視の作業がないので作業スピードも通常検品に比べて圧倒的に早く、入荷数の入力作業もないので入力ミスによる過剰・過少入荷も基本発生しません。 また習熟不要な入荷方法であることから、初めて作業をする人でもある程度の作業実績を上げることができるので作業が平準化されて作業予定が立てやすくなり、教育コストの削減にも寄与しています。 まとめ 今回紹介した出荷APIの例を見ただけでも、ブランド様の作業の自動化やZOZOBASEの作業の効率化に大きな効果があることをご理解いただけたかと思います。出荷API以外にも、多くのデータ連携の仕組みが稼働しており、ZOZOTOWNの要であるブランド様とZOZOBASEの作業を裏側から支えています。また、継続して連携ブランドの拡大も進めているため、さらなる作業効率化を目指して新たな連携の仕組みも増えてきています。 一方、連携するブランド様やデータの種類が増えることで管理・運用コストの増大が顕在化してきており、それは今後の解決すべき課題として考えています。 さいごに ZOZOテクノロジーズでは、今回紹介したような裏側の仕組み作りや、運営する様々なサービスを一緒に作り上げていける方を募集しています。ご興味のある方は、以下のリンクからぜひご応募ください。また、データ連携にご興味を持たれたブランド様がおられましたらZOZO営業までお気軽にお問い合わせください。 tech.zozo.com

こんにちは、SRE部ZOZO SREチームの中道です。 私が所属するZOZO SREチームは、普段ZOZOTOWNのインフラをメインに、サーバ・ネットワーク・仮想基盤・クラウド・バックアップなどの構築運用を担当しています。 DRやBCP対策の中でバックアップ/リカバリの体制や構築に悩むことは多いと思います。今後DRを検討していくにあたり、バックアップ/リカバリ方式改善のために導入したCohesityについて紹介したいと思います。 環境や状況によってバックアップ/リカバリに関する課題は様々ですが、チーム内で主にあがっていた課題は以下の3点です。 既存フローの課題点 それまで利用していたバックアップ/リストアの方式がベンダー考案・構築されているものが多い OS、DB、Webなどの対象ごとにバックアップ/リストア方式（手順書）が異なる 手順書が長く複雑で、手数が多く、リストア実績が少ない 以前まではツールの選定やフローの導入をベンダーに任せていた事が多かったため、ベンダー依存から脱却し、まずは自分たちでしっかり対応できる環境を整備する必要がありました。 複数のOS、物理サーバ、仮想サーバ、DBなどの対象ごとにバックアップ/リストアの方式が異なり、別々で手順が用意されているため、手順書が多く複雑でスムーズに対応できませんでした。チーム全員が同じレベルでの理解・把握が難しく、手順書を見てすぐ対応できるとは言い難い体制であったと思います。 定期的に復旧訓練を実施していますが、本番と同等の環境での訓練は難しかったりもします。また、実際に障害が起きたとき、迷いなくスムーズにリカバリを行えるのか？　自信をもってできるといえるのか？　そこには不安な部分もあり、大きな課題であったと思います。 また既存バックアップ製品ではバックアップとリカバリに時間がかかり、SLA要件を満たせないなどの問題がでてくることもあると思います。 そうしたことから、インテリジェンスなリカバリを行える環境・体制を整える必要となり、バックアップソリューションのリプレイスを進めることになりました。比較検討した結果、運用している環境にマッチしていること・設定の容易性・単一インタフェースで対応できることによる統合効果などから、 Cohesityの導入を進めました。 Cohesityの機能について簡単に説明していきたいと思います。 Cohesityについて ハイパーコンバージド型の統合セカンダリ・ストレージがコンセプト データ保護のサイロをなくし、単一の管理UIでポリシーベースの保護が可能 制限がなく、透過的なスケールアウトやオンラインでのアップグレードと拡張が可能 グローバル重複排除と圧縮による効率化の実現 データ保護だけでなく、ファイル、オブジェクト、分析、テスト/開発などさまざまな活用が可能 広範なアプリケーションとインフラストラクチャのサポート あらゆるデータを保護 資料提供元：Cohesity Cohesityの基盤となるのが、ストレージ基本管理ソフトウェアの Cohesity DataPlatform とバックアップ管理ソフトウェアの Cohesity DataProtect です。 Cohesity DataPlatform Cohesity DataPlatformは、Webスケールのアーキテクチャーを基本として、独自の分散ファイルシステムであるSpanFSに基づくスケールアウトソリューションです。複数のセカンダリワークロードを単一のプラットフォームに統合することで、セカンダリデータとセカンダリアプリケーションの管理をモダナイズおよびシンプル化します。 資料提供元：Cohesity Cohesity DataProtect Cohesity DataProtectは、コア、クラウド、エッジまでの広範囲をカバーし、最新のアプリケーション主導型インフラストラクチャを実現する、高パフォーマンス且つソフトウェアデファインドのデータ保護ソリューションです。仮想または物理的なDB、NAS、クラウド環境といったさまざまな場所のワークロードをポリシーベースですべて管理し、包括的に保護します。サイロ化した従来のバックアップをなくし、バックアップとリカバリを操作しやすい単一のユーザーインタフェースによって管理することで、データ保護を根本的に簡素化します。 Cohesityの導入によって目指した改善点は主に以下の3点です。 Cohesity導入で目指す改善点 作業手順の簡素化・単純化 バックアップリストア方式の統一化 運用の省力化 具合的にCohesityの機能・操作について、説明しながらみていきたいと思います。 ダッシュボード VM、物理サーバ、NASなどのバックアップはすべてデフォルトのDashboardから情報が確認できます。MS SQLだけが独立のDashboardとなり、下記のようにより詳細な情報の確認が可能です。 バックアップ バックアップ取得までの流れを説明します。必要な操作は下記のステップになります。 対象ソースの登録 ポリシーの作成 バックアップジョブの作成・実行 バックアップジョブの実行確認 1. 対象ソースの登録 物理マシンにはCohesity Agentをインストールします。Cohesity AgentはDashboardからダウンロードできます。仮想マシンでは、例えばVMであればvCenterを登録することで、仮想マシンのバックアップの取得が可能になります。 2. ポリシーの作成 ポリシーの作成で実行頻度、保持期間、バックアップ形式等を設定します。ひとつのポリシーを複数のバックアップジョブで利用できます。デフォルトで3つのポリシーが用意されており、そのまま利用することもできますし、デフォルトポリシーを元に編集し利用することも可能です。 3. バックアップジョブの作成・実行 バックアップジョブの作成でソースの選択、オブジェクトの追加、ポリシーの選択、実行時間等を設定します。永久増分バックアップなので、2回目以降のバックアップの所要時間が短縮されます。VM、DBも同じステップで設定可能です。 4. バックアップジョブの実行確認 Protection Jobs画面から実行のステータスを確認できます。 リカバリ 次にリカバリ方法について説明します。必要な操作は下記のステップになります。 リカバリジョブの実行 リカバリジョブの実行確認 1. リカバリジョブの実行 ここでは仮想マシンのリカバリの手順を記載します。リカバリ画面でVMsを選択し、対象マシン、任意のデータを選択します。リカバリ対象の仮想マシンがすでに削除されている場合は、Rename Recovered VMsのチェックを外すことで同一の仮想マシンとしてリカバリできます。Networking OptionsでDetach networkにチェックを入れることで、ネットワークから切り離された状態でリカバリできます。 Point-in-timeのリカバリ SQLサーバでは、データベースのバックアップおよびT-logのバックアップを組み合わせて、Point-in-time（いつの状態でもリカバリ可能）のリカバリが対応可能です。Point-in-timeリカバリの画面は下記のようになります。カレンダーベースとなり非常にわかりやすい画面です。 2. リカバリジョブの実行確認 Recovery画面から実行のステータスを確認できます。 クローン さらにクローン機能について触れたいと思います。Test & Devという機能で、バックアップデータをテスト利用することが可能です。 対象 動作 VM 指定スナップショットをNFS共有して、vCenter & ESXi上にデータストアとしてマウント、VM起動します。 SQL 指定スナップショットを、SMB共有してWindowsサーバ側でマウントし、SQLサーバはSMB共有上のデータ・ログファイルを使って、データベースを定義します。 必要な操作は下記のステップになります。 クローンの作成 クローンの実行確認 クローンの削除（ティアダウン） 1. クローンの作成 ここでは仮想マシンのクローンの手順を記載します。Test & Dev画面でVMsを選択し、対象マシン、任意のデータを選択します。詳細設定を行いクローンを生成します。 2. クローンの実行確認 Test & Dev画面から実行のステータスの確認ができます。 3. クローンの削除（ティアダウン） Test & Dev画面からTear Downを実行します。 動作のまとめ SQL バックアップ SQLサーバのバックアップ機能ではなく、OSレベルのVSSを利用してバックアップを行う。　※今後VDI APIを利用しての動作に変更予定。 ログはVDIを利用してバックアップ。　※VDIは無停止が可能。 WindowsにインストールしたCohesity Agentに、Cohesityから指示を送って実施する。 WindowsがデータをCohesityに送信。 Cohesity Agentが、SQLサーバの情報を読み取りVSSを含め適切に動作。 リカバリ Cohesity本体上の指定スナップショットをSMB共有して、Windowsサーバ側でマウント。 SMB共有上のデータ・ログファイルを使ったCohesity Agentが、SQLのリストアコマンドを発行。 必要なログのマージなどもここで実施。 リストアコマンドに基づいてデータベースがアクセス可能な状態になる。 クローン Cohesity本体上の指定スナップショットをSMB共有して、Windowsサーバ側でマウント。 SQLサーバはSMB共有上のデータ・ログファイルを使って、データベースを定義。 上記の動作を約10秒程度で準備し、データベースとしてアクセス可能（Read/Write共にOK）な状態にできる。 最終的にTear Downボタンにて廃棄する動作（廃棄までがクローンの一連の流れ） VM バックアップ vCenterと高度な連携を行い、最新の管理情報を元にした動作を行う。 vCenterを経由したAPI情報を元に、vCenterライクなUIによって対象を決定。 バックアップ操作を行うと、ESXi上でスナップショットの取得を実施。 Cohesityのボリュームを、NFSでESXi上にマウント。 上記スナップショットを、CohesityのNFSデータストアにESXiが書き込み。 バックアップ終了後、ESXi上のスナップショットを削除。NFSのアンマウント。 リカバリ Cohesity本体上の指定データストアとしてスナップショットをNFS共有して、vCenter & ESXi上にマウント。 上記のファイルを利用してVMのインベントリ登録＆起動（PowerOnを選んだ場合）※インスタント・マス・リカバリ機能。 裏ではストレージvMotionを利用して、指定ターゲットにファイルを配備。 ストレージvMotionの途中でVMは利用可能になる（PowerOnを選んだ場合） すべてが終わったらNFS共有がアンマウントされる。インベントリ情報も実際のターゲットのデータストアに切り替わる。 クローン Cohesity本体上の指定スナップショットをNFS共有して、vCenter & ESXi上にデータストアとしてマウント。 上記のファイルを利用してVMを起動（PowerOnを選んだ場合） 上記の動作を約20秒程度で準備し、その後OSが起動すれば利用できる（検証環境では、ログインプロンプトまで3-5分程度かかった） Read/WriteいずれもOK。バックアップには影響なし。 最終的にTear Down Cloneボタンにて廃棄する動作（廃棄までがクローンの一連の流れ） ※上記の数値は弊社での検証時の値になります。 上述した通り、VM、SQLのバックアップ・リカバリ・クローンの操作感はほぼ変わらないことがわかるかと思います。現代的なUIのもと、非常にテンポよく操作が可能です。VMとSQLが同じコンソールで対応できることによる、統合効果も大きいと思います。 導入による効果 既存のバックアップソリューションでは手順書で10ページ以上はあった各手順が、直感的に操作可能なUIによって作業手順の簡素化、単純化を可能にしました。さらに複数あったバックアップ/リストア方式の統一化を可能にしました。 今後既存バックアップを集約することで運用の省力化をさらにはかってきたいと考えています。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

こんにちは。ZOZOテクノロジーズZOZOTOWN部 検索チーム 兼 ECプラットフォーム部 検索基盤チームの有村です。 ZOZOTOWNでは、以前からキーワード検索時にはRDBと併用してElasticsearchを使用していました。本記事ではこれまでRDBで行っていたIDによる索引検索も含め、すべての検索をElasticsearchへ置き換えた事例と、その際に行った設定内容の一部をご紹介します。 背景 弊社CTOによるこちらの記事 にもある通り、ZOZOTOWNでは現在マイクロサービス化を進めており検索システムについてもその対象となっています。検索の文脈では、全文検索/サジェスト/ロギング等関連する様々な課題への解決策として有効であるElasticsearchを採用しマイクロサービス化を進めています。 また、もう1つの背景として検索のパーソナライズ化があります。これまでZOZOTOWNでは表示順として「人気順」という多方面から集計されたデータを基に算出されたスコアを使用していましたが、このスコアは商品に紐づくため全ユーザに対して一律な結果を返していました。一方でファッションは年代・性別だけでなく個人の趣味・時代によって大きく好みが異なる分野であり、個人にパーソナライズされた検索が必須となることは明らかでした。そこでRDBからElasticsearchのような検索に特化したシステムへ置き換えることによって検索のパーソナライズ化を実現することとしました。 先述した通りZOZOTOWNではElasticsearchをキーワード検索時の検索エンジンとしてRDBと併用していたため、Elasticsearchにデータを連携するシステムは存在していました。しかしRDBとの併用を廃止し、完全にElasticsearchのみで検索を行うにあたり既存のシステムでは以下のような難しい部分がありました。そこで今回インデキシングに特化した新規システムを構築しこれらの課題への対処を行うこととしました。 RDBからElasticsearchへ反映されるまでのリードタイム 既存のElasticsearchを用いた検索ではキーワードにマッチした商品IDのみを取得し、それをキーにRDBから最新の情報を引き当てていました。故に品切れや価格等のクリティカルな情報はRDB側で補完できたため、情報の更新は定期的なバッチで行っていました。一方でRDBの併用を廃止しElasticsearchのみでの検索を実現するにあたり、RDB内マスタテーブルの更新からElasticsearchへ変更を反映するまでのリードタイムに制約が設けられました。この制約を満たすためには既存のバッチの仕組み上対処が難しく、これに耐えうる新しい仕組みが必要でした。 多方面からのデータ登録 パーソナライズ化を進めていくにあたり、研究所の機械学習に基づくデータや分析チームのデータ分析に基づく商品特徴量など、データを追加する関係部署が複数考えられました。そのため任意の箇所から任意のデータを受け入れ、柔軟に検索可能になる状態を目指しました。今回構築した基盤はBigQueryをベースとしているため、データを抽出するクエリさえ用意できれば少ない手間でデータの反映が出来るような状態となっています。 システム概要 移行に際して新たに構築したシステムは以下のようなアーキテクチャです。 (1) CDCを取得 CDCとはChange Data Captureの略で、データベース内で行われた変更を追うことができる機能です。この機能はテーブル単位で設定可能で、レコードの追加・変更・削除やテーブルに対するカラム追加・削除の履歴が取得できます。 今回構築したシステムではこのCDCを以下の2つの用途で用いました。 テーブルへの変更差分を蓄積することによって、レプリケーションが行えないテーブル間でもスナップショットと差分の組み合わせから最新のテーブルを再現する insert/delete/updateのうちどの操作が行われたのかを判断し、Elasticsearchに対する適切な更新オペレーションを行う システム概要図のうち (1) の部分を更に詳細に示したのが以下の図になります。 SQL ServerからCDCを取得し、解読可能なメッセージの形への変換・配信するツールにはQlik Replicateを採用しました。 (2) 更新対象の取得、(3) データ返却 (1) で得られたCDCだけでは変更されたレコードの情報しかなく、用途にも書いた通り検索可能なデータにするためには別のテーブルと結合する必要があります。弊社では以前からDWHとしてBigQueryを使用しており、本システムに要求される大規模データを素早く処理するという要件に適していました。そのためBigQuery上でCDCを処理し、そこから得られた情報と、ある時点のスナップショットからなる元テーブルを結合し最新のテーブルを構築しています。 またBigQueryは構築されたテーブル同士の結合や配列への変換、データ整形も行っており、スケールしにくいバッチ側の負担を抑える役割も担っています。 (4) 更新 (2)、(3) の処理はストリームではなくバッチで行われており、データを取得した後はElasticsearchに対してリクエスト可能な形に変換し送信しています。このバッチはAppEngine上で動作しており、AppEngineでは cron.yaml を用いて定期的に処理を実行する事が可能です。今回のシステムでは変更差分を定期的に確認・処理する目的で使用するほか、定期的に行うデータ更新バッチのトリガーとして使用しています。 以上のシステムを用いることで、商品がマスタテーブルに登録されてから、もしくは売り切れ等でステータスが変わった場合でも平常時約10分以下のリードタイムでユーザに情報を届けることが可能となりました。 Elasticsearch故の苦労/Elasticsearch故にできること これまでRDBで補っていた部分をElasticsearchで全て完結しなくてはならなかったため、かなり苦戦した箇所もありました。またその逆で、RDBから解放されたことによって制約が外れ、自由にできることも増えました。今回はその中から特に印象的だった2つを紹介します。 JOINが難しい ZOZOTOWNではファッションECならではの機能として、「サイズ感が分かりづらい」という課題に対して、mm単位で指定可能なこだわりサイズ検索を提供しています。 これまで、この機能はRDB内でサイズに関するサマリテーブルを作成しJOINして検索することで実現していました。この機能を実現するためにはこれまでと同様にサイズのテーブルをJOINするか1アイテムに対して複数サイズの情報を持たせ、それぞれの情報に対して絞り込めることが必須条件でした。しかし、Elasticsearchではインデックス間のJOINの機能がないため、必然的に後者での実装を行う事となりました。 データ型として Join datatype といういかにもそれっぽいものが存在していますが、このデータ型には以下のような制約が存在しています。 同一shard上にparent/child documentが存在しなければいけない child documentがparent documentのIDを把握しなくてはいけない そこで、Join datatypeの代わりとして Nested datatype を用いることにし、1ドキュメント内にJOIN対象のデータを子要素として合わせて持たせることにしました。Nested datatypeではnested queryを用いることでそれぞれの子要素に対する検索をかけることができるため、SQLでいうJOINの動作が再現できます。 例 : 身長・体重を過去の履歴含めて検索する /* Mapping Definition */ PUT /health_index { "mappings": { "properties": { "id": { "type": "integer" }, "name": { "type": "text" }, "data": { "type": "nested", "properties": { "weight": { "type": "float" }, "height": { "type": "float" }, "created_at": { "type": "date" } } } } } } /* Create Data */ POST /health_index/_doc/ { "id": 1, "name": "Mike", "data": [ { "weight": 50, "height": 160, "created_at": "2020-01-01" }, { "weight": 55, "height": 160, "created_at": "2020-02-01" } ] } POST /health_index/_doc/ { "id": 2, "name": "John", "data": [ { "weight": 53, "height": 162, "created_at": "2020-01-01" }, { "weight": 55, "height": 165, "created_at": "2020-02-01" } ] } /* Search for matching document */ GET /health_index/_search { "query": { "nested": { "path": "data", "query": { "bool": { "filter": [ { "range": { "data.weight": { "gte": 50.0, "lte": 52.0 } } }, { "range": { "data.height": { "gte": 160 } } } ] } } } }, "_source": "name" } これらは以下のテーブル、SQLと同じような意味合いになります。 User userId name 1 Mike 2 John HealthData dataId userId weight height created_at 1 1 50 160 2020-01-01 2 2 53 162 2020-01-01 3 1 55 160 2020-02-02 4 2 55 165 2020-02-02 SELECT name FROM User INNER JOIN HealthData ON User .usedId = HealthData.userId WHERE HealthData.weight BETWEEN 50 AND 52 AND HealthData.height >= 160 GROUP BY name このように、JOINが必要となるデータに関してはあらかじめ1つのdocument内に併せ持つことによって、シャードの考慮等必要なくデータの再現が可能となりました。一方デメリットとして、Nested datatypeを使用した場合、親要素 + 子の要素分のドキュメントが生成されます。これによってKibana上のMonitoring > Indicesから見た際のDocument Countとインデックスに対して /_count で問い合わせた際の件数とで差異が生じます。 www.elastic.co 定義の追加なくA/Bテストが可能に RDBのみで検索を運用していた際のA/Bテストでは、事前にパターン分のカラム・データをテーブルに追加する作業が発生していました。 対してElasticsearchではRDBと異なり、明示的に定義されていないフィールドも受け入れ可能にするDynamic Mappingがデフォルトで有効化されています。更にこの設定はフィールドのトップレベルだけの設定だけでなく、子要素にも指定可能となっています。そのため、トップレベルではインデックスの構造を保護するためにDynamic Mappingをstrictに、A/Bテスト用の自由フィールドだけ子要素をdynamicにといった構造にすることも可能です。 /* テンプレート登録 */ PUT /_template/ab_index { "index_patterns": [ "ab_index_*" ], "mappings": { "properties": { "ab_params": { "dynamic": true, "properties": {} } }, "dynamic_templates": [ { "ab_params": { "path_match": "ab_params.*", "mapping": { "type": "float" } } } ], "dynamic": "strict" } } /* 許可されていないドキュメント */ POST /ab_index_1/_doc { "param1": 0.00 } => { "error": { "root_cause": [ { "type": "strict_dynamic_mapping_exception", "reason": "mapping set to strict, dynamic introduction of [param1] within [_doc] is not allowed" } ], "type": "strict_dynamic_mapping_exception", "reason": "mapping set to strict, dynamic introduction of [param1] within [_doc] is not allowed" }, "status": 400 } /* 許可されているドキュメント */ POST /ab_index_1/_doc { "ab_params.param1": 0.00 } => { "_index" : "ab_index_1", "_type" : "_doc", "_id" : "8t2RSnIBqlQNXy6Wvovk", "_version" : 1, "result" : "created", "_shards" : { "total" : 2, "successful" : 1, "failed" : 0 }, "_seq_no" : 1, "_primary_term" : 1 } /* 検索 */ GET /ab_index_1/_search?filter_path=hits.hits._source { "query": { "range": { "ab_params.param1": { "lte": 2.0 } } } } => { "hits" : { "hits" : [ { "_source" : { "ab_params.param1" : 0.0 } } ] } } この設定によってデータの構造が正常であることを担保しつつ、1インデックスで必要に応じてA/Bテスト用のパラメータが追加・検索可能な状態になりました。また、背景の箇所に書いた他部署による任意のデータを受け入れ可能な状態もこれによって実現されています。実際に現在ZOZOTOWNの検索の一部でこの機能が使われており、データ分析を行うような専門のチームによって作成されたスコアを用いた評価が行われています。 まとめ 本記事では、ZOZOTOWNすべての検索をElasticsearch移行した事例と、その最中に行った印象的な設定について紹介しました。新規の検索基盤に移り変わったばかりですが、様々なA/Bテスト案や改善案が立ち上がっており移行の恩恵を早々と受けています。 最後に、ZOZOテクノロジーズでは検索をさらに改善する検索エンジニアを募集しています。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

はじめに こんにちは、ZOZO研究所福岡の下所です。 検索チームでWEARの検索ログの解析を行なっているのですが、その中でファッション業界に限らず、多くの言語学者・データ解析者がインターネット上での文字解析、特に新語の理解に苦労していることを知りました。特に日本語のように表現が曖昧で流動的な言語を理解することに多くの労力を要しているように感じました。 例えば読者の皆さんは、「かわぱんつ」というキーワードを見て何を想起されますか？私は「革のパンツ」を思い描きました。しかし、昨今のファッション用語ではこれは「かわいいパンツ」としても通用するのです…！ この例のような困難なカテゴリ分類の問題が存在した時に、WEARのファッション用語に的を絞ることで、質の高い組織化を行えるよう研究を行いました。まだまだ課題は多いですが、近い将来、業界の大規模データの活用が簡素かつ高精度の状態で利用できるよう、この度の私の気づきを紹介します。 データ特徴 今回利用したデータの特徴は以下の通りです。 人気ブランド、アイテムの着こなしが探せるファッションコーディネートアプリで取得したデータ 検索ログはクリーニングが行われていない生データ ロードマップ 上記で紹介したデータを、以下の流れで考察していきました。 データフォーマットの理解とデータ抽出の自動化 現状把握と課題の確認 可能性の模索と問題点の確認 1. データフォーマットの理解とデータ抽出の自動化 データ抽出の自動化を行うために、データのパターンについて調査し、そのフォーマットの理解をします。 2. 現状把握と課題の確認 データはファッション業界におけるSNSにて最大級の規模を持つWEARの情報を用いました。自由検索とクリック検索の記録が混在するデータ形式で、データパターンとしてはクエリと情報contextの一致しないものが多い印象でした。加えて検索された単語の多くは、文法制限（表記パターン・表現）を受けず、さらに日本語の形態素解析を受け入れにくいものでした。 さらにインターネット、ファッション業界特有の造語・新語・略語も多数みられた印象です。誤字・新語・それとも短縮後なのか辞書を用いても判断がつかないものが多かったです。そのため、上記にもありますが、不鮮明な分類の影響から商品名やカテゴリ分類の由来や適応範囲を定義づけることは難しい印象です。 その結果、検索インデックスや常用語の言語コーパスを用いる既存の方法では、変化に富むファッション用語を正確に認識することに限界がありました。さらに商品説明から制作したファッション用語に特化したコーパスは、商品説明に特有の単語の用途の類似点から個々の差別化が困難だと分かりました。 残念ながら、ユーザーが一度の検索で使用する語彙数は少なく、文章の構造的な類似点を見つける手法も不向きでした。 3. 可能性の模索と問題点の確認 データ抽出の自動化を行う際に最も重要となるのが、入力単語の認識です。そのためには、正確な意味を把握することが必要になります。 実際、アパレル商品を定義する際に大きな問題となるのは、定義・分類できない言葉、由来や適応範囲が曖昧な用語の存在の多さです。デニム、ジーンズ、Gパンなどのように、表現は多種にわたり、時流の影響を受けます。 また、カーディガンとコートを組み合わせたコーディガンのような造語（out of vocaburary）も生まれやすい業界です。ガウチョ、スカーチョ、スカンツなど、キリがありません。 単語の部分一致によってカテゴリーを特定しようと試みると「スタイvs.スタイル」や「コートvs.ペチコート」のような問題も起こります。 結果として、字句解析やファジー解析では汲み取れない言葉の変化に対応する必要性を痛感しました。 他にも、短縮語の存在は形態素解析に大きな影響を与えました。 例えば「かわぱんつ」。形態素解析を用いると「かわ」と「ぱんつ」に分割され、それぞれの意味は解析によって「皮（革）」と「パンツ」という判定を受けてしまいます。正解の可能性に「可愛いパンツ」もあるらしいですが、現状では汲み取ることができません。 他にも「ワンピース」は衣類、アニメに加え、oneとpieceが可能性として出現します。 ではスペースはどうでしょうか？分けて考えるべきでしょうか？例えば「SHOO LA RUE」や「BEAUTY&YOUTH UNITED ARROWS」そして「アーバン リサーチ ドアーズ」の場合はどうでしょうか？ スペースだから、アルファベットだからと言って単語の分かちとは限りません。結局、ユーザーの検索モチベーションを判断し、単語を確定する上でログの情報量は圧倒的に不足していると感じました。 解析結果 ある程度の精度でデータ抽出、タグの再分配が完了したところで抽出単語の意味に執着せず文字構造の一致から条件付統計を取りました。その結果、データから年代別・性別・ブランド別・カテゴリー別・色別などの季節変動を読み取ることができました（Fig.1参照）。Fig.1は、2017年WEARで検索された季節性の見られるカテゴリクエリの出現頻度を表しています。振幅の大きいものほど季節変動が大きくなります。つまり平坦なグラフを持つカテゴリほど通年を通して検索されていることになります。 他にも、1年を通してよく検索される商品やブランドもあれば、繁忙期・閑散期を持つ商品（色・性別・身長・カテゴリー・イベント）を区別できます（Fig.2参照）。Fig.2は、Fig.1と同様2017年のトレンドを表しています。振幅の大きいものほど季節変動が大きい（閑散期・繁忙期）ブランドとなります。 さらに条件を加えながら多くの相関関係を可視化できます。これらの情報はデータに潜む関連性を定数化し、結果を考察する際に大変有効なものです。 次にお伝えするのは私の経験（単純な条件付の時系列解析）からの考察です。WEARのユーザーはショップ名・ブランド名に固有表現を、商品は「かわぱんつ」のようにdescriptive（ニュアンス）を含んだアイテムを検索する傾向があるようです。 このような多種にわたる表現が混在するデータを解析するにあたり、データ再構築（分類ごとにまとめ直す）作業が重要になります。一般的に大規模なカテゴリー分類のほとんどは階層的分類で、カテゴリー分類はルールベースの手法を取られます。そして昨今、機械学習モデルを使用することでその精度を上げる手法も提案されています。 今回は情報の量と質（意味・定義）を同時に保存、表記揺れ・誤字・新語・造語・短縮語の判定するためのhierarchy classifcationに特化したネットワーク構造を用意しました。ここで言うネットワークは、単語の意味から上位語・下位語を纏めたグラフ上の情報構造体のことを指します。 そのために、単語の「音・構造・意味（類義語）・上（下）位語・連想語・用途」に着目し完全自動化されたファッション用語の分類器のプロトタイプを設計しました。 その結果、商品名やカテゴリ分類の由来や適応範囲を定めるパラメータに対してhypothesisを提案できるようになました。今では多数存在するコート商品（アウター）を、定義に基づいてある程度のまとまりに分類できました。 しかもこの際には、ペチコートはアウターではないと区別されています。なお、今回の研究では、日本語や中国語を英語より優先的に考察しています。 その原因は言語特徴が似ていることに加え、ステミングやレンマの必要性が低い辞書表記となるため、形態素解析の精度に問題解決の焦点がある程度定められるためでした。 今後、素材や生地の情報を組み込むことで、さらに情報補填ができると考えています。 まとめ　 WEARがファッション業界の中でも有数のユーザーが抱えるSNS媒体であることもあり、そのログデータは有用なものだと判断できます。しかしミクロ解析の精度を上げ、さらにデータの価値を高めるには、まだまだ数多くの課題があることも事実です。 人・社会が変化する中で、言葉・常識も変化します。その結果、情報のあり方も影響を受けます。 ファッションを数値化するために、ファッション用語を理解することは避けて通れません。複雑に絡み合う情報をデータなどから紐解き、分かることを増やしていく地道な作業の重要性を感じました。 さいごに ZOZOテクノロジーズでは検索チーム、検索基盤チームのメンバーを募集しております。 hrmos.co

こんにちは！　ZOZOテクノロジーズの中坊（ e_tyubo ）です。 概要 私が所属しているマーケティングオートメーション（以下MA）を担当するチームでは、ユーザ毎にパーソナライズされた情報をメールやアプリのPush通知で配信しています。その際に利用するZOZOTOWNやWEARのデータは我々が管理する専用のデータベースに集約されています。このデータベースには日々のユーザの行動ログが記録されるため、必然的にデータ量は大きいものになります。このような巨大なデータを管理することに特化したデータベースはデータウェアハウス（以下DWH）と呼ばれていて、実績の可視化やマーケティングに活用するための分析等の用途に使われます。 MAチームでは配信内容をユーザ単位で最適化するためにDWHを利用していて、最近まではIBM PureData System for Analytics（以下PureData）を利用していました。しかし、PureDataの保守が終了してしまうため別のデータベースに移行する必要がありました。我々は互換性を考慮し、後継機であるIBM Integrated Analytics System（以下IIAS）へ移行することにしました。 PureDataとIIASはどちらもIBM製品であるため高い互換性がありますが、一部の機能については挙動の違いもあり個別に対応が必要となりました。本記事では新しく導入したIIASの特徴と、移行の際にぶつかった問題とその解決方法について紹介します。 IIASの特徴 最初に、IIASがどのようなデータベースなのかを紹介します。 IIASはデータベースそのものを指すのではなく、サーバ筐体や周辺ツールを含めたパッケージ製品の名称です。 公式ドキュメント に書かれている通り、Db2 Warehouseという製品を中核とし、様々な周辺ツールが提供されています。IIASはクラウドサービスではなく、計算機本体を購入し管理する必要がある、いわゆるオンプレミスなデータベースです。よく利用されるBigQueryの様なフルマネージドなDWHとは異なり、サーバ本体を自社で保有する必要があります。 Db2 Warehouse 以前まで利用していたPureDataはPostgreSQLベースでしたが、IIASは先程も述べた通り、Db2 Warehouseという製品を利用しています。Db2はIBMが開発したデータベースで、1983年にリリースされた歴史の長いRDBMSです。元々はWebアプリケーション等の裏側でリアルタイムな処理を主として利用されていたデータベースですが、改良が重ねられ、DWHとしての機能も果たすようになっていきました。 Db2 Warehouseもまた、データベースだけを指す言葉ではなく、データベースエンジンと周辺機能をDocker上で動作させるために必要な機能を提供する製品の名称です。 公式ドキュメント の図にも書かれている通り、GUIでデータベースの操作ができるWebコンソールやログインユーザの管理用のLDAPが標準で搭載されており、セットアップ後は様々な機能が利用可能になります。特徴的な点としてDb2 Warehouseの機能はDocker Imageで提供されている点が挙げられます。無料版も存在していて、Docker Hub 1 か、IBM Cloud Container Registryから入手が可能です。開発用の環境を自前で構築する際には利用が可能ですので、導入前の検討材料や本番で実施しにくいテストの実行環境として活用ができます。 複数のノードで分散処理 IIASには物理サーバが複数台含まれており、それぞれのサーバを使って1つのデータベースを動かします。RDBMSではしばしばシャーディングと呼ばれる方法でデータを分割をして負荷分散させることがありますが、Db2 Warehouseは標準でそのような仕組みを備えています。 また、Db2 Warehouseでは物理的なサーバ単位だけでなく、サーバの中に論理ノードという単位でデータを分けて保持できます。これはあるサーバの中でさらに論理的にデータを分割し、保持する仕組みです。Db2 Warehouseではノード毎に保持しているデータを、ノード毎に処理することで効率的にSQLを実行する仕組みを備えています。この場合CPU、メモリ、ストレージは同一サーバ上のものを共有することになります。しかし、利用可能なCPUのコア数が論理ノード数に対して十分な数がある場合はノード単位で同時に処理をすることで処理効率の改善が期待できます。 下記のようなSELECTステートメントを例に考えてみましょう。 SELECT * FROM SampleTable SampleTableというテーブルから全てのカラムをSELECTする単純なクエリです。1つのテーブルですが、Db2 Warehouseの仕組み上データは複数サーバに分散されているため、取得経路は下図のようになります。 この図は物理サーバが2台あり、その中でさらに論理ノードに分かれているケースを表しています。図のように全ての論理ノードからデータを集めて、全て取得し終わったら要求した全てのデータを返します。このようにDb2 Warehouseはそれぞれのノードで処理を並列実行することでクエリのパフォーマンスを効率化しています。 分散キー 先ほどデータが各ノードに分散配置されると書きましたが、分散させるには分ける基準となる情報が必要です。そのため、Db2 Warehouseには分散キーという属性をカラムに指定できます。 分散の方式にはハッシュ分散とランダム分散の2種類があり、分散キーの作成時にどちらを利用するか指定できます。ランダム分散は適切なキーが存在しない場合にDb2 Warehouseが自動で分散キーを決定する方式ですが、利用するケースがなかったため説明は割愛します。 ハッシュ分散は、カラムの値を用いて分散させる方式です。例えば会員情報を管理するためのMemberというテーブルがあった場合、分散キーは下記のように指定できます。memberIdはユニークな値のみ保持することとします。 CREATE TABLE Member ( memberId INTEGER , name VARCHAR ( 50 ) ) DISTRIBUTE BY HASH(memberId) ORGANIZE BY COLUMN ハッシュ分散は、指定したキーの値と格納先ノードを対応させるマップを作成し、それに沿ってデータを配置します。下記の画像はノードが4つ存在する場合に作成されるマップのイメージ図です。 値の重複がある場合、データは同じノードに格納されるため、均一化のためにはカーディナリティ（値のばらつき具合）が高い列を選択する必要があります。今回のケースではmemberIdがユニークであるため、均一にデータが配置されます。 次に分散キーの効果的な利用方法について説明します。並列処理を効率的に実行するためには各ノードで検索条件にマッチするデータ量を均一化することが必要です。もし特定ノードにデータが偏っていた場合、そのノードで実行されるデータ取得処理が終わるまで全体の処理を終えることができません。 JOINを例に考えてみます。例えば、下記のような会員のお気に入り商品の情報を管理するFavoriteProductテーブルがあるとします。 CREATE TABLE FavoriteProduct ( memberId INTEGER , productId INTEGER ) DISTRIBUTE BY HASH(memberId, productId) ORGANIZE BY COLUMN 下記のクエリでお気に入り情報に紐づく会員情報を取得するケースを考えましょう。 SELECT productId ,name FROM FavoriteProduct INNER JOIN Member ON Member.memberId = FavoriteProduct.memberId この場合FavoriteProductが保持しているmemberIdを使ってMemberテーブルを検索するため、分散キーを利用することになります。MemberテーブルのmemberIdはユニークなキーであり、均一に分散されているため十分効率的にSELECTを実行できると考えられます。 このように、検索条件に対していかにデータを均等に分散させるかがパフォーマンスを考慮する上で重要になります。 つまり分散キーを選択する際には、下記の条件を満たしているケースが望ましいです。 カーディナリティが高い列を指定する 検索条件に指定される列を指定する 必ずしもこの条件を満たす必要は無いですが、分散キーを選択する際の基準として考慮しています。 列指向と行指向 Db2の特徴として列指向と行指向を両方サポートしているという点が挙げられます。行指向はレコード単位でデータを保持し、列指向はカラム毎にデータを保持する方式の事を言います。 MySQLやPostgreSQL、SQL Server等のRDBMSはテーブルの中から特定のレコードを取得する事に重きを置いているため、行毎にデータを保持しておくことが効果的です。しかし、Db2 WarehouseのようなDWHは大量のデータを保持する事を想定しており、列単位にデータを保持することで大量データの中から特定の列のみを使った処理を効率的に実行できます。 Db2 Warehouseは列単位でデータを保持することにより、特に下記の利点があるようです。 不要列を読み込む必要がないため、メモリを効率的に利用できる 列の中に同じデータが含まれているケースが多いため、データ圧縮率が高い IIASで利用する際にはデフォルトで列指向なテーブルが作成されますが、明示的に行指向テーブルを作成することも可能です。 CREATE TABLE Member ( memberId INTEGER , name VARCHAR ( 50 ) ) DISTRIBUTE BY HASH(memberId) ORGANIZE BY ROW 上記のように ORGANIZE BY ROW を指定すると行指向テーブルが作成されます。DWHの用途を考えると列指向なテーブルを使うことの方が多いと思いますが、必要に応じて使い分けることができます。 データスキッピング 一般的なRDBMSでは検索を効率的に実施するためにindexを利用しますが、列指向で保持しているデータについては同じ方式では有効に検索できません。そこでindexではなくデータスキッピングという仕組みを用いてカラムの中のデータ検索を効率化しています。 データスキッピングとは、一定のデータ件数毎に各列が持つデータの最大値と最小値をメタデータとして保持し、レコードが存在する範囲を絞り込みやすくする機能です。 例えばMemberテーブルに登録時刻を保持するregistDtというカラムがある場合を考えます。 CREATE TABLE Member ( memberId INTEGER , name VARCHAR ( 50 ), registDt DATETIME ) DISTRIBUTE BY HASH(memberId) ORGANIZE BY COLUMN 下記のWHERE句を用いて2020年4月に登録した会員をSELECTします。 WHERE registDt >= ' 2020-04-01 00:00:00 ' AND registDt < ' 2020-05-01 00:00:00 ' この時データスキッピングの機能により、対象レコードを効果的に絞り込むことが可能です。 上図のように、メタデータを使って2020年4月1日より古いデータと2020年5月1日より新しいデータが存在する範囲を不要だと判断できるため、処理が効率化されます。 Webコンソール IIASをセットアップすると、Db2 Warehouse専用のWebコンソールが利用可能になります。様々な機能が利用可能ですが、特に頻繁に利用する機能は下記の通りです。 クエリの実行 テーブルやViewの定義の確認 実行中クエリの確認（実行計画も参照可能） ユーザの管理 ディスク、CPU、メモリの利用状況の確認 Mac用に標準ツールが提供されていないこともあり、Webコンソールからクエリを実行することが多いです。 PureDataからIIASに移行する際の注意点 次はPureDataからIIASへ移行する際に課題となったポイントをまとめます。 冒頭でも述べた通り、PureDataとDb2 Warehouseは高い互換性がありますが、一部挙動に相違が見られます。ここでは移行に当たって書き換えや、対応が必要となった機能の一部を紹介します。 FROM句は必須 PureDataで現在時刻を取得する時は、FROM句を指定せず下記のクエリで実現可能です。 SELECT CURRENT_DATE しかし、Db2 Warehouseでは明示的に指定が必須です。 SELECT CURRENT_DATE FROM SYSIBM.SYSDUMMY1 そのため単純に値の中身を確認するような場合には、上記のように、SYSIBMスキーマに用意されたダミーテーブルを利用します。 もしくは、 VALUES を使うことでも同様の結果が得られます。 VALUES ( CURRENT_DATE ) LENGTHとCHARACTER_LENGTH PureDataでは文字列に対してLENGTH関数を使うと文字数が返ってきましたが、Db2 Warehouseでは挙動が異なります。Db2 Warehouse内で扱う文字列の文字コードがUTF-8となっている前提で考えます。 SELECT LENGTH ( ' Hello ' ) FROM SYSIBM.SYSDUMMY1 SELECT LENGTH ( ' こんにちは ' ) FROM SYSIBM.SYSDUMMY1 どちらも文字数で見ると5ですが、結果は下記の通りです。 5 15 これはDb2 WarehouseがLENGTHによって文字数ではなく、文字列の合計バイト数を返していることが原因です。UTF-8の文字列ではアルファベットは1バイト、ひらがなは3バイトで表現されます。 単純な文字数をカウントしたい時は、CHARACTER_LENGTHを使って書くことで期待した結果を得ることができます。 SELECT CHARACTER_LENGTH( ' Hello ' ) FROM SYSIBM.SYSDUMMY1 SELECT CHARACTER_LENGTH( ' こんにちは ' ) FROM SYSIBM.SYSDUMMY1 ウィンドウ関数の中でrandomが使えない 我々のチームで管理しているクエリの中にはウィンドウ関数を利用しているものが多数ありますが、Db2 Warehouseにはその中でrandom関数を利用できないという制約があります。例えば、Memberテーブルが住んでいる都道府県のidを保持しているとしましょう。 CREATE TABLE Member ( memberId INTEGER , prefectureId INTEGER , name VARCHAR ( 50 ) ) DISTRIBUTE BY HASH(memberId) ORGANIZE BY COLUMN この時、下記のように都道府県ごとにランダムな値を割り振るクエリは利用できません。 SELECT memberId ,RANDOM() OVER(PARTITION BY prefectureId) FROM Member random関数を利用する場合はウィンドウ関数の中での利用を回避する必要があります。 下記のようにサブクエリで割り振ったランダムな値を基準にROW_NUMBERを振り直すことで、無作為に選ばれた連番をSELECTすることが可能です。 SELECT memberId ,ROW_NUMBER() OVER(PARTITION BY prefectureId ORDER BY randomNum) AS randomRowNum FROM ( SELECT memberId ,prefectureId ,RANDOM() AS randomNum FROM Member ) AS A NULLの順序が異なる NULLを含むカラムを並び替える際に、NULLが先頭に来るか末尾に来るかはデータベースによって異なります。PureDataとIIASの並び順は表の通りです。 DB ASC時のNULLの順序 DESC時のNULLの順序 PureData 先頭 末尾 IIAS 末尾 先頭 例えば何かしらの値でスコアリングして、大きい順に並べた結果を先頭から特定件数を抽出するようなクエリでNULLがヒットするようになってしまう可能性があります。 ORDER BY ASC のケースで対応が必要な箇所はありませんでしたが、上記のようなケースが存在する場合は ORDER BY DESC を利用している箇所で修正が必要です。 この件の対処法をサポートに問い合わせたところ、システム全体でNULLの並び順を指定する設定はないとのことでした。そのため、 ORDER BY DESC を使っている箇所で NULLS LAST を指定することで対処しました。 ORDER BY DESC NULLS LAST 上記のように指定することで対処が可能です。対応としてはクエリ自体をNULLを利用しない方式に組み替えることも考えられますが、影響範囲と改修コストの兼ね合いで一括置換できる方式を選択しました。 SORTHEAP DWHは巨大なデータを扱うため、メモリの利用量も多くなります。特にSORTHEAPと呼ばれるメモリは、Db2 Warehouseがクエリを実行する際にJOINやソートの時に一時的にデータを格納するために使われており、パフォーマンスに大きく関わります。PostgreSQLで言う所のwork_memのようなものです。 この値を超えるデータ量を扱うと、メモリに収まらないためディスク書き込みによるパフォーマンス低下を招く可能性があります。また、オプティマイザがメモリ消費の少ない実行計画を選択することで実行時間が長くなる可能性もあります。処理に十分なメモリが割り当てられていないとパフォーマンスが顕著に低下することがあるためSORTHEAPの設定値は調整を検討する価値があります。 ただし、SORTHEAPの値はあくまで1つのステートメント単位で利用できるメモリ量であり、同時接続数が増えれば増えるほど全体として利用するメモリの量は増えてしまいます。そのためDb2 Warehouseではシステム全体でSORTHEAPとして利用できるメモリの総量をSHEAPTHRES_SHRによって規定しています。全ての実行中クエリがSORTHEAPを最大まで利用している場合、理論的に同時接続できる最大数はSHEAPTHRES_SHR/SORTHEAPによって決まります。SHEAPTHRES_SHRを超えてメモリを利用することはできないため、SORTHEAPに割り当てるメモリの量には注意が必要です。 まとめ 本記事ではIIASの特徴とPureDataからIIASへ移行する際に考慮すべきポイントをまとめました。 MAチームではMA基盤上のアプリケーションの開発・運用だけでなく、データ連携の仕組みの開発・運用も行なっており、ビッグデータを活用したデータ基盤の改善に取り組んでいます。目立たない分野ですが非常にサービスへの影響は大きく、挑戦のしがいがあるチームです。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 tech.zozo.com Docker Hubで提供されるDocker Imageについては2020年3月31日以降はメンテナンスが終了しており、非推奨となりました。 ↩

はじめに こんにちは。SRE部USED基幹インフラの先崎です。 ZOZOUSEDは2016年、当時の株式会社ZOZOUSED システム部のインフラチームにて、基幹のデータベース（以下DB）をMySQLからMicrosoft SQL Server（以下MS SQL）に移行しました。 移行してから今日まで、データロストなどの大きなトラブルは起きておりません。そのため、当時の変更理由から選定時に検討した内容、その際に発生した課題の解決方法を簡単に紹介させていただきます。MySQLからMS SQLへ移行を検討しているどなたかのお役に立てられたら幸いです。 MySQLからの移行検討 当時、自動切替（フェイルオーバー）を実現しようとすると費用が大きくかかってしまうため、手動切替（スイッチオーバー）の形をとっていたことが最大の要因でした。 MySQLの正常時イメージ図 MySQLの障害時イメージ図 まず、当時のMySQLの構成と、前述以外の問題点についてご紹介します。 移行前の構成 構成 ライセンス費用がかからないもので構成していました。 CentOS 2台 MariaDB（Galera Cluster冗長化） 問題・課題点 スペック起因の可能性もありますが、当時課題として感じていた点は以下の通りです。 リスナーなどはなかったため、DBの切替時はDNSレコード変更かプログラムで見ているDBのIPやホスト名を手動変更しないといけなかった バックアップ・リストアに非常に時間がかかっていた レプリケーション（同期）の遅延があり、時々整合性が取れていないことがあった 良い点 反対に、MySQLを運用していてメリットに感じた点もご紹介します。 安価 セカンダリDBもReadDBとして使用可能 phpMyAdminでスロークエリ、ログ取得など監視可能 テーブル単位のバックアップ・リストアが可能 移行後の必須要件 上記の状況を踏まえて、移行後の必須要件を以下の2点に設定しました。 2台以上での冗長化かつ障害時の自動切替が可能であること 監査的の観点から、個人情報の入ったデータへのアクセスを監視できること この観点で製品選定を実施しましたので、その際の比較した内容をご紹介します。 比較選定のための調査 オンプレ、AWS、Azure、GCPの各サービスを比較検討することにしました。 オンプレミスサーバー「MS SQLのAlways On構成」 構成 必要条件を満たす構成を検討しました。Enterpriseエディションは予算的に選択できませんでした。 Windows Sever 2016 Standard + MS SQL Server 2016 Standard Always On 可用性グループでの冗長化 問題・課題点 上記構成にてMySQLと比較した場合に生じた課題点は以下の通りです。 StandardエディションでのAlways Onのため、冗長化のセカンダリDBがReadもできず、分析・開発に使えない テーブル単位でのバックアップやリストアができない スロークエリなどの監視をどうするか検討が必要 クライアント数が多くてCALライセンスでは非常に高額になってしまうため、CPUコアライセンスを選択せざるを得ず、さらにCPUコア数でも金額が変わるため、CPUコアを少ないもので抑える対策が必要 オンプレのため、老朽化対策のため数年後にはリプレイスが必要 監査のクエリ取得の検討が必要 良い点 検証時にMS SQLの良いと感じた点は以下の通りです。 冗長化がMS SQL任せでよく、レプリケーションの遅延もほぼ気にならない Always Onのリスナーがあるので、切り替えダウンタイムがほぼない Microsoft SQL Server Management StudioでGUI操作が容易 AWS「Aurora or RDS（MariaDB）」 既存MySQLを踏襲し、MariaDBで検討しました。 問題・課題点 以下のような、クラウド環境特有の課題がネックとなりました。 社内ネットワークとAWSネットワークの連携は複雑になりがちだが、Direct Connectなどを使うと高額 個人情報をクラウドに預けるというセキュリティ面の懸念（2016年当時） 監査のクエリ取得の検討が必要 AWS経験者不足（2016年当時） 良い点 AWS検討時に良いと感じた点をご紹介します。 高可用性、基本的にはブラウザからのGUIベースで設定が可能 MySQLからMariaDBへの移行を想定のため、データ変換はそこまで大変ではない オートスケールやインスタンスタイプの変更など柔軟に可能 MS Azure「Azure SQL Database」 早々に費用面がネックになり、調査はあまり行いませんでしたが、簡単に課題点、良い点をご紹介します 問題・課題点 当時のマネジメントパネルが非常に使いづらく、わかりにくかった DTUなども検討したが、想定よりも高額だった 良い点 高可用性、基本的にブラウザからのGUIベースで設定が可能 GCP「Google Cloud SQL」 当時、情報が少なく、カスタマイズもあまりできない状況だったので早々に断念しました。 以上の検討内容を元に、選定の際に重要視していた点をまとめたのが以下の表です。 検討結果とMS SQLの選定理由 可用性 フェイルオーバー コスト バックアップ 監査対応 オンプレ 〇 実装容易 〇 〇 〇 AWS ◎ 実装可能 △ ◎ × Azure ◎ 実装可能 × ◎ 不明 GCP 〇 不明 不明 不明 不明 以上の調査結果を踏まえて、MS SQLを選定することにしました。理由について以下で説明します。 MS SQLの選定理由 細かい理由は他にもありますが、下記6点が大きな選定理由となりました。 AWSとイニシャル・ランニングコストで比較計算したが、オンプレのMS SQL構成は数年以内にペイできてしまう結果となった 当時のZOZOUSED内では、AWSやAzureの導入実績がなかったため、コアシステムの構築・運用が不安視された Always Onによる冗長化が簡単で高性能であり、リリースまでが短期間で済む想定だった Webサーバーはオンプレに置いておく想定だったため、DBをクラウドにしてしまうと流れるデータのセキュリティや欠損率を考慮しなないといけなくなる クラウドでのクエリ監査対応が、当時の環境では実現が難しかった 構築当時「ZOZOUSEDのお客様の重要な個人情報」をクラウドに置くことに対して社内での懸念があった Always On正常時のイメージ プライマリ障害時のイメージ（自動切換え） 以上のことから、MS SQLを導入しました。その結果フェイルオーバーなど、MySQL運用時に抱えていた課題を解決できました。ただし、導入～運用フェーズにおいていくつか別の課題に直面したので、それらをどう解決したかご紹介します。 MS SQLで生じた課題と解決方法 1. 冗長化のためのセカンダリDBがReadもできず、分析・開発に使えない 分析チームからは「AM5:00に同期される前日のデータを使った解析をしなければならない」という要件がありましたが、本番DBは個人情報があること、また分析の高負荷を容認できないことから直接の本番DBへのアクセスは不可としていました。 さらに、StandardエディションでのAlways Onのため、冗長化のセカンダリDBがReadもできません。 しかしながら、移行のおかげでバックアップおよびリストアにかかる時間がMySQLに比べて飛躍的に短くなりました。そのため、同期完了後にバックアップし、そのバックアップデータを別サーバーにリストアするスクリプトを作成することで、前日のデータが入った開発用DBを始業開始までに用意することが可能になりました。これにより、上記の要件を解決することができました。700GB程度のDBがバックアップ開始からリストア完了まで3時間程度で完了できています。 2. テーブル単位でのバックアップやリストアができない 業務上、稀にバックアップから復元したいデータが出てきてしまうということがありました。MySQLであれば、バックアップからテーブル単位などでリストアできました。MS SQLではそれができないのですが、MS SQLへ切り替えた結果、フルバックアップのリストアが1時間程度で済むようになったため、フルリストアしたものからテーブル単位などでデータを移動することが可能なため、この制約は問題にはなりませんでした。 3. 個人情報の入ったデータへのアクセスを監視しなければならない 今まで通り、監査要件として個人情報の入ったテーブルへのアクセス履歴を追えるようにする必要があったため、MS SQLの監査機能を利用し、ファイルにクエリを吐き出し、そのファイルをDBサーバーにインサートすることでこの要件を満たすことができました。実際に設定した監査の例をご紹介します。 MS SQL監査設定の例 まず、SQL Server Auditを使用してサーバーの監査オブジェクトを作成します。 こちらでは、吐き出すログファイルの保存先や容量、クエリ遅延秒数などを設定しています。 USE [master] CREATE SERVER AUDIT [インスタンスの監査名称] TO FILE ( FILEPATH = N'ファイルを吐き出すパス' ,MAXSIZE = 200 MB ,MAX_ROLLOVER_FILES = 2147483647 ,RESERVE_DISK_SPACE = OFF ) WITH ( QUEUE_DELAY = 1000 ,ON_FAILURE = CONTINUE ,AUDIT_GUID = '＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊' ) ALTER SERVER AUDIT [サーバーの監査名称] WITH (STATE = ON) GO 続いて、データベース監査の仕様を作成します。 監査要件から、すべてのテーブルに対する「DELETE、INSERT、UPDATE」と特定のテーブルに対しての「SELECT」を取得するように設定しています。 USE [データベース名] CREATE DATABASE AUDIT SPECIFICATION [作成するDB監査の名称] FOR SERVER AUDIT [サーバーの監査名称] ADD (DELETE ON DATABASE::[データベース名] BY [dbo]), ADD (INSERT ON DATABASE::[データベース名] BY [dbo]), ADD (UPDATE ON DATABASE::[データベース名] BY [dbo]), ADD (SELECT ON OBJECT::[dbo].[テーブル名] BY [dbo]), ADD (SELECT ON OBJECT::[dbo].[テーブル名] BY [ユーザー名]) WITH (STATE = ON) GO 4. スロークエリなどの監視をどうするか検討が必要だった SolarWinds社のDPA（Database Performance Analyzer）を導入することで解決しました。2016年当時、国内実績はあまりなかったようですが、試用してみて有用だと判断し導入しました。トラブルシューティング時の調査、インデックス不足、日次業務の変化把握などに役立っています。 Database Performance Analyzerの画面 トップ画面 何が要因で時間がかかっているのかわかる 日毎のクエリ実行時間が可視化 時間毎のクエリ実行時間が可視化 5. Always Onのリスナー（ADへのコンピュータアカウント）が自動で作成されない Webに公開されている構築手順やブログを頼りに構築検証していましたが、なぜか手順通りにいきませんでした。Always Onの設定時、AD上にリスナー用のコンピュータアカウントを事前に作成し、アカウントのセキュリティに対して使用するクラスターアカウントのフルコントロールのアクセス権を付与しなければならないということがありました。 6. フェイルオーバー後にユーザーがログインできなくなる 包含データベースの有効化はしていましたが、ユーザーが包含ユーザーになっていませんでした。 そのため、サーバーユーザーとデータベースユーザーの紐づけが切れてしまっていました。 包含データベース設定 + 包含ユーザーを作成することで、フェイルオーバーしても包含ユーザーでアクセスできるようになりました。 包含データベースの有効化 包含データベースに設定 7. 包含ユーザーだとbulkのコマンドが使えない サーバーにユーザーを作成し、bulkadminのロールに属する必要がありました。 8. 上記bulkユーザーがフェイルオーバー後にログインできなくなる 包含ユーザーではないため、フェイルオーバー時にサーバーユーザーと包含ユーザーの紐づけが切れてしまうことが発覚しました。フェイルオーバー後に手動で以下のコマンドを実行し、サーバーユーザーと包含ユーザーの紐づけを修正することで解決しています。 USE [データベース名]; ALTER USER [包含ユーザー名] WITH LOGIN = [サーバーユーザー名]; 9. トランザクションログが肥大化する データベースの復旧モデルは完全復旧モデルを選択しました。完全復旧モデルの場合は、トランザクションログはログファイルにどんどん蓄積されてしまい、何も対応しないとディスクが枯渇し、書き込み操作が一切できなくなってしまう恐れがあります。1日1回の完全バックアップに加えて、メンテナンスプランで15分ごとにトランザクションログをバックアップすることでこまめにログの切り捨てを行うことでこの懸念点を解消しました。 10. ファイアウォールによりAlways Onの同期が停止する Windowsファイアウォールでアクセスを絞る案件がありました。その際、レプリケーションに使われているポート（デフォルトは5022）に気づかず同期を止めてしまいました。Windowsファイアウォールにそのポートを開けて復旧しました。 これは、バックアップデータが非常に増えたことから発覚しました。データベースのログファイルが肥大化しており、トランザクションログが退避されなくなったことによるものと推測しています。 さいごに SRE部USED基幹インフラでは、導入後からOS、DB、NWでチューニングを続けています。今期、Webサーバーをクラウドに移行する予定もありチューニングや見直しを引き続き実施し、さらなる高速化・安定化を目指しています。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

こんにちは、WEAR部運用改善チームの三谷です。 僕たちのチームのミッションは、WEARの運用においてエンジニアが行なっている作業内容を見直し、本来注力すべきサービス開発に取り組める時間を増やせるよう、運用を改善することです。時にはシステムを開発して自動化をしたり、時にはその業務自体が本当に必要なのかを考えて業務フローを整えたりしています。 そんな僕たちが、昨今の新型コロナウィルスの流行によってリモートワークがメインとなった状態で、メンバー間でペアプロをしたいと思った時に採用した方法がとても良かったので紹介したいと思います。 はじめに 新型コロナウィルスの世界的な流行を受け、弊社では2月半ばからリモートワークが推奨となり、3月末には全員が強制的に在宅勤務となりました。WEARプロダクトのエンジニアも2月より、各自自宅で業務を行なっています。 リモートワークになって懸念されたのが、メンバー間で十分なコミュニケーションが取れなくなることでした。特に、オフィスで自然と行われていた雑談レベルの会話が、リモートワークではできなくなってしまうことが問題と思われました。というのも、これまでは何気ない雑談から問題に気づいたり、問題が発生したタイミングで担当者に直接話しかけて素早く対処できたということが多々ありました。 また、業務の合間にメンバーと世間話をして、お互いの性格や価値観を知るということもできました。Slackなどのテキストチャットでコミュニケーションをとることもできますが、いくらタイピングが速くてもこういった雑談レベルのコミュニケーションを全てSlackで行うのは不可能と思われます。 個人的には、リモートワークでのテキストチャットによって、以下の点でコミュニケーションが低下することを懸念していました。 テキストを打つのが面倒で必要以上に発言しなくなる点 相手の状況がわからず、質問するタイミングが難しくなる点 急ぎの用であっても、相手が見てくれないと返事が来ない点 周りの状況がわからず、雑談を投げかけにくい点（雑談を投げかけても反応がないとソワソワしますよね） この他にも、リモートワークによる懸念はたくさんあると思います。 以降は、これらの懸念を解消するために行った対策を紹介します。 Discordでオフィスにいるかのように話しかける場を作る 上記の背景があり、弊社ではリモートワークで気軽にメンバーに話しかけることができるようにDiscordを導入しました。 Discordとは Discordは、もともとゲーマー同士が音声で会話をしながらゲームを進めるためのボイスコミュニケーションツールでした。サーバー（コミュニティ）を作成してチャンネルを用意することで、チャンネルにいるユーザーでボイスチャットができます。その他にも、テキストチャット機能やビデオ通話、画面共有もでき、とても便利なツールです。 弊社では、サーバーをプライベート設定することで使用を社内のメンバーに限定し、チームや個人のチャンネルを作成して様々な会話が行えるプラットフォームとして活用しています。 Discordについての詳細は、HPをご覧ください。 discord.com どこが便利？ 前述しましたが、Discordではチャンネルに入ることにより、チャンネル内のユーザーとボイスチャットができます。チャンネルはいくつも作成できるので、自分のチャンネルを作成している人もいます。 僕のチームでは、基本的に始業後はDiscordにログインしてチームもしくは自分のチャンネルに入り、マイクのみミュートの状態にしています。そうしておくと、僕に話しかけたい人は同じチャンネルに入ってきて「みっきー！」と話しかけることで、僕には相手の呼びかけが聞こえます。そして、マイクのミュートを解除するだけで会話を開始できます。 上図では、マイクをミュートにして自分のチャンネルにいる状態です。その他にも、数名が集まってミーティングをしていたり、僕と同じように個人のチャンネルで待機している人がいるのも一目でわかります。個人のチャンネルに一人でいる人は誰とも話していないことがわかるので、気軽に話しかけられます。また、誰かと話しているきに、チャンネルにふらっと他の人が入ってきて雑談が盛り上がるということもよくあります。 このように、Discordを利用すると雑談レベルの会話がリモートワークでも気軽に実現できます。これはとても画期的なことだと僕は思います！ 最近では、WEARプロダクトのみんなが一日中Discordにログインしているので、オフィスで働いているときと同じ感覚で効率よく会話ができています。 しかし、いくつか課題も残っています。Discordに常駐することは強制ではないので、ログインしていない人に話かけたい場合はSlackなどで呼びかけて返答を待つ必要があります。 また、どこかのチャンネルで複数人が会話している様子を伺えても、雑談をしているのか込み入った話をしているのか判断ができないのでチャンネルに入りづらい時もあります。 例えばDiscord常駐を強制にしたり、雑談は「雑談チャンネル」で行うなどルールを決めると、もっと気軽に話しかけられる環境が作れて快適になりそうです。 Discord × Visual Studio CodeのLive Shareプラグインを用いたリモートワークでのペアプロの試み ここで本題のリーモートワークでのペアプロについて紹介します。ペアプロには、先ほど紹介したDiscordとVisual Studio Code（以下、VSCodeと表記します）のLive Shareプラグインを組み合わせて使うのがオススメです！ Live Shareプラグインとは Live Shareプラグインは、簡単に言うとVSCode上で複数人が同じファイルをリアルタイム編集できるVSCodeの拡張機能です。ホスト側が招待リンクをゲスト側に渡すことで、ゲスト側がVSCode上でホスト側のファイルを編集できます。ファイルの他にも、ターミナルやローカルサーバーも共有できます。 marketplace.visualstudio.com 細かい使い方は公式情報をご覧ください。 visualstudio.microsoft.com Live Shareの機能を使ってみて個人的に驚いたのは、ゲスト側がホスト側のローカルファイルを触ることができることです。ホスト側のVSCodeのセッションにゲスト側がログインすることで、ホスト側のVSCodeで開かれているフォルダのファイルにアクセスできるので、ローカルファイルであっても共同編集できます。ソースコードを一旦GitHubへ上げ、プルリクを作成してレビューしてもらうなどの作業に比べると、ソースコードの共有と確認が格段にスムーズです。 Discordで話しかけて、Live Shareでペアプロをするととても効率的！ ここまでの結論として、リモートワークでは常にDiscordにログインした状態でいるのがオススメです。そして、ペアプロをしたいときは相手のいるチャンネルに行って「今ペアプロできますか？」と話しかけて、Live Shareを始める。こうすることでオフィスにいる時と比べても遜色ないほど、スムーズにペアプロを行うことができます。 さらに、Discordの画面共有機能も組み合わせると、ホスト側のローカル環境のプログラムの動作を一緒に確認しながら進められてとても便利です。僕たちのチームではこの方法を取り入れることで、リモートペアプロをしながらでも効率よくソースコードだけでなく表示の確認もできるようになりました。 DiscordとLive Shareプラグインのテキストチャット/ボイスチャットの比較 実は、Live Shareにもテキストチャットとボイスチャット機能があります。それぞれ、Live Share ChatとLive Share Audioという拡張機能をインストールすることで利用できます。尚、近日中にこれらの機能を統合したLive Shareがプレビュー公開される予定です。 詳しくは以下の記事をご覧ください。こちらの記事では、VSCodeでのテキストチャットとボイスチャットを使ったデモも確認できます。 devblogs.microsoft.com 実際に使ってみた感想 実際に使ってみた感想としては、テキストチャットについてはVSCodeアプリケーションから離れなくてもテキストが送れるので便利に感じました。しかし、現状ではテキストしか送れず、スクリーンショットやテキスト以外のファイルを送って説明するなどができないので少し歯がゆく感じました。その点では、他のテキストチャットアプリの方が快適です。 また、ボイスチャットも試したのですが音声が聞こえない状態になってしまい、その不具合は解消できませんでした。 何れにしても、Discordで相手に呼びかけてペアプロを始めるというフローが快適だと思うので、今の業務利用の仕方では、あえてLive Shareのボイスチャットは使わないかなと思いました。テキストチャットに関しては、ペアプロ中にURLなどちょっとしたテキストを送りたいときに便利なので使えそうです。 まとめ リモートワークにおけるペアプロの方法を紹介してきました。これまでの内容をまとめると、僕たちのベストプラクティスはDiscordでマイクをミュートにして常駐しておき、気軽に話しかけてLive Shareでペアプロをするという方法です。 この方法で、お互いに離れたところでリモートワークをしていても、話しかけてから10秒ほどでペアプロを開始することが可能になります。オフィスにいる時と同じくらいスムーズですよね！ リモートワークでのコミュニケーションやペアプロの方法に困っている方は、是非、この記事の内容を参考にしていただけると幸いです。また、この他にもリモートワークを快適に行う方法があれば教えていただけると嬉しいです。 さいごに 業務以外でも僕たちのチームでは、リモート環境でもチーム内コミュニケーション促進を狙えるゲームとして人狼ゲームをやってたりします。人狼ゲームはコミュニケーションがとれるだけでなく、その人の人間性や意外な一面を垣間見ることができるので、発足して間もない僕のチームにとってはとても実りがありました。 今回のリモートワークのように突然業務をする環境が変わった時、それまでとは違って不便になることは当然出てきます。そんな中で、新しい仕組みを作って快適にしていくということは、エンジニアが得意にしていることだと思います。環境の変化に負けず、新しい楽しみを見つけていきましょう！ ZOZOテクノロジーズでは、一緒に楽しく働いてくれる方を募集しています。ご興味のある方は、以下のリンクからぜひご応募ください。 tech.zozo.com

ZOZOテクノロジーズ SRE部の川崎（ @yokawasa ）です。ZOZOTOWNのアーキテクチャをマイクロサービスで再設計してリプレイス化を推進するチームに所属しております。 本記事では、このZOZOTOWNのマイクロサービスプロジェクトで実践している継続的インテグレーション/継続的デリバリー（以下、CI/CD）についてご紹介します。 はじめに まずはじめに、本記事に登場する中心的なキーワードであるCI/CDと、Infrastructure as Code（以下、IaC）について簡単に説明します。 IaCとは、インフラ構成をコード化して、そのプロビジョニングを自動化する手法です。コード化されたファイルはコードリポジトリで管理することが多く、また、IaCを実現するためのツールやサービスの利用が不可欠になります。 CI/CDは、その名の通り、CI（継続的インテグレーション）とCD（継続的デリバリー）の組み合わせです。CIはコードの変更を起点にコードの静的分析、ビルド、テスト、成果物の生成などの実行を自動化する手法です。一方、CDはCIで検証・テストされたコードや成果物を目的の環境に自動でデプロイする手法です。IaCと同様に、CI/CDを実現するためのツールやサービスの利用が不可欠です。 CI/CDの導入は組織全体のパフォーマンス向上のため CI/CDを導入する目的として、運用負荷の軽減や、自動化されたテストやデリバリによる品質の向上などが一般的に言われていることかと思います。もちろんこれらはCI/CDを導入する理由の1つではありますが、あまり強いものではありません。我々が考えるCI/CDを導入する真の目的は組織全体のパフォーマンス向上です。 CI/CDを導入することで、本来人間が行う必要のない作業は自動化され、結果的に空いた時間で本質的な作業に取り組むことができます。たとえば、開発者であればアプリ開発、SREであればサイトの信頼性向上といった本質的な作業に時間を割くことができます。これらのことはメンバーのモチベーション向上と、組織全体の生産性向上につながるものと考えています。 また、CI/CDパイプラインに落とし込むためには、作業の手順化とIaC化が必要になります。IaC化の恩恵は非常に大きく、変更履歴が管理できるようになり、属人的になりがちな運用・開発業務を非属人化しスケールさせることができるようになります。結果、組織全体のパフォーマンス向上が期待できます。 CI/CDを起点としたサービス環境の構築・更新 本プロジェクトにおいて、CI/CDはサービス環境の構築・更新の起点となる、非常に重要なプロセスであると捉えています。CI/CDの基本方針は以下の通りです。 可能な限りサービス環境の構成はIaC化する サービス環境の構築・更新はCI/CDパイプラインから行うことを基本とする もちろんIaC化、CI/CD化が技術的難しい、もしくはコスト的に見合わない場合は例外的にやらないものの、手動実行のための手順の文書化を徹底する 継続的な更新ループ CI/CDを中心としたサービス環境の更新ループの基本的な流れを紹介します。 先述の通り、CI/CDを起点としたサービス環境の構築・更新を基本方針としています。これをコード作成・変更から、CI/CDパイプラインからのサービス環境へのデプロイ、監視や試験結果によるフィードバックを元にさらにコード更新されるまでの一連のループを表したのが次の図です。 開発・検証、ステージング、本番環境など、ネットワークやKubernetesクラスタレベルで分離された複数環境を用意 GitHubでPull Request（以下、PR）を投げたら、自動的にテストを実行 PR上でレビューが完了するとソースコードがmasterブランチへマージされ、CI/CD経由で開発・検証とステージング環境に自動デプロイ リリースはreleaseブランチ管理で、releaseブランチにPRを投げてレビュアーによる承認、ソースコードのマージを経て、CI/CD経由で本番環境に自動デプロイ サービス環境は常に自動監視され、異常が検知されると関係者にアラート通知 ステージング環境で結合試験、負荷試験を実施し、本番想定の環境で機能要件・非機能要件の確認実施 この更新ループのゴールは、局所的ではなく全体として機能するよう継続的にアップデートできることです。そのため、開発・検証環境やステージング環境など、分離された環境でのアプリやインフラの変更点による影響の洗い出しはとても重要なプロセスになります。 また、上述の通り、デプロイ前のチェック機構として必ずレビュープロセスを通るようになっています。以下、レビュープロセスのポイントとフロー図になります。 PRにおいてマージ前に必ずレビュープロセスを通るように、 ブランチの保護機能 でレビュー必須を有効化している ソースコードの品質のみならず運用的な観点でコードの変更点による運用プロセスへの影響もレビューする 必要に応じて関連文書も含めてレビューする CI/CDパイプラインの紹介 マイクロサービスプロジェクトで導入しているCI/CDパイプラインを簡単に紹介します。 CI/CDを起点として構築・更新しているインフラやプラットフォームサービスのパイプラインをインフラCI/CDとして、またコンテナーアプリのパイプラインをアプリCI/CDとして紹介します。 なお、本プロジェクトではクラウド基盤にAWSを採用しており、アプリはコンテナーベース、コンテナーアプリの基盤プラットフォームにはマネージドKubernetesサービスであるEKSを採用しています。 また、AWS外のサービスでは、APMにDatadog、障害通知にPagerDutyを採用しています。CI/CDパイプラインは、インフラ・アプリ共にGitHub Actionsを活用して構築しています。 インフラCI/CD ネットワークやストレージを始め、IAM、監視、ログ解析サービスなどAWSで利用しているほぼすべてのリソースをAWS CloudFormation（以下、CFn）を活用してIaCを実施しています。CFnが対応しているリソースをCFnテンプレートに落とし、これをGitHubでコード管理します。CI/CDパイプラインで、CFnのChange Setの仕組みを使ってリソースの変更点を検証し、サービス環境にデプロイします。 また、コンテナーアプリはEKSにデプロイします。アプリのデプロイに必要なKubernetesリソースはすべてKubernetes YAMLファイルに落とし、これをGitHubでコード管理します。CI/CDパイプラインでYAMLの差分チェックを行い、EKSにデプロイします。 さらに、AWS外のDatadogやPagerDutyなどの利用サービスについても、Terraformを活用してIaCを実施します。これらの構成定義をTerraform構成ファイルに落として、GitHubでコード管理します。CI/CDパイプラインでterraform plan/applyコマンドを実行しサービス環境にデプロイします。 各CI/CDの利用IaCツールとパイプラインの内容を表したものが下図です。 アプリCI/CD 先述の通り、EKSにデプロイするためのコンテナーアプリをビルド、静的分析して最終的にECR（AWSのマネージドコンテナーレジストリサービス）にPUSHするところまでをCI/CDで行います。構築するコンテナーの構成をDockerfileに記述し、インフラCI/CDと同様にアプリのコードを含めてGitHubでコード管理します。 なお、ここでは内容については紹介しませんが、データ生成用の定期実行ジョブやDBのマイグレーション処理についてもCI/CDで実行している例もあります。 以上、簡単ではありましたが、CI/CDパイプラインの活用事例を紹介しました。 DevとOpsの責任分界点 DevとOpsは弊社組織でいうと、開発者（Dev）と運用管理を行うSRE（Ops）になります。マイクロサービスプロジェクトにおいては、その名の通り、開発者は基盤となるアプリケーションの開発を、SREはマイクロサービスの信頼性を向上させるための運用・開発作業を主に行います。 ただし、DevとOpsの間に責任分界点が明確に分けられているかと言えばそうではありません。基本的な精神としてソフトウェアをスピーディかつ安定的にデリバリすることが中心にあり、そのためには双方が協力し、それぞれのドメインを越えることは多々あります。つまり分界点は良い意味であいまいです。 たとえば、アプリケーションコードにSREが手を入れることもありますし、アプリのCI/CDパイプラインをSREが作成することもあります。また、開発者がKubernetes YAMLファイルに手を入れることもあります。 まとめ 本記事ではZOZOTOWNのマイクロサービスプロジェクトで実践しているCI/CDについてご紹介しました。 徹底したIaC化とCI/CDを起点としたサービス更新の取り組みがご理解いただけたのではないでしょうか。 なお、今回のトピックはCI/CDでしたが、マイクロサービスプロジェクトにおいては数多くのおもしろい技術的取り組みやチャレンジがあります。これらについては他のメンバーがどこかで共有してくれるはずですのでご期待いただければと思います。 登壇資料や関連サイト 著者のボスにあたる、 そのっつ さんが Infra Study Meetup#1 にて、リモートワークとIaCやCI/CDとの相性の良さについて発表しました。その時のスライドが こちら です。 docs.google.com ZOZOテクノロジーズは、 技術書典 応援祭 にて、有志で制作した技術同人誌【ZOZO TECH BOOK VOL.1】の頒布を行いました。著者は同誌において「第3章　速習GitHub Actions 〜 明日からの充実GitHub自動化ライフのための凝縮ポイント 〜」というタイトルで、GitHub Actionsについての記事を執筆しました。現在も引き続き BOOTHにて頒布中 ですのでご覧いただけたら幸いです。 zozotechnologies.booth.pm さらに、関連イベントとして、4/28と4/30の二日間、頒布をしている ZOZO TECH BOOK VOL.1 の解説会をオンラインで実施しました。著者は、そこで同記事に関する解説を行いました。そこでの発表スライドもよろしかったらご参照ください。 さいごに ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 tech.zozo.com

こんにちは。ZOZOテクノロジーズの廣瀬です。 弊社ではサービスの一部にSQL Serverを使用しています。先日、「普段は数10ミリ秒で実行完了するクエリが、たまに5秒間実行され続けて最終的にタイムアウトするので調査して欲しい」という依頼を受けました。調査方法を整理して最終的に原因の特定とタイムアウト発生の防止まで実現できたので、一連の流れとハマった点、今回のようなケースでの調査に使える汎用的な調査手法をご紹介したいと思います。 SQL Server以外のRDBMSをお使いの方にも、「SQL Serverではこんな情報がとれるのか。MySQLだったら〇〇でとれる情報だな」というように比較しながら読んでいただけると嬉しいです。 初めに浮かんだ仮説 依頼を受けて最初に思い浮かんだのは、「ブロッキングが起きているのでは」という仮説でした。そこで、 拡張イベント を使ってブロッキングを検出できる状態にしました。取得するように設定したイベントは以下の4つです。 blocked process report（ブロッキングが一定時間続いた場合に発生） attention（アプリから受け取った途中終了の要求に応じてクエリを停止したときに発生） sql_batch_completed（クエリの実行完了時に発生） RPC_completed（クエリの実行完了時に発生） sql_batch_completedとRPC_completedの違いについては、sql_batch_completedはクエリがTransact-SQLバッチとして実行されたときに発生します。一方で、RPC_completedはクエリがリモート プロシージャ呼び出しとして実行されたときに発生します。blocked process reportについては こちら に詳しく解説されています。今回はプログラム側で設定するタイムアウト値が5秒であるため、blocked process thresholdには3秒を設定しました。また、sql_batch_completedとRPC_completedについてはResult=Abort（異常終了）でフィルタを設定しました。Result=Abortでフィルタしたsql_batch_completedとRPC_completedイベントが起きた同一時間帯でblocked process reportイベントが発生していれば、ブロッキングが原因でタイムアウトした可能性があります。また、blocked process reportイベントの中身を見ることで、Result=Abortで終了したクエリがブロッキングされていたかどうかを特定できます。 調査した結果、Result=Abortでフィルタしたsql_batch_completedとRPC_completedイベントが起きた同一時間帯で、blocked process reportイベントは起きていませんでした。したがって、今回のタイムアウトの原因はブロッキングではないことが分かりました。 次の調査に移るための情報取得 ブロッキングではないことが分かったので、次の仮説を立てようと、考えられる原因について考えました。しかし、「いつもは高速なクエリが突然遅くなる事象」の原因としては考えられるパターンが複数存在します。そのため、次のステップとして、いきなり仮説を立てるのではなく、次の調査に移るためにどういった情報を取得すれば良いかを考えました。 タイムアウトしたクエリが5秒間実行され続けるとき、何らかの「待ち状態」になっていると考えられます。ブロッキングは数ある待ち状態の一つでしかなく、どういった待ち状態であったかを後追いできる仕組みを作ることで調査に必要な情報が取得できるのではと考えました。 そこで、実行中のリクエストを取得できる DMV である、 dm_exec_requests の実行結果を1秒ごとにテーブルにダンプする仕組みを作りました。このテーブルには、実行中クエリの現在の待ち状態と前回の待ち状態が「wait_type」、「last_wait_type」としてそれぞれ格納されています。そのため、1秒ごとにこの情報をダンプしておくことで、タイムアウトにいたるまでの待ち状態の遷移を後から確認することができます。 まず、ダンプするためのテーブルを以下のクエリで作成します。 select getdate() ,a.session_id ,a.request_id ,a.start_time ,a.status ,a.command ,a.database_id ,a.blocking_session_id ,a.wait_type ,a.wait_time ,a.last_wait_type ,a.wait_resource ,a.open_transaction_count ,a.open_resultset_count ,a.transaction_id ,a.cpu_time ,a.total_elapsed_time ,a.scheduler_id ,a.reads ,a.writes ,a.logical_reads ,a.text_size ,a.transaction_isolation_level ,a.lock_timeout ,a.deadlock_priority ,a.row_count ,a.prev_error ,a.nest_level ,a.granted_query_memory ,a.executing_managed_code ,b.login_time ,b.host_name ,b.program_name ,b.client_interface_name ,b.login_name ,b.memory_usage ,b.total_scheduled_time ,b.last_request_start_time ,b.last_request_end_time into dm_exec_requests_dump from sys.dm_exec_requests a with (nolock) join sys.dm_exec_sessions b with (nolock) on a.session_id = b.session_id where 1 = 1 次に、以下のクエリをジョブなどで実行します。dm_exec_requestsをSELECTした結果を、無限ループで1秒ごとにテーブルにINSERTしていきます。 set nocount on while ( 1 = 1 ) begin insert into dm_exec_requests_dump select getdate() ,a.session_id ,a.request_id ,a.start_time ,a.status ,a.command ,a.database_id ,a.blocking_session_id ,a.wait_type ,a.wait_time ,a.last_wait_type ,a.wait_resource ,a.open_transaction_count ,a.open_resultset_count ,a.transaction_id ,a.cpu_time ,a.total_elapsed_time ,a.scheduler_id ,a.reads ,a.writes ,a.logical_reads ,a.text_size ,a.transaction_isolation_level ,a.lock_timeout ,a.deadlock_priority ,a.row_count ,a.prev_error ,a.nest_level ,a.granted_query_memory ,a.executing_managed_code ,b.login_time ,b.host_name ,b.program_name ,b.client_interface_name ,b.login_name ,b.memory_usage ,b.total_scheduled_time ,b.last_request_start_time ,b.last_request_end_time from sys.dm_exec_requests a with (nolock) join sys.dm_exec_sessions b with (nolock) on a.session_id = b.session_id where a.session_id > 50 and datediff(s, a.start_time, GETDATE()) >= 1 waitfor delay ' 00:00:01 ' end あとは、タイムアウトしたクエリのセッションIDとタイムアウト時間帯でテーブルをフィルタします。タイムアウトしたクエリのセッションIDは、Result=Abortでフィルタしたsql_batch_completedかRPC_completedイベントを確認することで取得できます。 select top 100 datediff(ms, start_time, collect_date) as duration_ms ,* from dm_exec_requests_dump with (nolock) where collect_date between ' 2020-04-10 11:59 ' and ' 2020-04-10 12:10 ' and session_id in ( 559 ) order by collect_date タイムアウトしたクエリは上図のように、常にPAGEIOLATCH_SHで待っている状態でした。ここで、PAGEIOLATCH_SHという待ち状態について説明します。SQL Serverでは、必ずメモリからデータを読むのですが、以下のいずれかの流れをとります。 メモリに欲しいデータがある場合：メモリから直接読む メモリに欲しいデータがない場合：ディスクからメモリに読み、その後メモリから直接読む PAGEIOLATCH_SHは「ディスクからメモリに読む」ときに発生する待ちです。そのため、物理読み取りによる待ち時間が起因して普段よりもクエリ実行に時間がかかっている状況だったといえます。ブロッキングのように他のリクエストと競合しているわけではありませんでした。 実行プランが突発的におかしくなり、通常よりも大量のIOを発生させている可能性を考え、タイムアウトしたクエリの実行プランのプロパティを確認してみました。その結果、「十分な数のプランが見つかりました」という理由でクエリの最適化が途中で終わっていました。最適化が途中終了する程度にシンプルなクエリなので、実行プランが突発的におかしくなるわけでもなさそうでした。 別の可能性として、バッチ処理等で大量にデータを読み取る処理が発生したタイミングで、メモリからデータがキャッシュアウトされたことで通常時よりも多くのデータのディスク読み取りが発生する状況を考えました。そこで、[SET STATISTICS IO ON]をつけてタイムアウトしたクエリ実行し、各テーブルの読み取り状況を確認しました。 多少物理IOは発生していますが、通常時は10ミリ秒程度で実行完了します。そのため、仮にキャッシュアウトされたことで全データが物理読み取りになったとしても、5秒もかかるものなのだろうかと疑問に思いました。 以上を踏まえると、キャッシュアウトによる物理ディスク読み取り量が増えたことが原因というよりは、別のクエリが大量のデータを読み取ることで急激な物理ディスク負荷がかかり、ディスクキューの数値が上昇し、1IOあたりの物理読み取りの時間が伸びているのでは、と考えました。 タイムアウトしたときのdm_exec_requestsのダンプ結果を再掲します。上図から、wait_timeが毎回数10ミリ秒になっていることが分かります。これは普段の傾向なのか、タイムアウト時の傾向なのか判断するために、今までの累計値（≒通常時）から、物理ディスク読み取り時の平均待ち時間を確認しました。 select * ,wait_time_ms / waiting_tasks_count as avg_wait_time_ms from sys.dm_os_wait_stats where wait_type like ' %pageiolatch% ' and waiting_tasks_count > 0 PAGEIOLATCH_SHの平均待ち時間（avg_wait_time_ms）は2ミリ秒でした。このことから、タイムアウトが発生するタイミングでは、1IOあたりの待ち時間が通常時よりも大幅に長くなっていることが分かりました。ディスクまわりのメトリクスを採取することで、このあたりの情報をより詳細に確認できます。したがって、次のステップとしてperfmonで採取したメトリクスを解析してみました。 perfmonで取得したメトリクス解析 20:05:24ごろタイムアウトしたクエリがあったので、その時間帯付近に注目して各メトリクスを確認しました。 メモリ内のデータ保持予測期間を示す「SQL Server:Buffer Manager\Page life expectancy」の値が定期的に大幅に減少しています。これはデータのキャッシュアウトが定期的に発生していると読み取ることができますが、ある程度規則性があり、タイムアウト発生時だけ特異な形状というわけではありませんでした。 「PAGEIOLATCH_SH」待ちがエラー発生の時間帯で突出して高いことが分かります。タイムアウトしていないクエリも、一時的に実行時間が伸びている可能性がありそうです。 ディスクキューも確認しました。データファイルが格納されているドライブのディスクキューが突出して高くなっていました。タイムアウト時間帯以外もスパイクはみられました。 秒間のディスク読み取り量についても、データファイルが格納されているドライブが突出して高く、タイムアウトが起きた時間帯では高い値のまま一定期間推移しているように見受けられます。この値がDBサーバーの物理ディスク性能の上限値である可能性が高そうです。 物理読み取りサイズと、ディスクキューの発生状況の関係を見るため重ねてみると、両者には相関関係がありそうです。 物理読み取りサイズとPage IO Latch Waitsにも関係があるようでした。「大量にディスク読み取りを行うプロセスが1つ以上存在し、ディスク性能上限に達するほどの読み取りを行っている状況下で、物理ディスクにアクセスが必要なクエリが実行されることでPage IO Latch Waitsがスパイクする」と解釈しました。 perfmonのメトリクス解析結果まとめ 定期的に物理ディスク読み取り性能の上限に達しており、そのタイミングで物理読み取りが必要なクエリが出てくると「Page IO Latch Waits」が発生するようです。この時点で、「普段は数10ミリ秒で実行完了するクエリが、たまに5秒間実行され続けて最終的にタイムアウトする」原因としては、そのクエリ自身にはなんの落ち度もないことが分かりました。かわりに、別の何らかのクエリがディスク性能の上限に達するほどの大量の物理読み取りを行っているため、他のクエリがわずかな物理読み取りを行う際でも通常時よりかなり時間がかかってしまい、場合によってはタイムアウトに達することもある、という状況でした。 最後に、実際に大量の物理読み取りを発生させているクエリを特定すれば、実際に対策を実施できる可能性があります。 大量の物理読み取りをおこなっているクエリを特定する タイムアウトが発生した時間帯における物理読み取り量が多い順にsession_idを並び替えるクエリを以下の通り作成しました。 declare @start_time datetime, @end_time datetime set @start_time = ' 2020-04-14 20:05:10 ' set @end_time = ' 2020-04-14 20:05:40 ' declare @total_reads bigint set nocount on --session_idごとの物理読み取りページ数推移 select (a.reads - b.reads) as reads_diff ,a.* from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 order by a.session_id, a.collect_date --総物理読み取り数を取得 select @total_reads = sum ((a.reads - b.reads)) from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 --総論理読み取り数が多い順にリクエストを並べる select a.session_id, a.start_time, sum ((a.reads - b.reads)) as reads_diff, sum ((a.reads - b.reads)) * 100 / @total_reads as percentage from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where collect_date between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 group by a.session_id, a.start_time order by sum ((a.reads - b.reads)) desc このクエリの実行結果です。該当の時間帯で最も総物理読み取りサイズが大きいセッションでも29541ページ（約230MB）しか読み取っていないという結果になりました。この程度のディスク負荷では、性能上限には達しない印象で、作成したクエリが間違っていそうです。そこで、次に「タイムアウト発生直前の20:05ごろに開始したクエリの中で、総物理読み取り数が多い順」で並び替えてみたところ、以下のクエリをみつけました。 ①と④に着目すると、クエリがタイムアウトした時間帯（2020/04/14 20:05:24ごろ）では、物理読み取りページ数（reads）がカウントアップされておらず、ずっと0になっていました。そのため、最初に作成したクエリにはヒットしていませんでした。そして、タイムアウトとは時間的には関係がない時間帯（図中②）において、いきなり「reaeds」が5358249（約41GB）まで跳ね上がっていました。 今回のDBサーバーのディスク性能を考慮すると、数秒で41GBを読み取ることは不可能です。したがって、「readsは常に読み取ったサイズをカウントアップするわけではなく、あるタイミングで一気に累積読み取り数を計上することがある」といえます。この仕様を知らなかったのでクエリの書き方を間違い、結果として根本原因のクエリを見つけることができない状態になっていました。readsが計上されない条件ですが、少なくともlast_wait_type=CXPACKET（③）である場合、つまり並列処理している間はreadsに限らず、writesなど複数項目がカウントアップされないようです。 以上の調査を踏まえ、以下のクエリで大量の物理読み取りを行っているクエリを特定することができました。 declare @start_time datetime, @end_time datetime set @start_time = ' 2020-04-14 20:04 ' set @end_time = ' 2020-04-14 20:06 ' declare @total_reads bigint set nocount on --session_idごとの物理読み取りページ数推移 select (a.reads - b.reads) as reads_diff ,a.* from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 order by a.session_id, a.collect_date --総物理読み取り数を取得 select @total_reads = sum ((a.reads - b.reads)) from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 --総論理読み取り数が多い順にリクエストを並べる select a.session_id, a.start_time, sum ((a.reads - b.reads)) as reads_diff, sum ((a.reads - b.reads)) * 100 / @total_reads as percentage from ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) a join ( select row_number() over(partition by session_id, start_time order by collect_date) as rownum ,* from dm_exec_requests_dump with (nolock) where start_time between @start_time and @end_time ) b on a.session_id = b.session_id and a.start_time = b.start_time and a. rownum -1 = b. rownum where (a.reads - b.reads) > 0 group by a.session_id, a.start_time order by sum ((a.reads - b.reads)) desc 修正版のクエリの実行結果です。修正前は、「タイムアウト発生タイミングでreads=0だけどディスクに高負荷をかけているセッションが存在する場合がある」ということを考慮せずに作成したクエリでした。一方で、修正版ではそれを考慮したうえで作成しているため、こちらのクエリの方が信頼できる結果を得られています。 原因と解決方法まとめ 断続的なタイムアウトの原因 ディスク性能限界まで達するほどの物理読み取りが数秒～数10秒継続した状態において、物理読み取りが必要なクエリが実行されたとき、通常よりも物理読み取りに時間がかかり、タイムアウトに達することもある状況になっていました。 解決方法 理論的には、性能限界まで物理読み取りを発生させなければ大丈夫です。そのためには、大量の物理読み取りを行っているクエリを特定し、特定結果によって以下のAかBいずれかの場合に応じた対応をとれば良いはずです。 A：複数のクエリが同タイミングで実行されることで合算値として性能限界まで読み取る場合 各クエリをチューニングするか、定期的な周期で実行しているクエリがある場合は実行タイミングをずらす。 B：単一のクエリにより性能限界まで読み取る場合 物理読み取り削減という観点でのチューニング（圧縮・クエリチューニング・インデックス等）を実施する。 今回特定した結果はBに該当し、シンプルにインデックスを張ることで該当クエリのIOを劇的に削減できました。結果的にこのクエリ起因でのクエリタイムアウト発生を防ぐことができるようになりました。 クエリタイムアウト発生時の原因調査方法 今回紹介した調査手法を、以下の3ステップとしてまとめます。 現在実行中のクエリリストを取得できるDMVであるdm_exec_requestsのSELECT結果を定期的にダンプしておく タイムアウトが発生した場合に、該当のクエリがどういった待ち状態で遷移していたかを確認する 待ち状態の種類に応じてさらに調査していく ステップ3については、待ち状態によって手順が多岐にわたりますが、ステップ1と2については調査の初期段階として汎用的に使っていただけると思います。 補足 今回調査したサーバーでは使えませんでしたが、SQL Server 2017以降ではクエリストアを使って各クエリの待ち事象を取得することができるようになっています。そのため、今回ご紹介した調査手法をクエリストアだけで完結させることができます。なお、クエリストア自体は2016から提供されていますが、待ち事象が取得できるようになったのは2017からです。 参考： クエリストアを利用した待ち事象の取得 まとめ 調査依頼を受けたときに最初に思いついた原因はブロッキングでしたが、結果としてまったく違う原因でタイムアウトが起きていました。原因調査では、仮設を立てる前に可能な限り必要な情報を集めることが重要だと感じました。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

こんにちは、ECプラットフォーム部の権守です。普段はZOZOTOWNのリプレイスに関わるID基盤とAPI Gatewayの開発を行っています。 ID基盤やAPI Gatewayの中身についてもいずれ紹介したいと思いますが、本記事では、ID基盤のAPI開発で取り入れているGo言語におけるOpenAPIを使ったレスポンス検証について紹介します。 OpenAPIを使ったレスポンス検証 OpenAPI Specification （以下、OpenAPIと表記します）はREST APIのためのプログラミング言語に依存しない標準的なインタフェース記述言語です。OpenAPIについては以前に こちら の記事でも取り上げましたので、合わせて読んでいただければと思います。 弊社では、新規で開発するAPIについてはOpenAPIを用いて仕様書を作成しており、ID基盤もそうして社内にAPI仕様書を提供しています。 OpenAPIは非常に素晴らしいものですが、実装側が仕様書通りのレスポンスを担保できなければ台無しになってしまいます。以前、 こちら の記事では同様の問題について、Rubyにおいてシリアライザを自動生成することで解決を試みた事例を紹介しました。ID基盤はGoを用いて開発しており、同じ方法が取れなかったため、実装したAPIが仕様に沿ったレスポンスを返せているかどうかのテストコードを簡単に書けるようにしました。 実装にあたり、 kin-openapi というパッケージを利用しました。OpenAPIに関するパッケージは様々ありますが、OpenAPIの最新バージョンである3系に対応しており、レスポンスを検証する機能を備えているものはkin-openapi以外見つけられませんでした。 次に、kin-openapiを利用したテスト方法について例を用いながら紹介します。 kin-openapiの使用例 まず、次のような仕様のAPIを実装することを考えます。 # openapi.yaml openapi : "3.0.3" info : title : api example version : 1.0.0 paths : /users/{id} : get : parameters : - name : "id" in : "path" required : true schema : type : integer responses : "200" : description : ユーザー情報 content : application/json : schema : $ref : "#/components/schemas/user" components : schemas : user : type : object required : - id - nickname properties : id : type : integer example : 1 nickname : type : string example : ゾゾ age : type : integer example : 22 ユーザー情報を返すだけのシンプルなAPIです。次にこれを満たすAPIを実装します。ここでは説明の簡単化のためレスポンスをモックとします。 // main.go package main import ( "net/http" "validate-response-sample/router" ) func main() { http.ListenAndServe( ":8080" , router.Router) } 標準のhttpパッケージを用いてWebサーバーを立ち上げます。ルーティングは次のrouter.goで定義したRouterを用います。 // router.go package router import ( "net/http" "github.com/gorilla/mux" ) var Router = func () *mux.Router { r := mux.NewRouter().StrictSlash( true ) r.HandleFunc( "/users/{id}" , func (w http.ResponseWriter, r *http.Request) { w.Header().Set( "Content-Type" , "application/json" ) w.Write([] byte ( `{"id": 3, "nickname": "マックス", "age": 18}` )) }) return r }() httpパッケージにはパスパラメータを扱う実装は含まれていないので、ここでは Gorilla のルーターを使っています。 モックを返すAPIを実装できたので、次に本題のテストコードについて説明します。 // main_test.go package main_test import ( "net/http" "testing" testingHelper "validate-response-sample/testing" ) func TestUserRequest(t *testing.T) { req, e := http.NewRequest(http.MethodGet, "/users/3" , nil ) if e != nil { panic (e) } e = testingHelper.TestRequest(req) if e != nil { t.Error(e) } } ユーザーAPIへのリクエストを作成し、レスポンス検証のために用意したヘルパー関数であるTestRequestへ渡します。TestRequest関数は実際にHTTPリクエストを行い、受け取ったレスポンスが期待するレスポンス形式に沿っていないとエラーを返します。TestRequest関数の具体的な実装は以下になります。 // helpers.go package testing import ( "context" "io/ioutil" "net/http" "net/http/httptest" "net/url" "validate-response-sample/router" "github.com/getkin/kin-openapi/openapi3filter" ) func TestRequest(request *http.Request) error { ts := httptest.NewServer(router.Router) defer ts.Close() openAPIRouter := openapi3filter.NewRouter().WithSwaggerFromFile( "openapi.yaml" ) route, pathParams, e := openAPIRouter.FindRoute(request.Method, request.URL) if e != nil { return e } u, _ := url.Parse(ts.URL) request.URL.Scheme = u.Scheme request.URL.Host = u.Host response, e := http.DefaultClient.Do(request) if e != nil { return e } defer response.Body.Close() body, e := ioutil.ReadAll(response.Body) if e != nil { return e } requestValidationInput := &openapi3filter.RequestValidationInput{ Request: request, PathParams: pathParams, Route: route, } responseValidationInput := &openapi3filter.ResponseValidationInput{ RequestValidationInput: requestValidationInput, Status: response.StatusCode, Header: response.Header, } responseValidationInput.SetBodyBytes(body) return openapi3filter.ValidateResponse(context.TODO(), responseValidationInput) } 次の手順で処理を行っています。 テスト用サーバーを立ち上げ openapi.yamlの読み込みとリクエストに該当する記述の探索 受け取ったリクエストのテストサーバー用のURLへの書き換え 実際のリクエストとレスポンスの受け取り 返ってきたレスポンスとopenapi.yamlに記述されたレスポンス形式が一致するかの確認 これでOpenAPIを用いて作成した仕様書と実装が食い違うことを防ぐテストを簡単に書けるようになりました。 しかし、運用しているとある問題に遭遇しました。その問題と対応した方法について紹介していきます。 OpenAPIの拡張とその対応 OpenAPIではステータスコード毎に1つのレスポンスしか記載できません。しかし、実際には同じステータスコードに対して複数のレスポンス形式があることは珍しくありません。 例えば、ユーザー情報のGETリクエストにおいて本人にしか返さない項目があると、同じ 200 のステータスであっても本人からのリクエストかどうかでレスポンス形式が異なります。また別例として銀行口座からお金を引き出すAPIの例を考えると、同じ 403 のステータスでも本人以外の処理によるエラーと残高不足によるエラーではレスポンス形式は異なると考えられます。 そこで、 Responses Object に対して x-ステータスコード-タイトル といった形式のフィールドを追加して複数のレスポンスを表現することにしました。OpenAPIでは x- を接頭辞につけたフィールドを定義することで仕様を拡張することが許されています。具体的には次のように書きます。 # openapi.yaml openapi : "3.0.3" info : title : api example version : 1.0.0 paths : /users/{id} : get : parameters : - name : "id" in : "path" required : true schema : type : integer responses : "x-200-Self" : description : 自分のユーザー情報 content : application/json : schema : $ref : "#/components/schemas/self_user" "x-200-Other" : description : 他人のユーザー情報 content : application/json : schema : $ref : "#/components/schemas/other_user" components : schemas : self_user : type : object required : - id - name - nickname properties : id : type : integer example : 1 name : type : string example : 像造太郎 nickname : type : string example : ゾゾ birthday : type : string format : date example : 1998-05-21 other_user : type : object required : - id - nickname properties : id : type : integer example : 1 nickname : type : string example : ゾゾ age : type : integer example : 22 こうすることでOpenAPIの文法に準拠したまま1つのステータスコードに対して複数のレスポンス形式を記載できるようになりました。 しかし、これは独自拡張のため、このままでは導入したテストが動作しません。そこで、次のようにヘルパー関数を実装し直しました。 // helpers.go package testing import ( "bytes" "encoding/json" "errors" "fmt" "io/ioutil" "mime" "net/http" "net/http/httptest" "net/url" "regexp" "strconv" "validate-response-sample/router" "github.com/getkin/kin-openapi/openapi3filter" ) func TestRequest(request *http.Request, responseKey string ) error { ts := httptest.NewServer(router.Router) defer ts.Close() openAPIRouter := openapi3filter.NewRouter().WithSwaggerFromFile( "openapi.yaml" ) route, _, e := openAPIRouter.FindRoute(request.Method, request.URL) if e != nil { return e } u, _ := url.Parse(ts.URL) request.URL.Scheme = u.Scheme request.URL.Host = u.Host response, e := http.DefaultClient.Do(request) if e != nil { return e } defer response.Body.Close() e = validateResponse(response, route, responseKey) if e != nil { e = fmt.Errorf( "%v %v, %v: %v" , request.Method, request.URL.Path, responseKey, e.Error()) } return e } func validateResponse(response *http.Response, route *openapi3filter.Route, key string ) error { // validate status // ... // find expected response // ... // validate headers // ... // validate body // ... } TestRequest関数の大きな変更点は2つあります。まず、http.Request以外にレスポンスのキーを受け取ることです。元の実装ではレスポンスのステータスコードから期待するレスポンス形式が自動的にわかりましたが、拡張したことによってステータスコードからは一意に決まらなくなりました。そのため、期待するレスポンスのキーを指定する必要があります。 次に、kin-openapiが提供するvalidate関数の代わりに独自実装したvalidate関数を呼び出すことです。validate関数の中身について少しずつ説明していきます。 まずはステータスコードの検証部分です。 status := response.StatusCode var expectedStatus int re := regexp.MustCompile( "^[0-9]{3}$" ) if re.MatchString(key) { i, _ := strconv.Atoi(key) expectedStatus = i } else { re := regexp.MustCompile( "^x-([0-9]{3})-.+$" ) s := re.ReplaceAllString(key, "$1" ) if s == "" { return errors.New( "illegal response key" ) } i, _ := strconv.Atoi(s) expectedStatus = i } if status != expectedStatus { return fmt.Errorf( "want %v status, but got %v status" , expectedStatus, status) } レスポンスのキーとして従来通りのステータスコードを指定する場合と、拡張したキーを指定する場合を正規表現を用いて分岐しています。拡張したキーに関しては正規表現を用いてステータスコードの抽出も行っています。 OpenAPIではレスポンスのキーとして default や200系を示す 2XX などを設定できますが、厳密な仕様とするためにここではそれらを禁止しています。 次に、レスポンス仕様の取得部分です。 responses := route.Operation.Responses responseRef := responses[key] if responseRef == nil { return errors.New( "the response key is not documented" ) } expectedResponse := responseRef.Value if expectedResponse == nil { return errors.New( "reference of response has not been resolved" ) } 引数として受け取っているrouteは、リクエスト内容から該当する仕様を探したものです。そこから、レスポンス仕様を取り出します。 OpenAPI 3では $ref という表記を使うことで、componentsに記載した内容を参照できます。kin-openapiでは、この $ref を扱うために参照用の構造体を挟んで、実体はValueフィールドに持っています。参照を解決できていない場合にはValueフィールドの値がnilになるため、そのチェックをしています。 次はレスポンスヘッダーの検証です。 for k, v := range expectedResponse.Headers { h := response.Header.Get(k) expectedHeader := v.Value if expectedHeader == nil { return errors.New( "reference of header has not been resolved" ) } if expectedHeader.Schema == nil { return fmt.Errorf( "header schema of %v is not documented" , k) } expectedHeaderSchema := expectedHeader.Schema.Value if expectedHeaderSchema == nil { return errors.New( "reference of schema has not been resolved" ) } if e := expectedHeaderSchema.VisitJSON(h); e != nil { return e } } レスポンス仕様に記載されたヘッダーが実際のレスポンスに含まれているかを検証します。各ヘッダーのSchema Objectを取得し、VisitJSONメソッドに実際の値を渡すことでOpenAPI上のスキーマに沿っているかを検証できます。実際のレスポンスヘッダーの値はキーを元に取得します。 最後にレスポンスボディの検証です。 body, e := ioutil.ReadAll(response.Body) if e != nil { return e } content := expectedResponse.Content if len (content) == 0 { if string (body) == "" { return nil } return errors.New( "content of the key is not documented" ) } mediaType, _, e := mime.ParseMediaType(response.Header.Get( "Content-Type" )) if e != nil { return e } mediaTypeObject := content.Get(mediaType) if mediaTypeObject == nil { return errors.New( "unmatched Content-Type" ) } if mediaTypeObject.Schema == nil { return errors.New( "content schema of the key is not documented" ) } bodySchema := mediaTypeObject.Schema.Value if bodySchema == nil { return errors.New( "reference of schema has not been resolved" ) } var decodedBody interface {} if e = json.NewDecoder(bytes.NewBuffer(body)).Decode(&decodedBody); e != nil { return e } return bodySchema.VisitJSON(decodedBody) まず、レスポンスのボディを全て読み込んで変数に格納します。ボディが空の場合はそれが期待通りかどうかのチェックとしてContentフィールドも空であることを確認します。ContentフィールドはMedia Type毎にレスポンスボディのスキーマを持ちますが、レスポンスボディがないAPIであればContentフィールドは空になります。この場合はこれ以上検証するものがないので処理を終了します。 次に、ボディが空でない場合はレスポンスのContent-TypeヘッダーからMedia Typeを判別します。判別にはmimeパッケージのParseMediaType関数を用いています。ParseMediaTypeはContent-Typeヘッダーに含まれるパラメータも取得できますが、ここでは使わないのでMedia Typeだけを変数に格納しています。 Media Typeがわかったので、その値を用いて該当するレスポンスボディのスキーマを取得します。ここでもヘッダーの検証で用いたVisitJSONメソッドを使いますが、ヘッダーの値がただの文字列なのに対し、レスポンスボディはJSON文字列なので事前にデコードをしています。 これらによってレスポンスのキーを拡張した仕様書を使った場合でもレスポンスの検証ができるようになりました。 まとめ GoにおいてOpenAPIを使ったレスポンス検証を行うためにkin-openapiパッケージを使った方法を紹介しました。また、OpenAPIの表現力では足りないレスポンス表現についての拡張とそれに対応した検証方法を紹介しました。 Goで開発をしていてAPI仕様書と実装の食い違いに頭を抱えている方はぜひ試してみてください。 最後に、ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

はじめに こんにちは。ZOZO研究所の shikajiro です。主に研究所のバックエンド全般を担当しています。ZOZOでは2019年夏にAI技術を活用した「類似アイテム検索機能」をリリースしました。商品画像に似た別の商品を検索する機能で、 画像検索 と言った方が分かりやすいかもしれません。MLの開発にはChainer, CuPy, TensorFlow, GPU, TPU, Annoy、バックエンドの開発にはGCP, Kubernetes, Docker, Flask, Terraform, Airflowなど様々な技術を活用しています。今回は私が担当した「近似最近傍探索Indexを作るワークフロー」のお話です。 corp.zozo.com 目次 はじめに 目次 画像検索の全体像説明 Workflow Develop Application 推論APIの流れ 近似最近傍探索とAnnoy 近似最近傍探索Indexを作る ワークフローツールの説明 デメリット 画像検索のワークフローの全体像 日々のバージョンアップ 差分更新 特徴量抽出のキャッシュ 新しい特徴量抽出モデルへの変更 これから 失敗談 画像ダウンロードしまくって負荷をかけてしまう 開発期間の見積もりが難しい 課題 特定サービスが止まるとフローも止まる データはいつも同じではない ML部分のワークフロー化 まとめ 登壇資料や関連サイト さいごに 画像検索の全体像説明 クラウドはGCPを採用しています。分析基盤にBigQueryを使っていること、KubernetesのマネージドサービスであるGKEが安定していること、TPUを活用していることなどが採用の理由です。図の上から簡単に紹介します。 techblog.zozo.com Workflow ワークフローであるComposerは毎日販売中のおよそ300万の商品画像から特徴量抽出を行いIndexを作成しています。今回のお話のメインはここですが、もう少し全体像の説明を続けます。 Develop アプリケーションのコードはGitHub, CI/CDはCircleCIで管理しており、モデルはGCSに、アプリケーションはDockerとしてGCRに登録します。デプロイはCircleCIやComposerを使っています。なお、ML部分のCI/CDはまだ完全には実現できてません。 Application ユーザーが指定した画像から似た商品画像を返すAPIのことを 推論API と呼びます。Kubernetesで構成しており、後で紹介するマイクロサービスが連携して動作しています。 推論APIの流れ Composerの説明をする前に、特徴量Indexの動きを知るために推論APIの流れを紹介します。API、物体検出、特徴量抽出、近似最近傍探索、それぞれをマイクロサービスとして動かしています。商品情報検索だけはk8s外の外部サービスです。 ユーザーが画像検索に画像を送ると画像の中に写っている服などのアイテムを検出します。これが 物体検出 です。ここでトップスやシューズなどに分類します。判別した画像のままでは計算に適さないので、検出した部位を多次元ベクトルの特徴量に変換します。この特徴量で距離や類似度などの計量を計算できるようにします。具体的には512次元のfloatの配列になります。これが 特徴量抽出 です。過去テックブログでも紹介していますのでぜひご覧ください。 techblog.zozo.com techblog.zozo.com 特徴量から予め準備していたZOZOTOWNの約300万画像のIndexを使って、似ている商品画像を高速に探します。これが 近似最近傍探索 です。近似最近傍探索については東京大学の松井先生の資料が大変分かりやすいので、興味がある方は御覧ください。 speakerdeck.com 近似最近傍探索の段階では似ている商品の画像までしか分かっていません。最新の商品情報を取得するため、ZOZOTOWNの商品データベースに問い合わせてデータの整合性を保ちます。この部分は画像検索とは直接関係ないですが、実際のサービスでは大事な部分ですので紹介しました。 近似最近傍探索とAnnoy 上でも少し触れましたが、ZOZOTOWNが販売する約300万商品画像の中から最も似ている数十〜数百商品を高速に検索する必要があります。特徴量は多次元ベクトルであり対象商品も大量なため、普通に計算するととんでもない計算時間になってしまいます。ここで利用するのが近似最近傍探索です。これを実装した代表的なPythonのライブラリにSpotifyが開発しているAnnoy, Facebookが開発しているFaissなどがあります。画像検索の開発時に主にこの2つを検討し、Annoyを採用しました。理由は以下の2つです。 実装が容易であること 十分に高速であること もっと速度が必要ならばFaissとGPUの組み合わせを検討していましたが、AnnoyとCPUの組み合わせで速度・精度ともに十分だったため、現状はFaissにする予定はありません。 github.com 近似最近傍探索Indexを作る Annoyを使って近似最近傍探索を行うには、予め検索対象である約300万画像の特徴量を抽出して Index を作っておく必要があります。ビルド処理自体は数行のコードで実現できるのですが、画像を準備するのがなかなか大変です。以下の手順で作成しています。 BigQueryから現在販売中の画像情報を取得する 商品画像をZOZOTOWNストレージから取得する 画像から特徴量を抽出する 特徴量からAnnoyのBuildを行う IndexをGCSに保存する 推論APIで利用する これらをバッチプログラムを書いて実装することも可能ですが、上記それぞれで必要なCPUリソースもバラバラで、特に特徴量抽出は多くの計算資源を必要とします。エラー時のリトライ、Slackなどへの通知、ロギングの仕組みなどを考えるととても2から作るのは大変です。 そこで利用したのがAirflowなどに代表されるワークフローツールです。 ワークフローツールの説明 上でも触れましたが、バッチ処理を自前で書くとエラー処理、リトライ、ログ、通知処理など実装・運用コストが高いです。この辺りの面倒を見れくれるワークフローツールを検討しました。Airflow, Digdagなどがありますが、GCPのAirflowマネージドサービスであるComposerを採用しました。マネージドサービスだったのが一番の理由です。 AirflowなどのワークフローはDAG（Directed Acyclic Graph, 有向非巡回グラフ）という概念でタスク同士の依存関係を定義しています（詳しくは公式サイトに委ねます）。上記の1〜6の流れを簡潔に書けるようになり、途中からの実行などが容易になります。 airflow.apache.org デメリット ComposerのAirflowバージョンはGCPが管理しているため、最新のAirflowより遅れています。そのため、解決されていないバグや対応していないGKEオペレーションなどがあり、使い勝手・保守性に問題がありました。最近はバージョンでは追従できており、安定して稼働しています。 画像検索のワークフローの全体像 ざっと流れを紹介します。BigQueryから現在販売中の商品の画像URLをすべてダウンロードし、Filestoreに保存します。実際は前日までの画像がすでに存在するので、前日までの分と本日分の差分だけをダウンロードしています。 準備した画像を元に物体検出、特徴量抽出、近似最近傍探索Indexのビルドを行うのですが、大変重い処理なうえ、GPUも使うのでComposerのインスタンスで実行することはできません。そのため、別途GKEのクラスターを準備し、重い計算部分はそちらで計算しています。トップス、ボトムスなどのカテゴリ単位でPodを並列で動かし高速化しています。それでもまだ300万画像すべてを計算すると全体で24時間以上かかるので、日々改善を行っています。 特徴量は一部キャッシュとして保存しており、推論API側で利用しています。ZOZOTOWNの画像で画像検索する場合はこのキャッシュを流用できるため、推論APIのGPU資源を軽減させています。 ビルドしたIndexはモデルと同じGCSバケットに保存します。推論APIのGKEクラスターに対して近似最近傍探索PodのRollingUpdateを指示し、新しいIndexで動作する近似最近傍探索Podを起動します。ユーザーは更新された事に気が付かないまま、新しい結果を得ることができます。 エラーが起きた場合はSlackに通知しており、開発者がいつでも対応できるようにしています。 日々のバージョンアップ ワークフローは日々改善を行っています。リリース後に行った改善を紹介します。 差分更新 当初、早急にリリースする事を優先しており、ワークフローを簡素化していたため毎日販売中の画像300万画像すべての特徴量を計算しIndexを作成していました。これでは大変時間がかかりコストも高いので「昨日と比較して新しく追加された画像だけ計算する」ように変更しました。コストは大幅に下がり、数時間で計算が終わるようになりました。 特徴量抽出のキャッシュ 開発当初はユーザーが画像をPostして、その画像から似た商品を返却する予定で開発をしていました。ですが、ZOZOTOWNにある商品と似た商品を返却した方が良さそうとのことで、ZOZOTOWNの画像を推論するようになりました。その場合、ZOZOTOWNに既にある商品画像はIndexを作成する際に特徴量抽出を一度行っているため、キャッシュに使えることが分かりRedisを追加しました。これにより、推論APIで物体検出と特徴量抽出を行わなくてもよい状況が増えたので、GPU負荷が大幅に下がりコストが削減できました。 ※一部簡略化しています。すべてのリクエストでキャッシュを利用してるわけではありません。 新しい特徴量抽出モデルへの変更 現在トップスを始めとした8つのカテゴリに対応しており、日々新たなカテゴリに追加するため物体検出、特徴量抽出のモデルを開発しています。そこで特徴量抽出のモデルを更新する際にいくつかの問題が分かってきました。 新たなカテゴリに対応すると、今までのカテゴリの精度を劣化させる可能性がある 新たなカテゴリの学習のために今までのカテゴリ分も学習する必要があり、大幅に時間がかかる ここで、カテゴリ毎に特徴量を抽出するようにモデルを作り変える決断をしました。さらに、学習を高速化をするためTPU x TensorFlowへの変更も行いました。モデルが大きく変わったため特徴量は現版（v1）と新版（v2）でまったく異なります。v2でIndexを1から作り直すのに数日かかり、その間もv1でAPIは稼働し続けないといけないため、v1, v2のIndex作成ワークフローを並列で行う必要があります。今回は推論APIのPod、キャッシュストレージなどをv2用に予め作り、v2のDAGがIndexを作り終わったタイミングで、推論APIのPodの向き先をv2に切り替えるという対応を行いました。 ※一部簡略化しています。 これから 今後も機能追加、精度向上、コスト削減など様々な施策を実施していく予定です。ご期待ください。 失敗談 みんな大好き失敗談を紹介します。 画像ダウンロードしまくって負荷をかけてしまう 300万近くの画像はZOZOTOWNの画像サーバーから取得しています。300万画像を1つずつ取得していたら数週間かかるので、CloudFunctionsを使って無尽蔵に並列化して取得しました。案の定、サーバーに負荷をかけて怒られました。今は負荷をかけない程度の並列処理を実行しています。 開発期間の見積もりが難しい 実装自体は大したことないなと思っても、動作検証に大変時間がかかるため、実装に実質3日、検証に1か月みたいな事が平気で起きたりします。開発を効率化するためのスクリプト作り、安定した基盤づくり、可能な限り高速でタスクが完了するための高速化の工夫などがとても大事になります。 課題 これから解決していかなくてはならない課題たちです。 特定サービスが止まるとフローも止まる 例えばネットワークなどの都合で「特定のPythonパッケージがダウンロードできない」などが発生するとワークフローが止まってしまい、Indexを構築できません。これはクラウド時代には仕方がない部分ですが、ワークフロー中に外部依存する処理を減らしていく必要があります。 データはいつも同じではない 昨日まで動いていたのに動かなくなることが当たり前のようにあります。自分たちのコードのバグ、Airflowのバグ、商品画像数が増えたことでタイムアウトが発生した、依存している外部サービスに変更があった、など様々な要因があります。いつでも柔軟に対応できるよう、日々改善していくことが大事です。 ML部分のワークフロー化 現在Kubeflowを検証中で、モデルの精度が上がったら自動でデプロイされるような仕組みを検討しています。 まとめ 当初ワークフローの開発はそこまで大したこと無いだろうと考えていたのですが、API開発の10倍（個人の感想）くらい困難なものでした。これから新たに機械学習プロジェクトでワークフローを作る方は開発の初期段階からざっくり作り始めることをおすすめします。 私が携わった次期プロジェクトではこの知見が活き、迅速に開発・リリースができました。 lab.wear.jp このワークフローは一人で作ったわけではありません。研究所の研究者、開発者、特にMLOpsチームの協力があり安定したワークフローに成熟していきました。今後もZOZOテクノロジーズのメンバーで様々なサービスを提供していきますので、今後とも宜しくお願いします。 登壇資料や関連サイト techblog.yahoo.co.jp techblog.zozo.com さいごに ZOZOテクノロジーズでは福岡研究所のMLエンジニア、バックエンドエンジニア、MLOpsチーム（東京）のメンバーを募集しております。 https://hrmos.co/pages/zozo/jobs/0000029 hrmos.co hrmos.co hrmos.co

ZOZOMAT とは何でしょうか？オンラインで靴を購入する際に、サイズが合わないという問題を解決する仕組みです。1台のスマートフォンと紙製のZOZOMATだけで、正確に足のサイズを測れます。足をスキャンすると、高精度の3Dモデルが生成されます。最適なサイズの靴も表示されるので、すぐに靴を購入できます。 こんにちは！ZOZOテクノロジーズの @kapsy1312 です。ZOZOMATプロジェクトの一員として、スキャン結果を3D空間に表示するビューの開発を担当しました。プロトタイプでは、Appleの標準3Dフレームワーク、SceneKitを使用していました。しかし、全く同じ機能とデザインをAndroidで再現するにはコストがかかるため、さらに適切なソリューションを検討しました。 この記事では、スキャン結果の3DビューをAndroidとiOSデバイス向けに開発した際の課題と解決策を説明します。プラットフォーム依存のシーングラフフレームワークではなく、C++とOpenGLを選択した理由も説明します。付属の サンプルプロジェクト も用意してあり、後半で解説します。 スキャン結果の3Dビュー このようなスキャン結果の3Dビューには、次の設計要件がありました。 iOS 10以上とAndroid 5以上のサポート 遠近感が出ないように、足のメッシュを正投影で描画 足の寸法を表示するラベルとその測定値をビルボード（常にカメラの方向を向く動き）で描画 測定した箇所を正確に示す寸法線 アンビエントオクルージョン効果 カメラの初期位置を正確に指定 フェードと回転の初期アニメーション ピンチイン・ピンチアウト、ドラッグによる回転、ダブルタップによるカメラのリセット さらに、いくつかの実装上の要件がありました。 片足ずつスキャンするので、描画時に両方の足のメッシュを連結する（並べる）必要がある 描画前にメッシュのデータを90度回転し、大きさを調整しなければならない 足のメッシュは、OBJファイルと独自バイナリの両方の形式を読み込む必要がある 検討した選択肢 時間が限られていたため、iOSのプロトタイプにはAppleの SceneKit を選択しました。そのおかげでプロトタイプの開発は間に合わせることができました。しかし製品版としてリリースするには、SceneKitの様々な制限を回避する必要があり、さらに全く同じデザインをAndroidで再現するコストもかかることが分かりました。 そこで、次の点を考慮して、いくつかのソリューションを調査しました。 設計要件を満たす柔軟性は不可欠 3Dビューはプラットフォーム間で同一に見えるべき 設計の変更要求への対応が容易 検討した選択肢は次のとおりです。 SceneKit / Sceneform SceneKit には次の利点がありました。 重要な3D機能が揃っており、迅速なプロトタイピングが可能 アンチエイリアシング、ビルボード機能、フレームタイミングも用意されている 提供されているユーザータッチ入力とカメラコントロールはとても便利 ただし、これにはいくつかの制限もありました。 メッシュの3D変換、ラベルのビルボード、カメラの動作はAndroidで完全に複製する必要がある デフォルトのカメラ機能にバグ：ダブルタップしてリセットしてもアニメーションが思い通りに動かない メッシュを読み込んでから表示するまでに時間がかかる Swiftを使用して座標、ベクトル、行列の操作をするのは面倒 OBJファイルからのメッシュの読み込みは遅く、扱いも面倒 アンビエントオクルージョン効果が綺麗ではなくて、バグもある プロトタイプではSCNViewのdefaultCameraControllerを使っていたが、iOS 10では使用できないので、アニメーションのコードを書き直す必要があった これらの問題を解決するためには、美しくないハックと試行錯誤が必要です。また、望ましい結果が得られるまでフレームワークの動作を検証し続ける必要もあります。例えば、いくつかのサンプルプロジェクトを試してみないと、アンビエントオクルージョンの問題はバグなのか確認できませんでした。 詳細を調べたところ、Androidの Sceneform は、同様の制限が含まれているように見えました。これは、フレームワークに依存する際の根本的な問題と考えられます。フレームワークは提供者側が意図したとおりに使用されると役に立ちます。しかし、提供者側が意図していない使い方の場合には、回避策は自分で一から実装するよりコストが高くなる可能性もあります。 クロスプラットフォーム共有のC++とOpenGL クロスプラットフォーム共有のC++とOpenGLは、ゲーム業界でよく使われている開発のアプローチです。プラットフォーム固有の機能は抽象化されており、プラットフォーム自体はその抽象化された関数等に準拠しています。プラットフォームは抽象化コードを経由して共通のC++コードベースを呼び出したり、コールバックされたりします。コードのほとんどをC++に移植できる場合にはクロスプラットフォームの仕組みは非常に有効です。 iOSとAndroid（NDK）の両方にOpenGL ESのCヘッダーがあるため、直接レンダリング関数を呼び出せます。ただし、プラットフォーム固有のレンダラー（Metalなど）を呼び出すと、さらに多くの作業が必要となります。 クロスプラットフォームコードは、同じ機能の重複を避けられます。さらに、設計要件を実装するのに十分な細かい制御ができます。 C++を使用すると、他にも多くの利点があります。 メッシュの読み込みがより効率的になる SIMD機能も簡単に使える CPUのキャッシュに優しい処理も可能 メモリ効率の良い構造体で行列とベクトルを扱える ポインター操作は簡単で一貫している パブリックドメインのヘッダーのみのライブラリ（ stb など）を活用できる ただし、次の欠点もあると考えられます。 柔軟性は最も高いが、作業量が増加する 多くの機能は自分で実装する必要がある 他のソリューションと比較して学習コストが高い C++には不必要な機能があるため、コードガイドラインが不可欠 経験の浅い開発者がミスを犯しやすい シェーダーコードのデバッグが難しい Unity Unity はクロスプラットフォームのゲーム開発システムです。ソフトウェア自体は大きいのですが、携帯端末から高性能のゲーム用PC及びコンソールまで、幅広い複数の環境の開発が可能です。 ゲーム開発には向いていますが、ZOZOMATの開発要件を考えるとほんの一部しか必要ではありません。リアルタイムの物理シミュレーション、パーティクルシステム、VR、スクリプト、アニメーション等の必要性はゼロです。ZOZOMATでのユースケースが単純であることを考えると、学習コストがかなり高くなります。 Webアプリケーション three.jsなどのシーングラフフレームワークを使用して、ネイティブのWebビューに3Dを表示するという方法です。 JavaScriptのWebアプリケーションを使用すると、次の利点があります。 単一のコードベースが可能になる JavaScript自体は割と簡単 three.jsだと、3D知識がなくても開発ができる Webアプリケーションなので、変更する場合は再ビルド、再リリースが不必要 しかし、いくつか難点もありそうでした。 JavaScript側にメッシュデータを渡すにはASCIIの文字列でデータ量が多くなって、メッシュを表示するまで時間がかかる メッシュバイナリの読み込みには、C++インタフェースが必要 JavaScriptは高水準言語であり、パフォーマンスの問題を引き起こす可能性がある 実はこの方法は、ZOZOSUITのスキャン結果の3Dビューに使用しました。クロスプラットフォームを実現できましたが、パフォーマンスと品質の問題がありました。読み込み時間が遅く、iOSアプリのクラッシュバグが発生する場合もありました。原因は、あるiOSバージョンのUIWebViewのWebGL実装にあったので、その原因にたどり着くのも非常に困難でした。同じ状態を繰り返さないように、このWebアプリケーションの方法は避けた方がいいと考えました。 「クロスプラットフォーム共有のC++とOpenGL」を選択 いろいろな選択肢を検討した結果、完璧な解決策は存在しないと気がつきました。すべてのオプションには利点と欠点があり、その多くは開発が始まらないと気づかないと思います。 その上で、クロスプラットフォーム共有のC++とOpenGLが最善のアプローチであると判断しました。 SceneKitとSceneformをそれぞれ実装すると、C++で共有するよりも開発コストが高くなりそうです。C++とOpenGL ESだとコードが1か所で管理でき、設計要件を満たすための好ましくないハックも必要なくなります。 テストアプリを作成し、設計要件が最小コストで実現できることを確認しました。さらに、より迅速に3Dビューの開発サイクルを繰り返せるように、macOS版も開発しました。iOS版よりアプリケーションのビルドの待ち時間が大幅に削減できました。 Metalを採用すべきかの検討 AndroidではOpenGL ES、iOSではMetalを使用すると、両方をサポートする抽象化レイヤーがさらに必要になります。OpenGL ESはiOSおよびmacOSでは非推奨になっていますが、今回はコストと共通化の観点からOpenGL ESを使用しました。 パフォーマンスを追求しているアプリを開発する場合はMetalをサポートする抽象化レイヤーはオススメです。将来的に実装する計画はありますが、特に共通のシェーダー言語がないことを考えると、最初のバージョンとしてはコストが高かったです。 ZOZOMATのクロスプラットフォーム設計 ここまででクロスプラットフォームソリューションを選んだ理由を説明したので、次は実装の詳細について説明します。前述したように、iOS、macOS、Androidの サンプルプロジェクト があるので、プロジェクトの内容を詳しく解説していきます。 各プラットフォームには、独自のプラットフォームレイヤーが必要です。これは、プラットフォームと互換性のある言語で書かれています。C言語と対話できる外部関数インタフェース（Foreign Function Interface/FFI）をサポートする必要があります。Swift（iOS）やKotlin（Android JNI）はFFI機能を持つのですが、iOSやmacOS環境ではよりC言語と互換性が高いObjective-Cのほうが好ましいです。 処理の流れを解説します。 プラットフォーム抽象化レイヤー（platform abstraction layer）は、ヘッダーファイルにインタフェースを定義します。プログラムが正しく動作するためにプラットフォームレイヤー（platform layer）は抽象化レイヤーのインタフェースに従わなければなりません。 プラットフォームレイヤーは特有のフレームワーク（例えばNSFileManager、AAssetManager等）を内部的に使用し、プラットフォーム抽象化レイヤーのインタフェースに準拠します。 プラットフォームに依存しないレイヤー（platform independent layer）は、共有のC++が含まれています。このコードはプラットフォーム抽象化レイヤー（platform abstraction layer）の抽象化された関数なども従わなければなりません。 コードの大部分は、プラットフォーム依存しないレイヤー（platform independent layer）に収まる必要があります。そうでなければ、クロスプラットフォーム設計を選ぶ理由はほとんどありません。ZOZOMATとサンプルプロジェクトの場合、3Dのデータ変換とOpenGL ESレンダリングの呼び出しはすべて、プラットフォームに依存しません。 なお、プラットフォームごとにFFIを設定する方法の解説はこの記事の目的ではないので割愛します。iOSの場合は非常に簡単です。Android環境のJNIとNDKという機構の設定には Android NDK environment のドキュメントが参考になります。 クロスプラットフォーム関数の例 これは、 サンプルプロジェクト に掲載している、クロスプラットフォームのinitコールバック関数の基本的な例です。このコードの例は、より分かりやすくするために簡略化しています。 // ztr_platform_abstraction_layer.h typedef struct ztr_platform_api_t { platform_open_file *openFile; } ztr_platform_api_t; #define ZTR_INIT (name) void name (ztr_platform_api_t *platform) ZTR_INIT (ztrInit); // RenderView.m（iOS） #import "ztr_platform_abstraction_layer.h" static ztr_platform_api_t g_platform; - ( void ) setup { g_platform.openFile = openFile; ztrInit (&g_platform); } // RenderLib_ndk.cpp (Kotlin側から呼ぶAndroid JNIインタフェース） #import "ztr_platform_abstraction_layer.h" static ztr_platform_api_t g_platform; extern "C" JNIEXPORT void JNICALL Java_com_zozo_ztr_1android_RenderLib_init (JNIEnv* env, void *reserved, jobject assetManager) { g_platform.openFile = openFile; ztrInit (&g_platform); } // ztr_platform_independent_layer.cpp #import "ztr_platform_abstraction_layer.h" static ztr_platform_api_t *g_platform; ZTR_INIT (ztrInit) { // プラットフォームAPIのポインターを保存する g_platform = platform; // ここへプラットフォームに依存しない初期化コードを書く // ... // ... // ... } 共有のC++コードで初期化関数を実行したい場合は ztr_platform_abstraction_layer.h の初期化関数のシグネチャー ztrInit() が定義されているので、各プラットフォームで必要に応じてこの関数を呼び出し、必要なデータを渡すと、プログラムが正しく起動されます。 iOSの場合は RenderView.m の setup 関数から呼び出されます。Androidの場合は RenderLib の init 関数から呼び出されます。厳密に言うと、AndroidはJNIインタフェースを通じて RenderLib_ndk.cpp の中間関数を呼び出す、という流れです。この時、プラットフォームへのポインターも保存します。 プリプロセッサマクロを使用して関数のシグネチャを定義するという考え方は、 Handmade Hero からのものであることに注意してください。これは、抽象化レイヤー（platform abstraction layer）関数のシグネチャの引数の重複を回避するためです。これを使わないと各プラットフォームレイヤーにシグネチャーを複製しないといけません。引数の順番、数等を変更する場合も各プラットフォームの変更が必要です。プリプロセッサマクロを使用したら1つの変更で済むのでとても便利です。 プラットフォーム機能の呼び出し ztr_platform_independent_layer.cc がiOSとAndroidのプラットフォームレイヤー（platform layer）に存在するファイルを開く例を紹介します。 // ztr_platform_abstraction_layer.h #define PLATFORM_OPEN_FILE (name) ztr_file_t name ( const char *fileName) typedef PLATFORM_OPEN_FILE (platform_open_file); // RenderView.m（iOS） PLATFORM_OPEN_FILE (openFile) { ztr_file_t result = {}; NSArray *components = [[NSString stringWithUTF8String:fileName] componentsSeparatedByString :@ "." ]; if (components.count == 2 ) { NSString *fileNameBase = [NSString stringWithFormat:@ "res/%@" , components[ 0 ]]; NSURL *fileUrl = [[NSBundle mainBundle] URLForResource:fileNameBase withExtension :components[ 1 ]]; NSFileManager *manager = [NSFileManager defaultManager]; NSData *data = [manager contentsAtPath:fileUrl.path]; if (data) { result.data = ( void *) data.bytes; result.dataSize = ( unsigned int ) data.length; } } return (result); } // RenderLib_ndk.cpp（Android JNI interface） PLATFORM_OPEN_FILE (openFile) { assert (fileName != NULL ); ztr_file_t result = {}; AAsset *asset = AAssetManager_open (asset_manager, fileName, AASSET_MODE_STREAMING); assert (asset != NULL ); if (asset != NULL ) { result.data = ( void *) AAsset_getBuffer (asset); result.dataSize = AAsset_getLength (asset); } return (result); } // ztr_platform_independent_layer.cc static mesh_t * loadObj ( const char *fileName) { ztr_file_t file = g_platform-> openFile (fileName); if (file.data != NULL ) { // OBJファイル内容を読み込む } } プラットフォームに依存しないレイヤー、 ztr_platform_independent_layer.cc の loadObj() 関数では、3Dメッシュを読み込むためOBJファイルを開かなければなりません。ファイル名は認識していますが、ファイルを開くのはプラットフォーム自体に任せるしかありません。iOSとAndroidは異なる方法でファイルにアクセスするため、それぞれのプラットフォームレイヤーに依存する必要があります。 iOSアプリ内のファイルは、アプリケーションの内部ディレクトリ構造の特定の場所に存在するバンドルというものに収まっています。Androidの場合は、APK（基本的にはzipファイル）からファイルを抽出する必要があります。 ztr_platform_independent_layer.cc は各プラットフォームのファイルを開く方法は何も知らず、むしろ、知るべきではありません。 RenderView.m や RenderLib_ndk.cpp は ztr_platform_abstraction_layer.h で定義しているインタフェースに従い、 ztr_file_t の構造体を返しさえすれば、プラットフォーム間の差を無くすことができます。 これは、グローバル構造体 g_platform が使用される場所です。ファイルを開く関数を呼び出すには、プラットフォームへの参照が必要です。 g_platform は初期化関数で保存されています。 クロスプラットフォームOpenGL ES // ztr_platform_abstraction_layer.h typedef struct ztr_hid_t { float mouseX; float mouseY; int mouseDown; int mouseTransition; int doubleTap; int pinchZoomActive; int pinchZoomTransition; float pinchZoomScale; } ztr_hid_t; // MARK: Platform callback functions #define ZTR_INIT (name) void name (ztr_platform_api_t *platform) ZTR_INIT (ztrInit); #define ZTR_DRAW (name) void name (ztr_mem_t *mem, ztr_hid_t hid) ZTR_DRAW (ztrDraw); #define ZTR_RESIZE (name) void name (ztr_platform_api_t *platform, \ int w, int h) ZTR_RESIZE (ztrResize); クロスプラットフォームOpenGL ESを実装するのに、3つのコールバック関数を抽象化する必要があります。初期化関数、描画関数（各フレームごとに呼ばれる）、および画面のサイズを変更する関数です。 各プラットフォームのOpenGL ESセットアップについてはここでは説明しないので、興味のある方はぜひ、 サンプルプロジェクト を参考にしてください。 iOSの描画関数は次のようになります。 // RenderView.m（iOS） - ( void ) drawView { [[self openGLContext] makeCurrentContext]; CGLLockContext ([[self openGLContext] CGLContextObj]); ztrDraw ( 0 , g_hid); g_hid.mouseTransition = 0 ; CGLFlushDrawable ([[self openGLContext] CGLContextObj]); CGLUnlockContext ([[self openGLContext] CGLContextObj]); } プラットフォームレイヤー、 RenderView.m が特有のOpenGL ESメソッドを呼び出してから、抽象化されてる関数 ztrDraw を呼び出します。ユーザーのタッチ操作データも渡します。 Androidの場合、セットアップはより複雑ですが、最終的には RenderView クラスが RenderLib.draw() を呼び出します。 // RenderView.kt inner class Renderer( val assetManager: AssetManager) : GLSurfaceView.Renderer { var view: RenderView? = null var onSurfaceCreatedClosure: ((view: RenderView) -> Unit )? = null override fun onDrawFrame(gl: GL10) { RenderLib.draw( this @RenderView._mouseDown, this @RenderView._mouseDownUp, this @RenderView._mouseX, this @RenderView._mouseY ) } } RenderLib.draw() はJNIという機構を経由して、 Java_com_zozo_ztr_1android_RenderLib_draw のC++関数で、 ztrDraw を呼び出します。いくら文句を言ってもAndroidのJNIとはそういうものです。 // RenderLib_ndk.cpp（Android JNIインタフェース） extern "C" JNIEXPORT void JNICALL Java_com_zozo_ztr_1android_RenderLib_draw (JNIEnv* env, jobject obj, jint mouseDown, jint mouseDownUp, jint x, jint y) { hid.mouseDown = static_cast< int > (mouseDown); hid.mouseTransition = static_cast< int > (mouseDownUp); hid.mouseX = static_cast< int > (x); hid.mouseY = static_cast< int > (-y); ztrDraw ( 0 , hid); hid.mouseTransition = 0 ; } GLSurfaceViewやJNIなしでOpenGL ESを呼び出すことも可能であり、そのようなアプローチはより綺麗でパフォーマンスも高くすることができます。 クロスプラットフォームのレンダリング お馴染みのStanford Bunnyをレンダリングするための処理を紹介します。 初期化関数は以下のようになります。 // ztr_platform_independent_layer.cc ZTR_INIT (ztrInit) { g_platform = platform; g_scene.shaderCount = 0 ; // OpenGL ESを設定する GLint m_viewport[ 4 ]; glGetIntegerv (GL_VIEWPORT, m_viewport); glEnable (GL_CULL_FACE); glEnable (GL_BLEND); glBlendEquationSeparate (GL_FUNC_ADD,GL_FUNC_ADD); glBlendFuncSeparate (GL_ONE, GL_ONE_MINUS_SRC_ALPHA, GL_ONE, GL_ONE_MINUS_SRC_ALPHA); // シェーダープログラムをテキストファイルから読み込む assert (g_scene.shaderCount < MAX_SHADERS); g_scene.objectShader = g_scene.shaders + g_scene.shaderCount++; g_scene.objectShader->program = LoadShaders (shadingVersion, ( char *) "shaders/object_vert.glsl" , ( char *) "shaders/object_frag.glsl" ); g_scene.objectShader->elementType = GL_TRIANGLES; glUseProgram (g_scene.objectShader->program); // 一度、シェーダーの色を設定する GLint objectColorLoc = glGetUniformLocation (g_scene.objectShader->program, "objectColor" ); glUniform3f (objectColorLoc, 255.f / 255.99f , 174.f / 255.99f , 82.f / 255.99f ); GL_CHECK_ERROR (); // すべての構造体の初期値を設定する関数を呼び出す InitScene (&g_scene); InitCam (&g_scene.camera); InitMouse (&g_scene.mouse); // Stanford Bunny メッシュを読み込む // loadObj関数はメッシュのVAO、VBO、EBO、バッファを初期化する // GPU上に頂点とインデックスのデータを保存する領域を確保している mesh_t *bunnyMesh = loadObj ( "bunny_vn.obj" ); float S = 1.f ; bunnyMesh->S = HMM_Scale ( HMM_Vec3 (S, S, S)); bunnyMesh->R = HMM_Rotate ( 0.f , HMM_Vec3 ( 1 , 0 , 0 )); bunnyMesh->T = HMM_Translate ( HMM_Vec3 ( 0 , 0 , 0 )); bunnyMesh->shader = g_scene.objectShader; g_scene.ready = 1 ; g_scene.animatingIntroFade = 1 ; } loadObj 関数の内容は以下のようになります。 // ztr_platform_independent_layer.cc static mesh_t * loadObj ( const char *fileName) { // （省略した）tinyobj_parse_obj で頂点データを読み込む // ... // ... // ... // VAO、VBO、EBO、を初期化する glGenVertexArrays ( 1 , &mesh->VAO); glGenBuffers ( 1 , &mesh->VBO); glGenBuffers ( 1 , &mesh->EBO); // VAOを紐づけるとVBOとEBOを設定できる glBindVertexArray (mesh->VAO); // VBOバッファーメッシュの頂点を割り当てる glBindBuffer (GL_ARRAY_BUFFER, mesh->VBO); glBufferData (GL_ARRAY_BUFFER, mesh->verticesCount* sizeof (vertex_t), mesh->vertices, GL_STATIC_DRAW); // EBOバッファーメッシュのインデックスを割り当てる glBindBuffer (GL_ELEMENT_ARRAY_BUFFER, mesh->EBO); glBufferData (GL_ELEMENT_ARRAY_BUFFER, mesh->indicesCount* sizeof (GLushort), mesh->indices, GL_STATIC_DRAW); // メモリ上の頂点構造体(vertex_t)のポジションの位置を指定する glEnableVertexAttribArray ( 0 ); glVertexAttribPointer ( 0 , 3 , GL_FLOAT, GL_FALSE, sizeof (vertex_t), (GLvoid *) offsetof (vertex_t, position)); // メモリ上の頂点構造体(vertex_t)のノーマルの位置を指定する glEnableVertexAttribArray ( 1 ); glVertexAttribPointer ( 1 , 3 , GL_FLOAT, GL_FALSE, sizeof (vertex_t), (GLvoid *) offsetof (vertex_t, normal)); // glBindVertexArray に0を指定するとVAOが解放される glBindVertexArray ( 0 ); } 各フレームごとに呼び出されている描画関数は以下のようになります。 // ztr_platform_independent_layer.cc ZTR_DRAW (ztrDraw) { // 白色で塗りつぶす glClearColor ( 1.f , 1.f , 1.f , 1.f ); glClear (GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); if (g_scene.ready) { camera_t *cam = &g_scene.camera; mouse_t *mouse = &g_scene.mouse; // （省略）タッチ操作の変化でカメラの位置を計算する // ... // ... // ... // 射影行列とビュー行列を作成する float ratio = ( float ) g_scene.screenDims.Y/( float ) g_scene.screenDims.X; float orth = cam->orthScale; hmm_mat4 proj = HMM_Orthographic (-orth, orth, -ratio*orth, ratio*orth, CAM_NEAR, CAM_FAR); hmm_mat4 view = HMM_LookAt (cam->pos, CAM_LOOKAT_CENTER, CAM_LOOKAT_UP); // 射影行列とビュー行列をシェーダープログラムに渡す for ( int i= 0 ; i<g_scene.shaderCount ; i++) { shader_t *shader = g_scene.shaders + i; glUseProgram (shader->program); GLuint viewMatrixLoc = glGetUniformLocation (shader->program, "view" ); glUniformMatrix4fv (viewMatrixLoc, 1 , GL_FALSE, &view.Elements[ 0 ][ 0 ]); GL_CHECK_ERROR (); GLuint projMatrixLoc = glGetUniformLocation (shader->program, "projection" ); glUniformMatrix4fv (projMatrixLoc, 1 , GL_FALSE, &proj.Elements[ 0 ][ 0 ]); GL_CHECK_ERROR (); } // メッシュの位置、回転情報をシェーダープログラムに渡す for ( int i= 0 ; i<g_scene.meshCount ; i++) { mesh_t *mesh = g_scene.meshes + i; shader_t *shader = mesh->shader; glUseProgram (shader->program); mesh->model = mesh->T*mesh->R*mesh->S; GLuint rotateMatrixLoc = glGetUniformLocation (shader->program, "rotate" ); glUniformMatrix4fv (rotateMatrixLoc, 1 , GL_FALSE, &mesh->R.Elements[ 0 ][ 0 ]); GLuint modelMatrixLoc = glGetUniformLocation (shader->program, "model" ); glUniformMatrix4fv (modelMatrixLoc, 1 , GL_FALSE, &mesh->model.Elements[ 0 ][ 0 ]); // VAOを紐づける glBindVertexArray (mesh->VAO); GL_CHECK_ERROR (); // シェーダープログラムを経由して、三角形を描く glDrawElements (shader->elementType, mesh->indicesCount, GL_UNSIGNED_SHORT, 0 ); GL_CHECK_ERROR (); glBindVertexArray ( 0 ); GL_CHECK_ERROR (); } // 懐中電灯の効果のためカメラの位置をシェーダープログラムに渡す glUseProgram (g_scene.objectShader->program); GL_CHECK_ERROR (); hmm_vec3 lightPos = HMM_Vec3 ( 1 , 1 , 2 ); GLint lightPosLoc = glGetUniformLocation (g_scene.objectShader->program, "lightPos" ); glUniform3f (lightPosLoc, lightPos[ 0 ], lightPos[ 1 ], lightPos[ 2 ]); GL_CHECK_ERROR (); } } ここではOpenGLについてほんの僅かしか説明しておらず、シェーダーすら紹介していません。3Dラスタグラフィックスの基本については、いくつかの分かりやすいチュートリアル等が存在しているので、そちらを参考にしてください。 もう1つ、解説しておかないと分かりづらい箇所があります。 glDrawElements() のようなOpenGL ES関数はどこから来ているのでしょうか？それらもプラットフォームに抽象化されるべきではないか、と思われる方もいるかもしれません。 厳密に言えば、そうすべきです。ただし、どちらのプラットフォームでも同じであり、パフォーマンスの面で考えると直接呼び出した方が楽です。たとえばAppleのMetalレンダリングAPIを使用する場合は、レンダラーの抽象化も必要となります。 まとめ ZOZOMATを発表してからしばらく時間が経ち、クロスプラットフォームの共有C++とOpenGL ESを使用したことは正解だと思いました。 サンプルプロジェクト のように統一感を保つことができ、設計要件を満たして、開発コストも節約できました。 しかし、クロスプラットフォームコードは決して万能なソリューションではありません。いくら利点があっても、すべてのプロジェクトで実装することが賢明であるとは限りません。3Dの表示方法が簡単な場合や、迅速にプロトタイプが必要な場合は、SceneKitやSceneformで十分だと思います。 プラットフォーム抽象化レイヤーに追加された関数は、プラットフォームでの実装コストが発生します。コストが高まると、収穫逓減点を超える可能性があります。 プロジェクトで複数のプラットフォームのサポートが必要で、コードの大部分を共有できることが明確である場合は、少し時間をかけてクロスプラットフォームソリューションを実装する価値があると思います。 ZOZOテクノロジーズでは、iOSエンジニアを募集しています。興味のある方はこちらからご応募ください！ corp.zozo.com

はじめに こんにちは。MSP技術推進部の松藤です。本記事では弊社が展開する マルチサイズプラットフォーム 事業（MSP）におけるデジタルトランスフォーメーション（DX）の取り組みについて紹介します。 目次 はじめに 目次 マルチサイズプラットフォーム（MSP）とは なぜDXが必要なのか MSP技術推進部の取り組み ケアラベル自動化 検寸データ連携 検品データ連携 進捗データ連携 自動検寸 おわりに マルチサイズプラットフォーム（MSP）とは 低身長や高身長の方も、サイズ選びに悩まず購入できるサービスです。ZOZOTOWN上の MSP対象商品 を選んで、身長と体重を設定すると、あなたに合ったアパレルのサイズをレコメンドします。これによって届いた商品を着てみたらモデルさんのイメージと違った、膝丈ワンピースのはずがロングになった、逆に短すぎてミニサイズになったなどのサイズにまつわるペインポイントの解消を目指しています。 もともとは弊社のプライベートブランドとしてZOZOSUITとセットで始めた事業でした。そこで培ったサイズに特化した服作りの経験をベースに現在はZOZOTOWNに出店いただいているブランド様と一緒に商品を企画・生産・販売させていただいております。 なぜDXが必要なのか ここから本題ですが、MSPにおけるアパレル生産になぜDXが必要なのか、という点です。MSPでは、下図のようにブランドや商社、生産工場、物の移動を担うフォワーダー、運送会社など複数の企業が携わってお客様の元へ商品をお届けしています。川の流れのように上から1つずつ工程を流していき、発生するリクエストや課題をクリアしながら、上から下へバトンをつないでいきます。 エンジニアのみなさんは、工程ごとに担当や企業が異なるウォーターフォールモデルの開発を想像してもらえればイメージが湧くかと思います。 ただ実際には上図のようにシンプルな川の流れではなく、下図のように製品ごとに別々の流れがあり、各工程のタイミングは異なるケースが多いです。連続したウォータフォールを抜け漏れなく、バトンをつないで1つの製品にする。そして川の流れの中で、発生するトラブルや変更に対処しながら川の流れを整える。なんとなくこの図でアパレル生産の複雑性が理解できるのではないでしょうか。 こういった複雑な工程の中で、すべてを完璧にこなすのは非常に難易度が高く、製品や関係者が増えることでコミュニケーションコストや重複作業が多く発生しているというのが現状でした。 そこでMSP事業では、数多くのDX施策を実行して作業コスト削減を進めています。たとえば製品ごとのデータ管理を個別のExcelからkintoneへ寄せて集中管理したり、業務フローをすべて書き出して標準化やマニュアル化を図ったり、進行状況をリアルタイムでわかるようにするなどです。 その中でも我々のMSP技術推進部がどんなDX施策をやっているかご紹介します。 MSP技術推進部の取り組み MSP技術推進部では、各アパレル生産のエキスパートがそれぞれ集中すべき業務に集中できるように大小含めてさまざまな仕組みの構築をしています。我々は主に生産ドメインに特化した形で、生産データの連携や書類の自動作成、データの可視化に取り組み、MSP事業をテック面で推進しています。 システムやツールはほぼフルスクラッチで開発をしていて、業務対応した柔軟なシステム構成を目指しています。テクニカルには、Go言語、Python、Kotlin、gRPC、OpenAPI、Docker、PostgreSQL、AWS、Alibaba Cloudが主なアセットです。 この先は過去行った施策をいくつか紹介します。 ケアラベル自動化 MSPの商品には統一規格のケアラベルが取り付けられています。 ケアラベルの特徴として、生地によって洗濯表記（画像上段）や生地の混率（画像中上段）が異なり、製品・生地毎に表示内容を変更しなければなりません。自動化する以前は、弊社デザイナーがPhotoshopを使って一種類ずつレイアウトする必要がありました。一種類を作成することは大きな作業ではないのですが、アパレルの生産サイクルの都合上、同じ時期に作業が集中するため、デザイナーの負荷が一気に上がる状態でした。これを解決すべく、ケアラベルの自動生成にトライしています。 これに関しては以前弊チームの @ikeponsu が会社のブログを書いてくれました。詳しくはブログをご参照ください。 techblog.zozo.com このブログから約1年で開発が進み、現在はkintoneのデータを拾って自動的にケアラベル用のデータを作成できる仕組みとなりました。これにより人が介在するのはケアラベルの表示内容を決定する工程のみとなり、より専門的な業務へフォーカスできるようになっています。 検寸データ連携 MSPの製品において、検寸は非常に重要な工程の1つです。とくに製品のサイズを売りにしている我々の製品は、通常のアパレル標準の基準よりも厳しい基準を工場にお願いしております。しかし検寸する側からすると、MSPの製品は展開サイズが多いことから、チェックするパターン数が多く、検寸作業に多くの時間を割いていました。その課題を解決するべく、Bluetooh搭載の電子メジャーとAndroidアプリを連結して、検寸作業の効率化を行っています。ケアラベルへ付属するQRコードにあらかじめ検寸が必要な箇所と仕上がりの基準値、合格基準を埋め込んでおくことによりQRコードでオペレーターへ指示内容を表示できるようになりました。 以前までは結果を紙に書いたり、結果と基準の目視確認が必要だったのですが、これによりオペレーターは指示された計測箇所を電子メジャーで計測するだけで入力と合否判定を自動で行えるようになりました。検寸でNGになった製品にはシールプリンターでシールを出力し、工場内で情報共有ができるようにしています。 検品データ連携 MSPでは製品に不良がないか出荷前に全量検品を行っています。しかし不良が出た場合の言語化が難しく、物理的な製品を扱うため現物を郵送したり、現地とのリアルタイムなやりとりで詳細を聞くなどでコミュニケーションに多くの時間を要していました。その課題を解決するべき、商品の状態を記録するAndroidアプリの開発を行っています。 使い方はシンプルでケアラベルへ付属するQRコードを読み取り、不良があればアプリ内で該当の不良を選択。その後不良箇所を選んで、状態がわかるようにスマホのカメラで撮影します。この作業で検品の記録ができる他、製品と不良の場所と状況がすべて紐づくためデータを見るだけで何が起きているのか判断しやすくなりました。 現場では、製品と登録したデータが紐づくようにシールプリンターで下図のようなシールを出力し、製品に貼っています。 この検品データ連携と検寸データ連携によって、下図のような不良報告のレポート作成も自動化ができるようになり、管理コストがぐっと下がりました。 進捗データ連携 工場での生産は各工程の中でもっとも長い時間をかける工程の1つです。とくにお客様から注文を受けてから1点ずつ生産をする受注生産においては、生産遅れが発生するとお客様と注文時に約束したお届け日でお届けできないリスクが生じます。そういったリスクを早期に発見するため、工場ではケアラベルへ付属するQRコードとAndroidアプリを使って個体ごとに進捗管理をしていただいています。 これによって正常に進行しているものと、遅延が発生しているものを瞬時に区別でき、遅延しているものに絞ってアクションができるようになりました。これまでは進捗確認を都度電話で行っていたため確認する側される側共に負荷になっていたのですが、遅延として上がってきたものだけを対処すればよくなり双方の負荷が少なくなっています。 自動検寸 上記で挙げた検寸データ連携の施策以前に、産業用カメラとZOZOSUITで培った画像処理技術を使って、メジャー不要な計測システムにもトライしています。ZOZOSUITで使っているようなマーカーを両手に持ち産業用カメラで撮影すると、マーカー間の距離を自動計算し結果と画像をサーバへ送信するソフトウェアとハードウェアの開発を行いました。 社内では画期的な仕組みだということで、すぐに取引先と試験導入が決まったのですが、結論からいくとこれは導入見送りになってしまいました。 大きな要因としては以下です。 設備導入コストが高すぎたこと 既存業務から大きく外れすぎたこと メジャーを使わずに計測する点やカメラを主軸にすることで、従来の計測スタイルと大きく異なった点が既存業務から大きく外れてしまいました。結果、我々の想定よりも生産性向上に寄与しなかったことで、設備導入コストと見合わなくなってしまったところが大きかったです。 ただし、ここで得た経験はのちのDX施策の考慮ポイントとして生きています。業務の親和性を考え電子メジャーを採用したり、導入・調達コストが低いAndroidを採用することで導入のしやすさが向上しました。とりわけDX施策においてはその分野のエキスパートとじっくり話をし、作業を紐解き、既存業務と親和性を考えた施策に落とし込むことが重要だと感じています。 今回の施策は見送りになってしまいましたが、自動検寸の確立はアパレル産業の夢なので引き続き追いかけていきます。 おわりに 本記事ではMSP技術推進部の取り組みについて紹介しました。上記の施策以外にもグレーディングの自動化を目指した研究やシステムフレンドリーなマーキング技術の開発、業務フロー内に存在する手作業のシステム化によってさらなる効率化を狙っています。1つ1つは派手な施策ではありませんが、小さな施策もコツコツ積み重ねることで知識のフレームワークになり、さらに積み重ねていくことでプラットフォームになります。MSP技術推進部では、各エキスパートのみなさんが集中すべき作業に集中し、よりよいものを作れるような全体最適なプラットフォーム作りを目指して開発を進めていきます。 ZOZOテクノロジーズでは、ZOZOTOWNやWEARのサービスをはじめ、事業を支えるさまざまな職種を募集しています。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com ※「QRコード」は、株式会社デンソーウェーブの登録商標です。

こんにちは、基幹システム部BASEチームの横山です。 突然ですが、ちょうど1年程前に行われた ZOZOバイト革命 は覚えていますでしょうか？物流倉庫「ZOZOBASE」で一緒に働いてくれる仲間の2000人募集や、基本時給のUP等で少しだけ話題になりましたね。 今回は、そんなZOZOBASEの人材を管理する上で一助となる作業実績の集計自動化について紹介します。 はじめに ZOZOTOWNは独自の物流倉庫を保有しており、ブランド様からの商品入荷や保管、お客様への発送まで独自のシステムを用いて行っています。 一口に入荷から発送までと書きましたが、その中には多種多様な作業があり、現場で働く多くの方々に支えられております。このような物流倉庫の戦略を考える上で実績管理や人材管理はとても重要になります。 そんな実績の集計ですが、少し前までは人手で行われていました。それを自動化する際、どのような要件で設計・開発を行ったか、データ収集・集計・可視化はどのように行ったかを紹介します。社内で実績集計の自動化を行う際のお役に立てれば幸いです。 開発要件 開発の目的 ZOZOBASEでは倉庫全体の目標管理や、各作業者への教育・指導に生産性や単価といった指標が用いられています。しかし、その算出はこれまでデータ収集から集計作業まで人手で行われてきました。それでは集計自体が大変であったり算出ミスの可能性などいくつも問題があるため、データ収集・集計・表示を自動で行うことを目的として開発が始まりました。 物流に関する処理は自社システムを用いていますが、これまでの積み重ねで肥大化したシステムに手を加えるとなると、その改修範囲は膨大なものになってしまいます。今回は運用開始までの時間をなるべく短縮するため、既存のシステムへの改修を最小限にする形で行いました。 実績の指標 先述の通り、ZOZOBASEにおける実績には、生産性と単価という2つの指標が用いられています。今回の開発においても上記2つの指標を可視化することを目的としています。生産性は単位時間あたりどのくらいの商品を処理できたか、単価は商品一品あたりにどれくらいの人件費がかかっていたかを表しています。 生産性　＝　処理量　/　作業時間 単価　＝　人件費　/　処理量 ZOZOBASE内の作業 ZOZOBASEで行われている作業ですが、細かく分けると全部で100種類程あります。全ては書ききれないので、今回は入荷に関する作業を3つご紹介します。 バーコード検品/入荷処理 データ連携をしているブランド様からお預かりした商品に欠品等がないか確認しながら、タグをスキャナーで読み取り、商品管理シールを張る作業 荷受け/社内納品書作成 データ連携をしていないブランド様からお預かりした荷物の納品書をもとに商品情報を打ち込んでいく作業 通常検品/検品 荷受けで作成された商品情報をもとに欠品等がないか確認しつつ、商品名や色・サイズを確認しながら対応する商品管理シールを張る作業 他にも、トラック対応や段ボールの運搬等、入荷に関する作業だけでもその種類は多岐に渡ります。入荷以外の作業については 求人ページ に記載があるので、是非ご覧ください。 実績表示の粒度 上記で紹介した作業を見ると、 バーコード検品は商品タグを読みこむだけで対応する商品管理シールが発行される 通常検品は商品名・色・サイズを確認して対応する管理シールを探さなくてはならない 荷受けの社内納品書作成は上記2つと全く異なった作業 といった具合に、作業によって一商品の処理にかかる時間が異なることを感じられると思います。 つまり、異なる作業の生産性や単価を一概に比較することはできません。そのため、各作業単位で実績を可視化する必要があります。しかしながら、先述の通りZOZOBASEで行われている作業は多岐に渡るため、全ての作業実績を順に見るわけにはいきません。そこで、各作業を以下の3つの粒度で表示を行うことにしました。 ブロック 発送や入荷等の物流機能を一口で表す単位 セクション ブロック内の作業を種類ごとにまとめた単位で、入荷ブロックにはバーコード検品、荷受け、通常検品の3つのセクションがある アクティビティ 実作業の単位で、通常検品セクションを例に挙げると、検品作業、シール出し作業、搬送作業等がある 個人の生産性 ZOZOBASEでは、各作業者への指導材料としても生産性の値を用いています。そのため、個人の生産性も算出する必要があります。単価については、時給の違いがダイレクトに表れてしまうため、個人単価の算出は行わずに生産性のみ算出します。 千葉県習志野拠点と茨城県つくば拠点 ZOZOBASEは千葉県習志野と、茨城県つくばの2か所に拠点を構えています。拠点毎に比較を行うことを考え、どこの拠点で行われた作業なのかといったデータも保持しておく必要があります。 作業者の雇用形態 ZOZOBASEで働く作業者には様々な雇用形態があり、雇用形態毎に時給が変わります。アルバイトからアルバイトリーダーへの昇進といったように雇用形態が変化することもあります。 集計のスパン 実績の集計は毎日行われるようにします。 データの準備 実績算出に必要なデータ ここまでの内容から、集計・可視化を行うにあたり必要なデータとその条件は以下のように考えられます。 必要なデータ 処理量 作業時間 人件費 条件 各作業毎のデータであること 人件費算出・個人生産性の算出を考え、作業者一人一人を識別できること 人件費算出のため雇用形態に関する情報も含むこと 集計は日毎に行うこと 処理量データの取得 ZOZOBASEで行われる作業は自社システムを用いて行っているため、そのデータの流れから作業者の処理量を取得します。作業によってはシステムを介さないものもありますが、その場合は他作業の処理量から類推したり、日の終わりに入力する欄を設けることで補います。 作業時間と人件費の取得 自社システムを用いて作業を行っているとはいえ、「ある作業者が何時にどの作業を始めて、何時には別の作業に移った」といったデータは持っていませんでした。 また、処理量データと同様に、システムを介さない作業の作業時間を取得する必要があります。 そこで打刻システムを作成し、始業や終業、他の作業に切り替えるタイミングで必ず打刻してもらうことで、各作業に従事している時間を個人毎に取得できるようにしました。このデータは日に1万件近く集まります。 打刻システムの導入 新たに作成した打刻システムですが、この打刻という行為に時間をとられてしまっては元も子もありません。そこで、作業者が用いるハンディで打刻できるようにしたり、入館証と個人を紐づけ入館証をタッチするだけで打刻できるようにしています。 人件費は打刻データから休憩時間等を考慮した後、各作業者の雇用形態に紐づく時給をかけることで求めることができます。 以上のことを踏まえて、打刻システムで収集するデータは以下のようにしました。 アクティビティID 作業者ID 作業開始時間 作業終了時間 拠点ID 雇用形態ID 集計 処理量のデータはシステムの至るところに散在しており、打刻データは毎日膨大な量が集まります。これらのデータを表示の都度集計していてはロードに時間がかかってしまうため、日毎・作業毎に集計を行い集計データのみを集めたテーブルに保持しておきます。 実績の可視化 実績推移と生データ 可視化に際して、まず月次や日別での実績の推移をグラフで確認できる画面の作成を行いました。 次に、実績の指標である生産性・単価やそれらを算出する元となる人件費・総作業時間を表示する画面を作成し、それぞれの機能において表示期間・拠点・表示粒度の切り替えが行えるようにしました。 利用例としては、実績推移を表示する画面で実績が落ち込んでいる箇所をブロック→セクション→アクティビティの順に確認し、実績が落ち込んでいるアクティビティを特定する。 特定したアクティビティの生データとその期間に行った施策等を照らし合わせ、今後の施策を考える等が想定されます。 ※画像はダミーデータを表示したもので実際の実績とは関係ありません 個人生産性の確認 個人の生産性については教育・指導に用いるため、必要なのはブロックやセクション等の単位ではなくアクティビティ単位の表示のみです。そのため、生産性の平均値や総処理量、総作業時間の月次推移と日毎の処理量・作業時間の表示を1つのページにまとめて表示しています。 ※画像はダミーデータを表示したもので実際の実績とは関係ありません 打刻状況の確認 打刻システムを導入したことで、副次的に、現在どのような人がどのような作業をどれくらいの時間行っているのかを確認する機能を実装できました。この機能を用いることで現場管理をリアルタイムで行うことができます。 運用開始後に出てきた問題点とその解決方法 ここまで開発を終え、いざ運用を開始したところ、打刻システムの利用に関する部分で以下の問題点が出てきました。 誤った打刻がされてしまう（異なる作業、異なる拠点等） 打刻自体を忘れられてしまう 作業時間や人件費を算出する上で打刻データは必ず正確でなくてはならないのですが、上記問題の影響で正確なデータを扱えない期間がありました。 作業者の視点で考えると、いきなり打刻システムが導入されてよくわからないうちに運用が始まるもんだから開発者側が意図しない動きももちろんしますよね。それに人間だから忘れることもあります。 これらを解決するためにいくつかの改良を行いました。 打刻システムをもっと使いやすく 運用開始した初期は、拠点や雇用形態等の情報を作業者に選択してもらい打刻する仕組みだったため、誤打刻が頻発していました。そこで、拠点に関する情報はIPアドレスやCookieなどを利用して半自動で選択がされるように、雇用形態についてはDBの作業者を管理するテーブルで一元管理し自動入力されるようにしました。 また作業の選択については、物流システム上のメニューと打刻されている作業の紐づけを行い、メニューと紐づく作業で打刻されていなかったら該当作業の打刻画面に遷移するようにしました。 本来だったら自動で打刻されるようにしたかったのですが、1つのメニューに複数の作業が紐づく場合が多かったため自動打刻は断念しました。 集計値の修正をできるように 集計された後でも打刻データと集計データの修正を行えるように以下のことを行いました。 打刻データに修正フラグを持たせる 修正フラグの有無を検知し該当部分のみ集計し直すバッチを作成し毎日夜間に実行する 修正対象の打刻データと関連のある打刻データ（同拠点、同アクティビティ、同雇用形態）に対して修正フラグを立て、夜間実行のバッチに処理させる形です。 勤怠管理システムとの同期 各アクティビティの正確な作業時間を測定するため打刻システムを導入しましたが、労務で管理している勤怠システムもあります。 労務使用の勤怠管理システムでは勤務の開始時間と終了時間のみ記録されていますが、給与計算に用いられるため、人件費を算出する上ではこちらの値を使用したほうが正しい値が出せます。 ただ、そのデータが正式に利用できる形になるまで数日かかっていたため、運用を開始した初期は勤怠管理システムの情報は使えないでいましたが、集計後のデータ修正を可能にしたため同期が可能になりました。 現在では毎日の打刻データの中で各作業者の最初の開始時間と最後の終了時間のみ、勤怠管理システムの打刻時間に修正することでより正確なデータを用いて集計を行っています。 おわりに ZOZOTOWNを物流の面で支えるZOZOBASEにおける実績集計の自動化について紹介しました。既存システムになるべく改修を加えない形で実績を自動集計する一例として考えていただければと思います。 大部分が手探りの状態での開発でしたが、ZOZOBASEで働く方々と意見を出し合いながら今の形になりました。 まだまだ改善の余地はありますが、人手で行われていた集計を自動化することによって、現場の方々の負担は大分取り除かれているようです。 このように、ZOZOテクノロジーズではBASEをはじめとした様々な事業部と常に連携し、お互いが意見を出し合いながら開発を行っています。 ZOZOのサービスに愛着を持ち、より良いものにしていきたいという意思のある仲間を募集していますのでご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

ZOZOテクノロジーズSRE部の市橋です。普段は主にAWSを用いて複数プロダクトのシステム構築、運用に携わっています。今回は2020年2月にリリースされたZOZOMATについて、システム構成と開発時に直面した課題、その課題を解決するために工夫した点について紹介します。 ZOZOMATではEKSやgRPCを新規に採用しており、これによって仕様の変更に強くなる、通信のオーバーヘッドを削減できるなど様々なメリットを享受できました。しかし導入時に一筋縄ではいかないことがあったため、今回苦戦した点についてご紹介できればと思います。 ZOZOMATとは お客様の足を3Dで計測するために開発された計測用マットです。ZOZOMATでの計測情報をもとに、靴の推奨サイズを参照するなどのサービスをご利用いただくことが可能です。ご興味のある方は こちら をご確認ください。 ZOZOMATのシステム構成 システムの全体構成は以下のようになります。今回は構成図内のユーザートラフィックを処理するNLB、EKS周りが話の中心となります。この後説明していきます。 ZOZOMATシステムはAWS上に構築しています。システム監視にはDatadogを利用しており、Slackにインテグレーションして通知を行っています。 クライアントはネイティブアプリケーション（ZOZOTOWNアプリ）、ZOZOTOWNサーバーの2つで、上記の構成図内の上部に位置するものが該当します。通信方式は前者がHTTP/2（gRPC）、後者がHTTP/1.1（REST）となっています。 それぞれの役割をまとめると以下のようになります。 ZOZOTOWNアプリでは計測した時の足の画像データを元に各部位の計測値と3Dモデリングのデータを生成し、ZOZOMATシステムのデータベースに保存します。ZOZOTOWNサーバーからは靴の推奨サイズを参照する際にリクエストされ、保存されている計測情報を元に推奨サイズを計算し、ユーザーに結果を表示します。 前述の通り、アプリケーション実行基盤としてAWSのフルマネージド型のKubernetesサービスであるEKSを採用しました。EKSのワーカーノードはワーカーノードタイプと起動タイプの組み合わせから選択できます。 table { border-collapse: collapse; width: auto; } th { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; text-align: left; } td { border: solid 1px #666666; color: #000000; background-color: #ffffff; text-align: left; } thead th { background-color: #FFFFFF; } ワーカーノードタイプ 起動タイプ 特徴 セルフマネージド型 EC2 EC2インスタンスを自前で作成、管理する必要がある。 AutoScalingグループを自前で設定、管理する必要がある。 EC2インスタンスをEKSクラスターに参加させるために満たさなければならない要件が多い。 マネージド型 EC2 EC2インスタンスを自前で管理する必要がある。 EC2インスタンスをEKSクラスターに参加させるための設定が省略できる。 AutoScalingグループを設定することなく、水平スケーリングが可能。 マネージド型 Fargate EC2インスタンスの管理が不要。 EC2がプロビジョニングされないため柔軟なキャパシティ管理が可能。 NLBは2020年5月時点で未サポート。 今回は管理コストを削減することを目的として、マネージド型ワーカーノード、EC2起動タイプを選択しました。インスタンス管理が不要になるメリットを享受したくFargateの利用も検討したのですが、NLBに対応していない点で今回のシステム要件を満たすことができないことから採用を見送りました。NLBが必要な理由については後述します。 EKS内のpodに着目すると以下のようになります。 前述の通り、ZOZOMATシステムではgRPCとREST、両方のリクエストを受け付けられる必要があります。そのため、EnvoyのgRPC-JSON transcoder機能により、REST形式のAPIリクエストをgRPCに変換する処理を行っています。 アプリケーションはユーザーリクエストを受け付け、計測結果の登録やS3の署名付きURLの発行等を担うものと、計測後に表示される足形診断や靴のサイズ推奨値を計算する機械学習系のものに大別されます。前者はScala、後者はPythonで書かれています。上記のアプリケーションはそれぞれリソース、スケール要件が異なるため、それぞれ別のノードグループに配置しています。metrics-serverやexternal-dnsなどAPI処理以外の用途のpodについても、他のpodと比べて必要リソースや可用性レベルが下がるため別のノードグループに配置しました。 直面した課題 ここまではZOZOMATのシステム構成について説明しました。ここからはこの構成で開発を進める中で直面した課題についてみていきます。 1. 秘密情報の取り扱いについて まず、秘密情報の取り扱いについてです。Kubernetesで秘密情報を扱う場合は、Secretリソースを利用します。公式からの抜粋となりますが、利用方法は以下のようになります。 $ echo -n ' 1f2d1e2e67df ' | base64 MWYyZDFlMmU2N2Rm apiVersion : v1 kind : Secret metadata : name : mysecret type : Opaque data : username : YWRtaW4= password : MWYyZDFlMmU2N2Rm 秘密情報として管理したい値をbase64エンコードしてマニフェストファイルに設定し、kubectl applyコマンドにより適用することで利用可能になります。しかし、この例は秘密情報をbase64エンコードしているだけでデコードも容易なため、このマニフェストファイルをGitHub等で構成管理してしまうと安全とは言えません。 この問題に対して、大きく2つの方法で対応しました。 1つは、initContainersを利用する方法です。この方法ではSecretを利用しません。initContainersは本来稼働させたいコンテナが起動する前に起動し、事前処理を行わせることができます。役割を全うしたらinitContainersはTerminateするため、余分なリソースを必要とすることなく運用できます。 以下は証明書情報をSecretsManagerから取得するときの例になります。 apiVersion : apps/v1 kind : Deployment metadata : labels : run : nginx name : nginx spec : replicas : 1 selector : matchLabels : run : nginx strategy : rollingUpdate : maxSurge : 1 maxUnavailable : 0 type : RollingUpdate template : metadata : labels : run : nginx spec : initContainers : - name : set-cert image : infrastructureascode/aws-cli command : [ "sh" , "-c" ] args : - | aws secretsmanager get-secret-value --secret-id ssl/certificate --region ap-northeast-1 --query "SecretString" --output text > /tmp/server.pem aws secretsmanager get-secret-value --secret-id ssl/privatekey --region ap-northeast-1 --query "SecretString" --output text > /tmp/server.key volumeMounts : - mountPath : /tmp/ name : cert containers : - image : nginx ports : - name : https containerPort : 443 name : nginx volumeMounts : - mountPath : /tmp/ name : cert volumes : - name : cert emptyDir : {} まず、initContainersからawscliを使ってSecretsManagerから証明書情報を取得し、マウントしたvolumeに保存します。その後、稼働させたいコンテナから証明書情報が保存されたvolumeをマウントすることで、証明書を利用することが可能になります。 もう1つの方法としては、GoDaddy社製の kubernetes-external-secrets というツールを使用する方法です。このツールを利用するとSecretsManager、またはSystemsManagerから値を取得し、その値をKubernetesのSecretリソースに格納できます。インストール方法は公式ページの記載の通り、以下のコマンドを実行してマニフェストファイルを取得し、kubectl applyによって適用することで利用可能になります。 $ git clone https://github.com/godaddy/kubernetes-external-secrets $ helm template -f charts/kubernetes-external-secrets/values.yaml --output-dir ./output_dir ./charts/kubernetes-external-secrets/ インストールが完了したら、任意の値をSecretsManagerから取り込むマニフェストを作成することで利用可能となります。以下にSecretsManagerからDBの接続情報を取得し、環境変数に設定する例を示します。前提としてSecretsManagerには以下のような形で格納されていることとします。 table { border-collapse: collapse; width: auto; } th { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } td { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } シークレット名 シークレット値（Key） シークレット値（Value） db/connect_info username hogehoge password fugafuga マニフェストのサンプルとしては以下のようになります。 apiVersion : kubernetes-client.io/v1 kind : ExternalSecret metadata : name : external-secret-db-info spec : backendType : secretsManager data : - key : db/connect_info property : username name : db-username - key : db/connect_info property : password name : db-password kubernetes-external-secretはkindに ExternalSecret を指定することで利用できます。今回はSecretsManagerを利用するので、backendTypeに secretsManager を指定します。 data の設定項目の意味はそれぞれ以下のようになります。 table { border-collapse: collapse; width: auto; } th { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } td { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } 設定項目 説明 key SectetsManagerから取得したいシークレット名を指定 property SectetsManagerから取得したいシークレット値のKeyを指定 name KubernetesのSecretとして設定する名前を指定 次にSecretを利用する側のマニフェストを以下に示します。ポイントとしては、 secretKeyRef のnameにはexternal-secretsで設定した .metadata.name （external-secret-db-info）、keyには .spec.data.name （db-username、またはdb-password）を指定します。 apiVersion : apps/v1 kind : Deployment metadata : name : api-deployment spec : replicas : 1 selector : matchLabels : app : api strategy : rollingUpdate : maxSurge : 1 maxUnavailable : 0 type : RollingUpdate template : metadata : labels : app : api spec : containers : - name : api image : api-sample imagePullPolicy : IfNotPresent env : - name : DB_USERNAME valueFrom : secretKeyRef : name : external-secret-db-info key : db-username - name : DB_PASSWORD valueFrom : secretKeyRef : name : external-secret-db-info key : db-password これらの方法を使うことで、安全に秘密情報を管理することが可能になります。 2. NLBがALPNに対応していない件について ZOZOMATシステムではgRPCを利用して通信しています。gRPCはHTTP/2を利用した通信となるため、ロードバランサーがHTTP/2に対応している、もしくはL4（TCP）ロードバランサーである必要があります。Application Load Balancerは、フロントエンド（リスナー）はHTTP/2に対応しているものの、バックエンド（ターゲット）はHTTP/1.1にしか対応していません。そのため、ロードバランサーの背後で稼働するgRPCアプリケーションにリクエストを転送できません。AWSで利用できるHTTP/2の通信に対応したロードバランサーはNetwork Load Balancer（以下、NLB）、Classic Load Balancer（以下、CLB）となります。CLBはEC2-Classicネットワーク内に構築されたシステムの場合に使う必要があるのですが、それ以外の場合は性能上の理由から採用する理由はないため、実質NLB一択となります。 しかし、NLBでTLS終端しようとした際、ALPN（Application-Layer Protocol Negotiation）に未対応である点が問題となりました。ALPNはTLSの拡張で、同じTCPまたはUDPポートで複数のアプリケーションプロトコルがサポートされている場合にTLSのコネクション内で使用されるプロトコルをネゴシエートするものです。HTTP/2でTLSを利用する場合はこのALPNが前提となっており、gRPCクライアントとNLB間で通信に失敗するという事象が発生しました。 この問題に対して、NLBのリスナーをTCPモードに設定し、NLB配下に置かれているEnvoyにTLS終端の役割を担わせることで対応しました。この方法を取る場合は、ACMが利用できないためSSL/TLS証明書を自前で購入、管理する必要があるという注意点があります。 まとめると以下のようになります。 本章の見出し、文中にNLBがALPNに対応していないと書いていますが、本記事の執筆中に対応したようです。ただし、現時点ではHTTP/2通信のTLS終端はできないようです。着実に対応が進んでいることは感じ取れるので、NLBでHTTP/2通信のTLS終端に対応する日を心待ちにしたいと思います。 Network Load Balancer now supports TLS ALPN Policies 3. 特定APIエンドポイントへのアクセス元IPアドレス制限について 次にアクセス元のIP制限についてみていきます。システム構成を見て頂くと分かる通り、ZOZOMATシステムではネイティブアプリケーションからの通信以外に、ZOZOTOWNサーバーとのAPI連携を行っています。ZOZOTOWNサーバーから実行されるAPIについてはアクセス元のIPアドレスを特定できるため、制限をかける必要があります。 よくある構成の例として、ALBを利用する場合はALBのセキュリティグループにアクセス元のIPアドレスのみ許可する設定を行うことで制限をかけることが可能です。しかし、今回はNLBを利用するためセキュリティグループを設定できません。今回の構成において、アクセス元のIP制限がかけられるネットワーク内のノードと、APIエンドポイント単位の制限の可否についてまとめると下記のようになります。 table { border-collapse: collapse; width: auto; } th { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } td { border: solid 1px #666666; color: #000000; background-color: #FFFFFF; } 構成ノード APIエンドポイント単位の制限可否 特徴 AWS Network ACL × ステートレスなため、戻りのトラフィックも考慮する必要がある。 通常、AWSを利用する上ではあまり意識しないNTP等もルールを追加する必要がある。 ワーカーノード セキュリティグループ × - Kubernetes NetworkPolicy × - Envoy HTTP filters ○ Lua拡張を利用することでAPIエンドポイント毎のIP制限を設定することが可能。 上記からAPIエンドポイント毎にIP制限をかけることができるEnvoyのHTTP Filtersの機構を利用しました。これを実現するには、EKSがクライアントのIPアドレスを取得できるようにする必要があります。まず、EnvoyのServiceリソースを記載しているマニフェストに externalTrafficPolicy: Local の設定をします。これを設定することでクライアントのIPアドレスをx-forwarded-forヘッダから取得することが可能になります。 マニフェストの例を以下に示します。 apiVersion : v1 kind : Service metadata : name : envoy annotations : service.beta.kubernetes.io/aws-load-balancer-type : "nlb" service.beta.kubernetes.io/aws-load-balancer-internal : "false" spec : type : LoadBalancer selector : app : envoy ports : - name : https protocol : TCP port : 443 targetPort : 443 externalTrafficPolicy : Local なお、この設定値はデフォルトだと cluster が設定されています。この設定の場合、ワーカーノードにリクエストが到達した後に別のワーカーノードにもリクエストを転送することが可能になり、podの負荷を均等に保つことができます。しかしこれを実現するために各ワーカーノード上で稼働するkube-proxyが送信元、送信先IPアドレスを書き換える必要があり、その結果クライアントのIPアドレスを取得できなくなります。 続いてEnvoyの設定をみていきます。以下のものがEnvoyのConfigMapになります。 apiVersion : v1 kind : ConfigMap metadata : name : envoy-conf data : envoy.yaml : | static_resources : listeners : - address : socket_address : address : 0.0.0.0 port_value : 443 filter_chains : - filters : - name : envoy.http_connection_manager config : access_log : - name : envoy.file_access_log config : path : "/dev/stdout" codec_type : AUTO stat_prefix : ingress_http use_remote_address : true route_config : name : local_route virtual_hosts : - name : http domains : - "*" routes : - name : api match : prefix : "/" route : cluster : api timeout : 60s retry_policy : retry_on : "connect-failure" num_retries : 3 http_filters : - name : envoy.lua typed_config : "@type" : type.googleapis.com/envoy.config.filter.http.lua.v2.Lua inline_code : | function envoy_on_request(request_handle) local request_path = request_handle:headers():get(":path") if string.match(request_path, "/hogehoge/%w" ) then local ip_whitelist = os.getenv('IP_WHITELIST') local source_ip = string.gsub(request_handle:headers():get("x-forwarded-for"), "%." , "%%." ) if not(string.match(ip_whitelist, source_ip)) then request_handle:respond({[":status"] = "404" }) end end end - name : envoy.router config : {} tls_context : common_tls_context : alpn_protocols : - "h2,http/1.1" tls_certificates : - certificate_chain : filename : "/tmp/server.pem" private_key : filename : "/tmp/server.key" clusters : - name : api connect_timeout : 5s type : STRICT_DNS dns_lookup_family : V4_ONLY lb_policy : ROUND_ROBIN drain_connections_on_host_removal : true http2_protocol_options : {} load_assignment : cluster_name : api endpoints : - lb_endpoints : - endpoint : address : socket_address : address : api-service.default.svc.cluster.local port_value : 8080 health_checks : timeout : 2s interval : 3s unhealthy_threshold : 2 healthy_threshold : 2 grpc_health_check : {} admin : access_log_path : "/dev/stdout" address : socket_address : address : 127.0.0.1 port_value : 8090 Envoy側でもクライアントのIPアドレスを扱うために use_remote_address: true を設定する必要があります。今回は特定エンドポイントに対してIP制限をかける必要があるのですが、Envoyに備わっている機能だけでは実現できないため、Luaを使って機能拡張する必要があります。以下がLua拡張の抜粋部分になります。 http_filters : - name : envoy.lua typed_config : "@type" : type.googleapis.com/envoy.config.filter.http.lua.v2.Lua inline_code : | function envoy_on_request(request_handle) local request_path = request_handle:headers():get(":path") if string.match(request_path, "/hogehoge/%w" ) then local ip_whitelist = os.getenv('IP_WHITELIST') local source_ip = string.gsub(request_handle:headers():get("x-forwarded-for"), "%." , "%%." ) if not(string.match(ip_whitelist, source_ip)) then request_handle:respond({[":status"] = "404" }) end end end ファンクションに envoy_on_request を指定することでリクエストを受け付けた際に任意の処理を実行できます。レスポンス時に処理させたい場合は envoy_on_response を指定します。処理の内容としてはヘッダからリクエストパスを取得し、任意のパスであればIPアドレスの検査を行います。IPアドレスがホワイトリストに含まれていなければEnvoyが404を返し、バックエンドへの転送は行われなくなります。上記の設定を行うことでエンドポイントごとのアクセス元のIPアドレス制限を設定できます。 まとめ 今回はZOZOMATシステムの構成と開発時に苦労した点を紹介しました。これからEKSの導入、またはAWS上でgRPC通信を考えている方に何か1つでも参考になる点があれば幸いです。リリースはできたもののまだまだ改善点はあるので、1つずつ改善してより良いサービスに成長させていきたいです。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。 https://tech.zozo.com/recruit/ tech.zozo.com

はじめに こんにちは、計測プラットフォーム部バックエンドチーム、テックリードの児島（ @cozima0210 ）です。この記事では、ZOZOSUITとZOZOMATの違いにより生じたバックエンド開発における課題と、その解決のためにCQRSアーキテクチャを採用した経緯、そしてその実践について紹介します。 ZOZOSUITとは ZOZOSUIT は、2017年に発表した全身の計測を目的としたツールです。現在も計測機能は提供されていますが、新規の販売は終了しています。現在、ZOZOSUITの計測データは、マルチサイズ商品の開発に活かされています。 ZOZOMATとは ZOZOMAT は、2019年に発表した足の計測を目的としたツールです。足の計測データから、足型診断や推奨サイズの提案に活用されています。今年の2月にリリースし、ZOZOSUITに続く計測技術として、とても注目をいただきました。 計測プラットフォーム部とは 計測プラットフォーム部は、これら計測技術の活用を通して、「計測データと推奨サイズの精度向上により、お客様にオンラインでも最高の購買体験を提供する」ことをミッションとしています。 バックエンドチームのミッション 計測プラットフォーム部の中で、私の所属するバックエンドチームは計測プラットフォーム基盤を支えるために、高速で安定したシステムづくりを目指しています。 バックエンドチームの技術戦略 Scala 私たちバックエンドチームは、プログラミング言語に、Scalaを採用しています。Scalaは強力な型システムに支えられた堅牢なシステム作りを容易にしてくれます。また、DDDとも相性が良く、ビジネスの変化に柔軟に対応するためのツールとして大きく貢献してくれます。 DDD DDDとは「Domain Driven Design」の頭字語で、Eric Evans氏が2003年に考案した設計手法です。日本国内でも「ドメイン駆動設計」として知られており、多くの開発チームに採用されています。この定義については様々な説明がありますが、「現実世界の問題に立ち向かうため、ソフトウェアによって対象の抽象化を図り、その解決を容易にすることを目指す」ための方法論であると理解しています。私たちバックエンドチームでも、このモチベーションからDDDを設計手法に採用しています。 ZOZOSUITからZOZOMATへ ZOZOMATのシステムアーキテクチャを検討し始めた時期は、2019年の4月頃でした。開発の初期段階で抱いた印象としては、計測フローに若干の違いはあるものの、ZOZOSUITのシステムからそれほど大きな変更は必要ないと感じました。しかし、設計を進めていく中で、その印象は次第に覆されました。まず始めに、ZOZOSUITとZOZOMATの比較を通して、システムを設計する上で考慮する必要のあった違いについて解説します。 計測フロー ZOZOSUITでは、ユーザーがカメラを固定した状態で、その前で時計回りに一周します。その間に、12回の撮影が自動で行われ、計測が完了します。一方、ZOZOMATではユーザー自身が左右の足それぞれ、6枚の画像を撮影します。 計測結果の表示画面 それぞれの計測フローを終えた後、ユーザーに計測結果の画面が表示されます。どちらにおいても、3Dの立体図が表示され、各計測値が表示されます。 ZOZOSUITによる計測結果の表示画面 ZOZOMATによる計測結果の表示画面 計測のデータモデル 詳細を割愛していますが、下図はZOZOSUITの計測データモデルです。 ZOZOSUITの計測データモデル 一方、ZOZOMATでは、計測値と3Dデータを左右に分けて、それぞれ管理するようになりました。 ZOZOMATの計測データモデル 計測におけるデータフロー ZOZOSUITでも、ZOZOMATでも、計測値と3Dデータはクライアントアプリで生成されます。ZOZOSUITでは、計測後にデータをサーバーにPOSTしますが、データがサーバーに送信されるタイミングは1回のみでした。一方、ZOZOMATでは左右の足それぞれの計測後にデータをサーバーにPOSTする必要がありました。そのため、データがサーバーに送信されるタイミングは必ず2回以上あります。これについては、一度にまとめることも考えられましたが、計測が失敗した場合の考慮が必要でした。計測が失敗した原因の調査には、その計測中のデータが必要でした。そのため、計測が失敗を繰り返した時に、一度に送信するデータ量が、とても大きくなる懸念がありました。これらの理由から、データ生成の都度、サーバーにデータを送信することとなりました。 計測データの状態管理 ZOZOSUITでは「計測完了」のみが状態として存在し、とてもシンプルでした。 ZOZOSUITの状態遷移 一方、ZOZOMATでは、以下の4つの状態管理が必要になりました。 ZOZOMATの状態遷移 ユビキタス言語 DDDでは、設計において対象を的確に表す命名が、特に重要であると考えられますが、その命名された用語のことをユビキタス言語と呼びます。ZOZOSUITでは、計測そのものを指す用語として、Measurementが採用されました。しかし、ZOZOMATでは全体の計測と左右の足それぞれの計測を分けて命名する必要がありました。そこで、全体の計測をSession、左右の足それぞれの計測をScanと命名することが採用されました。 その他の表示画面 ZOZOSUITでは、計測データを元にする画面として、計測結果の表示画面と推奨サイズの表示画面がありました。一方、ZOZOMATでもその2つの画面がありましたが、それに加え足型診断の表示画面が必要になりました。 推奨サイズの表示画面 足型診断の表示画面 ZOZOMATでの課題 これらの違いによって発生した課題を解説していきます。 計測データを単一のデータとして表現できなくなった ZOZOSUITの計測データは、メタデータに対し計測値と3Dデータを、一対一のデータとして表現できました。しかし、ZOZOMATでは1つのメタデータに対し左右それぞれの計測値と3Dデータで構成されるため、一対多の構造をとる必要がありました。これにより、参照系の処理時に結合が必要となり、多くのことを考慮する必要がありました。 データベースでの結合 データベースで結合を検討する場合、DynamoDBのようなNoSQLでは、そもそも結合のためのAPIは存在しません。また結合がサポートされているRDBMSであっても、データサイズが大きくなるに連れて、3つのテーブルを結合することはパフォーマンスを悪化させます。 アプリケーションでの結合 アプリケーションで結合を検討する場合、3つのクエリの発行が必要になります。これは単一のデータソースから単一の行を取る場合と比較して、参照系の処理を複雑にし、パフォーマンスも悪化させます。 データの状態管理が複雑になった ZOZOSUITでは、バックエンドが扱う状態として、「計測完了」があるのみでした。一方、ZOZOMATでは計測の開始時に左右の計測データの親データを生成し、「計測開始済」の状態に移ります。その後、子データとなる左右の計測データが生成され、それぞれの「計測完了」に状態が遷移します。そして最後に、計測データの検証が行われ、「全体の計測完了」に状態が移ります。このように管理する状態が増えたため、更新系の処理も複雑度を増しました。 ドメインの関心ごとが増えた ZOZOSUITでの主な関心ごとは、計測結果の表示と推奨サイズの表示でした。計測結果の表示は、計測値の入出力のみで対応可能でした。そして、推奨サイズの表示については、機械学習の推論サーバーへのAPIリクエストが必要でした。これはZOZOMATにおいても共通であり、この記事では詳細について取り上げません。一方、ZOZOMATではこれに加え、足型診断というコンテキスト、つまり新たな関心ごとが追加されました。これにより、さらにドメインモデルを柔軟に保つための検討が必要でした。 CQRSによる解決アプローチ CQRSとは CQRSは、「Command and Query Responsibility Segregation」の頭字語で、Greg Young氏が2010年に考案したデザインパターンです。源流には、Bertrand Meyer氏が1997年に提唱したCQS、「Command-Query Separation」という原則があります。これらは端的に説明すると、「更新系（Command）と参照系（Query）の分離」を勧める考え方です。 システム構成図 ZOZOSUITとZOZOMATの実際のシステム構成図です。 ZOZOSUITのシステム構成図 ZOZOMATのシステム構成図 参照系をシンプルに CQRSを採用することにより、参照系のための最適化ができました。具体的には、先述の状態管理にある「全体の計測完了」に遷移した計測データに対し、メタデータと計測が成功した左右の計測データを結合したリードモデルを構築します。これを実現するため、DynamoDB StreamsをトリガーにLambdaを起動させます。そして、その処理の中で「全体の計測完了」に状態遷移した計測データに対し、計測結果の表示画面用に最適化されたリードモデルをAuroraに永続化します。これにより、計測結果の画面表示に必要な処理から結合をなくし、1回のデータアクセスで処理を完結させることができました。 最適化されたリードモデル イベントソーシングパターン ZOZOSUITでは、単一の状態のみを扱うため、一度生成されたデータを、ユーザーアクションによって更新することはありませんでした。一方、ZOZOMATでは先述の通り、4つの状態管理が必要でした。この事情から、更新系のデータモデルにイベントソーシングパターンを採用しました。 イベントソーシングパターンとは イベントソーシングパターンは、一般的にCQRSパターンとともに採用されます。ドメインのイベントをジャーナルとしてスタックし、そのジャーナルの再生により現在の状態を取得するデザインパターンです。 状態管理に対する課題の解決 ZOZOSUITでは、リリース後に計測値の補正を行う処理が必要になったことがありました。この時、私たちは履歴を管理する独自の仕組みを実装しましたが、それはとても煩雑なものでした。一方、ZOZOMATでは計測フロー中の状態管理もありましたが、もし同様のデータ補正処理が必要になったとしても、履歴管理の保守性と追跡可能性が担保されるようになりました。代表的な履歴を遡るユースケースとしては、カスタマーサービスの問い合わせ対応やデータ分析による行動解析がありますが、備えとして欠かすことができないものであることは必至でした。 ドメインの関心ごとを分離 ZOZOMATで追加された足型診断の表示画面用データは、更新系のシナリオの中では、扱われる必要のないものでした。それは、計測値のデータから計算を要する導出項目であったためです。そのため、更新系の処理の中で、この計算結果を永続化することは、以下の懸念を発生させていました。 集中すべきコンテキスト（計測結果の保存）の処理に、別のコンテキスト（足型診断の計算）の処理が入り込み、アプリケーションコードが複雑になる 計測結果の保存のみが行われるべき処理に、足型診断の計算も加わることによって、レイテンシにインパクトを与える可能性がある 一方で、参照系の処理中に都度計算をさせることも、以下の懸念を発生させました。 参照系の処理をシンプルに保つことを難しくする 計算コストによるレイテンシ低下を招く これらを解決するために、Lambdaの処理するリードモデルに、以下のような足型診断の計算結果を含めることにしました。これによって、すべての懸念は解決されました。 より最適化されたリードモデル さらに、将来において、足型診断に新しい項目が追加されることを想像してみます。例として、ZOZOMATにより、外板母子の傾向分析が可能になるとします。こうした拡張を検討する場合でも、本来参照系の処理でしか必要のないデータにより、更新系の処理に改修を発生させることは望ましくありません。もちろん、DynamoDBのようなNoSQLを採用していれば、RDBMSのテーブルにカラムを追加するような懸念もないかもしれません。しかし、このような関心ごとの分離によってアプリケーションの保守性が向上する効果は、とても大きなものだと実感できました。 CQRSの実践、その後 ドメインモデルの洗練 ZOZOSUITでも、DDDによるアプリケーションコードの関心ごとの分離や、レイヤー化が意識されていました。しかし、ZOZOMATで採用したCQRSによる参照系と更新系の二極化は、ドメインモデルが参照系について意識することがなくなりました。そして、更新系のみに集中することで、より深いドメインモデルに洗練させることを可能にしました。 洗練されたドメインモデル 複雑さ システムの複雑さの観点で言えば、単一のデータストアのみを採用したアーキテクチャと比較した場合、複雑さは増したと思います。しかし、それぞれのデータストアに独立した耐障害性を獲得できたことを鑑みても、十分なトレードオフができたと思います。 メッセージングの管理 メッセージングについては、私たちが採用したDynamoDB Streamsとその周辺に用意されているエコシステムによって、多くのことが解決されます。DynamoDBへのデータ更新をトリガーにLambdaを起動し、参照系のためのリードモデルを永続化する。この一連の中で、キューの管理、エラーの管理、リトライの管理、こうした仕組みのすべてがマネージドなものとして提供されます。これらによって、私たちはメッセージングに関する多くの懸念から解放され、アプリケーションの開発に集中できています。 結果整合性の問題 一貫性に付随する課題に対し、私たちの今回のユースケースはとてもシンプルでした。それは、計測が完了した後で、参照系のデータに一切の変更が発生しないことに起因します。これは、参照系データが読まれるタイミングでの遅延さえ許容されれば、一貫性の問題は発生しないことを意味します。この観点において、結果整合性の問題によって、私たちを悩ますものはありませんでした。 将来の課題解決 参照系と更新系のAPI Count これは、参照系と更新系のエンドポイントから、それぞれの呼び出し回数の推移を表したグラフです。上の実線が参照系で、下の実線が更新系です。多くのWebサービスに共通した性質かもしれませんが、ピークタイムを比較した時に、10倍以上の差がつく状態でした。 将来的なZOZOMATのシステム構成図 現在、参照系と更新系のサーバーは同居させた構成をとっていますが、将来的にこの図のように独立した構成をとることにより、以下の課題解決をもたらしてくれると思っています。 スケールの分離 参照系と更新系が独立することにより、それぞれのアクセスパターンに応じたスケールの戦略が選択可能となります。これにより、より細やかな弾力性が獲得できます。 サイジングの分離 参照系と更新系が独立することにより、それぞれのワークロードに適したサイジングが可能になります。参照系と更新系で必要なシステムリソースが異なる場合、より適切なリソース配置が可能になります。 耐障害性の分離 参照系と更新系が独立することにより、それぞれが疎になる箇所を拡げられます。先述のような参照系と更新系のデータストアに依存する耐障害性のみならず、より独立した耐障害性を獲得できます。 さいごに 今回は、ZOZOMATのバックエンドで採用したCQRSアーキテクチャについて紹介しました。初めてCQRSに取り組む機会として、規模的に小さなマイクロサービスから始められたことは、とてもいい機会だったと思います。CQRSは、提唱から今年でちょうど10年目の節目を迎え、特別に新しいものではありません。一方、その採用のために、これまでは様々な技術的障壁があったように思います。しかし、現在のAWSをはじめとするマネージドサービスにより、CQRSを実践するための周辺環境は十分に整っているように思います。 計測プラットフォーム部は、社内のPoC要素の高い新規事業を扱うことが多い部署という事情があります。一般的に、アーキテクチャおよび技術の選定は、様々な事情（安定性、コスト、構築までのスピード等）を考慮する必要があると思います。しかし、私たちバックエンドチームは様々な技術の先行事例を社内のナレッジとして残すことを使命に、多くの技術的挑戦に取り組んでいます。 計測プラットフォーム部バックエンドチームでは、ZOZOMATでより精度の高いサイズを推奨するバックエンドエンジニアを募集しています。ご興味のある方は、以下のリンクからぜひご応募ください！ www.wantedly.com

※AMP表示の場合、数式が正しく表示されません。数式を確認する場合は 通常表示版 をご覧ください ZOZO Researchの斎藤です。私たちはファッションコーディネートの推薦や生成の基礎として、深層集合マッチングという技術を研究しています。本記事では、深層集合マッチングを理解する上で必要な諸概念の説明と、ファッションデータを使った実験結果について紹介します。対象読者としては、機械学習系のエンジニアや学生を想定しています。 集合マッチングとは ある集合が与えられたとき、その集合にもっともマッチする集合を解の候補から選ぶという問題を考えます。 例えば コーディネートを画像集合として捉えると 、あるコーディネートの一部分（部分コーデと呼びます）に対して合う部分コーデを選択するという問題設定を考えることができます。 図： ある部分コーデ（左）にマッチする部分コーデを候補（右）の中から1つ選ぶ このような問題を集合マッチングといいます。もちろん部分コーデではなく、後述するように複数のコーディネートを含めた集合を扱うことも可能です。 その他の応用例としても、ファッションとはまったく異なる分野で使えることが分かっており、例えば監視カメラ向けのタスクであるGroup Re-identificationと呼ばれる集団人物のマッチングにも適用できます（本記事では割愛します）。集合マッチングは将来性・拡張性の高いタスクといえそうです。 ここで、2つの部分コーデが合う（マッチする）かどうかを判定するには、部分コーデを構成するアイテム同士の調和性を調べることが重要になります。 しかし、どういったアイテム同士がどのようにマッチして結果的にコーディネートとして調和しているのかは、人間にとっても未知な場合が多いため、判別モデルや特徴量を人手で設計することは困難です。 そこで、強力な特徴学習（深層学習）の仕組みが必要になると考えられます。 また、集合は要素を入れ替えても不変なデータ構造であり、データの並べ方を考えなくてよいという性質を持っています。例えばコーディネートも同様に、アイテム同士を入れ替えても同じコーディネートです。 言い換えれば集合マッチングのタスクでは、このような集合データを取り扱うために、集合の性質を保つことができるモデルを構築しなければならないという難しさがあります。 コーディネートはもちろんのこと、集合を深層学習によってマッチさせる研究はこれまでにあまりなく、本記事ではこの技術を深層集合マッチングと呼びたいと思います。 部分コーデの教師データ作成 2つの部分コーデが合うかどうかを調べるモデルのパラメータを教師あり学習によって獲得することを考えます。どの部分コーデ同士がマッチするかをおおまかに人手でタグ付けすることは可能ですが、労力の問題から網羅的な教師データを用意できません。 そこで、 集合の再構成問題 を考えます。集合（部分コーデではなく完全なコーディネート）が与えられたとして、これを適当に2分割して共通部分のない部分集合（部分コーデ）を2つ作るとします。 図： コーディネートから対応する部分コーデを2つ作成 このときモデルを通して、同じ集合から作られた2つの部分集合（部分コーデ）を正しく選べるか？　を解くことにします。 もともと1つのコーディネートであったなら、そこから得られる部分コーデ同士は合うはずですから、そのペアを正例として扱います。 また、他のコーディネートを構成していた部分コーデ同士や、ランダムに選んだアイテムの集合は合わないと仮定して、そのような部分コーデの組み合わせは負例と考えることができます。 このようにして、アイテム同士がどのように合う／合わないかの情報は与えずに、部分コーデが“合う”という教師データを作ります。そして、アイテム同士が“合う”ときちんと認識することを通して、正しい部分コーデを選択できるモデルを特徴学習によって獲得することを狙います。 弊社では、IQONという日本の女性向けコーディネート投稿サービスを展開しておりましたので、こちらのデータを研究に用いました。 深層集合マッチング 深層集合マッチングは、特徴抽出レイヤーとマッチングレイヤーで構成されます。特徴抽出レイヤーをCross-Set Feature Transformation (CSeFT)、マッチングレイヤーをCross-Similarity (CS) 関数と呼びます。 例えば集合のペア が入力されたとき、マッチする度合いをCS(CSeFT( ))によって計算します。 特徴抽出してからマッチングスコアを計算するという順番でモデルが構成されます。 ここで、集合マッチングに必要なモデルの条件は、前述したように 集合内の要素を入れ替えても不変 2つの集合を入れ替えても不変 であることです。不変というのは、モデルの最終出力が変わらないということを意味します。後述するように、CSeFTとCS関数の合成関数はこの性質を満たすことが分かっています。 さらに、今回の集合マッチングでは異なる種類のアイテムを含む集合をマッチさせる必要があるため、元々まったく違う特徴ベクトル同士をマッチさせようとすることになりますから、簡単ではありません。マッチする集合同士ではよりマッチする特徴量を抽出し、そうでない場合はマッチしないと判定するに足る特徴量を抽出する必要があります。そのためには、何がマッチするかを集合間での相互作用（インタラクション）を通して抽出する枠組みが必要です。提案手法では、特徴抽出やマッチングの過程に集合間のインタラクションを導入して、表現力の高い特徴量を抽出できるようにしています。 特徴抽出 集合データといえども、その実体はコンピュータのハードウェア上では順番をもって格納されています。このデータの列を、集合の性質を保つように扱ったうえでインタラクションを考慮した特徴抽出をする必要があります。 特徴抽出器であるCross-Set Feature Transformation (CSeFT) レイヤーは、以下の式で構成されます。 ここで、 は 番目のCSeFTレイヤーの処理によって得られた特徴ベクトルの列として表現されます（集合 の要素の特徴ベクトルを適当に並べたもの）。 は各画像に対して独立に適用した畳み込みニューラルネットワークから得られる特徴ベクトルの集合を指します。CSeFTは関数 によって構成されており、 は学習パラメータで2つの の間でweight-sharingされています。なお、関数 は入力の第一引数の集合の要素の順番を保ったまま特徴抽出を行い、第二引数の集合の要素の順番には影響されないとします。これは第一引数に関しては置換同変、第二引数に関しては置換不変な性質を持っているといいます。この性質があれば、CSeFTは2つの集合内の要素に対して置換同変な関数となり、後述するように集合マッチングの条件を満たすことになります。 私たちは関数 として以下の類似特徴ベースの変換を提案しています。ここでは例として、 番目のCSeFTレイヤーから抽出された集合 の 個目の要素の特徴量 を に変換しています。 ここで、 、 は線形関数で 、 はReLU、 です。 類似特徴ベース変換によって、似ている特徴ベクトル同士は似るように、似ていない特徴ベクトルはそのままになるように特徴写像を行います。 さらに、 multihead と呼ばれる構造を用いて、複数パターンの関数 からの出力を用いることで、提案手法では精度を向上させています。 マッチング 前項で抽出した2つの特徴ベクトルの集合がマッチするかどうかを調べるために、本研究では以下のCross-Similarity (CS) 関数を用います。 ここでは、線形写像された2つの集合の各要素の間で非負の類似度の平均値を計算しています。さらにmultihead構造のように、CS関数の出力値を複数パターン計算してconcatenationしたのち、全結合層によって実数に変換して最終的なスコアとします。 なお、CSeFTは置換同変な関数、CS関数は置換不変な関数なので、それらの合成関数は集合内の要素について置換不変な性質を持ちます。また、集合を入れ替えても出力は不変です。これにより、集合マッチングの条件を満たすことが分かっています。 -Pair-Set損失 提案手法では集合のペアに対してスコアを計算しますが、個別のペアに対して別々に負例を用意すると、大きな計算コスト（前処理）がかかります。そこで計算量が大きくなる問題を解くために、 -Pair-Set損失を提案します。 -Pair-Set損失では、正例となる 個の集合ペア を用意して、それぞれの正例ペアに対してその他のペアから 個の負例を作成することを考えます。つまり、ある集合 に対してマッチする可能性のある 個の候補 を用意します。このとき真の解は で、他の候補は負例として考えます。この方法を用いることで、例えばTriplet損失よりも効率的に学習が可能になることが分かっています。 図： -Pair-Set損失を計算するペアの例 実験 ここでは例として冒頭に述べたようにコーディネートのマッチングを行います。 可視化 まず、提案手法で学習した結果をテストデータの集合を用いて可視化してみます。関数 は入力の集合ペアの各要素の間でインタラクションの重みを計算していることを利用します。具体的には、関数 に関する式の の部分は、集合 の 番目の要素に対する の要素 からの重みといえそうです。また同様に、集合 の要素への の要素からの重みも確認できます。この重みの値を正規化して可視化したものが下記の図です。 図： 正しい集合ペアに対するマッチング結果（インタラクション）の例 図： 誤った集合ペアに対するマッチング結果（インタラクション）の例 正しい集合ペアに関してはインタラクションの重みが多数得られており、誤った集合ペアに関してはスパースな結果になっていることが分かります。ここで、重みの値が0のときはインタラクションを示す矢印を表示していません。このようにインタラクションがスパースになると、最終的なマッチング度合いを示すスコアが低く現れる傾向になり、逆に強くインタラクションが複数得られるとスコアが高くなりうると考えられます。 定量評価 以降ではIQONのデータセットを用いて定量評価した結果を示します。提案手法を評価するタスクは (1) 部分コーデマッチングと (2) 複合コーデマッチングの2つです。 比較手法 比較手法としてSet TransformerとBERTを導入し、集合マッチング向けに拡張して用いることにします。 Set Transformer は近年提案されたstate-of-the-artの集合関数で、 BERT は言語タスクのstate-of-the-artです。Set Transformerの拡張では、集合ごとにSet Transformerによって特徴ベクトルを1つ抽出し、それらの内積を2つの集合のマッチ度合いとして定義します。BERTの拡張では、BERTの入力に2つの集合の和集合を用います。比較のためにBERTのpre-trainingは用いず、また個別のtoken embeddingは用いずに、segment embeddingのみ導入して内部的に2つの集合を区別します。Set Transformerの拡張では集合マッチングに必要な置換不変性は満たしますが、特徴抽出の過程で集合間のインタラクションは提供されません。BERTの拡張では集合間のインタラクションは提供されますが、置換不変ではないという性質があります。 表： 比較手法の特徴 手法 置換不変性 インタラクション Set Transformer   BERT   Cross-Affinity (ours)     (1) 部分コーデマッチング 冒頭で述べたように、1つのコーディネートを分割して正しい部分コーデのペアを作成します。このとき、正しくない部分コーデの候補をランダムに3つ用意したとき、提案手法は正しい部分コーデを選べるか？　を調べました。なお、負例のアイテムは正例のアイテムと同じカテゴリになるように制約を加えました（例えばトップスとボトムス）。この制約を実装するために、本実験ではTriplet損失を用いました。 図： 部分コーデマッチングの定量評価結果 Set Transformer、BERT、提案手法の精度はそれぞれ39.2、50.5、60.2％でした。この結果から、提案手法が大きく勝っていることが分かります。 (2) 複合コーデマッチング 複合コーデマッチングでは、より複雑なデータに対応できるか調べるために、ランダムに選んだ4つの部分コーデの和集合（複合コーデ）をマッチングします。ランダムに選ぶので、複合コーデは様々なファッションスタイルの乱雑な混合を表現しています。こちらでは -Pair-Set損失を用いました。 図： ランダムに選んだ複数のコーディネートから複合コーデを2つ作成 このような集合でもうまくマッチングできれば、どのように複合的な趣向を備えているユーザに対しても対応できるモデルが原理的には学習できると考えられます。実験結果は以下の通りです。 図： 複合コーデマッチングの定量評価結果 Set Transformer、BERT、提案手法の精度はそれぞれ65.3、66.1、75.9％でした。提案手法が大幅に勝っていることが分かります。部分コーデを使用した際よりも全体的に精度が高くなっているのは興味深く、色々な考察が可能です。例えば集合に含まれるアイテムの数がある程度多くなれば、より識別に効くアイテムを含む確率が高まるため、精度向上を期待できます。しかしながら、ノイズのようなアイテムも同時に増えるはずであり、一概にはいえません。今後より深い検討が必要と考えられます。 結論 深層集合マッチングを提案し、ファッションデータで実験を行いました。近接するタスクでのstate-of-the-artの手法と比較し、提案手法は大幅に精度が高いことが確認できました。また可視化を通して、コーディネートの部分同士が“合う”とは何なのかを、結果的にモデルが学習しているという示唆を得ました。今後、私たちはこのモデルを継続的に発展させていく予定です。 謝辞 本記事に含まれる研究は、和歌山大学の八谷大岳先生、筆者の博士課程での指導教員である統計数理研究所の福水健次先生、弊所の中村拓磨氏の協力のもと行われました。 さいごに 本記事の内容はGroup Re-identificationへの応用も含めてMIRU2020で発表する予定です。ご興味のある方は口頭発表（ショート）をチェックしていただき、ぜひディスカッションしましょう！ また、ZOZOテクノロジーズでは一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

はじめに こんにちは。SRE部BtoBチームの田村です。BtoBチームにてECサイトの購入テストや会員登録等のテストを行う際には、これまでSeleniumを利用して毎日LinuxのChrome環境にて実行しておりました。しかしながらフロントエンドが変更された場合に、ソースコードの調整をしたりサーバー保守対応も必要で、運用コストを割かれることもしばしばありました。テストにおける自動化やテスト品質の向上及び運用コストの削減を目的として、今回AutifyというE2E自動テストツールを導入しました。 BtoBチームのE2Eテスト BtoBチームのE2Eテストは、Seleniumを用いて会員登録や購入テストを毎日実行しており、Slackにテスト結果を通知しています。エラー時には、サーバーに入ってログ閲覧し問題ないかを確認していました。そして、新しいテストパターン追加の要望があった場合にはソースコードを追加する必要があり、1パターンあたりに数時間の工数が発生して大きな運用コストが割かれていました。 このように運用コストが割かれておりましたが、Autifyを調査してみるとダッシュボード上でエラー内容を即座に確認可能とのことでした。さらにはSelenium IDEのようなレコーディングをするだけでテストパターンが作成可能でソースコードの調整が不要となり、運用コスト削減を見込めたということもありAutifyを導入しました。 Autify 特徴 コードを書かずにテストシナリオを作成・修正可能 複数OSでテスト実行可能 特定シナリオの定期実行が可能 クラウドで実行されるため、実行環境として実機を用意する必要はない AIによりUI変化を検知するためソースコード調整が不要 BASIC認証設定も可能 チャットで気軽に問い合わせ可能 複数OSでテスト実行可能という点が素晴らしく、さらにAIによりUI変化を検知してメンテナンス工数を削減してくれるところも良い点です。困ったことがあればAutifyのダッシュボード上からチャットで気軽に問い合わせすることも可能です。 シナリオ作成手順 シナリオ作成開始 開始URLを指定すると新規ブラウザウィンドウが立ち上がり、シナリオ作成が開始されます。試しに、 Seleniumに準備されているテストサイト を用いてシナリオ作成を行ってみます。 レコーディング 自動でレコーデイングされるので、シナリオパターンに沿って操作します。イメージとしてはSelenium IDEのように、レコーディングされる感じです。 検証 検証したいテキスト等があれば、画面右下にあるAutifyツールのチェックボックスアイコンで設定できます。デベロッパーツールのインスペクトモードのように要素を選択可能で、要素によって検証項目が変動しますが、大枠は下記のようなチェックが可能でした。 タイトルチェック URLチェック テキストチェック 要素表示チェック オンオフチェック 存在チェック シナリオ編集画面 微調整したい箇所は編集可能となってます。入力テキストの内容などを変更することが可能です。また、特定の操作までローカルブラウザで自動実行し、新規操作を追加することも可能です。Selenium IDEの場合は、ファイル共有などする必要があったのですが、Autifyではダッシュボード上にて最新シナリオ状態を確認できる点が便利です。 シナリオ実行結果 ステップごとに前回との比較ができ、わかりやすくなってます。前回からの見た目の変更点をすぐに確認可能となっています。 マルチデバイスで実行可能 複数OSでテスト実行が可能となっています。 SameSiteデフォルト変更の影響確認に利用 Chrome 80のSameSiteデフォルト変更の対応を行う際に役立った実例を紹介します。 iOS 12におけるSafariの場合は、 WebKit Bugzilla (Bug 198181) に記載ある通り、SameSite=None指定はStrictと扱われてしまうので、特定条件のみSameSite指定を外す対応が必要でした。 影響を確認するために、AutifyにてiOS 12の端末を指定しテストすることで、修正の確認が即座にできました。通常であれば実機にて手動テストを実行していたところですが、Autify導入していたおかげで自動テストが可能でした。 まとめ 良かった点 複数プラットフォームにて即座にテスト可能 シナリオファイルを共有する必要がなく、ウェブで全て完結している 不明点、改善要望があれば、チャットですぐ問い合わせが可能 気になった点 細かい挙動の調整ができない 例えば、お届け予定日をコンボボックスで選択する場合、実行日によって動的にラベル内容が更新されるようなサイトの場合です。Autifyの場合は、ラベル名で選択しているので、レコーディング時に選択した日付が無くなった場合にエラーとなってしまいます。このような場合は、インデックス選択できれば解決できそうなので、現在は改善要望中です。 度々アップデートが行われており、改善されていくかと思います。 さいごに ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com

ZOZOテクノロジーズでVRやARといったXR領域の利活用を推進しているWEAR部の諸星（ @ikkou ）です。 弊社に限った話ではありませんがCOVID-19の影響により、今までのようなオンサイトでのイベントをなかなか実施し難い状況が続いています。 例えば先日の『#技術書典 頒布本「ZOZO TECH BOOK」解説会』は弊社として初のオンラインイベントとなりました。 techblog.zozo.com いわゆる「勉強会」系のイベントもそうですが、オフィス見学といった社内の雰囲気を知るために重要なイベントも同様に実施できない状況です。 そこで先日、これもまた弊社としては初の試みとなる『バーチャルオフィス見学会』を実施することにしました。 zozotech-inc.connpass.com 『バーチャルオフィス見学会』に先駆けて、clusterに『ZOZOテクノロジーズ バーチャルオフィス』を公開しています。 cluster.mu 私はこのバーチャルオフィス作りの技術・運用まわりで携わったので、本記事ではその背景を紹介します。 手段の選定 プラットフォームの選定 ワールド作り Cluster Creator Kitの導入 clusterに最適化したシェーダーへの変更 VRChat向けシステムの削除 歩き回ることを想定したコライダーの削除と追加 植物の削除 バーチャルならではの「遊び」 エントランスのZOZOMATと箱猫マックス 持ち上げられるZOZO箱 リアルアバターの利用 プラットフォーム選定の補足 VRChatを選択しなかった理由 Mozilla Hubsを選択しなかった理由 まとめ 最後に 手段の選定 バーチャルオフィス見学を実施するにあたり、まずどのような手段で実施するか検討しました。大別すると次の2つになります。 1つ目はフォトリアルな全天球（360度）の写真や動画を使った方法です。 例えば国立科学博物館による「 おうちで体験！かはくVR 」は全天球写真を用いたウォークスルー型のバーチャル展示です。Matterportという特殊なカメラを使用して撮影しています。 www.kahaku.go.jp 2つ目は3D CGを使った方法です。 例えば「 Grani VR Office Tour 」はレーザースキャンを用いて実際のオフィスと同等の空間を3D CGで再現したバーチャルオフィスツアーです。 grani.jp それぞれにPros/Consがあり、個別の詳細は省きますが、今回は後者の3D CGで再現する方法を採りました。 これはオフィスの全天球写真が存在せず、しかし撮影のため外出自粛が求められる期間中にオフィスへの移動を避けたかったこと、そして後述する3D CGのアセットが既に存在していたことが理由です。 プラットフォームの選定 手段が決まった後、『バーチャルオフィス見学会』を実施するプラットフォームを選定しました。 具体的にはVRChat, cluster, Mozilla Hubsの3つの候補に絞りました。その上で、今回はマルチプラットフォーム対応のバーチャルSNSである「cluster」に青山オフィスを模した空間を再現する形を採りました。 cluster.mu clusterは誰もが自由に使える公式のイベント会場の他に、ユーザー独自の会場を作れるワールド機能があります。 つい最近ではグループ会社でもあるヤフーの『オープンコラボレーションスペース「LODGE」』が『バーチャルLODGE』として一足早くclusterのワールドとして公開されました。 note.com 今回はこのワールド機能で「バーチャルオフィス」を作成することにしました。 ワールド作り プラットフォームとしてclusterを選択しましたがclusterが提供するのは好きなイベント会場を作り、そこに集まってイベントを開催することで、会場そのものは自分自身で作る必要があります。 幸いなことに弊社では2019年に実施した社員総会で、VRChatに最適化した「バーチャルオフィス」を作成していました。今回はこのワールドをcluster向けに修正する形で対応しました。 techblog.zozo.com 修正点は次の通りです。空間そのものは出来上がっていたので、大きく手を入れる必要はありませんでした。 Cluster Creator Kitの導入 公式SDKとして提供されているCluster Creator Kitを導入し、もともと存在していたスクリーンと差し替える形で Standard Main Screen View と新たにコメントを表示する Standard Comment Screen View その他、最低限必要なオブジェクトを追加しています。 github.com 難しいポイントはないので、ドキュメント通りに設定すれば問題ありません。 VRChat向けの「バーチャルオフィス」では、エントランスから入って直ぐ目の前にある円会議室の中にのみスクリーンが用意されていました。しかし、数十人が1度に参加する可能性があるオフィス見学という特性を考慮してcluster向けの「バーチャルオフィス」では円会議室を出たところにもスクリーンを設置しています。 あわせて円会議室内のスクリーンは見やすさを考慮して「現実世界」よりも数割大きめに設置しています。 clusterに最適化したシェーダーへの変更 clusterはWindows, Mac, Android, iOSというマルチプラットフォームで動作する性質上、そのすべてのプラットフォームで期待する動作を求めるためにはジオメトリシェーダーが使えません。 VRChat向けの「バーチャルオフィス」では、円会議室を構成するガラス部分をはじめとする複数箇所でNGとなるシェーダーが使われていました。 ガラスの表現には、モバイルプラットフォームでも使えるシェーダーを選択しました。このシェーダーは、UnityのAssetStoreで無料でダウンロードできるのですが、擬似的な屈折表現なども行える優れたものでした。金属やガラスなどに物体が反射する表現には、リフレクションプローブを使用しており、計算負荷を抑えてながら品質の向上を目指しました。 https://techblog.zozo.com/entry/compass2019ss より引用 見栄えはとても良いのですが、様々な環境からオフィス見学を実現できるよう、今回はUnity標準のStandardシェーダーに変更しました。 VRChat向けに設定されていたシェーダー Unity標準のStandardシェーダー Standardシェーダーでも特徴的なガラスの曲面は再現できています。 VRChat向けシステムの削除 VRChat向けの「バーチャルオフィス」は文字通りVRChatで動作させることを意図しているので、VRChat向けの機能がいくつか内包されていました。これらは不要なので削除しました。clusterのワールドは不要なアセットを削除した方がアップロードもプレイ時のダウンロードも早くなります。 歩き回ることを想定したコライダーの削除と追加 VRChat向けの「バーチャルオフィス」は前述の通り「社員総会」で利用することを意識していたこともあってか、オフィス内を歩き回る「オフィス見学」用途としては成り立たない箇所がいくつかありました。そういった箇所は透明な壁となるコライダーを削除あるいは追加しました。 植物の削除 現実世界の青山オフィスには実に100鉢以上の緑が生い茂っています。これらをバーチャル世界でそのまま再現すると、少し歩きにくく感じてしまいます。その対策として青山オフィスの雰囲気を損なわない範囲で植物を削除しました。 オンサイトでのオフィス見学が再開した際には、ぜひ「バーチャルオフィス」との差分をその目で確かめてもらいたいです。 バーチャルならではの「遊び」 せっかくの「バーチャル」なので、現実世界の「青山オフィス」とは異なるちょっとしたアイテムを用意しました。 エントランスのZOZOMATと箱猫マックス 乗っかったところで実際に足のサイズは測れませんが、エントランスの左側足元に「ZOZOMAT」を設置しました。また、同エントランス右側にはZOZOTOWNの公式キャラクターである「箱猫マックス」を設置しました。 左: ZOZOMAT 右: ZOZOTOWN公式キャラクター「箱猫マックス」 持ち上げられるZOZO箱 箱猫マックスの身体を流用してオフィス内の複数箇所に「ZOZO箱」を複数設置しました。ZOZOTOWNを利用したことがある方ならお馴染みのあの黒い段ボール箱です。 Reference: https://note.com/zoooom/n/n06d63160f4bb 単純に置いてあるだけでは面白みに欠けるので、持ち上げたり積み上げられるようにしました。 ZOZO箱を持ち上げている様子 これはCluster Creator Kitで用意されている Grabbable Item コンポーネントを使うだけで簡単に実装できます。あわせて必要な Item , RigidBody , Movable Item 各コンポーネントも一緒に設定されるので、別途必要になるのは Item コンポーネントの名前を変えて、コライダーを追加するだけです。 Grabbable Itemの設定 ちなみに本記事の公開時点ではアイテムのリスポーン（初期位置に戻る仕組み）が実装されていません。そのため、1度動かされた「ZOZO箱」を「掃除」する手間を省くために公開版のワールドには含まれていません。 リアルアバターの利用 clusterの世界での見た目となるアバターは、原則として全ユーザー共通のものが用意され、顔の部分のみアカウントにアイコンとして設定している画像が表示される仕組みになっています。 標準アバターは顔部分にアイコンに設定した画像が表示される それとは別に、VRMという国産のVR向け3Dアバターファイルフォーマットのアバターを用意することで、自分が使いたいアバターを使用できます。 vrm.dev 今回は一部の社員に限りますが、フルボディ3Dスキャンした身体をclusterに最適化したVRMデータとすることで、いわゆる「リアルアバター」としてオフィス見学の旗振り役を務めました。 仕様に沿ったVRM形式のリアルアバターを設定した様子 リアルアバターを制作する手法は色々とありますが、今回は奇しくも1月時点でリアルアバター株式会社さんに撮影してもらっていたデータを活用しています。 www.real-avatar.com clusterでのVRMアバターは32,000ポリゴン制限があるので、UnityのMesh Simplifyで手早くポリゴン数を削減しています。 プラットフォーム選定の補足 補足にはなりますが、冒頭のプラットフォーム選定で挙げたVRChatとMozilla Hubsを選択しなかった理由を記載します。 VRChatを選択しなかった理由 今回は国産のVR SNSであるclusterを選択しましたが、実はVR SNSは全世界で100以上存在しています。その中でも日本国内のVRが好きな方々の中で特に有名なのが「 VRChat 」です。 つい最近では株式会社ウィゴーさんや、株式会社三越伊勢丹ホールディングスさんが企業として参加したバーチャルマーケット4のプラットフォームもこのVRChatです。 www.wwdjapan.com 前述の通り既存の「バーチャルオフィス」はVRChat向けに作られていたので、このVRChatを使えばcluster向けの修正も必要ありませんでした。 しかし、VRChatは一定以上のスペックを持ったWindows PCを必要とすること、そしてプライベートなワールドは運営と事前にフレンド登録が必要なことから選択しませんでした。 弊社がVR領域を中心とした事業を展開しているのであれば、VRChatを選択することもやぶさかではありません。しかし、今回は幅広い職種・職域の方が「来社」できることを考慮し、スマートフォンを含むマルチプラットフォームに対応しているclusterを選択した形になります。 Mozilla Hubsを選択しなかった理由 「MoziLla Hubs」はアプリのインストールを必要とせず、ブラウザだけで体験できる、いわゆるWebXR技術を活用したプラットフォームです。私自身はXR領域の中でも特にWebXRを推しているので、この Mozilla Hubs もリリース当初から強く推しています。 Mozilla Hubsでは「 Spoke 」というウェブアプリケーションを通してclusterやVRChatのように自分独自のバーチャル空間を構築できます。 SpokeにはVRChat向けのアセットであるFBXファイルをそのまま持ち込めないので、UniGLTFでSpokeでも扱えるGLBファイルにエクスポートしたものをインポートする必要がありました。しかし、Spokeに持っていくだけであれば大きな手間はかかりませんでした。 Spokeで円会議室を設置した様子 clusterやVRChatと違い、Mozilla Hubsは専用アプリのインストールを必要とせず、Windows, Mac, Android, iOSのどれでも普段使っているブラウザから気軽にアクセスできます そんな良いこと尽くしのMozilla Hubsですが、求める「バーチャルオフィス」を再現するにはアセットの容量制限（推奨は12MBで上限は128MBのところGLBファイルの容量だけで600MB超え）が厳しく、今回は諦めました。 公開を見合わせたMozilla Hubs版のバーチャル青山オフィス 緑とデスクを取り除いた形で、オフィスそのものと特徴的な円会議室だけであれば再現できたので、何らの形で使える機会を伺っています。 まとめ バーチャルSNSであるclusterをプラットフォームとして、VRChat向けワールドを改変したcluster向けのワールドで、『バーチャルオフィス見学会』を実施するまでの取り組みを紹介しました。 今回はVRChat向けの素材が手元にあったため、アイデア出しから実施までのスパンを短くできました。もしも手元になかった場合はゼロイチで「バーチャルオフィス」を作る必要があったので、高い再現性を求める場合は相応の工数が発生していたはずです。 5月25日を以て全都道府県で緊急事態宣言は解除されましたが、いわゆるアフターコロナ/ウィズコロナの世界ではオンサイトではなくオンライン、バーチャルで物事を実施する機会が増えていくと考えています。そのような世界で、こういった形でバーチャルオフィスを作るという手段もあるということが伝わりますと幸いです。 最後に ZOZOテクノロジーズでは今後も「オンライン配信」や『バーチャルオフィス見学会』など今まで取り組んでいなかったことにも積極的に取り組んでいきます。 一緒にサービスを作り上げてくれる方だけではなく、エンジニアの技術力向上や外部発信に興味のある方も募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com また、再掲になりますが、6月9日の『バーチャルオフィス見学会』も受付中です！ zozotech-inc.connpass.com 現場からは以上です！

こんにちは、基幹システム部メンテナンスチームの矢野です。 今回は僕のチームで行っている毎日勉強会について書いていきたいと思います。 新しいインプットの機会創出 組織内の技術力のベースアップ施策 社内コミュニケーション このようなことを考えている方の参考になればと思います。 経緯 まず毎日勉強会というものが形作られた経緯ですが、チームまたは部署のために下記の3つの事柄の質を向上できないかとぼんやり頭の中で考えていたことがきっかけでした。 自部署のブランディング（必要とされる部署になる、自分たちの見解を持つ） 部署内コミュニケーション向上（朝礼など） 部署のメンバーがエンジニアとして渡り歩いていくための手助け（心理的安全性） まず1つ目は自部署のブランディングです。 ブランディングと書くとちょっとお高い感じに聞こえちゃいますが、要は社内で必要とされるよう部署の価値を上げていきたいということです。「ZOZOの基幹のことは基幹システム部に任せておけば大丈夫」という認識を社内に一層持ってもらいたい、そういった社内の信頼を上げるためにはどのようなことをしていけばいいか、どのような組織に成長させたいかを考えていました。 2つ目がコミュニケーションの向上です。 僕が所属しているメンテナンスチームは、2019年5月から発足した比較的新しいチームです。今まで別々のチームに所属していた4人が集まり、緊急施策で優先度が下がった案件やリファクタリングなどのビジネスにはかかわらないが、必要なシステム改修を行うチームとしてスタートしました。 全く別々のチームで業務を行っていたメンバーが集まったため、発足当初はコミュニケーションがうまく図れず4人で黙々と作業をこなす日々でした。チームリーダーとしては「これはもうちょっと雑談とかできるような雰囲気にしたほうがいいな」と感じ毎朝5分間の雑談タイムを始めました。ランダムでネタを提供してくれるアプリを使いながら毎日やっていたため、ネタには困りませんでした。しかし、3か月もするとマンネリ化してきますし、メンバーの距離も縮まってきたため朝の雑談タイムは一旦ストップしました。 でもこの朝の雑談タイムがきっかけで、チーム全員で何か1つのことをやるという時間は、別の形で続けていきたいなと思うようになりました。 朝礼は自分の中で永遠のテーマですね。マンネリ化しない有意義な朝礼。これが思いついたらまたテックブログ書きますね。 3つ目に部署のメンバーがエンジニアとして渡り歩いていくための手助けです。 ZOZOの基幹システムはすでに安定した環境が出来上がっているので技術的にはその環境内での改修が主になります。ビジネス部門や倉庫の要望を改修し形にしていきますがそうなるとどうしても業務だけでは新しい技術への接点が少なくなります。メンバーには、エンジニアとしての視野を少しずつでも広げていってもらいたい。そのためにはエンジニアとしてのアンテナの張り方や新しい技術に触れる機会をこちら側から提供できれば成長の支援になるのではないか。そんな思いもありました。自分たちは基幹システムを改修する人ではなく、あらゆる問題をシステムで解決する集団という風に意識を一段階アップできれば先に書いた他部署からの信頼にも寄与できるのではないかと思っています。 枠組み・やること では、上記のような考えを形にするにはどうすればいいんだろう？？ 3つの軸で考えてみました。 絶対やりたくないこと 期待すること 現状（現実） 絶対やりたくないこと まず1つ目の軸ですが、これらを達成する手段として絶対にやりたくないことを考えてみたところ2つありました。 強制はイヤだ 途中離脱はイヤだ 真っ先に思ったのは強制的に何かをやらせることだけは避けたいということです。自主性を重んじた枠組みを作ることがこの枠組み自体を最大限有意義に活用でき、活用していくことで得られる成長やコミュニケーションにおいて都合よく働くと思ったからです。 中学生の時の実体験として「ギターを弾けるようになりたい」と思ったその時のモチベーション・初期衝動がギターを弾けるようになった一番の理由だと確信しています。 このことからも自主的に何かをやりたいと思った時が一番吸収する時期であることは間違いないです。 またやるからには途中で離脱できるような環境は作りたくないと思いました。ただ「途中離脱できない環境を作る」と考えると「絶対やりたくないこと」で書いた強制力が顔を出してきそうだったので、途中でやめられないようにレールを敷くのではなく、途中でやめてしまう理由を排除していって結果的に途中離脱がなくなるようにするといったイメージで考えを組み立てていくようにしました。 期待すること 2つ目の軸でこの枠組みに期待することは3つありました。 新しい技術に対するハードルを下げておきたい チームをまたいだ交流の活性化につなげたい 書籍購入補助制度を有効活用したい 先に書いたように現状ZOZOの基幹システムの開発は一定の技術を覚えればあとはビジネス部門や倉庫と話を詰めて案件を進めて行くことができます。ですが、今後モダンな環境へとリプレースする時期が必ずやってきます。そうなったとき、いきなりメンバーに使ったことのない技術を使って開発しろとなるとそれこそ効率的な開発などできませんし、その技術を習得するまでに時間もかかってしまい最悪案件を進められない時間が出てくる可能性もあります。経緯のところで記載した自部署のブランディングも保てなくなるかもしれません。なので、まずは新しい技術に対するハードルを下げておけるようなものにしたいと考えました。 次はチームをまたいだ交流を盛んにしたいというものです。弊社では、チームが組織の一番小さい単位になります。このチームという単位で業務を遂行する場面がほとんどなのでチーム内の交流は自ずと図れるのですが、その1つ上の「部」という単位での交流もさらに活性化させられたらいいなと思いました。最終的には部という枠も取っ払って社内の誰もが交流できる場を提供できたら最高ですね。 最後は書籍購入補助制度の有効活用です。弊社には書籍購入補助制度というものがあります。これは購入した書籍をレビューして経費申請すれば全額を精算できる制度です。会社の経費で購入した書籍は絶対に無駄にしたくないので（自腹で買った本であれば自分の好きにすればいいですが、経費はみんなが頑張って稼いだお金ですから無駄にしたくないですね）買ったからには最大限有効活用できる方法を見出してこの制度をさらに有意義に使えないかと考えました。ともあれ書籍を最後まで読むって達成感得られますよね。 現状（現実） 3つ目の軸には現状（現実）と書きましたが、これは実際に行われている勉強会などスキルアップするための機会についての問題点を考えてみました。 社内勉強会などで自分の興味が有るものが開催されるとは限らない（実体験） 講師がいる勉強会はわかったつもりになって終わることも結構ある（実体験） スケジュール調整できずに参加しなくなるとそのまま離脱してしまう（実体験） 興味があってもなかなか勉強に着手できる時間がとれない（実体験） 本を買って一人で勉強しても最後まで続かない（実体験） 全部実体験です。 こう見るとやっぱり自主性って成長にとって最大の栄養素なんだなと思えてきます。自主性をうまく成長へのモチベーションに変えられるような枠組みが作れれば上記のような問題も解決できるのではと思いました。 そして、ここから導き出した1つの答えがこちらです。 「 勉強したい人には勉強する時間を毎日1時間与える 」 これにより前述した問題点や希望することの中で解決できることがいくつかあります。 問題点・期待すること 解決理由 強制はイヤだ 勉強したいと思った人が使える時間なので強制ではなく完全自主性 新しい技術に対するハードルを下げておきたい 新しい技術も含め興味のある分野を習得できる時間として使える 社内勉強会などはあるが、自分の興味が有るものが開催されるとは限らない 興味を持った段階でそれについて学習できる時間が得られる 興味があってもなかなか勉強に着手できる時間が取れなそう 上長と相談の上、業務調整ができれば時間も確保できそう、というか時間を確保するために調整するというメリハリがつけられそう ただ、これだけではこの時間に何をやればいいか迷いそうなのでもう少し決めごとを作りました。 追加で考慮したいこと 途中離脱はイヤだ 書籍購入補助制度を有効活用したい 講師がいる勉強会はわかったつもりになって終わることも結構ある スケジュール調整できずに参加しなくなるとそのまま離脱してしまう 本を買って一人で勉強しても最後まで続かない チームをまたいだ交流の活性化につなげたい この辺りを何とか枠組みに追加できないかと考え、出てきた答えがこちらです。 「１冊の本を興味のあるメンバーを募って最後までやる」 これで追加で考慮したいことがカバーできそうです。 問題点・期待すること 解決理由 途中離脱はイヤだ 一冊の本を最後までやりきるという枠組みを作ることにより途中離脱を無くします。（終わらせる期限をつけないことがポイント） 書籍購入補助制度を有効活用したい 書籍を一冊最後までやりきるということを枠組みとします。 講師がいる勉強会はわかったつもりになって終わることも結構ある 興味がある人が集まって同レベルで勉強していくことで全員に当事者意識が生まれる。 スケジュール調整できずに参加しなくなるとそのまま離脱してしまう あえて期限を設けないので離脱する要因が減ります（後述します） 本を買って一人で勉強しても最後まで続かない 複数人でやることで補いあいながら最後まで進められる（複数人いることで見えない抑止効果もあるかも） チームをまたいだ交流の活性化につなげたい 勉強したい本が見つかった人はこの本の内容に興味がある人を誘います。賛同者をチーム外からも集められるので交流の場が広がります。 できた！ 上記をまとめるとこんな枠組みが出来上がりました 勉強したい本が見つかった人は同じ興味を持った人を募り（最大4人）毎日1時間全員でその本を最後まで勉強する ここで補足です この枠組がなぜ「毎日」なのか、なぜ「4人」なのかというところです。（補足だけど重要なポイント） 参加型の勉強会を見てきて運営が難しそうなだと思ったところがあります。 問題点 理由 参加者の続けるモチベーション 回数を追うごとに参加者が減っていく 参加者の当事者意識 参加しているという事実だけでわかった気になってしまっている。（自分はこの手の人間です） 1回の欠席がフェードアウトのきっかけになる 講義を一度欠席するとだんだん内容がわからなくなり途中離脱を助長させる これって大勢を集めてやるからこそ生じる問題点ではないかと考えました。 講義の開催者側としては受講生は大勢いるので一人が休んだくらいでは講義を止められない。受講者側の心理としては大勢だと自分ひとりが休んだくらいでは講義は止まらない、最悪自分はついていけなくなるかもしれないが他の受講者に迷惑をかけることはないので欠席することへのハードルが下がる。一回休むと講義は進むので理解に遅れが生じ途中離脱へ・・・ この辺りは「毎日やる」「最大4人での開催」というルールを定めることでいい方向に持っていけそうでした。 なぜ毎日なのか まず前提としてこの枠組みは有休や急なミーティング等で参加できなくなるのはOKとしています。勉強会のことは気にせず有休をとったり緊急案件の対応してもらいたいです。一人が参加できなくなった場合はその日の会はスキップしますが翌日また全員が集まった日に続きをやればいいのです。毎日といっているのに矛盾していますが毎日参加者が全員集まれる日に開催するというラフな感じです。 スキップOKが前提なので例えば開催日を毎日ではなく週1回にすると次の会が次週になってしまいます。1週開くと進みが遅く途中離脱を助長させそうなので開催は基本毎日です。ここが「毎日」とした理由です。 このような枠組みなので前述しましたが期限は設けていません。誰も離脱することなく最後まで終わらせるため、できる日は毎日書籍が終わるまで全員参加で行うというルールです。 なぜ4人なのか 有休や急用での会のスキップを参加者に切り出しやすい最大人数は4人位と想定しています。講師なしで進めるので個人個人が当事者意識を持てる最大人数も4人と想定しています。みんなで協力しあえる最大人数も4人と想定しています。失敗しても恥ずかしくない最大人数も4人と想定しています。完全に感覚値なのですが皆さんも4人と5人では5人の方が上記のバランスが崩れそうな感じがしませんか？ こうして出来上がった毎日勉強会の仕組みを利用して僕たちメンテナンスチームでは現在3冊目の本を絶賛勉強中です。 コロナ禍で全員在宅勤務ですが毎日14時にテレビ会議をつないでDockerの勉強をしています。進め方は扱う書籍によって変わってくるので枠組みの中には入れていません。適宜集まったメンバーで進め方を考えて勉強していけばいいと思います。演習やハンズオンが多くある本であればみんなでやりながら全員が同じようにできるまで進めるでもいいですし読み進めるような書籍であれば章や区切りやすいところまで読み進めまとめでディスカッションという形式でもいいと思います。そこは自由です。 4人のうちだれか一人でも置いてけぼりにならないようにというところにだけ気を付けて理解が早い人はフォローして進めることが大事だと思います。 会社や組織によって毎日1時間の時間を割くということは調整が難しい場面も出てくるかもしれません。上長や周囲と相談し業務調整の上、毎日1時間の勉強時間が取れればなるべく毎日4人がそろった日にみんなの興味のある書籍を進めるという気軽な気持ちで始めてもらえるといいと思います。 まとめると 毎日勉強会を開催すると参加者全員が興味のある書籍を当事者意識をもって最後まで読み切ることができます。 これにより、参加者は勉強したことはもちろんコミュニケーションの向上などが得られます。管理者としてはメンバーの学習機会の創出ができます。 またこの枠組みは一冊の本を最後までやりきることを目的としていてそれを達成できるようにスキップOK、毎日やる、参加者は4人、期限を設けないなど手軽に始められるようにも考慮されているのでぜひ調整がついたら一回やってみてもらいたいです。 今後社内に広がって所々で自然発生的に行われる文化になれば最高だなと思っています。 いかにシームレスに始められそして参加者がドライブしやすいインプット支援の方法を考えたら、毎日勉強会という1つの方法にたどり着いたというお話でした。 あとがき 上記のことが全部ひとりでできちゃう人はもちろんたくさんいると思います。自分はHowToやメソッドを考えるプロではないので実体験などから自分だったらこうやればストレスなく始められるな、こうやれば途中で諦めることなく続けられるなという目線で組み立てていきました。 仕組みを作る上で、はみ出さずにゴールまで導きたいときにはレールを敷くのではなく、なぜはみ出すのかを考えその理由を1つずつ排除していくことで自ずとはみ出さずにゴールまで行きつくという考え方があることに気付けたのもいい経験になりました。 この毎日勉強会の枠組みもなるべくレールを敷かないようにしていますのでフレキシブルな対応に頼っているところは多々あります。ルールとして決めるところは決める、でもそれ以外のところは当事者同士でフレキシブルに対応という形が取れれば管理しなくても自発的に動いていく仕組みができていくのかなと思いました。 ZOZOテクノロジーズでは、一緒にサービスを作り上げてくれる仲間を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください！ tech.zozo.com