Name: エアリフト クリス・デカロリス インタビュー（全文） (Airlift Interview with Chris Decarolis (Full Interview))
Uploaded: 2025-04-17T23:09:50.000Z
Duration: 21 min 56 s
Description: VoiceTubeの動画で発音を聞きながら英語表現を覚えよう！学べる英語：

I'm here in San Francisco to talk to Chris about Airlift, a project that he's been working on.

私はクリスが取り組んでいるプロジェクト『Airlift』について話を聞くためにサンフランシスコに来ている。

He has a long history at Dijkstra and he's worked on a lot of cool things.

彼はダイクストラで長い歴史を持ち、多くのクールなことに取り組んできた。

再帰代名詞

Would you mind giving yourself an introduction?

自己紹介をしていただけますか？

あなたが取り組んできたことについて話してください。

So yeah, my name's Chris as Colton knows, but you probably don't know.

そうそう、僕の名前はクリスだ。コルトンは知っているけど、たぶん君は知らないだろうね。

私はダイクストラ・ラボのエンジニアです。

Before that I was doing some machine learning related research stuff and then working on big data systems at Airbnb a little bit.

その前は機械学習関連の研究をしていて、Airbnbでビッグデータシステムに少し携わっていました。

And I, yeah, I joined because the team was really strong and I thought the problem was really interesting.

そして、チームが本当に強かったし、この問題が本当に面白いと思ったから参加したんだ。

But in that time I've worked across the stack.

しかし、その間に私はスタック全体で仕事をしてきた。

I worked on open source tooling for a while.

私はしばらくオープンソースのツーリングに携わっていた。

And then once our cloud product launched, I worked on our billing platform and our alerting system, built out a few other features like zero downtime deploys, ran our 1.0 release.

クラウド製品がローンチしてからは、課金プラットフォームとアラートシステムに取り組み、ゼロ・ダウンタイムのデプロイなど他のいくつかの機能を構築し、1.0リリースを実行した。

More recently I've been focused on this problem of airflow migrations.

最近、私はこの気流の移行の問題に注目している。

だから、エアリフトについてもっと話したい。

I know with Dijkstra you can observe different systems in an organization and Airlift offers a solution to both observe airflow environments and then also migrate for them.

ダイクストラを使えば、組織内のさまざまなシステムを観察することができます。エアリフトは、エアフロー環境を観察し、移行するためのソリューションを提供しています。

So can you talk a little bit about why we focused on Airlift and the inception of that project?

では、なぜ私たちがエアリフトに注目したのか、そのプロジェクトの立ち上げについて少し話していただけますか？

So I think, so I think there's a few different parts of that question, right?

だから、この質問にはいくつかの異なる部分があると思うんだ。

So to start out, like why are we thinking about airflow specifically, right?

ではまず、なぜエアフローについて特別に考えるのか？

Like why is that an important and interesting thing to integrate to for our business?

私たちのビジネスにとって、なぜそれが重要で興味深いことなのか？

So I think most people who are involved in the data engineering space know that airflow is the incumbent orchestrator in a lot of ways, right?

データエンジニアリングの分野に携わっているほとんどの人は、エアフローが多くの点でオーケストレーターの現職であることを知っていると思います。

It was one of the first on the scene in many ways, kind of arrived at a time that coincided with a lot of teams scaling out their data infrastructure.

多くのチームがデータ・インフラをスケールアウトしたのと同じ時期に登場した。

And so I think for a lot of teams it became the default choice for better or for worse.

それで、多くのチームにとって、良くも悪くもデフォルトの選択となったのだと思う。

ダイクストラはもう少し後だったよね？

And so I think by the time Dijkstra had a fully fledged cloud product and a lot of teams became aware of Dijkstra, those same teams might've already had an airflow deployment in place.

ダイクストラが本格的なクラウド製品を開発し、多くのチームがダイクストラを知るようになる頃には、同じチームがすでにエアフローを導入していたかもしれません。

Especially because of the power that an orchestrator holds inside the organization, right?

