Builderscon

Buildersconは”「知らなかった、を聞く」をテーマとした技術を愛する全てのギーク達のお祭りです。”とあるように、エンジニア向けのプレゼン会という雰囲気になっています。

当日のタイムテーブルについてはこのような感じでした！

私が主に聞いたものについては

9月6日は

• 【前夜祭】kazuph: IoT開発の闇
• 【前夜祭】KAYAC hara: 人類バーチャル化のすすめ
• 【前夜祭】ペパボ Make部: デモ2連発 〜夏の終わりの打ち上げ花火〜

9月7日は

• 産業でガチ利用されるRaspberry Piの話
• Webサービスの品質とは何か？アラート地獄と監視の失敗、サービスレベル目標設計から学んだ3つの答え
• ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか 〜その原因と対策〜

9月8日はTOEFLとボランティアの懇親会に被ってしまったので行くことができませんでした、残念！

自分のとったメモを中心に内容について触れていきます。

IoT開発の闇

こちらはBluetoothのセキュリティと規格の普及度のお話でした。
スマホに搭載された謎機能、謎ネーミングなどなど作業を停滞させるような闇の話がもりもりでした。

某XX社の闇や某YY社の闇が聞けて楽しかったです。

あまり深く掘り下げると怒られそうなのでこれについてはここまでにしておこう…

人類バーチャル化のすすめ

このセッション、VRに興味がある人間としては一番聞きたかったもの１つでした。

当日のスライドと解説はこちらにまとまっています！

VRChatのUX

VRChatのUXの根幹はユーザーが自らコンテンツを生み出すエコシステムにあるという話にはなるほどなあと感心しました。
事実その通りで、VRChatではユーザーがアバターを作成し、ユーザーがアバターを動かし、その組み合わせがコンテンツとなっています。
ユーザーが増えれば増えるほどコンテンツが増加し、その中の優れたコンテンツが人をまた呼び込むという流れが形成されることにもなりますね。
初期のSNSと同じルートをたどっているのではないかなあと思いました。

VRM

VRMフォーマットについては名前だけ知ってはいましたが、実際にどのようなものかについては知りませんでした。
VRMはドワンゴが作った3Dアバターファイルフォーマットです。

今まではのキャラメイキングでは、各プラットフォームごとにモーションや表情を設定していました。
そのためモーションや表情の扱いはプラットフォームによってまちまちでした。

しかしVRMで統一されたアクセス機構を提供することでプラットフォームに依存しない3Dアバターを作ることができるようになりました。

VRoid Studio, Vカツ

VRoidはPixivが開発した、VカツはIVRが開発した3Dアバター作成支援ツールです。

VRoidはタブレット持ちには使いやすそうなので入れてみてキャラを作ってみようかと思います。
作ったら記事書きたいですね。

VRChatで使えるアバターを作るならばVRoid一択になりそうですね。
というのもVカツはニコニコ立体とVirtualCastにしか対応しておらず、VRMファイルのダウンロードはできないからですね。

他サービスとの互換性を売りにするVRMの特徴を完全に殺してしまっています。
とはいえ”Vカツが目指す未来”の項目には”他外部サービスに向けた出力”とあるので期待してもいいのかな…?

といっても”向けた”という文言が気になりますね。
VRMファイルをダウンロード可能にする予定はないのでしょうか。

いずれのソフトも今後に期待したいところですね。

VRChat

コミュニケーションツールとしてはかなり優秀で、まだまだポテンシャルはある

VR系すべてに言えることではあるが、機材の価格によって参加ハードルが高くなっている

VRChat面接

ここ一番興味のあったトピックでした！

アバターがオリジナルのものでなかったり、頻繁に変更されたりすると誰かわからなくなるというのは新鮮でした。
オリジナルアバターを作るのがかなりハードルが高くVRChatにはなかなか参入できていませんでした。
オリジナルアバターでないとなかなか個人を認識してもらえないというのはわかりましたが、その分最初の段階で納得いくアバターを作らないといけないですね。

