VeryBuy技術團隊一直致力於優化現有的後端架構，在衡量整理架構能夠達到當求的業務目標外，以最能夠符合經濟效益的方式逐步優化現有的架構，近期VeryBuy團隊就以後端常遇到的技術轉移問題作一些經驗上的分享
故事
幾年前，在升級搜尋功能時，由於版本差異過大，我們決定重新架設系統。當時進行調查時，我們本來希望使用現成的服務（如Elastic Cloud或AWS ElasticSearchService）來處理，但是發現我們需要使用的擴展功能並未包含在現有的機器規格中，因此我們只能選擇自己在EC2上架設系統。現在，正好是一個很好的時機進行轉移和更新。
ElasticSearch 跟 OpenSearch 的關係
補充一下背景知識，ElasticSearch原本是一款開源軟體（採用Apache 2.0授權），AWS推出了Amazon Elasticsearch Service服務。但ElasticSearch對此提出異議，並修改了授權和認證方式。為此，AWS基於ElasticSearch的最新版本7.10分支，創建了OpenSearch並重新命名。在我們的技術堆疊中，AWS佔主導地位。在與其他團隊成員進行評估和討論後，我們決定以OpenSearch作為轉移的對象。
轉移前狀態
ElasticSearch version 7.3 版本
使用 EC2 自建 Cluster 安裝我們要使用的 extension 跟上傳自定義字典檔(IK)
轉移版本
OpenSearch v1.3
轉移考量的點
優點：
- OpenSearch 可以一鍵更新，省去了維運和升級成本，並且有內建許多 extension（包括我們目前正在使用的 IK）。
- OpenSearch 是 AWS 服務，整合現有服務很簡單，而且架設和設定都非常簡單，只需要幾個點擊，後台點一點後等待一下就可以完成。
- OpenSearch 可以避免自己處理 cluster 的問題，大大簡化了架設和維護的難度。
- 可以設定 VPC，權限控制系統完整，並且可以進行很多精細的權限設定。
- OpenSearch 有良好的監控畫面和後台，讓管理者可以更好地掌握系統的狀態和運作情況。
- 目前有官方支持更新，因此即使出現問題，也可以得到官方的支援。
缺點：
- OpenSearch 相對於自架來說可能會更貴，但這也省去了很多維運和升級成本。
- 升級是不可逆的，如果不小心升級出現問題，只能重開一個環境然後自己轉回去，因此一定要多開一個測試環境，並進行完整的測試後再上正式機。
- Extension 受限，目前只有官方提供的 extension 可以使用，無法自己添加，但目前官方提供的 extension 已經涵蓋了常用的功能，因此在大多數情況下仍然可以滿足需求。
- AWS 其他相關服務需要一定的熟悉度，否則可能會因為權限問題而遇到困難。
架構圖
舊版自建架構
新版 OpenSearch
實作過程
原本在設計搜尋系統的時候，就預計他是一個可以被重複建立的情況。
一開始就有寫好一個將所有資料重新倒入的 script
當把 OpenSearch 的環境架設好之後
上線流程就很簡單了
- 先用 script 將所有商品倒入 opensearch
- 把 endpoint 從自建的 es 改成 opensearch 的 endpoint
- 把中間有更新到的資料重新在更新一次
因為我們資料量多跟來源不一樣的問題，整個 script 跑完約需要 2~3 小時
而中間商品資料還是有持續在更新，所以當改完 endpoint 後需要中間有被修改的資訊再更新一次，達到資料最終一致 - 測試結果是否如預期
基本上在測試環境應該都已經走過幾次這個流程了
但如果真的不幸發生意外，也只需要把 endpoint 切回舊的，再慢慢 debug 看到底為何會壞掉，時間壓力就沒那麼大
心得及後續方向
使用別人做好的服務自然是舒服很多，也省了很多之後的維護問題
是剛接觸的話想測試看看而已的話
不考慮權限直接開 public 就可以開始玩了
但如果是想熟悉底層架構的話，就還是得自己架設一次，再回來對照他的各種設定會比較其運作原理
這次在轉移過程中我覺得最困難的是前置作業
像是處理權限的部分，如何讓 OpenSearch 跟 VPC 做連動
畢竟不會希望自己的系統在外面裸奔
處理的過程中就有發現自己不熟的東西，也可以趁機去搞懂他們到底是怎麼連動的
像是這邊是用以前沒用過的 SigV4，因為以前都是用 VPC + Security group 來限制存取，很習慣的以為這邊也是一樣
結果開始做才發現說他不在 VPC 下，不知道該怎麼存取他，看文件才知道他的認證方式不一樣(https://docs.aws.amazon.com/opensearch-service/latest/developerguide/vpc.html)
然後確認是否有如預期的結果（測試斷詞, 搜尋結果等等）
原架構的部分因為本來就有寫好 script ，目前版本也還沒有差太多(ElasticSearch 7.3 to OpenSearch v1.3)
轉移過去本身反而是最簡單的
之後應該是會再玩玩他有安裝的 extension，看看有沒有機會優化現在的搜尋結果(反正都裝了，就拿來研究研究）
結語
整個搜尋所需的技術轉移從評估到上線其實並沒有花費太多時間，一方面是由於團隊成員有自建ElasticSearch Cluster的經驗，在轉換成OpenSearch的服務，並沒有太多的技術負擔需要克服，從而在轉移的過程中，不得不佩服AWS在整合這些基礎的應用服務上所提供的方便性及可靠性。而另一方面則是業務資料的轉移及維護，由於在之前就些許經驗及既有的腳本，這對我們並沒有太大的困擾。
上線當天也很順利地切換過去，目前在前台的使用上並沒有太大的問題，也使得後續許多優化搜尋內容的專案也能夠在OpenSearch逐步開展起來!
By 後端團隊
