こんにちは、『スタディサプリ』でデータエンジニアをしている橘高 ( @masanobbb )と丹田 ( @JinTanda ) です。

今回は、昨年の10/24〜10/26 に 開催された QCon SF (San Francisco) 2022に参加してきましたので、その様子やセッションについての内容をレポートしていきたいと思います。

その前に、少し自己紹介になりますが、我々は新卒3, 4年目でデータエンジニアを主軸としながら、最近ではデータサイエンスや機械学習エンジニアのようなロールにもチャレンジし仕事をしています。そのため、MLOps やアーキテクチャ、データエンジニアとしてのキャリアパスなどに興味があり、それらに関するセッションを中心に参加しました。

QCon とは?

QCon は、 InfoQ が開催するカンファレンスです。

今回の QCon SF は2019年以来、3年ぶりに開かれたカンファレンスだったようです。

話される内容は MLOps 、マイクロサービスなどのアーキテクチャ、エンジニアのキャリアやマネジメントについてなどの幅広いトピックがカバーされ、特にイノベーター理論における Innovators から Early Majority までにフォーカスしています。

今回の QCon SF では15のトピックに関するトラックがあり、我々は MLOps , Operating Microservices: Patterns for Success, Staff+ Engineer Path などのトラックのトークセッションに参加しました。

セッションの紹介

それでは、ここからは MLOps, Operating Microservices: Patterns for Success, Staff+ Engineer Path の3つのトラックから特に印象に残った4つのトークセッションと、トークセッション以外に参加した3つのセッションの合計7つのセッションを紹介していきます。

1. Real-Time Machine Learning: Architecture and Challenges (丹田)

セッション内容

まずは MLOps トラックから、Designing Machine Learning Systems という本をオライリーで執筆し、現在スタンフォード大学で Machine Learning System Design の授業も教えている、 Claypot AI co-founder の Chip Huyen 氏によるリアルタイムの機械学習システムについてのトークセッションです。

MLOps トラックの中でも人が多くとても人気のトークでした。

トークでは、以下のようにリアルタイム機械学習システムにおいてのバッチ特徴量生成、リアルタイム特徴量生成、準リアルタイム特徴量生成という3つのアーキテクチャのパターンが、latency vs feature staleness の関係で整理され、紹介されました。

ここで、latency はリクエストを受けて予測を返すまでの時間、feature staleness は特徴量生成と特徴量が使用されるまでの間の時間です。

• バッチ特徴量生成: Low latency & High staleness
  • バッチで特徴量生成し、それを KVS (Key-Value Store) などに保存して、予測を行うサービスでは KVS から特徴量を取得するパターン
  • リクエスト時には既に計算された値を KVS から取得するだけなので、low latency に対応できる一方で、特徴量の生成は定期バッチのため、high staleness となります
• リアルタイム特徴量生成: High latency & Low staleness
  • リクエストを受け取ったときに、特徴量生成サービスで特徴量もリアルタイムで生成し、予測を行うサービスでその特徴量を直接使用するパターン
  • リクエストを受けてから DB から最新のデータを取得し特徴量を計算するので、high latency となる一方で、リクエスト時に特緒量生成を行うので、low staleness となります
• 準リアルタイム特徴量生成: Low latency & Low staleness
  • 特徴量生成サービスで、イベント駆動のストリーミング処理で特徴量を生成し、それを KVS に保存して使用するパターン
  • イベント駆動のストリーミング処理で生成された特徴量を用いることで、low latency かつ low staleness を実現します
  • ストリーミング処理とバッチ処理でそれぞれ KVS を持っており、推論時はそれら2つを統合した Feature Service から特徴量を呼び出して処理します
  • 特徴量が生成され KVS に保存されるまでには遅延があり、予測サービスから常に最新データに基づいた特徴量を参照できるわけではない点がデメリットです

