ref: https://ably.com/blog/no-we-dont-use-kubernetes
八月第一篇,就來個有趣的文章,來看看 ably 這間 SaaS 公司為什麼沒有使用 Kubernetes,不但當前沒有使用,甚至短期未來內都不會想要使用
更是直接的說如果你有興趣來加入團隊,千萬不要把將 Kubernetes 導入到團隊中是一個可能發生的事情。
我個人覺得這篇文章滿好的,因為是認真的去比較導入 Kubernetes 帶來的改變,而這些改變對團隊來說到底是可接受還是不可接受
而不是所謂的人云亦云,人家要我也要,人家不要我也不要...
文章分成兩部分,前述介紹當前 Ably 的環境架構是什麼,而半部分則是很技術的去探討如果導入 Kubernetes 帶來的好處與壞處是什麼
最終權衡比較之下,會發現導入 Kubernetes 沒有帶來實質上的好處。
文章開頭先簡述了一下 Kubernetes 這幾年的風潮,從最初 Google Borg 的開發開始談起,作者特別提到當初 Borg 的用法可是將一堆實體機器給搭建出一個 Private Cloud 的叢集給團隊使用,
而目前 Kubernetes 更多的用法則是搭建於 Public Cloud 上面的虛擬機器中,透過將 Kubernetes 部署到這些不同的 Cloud Provider 似乎帶來了介面統一的結果,對於 DevOps 人員來說
不同 Cloud Provider 如今看起來都是 Kubernetes 的樣貌。
Ably 目前到底怎麼部署應用程式
Ably 主要使用 AWS 作為其 Cloud Provider,並且於 EC2 機器上使用 docker/container 來部署團隊中的應用程式。
作者團隊中沒有使用任何已知的 Orchestration 服務來管理多節點上的 docker/container,取而代之的則是每個 VM 開機後則會根據 autoscaling group 的機制來判斷
每個機器應該要部署哪種 container/docker。
對於 Ably 來說,團隊中沒有任何 scheduler 相關的服務來調度各種服務,這意味每個 VM 就代表一種服務,所以將 VM 上的服務從 Core 轉換成 frontend 這種行為不會發生。
今天需要針對需求轉換服務時就以 VM 為基準來整批換掉即可。
每個節點上面都會有一個輕量的監控服務,用來確保運作的 Container 如果掛掉後可以被重啟,甚至如果當前運行的版本不符合需求時也能夠將該服務給停止。
流量方面,因為每個 Autoscaling Group 就代表一個服務,所以直接使用 NLB 與 Target Group 來將流量導入該 Autoscaling Group 即可。
至於容器與容器之間的內部流量(譬如 k8s service 等)作者認為也不是太大問題,畢竟每個機器本身都會被 VPC 賦予一個 IP 地址,所以使用上沒有什麼太大的問題。
接下來作者從幾個層次去探討當前設計與使用 Kubernetes 帶來的改變,分別有 (原文很多,這邊摘要不然文章會太長)
題外話,由於 Ably 的 Infra Team 數量有限,所以要考慮 K8s 只會考慮 K8s Service,如 EKS。
1. Resource Management
Ably:
a. 根據服務的需求來決定每個服務要用到的 VM 等級
b. 不需要去煩惱如何處理將多個小服務給部署到一個適合的大 VM 中
c. 作者稱這種行為其實就是 AWS 官方強調的 Right Sizing, 譬如只能跑兩個 Thread 的服務不需要 16vCPUs, 久久寫一次硬碟的服務也不需要一個 90,000 IOPS 的 SSD
d. 選擇一個正確的元件來搭建一個符合服務的 VM 讓團隊可以控制成本同時也減少額外的管理負擔
K8s:
a. 必須要使用一個比較強大等級的 EC2 VM,畢竟上面要透過 Container 部署很多服務
b. 針對那些需要小資源的服務來說,透過這種方式能夠盡可能的榨乾機器的資源,整體效能使用率會更好
c. 但是針對資源量沒有很辦法明確定義的服務則是會盡可能地去吃掉系統上的資源,這種被稱為 nosy neighbors 的常見問題已經不是首次出現了, Cloud Provider 本身就需要針對 VM 這類型的服務去思考如何處理資源使用,而 Cloud Provider 都有十年以上的經驗再處理這一塊
而所有 Kubernetes 的使用者則必須要自己去處理這些。
d. 一個可能的作法則是一個 VM 部署一個服務,不過這個做法跟團隊目前的作法已經完全一致,所以就資源管理這一塊,團隊看不到使用 Kubernetes 的優勢。
2. Autoscaling
Ably:
a. EC2 VM 本身可以藉由 Autoscaling Group 來動態調整需求
b. 有時候也是會手動的去調整 EC2 的數量,基本上手動跟自動是互相輔佐的
c. 團隊提供的是 SaaS 服務,所以其收費是針對客戶實際上用多少服務來收,如果開了過多 EC2 VM,則很多不要的花費與開銷都是團隊要自行吸收
d. 團隊需要一個盡可能有效率的方式能夠即使遇到流量暴衝時也能夠保證良好的服務的機制
K8s:
a. 可以透過不少方式來動態調整 Container 的數量,
b. 甚至可以透過 Cluster autoscaler 來針對節點進行調整,根據需求關閉節點或是產生更多節點
c. 動態關閉節點的有個問題是關閉節點時通常會選擇盡可能閒置的節點,但是閒置並不代表沒有任何服務部署再
上面,因此該節點上的 Container 都要先被轉移到其餘節點接者該目標節點才可以被正式關閉。這部分的邏輯作者認為相對複雜
d. 整體來說,k8s 有兩個動態調整的部分,動態節點與動態服務,而現有的架構只有一個動態節點。所以使用 k8s 則會讓問題變得更多更複雜。
3. Traffic Ingress
Ably:
a. Traffic Ingress 基本上每個 cloud provider 都提供了很好的解決方案,基本上團隊只要能夠維持每個服務與背後的機器的關係圖,網路流量基本上都沒有什麼需要團隊管理的。
b. 使用者會透過直接存取 NLB 或是透過 CloudFront 的方式來存取團隊內的服務
K8s:
a. EKS 本身可以透過 AWS VPC CNI 使得每個 Container 都獲得 VPC 內的 IP,這些 IP 都可以讓 VPC 內的其他服務直接存取
b. 透過 AWS LB Controller,這些 Container 可以跟 AWS LB 直接整合,讓封包到達 LoadBalancer 後直接轉發到對應的 Container
c. 整體架構並不會比團隊目前架構複雜
d. 唯一缺點大概就是這個解決方案是完全 AWS 綁定,所以想要透過 k8s 來打造一個跨 Cloud Provider 的統一介面可能就會遇到不好轉移的問題。
4. DevOps
Ably:
a. 開發團隊可以透過簡單的設定檔案來調整部署軟體的版本,後續相關機制就會將 VM 給替換掉,然後網路流量也會自然的導向新版服務
K8s:
a. 開發團隊改使用 Kubernetes 的格式來達到一樣的效果,雖然背後運作的方式不同但是最終都可以對開發團隊帶來一樣的效果。
上次四個分析基本上就是,使用 k8s 沒有帶來任何突破性的好處,但是 k8s 本身還有其他的功能,所以接下來作者想看看 k8s 是否能夠從其他方面帶來好處
Multi-Cloud Readiness
作者引用兩篇文章的內容作為開頭,「除非經過評估,否則任何團隊都應該要有一個跨 Cloud-Provider 的策略」
作者表明自己團隊的產品就是那個經過評估後斷言不需要跨 Cloud Provider 策略的團隊,同時目前沒有往這個方向去追求的打算。
同時作者也不認為 K8s 是一個能夠有效達成這個任務的工具。舉例來說,光 Storage 每家的做法都不同,而 K8s 沒有辦法完全將這些差異性給抽象畫,這意味者開發者終究還是要針對這些細節去處理。
Hybrid Cloud Readiness
管理混合雲(Public Cloud + Private Cloud based on Bare-Metal servers)是作者認為一個很合理使用 K8s 的理由,畢竟這種用法就跟當初 Google Borg 用法一致,是經過驗證可行的。
所以 Ably 如果有計畫要維護自己的資料中心時,底層就會考慮使用 Kubernetes 來管理服務。畢竟這時候沒有任何 Cloud Provider 提供任何好像的功能。
不過 Ably 目前沒有任何計畫,所以這個優點也沒有辦法幫助到團隊
Infrastructure as Code
團隊已經大量使用 Terraform, CloudFormation 來達成 IaC,所以透過 k8s YAML 來維護各種架構不是一個必要且真的好用的方式。
Access to a large and active community
另外一個很多人鼓吹 K8S 的好處就是有龐大的使用者社群,社群內有各種問題分享與探討。
作者認為
a. AWS 的使用者社群數量是高於 Kubernetes
b. 很多情況下,一個迭代太快速的產品其實也不一定對團隊有太大的幫助。
c. 很多人都使用 k8s,但是真正理解 k8s 的人微乎其微,所以想要透過社群來幫忙解決問題其實比你想像的還要難,畢竟裡面的問題太雜,很多時候根本很難找到一個真正有效的答案。
Added Costs of Kubernetes
為了轉移到 K8s, 團隊需要一個全新的 team 來維護 k8s 叢集以及使用到的所有基本服務。舉例來說,EKS, VPN CNI, AWS LB 帶來的網路好處並不是啟動 EKS 就會有的,
還必須要安裝相關的 Controller 並且進行設定,這些都是額外的維運成本。
如果找其他的服務供應商來管理 Kubernetes,這意味公司就要花費更多的$$來處理,所以對團隊來說,金錢與工作量都會提高,不同的解決方式只是這兩個指標的比例不同而已。
結論:
1. Ably 覺得 Kubernetes 做得很好,但是團隊目前沒有任何計畫去使用它,至少目前這階段沒有看到任何實質好處
2. 仔細評估後會發現,導入 k8s 其實也會帶出不少管理上的問題,反而並沒有減輕本來的負擔
同時也有10000部Youtube影片,追蹤數超過2,910的網紅コバにゃんチャンネル,也在其Youtube影片中提到,...
監控 硬 碟 缺點 在 台灣物聯網實驗室 IOT Labs Facebook 的最佳解答
迎接終端AI新時代:讓運算更靠近資料所在
作者 : Andrew Brown,Strategy Analytics
2021-03-03
資料/數據(data)成長的速度越來越快。據估計,人類目前每秒產出1.7Mb的資料。智慧與個人裝置如智慧型手機、平板電腦與穿戴式裝置不但快速成長,現在我們也真正目睹物聯網(IoT)的成長,未來連網的裝置數量將遠遠超越地球的人口。
這包括種類繁多的不同裝置,像是智慧感測器與致動器,它們可以監控從震動、語音到視覺等所有的東西,以及幾乎大家可以想像到的所有東西。這些裝置無所不在,從工廠所在位置到監控攝影機、智慧手錶、智慧家庭以及自主性越來越高的車輛。隨著我們企圖測量生活週遭數位世界中更多的事物,它們的數量將持續爆炸性成長。
資料爆量成長,讓許多企業把資料從內部部署運作移到雲端。儘管集中到雲端運算的性質,在成本與資源效率、彈性與便利性有它的優點,但也有一些缺點。由於運算與儲存在遠端進行,來自終端、也就是那些在網路最邊緣裝置的資料,需要從起始點經過網際網路或其他網路,來到集中式的資料中心(例如雲端),然後在這裡處理與儲存,最後再傳回給用戶。
對於一些傳統的應用,這種方式雖然還可以接受,但越來越多的使用場景就是無法承受終端與雲端之間,資訊被接力傳遞產生的延遲。我們必須即時做出決策,網路延遲要越小越好。基於這些原因,開始有人轉向終端運算;越來越多人轉而使用智慧終端,而去中心化的程度也越來越高。此外,在這些即時應用中產生的龐大資料量,意味著處理與智慧必須在本地以分散的方式進行。
與資料成長連袂而來的,是人工智慧與機器學習(ML)也朝終端移動,並且越來越朝終端本身移動。大量來自真實世界的資訊,需要用ML的方式來進行詮釋與採取行動。透過AI與ML,是以最小的延遲分析影像、動作、影片或數量龐大的資料,唯一可行且合乎成本效益的方式。運用AI與ML的演算法與應用將在邊緣運作,在未來還將會直接在終端裝置上進行。
資料正在帶動從集中化到分散化的轉變
隨著資訊科技市場逐漸發展與成熟,網路的設計以及在其運作的所有裝置,也都跟著進化。全盛時期從服務數千個小型客戶端的主機,一直到客戶端伺服器模型中使用的越來越本地化的個人電腦運算效能,基礎架構持續重組與最佳化,以便更貼近網路上的裝置以及符合運作應用的需求。這些需求包含檔案存取與資料儲存,以及資料處理的需求。
智慧型手機與其他行動裝置的爆炸性成長,加上物聯網的快速成長,促使我們需要為如何讓資產進行最佳的部署與安排進行評估。而影響這個評估的因素,包括網路的可用性、安全性、裝置的運算力,以及把資料從終端傳送到儲存設備的相關費用,近來也已轉向使用分散式的運算模型。
從邊緣到終端:AI與ML改變終端典範
在成本、資源效率、彈性與便利性等方面,雲端有它的優點,裝置數量的急遽增加(如圖2),將導致資料產出量大幅增加。這些資料大部份都相當複雜且非結構化的,這也是為何企業只會分析1%~12% 的資料的原因之一。把大量非結構化的資料送到雲端的費用相當高、容易形成瓶頸,而且從能源、頻寬與運算力角度來看,相當沒有效率。
在終端執行進階處理與分析的能力,可協助為關鍵應用降低延遲、減少對雲端的依賴,並且更好地管理物聯網產出的巨量資料。
終端AI:感測、推論與行動
在終端部署更多智慧的主要原因之一,是為了創造更大的敏捷性。終端裝置處於網路的最邊緣與資料產生的地方,可以更快與更準確地做出回應,同時免除不必要的資料傳輸、延遲與資料移動中的安全風險,可以節省費用。
處理能力與神經網路的重大進展,正協助帶動終端裝置的新能力,另一股驅動力則是對即時資訊、效率(傳送較少的資訊到雲端)、自動化與在多數情況下,對近乎即時回應的需求。這是一個三道步驟的程序:傳送資料、資料推論(例如依據機器學習辨識影像、聲音或動作),以及採取行動(如物件是披薩,冰箱的壓縮機發出正常範圍外的聲音,因此發出警告)。
感測
處理器、微控制器與感測器產生的資料量相當龐大。例如,自駕車每小時要搜集25GB的資料。智慧家庭裝置、智慧牙刷、健身追蹤器或智慧手錶持續進化,並且與以往相比,會搜集更多的資料。
它們搜集到的資料極具價值,但每次都從各個終端節點把資料推回給雲端,數量又會過多。因此必須在終端進行處理。倘若部份的作業負載能在終端本身進行,就可以大幅提升效率。
推論
終端搜集到的資料是非結構性的。當機器學習從資料擷取到關聯性時,就是在進行推論。這表示使用AI與ML工具來幫忙訓練裝置辨識物件。拜神經網路的進展之賜,機器學習工具越來越能訓練物件以高度的精準度辨識影像、聲音與動作,這對體積越來越小的裝置,極為關鍵。
例如,圖4顯示使用像ONNX、PyTorch、Caffe2、Arm NN或 Tensorflow Lite 等神經網路工具,訓練高效能的意法半導體(ST)微控制器(MCU),以轉換成最佳化的程式碼,讓MCU進行物件辨識(這個的情況辨識對象是影像、聲音或動作)。更高效能的MCU越來越常利用這些ML工具來辨識動作、音訊或影像,而且準確度相當高,而我們接下來馬上就要對此進行檢視。這些動作越來越頻繁地從邊緣,轉移到在終端運作的MCU本身。
行動
資料一旦完成感測與推論後,結果就是行動。這有可能是回饋簡單的回應(裝置是開啟或關閉),或針對應用情況進行最佳化(戴耳機的人正在移動中,因此會針對穩定度而非音質進行最佳化),或是回饋迴路(根據裝置訓練取得的機器學習,輸送帶若發出聲音,顯示它可能歪掉了)。物聯網裝置將會變得更複雜且更具智慧,因為這些能力提升後,運算力也會因此增加。在我們使用新的機器學習工具後,一些之前在雲端或終端完成的關鍵功能,將可以移到終端本身的內部進行。
終端 AI:千里之行始於足下
從智慧型手機到車輛,今日所有電子裝置的核心都是許多的處理器、微控制器與感測器。它們執行各種任務,從最簡單到最複雜,並需要各式各樣的能力。例如,應用處理器是高階處理器,它們是為行動運算、智慧型手機與伺服器設計;即時處理器是為例如硬碟控制、汽車動力傳動系統,與無線通訊的基頻控制使用的非常高效能的處理器,至於微控制器處理器的矽晶圓面積則小了許多,能源效率也高出很多,同時擁有特定的功能。
這意味著利用ML工具訓練如MCU等較不複雜元件來執行的動作,之前必須透過威力更強大的元件才能完成,但現在邊緣與雲端則是理想的場所。這將讓較小型的裝置以更低的延遲執行更多種類的功能,例如智慧手錶、健康追蹤器或健康照護監控等穿戴式裝置。
隨著更多功能在較小型的終端進行,這將可以省下資源,包括資料傳輸費用與能源費用,同時也會產生極大的環境衝擊,特別是考量到全球目前已有超過200億台連網裝置,以及超過2,500億顆MCU(根據Strategy Analytics統計數據)。
TinyML、MCU與人工智慧
根據Google的TesnsorFlow 技術主管、同時也是深度學習與TinyML領域的指標人物 Pete Warden 表示:「令人相當興奮的是,我還不知道我們將如何使用這些全新的裝置,特別是它們後面代表的科技是如此的吸引人,我無法想像那些即將出現的全新應用。」
微型機器學習(TinyML)的崛起,已經催化嵌入式系統與機器學習結合,而兩者傳統上大多是獨立運作的。TinyML 捨棄在雲端上運作複雜的機器學習模型,過程包含在終端裝置內與微控制器上運作經過最佳化的模式識別模型,耗電量只有數毫瓦。
物聯網環境中有數十億個微型裝置,可以為各個產業提供更多的洞察與效率,包括消費、醫療、汽車與工業。TinyML 獲得 Arm、Google、Qualcomm、Arduino等業者的支持,可望改變我們處理物聯網資料的方式。
受惠於TinyML,微控制器搭配AI已經開始增添各種傳統上威力更強大的元件才能執行的功能。這些功能包括語音辨識(例如自然語言處理)、影像處理(例如物件辨識與識別),以及動作(例如震動、溫度波動等)。啟用這些功能後,準確度與安全性更高,但電池的續航力卻不會打折扣,同時也考量到各種更微妙的應用。
儘管之前提到的雲端神經網路框架工具,是取用這個公用程式最常用的方法,但把AI函式庫整合進MCU,然後把本地的AI訓練與分析能力插入程式碼中也是可行的。這讓開發人員依據從感測器、麥克風與其他終端嵌入式裝置取得的訊號導出資料模式,然後從中建立模型,例如預測性維護能力。
如Arm Cortex-M55處理器與Ethos U55微神經處理器(microNPU),利用CMSIS-DSP與CMSIS-NN等常見API來簡化程式碼的轉移性,讓MCU與共同處理器緊密耦合以加速AI功能。透過推論工具在低成本的MCU上實現AI功能並符合嵌入式設計需求極為重要,原因是具有AI功能的MCU有機會在各種物聯網應用中轉變裝置的設計。
AI在較小型、低耗電與記憶體受限的裝置中可以協助的關鍵功能,我們可以把其精華歸納至我們簡稱為「3V」的三大領域:語音(Voice,如自然語言處理)、視覺(Vision,如影像處理)以及震動(Vibration,如處理來自多種感測器的資料,包括從加速計到溫度感測器,或是來自馬達的電氣訊號)。
終端智慧對「3V」至關重要
多數的物聯網應用聚焦在一些特定的領域:基本控制(開/關)、測量(狀態、溫度、流量、噪音與震動、濕度等)、資產的狀況(所在地點以及狀況如何?),以及安全性功能、自動化、預測性維護以及遠端遙控(詳見圖 6)。
Strategy Analytics的研究顯示,許多已經完成部署或將要部署的物聯網B2B應用,仍然只需要相對簡單的指令,如基本的開/關,以及對設備與環境狀態的監控。在消費性物聯網領域中,智慧音箱的語音控制AI已經出現爆炸性成長,成為智慧家庭指令的中樞,包括智慧插座、智慧照明、智慧攝影機、智慧門鈴,以及智慧恆溫器等。消費性裝置如藍牙耳機現在已經具備情境感知功能,可以依據地點與環境,在音質優先與穩定度優先之間自動切換。
如同我們檢視的結果,終端AI可以在「3V」核心領域提供價值,而它觸及的許多物聯網領域,遍及B2B與B2C的應用:
震動:包含來自多種感測器資料的處理,從加速計感測器到溫度感測器,或來自馬達的電氣訊號。
視覺:影像與影片辨識;分析與識別靜止影像或影片內物件的能力。
語音:包括自然語言處理(NLP)、瞭解人類口中說出與寫出的語言的能力,以及使用人類語言與人類交談的能力-自然語言產生(NLG)。
垂直市場中有多種可以實作AI技術的使用場景:
震動
可以用來把智慧帶進MCU中的終端AI的進展,有各式各樣的不同應用領域,對於成本與物聯網裝置與應用的效用,都會帶來衝擊。這包括我們在圖6中點出的數個關鍵物聯網應用領域,包括:
溫度監控;
壓力監控;
溼度監控;
物理動作,包括滑倒與跌倒偵測;
物質檢測(漏水、瓦斯漏氣等) ;
磁通量(如鄰近感測器與流量監控) ;
感測器融合(見圖7);
電場變化。
一如我們將在使用場景單元中檢視的,這些能力有許多可以應用在各種被普遍部署的物聯網應用中。
語音
語音是進化的產物,也是人類溝通非常有效率的方式。因此我們常常想要用語音來對機器下指令,也不令人意外;聲音檢測是持續成長的類別。語音啟動在智慧家庭應用中很常見,例如智慧音箱,而它也逐漸成為啟動智慧家庭裝置與智慧家電的語音中樞,如電視、遊戲主機與其他新的電器。
在工業環境中,供車床、銑床與磨床等電腦數值控制(CNC)機器使用的電腦語音引擎正方興未艾。iTSpeex的ATHENA4是第一批專為這些產品設計的語音啟動作業系統。這些產品往往因為安全原因,有離線語音處理的需求,因此終端 AI 語音發展在這裡也創造出有趣的機會。用戶可以指示機器執行特定的運作,並從機器手冊與工廠文件,立即取用資訊。
語音整合在車輛中也相當關鍵。OEM 代工廠商持續對車載娛樂系統中的語音辨識系統,進行大量投資。語音有潛力成為最安全的輸入模式,因為它可以讓駕駛的眼睛持續盯著道路,而雙手仍持續握著方向盤。
對於使用觸控螢幕或硬體控制器通常需要多道步驟的複雜任務,語音辨識系統特別能勝任。這些任務包括輸入文字簡訊、輸入目的地、播放特定歌曲或歌曲子集,以及選擇廣播電台頻道。其他的服務包含如拋錨服務(或bCall)與禮賓服務。
視覺
正如我們之前已經檢視過,終端 AI 提供視覺領域全新的機會,特別是與物件檢測及辨識相關。這可能包括觀察生產線的製造瑕疵,以及找出自動販賣機需要補貨的庫存。其他實例包括農業應用,例如依據大小與品質為農產品分級。
曳引機裝上機器視覺攝影機後,我們幾乎可以即時檢測出雜草。雜草冒出後,AI可以分類雜草並估算它對農產收穫的潛在威脅。這讓農民可以鎖定特定的雜草,並打造客製的除草解決方案。機器視覺然後可以檢測除草劑的效用,並找出農地中仍具抗藥性的殘餘雜草。
使用場景
預測性維護工具已經從擷取與比較震動的量測資料,進化到提出即時的資產監控。藉由連接物聯網感測器裝置與維護軟體,我們也可能做到遠端監控。
震動分析
這種類型的預測性維護在旋轉型機器密集的製造工廠裡,相當常見。震動分析可以揭露鬆脫、不平衡、錯位與軸承磨損等狀況。例如,把震動計量器接上靠近選煤廠離心泵浦內部承軸處,就可以讓工程師建立起正常震動範圍的基線。超出這個範圍的震動,可能顯示滾珠軸承出現鬆動,需要更換。
磁感測器融合
磁感測器利用磁性浮筒與一系列可以感應並與液體表面一起移動的感測器,測量液面的高低。所有的這些應用都使用一個固定面上的磁感測器,它與附近平面的磁鐵一起作動,與這個磁鐵相對應的感測器也會移動。
聲學分析(聲音)
與震動分析相似,聲測方位分析也是供潤滑技師使用,主要是專注在主動採取潤滑措施。這意味我們可以避免移動設備時產生的過度磨損,否則會為了修理造成代價高昂的停機。實際的例子可能包括測量輸送皮帶的承軸狀況。出現過度磨損時,承軸會因為潤滑不足或錯位出現故障,可能造成整個生產流程的中斷。
聲學分析(超音波)
聲音聲學分析雖然可以用來進行主動與預測性維護,超音波聲學分析卻只能用於預測性維護。它可以在超音波範圍內找出與機器摩擦及壓力相關的聲音,並使用在會發出較細微聲音的電氣設備與機器設備。我們可以說這一類型的分析與震動或油量分析相比,更可以預測即將出現的故障。目前它部署起來比其他種類的預防性維護花費較高,但終端 AI 的進展可以促成這種細微層級的聲學檢測,大幅降低部署的費用。
熱顯影
熱顯影利用紅外線影像來監控互動機器零件的溫度,讓任何異常情況很快變得顯而易見。具備終端 AI 能力的裝置,可以長期檢測微細的變化。與其他對事故敏感的監視器一樣,它們會觸發排程系統,自動採取適當的行動來預防零件故障。
消費者與智慧家庭
將語音運用在消費者與智慧家庭,是最常看到的場景之一。這包括智慧型手機與平板電腦上、未包含電話整合功能的裝置,例如螢幕尺寸有限的穿戴式裝置。這類型的裝置包含智慧手錶與健康穿戴式裝置,可以為各種功能提供免動手的語音啟動。像 Amazon 的 Echo 或 Google 的 Home 等智慧音箱市場的成長,說明消費者對於可接收與提供語音互動等現有裝置的強勁需求,與日俱增。
消費者基於各種理由使用智慧音箱,最常見的使用場景為:
聽音樂;
控制如照明等智慧家庭裝置;
取得新聞與天氣預報的更新;
建立購物與待辦事項清單。
除了像智慧音箱與智慧電視等消費裝置,智慧家庭裝置語音的使用,也顯現相當的潛力。諸如連網門鈴(如 ring.com)等裝置與連網的煙霧偵測器(例如 Nest Protect 煙霧與一氧化碳警報)目前都已上市可供消費者選購,它們結合了語音與視覺的感測器融合功能以及運動檢測。有了連網的煙霧偵測器,裝置在偵測到煙霧或一氧化碳時,可以發出語音警告。
終端 AI 為強化這些能力提供了全新機會,而且常常結合震動(動作)、視覺與語音控制。例如,增加姿態辨識來控制例如電視等家電,或是把語音控制嵌入白色家電,即是以最低成本強化功能性最直接的方式。
健康照護
用來發現醫護資訊的 AI 驅動終端裝置的應用,將為病況的治療與診斷,提供更多的價值。這種資訊可能是資料,也可能是影像、影片以及說出的話,我們可以透過 AI 進行型態與診斷分析。這些資料將引發全新、更有效的治療方法,為整個產業節省成本。受惠於終端 AI 的進展,像 Google Duplex 等語音系統的複雜性將會降低。例如門診預約等勞力密集的工作,也可以轉換成 AI 活動。利用自然語言語音來延伸 AI 的使用,也可以把 AI 用在第一線的病人診斷,然後再由醫師接手提供諮詢。
其他健康照護實例包括像 Wewalk5 等物件,這是一個供半盲與全盲人員使用的智慧拐杖。它使用感測器來檢測胸口水平以上的物件,並搭配 Google Maps 與 Amazon Alexa 等 app,方便使用者提出問題。
結論
由於連網的終端裝置數量越來越多,這個世界也越來越複雜。連接到網際網路的裝置已經超過 300 億個,而微控制器的數量也超過 2,500 億,每年還會增加約 300 億個。越來越多的程序開始進行自動化,不過,把大量資料傳送到雲端涉及的延遲以及邊緣運算的額外費用,意味著許多全新、令人興奮且引人矚目的物聯網使用場景,可能無法開花結果。
解決這些挑戰的答案,並不是為雲端資料中心持續增添運算力。降低出現在邊緣的延遲雖然會有幫助,但不會解決日益分散的世界的所有挑戰。我們需要把智能應用到基礎架構中。
儘管為終端裝置增添先進的運算能力在十年前仍不可行,TinyML 技術近來的提升,已經讓位處相當邊緣的裝置 (也就是終端本身)增添智能的機會大大改觀。在終端增加運算與人工智慧能力,可以讓我們在源頭搜集到更多更具關聯性與相關的資訊。隨著裝置與資料的數量持續攀升,在源頭掌握情境化與具關聯性的資料,具有極大的價值,並將開啟全新的使用場景與營收機會。
終端裝置的機器學習,可以促成全新的終端 AI 世界。新的應用場景正在崛起,甚至跳過傳送大量資料的需求,因而紓解資料傳輸的瓶頸與延遲,並在各種作業環境中創造全新機會。終端 AI 將為我們開啟一個充滿全新機會與應用場景的世界,其中還有很多我們現在想像不到的機會。
附圖:圖1:從集中式到分散式運算的轉變。
(資料來源:《The End of Cloud Computing》,by Peter Levine,Andreessen Horowitz)
圖2:全球上網裝置安裝量。
(資料來源:Strategy Analytics)
圖3:深度學習流程。
圖4:MCU的視覺、震動與語音。
(資料來源:意法半導體)
圖5:AI 工具集執行模型轉換,以便在MCU上執行經最佳化的神經網路推論。
(資料來源:意法半導體)
圖6:物聯網企業對企業應用的使用-目前與未來。
(資料來源:Strategy Analytics)
圖7:促成情境感知的感測器融合。
(資料來源:恩智浦半導體)
資料來源:https://www.eettaiwan.com/20210303nt31-the-dawn-of-endpoint-ai-bringing-compute-closer-to-data/?fbclid=IwAR0JTRpNsJUl-DmSNpfIcymGQpkQaUgXixEaczwDpELxGCaCeJpkTyoqUtI
監控 硬 碟 缺點 在 黑眼圈奶爸Dr. 徐嘉賢醫師 Facebook 的最佳貼文
如何備份保存孩子的相片及影片,純分享一下心得
大家手機中的容量,應該大部分都是被孩子的日常生活相片及影片所佔據了。手機滿了又捨不得刪除照片,存在電腦又沒辦法隨時回頭觀看。
奶爸Dr.常常在備份相片(GoPro, 單眼,手機),有一點小小的心得,可以分享給大家。
現在除了Dropbox, Flickr, Google Photo,iCloud 等雲端服務外,還有手機用的USB暫時備份的方式
其中Google Photo 無限的容量,是很貼心的備份方式,對於父母來說是很方便,會自動備份手機的照片影片。#而且是免費的!可以隨時隨地看很久以前的照片或是影片。小缺點就是會經壓縮而降低畫質。
NAS:
如果跟我一樣龜毛,不放心只放在雲端,希望多一層保障,想要儲存在家中安全的地方,但是家中的電腦容量又不夠大,怎麼辦?
可以考慮用網路硬碟NAS (Network attached storage ),把相片及影片存在其中,而且不會降低畫質。慨念有點像「個人的雲端」,但是功能更多。可以儲存音樂、各種檔案、自動下載bt ⋯功能可以很強大。
他可以透過手機上的App,隨時隨地看很久以前的照片或是影片。或是用手機連線至家中的NAS ,觀看監控攝影機或自己下載的影片
而市面上最多人使用的有兩個品牌: Synology 群暉科技 , QNAP , 兩個都很不錯很推薦。很多不同的機型可以選擇。
如果有興趣可以自行去他們的官網:
Synology: https://www.synology.com/zh-tw/products/series/plus
QNAP: https://www.qnap.com/zh-tw/