クラウド ネイティブ アプリを構築する際に回復力を無視できますか?

Temporal の Samar Abbas 氏は、開発者は状態を失うことさえ考えなくてもよいと考えています。決して失敗しないこれらの永続的な実行があります。

ワード プロセッシング ツールを長い間使用したことがある場合は、「保存」キーボード ショートカットを押すという反射的なアクションを覚えているでしょう。つまり、作業内容を失うことへの恐怖、大声でののしり、失った素晴らしい作業を嘆くことです。

最新のツール (Google Docs を考えてみてください) を使用すれば、この心配はまったくありません。言葉の途中で力が抜ける？問題ない。すべてがそのままの状態で保存され、次に進むことができます。

ワークフロー オーケストレーション エンジン Temporal の Samar Abbas と彼のチームは、この概念をエンタープライズ ワークフローに取り入れたいと考えています。ビジネス ロジックを提供すると、永続性や回復力などの専門知識を必要とするすべての部分が処理されます。

Temporal は、 2019 年に Abbas と彼の同僚である Maxim Fateev が Uber に在籍していたときに設立されました。彼らは、「ケイデンス」と呼ばれる配車アプリ会社の開発プラットフォームを作成していました。これは、2000 年代半ばに 2 人が Amazon で同僚だったときに開発を支援したAWS Simple Workflow Service プラットフォームの進化版です。数十の Uber サービスとアプリケーションがCadenceを採用しています。

Abbas と Fateev は、Temporal を共同設立し、Cadence のフォールト トレラントなワークフロー エンジンの後継プロジェクトを構築するために会社を去りました。それ以来 3 年間、同社は堅実な成功を収めており、Netflix、Instacart などの企業が Temporal のオープン ソース ソフトウェア コードを使用しています。今年初め、同社は 1 億 300 万ドルのシリーズ B ラウンドを確保し、評価額は 15 億ドルになりました。

私は最近、Abbas (すべてを見ることができます) と、彼と Fateev が大成功を収めたベンチャーをどのように構築したかについて話しました。 （以下の彼の言葉は、明確さと長さのために編集されています）。

Uber から Temporal へ

2015 年に Uber がシアトルにオフィスを開設し、私は同社のエンジニアリング チームに加わりました。私と Max [Temporal の共同設立者 Maxim Fateev] は、互いに 1 か月以内に Uber を利用することになりました。私たちが一緒に取り組んだ重要なプロジェクトは Cadence でした。

Uber では、エンジニアは低レベルのキュー、データベース、 耐久性のあるタイマーをつなぎ合わせて、アプリケーションに回復力を組み込むことに多くの時間を費やしました。

これは、私たちが Cadence のようなシステムで解決しようとしていたことです。そこでは、まだコードベースである高レベルの抽象化を提供していましたが、特定のクラスの失敗をエンジニアのプレートから取り除き、プラットフォームの下で解決して、エンジニアができるようにしました。回復力を構築するのではなく、アプリケーションのビジネス ロジックに集中できます。

これは Uber 内で成功し、オープン ソースであるため、この技術が外部から多く採用されるようになりました。そのため、2019 年に私と Max の両方が飛躍することを決定し、Temporal を開始しました。なぜなら、私たちはこのテクノロジーの外部採用に本当に集中したかったからです。

一時的な開発者エクスペリエンス

Temporal をワークフロー エンジンと説明したり、その機能について説明したりすることがありますが、私たちにとって重要な価値命題は開発者の生産性です。つまり、開発者がアプリケーションを構築して本番環境で実行できるようにするために、数週間または数か月かけてあらゆる種類の障害状況をテストする必要はありません。クラウドネイティブ環境で発生します。

したがって、開発者エクスペリエンスについての私たちの考え方は、テクノロジが提供するものの中核的な側面だけではありません。開発者がアプリケーションを構築する方法など、最初からソフトウェア開発ライフサイクル全体をカバーしています。たとえば、多くのワークフロー エンジンは通常、ドメイン固有言語 (DSL) ルートを使用します。私たちは皆、コードベースです。私たちは開発者がコードを書くのが好きであることを知っており、開発者にコードを書いてもらいたいと思っていますが、基盤となるインフラストラクチャがダウンした場合にそのコードを回復力のあるものにする方法や、ネットワーク障害が発生したときにコードを回復力のあるものにする方法など、特定の種類の懸念を取り除いてください。 .

テンポラルはいつ、どのように違いを生むのか?

送金は、Temporal が頻繁に使用される主要なユース ケースの 1 つです。ある口座から別の口座にお金を移動する場合、通常はユーザーの観点から、私は口座 A から引き落とし、次に口座 B に入金します。しかし、ソフトウェア開発時間の大部分は、これら 2 つの呼び出しの間のシステム障害に費やされます。そして、これは基本的にエンジニアがあらゆる種類の時間を費やしている場所です。

