我想試試看 nginx 在 Cloud Run 啟動之後，

能不能去 Cloud Storage 讀取最新的 index.html 檔案：

這樣的話，我以後每次改網頁，我就不用重新建立 Docker Image，

或是重新跑一個 CI/CD 的流程。

我先用預設的 Nginx Container，

而我在 Cloud Storage 寫的首頁 index.html 是 “Hello world from Dongdong Cloud Storage!!”

我希望部署出去後，就顯示這個首頁，代表這個檔案是部署的當下去 GCS 抓過來的。

但是我如果在 Cloud Shell 使用 docker build 指令，

Docker 執行 gstuil cp 去 Cloud Storage 複製檔案時，

總是會碰到這個錯誤：

ServiceException: 401 Anonymous caller does not have storage.objects.get access to the Google Cloud Storage object. Permission ‘storage.objects.get’ denied on resource (or it may not exist)

就是 GCP 並不認識 Dockerfile 執行的指令，把它視為匿名者 Anonymous。

我已經試了應該有2個禮拜了，一直都沒有成功，

現在打算改用 Cloud Build 來試試看。

因為 Cloud Build 會使用預設的 Service Account，

這樣 Cloud Storage 會認得是它去拉資料的。

像這個是我專案的預設 Service Account：

600195576280-compute@developer.gserviceaccount.com

它本身已經具有一些權限，因為它預設就是 Editor 的角色。

這個 Service Account 除了操作 Cloud Build 之外，

會把建置過程的 Log 寫到 Cloud Storage 的某個地方，

還要把 Image Push 到 Arfitact Registry，

所以如果要另外使用 Service Account，相關的權限和 Cloud Storage Bucket 都要建立起來。

在此我們一樣先用預設的 Service Account 就好。

我先在 Cloud Shell 建立資料夾

mkdir cloud-run

cd cloud-run

mkdir nginx-cp-gcs

cd nginx-cp-gcs

建立相關檔案

首先是 Web Server Nginx 的設定檔，

只是用預設的，讓它對外使用 8080 Port 即可。

vim nginx.conf

server {
    listen 8080;
    server_name localhost;

    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
    }
}

再來是 Dockerfile，

建立 Image 時要執行的一系列動作會在這裡準備好。

vim Dockerfile

# 使用官方的 Google Cloud SDK 映像作為基礎
FROM gcr.io/google.com/cloudsdktool/cloud-sdk:alpine

# 安裝 Nginx
RUN apk add --no-cache nginx

# 複製 Nginx 配置
COPY nginx.conf /etc/nginx/http.d/default.conf

# 複製啟動腳本
COPY start.sh /start.sh
RUN chmod +x /start.sh

# 創建 Nginx 運行所需的目錄
RUN mkdir -p /run/nginx

# 設置工作目錄
WORKDIR /usr/share/nginx/html

# 暴露 8080 端口
EXPOSE 8080

# 設置入口點
ENTRYPOINT ["/start.sh"]

你會注意到它在最後有一個入口點，

它會執行 start.sh 這個檔案：

vim start.sh

#!/bin/sh

# 從 GCS 下載 index.html
gsutil cp gs://dong-dong-gcp-config/index.html /usr/share/nginx/html/index.html

# 啟動 Nginx
nginx -g 'daemon off;'

你可能會好奇，為什麼要另外執行 gsutil cp 多此一舉？

因為獨立的 start.sh 讓我們在容器啟動後執行動態操作，

比如從 GCS 下載最新的 index.html。

如果我們將這個操作放在 Dockerfile 中，

它只會在構建時執行一次，而不是每次容器啟動時都執行。

所以另外使用 start.sh 就可以讓整個流程更為靈活。

最後我們是要呼叫 Cloud Build 來幫我們執行建立 Image、Pull Image 和部署到 Cloud Run 的動作，

我們就全部都寫到 cloudbuild.yaml 這個檔案裡：

vim cloudbuild.yaml

steps:
# 建立 Docker 映像檔
- name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'asia-east1-docker.pkg.dev/dong-dong-gcp-3/nginx/cp-index-from-gcs', '.']

# 推送 Image 到 Artifact Registry
- name: 'gcr.io/cloud-builders/docker'
  args: ['push', 'asia-east1-docker.pkg.dev/dong-dong-gcp-3/nginx/cp-index-from-gcs']

# 部署到 Cloud Run
- name: 'gcr.io/google.com/cloudsdktool/cloud-sdk'
  entrypoint: 'gcloud'
  args:
  - 'run'
  - 'deploy'
  - 'nginx-custom-service'
  - '--image'
  - 'asia-east1-docker.pkg.dev/dong-dong-gcp-3/nginx/cp-index-from-gcs'
  - '--region'
  - 'asia-east1'
  - '--platform'
  - 'managed'
  - '--service-account'
  - 'cp-from-gcs@dong-dong-gcp-3.iam.gserviceaccount.com'
  - '--allow-unauthenticated'

images:
- 'asia-east1-docker.pkg.dev/dong-dong-gcp-3/nginx/cp-index-from-gcs'

我們現在總共有這些檔案：

最後就來部署了！

把所有動作都照 cloudbuild.yaml 裡的指令來執行即可：

gcloud builds submit –config=cloudbuild.yaml

接下來要等3分鐘左右，讓它把所有步驟跑完。

在等待的同時，也可以去 Cloud Build 的 Console 看看有什麼東西

你可以點擊最新的版本，

會看到所有建置過程的記錄：

你會看到三個步驟：docker build、docker push、gcloud run deploy

都有詳細記錄建置的過程。

最後顯示部署完成

那我們去 Cloud Run Console 看看

再點進去看看

會你看到它的網站竟然是反灰的，

因為「調整權限」這個動作，Cloud Build 的 Service Account 是沒有權限的，

我們要人工執行下方這個「調整權限」的指令，才會有公開 URL

gcloud run services add-iam-policy-binding nginx-custom-service \
  --region=asia-east1 \
  --member=allUsers \
  --role=roles/run.invoker

我們再重新整理一下網頁：

成功了，看到的網頁是從 Cloud Storage 複製過來的。

所以結論就是，

不要在 Dockerfile 這個「小三」裡面做太多事，

尤其是要呼叫 GCP 各項 API 的時候，

讓 Cloud Build 這個「有名份」的老婆去 Cloud Storage 拿東西，

就不會被警衛阻止了。

說實話，我並不是熟悉寫程式的，

也許各位軟體工程師有更好的方法也說不定，

歡迎批評指教，謝謝大家！

The post [Cloud Build 教學] 用 Cloud Build 部署 Cloud Run 存取 GCS 才不會碰到權限問題 first appeared on 東東 GCP 教學 - GCP 實戰講師.

BigQuery 是 GCP 的企業級資料倉儲服務，它可以快速處理結構化和非結構化資料，並提供即時查詢和分析功能。

它主要針對需要分析大量資料的企業所設計，例如電子商務平台、遊戲公司、媒體公司和金融服務公司等等。簡述 BigQuery 的優勢如下：

(一) 再大的資料都能即時高速處理與查詢

BigQuery 能在幾秒鐘內處理數百億行數據，這對於需要快速決策的企業來說至關重要。它的分散式架構允許你同時查詢和寫入資料，完全不需要等待。

而且無論是幾百 GB 的數據，還是幾 PB 的數據，BigQuery 都能輕鬆處理。它的擴充能力確保即使你的業務需求增長，你的資料分析能力也能跟上。

(二) 串接各種資料來源

BigQuery 自問世以來，便極力整合巿面上各種服務，尤其是針對第三方的資料來源，開發了各種連接器 (Connector) 來串接，直接省去你手動傳輸的工作，非常方便。

建議你可以先查看官方文件，也許你的資料來源已經內建整合 BigQuery 的功能喔！

(三) 無伺服器容易上手

使用 BigQuery 根本不用開機器，直接倒入資料就可以開始分析，光是這一點就足以輾壓巿面上各種分析工具。而且你只要使用 SQL 語法就能分析出結果 (如第一張圖片)，不用重新學習新的語法，對使用者非常友善。

基於以上特色，BigQuery 在世界各地早已經有各大知名企業使用，最知名的就是 Twitter (現在叫 X)，而在台灣像是知名的社群數據分析公司 QSearch，在 8 小時內可以分析 432 億筆資料。痞客邦 幾10秒就查完 60 億筆資料。

其他成功案例還有 KKBOX、東森新聞雲、大數據(網路溫度計)、旋轉拍賣 Carousell、智生活、UDN 聯合新聞網、 QBurger、Freshworks、Blibli 等等，族繁不及備載。

二、資料上傳到 BigQuery 的方法介紹

BigQuery 支援多種上傳資料的方法和工具，方便企業處於各種不同情境，都能夠找到方法把資料匯入 BigQuery，分述如下：

(一) 手動匯入檔案

1. 從本機上傳 CSV 檔

假如你剛開始使用 GCP，你可以先在 Console 上面手動匯入一筆小量的資料，我這裡先準備一個 CSV 檔案，內容是 GCP 的帳單明細。如果你想用我的資料測試看看，也可以從這裡下載。

這裡要注意如果第一列是你的欄位名稱，務必要確保它是小寫英文字母開頭，後面是可接英文和數字，如果有空格請使用底線，萬一沒有按照要求來匯入資料，就會失敗喔！

我們先到 BigQuery 的主畫面，然後點擊「建立資料集」，也就是 Dataset：

點擊之後，馬上跳出側邊視窗，先設定 Dataset ID，注意不能用 “-” 而是要用 “_”。另外 Dataset ID 並不像 Cloud Storage，使用全球獨一無二的 Bucket ID，你可以設定任何的 Dataset ID。

在位置部分，和 Snapshot 或 Image 一樣，你可以設定單一地區或是多個地區的儲存位置。

下方有一個預設資料表到期時間，通常我們不會去設定，因為萬一時間到了，整個 Dataset 的資料都會刪除乾淨。除非你很確定只是短期使用，再做這個設定。

確認沒問題的話，就可以點擊「建立資料集」。

接下來你會看到左邊已經產生剛剛建立的 Dataset，並在右邊視窗看到相關資訊，我們再點擊「建立資料表」：

接著跳出側邊的視窗，我們在來源部分點擊下拉選單，選擇來源為「上傳」。

同時你也會看到它可以從各種不同來源來建立資料表，例如 Cloud Storage、雲端硬碟、Bigtable 甚至 AWS 的 S3 和 Azure Blob Storage 都可以是匯入資料的來源。

接著跳出上傳檔案的視窗，選擇我的 CSV 檔案之後，BigQuery 自動偵測要匯入的檔案格式，自動秀出 CSV。

我們再輸入要建立的表格名稱，接著不要急著按下「建立資料表」喔！我們再來看一些重要參數。

結構定義就是 Schema，指的就是這張表格的結構，包含欄位名稱和資料格式，例如文字叫 STRING、日期叫 DATE 等等，還有欄位是否可以為空 (NULLABLE) 還是必填 (REQUIRED)。

你可以點擊「以文字形式編輯」，手動一個一個欄位設定。如果你是初學者，不知道如何設定的話，可以直接勾選「自動偵測」，BigQuery 會自動幫你偵測內容，選擇一個適合的格式。

如果你是專業的資料數據工程師，請務必手動設定欄位，確保它的格式符合你後續的分析工作。 

接下來的「分區」下拉式選單，是因為 BigQuery 有所謂的分區表 (Partitioned Table)。

因為 BigQuery 一般的表格，每次都是查詢整個表格，即使你只撈出一點點資料，但它仍然會以整張表格的資料量計費，這樣很容易就花費不少錢。

而分區表的設計，可以讓你設定撈取資料的日期範圍，當你使用相同語法來查詢時，它只會依照日期範圍的資料量來計費，而不是整張表格計費，節省不少成本。

我們目前的資料量不大，可以保持「無分區」就好。我們再往下展開進階選項。

進階選項展開後，第一個是「寫入偏好設定」，如果你的表格本來有資料，你可以決定要繼續新增 (附加到資料表中)，或是把原本資料蓋掉 (覆寫資料表)，而我們是建立新的表格，所以選哪一種都可以。

而「允許的錯誤數量」很重要，指的是你對於這個匯入動作，是否要求必須每一筆都格式正確。

如果是，你就設成 0，但你要注意，在匯入過程中，只要偵測到一筆資料有問題，你就必須「全部重新匯入」，即使你已經匯入 100 萬筆資料。

這就會導致你浪費前面所有的時間，你可以視情況「把允許的錯誤數量」調高一點，例如資料筆數的 1%，否則你就必須保證資料格式完全正確。 

至於「要略過的標題列數」，就像我前面準備好的 CSV 檔，第一列是欄位名稱，所以我就在這裡輸入 1，確保它不會把欄位名稱也當成一筆資料，如果你的原始資料並沒有欄位名稱，就保持 0 就好。 

其他選項就保持預設，然後按下建立資料表。

幾秒鐘後，會看到系統提示資料表建立完成的訊息，我們可以直接點擊「前往資料表」： 

13 系統提示表格建立完成，點擊前往資料表

資料來源：擷圖自 GCP 主控台

畫面跳轉到我們建立完成的表格，你可以看到 BigQuery 自動偵測的欄位名稱和資料類型。 

我們點擊「詳細資訊」，可以看到表格的一些基本資訊，例如表格的完整 ID、建立時間、位置、表格的大小和資料比數等等。 

我們在點「預覽」，可以看到表格前面幾列的內容。

要注意 BigQuery 是按照查詢的資料量來計費的，如果你想探索資料，不要動不動就 「Select * from 某個 Table」，這樣是會被計費收錢的喔！

這個方法要注意，只能上傳最大 100 MB 的檔案，再大就無法上傳了。

2. 從 Google Drive 匯入 BigQuery

這個方法可以上傳最大 10GB 的檔案，所以先上傳到這裡比較方便。 但它只限 Google 試算表，不能匯入 CSV 檔案喔！

你可以直接在檔案上按右鍵=>共用=>複製連結：

然後貼到「選取雲端硬碟 URI」欄位中：

比較特別的地方是，你可以指定匯入的資料範圍，不一定要全部匯入。我們選定資料範圍後可以複製左上角的座標： 

然後貼到工作表範圍：

其他的設定跟前面一樣，沒問題就按下建立資料表： 

完成後去查看表格，你會發現，你看不到資料量大小和筆數，是因為 BigQuery 並沒有把 Google 試算表的資料複製進來，而是當成外部的表 (External Table) 來用。

接著我們使用查詢來確認，看它是不是剛好 10 筆資料。我們開啟新的分頁：

它把前面欄位的部分空著，我們直接輸入「 * 」代表所有欄位，並且把「 LIMIT 1000」刪除，確保它能夠秀出所有資料，接著按下「執行」：

你會到剛好 10 筆資料的查詢結果，代表即使試算表有 100 多筆資料，但我們己在匯入時限制 10 筆的範圍，所以這裡就只能看到 10 筆。

關於資料不在 BigQuery 裡面的問題，不用擔心，接下來我們使用「撈出資料寫入表格」的語法來處理，我們開啟一個新的查詢分頁，然後準備以下語法：

沒問題就按下執行，因為這個語法是讓它直接執行寫入資料表的動作，是在背景作業，不會秀出資料給你看。所以我們再按「前往資料表」：

你會看到它沒有再秀出「外部資料設定」和「來源 URI」，而是直接秀出資料筆數和佔用空間大小。 

代表它已經是 BigQuery 本身的內部表格喔！

3. 從 Google Cloud Storage 匯入檔案

假如你的資料超過 10 GB，那建議先上傳到 Cloud Storage 再匯入 BigQuery，這樣最大單次能匯入 5TB 的檔案。

我用同個檔案來示範，首先我直接拖曳到 Cloud Storage 的 Bucket。

然後回到 BigQuery 建立資料表，按下「瀏覽」：

然後找到要匯入的檔案，再按「選取」。

順便提一下，它支援萬用字元 (例如: gs://bucket/data/*.csv)，代表你可以一次匯入多個檔案，但資料總量還是不能超過 5 TB 喔！

接下來看到「結構定義」，我們這次自己來挑選匯入之後的欄位格式。如果你使用我的範例檔案，可以參考下圖設定，其它類型可以查看官方文件。

然後按下「以文字形式編輯」，它會把設定轉換成語法，強烈建議你複製語法。

為什麼要多此一舉？

你剛剛手動設定欄位，一定花費很多時間。如果待會匯入發生錯誤，相同的動作你就要再做一次。

現在只有 6 個欄位就算了，如果正式的表格有 40 個欄位，你可能已經花了半個小時設定，結果匯入失敗要重來的話，你可能會懷疑人生。

如果你已經事先複製語法，你只要稍做調整就可以直接貼上，可以省去你大量的時間。 

接下來是分割設定，是因為 BigQuery 有所謂的分區表 (Partitioned Table)。

因為 BigQuery 一般的表格，每次都是查詢整個表格，即使你只撈出一點點資料，但它仍然會以整張表格的資料量計費，這樣很容易就花費不少錢。

而分區表的設計，可以讓你設定撈取資料的日期範圍，當你使用相同語法來查詢時，它只會依照日期範圍的資料量來計費，而不是整張表格計費，節省不少成本。

我們這次選擇「依欄位分割」，然後選取「use_date」欄位，並且勾選必須使用「WHERE 子句」來查詢資料。

目的就是要強迫使用者在查詢的時候指定時間範圍，如果使用者不使用這個語法，系統不會讓他執行，藉此降低查詢成本 。

接下來進階選項的部分跟前面一樣，你可以事情況設定「允許的錯誤數量」，以及「要列過的標題列數」，如果沒問題就按下「建立資料表」。 

建立完成之後你會看到系統提示「這是分區資料表」，你也會在下方看到「已分區」以及分區的欄位。 

關於更多從 Cloud Storage 匯入 BigQuery 的細節，可以參考這份文件。

我們將三種方法整理如下表，你可以視情況選用適合的匯入方法。

(二) 使用 Data Transfer Service 立即或排程匯入

如果你要正式傳輸大量資料到 BigQuery，推薦使用 Data Transfer Service（ 簡稱 DTS)。

