Google Cloud 教學

Google Cloud 學習筆記 (3)

教學目標

初步了解 Google 雲端平台架構規劃的基本概念,此篇主要為學習筆記。

重點概念

首先當我們需要管理和設定解決方案基礎架構時,主要會先考量容量和需求,並且選擇正確的基礎架構元件來支持和適應需求,同時我們更需要了解網際網路、虛擬私有網路、雲端路由器、… 等連線方式,而 Google Cloud Networking 與其他網路供應商不同,不像傳統 IP 網路和軟體定義架構網路,其是雲端中的網路服務,因此我們需要知道如何將現有資料中心網路遷移至 Google Cloud Platform 網路的過程,同時 Google Cloud Platform 網路的過程將能夠將子網路擴展到同一區域中的區域,也就是說一個虛擬機器和一個備用虛擬機器可以位於同一子網路上,但是位於不同的區域中。

接著單一防火牆規則可以應用於不同的區域中的多個虛擬機器中,這使得設計和實作彈性或高可用性解決方案變得更加容易,此時我們需要了解擇哪種備份連線、網路故障排除、維護管理、…等方法?此外我們針對雲端網路服務的解決方案設計必須要考慮安全性,其目標主要是將違反安全管理的成本提高至高於資料的價值,一個很好的模型是一座城堡。城堡的牆壁越大越高,內部的寶藏就越大,請注意即使我們遵守該標準,也可能不足夠滿足業務安全的要求,因此我們針對安全性設定通常採用最小權限原則。

再來企業客戶皆有業務的需求,像是若業務單位付款,則業務單位會需要透過審核的流程獲取消耗資源的詳細資訊,像是開關虛擬機器,並且當我們開始增加任何類型的流程,就會有對於開發人員生產力造成影響,此時透過雲端服務就能夠將對於開發人員生產人的影響降至最低,甚至沒有影響。此外雲端基礎架構資源設定必須進行記錄和稽核,同時對於雲端基礎架構的變更必須要有審核的流程,以及對於開發人員生產力的影響最低,而為了達到上述需求雲端服務解決方案的一部分就是基礎設施即程式碼,其主要能夠將解決方案強制實作流程審核,程式碼審核以及所有有助於滿足其業務需求的內容的好處。

最後我們根據以上需求主要會將雲端服務以基礎設施即程式碼的方式和搭配流程審核和程式碼審核進行實作,其中我們主要能夠透過 Google Cloud Deployment Manager 自動化部署雲端服務,並且透過 Google Cloud Identity and Access Management 提供最小權限的服務帳戶,以及透過 Github Enterprise 進行程式碼版本的控管,並且用於限制可以在程式碼儲存庫中實際執行操作。

相關資源

Google Cloud 學習筆記 (2)

教學目標

初步了解 Google 雲端平台架構規劃的基本概念,此篇主要為學習筆記。

重點概念

首先雲端技術通常會有多種方法可以實現相同的功能,然而不同的技術對於整個系統品質將會產生影響,所以我們必須確定在某種情況下選擇哪種服務是最適合的,此時識別瓶頸對於涉及從現有解決方案建立的問題特別實用,像是目前系統可以支持 X 個使用者,但是目標是支援 Y 個使用者,此時目前設計的瓶頸是什麼呢? 應用程式將在何處達到極限?這通常是決定哪種解決方案在這種情況下最適合的因素,因此我們需要能夠讀取資料流程圖,並且清楚地了解系統處理資料的流程。

接著我們針對處理資料的流程請勿假設資料流程或資料容量是對稱,所以我們主要會考慮 CAP 理論,所謂 CAP 理論主要是一致性、可用性和分區容忍性,其中一致性則會基於 ACID 理論,所謂 ACID 理論主要是原子性,一致性,隔離性和持久性,而可用性則會基於 BASE 理論,所謂 BASE 理論主要是基本可用、軟狀態和最終一致性。因此我們需要針對任何的資料解決方案確定應該至少符合 CAP 理論中一致性、可用性和分區容忍性其中的兩個元素。

