Nuclio On Kubernetes (上)

Nuclio On Kubernetes (上)

Nuclio On Kubernetes (上)

Nuclio是Iguazio所開發的Serverless開源項目。Iguazio是以色列一家專門提供連續性資料的平台,提供即時、高速的資料處理框架。Iguazio認為現今的Serverless服務所提供的主要還是在功能面上,也就是最基礎的FaaS所提供的:利用Function整合其他服務,以提供整合後的服務或應用。

Serverless Function的設計是Single Thread透過Event-Driven觸發,僅在Event喚醒Function時運作,這意味著每個Function都可能透過不同的Event觸發,並連結所需的Services,有效提供整合後的服務或應用,因此除了Function as a Service外,部份文章也將其稱之為Backend as a Service。Iguazio CTO Yaron Haviv認為目前的Serverless Solutions並無法完全滿足Iguazio的需要,因為Serverless目前還有以下幾個需要解決的問題,包含:

低下的Performance

Serverless在架構上由於大量依賴Function和服務間的訊息傳遞,因此會有不同機器或服務所需IO產生來回(Round-Trip)延遲的問題,而造成來回延遲時間的增多,主因有以下兩點:

  1. 每個Function都是Single Thread,雖然可方便開發人員的除錯並減少多執行緒所帶來的麻煩,但也意味著每個Function無法利用並發(Concurrency)來處理資料存取時可能發生的問題,也就是該Function所需的資料尚未處理好前,該Function將會無法即時繼續執行。
  2. 由於每個Function都是無狀態(Stateless)的,因此許多有狀態的Function要被應用時,須連接其他服務以取得狀態,頻繁的喚醒Function將需要許多的成本在通訊、資料複製及Context Switch上。

為了解決上述兩點,針對a點,Iguazio利用Go語言撰寫Non-Blocking的資料存取方式,讓該Function可即時取得所要存取的資料。而對於b點,則利用Share Memory的方式,實現Zero-Copy的資料搬移,減少Context Switch的次數。此外,為因應大流量的Function需求,Nuclio可透過Scale Out Function Container的方式,將Incoming Data分流至各個Function Container。透過以上方法,Nuclio可提供單一Process每秒40萬次Event的請求,並至少比主流的Serverless Solutions快10~100倍。

被限制的平台、Event和資料來源

目前有許多Serverless的服務,但不同Serverless所提供的FaaS有不同的Event和Data Resources支援,如HTTP gateway、Kinesis 、SQS等等。每一個Event Source會產生不同的Event Structure,如圖1所示。這代表若不同平台間的Event Trigger不通用的話,則開發者將被限制在該平台上,例如AWS Lambda的Function僅可透過AWS所提供的服務如Kinesis等所觸發。

有鑑於此,Nuclio提出Common Event Structure的概念,如圖2所示,將各種協定及Event Source分類並整合,以及提供多種序列化(Serialization)的選擇。Nuclio的Common Event Source Approach也在CNCF提供了Specification,期望其他Serverless平台也能跟進,旨在簡化各種不同Event Source所帶來的複雜性和平台限制,讓開發者開發的Function可以在不同平台上不需改動便可快速的接上不同的Event Source並佈署,大幅提高Function的可攜性。作為第一個提出該概念的Nuclio,相同的Function在Nuclio上可不需修改原本的Code,便可透過快速修改Event Consumer API來使用類似Plugin的方式任意更換諸如HTTP、 KinesisKafkaRabbitMQMQTTNATSiguazio’s V3IO、File content或Event emulator等Event Sources來觸發Function。

複雜的Function App狀態維護,Code Dependencies和Service Dependencies

如1.b所述,每個Function都是無狀態的,因此其State或Content的取得、Result的儲存以及Message的傳輸有很大部份皆須仰賴於外部的Data Services。為了使用這些Data Service,如MySQL等,開發者需要在Function內寫好固定的資料庫連接及身份認証相關的程式碼,或是一些環境參數。如第2點的Event Source所述,這些各式各樣的Data Source也存在同樣的問題,當Function的Data Types或Repositories有所改變時,則Function也失去了可攜性,因為相同的代碼將變得無法使用。

