關於將預購系統導入容器化、微服務架構的工程,中華電信規畫了三個階段,初期的重點是容器化,中期則是將應用程式拆解開來,後期則是希望達成DevOps的流程。(圖片來源/黃昭文)

雲端服務當道,接連掀起了伺服器虛擬化、容器化、微服務化的風潮,應用系統的開發、整合、測試、上線的速度有了劇烈的提升,承載應用系統的平臺發生量變與質變,在企業IT環境裡面的工作負載,除了支撐日常關鍵應用系統的穩定運作,也面臨更多極端的需求,像是持續時間不長、負載量卻超高的應用服務,越來越常出現,該如何因應這樣的挑戰?

在iThome主辦的Kubernetes Summit大會當中,今年就有兩家臺灣電信業者談到他們導入容器服務平臺的經驗,中華電信就是其中之一,他們目前是將這樣的架構用在既有的預購系統上,而且,建置的平臺是企業級軟體──紅帽的OpenShift Container Platform,不過,即便如此,他們在系統搬遷過程中,仍經歷了預期以外的狀況,有意採用這類環境的企業,若能及早掌握可能影響搬遷作業的各種細節,應能減少出錯機會。

先拿預購系統開刀,因其服務特性很適合移植到雲端環境

身為成立時間最久的臺灣電信業者,中華電信所經營的各種通訊、網路與加值服務,背後都由資訊系統支撐,當中有許多都是十年以上的老舊系統,因此,他們近期開始思考把這些系統搬到雲端服務的環境,而預購系統的搬遷就是率先進行的工程。

為什麼是這套系統先行?中華電信資訊處工程師黃昭文表示,傳統預購系統最大問題就是瞬間的搶訂壓力,許多網站往往承受不住,為了解決問題,業界提出的作法是運用分散式架構,但同時也須面對一些問題,像是網路管理、多臺設備管理、資料庫系統負荷能力、儲存管理,建置這些環境的成本也很高。

第二個考量是預購系統的另一個特性:使用時間很短。一般而言,電信業者的預購系統,運作時間並不長,可能上線為期三天、一週,之後就會下架,若要建置專屬環境,不敷成本效益。

這是一般電信業者預購系統的運作架構,在設計上,是以分散負載的方式來考量,希望能夠妥善消化瞬間搶購的壓力,但需要針對網路管理、設備管理、儲存管理、高可用性的需求,來配置IT資源,搭建成本相當高,而且這類系統服務時間並不長,之後又需要撤下、回收,想要以更經濟的方式快速擴展(縮回)應用系統規模,相當不容易。(圖片來源/黃昭文)

這是中華電信建置的容器服務平臺,他們採用的是Red Hat OpenShit Container Platform,在Kubernetes Summit大會上,他們首度揭露目前系統的架構。(圖片來源/黃昭文)

歷經容器化、解構,進入微服務

在系統搬遷的作業時程上,中華電信規畫了下列3個階段。

第一階段:原貌搬遷

系統搬遷初期,他們對應用系統的調整幅度不大,優先考量服務正常運作。此時主要的工作,是將應用程式的執行環境,從實體伺服器、虛擬機器,搬到OpenShift。過程當中,他們先把虛擬機器當中的應用程式,放到Docker container,再將容器搬到OpenShift。以耗費時間而言,從VM轉到Docker較短,從Docker到OpenShift較久。

關於這階段的搬遷,黃昭文列出7大工作重點。首先是盤點程式行為,因為當應用程式改到OpenShift執行之後,開始會有一些橫向擴充(Scale out)的活動,可能就會相互衝突;其次是參數需重新設計,若能用對參數、改變參數餵送的方式,對於K8s的操作比較友善。

第二階段:系統解構

