サーバーレスは操作的意味論の夢を見るか？ #AWSDevDay / AWS Dev Day 2022 Japan

© 2022, Amazon Web Services, Inc. or its affiliates. All
rights reserved. © 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. サーバーレスは操作的意味論の夢を見るか？チェシャ猫 (@y_taka_23) AWS Dev Day 2022 Japan (10th Nov. 2022) Breakout Session E-2 ProofCafe Software Engineer

rights reserved. 今日の話は何では「ない」か • 明日からの仕事で役立ったりはしません ◦ ツールや機能の How To の紹介ではありません ◦ 計算機科学に関する理論的な内容（の入門）中心です • とはいえ Developer にとって決して無駄ではない（はず） ◦ 普段見るサーバーレス with ガチ理論という構図が単純に面白い ◦ 講演後「参考文献ちょっと読んでみるか」と思ってもらえると嬉しい

rights reserved. 例：認証用のサーバーレス関数 function auth(req, res) { let {uesr, pass} = req.body; if (db.get(user) === pass){ res.write(true); } else { res.write(false); } } ユーザ名とパスワードを受け取り DB に問い合わせて合致を確認それ以外

rights reserved. 例：ローカルキャッシュによる改良（？） var cache = new Map(); function auth(req, res) { let {uesr, pass} = req.body; if (cache.contains(user, pass)) { res.write(true); } else if (db.get(user) === pass){ cache.insert(user, pass); res.write(true); } else { res.write(false); } } 関数インスタンス内にキャッシュユーザ名とパスワードを受け取りキャッシュにヒットした DB に問い合わせてキャッシュに登録したそれ以外

rights reserved. サーバーレスの解析困難性 • 直感的には安全そうだが、どうやって確認するか ◦ 複数の関数が同時に実行されたら？ ◦ Warm Start で関数インスタンスが再利用されたら？ ◦ At-Least-Once 実行により複数回実行されたら？ • プラットフォームの低レベルな挙動が露出している ◦ 言語外の挙動が影響するため、通常の Linter などでは手が届かない

rights reserved. もっと確実な「理論的裏付け」が欲しい

rights reserved. Formal Foundations of Serverless Computing Jandga A. et al. 2019 https://dl.acm.org/doi/10.1145/3360575

rights reserved. 本日の解説の流れ • サーバーレスの動作を厳密に記述したい • そもそも動作を厳密に記述するとはどういうことか • 改めてサーバーレスの動作を厳密に記述する • 理想化されたサーバーレスの動作はどうあるべきか • その理想化はどういう条件の下で妥当か

rights reserved. if 0 + 1 < 2 then 3 + (4 + 5) else 6 + 7 = ?

rights reserved. ＼言語の定義が不明なので解答不能／

rights reserved. if 0 + 1 < 2 then 3 + (4 + 5) else 6 + 7 = ? 数値は自然数値は true、false または数値式はリテラル、+、< または if 式

rights reserved. ＼言語の「意味」が不明なので解答不能／

rights reserved. 言語の「意味」を定義する 3 つの方法 • 実装による定義（かつての Ruby など） ◦ 参照実装を提供する：動作の正しさとは参照実装との一致 • 自然言語による定義（C++、Java、ECMAScript など） ◦ 仕様書を提供する：曖昧性や矛盾の発見は人間の思考力に依存 • 形式的意味論による定義（Scheme、Standard ML など） ◦ 厳密なルールを提供する：曖昧性を廃し、機械的検証の土台となる

rights reserved. オレオレ言語のフル仕様構文意味論

rights reserved. 意味論に現れる変換規則の読み方 • 規則には便宜上の名前が付けられていることが多い • 横線より上の部分は変換に必要な前提 • 横線より下の部分は前提のもとで可能な変換の内容仮定：e1 が n1 に、e2 が n2 に評価される結論：e1 + e2 が n1 と n2 の和に評価される規則名：Plus-N

rights reserved. オレオレ言語の意味論 (1/3) • 値は評価してもその値のまま変わらない • "e1 + e2" の形の式はそれぞれの評価値の和に評価される構文要素としての + ホスト言語としてのメタな +

rights reserved. オレオレ言語の意味論 (2/3) • "e1 < e2" の形の式はそれぞれの評価値の大小に応じて true または false に評価される