它除了可以從地端的資料庫上傳之外、也支援從 Google 相關的行銷平台如 Google Ads、Ad Manager 和 Google Play，甚至其他雲端如 AWS S3 Storage、AWS Redshift、Azure Blog Storage、Salesforce 等，更多資料來源可以參考這份文件。

針對不同來源，操作方法都差不多，我們就以 AWS S3 Storage 來源為例子，說明步驟如下。

我們先從 BigQuery 主選單進去，找到「資料移轉」再建立「移轉作業」： 

接下來從「來源類型」點擊下拉式選單，你會看到它有非常多的來源可以選擇，我們就直接選 「Amazon S3」： 

我們就來設定轉移的作業名稱，以及排程的執行頻率，例如每天執行一次就設定為 24 小時。 

在目的地設定，我們輸入轉入  BigQuery 的表格名稱。而在 Amazon S3 的資料來源設定當中，有兩個重要的欄位叫做 Access Key ID 和 Secret Access Key： 

我們就去 AWS 的主控台然後點擊右上角自己的 ID，進入安全憑證頁面：

接著點擊「建立存取金鑰」：

接著就進入到存取金鑰的頁面，它有提供 Access Key ID 和 Secret Access Key，如果你只是短暫測試，就直接將兩個值複製起來，不要下載 CSV 檔案，以免金鑰被駭客拿到。 

 Access Key ID 和 Secret Access Key 複製後貼入 DTS 的內容欄位。

另外 Write Disposition 指的是，你匯入資料後，要不要清除原始資料 (WRITE_TRUNCATE)，或是一直附加到表格的最後面 (WRITE_APPEND)。

而在傳輸選項的部分：

Number of Error Allowed

跟之前建立 BigQuery 一樣，如果資料量夠大，建議設定一些允許的錯誤，以免整個傳輸作業有任何一點錯誤，導致全部重來。

Decimal Target Types 

這是非常重要的欄位，指的是關於如何處理從 S3 中的 decimal (十進位數) 格式資料轉換到 BigQuery 時的資料型態轉換規則。

你可以先指定比較偏好的型態，再指定退而求其次的型態，最多三個。

在傳輸過程中，先用第一個型態來接收資料，如果接收到不符合這個型態的，整個欄位自動調整成第二個型態來接收看看，不行再改成第三個型態。

例如你有一個 decimal(38,9) 的欄位 (總共38位數，小數點後9位)，你先設定「NUMERIC, BIGNUMERIC, STRING」：

• 系統會先檢查 NUMERIC 是否能處理這個精確度 (這麼多位的數字)。
• 結果後來發現有一個數字太大，NUMERIC 不足以處理 (因為 NUMERIC 最多 38 位)，就會嘗試把欄位整個改成 BIGNUMERIC 繼續接收資料。
• 結果數字又更大，或是非數字的資料出現，BIGNUMERIC 也不行，最後會轉成 STRING，幾乎什麼格式的內容都可以接受。

這樣做的好處是：

• 避免資料傳輸中斷 – 不會因為突然出現意外的資料格式就失敗，不要全部重來太辛苦了。
• 自動調適 – 不需要事先精確知道所有資料的格式和範圍，如果你懶得事先指定格式，就給一個順序讓 DTS 自動判斷就好。
• 資料完整性 – 確保所有資料都能被正確保存，即使需要轉換成比較寬鬆的格式，寧可先收進來，格式後續再慢慢處理就好了。

Ignore Unknown Values

很容易理解，無法判斷的內容就直接略過，也可以避免因錯誤而中斷。

Header Rows to Skip

跟之前匯入 CSV 檔的操作一樣，如果第一列是標題就讓它略過。

最後服務帳戶的部分，要指定一個讓它能有權限代替你執行整個傳輸工作，你不需要事先研究要設定給這個 Service Account 哪些權限。

你直接指定一個帳戶給它，它會自動授予必要的權限角色給這個帳戶，當然你可以先產生一個不具備任何權限的服務帳戶，後面碰到權限問題再調整就好。

然後勾選「電子郵件通知」，這樣就不用時時進來確認進度。沒問題就按下「儲存」，它就會自動開始傳輸了。

整個設定如上，除了你可以在 Console 設定，如果你有安裝指令套件，也可以下 bq 指令；或是寫程式呼叫 API，或操作 Java 的 Library 都可以執行傳輸工作。

更多設定的細節可以參考這份文件。如果是從 Azure Blob Storage 來傳輸，也可以參考這份文件。

(三) 匯入串流資料

前兩種都是批次，代表一次性把資料匯入完成。

而串流資料是持續不斷產生的 (例如社群留言、股票報價、使用者點擊遊戲或工廠 IoT 設備回傳)，可能要即時處理和反應 (例如即時推薦商品或掉出寶物)，就必須使用串流資料的傳輸方法，依照複雜程度分述如下：

1. BigQuery Storage Write API

這個方法針對小規模、簡單的串流需求，直接從應用程式寫入資料，並且不需要複雜的資料轉換，最適合這種方法。

BigQuery 早期主要使用 tabledata.insertAll API。這個 API 的設計相對簡單，主要特性包括：

(1) 使用 REST over HTTP 通訊協定。

(2) 資料格式採用 JSON。

(3) 提供基本的串流寫入功能。

(4) 操作直觀容易上手。

但它同時也存在一些明顯的問題：

(1) 效能限制

．使用 REST over HTTP 通訊協定，傳輸效率較低。

．JSON 格式佔用較大的網路頻寬。

．屬於短期 Request，每個連接都有建立和關閉的動作，耗費系統資源且傳輸量受限。

(2) 資料一致性問題

．沒有完整的交易支援，例如有一部分失敗，不能全部倒回處理。

．無法保證資料的精確一次處理，可能出現資料重複的情況。

(3) 成本考量：

．資料傳輸成本較高。

．沒有免費用量額度。

而 Storage Write API 相對的優勢如下：

(1) 採用 gRPC 串流取代 REST over HTTP

雖然每個資料表最多 100 個連線，但這 100 個連線是持久的，可以持續使用，效能提昇不少。

(2) 資料一致性強化

它使用一個編號系統「串流偏移」(Stream Offset) 來追蹤每筆資料，當發現資料重複就不會傳送，提供「完全一次性」處理保證的選項。

(3) 成本效益

Storage Write API 提供每月 2 TiB 的免費擷取額度，而且 gRPC 串流能夠使用更少的資源來處理資料，提升資源的使用效率。

兩者比較總結如下表：

因此，如果需要高頻率的短期連線，可以使用 tabledata.insertAll API，如果需要穩定的長期資料串流以及資料一致性保證或交易支援，就選擇 Storage Write API。

2. Datastream

如果不寫程式，最好的方法就是使用 Datastream，它可以支援資料庫的即時同步，包含 MySQL、PostgreSQL、Oracle 等，如果來來源資料庫有變更，它也能同步到 BigQuery，也就是所謂的 CDC (Change Data Capture)。

設定步驟很簡單，首先進入Datastream 來建立連線設定檔：

我們真是 PostgreSQL 資料來為範例的資料來源，點擊 PostgreSQL：

我這裡沒有現成的資料庫，以下使用國外網友的示範圖片，輸入連線設定檔名稱和 ID，並且指定 Region：

接著輸入資料庫的 IP、Port、連線帳號、密碼和資料庫名稱： 

它有提供三種連線方式，我們選擇最簡單的 IP 白名單，這裡指的是允許地端的資料庫可以從Datastream 的 IP 連線過去存取資料。 

看到它跳出 IP 位址，直接複製起來貼到地端的防火牆去設白名單。

接著要測試連線，這裡一定要測試成功，才可以建立設定檔，所以上方的欄位不能隨便亂打喔！

若測試通過，就可以建立設定檔了。

接著畫面會秀出，我們剛剛建好的連線設定檔內容，我們回到上一層： 

我們要針對傳輸的目的地 BigQuery 也建立連線設定檔，點擊「Create Profile」： 

選擇 BigQuery：

設定名稱和 Region 並按下建立：

接下來就看到它設定完成了：

我們現在可以正式建立串流工作，點擊「Create Stream」： 

輸入串流的名稱、ID、Region、來源跟目的地： 

然後按「Continue」進行下一步：

在這裡我們選擇剛剛建立的 PostgreSQL 連線設定檔： 

在這裡我們一樣要測試一下資料庫的連線，成功後再按「Continue」：

在 Configure Source 中，我們要設定 Publication Slot Name 和 Publication Name。

這個 Slot 不是 BigQuery 本身的 Slot 喔！在 PostgreSQL 的資料複寫 (Replication) 機制中，Replication Slot 是一個重要的概念。

它能夠追蹤資料變更，即使複寫目標 (Datastream) 暫時離線或延遲，Slot 也會確保需要的 WAL (Write-Ahead Logging) 檔案，直到 Datastream 收到這些變更，也能避免資料遺失。

你需要在 PostgreSQL 資料庫中預先建立這個 Replication Slot，然後在設定 Datastream 時提供這個 Slot 名稱，這樣 Datastream 就能透過這個 Slot 來追蹤和接收資料庫的變更。

而 Publication 是 PostgreSQL 10 版之後推出的邏輯複寫 (Logical Replication) 機制中的一個重要元素。你可以指定特定的表格要被複寫，以及要複寫哪些類型的操作。

再往下選擇要轉移資料的表格跟欄位，選好再下一步： 

在目的地的部分，我們就選擇剛剛建立的 BigQuery 連線設定檔： 

這裡是問你要把轉移出來的資料要放在單一 Region 還是多個 Region 的 Dataset。

如果你後續的的應用主要在特定區域運作，選擇 Region 即可，如果你需要更高的配額限制和更高的可用性，選擇 Multi-region。

Stream Write Mode 指的是寫入模式，包含 Merge (合併模式，會更新舊資料)、Append (追加模式，不會更新或刪除現有資料) 和Replace (替換模式，會刪除所有現有資料)。

而 Staleness Limit (資料陳舊限制)，指的是資料是否需要立即處理，設定為 0 秒表示資料會立即被處理，用來保持最即時的狀態。但可能會導致較高的查詢成本，因為每次變更都需要立即處理。

如果您想降低成本，並且可以接受一點資料延遲的話，可以增加一點 Staleness Limit。

最後再按一下「RUN VALIDATION」來確認所有的設定正確無誤，如果都沒問題就可直接按下「CREATE & START」直接開始傳輸：

它跳出一個確認視窗，再次按下「CREATE & START」：

接著我們就看到 Datastream 開始同步資料了： 

3. Pub/Sub 搭配 Cloud Functions

Pub/Sub 是一個完全代管的訊息佇列 (Message Queue) 服務，基於發布/訂閱 (Publish/Subscribe) 模式，主要用於事件驅動架構和串流資料處理。主要有三個特性：

(1) 解耦 (Decoupling)

透過發布/訂閱模式，發送方和接收方之間不需要直接互動，讓系統的各個部分能夠獨立發展和擴展，大幅提升了系統的靈活性和可維護性。

(2) 可靠性 (Reliability)

系統會將所有訊息永久儲存，即使在過程中發生異常，訊息也不會遺失。

(3) 擴展性 (Scalability)

系統能夠因應流量變化自動擴充，無需手動干預。

而 Cloud Functions 本身是輕量級的應用程式平台，內建訂閱 Pub/Sub Topic 的功能 很適合處理中小規模的串流資料，尤其是針對簡單的資料轉換。

當新訊息到達時，能夠自動觸發 Cloud Function 執行，最適合用於事件驅動的架構，特別是那些資料流時有時無的場景。

優勢：

因為是無伺服器架構，不用管理任何基礎設施。系統能夠根據實際負載自動擴展，只要為實際使用的資源付費。

開發過程也相對簡單，工程師可以專注於業務邏輯的實現，不必擔心底層基礎建設的管理。這種按需付費的模式通常能提供較好的成本效益。

限制：

Cloud Functions 的執行時間有上限，最長只能運行 540 秒，不適合需要長時間處理的任務。例如資料轉換太複雜的時候，並且冷啟動也會帶來延遲。另外對於併發處理能力也有一定的限制。

注意事項：

首先要設定合理的 Time-Out 時間，確保能夠完整處理資料。同時，必須實作穩健可靠的錯誤處理和重試機制，以應對可能的失敗情況。你也要建立完善的監控機制來追踪 Cloud Functions  的執行狀態。

4. Pub/Sub + Cloud Run

Cloud Run 結合 Pub/Sub 提供了一個更加靈活的串流資料處理方案。特別適合那些需要自訂處理邏輯，或需要特定運作環境的場景。

與 Cloud Functions 相比，它支援更長的運作時間，最長可達到 60 分鐘，並且能夠處理中大型的串流資料。

優勢：

由於容器化的部署方式，這提供很大的靈活性。

您可以使用任何程式語言，安裝任何所需的相依性套件。Cloud Run 能夠自動擴充 (Autoscale)，同時能運作較長時間，讓它能夠適用於複雜的應用場景。

限制：

首先是容器映像檔的維護，這需要一個完整的容器管理或 CI/CD 流程。相比 Cloud Functions，Cloud Run 的設定也相對複雜一些，需要更多的維運工作。

從成本角度來看，如果沒設定好 Autoscale 的參數，可能會導致較高的費用。

注意事項：

要注意容器映像檔的維護和更新策略。對資源的配置需要仔細優化，包括記憶體、CPU 等參數的設定。

建立完善的監控和警報機制也很重要，需要及時發現和解決潛在問題。另外，為了控制成本也要小心設定 Autoscale 的策略。

5.  Pub/Sub + Dataflow

Dataflow 結合 Pub/Sub 是一個企業級的串流處理方案，適合處理大規模資料和複雜的轉換。

Dataflow 具有高度的擴展性，特別是那些複雜的業務邏輯，或需要進行大規模數據處理的企業級應用場景。

優勢：

Dataflow 提供了豐富的資料轉換和處理功能，能夠處理複雜的業務邏輯。它也能 Autoscale，能夠自動處理負載量的變化。

還內建完善的容錯機制，能夠確保數據處理的可靠性。此外，它還支援複雜的視窗操作 (Window Operations)，將連續不斷的資料流切分成有限時間區段來處理，以及自訂的轉換邏輯。

限制：

Dataflow 也是最複雜的，它需要較多的專業知識，從設定到後續維護都很複雜。從成本角度來看，它是會自動建立虛擬機器來運作，也有較高的運營成本，通常需要專門的團隊和較長的時間投入。

注意事項：

首先是仔細規劃資料管道 (Data Pipeline) 的設計，確保能夠高效地處理資料流。

成本優化也是一個重要考量，需要合理設置資源使用策略，從 CPU、記憶體、硬碟，到 Autoscale、處理窗格和管道設計等等。建立完善的監控機制是很重要的。

6.  串流方法比較表

以下整理五種串流資料的方法，你可以根據場景來決定處理方式：

三、資料「不用」上傳到 BigQuery 的方法介紹

沒錯，資料不一定要上傳到 BigQuery 才能做分析，你可以讓資料就在原來的地方，讓 BigQuery 自己過去抓資料來分析，以下介紹資料「不用」上傳到 BigQuery 的方法：

(一) 外部表  (External Tables)

外部表就像是在 BigQuery 中設定一個連結，指向存放在別處的資料。連結建立後，你就一樣在 BigQuery 的介面，使用一般的 SQL 語法來查詢，就跟查詢 BigQuery 本身的表格一樣方便。

適用的資料來源包含：

• Cloud Storage 中的 CSV、JSON、Avro、Parquet、ORC 等檔案
• Google 試算表
• Bigtable

像是從雲端硬碟匯入 Google 試算表，我們在最前面已經示範過了，匯入之後，就會呈現表格的詳細資訊，有一個來源 URI 代表真的是外部表，這裡就不再贅述。

使用外部表有一些注意事項如下：

1. 查詢效能會比較慢

因為每次都要讀取外部資料，效能取決於資料來源本身，就不像在 BigQuery 身上那麼快。

2. 資料格式要一致

尤其是 CSV 的欄位順序和型態，例如 Schema 設定 3 個欄位，但某些 CSV 檔只有 2 個欄位，就會報錯「Invalid field count」；或是​​數字欄位出現文字，會造成「Invalid integer value」錯誤。

3. 檔案路徑支援萬用字元 「*」

代表你可以一口氣匯入「多個」檔案成為「一個」外部表，很適合定期新增的資料檔案，例如每天的 Log 檔，每次執行查詢時，BigQuery 都會重新掃描符合萬用字元的檔案，非常方便。

4. 權限要設定正確

你設定適當的權限給 BigQuery Service Account，例如 storage.objectViewer，確保 BigQuery 能存取Cloud Storage 的檔案。

(二) 同步查詢 (Federated Query)

Federated Query 是直接發送 SQL 查詢語法到其他資料來源，即時取得結果。這種方式更有彈性，可以直接查詢原始資料庫，尤其來源資料經常變動的話，適合用這種方式查詢。

適用的資料來源包含：

