<-- mermaid -->

GitHub・Slack・Google、世界のトップエンジニアが集結 —— QCon NY 2019レポート(Day 1)

こちらの記事は以前にNewsPicks Tech Guideに投稿された記事をインポートしたものです。元の記事はid:monzoupによって書かれました。

こんにちは!NewsPicks エンジニアの文字と Quartz エンジニアの大川です。6/24 からニューヨークで開催されている QCon NY 2019 に参加しています。今日から数回に分けてこちらのカンファレンスの参加レポートをお届けしようと思います。

QCon NY は 3 日間のセッション・2 日間のワークショップがあるのですが、今回はまず初日に私たちが参加したセッションについて簡単にご紹介します。明日以降、特に面白かったセッションを取り上げて個別に紹介していこうと思います。

海外の QCon には初めて参加したのですが、日本ではなかなか聴くことが出来ないようなセッションが多く非常に面白いです。本当に多様なセッションがありますので、ぜひ皆さんにも QCon の魅力を感じて頂ければと思います。それでは早速どうぞ!

Keynote: Learning from Machines

by Ashi Krishnan - Building the Next Generation of Developer Tools @Github

コンピュータにより生成された動画・3DCG を多用した、視覚や音で五感を刺激するキーノート。機械学習による認識のモデルを示しつつ、生物と人工物の違いが語られました。個人的にはこれほど演出に凝ったプレゼンというのは初めて見たので、大変刺激になりました。

スピーカーの Ashi は子供の頃からプログラミングをしてきたハッカーのようで、このセッションと彼女のウェブサイトを見るだけでその非凡さが分かります。まさに世界レベルの天才という感じ。こういう人のセッションを日本で聴くことはないと思うので、貴重な経験でした。

Ashi Krishnan

Scaling Infrastructure Engineering at Slack

by Julia Grace - Senior Director of Infrastructure Engineering @Slack

急成長してきた Slack のインフラをどのように整えてきたかというセッション。Slack は 2015 年で 2.5M DAU・2016 年で 4M DAU・エンジニアが 150 人だったそうですが、この時点でインフラを担う組織は存在しなかったそうです。また、2017 年の時点でもバックエンドは Hack/PHP モノリス・フロントエンドはライブラリを一切使用しない JavaScript で開発されていたそう。このようなプロダクトドリブンな会社において、いかにしてエンジニアリングが中心のインフラ組織を作って改善してきたかというお話でした。

全体的にテクニカルな話というよりはマネジメント寄りのセッションでしたが、特に急成長中のスタートアップにおいてはありがちかつ解決するのが難しい課題だと思うので、非常に面白く聴くことが出来ました。

(こちらは後日別記事で紹介予定です)

Machine-Learned Index - Research from Google

by Alex Beutel - Senior Research Scientist @Google

Google の中の人による ML for Data Systems のセッション。セッションでは古典的なデータ構造の紹介から始まり、機械学習を使ってこれらをどのように改善出来るのかというお話で抜群に面白かったです。

例えば 200M の地図データを B-Tree に格納した場合、GPU/TPU・SIMD 最適化なしで Learned-index は普通のインデックスに比べて 60% lookup faster, 1/20 spaces で格納できたそうです。他にも Hash Map では 70% Collision を削減。Bloom Filter は 35% メモリ使用量を削減などなどの成果が紹介されていました。同じようなことは他のデータ構造やアルゴリズムに適用できるよねという話でセッションが締めくくられました。

(こちらは後日別記事で紹介予定です)

Driving Technology Transformation at @WeWork

by Hugo Haas - Fellow Engineer, Developer Platform @WeWork

世界中でコワーキングスペースを核としたリアルビジネスを展開する WeWork の取り組みを紹介したセッション。WeWork は現在 466,000 の会員・485 の物理拠点・105 の都市・28 の国(中国も含む!)にまたがって事業を展開しており、真にグローバルな企業として急成長をしています。

ところが数年前に事業を開始した際は、それぞれの事業に必要なシステムがバラバラに開発されており、かつグローバル展開に対応出来るものではなかったそうです。そこで WeWork は ① 開発基盤の整備 ② DWH の整備 ③ グローバルなマルチクラウドインフラ基盤 の構築を進めたらしく、その知見について紹介されました。こちらもテクノロジーの詳細について深掘りするというよりはマネジメント寄りの話でしたが、大変参考になる良く整理されたセッションでした。

(こちらは後日別記事で紹介予定です)

PID Loops and the Art of Keeping Systems Stable

by Colm MacCárthaigh, Engineer @ Amazon Web Services

AWS のエンジニアによる、PID 制御をWeb システムにどうやって応用するかに関するセッション。PID 制御は機械制御において良く知られた手法ですが、AWS システムの中の Elastic Load Balancer や DynamoDB Capacity Planner などにも広く使われています。このセッションでは、AWS に PID 制御を導入する過程で得られたベストプラクティスやアンチパターンが紹介されました。

  • Open Loop なシステム(出力が観測可能になっていないシステム)を、 Closed Loop なシステム(出力が入力に変化を与えることができる)にすることが制御可能なシステムをつくる第一歩。例えば、AWS CLIが何かエラーを起こしても先に進んでしまうスクリプトは、Open Loop であって制御不能。
  • システムは一般的に、崩壊が始まるとべき乗則でその流れが伝播する。一部の失敗を全体に波及させないために、API Request 数制限(throttling)などを早いタイミングで検討することが大切。
  • FIFO Queue で状態更新を行うと、処理に時間がかかった場合に古すぎる状態にシステムが誤って反応することがある。LIFO Queue はこの問題に対するかなり良い解決策。
  • なるべくローレベルの正しい計測値を使って制御を行わないと正しい予測/制御ができない。OS が提供する Statistics は誤っていることがある。
  • 閾値制御は人間へのアラートには良いが、システム制御ではまず使わない方が良い。