rights reserved. オレオレ言語の意味論 (3/3) • "if e1 then e2 else e3" の形の式は e1 の評価値に応じて e2 の評価値または e3 の評価値に評価される e2 の評価値は問わない e1 の評価値は問わない

rights reserved. 例：オレオレ言語の意味論による計算 • 部分式に対して規則を適用し、反復・再帰的に計算を行う • 各ステップではすべての部分式を同時に、値まで評価する

rights reserved. この方法でサーバーレスも厳密に扱える…？

rights reserved. Big-Step 意味論と Small-Step 意味論 • ここまでで見たスタイルは Big-Step 意味論と呼ばれる ◦ すべての部分式に対して同時に、値まで一気に評価 • Big-Step スタイルはサーバーレスと相性がよくなさそう ◦ 複数の関数が並行的に実行されている途中の状況が重要 ◦ 常に次回 Warm Start の可能性があり「値まで評価」はナンセンス • もう一つの Small-Step 意味論と呼ばれるスタイルを考える

rights reserved. オレオレ言語の Small-Step 意味論 (1/3) • "e1 + e2" の形の式は左を値まで簡約してから右を簡約 • 左右両方が値まで簡約されて初めて和の計算を行う左が値のときのみ適用可

rights reserved. オレオレ言語の Small-Step 意味論 (2/3) • "e1 < e2" の形の式も同様に左を値まで簡約してから右を簡約 • 左右両方が値まで簡約されて初めて比較を行う左が値のときのみ適用可

rights reserved. オレオレ言語の Small-Step 意味論 (1/3) • "if e1 then e2 else e3" の形の式は、条件部分を先に簡約 • 条件部分が値まで簡約されて初めて実際の選択を行う条件節が true / false のときのみ適用可

rights reserved. 例：Small-Step 意味論による計算 • 部分式に対して規則を適用し、逐次的に計算を行う • 各ステップではひとつの部分式のみ、かつ 1 回分だけ簡約する

rights reserved. 同じ構文 + 別の意味論

rights reserved. 言語は構文のみにあらず • 構文が同じでも意味論が異なるなら既に別の言語 ◦ 例えば「if 式は中身を先に簡約」だとエラーの有無が変わりうる ◦ 先ほどの Big-Stap と Small-Step も一致するかどうかは実は不明 • 意味論が妥当であることの保証も言語設計に含まれる ◦ 途中で進行不能にならないか、結果が簡約順に依存しないか、など ◦ それを数学的に証明するための「厳密」な意味論

rights reserved. 形式的意味論の 3 分類 • 操作的意味論 (Operational Semantics) ◦ 構文に対する変換規則を定め、どのように実行されるかを定義 • 表示的意味論 (Denotational Semantics) ◦ 意味論が既知の（より単純な）対象へのマッピング規則を定義 • 公理的意味論 (Axiomatic Semantics) ◦ 部分式の事前・事後条件に着目し、組み立てた際の伝搬規則を定義

rights reserved. Section 1 のまとめ • 操作的意味論を用いた言語の「意味」の定義 ◦ 構文に対して、その「実行」を進めるための変換規則を定める ◦ 「横棒の図式」の上側が必要な前提、下側が得られる帰結 ◦ 言語の性質について厳密な議論が可能になる • それ以外の方法として、表示的意味論や公理的意味論がある ◦ 操作的意味論はインタプリタ、表示的意味論はコンパイラに相当

rights reserved. Formal Foundations of Serverless Computing Jandga A. et al. 2019 https://dl.acm.org/doi/10.1145/3360575

rights reserved. サーバーレスの状態を計算する「言語」構文意味論

rights reserved. サーバーレスの構文 • プラットフォーム全体の状態を「式」で表す ◦ 呼び出し元からの未処理リクエスト ◦ 実行中で内部状態 σ の関数インスタンス ◦ Warm up 済みで内部状態 σ の関数インスタンス ◦ 呼び出し元に返すレスポンス • 場に存在するすべての要素を並べてプラットフォームを表す

rights reserved. サーバーレスの意味論 (1/6) • 関数 f に対して起動リクエスト start を受ける • プラットフォーム内にそのリクエスト情報 R が現れる • まだ（Warm / Cold 問わず）関数インスタンスは起動しない x は新規のリクエスト ID 場に R が出現するが F はまだいない

