ドワンゴ 技術コミュニケーション室の小枝です。

インターンシップシーズン後半、エンジニア志望の学生さん向けに開いていた「プロダクト開発インターン」の第2クールが終了しました。 （第1クールの様子はこちら）

第2クールの参加者は8名だったため、2人チーム４組に分かれてそれぞれ開発を行い、3チームの機能がfriends.nicoのプロダクトとしてサービスリリースされました。

各チームの成果

チームWRP

• utam0k (GitHub/Twitter)
• spring_raining (GitHub/Web)

このチームの選んだ課題は『ユーザーが自由に絵文字を追加できる』ようにしたいというものでした。

開発初期は「マイ絵文字」機能として、ユーザーが自由に絵文字を追加できる機能を開発していましたが、開発中に本家マストドンにCustom emojiという機能が追加されてしまいました。

このままマイ絵文字の開発を続けても将来的に大きな負債になると予想されるため、『ユーザーのプロフィールアイコンを絵文字のフォーマットで表示する書式[:@username:]の追加』という形に企画のピボットを行い、機能名も「ユーザープロフィール絵文字」に変わりました。

ユーザープロフィール絵文字機能は画像リソースの登録画面がいらず、既存のユーザー名サジェスト機能を流用できたため、少ない工数で実現可能かつシンプルで使いやすい仕様になり、9/28にサービスリリースされました。

チームsuits

• mtsue (GitHub/Web)
• sasamaru

このチームはfriends.nicoを始めた際に、「このインスタンスはどんな文化なのか、どう慣れていったら良いのか」がわからないという不満に着目し、アカウント登録時に表示されるチュートリアルを『よりfriends.nicoという文化にフォーカスしたチュートリアル』に変更する ということにチャレンジしました。

新しいチュートリアルでは、独自機能であるニコるの使用方法やユーザーの初トゥートを促すステップを用意し、ユーザーの能動的なアクションに対する恐怖心を早期に取り除けるよう設計されています。 また重要度の低い機能の説明をあえて省くことによりユーザーの混乱を避け、よりfriends.nicoの魅力を理解しやすいチュートリアルに仕上がりました。 社内デザイナチームの協力も受けて開発は順調に進み、9/27にサービスリリースされました。

チームUK

• uchiyu (GitHub/Qiita)
• kabik (GitHub)

このチームは画面を見ていないときでもマストドンのタイムラインを追いたいという思いから、『マストドンのトゥートを読み上げるデスクトップアプリ(Tootalk)』の作成に挑戦しました。

前期のPHPチームと同じくElectronのフレームワークを使い、ゼロベースからのアプリ開発を行いました。 Tootalkはマストドンから取得したテキストデータを読み上げ用のフィルターを通して正規化し、WebSpeechAPIを通して発声させる仕組みになっています。

惜しくもインターン期間中にリリースすることはできませんでしたが、最終週には社内デモができる形までは辿リついていました。

チームaneula

• kuromen__ (GitHub)
• tarotaro0

このチームは「自分の名前を含んだトゥートや、自分の興味関心がある話題が出た際に見逃さないようにしたい」という想いから、『キーワードハイライティング&Push通知』の機能を開発し、9/29にサービスへリリースされました。

ユーザーはキーワード管理画面でハイライティング及びPush通知したいキーワード（自分の名前や気になる話題など）を入力します。 ブラウザが登録されたキーワードを含むメッセージ(トゥート)を受信すると、画面上で該当キーワードがオレンジ色にハイライト表示され、Push通知(Web Notifications)が送られます。

終わりに

以上、ドワンゴのインターンシップ第2クールの様子をお届けしました。 インターン生からの感想では、「コミュニティマネジメントの概念が勉強になった」、「サービスの文化や理念を深く知ることが機能開発には欠かせないことを実体験から学べて良かった」などのコメントが多く、サービスの文化にフォーカスした開発について多く学んでいただけたようです。

