トレタ開発者ブログ

飲食店向け予約/顧客台帳サービス「トレタ」、モバイルオーダー「トレタO/X」などを運営するトレタの開発メンバーによるブログです。

iOSDC 2017に参加してきました

iOSエンジニアの高です。

去年に引き続き、今年もiOSDCに参加してきました。

iosdc.jp

今回は前回以上に色んな所がパワーアップしていて、運営のみなさんの本気を感じました。 トレタとしてはゴールドスポンサーとしてスポンサードさせていただいています。 バッグの中にお風呂♨️のチラシがありましたよね。あれが弊社です。

またスポンサー読み上げをアークエンジェル艦長のマリューさんにして頂けるとはなんとも嬉しい限りです。
iOSDC Japan 2017 スポンサー紹介 - YouTube

弊社登壇メンバー

弊社からは増井と堀見が登壇しました。

増井はトレタ初のBluetoothデバイスの開発について。 堀見は誰もが悩むログ収集について登壇しました。

f:id:y_koh:20170917133256j:plain 初めて作るIoT機器とBLEの光と闇 | iOSDC Japan 2017

ここで話していた実際の製品はこちらになります。トレタフォン ボックスタイプ

f:id:y_koh:20170917162326j:plain サポート効率を上げるログ収集環境の構築 | iOSDC Japan 2017

気になったセッション

以下、個人的に気になったセッションをいくつか上げていきます。

Build high performance and maintainable UI library | iOSDC Japan 2017
パフォーマンスの話だけでなく、テストしやすいUIコンポーネントの書き方に至るまで幅広い内容でした。 iOSエンジニアであれば誰でも一度はViewControllerになんでもかんでも書いてしまうと思うのですが、テストしやすくするために、データの流れを一方向にして、状態をモデルに分離することが大切とのことです。

アプリエンジニアはどのように事業に貢献すべきか | iOSDC Japan 2017
Fablicのhuinさんの発表。発表を聞いていて非常にトレタと同じ悩みを持っているなと感じました。アプリエンジニアはアプリの使い勝手を良くしたり、ユーザーに喜んでもらえることを一番に考えることが多いと思います。ただ、それだけでは足りなくて、当然ビジネス的な観点も必要になってくるんですよね。

何を持ってユーザーが喜んでいると判断するのか、と質問してみたのですが、定性的にはアプリのレビュー等、直接聴こえてくる声を。定量的にはAnalyticsの結果を元に判断しているとのことでした。

Human Interface Guidelinesから滲み出る限界感を考える | iOSDC Japan 2017
Human Interface Guidelines(HIG)を守れと言うけれど、最近のAppleの標準アプリも守ってないのでは?というところから始まり、HIGとは何なのか。どこまで守ってどこからはみ出してもよいのか?という話でした。

HIGを狩野モデルを用いて解説しているのがとても印象的でした。

触り心地の良いInteractive Transitionをマスターしよう | iOSDC Japan 2017
さわり心地の良いアプリ。アプリエンジニアであれば誰もが目指すところですよね。このセッションではeasing curveに始まり、durationはどれくらいがベストなのかなど、具体的な数値を見せてくれているのがとても貴重でした。

iOSデバイス3,500台を管理する、東急ハンズのデバイス管理手法とは | iOSDC Japan 2017
普段聞く事の少ないMDMのお話。MDMというのは端末を管理するためのもので、管理側でアプリをインストールしたり、端末でできることを制御することが出来ます。普段聞けない話ということもあってとてもおもしろかったです。

業務アプリの切札、Programable Kiosk Mode大全 | iOSDC Japan 2017
こちらもなかなか聞く事の少ない話の1つですね。iPadにはSingle App Modeという1つのアプリしか立ち上げられないモードが有ります。KIOSKスタイルで専用端末や、店頭で展示する場合なんかに使われています。

クラッシュした時の話が面白くて、おそらくOSバグだと思うんですが、Single App Modeでクラッシュするとそのアプリだけでなく、他のアプリも一切起動できなくなるという恐ろしい現象が起きるそうです。一応ワークアラウンドも紹介されていましたが、完璧ではないそうです。