これは、Temporal のようなシステムが非常に役立つ例です。魔法のようにさえ感じます。この質問をよく耳にします。この時点でアプリケーションが失敗するとどうなりますか?

その質問に対する私たちの答えは次のとおりです: ワークフローは決して失敗しません (Temporal では、作成しているプリミティブを「ワークフロー」と呼んでいます)。それから、電気のスイッチがオンになる瞬間の 1 つです。私たちはこれを「永続的な実行」と呼び始めました。大まかに言えば、実行は完全に永続的です。彼らは決して失敗しません。

「障害に気付かない」ステートフル ワークフローのビジネスへの影響

私が学生だった 90 年代には、すべての課題を Microsoft Word で入力していました。いくつかの編集を行うたびにドキュメントを保存する習慣ができました。それでも、ハード ディスクがダウンしてすべての作業が失われるなど、特定の種類の障害が発生しました。

現在、Google ドキュメントを使用すると、子供はこれに関係することさえできなくなります。 「保存」ボタンすらありません。この 1990 年代の時代にまだ残っているステートフル アプリケーションのクラスがあり、コードの 80% 以上が、ステートフル アプリケーションの回復力を構築するためのインフラストラクチャ障害の処理に関するものであると考えています。イベントが発生するたびに、その状態をロードし、そのイベントを適用し、一連のアクションを実行してから、その状態を保存します。エンジニアリングの大部分は、信頼性、速度、パフォーマンスを向上させ、あらゆる種類の障害や破損から保護する方法に取り組んでいます。

開発者は、状態を失う可能性があると考える必要さえありません。決して失敗しないこれらの永続的な実行があります。そして、クラウドネイティブ システムに対するエンジニアの考え方が完全に変わると思います。

マネージド Apache Cassandra を使用する理由

共同創設者の Max と私は、メッセージング システムとミドルウェアの構築のバックグラウンドを持っています。ストレージ システムを実行することは、私たちの強みではありません。そのため、たった 2 人で会社を始めたときの主な目標は、Temporal ユーザーに最高の開発者エクスペリエンスを提供するという当社の強みを活用することでした。 Temporal にはサーバー コンポーネントとクライアント SDK があり、ほとんどの開発者はこれらをアプリケーションの構築に使用しています。しかし、運用上のオーバーヘッドを最小限に抑えてこれらのサーバーを実行するにはどうすればよいでしょうか?これは、Temporal を実行するためのオーバーヘッドの大部分が存在する場所です。

プラグ可能な永続性モデルがあります。 Apache Cassandra 、MySQL および Postgres をプラグ可能なアダプターとしてサポートしています。 Cassandra は、非常に優れたスケーラビリティ特性を持つアダプターの 1 つです。ユーザーにとって重要な価値提案は、ミッション クリティカルなアプリケーションを実行しているという事実であり、信頼性はユーザーが求めている重要なものです。そのため、Temporal フォールドに新しい依存関係を持ち込むときは、軽視しません。あらゆる種類の永続化オプションについて、1 か月以上の評価を実施しました。それはDataStax Astra DBでした。

いくつかの機能で成功するデータベースもあれば、他の機能で成功するデータベースもあります。しかし、この場合、それはテクノロジーについてでさえありませんでした。それは人々についてです。私たちは、バグや失敗は人生の一部であると信じています。障害が発生したときにどのように対応するかがすべてです。そして、これがAstra DBが勝つと私たちが信じているところです. DataStaxが顧客を扱う方法と、データベースの運用化に関して顧客が構築する関係の種類には、非常に多くの類似点があります.そして、これがシステムのコア部分に投資したい依存関係であるという確信を与えてくれました。

Astra のような技術を利用して構築することがなければ、今日のような状況にはなっていなかったと思います。 Cassandra を運用するだけで何かを「成し遂げる」だけでも、少なくとも 1 年はかかるプロジェクトであり、それは私たちの強みの一部ではありません。私たちのような企業にとって、重要な価値命題が信頼性である場合、信頼できる方法でストレージを実行および運用する方法を見つけられなければ、ビジネスはありません。

Cassandra Forward に今すぐ登録してください。これは 3 月 14 日に開催される無料の 2 時間の仮想イベントで、Apache Cassandra のすべてを取り上げます。

パトリック・マクファディン、DataStax

Patrick McFadin は、O'Reilly の著書「Managing Cloud Native Data on Kubernetes」の共著者です。彼は現在、DataStax で開発者関係の仕事をしており、Apache Cassandra プロジェクトへの貢献者として働いています。 Patrick は Apache Cassandra のチーフ エバンジェリスト (彼は新しく作成された Cassandra コミッターでもあります!) および DataStax のコンサルタントとして働いており、本番環境で最大のデプロイメントのいくつかを構築するのに素晴らしい時間を過ごしました。