• Cloud SQL (MySQL/PostgreSQL)
• Cloud Spanner
• Alloy DB

我們以網路上示範的影片為例子呈現如下，我們現在 Spanner 準備好一個 demo_db 資料庫，點擊進入看到 emp 表格，再點進去：

我們再點擊「Data」，看到裡面已經準備好一筆資料。 

我們在回到 BigQuery 去新增外部的資料來源，點擊「ADD DATA」裡面的「External data source」： 

選擇 Spanner 之後，填上資料庫的相關資訊，如果相關內容都輸入正確，可以直接按下「Create Connection」：

接下來它秀出連線資訊，我們可以直接點擊「Query」來試著查詢資料：

它預設的語法是讓你看到整個資料庫的 Metadata，例如資料庫裡有哪些表格和欄位。 

我們來調整一下語法，讓它直接查詢「emp」這個表格，最後就看到原本儲存 Spanner 的裡面的資料內容，代表我們的確是連線到 Spanner 做查詢。 

使用 Federated Query 的注意事項：

1. 需要額外設定連線和授權

因為我們直接連線到來源資料庫，查詢時間可能較長。光是連線成功就需要時間等待。

2. 要注意資料量

避免查詢太大量資料，影響原始資料庫的運作，如果要大量還是把資料轉入 BigQuery 比較好。

3. SQL 語法會因資料來源而異

要配合來源資料，例如 MySQL、PostgreSQL 和 Spanner 的查詢語法可能有所不同。

4. 計費方式與一般查詢不同

它不會佔用 BigQuery 的儲存費用，但仍然會有查詢費用。如果頻繁查詢外部資料庫，也要考慮提高規格，相對也造成較高成本。

(三) 如何判斷要用原生、外部表或同步查詢？

我們已經看了各種匯入資料到 BigQuery 的方法，那要選原生或外部表或同步查詢的決策標準是什麼？這裡整理各種方法優缺點和適用的場景給你參考：

建議策略

1. 從資料更新頻率來看

(1) 如果資料每天更新 1-2 次，建議使用原生表，查詢效能最好。

(2) 如果資料持續變動 (如每分鐘)，考慮外部表或 Federated Query。

(3) 如果是即時分析需求，一定使用 Federated Query。

2. 從查詢效能來看

(1) 需要毫秒級回應，必須使用原生表。

(2) 可接受秒級延遲，使用外部表。

(3) 可接受較高延遲，使用 Federated Query 。

3. 以成本為考量

(1) 資料量大但查詢頻率低，選擇外部表或 Federated Query，不用花費 BigQuery 儲存成本。

(2) 查詢頻率高，原生表有 24 小時快取，重複讀取外部資料成本較高。

(3) 預算有限，可先用 Federated Query，再根據使用情況調整。

4. 實務建議

(1) 可採用混合策略，不同的資料採用不同的查詢方式。

• 熱門資料 (經常查詢) 使用原生表
• 冷資料 (不常查詢) 使用外部表
• 特殊即時需求用 Federated Query

(2) 建議先小規模測試：

• 先用小部分資料評估性能
• 測試實際查詢場景
• 監控成本和效能數據再決定

四、上傳到 BigQuery 之前的注意事項

前面看完各種上傳或不上傳到 BigQuery 的方法，除了針對採取的方法提共建議之外，這裡也建議上傳之前要確認以下注意事項：

(一) 資料品質與準備工作

你必須確保所有資料的格式是一致的，包括日期格式和數值類型都要統一，異常值和空值也要先處理好。

編碼格式最好用 UTF-8，這樣比較不會出現亂碼。另外欄位名稱要注意，不能用特殊字元，不然 BigQuery 會報錯。

針對批次載入，你沒有辦法在 BigQuery 傳到一半給它按暫停，調整後再繼續傳，它錯了就是要全部重來，所以請務必謹慎處理，避免重工。

(二) 成本考量

如果資料需要整理，可以先用臨時表，等到都整理好了再存到永久表。這樣中間處理的表隔天會自動刪除，不會佔用空間也不用付費，最後的結果才存在永久表裡給大家查詢使用。

分區 (Partitioned) 策略也要規劃好，確保查詢只針對部分資料而不是整張表格，這樣可以省下不少查詢費用。要是預算有限，最好設個配額上限，免得花太多錢。

(三) 效能優化

表格結構要設計得合理，別搞得太複雜，例如盡量使用巢狀表格 （Nested Table） 而非 Join 太多表格。

選擇分區欄位的時候，通常用時間欄位或是基數 (Cardinality：一個欄位中不重複值的數量) 比較高的欄位會比較好。如果需要的話，也可以考慮加上叢集索引。

(四) 權限與安全性

如果上傳有使用特定工具，要遵守「最小權限原則」，給予剛好且必要的權限。資料存取的控管策略也要想清楚，特別是有敏感資料的話，可能還需要設定資料遮罩或加密。

(五) 上傳方式選擇

大部分情況都建議先傳到 Cloud Storage 再導入 BigQuery，至少資料已經先進來了，也不受檔案大小限制。

記得要設定合理的 Time-Out 時間，讓傳輸工作多等待一段時間，萬一上傳失敗也要有因應的處理方式。

(六) 監控與維護

上傳過程中要做好監控，隨時掌握進度。要是上傳失敗了，得要有辦法快速恢復。定期維護和檢查資料品質也別忘了。

(七) 文件與溝通

透過文件把所有細節都記錄下來，每個欄位都要寫清楚說明，資料從哪裡來、怎麼處理的都要記錄好。

跟其他團隊也要講清楚什麼時候上傳、會影響到誰。要是碰到問題，大家也才知道該怎麼處理。

五、結論

我們總共看了手動上傳、Data Transfer Service、Datastream 和串流各種方法，以及「不上傳」到 BigQuery 的外部表和 Federated Query。

可以看到 BigQuery 提供的方法真的非常多，讓你可以因應各種情境，來評估和選擇最適合的方法。

至於到底要用哪一種方法，除了參考上面的整理表格之外，最重要還是建議你先以小量資料試過一遍，才會發現到更多沒提到的小細節，來幫助你做出更好的判斷。

只要資料成功進來了，BigQuery 就不只能夠幫你做好分析，還能做為開發 AI 模型的基礎，幫企業產生更多價值。

本文同時刊登於：

【東東老師 X 思想科技】BigQuery 的優勢與使用方法

【東東老師 X 思想科技】資料匯入到 BigQuery 的方法

【東東老師 X 思想科技】資料「不用」上傳到 BigQuery 的方法介紹

The post [BigQuery 教學] 把資料上傳到 BigQuery 的各種方法和步驟 first appeared on 東東 GCP 教學 - GCP 實戰講師.

1. 自適應串流技術 (Adaptive Streaming)

你手機或家裡的 Netflix App，如果發現你網路突然變慢，它會立刻幫你把影片畫質調低一點，讓你可以繼續追劇不中斷。等網路速度恢復後，畫質也會自動變回高清，完全不用你操心。

2. 內容分發網路 (CDN)

當你想看魷魚遊戲時，影片不是從韓國或美國傳過來，而是從離你最近的「倉庫」傳送，就像是從你家附近叫外送一樣快速方便。

技術一點來講，他們與世界各地的網路服務商合作，在不同地理位置部署內容伺服器，會先把最近觀眾看過的內容「暫存」在 CDN 節點上，這樣就不用大老遠從美國傳影片到你家，

3. 高效影片編碼

Netflix 採用如 VP9 和 HEVC/H.265 影片編碼技術，比上一代 H.264 減少約 40-50% 的檔案大小，甚至 H.265 需要的頻寬 (15-25 Mbps) 還比 H.264 小 (25-35 Mbps)，特別適合 4K 內容，所以你在家用超大螢幕觀看都不會模糊。

4. 預測性快取

Netflix 會分析你的觀看習慣，猜你接下來想看什麼。比如說你在追「單身即地獄」或「殺手安西教練」(?)，它就會偷偷先把下一集存在附近的伺服器，這樣你要看的時候就超級快。

5. 智慧播放緩衝

它會提前載入一段內容，確保你的觀看體驗順暢。如果網路不穩，它會多存一點；網路很順的時候，就少存一點，在確保流暢播放和節省頻寬之間取得平衡。

祝大家追劇愉快！

The post 為什麼看魷魚遊戲都不會卡？Netflix 的影片處理技術解析 first appeared on 東東 GCP 教學 - GCP 實戰講師.

(一) 證照背景與 Google Cloud Platform 的發展

Google Cloud Platform (簡稱 GCP) 是 Google 的雲端平台，提供各種伺服器、負載平衡、資料庫、數據分析和 AI 各種工具，讓你可以架站、部署電子商務平台、做大數據分析和開發 AI 應用。

Cloud Architect 證照是 GCP 第一張推出的證照，比 Associate Cloud Engineer 雲端助理工程師證照還早很多年。

(二) GCP Cloud Architect 認證的核心技能

1. 熟悉整個 GCP 各種常見的服務
2. 根據客戶需求，從 GCP 挑選服務，組合成適合的方案
3. 設計 GCP 的雲端架構
4. 針對主機或資料搬遷上雲的方法評估
5. 優化成本並提高效能

二、為什麼要考 GCP Cloud Architect 認證？

(一) 轉職雲端架構師

如果你沒做過雲端相關工作，必考這張證照，可以做為你求職的敲門磚。畢竟，沒有證照又沒有經驗的你，如何證明你懂 GCP？

如果你是要在 GCP 代理商工作，這張只是基本條件。

那 Associate Cloud Engineer 雲端助理工程師證照不夠嗎？

ACE 證照只代表你會操作 GCP，但在操作之前，你要知道為什麼要執某個操作，就是要懂得思考。例如為什麼要用 BigQuery 而不是 Cloud SQL，為什麼要用 Cloud Armor 而不是防火牆等等。

那不用先考 ACE 證照，才能考 Cloud Architect 嗎？

不用，沒有規定你要先考 ACE，你可以直接考 Cloud Architect。

(二) 增強職場競爭力

對於非 IT 背景的人來說，例如高階主管、行政單位或客戶，你跟他們說你 GCP 很強，他們不知道什麼叫「很強」。

但是你證照拿出來，他們至少會認同這是一個客觀的評價，好歹你是有考過試的人，再怎麼樣也不會差到哪裡去。

(三) 提高薪資潛力

很多公司有對 GCP 證照提供薪資的加給，對於你當前工作，或未來跳槽都很有幫助。

(四) 充份掌屋 GCP 各項服務

如果你沒考過 Cloud Architect，你只會針對你常用的功能熟悉，但你不知道可能有更好用的功能。

考 Cloud Architect 就是要強迫你把整個 GCP 都了解一遍，讓你碰到各種不同情境時，都能找到相對應的解決方案。

三、GCP Cloud Architect 認證適合誰？

(一) 雲端從業人員

證明你真的懂雲端，或至少給外行人看，像政府標案投標，一定是先看你有沒有證照再說。

(二) IT 專業人士

如果你突然被交待要了解 GCP，幫公司搬遷上雲，趕快考取證照是一個強迫你快速學習的方法。

(三) 想轉職雲端產業的人

如果你沒做過雲端相關工作，這張證照可以做為你求職的敲門磚。

四、準備 GCP Cloud Architect 證照的方法

證照考試介紹

考試是 50 題選擇，時間兩個小時，你可以去恆逸資訊或資展國際考試，也可以遠端考試。

考試用費訂價 200 美金，目前都是優惠價 120 美金 (Renew 證照還有優惠喔)。

考試時間則是自己選的，當你選好考場，你就可以找一天考場有開的寺間去考試，但是如果考試近了，你還沒準備好，可以趕快去改時間。

如果你在考試前 72 小時才改，可能會被多收錢，我是沒試過啦。

當你考完之後，這張證照有兩年期限，每次我從 2018 年考過之後，最近是第四次考，這是證照的公開連結。

你可以先去證照的官網查看相關資訊，它會提供考試指南，就是大概會考哪些東西，讓你心裡有個底。

它還有提供範例題目，必看，而且它有詳細的題目解析，不要連送分的都沒掌握到喔！

考試範圍與準備方法

我個人整理的各項服務出題比例依照大類排名如下：

Compute Engine 就是虛擬機器相關，包含 VM、Disk、Image、Snapshot、Instance Template、Instance Group，因為用的人最多，所以考題也最多。

再來是架構綜合性問題，沒有特別針對哪一個服務，就是要考你有沒有架構師的 Sense，什麼時候應該怎麼做，算是觀念類型的問題。

資安則包含身份驗證、Secret Manager、加密、Cloud DLP、Service Control、Org Policy 等等。

DevOps 也是偏向一些觀念和原則，不針對特定服務去考。

然後 GKE 和 BigQuery 也是 GCP 的主力服務，一定要會的。

如果我們再細分成小類，你會發現每個主題，考得「非常平均」。

所以並沒有「只要唸哪一部分就能考過」這種想法，就是「整個 GCP 都要唸過一遍」就對了。

另外，根據業界人士消息，因為生成式 AI 發展快速，導致 GCP 許多服務都整合 AI 的功能，預計今年 Cloud Architect 考題要大改版，但幾月幾日？不知道。

只能說，趕快去考吧！

官方 GCP 學習資源

如果要真的懂 GCP 的各項資料服務，還是先以官網文件為準。

但是文件非常多，而且是「非常非常非常多」，所以你只要大概知道每個服務大概在做什麼就好，不然是不可能讀完的。

你可以讀像是：

Overview 和 Introduction： 大概了解每個服務到底在做什麼。

Best Practice：應該怎麼用比較快、效能比較好、比較便宜、比較安全等等。

Troubleshooting：有問題時應該怎麼處理，要檢查什麼地方。

不要求你看完全部的文件，因為根本看不完。

其實 Google 官方文件很難閱讀，寫得文謅謅的，看不懂就複製貼到 ChatGPT 幫你寫成白話一點的文字，幫助理解。

另外，你也可以上 Google 免費的線上課程，還有免費 Lab 可以做喔！這樣比較有感覺，不然你可能會不知道你到底在讀什麼。

https://www.cloudskillsboost.google/paths/12

如果你對 GCP 已經有基本的了解，那建議你直接找題目來看就好，不要再浪費時間看文件。

有人直接在網路上分享題目，各位請點擊下面這篇文章，裡面有提到相關內容，分享給大家：
https://medium.com/chouhsiang/%E5%BF%85%E9%81%8E%E7%A7%98%E8%A8%A3-%E4%B8%89%E5%A4%A9%E9%80%9A%E9%81%8E-google-cloud-professional-cloud-architect-524405687711

對於這位大神的標題「三天通過」，我建議大家看看就好，像我當年第一次、第二次考 Cloud Architect 都沒過，直到考第三次才過，三次加起來的準備時間也快一年。

即使我現在要再考 Cloud Architect 證照，絕對不是只要花三天就夠了，這是我當初考很多次才過關的證據。

每個人的學歷背景、學習狀況和際遇各有不同，不要看人家很會考就懷疑自己的能力。各位按照自己的步調來準備就好，不要被他影響。

反過來說，如果你是缺乏驅動力，經常拖延的人，那也有一個辦法，就是先報名考試，卡刷下去，你就會開始積極準備考試了 XD。

當然你也可以報名我的 GCP 課程 來學習比較快，置入一下 XD。

Google Cloud Architect 證照考試報名方法

考試報名的網站：

https://cp.certmetrics.com/google/en/home/dashboard

你在註冊時要注意，姓和名要用「護照名稱」，不要用小名像是 Peter 或 Helen 這種，要不然無法核對護照，不給你進考場喔！

這個網站裡面有一個 Access Webassessor，就是去報名考試的地方：

https://webassessor.com/googlecloud

當你進入網站之後，點擊 Register For An Exam，選得要選英文的喔。

然後不要選 Pilot and Beta Exam，它通常是針對「即要大改版的」證照所提供的考試。對 GCP 很熟悉的人才適合去考，像我也不太敢考 XD。

接著選你要去考場考試，或遠端考試。

如果是考場考試，你要把報名完成通知單印出來，還有身份證跟護照，給考場人員檢查。

如果你選遠端考試，你要在你的電腦安裝一個考試軟體，它不是只有出題目而已，它會拍你的考試畫面，避免你作弊。

接下來選考場

然後選擇考試時間，要注意，盡量不要在 12 月到 1 月之間考試，因為……他們都休假去了！！

這是我 2024/12/23 要報名時看到的畫面：

因為我已經讀完了，不可能讓我一直拖到 1/14，所以我就被迫第一次用遠端考試。

當我切成遠端，能選的時間就變多了。

接下來就是付款了，你會看到如果你是要 Renew 延長證照的話，CertMetrics 網站有提供優惠碼，讓你半價就可以考試。

更重要的是，你的姓跟名不要打錯位置，我有一次打錯 (Chrome自動填入)，它刷卡後直手接跳回首頁，沒跟我說我報名成功還是失敗。

當時沒注意到我姓跟名打相反，前後按了三次，第四次才發現我打錯，趕快改回來再刷卡，結果我前三次一樣被扣款，總共扣了四次。

害我後來跟考試網站的客服人員，以及銀行客服人員花好幾天，前後盧了十幾個小時，才終於拿回退款。

最後回到首頁，安裝考試軟體。

開始遠端考試

考前進入網站，剛開始考試連結還不會出現，等就對了，15 分鐘前才會有連結讓你點進去考試：

接下來就不秀畫面了，那些算是機密的範圍。

它會有一個對話視窗，除了驗證身份，還要你舉起電腦的 Web Cam，拍攝你考試場地的四周，確保你的環境很乾淨，沒有其他人，沒有作弊嫌疑。建議各位提早驗證，因為……非常耗時，我弄了半個多小時才真正開始考試。

