dwango エンジニア ブロマガ

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

インターンシップシーズン後半、エンジニア志望の学生さん向けに開いていた「プロダクト開発インターン」の第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がどうなっていくのか、ますます目が離せないとても刺激的な状況です。

エンジニア募集中です