giantneco’s blog

技術メモ

builderscon 2018

9/7, 9/8 に builderscon tokyo 2018 に参加してきた。 builderscon はあまり技術分野などの縛りがないカンファレンスで、 他のカンファレンスではなかなか聞かない話が聞けるおもしろイベントだ。 縛りがゆるいとはいえ、発表内容は結構レベルが高いものも多い。

Web周りから低レイヤまで幅広いジャンルの話が聞けるので、 参加したらなにか一つは引っかかるものがあるんじゃないだろうかと思う。 これまで聞いたことがない話を聞きたいという人にはすごいあっているじゃなかろうか。

会場は一つを除くとさほど狭くないので、 観るセッションは決めておいて早めに並んでおかないと見逃しやすい。 自分も結構聞きたいセッションを逃してしまったので、ここらへんは改善してほしい。 そういうのは会場変えないと難しいのかもしれないが…

ちなみに開催場所は日吉。 Google Map での表示を見ると駅から少し歩くように見えるが、 実際には駅から出てすぐの建物になるので初参加の場合は気を付けたい。 前回初参加のときはちょっと間違えた場所に行ったが今回は間違えなかった。

以下見てきたセッション

Envoy Internals Deep Dive by Matt Kelin

Envoyはマイクロサービス向けのサービスプロキシ。発音は「あんぼい」に近い。

Envoy とは

Envoy はマイクロサービス向けのサイドカーロキシー。ユニバーサルなデータプレーンとも。 このサイドカーロキシーは、マイクロサービスを動かすノードに常駐して、 アプリケーションや言語、フレームワークによらずロードバランシグなどを行ってくれるものを指すようだ。 同じノードにのるということで「サイドカー」ということなのかも。

背景