遠端考試中途不能去上廁所，考場考試可以但時間會照算。

考完會告訴你 Pass 或 Fail，但不會告訴你幾分，也不會跟你說哪題對哪題錯。

過兩天 Google 會再發一封正式的信，確認你真的考過了。

以上分享，祝你考試順利！！

The post [GCP 證照] 轉職必備 Google Professional Cloud Architect 雲端架構師證照介紹、考試心得與準備方式 first appeared on 東東 GCP 教學 - GCP 實戰講師.

一、前言：為何要將主機搬遷上 GCP？

其實將主機搬遷上雲的理由和好處很多，這裡提供三個最重要的理由如下：

(一) 降低成本

GCP 是每月依使用量計費，每月付款，企業可以從一次性大額採購的「資本支出」，轉變成每月的「費用支出」，減低現金流的壓力。

此外，實體機要考慮機房、水電相關設備的建置和維護成本，在管理上也是耗費不少心力。

而公司採用雲端，等於就是把基礎建設外包給專業的 Google，你可以省下許多寶貴的時間，然後專注在開發公司產品或提供服務，為公司創造更大的價值。

(二) 彈性擴充

在地端，你的機器數量是固定的，如果碰到活動期間，需要緊急擴充機器，往往要走採購流程包含詢價、議價、選商，以及後續的安裝建置，等到機器準備好了，活動都結束了。

而在雲端上有所謂的自動擴充 (Autoscale)，你可以在 GCP 主控台上設定擴充的功能，指定要擴充的數量，接著 GCP 會依照當前主機的負載，如果主機太過於忙碌，GCP 會立即增加主機來對外服務。當活動結束，人潮退去時，機器也能自動縮減，不會讓它閒置導致額外的花費。

(三) 創新整合

和其他公有雲相比，Google 的強項就是大數據分析與人工智慧。如果你的系統在 GCP 上運作，可以輕易導出資料到 BigQuery 來分析，發現洞察。你也可以將資料用來訓練模型，開發 AI 應用程式。不需要尋找外部工具，從頭到尾都在 GCP 做完。

當你開發完成，也可以直接在 GCP 上部署 AI 應用，或是做為  API 讓外部來呼叫，這些都是 GCP 內建的功能，讓你從收集資料、開發模型、測試模型到部署 AI 應用，都可以透過 GCP 來達成。

從商業的角度來看，就是加速你回應市場的速度，當市場上有新的技術或是新的商機出現，你就可以快速的在 GCP 取得各種創新資源，讓你可以快速的開發出應用程式，提供給廣大的使用者。 

以上只列出常見的上雲理由，如果你想知道更多，可以參考《企業上雲的10大理由、15個評估面向與6大好處》和《上雲比較貴？雲端和地端的成本詳細比較》這兩篇文章。

二、主機搬遷類型

將主機搬遷上雲有很多方法，我們可以依照系統的狀況 (例如好不好搬遷)，和公司的時間表 (有沒有急迫性或是足夠的人力) 來選擇適合的搬遷類型，這裡分別介紹如下： 

(一) 更換主機 (Rehost)：照原來樣子搬遷 (Lift And Shift)

這種搬遷方式就像是單純的搬家，把所有東西從舊環境搬到新環境，期間只做最少必要的調整。就像是把傢俱從舊房子搬到新房子，只需要因應新房子的格局做一些微調而已。

當你的系統可以直接在新環境運作，或是當業務上沒有需要對系統做太多更改，又或者當你需要快速完成搬遷時，這種方式就特別適合。

這種方式的優勢在於執行起來最簡單，團隊可以繼續使用熟悉的工具和技能，而且支援現成的軟體，最重要的是搬遷速度最快。

但這種方式也有其侷限性，系統無法充分發揮雲端環境的優勢，也無法善用 GCP 的特殊功能，包括自動擴充的能力、更靈活的計費方式。這就像是把老房子整棟搬到新地點，雖然可以快速入住，但無法享受新社區提供的現代化設施。

不過企業會因為各種因素，不得不採用這種方式，例如程式碼太老舊或複雜而不容易修改，或是重新編譯程式很困難，又或者必須持續維持系統運作而沒辦法停機重做。

(二) 更換平台 (Replatform)：重新優化 (Lift And Optimize)

想像一下，這不只是單純的搬家，而是搬家時順便整修。就像是搬到新房子時，不只是搬運傢俱，還會順便更換一些老舊的設備，或是重新規劃空間跟裝潢，讓新家更好用。

把主機內的系統搬到 GCP 上，讓它能用上更新、更有效率的工具和服務。這種搬遷方式最適合那些希望充分運用雲端核心功能的組織，包括彈性運算能力、系統備援、提升效能和加強安全性等優勢。

舉例來說，你可以將應用程式轉移到 GCP，以便使用 Google Kubernetes Engine 提供的微服務架構或容器服務。這樣一來，系統在雲端運行時就能發揮更好的效能和效率。

不過呢，這種搬家方式當然會比單純搬家麻煩許多。因為新環境的設備和系統都不太一樣，所以需要多花時間測試、調整，確保所有東西都能完美運作。就像是要學習使用新家裡的各種 AI 電器，需要一段適應期一樣。

(三) 重構 (Refactor)：徹底改造升級 (Move And Improve)

重構這種搬遷方式就像是趁搬家時，不只是簡單改裝，而是徹底翻新改造，讓系統能充分運用雲端的各種優點，已經不是針對「主機」來搬遷了。你可以針對效能、功能、成本和使用體驗，把每個部分都改造得更好。

這個改造工程可以選擇在搬到雲端時一起進行，也可以提前先做好。就像是裝修房子，如果你是第一次做大規模裝修，可能會想等搬家時再一起處理。但如果你有經驗，就能提前規劃好需要改造的部分，讓系統更好地運用雲端的功能。

有時候你會被迫選擇重構，因為舊系統的架構可能無法直接在新環境中運作。又或者是趁這個機會，你想要對系統做一次大規模的更新和改進。

重構的好處是你的系統可以充分運用雲端平台的特色，例如自動擴充 (Autoscale) 的功能，或是提高系統的穩定性。你還可以讓系統變得更容易在不同平台間轉移。

不過呢，重構需要花比較多時間，畢竟要把整個系統重新改造一番。而且你的團隊可能需要學習新的技術和工具，就像是要學習使用全新的裝修工具和材料一樣。

(四) 重新設計架構 (Re-architect)：全面改頭換面 (Continue To Modernize)

這種搬遷方式和前面說的重構有點像，但更加徹底。它不只是改變系統程式碼的運作方式，而是完全重新設計整個系統的運作模式。

這就像是不只是翻修房子，而是把整棟房子拆掉重建，讓它能充分運用新環境的優點，像是更好的擴充性、安全性和靈活度。

最經典的例子就是從單體式架構（Monolithic）轉換成微服務（Microservices）架構。單體式架構就像是一間大型百貨公司，所有部門（功能）都在同一棟大樓裡，所有服務都綁在一起，任何一個小改動都要動到整個系統。並且擴充時必須整個系統一起擴充，如果有一個地方出問題可能影響整個系統。

而當我們改成微服務架構後，就像是把大百貨拆分成許多專賣店，每個服務都是獨立的小系統，可以個別更新和維護，當需要擴充時，可以只擴充需要的服務。

某個服務出問題時不會影響其他服務，不同的服務可以使用最適合的技術，不一定都要使用虛擬機器，有的可以用 Cloud Run，有的可以用 GKE。

不過要注意的是，這種全面改造比一般的重構更複雜，需要投入更多時間和心力。而且在重建的過程中，可能會不小心引入一些程式錯誤或安全漏洞。

因此，需要進行多次測試，確保新系統的每個部分都能完美運作，就像是新蓋好的房子需要仔細檢查每個管線和設備是否安全可靠。

(五) 重建 (Rebuild)：完全推倒重來 (Remove and Replace or Rip and Replace)

重建就是重寫，就是先把現有的系統停用，然後重新設計並開發一個完全針對雲端優化的全新系統。

什麼時候會選擇重建呢？通常是在這些情況：

• 當你覺得舊系統已經不值得繼續維護
• 當其他改造方式的成本太高
• 當舊系統根本無法在 GCP 上運作

重建的好處是，新系統可以完全發揮 GCP 的優點，像是自動擴充、完整的雲端服務支援，以及超高的系統穩定性。而且因為是從頭開始，你不用被舊系統的技術包袱拖累。就像蓋新房子可以使用最新的建材和設計，不用被舊房子的格局限制。

但是呢，重建需要最多的時間，比其他方式都久。而且因為要重寫整個系統，所以不適合用在現成的軟體上。你需要把重新設計和重寫的時間都算進整個專案的生命週期裡。

另外，你的團隊可能需要學習全新的技術和工具，因為要用新的工具來設定環境並部署系統。這就像是要學習使用全新的建築工法和工具來蓋房子一樣。

(六) 重新購買 (Repurchase)

這種方式最簡單，就像是不想修理舊電器，直接去買新的雲端服務來用，其實就是不搬遷了，直接買新的來用。

舉例來說，與其維護公司自己的郵件系統和檔案系統，不如直接改用 Google Workspace (就是 Google 的企業版 Gmail、雲端硬碟等服務)。

從資源投入的角度來看，這種方式比重構、重建或重新設計架構簡單多了。就像是比起修理老舊的冰箱，直接去買一台新的智慧冰箱來用比較不費心。

不過要注意的是：

• 這種方式的花費可能比較高，因為要持續付費使用服務
• 你可能無法完全掌控系統，因為是用人家現成的服務，就像是租用別人的設備，雖然方便，但無法像自己的設備那樣隨意改造和調整，自由度比較低。而且有可能會被綁住，沒有辦法輕易更換系統，或是匯出資料。

綜上所述，我們可以把各種搬遷類型整理如下：

如果想完整了解搬遷類型，可以參考這份文件。

三、主機搬遷步驟

根據 GCP 官方部落格提到，搬遷的步驟如下圖：

(一) 盤點 (Assess)

在進行搬遷之前，請評估您的應用程式以及它們對 GCP 的適合程度。

需要考慮的事項包括 (但不限於) 硬體和效能需求、使用者、授權、合規性需求和應用程式相依性。

一般來說，應用程式大概分種三種：很好搬、很難搬和不能搬。通常建議先選最好搬的，或是測試中的系統，或是較不重要的應用程式，因為搬遷中碰到問題，畢竟不是核心系統，對公司影響較小。

(二) 測試 (Pilot)

這步驟主要是讓你在搬遷過程中熟悉整個操作流程和 GCP 的搬遷介面，對於複雜的系統也可以測試，尤其是有授權議題的主機，如果搬遷有問題也可以試著回溯 (Roll Back)，確保到時候正式搬遷會有一個 (Plan B) 備用計畫。

(三) 搬遷資料

根據Google官方的說法，建議先搬遷資料到 GCP，再搬遷應用程式，因為你的應用程式要能正常運作，必須要先存取到資料，否則應用程式即使搬上去，因為它撈不到後端的資料，還是會出問題。

在下一段會先分享搬遷主機的方法，你可以先試著搬遷不需要連接外部資料庫的主機，確認都沒問題的話，再搬遷資料庫，最後再搬遷應用程式。

(四) 搬遷應用程式

正式搬遷的時候，盡量保持用最簡單的流程和方法，並且執行最少的操作。 

(五) 優化

在搬遷完成之後，你可以考慮讓你的系統運作的更好。例如增加可用性 (HA)，或是使用自動擴充 (Autoscale) 以及使用監控程式 (OPs Agent)，或是把靜態資料放在 Cloud Storage。

而在實務上，我們通常不會等到搬遷完成才開始優化，而是在搬遷之前，就會依照應用程式的特性，來判斷他適合在什麼樣的 GCP 服務上面運作。前面規劃的越多，後面花在調整的時間越少。 

如果想完整了解搬遷步驟，可以參考這份文件。

四、主機搬遷具體方法

由於大多數使用者在地端運作的系統，都是單台虛擬機器的形式，本段針對大家最常用的「更換主機」 (Rehost) 這一類型，依照使用的工具，分成 Migrate to Virtual Machines 和 VMware HCX 來說明如下。

(一) Migrate to Virtual Machines

Migrate to Virtual Machines 是一個代管的服務，就是一個網頁介面，讓你可以直接在網頁上操作並監控整個搬遷的過程，操作起來非常簡單。

你可以直接匯入主機的映像檔，也可以讓主機平行運作，就是讓地端主機還在運作的同時，複製主機的資料到 GCP 上，複製並確認完後再進行切換動作。

如果你有大量主機要搬遷，你不用一台一台機器手動設定搬遷，你可以把多台主機設定為同一批次，讓他們同時複製資料到 GCP。

不過要注意的是，並非任何作業系統的主機都可以搬遷，目前支援各種 Linux 和 Windows Server 作業系統的 64 位元 x86 虛擬機器，另外也支援 Oracle Linux 作業系統。

但是要注意版本，像是太舊的版本像是 CentOS 6 雖然可以搬上 GCP，但是主機有問題，GCP 是無法提供技術支援的喔！對於支援的作業系統完整清單，可以參考這份文件。

以下分別描述 Migrate to Virtual Machines 各種搬遷方法：

1. 匯入主機檔案

(1) 匯入虛擬機磁碟映像檔 (Virtual Disk Images)

如果你手上有現成的虛擬機磁碟映像檔，可以直接匯入，完成之後可以馬上用這個映像檔，在 GCP 建立和地端一樣的虛擬機器。

虛擬機磁碟映像檔支援的格式包含：VMDK、VHD、VHDX、VDI、QCOW、QCOW2、QED 等，也支援 .tar.gz 檔案，你要確保壓縮檔案包含名為 disk.raw 的單一檔案。

不過要注意的事，這個虛擬機磁碟映像必須要先儲存在 Cloud Storage，所以你必須要先上傳檔案，然後再去 Migrate to Virtual Machines 的主控台上匯入它。

而在匯入之前，由於 Migrate to Virtual Machine 這個服務背後是有一個 Service Account 在運作，而它目前沒有權限去 Cloud Storage 存取任何檔案，所以我們就先去給它賦予權限。

我們進入「IAM 與管理」=>「身分與存取權管理」=>再勾選「包含 Google 提供的角色授予項目」：

接著視窗往下滑，會你看到像這樣的 Service Account：

service-xxxxxxxxxx@gcp-sa-vmmigration.iam.gserviceaccount.com

接著點擊 VM Migration 服務代理右邊的鉛筆圖示：

接下來就可以把你準備好的 VMDK 檔案上傳到 Cloud Storage：

上傳完成之後，你就可以點擊 Compute Engine 的 Migrate to Virtual Machines。接下來可以點擊「映像檔匯入作業」：

接著再點擊「建立映像檔」：

接著它就會進入建立映像檔的畫面，首先就是在 Cloud Storage 選擇要匯入的檔案，接著由於虛擬機映像檔會轉換成 GCP 格式的映像檔，所以我們要另外選擇儲存的位置，看你要多區域 (例如 Asia) 或是單一區域 (例如 asia-east1) 都可以：

當我們選好檔案跟儲存位置後，再選擇要儲存映像檔的專案，因為你手上可能有不只一個專案，它讓你不一定只能使用現有的專案，可以選擇匯入到其他你有權限的專案。

但你點擊下拉選單之後，你會發現沒有目標專案可以選，因為它必須要事先勾選起來，才會在這個畫面看到可以選擇的專案。但是沒關係，我們也可以在這裡直接設定，點擊「管理目標專案」：

點擊之後，它會開啟新的視窗，我們再點擊「新增目標專案」：

接下來它會彈出一個視窗，讓你勾選目標專案，我們勾選後就按下新增：

接著畫面會跳轉到目標專案，你可以再確認一次：

再回到原來的分頁，按下「重新整理」：

等待幾秒之後，專案就秀出來了，選擇這次要建立映像檔的目標專案：

上述相關欄位設定好之後，會看到像這樣的結果。其中還有兩個選項需要注意。

(1) 略過 OS 調整作業：

指的是為了讓你在地端的主機可以在雲端上運作，它需要做一些調整，才能讓它在 GCP 上開起來。包含：

・Serial Console (讓你在SSH無法連線時還能操作主機)

・網路設定 (讓主機可以連到 VPC 內的主機、其他 API 和上網) 

・Cloud SDK (讓你可以下 gcloud 指令操作 GCP的資源)

如果你匯入的映像檔不是拿來當作開機碟，那可以勾選「略過 OS 調整作業」，如果是，就不能勾選，要不然主機會無法在 GCP 成功開啟。更多細節可以參考這份文件。

(2) 一般化：

通常是針對 Windows 作業系統，因為 Windows 作業系統會有一些「針對該主機的識別資訊」，例如 SID (Security Identifier)，勾選「一般化」可以將其識別資訊洗掉，以便部署到其他地方，才不會有識別碼衝突的問題，而 Linux 沒有這方面的問題，不用勾選。更多細節可以參考這份文件。

如果都沒問題的話，可以按下「建立」：

接下來畫面跳轉到 Migrate to Virtual Machines 主頁，看到正在匯入映像檔的訊息：

我們等待一下，因為這個動作都在 GCP 上進行，我們可以關掉視窗，稍後再回來查看即可。

接著我們就看到 VMDK 檔案已經匯入成功，看到它已經成為 Compute Engine 的 Image 了。

接下來我們可以直接點擊箭頭圖示，直接轉到 Image 的頁面：