まとめ

今年のiOSDCもとても楽しめました。運営の皆さんには感謝しかありません。 どれも興味のあるセッションばかりで、直接見れなかったものに関してはこれからキャッチアップしていこうと思っています。

今年も素晴らしいiOSDCをありがとうございました。

トレタはRubyKaigi 2017に参加しています

サーバーサイドエンジニアの芹沢です。広島のホテルでこのエントリを書いています。

トレタはSilver SponsorとしてRuby Kaigi 2017にスポンサードしています。
また、トレタからは私を含むエンジニア3名とCTO増井が参加しております。

トレタはスポンサーブースは設置しておりませんが、増井が会場中を歩き回っておりますので、会場で見かけたらお気軽に話しかけてみてください。

f:id:serihiro:20170918102225j:plain

また、今回参加するエンジニア3名がそれぞれこのブログにて参加レポートを書く予定です。
そのレポートの中では、事前に決めた各自の担当セッションについて解説する予定です。こちらもご期待ください。

さきほど初日のセッションが全て終了しましたが、とても濃いセッションが多い1日でした。

ruby commiterであるnobuさんのruby開発生活を紹介するキーノートから始まり(nobuさんのトークはruby界隈では大変貴重です)、

  • RailsにおけるAPI開発のトレンドの移り変わりと最近の取り組み
  • productionで動作しているRails appを用いたベンチマーク環境の構築
  • opalでdruby対応した話
  • web application frameworkであるhanamiの紹介
  • pycallの紹介とデモ
  • 去年もすごく盛り上がったruby commiters vs worldのコーナー

という、以前から興味のあった話題が沢山聞けてとても楽しかったです。(英語トークもあってとても疲れましたが。。) 残り2日も楽しんでいきたいと思います。

f:id:serihiro:20170918184154j:plain

トレタにおけるBigQueryの活用法について

サーバーサイドエンジニアの芹沢です。

トレタは検索用のデータストアとしてBigQueryを使用しています。 奇抜な使い方はしていませんが、トレタにおけるBigQuery活用法を紹介します。

システム構成

BigQuery周りのシステム構成を1枚の図にまとめるとこんな感じです。珍しいものは使っていませんがその分安定した構成かと思います。

f:id:serihiro:20170530163636p:plain

BigQueryにimportしているデータ

大きく分けて以下2種類のデータをBigQueryにimportしています。

1.APIが参照しているRDBのデータ

APIが参照しているRDB(Amazon Aurora)のslaveからデータをimportしてデータ分析や調査用のデータ検索業務に使っています。

2.各種ログ

以下のログをfluentdでBigQueryに保存しています。

  • nginxのaccessログ
  • railsで1リクエスト単位で出力しているカスタムログ
  • sidekiqのログ(Sidekiq.loggerが出力するログ)
  • shoryukenのログ(Shoryuken.loggerが出力するログ)
  • sendgridのメール送信ログ

sendglidのログについては過去に佐野おにいさんが解説記事を書いていますのでこちらの記事を参照ください。

tech.toreta.in

データ可視化ツールとしての活用

社内向けのデータの可視化にはRedashを使い、用途別のDashboardを作成してセールス、カスタマーサポート、マーケティングチームが普段から追っている数値をエンジニアに頼らず検索できるようになっています。

また、BigQueryに入れたログをグラフで描画するなどのエンジニアリング方面でも使用しています。

f:id:serihiro:20170530161120p:plain

Redashの導入についてはaccountの権限管理など色々とハマりどころがあったようなのですが、その辺の話はRedash導入をリードしたサーバーサイドエンジニアの中村君がこのブログに書いてくれると思います。

データ集計基盤としての活用

最近トレタのRDBにたまったデータを活用する機運が高まり、データの集計や分析を行うようになりました。(今はどちらかと言えば集計と可視化がメインですが)