Colm によるトークは Youtubeで視聴できます

Tackling Computing Challenges at CERN

by Maria Girone - CTO @CERNopenlab

CERN Openlab の CTO によるセッション。CERN といえば LHC ですが、ここでは PB/sec(!)単位のデータが生成されるそうで、これを処理するために全世界で分散計算をしているそうです。この分散計算環境(ほとんどプライベートクラウド)は

  • CPU: ~ 100 万コア
  • ストレージ ~ 1 EB
  • ネットワーク 100GB/s(DC 間)

という処理能力を持っているとのことですが、2026 年からは更に高性能な LHC である HL-LHC が稼働するそうで、このままでは全く計算能力が足りていません。2026 年までに 1,000 倍の計算能力という目標を達成するためには既存の技術の延長線上では実現が難しく、HPC 分野に様々な投資をしているそうです。具体的には FPGA や TPU・GPUs in ML・量子コンピューティング、それから少し経路は違いますが OpenStack などが挙げられていました。

Machine-to-Machine Interfaces

by Ari Lerner, Sr. Consultant and AppDev at Amazon Web Services

Ari は AWS の開発者ですが、このセッションは会社とは関係のないセッションでした。

User Interface はユーザーが操作する画面のことですが、Machine Interface は機械と機械がコミュニケーションを取るために使う約束や規則です。ハードウェアの世界でも同じように Machine Experience を考えることが Machine 同士の効率的なコミュニケーションを実現し、ひいては User Experience を良くすると Ari は主張します。

このセッションでは、RFID、Raspberry PI、 WiFi、Node.js サーバー、仮想通貨を用いて、有料駐車場管理システムのデモを行われました。その過程で生まれる Machine Interface に関する議論と考察がセッションの肝です。

「失敗状態を正常状態として設計せよ」というのが大きいメッセージでした。本デモのような環境では通信失敗や状態保存失敗などが頻繁に起こりうるので、これを最初から予測して設計に組み込んでおくことで、優れた UX を実現することができます。

個人的な経験ですが、最近とあるシステムをつかったら「本人確認のため登録されたアドレスにメールを送信しました。」という画面とともに、メールが届かなくて先に進めなくなったことがあります。これはまさに、失敗を組み込むべき例です。(登録アドレスは変わるかもしれないし、メールはスパムフィルタではじかれるかもしれません。)

Live Video Streaming at Scale

by Lysa Banks - IBM Distinguished Engineer, CTO Watson Media Cognitive Solutions @IBM

IBM Cloud Video の開発者によるセッション。IBM Cloud Video のアーキテクチャをオーバービューから各コンポーネントまでざっくり説明してくれるというものでした。弊社(NewsPicks)でも動画配信を行っているので、全体の流れについてはおおよそ想定通りでしたが、やはり基盤自体を自作しているだけあり独自の工夫も見られました。中でも UUMF というプロプライエタリな独自フォーマットを作っているのが印象的で、これを使って動画を保存しているところが興味深かったです。UUMF の特徴としては以下が挙げられていました。

  • マルチレイヤー
  • メインインデックスはストリーム
  • RTMP 互換のあらゆるコーデックに対応
  • UUMF を元に任意の VOD 動画を生成できる(FLV・mp4 など)

テクノロジースタックは以下の通り。

  • インフラ:Docker + k8s
  • RTMP ストリーミング:Java
  • Transcontroller:Clojure
  • Transcoder:C

ちなみに k8s と Java はどのセッションでも話題が出てくるぐらい人気でした。

Breaking the hierarchy - How Spotify enables engineer decision making

by Kristian Lindwall Senior Engineering Manager, Data and Machine Learning Infrastructure @Spotify

組織論で有名な Spotify の中の人によるセッション。意思決定のピラミッドを逆転させるという話が面白かったです。いわく通常の会社では職位が上になるほど意思決定のパワーを持つようになり、代わりに頭を使えなくなる(笑)。だからこのピラミッドを逆転させ、下位に行くほど意思決定のパワーを持ち、上位に行くほど本当に重要なことに頭を使えるようにすべきだというお話でした。

これは口で言うのは簡単ですが、実行するのは簡単ではありません。当たり前ですが、通常は経営陣が最も意思決定の権力を持つことになります。それでもこの意思決定の逆転を進めるために彼が使っているフレームワークが、Farnam Street のブログで紹介されている以下の意思決定マトリクスです。

The Decision Matrix: How to Prioritize What Matters

この意思決定フレームワークは「可逆 ⇄ 不可逆」「重要 ⇄ 重要でない」という二軸で意思決定を分類するものだそうです。このようなテクニックの他にも組織構造に工夫を加えることで組織の自律性を最適化されていて、大変勉強になるセッションでした。

(こちらは後日別記事で紹介予定です)


本日は初日に参加したセッションについてご紹介しました。今後は各日のセッション紹介に加えて、特に面白かったセッションを幾つか掘り下げて紹介していきたいと思います。よろしければこちらのブログをフォローして更新をお待ち頂けると幸いです。お楽しみに!

Page top