然後點擊「建立執行個體」，把它開成一台 GCP 的主機：

就跟一般建立機器的步驟一樣，我們給主機取名字，並選定規格：

其他參數可依照你的需求設定，沒問題就可以按下「建立」。

過幾秒後看到主機建立完成，我們點擊 SSH 按鈕：

看到 SSH 視窗成功開啟，代表我們從地端匯入 VMDK 檔案成功囉！

如果你的機器能開機，但是連不進去的話，先不要慌，你還是可以透過 Serial Console 調整一下主機，可以參考這份文件。

(2) 匯入機器映像檔 OVF, OVA

這個方法跟前一個幾乎一樣，都是先把檔案上傳到 Cloud Storage。但不同的地方是，前段的映像檔只有開機磁碟而已，如果你的主機有加掛磁碟的話，你就必須再匯入另一個映像檔，等到兩個映像檔都匯入完成，再用第一個映像檔來開機，再手動掛載另一個映像檔的磁碟。

機器映像檔則是直接包含一台主機所有的磁碟，如果你匯入機器映像檔，你就不用手動匯入多個檔案了。

首先我們點擊「建立機器映像檔」：

我們一樣設定作業名稱、來源、部署區域、目標專案等等，沒問題就按下建立：

接著就等它開始作業，我們可以在畫面上確認機器映像檔匯入的進度：

確認匯入成功後，一樣進入機器映像檔管理控制台，用機器映像檔來建立機器：

我們在主機列表看到機器成功建立，接著點擊 SSH 按鈕：

接下來就看到 SSH 連線成功的畫面，確認匯入成功。

關於匯入映象檔或是機器映象檔，還有一個更簡便的方法，不過它是使用 gcloud 指令來操作 你可以參考這份文件。 

上述方法最容易卡住的地方，就是我們要匯入的檔案有問題，可能是作業系統或是檔案格式的問題，造成匯入失敗的機率很高，所以請再匯入之前多確認映像檔的內容。

2. 從地端 VMware 環境搬遷主機或 Disk

這個方法的前提是你在地端必須要有一個 vSphere 資料中心，然後再搬遷之前會有一系列的前置作業，讓你的地端和雲端可以連接在一起，之後才能開始搬遷，如下圖：

雖然比較麻煩，但是它可以針對大批的主機一口氣快速搬遷，而不是像上述方法一台一台操作。

此外，因為主機是在 VMware 環境，搬遷到 GCP 有比較高的相容性，所以這個方法成功率高很多。 如果你在地端有大量的主機需要搬遷，強烈推薦使用這種方法。

搬遷的前置作業分述如下：

(1) 挑選一個主要專案 (Host Project)

如上圖，我們在雲端上有多個 GCP 的專案，你可以挑選一個主要的專案 (Host Project) 來負責執行搬遷工作，但是你搬上來的主機不一定要部署在這個專案上，你也可以部署到另外一個專案上去。

(2) 啟用相關的 API
由於搬遷過程中會呼叫 GCP 各種不同的 API，所以我們要事先啟用，這裡提供一個快速的指令，讓你可以直接複製貼上，然後在 Cloud Shell 或是你有安裝 gcloud CLI 的電腦執行：

gcloud services enable vmmigration.googleapis.com servicemanagement.googleapis.com servicecontrol.googleapis.com iam.googleapis.com cloudresourcemanager.googleapis.com compute.googleapis.com

(3) 授權給相關人員

如果有許多人員要參與搬遷，你可以授權這兩個角色給相關的人員：

VM Migration Administrator：是給執行搬遷的人員使用。

VM Migration Viewer：如果其他的人想要查看搬遷的相關資訊，不直接動手操作。

(4) 在 vCenter 建立使用者帳號

因為我們會在 vSphere 建立一台主機，並且安裝 Migrate Connector，而這個 Migrate Connector 需要有一個使用者的帳號，並且要擁有相關權限，才能夠呼叫  vCenter的API，去把 VMware 主機的資料拉出來並且搬到雲端上。

(5) 在 GCP 準備一個使用者帳號和服務帳戶

這個使用者帳戶必須要有權限，才能註冊 VMware 上的 Migrate Connector 主機到 GCP。它只有在註冊的那一刻需要相關的權限，只須執行一次性的註冊動作。

而在 GCP 上面也要有一個服務帳戶，用來存取 19 項 GCP 資源，來完成搬遷的動作。 如下圖：

(6) 設定網路存取

在 GCP 這邊，因為都是開放的 API，比不需要特別再去設定，反而是地端那台 Migrate Connector 主機，要確保網路流量可以存取得到 vCenter、vSphere 和上網存取 GCP 相關服務。如下圖：

如果防火牆也有限制，要記得開放存取到 *.googleapis.com 和 gcr.io 這兩個網域喔！

(7) 建立連線到 Migrate Connctor 所需的 Key

為了要安全的連到 Migrate Connctor ，你必須建立一組金鑰，等到這台機器建立完成，你就要透過這個金鑰連線進去操作。你可以在任何地方使用 ssh-keygen -t rsa 這個指令來建立金鑰，如下圖我們是用 Mac 本機電腦來建立的：

(8) 安裝 Migrate Connctor
接下來環境切換到 vSphere，點擊 Deploy OVF Template 然後貼上 Migrate Connector 機器映像檔的網址：

接下來等它安裝完成，看到主機的資訊如下：

(9) 連線到 Migrate Connector 主機並註冊到 GCP 

我們使用 SSH 連到 Migrate Connector 主機之後，輸入 m4c register 開始註冊，經過一連串的互動操作，可以看到註冊成功的畫面：

我們回到 Console 上就會看到地端的機器列表，這時我們就可以選定要搬遷的主機：

雖然是將主機一模一樣的搬到 GCP，但是我們並不一定要使用一模一樣的規格，我們可以設定部署的規格跟環境：

接下來就開始進行資料複製的動作，等到複製完成，我們可以先點擊「Test-Clone」，來觀察資料是否都複製完成，它會建立一台測試機，讓你進去檢查。如果確定都沒問題的話，我們再點擊「Cut-Over」 ：

最後我們可以在 Console 上看到主機切換完成的相關訊息：

這裡要注意的是，它的「切換」會把原來的地端主機「直接關機」，如果你不希望機器被關，目前的方法就是再手動把它開起來。 

很多使用者會藉由這個功能，執行雲地資料同步的動作，不過不算正規方法，所以沒有備份的保證喔！只是因為做起來很方便，單純分享給各位參考！

(二) VMware HCX 

GCP 本身可以建立一個純粹的 VMware 環境在雲端，叫做 VMware Engine，而這個環境可以和地端的 VMware 環境連結在一起。既然兩邊都是 VMware，就可以使用 VMware 本身的 HCX 將地端的主機無縫的搬遷到雲端上，但不是 Compute Engine 主機的形式，而是 VMware 格式的主機。

所以它具體的搬遷方法是由 VMware 所發展的， GCP 就只是提供基礎建設，讓 VMware 可以在 GCP 上面順利運作，整合概念圖如下：

而這樣的服務要在 GCP 上開起來，必須要使用通過 VMware 認證的主機，我們可以從「VMware Engine」進入「私有雲」，然後點擊「建立私有雲」 ：

接下來你會發現台灣 (asia-east1) 並沒有提供這樣的環境，VMware Engine 離台灣最近的資料中心在新加坡 (asia-southeast1)：

另外我們在設定節點數量的時候，系統會要求至少要三個節點以上，而每個節點的規格是 72 個 vCPU和 768 GB 的記憶體，以及1.92 TB 的 Disk 空間，可以知道它的費用不低，有一定規模的跨國企業才有機會使用這樣的服務：

我們在 YouTube 看到有人示範 HCX 操作的畫面，功能和 Migrate to Virtual Machines 很像，首先就是勾選要搬遷的主機：

接著我們就設定主機要搬遷的目的地：

在設定的過程當中，也可以設定目的地的主機規格和環境參數，你還可以設定搬遷的排程，例如在幾月幾號的幾點開始搬遷。

開始搬遷之後，你也可以在畫面上看到搬遷的進度：

關於更多 HCX 的操作細節，可以參考這份文件。

另外這樣的規模通常都不小，我們可以聯絡代理商或是 Google 原廠，來提供相關的技術服務喔！

五、結論

最後我們總結從地端搬遷主機到 GCP 的方法，整理比較表如下：

不管你是哪一種企業規模或是場景，都建議你先從匯入映像檔的方式開始，不是真的要你在正式搬遷都用這個方法，而是要你藉由這個動作，去熟悉整個搬遷的流程、細部操作和相關的注意事項，讓你了解搬遷過程的全貌。

這樣才能在正式搬遷之前，做好完整的評估和規劃，和搬遷失敗的處理方式，讓你確保在公司系統照常運作，影響最小的前提之下，讓搬遷順利成功。

本文同時刊登於：

【東東老師 X 思想科技】地端主機如何搬上 GCP？（上）

【東東老師 X 思想科技】地端主機如何搬上 GCP？主機搬遷具體方法（下）

The post [GCP 教學] 地端主機如何搬上 GCP？各種方法和步驟詳解 first appeared on 東東 GCP 教學 - GCP 實戰講師.

你可以管理這個專案中的所有資源，愛怎麼用就怎麼用。

但如果你今天是在一家公司裡，一個專案可能會跟同事或其他部門的人一起使用， 如果企業夠大，有專業分工，甚至會有管理網路的、管理主機的、管理負載平衡的、還有專門管理帳單的人。 

所以我們就必須切分成不同的權限，讓大家各司其職的同時，不影響其他人的操作，也能兼顧資訊安全，這就是為什麼我們要了解 Cloud IAM。

一、Cloud IAM 簡介

(一) Cloud IAM 是什麼？

Cloud IAM，全名 Cloud Identity and Access Management，直譯為身份和存取管理。

就是 GCP 的角色和權限管理系統，管理「誰」可以進入「某個區域」做「什麼事情」。

由此可知它有三個元素：

1. 「誰」指的就是一個身份

又叫做「主體」(Principal)。

2. 「某個區域」就是「資源」

像是 VM、Disk 或 Cloud Storage Bucket 都是資源。

3. 「什麼事情」指的是具體的操作行為

也就是細分的權限，例如建立 VM、修改 VM 參數、讀取 VM、刪除 VM 等等。

所以 Cloud IAM 就像是 GCP 的門禁系統，確保「對的人」可以存取「對的資源」，並且只能進行「被允許的操作」。

(二) Cloud IAM 有什麼前提？

這裡指的是 Cloud IAM 可以管理的帳號，分成以下幾種狀況：

如果你本來就是使用 Gmail 或是 Google Workspace，當你啟用 GCP 的環境，你的帳號就可以直接用在 Cloud IAM。 

如果你使用的不是 Google 的帳號，例如你可能使用微軟的 M365，或是其他的郵件系統，你會看到像這樣的錯誤訊息：

代表這並不是一個 Google 帳號，你就必須要申請 Cloud Identity，讓你能夠建立 Google 的帳號， 這樣就可以使用 Cloud IAM 了。

而可以被授權 Cloud IAM 角色的對象我們稱為主體 Pricipal，而這個主體並不是只有帳號，還包含了 Google Group (群組)，還有 Service Account (服務帳號) 跟網域，這些都是都是可以在 Cloud IAM 裡面，被賦予角色權限的對象。 

二、Cloud IAM 的角色與權限的介紹與運作方式

(一) Cloud IAM 的角色與權限的關係

在 GCP 的專案環境中，每一個對資源的操作，有可能包含一個以上的權限，像是建立一台 VM，可能至少包含以下權限：

• compute.instances.create  (建立 VM)
• compute.disks.create (建立開機磁碟)
• compute.networks.use (讓 VM 連接到某個 VPC)
• compute.subnetworks.use (讓 VM 連接到某個 Subnet)
• compute.images.useReadOnly (使用一個作業系統的 Image，例如 Ubuntu)

而目前在一個 GCP 專案中，截止目前 (2024年11月21日)，已經有超過 10000 個細分權限，如果我們直接設定這 10000 個權限分配，應該會設定到懷疑人生。

而且這個權限數量，還隨著 GCP 新推出的服務持續增加當中。以專案擁有者，幾乎擁有全部的權限數量如下：

為了簡化管理，GCP 把相關的權限群組起來，依照使用的場景或是執行的操作， 劃分成不同的「角色」 ，這樣我們就能方便地管理大家的權限。 

補充一下，GCP 的帳單角色，不直接屬於專案，而是和帳單帳戶 (Billing Account) 綁定的，運作方式有些不同，未來會再專文討論。

(二) Cloud IAM 的角色類型

Cloud IAM 的角色有三大類，分述如下：

1. 基本角色 (Primitive Roles)

之所以叫「基本」，就是以簡單粗暴的方式來劃分權限，許多小公司或個人使用者都是用這類的權限，就是因為簡單，我們從權限由大到小說明如下：

(1) 擁有者 (Owner)

當你第一次進入 GCP 主控台，GCP 會用你的身份來建立一個專案，而你就是專案的擁有者。

你擁有在這個專案裡全部的權限，看得到所有資源和資料，也可以任意更改，你也能夠管理任何帳號被分配的角色和權限。

(2) 編輯者 (Editor)

編輯者能看到專案內所有資源的內容，也都能修改，像是開機器、關機器、建立負載平衡器，這些都做得到。

編輯者和擁有者的權限很接近，就差在不能管權限，你沒有辦法授權別人進來這個專案，或者是把某個成員踢掉。

(3) 檢視者 (Viewer)

檢視者在這個專案裡面的東西，你全部都可以看，可是你不能改，但是全部都看得到，權限也是蠻大的。

你可以看到專案內開了幾台機器、所有的 Cloud Storage Bucket 都能點進去看儲存了哪些檔案、 BigQuery 裡面有哪些表格和裡面的資料，全部都看得到，甚至可以下載到你的電腦上。

(4) 瀏覽者 (Browser)

瀏覽者的權限是最小的，它只能讓你知道，手上有一個專案叫做 dong-dong-gcp-4-cloud，並且能夠進入資訊主頁，看到這個專案的基本資訊，僅此而已，但裡面所有資源的內容都完全看不到。

2. 預先定義的角色 (Predefined Roles)

由於基本角色的權限劃分比較簡單粗暴，方便好用，但這種方式給出的權限都有一點太大了。

對於公司規模較大，在部門專業分工的情境下，就可以使用預先定義的角色。 這種角色就是依照使用者在公司賦予的任務之下，授權相對應的權限。 

例如：

(1) 只管虛擬機器的人，就可以給他執行個體管理員 (Compute Instance Admin)；

(2) 管理 VPC 和 Subnet 的人，可以授予 Compute Network 管理員；

(3) 管理防火牆的人可以授予 Compute Security 管理員； 

(4) 管理上述全部的人，可以直接授予 Compute 管理員；

(5) 而管理整個專案資訊安全的人，卻又不管理虛擬機器和網路的人，可以授予 Security 管理員。 

這樣感覺很複雜，我們整理如下表：

你可以看出，每個權限都可以縱向擴充 (網路相關權限包含資安)，或是橫向擴充 (資安相關權限包含網路)。

而且不是只有管理員，GCP 的每一個服務也都能再細分成編輯者和檢視者。

而且上述只針對虛擬機器和網路，GCP 還有各種服務如 Cloud Storage、Cloud SQL 和 BigQuery，各自又區分出不同的角色。由此可見，角色區分地非常細。 

只要公司有對於權限或資安有較高的標準和規劃， 都可以依照分工和職責去給予不同的角色。 但反過來說，也會需要專人來負責管理權限劃分，以免造成授權混亂的情形。

3. 自訂角色 (Custom Roles)

因為預先定義的角色是用服務或屬性來劃分每個角色擁有的權限， 但是如果一個人的職責橫跨不同的服務，例如他同時管理虛擬機器和 Cloud SQL 資料庫，你就必須同時給予兩種角色，或是使用一個自訂角色配上相關的權限。 

這種方式可以對每個人的權限做最細緻的管理，做到「剛好必要」的權限分配。但這就需要一個專門的人員，除了了解 GCP 的每一項操作產生的結果，也要知道該行為涉及哪些權限。

因為當這個制定角色開通並且授權出去之後 ，使用者可能會在過程中會發現提出某個功能的操作權限不足，然後再回報給自訂角色管理人員， 來來回回重複確認和測試，並且調整權限，過程會很耗時。 

而且這個過程很有可能是會持續發生的，隨著使用者對於 GCP 的操作越來越深入或廣泛， 所以會持續提出增加權限的需求。 

同時  GCP 的服務也會持續的成長，每個服務的功能也會越切越細，導致新的權限不斷產生，然後再持續調整授權。 如果沒有專屬的角色管理人員來處理的話， 很容易讓權限管理變得混亂。 

因此通常建議使用預先定義的角色就好，除非公司專業分工到了極致，再考慮使用自訂角色。

(二) Cloud IAM 的基本授權操作

主選單有一個 IAM 與管理，進去後會直接顯示「身分與存取權管理」的頁面，它會列出在一個 GCP 專案內，所有帳號授權的角色有哪些，如果要授權給新的帳號，就點擊「授予存取權」。

接著在「新增主體」欄位輸入要授權的帳號，選擇要指派的角色，因為角色非常多，要慢慢找，或著是先去「角色」頁面看好要授權的角色，把名字複製起來，貼在角色的搜尋欄位裡面。

有一點要注意的是，如果你今天是授權專案擁有者給別人，系統會發信通知對方，但是其他角色的授權不會發信通知。

