Weekly Selection 2021-01-22

しばらく記事を書き溜めて毎週だしてみる.

Service Meshを紹介する動画

NCSA HTTPd

NCSA HTTPdは世界で二番目のHTTPサーバ.一番目はCERN httpd.

NCSA_HTTPd – Wikipedia

Awesome Storage

分散ファイルシステム(DFS)のことを調べていたら発見.特にCeph, GlusterはKubernetesクラスタのストレージとして検討してみたい.同様の役割としてDRBDがあるが,DRBDはスケーラビリティに課題があるそう.

Awesome Storage – GitHub

SameParty Cookie

TwitterのIntent To Shipを眺めていたら発見した.Prototypeがリリースされるとのこと.以下のリンクのMotivationに導入の背景が説明されていた.

Motivation

In order to increase privacy on the web, browser vendors are either planning or already shipping restrictions on cross-site tracking, such as phasing out third-party cookies. Third-party cookies are currently defined as those associated with a site that is different from the site of the top-level page. However, modern websites are typically served over multiple domains/sites, many of which are owned by the same organization. First-Party Sets provides a mechanism to group domains/sites belonging to the same organization as being same-party with each other, and thus defines a privacy boundary for websites.

出典 https://groups.google.com/a/chromium.org/g/blink-dev/c/-unZxHbw8Pc/m/_23CsOkHAQAJ

日本語で書かれた資料はyukiさんが書かれた以下の記事が分かりやすい.

PHPとRubyとPythonのデータ構造改善

辞書(連想配列)の内部実装が変更された話.Pythonは辞書の順序が変更されたのと同じタイミングだった.

HTTPのバージョン

RFCとHTTPバージョンを整理した図が素晴らしい!

HTTPのバージョンについて、現在のまとめ – Qiita

YAMLのフォーマット

YAMLでは文字列をダブルクオートまたはシングルクオートで囲まないと,意図しない動作をすることが知れた.JSONのほうがStrictではあるが楽になりそう.YAMLパーサーの実装によって,扱いに違いが生じてきそうで怖い.

AWSが生まれたきっかけ

Sunのサーバによるコストを削減するためにHP/Linuxのサーバに乗り換える挑戦をした.大きな賭けが結果的に,大きなコスト削減の成果を生んだ.

AWSが生まれたのは、Amazonが経費削減のためにSunのサーバからHP/Linuxサーバへ切り替えたことがきっかけ。当時の社員が振り返る - Publickey

論文メモ「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年でありますように~!!