Hejdaの見る夢

一人前のエンジニアを目指して頑張ったこととかをつらつら書くブログ

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

個人メモ 勉強会

日時・場所

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

  • 説明
  • 発表者
  • アジェンダ
    • 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
      • 通信
    • ログ
      • 基本的にはwebサーバと一緒
      • 違う点
        • 容量が少ないので削除は頻繁に
        • I/Oの上限がある
        • 日時でクラウドにアップロード
    • セキュリティについて
      • SDカードを使う以上は中身を抜かれる
      • 大事な情報はSDではなく、拡張基盤(nRF52)にいれる
      • ソースコードの暗号化
      • OSは最新に保つ
      • 仕様として、ゲートウェイ起因でクリティカルな処理が実行出来ないようにしておく
      • 外部検査機関でチェックする
      • ソフトウェアのアップデート
        • apt経由でアップデートする
  • それでもRaspberry Piではだめな場合はどうするか？
  • 他、Raspberry Piの利便性を高める方法や、安全に使うためのノウハウなど
    • 4000円すら高い時
      • コンシューマ用途
      • BLEだけでいいならnRF52がおすすめ
      • BLEとWiFi使いたいなら…
    • 電池駆動させたい
    • セキュリティ的
      • 組み込み系は大抵の場合、外からのアクセスを防ぐ仕組みがある
      • 破壊 = 製品の破壊 なので、あまり意識していない
    • 罠
      • Non-OSのコンボチップはWi-Fi5GHzに対応していない
  • 質疑応答
    • 使用するSDカードは品質のチェックは必須
    • 再利用性を考えて、SDカードは抜き差し可能な状態にしていている(レンタル事業のため)
    • 次回のraspiに求めているのは、ハード面で追加・改善
    • 5GHz必須の時はtoBの時。闇のお話。
    • SDカードの耐久試験 = Write試験
    • raspi0はtoB向けだと信頼性とコストで選択肢から外れている。toCなら可能性あるかも。
    • SDカードはT社が良い

Caching at Netflix: The Evolution of EVCache

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

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

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

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

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

  • 説明

  • 発表者

  • 話すこと

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

builderscon 2018 前夜祭 に行ってきた時の個人メモ

個人メモ 勉強会

日時・場所

uzulla: 乾杯＆ウェアラブル謎ガジェット

cho45: 自作 BLE キーボードのその後

kazuph: IoT開発の闇

f:id:nari_kyu:20180907133228g:plain

KAYAC hara: 人類バーチャル化のすすめ

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

  • 説明
  • ぺぱぼMAKE部
    • GMOペパボ社員による非公式のものづくり部活動
    • ほとんどがゆーれー部員
    • MakerFaireにも出店
    • 社内展示会
  • IoTでどんなものを作ってきたのか
    • ロボットボールの作り方
      • ロボットボールを触ってみたいという衝動
      • 光るは正義
      • omicro
    • omicro
      • https://medium.com/tichise/ロボティックボール-liveballを作った-7185b45f6e88
      • 球体の中のラジコン
      • bluetooth -> iOSアプリ -> omicro
      • マイコン
        • mbed
          • LPC1768
          • LPC114FN28
          • LPC**
        • mbedの良さ
          • オンラインIDEがある
          • ライブラリが豊富
          • コマンドツールが使える
      • watch OSアプリも作っている
        • 手の甲の動作で動くのは展示では良い
        • 予期せぬ動作もある
      • BLE
        • koshianを使用
      • ボディ
  • IoT歯ブラシスタンド
    • 原因
      • 口内環境は大事
      • 歯ブラシの交換時期が分からない
      • 歯磨きを計測して、口内環境を管理したい
    • マーケ
      • 「歯ブラシ」と「IoT」はたくさんある
      • 「歯ブラシスタンド」と「IoT」は前例が無かった
    • 工程
      • アイデアづくり
      • 雑なプロトタイプを作る
        • 圧力センサー
        • ESP32
        • 昇圧3.3V DC
        • Arduino IDE
      • 実際に動かす
        • 思った通りに動かない
        • 展示すると次の改善点が見えてくる
    • 作った感想
      • プロトタイミング大事
      • 物理を感じる
      • 楽しい!!

感想

  • 普段やっていることとは違って、実際にアプリを作っているエンジニアのつらみとつらみの中の面白みを感じ取れたので楽しかった 😊

Node-REDをVagrant上で立ち上げて、ブラウザで確認する

Node-RED Vagrant nodejs

Qiita

Node-REDをVagrant上で立ち上げて、ブラウザで確認すると同内容です。

使用するvagrant box

# cat /etc/debian_version
9.5

構築

vagrantの起動

割愛

Debianの基本設定

  • ROOT化
sudo su -
  • aptの更新
apt-get update
apt-get upgrade -y
  • (今回使う)最低限のアプリのインストール 
