dely engineering blog

料理レシピ動画アプリ『KURASHIRU』を運営する dely 株式会社のエンジニアブログです。

kurashiruの検索UX改善プロジェクト

こんにちは。
delyでISE(In-house System Engineer)をやっている@_skuwaです。
kurashiru[クラシル]のグロース、プロダクト改善の為の基盤の設計・開発を行っています。

今日はユーザーの検索行動のUXを向上させるために立ち上がった、検索改善プロジェクトについて書こうと思います。

検索機能における、UX上の課題点

  • 検索したものの、レシピ数が少ない
  • 豚肉、パスタなどの曖昧なワードでの検索時に結果が多すぎる(ユーザーが求めているレシピの割合が低くなってしまう)
  • 明らかに不適切なレシピが検索結果に混ざり込んでしまっている

その結果、検索後の離脱率(動画再生せずに直帰した割合)が高い状態になっていました。

課題解決へのアプローチ

delyでは基本的にグロースは開発チームが行っています。
しかし、今回の検索はドメインの専門知識があったほうが質の良い仮説が立てられるということで、調理部などの各部署と連携したプロジェクトが立ち上がりました。

やったこと

  • 部署横断での検索改善プロジェクトチームの立ち上げ
  • 料理人の方々がPDCAを回せるように、SQLを書かなくても主要なデータ分析を行えるWebアプリの作成(Mondoru)
  • Mondoru上でElasticsearchの辞書、シノニム管理
  • 数値やKPIのSlack通知
  • 検索数が多いのに結果が少ないキーワードを抽出し、レシピを開発

Mondoru

delyではリポジトリ名やアプリケーション名をワンピースのキャラにするという習慣があるので、今回はそれっぽい『シャーロット・モンドール』から名前を付けました。

Mondoruには主に以下の機能があります。

  • 辞書、シノニムの追加
  • スコアリングの調整
  • 上記チューニングでの検索結果をテストする
  • Elasitcsearchの管理
  • 検索離脱率などの主要データを画面をポチポチして集計、出力する
  • データのビジュアライズ
  • その日の検索データ速報をSlackへ通知

改善でやったこと、成果

基本的には季節ごとの検索傾向や離脱率を見ながら辞書とシノニムを追加していくことになります。
調整した検索ワードの離脱率と動画再生画面への遷移数の変化を見ながら、ベストな検索結果を探っていきます。

f:id:skuwa:20170912210722p:plain

日々の検索データを眺めながらノイズの割合が多いものに関しては辞書とシノニムを活用したチューニングを、検索結果数が少ないものは該当キーワード向けのレシピ開発を行います。

↓検索結果改善によって、検索後に動画再生される割合が急速に増えてきています。 f:id:skuwa:20170912211633p:plain

今後の課題

レシピ開発によってニーズのある検索結果を充実させ、辞書やシノニムで検索結果に含まれるノイズを減らすことに成功しました。

ただ、冒頭に述べたように検索結果が多すぎる時にユーザーに刺さるレシピの割合が少ないという問題は解決できていません。データで見ても、具体的な料理名での離脱率は減少していますが一般的な食材名での離脱率はあまり変化が見られません。

そこで、検索関連のユーザー行動データを元にしたサジェスト機能を実装中です。

サジェストには2種類あって、絞り込みのサジェストと置き換えのサジェストがあります。

絞り込みサジェスト

『パスタ』を入力したユーザーに対して、

  • 『パスタ トマトソース』
  • 『パスタ 魚介』

をサジェストする。

一般的なサジェスト機能です。
キーワードの検索数や、検索結果の件数などを元にスコアリングして表示を行います。

置き換えサジェスト

『豚肉』を入力したユーザーに対して、

  • 『豚こま肉』
  • 『豚ひき肉』

をサジェストする。

『豚肉』といったカテゴリに近い検索ワードは、サジェストでより細かいカテゴリに置き換えすることで検索結果を最適化できるようにします。