所以當你授權其他角色之後，你就把專案的網址直接傳給對方，讓對方方便進入你的專案操作。 

(三) Cloud IAM 角色和權限的繼承機制

上述只提到專案和資源的範圍，而在整個 GCP 的組織架構裡，總共分成 機構 (Organization)、資料夾 (Folder)、專案 (Project) 和資源 (Resource) 四個層級。

權限會從上而下繼承，代表在機構層級授予的角色，會應用到所有資料夾、專案和專案內的資源。

如上圖，如果你在 Team B 資料夾層級授權 Viewer 給同事，他就可以看到 Project 1 和 Product 2 底下所有的專案，以及專案之下所有的資源。

如果你在 Production Project 又授權 Editor 給同事，因為 Editor 角色涵蓋的權限比 Viewer 多，所以會覆蓋原本 Viewer 的權限，同事在專案就擁有 Editor 角色的所有權限。

在專案層級，如果你是在 Test 專案授權 Compute Instance Admin 給同事，他就可以連到 Test 專案裡所有的虛擬機器。

那假如只想給同事連到其中一台機器怎麼辦？

在 IAM 授權的介面中，還有一個條件 (Conditions)，這裡可以設定到最細的資源對象，甚至連授權的時間都可以規範，不過要注意目前還是 Preview 階段，建議多反覆測試再使用，詳細的說明可以參考這份文件。

三、Cloud IAM 設定中常見的注意事項

(一) 遵守最小權限原則 (Principle of Least Privilege)

1. 最小權限原則主要三個基本原則

(1) 使用者只能擁有完成其工作所需的最小權限，也就是剛好必要的權限。

(2) 如果可以的話，權限的範圍和時間都應該最小化。

(3) 預設拒絕所有權限，只開放必要的存取

2. 最小權限原則的比喻

可以想像成一個飯店的房卡系統：

(1) 住客的房卡只能開啟自己的房間。

(2) 清潔人員的房卡有時效性限制，例如從退房期限開始 (中午 12:00) 到新客入住之前 (下午 15:00)。

(3) 經理雖然是主管，但是他也只能進入辦公室區域，不能進入住客的房間。

3. 最小權限原則在 GCP 的正式做法

(1) 優先使用預先定義的角色或自訂角色

(2) 除非真的別無選擇，否則盡量不要用基本角色

(3) 可以使用 GCP 的「角色建議」和「政策模擬」來找出最適合的角色

角色建議 (Role Recommendations) 功能，它是由 IAM Recommender 所產生的，它會主動提示目前授予的角色，是否包含太多權限，確保你能夠遵守最小權限原則，詳細說明可以參考這份文件。

我們在 IAM 的主畫面就可以看到，它提示了某個授權設定包含 9003 個超額權限。

當我們點擊它所提示的超額權限之後，它會秀出建議替換的角色，並且分析權限數量的變化。

政策模擬器 (Policy Simulator) 功能則是讓你在變更某個帳號的角色時，讓你預先確認變更前後的差異。如下圖我把一個帳號從 Secret Manager 密鑰存取者改成Secret Manager 密鑰管理員：

若我們按下測試變更，會看到它模擬變更後會有什麼結果：

要注意它列出來的存取權變更，是根據前面 90 天的操作記錄來分析，如果你像我一樣，90 內曾經刪除過某些資源的話，它就會顯示「狀態不明或發生錯誤的存取權」，所以如果可以的話，最好能夠逐條確認變更後的影響。

(二) 個人帳號務必啟用兩步驟驗證

如果駭客今天不是駭入你的主機或程式，而是直接破解你的密碼，那它就有可能做出任何毀滅性的事情，例如瘋狂開你的機器來挖礦，或開啟殭化電腦去攻擊其他系統，所以這是根本且必要的步驟。

如果可以的話，最高管理員請使用 Security Key，長得有點像隨身碟，以後兩步驟驗證的第二步驟，就可以插入金鑰來驗證。

(三) 設置兩個最高管理員

如果你目前只有專案層級，那就是設定兩位擁有者，為什麼呢？

曾經發生過一家中小企業，老闆要工程師使用 GCP，但工程師用自己的 Gmail 來申請 GCP，而且沒有授權給老闆。有一天工程師離職了，沒有交接 GCP 的專案，直接人間蒸發，老闆從頭到尾都沒有被授權 GCP 專案，等於員工直接帶走公司的重要系統和資料。

如果為此向 Google 提交技術支援申請，Google 基於本身的條款，不會介入任何 GCP 的操作，就是不可能直接把那個專案還給老闆並且把工程師踢掉。

所以第一個方法就是至少要有兩位擁有者，第二個方法則是，不要用 Gmail，而是使用 Cloud Identity 來創建一個機構，如果工程師在專案是擁有者，老闆是機構管理員，還可能把專案的權限拿回來。

同理，如果你是已經有 GCP 的機構層級，那也要設定兩位機構管理員，一方面防止上述情形發生，另一方面則是防止帳號被駭客盜走，至少另一個帳號還有機會阻止駭客。

(四) 善用稽核記錄 (Audit Logs)

GCP 預設會自動記錄每個使用者的操作，如果有人做了什麼異常的行為，都會被記錄起來，但有些 Data Access Logs 預設沒有開啟，你可以評估有哪些重要服務要開啟記錄功能。

要注意額外開啟的 Log 會佔用 Cloud Logging 的儲存空間，如果想要節省費用，可以匯出到其他地方保存。

(五) 在機構層級管理跨專案存取的 IAM 政策

如果你有多個專案，在機構層級設定 IAM 的話，你只要設定一次就好，而不用每個專案都設定一次，如果公司常常新增或刪除 GCP 專案，這樣可以避免有哪一個專案沒設定到。

另外，可以針對部門成員建立群組 (Google Group)，這樣就可以透過群組統一授權，也能避免人員異動，而沒有被授權到相關權限。

最好的方式就是，各個部門都有各自的資料夾，資料夾底下就是部門自己擁有的 GCP 專案，然後資料夾直接分配授權給部門群組，或是主管，這樣就能更方便地管理全公司的 IAM。

四、 Service Account (服務帳戶) 簡介

Service Account 是一種特殊的 Google 帳戶，設計用來代表應用程式或服務，而不是人類使用者。它能夠執行指定的任務並存取必要的資源。

和人類使用的帳號比起來，Service Account 的使用頻率更高，像我們人類平日會上下班，假日會休息，而 Service Account 是和程式綁在一起，全年無休 24小時運作的，因此它更顯得重要，本文特別拉出來單獨說明。

(一) Service Account 的功能和特色

1. 提供應用程式授權，以操作 GCP 資源

Service Account 的主要任務之一是提供授權給應用程式，允許它們存取和操作 GCP 資源。

無論是存取 Cloud Storage 中的檔案，還是對 BigQuery 的表格查詢，Service Account 都能做為應用程式的「身份」，確保只有經授權的應用程式能與資源互動，避免未經允許的存取行為。

2. 基於身份和角色的存取控制

Service Account 在 Cloud IAM 中也是被授權的「主體」，你可以授予任何需要的角色來取得權限，讓 Service Account 能操作 GCP 的資源。

例如，某個 Service Account 可以被授權僅限讀取 Cloud Storage 資料，而另一個 Service Account 能被授權操作 Compute Engine 資源 (例如給 VM 開機或關機)，這種細微的權限控制提高了整體的安全性。

另一方面，上述提到的自訂角色，設定給一般使用者，由於使用者操作 GCP 所需的權限較多，實際執行起來有點麻煩。

但是如果是給 Service Account 使用自訂角色，反而是好的，因為你可以真的只給 1~2 條必要的權限，真正符合最小權限原則的精神。

3. 提供安全的 API 呼叫和資源操作方式

我們人類在 GCP 的任何操作，背後都是 AP 在運作的。而應用程式需要透過 API 與 GCP 服務互動時，Service Account 會以它的身份進行授權並簽署 API 請求。這樣能確保通訊的安全性，避免敏感資料在傳輸過程中被駭客攔截。

而且，Service Account 的 Key 還能進一步加密對 API 的呼叫，提供額外的保護。

(二) Service Account 的運作流程

如下圖所示，Service Account 的運作流程可分為以下四個步驟：

1. 應用程式保存著 Service Account Key 的 Json 格式金鑰檔案，裡面包含 GCP Project ID、Service Account ID 和 Key 的內容。

2. 當需要存取 GCP 服務時，應用程式使用這個 Json Key 來呼叫 GCP 的 API 進行身份驗證。

3. GCP 驗證金鑰的有效性，並確認對應的 Service Account。

4. 驗證成功後，應用程式可以使用該 Service Account 被賦予的角色和權限存取 GCP 服務。

(二) Service Account 的常見使用情境

1. 自動化工作流程

GCP 提供的 CI/CD 工具如 Cloud Build 和 Cloud Run，能幫助開發人員簡化軟體的編譯、測試與部署流程。

這些工具在運作過程中，通常需要訪問其他 GCP 資源，例如讀取 Cloud Storage 中的設定檔，或寫入結果至 BigQuery，此時就必須要使用 Service Account。

Service Account 為這些工具提供授權，確保它們能安全地訪問資源，同時避免人為操作的繁瑣與潛在錯誤。這不僅提高了工作效率，也降低了安全風險。

2. 跨系統間的安全通訊

應用程式通常需要在各個服務之間通訊或傳輸資料，例如從 Cloud Storage 中讀取資料，並透過 BigQuery 分析處理。而通訊必須以安全為首要考量，否則可能導致敏感資料洩露出去。

Service Account 可以充當服務之間的信任橋樑，透過授權的 API 呼叫，Service Account 確保只有經過允許的服務才能執行特定操作。

此外，它還能限制操作範圍，避免過多的權限導致潛在風險，這點非常重要。這樣的安全機制，不僅保護了資料的完整性，也簡化了跨服務整合的流程。

3. 第三方應用整合

在許多情境下，企業需要將 GCP 資源與第三方應用程式串接。例如，某些外部程式需要訪問您的 Cloud Storage 或監控你的虛擬機器的效能指標。為了保障安全，為這些第三方應用創建專屬門的 Service Account 是最好的方法。

專門的 Service Account 能夠以最小權限原則給予角色，只讓它存取必要的資源。同時，這種設計方式也能確保第三方應用與內部服務之間的存取控制是清晰且可管理的。

一旦某個第三方應用不再需要訪問資源，刪除其對應的 Service Account 就可以立即撤銷其權限，提升整體安全性。

(三) 如何建立和管理 GCP Service Account

1. 建立 Service Account

主選單「IAM 與管理」的「服務帳戶」，點擊「建立服務帳戶」。

接下來給 Service Account 命名，建議取一個容易了解的名字，或是設定一個命名原則，在說明欄也寫清楚這個 Service Account 的用途，讓其他人都看得懂。接下來按「建立並繼續」。

接者設定要授予 Service Account 的角色，這個動作在 IAM 的主畫面也可以設定，GCP 在這裡是給你方便一起設定，如果還不確定要授予什麼角色，也可以先跳過。

如果你按「繼續」，下一步驟是把 Service Account 的存取權給使用者，這一步請跳過！！直接按下完成。

你可能會覺得奇怪，這個步驟在做什麼？為什麼要跳過？

因為這個動作是把 Service Account 的使用權給使用者，使用者會取得這個 Service Account 的所有權限，例如使用者原本只有 Compute Instance Admin 角色，只能管理虛擬機器，結果他拿到一個 Service Account 的存取權限，而這個 Service Account 可以存取 BigQuery 所有的資料，等於這個使用者也能看到 BigQuery 的資料。

所以這個動作會讓使用者的權限範圍擴大，違反最小權限原則。

除此之外，使用者透過 Service Account 存取資料，會繞過正常的權限管理機制。因為系統日誌只會記錄 Service Account 存取資料的記錄，追蹤不到實際的操作者是誰，如果發生資安事件，也會阻礙調查。

就像你是大樓的管理員，Service Account 就像是公司的門禁卡，使用者小明是員工，GCP 的服務就像是大樓裡的不同房間。

小明只能進入一樓茶水間和三樓的辦公室，結果你把你的門禁卡給了小明，小明突然可以進入所有樓層，包括機密檔案室！

而大樓的監視器只會拍到「有人用公司門禁卡進出」，但不會知道用門禁卡的人是誰。如果小明把資料帶出大樓，或是銷毀，沒有人會知道是小明做的。

所以這個動作，除非你熟悉會有什麼後果，如果不懂最好不要授權給使用者。

按下完成之後，你可以點擊 Service Account 的名稱，進入它的詳細資訊頁面。

在這裡你會看到專屬 ID，如果你再展開下方進階設定，還會看到用戶端 ID，這些都是機密資訊，不要隨便分享。

尤其是「網域層級委派」，這是一個在 Google Workspace 中的「超級無敵大權限」，它可以看到公司內所有人的雲端硬碟檔案，如果不懂絕對不要設定。

2. 建立 Service Account Key

如果你的 Service Account 是要讓外部的應用程式存取 GCP，就要再建立 Service Account Key。這時我們再點擊「金鑰」頁籤。

下方會看到「新增鍵」，這是 Google 翻譯得不好，其實就是「新增金鑰」，然後再「建立新的金鑰」。

點擊之後會彈出一個視窗，問你 Service Account Key 的檔案要下載成什麼格式，通常我們都用 Json 格式。

按下「建立」之後，會自動下載金鑰檔案到你的本機電腦。

這裡要注意，我們只有在建立金鑰的這一刻，是唯一能下載金鑰檔案的機會，如果這次下載後，金鑰檔案弄丟了，那你是無法再次下載金鑰的。你只能再建立另一個新的金鑰，同時刪除舊的金鑰，以免舊的金鑰檔案被駭客取得。

下載完後，我們可以用文字編輯器打開檔案，像我是用 Firefox 瀏覽器打開，它能夠以 Json 格式呈現檔案的內容。

你會看到這個金鑰檔案包含 Project ID、Key ID、Key 的內容、Service Account 的 Email 等相關資訊，這些資訊就是應用程式要去呼叫 GCP 的 API 時，做身份驗證要提供的內容。

所以當你擁有這個金鑰檔案，你就有能力存取 Service Account 能存取的各項資源了。

這也代表你必須好好保管這個檔案，要注意「非常非常多用戶」因為沒保管好金鑰檔案，導致檔案被駭客拿走，在 GCP 的專案裡大肆破壞你的環境，或是開一堆機器在挖礦， 一天之內造成上百萬元的 GCP 帳單，是由你幫駭客買單，不可不慎！

(四) 什麼時候要使用 Service Account？

Google 在官網有提供一個決定是否要用 Service Account 的決策過程如下：

1. 你是否在單一使用者開發環境 (如個人電腦、Cloud Shell、個人用的虛擬機器、虛擬桌面)？

像這樣的環境通常已經有使用者登入，你可以直接使用個人的憑證，例如你可能就是專案擁有者，權限也夠大，所以在開發或測試時較為彈性，不會動不動就因為權限不足而卡住。

・是，往問題 4，因為可能有更簡單的驗證方式。

・否，往問題 2，可能是生產環境或共享環境，會影響到這些環境的正常運作，所以可能要使用 Service Account，能確保它的權限不會太大，影響到其他部分的運作。

2. 你是否在 GCP 中運作程式？

因為 GCP 有特殊的驗證機制，可以直接使用內建的身份驗證，不一定真的要用 Service Account。

・是，往問題 3，確認是否使用容器服務，如果是，遇有其他方法可以使用。

・否，往問題 5，程式可能在本機或其他雲端的外部環境，可能真的要用 Service Account。

3. 是否在 GKE 或 Anthos 中執行容器 (Container) 應用程式？

GKE (Google Kubernetes Engine) 是 GCP 的容器管理服務，它把原生的 Kubernetes 直接做在 GCP 上，底層交由 GCP 直接來管理維護，並做出各種加值應用，比原生的 Kubernetes 更為方便強大。Anthos 則是讓地端也能夠執行 GKE。

・是，使用 Workload Identity Federation for GKE，這是 GKE 專門的身份驗證機制，比 Service Account 更安全。

・否，直接使用 Service Account。

4. 你的情境是否真的需要 Service Account？

它是問你是否需要在所有環境中統一驗證的方式，需要特殊的權限組合，或是自動化的操作。

・是：使用使用者憑證 (User Credentials) 模擬 (Impersonate) Service Account，因為這個動作必須要先做使用者身份驗證，事後可以追蹤到是誰在使用，而且它會產生短期憑證，會自動過期，比較安全。詳細內容可以參考這份文件。

・否：使用使用者憑證，就是使用者本人親自驗證。

5. 你的工作負載 (Workload；就是你在運作的程式) 是否支援 (Workload Identity Federation)？

它指的是 Workload Identity Federation 可以支援像是 AWS IAM 或 Azure AD 所提供的身份，這樣的話就不用額外建立和管理 Service Account 和金鑰，更安全也更方便。

・是：是：設定 Workload Identity Federation。

・否：建立 Service Account Key，已經沒有其他更好的方式了。

(五) 預設的 Service Account 

1. 為什麼會有預設的 Service Account？

你可能會發現，在 Cloud IAM 的畫面中，經常看到兩個預設的 Service Account： Compute Engine default service account 和 App Engine default service account。

這些 Service Account 是 GCP 自動創建的，主要用於特定服務的運行授權。當 Compute Engine VM 或 App Engine 應用程式運行時，GCP 會自動為它們提供一個安全的「內部身份驗證代碼 」(Identity Token)，這些代碼用來代表預設的 Service Account 進行身份驗證和授權。

2. 預設的 Service Account 的特點如下

