Streaming Conference #4 にて登壇しました

こんにちわ。

SHOWROOMエンジニアのシミズです。

先日「Streaming Conference #4」に参加し登壇しましたのでその報告です

streaming-lab.connpass.com

当日の様子はFRESH LIVEでも放送されました。

freshlive.tv

今回はDeNAのオフィスでの開催ということでしたので、 カメラなど一部機材はSHOWROOMの物を提供させていただきました。



speakerdeck.com

"最近"の負荷対策というか、障害報告をさせていただきました。

今回、我々のサービスの事例を紹介しましたが、他のサービスではどうしているのか、どう考えているのかもとても興味ありますので、差し支えなければ是非お話聞かせてください。

懇親会でお話させていただいた皆様、ありがとうございました。貴重な学びでした。


そして、賛否両論あるとは思いましたが、「サーバーはダウンするものなので、ダウンした場合の考慮をするべき」という考えも述べさせていただきました。

当然、ダウンさせないべきです。ダウンさせないように全力を尽くします。

それでも想定外の自体が起きることはありえます。

そんな想定外の時にどう動けるかこそが、エンジニアの腕の見せ所ではないでしょうか。

復旧方法がしっかり確立されているので、サーバーダウンを恐れないということとは決して違うので履き違えないようにだけお願いいたします。

安定化の話をするとどうしても守備的というか、既存の仕組みを変えるのを恐れがちですが、少なくとも我々は新しいことへのチャレンジも実施しています。

その例がCDN配信への取り組みです。

既存の仕組みで安定稼働しているのだから、そのまま進めるだと、既存の仕組みで対応しきれない場面に出くわした時に脆いです。

我々はより強固な安定を求める為に新しい施策にチャレンジする、そのチャレンジでもトラブルが起きないように全力を尽くす。

全力を尽くしてもトラブルが起きてしまうときは起きてしまうので、そんな時でも、冷静、丁寧、正確に対応できる組織を目指したいなと考えています。



Streaming Conference #1, #4と運用の話をさせていただきました。 でも、他の方の技術的な登壇も憧れます。 次は自分も技術的な話をしてみたいです。「xxxxをやってみた!」的な。 みんながあっと驚くすごい内容は難しいかもしれませんが、LT枠なら暖かい目で聞いていただけるのではとハードルは下げさせてください。

13日の金曜日

13日の金曜日ということで、

弊社では、Live Blu-rayの鑑賞会をやりました。

その様子をシミズが簡単にレポートします。

(*本投稿は技術的な話は一切ありません!)

f:id:otto13:20180717174501p:plain

今回は、SHOWROOM以外のエンジニアもお招きしました。

以前から、久しぶりに交流会(飲み会)しましょうとお話をしており、

  • 13日の金曜日ありますね!
  • Blu-ray発売しますね!

っていう絶好の機会だったのでやっちゃいました。

(SHOWROOMの休憩室は勉強会や交流会などに活用できます)

f:id:otto13:20180717175124p:plain

Hey, Hey, Hey, Hey♪

Hey♪

f:id:otto13:20180717175445p:plain

以前ノベルティで配ったサイリウム。
 

再生終了後も、この夏の予定だったり、最近の活動の話だったりしながら親睦を深めました。

お集まりいただいた皆様、ありがとうございましたmm

今回の目的は、

「親睦を深めて、勉強会とかで会った時に気楽に話せる仲間づくり」

だったのですが、ライブ会場で会った時も気楽に話せるような気がします。

次の展開はどうなるの?

良き会だったのでまた別のテーマでやれたらなーなんて思ってます。

  • サッカー観戦
  • ゲーム大会
  • etc...

今回は知り合いづてでの開催でしたがcompassとかでパブリックに募集なんかも検討中です。 (IT界隈の人間のドメイン特化型勉強会という体裁)

いっしょに働きませんか!

SHOWROOMでは現在採用に力を入れており、
一緒にプロダクトを作り上げていく仲間を大募集しています!
興味が湧いた方は一度遊びに来てください! www.wantedly.com

SHOWROOMの新規開発にHyperappを採用した話

こんにちわ、エンジニアのきむらです。現在は主にフロントエンドを担当しています。