冷蔵庫に『豚こま肉』が入っているユーザーが『豚肉』で検索しようとした際に、『豚こま肉』をサジェストすることで、より最適な検索結果にユーザーを誘導することが可能です。

まとめ

ドメインの専門知識を活かすグロース基盤を作ることで質の良い仮説を立てることができ、『超速』でのグロースをすることができました。

delyではその他にもグロースの質と速度を爆速にする基盤やアプリケーションの開発に投資をしており、Mondoruのようなアプリケーションの開発を多数行っています。

世界最速のグロースに挑戦したいという方、是非応募してみてください!

www.wantedly.com

SRE育成プロジェクト(APOLLO計画)でアストロノート1号になってみた!!

iOSエンジニアの西川です! kurashiru(クラシル)のiOSアプリの開発を担当しています。

前回のdely engineering blogで紹介させていただいたAPOLLO計画にアストロノート一号として選ばれた僕がこの計画の感想を書いていきたいと思います。

未来のSREを最速で育てる!dely流SRE育成術、APOLLO計画の紹介

APOLLO計画ではSRE候補者のことをアストロノートと呼んでいます。

f:id:delyjp:20170815144834j:plain

アストロノート1号への道のり

私のdelyでの業務は冒頭でも述べた通りkurashiru(クラシル)のiOSアプリ開発です。 しかし、delyで日々過ごしているうちにkurashiru(クラシル)の大規模トラフィックを捌くSREの業務に興味がでてきました。 そこでSREの業務に興味があることを伝え、今回のこのAPOLLO計画に参加することになりました。

APOLLO計画

1.インフラ構築

APOLLO計画を受ける前の僕のスキルセットはアプリAPI用のVPSサーバーを構築した程度でAWSについてはほとんど知識がない状態でした。

なので事前にAWSの用語の知識を簡単にまとめてくれたものを渡してもらいそれを頭にいれて本番にいどみました。そのおかげでインフラ構築自体はスムーズに進んでいきました。

具体的にはElastic Load Balancerの作成、EC2インスタンスの作成、セキュリティグループやAuto Scalingグループの作成です。

しかし、それぞれがどのように動作していてどういう役割をしているのかを一人で理解することは厳しかったのでその都度質問していました。質問するとすぐに的確な答えがかえってくるのでその場で理解することができました。

またどこまでが正常に動いていてどこが原因で動いていないかを確認するためにNginxのアクセスログやFluentdのエラーログの見方などを最後に教わりました。iOS開発でもデバッグのためにログをみますが、それとは違い”こうゆうところを見るのか〜”ととても新鮮で学ぶことが多かったです。

2.障害対応

いよいよ本番です。課題内容の簡単な説明を受け障害対応スタートです。

今回の障害は

EC2インスタンス内での変更作業によって、正常稼働しないAMIがリリースされました。障害から復旧させ、原因の追求と対応をしてください。

という内容のものでした。

障害対応中はslackで分報チャンネルを作ってそこに今どんな作業をやっていて、どんなことを考えながらその作業をしているのかを書いていきます。これをやることでどの部分で詰まっているかを伝えることができるとともに障害のログを残せるのでもし同じことが起きたときにすぐ対処ができます。

まずはどこにボトルネックがあるのかの検証を行っていきました。具体的にはnginxのアクセスログをtailしながらcurlでリクエストを送ってみてどうなるかや、td-agentのログを追ってみたりしていました。実際にやってみるとエラーをみつけることはできるもののそれがどんな要因でエラーになっているのかをなかなか突き止めることができません。ヒントをもらいながら試行錯誤して動いていない部分を特定していきます。思っていた以上に大変で時間だけがどんどん過ぎていき焦りながら必死でやっていました。結局すべての問題を解決することはできずに終わりましたが、今起きている障害にどういうフローで対処していったらいいのかを実際に体験できたのは本当に貴重な体験になりました。

反省としては今起きている障害がどんな障害かを理解するために時間を使い過ぎたことです。 優先させるべきはいち早く正常な状態に回復させ、被害の影響を最小限に抑えることでした。