Envoy はマイクロサービスを作るにあたって出てくる次のような問題を解決する: * 複数の言語とフレームワークの解決 * 複数のプロトコル ( HTTP/1, HTTP/2, gRPC etc ) * ブラックボックスなロードバランサ (AWS ELB とか) * 一貫したモニタリング方法がない (統計、トレーシング、ロギング) * 足りない機能 (リトライ、サーキットブレーカー、タイムアウトなど分散システムのベストプラクティス * 認証周り * 言語ごとに存在するサービス呼び出しのライブラリ * レイテンシーやエラーのデバッグの難しさ * マイクロサービスアーキテクチャを信用していない開発者

Envoy は、ネットワークはアプリケーションに対して透過的=アプリケーションの問題が起きたときにその発生元が簡単に特定できるようにしたい。

Envoy の目標

  • プロセスアーキテクチャの外側で動かす
  • 低レイテンシ、高パフォーマンス、高開発効率
  • L3/L4 フィルター
  • L7 での HTTP フィルター
  • HTTP/2 ファースト
  • サービス・コンフィグディスカバリと API の提供
  • アクティブ・パッシブなヘルスチェッキン
  • よりよいロードバランサ
  • サービス・ミドル・エッジプロキシー
  • ホットリスタート

Envoy のアーキテクチャ

xDS API による設定マネジメント

  • Envoy is a universal data plane
  • xDS == X Discovery Service つまり:
    • LDS == Listener Discovery Service
    • CDS == Cluster Discovery Service
  • gRPC ストリーミングや JSON/YAML REST Protocol Buffers (proto3) もサポート
  • 中央集権的に Envoy 設定を管理することができる
  • Eventual consistency

Envoy のスレッドモデル (c10k)

  • アイディアとしては、スレッドにイベントループを持たせて複数のコネクションを操作する
  • メインスレッドはデータと関係ない様々なタスクを実行
  • ワーカースレッドは並列にリスナー、コネクション、プロキシをハンドリングする
  • ブロッキングを避けるためにファイルのフラッシュをするスレッドを持つ
  • 100% ノンブロッキング
  • RCU (read-copy-update) をメインスレッドとワーカー間の共有に使用

ホットリスタート

Envoy はコネクションを一切切らずにバイナリのリロードができる。 仕組みとしては: * ソケット、ロックはシェアドメモリー上に持つ * シンプルな RPC プロトコルunix domain ソケット上で使用 * ソケットなどはプロセス間でやり取りする

Caching at Netflix: The evolution of EVCache by Scott Mansfield

EVCache = Ephemeral VOlatile Cache は Netflix が開発している KV ストア形式のキャッシュ。 特徴として: * 分散、シャードされた KV ストア * memcached を基にしている * インリージョンかグローバルかチューニング可能 * AWS に最適化している (AWS は色々問題があるので)

パフォーマンスの話で性能について話すのにパーセンタイルを使っていたのが興味深い。 聞いてみるとパフォーマンスのイメージを掴みやすいかったので、ぜひ自分もマネしたい。

パフォーマンスの問題解決については同じフロアに Brendan Gregg (詳解システムパフォーマンスの著者、パフォーマンス研究のすごい人)がいたのがよかったとのこと。

カクヨムでの縦組み表示の実装と縦書きWebの将来に向けて by nanto_vi

カクヨムで行っている縦書き表示での苦労と将来的にはどうするかについての話。

縦書き表示は CSS では規格があるものの、そのまま使うと表示がおかしくなる例があったり、バグも結構あったりで大変だったらしい。

後半ではバグの報告の行いかたについての話があった。

バグを新たに報告する際には次の3つを書くとよい * 簡潔な再現コード (jsfiddle を使うのが便利) * 期待する挙動 * 実際の挙動

あと Web 屋さんにとってはブラウザ間の挙動の違いもバグに含むものらしい。

謎ガジェット by @uzulla

https://builderscon.io/tokyo/2018/session/442f46cc-c888-4cc6-8e66-0f17144ea5fb

おもしろガジェットを作ったという話だが、作った数が 200 台ということでなかなか普段聞くことがない話を聞けた。

200 台なのでバッテリーが200個とかネジが 4,000 本あったりとするので購入するのにかなり苦労したという話も。 実際に小規模な大量生産しようとすると訳に立ちそうな話がたくさんあった。

途中でも人に評価してもらうことが大事で、作業に集中しているとすごい見落としてしまうことがあるそうだ。

Java カード @moznion

Java カードの話。SIM カードやクレジットカードはこの Java カードらしく、それらのカードの上で jvm が動いている。 当然制限は普通の JVM よりかなり厳しく型は byte だけだし、メモリの扱いなどにもかなり癖がある。

たとえば、電源を切っても Java カードの vm はとまらず、インスタンス変数のデータは残り続けるなど普通の環境とは違うことが多々あるようだ。

lld, rui314

lld の話。今回の builderscon で聞きたかった話。 lld はとにかく高速ということで、最近色々なプロジェクトで使われているし、特に FreeBSD ではデフォルトのリンカになっている。

最初は Windows 上のリンカとして作られたが、ELF 向けのパッチが送られてきてなし崩し的に他のものもターゲットになったというこ。

高速にするためのコツがかなり聞けたので良かった。 * よいデータ構造にするのが重要:データが先、コードが後 * 2回書く、1度目の経験を2度めに活かす * 最適化する箇所を最小にとどめる

gold との違いが気になっていたが、gold ではスレッドをタスク、ワーカーで扱うなど汎用的な書き方にしているので lld よりも遅くなっているのではという話。

Securty, privacy performace of next-generation transport protocols, Kazuho Oku

ネットワークプロトコルのセキュリティで、主に TLS の現状と将来のQUIC の話を聞いた。

現在の TLS 1.3 でどのような問題があって、 QUIC ではどのように解決しているのかなどを聞いた。 主な話としては: * TLS 1.3 * QUIC * Encrypted SNI

といったようなあたらしい拡張でプライバシーを確保することができるようになり、 セキュリティ面でこれまでの TCP/TLS とはかなり違った世界になるらしい。

ルーター屋とプロトコル屋で意見に違いがあったりしてな興味深かった。

TLS

  • TLS 1.2
    • ハンドシェイクには時間がかかる: Hello -> 鍵交換 -> 終了通知 -> 終了通知
    • 最初のパラメータ交換のときは暗号化されていないので、クライアント証明書・サーバ証明書がバレてしまう
    • iOS はクライアント証明書が端末単位なので、あるユーザがどのネットワークにいたのかがわかってしまっていた (トラッキング)
  • TLS 1.3
    • 最初に公開鍵を交換してとりあえず通信を暗号化
    • 暗号化してから証明書の交換

QUIC

TLS over TCP では man-on-the-side アタック = パケットを観察して RST などをインジェクションする攻撃が多い。 これは他の攻撃に対してコストが安く済むため。 この攻撃に対策するためには、認証付きでパケットを暗号化するのがよくて、QUIC ではそれを行っている。

  • QUIC の特徴
    • encrypted transport
    • handshake in 1 RT
    • mulitiplexing streams int on connection
    • fix head-of-line blocking int HTTP/2
    • mobility (network migration)

QUIC の問題 * 暗号化 * 複数のストリーミングの1つで暗号化のための前処理を行っているので、他のストリームからはいつ QUIC で暗号化通信が開始できるかの判断が難しい

Encrypted SNI

SNI = Server Name Identity も暗号化が進められている。まだドラフト段階。

Excel 依存からの脱却と失敗

非常にレガシーな体制な会社でワークフローを Excel 依存から切り替えようとしてうまく行かなかった話だった。

技術選定に失敗したとあったが、技術選定は選ぶ余地がある場合に使う言葉ではなかろうか。

上からの命令が絶対で、技術の選定が技術的な理由でなく政治的な理由から決まるというのはかなりひどい話だ。

最初から最後まで成功しそうな感じがしていなかったので、大変でしたねと言う他ない。

自分が作ったシステムで人が首になるというのはかなり胃が痛いらしい。

なぜエンジニアはパフォーマンス計測しないのか , @mogetta

健康の話

ウェアラブルバイスや IoT 機器など、健康に関する色々なガジェットを試してみたという話だった。

色々製品が紹介されたので、若干通販番組のような気分だった。

結構お金がかかっているが、健康のためにはしょうが無い。。のか?

紹介されてたモノ * HEALBE Gobe2 * Withings Wifi Body Scale * Withings Activie * Withings Sleep * JINS MEM * Spire

話を聞いてて欲しくなったがちょっと高い…。

計測結果はは Firebase に入れておいて、いろいろグラフを作りやすくしていたらしい。 やっぱり計測は大事か。

Chrome デベロッパーツールのハック

Chromeデベロッパーツールをうまいこと使ってテイラースウィフトのチケットを入手したという話。 テイラースウィフトのPVをたくさんみると、チケットが購入しやすくなるというキャンペーンをやっていたらしく、 紹介されていたハックは youtube の動画の再生数をスクリプトを使って稼ぐようにするものだった。

スクリプトを作るために、まず最初にChromeデベロッパーツールを使って、 動画の再生速度を上げたり自動再生するようにしたりするリクエストがどうなるかを調査していた。

そして狙いのリクエストが作れたらクリップボードにそのリクエストがコピーできるので、これを cURL などに渡す。 後はシェルスクリプトでもなんでもこのリクエストを投げるようにして目的達成となる。

普段フロントエンドそれほど触ったりしないので、興味深く話を聞いていた。活用できれば便利そうだ。

1 日 700,000 ビルド: Docker と Nomad が支える CI/CD プラットフォーム

Circle CI でどのように CI/CD プラットフォームを提供しているかという話。

Docker は当然として、Nomad は全然知らなかったので使っているとは思わなかった。 ただ話を聞いていると、たしかに妥当だなという感じがする。