apt-get install -y vim
curl https://gist.githubusercontent.com/iganari/a2baec1af976425cc8e21ccd68cf5585/raw/b6fce2cc91e1c77da759af1d2ea7b771b597787f/_vimrc -o /root/.vimrc
ls -la /usr/bin/vim.basic 
unlink /etc/alternatives/editor
ln -s  /usr/bin/vim.basic /etc/alternatives/editor
apt --purge remove -y nano
  • サーバの時刻を日本にする
rm -rfv /etc/localtime &&\
ln -s /usr/share/zoneinfo/Asia/Tokyo /etc/localtime
echo 'LANG="en_US.UTF-8"' > /etc/default/locale

nodejs version8 をインストールする

  • 既存のnodejsを削除して、公式からインストールスクリプトを用いてインストール
    • 意図したnodejsをインストールした後にNode-REDもインストール
apt remove --purge -y nodejs
curl -sL https://deb.nodesource.com/setup_8.x | /bin/bash
apt-get install -y nodejs
npm install -g --unsafe-perm node-red

作業ユーザ作成

  • 作業ユーザは node-red 
username='node-red'
useradd -m -s /bin/bash ${username}
echo "${username} ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/${username}
chmod 0440                                  /etc/sudoers.d/${username}
cp    /root/.vimrc            /home/${username}/.vimrc
chown ${username}:${username} /home/${username}/.vimrc

Node-RED をnpmからインストールする

  • 作業ユーザ node-red になる
su - node-red
  • 専用のディスクトリを作成し、node-redをインストール
mkdir         /opt/nodered-vagrant
chmod 0777 -R /opt/nodered-vagrant
cd            /opt/nodered-vagrant
npm install node-red

起動・終了スクリプトを設置

  • 再び、ROOT化
sudo su -
  • ダウンロード
wget "https://raw.githubusercontent.com/iganari/nodered-vagrant/master/bin/usr/bin/node-red-start" -O /usr/bin/node-red-start
wget "https://raw.githubusercontent.com/iganari/nodered-vagrant/master/bin/usr/bin/node-red-stop"  -O /usr/bin/node-red-stop
  • 権限変更
chmod 0755                /usr/bin/node-red-st* 
chown root:root           /usr/bin/node-red-st*
wget "https://raw.githubusercontent.com/iganari/nodered-vagrant/master/bin/etc/systemd/system/node-red.service" -O /etc/systemd/system/node-red.service
  • 権限変更
chmod 0755      /etc/systemd/system/node-red.service
chown root:root /etc/systemd/system/node-red.service
  • 起動
systemctl start node-red
systemctl enable node-red

ブラウザで確認

http://192.168.33.131:1880/

f:id:nari_kyu:20180820191504p:plain

ソース全体

簡単な構築方法含め、以下のレポジトリにまとめたので確認してみて下さい :blush:

https://github.com/iganari/nodered-vagrant

Mercari meetup for SRE に行ってきた時の個人メモ

個人メモ 勉強会

開催日 / 場所

  • 2018/07/25(水)
  • 19:30 〜 21:30
  • 株式会社メルカリ

connpass

https://mercari.connpass.com/event/92098/

Twitter hashtag

https://twitter.com/hashtag/mercari_sre?f=tweets&vertical=default&src=hash&lang=ja

オープニング＆SREチームのご紹介

  • 登壇

    • @masartz

  • slackの使い方メモ

    • リモートの出勤
    • hello bot で出勤になる
  • task管理
    • add todo hogehoge でJIRAにチケット起票
    • slackのURLがチケットに入ってくるので、チケットからslackの流れに戻れる

Traffic Optimization @cubicdaiya

  • 登壇

    • @cubicdaiya

  • メルカリの特徴

    • ネットワーク回線は細い
      • Wifiを前提にしない
    • スマホで利用可能なデータ通信量は有限
    • 良いUI/UXを実現するには高速な動作が必要不可欠
      • 低速なネットワークでもストレスなく動作する必要がある
      • 端末一つあたりの画像配信量はなるべく抑えることが重要

  • API

    • JSON
      • gzip
        • 圧縮レベルは6に設定している。理由は後述。
    • バイナリデータ
      • これから主流
    • ネットワークレイテンシ >>> 圧縮にかかるオーバーヘッド
      • トレードオフだが、マクロな目線で見ると圧縮にかかるオーバーヘッドは今は無視出来る
      • メルカリにおいては、ネットワークはCPUより高い
  • 構成
    • アプリ --- akamai --- imageflux --- S3
  • 圧縮に関して
    • 圧縮
      • 10% ~ 20% 減
    • 圧縮 && WebP
      • 30% ~ 50% 減

Expanding World of Data @kazeburo

  • 登壇

    • @kazeburo

  • メルカリのデータセンター

    • 石狩DC
      • 空調のコストが低い
      • 災害のリスクが低い
    • GCP
      • cloud(東京リージョン)
  • データセンターの距離
    • 1,000 Km
  • 早く通信する施策

  • これから

    • 東京のどこかのDCにラックを確保して、GCPと石狩の真ん中として使用する

  • DataBaseについて

    • MySQL 5.6, 5.7系
    • 巨大なデータ && トラフィック
    • TBを超えるテーブルが複数
    • 高いIOPS
    • 次世代は東京のDCに作りたい