3.振り返り

今回このAPOLLO計画に参加して学んだことは以下の2つです。

  • AWSのEC2インスタンスやELBの仕組みが今までより明確になった
  • 障害が起きたときのデバッグの仕方を実際に体験でき、障害が起きそうな部分、ボトルネックになりそうな部分を見分ける思考が少し身についた

このAPOLLO計画を繰り返すことによってSREとしてスキルを最速で身につけることができる可能性を感じました。

delyではAPOLLO計画でSREになってみたいというエンジニアの方、我こそはという最強SREを募集しています。 是非Wantedlyから応募してください!!

www.wantedly.com

www.wantedly.com

未来のSREを最速で育てる!dely流SRE育成術、APOLLO計画の紹介

こんにちは。SREの@_skuwaです。
kurashiru(クラシル)を支えるインフラ作りや、ミドルウェアの開発等をやっています。

今日はdely SREチームが行っている障害対応訓練、APOLLO計画をご紹介します。

f:id:skuwa:20170804000901j:plain

SREチームの課題

クラシルは他に類を見ないスピードで成長しているサービスのため、一般的には半年から数年ごとに行わなければいけないような負荷対策を数週間でどんどん行っていく必要があります。
SREとしては非常に高いスキルや経験を要求されますが、それを持ち合わせているSREが市場的にはあまりいないというのが課題でした。

私はdelyに入社した時点ではSREとしてのスキルは持っていませんでしたが、入社して半年程度でSRE業務を行えるまでになりました。

私がSREとして戦えるまでに培ってきたノウハウを元に作った、最速でSREを育てる教育体制がAPOLLO計画です。

APOLLO計画

APOLLO計画の名前の由来ははNASAのアポロ計画です。
人類の月面着陸という困難なミッションを実現させたアポロ計画のように、SREを短期間で育成するという大きな目標を達成させたいという願いを込めての命名です。

APOLLO計画では大事にしているポイントが3つあります。

  • コマンドやコードに関しての知識など、大前提として必要な知識を身に付けてもらうこと。
  • “事実確認→仮説→検証→再発防止策の検討"というフローを徹底的に叩き込むこと。
  • 障害が起きそうな部分、ボトルネックになりそうな部分を嗅ぎ分ける嗅覚を身に付けてもらうこと。

各ポイントについて、APOLLO計画ではどのように教育しているのかをご紹介します。

1. ペアインフラ構築

APOLLO計画を受けてもらうエンジニアの多くはクラウド環境やインフラ構成についての知識がありません。
私と一緒に本番と同等の環境を作成するところからがスタートです。

どういった経緯があって今の構成になったのか、そもそもロードバランサーってどういう役割なの?みたいなところを解説しながら、0からの構築をしていきます。 その際には、少しでも疑問がある箇所、気になった箇所は必ず質問してもらうようにしています。

また、構築後は簡単なシェルスクリプトやcurlなどを利用して動作の仕組みを追ってもらいます。
ここでLinuxコマンドやアプリケーションの仕組みを知ってもらうとともに、どこまでが動いていて、どこまでが動いていないのかを把握できるようになってもらいます。
Linuxコマンドやシェルを1から覚えるのは非常に大変ですが、実際の業務では一部しか使わないことが多いです。そのため、より実践的なテクニックをペアプロ形式で覚えてもらいます。

2. 小さな課題をたくさんこなす

実際の障害では何かがトリガーとなって連鎖的に問題が発生するケースが多いです。しかし、いきなりそれを解決してもらうのは無理があります。
そこで、まずは1つのトリガーによってどこかが停止してしまうといったケースの課題をたくさん用意し、それを解決してもらうということに取り組んでもらいます。

具体的には設定ファイルの記述ミス、セキュリティグループの設定ミス、最適化されていないコードによるパフォーマンス低下等です。

