# スクリプタブルロードバランサー ## 定義 スクリプタブルロードバランサー(scriptable load balancer)とは、Lua などのスクリプト言語を通じてリクエスト/レスポンス処理フローを変更できるプロキシである。従来のロードバランサーが出荷時に導入する制限の多い宣言型設定言語(アプリケーションロジックの表現が困難で、正しさをテストで検証しにくい)と、Facebook の Proxygen のようなカスタムビルドのアプリケーション認識型ロードバランサー(C言語ベースのプラグインシステムで機能拡張するが、メモリ安全性の保証がなくバッファオーバーフロー等のリスクを負う)という両極端の中間領域を埋める。高水準のスクリプト言語はランタイムとメモリに関する厳格な保証によりサンドボックス化でき、開発者は低レベルの実装詳細を無視して純粋にアプリケーションロジックの記述に集中できる。主要なプロジェクトは OpenResty(LuaJIT が組み込まれた Nginx の C モジュール)と nginScript(Nginx Inc. による JavaScript 実装)の2つ。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.1) スクリプタブルロードバランサーが解く典型的な問題領域は4つある。 | 問題領域 | 解法の要点 | |---|---| | シャード対応ルーティング | シャード解決ロジックをロードバランシング層に完全に移し、アプリケーションからシャード分割を抽象化する | | ダウンタイムなしのデプロイ | リクエストの一時停止(Intermission)により、メンテナンス中のエラーをレイテンシ増加に転換する | | サービスレベルミドルウェア | リクエストと最初に接触するという位置付けを利用し、識別・WAF等の横断的ロジックをRPC呼び出しなしに実装する | | 状態管理(スロットリング・キュー) | 共有データストア(正確性優先)とロードバランサーごとのローカル状態(弾力性優先)のトレードオフとして設計する | (Source: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ch.25 §25.2-25.4) ## 横断的知見 - (現時点で本概念のソースは [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] の1件のみ。今後 Envoy・HAProxy・Cloudflare Workers 等の別ソースが ingest された際に、複数ソースを突き合わせた知見をここに追記する。) - **サービスメッシュのサイドカープロキシは、同じ「機能をアプリケーション本体から切り離す」問題を配置の集中度が異なる形で解く**: 26章([[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]])は[[サービスメッシュ]]のサイドカープロキシを扱うが、本章がロードバランシング層への機能集約(シャードルーティングの最終形態)で目指したこと——アプリケーションからネットワーキング関心事を抽象化すること——と同一の設計思想を、「中央のロードバランサー1箇所」ではなく「アプリケーションごとに1:1配置されたプロキシ群」で実現する。26章自身が脚注で「HAProxy などのハイパフォーマンスなプロキシをアプリケーションと共にインストールするパターンは、完全なサービスメッシュへの前段階と考えることができる」(ch.26 p.465-466 脚注3)と明記しており、スクリプタブルロードバランサーとサービスメッシュは同一スペクトラム(判断の集中 対 分散)の両端として位置づけられる。ロードバランサー層への集約は判断の一貫性・再利用性を高めるが単一障害点になりやすく、サイドカー配置は障害の影響範囲を局所化できる一方でコントロールプレーンという新しい複雑さを持ち込む。(Source: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]], [[@2021__OReillyJapan__SREの探求 - Chapter 26 サービスメッシュはマイクロサービスの世話人か]]) ## 未解決の問い - OpenResty(Lua/LuaJIT)と nginScript(JavaScript)以外に、Envoy の WASM フィルタ・HAProxy の Lua スクリプティング・Cloudflare Workers(V8 Isolates)のような後続世代のスクリプタブルロードバランサーは、本章が指摘したサンドボックス化・パフォーマンスのトレードオフをどう再構成したか。 - ロードバランサー内のロジックが「難しい問題の強力な解決策」から「釘を探すハンマー」(単一障害点の持ち込み・可用性への悪影響)へ転落する境界を、事前にどう見極めるか。本章は危険性を指摘するが、具体的な判断基準までは示していない。 - 状態を共有データストアに置くか個々のロードバランサーに分散するかのトレードオフ(正確性 対 弾力性)は、[[待ち行列理論]] や合意アルゴリズムの知見からどこまで一般化できるか。 - シャードルーティングロジックをロードバランサー層に集約する設計(本章の Slicer 事例)は、[[マイクロサービスアーキテクチャ]] のサービスメッシュ(サイドカープロキシによる分散型ルーティング)とどう関係し、どちらが優位な状況があるか。 ## 関連 - 概念: [[Webロードバランシング]] / [[負荷分散]] / [[マルチテナンシーのためのシャーディング]] / [[待ち行列理論]] / [[マイクロサービスアーキテクチャ]] - 実体: [[Emil Stolarsky]] / [[Cloudflare]] / [[nginx]] / [[OpenResty]] / [[Shopify]] / [[DigitalOcean]] - ソース: [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]] ## 出典 - [[@2021__OReillyJapan__SREの探求 - Chapter 25 スクリプタブルロードバランサー]](スクリプタブルロードバランサーの定義、シャード対応ルーティング4方式の比較、Intermission、サービスレベルミドルウェア、状態管理のトレードオフ)