論文メモ「Firecracker: Lightweight Virtualization for Serverless Applications」

AWSのLambdaの裏側で動いているマイクロVMの論文を読んでみた.
4章はAWSでのLambdaの動作を知るには有益なので読んでみるとGoodかも.

URL) https://www.usenix.org/system/files/nsdi20-paper-agache.pdf

最初のLambdaではLinux Containerを使っていたのが意外だ.
顧客アカウント単位で単一のVM内で複数の関数を実行していたのか.

When we first built AWS Lambda, we chose to use Linuxcontainers to isolate functions, and virtualization to isolatebetween customer accounts. In other words, multiple func-tions for the same customer would run inside a single VM,but workloads for different customers always run in differentVMs.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

AWSにおいて重要だったポイントは「density (密集度)」と「overhead (オーバヘッド)」の2つ
ねらい(たぶん)→関数が起動するまでの時間の削減,マルチテナンシー(収容率)の向上

Two key, and related, challenges of virtualization are density and overhead

出典) Firecracker: Lightweight Virtualization for Serverless Applications

QEMUの複雑さがエグい… 140万行のコードと270のシステムコール…

To illustrate this complexity, the popular combination of Linux Kernel Virtual Machine [29] (KVM) and QEMU clearly illustrates the complexity. QEMU contains>1.4million lines of code, and can require up to 270 unique syscalls [57] (more than any other package on Ubuntu Linux15.04). The KVM code in Linux adds another 120,000 lines. The NEMU [24] project aims to cut down QEMU by removing unused features, but appears to be inactive.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Rustで書いて96%のコード量をQEMUに比べて削減… 

Firecracker’s approach to these problems is to use KVM(for reasons we discuss in section 3), but replace the VMM with a minimal implementation written in a safe language. Minimizing the feature set of the VMM helps reduce surface area, and controls the size of the TCB. Firecracker contains approximately 50k lines of Rust code (96%fewer lines than QEMU), including multiple levels of automated tests, and auto-generated bindings. Intel Cloud Hypervisor [25] takes a similar approach, (and indeed shares much code with Fire-cracker), while NEMU [24] aims to address these problems by cutting down QEMU.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

Lambdaの関数実行環境はコロコロ変わるけれど,コードの読み込みとコードの移動にかかるコストを抑えるために関数実行環境をSticky(2回目以降は1回目を使う)に割り当てるのか !!

The execution of the customer code happens on the Lambda worker fleet, but to improve cache locality, enable connection re-use and amortize the costs of moving and loading customer code, events for a single function are sticky-routed to as few workers as possible.

出典) Firecracker: Lightweight Virtualization for Serverless Applications

SSO ProxyとZero Trust ProxyとSSO Proxyが分からない

これらの違いが分からない.

  • Zero Trust Proxy
  • Identity Aware Proxy
  • Single Sign On Proxy

具体的なソフトウェア名はわかる.

  • (製品) Google Cloud IAP → IAP
  • Pomerium → IAP
  • OAuth2-Proxy→SSO Proxy
  • BuzzFeed SSO→SSO Proxy

検索してみた.わからない.Zero Trust Proxyの実装のひとつがIdentity Aware Proxyなのだろうか.では従来のSSO Proxyとは何が違うのだろうか.

特に「ID認識型プロキシ(Identity Aware Proxy)」と呼ばれる仕組みを中心に据え、認証・認可を強化している。これは、アプリケーションやユーザーの場所を問わず、無理のない方法でアクセスさせる仕組みだ。アカマイのID認識型プロキシは、EAA(Enterprise Application Access)という製品として顧客にもサービスを提供している。

解説「ゼロトラスト」シフト:脱“境界セキュリティ”が進む2つの動き https://japan.zdnet.com/article/35134505/ より

CNCF Landscapeを見たが分からない.Pomerium, BuzzFeed SSO, OAuth2 Proxyあたりが該当するが違いについて触れられていない.

CNCF Landscape https://landscape.cncf.io/ より

Google Cloudの説明を見てみる.これによるとAuthNに加えてAuthZが詳細に行えるように見える.Role Based Access Controlが従来のSSO Proxyよりも細かく行えるということだろうか?

Cloud IAP 使用時の App Engine へのリクエストパスの図
Identity-Aware Proxy の概要 https://cloud.google.com/iap/docs/concepts-overview より

やはりよくわからなかった.有識者各位もし補足や答えを知っていれば教えて下さい.


余談:

感想「SREがセキュアなWebシステムを構築、維持するためにやれることはなにか」

mixiの清水さんがSRE NEXT 2020で発表されていたスライドを見て感じたことをメモする.

ログの扱い

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system 49 ページより引用
  • ログに認証情報や個人情報をはじめとする機密情報を出力しない.
  • ログを大量に出力するとコスト(お金)に影響が生じる.

koyamaの脳内

  • 役立つログを適切な粒度で出力するよう適切な設定が必要になりそう.
  • この粒度を適切に決めるのは,熟練したソフトウェア開発者しか出来ないのでは?
  • 複数メンバーが参加するソフトウェアプロジェクトで認識を統一するのは難しい.
  • 開発用のデバッグログもプロダクションで出力すると機密情報になるので,動作モードによって出力するログも制御すべきということかな.
  • 開発環境→トークンをログに表示
  • 本番環境→トークンをログに非表示

デフォルト設定を使わない

https://speakerdeck.com/isaoshimizu/what-can-sre-do-to-build-and-maintain-a-secure-web-system 67 ページより引用