ただ自分の理想の美少女像を言語化ないし表現するのって、顔だけに絞るとかなり難しいと思うんですよね。
しかもあまり頻繁に変えることもできないので、一気に作り上げて長く使うしかないですし….。

その点VカツはRPGのキャラクリみたいにアバターを作れるので、これがVRM出力、ダウンロード可能になれば一気に普及すると思います。

デフォルトアバターだと裏側にどんな人がいるのかなどと勘ぐってしまうというのはどうなんだろう。
自分はオンラインゲームのVCとかで慣れているので変更されないユーザーネームを見れば誰が誰かはわかりますし、勘ぐることもあまりないですね。

ただこれはゲームの話なので仕事の話などをするときとは着眼点が違う可能性が高く、はっきり断言はできないですね。

VR面接が機能するためには

• ユーザーネームがわかる
• 全員がオリジナルのアバターを持っている
• アバターを頻繁に変更しない

といったところが必要なのかもしれないですね。

VRイベント

詳細についてはメモしていないのですが、VRを利用してリアルワールドとバーチャルワールドをつなぐ催しを行ったそうです。

当日の連絡手段や配役については、1on1でしか話すことができないという点を見落としていたそうです。
リハーサルは大事ですね。

ここらへんは既存のイベントの運営のノウハウが生きてくるエリアかなあと思ったりします。
文化祭の出し物でVRイベントとかやってもおもしろいかなあと思いました。

来年の高校の文化祭の1つのアイデアとして提案していきたいですね（）

VRIK

Final IK(VRIK)はアバターの制御に使えるUnityアセットのようです。

まぁまぁ値段が張りますね….

当日の登壇の際にはVRIKとモーションキャプチャを用いて発表していたそうです。
すげー。

ペパボ Make部: デモ2連発 〜夏の終わりの打ち上げ花火〜

スライドはコチラにあります！

ロボットボール

1人目の方のセッションはロボットボールをどう作ったかについてでした。

製図

Fusion360(3D CADツール)で設計し、これをもとに3Dプリンターで出力して台などを作ったようです。

3Dプリンターが活きてくるのは1ミリ2ミリのずれについてあまり気にしない場合で、精度が求められる加工はレーザーカッターでやった方がいいとのことでした。

mbed

mbedは組み込み向けのプロトタイピング用ワンチップボードです。
他にもLPCだったりいろいろなマイコンないしマイコンボードがあるようです。
へー。

Bluetooth&Androidの組み合わせは闇が多いという情報を事前に得ていたので、iOSだけの対応にしたそうです。
実際にiOSのほうが統一されていて実装しやすかったとのこと。

そしてWatchOS（apple watch）からも操作できるのでかなりおもしろそう。

誤動作多め

誤動作が結構多かったというのは実際の環境と家の環境があまりに違っていたためで、路面によってはすぐに傷ついてボロボロになることも。
東急ハンズのプラ半球を組み合わせて作っているのでボール自体は割と安上がりらしい。

Bluetoothチップ

Koshian BLEを使ったそうです。
興味本位で調べていたところスイッチサイエンスでは販売終了になっておりました。

基板設計ソフト

Eagle, LiCAD, Fritzingなどがあるようです。
自分はDesign spark PCBしか知りませんでした。

Fusion PCBやelecrowは安くプリント基板を作ってくれる会社とのこと。
中国から発送するそうです。へー。

IoT歯ブラシスタンド

アイデアスケッチをして、実際に作ってみよう！

ESP32というWifiとBluetoothが使えるモジュールの紹介がありました。
これ同時に使えるならかなりいいですね。同時に使えれば….

2つのおもしろIoTガジェットの話を聞いて自分も作りたくなってきました！
感化されやすい～～～～

ここから2日目の内容です！

産業でガチ利用されるRaspberry Piの話

こちらは前日のIoTの闇を暴いた？方の光のほうのセッションです。

スライドはこちら。

Raspberry Pi

Akerunにはラズパイが実際に使われているそうで、以下が採用の理由です。