再來我們在遷移至雲端服務時,我們需要從資料中心的資料處理開始,所以雲端服務一開始僅是副本,但是當我們完成遷移計劃時,則雲端服務與資料中心的所有資料皆相同,並且更相關,或者更有可能整合資料中心的資源。為了整合資料中心的資源,我們需要在客戶所面臨的問題中尋找更多實用資訊,而不僅僅是技術線索,以利找出最適合的雲端服務解決方案,請注意實務上通常存在許多無法從資料中心遷移的資源需要保留在本地,此時我們就會需要整合雲端服務和資料中心的現有系統和流程,至於要如何證明解決方案是有效的,而不僅僅是一個好的理論,此時除了需要執行概念性驗證之外,更需要考量如果為了提高效率而從設計中移動某些資源,以及降低成本,請考慮所會造成不同層面的影響後果。

最後我們遷移至雲端服務之後需要考量測量和調整,最好的解決方案將將會解決所有利益或共同利益,像是 CEO 希望改善資料分析,CTO 希望降低成本,一開始這兩個利益似乎存在衝突,但是如果轉向另一個更有效的雲端服務解決方案就有可能會同時解決這兩個要求,此外擴大情境應用的規模通常會改變問題的性質,所以需要重新進行雲端服務解決方案的評估,同時我們針對已經採用的雲端服務解決方案將會進行監控,日誌記錄,指標,以及管理,請注意雲端服務解決方案的設計通常不是在交付時完成的,而是在實務中大多數的雲端架構師需要在交付後的一段時間內確保雲端服務解決方案繼續營運,並且容易進行維護。

相關資源

Google Cloud 學習筆記 (1)

教學目標

初步了解 Google 雲端平台架構規劃的基本概念,此篇主要為學習筆記。

重點概念

首先設計雲端解決方案主要會先從服務定義開始,一步一步根據不同層級的考量因素規劃推出和維護解決方案,所謂不同層級的考量因素,分別為:

  1. 服務定義
  2. 業務需求
  3. 資料管理
  4. 網路傳輸
  5. 擴展還原
  6. 安全存取
  7. 成本效益
  8. 部署監控

其中當我們談到業務需求時最主要會先問:「客戶的需求和期望是什麼?」並且確定成功標準和決定如何進行衡量,但是優化成功標準,並且同時降低成本是非常困難的一件事,因此我們需要先將活動劃分為功能,然後再將成本優化劃分為優先等級。此外我們還能夠保持現有系統並行工作一段時間,並驗證新系統是否按預期執行,以利確認雲端解決方案能夠達到衡量目標。

接著不同的設計模式皆有其最佳用途和限制,在每個設計中,總會有一些問題需要考慮,像是優先等級,像是時間,預算或品質的衡量標準是什麼?考慮這些因素將有助於決定是否購買解決方案,還是客製現有產品和服務,像是 Google Cloud Platform 中的機器學習產品,主要有預先訓練的模型,像是 Cloud Vision API 和 Natural Language API 讓我們能夠快速進行機器學習模型的部署應用,或者 Cloud ML Engine 和TensorFlow 讓我們能夠完全控制機器學習模型,以利我們定義並添加到預先訓練的模型中。

再來當客戶對於雲端服務不了解時,我們能夠告知客戶透過雲端服務將能夠進行故障移轉和災難恢復,而當故障轉移和災難恢復解決方案執行之後,我們就能夠根據客戶的需求動態進行擴展,因此我們主要能夠撰寫簡單的服務,並且對其進行雲端服務的改善和限制,規劃避免瓶頸等故障,同時更我們能夠規劃在發生故障時快速恢復。在企業中所有價值都是即時價值,這代表我們可能希望確定測量標準何時可能更改或將如何影響業務,此時若是提前交付雲端服務的解決方案,則就會具有更高的附加價值。

最後雲端服務的解決方案最常見的設計模式,像是將問題解決方案劃分為前端和後端,無狀態和有狀態將有助於解決前端可擴展性的問題,以及使用許多後端可擴展性的小型無狀態服務器將有助於解決後端故障轉移的問題,請注意前端和後端的資訊主要是隔離和分離的狀態。

相關資源