狠狠撸

狠狠撸Share a Scribd company logo
The material contained in this documentation is proprietary and confidential to PIXNET. Copies are made available on the basis that use is limited to the sole purpose of
evaluating PIXNET’s capabilities. It is not permissible to use, modify, copy or disclose any information contained in this presentation document for any other purpose
without the express written permission of PIXNET. If you are not the intended recipient of this material you are requested to take immediate steps to destroy it.
Copyright ? 2018 PIXNET. All rights reserved.
2019.05.15
賴義偉 (Raix Lai)
使用雲端技術打造快速的
AI 服務上線
自我介紹
● 廣盛 NAS 軟體工程師
● Etu 軟體工程師
● 現任 PIXNET 數據工程師
● SRE 讀書會成員
台灣最大社群網站
PIXNET 創立於2003年,2006年成立「優像數位媒體科技股份有限公司」,並於2007年加入城邦媒體控股集團。我們是一間以社群
為核心的科技公司,旗下主要服務包含:痞客邦、PIXgoods、PIXmarketing、PIXinsight,透過創新的數據應用、多樣化社群服務,
實現「Guide to SMART Life」企業核心價值。2018年,PIXNET 推出「全新痞客邦」加速興趣同好彼此凝聚及交流,並持續與產業各
界結盟,踏實建構「社群共榮圈」願景。
PIXNET 研究組
● 團隊組成:
○ 5 位演算法工程師、2 位資料分析師、
1 位數據工程師
● 開發各式 AI 服務和演算法
○ 關鍵字主題分析服務
○ 文章 Tag 搜尋服務
○ Chatbot 數據指令服務
○ 性別年齡預測演算法
○ Spam 文章偵測演算法
○ 個人化文章推薦演算法
○ 部落格圖片辨識演算法
○ 圖片風格轉換演算法
○ 興趣族群演算法
○ ...
開發 AI 服務
沒問題,
請問需要怎樣的機器規格?
預期負載流量是多少?
評估花費成本?
服務要怎麼部署?
服務監控機制?
安全性的設定?
….
早期服務上線
Hi, SRE
我們開發了一套最新的
演算法,需要機器提供
上線服務
Research
Site Reliability Engineer
(SRE)
密切與 SRE 合作
● 機器和服務一起掌控在 SRE 身上
● 溝通和需求確認來回費時
● 開發人員需要對網路系統需要有一定程度的瞭解
● SRE 人員經常處於忙碌狀態,需要的東西難以馬上準備
快則當日,慢則七天
思考加速開發方法
既然都採用了 Google
Cloud Platform,
那有哪些功能可以幫助
加速服務部屬上線?
Deciding between Compute Engine, Container Engine, App Engine and more (Google Cloud Next '17)
GCP 服務比較
學習難度 簡單 中等 困難
部屬難度 中等
根據不同服務需要客製部屬 腳本
簡單
app.yaml 配置好即可
中等
將服務打包 image,配置相關 yaml 檔
服務擴展難度 困難
通訊和資源分配複雜,需仰賴其他工具
簡單
可自動依負載量擴充
中等
可自動依負載量擴充,但受限 worker 容量
SRE 介入程
度
多
安全配置、服務監控、系統管理
幾乎不用
服務完全託管
中等
管理 Kubernters 集群為主
Compute
Engine
App
Engine
Kubernetes
Engine
採用 Kubernetes
斷詞服務
關鍵字
抽取服務
Spam 文章
偵測演算法
主題文章
分析服務
● 資源利用率不佳
○ 開發政策採一個專案就是一座集群
○ 部分服務特性是只有工作時間才有使用
● 特性不熟悉
○ Base Image 過大,服務擴充緩慢
○ 開發階段容易忽略 Container 配置,產生連線或資料儲存的問題
● 部屬流程仍不夠簡潔
問題漸漸冒出
演算法開發
工程師
數據工程師 SRE 服務上線
再次思考加速開發方法
有沒有辦法讓服務開發者
直接部署上線?
App Engine
● 支援主流開發語言
● 應用程式版本管理
● 全代管的環境
● 監控、紀錄與診斷
● 流量拆分
● 服務生態系統
● Standard / Flexible Environment
○ Starndard 適合做快速擴充,沒有流量時自動停機
○ Flexible 適合提供穩定的服務,長時間的回應
案例分享
Tag 集結頁
優化搜尋服務
● 提昇站內搜尋點擊率,為 PIXNET 創造自主流量
● 開發機器學習演算法,從使用記錄中回饋排名
● 大量測試參數,產生大量測試版本
● 每日觀察版本表現,挖掘問題
PIXNET Search Engine 服務架構
如何大量提升Elasticsearch
在雲端上的效能
曾祺元 11:20 101A
ES Cluster
Redis Cluster
API Server
本次分享部分
App Engine API Server
多版本同時上線
● 應用程式版本管理 + 流量拆分 = A/B 測試基礎架構
● 開發快速 + 部屬方便 = 容易產生大量測試版本
● 可同時支撐 15+ 版本上線測試
● 維持每一版程式穩定
○ 要求自動化測試
○ 使用自動化部屬多版本的工具
○ 服務健康監控
Datastudio 觀察數據
● 服務使用紀錄皆儲存至 BigQuery
● Datastudio 串接 BigQuery 呈現每版表現
● 觀察服務中不同面向的數據
○ 熱門文章和作者
○ 關鍵字熱門度
○ 文章排名位置
○ 平均曝光頁數
○ 文章閱讀關聯表
搜尋點擊率
Top 10 熱門關鍵字佔比
Memory Store 緩存資料
● Fully Managed Redis Server
● 部分地區尚未提供服務,採取使用 Compute Engine 建立 Redis Server
● Cache 搜尋結果,加快服務回應
● 需要定時更新 Cache 內容
Composer 更新排程工作建立
● Google Composer (Apache Airflow)
● 有向非循環圖 (DAG) 的方式管理任務流程
● 支援各式 GCP 服務,整合所有資料處理在
同一個任務裡
● 設計每一版 Cache Warmup 工作,結束之
後自動切換流量到新版。
取得新版資訊 Cache Warmup 新版上線切換流量 舊版關閉
RollbackError
Stackdriver 監控服務狀態
● 蒐集和處理 Log
● Error Reporting
○ 自動處理 Error 訊息
○ 追蹤錯誤發生頻率
● 告警指標設置
○ 設定錯誤累積次數
○ 設定平均回應時間
○ 檢查回應是否正常
Error Reporting
Alerting
App Engine API Server
Stackdriver 記錄和處理 log
● Error Reporting
● 設定監控指標和告警
多版本同時上線
● 提供 A/B Testing 框架
● 版本管理方便
● 流量拆分機制
Memstore / Redis
● Cache 機制
● 排程更新工作
BigQuery + Data Studio
● 使用紀錄儲存至BigQuery
● Data Studio 分析數據
結論
● 善用雲端平台提供的服務,節省大量開發和維護成本
● 使用少量人力,做到大量服務和 A/B 測試版本上線
● 打造出可重複利用的服務開發框架,套用到不同專案上
● 開發者直接掌控服務,問題第一時間反應和處理
● 早上開發,下午部署,晚上上線
Q & A
THANK YOU

More Related Content

[2019 臺灣雲端大會]使用雲端技術打造快速的 AI 服務上線