それぞれのアーキテクチャパターンはよく見るものですが、latency vs feature staleness の関係で考えることにより、よりクリアにそれぞれの機械学習システムのアーキテクチャの特徴を理解できました。 準リアルタイム特徴量生成におけるストリーミング処理で用いる具体的な技術には、Kafka, Kinesis, Flink, Spark Streaming が挙げられていました。

また、データサイエンティスト (DS) とデータエンジニア (DE) / 機械学習エンジニア (MLE) の協業方法として、バッチ向けに書いたコードをストリーミング用コードに書き直すことを少なくするため、最初から特徴量生成をストリーミング処理としてデータサイエンティストが書いて、それをバッチ的に使用するという方法が紹介されました。

所感

リアルタイム性を考慮した機械学習のアーキテクチャを構築する際に考える必要がある latency と staleness を、トレードオフの関係で説明している点は非常に理解しやすい内容でした。ストリーミング処理を使ってこのトレードオフを解決するというアイデアは、シンプルですが、理にかなった仕組みだと感じています。ストリーミング処理においては Flink SQL や KSQL を用いて SQL でストリーミング処理を書けるようにすることで、ストリーミング処理のハードルを下げ、より扱いやすいものにすることができます。

セッションの中でも話題に上がりましたが、今後このように SQL でストリーミング・バッチを統合的に扱う方法がより注目され使われていく可能性を感じましたし、SQL の中で扱えるとなると改修コストもある程度抑えられるのはメリットだと感じています。

また、今回の QCon SF 2022 のワークショップにも、 Kafka についてのセッション があり、そこでも ksqlDB のハンズオンがあったようです。ワークショップが SOLD OUT していることからも、注目度が高くなっていることを感じました。

セッション内容の中でも紹介したように、モデル開発時の DS と MLE の協業方法は話題に上がっていましたが、個人的には DS や DE, MLE の職務の責任分界点は、サービスの成熟度合いや組織の体制によって様々であり、近年の ML 開発の大きな課題の一つだと考えています。Flink SQL や KSQL のようなツールが進化していくことで、今後職務要件がより明確になっていくのではないかと思っています。

最後に、リアルタイム機械学習におけるストリーミング処理を用いたアーキテクチャは、今後設計を行っていく上での重要な選択肢の一つとして活用していくことになりそうです。

2. Declarative Machine Learning: A Flexible, Modular and Scalable Approach for Building Production ML Models (丹田)

セッション内容

続いても MLOps のトラックから、Shreya Rajpal 氏による Declarative Machine Learning についてのセッションを紹介します。

QCon では全てのセッションにおいて聴講者による3段階の投票が実施され、本セッションはその中で2位を獲得しており、評価の高いセッションでした。

昨今の事業で用いられる ML 開発は、大きく2つのスタイルに分類されます。

• Low-level APIs
• AutoML

Low-level APIs は TensorFlow や PyTorch, scikit-learn などのフレームワークを指し、AutoML は Google Cloud AutoML や DataRobot などを指します。

Low-level APIs は柔軟にコードを記述することが可能なので、様々な課題を解決することができます。一方で、データの前処理、モデル作成、検証、評価、デプロイと断片的に様々な開発を行う必要があり、スピーディーに開発することができず、開発コストも非常に高いというデメリットがあります。

AutoML はほとんどコードを書く必要がなく、シンプルに実装することができます。一方で、中身がブラックボックスであったり、モデルの精度を改善するためにユーザーができることが少なかったり、解決したい課題が複雑になると柔軟に対応できなくなってしまうというデメリットがあります。

Declarative ML システムは、これら2つのスタイルのそれぞれの問題を解決できる統合的な仕組みであると述べています。

ソフトウェアシステムでは、様々な領域で high level と low level な仕組みを interface で繋ぐ構成が主流であり、例えばコンパイラにおいて、プログラマはコンパイラの中身を熟知せずとも、プログラミング言語という interface を使って開発することができる high level に属され、コンパイラ開発者は low level に属されます。