koyamaの脳内

  • デフォルトVPCとセキュリティグループを使わないことをプラクティスにするのはイマイチな気がした.
  • 全利用者にセキュアな状態をデフォルトで提供するために,明示的な指定を利用者に求めればいいのに.
  • 利用者が簡単に使えること,デフォルトでセキュアな状態が作られることを両立してほしいな.
  • AWSはクラウド事業者なので,簡単に使えることを優先しているのではないか?と思った.

2020年に買ってよかったもの3選

2020年も終わるので買ってよかったものを3つ紹介します.

会議用スピーカー・マイク

会議用スピーカー・マイクのJabra SPEAK 510です.オンラインでの授業やミーティングが多く重宝しました.特に集音性能に満足しています.Bluetoothに対応しているのでiPadと接続して使えるのも便利です.

ディスプレイアーム

Amazon Basicのディスプレイアームです.今までディスプレイアームを使ったことが無かったので試しに買ってみました.ディスプレイの位置を上下や前後に移動できるメリットを実感しています.立ちながら作業するときもアームがあると自由にディスプレイが移動でき最高です.

ディスプレイ

Dellの34インチ ウルトラワイドディスプレイ P3421Wです.Twitterでりっちゃさんがオススメしていたツイートで見つけました.割引率が高く欲しい条件(Type-C対応, 30インチ以上)が揃っていたので衝動でポチりました.ディスプレイアームと組み合わせて使っています.

Dell 34インチ曲面USB-Cモニター:P3421W | Dell 日本

予定では1/7の到着でしたが12/23に届きました.とにかく最高で進捗が爆上がりです.


今年はコロナもあり生産性を向上するためにデスク周りを強化しました.来年はM1搭載のMacBook Airを買う予定です.来年も素敵なガジェットに出会える1年でありますように~!!

draft-ietf-httpbis-cacheを眺めてみた[執筆途中]

IETFのメーリングリストを眺めていたら,httpbis-cacheのdraftの議論があったので眺めてみました.既存のRFC 7234からの変更点(Change Log)で気になったものピックアップしてみました.

この記事では,draft-ietf-httpbis-cache-08の段階での情報を書いています.今後の動向は最新のDraftを確認してください.

C.4. Since draft-ietf-httpbis-cache-02

Warningヘッダの非推奨

In Section 5.5, deprecated “Warning” header field
(https://github.com/httpwg/http-core/issues/139)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

個人的には,こんなヘッダがあることに驚きです.MDNによるとレスポンスヘッダに状況の説明として含めることが想定されているそうです.ヘッダの構造は以下で定義されています.

Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>]

C.5. Since draft-ietf-httpbis-cache-03

リクエストヘッダのキャッシュ制御を削除

Remove requirements around cache request directives
(https://github.com/httpwg/http-core/issues/129)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先のGitHubでも書かれているとおり,リクエストヘッダのキャッシュ制御ヘッダがブラウザやWebサーバ,CDNで無視されている状況から取り除くことになったそうです.

Pragmaヘッダの非推奨

Deprecate Pragma (<https://github.com/httpwg/http-core/issues/140>)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

HTTP/1.1ではCache-Controlヘッダが同様の働きをするので非推奨になったようです.

C.7. Since draft-ietf-httpbis-cache-05

キャッシュ可能メソッドのコンセプトを削除

In Section 3, remove concept of “cacheable methods” in favor of prose (https://github.com/httpwg/http-core/issues/54, https://www.rfc-editor.org/errata/eid5300)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

リンク先の表には,メソッドごとにSafe(安全性), Idempotent(冪等性)の2カラムが存在します.Safeはリクエストのメソッドがリソースの読み取り専用であるか(変更を伴うか)を表しています.Idempotentは,同時に同一のリクエストが複数あった場合と1つあった場合で影響が同一であることを表しています.

MethodSafeIdempotentReference
CONNECTnonoSection 7.3.6
DELETEnoyesSection 7.3.5
GETyesyesSection 7.3.1
HEADyesyesSection 7.3.2
OPTIONSyesyesSection 7.3.7
POSTnonoSection 7.3.3
PUTnoyesSection 7.3.4
TRACEyesyesSection 7.3.8
Table 8
https://httpwg.org/http-core/draft-ietf-httpbis-semantics-latest.html#rfc.section.7.2

7.2ではSafeとIdempotent, Cacheについて触れられているものの,表にはSafeとIdempotentの2つのみ記載がありCacheは省略されていました.以下がGitHubのPull Requestです.

Get rid of “cacheable methods” by mnot · Pull Request #229 · httpwg/http-core

クオートで囲まれたキャッシュ制御ディレクティブの扱い

Change requirements for handling different forms of cache directives in Section 5.2 (https://github.com/httpwg/http-core/issues/128)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.8. Since draft-ietf-httpbis-cache-06

Varyディレクティブが * の場合キャッシュを無効化

In Section 4.1, clarify that any “*” as a member of Vary will disable caching (https://github.com/httpwg/http-core/issues/286)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中

C.9. Since draft-ietf-httpbis-cache-07

明確: 他のキャッシュ要件を無視

In Section 5.2.2.6 and Section 5.2.2.7, make it clear that these directives do not ignore other requirements for caching (https://github.com/httpwg/http-core/issues/320)

https://datatracker.ietf.org/doc/draft-ietf-httpbis-cache/

執筆中