builderscon 2018 1日目 に行ってきた時の個人メモ

日時・場所

• 日時
  • 2018/09/07
• 場所
  • 慶応大学　日吉キャンパス
• タイムテーブル
  • https://builderscon.io/tokyo/2018/timetable?date=2018-09-07

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

• 説明
  • https://builderscon.io/tokyo/2018/session/824f1750-4c2b-43e2-b942-e610b3c88c6c
• 発表者
  • @kazuph
  • Photosynth
• アジェンダ
  • IoTの光の話
• Raspberry Pi(=raspi)を産業利用で選ぶのか
  • 高い品質
    • 世界ナンバーワンの製造数(当社比)
    • 他社とは製造数で雲泥の差
    • 最近はSONY工場でも作ってる(もともとはSONY UKが作ってる)
  • 安価
    • raspi日本だと4000円くらい
    • 他社は5万円くらい…
  • 汎用的な開発環境
    • デフォがDebian
    • CPUがARMだけど、最近はARM用ビルドも増えてるので問題はあまり無い
  • 安定供給
    • 製造数的に問題無さそう
    • 互換ボードも出てきた
      • eg. ASUSのTinker-Board
• 弊社でのRaspberry Pi採用の実績
  • 実製品のプロトタイミング
    • raspiで試作して、本番へ
    • Golang使ってる
  • 組み込み製品のデバック用途
    • CIを回すことも出来る
      • Gtihub + Jenkins + Slack
  • 工場での出荷(のためのチェック)ツール
    • 小型で安価なチェック機材が作れる
    • 治具祭り
    • 出荷前の最終チェックとしてansibleを使ってチェックしている
      • 最終的に、ansible経由でアクセス出来ないようにして完了
  • IoTゲートウェイ
    • 最初は品質に懐疑的だった
    • 以下の実績がすでにあった
      • 工場ツール
      • 負荷試験もOK
      • raspi3bからBLE対応したので、原価削減(Wi-Fi、BLEドングルが必要無くなる)
• 手軽に使えるRaspberry Piのソースコードを交えた利用例
• より強固なデバイスにするための基板拡張とそれを支えるソフトウェア技術
• それでもRaspberry Piではだめな場合はどうするか？
  • 構成
    • Node
      • noble
      • express
    • 通信
      • HTTPS
      • MQTTS
      • SPI
  • ログ
    • 基本的にはwebサーバと一緒
    • 違う点
      • 容量が少ないので削除は頻繁に
      • I/Oの上限がある
      • 日時でクラウドにアップロード
  • セキュリティについて
    • SDカードを使う以上は中身を抜かれる
    • 大事な情報はSDではなく、拡張基盤(nRF52)にいれる
    • ソースコードの暗号化
    • OSは最新に保つ
    • 仕様として、ゲートウェイ起因でクリティカルな処理が実行出来ないようにしておく
    • 外部検査機関でチェックする
    • ソフトウェアのアップデート
      • apt経由でアップデートする
• それでもRaspberry Piではだめな場合はどうするか？
• 他、Raspberry Piの利便性を高める方法や、安全に使うためのノウハウなど
  • 4000円すら高い時
    • コンシューマ用途
    • BLEだけでいいならnRF52がおすすめ
    • BLEとWiFi使いたいなら…
  • 電池駆動させたい
    • 構成を変えるしか無い
    • N個のBLEエッヂデバイス + 給電ゲートウェイ
  • セキュリティ的
    • 組み込み系は大抵の場合、外からのアクセスを防ぐ仕組みがある
    • 破壊 = 製品の破壊 なので、あまり意識していない
  • 罠
    • Non-OSのコンボチップはWi-Fi5GHzに対応していない