今回は、SHOWROOMの新規機能開発にHyperappというJavaScriptフレームワークを採用したので、そのお話をします。

はじめに

SHOWROOMは、ターゲットのプラットフォームをPC / iOS / Androidとしていますが、 iOS / Androidではアプリ内でWebViewコンポーネントを利用しWebページを表示している画面がまだ数多くあります。

既存のページは以下のJavaScriptフレームワーク / ライブラリを使用しています。

数年前に流行ったBackbone.jsからなるクライアントサイドMVCを構成するためのモジュール群です。 ですが、今の世の中の流れは完全に仮想DOM一色、SHOWROOMもこの流れに乗り より機能の変更に柔軟に耐えうる、低コストかつ高速描画の可能なフレームワークを採用することにしました。

f:id:hkmn:20180707121817p:plain:w256 < 乗るしかない このビッグウェーブに!

仮想DOMとは

仮想DOMは、VirtualDOM、VirtualNode、VDOM、VNodeなどとも呼ばれます。 もうすでに数年前から仮想DOMに関しての記事は山程出ているため、いまさらこの記事で紹介するまでもないのですが

ものすごく簡単にご説明すると

「ブラウザ自体が画面の変更に対して行っていた処理を、JavaScriptで肩代わりすることで高速にレンダリングする技術」

です。

ブラウザは画面の構成要素をDOMという単位で管理しますが、これをJavaScriptで「仮想のオブジェクト」として管理することで ブラウザ内で行われているDOMを直接操作することをせず、モデルとビューのデータバインディングを行うことができます。

仮想DOMを採用しているライブラリ

有名なものとして以下が挙げられます。

f:id:hkmn:20180710194228p:plain:w128