”こういったことがトリガーになって、こんな現象が発生するのか〜”という知見を得てもらいます。
どこまでが動いていて、どこから動いていないのか。じゃあありえる可能性は?といった思考フローを徹底的に叩き込みます。

”あ、これAPOLLO計画でやった問題だ!”

と、実際の業務で思ってもらえることが理想です。

3. 実際に発生した障害の完全再現

まずは弊社の環境(AWS、Nginx、Fluentd、Rails、Goによるアプリケーションサーバー等)でしっかりとSRE業務を行えるようになることにフォーカスを当てています。
弊社ではオライリーのSRE本を参考にして、障害発生時にはPostmortemを残しています。
(Postmortemに関してはSRE本の15章に詳しく書かれています。英語版しかありませんが、8月12日に日本語版が発売予定です。)

Postmortemを元に実際に発生した障害を完全再現して、それの解決を課題として取り組んでもらっています。
障害を再現するのは運用側のコストがかなりかかるので、VacuumDecayというGo製のコマンドラインツールを作成し、コマンド一つで可能な限り障害を再現させられるような体制を作っています。

ここまで学習してきたことを活かしながら、実際の障害対応と同様の体制で復旧してもらいます。
取り組んでいるエンジニア達は、まずはボトルネックやどこで問題が起きているのかを必死に追っていこうとします。
しかし、これは実際の障害です。まず優先させるべきは正常な状態に回復させること、被害の影響を最小限に抑えることです。
そのため、積極的に経過時間を教えてプレッシャーを与えていきます。

影響範囲がこれぐらいで、ユーザーはもう戻ってこないかもしれないね〜、リテンションめっちゃ落ちそうだよね〜と、どんどんプレッシャーを与えます。
こうした中で課題に取り組んでもらうことで、SREとして大事な"システムを正常稼働させることの重要性"を知ってもらいます。

また、実際の障害対応と同様の体制での作業となるのでPostmortemをしっかり書いてもらいます。 そこで自分の行動の振り返りと、同様のことが二度と発生しないための仕組みづくりや運用方法を検討してもらいます。delyのエンジニアは本当に優秀なので、このレベルになってくると、私もなるほどそういう考えがあったのかと気付かされることも多いです。

この課題に取り組んでもらうことで、インフラエンジニアではなく、SREとしての仕事を覚えてもらいます。

新しい機能の実装は毎日のように行われていますが、障害はあまり発生しません。
そのため、一般的には障害対応やリスク予知のノウハウというのは短時間で身につきにくいものです。
ですが、delyでは障害をPostmortemとして記録し、”資産”として活用することによって、スピード感のあるSREチームを作っています。

最後にSREチームの紹介と募集

delyのSREチームは、超スピードで成長するクラシルを支えるチームです。

  • Rails、Go製アプリケーションの運用
  • 開発チームの作業効率アップのための開発環境作り
  • プッシュ配信基盤等のミドルウェア開発
  • FluentdやKinesisを利用したログ集計基盤、分析基盤の構築
  • CloudWatchやPrometheusでの監視基盤の構築
  • kubernetesなどのコンテナ技術の導入

など、業務内容は多岐にわたります。

組織も、プロダクトも、そしてAPOLLO計画もまだまだ未熟ではありますが、今のフェーズから一緒に世界一イケてるSREチームを作ってくれるメンバーを募集しています。
我こそはという最強SRE、APOLLO計画でSREになってみたいというエンジニアの方!
是非Wantedlyから応募してください!!

www.wantedly.com

www.wantedly.com

1台あたり10,000人を捌くRails製Webサーバのチューニング

SREの深尾です。kurashiru [クラシル] のインフラを担当しています。

タイトルのとおり、クラシルのwebサイトではRailsを使っており、1サーバあたり10,000人程度のアクセスに耐えることができます。実際には余裕を持たせて5,000人/サーバを目安にスケールさせており、TV CMをガンガンやったり、国内外のTV番組で特集されたり、芸能人にSNSで拡散されても動じませんが、実は過去に1度だけWebサイトがダウンしてしまったことがあります。それは2017年3月11日にSmaSTATION!!というTV番組でクラシルが取り上げられた時のことでした。