• 質疑応答
  • 使用するSDカードは品質のチェックは必須
  • 再利用性を考えて、SDカードは抜き差し可能な状態にしていている(レンタル事業のため)
  • 次回のraspiに求めているのは、ハード面で追加・改善
  • 5GHz必須の時はtoBの時。闇のお話。
  • SDカードの耐久試験 = Write試験
  • raspi0はtoB向けだと信頼性とコストで選択肢から外れている。toCなら可能性あるかも。
  • SDカードはT社が良い

Caching at Netflix: The Evolution of EVCache

• 説明
  • https://builderscon.io/tokyo/2018/session/280dbae9-849b-11e8-b5f0-42010af006c2
• 発表者
  • @sgmansfield
• Netflix
  • サービスの中でいろんなとこでcacheを使っているのか

• EVCache

  • Netflix謹製
    • KVS
    • base memcache
    • optimize AWS
  • github
    • https://github.com/Netflix/EVCache/wiki

• Use Cases

  • lookaside cache
    • Netflixはカサンドラ使っている
  • Transient Data Store
    • セッションを見ているかのチェック
  • Primary Store
    • オンラインとオフラインの橋渡し
  • Versioned Primary Store
    • どのバージョンを読み込めばいいかの情報
  • High Volume && High Availability
  • Personalization Fact Store
  • Pipeline of Personalization
  • Full Circle
    • ブラウザの閲覧情報 -> unified logging -> Hive -> EVCache -> online service -> ブラウザ
• Moneta
  • 記憶の女神が由来
  • グローバルのデータをキャッシュのコピー
• Rend
  • Golang
  • githubで公開している
  • 高機能 memcached proxy

• Rend batching Backend

  • Rendのバックエンドのmemcachedとの通信を最適化するために開発

• OSS化

  • https://github.com/Netflix/EVCache
  • https://github.com/Netflix/rend

Webサービスにて200週連続で新機能をリリースする舞台裏

• 説明
  • https://builderscon.io/builderscon/tokyo/2018/session/eaaa57e7-0ca5-49b4-a4d4-da13ac969b27
• 発表者
  • @daiksy
  • Mackerelディレクター
• 発表資料
  • https://speakerdeck.com/daiksy/builderscon-tokyo-2018
• Mackerel
  • 2018/7/2に200(営業)週連続リリース達成
  • リリースの定義
    • ユーザにとって価値のある機能を新規・追加をしたもののみ
• なぜやったか
  • 顧客に約束出来る価値の一つであり、当時は優位性でもあった
• 開発の流れ
  • Github -> Jenkins -> staging環境
  • 当番制
• 質疑応答
  • スタートアップが開発手法を真似ることは出来そう。どれだけユーザの声を実現出来るか

実録！ある担当者がみた「謎ガジェット」開発１年史

• 説明
  • https://builderscon.io/tokyo/2018/session/442f46cc-c888-4cc6-8e66-0f17144ea5fb
• 発表者
  • @uzulla
• 必要なもの
  • 意欲
  • 時間
  • お金
  • 仲間
  • 場
• electronic badge
  • https://www.google.co.jp/search?ei=0wuSW47-KtnN-QbEr4igDg&q=electronic+badge&oq=electronic+badge&gs_l=psy-ab.3...0.0.0.22076.0.0.0.0.0.0.0.0..0.0....0...1c..64.psy-ab..0.0.0....0.0DiG0bw64CE
• マイコンのまとめ
  • 実際に買って触ってみないと評価軸が出来ない
  • 触っていると実は必要な追加特性も煮えてくる
  • 安い液晶は上から見ると読めないとか
• 独りよがりな危なさ
  • 独りだと気づかない
• 時間とは
  • 時間がある = 工夫出来る余地の時間がある
• 発表自体がエンターティンメントだったので、次は動画を撮ったほうがいいかも
• 制作物
  • https://github.com/builderscon/electronic_badge_2018
• journald 設定はデバックにしておく
  • オフにしておくと、再起動で揮発する

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

• 説明
  • https://builderscon.io/tokyo/2018/session/de841175-4619-4dc9-b6f1-434be948394d
