Weekly Selection 2021-01-29

T.Koyamaコメントする

one-copy serializability

one-copy xxxは「単一ノードで実現できるxxxを分散ノードでも実現できること」だと分かった．

この場合だと「単一ノードで実現できるシリアライズ可能性を，分散ノードでも維持できる」ということになる．ちなみに元の単語はAWS Auroraの論文で前に見つけた．以下の記事も参考になった．

Eventual Consistencyまでの一貫性図解大全 – Qiita

アンバサダパターンとアダプタパターン(分散システムデザインパターン)

アダプタパターンは，既存のコンテナへ変更を加えることなくインターフェースを変換する．例えば以下は，Redis Containerのslowlogを取得するためにFluentd Containerをアダプタコンテナとして導入している．

Redis向けアダプタパターン

アンバサダパターンは，既存コンテナの機能を補完する役割をもつ．大きなメリットが2つある．1つ目は，モジュール化された再利用できるコンテナをつくれること(関心の分離)である．2つ目は，アンバサダコンテナをほかのアプリケーションコンテナと組み合わせることで再利用しやすいことである．

以下は実験的リリースをアンバサダパターンによって実現した例である．Canary ReleaseではNginx Containerで重み付けロードバランシングにより，部分的リリースを実現している．MirroringではNginx Containerでリクエストをミラーリングすることで，1リクエストをstableとbetaの両サービスへ転送している．

実験的リリース向けアンバサダパターン

PomeriumにTCP forwarding over HTTPが追加

CNCFに参加しているIAPであるPomeriumにTCP Forwarding over HTTPが追加された．これを使うことでSSHやRDPをはじめとするTCPベースのプロトコルをIAP経由で使える．この機能はGoogle Cloud IAP では既に実現されていたのでOSSで実装されたのはおそらく初めてだろう．

Nginxはthread_poolを使っている

前に調べて忘れていたので読み直した．Apache HTTP ServerのC10K問題をなぜ解決できたのか？の答えでもある．

Thread Pools in NGINX Boost Performance 9x!

ソフトウェアにおけるログの設計

出力するログの内容や形式をはじめとする詳細が触れられた記事でよかった．処理の終わった段階でログを出力するのは参考にしたい．

ログレベルを複数人で開発するときに揃えるのが難しいと思った．JSONで構造化したログもスキーマの制約を入れないと，ログを解析するときに苦労しそうだと思った．ログの内容をいかに解析しやすい形式にするかは，課題になりそうだと思った．このあたりは共通ログライブラリを作り込むのがベターかもしれない．

ログを出力するにはどうするか？

NAT Slipstream 2.0 attack

ChromiumのメーリスにHTTP Port BlockingがIntent to shipになっていたので気になった．これはNAT Slipstreaming 2とよばれる脆弱性の対策として導入されるという．これはNAT配下に存在する端末へ外部からアクセスが可能になる脆弱性だ．NAT配下の端末でP2Pをおこなうために，WebRTCでホールパンチをしていたことを思い出した．境界セキュリティも限界があるように感じた．

Connections to HTTP, HTTPS or FTP servers on ports 69, 137, 161, 1719, 1720, 1723 or 6566 will fail. This is a mitigation for the NAT Slipstream 2.0 attack: https://www.armis.com/resources/iot-security-blog/nat-slipstreaming-v2-0-new-attack-variant-can-expose-all-internal-network-devices-to-the-internet/. It helps developers by keeping the web platform safe for users.

This security fix has already shipped in version 87.0.4280.117. This intent has been delayed until the vulnerability was publicly disclosed.

Intent to Implement and Ship: Block HTTP ports 69, 137, 161, 1719, 1720, 1723, and 6566

さっそくyukiさんが記事をかかれていてスピードに驚いた…

分散ストレージと分散ファイルシステム

研究室のオンプレ環境にHA構成なKubernetesクラスタを構築しようと思い，分散ストレージと分散ファイルシステムを調べた．以下の資料がかりやすい．

Kubernetesの永続化ストレージ基礎 – Speaker Deck

分散ストレージと分散ファイルシステムの違いがわからなかたので，以下に整理した．ポンチ絵がうまく出来たか微妙だが，ひとまずリリースしておく．

ポンチ絵

分散ストレージシステム SDS(Software Defined Storage)は次の特徴をもつ．

  • OSからデバイスとして認識される．
  • ファイルシステムの構築が必要になる．

分散ファイルシステム DFS(Distributed File System)は次の特徴をもつ．

  • 専用のドライバでOS上にマウントされる．
  • ファイルシステムの構築が不要である．

参考資料 ウマいストレージの選び方。 – Qiita

Weekly Selection 2021-01-22

T.Koyamaコメントする

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

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」

T.Koyamaコメントする

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が分からない

T.Koyamaコメントする

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

  • 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システムを構築、維持するためにやれることはなにか」

T.Koyamaコメントする

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はクラウド事業者なので，簡単に使えることを優先しているのではないか?と思った．