以下はその時のリクエスト数を表すグラフです。ダウンしてしまったので計測できなかったユーザの数字は含まれませんがそれでもアクセス数は1分で数万人を超えていました。

f:id:motobrew:20170612121013p:plain

それまで、Webサイトの負荷対策はあまり行っておらず、2台のWebサーバをLoad Balancerに繋いで冗長化しているだけでした。まず負荷対策においてサーバの数を増やすだけではダメなのかということについて考えたとき、以下の理由からサーバを増やすだけではなくボトルネックを調査した方が良いと言えます。

  • ボトルネックがわからないとスケーラビリティを保証できない
  • 仕組みを理解していないと障害原因の特定が難しい
  • 1台あたりの限界がわからないと適切にサイジングできない
  • リソースを使い切れないとインフラ費用が何倍にも膨れ上がる

スマステでサービスがダウンした時、CPU使用率が20%を超えることはなく以下のようなエラーログを出し、nginxが502を返していました。

[error] 2820#0: *10321 connect() to unix:/tmp/web/unicorn.sock failed (111: Connection refused) while connecting to upstream,

そこでCPUの利用効率を上げるために同時に捌くリクエストの数を増やすことを考えました。

 Unicornのプロセス数を増やす

Unicornは1プロセスあたり1リクエストずつ捌く設計になっています。そのため1サーバあたり同時に捌けるリクエストはworker_processesで設定された値になります。

デフォルトでは5になっていました。これを増やせば同時に捌くリクエストを増やすことができます。どれくらいが適切かはアプリケーションによって変わります。例えば、リクエストの裏側でDBや全文検索エンジンなど、別のサーバにリクエストを投げてそのレスポンスを待っている間は、Rails側のサーバのCPUは使われません。その分Rails側のCPUは余裕があることになりますが、プロセス数を増やすとメモリ使用量も増えます。仮にメモリ使用率が100%近くになってしまうと、OSが使うファイルシステムキャッシュのメモリが少なくなってパフォーマンスが悪くなってしまうことがあります。そのため、以下のことを考慮しながら、本番環境でレイテンシなどのパフォーマンスを測りながら細かくチューニングすると最適な値が見つかると思います。

  • プロセス数に比例してメモリ使用量が増える
  • コア数に対して多すぎるとロードアベレージが上がり、オーバーヘッドが大きくなる
  • メモリの未使用領域はファイルシステムキャッシュに利用される

プロセス数を増やすことでCPUを使いきれるかと思ったのですが、abコマンドで簡単な負荷テストを実施したところ、実際には同時接続がおよそ1000を超えるとCPUやメモリはまだ余裕があるのにnginxがエラーを返していました。そこで次のチューニングです。

UNIXソケットのバックログを増やす

瞬間的におよそ1000を超えるリクエストがきた場合はエラーになってしまうことがわかりましたが、1台のサーバで同時に処理できるリクエストはUnicornのプロセス数なので、プロセス数を超えるリクエストは1000ぐらいまでどこかで順番待ちをしていることになります。

弊社ではNginxからUnicornへリバースプロキシにUNIXソケットを利用しており、Unicornでこのソケットのbacklogがデフォルトで1024になっているのではないかという仮説を立てました。つまり、backlogを増やせば一時的に数千以上のリクエストが来ても順番待ちをさせて返すことができるのではないかというわけです。そこで環境変数で以下のように設定します。

unicorn socket backlog

backlogを4096に変更したところ、1500や2000以上のリクエストを同時に投げてもエラーにならずに(少し時間はかかるけれど)正常なHTTPレスポンスを返すことができました。また、負荷テストを行ったところ、CPUを100%近くまで使える状態になりました。

最後に

f:id:motobrew:20170621213240j:plain

