紐約時報如何將遊戲平台搬遷到 Google App Engine

「紐約時報」填字遊戲自從1942年開始出版以來，一直是很多人日常生活中不可或缺的一部分。1996年「紐約時報」建立了第一個網站時，數位版的填字遊戲很快就成為一個獨立出來的數位產品。雖然填字遊戲最初是基於 Web 的 Java applet 來構建的，但它已經發展成為一套行動應用程式和一個擁有超過 30 萬付費用戶的完全互動的網站。 為了向眾多玩家提供拼圖的數據，並同時要處理進階功能，例如在多個裝置上同步遊戲進度，紐約時報的後端系統運行在 Amazon Web Services 上，並採用了類似LAMP的架構。 然而在 2014 年 8 月推出的免費每日迷你填字遊戲，為紐約時報帶來了更多的玩家，這讓系統架構帶來了很大的壓力。

隨著填字遊戲越來越流行，紐約時報的系統架構在處理遊戲流量方面面臨規模上的限制。 由於系統中有被遺留下來的非彈性架構，導致需要在晚上10點發布每日難題時，將系統架構的規模擴大以處理高峰流量。 這些遺留下來的架構依賴於一定程度的人機交互的技術，可能需要數小時才能夠在規模上擴展和縮減。 然而這必須要在幾分鐘內擴展，而這個系統一般在一天內只有幾分鐘的高峰期，所以這種設置對於「紐約時報」的團隊來說是非常昂貴的。 因此，紐約時報決定將所有產品開發轉移到Google雲端平台，GCP 不僅有多樣的工具可以協助用戶節省成本，也更快地把資源轉移過去。

在購買Google產品套件後，紐約時報決定使用 Go語言、Google App Engine、Datastore、BigQuery、PubSub、Container Engine 來重建系統。而這篇文章將專注於整個系統中的核心 – App Engine。

該平台自2008年起提供平台即服務（PaaS），將 Web 服務器的大部分內部工作抽離出來，讓開發人員可以專注於編寫代碼來解決業務問題。 以下是幾個值得強調的重點：

⬩ 本地端開發：Google 提供了一個 SDK，讓用戶能夠使用一個指令就能運行一整套服務以及管理界面、資料庫和緩存層。

⬩ 聯合訪問和應用程式 log：使用平台已經提供好的日誌記錄庫，開發人員能夠在平台連接到伺服器訪問的時候，編寫應用程式 log 並會把 log 記錄在 Google 的雲端 log 界面上。因為可以清楚看到在已知請求中發生的事情，這個服務大大地簡化了 debug 系統時的操作。

上圖顯示了由填字遊戲板更新而生成的 application logs。

⬩ 監控/警報：要可靠地啟動任何系統，開發人員需要深入了解其系統的性能。在沒有任何額外的配置下，平台將會追蹤回應延遲、錯誤率、網絡使用率、內存、CPU 使用率等等的資訊，而這一切都透過可以基於測量數據來設置警報的 Stackdriver 儀表板來顯示。

⬩ 用戶身份驗證：只要添加單單一行到服務配置，開發人員就可以強制用戶使用其Google 憑證來進行身份驗證。 Google也可以處理特定的憑證，因此整個服務僅面向選定的受眾群體。

⬩ HTTPS / DNS：將服務部署到應用程式引擎後，即可在互聯網上立即啟用 HTTPS，類似於“https://{服務名稱} -dot- {專案名稱} .appspot.com“。 這使開發人員只需花費幾分鐘就可以把概念轉轉化成可以分享的prototype。

⬩ PubSub 推送訂閱：只要將新消息傳送到訂閱，Google的PubSub服務就可以被設定成發送到HTTP端點。 傳統上這會要求開發人員額外添加一層的安全層，但 Google App Engine 可以為你處理。 在這個概念下，可以輕鬆地將大型工作負載分散到一組服務器上以方便執行離線項目，如個人統計計算和將批量數據加載到BigQuery中。

儘管大部分正在重新引入進去 App Engine 的功能似乎有點神奇，但是裡面一些開箱即用的功能並不能滿足紐約時報的需求，不過紐約時報找到了解決方式，可能對正在考慮使用 App Engine 的其他團隊會有幫助。

⬩ 部署工具：Google確實提供了一些優秀的工具來將代碼版本化並部署到 App Engine 上，但在這個專案中，紐約時報選擇使用 Drone CI，它並沒有現成的插件，所以紐約時報開發了一個能夠與 Drone 和 App Engine 互相溝通的開源插件。

⬩ API安全性：雖然 App Engine 的用戶身份驗證十分好用，但在使用其他服務驗證的時候就有點困難。 Google 的 Cloud Endpoints 產品仍不適用於 App Engine 和 Go語言，因此紐約時報將邏輯添加到了白名單 IP 地址的服務裡面，以限制對非生產環境的訪問。 對於從一個 App Engine 服務到另一個 App Engine 服務的內部請求，可以依賴於不可偽造的HTTP標頭。 期待未來能夠在 App Engine 中依靠 Google 的 OAuth 工具。

⬩ Auto Scaling：Auto Scaling是App Engine的其中一個優點，但在晚上10點的流量高峰期，它確實仍存在一些問題，您可以在下圖中看到。

這個圖表顯示了超過7天的遊戲 API 流量， 可以注意到的是，在平日晚上的時段出現了高低起伏的波幅。

由於紐約時報的流量高峰是可預期的，所以最後透過添加一個 cron 來解決這個問題，以便在系統升級之前的短時間內，還有在流量縮減到正常水平之後，在服務中創建一個特殊的端點專門來處理。 此特殊端點可以透過 App Engine 的管理 API 快速添加或者減少額外的空閒個體，以處理流量的短暫性增加。

儘管紐約時報才剛把服務搬遷到 GCP 上不久，但是他們所有遊戲的 API 流量都已經在App Engine 中流動，而當中有 90％的流量只純粹由 App Engine 服務和 GCP 資料庫提供服務。

如果沒有 Google 和 App Engine 提供的工具和模組化，僅有三人的紐約時報工程師團隊就無法實現這一項成就。 除了能夠快速轉移到更加可靠的平台之外，在這段時間內，他們更設法將基礎的系統架構成本降低了一半。 隨著遊戲的不斷發展，紐約時報無疑地做出了正確的選擇，讓他們能夠輕鬆地實驗迭代跟規模縮減的操作。

更多 GCP 案例：https://blog.gcp.expert/google-cloud-pokemon/
(原文翻譯自：https://open.nytimes.com/moving-the-new-york-times-games-platform-to-google-app-engine-e9337f2c9444)