Home » Computer » Archive by category "Software" (Page 2)

擋 Facebook 廣告的 Userscript

Facebook 為了反制各種「擋廣告軟體」,用了各種奇怪的 DOM 在擋:

目前看起來 ublock origin 這類擋廣告軟體支援的格式已經擋不住了,得靠其他工具來擋... 用到現在一直有在更新的「Facebook unsponsored」算是還行... 看 source code 可以看到他是直接抓有顯示的字串來分析,所以不會受到 DOM 的干擾,不過最近看起來又開始被搞了... XD

JPMorgan Chase 的 WePay 用的 MySQL 架構

看到「Highly Available MySQL Clusters at WePay」這篇講 WePayMySQL 的設計,本來以為是 WeChat 的服務,仔細看查了之後發現原來是 JPMorgan Chase 的服務...

架構在 GCP 上面,本來的 MySQL 是使用 MHA + HAProxy (patch 過的版本,允許動態改變 pool),然後用 Routes 處理 HAProxy 的 failover。

他們遇到的問題是 crash failover 需要至少 30 分鐘的切換時間,另外就是在 GCP 上面跨區時會有的 network partition 問題...

後續架構變得更複雜,讓人懷疑真的有解決問題嗎 XDDD

改用 GitHub 推出的 Orchestrator 架構,然後用兩層 HAProxy 導流 (一層放在 client side,另外一層是原來架構裡面的 load balancer),在加上用 Consul 更新 HAProxy 的資訊?

思考為什麼會有這樣設計 (考慮到金融體系的背景),其實還蠻有趣的...

DynamoDB Autoscaling 的各種眉眉角角...

AdRollDynamoDB Autoscaling 的踩雷記錄,裡面有些資訊如果不是跳下去玩應該不會注意到 (魔鬼藏在細節裡的感覺):「Managing DynamoDB Autoscaling with Lambda and Cloudwatch」。

第一個提到的問題是 autoscaling 的觀察對象:

Ideally, the table should scale based on the number of requests that we are making , not the number of requests that are successful.

另外一個是 autoscaling 遇到完全不用的情況下不會 scale down,看起來是某種保護機制。但這使得平常只有拿來讀取的表格在跑完 batch job 後得自己處理 write scale down 問題:

Additionally, at the time of implementing this algorithm, the DynamoDB capacity could not be brought down automatically if the consumption was exactly zero, which can happen if you write to your table in batch instead of realtime, for example.

This meant that, when enabling autoscaling, tables that were read in realtime, but written to in batch, still needed manual intervention to bring the write capacity down after our jobs were done writing.

另外一個問題是 scale down 是有次數限制的:

Another interesting point that might bite users is that capacity decreases are an expensive operation for AWS, so they’re limited.

The number of decreases cited in the documentation can be achieved under very special conditions, since you need to have 4 decreases in the first hour of the day plus one for each of the remaining hours, for a total of 4 (first hour) + 23 (1 hourly) = 27.

後面就是自己研究什麼 algorithm 可以調整的更細,然後用 lambda 重寫... 最後省下 30% 的成本:

Here is where we detected our costs for our batch tables dropping to around 30% of the initial cost.

AdRoll 的規模應該是不小,所以為了省 30% 可以花不少力氣在上面...

看檔案改變的過程

像是這樣的東西:

專案在「pomber/github-history」這邊,目前只支援 GitHub 平台。在選好檔案後,只要把本來網址上的 github.com 改成 github-history.netlify.com 就可以切過去操作了。

主要是看起來頗有趣的,實用性我覺得有點低 XD

GitHub Actions

GitHub 藉著 open source 函式庫,說明了目前還在 beta 的 GitHub Actions 是什麼:「An open source parser for GitHub Actions」。

GitHub Actions 是 GitHub 規劃將自動化設定包裝成設定檔的服務,以往是透過 GitHub 網站上設定,現在則是把這些設定放到 git repository 內。

重點在於 Actions 其實是透過 HCL (HashiCorp Configuration Language) 語法定義:

All Actions workflow files are valid HCL, but not all HCL files are valid workflows.

用關鍵字搜尋 Apple 的 App Store 對不同地區的上架情況

The Intercept 提到了 Apple Censorship 這個站,可以丟關鍵字進去看 app 在不同地區的上架情況:「New Site Exposes How Apple Censors Apps in China」。

預設有美國 (United States) 與中國大陸 (China (mainland)) 當作比較,也可以自己增加地區。除了拿來看 censorship 外 (像是搜尋 vpn 或是 tor),也可以看其他的 app 上架的情況...

整個站其實頗簡單的,是個簡單的 PHP 站台,可以參考 GitHub 上的 greatfire/applecensorship 專案。

Amazon 版的 OpenJDK 8 進入 GA