・無需手動管理密鑰檔案：不需要產生、下載 Service Account 金鑰檔案。

・安全性更高：避免了因金鑰洩露導致的資安風險。

・簡化操作：應用程式可以直接使用 Google 提供的函式庫 (例如 Google Cloud SDK 或 Cloud Client Libraries) 進行授權，這些程式庫會自動檢測並使用預設的身份。

以下分述兩個預設的 Service Account：

(1) Compute Engine Default Service Account

Compute Engine Default Service Account 是當您在專案中啟用 Compute Engine API 時自動生成的 Service Account，它的格式會長這個樣子：

[project-number]-compute@developer.gserviceaccount.com

你可能會想，你什麼時候啟用這個 API？其實當你建立好一個新的專案，接著要準備建立你第一台虛擬機器時，它就會自動啟用 Compute Engine API 了。

由於虛擬機器在 GCP 裡面也可能要呼叫其他服務，所以這個 Service Account 會授權虛擬機器存取 GCP 資源，例如讀取 Cloud Storage 中的資料或與 Cloud SQL 進行互動。

預設情況下，此 Service Account 通常具有 Editor 角色 (Role)，即允許對專案中的所有資源進行讀寫操作。然而，這種設置在安全性上存在潛在風險，詳細內容可以參考這份文件。

你可能會很緊張，擔心如果機器被駭客入侵，那駭客不就拿到 Editor 角色的權限了？

其實當我們在建立機器時，雖然 GCP 預設使用 Compute Engine Default Service Account，但是它受到「存取權範圍」的控制。如果你當時切換到「針對各個 API 設定存取權」，可以看到它原始的設定如下圖：

它的預設設定包含：Storage 和 Service Management 的唯讀存取權、Stackdriver Logging 和 Monitoring 的寫入權限，以及 Service Control 的讀取/寫入權限。所以它的權限是比較小的，不用太過擔心。

假如你對這一點有充份了解，那就建議你以後建立虛擬機器時，不要使用 Compute Engine Default Service Account，而是用你自訂的 Service Account，然後採用最小權限原則，根據 VM 的具體需求調整其角色。

例如，只賦予存取必要資源的權限，而非整個 GCP 專案所有服務的讀寫權限。還要注意要設定 Logs Writer 和Monitoring Metric Writer，這樣虛擬機器才能夠把 Log 和效能指標寫入 GCP 喔！

(2) App Engine Default Service Account

這是當您啟用 App Engine 應用程式時，GCP 自動創建的 Service Account，它的格式會長這個樣子：

[project-id]@appspot.gserviceaccount.com

它會授權 App Engine 的應用程式存取 GCP 資源，例如呼叫其他 GCP 服務的 API 或存取資料庫。

這個 Service Account 也有 Editor 角色，允許應用程式對專案內的資源進行各種讀寫操作。它和 Compute Engine default service account 一樣，預設權限過高可能導致安全性問題。

建議你手動把它的 Editor 角色改成更小權限的角色，等到它存取其他服務，卡住的時候再逐步開放也不遲。

如果你的機構 (Organization) 是在 2024 年 5 月 3 日以後建立的，它有一個機構政策「停用自動為預設服務帳戶授予 IAM 的功能」，是預設會強制執行的，那就不用擔心。(注意你要切換到機構角度，不是專案角度)

像我是的機構是之前就建立的，該政策並沒有強制執行，就請務必透過「管理政策」來改成「強制執行」。

(五) Service Account 注意事項

在 GCP 官方文件提供的 Service Account 注意事項非常多，這裡整理幾個最簡單也最重要的要點給大家：

1. 將 Service Account 視為資源管理

因為它的使用方式，跟一般的使用者帳號差很多，所以要定期觀查每個 Service Account 的使用情形，如果有程式不再運作，就要跟著停用對應的 Service Account 和金鑰。

2. 建立單一用途的 Service Account

遵守最小權限原則，Service Account 只做一件事，使用最小剛好用到的權限，不要使用預設的 Service Account。

3. 建立並遵守命名原則

讓大家一看就知道 Service Account 用在什麼地方，甚至在說明欄位記錄聯絡人和文件連結，以後如果要異動，能夠找到對應的負責人員聯絡，避免誤刪造成系統無法運作。

4. 識別並停用未使用的 Service Account

你可以使用 Activity Analyzer 檢查使用情況，查看最近 Servcie Account 和金鑰的驗證記錄，具體操作可以查看這份文件。

5. 在刪除前先停用

先停用一段時間再決定是否刪除 Service Account，或先刪除金鑰，觀查是否有影響到某個程式的運作，避免太快誤刪造成系統維護的麻煩。

6. 不要用預設的 Service Account

如上述所談，權限太大了。虛擬機器也不要用預設的 Service Account，盡量用專屬的 Service Account 配上專屬的角色。

7. 不要使用網域授權 (Domain-wide Delegation)

這個權限太大了，會讓 Service Account 模擬組織中的任何使用者，也容易被駭客拿來破壞。或是必須設定權限到期日，不要讓它的權限一直存在。 

8. 不要讓任何人可以直接存取 Service Account

如果一個使用者可以存取 Service Account，他就有可能用 Service Account 的權限做更多事情，甚至利用 Servcie Account 的權限 (像是 iam.serviceAccounts.setIamPolicy)，再間接取得更多權限。

9. 在沒有其他選擇時才使用 Service Account 金鑰

使用金鑰做所份驗證時，你沒有辦法追蹤誰使用了金鑰。此外也不要把金鑰檔案儲存在公開的程式碼儲存庫 (如 GitHub)。還有定期輪替金鑰，防止過期或洩露帶來的風險。  

10. 善用稽核記錄 (Audit Logs)

某些 GCP 服務 (例如 Compute Engine) 在Audit Logs 中會包含 serviceAccountDelegationInfo 欄位，這個欄位會顯示Service Account 是否被模擬使用，以及是誰在模擬這個 Service Account。

但不是所有服務都會記錄模擬的詳細資訊，需要額外啟用某些 API 的資料存取記錄，否則可能會遺漏重要的追蹤資訊。因此還要再啟用 Data Access Logs： 

(1) Identity and Access Management (IAM) API，能夠追蹤 Service Account 的詳細使用情況。

(2) Security Token Service API，會記錄 Token 的請求和發放，追蹤身份驗證的過程。

還有很多更細節的注意事情，有需要再參考這份文件。

五、結論

你會發現，本文前半部在開始介紹 IAM 還蠻簡單的，後面隨著牽涉到的範圍越廣也越深。因為整個 GCP 環境內的所有動作，沒有一個和權限無關，就算是 GCP 本身例行性的維護和運作，雖然沒有經過你的操作，你也都能夠查到相關的記錄和使用的權限，而不會直接隱藏不讓你知道。

所以 Cloud IAM 就是 GCP 運作的底層邏輯之一，如果這部分能夠充分了解，對你以後操作 GCP 和故障排除時會很有幫助，也能夠確保整個環境的資訊安全，避免內部人員越權或駭客入侵造成嚴重的後果。

本文同時刊登在思想科技官方網站：

【東東老師 X 思想科技】Google Cloud IAM 的角色與權限控管介紹

【東東老師Ｘ思想科技】Google Cloud IAM Service Account 基本介紹和設定

The post GCP 的 Cloud IAM – 角色與權限控管介紹 first appeared on 東東 GCP 教學 - GCP 實戰講師.

前陣子周杰倫演唱會售票系統面對超過 89 萬人同時搶票的情況，售票系統方很自豪地說，系統能夠承載如此大的流量，不會掛掉的同時，還能順利地把票賣完。

雖然能夠推持住系統不會崩潰，但該系統的售票頁面不斷出現「轉圈圈」的狀況，讓許多歌迷無法順利購票，關於使用者體驗這一點，似乎還有可以再優化的空間。

本文將從技術角度深入分析售票系統架構，並探討各種可能的優化方案。

一、現有AWS架構的問題分析

根據 AWS 官方指出，售票系統就是架設在 AWS 雲端上。不過啊，這張圖是2020年的，現在的架構應該優化更多了，但目前只找到這張，我們就以這架構來分析看看吧！

首先來看一下售票系統的架構圖：

接下來以個人淺見來看看該架構是否有可以更好的地方：

(一) 系統架構層面

1. 負載平衡

想像一下，就像是一個只有三個服務窗口的車站，突然間來了九十萬人要買票。即使每個窗口再怎麼快，也無法應付這麼多人。

雖然有基本的負載平衡器 (Elastic Load Balancing) 來分配人流，但就像是交通指揮只會把人平均分配到三個窗口，沒有更聰明的疏導方式。系統需要的是更像春節期間的車站管理，有預約、分流、排隊等多重措施。

2. 資料庫設計問題

現在的資料庫就像是一本大帳本，所有人都要搶著在同一本帳本上記錄。當九十萬人同時要在這本帳本上寫東西，自然會打架。

DynamoDB 雖然很強大，但難以處理高併發，如果只用一個資料庫來處理所有請求，就像是再厲害的收銀員，同時間也只能服務有限的客人。

我們需要的是資料分片策略，就像是多個專門的小帳本，分別處理不同的資料，就像大賣場會開很多收銀台一樣。

3. 擴展性限制

EC2 主機的擴充速度可能趕不上需求，等擴展完成可能大部分客人已經等得不耐煩走人了。這就需要更智慧的預測和更快的擴充機制，就像餐廳會預先觀察訂位情況來準備桌位。

(二) 使用者體驗問題

1. 缺乏透明度

目前的系統就像是把用戶關在一個黑盒子裡，只能看到一個永遠轉不完的圈圈，不知道自己排在第幾位，還要等多久。

這種體驗就像是排隊但看不到前面有多少人，也不知道隊伍有沒有在動。這會造成用戶焦慮，也容易讓人懷疑系統是否還在正常運作。

2. 系統響應問題

當系統過載時，用戶看到的就是無止盡的載入畫面，不知道到底是成功了還是失敗了。這就像是在自動販賣機投錢後，機器既不出貨也不退錢，讓人不知所措。

系統需要明確告訴用戶當前的狀態，即使是失敗也要讓用戶知道原因和下一步該怎麼做。

也就是說，買票的粉絲可能太晚買票了，至少讓他們知道前面還有多少人在買，大概要等多久，當他們看到人數太多，也有可能乾脆就不買了，讓真正死忠的粉絲繼續排隊買票。

二、改進方案分析

(一) 資料庫架構優化

1. 為什麼需要改進資料庫架構？

現有的單一資料庫架構就像是一個超大的倉庫，所有人都要從同一個門進出。當人太多時，自然會造成擁擠。

改進的方案就像是把一個大倉庫分成多個小倉庫，每個倉庫負責不同的區域或功能，這樣就能更有效率地服務更多人。

如果使用多個不同資料庫，把一個大資料庫切分成多個小資料庫，就像是一個服務櫃台變成多個服務櫃台，自然能夠服務更多人，也降低了某個櫃台故障時影響所有人的風險。

2. 可能會有的缺點

想像一下，如果今天有個客人要同時買 A 區和 B 區的票，但這兩個區域是分別由不同資料庫管理的。這時系統就必須同時和兩個資料庫溝通，確保兩邊都要成功購票，才算交易完成。

這種跨資料庫的交易變得很複雜，就像是要同時在不同櫃台辦理業務。而且每個資料庫的資料都要保持同步，比如說座位狀態、購票紀錄等，

這會讓系統變得很複雜，也需要投入更多資源來維護這些資料庫。

3. 推薦做法

與其完全切分成獨立的資料庫，不如採用「分片」的方式。分片就像是同一個大資料庫的不同分部，它們共用相同的管理方式，但各自負責不同的資料。

再搭配分散式的快取系統，可以先把熱門的資料（例如座位狀態）存在記憶體中，這樣就不用每次都去資料庫查詢。

最後，對於跨區域的購票需求，可以使用訊息佇列來處理，讓系統能夠更有條理地處理這些複雜的交易。這樣的設計既保持了系統的簡單性，又能應付大量的購票需求。

(二) 實名制驗證機制

1. 實名驗證的好處

實名制最直接的好處就是能大幅降低黃牛票的問題，因為每張票都綁定實際觀眾的身分證，黃牛就無法大量囤票轉售。

這也讓整個交易變得更有保障，因為買票的人就是要進場看表演的人，票券的來源更有保障。

另外，當有人需要退票或換票時，主辦單位也能很容易確認這個要求是來自原始購票者，不會有人冒用他人身分來退票，整個售後服務變得更好管理。

當然，這點所有的人都理解，但並不是那麼容易做到。

2. 實名驗證的缺點

實名制最明顯的缺點是會拉長整個購票流程。想像一下，除了選位置、付款之外，還要額外填寫身分證字號、姓名等資料，而且可能還需要系統和政府資料庫做驗證，這些都會增加購票時間。

對售票系統來說，也需要建立更複雜的程式邏輯，要處理身分驗證、確認真實性、處理例外狀況等。

最重要的是，系統現在要處理大量的個人資料，不只要符合個資法的規範，還要有足夠的資安防護，以免發生資料外洩，這些都是很大的挑戰。

3. 建議做法

最理想的做法是讓使用者「提前」完成身分驗證。就像是網路銀行開戶，先在平常時間完成所有驗證程序，到真正要搶票時就不用再重新驗證，可以大幅縮短購票時間。

建議採用分散式的身分驗證服務，這樣就不會所有驗證請求都擠在同一個地方。系統可以同時使用多種驗證方式，例如身分證字號、手機號碼認證、金融卡驗證等，讓使用者可以選擇最方便的方式。

重要的是要在便利性和安全性之間取得平衡，既不能讓驗證程序太複雜而影響購票體驗，又要確保身分驗證的真實性。這樣的設計才能真正發揮實名制的優點，同時降低它帶來的負面影響。

4. 和劉德華演唱會實名制的做法比較

(1) 採用「登記抽選制」而非即時搶票

這完全避免了系統崩潰的風險。因為在15天的時間窗口內（8/25-8/30），人們可以從容地登記資料，系統負載被分散到更長的時間。

(2) 有清楚的分流機制

卡友優先購票時段（11:28-13:28）和一般民眾登記時段（15:28後），這樣的設計可以有效管理系統負載。

身分資料修改機制很人性化：給予5天的時間（8/25-8/30）供人們修正資料錯誤，而且提供了明確的修改介面（「查看詳情」修正資料）。

(3) 對特殊情況有完整的配套

・生僻字可以用護照英文名稱取代
・身心障礙者和陪同者必須同時登記
・明確區分本地居民和海外人士的證件要求

與我們原本建議方案的主要差異：

我們建議的「預先驗證」機制著重在搶票前就完成身分驗證，但劉德華演唱會採用的是「登記後慢慢驗證」的方式。這種方式雖然較不即時，但因為有抽選機制，所以時間不是那麼關鍵。

我們建議的分散式驗證服務主要是為了處理高併發的即時驗證需求，但在登記抽選制下，這種複雜的架構反而顯得多餘。

所以劉德華演唱會的做法其實更優秀，因為它徹底改變了遊戲規則 – 從「比快」變成「抽籤」。這種方式有幾個關鍵優勢：

・完全消除了系統崩潰的風險
・給予購票者更多時間確認和修正資料
・降低了黃牛票的投機空間（因為無法透過技術手段提高中籤機會）
・整體成本更低（不需要建置複雜的高併發架構）

這個案例告訴我們，有時候與其用技術解決問題，不如從商業邏輯層面改變遊戲規則。這種「登記抽選」的方式，既解決了技術問題，又提供了更好的使用者體驗，是一個值得借鑑的範例。

(三) 智慧排隊系統

1. 排隊機制的運作原理

想像一下，就像是遊樂園的快速通關系統，每個人進入隊伍時會拿到一個號碼，系統會告訴你大概什麼時候可以入場，你不用一直站在那裡等。在線上售票系統中，這表示用戶可以知道自己的位置，預估等待時間，甚至可以做其他事情同時等待。

2. 具體實做方式描述

(1) 即時狀態顯示

我們使用 API Gateway 的 WebSocket API 來建立與使用者的即時連線，這個連線資訊會被存放在 DynamoDB 中。

當使用者的排隊狀態有任何更新時，系統就會立即透過這個 WebSocket 連線推送最新狀態給使用者，讓他們能即時看到自己在隊伍中的位置和預估等待時間。

說到這個，我想到我用手機買郭富城演唱會門票時，至少它有告訴我要等多久。

(2) 排隊機制

排隊機制的實現則依賴於 DynamoDB 的分散式計數器功能。當使用者加入隊伍時，系統會在 DynamoDB 中建立一筆排隊記錄，並使用計數器來取得這位使用者在隊伍中的確切位置。

這些排隊資訊會被送入 SQS 佇列中等待處理，確保系統能夠有序地處理每一個排隊請求，不會因為大量湧入的請求而崩潰。

(3) 分批放行

分批放行的處理是透過 Lambda 函數來完成的。系統會定期觸發 Lambda 來處理一定數量的排隊用戶，這個數量是根據系統當前的負載狀況和處理能力來決定的。

當一批用戶被選中可以進入購票流程時，系統會同時通知這批用戶，讓他們開始選位和付款的流程。這種分批處理的方式可以有效控制系統負載，避免所有人同時湧入造成系統癱瘓。

(4) 超時處理

為了處理逾時的情況，我們使用 CloudWatch Events 來定期觸發檢查機制。

如果有用戶在規定時間內沒有完成購票流程，系統會自動將他們標記為逾時，釋放相關的資源（如暫時保留的座位），並通知後面的使用者前進。