React.js(Facebook社製ライブラリ https://reactjs.org/

f:id:hkmn:20180710193746p:plain:w128

Vue.js(Google社のEvan Youさん個人が開発したライブラリ https://jp.vuejs.org/index.html

今回の開発で採用するにあたって

ここで一旦SHOWROOM自体の機能について一度ご説明すると、大きく分けて以下の2つで成り立っています。

  • 配信を視聴するための画面(様々な画面要素が存在し、通信が頻繁に発生する)
  • それ以外の画面(簡単な設定変更のみを行うページや検索や記事的なページ)

今回新規で開発する画面は、後者であったため、複雑な処理は行う必要がありませんでした(実際に開発した画面の詳細は後述)。

そのため以下の点から、上記2つのライブラリは今回の開発には利用しないことにしました。

  • 要件を満たすにはすこしオーバースペックである(機能は充実しているが、そこまで利用しない)

  • 学習コストが高い(ライブラリ独自のお作法、周辺ライブラリの選定等、導入にあたって学習・検討しなくてはいけない内容が多い)

  • 一度採用すると、そのライブラリを剥がしにくい(がっつりフレームワークに依存した処理が多ければ多いほど、書き換えコストも増大)

Hyperappについて

f:id:hkmn:20180710194336j:plain:w128

Hyperappは、JorgeBucaran(https://github.com/jorgebucaran)さんが開発している仮想DOMを実現しているライブラリです。

https://github.com/hyperapp/hyperapp

昨年末にIncrements社が運営するプログラマーコミュニティ「Qiita」において、ReactからHyperappに置き換えたことで話題になりました。 JorgeBucaranさんは、Qiitaの中のひと(2018年現在)で、独自に開発していたHyperappをオープン化しています。

今回、Hyperappを採用したのは以下の理由からです。

  • ライブラリ自体がとても軽量
  • 学習コストが低い
  • ビューの管理にJSXをサポートしている

ライブラリ自体がとても軽量

ライブラリは1ファイルのみ、行数も400行未満、とてもシンプルな実装で軽量です。 自分で1からコードを読むのも全く苦ではないレベル、仮想DOMの考え方や実装を学ぶにもとてもよいライブラリだと思います。

学習コストが低い

先に述べた通りReactやVueは、学習・検討しなくてはいけない内容が多いのですが、Hyperappはこのライブラリ固有の考え方がとても少ないため導入が容易で、プロジェクトにあとから参加するメンバーがいても学習コストを低く抑えられます。

ビューの管理にJSXをサポートしている

同様にJSXをサポートしているReactに仮に置き換える必要がでたり、今後Reactで開発する必要がでてきて場合でも 書き換えが容易であり、モジュールの共有がしやすいと考えました。

(JSXについて:https://facebook.github.io/jsx/

以上から、Hyperappを今回採用しました。 Hyperappの利点は、QiitaにJorgeBucaranさんが記事をあげていますのでそちらも参照するとさらにわかりやすいかと思います。

Hyperappのアーキテクチャ

Hyperappは以下の3つのモジュールで構成されています。

State

プレーンなJavaScriptオブジェクトであり、アプリケーション全体の状態を管理します。

Actions

Stateを更新するための処理群を管理します。このオブジェクト配下にある処理のみがStateを更新できます。

View

仮想DOMを実現します。ActionsによってStateが更新されるたびにViewが再描画される仕組みになっています。

以上がHyperapp独自の考え方のすべてなので、学習コストはとても低いといえます。

実際の開発について

ここからは、実際に開発した画面について、どんな構成にしたのか、どんなところでハマったのか、等を共有できればよいなと思っています。

(コストが低いのにハマったのかよ、というツッコミはまあ初期導入は得てしてそんなものだということでご理解ください。。。)

開発した画面

SHOWROOMは、ユーザの分身をアバターで表現しています。 仮想ライブ空間では、配信画面上にアバターがたくさん表示されており、いわゆる「ライブ感」を演出しています。

ユーザはアバターを頻繁に着替える機会があるのですが、着替えるための画面が使いにくいという声がユーザさんから多数上がっており、 この画面をより使いやすいように改修することになりました。

機能は以下の通りです。

  • アバターのリストをページ送りで確認できるようにした。
  • 条件で絞り込みできるようにした(使用した履歴 /「お気に入り」)。
  • アバターを「お気に入り」設定し、管理できるようにした。

画面イメージ:PC

f:id:hkmn:20180708005259p:plain:w512

画面イメージ:アプリ

f:id:hkmn:20180708001945p:plain:w256

実際の画面はログインが必要です。

(PCの場合)

https://www.showroom-live.com/

左メニューより、ログイン -> マイプロフィールアイコン -> アバター着替えはこちらバナーをクリック

(アプリの場合)

‎「SHOWROOM-ライブ配信ならショールーム」をApp Storeで

play.google.com

左メニューより、ログイン -> マイページ -> 編集 -> アバター着替えはこちらバナーをクリック

または、

配信画面で画面下自分のアバターをクリック -> アバター着替えはこちらバナーをクリック

ぜひ使ってみてください!

開発環境

以下のような構成にしました。

JavaScriptライブラリ

  • Hyperapp 1x(アプリケーション全体の管理)

  • Hyperapp router(ルーティングの管理、今回はページ送りで使用)

  • axios(非同期処理)

開発言語

Flowでもよいのですが、現状TSをサポートしているライブラリのほうが多いのでこちらを採用。

  • JSX(TSX)

スタイルライブラリ

Showroom独自のコンポネントとテーマを適用しています。

タスクランナー

(既存の画面もwebpack 4を使っています)

ディレクトリ構成

.
├── dev
│   └── pages (webpack-dev-serverのrouting)
├── src
│   ├── api (非同期処理まわり)
│   ├── components (共通コンポーネント)
│   ├── ext (外部ライブラリ)
│   ├── icon (SVGアイコン用tsx)
│   ├── img (静的画像)
│   ├── pages (ページ固有の処理)
│   │   └── UserAvatar
│   │       ├── actions
│   │       ├── components
│   │       ├── icon
│   │       ├── img
│   │       ├── index.tsx
│   │       ├── state
│   │       └── utils
│   ├── typings (TypeScript型定義ファイル)
│   └── utils
├── tsconfig.json
└── webpack.config.js

開発する上でのルール

以下のようなルールを最低限のコーディング規約としました。

  • Actionsの命名規則

とくにHyperappによらない話で、Fluxを使った場合でも決めたほうが複数人の開発がスムーズになります。

今回Actionsの命名規則を、

「誰が」「どこを」「何をしたか」

で定義するようにしています。 具体例は以下のような感じです。

// ユーザ操作
// ユーザが、アバター画像を、クリックした
userAvatarImageClicked: (id: number) => (state: State) => ActionResult<State>

// システム
// システムが、Appコンポーネントを、起動した
systemAppLaunched: () => (state: State, actions: Actions) => ActionResult<State>

ハマった点

以下のようなところでハマりました。。。

非同期処理まわり

「ActionsによってStateが更新されるたびにViewが再描画される仕組み」というアーキテクチャにおいて、ActionsがStateを更新し反映するタイミングは、「Actionsで定義される関数の戻り値がStateを返却したとき」です。

公式にちゃんと書いてはあるのですが、横着して読み飛ばすとだめな典型。。。

https://github.com/hyperapp/hyperapp#asynchronous-actions

ルーティングまわり

後々簡単なSPAもできるように検証も兼ねて導入したHyperapp routerは、ライブラリが絶賛更新されているタイミングだったため、使い方がよくわからなかったり、TS型定義ファイルが公式になかったりしてなかなかビルドが通らないという羽目に。。。

また、ie11をサポートするために、polyfillを使用しています。 (Hyperapp routerでは内部で、CustomEventが使われています。)

TypeScriptまわり

いきなりTSまで導入するのがそもそもいけない説あります。。。 が、せっかくなので新規環境で早く導入したほうが、途中で導入するより楽です。

ハマりポイントはやはり型定義ファイルが見つからなかったり、サーバのテンプレートから渡されるデータとのやりとり、ネイティブオブジェクトをどうするか、等です。

今回すべてのファイルでTSを導入したのですが、そもそも「型の恩恵を得たいファイルのみに限定する」という割り切りが必要だと思います。

開発コミュニテイ

Hyperappは、公式のSlackコミュニティが活発なので、ハマった場合思い切ってそこで質問をなげてみるのも手です。

https://hyperappjs.herokuapp.com/

JorgeBucaranさんが、頻繁に発信したりするので最新の情報はこちらを見ていると追えます。 基本は英語のコミュニティですが、日本語のチャンネルも用意してあって、JorgeBucaranさんが日本語で答えてくれたりします。

その節はありがとうございました!mm

まとめ

まだあまり日本でのHyperappプロダクト導入事例は見たことがないため、チャレンジの意味も込めて導入してみましたが、一度導入してしまえばかなり楽に開発していける印象を持ちました。

ライブラリがかなりシンプルなため、もしハマったとしても解決のために内部を読むのはかなり楽にできそうです。

また、コミュニティが活発なライブラリは、更新速度も速いですが、より良い機能追加やサポートも受けやすいメリットもあります。

少し前の技術書典4でついに書籍がでていました。

イヌでもわかるHyperapp - 犬テトラ+ - BOOTH

この記事で、Hyperappに少しでも興味を持たれた方がいれば、ぜひ試しに導入してみてください!

小規模、中規模の機能改修にはかなり向いているのではないかと思います。

いっしょに働きませんか!

SHOWROOMでは、一緒にプロダクトを作り上げていく仲間を絶賛大募集中です。

自分たちが楽しく働ける仕組み、ユーザさんに良いと思ってもらえる機能をボトムアップでどんどん作り上げていける会社ですが、まだまだ人が足りません!

今回のようなチャレンジも、許容される組織です。

興味が湧いた方は一度ぜひ遊びに来てください! www.wantedly.com

RubyKaigi 2018 レポ

SHOWROOMエンジニアのシミズです。

RubyKaigi 2018 @仙台 行ってきました!

rubykaigi.org

f:id:otto13:20180604201434j:plain 仙台城跡から見下ろした会場

f:id:otto13:20180604201617j:plain 近くから見るとこんな感じ

ぶっちゃけ、SHOWROOMではRubyを本格的には使っていませんが、旅費、参加費もろもろ会社に負担いただきました。 (ちょっとしたツールならRubyでさくっと書いちゃうことはありますけど)

RubyKaigiは初めての参加で、100%理解できたとは言い難いですが、また参加したいと思いました。

言語仕様や、コンパイラに関する話が多く、普段はあまり考えない部分に3日間肌で感じれたことだけでも学びが多かったと思います。

難しそうな改善内容も、Ruby 2.6にあげさえすればその恩恵を受けらるというはとてもワクワクします。

今からクリスマスが楽しみです(Rubyは例年クリスマスにアップデートがあります)

特に印象に残ったセッション

RubyGems 3 & 4

RubyGems 3 & 4 - RubyKaigi 2018

www.slideshare.net

セッション中に話されていた、デフォルトオプションの考え方はとても感銘をうけました。

不自然な挙動にならないようにすることと、初心者がはまらないようにしているという話は、だからRubyはとっつきやすいのかという理解が深まりました。

My way with Ruby

My way with Ruby - RubyKaigi 2018

slide.rabbit-shocker.org

いつもお世話になっているライブラリが紹介されていて、うらばなしに触れられて新鮮でした。 Rubyで顔認識するライブラリ(CV::CascadeClassifier)は実はちょっとした業務で使いました。(そのうち紹介するかもしれません)

Ruby Committers vs the World

Ruby Committers vs the World - RubyKaigi 2018 f:id:otto13:20180604180706j:plain

developers meeting風な会議のセッションでRubyがどうやって進化して行くのか、新機能がどうやって生まれるのかに触れられてとても刺激的でした。 中央にMatzさんがいる構図も面白かったです。

yield_selfの名前が結局どうなるのか、とても気になってます。

The Method JIT Compiler for Ruby 2.6

The Method JIT Compiler for Ruby 2.6 - RubyKaigi 2018

speakerdeck.com

「C langage is dead」の破壊力はすごかったです。

実際にベンチマークでも圧倒してるのがすごいです。驚きしかないです。

まだJITコンパイラを本番に投入するには課題があるとのことですが、「C langage is dead」な未来にワクワクします。

その他旅の思い出

f:id:otto13:20180604203500j:plain

店舗案内 | 仙台牛タン発祥の店 味太助

「味太郎」に行きました。

近くにある「あじたろう」は居酒屋であり別物という学びを得ました。

f:id:otto13:20180604203735j:plain

googleマップを開いたら、会場の近くに伊達政宗の銅像があるということで足を伸ばしてみたら、、、

地図上では近い距離だったのですが、まさかの山登りでした。

政宗パフェというのを昔ネット番組(SRでも配信)で見たので、それを食べようと思って頑張ったのに、それは違う史跡で残念。

f:id:otto13:20180604204357j:plain

近くに神社があり、伊達政宗パワーといいますか、勝負運に溢れてそうだったので、あのイベントの必勝祈願をしてきました!

以上、3日間にわたるRubyKaigi 2018 レポでした!

仙台、次は9月1日くらいに行きたい!!!

SHOWROOMのUIをカイゼンしてみた

こんにちわ、エンジニアのきむらです。現在は主にフロントエンドを担当しています。

今回は、IBPでSHOWROOMの既存UI改修のプロトタイプ制作をしてみたのでその報告です。

※ IBPに関してはこちら tech.showroom.co.jp

はじめに

入社前からずっと気になっていて、直したかったUIがありました。

それが、こちら

f:id:hkmn:20180423011759g:plain:w256

こちらは、SHOWROOMのPC版のグローバルナビゲーションです。 ナビにカーソルがホバーすると、自動でナビがでてきます。

実際の動きはこちら(SHOWROOMの実際のサイト)

いかがでしたか?

ずっと触っていると私はこんな気分になります(あくまで個人の感想です)。

f:id:hkmn:20180423122827p:plain:w256

SHOWROOMはサービスの特性上、配信に関する改修やイベントの改修が優先されるため、どうしてもこのようなUIの改修は後手後手になってしまうところが正直あると思っています。

ユーザさんも気になっているはずですが、ありがたいことにそこまで重大な問題になっていません。

が、日々のカイゼンの積み重ねはとても大事なわけでして、IBPでまとまった時間が取れるようになったため、ここで一気にやってしまおうと思ったのでした。

改修の方針を考える

いままでの私の開発経験上、以下の2点は特に気をつけなければいけないと思っています。

* 開発者が良かれと思ってつけた機能は、案外ユーザには不要なケースが多い

* ユーザが想定しない動きをするUIは使いづらい

これを踏まえると上記のUIは、

  • ナビが、ホバー時に自動で意図せず出てきて、コンテンツが見えづらくなる

  • アニメーションはユーザの目を引くので、意図せず出てくるとコンテンツから意識がそがれる

が課題だと思っています。 更にこのUIではもう1つ課題があり、

  • アニメーションがなんか遅い

点が気になります。 Googleが提唱するマテリアルデザインのガイドラインによると、デスクトップでのアニメーションの速度は150〜200msがよいとの記述がありました。

現状のナビゲーションは、delay 100ms と アニメーション 300ms に設定されていたため、だいぶ遅いようです。

以上を主な改修箇所とし、UIを改修することにしました。

改修内容

前項の内容を踏まえて、改修した内容がこちら

ホバーしたら勝手に出てくるのをやめる

ユーザのアクションでナビの開閉をします。今回はよくあるハンバーガーメニューを採用しました。

これは「ボタンを押した」 -> 「画面が反応した」という、ユーザが想定しやすいUIです。

アニメーションの速度を速くする

ガイドラインをもとに200msに設定し、自動で出てこないので delay をなくしました。

おまけ

ブラウザのウィンドウ幅が十分に広い場合、ナビを閉じておく必要がないため開いた状態にし、ウィンドウ幅が狭い場合のみ現状の閉じたデザインに変更しました。

ユーザの視認性の向上を目的としています。

改修後の画面

できあがったものがこちら

ウィンドウ幅が広いときは、ナビが最初から開いている

f:id:hkmn:20180423021208p:plain:w512

ハンバーガーメニュー

f:id:hkmn:20180423022109g:plain:w256

ウィンドウ幅を変えると、ナビの開閉状態が変わる

f:id:hkmn:20180423022201g:plain:w512

細かい問題はまだまだあるでしょうが、多少「よくあるサイト」「見慣れたサイト」になったのではないでしょうか。

まとめ

UIに正解はないと思っていますが、「根拠のある」「納得感のある」ものである必要はあり、またノウハウをまとめている記事はインターネット上にたくさんあります。

また、書籍もあります。

このあたりはデザインセンスとかは関係なく、学習すれば身につく領域で、いろいろな情報を日々アンテナをはって得たり、他社のサービスを良く見てみることがとても大事だと思いました。

そして、自分が作っているサービスは、たとえ使いにくいと思っていてもずっと触っていると慣れてしまいます。

慣れてしまう前に、気になる部分はどんどんあげだし、改修していくスピード感もまた必要だと感じました。

いっしょに働きませんか!

SHOWROOMでは、一緒にプロダクトを作り上げていく仲間を絶賛大募集中です。

職能や役割にかかわらず、自分たちが楽しく働ける仕組み、ユーザさんに良いと思ってもらえる機能をボトムアップでどんどん作り上げていける会社ですが、まだまだ人が足りません!

後手後手になっている改修をスピード感もって行うためにも、エンジニア、そしてデザイナーがもっと必要です。

興味が湧いた方は一度ぜひ遊びに来てください! www.wantedly.com

ルームフォロー情報を活用したターゲティングpush通知をトライしました

こんにちわ。

SHOWROOMエンジニアのシミズです。

僕です。

今回はこちらの取り組みについて紹介したいと思います。

きっかけ

こちらの機能を作ったきっかけはIBPの取り組みによるものです。 IBPについてはこちらの記事を参照下さい。

tech.showroom.co.jp

IBPで何を作ろうかなーと考えていた時に、

せっかくなら楽しみにしている配信をより盛り上げたい!

というテーマに絞って考えたときに思いつきました。

思いついてから実装するために出社する足取りは、いつの間にか少し早歩きになりました。

何を作ったのか

push通知を送信する仕組みを作りました。

f:id:otto13:20180326181812p:plain

すみません、また、技術的な話は少なくなりそうです。

何がすごいのか

今回、ルームのフォロワー以外のユーザーにも通知を送信させていただきました。

一部のユーザーにはびっくりさせてしまったかもしれません。

ですが、この通知は闇雲に送信したわけではありません。

今回の取り組みでは、個人の配信ルームをもつ演者さんが別の配信ルームの配信に出演するものでした。

SHOWROOMの配信ルームは主に個人単位で取得いただいており、ユーザーはグループよりも個人をフォローする傾向が強いです。

いわゆる推しメンです。

SHOWROOMのフォロー情報は、ユーザーの推しメン情報です。

今回はその情報を利用して、その推しメンが出演した時に、その推しメンのフォロワーに通知を送信させていただきました。

手前味噌ですが、かなりコンバージョン率の高いターゲティングができているなと思います。

公式のtwitterでも何名かにお礼させていただきましたが、この機能に激励のコメントを頂きとても嬉しかったです。

トライに至るまで

この機能は、誰かや他部署に作って欲しいと依頼されていた機能ではありません。

なので、

「こんな機能を作ったよ!」

「こんな感じで使ったら良さそうだと思うんです!」

と軽く営業メンバーに売り込んだら、早速やってみることになりました。

このスピード感が素敵です。

通常の告知などの宣伝業務であれば、営業メンバーが担当しますが、

今回は作ったばかりの機能だったので、当然、利用マニュアルもなく、自分の手で送信作業を行いました。

いきなり大規模配信に投入

通常であれば、小規模、中規模の配信でトライしてから大規模な配信に投入しますが今回は、いきなり大規模な配信に投入しました。

もちろん、配信内容がとてもよかったことが主要因ですが、この取り組みの配信がSHOWROOM史上最高の閲覧者数になりました。

今思うと、そんな配信に、新機能がいきなり投入していたことはとても恐ろしいですが、

やらせてもらえるとなったときはとてもワクワクしました。

出てきた課題

大規模配信でトライできたこともあり、課題点もたくさん出てきました。

ちょっとだけ技術の話します。

queueの処理が追いつかない

今回の取り組みに出演された演者さんたちは多くのフォロワーを抱えており、その全てのフォロワーに通知を送信したところ、queueが捌ききれず大量にスタックする事件が起きました。

原因

分散処理ができていなかった。

SHOWROOMではpush通知をQ4Mを利用した非同期処理にて実現しています。

また、そのQ4Mのサーバーは複数台構成となっており、キューイング先を散らすことで分散処理を行っています。

f:id:otto13:20180327020344p:plain

キューイング先はMyDNSのラウンドロビンで切り替えながら、まんべんなく散らすように作っているのですが、それがうまくできませんでした。

通知のqueueはN件毎に分割してキューイングしているのですが、全てが1箇所のサーバーに集中してしまったのです。

その原因は、一度接続したサーバーにそのまま繋ぎっぱなしになっていたことでした。

N件毎に分割してキューイングした際に、都度MyDNSを参照してサーバーの接続をし直すように修正しました。

問題解決に協力いただいたDeNAのインフラチームに感謝です

通知がユーザー毎に大きく異る

こちらは未解決ですが、送信対象ユーザー数が多いことが主な要因です。

送信を実行するワーカー数を増やすことでもある程度解決はできそうですが、どうしてもユーザー毎に早い、遅いが出てきてしまいます。

なので、遅延を解決することと同時に、送信順番を決める新ロジックを作ったり、そもそも通知を希望するかユーザーに選ぶ機能を作って送信対象を減らすことも検討しています。

総括

またまた手前味噌ですが、この機能を本番に投入できたことで少なからず配信の盛り上げに寄与できたのではないかと思います。

それができたことが何よりも喜びです。

我々のSHOWROOM Tech Studioチームではユーザーにサービスを提供することに重きをおいて仕事をしていますが、

今回の記事では、そのサービスがどのように生まれていくのかを簡単に紹介させていただきました。

最後に

今回の取り組みの配信で、一時映像が正常に配信できない時間が発生してしまい、大変申し訳ありませんでした。

このようなことが繰り返されないように、我々も成長していきたいと思います。

これからも引き続きSHOWROOMをよろしくおねがいします。

YAPC OKINAWA 2018に行ってきました

おはようございます。サーバサイドエンジニアむっくです。

この度、会社のお金で沖縄旅行YAPC OKINAWA 2018に行ってきました。 その感想をまとめたいと思います。

yapcjapan.org

会場までの道のり

前夜祭は参加できなかったのですが、当日は朝も早いため前乗りで沖縄に向かいました。
京急運転見合わせがありましたが、品川から浜松町に移動し東京モノレールに乗り換え無事羽田空港に着けました。

※飛行機移動では、余裕を持って行動しましょう💁
※運転見合わせのリスクを考え、複数経路を把握しておきましょう💁

当日は、あいにくの雨でした。 那覇市内から沖縄科学技術大学院大学 OISTまではレンタカーで移動したのですが、公式サイトのアクセスマップにあるように1時間ほどで到着しました。

オープニングまで

豪華ノベルティの数々🎉

f:id:mukkua:20180306003437j:plainf:id:mukkua:20180306003448j:plainf:id:mukkua:20180306003451j:plainf:id:mukkua:20180306003455j:plainf:id:mukkua:20180306003458j:plain

印象に残ったセッション 前編

Webサービスを監視するときに僕達が考えたこと papixさん

初心者向けという言葉通り、とても丁寧で聞きやすいセッションでした。 "監視とは"と”Mackerelで監視できるメトリクスとその説明”をされていました。 mackerelで監視出来るプラグインにnasneやスマートリモコンのNeture-REMOもあるのは驚きました。

mackerel-plugin-nature-remo https://github.com/papix/mackerel-plugin-nature-remo

yapc豆ハックとして、"僕達が考えたこと〜"というタイトルにすると通りやすい…らしいです。

HTTP/2で早くなるとき、ならないとき Kazuho Okuさん

毎度ながらとてもわかりやすい説明と話し方でした。ちなみに、今回のネタは同僚の方のものだったらしいです。

「一番早いのは、"HTTP/1"、"HTTP/2"、"場合による"のどれか?」のような質問から始まりました。 答えは、"場合による"なのですが、現状利用しているサーバ、クライアントの組み合わせでベンチマークの結果も変わるようです。 (正常なリクエストはHTTP/2圧勝なのですが、パケットロスの発生するケースだと場合によってはHTTP/1の方が早いケースもあるとのことです。)

セッションの意図としては、実際のユーザが利用してる環境でベンチマークを取りましょうということでした。

閑話休憩

パールスポンサーということで、弊社のエンジニアもランチセッションでお話させていただきました。

f:id:mukkua:20180306004745j:plain

超豪華なお弁当🎉

f:id:mukkua:20180306004738j:plain

印象に残ったセッション 後編

2018年春のPerl karupaneruraさん

@charsbarさんが毎年発表されていたシリーズを引き継がれたようです。まさに今回のテーマの架け橋を体現するセッションでした。

perl5やperl6のバージョンアップ情報、バグフィックスから機能改善などとても良くまとめられていました。

※perl6のatom演算子は今年一番の驚きでした😲

High (Availability|Performance) WebSocket for Perl Real-Time Application macopyさん

趣味で作っていたプロダクト(HTTP/1.1とWebsocketの相互変換プロキシサーバ)を社内利用しリリースするまでの話。 設計思想や課題、戦略などがまとめられた素晴らしい内容で、個人的にはこのセッションがベストスピーカー賞でした!!

speakerdeck.com

その後のセッションも

ゲストスペシャルセッションやLT大会でも(ネタを含め)perl愛に溢れたセッションが続きました。 (語り始めるとキリがないほどです。)

最後に

今回のカンファレンスに参加し、perlに限らず様々な分野の話を聞いて自身の見識が広がりました。 また、プロダクトに対する熱い想いに感化され自分ももっとコードを書きたくなりました。

運営スタッフの方、スポンサーの方、登壇者、参加者の方、本当にお疲れ様でした。 次回、YAPC TOKYOでお会いしましょう。

f:id:mukkua:20180306010526j:plainf:id:mukkua:20180306010455j:plainf:id:mukkua:20180306010413j:plainf:id:mukkua:20180306010341j:plain