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

こんにちは！ NewsPicks エンジニアの文字と大川です。先日から QCon NY 2019 のレポートを順次お届けしていますが、お楽しみ頂けているでしょうか？

tech.newspicks.com tech.newspicks.com tech.newspicks.com tech.newspicks.com

今回は 2 日目に私たちが参加したセッションについて、簡単にご案内します。2 日目のセッションについても後日記事化していきますのでお楽しみに！

Keynote: No Moore Left to Give: Enterprise Computing After Moore's Law
Scaling DB Access for Billions of Queries Per Day @PayPal
A Dive Into Streams @LinkedIn With Brooklin
Maximizing Performance with GraalVM
Are We Really Cloud-Native?
The Not-So-Straightforward Road From Microservices to Serverless
Datadog: A Real Time Metrics Database for One Quadrillion Points/Day
Conquering Microservices Complexity @Uber With Distributed Tracing
Robot Social Engineering: Social Engineering Using Physical Robots
Modern WAF Bypass Scripting Techniques for Autonomous Attacks
Peloton - Uber's Webscale Unified Scheduler on Mesos & Kubernetes
Sink or Swim - Effective Collaboration between Eng & Product

Keynote: No Moore Left to Give: Enterprise Computing After Moore's Law

Bryan Cantrill - CTO @Joyent

異様に陽気な Bryan 氏によるムーアの法則の話。セッションでは、ムーアの法則の歴史に始まり、今後の展望として、量子コンピューティング・GPGPU・3D／2.5D 積層技術・カーボンナノチューブベースのメモリなど、新しいテクノロジーが紹介されました。

今後のコンピューティングは今以上に複雑化していくので、ソフトウェアエンジニアであろうと下位レベルのハードウェアに対する理解が重要になってくるだろうと改めて感じました。

Scaling DB Access for Billions of Queries Per Day @PayPal

Kenneth Kang - Software Engineer @PayPal
Petrica Voicu - Software Engineer @PayPal

PayPal のデータベースアクセスのスケーリングについてのセッション。主に Hera という OSS についての紹介でした。PayPal では OLTP DB が 2,000+・App Server が 200,000+ あるそうなのですが、マイクロサービス毎に DB が分かれているわけではなく、沢山のサービスが同じ DB を参照しているそうです。各サービスは当然コネクションをプールしているそうなのですが、そうするとコネクションが枯渇してしまう ── というところから作ったのが Hera とのこと。C++ から Golang に移行するなど、現在もアクティブに開発が続けられているようです。

A Dive Into Streams @LinkedIn With Brooklin

Celia Kung - Data Infrastructure @LinkedIn

LinkedIn が開発している Brooklin という分散システムについての紹介。世界最大級の SNS である LinkedIn にとって、大量のメッセージをいかに高速かつ確実に処理できるかは大変重要です。そのために LinkedIn は、スケーラブルで低遅延なデータパイプラインの構築に努めてきました。

しかし LinkedIn では次々に新しいストレージやメッセージングシステムが採用されるため、これに追随してデータパイプラインをひとつずつメンテナンスしていくのも大変になってきました。そこで彼らが作ったのが Brooklin という基盤システムです。Brooklin のコンセプトの 1 つは「anywhere to anywhere」で、様々なデータストアやストリームから、他のデータストア・ストリームなどにアウトプットが可能になるように設計されています。具体的には、Fluentd のようにプラガブルに In/Out を定義出来るようになっています。このようなプラグイン機構の他にも、CDC（Change Data Capture）などの特徴が取り上げられて紹介されていました。

QCon 開催当時（6 月末）は OSS 化されていなかったのですが、先日めでたく OSS 化されたようです。GitHub やブログなどに詳細な説明がありますので、解説はそちらに譲ります。

engineering.linkedin.com engineering.linkedin.com

Maximizing Performance with GraalVM

Thomas Wuerthinger - Graal Compiler Architect @Oracle

