サーバーレスを再考する: FLAME 技術

 (fly.io)
3 ポイント 投稿者 GN⁺ 2023-12-08 | 1件のコメント | WhatsAppで共有

FLAME パターン: アプリケーションの弾力的なスケーリングのための新しいアプローチ

  • サーバーレス/FaaS(Function as a Service) は、弾力的なスケーリングと使用量ベースの課金という利点を提供する一方で、実際にはより多くの複雑さを招く。
  • 既存のアプリコードを関数で包み、一時的なアプリのコピー上で実行できれば、自動スケーリングが可能になる。
  • FLAME(Fleeting Lambda Application for Modular Execution) パターンは、アプリケーション全体をラムダのように扱い、モジュール化された部分を短期間のインフラ上で実行する。

FLAME パターン

  • FLAME パターンは、サーバー管理なしで、アプリコードの特定部分に対する需要ベースのきめ細かな弾力的スケーリングを目指す。
  • 既存のアプリケーションを書き直したり、独自ランタイム向けに部分的に書き換えたりする必要はない。
  • Elixir の flame ライブラリは FLAME パターンを実装しており、Fly.io バックエンドアダプターを含むが、アプリコードを実行できる API を提供する任意のクラウドで利用できる。

FLAME バックエンド

  • Fly.io インフラ上では、FLAME.FlyBackend が新しい Machine を起動し、約 3 秒以内に親ジョブへ接続できる。
  • FLAME は LocalBackend と FlyBackend を標準で提供するが、サーバーをプロビジョニングしてアプリコードを実行できる API を提供する任意のホストは FLAME バックエンドとして動作できる。
  • Fly.io はアプリケーションを Docker イメージとしてパッケージ化して実行するため、同じイメージで新しい Machine を起動するだけでよい。

FLAME 以外での Elixir

  • Elixir はプロセス監督や分散メッセージングのような機能を標準で提供するため、FLAME モデルに非常に適している。
  • 言語が妥当な並行性の基本要素を備えていれば、このパターンを活用できる。
  • JavaScript アプリケーションでも FLAME パターンを実装できる例があり、モジュール化された実行を新しいファイルへ移して実行する。

バックグラウンドジョブプロセッサについて

  • FLAME はバックグラウンドジョブプロセッサ内でうまく機能するが、ジョブライブラリがジョブプールを拡張することとは別問題である。
  • 耐久性を保証するジョブと、弾力的な実行を分離することが重要である。

弾力的スケーリングのためのプーリング

  • Elixir の FLAME 実装では、弾力的プールのランナーを定義でき、これによりゼロまでスケールしつつ、最大同時実行数の上限を持つ FLAME サーバーを弾力的に拡張できる。

プロセス配置

  • Elixir では、状態を持つアプリケーションの部分はプロセスという基本要素を中心に構築され、FLAME.call や FLAME.cast で包まれた形でうまく動作する。

リモート監視

  • 親がランナーをスピンアップするとき、ランナーはジョブがないときに自らアイドル状態を管理し、親ノードとの接続が切れた場合は安全に終了できるようにする必要がある。

GN⁺の見解

この記事で最も重要なのは、FLAME パターンが従来のサーバーレス/FaaS アプローチの複雑さを減らしつつ、アプリケーションの弾力的なスケーリングを単純化できる点です。このパターンは、開発者が既存コードを大きく変更せずに必要な部分だけをすばやく拡張できるようにし、クラウドインフラを利用する多くのソフトウェアエンジニアにとって魅力的なソリューションとなりえます。FLAME パターンは、特に Elixir のような言語で強力なツールとなる可能性があり、他言語での実装可能性も探られているため、多様な開発環境での適用が期待されます。

関連記事

1件のコメント

 
GN⁺ 2023-12-08
Hacker Newsの意見

  • 100個を超えるLambda関数で構成されたアプリケーションを4年間扱ってきた苦痛と複雑さについて、この文章はサーバーレスFaaSアーキテクチャの欠点をよく指摘している。

    • 当初はこうした欠点は目立たず、利用量が少ないときは無料で、保守もほとんど不要といった明確な利点がある。
    • しかし時間が経つにつれて、相互依存性によってますます硬直化したLambdaワークフローの混乱を経験し、自前で管理するモノリシックなアプローチを選んで多少の追加コストを払うほうがよかったのではないかと思うようになった。

  • 文章の著者として、FLAMEパターンをJavaScript、Goなど他の言語で実装しようとする人たちの関心を引ければと思っており、質問に答える用意がある。

  • PiCloudサービスは、ジョブを透過的にワーカーへ渡すモデルを採用していたことがあり、これはElixir以外の言語でも同様に適用できる可能性を示している。

  • FLAMEを使うと、既存のアプリコードを関数でラップして一時的なアプリのコピー上で実行でき、これはサーバーレス環境でプロセスをフォークするのに似ている。

  • Windmill.devはソースコードレベルで抽象化の単位を考慮し、主要な関数とインポートをパースして引数と依存関係を抽出し、望むランタイムでコードを実行する。

  • FLAMEを使うと、開発用およびテスト用ランナーがローカルバックエンドで実行されるため、サーバーレス環境でも優れたローカル開発体験を提供する。

  • Flame.call を使うたびに新しいアプリプロセスを起動して実行コンテキストをコピーするが、これはスケーリングのためのシンプルな解決策である一方、アプリ起動時間に追加される遅延やメモリ使用量への考慮が必要である。

  • Hacker Newsの見出しにおける大文字使用への批判とともに、サーバーレスの原則ではなく serverless.com という会社の再考につながることへの期待を表している。

  • Inngest.comは既存のコードをサーバーレス関数として使えるようにするのと似た方式を提供しており、コードの状態を外部で管理し、監視と可観測性の重要性を強調している。

  • 「Long Lambda」というシステムを作り、Lambdaが15分以上実行できるなら、すべての作業をLambdaで処理でき、ローカルでの実行やデバッグも可能になる。

この要約は各コメントの主要な内容を簡潔に伝えており、初級ソフトウェアエンジニアが理解しやすい水準で書かれています。背景知識が必要な部分の説明は最小限にとどめ、中立的な態度を維持しつつ主題から逸れないようにしています.