次世代の ML においても、スキーマやタスクを定義するが、ML のコードを書く必要がない high level に属する ML Practitioner と、モデルやアーキテクチャの最適化を行うような low level に属する DS / ML Researcher とを interface で繋ぐような関係になっていくと提唱しています。

Declarative ML はこの interface として活用することができ、例えば以下のようなプロダクトがあり、注目されていることがわかります。

• Overton: Apple によって開発され、社内のみで利用可能
• Looper: Meta によって開発され、同じく社内のみで利用可能
• Ludwig: Uber AI によって開発され、OSS として利用可能

Declarative ML は low-levels API の持つ柔軟にコードを記述し、様々な課題を解決できるという良さと、AutoML の シンプルに実装できるという良さを合わせ持った新しい interface です。同時に、low-levels APIの持つ断片的に様々な開発を行う必要があるというデメリットと、Auto ML の中身がブラックボックスになってしまったり、モデルに工夫を加えての精度改善が難しい、というデメリットを解消してくれます。

今回は OSS として利用できる Ludwig を使ったモデル開発を紹介していました。

Ludwig では基本的に yaml 形式の config ファイルを一つ用意し、以下のようなコマンド1つでモデル学習を行うことができます。

$ ludwig train --dataset agnews.csv --config config.yaml

config.yaml

input_features:
  - name: title
    type: text
    preprocessing:
      tokenizer: space_punct
  - name: description
    type: text
    preprocessing:
      tokenizer: space_punct

output_features:
  - name: class
    type: category
    preprocessing:
      missing_value_strategy: drop_now

また、モデルの学習結果の可視化も同様に、

$ ludwig visualize --visualization learning_curves --training_statistics results/experiment_run/training_statistics.json

のような形でいくつかの評価結果を描画することができ、low-level APIs のような複雑なコーディングを必要としません。 例えば描画に learning_curves を指定した場合、以下のようなグラフを簡単に取得することができます。

モデルのサービングも同様に、コマンド1つで立ち上げることができます。

学習時には、yaml の設定を柔軟に更新していくことで、ある程度複雑なモデルを組むこともできます。例えばテキスト分類タスクの場合、導入初期段階ではシンプルなモデルを作り、その後 encoder に BERT を用いたり、regularization や dropout を指定したり、さらにハイパーパラメータ探索を導入したりと段階を経てモデルをより強固なものにしていくことが可能です。下記の config.yaml の例では、上で紹介したものに encoder として BERT を追加し、さらに trainer に regularization の指定を追加しています。

BERT での encoder と regularization を追加した config.yaml の例

input_features:
  - name: title
    type: text
    preprocessing:
      tokenizer: space_punct
    encoder:  # encoderとしてBERTを追加
      type: bert
      num_hidden_layers: 16
  - name: description
    type: text
    preprocessing:
      tokenizer: space_punct

output_features:
  - name: class
    type: category
    preprocessing:
      missing_value_strategy: drop_now

trainer:
  epochs: 50
  regularization: l2  # regularization の指定を追加

CLI によるコマンド実行だけでなく、Python SDK もサポートしているとのことでした。

所感

これまでに、我々も基本的には Low-level APIs を用いた ML 開発を行いつつも、プロジェクトの規模によっては AutoML のサービスを使うことを検討する機会はありましたが、やはり柔軟性に欠けるために導入に至らなかったケースがありました。今回の Declarative ML は新しい ML 開発の位置付けとして、今後弊社にもプロジェクトによっては導入する価値が十分にあるような期待が持てるソリューションだと感じています。

また、MLOps の別のセッションの “Fabricator: End-to-End Declarative Feature Engineering Platform” というトークでも “Declarative” というキーワードが登場していました。これまでは ML に関する深い専門性を持った豊富な人材がいる組織では Low-level APIs を用いた開発ができていた一方で、専門的な知識を持った人材がいない組織では Auto ML という選択肢があるものの、やはり柔軟性に欠けるという点がネックになってしまっているケースは少なくないと思います。 “Declarative” という概念は、そういった組織でも ML が使われるようになっていく未来を見据えているように感じました。今後も動向を追っていきたいと思っています。