rights reserved. サーバーレスの意味論 (2/6) • 到着済みのリクエスト R に対応して Cold Start が発生する • プラットフォーム内に関数インスタンス F が現れる • 保持されているリクエスト R は起動後も残る新規で F が出現、まだレスポンスを返してないので R は残る f の初期状態が σ

rights reserved. サーバーレスの意味論 (3/6) • 到着済みのリクエスト R に対応して Warm Start が発生する • idle 状態だった関数インスタンス F が busy 状態になる • リクエスト R はやはり起動後も残る既にあった F を再利用、まだレスポンスを返してないので R は残る前回残っていた状態 σ から σ’ に遷移

rights reserved. サーバーレスの意味論 (4/6) • 関数インスタンス F の内部で処理が 1 ステップ進む • まだ return 文までは到達しておらず外部からは観測できない内部で状態 σ から σ’ に遷移場に出ている要素は変化しない

rights reserved. サーバーレスの意味論 (5/6) • 関数インスタンス F が return し停止レスポンス stop を返す • リクエスト R が消化されてレスポンス S が現れる • 関数インスタンス F は busy から idle になり残る値 v’ を return した R が S に置き変わる

rights reserved. サーバーレスの意味論 (6/6) • 関数インスタンス F が終了する • 規則に前提がない、つまり終了はいつでも突然発生しうる前提が空

rights reserved. Section 2 のまとめ • サーバーレスプラットフォームを表現する「構文」 ◦ 場に存在するリクエスト・関数インスタンス・レスポンス • サーバーレスの特有の挙動を表現した「意味論」 ◦ 複数の関数インスタンスによる並行実行 ◦ リトライによる At-Least-Once 性 ◦ Warm Start による関数インスタンスの再利用

rights reserved. サーバーレスは「特有の事情」が多い

rights reserved. 理想化された「心の中」のサーバーレス • 一度にひとつの関数インスタンスしか実行されない • Warm Start による関数インスタンスの再利用は行われない • At-Least-Once ではなく Exactly-Once で実行される • 関数インスタンスが突然終了したりしない

rights reserved. サーバーレスを単純化した「言語」構文意味論

rights reserved. 単純化されたサーバーレスの構文 • プラットフォーム全体の状態を「式」で表す ◦ 処理中の関数名 ◦ 処理中のリクエスト（最大ひとつ） ◦ 内部状態 σ の履歴リスト（履歴は直線的） ◦ 既に返したレスポンスの集合（順不同） • 以上の要素の一組をプラットフォームの状態とする

rights reserved. この単純化は「妥当」だろうか？

rights reserved. 双模倣による状態遷移系の等価性 • 終了することがない状態遷移をどうやって比較するか ◦ 関数のように「同じ引数を入れると同じ結果が出る」はナンセンス • 双模倣 (Bisimulation) による比較 ◦ 相手側がどんな遷移をしたとしても、常に同じ遷移を真似できる ◦ 元の状態で「同じ」ならば、遷移した先でもやはり「同じ」 ◦ 内部遷移を無視したものを弱双模倣 (Weak Bisimulation) と呼ぶ

rights reserved. 例：双模倣が成立する場合 a a b b b

rights reserved. 例：双模倣が成立しない場合 a a b b c a c 次に b で遷移するルートがない

rights reserved. 単純化された意味論は双模倣同値になるか？

rights reserved. 関数インスタンスの内部状態 • 関数インスタンス内部の状態をどう扱うか ◦ 例として挙げたキャッシュを持つ関数は、内部に状態が残る ◦ 処理の開始時に「完全に同じ状態」を要求するのは強すぎる ◦ 外部から見て観測できない差であれば許容したい • 状態間に Safety Relation と呼ぶ「許容可能な差」を定義 ◦ 処理中に「許容可能な差」から逸脱しないことを要求したい

rights reserved. Safety Relation (Deﬁnition 4.1) (1/3) • 関数インスタンスの状態間に定義された同値関係 ≒ が以下 (1) - (3) を満たすとき、≒ は Safety Relation であるという ◦ (1) リクエスト受信前に ≒ が成立していれば、受信後にも成立する

rights reserved. Safety Relation (Deﬁnition 4.1) (2/3) ◦ (2-1) 処理の各ステップの前に ≒ が成立していれば、後にも成立する ◦ (2-2) もし return 文で値を戻すならば、その値も一致する

