builderscon tokyo 2018 聴講メモ #6「ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ」by aerealさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
ブログサービスのHTTPS化を支えたAWSで作るピタゴラスイッチ
@aereal
テーマ
テイクホームメッセージ
- バッチシステムについても、ソフトウェア構築一般の原則が使える
- 状態を持たない
- 分割統治
- ↑↑実現するための一例として、
- ワークフローエンジン：AWS StepFunctions
- pub/subをサポートするデータストア：DynamoDB
内容めも
- Let's encrypt
APIで証明書発行が可能
← はてなから寄付も。これから継続していく 万単位のドメイン。発行・管理を自動化しないと有料プランのサービスとしてきつい
配信の要件
発行の要件
発行の実装
更新の実装
考察：ピタゴラスイッチ
巨大なバッチの難しさ- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
全体がわからないとどこにどう手を入れていいかわからなくなる - 巨大なバッチ、扱うデータ量が巨大 → 処理時間が長くなる。成功／失敗のログが必要
- 全体でどれだけあって、どこで失敗しうる／したのか把握しにくい
さいきょうのピタゴラスイッチ
- ワークフローエンジンの導入
- 分割統治
バッチ処理側がデータの状態を気にしなくていいようにする
アプリケーション書くときは意識できてるのに、なぜバッチ設計ではできないのか？- 合成可能ではない
合成可能なバッチ
質疑
- SFnのテスト
ダミーのLamdaを呼び出すようにして動かしてみた - TTL Triggerで失敗したとき、DynamoDBから消えているからリトライできてないんでは？
TTLを仕込んだテーブルと仕込んでないテーブルの2つがある。
TTLは証明書の期限より2週間くらい早く設定している。
リトライにも失敗したらMackerelから通知が来るのでログを元に手動対応。 - proxyのリロード、メモリにのっていたもの消えちゃうんでは？
proxyのリロード = nginxのプロセス再起動。memcachedにのっているのでnginxを立ち上げ直しても影響はしない。
memcachedにも無かったらDynamoDBに取りに行くが、そのときの遅延も許容範囲内だった。 - AWS SFnの設定をJSONで書くの、気持ちのいいもの？w
全体でどういう状態があるか、みたいなスキーマが特に無いから今は平気。
だけどミスったときに検知できない。バッチ側から可能的な状態一覧を生成するようにしたい。。。
感想
ソフトウェア設計の考え方をこういうシステム設計に適用するっていうの、ちらちら思ってたけど全然実現できてなくてすごく参考になった。
TTL Triggerみたいなマネージドサービスの機能をきれいに使ってるの見て、自分の思考がアプリケーション（プログラム）の中に閉じてたのに気づいた。
解くべき問題（要件）をまとめた後、何が最短経路かを構成全部から考えられるようになりたい。
こういう設計力、勉強というより実際のサービス設計・運用とかその過程でのディスカッションとかから得られるのかなあ。
日常にディスカッションが足りない……。
builderscon tokyo 2018 聴講メモ #5「高集積コンテナホスティングにおけるボトルネックとその解法」by P山さん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
高集積コンテナホスティングにおけるボトルネックとその解法
@pyama86
GMOペパボ ホスティング事業部
ロリポップ！ マネージドクラウド
テーマ
- 7分であなたもコンテナーマイスター講座
- はまった問題
- 展望
テイクホームメッセージ
- コンテナのボトルネックはLinuxコマンドを駆使してあたりをつけて解決する
- そのシステムコールが何をするのか、基礎的学習が必要（manを読んでわかるように）
『Linuxプログラミングインタフェース』
内容めも
コンテナ = プロセス
FastContainerアーキテクチャ
事象：監視コンテナのダウン
事象：コンテナが起動しない
- bridgeにインタフェース追加するとき：1025になっている。上限ぽいな
- BR_PORT_BITS：10 ← 1つのbridgeに2の10乗がポートの上限
- bridgeを分散させる
事象：CPU・メモリには余裕があるのにLAが高い
- cadviser：google製コンテナリソース管理
- gdb → bt（back trace）
- iproute2でnetlinkを利用したNSID取得 ← 最新のソースでは取得していなかった
もともと、ディストリビューションが配布しているパッケージでインストールしていた - 取得しないようにしたら2秒→0.05秒へ
gdb 便利
ディストリビューション配布、意外と最新のソースと乖離している。詰まったらソース読んで見る4000コンテナ弱でメモリ枯渇 = リソース使い切れた！
システム調査コマンド valfrind
あるwordpressサイトにabかけたら別のサイトが落ちた
コンテナなのに……？
質疑
- 直感的に、コンテナの起動はI/O等に比べて負荷にはならなさそうだけど
うちではディスクI/Oは負荷にはなっていなかった - コンテナの起動速度（イメージによりそうだけど）
過負荷状態でなければ1秒以内。起動直前の状態をメモリにのせて、メモリから起動する方法を検証中 - iproute2入れ方
makeインストール
感想
「測定 → バックトレース → ソース読む」の流れ、言うは易し行うは難しだ……。インフラ屋さんすごい……。
今まで現職でもうわからんって匙を投げてたところをこういうふうに調べて直していけたらどんなに良いだろう。
ものを言うのは知識と努力だ、がんばろって思わせてくれた。
あと何より面白かった！w
こんな高い技術あってこんな楽しく話す人と働けたらめっちゃ楽しいだろうなーって、こういう人たちと一緒に働けるくらい勉強と経験を積まないとなーって思った。
builderscon tokyo 2018 1日目に参加してきた
行ってきたーーー！
全部のトーク聞けないのもどかしすぎたけど、選んだどのトークでも「知らなかった、を聞く」を圧倒的な衝撃をもって体験させてもらった。
エンジニアになってよかったって、身体にすとんとくる感覚があった。明日も楽しみ。
トーク
トークはこちら↓↓を拝聴した！
全部メモを取ってたんだけど、ちょっと内容に自信無いものもあるから抜粋で記事にあげた。
産業でガチ利用されるRaspberry Piの話
産業でガチ利用されるRaspberry Piの話 - builderscon tokyo 2018
by @kazuph さん
ラズパイほんとに使われてるんだ……！ っていうレベルのガチ無知だったりしたんだけどちゃんと聞けたw
セキュリティとかログとか、webと同じテーマだけど違う制約の問題になっているところが個人的に面白かった！
開発現場で役立たせるための設計原則とパターン
開発現場で役立たせるための設計原則とパターン - builderscon tokyo 2018
by @shinpei0213 さん
あるあるすぎる課題を「『デザパタによる構造化』と『設計原則によるレビュー』とのサイクル」で鮮やかに解決しててテンションあがった！
事前知識なしで理解する、静的検査のいろは
事前知識なしで理解する、静的検査のいろは - builderscon tokyo 2018
by Kuniwak さん
スライドめちゃくちゃわかりやすかった！ 構文解析をひとさらいするとソースコードとかエラーメッセージとかの見方が変わって面白いなーと。
これからRubyやるし、rubocop読もうというきもち。
これはスライドが完璧すぎて足すこと無い……w スピーカーの方がブログ記事上げていらしたので貼らせていただきます↓↓
機械学習を用いず数学でゲーム内の需要予測をする
機械学習を用いず数学でゲーム内の需要予測をする - builderscon tokyo 2018
by @nessie_sesein さん
数学徒な名言がばんばん出てきて楽しかったw 黒い羊の寓話を体現するようなセッションだった。
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう
airflowを用いて、複雑大規模なジョブフロー管理に立ち向かう - builderscon tokyo 2018
by Attsun さん
airflow気になってたから聞けてよかった。Pythonのコードで管理っていうのイメージつかなかったけどふむふむ、てなった。
サーバー大丈夫か……？ てなったけど豊富な余力があるのねブレインパッド……！w
スライド公開されてた！
builderscon2018 airflowを用いて、 複雑大規模なジョブフロー管理 に立ち向かう - Speaker Deck
安全なランダムネスの理論と実践
Safe randomness: theory and practice - builderscon tokyo 2018
by Kenji Rikitake さん
はずかしながら全然考えたことなくて、PCのハード部分（打鍵とか）からランダムネスを生成する発想も知らなかった……！
こちらもスライド公開されてた！
Safe randomness: theory and practice - Speaker Deck
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話 - builderscon tokyo 2018
by Rui Ueyama さん
ちょっとこのトークの感動はまだうまく言語化できてない……。
メモだけ↓↓
builderscon tokyo 2018 聴講メモ #4「lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話」by Rui Ueyamaさん
（スライド公開されたら貼らせていただきます）
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
lld − 開発ツールの主要コンポーネントの1つをスクラッチから作成した話
@rui314
テーマ
- lldの紹介
- 開発を始めた経緯
- 速くてシンプルなコードを書くためのポイント
- 具体的な高速化のテクニック
テイクホームメッセージ
- 問題についてよく考えて、自分が良いと思うやり方を勇気をもって試してみよう
仮にアンチパターンであっても - 存在しない問題を作り出さない。もともとの問題を直接解決できないのか、をよく考えよう
- 「Unixの開発環境の標準リンカになる」という大きな目標も、誰も挑戦しないだけで意外と実現可能だったりするので、挑戦してみよう
内容
- リンカ：オブジェクトファイルを1つの実行ファイル・DSOにまとめるもの
- 何もしないプログラムのソースコードを、既存のリンカに入れて、出力されたバイナリを印刷して読んだ
→ 1bitだけ変えてみたりして理解していった。 - 当時、Linux, Windows, mac OS すべてファイル形式違うのにひとつのリンカでやっていた
→ スクラッチで書き直し。Windowsだけターゲットとするようにした- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
→ 無視して書いたら10倍早くなった。 いちいち対応してると 無い問題を解決しようとすることになる - 遅いプログラムを構造によって早くすることはできないが、構造によって自然と早いプログラムが書ける
構造が先、コードは後
- 「書き直したくなる気持ちはわかるけど」「リファクタリングでいいのでは」などの意見
- 他の人が、同じデザインでLinuxのリンカを作った → 4バージョンに対応することに
- OSSとして、オーナーシップを持っておく
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
→ 送ること自体は良いが、それを取り入れるかはオーナーが判断する
きれいなコードはオーナーが保つ
- 1回しかコントリビュートしない人が、自分の（狭いスコープで）達成したいことのためにプルリクを出してくる
- 2回書く ← 1回目から学ぶ。できれば3回書く
質疑
- 「コードを2, 3回書き直してみる」：最初のコードに引きずられそう
1回目書いてるときに思った「ここをこうしてみたら」を次に実践してみる、思いつくものは全部試す感じ。
しっくりくるものを探す。 - 「コードを共有しない」：改修コストがある反面、共通化するとif文が増えたりする。どう選んだ？
勘です。 - 次の目標は
Linuxのディストリビューション全体が10秒でビルドされる、とか？w
カーゴ・カルト・プログラミングはやらない。
80年代に決められたデフォルト値に従う理由は無い。
感想
さいしょわかんないとこ来ちゃったーと思いながら聞いてて、終わったときにはエンジニアとして何かを叩き起こされたような感じで、まだうまく言葉にできない……。
すごく素敵なセッションだった。動画公開されたらまた改めて聴いてみる。それでできれば改めてまとめてみる。
builderscon tokyo 2018 聴講メモ #3「機械学習を用いず数学でゲーム内の需要予測をする」by @nessie_seseinさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
機械学習を用いずに数学でゲーム内の需要予測をする
@nessie_sesein
カヤックのゲームレベルデザイナー
テーマ
純粋数学の見方・考え方を理解する
分析の重要性と問題
- 数学について
- ゲーム内の需要予測
テイクホームメッセージ
なぜの追求、数値と言語の行き来
- 理論ベースで需要予測を行うと、機械学習とは違って未来を最適化するアクションが見えやすい
- データが少なくてもいける
- 時間が経つと予測がズレるが、原因を見つけやすい
内容めも
- 分析の重要性と問題
- 純粋数学
- 証明するまで正しさを認めない、見える範囲の事実にだけ言及するのが数学
- なぜの追求：事実以外の認知をしたとき、なぜ自分はそう考えた？ を追求する
- 数値と言語の行き来：数値による根拠を元に認知する。バイアスを取り除く
- ゲーム内の需要予測
あるある：「新規ガチャ売れた → 復刻ガチャでも売れるでしょ！」← なぜ主観的予測がこうなるのか？
もし売上構成が「課金上位者10％が売上の90％を占めていた」場合、その人達がガチャをコンプリート・カンストしたら買わない
→ 残りの課金下位90％（売上の10％を占めていた）の人達だけが復刻ガチャに課金しうる- 前提条件とゴールの設定
- データを眺める
サンプル500くらいあればいいと統計学的には良いと言われるけど、高々有限なんだから全部見ればいい。
自分は5,000くらいは眺める - 仮説作成
- 仮説を数値に落とし込む
ゴール（ユーザーがガチャを何回回すか）と相関がありそうなものから順番に処理。
「レベル5になったら何人かのユーザーは満足しちゃうかな」→ とりあえず8割くらいガチャやめるとする
端点さえ合っていれば中身はどうとでもできる
= 相関係数を元に一度 y = ax + b を用意して、例えば上側にふくらむ非線形の式にしたいのであれば、上側にふくらませるf(x)をかける
→ y = (ax + b)・f(x) - 例外処理・微調整
土台の式ができても、3割くらいはズレている → 外したり、影響を小さくする関数をはさんだり
→ ゴールと相関のある部分を求めて、例外をつぶしていく
- 施策
改を出す前に、☆5の排出率を上げて、改を欲しがりそうなユーザーを増やしておく → 売上144% - 機械学習
ユーザー数はあっても、1ユーザーあたりの試行回数が少ないと処理する例外が多くなる。
前処理しやすい、DBが機械学習用に整っている、データが多い、というケースでは機械学習が適用できる。
そうでなければ理論で予測したほうがいい。
質疑
- 今のお話に必要な数学的素養を身につけるのにおすすめの本
普段から「なぜ？」を考える癖をつけてみるといいかも - ドメイン知識・仮説
自分が「なぜ」を追求して、誰にでもそれを説明できるように用意する。
自分がユーザーにもなって、行動経済学や心理学の知見ともあわせながら説明できるようにする。
感想
面白かったあー！
言葉の端々に数学徒感が出てて楽しかったw 「高々有限なんだから全部見る」は名言。
定理・公理や数式ではなくて、なんていうか「"数学的"なものの見方」にこだわって話を進められていた。
質疑にあったように日常的な習慣づけで数字の扱い方を変えていけるんだなって素直に思った。
でも別に知識が何もいらないということではなく、普段からなぜを考えていくことで知識の身につけ方も変わっていくのかなあとか。
大人になったあとの勉強の仕方もあるかもしれないと思った。
builderscon tokyo 2018 聴講メモ #2「開発現場で役立たせるための設計原則とパターン」by @shinpei0213さん
（スライドもし公開されたら貼らせていただきます）
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
開発現場で役立たせるための設計原則とパターン
by Shinpeim
『WEB+DB vol.91』データ構造特集がおすすめ
テーマ
- このケースで何が最適か、どうやって判断するの？
「適材適所」「ケースバイケース」は何ら回答になっていない
テイクホームメッセージ
- 複数の選択肢を用意する → 問題の「変わりやすいところ」を考慮して設計原則からレビュー を繰り返す
- 設計原則
- 単一責任原則
- 開放閉鎖原則
- 凝集度・結合度
内容めも
設計・パターンは抽象的な話が多く、空中戦になりがち
- 「抽象化」って人による
- 「責務」って考え方による
「システム全体に責務を持つからSystemManagerクラス作ろう」← 反論できるか？
そもそも設計って？
複数の分割構造の選択肢から 選び出す こと。設計原則・デザインパターンはその武器- デザインパターン：カタログ
- 設計原則：良い構造かを判断する指針
パターンを使って分割する ⇔ 目の前に立ち上がってきた構造に対して、原則を使ってレビューする
例題：掲示板ウォッチスレ 投稿通知機能
単一責任原則
でも「責務」ってふわっとしてる……
あるモジュールを変更する理由が2つ以上あってはいけない
「なんとなく駄目」だったのが「コメント通知の仕様変更でもスター通知の仕様変更でもこのクラスに変更が必要になるから、駄目」になる開放閉鎖原則
例題：引き落としできなかったらsuspend、3回引き落としできなかったら永久追放
新しい機能を足す時に、既存のクラスを書き換える必要がある ← 拡張に開かれていない凝集度と結合度
凝集度は高く、結合度は低く- Customerに関する操作をCustomerSuspenderにやらせてしまっている
- Customerにとって他人であるCustomerSuspenderの処理をCustomerが何度も呼ぶ必要がある
「なんかオブザーバーパターンっぽくね？」ってにおいを感じる
- CommentObseverを作ると、そいつはスターというイベントは完全スルーできる
- パターンに従ってCommentとCommentObsercerを分けてみたけど、分ける必要はあるのか？
そもそもオブザーバーパターンて何だっけ、から「開放閉鎖の原則」を評価軸にする- 今回のケース、拡張される？（コメント発生時に通知以外のイベントが足されることある？ オブザーバー足される？）
→ 結合度はOKだが、現実的な未来予測について見るとそもそも分ける必要があるのか不明 - 今回のケース、修正に対して閉じなければならないの？（コメントの仕様が変わったとき、通知の仕様はそのままなの？）
→ むしろ凝集度がNG
- 今回のケース、拡張される？（コメント発生時に通知以外のイベントが足されることある？ オブザーバー足される？）
- パターンを使って構造化したとき、設計原則を使ってレビューすると「実は不適切では」ということもある
Commentクラスにひとまとまりにしてしまう
単一責任原則はどうなる？ まざっているのでは？- コメントの仕様が変わる（→ 通知の仕様もきっと変わる）ときに、Commentクラスだけの改修で足りる
→ 単一責任原則を満たしている
- コメントの仕様が変わる（→ 通知の仕様もきっと変わる）ときに、Commentクラスだけの改修で足りる
まずは問題を見極める = どこが変わりやすいポイントか
コメント発生時に通知以外のイベントが足されるのであれば、オブザーバーパターンでよかった。
どこが変わりやすいポイントかがわからないと、単一責任原則で設計のレビューができない未知の問題に対する解決
どこが変わりやすい（やわらかい）部分で、どこが変わりにくい（固い）部分なのか、まずは問題と向き合う。
KISS原則、YAGNI原則
質疑
- 設計原則について適用フェーズによって分けられるかも？（← あまり聞こえなかった）
SOLIDの原則のうちSとOが今日の話だった。KISSやYAGNIもやや抽象的なもの。
LとかDは抽象度が低く、自分で構造を考えるときに使えるかも。 - チーム開発で、設計レビュー時には一通りコードを書いてしまっている
前職は採用時に絞っていて、暗黙知で通っていた。
現職では設計レビューうまくできていない。
感想
「なんかあかん」設計にデザパタ適用して、それをさらに設計原則からレビューする、ていうサイクルを実演してみせてた。
オーディエンスが例題見た時に持った「なんかあかん」をきれいに議論に落とし込んでてとてもスマート、聞いててテンションあがった。
自分のためにもチームのためにも、パターンと原則を武器として身につけねば……！
アニメと構成そろえてて、合間合間に息子さんのショットが入るの和んだw
builderscon tokyo 2018 聴講メモ #1「産業でガチ利用されるRaspberryPiの話」by @kazuphさん
※ 以下は私個人の解釈を多大に含んだメモ書きです。正確な講演内容はスライドか、もしくはYouTubeで公開される（？）公式動画をご覧ください。
産業でガチ利用されるRaspberryPiの話
@kazuph
- 日本で最初のスマートロックAkerun
テーマ
- なぜラズパイ？
- 利用実績
- より強固なデバイスにするために
- ラズパイで駄目な場合
テイクホームメッセージ
- ラズパイが完全に品質面で他を圧倒している
- ラズパイが完全にIoTレディーになった（Wi-Fi, Bluetooth対応によって）
- ラズパイが同類では最安
- 大量のソフトウェア資源があるので、試作・開発コストが低くて済む
内容めも
ラズパイ：高い品質・安価・汎用的な開発環境・安定供給
利用実績
- Akerunプロトタイピング
秋葉原で買える、Pythonで書ける。買い出し含めて1日でできる。 - 組み込み製品のデバッグ
Node, Python, Golang
Jenkinsでビルドしたイメージをラズパイ経由で組み込み製品に反映させる - 工場での出荷ツール
状態をラズパイ経由で飛ばしてPCのブラウザから確認できる
向上ツール開発祭り（治具祭り）← テンション上がらないので「祭り」として数日間実施
工場でAnsible：物理的に組み立て → 検査 → 自壊プログラムを流し込む → Ansibleを流せなくする
2016年から一回も交換なし - IoTゲートウェイ
工場で実際に使っていて、大丈夫だと思った
BLEが標準搭載になって、別途ドングルを買う必要が無くなった
性能：1m離れたところで計測すると、旧製品が25％くらいだったのがラズパイで80％近く
5m離れると差は小さくなる、これはBluetoothの仕様として当然- 電源まわり：
ラズパイだけだと怖い。雷サージ対策済みのACアダプタ、拡張基盤で静電気対策 - ログ：
容量・I/O上限・接続できない（お客さんの環境に置いてあるので）
→ すぐ削除、できるだけオンメモリ、S3に日次アップロード - セキュリティ：
大事なものはSDカードに置かない
機密情報はすべて拡張基盤（nRF52）
ゲートウェイ起因でクリティカルな処理が行われないように。乗っ取られても開かない（サーバーからの指示が必要）
あくまでゲートウェイとして暗号化されたあれこれを仲介しているだけ、「開ける」という動作を起こせない - ソフトウェアアップデート
nRF52でイメージ作成・更新してラズパイに反映させる（？）
- 電源まわり：
- Akerunプロトタイピング
ラズパイでは駄目なとき
質疑
- 使う上で気をつけること
正直あんまりケアしていない。濡れたり静電気とかは別だけど、雑に使っても意外と大丈夫。
SDカードは耐久試験して使ってる。良いやつを使うべし - ゲートウェイとして使うとき、ラズパイがどこかに置いてあると思うと物理的なセキュリティが気になる（SDカードが抜かれていじられたり）
レンタルというビジネス形態上、SDカードを抜けないようにはしていない。
スマートロックの場合、基本的にラズパイは室内に置いてあるのでいいでしょうと思っている。 - ラズパイの次のバージョンで改善してほしいところ
今でもLinuxベースなので改善はしていけると思っている。
IoTまわりの通信規格、新しいのが出てきている。範囲が広く、通信量も保てる規格が出たらそれに対応したくなると思う - 5GHz対応が必要になる場合というのは 企業ユースの場合、5GHzを必須で求められることがある
- TensorFlow？
うちでは使ってない、ファームビルドが対応してるよという紹介だった。最近ラズパイ用のビルドが出たので使ってる人もいるらしい - SDカード選定
メーカーを選定 → 連続で書き込み・読み込み - ラズパイ0
安価で小型で、良いなと思っている。
ただ品質がまだ不安、有線LANに対応しておらずtoBだと合わないかもしれない。 - SDカード
T社じゃないですかねw
感想
使ってみたくなった！！
組み込み系ぜんぜんやったことなくて用語がたまにわからなかったけど、WEBなところもあって（むしろWEBとの境界が曖昧になっていて）意外とわかりながら聞けた。
セキュリティとログみたいに、WEB開発と同じテーマで前提の違う解決をしてるの知っとくとWEB開発にも活かせるところがある気がした。
