こんにちは。MA部の田島です。 弊社では開発ガイドラインというものを用いて、システムの品質を担保しています。今回私がテックリードを務めているということもあり、バッチアプリケーションを開発するためのガイドラインを作成しました。本記事では「開発ガイドライン」と「バッチ開発ガイドライン」を紹介します。 バッチアプリケーション開発に限定したTipsはまとまっているものが多くないため参考にしていただければと思います。 開発ガイドラインについての紹介 冒頭でも紹介した通り弊社では、開発ガイドラインというものを用いてシステムの品質を担保しています。バッチ開発ガイドラインを紹介する前に、まず開発ガイドラインを紹介します。 開発ガイドラインの種類 開発ガイドラインは現在、以下の種類が存在します。 共通 Android iOS Frontend Backend Infra API Batch DB(Datab

こんにちは、MA部MA開発1ブロックの齋藤（@kyoppii13）です。 ZOZOTOWNではユーザ行動に基づくキャンペーン配信を実施しています。この配信はリアルタイムマーケティングシステム（以降、RTM）と呼ばれるシステムによって実現しており、RTMでは配信トリガーや配信タイミングの最適化等にユーザの行動ログを利用しています。 この行動ログは、ユーザがZOZOTOWNのページへアクセスした際に、HTTPリクエストをRTMが直接受信する形で収集していました。しかし、RTMの既存のログ収集機能はシステム要件や運用などの課題を抱えていました。また、その一方で全社的にログを収集・蓄積する基盤も並行して運用されており、RTMはこのログ基盤を活用できていませんでした。そのため、RTMでもこの全社ログ収集基盤を利用することで既存の課題を解決しました。 本記事では、RTMにおける行動ログの活用方法と、全

はじめに こんにちは、MA部MA基盤ブロックの齋藤（@kyoppii13）です。 ZOZOTOWNではキャンペーンやセール情報などをメールマガジン（以下、メルマガ）で配信しています。そして、そのメルマガの最下部にバナーを掲載しています。従来のメルマガバナー運用方法は、スプレッドシートでバナー掲載スケジュールを管理し、DBに対して直接クエリを実行するという手作業による運用でした。この運用方法だと、人的なミスが発生しやすく、掲載されるバナーがイメージしづらいという問題がありました。そこで、バナー管理のためのCMSを開発し、既存配信システムへのデータ連携によって従来のバナー運用方法における問題点を解決しました。 メルマガバナー運用の移行は、急いでいたこと、開発メンバーが限られていることから開発工数を極力抑える必要がありました。そこで、本記事ではメルマガバナー運用の配信を限られた開発工数で、かつ安

はじめに こんにちは、EC基盤本部・MA部・MA基盤チームでマーケティングオートメーションのシステムを開発している長澤（@snagasawa_）です。この記事では、社内で運用しているLINEメッセージ配信基盤の課題を、アーキテクチャ改善によって解決した話をご紹介します。 当時、LINEメッセージ配信基盤では、配信処理を担っていたApp Engineで2つの課題を抱えていました。「メモリ不足による配信処理の中断」と「リクエストタイムアウト後の意図しない処理の継続」です。一時はスケールアップによるメモリ増強を検討しましたが、後者の課題を解決できないためアーキテクチャの変更に着手しました。 結果として、App Engineが担っていた処理をBigQuery・Cloud Storage・Dataflow Batch Jobに置き換えることにより、この2つの課題を解決しました。加えて、配信対象ユーザ

こんにちは、MA部でエンジニアをしている田島です。 以前に弊社の塩崎が「Amazon AuroraのデータをリアルタイムにGoogle BigQueryに連携してみた」という発表を行いました。 こちらの発表では、Amazon Aurora MySQLのデータをGoogle BigQueryへリアルタイムにデータ連携する方法を紹介しています。リアルタイムデータ連携を実現するために、Aurora MySQLをレプリケーションソースとしてGoogle Cloud SQLへレプリケーションします。そして、BigQueryのFederated Query機能を利用してリアルタイムにデータを参照できるようにしています。 本記事ではその中の、Aurora MySQLからCloud SQLへのレプリケーション部分にフォーカスします。Aurora MySQLがマネージドサービスだからこそ発生する大きな注意ポ

こんにちはSRE部の川津です。ZOZOTOWNにおけるログ収集基盤の開発を進めています。開発を進めていく中でCloud Pub/Subのリージョン間費用を削減できる部分が見つかりました。 今回、OSSであるfluent-plugin-gcloud-pubsub-customにコントリビュートした結果、Cloud Pub/Subのリージョン間費用を削減できました。その事例を、ログ収集基盤開発の経緯と実装要件を踏まえて紹介します。 目次 目次 ログ収集基盤の紹介 開発経緯 フロントエンドのログしか取得できない BigQuery ExportはSLAを担保されていない リアルタイムにログを保存できない 実装要件 ログ送信側の環境に依存しない共通の仕組みで実装する 転送されるログの量に応じてオートスケールする構成にする 送られてくるログをロストしない リアルタイムにログが保存される インフラ構成

こんにちは、SRE部の谷口（case-k）です。 本記事では、EC2 Image Builderを使いRedashの運用改善を行った事例をご紹介します。運用しているRedashについてご紹介し、その後、Redashの運用課題に対してEC2 Image Builderでどのように解決したかTipsも踏まえご紹介します。 余談ですが全国どこでも働けるようになったので沖縄に住めています(感謝！) https://press-tech.zozo.com/entry/20210118_zozotechpress-tech.zozo.com 目次 目次 運用しているRedashの紹介 役割 インフラ構成 クエリ実行の流れ EC2インスタンス起動時の処理 Redashの運用課題 EC2 Image Builderによる課題解決 EC2 Image Builderの紹介 各リソースのTips 事前準備 コ

こんにちは。SRE部MA基盤チームの川津です。 私たちのチームでは今年サービスを終了した「IQON」の10TBを超える大規模データをBigQueryからS3へ移行しました。本記事ではデータ移行を行った際に検討したこと、実際にどのようにデータ移行を行ったかを紹介します。 データ移行の経緯 IQONは2020年4月6日をもってサービスを終了しました。そのIQONではデータ分析にBigQueryを利用していましたが、Amazon Web Services(AWS)上にもIQONに関するリソースが存在します。そのため、IQONはGCPとAWSの2つのクラウドで運用していました。 しかし、サービス終了に伴いGCP・AWSどちらかにリソースを統一する必要が出てきました。統一する意図としては、終了したサービスが利用する取引先を減らし、請求対応などの事務的なコストを減らしたい意図がありました。そのためGC

こんにちは、SRE部MA基盤チームの谷口（case-k）です。私達のチームでは、データ連携基盤の開発・運用をしています。 データ基盤には大きく分けて2種類あり、日次でデータ連携してるものとリアルタイムにデータ連携しているものがあります。本記事ではリアルタイムデータ連携基盤についてご紹介します。 既存のデータ連携基盤の紹介 リアルタイムデータ連携基盤の紹介 なぜ必要なのか 活用事例の紹介 データ連携の仕組みと課題 リプレイス後のリアルタイムデータ連携基盤 SQL Serverの差分データの取り方を検討 アーキテクチャ概要と処理の流れ Fluentdのプラグインを使った差分データの取得 Dataflowでメッセージの重複を排除 Dataflowで動的にBigQueryの各テーブルに出力 Pub/Subのメッセージ管理 イベントログ収集基盤 個人情報の取り扱い ビルド・デプロイ戦略 監視 データ

作った経緯 AWS料金Botの機能 実装 気をつけるべき点 Lambdaのコードをアップロードする際の問題 Serverless Application Modelの採用 CloudFormationとServerless Application Modelの比較 まとめ 最後に こんにちは。今年の4月に新卒で入社し、SRE部MA基盤チームに配属された川津（@jon_ground）です。 MA基盤チームではMAで利用しているインフラの使用料金が把握できていない問題があります。そこで気軽に料金を確認できるようにAWSの料金をSlackに報告してくれるBotを作成しました。本記事では上記の問題を解決するため、Botを作成するまでに至った経緯や数ヶ月運用して得られたメリットについて紹介します。 作った経緯 MA基盤チームでは、MA関連のインフラをAWS上で構築しており、開発、ステージング、本番と

こんにちは！最近気になるニュースはスピノサウルスの尻尾の化石が発見されたこと1な、SRE部エンジニアの塩崎です。ZOZOテクノロジーズの前身となった会社の1つであるVASILYでは数多くのクローラーの開発・運用の担当をしてきました。 今回はその知見を生かして、クローラーを楽に運用するためのクラウドサービスを紹介します。 概要 データ解析を円滑に進めるためには、CSVやWeb APIなどの構造化されたデータが必要です。しかし全てのWebサイトにあるデータが構造化データを提供しているとは限りません。むしろ提供していないケースの方がはるかに多いです。そのため、Webクローラーを作成して構造化されていないWebページを解析し、構造化データを生成する必要があります。 しかし、Webクローラーの運用には数多くの「つらみ」があります。特に大量のWebページを1日1回などの頻度で定期的にクロールする際には

こんにちは。開発部データエンジニアの遠藤です。現在、私はデータ×テクノロジーでZOZOグループのマーケティングを支援するデータチームに所属して、データ処理基盤の運用などに従事しています。 本記事では、Lookerを用いて運用中のデータ集計基盤をきれいなデータをスマートに取り出せる基盤に改良した件について報告します。 データ集計基盤で燻っていた問題 1. クエリ管理の限界 2. 集計定義に対するデータの信憑性が謎 Lookerは何が良い？ ～データガバナンス機能～ LookML データディクショナリ Gitによるバージョン管理 データ集計基盤（改）の設定フロー データ集計基盤（改）でのデータマート更新 まとめ データ集計基盤で燻っていた問題 ZOZOでは、サービスに関するあらゆるデータをBigQueryに集約しています。BigQueryに集約した大量のデータからデータマートとして必要なデータ

こんにちは！ App EngineのスタンダードランタイムにRubyが追加されて喜んでいるバックエンドエンジニアのりほやん（高木）と、オレンジ色のチンアナゴは実はニシキアナゴという別種だったことに驚きを禁じ得ない塩ちゃん（塩崎）です。 4/9, 10, 11の期間で開催されたGoogle Cloud Next '19にZOZOテクノロジーズから高木と塩崎が参加しました! GCPの新しい機能や活用についての事例が多く紹介されました。 その中でも2人がカンファレンスで気になった技術を紹介します。 Cloud Run Cloud Runとは Cloud Runの特徴 実際に使ってみる 1. アプリケーションの準備 2. コンテナイメージをビルドする 3. Cloud Runにサービスを作成する App Engineとの違い サービスの比較 各サービスの概要 App Engine Cloud Ru

はじめまして。2019年1月に入社したSREスペシャリストのsonotsです。最近MLOpsチームのリーダーになりました。今回の記事はMLOpsの業務とは関係がないのですが、3月に弊社で実施した会社用GitHub個人アカウントの廃止について事例報告します。 TL;DR 会社用GitHubアカウントを作るべきか否か問題 会社用GitHubアカウントの利用で抱えた問題 1. OSS活動時にアカウントを切り替える必要があり面倒 2. GitHubの規約に準拠していない 会社用アカウントを廃止した場合にセキュリティをどのように担保するか GitHubのSAML single sign-on (SSO)機能について 会社用アカウントの廃止およびSSO有効化の実施 会社用GitHubアカウントを使い続ける場合 私用GitHubアカウントに切り替える場合 Botアカウントの場合 Outside Coll

はじめまして！ ZOZOテクノロジーズ開発部の平田（@TrsNium）と申します。 業務ではデータ基盤の開発・運用を行っています。 よろしくお願いいたします。 今回複数のツールが混在していたデータ基盤を「Digdag・Embulk」に統一したので、その取り組みを紹介します。 概要 弊社のデータ基盤は注文情報や顧客情報などをSQL Serverから取得しBigQueryに転送しています。 以前のデータ基盤では「Talend」と「Embulk・Digdag」でデータの収集と転送をしていました。 Talendは、タスクのスケジューリングとデータ転送を行うツールです。 Digdagはタスクのスケジューリングをするツールで、Embulkはデータを転送を実行するツールです。 「Talend」と「Digdag・Embulk」は別々のチームが管理・運用をしており、運用負荷が高いという問題がありました。 そ

こんにちは、サーバーサイドエンジニアの竹若です。今回GraphQLにおけるエラーハンドリングを調査、Ruby on Railsとgraphql-rubyを使って実装する機会があったので、そこで得られた知見を共有させていただきたいと思います。(なお今回の実装はプロダクション環境には出ていません) GraphQLの仕様とプラクティス それではまず初めに、GraphQLが仕様に定めているレスポンスの返し方を見ていきましょう。 レスポンスのフォーマットに関するプラクティス GraphQLのプラクティスの1つに、レスポンスのhttp statusを200で統一し、レスポンスのerrorsキーにエラーの詳細な情報を持たせるというものがあります。 なぜならGraphQLではリクエストに複数のクエリを含めることができるからです。 https://www.graph.cool/docs/faq/api-ee

こんにちは。ZOZOテクノロジーズ開発部の田島です。 今時のシステム開発ではさまざまなツールを利用することが当たり前になっています。 そして各種ツールは日々新しいものが開発され、今まで当たり前だったものがレガシーなツールと呼ばれることも珍しくありません。 弊社では、GitHubやCircleCI・Slackなど様々なツールを利用しています。 私達のチームでもこれらのツールを利用していますが、それ以外にもGitBucketやJenkins・Redmineを独自で管理し利用していました。 今回ある理由からそれらのツールをSaaSへ移行しました。その経緯と移行手順を紹介します。 概要 開発支援サーバの紹介 利用しているGitBucket・Jenkins・Redmineは開発支援サーバと呼ばれる一台のEC2インスタンスの上で動作していました。 やったこと これらのツールを以下の図のように、「Git

こんにちは！ ZOZOテクノロジーズ開発部の塩崎です。 この記事ではCloudFormationにDBのマスタパスワードなどの秘密情報を渡す3つの方法を説明いたします。 前提 我々のチームではAWSインフラリソースのプロビジョニングにCloudFormationを使用しています。 CloudFormationのテンプレートファイルはGitHubでバージョン管理されており、スタックに対するチェンジセットの作成をCircleCIから行っています。 このあたりの詳細は以下の記事に書かれているため、詳細はそちらをごらんください。 techblog.zozo.com 課題 このような方法でCloudFormationテンプレートを管理していましたが、それに伴う課題が生まれました。 DBのマスタパスワードなどの情報をどのようにして渡すかということです。 テンプレート内で使用するためのパラメーターは以下

こんにちは、ZOZOテクノロジーズ VPoEの今村(@kyuns)です。 この記事はZOZOテクノロジーズ Advent Calendar の25日目の記事になります。 今年の4月にスタートトゥデイテクノロジーズ（現ZOZOテクノロジーズ）が発足してから約8ヶ月が経ちました。新型ZOZOSUITやプライベートブランド「ZOZO」の発表など今年は色々と新しいチャレンジをしていた弊社ですが、外から見たときにエンジニア観点だとまだまだ謎めいている部分がたくさんあると思います。 ちょうど先日代表の前澤がツイートしたことでTwitter採用が話題になりましたが、反響も非常に大きく、多くの方にご応募いただき実際に何名かのエンジニアを採用することができました。 news.yahoo.co.jp この祭りでも非常に多くの質問をいただきましたが、このエントリではZOZOテクノロジーズが行っている事業やプロダ

こんにちは、サーバーサイドエンジニアの竹若です。11/13 ~ 11/15にかけてロサンゼルスで開催されたRubyConf2018にZOZOテクノロジーズから竹若・高木(@rllllho)・田島(@katsuyan121)の3人が参加しました。 今年のRubyConfは講演数60、参加者数840の大規模なカンファレンスでした。この記事では私たちが興味を持った講演をいくつか紹介させていただきます。 Opening Keynote Sweat the Small Stuff Being Good: An Introduction to Robo- and Machine Ethics Empowering Early-Career Developers Ethical Data Collection for Regular Developers The Ruby Developer's Com