rights reserved. Safety Relation (Deﬁnition 4.1) (3/3) ◦ (4) return 時の状態と初期状態の間に関係 ≒ が成立する

rights reserved. 単純化した構文との対応 (Deﬁnition 4.2) • 単純化側のレスポンスは必ず元の側のリクエスト R に起因 ◦ • 関数インスタンス F の状態は Safety Relation の差を除いて対応 ◦ • この対応関係を ≈ で表す ◦ 単純化された構文の式 A と元の構文の式 C が対応

rights reserved. 単純化の正当性 (Theorem 4.3) • 単純化された意味論と元の意味論は ≈ により弱双模倣同値 ◦ (1) 単純化側の遷移 l (= start / stop) に対し、元の側も l で遷移できる ◦ (2) 逆に、元の側の遷移 I に対し、単純化側も l で遷移できる • 要するに Safety Relation が存在すれば両者は外から区別できない (1) (2)

rights reserved. 例：ローカルキャッシュによる改良（再掲） var cache = new Map(); function auth(req, res) { let {uesr, pass} = req.body; if (cache.contains(user, pass)) { res.write(true); } else if (db.get(user) === pass){ cache.insert(user, pass); res.write(true); } else { res.write(false); } } 関数インスタンス内にキャッシュユーザ名とパスワードを受け取りキャッシュにヒットした DB に問い合わせてキャッシュに登録したそれ以外

rights reserved. 例：キャッシュを持つ実装の正当性 • 考慮したい状態は、実行中の変数の値 + キャッシュ + DB • キャッシュを無視した同一視は Safety Relation の条件を満たす • したがってこの例の実装はサーバーレス特有の影響を受けない（ただし c, c’ ⊆ d のときのみ）（ただし C, D は U から P への部分関数）

rights reserved. Section 3 のまとめ • サーバーレスの意味論の単純化 ◦ 一旦、サーバーレス特有の挙動を無視して理想化して考える ◦ 実行は一度に一つの関数のみ、リトライも Warm Start も無し • 元の意味論との対応関係 ◦ うまく「特有の挙動」を吸収できる Safety Relation を定義 ◦ 元の意味論との間で弱双模倣が成立するための条件を定式化

rights reserved. おまけ：論文後半の展開 • さらに永続化層の操作も含めて意味論を展開 ◦ トランザクショナルな Read / Write を仮定 ◦ 新しい規則 Read、Write、BeginTx、EndTx、DropTx が追加される • サーバーレス用のプログラミング言語 SPL の提案 ◦ 言語組み込みの機能として Arrow ベースの「関数の合成」を持つ ◦ Apache OpenWhisk 上に SPL の処理系を実装

rights reserved. 本日のまとめ • サーバーレス特有の複雑性 ◦ プログラマが意識したくない低レベルな挙動が露出している • プログラミング言語と意味論 ◦ 厳密な数学的定義を用いてシステムの「意味」を明確化できる • Jangda らによるサーバーレスの意味論 ◦ 理論的に「低レベルな挙動」が無視できる条件を定式化した

rights reserved. あなたが次に読む本 (1/3) • プログラム意味論の基礎 ◦ 小林直樹・住井英二郎著 ◦ サイエンス社、2020 • 理論も含めプログラム意味論の入門向け ◦ 論理式などの数学的準備も 1 章割かれている ◦ 操作的・表示的・公理的意味論を一通り概観

rights reserved. あなたが次に読む本 (2/3) • プログラミング言語の基礎概念 ◦ 五十嵐淳著 ◦ サイエンス社、2011 • 言語の中でも特に型システムがテーマ ◦ 意味論としては操作的意味論のみ ◦ 言語や型システムの性質を証明することに主眼

rights reserved. あなたが次に読む本 (3/3) • アンダースタンディング・コンピュテーション ◦ Tom Stuart 著・笹田耕一監訳・笹井崇司訳 ◦ オライリー・ジャパン、2014 • Ruby で実装しながら計算機科学を学ぶ ◦ 厳密さよりも「動かして勘を掴む」的スタンス ◦ Chomsky 階層や停止性など「名所」を一巡り

サーバーレスは操作的意味論の夢を見るか？ #AWSDevDay / AWS Dev Day 2022 Japan

サーバーレスは操作的意味論の夢を見るか？ #AWSDevDay / AWS Dev Day 2022 Japan

More Decks by y_taka_23

Other Decks in Technology

Featured

Transcript