何かデータを使ってやりたいことがある時、試行錯誤段階ではRやPython + Jupyter Notebookで少量のデータを対象に前処理や集計をするのですが、それをproductionの全データに適用すると、処理時間がかかりすぎて丸1日かかってしまうといったケースが増えてきました。

そこで、複雑な集計処理や重たい処理はなるべくSQLに落とし込んでBigQueryで処理するようにすることで解決を図っています。

例えば、普通にコードで書くと全件ループせざるを得ず数十秒かかるような集計処理でも、WINDOW関数などを駆使してSQLに落としてこんでクエリを投げると、何事もなかったように数秒で結果が返ってきます。1回のクエリで処理できるデータのサイズに上限があるため、あらゆることが1回のクエリで解決する訳ではありませんが大抵は問題なく実行できています。
余談ですが、pythonのデータ分析ライブラリのpandasには、BigQueryにクエリを投げて結果をdataframeに変換して返す処理をread_gbqという関数一つで実現できるので大変便利です。

SQLに寄せる最適化を進めた結果、bqコマンドラインツールでクエリを投げて結果を別のテーブルにimportするだけで完了する処理も出てきました。BigQueryのUDFはまだ使っていないのですが、UDFも活用すればさらにscript less化が加速するのではないでしょうか。

なお、トレタではこういったデータエンジニアリングや、ビジネス方面のアナリティクスが得意なデータサイエンティストを募集しています。こちらもよろしくお願いします。

www.wantedly.com

ログ検索基盤としての活用

sidekiqとshoryukenのログ本文には、Workerの名前、ジョブのIDやステータス、実行したスレッドのIDなどが含まれています。これらの情報をキーとして利用しやすいにように、parseして構造化する必要があります。また、個人情報を出力することもあるため、マスキングも必須です。

これらの課題を解決するため、LogのFormatterを独自のものに置き換えて運用しています。現在は以下のようなjsonのformatでログを出力してBigQueryにimportしています。

{
   "datetime":1472553986,
   "hostname":"sidekiq-server",
   "pid":"17863",
   "tid":"owww1vp08",
   "severity":"INFO",
   "worker":"TestWorker",
   "jid":"JID-08102742edd82acc5b698f7e",
   "job_action":"done",
   "processing_time":10.000,
   "formatter_err":null,
   "message":"{\"class_name\":\"String\",\"body\":\"done\"}",
   "log_version":1
}

Sidekiq.loggerinfo , error 等のメソッドの引数に渡されたデータは messageというキーにjsonとして格納されるので、BigQueryのJSON関数を使ってカラムに展開した一時VIEWを作成し、そのVIEWに対してクエリを実行することでメッセージの本文で絞り込むことが可能です。

例えば、過去10日間のログの中からerrorという文字列がmessageに含まれるものを検索したい時は、こんな感じのSQLで取得できます。

#standardSQL
WITH
  MESSAGE_EXTRACTED AS(
  SELECT
    TIMESTAMP_SECONDS(datetime) AS UTC_DATETIME,
    worker,
    JSON_EXTRACT_SCALAR(message, '$.class_name') AS mesasge_class_name,
    JSON_EXTRACT_SCALAR(message, '$.body') AS message_body
  FROM
    `sidekiq_logs*`
  WHERE
    _TABLE_SUFFIX BETWEEN FORMAT_DATE("%Y%m%d", DATE_SUB(DATE(CURRENT_TIMESTAMP(), 'Asia/Tokyo'), INTERVAL 10 day))
    AND FORMAT_DATE("%Y%m%d", DATE(CURRENT_TIMESTAMP(), 'Asia/Tokyo')) )
SELECT
  *
FROM
  MESSAGE_EXTRACTED
WHERE
  message_body LIKE '%error%'
ORDER BY
  UTC_DATETIME DESC
LIMIT
  1000

まとめ

簡単ではありますがトレタにおけるBigQueryの活用方法について紹介させていただきました。
ビジネスにおけるデータ活用の重要度が日々高まる昨今、トレタもデータから得た知識を活用してビジネスを加速させていきたいと思います。

© Toreta, Inc.

Powered by Hatena Blog