このようにボトルネックを1つずつ解消するというプロセスを繰り返すことでハードウェアリソースを使い切ることができます。また上記以外にNginxのキャッシュを利用して、瞬間的なアクセスにはNginxのキャッシュを返すことで1台あたり10,000人程度でも高速に捌けるサーバとなっています。最後にサーバのサイズとプロセス数とバックログの参考値を以下に記載します。

  • サーバ:CPU2コア、メモリ8GB
  • worker_processes:24
  • backlog:8192 

 

delyでは、急速なサービス成長を支えるSREを募集しています。

www.wantedly.com

www.wantedly.com

インフラ技術はエンジニアが普通の壁を超えるための必要条件

dely株式会社 CTOの大竹です。今回は「エンジニアが普通の壁を超えるためにインフラを習得すべき理由」について自身の経験を織り交ぜて話したいと思います。 

Railsを使えるだけのエンジニアはコモディティ化している

ここ数年でWeb系のエンジニアの敷居は驚くほど低くなりました。すこし前はRailsを使ってウェブサービスを作れるエンジニアは重宝されていました。しかし今では、Railsが使えるとポートフォリオに書いているエンジニアはいくらでもいますし、簡単なサービスならわざわざRailsを使わずともPaaSのようなサービスでバックエンドを構築してしまうことだってできます。

Railsでウェブサービスを作れるスキルはすっかりコモディティ化しました。Railsのような極めて簡単にウェブサービスを作れるフレームワークが登場し、それならばとエンジニアリングを始める人が増えたのです。*1

*1:この場合の「ウェブアプリケーションを作れる」とは、インフラは誰かに任せるかHerokuのようなホスティングサービスを使ってその上で動かせることを意味しています。

続きを読む

フルスタックでないアプリ開発者が今後役に立たなくなる3つの理由

f:id:SonyGulss:20160706094741j:plain

dely株式会社 CTOの大竹です。今回は、アプリ開発者がフルスタックである優位性について話したいと思います。

 

f:id:SonyGulss:20160706103412p:plain

人数を増やしても良い製品は作れない

サーバーサイドのアプリケーションの場合、MVCモデルを採用して分業で開発を進めることが容易です。デザイナー、フロントエンジニア、バックエンドエンジニアのようにそれぞれの専門領域を持っている人たちが集まって開発することができます。特にRailsのようなデファクトスタンダードに近いフレームワークを採用すれば、それが共通言語になって意思疎通もスムーズになります。

一方、iOSやAndroidのネイティブアプリの場合、UIのコードとロジックのコードをどちらも密に理解して開発する必要があるので、分業するのが困難です。いろいろ分離して分業する方法も考えられてはいますが、Webの開発のように分かりやすく分離することはやはり困難です。必然的に、アプリ開発は少人数のチームで進めることが多くなります。

また、最近ではチーム開発の方法論として人気の高い『スクラム開発』を採用する企業が増えています。スクラム開発とは簡単に言うと、短いスパンで開発サイクルを回し、問題が小さいうちに発見するできるようにして大きな手戻りを防ぐ手法です。

スクラム開発において、1チームの最適な人数は3人〜9人と言われています。それ以上になると共有に時間が余計にかかって一人当たりのパフォーマンスが低下します。

このように、開発チームはどんどんコンパクト化しています。優秀なメンバーで構築された少人数でコンパクトなチームが一番価値のあるものを生み出しやすいのです。*1

*1:プロダクト・マーケットフィットを確認し終え、サービスの安定性が重要になってくるフェーズでは大人数の方が有利かもしれません。ここでは新規サービスを開発するチームを想定しています。

続きを読む

レシピ動画アプリ『クラシル』のエンジニアが解説する、動画アプリ特有のUIデザイン

dely株式会社 CTOの大竹です。今日は弊社が運営しているレシピ動画アプリ『KURASHIRU』を作る上で考えている、動画アプリ特有のUIデザインについてお話しします。

2016年は動画元年

インターネット上でコンテンツビジネスをしている企業の間では、今年2016年から動画を活用したビジネスが一気に普及すると言われています。

続きを読む