3. Dark Energy, Dark Matter and the Microservices Patterns?! (橘高)

セッション内容

次は、Operating Microservices: Patterns for Success トラックからの紹介で、マイクロサービスとモノリスアーキテクチャのどちらにするべきか、という2つの選択肢の間で競合する力をダークマターとダークエナジーの比喩を使用してよりよく理解するという内容でした。

スピーカーは Microservice.io の作者であり、 Microservices Patterns の著者の Chris Richardson 氏です。

このトークもとても人気で、かなり大きな会場で行われたのですが、今回の QCon SF で最も聴衆が多かったセッションで、会場に入れず他のトークを見た人もいたようです。

ダークエネルギーは宇宙の膨張を加速するエネルギーであり、サブドメインを異なるサービスに分けようと反発する力（マイクロサービス化に働く力）に作用するものの比喩として、ダークマターは星や銀河に重力の影響を与える目に見えない物質であり、サブドメインが同じサービスにまとまる方向に働く引力（モノリスアーキテクチャ方向に働く力）の比喩として、それぞれ紹介されました。

マイクロサービス化に働く力（ダークエネルギー）としては、

• Simpler components/services
  • よりシンプルにサブドメインごとにコンポーネント・サービスを分割する
• Team autonomy = service per team
  • チームの自律性を高めるためサブドメインごとにチームもサービスも分割する
• Fast deployment pipeline
  • サービスごとのデプロイでリードタイムが短くなる
• Support multiple technology stacks
  • 複数言語などの異なる技術スタックのサポートが容易になる
• Separate subdomains by characteristics
  • サブドメインごとに異なるセキュリティ要件やリソース要件によってサービスを分割する

モノリス方向に働く力（ダークマター）として、

• Simple interactions
  • 分散システムではないローカルでのシンプルなインタラクション
• Efficient interactions
  • インメモリでの効率的なインタラクション
• Prefer ACID over BASE
  • BASE特性よりもACID特性を優先（サービスの境界を超えた ACID トランザクションは難しい）
• Minimize runtime coupling
  • あるサービスが他サービスに依存するといったランタイム時の結合を最小化
• Minimize design time coupling
  • あるサービスの変更により他サービスの変更が必要となる設計時の結合を最小化

が挙げられました。

また大事な点として、マイクロサービスまたはモノリスなアーキテクチャにすることで自動的に上の各項目がメリットとして享受できるわけではなく、これらのメリットを享受しつつ、反対のデメリットをどう最小化するかを考えながらアーキテクチャを設計する必要があることが語られました。

所感

ここ数ヶ月の仕事でアーキテクチャの設計や議論をしたのですが、その時に考えたことも抽象化された形で上の項目に出てきて、目から鱗な発表でした。 例えば、サブドメインの特性によってサービスを分割するといったことは、機械学習システムであれば、リソース要件として GPU が必要なサブドメインはサービス分割することでスケールした時のコストを小さくすることができるという内容も例として登場していました。

ランタイムや設計時の結合は、サービスを運用する中で具体的に経験したことはあったのですが、初めて今回の発表で言語化された概念を知りました。 疎結合はマイクロサービス化の利点としてよく語られると思っていたので、逆にモノリス方向に働く力として “minimize coupling” という言葉が出た点が驚きでした！

これまでのマイクロサービスへの期待の反動によるモノリスなシステムの再評価など、マイクロサービスにするか、モノリスなアーキテクチャにするか現在も議論は絶えないですが、本トークのように両者の間に働く力学を整理することでさらに進んだ議論ができると思います。

4. The Engineer/Manager Pendulum (橘高)

セッション内容

Staff+ Engineer Path トラックから honeycomb.io の co-founder で CTO の Charity Majors 氏によるトークです。