• 高い品質
• 汎用的開発環境
• 安定供給

どれも満たしていますね。
興味こそあったもののなかなか手を出していなかったラズパイ…
今度買って遊びます。

実際の用途としては

• プロトタイピング
• 組込製品のデバッグ
• 工場での出荷（品質管理）ツール
• IoTゲートウェイ

とのこと。

プロトタイピング

秋葉でパーツを買いあさってすぐに作ることができる。
素早い開発が可能。

デバッグ

動かしながらログを取って開発環境に送信したり、アップデートサーバとしての運用もできる。
リアルタイムロガーとして使える。

出荷ツール

製品のIOテストなどに使っている。

J-Link

マイコンのテストツール、初めて知った

BLEマイコン

BLEはBluetooth Low Energyの略称。
スイッチサイエンスではたくさんのBLEマイコンが売られていました。

GoのライブラリにはGolang BLEといった優秀なBTライブラリがあるようです。

nRF52という強そうなチップも結構よくつかわれているらしい

工場でAnsible

工場でAnsibleが使われているとのこと。
ラズパイ=>ラズパイで書き込むことができる。

最初のlinuxイメージを作成するときに使う。

工場では検査と後片付け用に使っているそうだ。

ラズパイを実際に運用

2016年から1度も交換なしで現在も稼働中
耐久性は抜群

工場の検査システムをラズパイだけで構築することが可能である

Linuxのリソースをフルに使えるというメリットもかなり大きい

MQTT(s)

IoT関連はかなり初心者なのでよく出てくるMQTT(s)という用語がわからなかったので調べた。

IoT向けのかなり軽量なプロトコルのようだ。

IoTゲートウェイ用途

• 工場で耐久性についての実績がある
• 負荷テストを行った際の実績
• 3Bからは標準でBLEに対応しており原価の削減につながる

ということで実際にIoTゲートウェイデバイスに採用した。
Wifi,BTドングルはそれぞれ数千円もしるので原価高めで、これらを削れるのはかなりのメリット。

負荷テストについては数万回から数百万回のテストを行ったとのこと。

BLEの負荷テストについては
1m~5mの範囲内での通信の成功率を見た。
BTは距離が離れれば離れるほど通信が失敗する確率が指数関数的に上昇するそうだが、ラズパイ3BのBLE機構は既存のBTドングルよりも好成績だった。

IoTゲートウェイの構成

通信については

• HTTP(s)
• MQTT(s)
• BLE
• シリアル通信

を使って行い、デーモンで処理したとのこと

拡張基板については

• 先述のnRF52
• UI（OLED,モニター,サウンダ―,SPI）

電源については雷サージ対策済みのACアダプタを拡張基盤を使って挿せるようにした。
拡張基盤での静電気対策についてはIoTデバイスにおいて必須。

ラズパイの内部ではNode（Noble, Express）が動いており、C言語でLEDやサウンダ―やSPIなどの拡張基板の制御をした

DFUモードにおいてのみ、BLEを使用した。

ログ戦略

基本的には通常のサーバと同じ

違う点は

• ラズパイで使える容量が少ないのですぐに削除する
• I/Oの上限が決まっているのでできるだけオンメモリで処理
• ネットに接続できるときはAmazon S3にアップロード

セキュリティ

SDカードを使う以上中身を抜かれるのは必至なので、大事なデータはSDカードにはおかないようにした。悲観的なアプローチで行ったそうです。

認証情報についてはすべて拡張基板に入れ、ソースコードは暗号化（？）、難読化を施し、OSは最新のバージョンにしておき、外部にセキュリティの検証を依頼するという一般的な対策をした。

他にゲートウェイデバイスによってクリティカルな処理（Akerunなら開錠など）が行われないようにし、ただ通信を中継するだけの役割に徹したとのこと。
仕様ベースでセキュリティを担保するんですねー。

アップデート

sshでは任意のコマンドが実行できるので便利
aptでアップデートすると楽ちん

ただし拡張基板のアップデートについてはかなり大変で、社内での情報共有コストが高いのはデメリット