此時,中華電信開始執行預購系統的解構,提高邏輯的清晰度。相較之下,前一個階段,他們是把整個應用系統包進容器當中,但在這個階段,則是開始進行合理拆解,導入微服務的概念,讓系統上下游之間可透過RESTful API去串接,應用程式當中的不同部分,可以橫向擴充規模。同時,他們也選用輕量的Web應用程式框架,像是Spring Boot來進行改寫,而不再採用WebLogic這類應用程式伺服器。

關於Kubernetes平臺的使用上,黃昭文也特別提醒,要注意Pod的串接數量。他們發現,串連路徑越長,效能折損越大。所謂的Pod是指一群容器的代稱,對於K8s環境而言,是最小的物件模型單位。

他也秀出效能測試的圖表,當Pod串接到兩個站點時,網路呼叫的效能就會瞬間降至低點。若要增加效率,他提出以下幾個建議:我們可以在應用系統上游的呼叫端,導入共用連線(Connection Pool),或是運用非同步作業的機制,也可以在應用系統下游的服務端,採用高效能的應用程式框架。若需要非常高的效能,我們可以多個相關的容器封裝在同一個Pod裡面,如此可以大幅減輕網路流量的負擔。

第三階段:微服務、DevOps

在預購系統的搬遷進入最終階段之際,中華電信期望可以跨入微服務、DevOps的應用。

在此之前,黃昭文呼籲企業應評估自身體質是否適合,確認應用系統架構的調整,究竟是想要還是必要。同時,也要注意單位組織分工的變化,如果是橫向切割,未來在DevOps的流程當中,彼此合作會更為密切,在系統維運的慣性上,IT人員也要有心理準備,因為複雜度可能會提升。

在資料處理的結構與流程,這時也可能需要重新設計。例如,應用程式連接的資料庫系統可能需要拆解,才能支應微服務的存取需求,而拆解之後的資料內容同步,也需要注意。

事實上,這個階段的目標更為宏觀,希望達到獨立開發、高效率部署、維運標準化的要求。黃昭文坦言,其實在中華電信內部有太多系統,每一套系統都有不同維運的方式,對於經驗傳承、未來招募新人而言,都是困難的地方,於是,他們希望應用系統的開發與維運,從需求管理延伸到交付部署,都有一模一樣的流程,對於企業而言,不論是成本或管理考量,都會比較簡單、穩定。

掌握不同環境差異,可少走冤枉路

除了規畫三大階段,黃昭文也列出多項過程當中需注意的技術細節。首先是底層環境,有些商用軟體的登錄機碼或組態授權,會綑綁處理器或伺服器的型號,如果沒有處理好,系統搬移到另一個環境時,可能無法啟動。

軟硬體的相依性上,由於部分軟體授權有處理器核心數量授權限制,因此,若搬遷到新環境,提供的處理器核心數量很多時,也可能無法啟動系統。

系統軟體本身也有一些相依性的議題,那就是與作業系統核心(Kernel)版本之間的捆綁。舉例來說,若底層伺服器的作業系統更新核心,應用系統可能就會受到影響而停擺。

在容器的部份,黃昭文建議,每個容器裡面不要放置太多處理程序,否則當多個容器同時執行,可能會相互干擾。

接著要注意的部份,在於容器的執行權限,以及K8s或OpenShift本身的環境變數,在配置上,應避免與其衝突,因為若發生這樣的狀況,原本自定的部份,將會被系統覆蓋。

容器的Volume設定也要關照一下,當我們包好容器或採用他人的容器之後,請記得打開裡面的組態,例如,查看Dockerfile,確認儲存Volume掛載的位置,以防出現資訊遺漏的狀況。

在Kubernetes的部份,我們要注意ConfigMap的唯讀限制,有些應用程式需要修改設定時,若沒有考慮到這個因素的影響,可能就無法啟動。對於實體儲存配置上,也要關注可用空間的多寡,因為若出現容量不足的狀況,Kubernetes系統會停用Pod。

 相關報導  企業K8s實戰在臺灣 

熱門新聞

Advertisement