マネージャーになるべきか？エンジニアであるべきか？という問いについて、振り子のようにマネージャーとエンジニアを行き来するキャリアパスを提案するという内容でした。

そして、シニアエンジニアやエンジニアマネージャーといった括りではなく、テクノロジストまたはテクニカルリーダーとして自分のことを考えるべきだということが言われました。

トークの中であったメッセージやアドバイスを紹介すると、以下のようなものがあります。

• マネジメントはプロモーションではなく、キャリアチェンジ。
• マネジメントがプロモーションではないなら、エンジニアリングも降格ではない。
• マネージャーか、エンジニアか、どちらかの道を選ばなければならないというわけではないが、その時々ではどちらか一つを選ばなければならない。
• マネージャーでコードを書く場合は、クリティカルパスではない部分でコードを書くのが良い。
• マネージャーにはなるのは少なくとも7、8年の経験を持ち、経験豊富なシニアエンジニアになってからが良い。

所感

歯に衣着せぬ物言いとはこういうことを言うのかと思ったトークで、質疑での回答もストレートにシンプルに本当に思っていることを伝えていることがわかるような話し方で、質疑の終わりにも大きな拍手が起こるようなトークでした。

マネージャーになるべきか?エンジニアであるべきか?という問いに対してマネージャー/エンジニアのどちらかの答えを出すものだと考えていましたが、そうではないという考え方は新鮮でした。 実は今回のトークの内容のベースは 2017年の Charity氏のブログポスト であり、その時点では少し急進的な考えでしたが、それから5年経った今ようやく受け入れられるようになり、このトークができたようです。

このトピックについての Charity 氏の他にもブログを書いているので、興味のある方のためにリンクを貼っておきますので、どうぞ！

• Twin Anxieties of the Engineer/Manager Pendulum
• Engineering Management: The Pendulum Or The Ladder
• If Management Isn’t A Promotion, Then Engineering Isn’t A Demotion

5. Unconference Session (橘高)

Unconference Session は、 Open Space Technology と Lean Coffee を組み合わせたディスカッションを行う参加型のセッションです。

流れとしては、

1. 参加者が各々自分が話し合いたい課題やテーマをトピックとして共有する (ファシリテータがホワイトボードにメモする)
2. 参加者は共有されたトピックの中から参加したいものを選ぶ
3. トピックごとに参加者が集まりディスカッションを行う
4. 10分経つとファシリテータが今のトピックでディスカッションを継続したいかどうかを参加者に尋ねるので、継続したい人が多い場合は継続し、そうでない場合は再度次のトピック選びに移る

という流れでした。

私は MLOps トラックの Unconference Session に参加しました。 参加するまでは英語でディスカッションすることに緊張しドキドキでしたが、自分の興味のあるトピックのグループに参加してディスカッションするため、少人数（4人〜7人くらいでした）のグループで話せたこともあり、思ったよりも緊張せずに話すことができました。 ※ MLOps の Unconference の参加人数自体が、合計で20人いかないくらいの人数だったこともあるかもしれません。

挙がったトピックには、

• MLOps のツール・ SaaS 選定方法
• データサイエンティストとデータエンジニア・機械学習エンジニアの協業方法
• 機械学習システムのデータバリデーション

などがありました。

ディスカッションでは、それぞれ異なる会社からエンジニアが集まっており背景が異なるため、同じ言葉でも違う意味で使用していることがあり、それぞれの課題と背景を共有・理解する点に時間がかかってしまいました。 例えば、データサイエンティストと言っても、ある会社ではサービスに組み込むところまでを責務にしていて、他の会社ではモデルを作成する部分までが責務であったり、様々です。

50分というセッションの時間は思ったより短くあっという間に過ぎてしまい、各トピックで結論のようなものは出なかったのですが、さまざまなエンジニアと課題を共有し議論することができ、改めて銀の弾丸はなくプロダクトそれぞれの背景・課題に向き合うことが大切だということを再認識することができました。