手段としては

• ラズパイとnRF52を組み合わせて超近距離で通信をする

ことが挙げられるが、

• ラズパイが使えないとき（コストだったり）
• 電池駆動させたいとき
• クリティカルな処理に関する通信を行うとき

には使えない

BT対応チップ

BLEだけでいいのであればnRF52推奨

• ほぼデファクトスタンダード
• 2年前から本番環境で使っているそうだ

Wifiが欲しいならESP32

• デファクトスタンダードではない
• 物によってはBLEとWifiを同時に使えないなどの道の問題に対処する必要があったりする

いずれにせよ電池だと数時間しか持たない

組み込み系のチップにはベンダー側が外部からのアクセスを防ぐ仕組みを搭載してくれている場合が多い

共通の認証情報は避けよう！

（ほぼすべてのnon-OS、つまり組み込み系のコンポーネントチップは5GHzのWifiに対応していない）

まとめ

• ラズパイの品質が他を圧倒している
• ラズパイが完全にIoT Ready
• 値段も競合と比較してほぼ最安
• ラズパイには先人の大量のリソースがある

Webサービスの品質とは何か？アラート地獄と監視の失敗、サービスレベル目標設計から学んだ3つの答え

スライドについてはコチラにあります！
こちらも今回一番聞きたかったセッションの一つでした！

アラート

今まではアラートが出ても….

• まず意味がわからない
• なんのためにこのアラートを表示しているのかわからない
• アラートが出て悩む
• まず打つ手がなく、行動に結びつかない
• 行動が正しい方向に向かっているのかわからない

ということで

アラートはアラートでなくてはならない

という教訓を得たという話でした。

まずアラートを見て優先度の判断をすることが必要である。

監視

これが機能していないと忖度をベースにした意思決定が行われ、開発生産性が低下する。

指標についてはまず一旦シンプルな形態で置いておき、技術的なエントロピーをあげずに運用することを目指した。

eurekaではdatadogを使っているそうだ。

通信成功率などのパフォーマンス指標はすべて成功率,割合で計測するようにしたことでトラフィック量やサービス特性に依存しないようにした。

アラートはslackで表示するようにしている

監視=>対応の自動化=>人力での監視を不要にすることを目指して対策している

質問タイム

マニュアルについて何か作ったりしているのか
=>マニュアルは約に立たなかったのでやめて、今はSREを担当するエンジニアが対処している

slackが落ちたらどうするのか？
=>過去にslackが落ちてやらかしたことがあったので、slackが落ちた時の対策としては人海戦術で対処している。そもそも通知が来ないというのは異常事態なので。

ソーシャルゲームが高負荷に陥っているとき、何が起こっているのか 〜その原因と対策〜

スライドについてはコチラにあります！

ログ増えすぎた問題

他のサーバの管理体制はばっちりだったが１つ盲点があった

管理者用のサーバのログが増えすぎてしまった！
そしてRedshiftは気軽にスケールアウト,スケールアップしにくいので管理者用ログの要領には注意しようねという話。

APIが重すぎる

Photonをマルチプレイ用のリアルタイムサーバとして利用する構成でDBにはRedisを使っていた。

Redisの本番運用でkeysが使われていた

keys=>全部のキーを見に行くコードだが、redisはシングルプロセスなので死

keysの利用をやめたら解決した

API叩かれすぎ問題

スマホゲーでは広告,イベントのスケジュール,ユーザー数がパフォーマンスに強い影響力を持っている

PhotonとRedisの最大同時接続数は見落としがちなポイント

という感じでした！

総括

builderscon、いろいろお土産ももらえたし、普段あまりかかわりのない業界の人の話も聞けたし、後々役に立ちそうな話も聞けたし、学生料金で割と安く入れたしとコストパフォーマンスはよかったです。

9月8日の部はTOEFLとボランティアの懇親会のために行けませんでしたが、十分元は取ったかなという印象。

来年もぜひ参加したいところですね！

それではまた！