去年 11 月的時候 AWS 宣佈了要自己維護 OpenJDK 套件的計畫 Amazon Corretto:「AWS 決定花力氣支援 OpenJDK (Corretto 計畫)」,現在這個計畫的 OpenJDK 8 進入 GA (General Availability):「">Amazon Corretto 8 Now Generally Available」。

之前有提到進入 GA 其中一個重點是提供 .rpm.deb 套件安裝,目前可以看到文件已經提供了,不過目前還只能手動下載安裝並更新:「Amazon Corretto 8 Installation instructions for Debian-based and RPM-based Linux distributions」。

與其他版本的差異可以在「Change Log for Amazon Corretto 8」這邊看到 AWS 修改的內容。

Google 也透過同樣機制蒐集使用者的行為

Update:Google 的憑證也被 revoke 了,另外 Facebook 的恢復內部使用的部分了:「Apple blocks Google from running its internal iOS apps」。

昨天是 Facebook 被發現在 iOS 上使用 Enterprise Certificate 取得使用者的行為記錄 (參考「Facebook 花錢向使用者購買他們的行為記錄」),後來 Apple 撤銷了這張 Enterprise Certificate (因為不符合 Enterprise Certificate 的使用條款),並且使得 Facebook 內部符合 Enterprise Certificate 的應用程式都失效。

Google 也被抓出幹同樣的事情,叫做 Screenwise Meter:「Google will stop peddling a data collector through Apple’s back door」。

目前 Google 自己已經下架,但這表示已經有的 spyware 還是會生效,就看 Apple 要不要拔了...

Facebook 花錢向使用者購買他們的行為記錄

這則從 Nuzzel 上看到的,國外討論得很凶:「Facebook pays teens to install VPN that spies on them」。

Facebook 付錢給使用者,要他們安裝 VPN (以及 Root CA,看起來是為了聽 HTTPS 內容),然後從上面蒐集資料,這本身就不是什麼好聽的行為了,但更嚴重的問題在於包括了未成年人:

Since 2016, Facebook has been paying users ages 13 to 35 up to $20 per month plus referral fees to sell their privacy by installing the iOS or Android “Facebook Research” app. Facebook even asked users to screenshot their Amazon order history page. The program is administered through beta testing services Applause, BetaBound and uTest to cloak Facebook’s involvement, and is referred to in some documentation as “Project Atlas” — a fitting name for Facebook’s effort to map new trends and rivals around the globe.

這個計畫在 iOS 平台下架了,但 Android 平台看起來還是會繼續:

[Update 11:20pm PT: Facebook now tells TechCrunch it will shut down the iOS version of its Research app in the wake of our report. The rest of this article has been updated to reflect this development.]

Facebook’s Research program will continue to run on Android. We’re still awaiting comment from Apple on whether Facebook officially violated its policy and if it asked Facebook to stop the program. As was the case with Facebook removing Onavo Protect from the App Store last year, Facebook may have been privately told by Apple to voluntarily remove it.

未成年人部份應該會是重點,拉板凳出來看...

Kubernetes 的失敗案例

有人把 Kubernetes (通常縮寫成「K8S」) 的失敗案例 (轉移失敗、爛掉、...) 整理到 GitHub 上:「Kubernetes Failure Stories」,裡面有文章也有演講影片,然後也有重複的公司在不同時間點說明。

先來講 K8S 好了,如果要粗略的解釋 K8S 是什麼東西,我會說就像是架一組 AWS 服務起來,但是是基於 container 而非 VM。

拿 AWS 的詞彙來說,他在上面疊了一層 Amazon VPC (會對應到 Kubernetes 的 overlay network 與 CNI),然後也提供 AMI (透過 Docker Image) 與 EC2 (因為是比喻,這邊就拿 AMI + EC2 來對比),還有基本的 ELB (各種 NodePort、HostPort 與 Ingress) 與 Service Discovery。

比較特別的是 Pod 的概念,在一般的雲上不太會看到。

不過大致上你可以想像這是一個小型的 AWS,而試著去猜測管理一個小型的 AWS 會需要了解多少底層知識,加上 K8S 一直在發展,很多功能可能都還不成熟 (所以用起來會覺得設計很奇怪),然後上面整理出的失敗案例就不意外了... XD

如果你是自己有機房,或是用便宜的 VPS (像是 LinodeDigitalOceanVultr),那麼我覺得在上面堆 K8S cluster 還算合理,畢竟你可以透過 K8S 幫你整合不少以前得自己架設的服務。

但如果你是已經在 Cloud 上面,然後還想在上面跑 K8S cluster,我是覺得還是要有個理由 (不管是技術上或是政治上的)。如果只是因為 K8S 潮到出水而用的話,可能過一個月後你家就淹水了 XD

另外講一些題外話,因為最近弄 Kubernetes 的關係 (可以參考我的筆記「Kubernetes」),才能理解為什麼 Linode 這些 VPS 會推出 load balancer 與 block storage,算是後知後覺...

Archives