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

© 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

View Slide

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

View Slide

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

View Slide

例：ローカルキャッシュによる改良（？）
var cache = new Map();
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 に問い合わせてキャッシュに登録した
それ以外

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

1. 「意味」の意味を考える

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

言語 = 構文 + 意味論

View Slide

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

View Slide

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

View Slide

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

View Slide

● "e1 < e2" の形の式はそれぞれの評価値の大小に応じて
true または false に評価される

View Slide

● "if e1 then e2 else e3" の形の式は e1 の評価値に応じて
e2 の評価値または e3 の評価値に評価される
e2 の評価値は問わない
e1 の評価値は問わない

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

● "e1 < e2" の形の式も同様に左を値まで簡約してから右を簡約
● 左右両方が値まで簡約されて初めて比較を行う
左が値のときのみ適用可

View Slide

● "if e1 then e2 else e3" の形の式は、条件部分を先に簡約
● 条件部分が値まで簡約されて初めて実際の選択を行う
条件節が true / false のときのみ適用可

View Slide

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

View Slide

同じ構文 + 別の意味論

View Slide

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

View Slide

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

View Slide

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

View Slide


View Slide

2. 意味論、サーバーレスを語る

View Slide

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

View Slide

サーバーレスプラットフォーム
= 構文 + 意味論

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

● 関数インスタンス F の内部で処理が 1 ステップ進む
● まだ return 文までは到達しておらず外部からは観測できない
内部で状態 σ から σ’ に遷移
場に出ている要素は変化しない

View Slide

● 関数インスタンス F が return し停止レスポンス stop を返す
● リクエスト R が消化されてレスポンス S が現れる
● 関数インスタンス F は busy から idle になり残る
値 v’ を return した
R が S に置き変わる

View Slide

● 関数インスタンス F が終了する
● 規則に前提がない、つまり終了はいつでも突然発生しうる
前提が空

View Slide

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

View Slide


View Slide

3. あなたの心の中のサーバーレス

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

○
(2-1) 処理の各ステップの前に ≒ が成立していれば、後にも成立する
○
(2-2) もし return 文で値を戻すならば、その値も一致する

View Slide

○
(4) return 時の状態と初期状態の間に関係 ≒ が成立する

View Slide

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

View Slide


View Slide

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

View Slide

例：ローカルキャッシュによる改良（再掲）
var cache = new Map();
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 に問い合わせてキャッシュに登録した
それ以外

View Slide

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

View Slide

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

View Slide

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

View Slide

4. まとめと読書案内

View Slide

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

View Slide

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

View Slide

● プログラミング言語の基礎概念
○
五十嵐淳著
○
サイエンス社、2011
● 言語の中でも特に型システムがテーマ
○
意味論としては操作的意味論のみ
○
言語や型システムの性質を証明することに主眼

View Slide

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

View Slide

Thank you!
チェシャ猫
@y_taka_23

View Slide

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

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

y_taka_23

More Decks by y_taka_23

Other Decks in Technology

Featured

Transcript