はじめに
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というのを選択、一つに統一
- オペレーションの負荷軽減
- ネットワークが複雑化している
- ネットワークの種類を減らすなどで負担軽減してきた
- 運用の自動化