one-copy serializability
one-copy xxxは「単一ノードで実現できるxxxを分散ノードでも実現できること」だと分かった．
この場合だと「単一ノードで実現できるシリアライズ可能性を，分散ノードでも維持できる」ということになる．ちなみに元の単語はAWS Auroraの論文で前に見つけた．以下の記事も参考になった．
Eventual Consistencyまでの一貫性図解大全 – Qiita
アンバサダパターンとアダプタパターン(分散システムデザインパターン)
アダプタパターンは，既存のコンテナへ変更を加えることなくインターフェースを変換する．例えば以下は，Redis Containerのslowlogを取得するためにFluentd Containerをアダプタコンテナとして導入している．
アンバサダパターンは，既存コンテナの機能を補完する役割をもつ．大きなメリットが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問題をなぜ解決できたのか？の答えでもある．
ソフトウェアにおけるログの設計
出力するログの内容や形式をはじめとする詳細が触れられた記事でよかった．処理の終わった段階でログを出力するのは参考にしたい．
ログレベルを複数人で開発するときに揃えるのが難しいと思った．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上にマウントされる．
- ファイルシステムの構築が不要である．
コメントを残す