特に、オーケストレーターは組織内部で力を発揮しますからね。

It's basically controlling all of your compute a lot of times.

基本的に、多くの場合、すべての計算をコントロールすることになる。

It leads to a place where orchestration tools are very sticky and hard to remove.

それは、オーケストレーション・ツールが非常に粘着性が高く、取り除くのが難しい場所につながる。

And so basically we run into a situation where there's a lot of teams who really want to switch to Dijkstra, right?

だから基本的には、ダイクストラに乗り換えたいチームがたくさんいるという状況になるんだ。

But they feel pretty overwhelmed by this prospect of ripping out this orchestrate of the prospect of ripping out an orchestration system.

しかし、彼らはこのオーケストレーション・システムを取り払うという見通しにかなり圧倒されているように感じる。

That also makes it hard to migrate off of airflow.

そのため、エアフローからの移行も難しくなる。

So things like poor local development story, hard to test, like Python dependency management, hell, stuff like that.

そのため、ローカルでの開発ストーリーが乏しかったり、テストが難しかったり、Pythonの依存関係管理のような、地獄のようなものだ。

These are all simultaneous reasons that people want to switch to Dijkstra and all things that also make airflow sticky.

これらはすべて、人々がダイクストラに乗り換えたがる理由であり、エアフローをべたつかせるものでもある。

And so we're trying to basically figure out a way to thread that needle of like making those types of migrations easy while also allowing you to get the benefits of Dijkstra earlier in the process.

私たちは基本的に、このようなタイプの移行を簡単にする一方で、プロセスの早い段階でダイクストラの利点を得られるようにする方法を見つけ出そうとしています。

そのため、価値を見出すまでの時間が短縮される。

A really compelling story with Airlift for me is not necessarily migrating everything off of Airflow, but being able to observe multiple Airflow instances and then bring all Greenfield projects in Dijkstra.

私にとってのAirliftの本当に魅力的なストーリーは、必ずしもAirflowからすべてを移行することではなく、複数のAirflowインスタンスを観察し、すべてのグリーンフィールド・プロジェクトをDijkstraに取り込むことができることです。

Can you tell a little bit about how you might do that with just observing Airflow from Dijkstra and then bringing new jobs in Dijkstra?

ダイクストラからエアフローを観察して、ダイクストラに新しい仕事を持ち込む方法について少し教えていただけますか？

So what Airlift really is, is an Airflow integration in a lot of ways, right?

つまり、エアリフトは多くの点でエアフローを統合したものなんだ。

Airflow has a REST API and we're basically using a lot of, we have some advanced state management tooling that allows us to read a bunch of information about the Airflow deployment using the REST API and then ingest it in Dijkstra.

AirflowにはREST APIがあり、私たちは基本的に、REST APIを使用してAirflowのデプロイメントに関する多くの情報を読み取り、それをDijkstraに取り込むことができる高度な状態管理ツールをたくさん使用しています。

And more recently in the system, we have this like very clear separation of reporting and orchestration.

さらに最近では、レポーティングとオーケストレーションを明確に分けている。

And that allows us to ingest an external orchestration system and represent it in a clean way that's distinct from representing things that we're orchestrating, right?

これによって、外部のオーケストレーション・システムを取り込み、自分たちがオーケストレーションしているものとは異なる、クリーンな方法でそれを表現することができるんだ。

And so basically what that allows you to do, right, is write a few lines, like the upshot of that is you can write a few lines of code, right?

それで、基本的に何ができるかというと、数行のコードを書くことができるんだ。

And ingest your entire Airflow instance, right?

そして、Airflowインスタンス全体をインジェストするのですね？

And have the whole thing show up in Dijkstra.

そして、ダイクストラにすべてを表示させる。

And because you're just writing net new Dijkstra code, right, you can do that for any number of Airflow instances.

そして、新しいダイクストラ・コードを書くだけなので、Airflowインスタンスの数だけ書くことができる。

So you can, something we've seen in the past is that a lot of teams might have a few Airflow instances, right?