這個機制確保了隊伍能夠持續流動，不會因為個別用戶的延遲而影響整體效率。

(5) 防欺詐機制

防欺詐機制則是整個系統的安全防護網。系統會檢查是否有重複排隊的情況，驗證每個用戶的身份，並且限制單一用戶在特定時間內能夠進行的操作次數。

這些機制共同確保了排隊過程的公平性，防止有人利用技術手段破壞正常的排隊秩序。

這整套系統需要多個 AWS 服務的配合才能順利運作。API Gateway 處理所有的即時通訊需求，DynamoDB 負責資料的儲存，SQS 確保訊息的可靠傳遞，Lambda 處理各種業務邏輯，CloudWatch Events 負責定時任務的觸發，而 ElastiCache 則用於提供快取服務以提升系統效能。

這些服務相互配合，打造出一個可擴展、可靠且高效的智能排隊系統。

這樣的架構設計不僅能夠處理大量的並發連接，還能確保整個購票過程的公平性，同時為使用者提供即時的狀態更新，並能自動處理各種異常情況。

最重要的是，它提供了良好的使用者體驗，讓使用者清楚知道自己的排隊狀態，不會因為系統的不透明而感到焦慮。

(四) 概念示意圖

1.入口層

系統的第一道防線是 CloudFront 全球內容分發網路（CDN）。它負責將靜態內容快取在全球各節點，大幅降低使用者的存取延遲。

當大量用戶同時湧入時，CDN 可以有效分散流量，避免直接衝擊後端伺服器。

在 CDN 之後，應用程式負載平衡器（ALB）進一步分配流量到不同的前端服務節點。

2.前端層

使用 ECS Fargate 運行前端應用程式，採用無伺服器架構可以根據實際流量自動擴展。這層主要處理使用者介面渲染和基本的業務邏輯，像是表單驗證、頁面導航等。

由於使用容器化技術，可以快速部署和擴展，且無需管理底層基礎設施。

3.排隊層

當用戶進入系統後，首先進入排隊層。這層使用 API Gateway 的 WebSocket 服務維持與用戶的即時連線，讓系統能夠即時推送排隊狀態更新。

排隊狀態存儲在 DynamoDB 中，確保高併發存取性能。使用 SQS 訊息佇列來管理排隊隊伍，確保公平性和系統穩定性。

4.身分驗證層

輪到用戶時，進入身分驗證層。REST API 接收驗證請求，Lambda 函數執行實際的驗證邏輯。

用戶資料存儲在 DynamoDB，而驗證結果快取在 ElastiCache 中以提升效能。

這層的設計重點是安全性和效能的平衡，確保驗證過程既安全又快速。

5.訂票層

通過身分驗證後，用戶進入實際的訂票流程。ECS Fargate 運行訂票服務，處理座位選擇和訂單創建。

座位狀態快取在 ElastiCache 中，確保快速響應。最終的訂單資料寫入 Aurora 資料庫，提供強大的交易保證和數據一致性。

6.資料流向

用戶從 CloudFront 進入系統，經過排隊系統獲得順序號，通過身分驗證後進入訂票流程，最後完成訂單創建。

每一步驟都有相應的快取和備份機制，確保系統的可靠性和效能。

這種分層的架構設計，不僅讓系統容易擴展和維護，也提供了良好的用戶體驗。

三、GCP優化架構方案

接下來，我們來看看，售票系統在 GCP上可以怎麼做。

(一) 核心服務

我們的售票系統核心架構是建立在六個關鍵的 GCP 服務上。

1. Cloud CDN 負責處理所有靜態資源的分發

包括網站的 JavaScript、CSS 文件、圖片等。這些資源會被快取在全球各地的節點上，大幅降低延遲時間，讓世界各地的用戶都能快速載入網頁。

系統會自動偵測使用者位置，連接到最近的 CDN 節點，確保最佳效能。

2. Global Load Balancer 扮演著全球流量調度的角色。

它能夠智慧地判斷使用者的地理位置和網路狀況，自動將請求導向最適合的資料中心。

尤其它跟 AWS 的 ALB 比起來，還不用預熱 Pre-Warm。

當某個區域的負載較高時，可以自動將流量導向其他區域，確保系統的穩定性。

而且它還具備智慧路由功能，可以根據後端服務的健康狀況來分配流量。

3. Cloud Run 用於部署前端應用

這個無伺服器的平台能根據流量自動擴展，當訪問量突然增加時，系統會自動建立更多的容器實例來處理請求。

閒置時則會自動縮減資源，既確保了效能又能節省成本。

4. GKE（Google Kubernetes Engine）處理核心業務邏輯。

我們將不同的功能（如訂單處理、座位管理、付款服務等）拆分成獨立的微服務，部署在 GKE Cluster 中。

這種微服務架構讓我們能夠獨立擴展每個服務，也讓系統更容易維護和更新。

5. Cloud Spanner 資料庫保證資料的一致性

這對於處理座位預訂這類需要精確性的操作特別重要。

它能夠在全球範圍內保持資料同步，同時支援大規模的並發操作，完全滿足大型演唱會售票的需求。

6. Pub/Sub 訊息佇列系統用於處理非同步任務

例如當用戶提交訂單時，系統會發送消息到 Pub/Sub，由後端服務依序處理，避免系統過載。

它也用於服務間的通訊，確保訊息能可靠傳遞。

(二) 高可用性設計 (High Availability)

1. 多區域部署

系統同時部署在多個地理位置的資料中心，即使某個區域發生故障，其他區域仍能繼續提供服務。

每個區域都配置了完整的服務架構，並通過 Global Load Balancer 進行流量分配。

2. Autoscale

Autoscale 機制是建立在 GKE 和 Cloud Run 的基礎上。系統會根據 CPU 使用率、記憶體使用量、請求數等指標自動調整資源配置。

例如，當檢測到存取量增加時，會自動增加容器主機數量；當負載降低時，則會自動縮減資源以節省成本。

3. 故障自動轉移

故障自動轉移機制確保了系統的穩定性。

當檢測到某個服務主機故障時，系統會自動將流量導向健康的主機，同時啟動新的主機來替補。這個過程對使用者來說是完全透明的。

4. 分散式快取

分散式快取系統使用了多層次的策略，包括瀏覽器快取、CDN 快取、應用層快取等。

我們使用 Memorystore 來儲存熱門資料，如座位狀態、活動資訊等，大幅減少資料庫的存取壓力。

(三) 監控與維運

1. Cloud Monitoring

負責收集各種系統指標，包括伺服器效能、網絡流量、API 回應時間等。

這些資料會以直觀的儀表板呈現出來，幫助維運團隊快速掌握系統狀態。

2. Cloud Logging

集中管理所有服務的 Log，支援複雜的查詢和分析。維運人員可以輕鬆追蹤問題，了解系統行為。

而且它還支援長期儲存，有助於後續的分析和稽核。

3. Cloud Trace

提供了詳細的 Request 追蹤功能。它可以追蹤一個 Request 在不同服務之間的傳遞過程，幫助我們找出效能瓶頸，就是看出 Latency 高到底是卡在哪裡。

特別是在微服務架構中，這個功能對於問題診斷極為重要。

4. 即時警報系統

當系統出現異常時（如錯誤率升高、回應時間變長），會立即通過 Email、簡訊等方式通知相關人員。不同層級的問題有不同的通知策略，確保運維團隊能及時處理各種情況。這個警報系統也與事件處理流程整合，能夠自動創建工單 (Ticket)，追踪問題解決過程。

四、結論

打造一個優秀的售票系統不僅需要穩定的技術架構，更需要良好的使用者體驗設計。關鍵改進點總結如下：

(一) 系統架構層面

• 1. 多層次快取策略
• 2. 智慧負載平衡
• 3. 資料分片處理
• 4. 異步處理機制

(二) 使用者體驗層面

• 1. 透明的排隊機制
• 2. 即時狀態更新
• 3. 清晰的錯誤提示
• 4. 合理的重試機制

(三) 運營管理層面

• 1. 完善的監控系統
• 2. 靈活的擴展策略
• 3. 有效的成本控制
• 4. 安全防護機制

這些層面的改進點環環相扣，缺一不可。好的系統架構是基礎，但如果沒有良好的使用者體驗設計，用戶仍然會感到挫折。

同樣，沒有完善的運營管理機制，再好的系統也可能因為無法及時發現和處理問題而導致服務中斷。只有將這三個層面都做好，才能打造出真正優秀的售票系統。

The post [GCP 教學] 周杰倫演唱會 AWS 售票系統架構解析 – 系統穩和 vs 使用者體驗，哪個重要？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

我以前也不懂為什麼會有 Cloud Deploy 這個東西，因為原本 DevOps 相關的工具已經夠多了，後來看到這個 Release 才懂，它的確有其必要性。

具體來說：

Release 的組成部分包含如下：

• 容器映像檔（Container image）
• 部署設定檔（如 Kubernetes 清單）
• 部署相關的中介資料（metadata）
• 環境特定的設定

Release 的特點：

• 不可變性（Immutable）：一旦創建就不能修改
• 可追蹤性：每個 release 都有唯一的標識符
• 可重複使用：同一個 release 可以部署到不同環境

創建 Release 的方式：

gcloud deploy releases create release-001 \
  --delivery-pipeline=my-pipeline \
  --region=asia-east1 \
  --source=/path/to/source

Release 的生命週期：

• 創建（Create）：打包應用程式和配置
• 部署（Deploy）：部署到目標環境
• 推進（Promote）：將相同的 release 推進到下一個環境

Release 的優點：

• 確保一致性：相同的 release 在所有環境中保持一致
• 版本控制：每個 release 都有版本記錄
• 回滾能力：可以輕易回滾到之前的 release
• 稽核追蹤：可以追蹤每個 release 的部署歷史

Cloud Deploy Release 實際應用例子：

Release-001
├── 容器映像: gcr.io/my-project/my-app:v1.0.0
├── 部署配置: 
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
└── 中繼數據:
    ├── 創建時間
    ├── 創建者
    └── 描述信息

Cloud Deploy Release 與環境的關係：

• 開發（Dev）環境：初始部署和測試
• 暫存（Staging）環境：整合測試
• 生產（Production）環境：最終部署
  每個環境可能需要不同的配置，但基礎映像和應用邏輯保持一致。

使用 Release 的好處

通過使用 release，團隊可以：

• 確保部署過程的可重複性
• 維護清晰的部署歷史
• 在問題發生時快速回滾 (Rollback)
• 實現更安全和可控的部署流程

這種方式最能保證部署的一致性和可靠性。

The post [GCP DevOps] Cloud Deploy 的 Release 是什麼東東？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

簡單來說，它就像是一個翻譯器，把 Google Cloud 的資源轉換成 Kubernetes 可以理解的格式。

在實際使用中，Config Connector 扮演著橋樑的角色。

當我們想要在Google Cloud上建立新的服務，比如說建立一個 Cloud Storage Bucket 或是設定一個負載平衡器，我們不需要去 GCP 的控制台點點按按，而是可以直接用 Kubernetes 的設定檔來描述我們想要的資源。

Config Connector會自動幫我們在Google Cloud上建立這些資源，並且持續確保它們的狀態符合我們的期望。

這個工具的強大之處在於它的自動化能力。

比如說，如果有人不小心在 GCP Console 上手動修改了某些設定，Config Connector 會自動發現這個變化，並把它改回到我們在設定文件中定義的狀態。這樣可以確保我們的環境始終保持一致性。

在安全性方面，Config Connector 完全整合了 Kubernetes 的權限管理系統。代表我們可以精確控制誰能夠管理哪些 GCP 的資源，而且所有的操作都有完整的稽核記錄。

使用 Config Connector 的時候，我們需要先在 Kubernetes Cluster 中安裝它，然後配置適當的權限。之後，我們就可以用 YAML 格式的設定檔來描述我們想要的Google Cloud資源。

這些配置文件可以存放在Git倉庫中，配合 CI/CD 流程實現自動化部署。

在實際工作中，Config Connector 特別適合需要經常建立和管理GCP 資源的團隊。

比如說開發團隊需要經常建立測試環境，或者維運團隊需要統一管理多個專案的資源，使用 Config Connector 都能大大提高工作效率。

當遇到問題時，我們可以通過查看 Config Connector 的 Log 來進行故障排除。它會清楚地告訴我們哪裡出了問題，比如權限不足或者資源設定有誤。這讓問題診斷和修復變得更加直接和簡單。

總的來說，Config Connector 是一個非常實用的工具，它讓 GCP 資源的管理變得更加自動化和規範化，特別適合已經在使用Kubernetes的團隊。它不僅簡化了日常運維工作，還能確保環境的一致性和可靠性。

要使用 Config Connector，先準備以下 YAML 檔案：

apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: cluster
  googleServiceAccount: GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

當這個 YAML 被應用 (Apply) 到GKE後，它會在你的 Kubernetes Cluster 中設置 Config Connector，並且設定使用指定的 Google Service Account 來操作 GCP 資源。

例如我們想要建立一個 Bucket，可以準備以下的 YAML 檔：

apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: my-bucket
spec:
  location: US-CENTRAL1
  uniformBucketLevelAccess: true

當這個 YAML 被套用 Apply 到 GKE 後，流程是這樣的：

1. GKE 中的 Config Connector 會讀取這個YAML檔
2. Config Connector 會解析這個檔案，了解到你想要創建一個Cloud Storage bucket
3. Config Connector 會使用它被配置的 Google Service Account的權限
4. 通過 Google Cloud API 去創建實際的 Storage bucket
5. 持續監控這個 bucket 的狀態，確保它符合 YAML 中描述的配置

如果之後有人直接在 GCP 控制台修改了這個 bucket 的設定，Config Connector 會自動發現並改回 YAML 檔中定義的狀態。

這就是為什麼它特別適合用在 GitOps 的工作流程中，因為它能確保實際的 GCP 資源狀態始終與程式碼倉庫中的定義保持一致。

The post [GKE 教學] Config Connector 是什麼東東？如何使用？ first appeared on 東東 GCP 教學 - GCP 實戰講師.

GitOps方法論是什麼？

GitOps是一種現代的軟體部署和運維方法論，核心理念是使用Git作為單一事實來源(Single Source of Truth)，所有系統設定和基礎設施都以程式碼形式存儲在Git倉庫中，以宣告式語法來描述整個系統狀態。

主要特點

1. 自動化同步：系統會自動將Git倉庫中的期望狀態與實際運行環境同步
2. 版本控制：所有更改都有完整的版本歷史記錄
3. 可稽核性：每個變更都可以追踪誰在什麼時候做了什麼修改
4. 回滾能力：可以輕鬆回退到任何之前的版本

優點如下：

1. 提高部署一致性和可靠性
2. 減少人為錯誤
3. 更容易進行協作和審查
4. 簡化復原流程

常用工具包含：Flux、ArgoCD、Jenkins X、Config Connector (Google Cloud 專屬)。

GitOps特別適合管理Kubernetes環境，因為Kubernetes本身就是基於聲明式配置的系統。這也是為什麼在GKE環境中，Config Connector配合GitOps方法論會是一個理想的選擇。

撇開 GKE，Flux 和 ArgoCD 就是兩個業界常用的 GitOps 工具

Flux:

• 像是一個勤奮的管家,會定期檢查 Git 程式碼庫有沒有更新
• 如果發現更新了,就會自動把新的設定套用到系統
• 特別適合單一團隊使用,設定相對簡單

ArgoCD:

• 功能比較豐富,有圖形化介面可以看系統狀態
• 可以管理多個專案和團隊
• 提供更多進階功能,例如可以設定部署的順序和條件

這兩個工具的主要差別在於:

• Flux 比較輕量化,適合小型專案
• ArgoCD 功能比較完整,適合大型組織使用
• Flux 通常整合在系統內,ArgoCD 則是獨立運作的服務

你要選擇哪一個,主要看:

1. 團隊規模大小
2. 是否需要圖形化介面
3. 需要的進階功能有哪些
4. 維護的難易程度

GitOps的工作流程是什麼？

1. 開發階段

• 開發人員在本地開發功能或修改
• 將所有設定檔（包括應用代碼、基礎設施配置）存儲在 Git 倉庫 (Repository)，例如 Github。
• 創建 Pull Request（PR）提交更改

2. 審核階段

• 其他團隊成員審查代碼變更
• 自動化測試運行檢查
• CI（持續整合）流程驗證更改
• 審核通過後合併到主分支 (Main Branch)

3. 同步階段

• GitOps 操作器（如 ArgoCD 或 Flux）持續監控 Git 倉庫
• 自動檢測到主分支的新變更
• 比較目標環境與 Git 中定義的期望狀態

4. 部署階段

• 操作器自動將變更同步到目標環境
• 執行必要的部署和配置更新
• 確保實際狀態與 Git 中定義的狀態一致

5. 監控與修正

• 持續監控部署狀態
• 如果檢測到偏差，自動進行修正
• 將實際狀態調整回 Git 中定義的期望狀態

6. 回滾機制

• 如果發現問題，可以快速回滾
• 只需將 Git 倉庫回退到之前的穩定版本
• 操作器會自動將環境同步到回滾後的狀態

整個流程的核心是：

• 所有更改都通過 Git 進行
• 自動化工具負責同步和部署
• 持續確保系統狀態與 Git 定義保持一致

這種工作流程特別適合：

• Kubernetes 環境管理
• 微服務架構
• 大規模分布式系統
• 需要嚴格變更控制的環境

The post [GKE 教學] GitOps 方法論是什麼東東？GitOps的工作流程是什麼？ first appeared on 東東 GCP 教學 - GCP 實戰講師.