GraalVM を使ったアプリケーション開発についてではなく、GraalVM そのものについて解説するセッション。良く Graal と GraalVM を混同してしまいますが、Graal は JIT コンパイラです。GraalVM は JIT コンパイラとして、C2 ではなく Graal を利用しています。さらに GraalVM は AOT コンパイラを使って Native Image を作ることも可能になっています。このように GraalVM は、JIT コンパイラと AOT コンパイラという 2 つの側面を持っています。

GraalVM と言うと注目度が高いのは AOT コンパイラを利用した Native Image だと思いますが、このセッションでは様々な観点（起動時間・パフォーマンス・メモリフットプリントなど）で AOT と JIT を比較して説明してくれました。簡単に要約すると、ピークスループットを重視する場合は JIT の利用が最適で、メモリあたりのスループットを気にする場合は AOT を利用しましょうということなのですが（当たり前の話ですね）、多くの観点で比較してくれるので改めて勉強になりました。

AOT では現状 JIT に比べてスループットが 20% 程度低下するそうですが、今後最適化を進めていくそうです。そのための手段として、① プロファイルガイドの導入 ② ネイティブイメージ用の低遅延 GC オプションの導入などが検討されているとのことでした。

Are We Really Cloud-Native?

Bert Ertman - Director of Technology @Luminis_eu

クラウドネイティブ時代に開発者がどうあるべきかという持論を話す opinionated なセッションで、大変面白かったです。マイクロサービスや k8s のような新しいテクノロジーが次々と生まれていますが、目の前のテクノロジーだけに着目するのではなく、IaaS → PaaS → Serverless → Cloud-Native という進化の流れを正しく理解しましょうという内容でした。

マイクロサービスやコンテナ化・DevOps などが発展してきたが、システム開発はどんどん複雑化し、インフラコストも高騰してきている。IT 投資の 8-9 割はシステム運用にかかるのに、それほど難しいシステム構成にすべきなのか ── という問いから始まり、システム開発は氷山のようにどんどん海面下が見えなくなってきていることを指摘。クラウド化の本質はビジネスに対するアジリティが増したことであると説明した上で、この時代にエンジニアはどうあるべきかを見失わないようにすべきだとしてセッションが締めくくられました。

The Not-So-Straightforward Road From Microservices to Serverless

Phil Calçado - Director, Platform Engineering @Meetup

SoundCloud や DigitalOcean をはじめ、様々な企業でマイクロサービス化を率いてきた Phil 氏によるサーバーレス挑戦談。登壇者はこれまでのマイクロサービス化の経験を振り返り「Keep your monolith for as long as possible」という結論に至ったようです。しかしマイクロサービスのような旨味を得たい ── そこで Phil は、モノリス + CQRS 的なアーキテクチャを採用し、コマンド側はこれまで通りモノリスにしつつ、クエリ側をマイクロサービス的なサーバーレスアーキテクチャにすることで上手くいくのではないかと考えたそうですが、これは様々な理由で難しかったとのこと。

最終的には現時点のベストプラクティスとして

マイクロサービスじゃないけどシステムは業務単位でいくつかに分ける
各システムは AWS アカウントを分けると良い（サービス境界になる）
各システム内のビルディングブロックとしてサーバーレスを利用するのはアリ

という感じのお話でした。

Datadog: A Real Time Metrics Database for One Quadrillion Points/Day

Ian Nowland - VP Engineering Metrics and Alerting @datadoghq
Joel Barciauskas - Director of Engineering, Distribution Metrics

Datadog のアーキテクチャについて解説するセッション。DD の技術的なチャレンジとして ① 大量のメトリクスを保存するためのストレージ ② スケーラブルな時系列データ処理を取り上げて、どのような工夫を行なっているのかが説明されました。

DD の平均的な顧客は、1 日あたり 10TB のデータを保存するそうです。この量になると、S3 に保存したとしても $210 / Month かかることになります。また、DD では各メトリクスを高速に検索出来る必要がありますが、当然ながら S3 に保存したままではリアルタイムに検索することは難しいため、様々な技術を使い分けて永続化しているそうです。また時系列データのストリーム処理については、Sketch を多用しているそう。DDSketch という分散型の Sketch を実装したという話がありましたが、詳細については触れられませんでした。

