技術專欄
.svg){kind=logo}
技術六處三部 雲端架構師 | Herman Kou
( 圖片取自AWS Architecture Icons Deck © Amazon Web Service)
想要打造現代化應用程式，事件驅動架構是不可或缺的一環。Amazon EventBridge是一個全托管的事件中心，可協調不同應用程式、服務及AWS資源之間的事件，實現更高效、更可靠的應用程式。這篇文章深入探索Amazon EventBridge的Event及Scheduler，幫助讀者了解實踐事件驅動架構的應用。如果您是一名開發者或系統架構師，這篇文章將是您深入了解事件驅動架構及Amazon EventBridge的絕佳資源。
Amazon EventBridge 服務讓您無需撰寫程式碼，即可即時存取 AWS 服務、自有應用程式和軟體即服務 (SaaS) 應用程式的資料變更。首先，您可以在 Amazon EventBridge 主控台選擇一個事件來源。然後，您可以從 AWS 服務中選取一個目標，包括 AWS Lambda、Amazon Simple Notification Service (SNS) 和 Amazon Kinesis Data Firehose。Amazon EventBridge 會以近乎即時的速度自動傳送事件。
Amazon EventBridge 是一種無伺服器的整合服務，透過事件 (Event) 的導向、管道及排程，提供一種簡單及一致的方式整合事件產生者及事件取用者，從而幫助您建置點對點整合。
簡單來說，在AWS服務中所有的改變都是API呼叫的一種，而所有的API呼叫都會產生事件儲存在AWS CloudTrail裡面。Amazon EventBridge 就是以此類事件為基礎以鬆散耦合的方式，在AWS內事件的改變來觸發其他事件的發生。
例如我想啟動一台EC2實例，但EC2在啟動的時候因為某原因失敗了，這時候就會產生EC2 Instance Launch Unsuccessful 這個事件，若我已經在EventBridge設定了規則當發生該事件時，SNS會傳送通知到我的Email的話，它該按設定執行指定動作。
( 圖片取自 AWS 官網 : https://aws.amazon.com/tw/eventbridge/ © Amazon Web Service)
Amazon EventBridge 事件匯流排是一種無伺服器事件匯流排，可幫助您接收、篩選、轉換、路由和傳遞事件。
事件是指在運行環境內發生的任何改變，例如在AWS Console上進行的變更，合作夥伴的SaaS 或應用程式，又或是你本地的應用程式或服務。以下將列出三個事件的例子：
• 一個EC2實例的狀態從Pending轉為Running的狀態轉變
• EC2 Auto Scaling 啟動或終止任何EC2的實體
• 當你呼叫API時，在AWS Cloudtrial上所產生的事件
你還可以建立週期性自動觸發的事件。
事件以JSON 物件的格式表示，而事件的架構大多都一樣。
如果你想詳細查看所有AWS服務產生的事件表列，請前往 Events from AWS services 。
以下為觸發一個事件的例子：
Step.1
前往AWS Console，其前往Cloudtrail服務，點擊左方選單的”Event history”查看。
Step.2
先建立一個EC2實例作為例子。
Step.3
回到Cloudtrail服務，找到啟動EC2的Event Log。
在Cloudtrail的Event history上找到了RunInstance的記錄，代表在建立EC2實例時有事件觸發。
以上為觸發事件的例子。
事件匯流排是一種用來接收事件的管道，上面可以關聯多個規則 (Rules) ，當事件進入匯流排的時候，每一項規則都會檢查該事件是否符合設定好的條件。當你把規則關聯到指定的匯流排時，該規則只會被進入該匯流排的事件所觸發。
預設擁有一個預設的 event bus，所有AWS服務的事件都會向該 event bus 傳送；在一般情況下應使用該event bus，但若需要第三方或自定義事件及匯流排，便需建立自己的事件匯流排。
以下是建立事件匯流排的例子：
Step.1
進入AWS Console 並打開 Amazon EventBridege 頁面。
Step.2
1. 從左方選單點擊Event buses；
2. 點擊右方”Create event bus”。
Step.3
1. 輸入Event bus 的名字；
2. 選擇啟用事件記錄；
3. 輸入事件記錄的名稱；
4. 輸入事件記錄的描述；
5. 選擇不啟用Schema discovery。
• 事件記錄 (Archives) 能把每個傳到該匯流排的事件都記錄起來，以方便發生錯誤時除錯使用，這次因示範用途啟用。
• Schema discovery啟用時，會把所有該匯流排處理過的事件以Schema的形式儲存到Schema registry裡面，用於加速開發及開發新功能，本文不會介紹該功能故不會啟用。
Step.4
往下：
1. 點擊”Load template”載入Resource-based policy 的範本；
2. 點擊”Copy”以複製範本。
• Resource-based policy 定義了誰又或是什麼資源能取用你的event bus，在預設的情況下，只有該event bus 的擁有者才能把事件傳入event bus。
Step.5
把它貼到任意文字編輯器查閱：
1. 第一段允許指定AWS account對該event bus傳入event，請把<ACCOUNT_ID>換成自己的Account ID；
2. 第二段允許指定Organization 的所有AWS Account都能對該event bus 傳入 event；
3. 第三段允許指定AWS Account 能對該event bus 管理與並關聯的規則，同樣請把<ACCOUNT_ID>換成自己的Account ID。
• 把###括起來的所有提示刪去，並按自己的需要編輯其Policy。
• 由於我們不需要Organization內的所有帳號都能傳入event，故把第二段刪去。
Step.6
完成編輯後的Policy大概會像這樣子。
Step.7
把編輯好的Policy貼回去後：
1. 點一下格式化Policy；
2. 點擊”Create”建立Event bus。
以上是建立事件匯流排Event bus的流程。
規則用於比對傳入的事件(Event)及把比對結果傳到目標上。一項規則能向多個目標平行傳送Event。Rules基於Event pattern 或 schedule (排程)。事件類型定義了Event的Structure及用於比對的欄位。
簡單來說，規則像是設定條件來與發生的Event作比對，若比對成功的話，則向設定好的目標發出事件結果，以觸發其他服務。
以下是一個規則的設定範例：
Step.1
前往AWS Console，前往EventBridge服務，從左方選單點擊”Rules”。
Step.2
1. 選擇自己建立的Event bus；
2. 點擊”Create Rule”以建立Rule。
Step.3
定義Rule的詳細項目：
1. 輸入Rule的名字；
2. 輸入Rule的描述；
3. 選擇Rule要關聯的Event Bus；
4. 當啟用時代表Rule在Event Bus建立之後，便會設定成啟用狀態；
5. 選擇”Rule with an event pattern”，代表該Rule使會與傳入的Event比對再傳出結果；
6. 設定完畢，點擊右下角”Next”至下一步。
• 注意：排程類型的Rule不能夠在自定義或第三方的Event bus中建立。
Step.4
建立Event類型：
Event source：選擇該Rule接收的Event來源。
1. AWS Events or EventBridge partner events：接收AWS或EventBridge 合作夥伴所產生的Event；
2. Other：其他自定義的Event或是從多個來源發送的Event；
3. All events：接收所有該帳號收到的Event。
這裡的Demo會以AWS EC2服務所發出的任務為主，因而選擇第一項。
Step.5
Sample event：
在這裡可以設定預計傳入Event bus的Event的例子； 雖然這一步可以略過不填，但它可以用來測試你之後設定的Event pattern。
Sample event type 事件例子類型：
1. AWS events：AWS 服務所產生的events；
2. EventBridge partner events：EventBridge合作夥伴所產生的events；
3. Enter my own：以JSON的方式輸入自定義Event。
Sample event 事件例子：
可以設定適合於應用場景的Sample event。
這裡作為例子輸入”EC2 Instance Launch Successful”，當EC2啟動成功的例子。
Step.6
Creation method 建立方法，從左至右分別是：
1. Use schema：使用EventBridge create schema的功能生成的事件樣式；
2. Use pattern form：使用樣式表格，AWS 提供一個表格供你填寫以生成Event pattern；
3. Costom pattern (JSON editor)：使用JSON編輯器來撰寫自定義的Event pattern。
這次示範會使用第二項來生成Event pattern。
Event pattern 事件樣式：
我們會生成一個EC2進行運行狀態的事來示範。
1. Event Source：事件來源，只可以選擇AWS services 或 EventBridge partner兩個，由於我們是使用AWS服務所生成的Event 所以選擇AWS services；
2. AWS service：選擇生成Event的服務，這裡選擇EC2；
3. Event type：選擇事件類型，這裡選擇EC2 Instance State-change Notification，EC2狀態改變通知；
4. Specific state(s)：加入指定的狀態，這裡加入running；
5. Any instance：這裡可以指定只接收指定ID的Instance所發出的事件，不只定的話所有Instance進入running狀能都會觸發。
設定完成後，右邊會按照要求生成Event pattern，確定無誤後點擊”Next”進入下一步。
Step.7
Select target(s) 選擇目標：
在這裡將設定若傳入的事件符合Rule所設定的Event pattern則觸發的目標。
在這個示例中將會觸發SNS的Topic發佈Event。
1. Target types：選擇目標類型，分別可以選EventBridge event bus，把事件傳到別的event bus； EventBridge API Destination：把事情傳到API 端點，通常是SaaS Partner的；最後是AWS service，把Event 傳到別的 AWS service 去 ；
2. Select a target：選擇目標服務，這裡選擇SNS topic；
3. Topic：選擇自己建立的SNS Topic。
當設定完後點擊”Next”下一步。
Step.8
Configure tags：設定Tags的地方，用於資訊分類及集中管理。
這次因Demo的原因故不設定任何Tags，點擊”Next”進入下一步。
Step.9
最後確認設定正確後，點擊右下角”Create rule”建立規則。
Step.10
由於AWS Services所發生的Event，只會也只能傳到default的Event bus。所以接下來我們會需要在default的Event bus 建立Rules，把Event 傳入自己建立的Event bus裡面。
其設定如下：
Step.11
接下來前往EC2 Console，重新啟動測試用的EC2以觸發事件。
Step.12
這樣，EC2 Instance 改變成 running狀態之後，會把該事件傳送到default event bus，觸發轉送的Rule，再轉送到自定義的Event bus，觸發呼叫SNS的Rule，從而傳出Email到所有該Topic的Subcriber。
以上是規則Rule的設定例子。
全域端點 (Global endpoints) 可以讓你的應用程式擁有區域故障容許性。首先你需要在Route 53 的健康檢查指向應用程式的端點，當故障事件發生，健康檢查將會回傳”不健康”的狀態。在故障轉移開始後的數分鐘內，所有自定義的Event都會被路由到在備用區域裡的Event bus，並被其處理。當健康檢查回傳”健康”狀態時，所有Events會被路由回到首要區域內的Event bus。
本文並不會列有建立全域端點及其測試，但會列出建立表格之內容並進行解釋。
需要更進一步了解的話，見這裡。
解釋如下：
端點詳細資料：
1. 輸入全域端點的名字；
2. 輸入全域端點的描述；
主要及備用區域Event bus 之詳細內容：
1. 選擇主要區域(Primary Region)中的Event bus，則要進行備援的Event bus；
2. 選擇備用區域(Secondary Region)，即備援Event Bus所在的區域；
3. 選擇備用區域中的Event bus，即備援Event bus。
災難轉移及復原：
1. 選擇Route 53 中已建立並需監察的Health check；
2. 若未建立Health check的話則可點擊這裡進行建立。
資料複寫：
啟用後Event 將會在備用區域進行異步處理，這代表Event不保證在兩個區域內同時被處理。當故障轉移發生時，Event會被備用區域所處理，只有主要區域恢復後才會被它處理。
AWS官方推薦使用事件複寫，原因為下：
• 事件複寫可幫助您驗證全球端點的配置是否正確。這有助於確保在發生故障轉移事件時您將得到保障。
• 為了自動從故障轉移事件中恢復，需要啟用事件複寫。如果您未啟用事件複寫，則必須手動將Route 53健康檢查重置為“健康”，然後事件才會返回到主要區域。
1. 啟用資料複寫的按鈕；
2. 選擇要建立一個新的Role或使用現有的Role；
3. 建立新的Role的名字。
以上建立全域端點的設定說明。
當您在EventBridge中創建時，可以通過指定事件模式來確定發送到存檔的事件。EventBridge會將與事件模式匹配的事件發送到存檔中。您還可以設置保留期限，以在事件被丟棄之前將其存儲在存檔中。
在創建Event bus時可選是否建立Archive，以下是由AWS產生Archive：
1. Archive 的名字；
2. Archive 的描述；
3. Archive 的啟用狀態；
4. 已儲存的Event的大小；
5. Archive 的建立日期；
6. Archive會保留多久。
以上是Archive的例子。
創建存檔後，您可以從存檔中重放事件。例如，如果您更新具有附加功能的應用程序，則可以重放歷史事件以確保事件被重新處理以保持應用程序的一致性。您還可以使用存檔重放事件以實現新功能。當您重放事件時，可以指定要從哪個存檔中重放事件，事件的開始和結束時間，事件總線或一個或多個規則以將事件重放到其中。
以下是建立一個Replay的例子：
Step.1
在Replays的頁面上點擊”Start new replay”來建立新的Replay。
Step.2
1. 輸入Replay的名字；
2. 輸入Replay的描述；
3. 選擇要從哪一個Archive進行Replay；
4. 選擇Replay時重新觸發的事件會傳到哪個Event bus；
5. 重新觸發所有Rule觸發的Event，又或是只觸發指定Rule所觸發的Event。
Step.3
1. 輸入需要Replay的開始時間及時區；
2. 輸入需要Replay的結束時間及時區；
3. 點擊”Start Replay”開始Replay。
Step.4
從CloudWatch的Invocations來看可以看到它在沒有實際觸發Event的情況下觸發了Event，代表Replay成功。
以上是Replay的建立例子。
Amazon EventBridge Scheduler 是一種無伺服器的排程器，可讓你在同一排程器上建立、執行、管理多個Task，並管理服務。由於並無伺服器的特性，使其擁有高擴展性，高可靠性等特性。
你可以使用排程器設定時間及頻率來使排程器發出指定Event pattern 的 Event，又或是設定一次性的Event觸發機制。
例如你想在每天早上8點啟動某一台EC2，並在晚上6點關閉它；或是向下遊服務發出一次性Event，使用EventBridge的Scheduler功能都可以完成。
使用 Amazon EventBridge 排程器大規模安排任務和事件。
每個排程都有自己的排程規則表達式，用於描述該排程在何時、以什麼頻率去執行排程內容。EventBridge 排程器支援三程不同的排程：分別是速率、時間及一次性排程。
排程與規則(Rules)同樣用於把已發生的Event傳送到目標，不同的地方在於規則(Rules)發送Event的原因是他發性的，而排程(Schedules)發送Event的基準更像是自發時，只要設定好就會按照設定發送。
簡單來說兩者都需要設定，但Rules在設定後還需要額外的輸入才會傳出Event，而Schedules並不需要額外的輸入才會傳出Event。對於一些具週期性及重複性較高的Task來說更合適。
以下是設定一個Schedule的例子：
Step.1
1. 進入EventBridge的Console，點擊左方選單中的”Schedules”；
2. 點擊右方”Create schedule”來創立一個新的Schedule。
Step.2
1. Shedule name：輸入Schedule的名字；
2. Description：輸入Schedule的描述；
3. Schedule group：選擇所屬的Schedule group，用於分類管理Schedule，這裡自選擇default。
Step.3
先以一次性觸發為例：
1. Occurence：觸發模式，可以選擇一次性觸發或週期性觸發；
2. 輸入觸發的日期；
3. 輸入觸發的時間；
4. 輸入觸發時間的時區；
5. Flexible time window：彈性時間觸發區間，以這設定為例即在UTC＋8的2023/03/17的03:00開始一小時內觸發，若需要準時觸發的話可以將本功能關閉。
這次以週期性的Schedule為例：
1. 選擇週期性的Schedule；
2. Schedule type：選擇排程類型，這次先示範Cron表達式的方法；
3. Cron expression：這裡我輸入的Cron表達從右到左代表 “從2023年到2024年每個月最後一個週五的10小時15分” 都會執行該Schedule，詳細的cron表達式見這裡；
4. 列舉出未來十個將會執行的時間，用於確認cron表達式填寫是否正確；
接下來是基於頻率的Schedule：
1. 選擇基於頻率的Schedule；
2. 設定頻率表達式：這裡設定了5分鐘，即該Schedule開始運作每5分鐘就會觸發一次；單位分別有：分鐘，小時，日。
Timeframe，上述的Schedule只會在Timeframe內生效：
1. 描述Timeframe生效的時區；
2. 輸入Timeframe生效的開始日期及時間；
3. 輸入Timeframe生效的結束日期及時間。
完成設定後點擊”Next”進行下一步設定。
Step.4
Select target 選擇目標：
選擇發送Event的目標，這裡以SNS為示範。
Step.5
Publish 發佈，填入SNS相關的資料：
1. SNS topic：選擇發佈信息的Topic；
2. Input：輸入要發佈的信息，需為JSON物件的格式。
Step.6
Settings 設定：
1. Enable schedule：設定建立完畢後是否設定為啟用狀態；
2. Retry policy：啟用重送政策，即當Event傳送失敗時會否重新嘗試；
3. Maximum age of event：event的最長存活時間，即當event送失敗嘗試重新傳送時，event還能存活的時間，超過該時間的話會被視作Dead-letter處理；
4. Retry attempts：event傳送失敗時最大重新嘗試次數，當超過該嘗試次便會當作Dead-letter處理；
5. Dead-letter queue (DLQ)：當Dead-letter發生後該傳到哪個Queue，選擇None的話代表不對Dead-letter進行下一步動作，或是可以傳入AWS SQS的Queue中作其他處理。
Step.7
1. Encryption 自定義加密選項：雖然傳送Event的資料都會由AWS 管理的 key 進行加密，但若有自定義加密的話可以輸入相關資料；
2. Execution Role：設定執行的時候所需的Role的類型；
3. Role name：選擇執行時所需要的Role。
接下來只需確認設定並點擊”Create”建立即可。
Step.8
接收到由SNS傳送來的Email，內容亦符合設定。
以上是建立Schedule的例子。
排程群組(Schedules group)是一種用於管理Schedules的群組。
排程群組的功能並不複雜，它簡單來說就是一個可以讓你加入、刪除及上Tag的Schedules group，用於管理大量Schedules；此外Schedules group只會有兩種狀態：啟用(Active)及刪除中(Deleting)。
預設每個AWS Account都會建有一個default Scheduel group，預計建立的所有Schedule都會在這個群組裡面，若需要另外的排程群組，以下是建立排程群組(Schedules group)的例子：
Step.1
前往Amazon EventBridge Console後：
1. 點擊左方選單內的”Schedules group”；
2. 這裡可以看到default的Schedules group正在啟用；
3. 點擊”Create schedule group”建立新的Schedule group。
Step.2
1. 輸入Schedule group 的名字；
2. 新增Tag的按鈕；
3. 點擊”Create schedule group” 來建立此shcedule group。
Step.3
接下來在建立Schedule事便可以選擇該Schedule group了。
以上是建立Schedule group的例子。
使用Amazon EventBridge 可以以Event的為中心建立事件驅動架構應用程式，這使應用程式能進一步提高並可靠性及解耦合性，更符合現代應用程式的模式。
即使不使用上述架構，Amazon EventBridge也可以協助你完成一些具週期性或重複性的功能，使你在結合使用AWS服務性更加得心應手。
MetaAge 邁達特數位在資安、網路、儲存、伺服器、虛擬化、資料庫管理有豐富經驗，技術深厚的架構師群與維運團隊是企業雲服務的最佳幫手。客戶無論想要部署 AWS 服務，進一步代管維運（Cloud Managed Service）、基礎架構即代碼(Infrastructure-as-code)、 API 整合、雲地整合等加值服務，邁達特均能一站式滿足多構面需求。
MetaAge 邁達特數位(原聚碩科技)於1998年創業之初，即以成為「The ICT Solution Provider專業資訊應用服務供應商」角色自期，為經銷夥伴與企業用戶提供一流產品與專業服務，成為業界最佳之加值服務名牌通路商。針對廣大的經銷商夥伴以及雲市集之獨立軟體供應商(ISV)，也可洽談經銷合作方案，設計後續合作的框架。
MetaAge 邁達特代理的軟硬體產品線均為全球知名品牌，針對廣大的經銷商夥伴以及雲市集之獨立軟體供應商(ISV)，提供強大的技術支援與量身訂作之經銷合作方案，擴大合作夥伴的服務範圍，在多樣化的場域中一同實現更優質的客戶服務體驗。
邁達特持續作為IT智能化最佳夥伴，竭誠歡迎舊雨新知攜手共創數位新局。
MetaAge邁達特數位 AWS MSP 團隊導入次世代監控系統，提供客戶完全託管和完整監控的 MSP 整合服務。
聯絡方式 —— 24小時免付費電話: 080-000-8669 | Email: aws@metaage.com.tw | MSP服務官方LineID: @metaage_msp
雲端運算是什麼 ? 有什麼好處？如何挑選上雲的合作夥伴？啟用您的第一個雲端專案，享受隨開即用的無限資源，快速滿足商務需求
https://aws.amazon.com/tw/eventbridge/
https://docs.aws.amazon.com/zh_tw/eventbridge/latest/userguide/eb-what-is.html