過去に見たことですが、多くのチームはAirflowのインスタンスをいくつか持っているのではないでしょうか？

They have their one Airflow instance that's doing their important stuff.

Airflowのインスタンスは1つだけで、重要な作業を行っている。

They have some other one running in MOA or something that's like doing legacy stuff.

彼らはMOAか何かでレガシーなことをやっているようだ。

They have some upstream team whose data sources they depend on, right?

彼らには、データソースに依存している上流のチームがあるんだろう？

And they'll bring all of those different Airflow instances into Dijkstra using something like Airlift.

そして、Airliftのようなものを使って、異なるAirflowインスタンスをすべてDijkstraに取り込む。

Yeah, and another thing that's really cool is you can then trigger jobs in Airflow from Dijkstra.

そしてもうひとつ、とてもクールなのは、ダイクストラからAirflowのジョブをトリガーできることです。

So if you have, say, a machine learning team who just wants to stay with Airflow, but you have a lot of upstream dependencies in Dijkstra, you can then just trigger their DAGs or tasks from Dijkstra directly.

例えば、機械学習チームがAirflowを使い続けたいが、Dijkstraに多くの上流依存関係がある場合、Dijkstraから直接彼らのDAGやタスクをトリガーすることができる。

So the way it works, right, is, or the way to think about it is typically speaking, especially in larger teams, the data ecosystem, the asset graph that exists, right, when we think about asset graph, what does that mean?

つまり、一般的に言えば、特に大規模なチームでは、データのエコシステム、アセットグラフが存在するわけですが、アセットグラフについて考えるとき、それは何を意味するのでしょうか？

It's like the physical set of things that are being produced by that organization, right?

それは、その組織が生産している物理的なものの集合のようなものだろう？

Like Snowflake Tables, Excel spreadsheets, anything, right, is widely distributed across a large array of orchestration systems.

スノーフレーク・テーブルのように、エクセルのスプレッドシートのように、何でもそうだが、多くのオーケストレーション・システムに広く分散されている。

And out of all those orchestration systems, Dijkstra is kind of the one that has this notion of both orchestration and reporting.

これらのオーケストレーション・システムの中で、ダイクストラはオーケストレーションとレポーティングの両方の概念を持っている。

And so it's a natural place for you to consolidate.

そのため、あなたがこの場所を統合するのは自然なことだ。

And so basically the whole idea is you can, if you can represent the whole asset graph within Dijkstra, right, then you can also orchestrate between those orchestration systems, assuming you have a way to trigger computations, right?

基本的には、ダイクストラの中でアセットグラフ全体を表現することができれば、計算をトリガーする方法があれば、オーケストレーションシステム間でオーケストレーションすることもできる、ということですね。

And so we have this notion of declarative automation, right, which allows you to flow computations through the entire graph, right, starting at some source point.

宣言的自動化という概念があり、グラフ全体を通して計算を流すことができる。

And so the way things become really powerful is instead of, whereas before you might have all these fragmented crons working across like different orchestration teams, right, instead now you just, if you can represent the entire asset graph, right, you can just cron the top of it, right, and then flow orchestration through the whole thing without, only when you need it.  And so that's, I think, the power of something like being able to trigger computations from Dijkstra even though they're running in some external system.

以前は、オーケストレーション・チームがバラバラで、それぞれのクーロンがバラバラに動いていたかもしれませんが、今は、アセット・グラフ全体を表すことができれば、その上をクーロンするだけで、必要なときだけオーケストレーションを流すことができます。  外部システムで実行されている計算をダイクストラからトリガーすることができるのです。

I think we'll go into an example in a little bit, but before that, I know Airlift has three stages to it, the peer, observe, and migrate.

その前に、エアリフトにはピア、オブザーバー、マイグレーションの3つの段階があることは知っている。

Can you talk a little bit about why we went with three stages and the design decisions around that?

なぜ3つのステージにしたのか、そのあたりのデザインの決定について少し話していただけますか？