為了簡化Data Source的複雜度,並解決Code和Service Dependencies的問題,Nuclio採取Azure所倡導的資料連結方法,提供Pluggable的Data Binding方法,將Data Binding所需的程式碼提供通用的API呼叫,API所連結的Data Resource的資料要怎麼連結認証、要如何處理等等的細節則另外在Function外設定,也就是將處理Data Bilnding的角色由Developers改為Operators,讓Developers只需專注在Function的撰寫上,並讓Function具有可攜性。透過該作法,提供:

  1. Simplisity:透過Simple API讓程式碼不再關注資料連結的細節和SDKs。
  2. Security:資料連結的身份認証等隱私資訊將不再出現在Function的程式碼或變數內。
  3. Portability:Data binding的分離讓Function可任意更換Data Sources。
  4. Reusability:同樣的Code透過連結不同的Data Sources可能又能提供不同的應用。
  5. Performance:資料的連結透過Nuclio Components連結,可提供non-blocking IO和zero-copy access。

Function無法在Hybrid或Multicloud環境進行Develop、Debug、Test和Deploy

分為兩個部份討論,第一個部份是如何在單一的Serverless Provider提供Develop、Debug、Test和Deploy。第二個部份是如何可讓Function在不同Provider或Cloud環境下運作。

首先針對第一部份,一般Serverless的Function並不容易Debug,以AWS Lambda為例,其不支援Function下中斷點Debug,因此開發者需要透過觀察Log的方式來進行程式的除錯。由於Serverless的Function幾乎都是透過容器包裝的方式來等待Function的Event觸發,因此每個Function的運作本質上就是一個容器。既然每次Deploy一個Function就是Deploy一個容器,那麼也意味著Function的Regression testing若無自動化的話,那同一個版本的Function每修改一段程式碼要重新測試時,依造作法的不同,可能會有需要重新Deploy新的容器並刪除舊有的Function容器的狀況發生。此外,由於Function是運行在容器中,在整個CI/CD的過程中,可能會產生許多Log資訊,如何提供Log Parsing也會是整個自動化的一個重點。Nuclio對此第一部份的作法如下:

  1. 提供可進行Verbosity層級的動態控制的非侵入式Structured和Unstructured的多種Logging方法,例如Screen、HTTP、File、Log streams等。此作法可讓開發者在許多不同的Log或Debug Points產生Log,並能在容器運行中直接修改Log的Verbosity Level,以進行Log Parsing取得更有意義的Log資訊,提供開發者不需修改Function便可進行更高效的Bugs和Failures診斷。此作法提供了開發者理想的Function自動化測試和分析。
  2. Nuclio目前提供多種Runtimes的SDK,如GoJava.NET,未來或許還會支援更多不同的語言。開發者只需在Function內Import該SDK,便可在Function內下中斷點並提供Function自動完成(Auto-Complations)的功能。該Runtime的SDK提供開發者類似本地IDE的環境,模擬開發者的Function在本地端上被模擬的Event觸發並連接Data Sources,以取得模擬測試的Input和Output,並將Log顯示於螢幕上或儲存於File內。
  3. 為了讓測試人員可進行回歸測試(Regression Testing),Nuclio如上述b點所提,提供如Files、Http、Streams等等Event的模擬,讓測試人員可在不更改Function Code的情況下觀察Function的行為模式。
  4. 更多Debugging和Instrumentation的支援已列入Nuclio的未來規劃,包含Statistics Debugging和OpenTracing的整合。

針對第二部份,許多情境下開發者可能會需要Function在不同的雲上運行,除了成本和平台限制性的考慮外,針對IoT或Edge Computing,同樣的Function也很可能需要在不同的Devices或Edge Servers上運行。在平台限制性上,或許只能仰賴於各Serverless服務的提供者共同合作,例如前述2和3點所提的議題,讓Funtion在不同平台間仍具有可攜性。而單一平台在上述針對IoT或Edge的情境下,也意味著Nuclio需可讓Function掛上版本號並支援分散式的自動化佈署方式,以期進行Rolling或金絲雀佈署。

未完待續

撰文: 呂威廷 迎棧科技工程師