yahoo

[*その他*] Yahoo! JAPAN Tech Conference 2019 に参加してきた


はじめに

Yahoo! JAPAN Tech Conference 2019に参加してきたのでメモ。


スライドまとめ

セッション名
ルーム
参加

Keynote
A
×

もう道に迷わない! Yahoo! MAPにおけるAR体験
A

ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン"/ワイキューが目指した"楽しい時間を作るデザイン"
A

ユーザーコミュニケーションの新たな武器、けんさくとえんじんの秘密
A
×

LEAN XPを活用したユーザーの声を聞くものづくり 〜Yahoo! JAPAN タブレットアプリのリニューアル〜
A
×

拡張性あるデザインシステム構築から挑む、GYAO!のウェブリニューアル
A
×

[CtoC配信サービスのバックエンドからiOSアプリまで ~ヤフオク!ライブの全貌とXP開発~
A
×

パスワードレス普及への取り組み/ヤフーのデータ戦略を支えるID連携](https://www.slideshare.net/techblogyahoo/b1-id-yjtc)
B
×

データの力で実現するYahoo!ショッピングのCRM
B
×

ライブ動画配信サービス「ワイキュー」の作り方〜優れた社内技術で実現する、少人数のサービス開発〜
B

豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ
B

Kubernetesで実現したYahoo! JAPANの次世代開発環境~ 100以上のクラスタを少人数で運用する秘訣 ~
B

Yahoo! JAPANの巨大インフラの運用と展望
B


メモ


もう道に迷わない! Yahoo! MAPにおけるAR体験

YahooMapにはいろいろ機能が


  • 防災マップ

  • 混雑レーダー

  • 雨雲

  • AR


  • ARKitを使用・・・Appleから提供されている


  • ARチームは3人だけでやってる


  • 3ヶ月でリリースまで行った


  • AR世界座標と現実の緯度経度は相互に変換可能


  • 日本でAR体験に慣れている人は少ない


  • 暗闇の場合はユーザーにとって危ないので使えないようになっている


  • 歩きスマホに対する注意メッセージを表示している


デザインするのにいろいろなツールを使用


  • Prott

  • Flinto

  • Adobe After Effect

  • Github


  • 名古屋↔東京 で遠隔開発


  • コミュニケーションによる信頼関係の構築が重要


  • ARのユースケースをしっかり考えることが必要


  • ユースケースが決まったらパーツの最適化を行う


  • パーツにちょっとした遊び心があったほうがよい


  • 新しい技術を使った際のユーザーへのフィードバックがとても大事



ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン"/ワイキューが目指した"楽しい時間を作るデザイン"


  • ワイキュー:賞金山分け型エンタメライブ番組


  • 内因的・外因的モチベーション


  • 内因的・・・物事への興味・関心


  • 「私の理想が世の中を楽しくする」を実現したい


  • burari・・・お出かけ共有アプリ


  • bonfire・・・課題解決型コミュニティ


  • 「惰性的な日常にドキドキする瞬間を」作りたい


  • ワイキューにはペインポイントはない


  • 課題解決のためにエンタメやらないし


  • 全社員に向けてチャットで試した


  • 5分の1くらい(2000人)は参加してくれた


  • パフォーマンスチューニングに手間取ってリリース時期を見直し


  • ものづくりを伸ばすのは精神への影響が大きかった


  • 成功体験を因数分解してあげるのもPMの仕事


  • モチベーションにも賞味期限がある:3ヶ月くらいが限界


  • MLPは仮設証明だが、チームビルディングでもある


  • 仮説検証するときは全社でやるとか大きくやったほうがいい


  • 心が折れない拠り所の確立


  • モチベーションの導火線は人それぞれ


  • ドキドキとワクワク をデザイン


  • パーティーを参考にデザイン


  • 楽しい時間を作るデザイン


  • ヤフーにはデザインガイドラインが用意されている



ライブ動画配信サービス「ワイキュー」の作り方〜優れた社内技術で実現する、少人数のサービス開発〜


  • yui→React

  • CDNつかってる

  • HLS使用

  • 動画にメタ情報を付与できる

  • コメントのNGワード → 不正投稿判定プラットフォームがYahooにはあるのでそれを使用

  • 問題の回答のリクエストを全てさばかないといけないのが難しい

  • 西日本と東日本でクラスタ構成、サーバー50台分のインスタンス

  • ポイントについてはメッセージキューを使用して逐次やってる

  • Tポイントの付与自体はTポイント側でやってくれている

  • CDNも社内にある

  • プッシュ通知のプラットフォームも自社内にある

  • ヤフー内には幅広くプラットフォームが揃っている


豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ


  • スポーツナビ

  • 感動を届ける

  • スポーツをCan Doする人をふやす


  • データ提供元とシステム連携している


  • 入稿されてくるデータごとにプラグインがあってそれが動いて対象システムへとデータを送っている


  • プロ野球速報アプリ


  • Redis


  • Soeket.io …を使用


  • データが増え続けても保守し続けられるように → プラグインを利用


  • 取り扱うコンテンツを拡充しやすいように


  • スポーツの盛り上がりを逃さない


  • Chefを使用して、負荷が高まると仮想サーバーが立つようになっている


  • アクセスが多かったイベントは記録に残しておいて、次回の予測に使っている


  • CaaS/PaaS環境への移行も進行中



Kubernetesで実現したYahoo! JAPANの次世代開発環境~ 100以上のクラスタを少人数で運用する秘訣 ~


  • Z Lab → インフラ基盤の開発及び技術研究

  • より早く、安定したサービスを届けたい

  • 開発に集中できるようにする


  • 参考としたこと


  • 12 Factor App・・・Webアプリケーションを使いやすい形で構築するための方法論、システムとアプリケーションを分離し、それぞれ独立してアップデートできるように


  • マイクロサービス・・・ それぞれのアプリケーションを小さくする → 少人数で開発可能、変更した際の影響を小さくできる


  • コンテナ技術・・・1マシン1マイクロサービスだと効率が悪い


  • VMのオーバーヘッドのほうがでかい


  • 障害時にマシンが壊れた時、コンテナを移動するといったことが必要


  • 負荷に応じてスケールしたい


Kubernates


  • 調子が悪いとき、コンテナ実行を別の正常マシンでやってくれる、移動して実行

  • 運用者は何もしなくても自動的に行われる

  • 負荷に応じてコンテナの数を増やすことも可能

  • 人間がコンテナの運用作業をすることがなくなる

Kubernatesクラスタ自体を同管理するか

* 壊れたマシンをどうするか → 人が足す必要がある

* Kubernates自体のバージョンアップをどうするか → 人がやる必要がある

KaaS


  • Kubernatesを管理するためのサービス → 人間がKubernatesを管理する必要もなくなる

  • マシン故障の障害を検知、マシンを作ってくれる

  • バージョンアップもしてくれる

  • 新しいマシンを作って、古い方に対比命令をだして停止し、新しいマシンにコンテナ再度追加、 古いマシンの削除

  • 各マシンの何かを監視したい、ログの収集をしたい → それぞれでやるとメンテナンスコストが発生 → アドオンとして開発


  • ATHENZ・・・認証関連


  • エンジニアとしては開発してGithubにプッシュするだけで、その後は自動的に行われる



Yahoo! JAPANの巨大インフラの運用と展望


  • プライベートクラウド → openstackを使用

  • 162クラスタが稼働

  • 運用の専任者はいない

  • 環境ごとにクラスタを立てる

  • OpenStackの自動化

  • 構築作業の効率化

  • Swiftを活用してV2Vシステム構築

  • コンポーネントの数だけストレージが存在

  • 新しいクラウドストレージ → SDS → Quobyteというのを選択、一つに統一

  • オペレーションの負荷軽減

  • ネットワークが複雑化している

  • ネットワークの種類を減らすなどで負担軽減してきた

  • 運用の自動化