Yeah, so I think it all basically boils down to this idea that, you know, so the founder, Nick, me and him were working pretty closely on this in terms of figuring out the right way to sequence a migration.

そう、基本的にはこの考えに集約されると思うんだ。つまり、創設者であるニックと僕と彼は、移行を順序立てて行う正しい方法を見つけ出すという点で、かなり緊密に取り組んでいたんだ。

I think the largest piece of feedback we were getting from clients who were trying to migrate off of Airflow is we want something opinionated.

Airflowから移行しようとしていた顧客から得たフィードバックの中で最も多かったのは、何か意見のあるものが欲しいというものだった。

We want something that's heavily opinionated that tells us how we are going to do this.

私たちが求めているのは、どうすればいいかを教えてくれるような、重厚な意見のものだ。

Nick gave this talk at Facebook called Evolutionary Means for Revolutionary Ends.

ニックはフェイスブックで「革命的な目的のための進化的手段」という講演を行った。

It's like the art of designing, the art of changing large scale software systems in place.

大規模なソフトウェアシステムを変化させる、設計の芸術のようなものだ。

The kind of bonus of that whole talk is this idea that you should be making as incremental changes as possible that are easily repeatable and you don't have to think about.

この話のオマケのようなものは、簡単に再現可能で、考える必要のない、できるだけ漸進的な変更を加えるべきだという考え方だ。

And the other aspect of it is that migrations build momentum, right?

そしてもう一つの側面は、移籍が勢いを増すということだね。

Once you see value, people are a lot more likely to do the work.

ひとたび価値を見出せば、人々は仕事をする可能性が高くなる。

And so the whole point of Airlift is to do two things, right?

Number one is give you as much value as possible without doing migration so that you can communicate to your stakeholders why Dagster is useful, right?

その1は、移住をせずにできるだけ多くの価値を提供することで、なぜダグスターが有用なのかをステークホルダーに伝えることができますよね。

Which gives you the buying power you need to actually structure a migration, right?

そうすれば、実際に移住を計画するのに必要な購買力を得ることができるだろう？

And then the second part is that there's no silver bullet for migration, right?

そしてもうひとつは、移籍に特効薬はないということだ。

At some point, you know, there's some DAGs that are easy to migrate.

ある時点で、移行が簡単なDAGも出てくる。

There's some DAGs that are hard to migrate.

We can help you do things, make certain migrations easier, but in the degenerate case, you're always going to have to move some code over, right?

私たちは、移行を簡単にするための手助けをすることはできますが、退化したケースでは、常にコードを移行しなければならないでしょう？

And so the whole point is then making that process of moving code over as safe and incremental as possible.

そして要は、コードを移行するプロセスを可能な限り安全かつ漸進的なものにすることだ。

And so the peer step, right, is this, okay, let's give you value as quickly as possible.

だから、ピアステップは、オーケー、できるだけ早く価値を提供しよう、ということなんだ。

You can just ingest your code immediately into Dagster, no changes to Airflow, right?

Airflowに変更を加えることなく、コードをすぐにDagsterに取り込むことができるのですね？

And it's very safe, simple, easy to try out.

とても安全で、シンプルで、簡単に試すことができる。

It's like people try it out in like 10 minutes, not a big deal, and they get value, right?

10分くらいで試して、大したことなくて、価値があるんでしょ？

You still don't have to make any changes to Airflow, right?

それでもエアフローに変更を加える必要はないよね？

But now you have to do a little bit more thinking about, okay, what does the actual internal asset graph look like?

しかし今は、実際の内部資産グラフはどうなっているのか、もう少し考える必要がある。

字幕リスト動画再生

エアリフトクリス・デカロリスインタビュー（全文） (Airlift Interview with Chris Decarolis (Full Interview))

stuff

ultimately

entire

assume

エアリフト クリス・デカロリス インタビュー（全文） (Airlift Interview with Chris Decarolis (Full Interview))

stuff

ultimately

entire

assume

エアリフトクリス・デカロリスインタビュー（全文） (Airlift Interview with Chris Decarolis (Full Interview))