• 発表者
• 後に資料公開する予定
  • WIP
  • 立ち見だったので資料を見るメイン
• 監視
  • 普段は意識されないもの
  • 障害発生時に意識されるもの
  • 辛い
• webアプリケーションの監視の技術トレンド
  • サーバの見方が「ペット」から「家畜」へ
  • 監視サービスの充実
    • インテグレーションも充実
    • 監視サービスの監視からの開放(Zabbix重いよね問題)
• アラートあるある
  • 本当に異常なのかわからない
    • エンドユーザにとってどう損害なのか
  • アラートが行動に結びつかない
    • 一時対応
    • 今、対応するべき障害か分からない
    • とりあえず動かない
      • アラートなってるけど、webブラウザで見ると、(遅いけど)動くケース
    • 常に異常
      • 毎日、定期的にアラートが出ている
      • ずっとエラー出てる…
    • 何も出来ない
  • ただしい方向にむかっているのか分からない
    • 闇雲にやってもなにも分からない
• そもそも監視は
  • エンドユーザへの品質担保
  • 監視はその手段である
• 監視がうまく動いていないと
  • 開発生産性が下がる
  • 会社全体の士気が下がる
• MTTR
  • Mean Time To Repair
  • 平均復旧時間
• MTBF
  • Mean Time Between Failures
  • 平均故障間隔

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

• 説明
  • https://builderscon.io/tokyo/2018/session/ab9ab3d7-fc26-47c6-ba44-e16299a0c712

• 発表者

  • @takihito
  • 面白法人カヤック 技術部

• 話すこと

  • スマホアプリでゲームが動く仕組み　
  • 開発と運用チームの体制について
  • リリースから現在までに起きた問題を対策対応
• アジェンダ
  • ゲームの仕組み
  • ゲーム制作チームとプロジェクト
  • その他は上記と一緒
• ゲームの開発に関して
  • 開発運営チーム
    • たくさんの役割の人がいる
    • イメージ的には中規模の会社
  • コストの話
    • 開発期間は2-3年
    • その間にかかるコストは投資
    • リリースしてから回収出来るようになる
    • 初期開発費の回収
  • アプリの構成
    • スマホアプリ
    • アプリ内で保存管理するデータ
    • API
    • リアルタイム通信
  • ゲーム特有のサーバ事情
    • 予測を結果
    • 構成要素と複雑さ
    • クライントアプリ
    • 施策とアクセス状況の関係
• 負荷の対策と原因
  • リリース時に起きたもの
    • リリースまでに多くのチェックポイントがある
    • αテスト/βテスト
    • 予測流入数とそれを耐えられるように負荷試験
    • フェイルオーバー試験
    • QA(インゲーム/アウトゲーム/課金試験)
    • 運用演習(リリース/データ更新)
  • ログに関して
    • ログ集約はサービスに即座に影響が出るとこでは無いので、リリース後に後手後手に回る傾向がある
  • マルチプレイの罠
    • リアルタイムサーバを介して通信
    • photon を使ってる
      • https://www.photonengine.com/ja/photon
    • Redisでkeysを使うと死ぬ
      • Redisはシングルプロセス
      • keysは総なめのコマンド
      • 対策として、setを使う
    • βテストではマルチプライのテストが出来てなかったので分からなかった
  • クライアントに仕組まれたバグ
    • 事前準備はしたけど、リリース後にAPIが重い…
    • 全ユーザ情報をとってくるAPIを頻繁に叩かれている
      • 本当は最初の1回だけで、後は差分更新のはず
      • クライアント制作チームの認識のズレ
    • アプリのバージョンアップの時間は無い
      • APIを研ぎ澄ますしかなかった
• まとめ
  • ソーシャルゲームは想定外のことが多い
  • 障害を完全防ぐことは不可能
  • 想定外の自体も受け入れる
  • 過渡に神経質にならない