こちらのセッションの内容については、後日ご紹介できればと思います。

Conquering Microservices Complexity @Uber With Distributed Tracing

Yuri Shkuro - Creator of Jaeger & Software Engineer @Uber

システムはユーザーの数、開発者の数、計算機の数で爆発的に複雑度を増していきます。Uber のシステムは非常に巨大で複雑なため、エラー発生確率は指数的に増加し、トランザクションの Observability (可観測性）はなによりも重要になります。

Uberの複雑に絡み合うノード群、エラー発生ポイントとエラー原因（スライドより）

Observability と Monitoring は違う概念です。Monitoring はリソース使用状況などを監視・レポートする技術ですが、Observable なシステムは、問題が発生したとき、その問題が根本的にどこで発生し、何が原因だったのか特定が可能なシステムです。そして、工夫された可視化も必要です。

Yuri はこういった問題を解決する Distributed Tracing システムを Uber で開発した第一人者です。このセッションの詳細は後日、別記事で紹介予定です。

Brittany Postnikoff - Computer Security and Privacy / Human-Robot Interaction Researcher

「セキュリティ」カテゴリのセッションですが、QConのなかでは異色のトピックで、ロボットの Social Engineering （社会工学）に関する発表です。"Robot Social Engineering" は Brittany が提案した概念で、本来とは違った目的でロボットを誤用してしまうのは（故意であろうとなかろうと）どんなときか、ということを研究しています。

まずは権限の問題です。薬を自動で運んでくれるロボットがあるとして、その薬は医師が処方すべきです。では、毎日同じ薬を飲むためにジョブを設定したとして、ロボットがとってきた薬は医師の確認なしに飲んで良いのでしょうか？問題が起こったら誰の責任でしょうか？あるいは、オフィスのお掃除ロボットがドアを開けられなくて困っているとき、開けてあげるべきでしょうか？物理的なセキュリティを突破する敵の策略かもしれません。

感情が「誤用」を引き起こすこともあります。ロボットは人間っぽい仕事をしてくれるので、たとえ見た目が人間のようでなくても感情移入してしまいます。危険地帯で獅子奮迅の活躍をした愛着のあるロボットが、故障で動けなくなってしまったら、捨てるべきです。しかし実際には多くの人が身の危険を顧みずにロボットを救おうとしてしまいます。全くの本末転倒であり、目的に反しています。

アクセシビリティが問題を引き起こすこともあります。例えば、宅内ネットワークにつなげることができるロボットで、スイッチを押すと自分の Local IP Address を教えてくれたり、ロボット用ダッシュボードに脆弱なパスワードでログインすることができてしまったりすることはよくあるそうです。また、通信が平文で行われていたり、古すぎる暗号規格を使っていたり、ミドルウェアのアップデートが行われないこともあります。人と密接に関係した情報を持つロボットは、本来厳重なセキュリティで保護されるべきなのですが、そうなっていないことは今後、社会問題になりそうです。（すでにスマートスピーカーなどは論争の対象になっています。）

Modern WAF Bypass Scripting Techniques for Autonomous Attacks

Johnny Xmas - Blade Runner & Director of Field Engineering

こちらもセキュリティのセッションで、セキュリティのスペシャリストである Johny が WAF（ファイアウォール）を試験するとき、どのように攻撃しているかを紹介しました。

攻撃者がとる下記のような手段を駆使して、WAFを突破してきます。

Proxy を使って IP を複数順繰りに使用する。無料のサーバーを経由しても良いのだけど、そういうIPは有名でブロックされがちなので、"Residential Proxy" を使う。有料だが、普通のIPと見分けがつかないので攻撃には便利。
HTTP Header は本物らしく偽装する。Accept, DNT, X-Headers を忘れずにいれ、User-Agent を本物のブラウザから複数もってきて順繰りに使用する。
ドメイン、Path の情報を集めて分析し、あらゆるエンドポイントを総当たりに調べる。大概のアプリケーションは複数ログインする入り口があるので、一番弱い箇所を発見して攻撃する。
CDNは攻撃しにくいので、攻撃対象サーバーの Public IP を特定して攻撃する。
TimeZone、スクリーン解像度、スクリーンサイズなどを自分のPCから持ってきて、攻撃ツールを「人間らしく」する。

実際の Python スクリプト実演を交えた楽しい発表でしたが、普段攻撃される側のアプリケーションエンジニアにとっては、かなり胃が痛くなる話でした。

Peloton - Uber's Webscale Unified Scheduler on Mesos & Kubernetes

Mayank Bansal - Staff Engineer @Uber
Apoorva Jindal - Senior Software Engineer @Uber

Uber の Peloton というリソーススケジューラのアーキテクチャ紹介です。Uberは大きく分けると次の4種類のようなサービスがあり、

Stateless Job: 永続情報を持たない長時間実行されるサービス
Statefull Job: MySQL, Cassandra, Redis などの永続化用の長時間実行されるサービス
Batch Job: 数分〜数日で完了する、Hadoop、Spark、TensorFlow などのジョブ
Daemon Job: Apache Kafka、HAProxy、M3 Collector など各ホストで動くエージェント

それぞれ特性やリソースが違うため、十分インフラリソースを活用できていませんでした。そこで Peloton を開発し、それらの抽象化を行っています。Apatch Mesos, Docker, Kubernetes を活用しています。

社内で十分なドッグフーディングが行われ、現在は OSS として公開されています。

Sink or Swim - Effective Collaboration between Eng & Product

Jean Barmash - VP Engineering @Komodo Health
Khadija Ali - Director of Product Management @Better Mortage

ソフトウェアエンジニアと、技術畑出身ではない Product Manager の衝突がなぜ起きるのか、どう解消するのかがテーマでした。実際に VPoE と PM が、それぞれに抱えがちな不満を紹介しつつそれぞれの考えを言っていく対談のようなセッションでした。

① コンテキストを共有する

まずは問題解決の前に、問題をクリアにするため、お互いの景色を十分に共有し合う。リリースを急ぎたい理由や、設計を練りたい理由が単純に共有されていないことも多い。

② 信頼関係を構築する

信頼があれば、話をきいてもらえるし、細かいことは任せることができる。

③ 相手の立場を想像して、耳を傾ける

コンテキストを理解した上で、自分がどう相手を助けられるかを考える。

④ 責任境界の明確化

エンジニアは How に、PMは What/Why に責任を持つ。その代わりに最終決定権を持つ。

⑤ 歩み寄ること

どうしてもグレーゾーンは発生するので、そういう箇所は歩み寄って解決する。

以上の5つが大事であると主張しました。

PMの感じる不満例：

1週間もアーキテクチャを考えてるのはなぜ？仕事をさぼっているのでは？
エンジニアが100%完璧なスペックを求めてくる。コンピューターじゃないんだから無理だ。
エンジニアが PM の仕事を取ってしまう、仕様に口出ししないでほしい。
エンジニアが NO しか言わないで、他のオプションを提案してくれない。

エンジニアの感じる不満例：

巨大な機能をつくろうと言ってくるのはなぜ？もっと小さいところから始めたい。
PM が意思決定しないで中間者になっている。
PM が意思決定の場に参加させてくれない。
PM が技術的負債解消に時間を使わない。

現場で活躍する2人が出した例は、本当に「あるある」だと思います。チーム内で実際にこういったシミュレーションを行うのも、コミュニケーションを改善する1つの手ではないでしょうか。

今回は、QCon NY 2019 2日目のセッションについてご紹介しました。特に興味深いセッションは詳細化してお届けしますので、よろしければこちらのブログをフォローして更新をお待ち頂けると幸いです。お楽しみに！