透過ELK技術打造Smart Search系統

• Elasticsearch

Elasticsearch 為 ELK Stack 架構中的核心，本身的定位為分散式的搜尋系統，其中的優勢為

1. 分散式的系統能透過各自的處理器與記憶體達到搜尋時的加速效果。

2. 本身是以反向索引的方式去儲存資料，所以在全文檢索的效能與結果上比一般的資料庫更加優秀。

3. 同時也是 Smart Search 叢集中的資料存放中心，分散式的系統同時也保證了資料的備份，提高整體服務的穩定性，防止突如其來的個別節點故障所造成的影響。

• 區間帳務檢測

確保 Kafka 每段時間內傳送出的資料與寫入 Elasticsearch 的資料是同步的，若是發生錯誤時則可以透過此檢測得知 Elasticsearch 內的資料出現問題，並針對問題的嚴重程度即所負責之單位進行告警通知，能夠在第一時間就能快速掌握系統健康度。

需要考慮到從 Kafka 與 Elasticsearch 中讀取資料的不同特性，加以設計即時比對程式，而Kafka 與 Elasticsearch 有官方開發的程式套件，對於開發客製化程式上有一定的穩定性以及後續的維護也會較方便。

• 每日帳務校驗

經過區間帳務檢測可知道 Elasticsearch 是否寫入正常，且考量到即時串流方案發生問題時，可作為資料同步的備案，故需要每日帳務校驗的功能，此功能可從中心帳務主機取得資料庫內之完整資料，此資料則不會受到 Kafka 影響，所以可以與 Elasticsearch 內的資料進行完整比對。

需要考慮到資料庫每日產出檔案的時間區間與此區間即時寫入 Elasticsearch 的資料可能會有內容更新的問題，或是資料庫有做手動更改資料內容時， Smart Search 叢集需要如何修改內容等技術問題。

• 本地備援與異地備援

根據系統服務的等級可做此規劃。

1. 重要性較低的系統，可使用本地備援即可，本地備援機制為Elasticsearch 本身的 HA 機制，同時會有數個節點進行互相備份，若是少量節點失效，叢集仍然能正常運作，為維護者保留修復系統的時間，除此之外會定時進行 Elasticsearch 的Snapshot，確保叢集因意外而故障時，能及時將資料轉移至其他伺服器進行服務，但是其轉移資料的時間會需要一段時間，無法像異地備援一樣直接做切換的速度。

2. 重要性較高的系統，如交易系統、客戶服務系統等，則可除本地備援外再加上異地備援，異地備援則是本地叢集的鏡像備份，異地備援本身也是有 Elasticsearch 的 HA 與 Snapshot 機制，由於可能會發生整個廠區或是大樓斷電的意外，故異地備援為針對此意外所產生時的運作機制，其能即時切換至鏡像叢集繼續進行服務，使整體系統服務的 Down time 最小化。

        備援機制需要考慮到的實作方式有以下幾點：

1. 備份方式，若是大批量同時備份會造成在使用之叢集的負擔，過小批量則會造成維護上的複雜。

2. 備份時間，本身有差異備份的機制，所以不會造成每次負擔都很重，但是仍需要尋找適合的系統非尖峰時段進行備份。