インターンシップ最終日には、全ての機能がサービスイン(読み上げアプリも手元で実行）されたfriends.nicoの様子を皆で眺めながら懇親会を行いました。 自分たちで考え作り上げたプロダクトが実際にユーザーに使われている風景を見て、プロダクトを開発するということやサービスを育てるということの魅力を体感してもらえたのではないでしょうか。

はじめに

はじめまして。ニコニコ生放送でマイクロサービスチームのグループリーダーを務めています、 ビビる(@vivil@friends.nico) です。以前歌舞伎座.techでニコニコ生放送フロント レガシーシステムの改善の発表をさせていただきました。

ニコニコ生放送（以下「生放送」）ではバックエンド・フロントエンドのサーバーを建てる環境として、2016年からDocker Swarmを採用し始めています。ここではその際に得た知見等を書いていきます。 ご意見・ご質問等あればコメント・トゥート等でお声をおかけ下さい。

何故docker化を始めたの？

マイクロサービス化の機運

生放送は肥大化したモノリシックなサービスが2つ並列運用されており、それぞれロジックを保有する見通しの悪い状態になっていました。 そこで、各種のロジックをマイクロサービスとして切り出すことで、サービス全体の見通しを良くする為にマイクロサービス化を進めることになりました。

ポータビリティ

生放送は機材の関係で色々な環境で動くのが要求されるため、フロントエンド/バックエンドともにポータビリティ性の高いコンテナ化が求められ、技術的にはDockerが妥当であろうという結論に達しました。

フロントエンドの分離

フロントエンドサービスをScalaから脱却する / バックエンドサービスはScalaを引き続き使う

従来、フロントエンドエンジニアはサーバーサイドも触る必要があったため、Scala/TypeScript/SCSS/Rakeを理解している必要がありました。（一部PHPが必要なこともありました）   フロントエンドエンジニアが複数言語を覚える負荷を下げるため・Scalaのコンパイル時間を減らす為に、サーバーサイドをTypeScriptで書きたい要望が出ました。
一方、バックエンドサービスに関しては利便性等を考慮して、引き続きScalaを利用していく方針の為、それぞれ独立した環境で実行できるDockerを利用することになりました。

スケーラビリティの向上

超会議や人気アニメ一挙放送など、多数の来場者が予想される際にはインスタンスを増やして、たくさんの方に視聴していただけるようにし、人が少ない時間帯はスケールダウンさせて、別用途に利用する等、柔軟に対応出来るようにしたい意図がありました。

なんでSwarmなの？

2016年当時、Dockerのクラスタリング技術としてはKubernetes or Swarmの二択であり、

• Docker公式のSwarmのほうが後々廃れにくいだろう
• 知見が社内にほぼない状態だったので、挑戦していきたい

と考えたため、Swarmを選定しました

サービス構成

マシン数

現状70台以上のサーバーでクラスタを組んで運用されています。

構成

Blue-Green Deploy

フロントエンドサービスについて、 Blue-Greenの2系統準備しています。 Coldインスタンスにデプロイして動作確認後、Hotとスワップすることで無停止で新バージョンの動作確認/デプロイを行うことが出来ます。

また、問題が発覚した際、従来のScalaベースのシステムでは数十分デプロイに時間がかかっていたのが、Blue-Greenデプロイを実装した現在では3分程度でロールバックできるようになりました。

監視

コンテナについてはcAdvisor -> Prometheus -> Alertmanager -> Slack の流れでアラートを飛ばすようにしています。

Web上でも、Grafanaを使ってPrometheusの情報をリアルタイム監視できるように整えています。

ホスト単位での監視はインフラチームが構築したZabbixで行っています。

Swarmについての知見

以下に、半年以上Swarmを本番運用して得られた知見を紹介します。

未解決

Dockerのバージョンアップで不具合が出ることがある

無停止で更新すると、Ingressネットワークが不通になったり、jobが不安定になったりと不具合が出ることがあったため、Dockerのバージョンアップは一度サービスを止めてメンテナンスを行っています。

vip/ingress network周りが不安定になることがある

現在進行系で不安定になることがあります。ネットワークが極稀に数秒詰まったりします。安定稼働に向けて引き続き改善を進めています。

解決済み

アクセス元IPの取得ができない

Swarmの仕様上、アクセス元IPがSwarmのvipになっていた問題がありました。ネットワーク設定をhostmodeにすることで、解決しました。

カーネルパラメータ

Docker機材にはカーネルパラメータのチューニングが必要でした。（未だに試行錯誤はしています）

具体的に一部事例を紹介させていただくと、コンテナを多数建てるとホストマシンのARPキャッシュが溢れる事があったため、GCの閾値を上げています。

  "net.ipv4.neigh.default.gc_thresh1": 4096
  "net.ipv4.neigh.default.gc_thresh2": 8192
  "net.ipv4.neigh.default.gc_thresh3": 8192

個人的な感想

以下は個人的な感想です。

Docker / Swarm 使ってみてどうだった？

色々アプリケーションを追加する必要なく、Dockerさえ入れられれば立ち上げられるので、とても便利でした。

アプリケーション開発者も、サーバー側の心配をせずにアプリケーション実装に集中できるので楽になったと思います。（特に、この変更によってフロントエンドエンジニアはTypeScript/SCSSに集中できるようになり、効率が上がったと言われています）

今まで1つのモノリシックサービスのデプロイを週に3回やる、と言うかたちから、毎日特定のサービスのみ複数回更新できる、というかたちになったので、更新頻度をあげられるようになったのは良かったと思っています。

今後はどうする？

マイクロサービスをどんどん増やす方針なので、より使いやすいプラットフォームになるよう、改善を進めていきたいと考えています。

10月16日から開催されているDockercon EU 17で、Kubernetesの公式サポートが発表されました。
今後、KubernetesとSwarmがどうなっていくのか、ますます目が離せないとても刺激的な状況です。

エンジニア募集中です

さて、企業ブースでは「ドワンゴからの挑戦状」と題したプログラミング課題を用意し、正解者には先着順でアスキードワンゴの技術書をプレゼントする企画を実施しました。「ヒントが欲しい」「解き方を教えてください」という要望も多かったので、解法をJavaScriptによるサンプルコードを添えて紹介します。

解答と解説

Q1 : 101

function gcd(x, y) {

  let r

  while (y > 0) {

  r = x % y

  x = y

  y = r

  }

  return x

}

const a1 = gcd(2525, 5252)

Q2 : 2859870693

const TWO_POW_32 = Math.pow(2, 32)

let arr = [a1]

for (let i = 1 ; i <= 1000 ; i ++) {

  arr[i] = (arr[i - 1] * 2525 + 5252) % TWO_POW_32

}

const a2 = arr[1000]

Q3 : [2355222565, 3890716245, 434637493, 1285940997, 3265016661, 5746901]

const a3 = [...'dwango'].map(v => arr[v.charCodeAt(0)])

Q4 : 2110379477

const sortedArr = arr.sort((a, b) => a - b)

const a4 = sortedArr[500]

問題 : 3322

const answerArr = a3.concat([a1, a2, a4])

const answer = ((answerArr.reduce((a, x) => a + x))% TWO_POW_32).toString().slice(0, 4)

蛇足

a1 = 2525.gcd(5252)

puts "Q1 : #{a1}"

arr = [a1]

1.upto(1000) { |idx| arr[idx] = (arr[idx - 1] * 2525 + 5252) % 2 ** 32 }

a2 = arr[1000]

puts "Q2 : #{a2}"

a3 = "dwango".each_byte.map { |idx| arr[idx] }

puts "Q3 : #{a3}"

a4 = arr.sort[500]

puts "Q4 : #{a4}"

answer = (a3.concat([a1, a2, a4]).sum % 2 ** 32).to_s[0..3]

puts "Answer : #{answer}"

まとめ

インターン概要

成果物

anancus

この機能のポイントは、同意できないが回答したい人のために必ず :thinking_face: という選択肢が入ること、結果のパーセンテージがざっくりで表示されることなどです。friends.nicoのゆるいコミュニケーションの空気にマッチした、楽しい機能を実装してくれました。

mahout

PHP

こんにちは。チームPHPです。

チーム名は、Mastodonが象の祖先ということで、PHPにしました。

我々がこのインターンシップでどんなことをしたかを報告させて頂きます。

不満とその解決

まず、現在のfriends.nicoに対するユーザーが抱える不満を挙げていきました。その結果、「friends.nicoユーザーはローカルタイムラインを中心に見ているのに、ウェブクライアントはPCの全画面で見ることを想定していて、省スペース派、ネイティブアプリ派のユーザーが不満を抱えているだろう」という意見でまとまりました。 

その不満を解決するために、「frineds.nico専用の省スペースクライアントアプリ」を作ることにしました。ここでいう省スペースとは、画面の端に置いて鑑賞できるようなものを想定しています。また、Mastodonの全てのインスタンスではなく、frineds.nicoに限定したのは、よりユーザーの体験を具体的に想像できて、プロダクトとしての魅力を高められると思ったからです。

 コンセプトを叶えるための機能として

• 省スペース
• 高いカスタマイズ性
• friends.nicoに特化

の3点を意識しました。省スペースはミニマリズムとして当然です。しかし、どのような省スペース性や機能が欲しいかというのは個人によって結構異なるので、それぞれの需要に応えられるようにカスタマイズできるようにしたいと考えました。

 成果物

 実際に開発したものが、これです。開発はメンバーの技術とマルチプラットフォームでの動作を考え、Electronを使用しました。フロントの実装にはマストドン本家と同様にReactを採用しました。 

左が、僕らの作ったアプリのホーム画面です。ウェブクライアントでは別々になっているローカルタイムライン、ホーム、通知を1つのタイムラインで見れるようにして、画面の端に置いておける省スペースアプリとなりました。また、タイムラインの1カラムも出来るだけ細くしました。しかし、friends.nico特有のニコるをしやすいように、ニコるボタンは大きめに設定しています。

これは、設定画面です。他画面が必要な時はドロワーを横から出しています。friends.nicoではトゥートの更新が非常に速いので、画面遷移ではなく画面拡張をすることによって、タイムラインを常に表示し、話題においてけぼりにならないようにしました。設定からは、何をタイムラインに流したり、通知するかを選べたり、アプリのテーマカラーを変えられたりします。

これは、ホワイトバージョンです。α版を使ってくれた人からは人気がありました。ちなみに、タイムラインの右上のピンボタンをクリックすることで最前面表示もできます。これもレビュー会で好評だった機能でした。

成果発表会を通して

成果発表会を行い、メンターの方からフィードバックを頂きました。僕らは、オープンソースとして公開することを目指しましたが、残念ながらそれは叶いませんでした。

しかし、省スペース性の追求という、自分たちのコンセプトは間違っていないことは開発を通して感じました。しかし、現段階でユーザーが満足に使えるレベルには達していない、コードが汚くて今後誰かが引き継げるような状態ではない、というのが問題でした。反省点としては、開発の全体の構成や、メンバーの技術力を考慮した予定管理ができず、行き当たりばったりの開発になっていたことです。悔しいですが、これからの開発に活かせれば良いかと思います。

最後に

他の社員さんと同じ部屋で開発を行い、多くの社員さんが自由に仕事をしているのを肌で感じる4週間でした。僕らも伸び伸びとプロダクトの考案・開発をしながら、的確なフィードバックを受けられて学ぶことの多いインターンシップとなりました。このような機会を提供していただき、本当にありがとうございました。

まとめ

こんにちは、ニコニコ生放送開発の太田です。

今回は新配信移行の延期、延長と予約の無料化の件についてお伝えさせていただきます。

■新配信全面移行を延期しました

8月24日に予定しておりました新配信全面移行ですが、移行日を延期させていただきました。ユーザーの皆さんからのご意見ご要望にて、新配信で安定した配信や視聴ができないとの多くのお声をいただいておりました。

新配信の全面移行前にまだ改善出来る余地があり、皆さんに安心して新配信で生放送を配信・視聴していただける状態にするため、延期させていただくこととなりました。

新配信全面移行の予定日は、現在まだ未定とさせていただいておりますが、確定次第ニコニコインフォにてご案内させていただきます。

また、新配信は旧配信から仕様が大きく変更されるため、ユーザーの皆さんにはご不便をおかけしてしまい、大変申し訳なく思っております。ヘルプやインフォでの情報の拡充を図って参ります。

詳細は ユーザー生放送『新配信』への移行延期のお知らせ にてご確認ください。

■新配信の延長と予約が無料化されます

8月24日より新配信での番組の予約が開始されます。前回ご案内差し上げた通り、新配信での番組は予約・延長が無料になります。

なお、大変恐縮ですが旧配信につきましては無料化の対象外となります。

まだ新配信をお試しされたことのない方は、この機会に是非新配信をお試しいただければと思います。

こちらにつきましても詳細は 【8/18更新】ニコニコ生放送の番組延長、配信予約を無料化します にてご確認ください。

■最後に

現在もユーザーの皆さんから新配信に関するご意見ご要望をたくさん頂戴しております。

私達生放送開発者も毎日拝見させていただき、チーム内で検討をさせていただいております。本当にありがとうございます。

今後も皆さんの率直なご意見・ご要望をこちらからお寄せ下さい。

よろしくおねがいします。

こんにちは、ニコニコ生放送開発の太田です。

今回は皆さんからご意見・ご要望の多かった延長と予約の仕様について、それから動画引用放送の件についてのご報告です。

■延長・予約が無料（ポイント不要）になりました

8月24日から新配信では延長と予約に必要なポイントを撤廃させていただくことになりました。今まで新配信では「初回30分の延長のみ無料」とさせていただいておりましたが、新配信移行してからは「最大6時間までの延長・予約を無料」への変更となります。

これで時間を気にせずにゆっくりと生放送をお楽しみいただけるようになると非常に嬉しいです。（私もこれでたっぷり生放送配信ができると今から楽しみです。過疎放送ですが…！ｗ）

詳細は ニコニコインフォ - ニコニコ生放送の番組延長、配信予約を無料化します をご覧ください！

■動画引用放送を継続してご利用いただけるように対応します

「8月24日に新配信全面移行をすると動画紹介放送が行えなくなる」という声を多数いただいておりました。これまで長く継続されてきた番組も多く、私達としてもニコニコ独自の文化として機能を活かしていただいていることを嬉しく思っております。

そこで、新配信での動画引用機能対応までの期間「動画紹介カテゴリ」での放送についてのみ、旧配信でのこれまで通りの番組作成が行えるようにいたします。

なお、動画紹介カテゴリでの旧配信番組につきましては同時に50枠を予定しております。

同内容が ニコニコインフォ - 【8/14更新】ユーザー生放送『新配信』への移行のお知らせ にも掲載されております。

その他の番組につきましては、新配信での放送となりますが、新配信に伴うご不満やご意見は引き続きユーザーの皆さんのご意見を頂戴しながら改善を進めて参ります。

こちらまでご意見をお寄せください。

■最後に

今回はやっとユーザーの皆さんからのお声に対してお応えすることができた2件のご報告ができました。

私を含め開発者、関係者で「何がニコ生に必要なのか」「ユーザーの皆さんが欲している物は何か」「そもそもニコ生でどうやってニコニコしてもらえるか」を改めて見つめ直し、こうしてひとつの歩みを進められたのはユーザーの皆さんのお声があればこそです。本当にありがとうございました。

とは言え、まだまだ課題はたくさん残っています。これからもより良いサービスをユーザーの皆さんと作り上げていきたいと、開発者・関係者一同願っております。これからもどうかよろしくお願いいたします。

こんにちは、ニコニコ生放送開発の太田です。

今回は配信者コメント（通称運コメ）の色についてと、ユーザーさんよりいただいた不具合について調査結果が出た件と、ご意見ご要望フォームについてのご報告です。


■運コメの色について

> お世話になっております。いろいろ新配信でテストとかしていますがいくつか気になった点がありましたので書かせていただきます。まず主コメのHTMLタグが全て無効化されているようです。
> 白一色というのも味気ないなとも思うのでfont size や color あとは強調表示や改行とかは実装してもらいたいなと思っております。

配信者コメント通称運コメについてですが、色についてはHTML5プレイヤーでも左下の「コマンド」からご指定が可能です。

外部ツールからの運コメ投稿の場合の色の指定方法はこちらの大百科記事が参考になると思います。
→ ニコニコ大百科 運コメAPI

フォントサイズとHTMLタグについてですが、フォントサイズについては文字数によって自動的にサイズが変動する仕様となっております。HTMLタグについては現在HTML5プレイヤーからは送信ができない仕様となっておりますが、こちらは改善タスクとして検討させていただきます。


■新配信の不具合について

（ 新配信に関するご報告のコメントより ）

■はじめに

こんにちは、ニコニコ生放送開発の太田です。

多数のご意見ご要望、コメントありがとうございます。

思っていた以上にフォームからのご意見ご要望・コメントを頂戴しており、今まで私達が聞く事が出来ていなかったと痛感し、反省するとともに非常にありがたく拝見させていただいております。

予想を上回る数のご意見を頂戴しており、対応が追いついておらずご報告の進捗が遅くなってしまっている点につきまして、お詫びさせていただきます。大変申し訳ございません。

今回は視聴時の画質が頻繁に切り替わったり明らかに旧配信よりも低い場合の、一つの対策についてご報告をさせていただきます。

■視聴時の画質が旧配信よりも低い、画質が頻繁に変わる

新配信をHTML5プレイヤーで視聴している際に以下のような現象が発生した場合、お試しいただきたい点についてご説明させていただきます。

・映像と音声が一瞬だけ暗転（1秒未満）するがすぐに映像と音声が流れ始める
・そのたびに画質が悪くなったり綺麗になったりする

HTML5プレイヤーには、回線の通信状況を見ながら自動的に最適と思われるビットレートへ変更する仕組みがあり、これが頻繁に切り替わってしまうと上記の現象が発生するケースがございます。

ビットレートの設定を手動で固定値にしていただくことで、状況が改善される可能性があります。

（手順）

HTML5プレイヤーの歯車マークから、画質切替の「自動（数字）」と書かれているところを「2Mbps」または「1Mbps」へ切り替える

「2Mbps」にしていただくのが画質は最も良くなりますが、もし定期的にプレイヤーの映像が出る箇所にくるくると回る、読み込み中を示す表示が出る場合は「1Mbps」へビットレートを下げていただくと、改善される可能性があります。

・旧配信より明らかに画質が悪い

こちらも上記のビットレートを自動選択にしている際に、「自動（384k）」や「自動（192k）」になっている場合に発生している可能性があります。

同様に「2Mbps」や「1Mbps」へ手動でご設定いただく事で画質が改善される可能性があります。ぜひお試しください。

これらビットレートの設定はHTML5プレイヤーのみ設定可能となっております。また、新配信の画質などについては別の原因が発生していることもございます。

改善が見られない場合は、お手数をおかけして恐縮ですが こちら より、発生したお時間とご覧いただいていた番組のID、ご利用になられていた環境などを併せてお寄せ頂けますようお願いいたします。

また、こちらのページ 【7/31更新】「新配信」でお困りの方へ にて、新配信で確認されている不具合や疑問、解決策や現在の状況について記載させていただいております。

ご参考になれば幸いです。

■最後に

繰り返しとなってしまいますが、本ブロマガで私からの回答とさせていただくのは原則として新配信に関わる事、ニコ生のエンジニアとしてお答えできる事、に限らせていただいております。恐縮ではありますが、ご了承下さい。

ですが、頂戴したご意見につきましてはそれぞれ担当者を含め、全て拝見させていただいており、本当に貴重なユーザーさんの生のご意見として検討課題とさせていただいてます。

今後も引き続き こちら より、ご意見ご要望お待ちしております。

よろしくお願いいたします。

こんにちは、ニコニコ生放送開発の太田です。

先週の記事にてご案内させていただきましたご意見ご要望のフォームへの多数のご回答、ありがとうございます。

本日12時半までにお寄せ頂きましたご意見ご要望の中から「動画引用について」と「ロスタイムについて」ご回答をさせていただきたいと思います。

※重複する内容や同様のご意見は抜粋してのご紹介させていただきます。また、ほかにも多数のご意見ご要望を頂戴しておりますが、順次ご報告させていただきます。予めご了承下さい。

■動画引用について

> 結局はもともとあった機能を引き継げず、準備もせずに新移行しているんですよね？

> 動画放送(動画引用を利用した動画紹介放送)が出来ない状態で新配信に完全移行というのは明らかにおかしいのではないでしょうか？

> 動画引用機能がなければ個人的には無価値ですし、他のライブ配信サービスと比較しても唯一の個性だと思います。

> 動画紹介放送としては、動画引用ができない部分で致命的。テストするにも動画を読み込めない。それとも動画紹介放送はもうできないのですか？

> 個人的には、動画引用不可のままの移行というのは、ニコニコ生放送の存在意義を無くすと同義な内容だと思います。ですが、様々な数字的理由で、「切り捨てて構わない」と運営的判断が成されたのであろうことも、理解できないことではありません。ただ、これほどまでに「切り捨てられる存在」になったのだな、ということをいささか寂しく思います。

> 動画引用ができない間は旧配信も残すべきだ

動画引用の機能が8/24から10月に新配信での対応予定の間利用できなくなる件について、多数のご意見ご要望ありがとうございます。

まず、そもそも使える機能が減っていると言うご指摘、誠にその通りだと思います。

ニコニコ動画とニコニコ生放送という2つのサービスで連携し、利用できる機能が強みである・ユニークな個性であるというお言葉ありがとうございます。

確かにニコニコだからこそできる事、強みも弱みも理解した上でできうる限り機能を提供し、「真に求めるものが何であるか」というユーザーの皆さんのお声に耳を傾けていきたいと考えています。

私達開発者も含め中の人一同、ユーザーさんにニコニコしていただけるサービスを目指す気持ちには偽りはございません。

いつもいつもお待ち下さいばかりになってしまって本当に心苦しく恐縮ですが、社内でも関係各所に協力を仰ぎつつ、気持ち良くご利用いただける状態・サービスとは何かを常に念頭におき、より良い形で提供できるように努力して参ります。

■ロスタイムについて

> 配信枠終了後、配信ソフトがすぐ切断食らうようにした理由が知りたい

ロスタイムと呼ばれている現象について、まずこれが現状どのような仕組みによって発生しているのか？からご説明いたします。

旧配信と言われる既存のニコ生の仕組みでは、30分の番組が終了時間を迎えた際に自動的に枠が閉じる仕様になっていますが、この「番組の枠を終了」させるのは1分おきに実行される定期実行処理によります。

簡単に流れを書きますと、

※【前提条件】生放送の配信ページを開いていない状態

1. 毎分放送中の番組一覧から終了時刻を迎えた（過ぎた）放送が無いかチェック

2. 該当する番組があった場合には、それぞれに終了の処理を行う

3. 該当する番組に対して「/disconnect」の運コメを送出する

4. プレイヤーは3の「/disconnect」の運コメを受信した場合、切断などの終了処理を行う

と言う仕組みになっています。

配信者の方が意図的に放送を終了した場合には、上記フローの2番目から実行を即時に行います。

また、生放送の配信ページを開いている場合、配信ツールが終了時刻を迎えた時点で上記3の処理を行います。その為、配信者の方が終了した場合はロスタイムは存在せず、すぐに番組が終了します。

ところが、上記フローの1番目の仕様により、定期実行処理による場合は最大59秒程度「番組は終了時刻を過ぎているのに、終了処理が行われない時間」が発生することになります。

例：20時00分01秒に放送開始した「テスト放送」というタイトルの番組が仮にあったとします。この番組の放送終了時刻は20時30分01秒になります。

ここで、自然に番組が終了する20時30分00秒になったとします。

1分おきに起動する定期実行処理が20時30分00秒時点で終了対象となる番組をチェックしますが、20時30分00秒の時点では「テスト放送」は終了対象となっておらず、59秒後の20時31分00秒に起動する次の定期実行処理で初めて終了処理が開始されます。

つまり、59秒間放送が継続します。これがロスタイムです。

更に、この1分おきの定期実行処理が重く1分以内に終了せず、59秒を超えても番組の終了処理が完了しないケースが発生するようになり、結果的に1〜2分程度のロスタイムが発生する事がありました。

新配信でも処理の内容は若干異なるものの、フローとしては旧配信のものと同様となっております。

ですが、新配信の運コメは外部ツールに対応していないという問題があり、前提条件の「配信ページを開いていない」がクリアできない状態になっておりました。

それにより、終了時刻になった時点で配信ページを開いている番組では終了の通知が行われて、ロスタイム無しに番組が終了していました。

また、新配信につきましては旧配信よりも内部の定期実行処理の実行時間が短いため更にロスタイムは発生しにくくなっている状況です。

以上がロスタイムそのものと、そして外部配信ツールが終了後すぐに切断されるようになった件に関するご説明です。

> 放送中にマイページから放送枠を終了させた場合にも、次枠誘導を出せるように/disconnetを1分遅らせていただけないでしょうか。

現在、多くのユーザーさんがニコ生を外部ツールを用いて配信していただいている実情を理解しております。（私も色々な作者さんがお作りになっているツールを利用させていただいております。ニコ生自体がユーザーさんに使いやすい環境を提供していないにも関わらず、とても便利なツールを作成していただいてる事に感謝の念に絶えません）

ロスタイムの次枠誘導に関しましては、非常に便利だと痛感しております。

どういった形になるかは分かりませんが、使いやすく・配信者も視聴者も便利になるように改善を検討させていただきます。ご意見ありがとうございます。

■最後に

今回は動画引用と、ロスタイムについての回答についてご報告させていただきました。

次回も続いて頂戴したご意見ご要望のご紹介と回答をご報告させていただきたいと考えております。

引き続きご意見ご要望についての投稿を こちら よりお待ちしております。

よろしくお願いいたします。

こんにちは、ニコニコ生放送開発の太田です。

昨日公開させていただいた記事に対する多くのご反応とご意見、ありがとうございます。

■はじめに

前回の記事につきまして二点お詫びをさせていただきたいです。

一点目は、動画引用の件で「絶賛実装中」という表現についてです。

ユーザーさんのご反応で動画引用を待望されている内容を多数拝見し、期待されているという事で浮かれてしまい「絶賛」と言う表現を安易に用いてしまいました。

まだご利用いただける状態でもなく、ユーザーさんに不便を強いている中でする表現としては不適切でした。申し訳ございませんでした。

二点目についてですが、「殆ど全部待ってくれと言ってるだけで内容が無い」と言うご意見についてです。

こちらについては返す言葉もございません。出来る限りではございますが、確定した事は素早く本ブロマガの記事としてユーザーの皆さんに公開させていただきます。それまではどうしても新情報に欠ける内容になってしまうかも知れません。申し訳ございません。

■ご意見について

本日18時半時点で頂戴いたしましたコメントでのご意見について、昨日のコメントレスポンスでは書ききれなかった点も含めて、改めてご返答させていただきます。

＞ くらふとさん ナスさん yamaさん

・タイムシフトが29分で止まってしまう件について

先日のコメントにて記載させていただきました通り、旧配信のタイムシフトにて現象を確認しております。現在調査、対応中となりますので進捗につきましては追ってご報告させていただきます。ご指摘・ご確認ありがとうございました！

＞ しょうひらさん 岐阜のかっちゃんさん T-23さん you1さん gwinさん ユウスケさん

・動画引用が間に合わないのに何故全枠移行するのか？

動画引用につきましてですが、おっしゃられている事は痛いほど分かります。そして、動画引用ができない事で離れてしまったユーザーさんは、その後で実装されても戻ってこないと言うご意見につきましても深く頷けます。

しかし、大枠の判断として移行する事になったとのことです。

現在社内で動画引用の対応について再度検討していただけるよう、ユーザーさんからのご意見を参考にさせていただき、現状をできるだけ共有し良い解決策を提案したいと思っております。

＞ とーさん

・184コメントが無くなる？

184コメントにつきましては昨日のコメントにて記載させていただいた通り、無くなると言う計画は聞いておりません。今後もご愛顧いただけますよう、使い勝手の良いサービスを目指して参ります。よろしくお願いします。

＞ mizuPEIさん

・ニコニコがつぶれるまで配信するわ

大船…とはまだ言えませんが、皆さんが安心してご利用いただけるようなサービスとなるように、今後も改善を心がけて行くよう継続して努力して参ります。その一歩として、今回のブロマガ記事のようにまずは情報公開から始めさせていただきます。

＞ you1さん

・新配信が重い、途切れると言った問題はどの程度把握しているか

新配信は旧配信と比較してCPUの使用率が増えています。

CPUの使用率につきましては、後日本ブロマガにて新配信の解説記事を書かせていただきます。

途切れる問題につきましても、ビットレートの増加や通信方法の変更にともなって途切れが発生するケースはございます。この対応策といたしまして、アダプティブビットレートの対応、手動による視聴ビットレート変更機能の対応をさせていただきました。

対応するクライアント（現在PC HTML5ブラウザ、iOSアプリ）でご視聴の際には、以下の設定（画像）を調整する事で途切れにくくなる可能性がございます。

PCの場合: 歯車アイコンをクリックし、

ビットレートを変更してお試しください。


iOSの場合: 設定画面の「生放送画質」から、

「安定性を優先」をお試しください。

こちらでも改善されない場合は、大変お手数ですが「現象が発生した生放送の番組ID」「発生した時刻」を添えてお問い合わせいただけますと、調査がしやすくなりとても助かります。ご面倒ではありますが、ご協力いただけますと幸いです。

＞ なんばさん

・新配信で音声がおかしくなる

タイムシフトを拝見させていただきました。現象についても確認させていただきました。

音が早回しになって、0.5秒ぐらいおきに音が途切れ途切れになっているという現象ですね。担当部署にて調査を開始させていただきました。

ご使用いただいている環境や配信ツールの設定も含めてこちらへご投稿いただけますでしょうか。お手数をおかけして申し訳ございませんが、よろしくお願いいたします。

＞ weep.jpさん

・ニコキャスは復活するの？

PVでは帰ってくると言われてましたね…

＞ かたくりこさん

・フォローしている生放送がすぐに視聴できない

この現象につきましては、生放送開始の情報通知のやり取りの仕組みが古い為発生している現象となっています。こちらはキャッシュ戦略の見直しや、通知のやり取りのフロー見直しを検討させていただきたいです。ご意見ありがとうございます。

・10月の詳細発表について

今のところお伝えさせていただける新しい情報がございません…申し訳ありません。

＞ あやめんさん

・8年やって結果がこれか

うっ…厳しいご意見ごもっともです。

おっしゃる通り、技術者としてまだまだ学ぶところがたくさんあります。web業界の日進月歩は本当に早く、私もより一層の精進が必要だと痛感しております。稚拙な面や至らない点も多々あると思います。

そして、8年もやっていてと言う点についてもう一つ私に不足している事がございます。

それは8年も中の人をやってしまった結果、真の意味でのユーザー目線を忘れつつある、という事です。

厳しいお言葉とは言え、真摯に受け止めさせていただき今後に活かせるよう努力致します。ご意見ありがとうございました。

＞ koichilさん

・前回の放送を使いまわす時にコミュごとに分けて欲しい

ご声援まことにありがとうございます。

現在は仕様上、おっしゃられている通り最も直近の放送の情報を取得する仕組みになっております。コミュニティごとの直近のデータを取得すると言う機能につきましては、検討させていただきます。

貴重なご意見ありがとうございました。

＞ parakeraさん

・宣伝広告の代わりに投げ銭機能が欲しい

・トップページをランキングにして欲しい

サービス改善のご提案、ありがとうございます。

私は技術者（エンジニア）ですので、システムの挙動や実装に関するご提案やご意見についてはお話させていただく事ができるのですが、サービスの見た目等に関しましては専門外となってしまいますので、担当者へ頂戴したご意見をお伝えさせていただきました。

貴重なご意見ありがとうございます。

■記事と回答について

以上、本日18時半時点でいただいていたコメントについてご回答させていただきました。

コメントについては大変申し訳ございませんが、今後個別での対応が難しいため記事本文にてご回答とさせていただきます。

また、私がお答えできること・担当している箇所はニコニコ生放送となっておりますので、それ以外の事となりますとお答えできかねる事が多くなってしまいます。

より広範囲のお話になってしまいますと、話の内容が発散してしまうので技術者として話すエンジニアブロマガの主旨から逸れてしまう懸念もございます。

そこで、本記事並びに私が投稿させていただく一連の「新配信についてのご報告」につきましては、ニコ生の新配信に関連した内容のみを取り扱わせていただきたいと思います。

まことに勝手ではありますが、ご理解ご容赦のほどよろしくお願いいたします。

■最後に

たくさんのご意見ご要望をお寄せいただきまことにありがとうございます。

アンケートフォームにたくさんのご意見・ご要望を頂戴しております。この週末にまとめさせていただき、週明けに次回記事にて回答させていただきます。

引き続き、新配信に関するご意見・ご要望につきましては 以下のリンクよりお寄せ下さい。

https://goo.gl/forms/P99F1DyUb40HzHDi2

よろしくお願いいたします！

この記事はドワンゴ Advent Calendar 2016 12/24の記事です。昨日は@gomi_ningenの「大規模ネイティブアプリへのプッシュ通知機能導入にあたって考えたこと」でした。

ドワンゴの塩谷（@kwappa）です。2016年11月より「技術コミュニケーション室」（以下技コミ）という部署の室長を清水（@meso）から引き継ぎました。

技コミ is 何？という質問を時々受けるので、この記事を書くことにしました。自分の仕事を整理する、という意味もあるので一石二鳥です。

技コミのミッション

技コミのミッションで最も大切なもの。それは「エンジニアの生産性をあげる」ことです。

ドワンゴには現在400人以上のエンジニアがいます。そのエンジニアたちが最大限の生産性を発揮できるように、のびのびと仕事をしてもらうための環境を整えたり問題を解決したりすることで、サービスやプロダクトをよりよいものにしたり、まだ世の中にないものを作り出していけるよう支援していくのが主な仕事です。

そのためにどんなことをしているか、実際の取り組みをご紹介します。

開発環境の整備

情シスやインフラと連携し、GitHub EnterpriseやSlack、IntelliJ IDEAなど、エンジニア全体で共通して使えるようなツールの選定や導入、運用管理をしています。最近ではJFrog Artifactoryというリポジトリ管理ツールを各チームに使ってもらい始めています。

エンジニアのコミュニケーション促進

週に一度、社内で「エンジニアLT」というイベントを開催しています。持ち回りで毎週5人をアサインし、発表5分 + 質疑応答5分のプレゼンをしてもらいます。お題は自由なので、業務で困ったことの共有から自分で書いた技術系同人誌の即売まで、幅広いテーマの発表を聞くことができます。飛び入り発表をしていくエンジニアも多く、自作のサービスやアプリをデモする場としても活気にあふれています。昨年リリースしたサービス「ニコナレ」も、原型はエンジニアLTで発表されたのが最初でした。

また、キャリアや技術で悩んでいるエンジニアの相談に乗ったりアドバイスをするために、「お悩み相談室」という時間を設定しています。グループウェアに「お悩み相談室」という予定が用意してあるので、相談したいエンジニアが自分で予定を確保するというシンプルな仕組みで、結構な頻度で利用されています。深刻度はさまざまですが、悩み事の一次受けルートのひとつとして機能し始めているように感じています。

ドワンゴのプレゼンス向上

カンファレンスのスポンサーになったり、コミュニティや学会に勉強会の会場を提供したり、歌舞伎座.techという勉強会を開催したりといった活動を通して、社内外のエンジニアのみなさんにドワンゴのよさを知ってもらおうとしています。

エンジニア採用

人事部と連携し、エンジニアの新卒・中途採用を推進するのも重要なミッションのひとつです。書類審査や面接といった直接的な業務はもちろんですが、前述した「プレゼンス向上」とも関係するさまざまな取り組みを行なっています。

ドワンゴでエンジニアとして働くことに興味を持っていただいたら、ぜひこちらからご連絡ください。おまちしています！（これも採用活動の一環）

新卒研修

新卒社員の研修プログラムを考え実施するのも技コミが担当しています。scala_textというオリジナルの教材による座学、各分野で必読の技術書を読んでのワークショップ、チーム開発体験など、少しでも一人前に近い状態で配属できるよう、オリジナルの内容でしっかりと研修を行なっています。

その他にやっていること

最大のミッションは「エンジニアの生産性をあげる」ですが、そのほかにもユニークな仕事がたくさんあります。いくつか紹介しましょう。

アスキードワンゴ

「エンジニアに最も近い技術書ブランド」を掲げるアスキードワンゴの編集部は技コミに所属しています。

出版業務は鈴木嘉平（@kahei）編集長が行なっていますが、ときどき「この本どうします？」などと相談を受けるのは役得感があります。先日「おもしろいですねいっときましょう！」と言ってしまったプロジェクトを公開できる日が楽しみです。

OpenToonz

スタジオジブリで使われていた「Toonz」というアニメーション制作ソフトをオープンソース化したものが「OpenToonz」です。この開発チームも技コミに所属しています。

11月に参考書「OpenToonzではじめるアニメーション制作」が発売され、12月には阿佐ヶ谷ロフトAでイベント「使ってみよう!OpenToonz ~1から始めるアニメ制作~」が開催されるなど、少しずつ注目が集まっているプロダクトです。今後の成果次第では日本のアニメ業界に貢献できるかもしれないという、不思議な縁だが頑張りたくなる仕事です。

準エンジニア試験

カドカワグループの社員に向けて実施される「準エンジニア試験」という制度があります。エンジニアリングを主な職務としていない人向けにソフトウェア開発の試験を実施し、その成績によって「準エンジニア」として認定します。

この試験の実施に向けて、問題の作成、希望者向けに勉強会の実施、試験の立ち会い、採点などを技コミで行なっています。他人のキャリアにも影響してしまう可能性があるので、ものすごく重圧のかかる大変な仕事ですが、エンジニアとそうでない人たちの視点や語彙の溝が埋まればコミュニケーションが円滑になり、結果としてエンジニアの生産性が上がるのは間違いありません。エンジニアにとっても意義のある制度だと思うので、来年度の実施に向けて準備を始めたところです。

まとめ

ドワンゴならではの部署である技術コミュニケーション室についてお話してみました。自分でもいろいろやってるなーと笑ってしまうぐらいなのですが、大半が先代の手柄なので、二代目としてはこれからが腕の見せどころなのです。「ドワンゴは技コミがあるからいいね」と言ってもらえるよう頑張っていきますので、どうぞよろしくお願いいたします。

ドワンゴ Advent Calendar 2016の最終日は、先代の室長にして現在は人事部長になった@mesoです。お楽しみに！

合同プログラミング研修

ドワンゴのエンジニアに必要な基礎知識

スマホアプリ開発体験

Scala 研修

チーム開発実習

に大まかに分かれてもらい、各チームで要件をもとにAPI仕様を話し合い、ドキュメントをきちんと整備しながら進めてもらっています。

まとめ

おまけ

合同プログラミング研修

エンジニアへの Scala 言語研修

Scala と JavaScript が2強ですね。C++ や Erlang も上位に入っているのがドワンゴらしいところでしょうか。逆に Perl はチャンネルすら存在しなかったです。
言語以外の技術要素やエディターなどでも集計してみたのですが、宗教戦争が始まりそうなので公開は控えておきます。

ドワンゴではScala, JavaScript, C++, Erlang, Android/iOS, PHPなどが得意なエンジニアを募集しています！

ドワンゴで、技術イベントなどのスポンサー対応もしている @meso です。

ドワンゴではこのたび、Tokyo Technical Samurai のスポンサーとなることを決めましたので、ご報告させていただくとともに、皆さまに Tokyo Technical Samurai とはなにかを知っていただきたく、エントリを書かせていただきます。

Tokyo Technical Samurai とは

Tokyo Technical Samurai とは、世界的なロボコンである FRC に日本から初めて参加する高校生の集団です。東京工業大学附属科学技術高等学校の有志10名によって形成されています。

公式サイトは こちら

FRC とは

FRC というロボコン自体、聞きなれない方も多いと思います。アメリカで毎年3月〜4月に開催されるのですが、世界17カ国2700チームが登録する大会です。しかもただのロボコンではありません。なんと、参加するのに必要なもろもろの資金を、自分たちで集めたスポンサーからの資金提供で賄わなければならないというルールだというのです。

詳しいインタビュー記事は こちら

様々な技術イベントのスポンサーをしたり、また、自分で東京Node学園祭というカンファレンスを主催した経験からしても、このルールはかなり厳しいものだと思いましたし、同時に、なんとしてもこの高校生たちをFRCの舞台に立たせてあげたいと考えました。

そこで、ドワンゴとしてスポンサーとして支援することを決めたのですが、それだけではなく、当チャンネル上での生放送の配信や、このような記事の配信によってより多くのスポンサー集めの手助けになればと考えております。

これを読んでもし興味を持った方がいらっしゃいましたら、是非彼らを応援してあげてください。よろしくお願いいたします。

なぜElasticsearchなのか？

ニコニコ動画、生放送、静画など、そして今後増えていくニコニコサービスの
検索インデックスを抱えるためには、スケールアウトできることが大前提で、
プロジェクト開始当時に広く利用されていたSolr 3よりElasticsearchが
適していたことが大きな理由です。

どうElasticsearchを使っているのか？

今回は検索エンジンとしての利用事例を話しました。
なお、ログ解析にKibana用途のElasticsearchを別クラスタで構築しています。
それと、検索フォームのサジェスト検索用の辞書作成時にスコア計算用にも利用しています。

アーキテクチャ

だいぶラフな図ですが、検索システム周りのアーキテクチャは図のようになっています。
青い線で示した部分が参照系(検索)で、赤い線で示した部分が更新系(インデックス構築)になります。


まず青い線についてですが、API frontは他システムから検索クエリを受けとったら、Elasticsearch用のクエリに変換し検索します。
(ElasticsearchのQuery DSLは種類が豊富で柔軟なクエリやフィルタが可能ですが、ここでは必要なものだけに限定しています)
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/query-dsl.html

Elasticsearchは検索結果としてコンテンツのID列(一部例外でスコアを含むことがあります)を返し、次にMySQLからタイトルや本文など必要なフィールド情報を取得し、肉付けした結果をAPI frontへ、そしてリクエスト元へと返します。

次に赤い線についてですが、他サービスから「コンテンツが投稿/削除された」「視聴数が上がった」「タイトル/タグが変わった」などの更新メッセージ(JSON形式)がほぼリアルタイムにMessageReceiverへと送られてきます。
MessageReceiverはコンテンツIDを元にハッシュ値を算出し、更新メッセージを該当するRabbitMQのキューに振り分けます。
Indexer & Converterは担当するRabbitMQのキューを監視しており、更新メッセージを取り出し、必要な変換を加えた後にElasticsearchとMySQLへと保存します。

メンテナンスのためのエイリアス利用

運用しているとElasticsearchのインデックスについてアナライザやマッピングの変更の必要性が出てきて、インデックスの再構築(reindex)が必要になることがあります。
その際に、古いインデックスは参照したまま新しいインデックスを裏側で構築し、エイリアスの向き先を変更すればアプリケーション側の改修をすることなく、サービス無停止でのメンテナンスが可能になります。
(インデックスの再構築の際には、number_of_replicasを0(ゼロ)にしておくと、再構築時間が数十パーセントほど短くて済みます)


なお、エイリアスはインデックスの別名という用途以外にも、デフォルトのフィルタ機能を設けたインデックスを提供する用途にも使えます。

index aliases
http://www.elasticsearch.org/guide/en/elasticsearch/reference/current/indices-aliases.html

これまで遭遇したトラブル

遭遇したトラブルで代表的なものとして、スプリットブレイン問題(SpritSplit-brain)があります。

スプリットブレイン問題とは、本来１つのクラスタには1つのマスタノードが存在して、
クラスタの構成を管理するのですが、マスタノードに問題が発生したとクラスタ内で
判断されると、新たなマスタノードが選定され、元のマスタノードと合わせて2つの
マスタノードが存在してしまうというものです。
この問題が発生すると自然に解消することはないため、どちらかのマスタノードを
マスタから降格させる対応が必要になります。

HOW TO AVOID THE SPLIT-BRAIN PROBLEM IN ELASTICSEARCH
http://blog.trifork.com/2013/10/24/how-to-avoid-the-split-brain-problem-in-elasticsearch/

負荷計測とチューニング

どれくらいの検索/インデクシングリクエスト(QPS: Queries Per Secondを許容できるかを計測するために、GatlingやApache JMeterを利用しています。どちらを使うかは計測者の好みに任せてます。

なお、ElasticsearchのGithubリポジトリにはJMeterのテストシナリオがあるので、参考に
してみるのも良いかもしれません。

Gatling
http://gatling.io/

Apache JMeter
http://jmeter.apache.org/

elasticsearch / src / test / resources / jmeter /
https://github.com/elasticsearch/elasticsearch/tree/master/src/test/resources/jmeter

最後に

他にも検索/インデクシングのパフォーマンス・チューニングの例をいくつか紹介する
というような話をしましたが、長くなってしまったのでこの辺で。

勉強会が終わった後の懇親会でも、Elasticsearchを運用されてる方々とお話させていただきお互いに運用事例やノウハウを共有する機会がありました。皆さん、ありがとうございました。

なお、主催の@johtaniさんが開催報告ブログをまとめてくれています。
http://blog.johtani.info/blog/2014/11/19/hold-on-7th-elasticsearch-jp/

12月に入り、今日から各所でアドベントカレンダーが始まりましたね。
Elasticsearchに関してもあるので、個人的に楽しみにしています。

Elasticsearch Advent Calendar 2014
http://qiita.com/advent-calendar/2014/elasticsearch

ちなみにドワンゴ社員によるアドベントカレンダーもありますので是非ご覧ください。
ドワンゴ Advent Calendar 2014
http://qiita.com/advent-calendar/2014/dwango