この記事は Retty Advent Calendar 18日目の記事です。 昨日は@isaoekaさんの会社の行動規範浸透を図るため、メニューバーからいつでも確認できるアプリを作ったの話でした。 はじめまして、Rettyのデータ分析チームでマネージャーをやっている平野です。 Rettyのデータ分析チームは今年4月に立ち上げ現在9ヶ月目です。 この記事では立ち上げから9ヶ月でやってきた組織的取り組みについて中心に書きました。 今アドベントカレンダーではデータ分析の技術的取り組みついてを、一緒にデータ分析チームを立ち上げた@takegueが書いてますので、そちらも合わせて読んでいただけますと幸いです。 ベンチャー企業におけるDWH DevOps @ Retty - Retty Tech Blog Webサービスを支えるユーザログ基盤開発@Retty - Retty Tech Blog 目次
こんにちは。アプリケーション基盤チームの @ueokande です。 今日は、サイボウズの新しくなったログ基盤についてお話しします。 サイボウズのログ基盤の進化 リプレイス前のログ基盤 サイボウズのログ基盤はサービスの成長に合わせて、常に進化し続けてます。 そんななか2017年の夏に大きなリプレイス作業がありました。 サイボウズのサービスを支えるログ基盤 from Shin'ya Ueoka 以前のログ基盤は、ログを収集するホストがあり、各ホストからログを収集してました。 しかしログの転送システムが単一障害点であったり、スケーラビリティに欠けるのでサービスの成長に追いつかず、性能的にも限界に達してました。 また以前のログ基盤では、ログの解析がしにくく、ログはあるけどビジネスに役立てにくい状況でした。 そのため今後のサービスの成長や、より安定したログ基盤を運用できるように、ゼロから刷新するこ
API GatewayにPOSTで送ったリクエストを直接Kinesisに入れる方法について解説します。 「あるURLにPOSTメソッドでデータを送ると、Kinesisにそのデータが入れることが可能な仕組み」 を作ることができます。 Kinesisにデータを入れる以外にも、参照/削除もできます。 以下の作業はすべて、AWSのコンソール画面から行うことを想定しています。 目次 IAMでロールの作成 Kinesis Streamsの作成 API Gatewayの設定 確認 エラー集 参考 目次としては、以上となります。AWSの3つのサービスを使用します。 IAMでロールの作成 本システムでは、「API Gateway」で設定するロールを一つ用意する必要があります。 IAM上で「AmazonKinesisFullAccess」ポリシーをもったロールを作成すれば大丈夫です。 適当に、KinesisP
API の /streams リソースに対する HTTP GET メソッドを公開し、そのメソッドを Kinesis の ListStreams アクションと統合して、呼び出し元のアカウントでストリームを一覧表示します。 API の /streams/{stream-name} リソースに対する HTTP POST メソッドを公開し、そのメソッドを Kinesis の CreateStream アクションと統合して、呼び出し元のアカウントで指定したストリームを作成します。 API の /streams/{stream-name} リソースに対する HTTP GET メソッドを公開し、そのメソッドを Kinesis の DescribeStream アクションと統合して、呼び出し元のアカウントで指定したストリームを表示します。 API の /streams/{stream-name} リソース
Envoy, Nginx, Apache HTTP Structured Logs with Google Cloud Logging Google Cloud Logging provides several plugins that allows you to easily emit structured logs for common applications. For example, if you install the Stackdriver Logging agent, you can get logs using the following fluentd plugins This sample demonstrates two of these plugins (apache and nginx) and how to configure them to emit not
こんにちは。去年の今頃は Rust を書いていました。 インフラストラクチャー部データ基盤グループの id:koba789 です。 背景 クックパッドではデータ基盤の DBMS として Amazon Redshift を利用しています。 既存のデータ基盤について詳しいことは クックパッドのデータ活用基盤 - クックパッド開発者ブログ を参照してください。 今まで、ログは数時間に1度、定期実行ジョブで Redshift 内のテーブルにロードしていました。 ロードジョブの実行間隔が "数時間" と長めなのは、Redshift のトランザクションのコミットが遅いためです。 クックパッドでは数百ものログテーブルがあるため、仮に1分おきにすべてを取り込もうとすると秒間数回以上のコミットを行わなければなりません。 このような頻繁なコミットは Redshift 全体のパフォーマンスを悪化させてしまいます
※ Retty Advent Calendar 15日目の記事です おしながき はじめに ベンチャー企業とデータ活用 完璧さよりも早さを重視する Rettyにおける現状 DWHの開発で大切にしていること プロダクトとしてのUXを大事に プロダクトとしての変化を大事に 開発者として横断的な動きを大事に RettyにおけるDWHの開発プラクティス BigQueryを中心としたデータ基盤 アウトプットを最大化するためのダッシュボードツール スプレッドシートによるお手軽ダッシュボード データポータル (Datastudio) データソースのUX/DX データソースの集約化 As-is ではなく As-was 分析者も巻きこみDWHの品質改善を行っていく 技術スタックはSQLを中心とする 仮想テーブル (View) <-> 実テーブル による スキーマのPoC SQLによるView/データソースのユ
Amazon Web Services ブログ AWS Application Auto Scaling を使用した Amazon Kinesis Data Streams のスケーリング 先日、AWS は AWS Application Auto Scaling の新機能を発表しました。Amazon Kinesis Data Stream に対してシャードを自動的に追加・削除するスケーリングポリシーを定義できる機能です。この機能の詳細については、Application Auto Scaling の GitHub リポジトリを参照してください。 ストリーミングの情報が増えると、あらゆるリクエストに対応するスケーリングソリューションが必要になります。逆にストリーミング情報が減る場合も、スケーリングを利用してコストを抑えなければなりません。現在、Amazon Kinesis Data Stre
こんにちは、最近気になっている哺乳類はオリンギートな、開発部の塩崎です。 私の所属しているMarketingAutomationチームではRealtimeMarketingシステムの開発運用を行っております。 このシステムはZOZOTOWNのユーザーに対してメールやLINEなどのコミュニケーションチャンネルを使い情報の配信を行うものです。 メルマガの配信数や開封数などの数値は自動的に集計され、BIツールであるRedashによってモニタリングされています。 このRedashは社内PCによってホスティングされていましたが、運用面で辛い部分が多々あったためパブリッククラウドに移行しました。 移行先のクラウドはawsを選択し、RedashをホスティングするためのサービスはECS/Fargateを選択しました。 この記事ではawsに構築した環境や、移行作業などを紹介します。 移行前のRedash 移
[Sun Sep 09 06:41:35.275151 2018] [:error] [pid 1517] [client 10.2.3.4:30626] script '/var/www/html/help.php' not found or unable to stat [Sun Sep 09 06:41:35.489685 2018] [:error] [pid 1517] [client 10.2.3.4:30626] script '/var/www/html/java.php' not found or unable to stat [Sun Sep 09 06:41:35.699245 2018] [:error] [pid 1517] [client 10.2.3.4:30626] script '/var/www/html/_query.php' not found or
こんにちは。メディアプロダクト開発部の我妻謙樹(id:kenju)です。 サーバーサイドエンジニアとして、広告配信システムの開発・運用を担当しています。 今回は、cookpad storeTV (以下略:storeTV )の広告商品における、リアルタイムログ集計基盤の紹介をします。 storeTV における広告開発 storeTV とは? storeTV は、スーパーで料理動画を流すサービスで、店頭に独自の Android 端末を設置し、その売り場に適したレシピ動画を再生するサービスです。 より詳しいサービス概要にについては、弊社メンバーの Cookpad TechConf 2018 における以下の発表スライドを御覧ください。 storeTV における広告商品の概要 storeTV では、imp 保証型の広告商品を提供予定です。imp 保証型の広告商品とは、例えば「週に N 回広告を表示す
はじめまして。アプリケーションエンジニアの中野です。 以前、MicroAdのデータ基盤の記事で紹介されていましたが、マイクロアドではデータ基盤刷新のタイミングでワークフロー管理ツールのDigdagを採用しました。 今回の記事では、Digdag採用の経緯やワークフローを作成する際に注意した点を紹介します。 Digdag採用の経緯 マイクロアドのDSP*1であるBLADEではBidRequestやImpression*2、Click、Conversion*3、その他BLADEから出力される様々なログやマイクロアドの他のプロダクトのログ、他社から提供されるデータなど、様々なデータを広告配信最適化の分析に活かしています。 これらのログを分析するバッチ処理は各々のジョブが複雑な依存関係を持っています。 これまではcronやJenkinsを用いてこれらの処理を行っていましたが コード管理が出来ていない
Google Kubernetes Engine (GKE) 上で稼動させている Java アプリケーションのログをいい感じに Stackdriver Logging で閲覧できるようにするメモです。 TL; DR REST API を直接叩くのはライブラリ由来のハングアップ問題に遭遇しかねないので避けた方がいいよ アプリケーションからのログは JSON フォーマットで出力するといいよ ログレベルを表すフィールドは "severity" の名前で出力しよう タイムスタンプは "timestampMillis" と "timestampNanos" をセットで出力しよう Spring Boot アプリケーションなら spring-cloud-gcp-starter-logging を使うのがいいよ はじめに GKE を利用してコンテナ化されたアプリケーションを稼動させていると、アプリケーショ
こんにちは、エンジニアの大迫です。 Kaizen Platformでは、以前からGoogle BigQueryを利用して、ウェブサイトの行動ログや広告の配信レポートなど様々なデータを保存・活用できるような仕組みを整え、お客様のウェブサイトや広告クリエイティブの改善に取り組んできました。特にここ最近では、非エンジニア向けにBigQueryやSQLの社内勉強会が行われたり、 @ikedayu によりProduction以外のメンバーでも気軽にデータ分析ができる仕組みが作られたりして全社的にBigQueryの利用が広がっています。 その一方で、データを活用できる人が増えた結果として、BigQueryのクエリ料金も増えていく傾向になっています。 せっかくエンジニア以外でも分析できる仕組みがあるのに、クエリコストが気になってクエリ書くのが怖くなってしまってはもったいないので、こちらの記事にあるように
はじめに 現在データ分析基盤の再構築を担当している、サーバーサイドエンジニアの小川詩織です。これまで私は4つのソーシャルゲームの新規開発・運用を経験してきました。そこでの知見と考察をまとめます。 ログデータは、調査などに必要なただの履歴という立場に置かれがちです。ですが、作業工数を大幅カットしたり、定量的な効果測定や判断ができるなど、適切なログ設計と活用により利益に繋がる施策の指針にすることも出来るものです。 ログには、コンテンツ内容により色々な種類や設計があるため、全てに共通する最適解はありません。ですが設計の指針となるべき事柄はあるので、ログの種類や活用例、設計の仕方、工夫などについて入門的な内容について一通り触れていきます。その中でログの可能性も一緒に感じていただきたいと考えています。 対象とするログと、全体像 今回はこれまでの経験が最活かせるソーシャルゲームのログのみを想定した内容
インフラストラクチャー部セキュリティグループの水谷(@m_mizutani)です。 クックパッドでは現在セキュリティ監視の高度化に取り組んでおり、その一環としてセキュリティ関連のログ収集およびその分析に力を入れています。ログ収集の部分では可用性などの観点からAWSのオブジェクトストレージサービスであるS3に一部のサービスやサーバのログをまず保存し、後から保存されたファイルを読み込んで分析などに利用しています。分析のためにS3に保存したファイルを前処理する方法としてAWS Glueなどを用いたバッチ処理がありますが、到着したログをなるべくストリームデータのように扱いたい場合もあります。特にセキュリティ関連のログでは以下のようなユースケースで利用しています。 アラートの検出: ログを検査してその中から危険度の高いと考えられるログを探し出し、アラートとして発報します。アラートの具体的な例としては
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く