はじめに
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チームは３人だけでやってる
-
３ヶ月でリリースまで行った
-
AR世界座標と現実の緯度経度は相互に変換可能
-
日本でAR体験に慣れている人は少ない
-
暗闇の場合はユーザーにとって危ないので使えないようになっている
-
歩きスマホに対する注意メッセージを表示している
デザインするのにいろいろなツールを使用
-
Prott
-
Flinto
-
Adobe After Effect
-
Github
-
名古屋↔東京 で遠隔開発
-
コミュニケーションによる信頼関係の構築が重要
-
ARのユースケースをしっかり考えることが必要
-
ユースケースが決まったらパーツの最適化を行う
-
パーツにちょっとした遊び心があったほうがよい
-
新しい技術を使った際のユーザーへのフィードバックがとても大事
ライブクイズ「ワイキュー」を生み出した"内因的モチベーションドリブン"／ワイキューが目指した"楽しい時間を作るデザイン"
-
ワイキュー：賞金山分け型エンタメライブ番組
-
内因的・外因的モチベーション
-
内因的・・・物事への興味・関心
-
「私の理想が世の中を楽しくする」を実現したい
-
burari・・・お出かけ共有アプリ
-
bonfire・・・課題解決型コミュニティ
-
「惰性的な日常にドキドキする瞬間を」作りたい
-
ワイキューにはペインポイントはない
-
課題解決のためにエンタメやらないし
-
全社員に向けてチャットで試した
-
５分の１くらい（2000人）は参加してくれた
-
パフォーマンスチューニングに手間取ってリリース時期を見直し
-
ものづくりを伸ばすのは精神への影響が大きかった
-
成功体験を因数分解してあげるのもPMの仕事
-
モチベーションにも賞味期限がある：３ヶ月くらいが限界
-
MLPは仮設証明だが、チームビルディングでもある
-
仮説検証するときは全社でやるとか大きくやったほうがいい
-
心が折れない拠り所の確立
-
モチベーションの導火線は人それぞれ
-
ドキドキとワクワク をデザイン
-
パーティーを参考にデザイン
-
楽しい時間を作るデザイン
-
ヤフーにはデザインガイドラインが用意されている
ライブ動画配信サービス「ワイキュー」の作り方〜優れた社内技術で実現する、少人数のサービス開発〜
- yui→React
- CDNつかってる
- HLS使用
- 動画にメタ情報を付与できる
- コメントのNGワード → 不正投稿判定プラットフォームがYahooにはあるのでそれを使用
- 問題の回答のリクエストを全てさばかないといけないのが難しい
- 西日本と東日本でクラスタ構成、サーバー５０台分のインスタンス
- ポイントについてはメッセージキューを使用して逐次やってる
- Tポイントの付与自体はTポイント側でやってくれている
- CDNも社内にある
- プッシュ通知のプラットフォームも自社内にある
- ヤフー内には幅広くプラットフォームが揃っている
豊かなスポーツライフの実現を目指す、スポーツナビのシステムアーキテクチャ
-
感動を届ける
-
スポーツをCan Doする人をふやす
-
データ提供元とシステム連携している
-
入稿されてくるデータごとにプラグインがあってそれが動いて対象システムへとデータを送っている
-
プロ野球速報アプリ
-
Redis
-
Soeket.io …を使用
-
データが増え続けても保守し続けられるように → プラグインを利用
-
取り扱うコンテンツを拡充しやすいように
-
スポーツの盛り上がりを逃さない
-
Chefを使用して、負荷が高まると仮想サーバーが立つようになっている
-
アクセスが多かったイベントは記録に残しておいて、次回の予測に使っている
-
CaaS/PaaS環境への移行も進行中
Kubernetesで実現したYahoo! JAPANの次世代開発環境～ 100以上のクラスタを少人数で運用する秘訣 ～
-
Z Lab → インフラ基盤の開発及び技術研究
-
より早く、安定したサービスを届けたい
-
開発に集中できるようにする
-
参考としたこと
-
12 Factor App・・・Webアプリケーションを使いやすい形で構築するための方法論、システムとアプリケーションを分離し、それぞれ独立してアップデートできるように
-
マイクロサービス・・・ それぞれのアプリケーションを小さくする → 少人数で開発可能、変更した際の影響を小さくできる
-
コンテナ技術・・・１マシン１マイクロサービスだと効率が悪い
-
VMのオーバーヘッドのほうがでかい
-
障害時にマシンが壊れた時、コンテナを移動するといったことが必要
-
負荷に応じてスケールしたい
Kubernates
- 調子が悪いとき、コンテナ実行を別の正常マシンでやってくれる、移動して実行
- 運用者は何もしなくても自動的に行われる
- 負荷に応じてコンテナの数を増やすことも可能
- 人間がコンテナの運用作業をすることがなくなる
Kubernatesクラスタ自体を同管理するか
- 壊れたマシンをどうするか → 人が足す必要がある
- Kubernates自体のバージョンアップをどうするか → 人がやる必要がある
KaaS
-
Kubernatesを管理するためのサービス → 人間がKubernatesを管理する必要もなくなる
-
マシン故障の障害を検知、マシンを作ってくれる
-
バージョンアップもしてくれる
-
新しいマシンを作って、古い方に対比命令をだして停止し、新しいマシンにコンテナ再度追加、 古いマシンの削除
-
各マシンの何かを監視したい、ログの収集をしたい → それぞれでやるとメンテナンスコストが発生 → アドオンとして開発
-
ATHENZ・・・認証関連
-
エンジニアとしては開発してGithubにプッシュするだけで、その後は自動的に行われる
Yahoo! JAPANの巨大インフラの運用と展望
- プライベートクラウド → openstackを使用
- 162クラスタが稼働
- 運用の専任者はいない
- 環境ごとにクラスタを立てる
- OpenStackの自動化
- 構築作業の効率化
- Swiftを活用してV2Vシステム構築
- コンポーネントの数だけストレージが存在
- 新しいクラウドストレージ → SDS → Quobyteというのを選択、一つに統一
- オペレーションの負荷軽減
- ネットワークが複雑化している
- ネットワークの種類を減らすなどで負担軽減してきた
- 運用の自動化