また、こういったカンファレンスでいきなり知らない人に話しかけるのはハードルが高いですが、Unconference のようなセッションに参加することで、参加者と話し、知り合いを増やす機会を作ることができます。 そのため、Unconference Session 以外の場面でもここで知り合った方々と話すことができ、有意義な時間を過ごすことができました。

6. Well-being Session (橘高)

今回の QCon SF から新しくできたセッションで、ランチ休憩の間に Chair Yoga, Stress Less, Guided Meditation のセッションがそれぞれ1〜3日目にありました。

私は1日目の Chair Yoga セッションに参加しました。 Chair Yoga では、ヨガのインストラクターの指導のもと、椅子に座ったままできるストレッチや椅子を利用して行うヨガを20分程度行いました。 セッションが始まった時は6人ほどしか参加者がいなかったのですが、少しずつ人が増えて最後の方では20人程度の人が参加していたと思います。 少し急いでランチをとる必要がありましたが、カンファレンス参加中に少し気分転換するのにはとてもいいセッションでした。

心身ともに健やかな状態を維持することは、エンジニアとして中長期的に成果を出し続けることには不可欠であり、世界的なパンデミックもあったことからセルフケアの重要性が再認識されていることを感じました。

7. Women & Allies in Tech Breakfast (橘高)

Women & Allies in Tech Breakfast は、QCon での女性とアライ（女性の活躍を支持する人）のつながりをサポートするためのソーシャルなイベントです。 2日目の朝早くに開催され、参加するには QCon SF のWebページからの事前登録が必要でした。 男女の参加割合は半々で合計で3, 40人ほどは参加していたと思います。

今回の QCon SF で Optimizing Teams for Fast Flow トラックのホストをされていた Courtney Kissler 氏の LT（ライトニングトーク）でセッションは始まりました。 LTの内容は、キャリアで重要な意思決定をする際に大切にしている基準についてで、性別関係なく共感できる素晴らしい内容でした。 朝食も提供され、LT 後は朝食を食べながら、自由に一緒のテーブルにいる人と会話するという流れでした。 セッション後は時間があったので、テーブルが一緒だった数人でコーヒーを飲みつつ、外を散歩しながら次のセッションに向かいました。

Women & Allies in Tech Breakfast はソーシャルなイベントで、Unconference と同様に少人数でゆっくりと話せたり、新しい繋がりも作ることができました。

リクルートでも ダイバーシティへの取り組み を行っていますが、QCon のようなカンファレンスでこういった取り組みがなされていることは素晴らしいことだと思いました。

最後に

今回 QCon SF 2022 に現地参加したことで、全く知らなかった会社から弊社で使っている SaaS を提供する企業、誰もが知る大きなテック企業など様々な会社のエンジニアと交流することができました。セッション毎の休憩時間が25分も設けられており、その間広めのロビーに完備されているコーヒーやお菓子を片手に交流しやすい雰囲気を作り出す工夫がされているように感じ、現地ならではの経験ができました。また、実際に現地で参加したことで、聴衆の多さや反応からトークの人気度合いや注目度、共感しているポイントなども感じることができました。

今回は世界の様々な企業のナレッジを吸収し、持ち帰り展開することを目的としていましたが、想像以上に各企業の具体的な課題とソリューションの学びを得る素晴らしい機会になりました。

QCon はトピックが広範囲なので普段は自分からは見ないようなトピックのセッションも見ることができましたし、そこで受ける刺激も大きかったです。特に Staff+ Engineer Path トラックのトークは予想以上に楽しめましたし、今後のキャリアを作っていく上で糧になる経験になったと思います。

データエンジニア

Masanobu Kittaka

主に『スタディサプリ』のデータ基盤・データプロダクトの開発をしています。最近はサウナにハマってます。

データエンジニア, MLエンジニア, データサイエンティスト

Jin Tanda

『スタディサプリ』のデータ基盤やデータプロダクト開発、タウンワークのレコメンドモデル開発をしています。