韓國最具破壞性的地震,原因竟來自地熱發電廠?

韓國最具破壞性的地震,原因竟來自地熱發電廠?
Photo credit: AP / 達志影像

我們想讓你知道的是

2017年11月15日韓國浦項市(Pohang)發生規模5.4的地震,是韓國自1978年有紀錄以來規模第二大的地震。近日調查研究小組於國際期刊《Science》發表,認為地震可能是由當地實驗性地熱發電廠,於地下注入液體導致。

  • 更多地熱發電相關科學資訊請點此

議題:韓國最具破壞性的地震,可能是由地熱電廠引發

背景描述:2017年11月15日韓國浦項市(Pohang)發生規模5.4的地震,是韓國自1978年有紀錄以來規模第二大的地震。近日(2018年04月26日)調查研究小組於國際期刊《Science》發表,認為地震可能是由當地實驗性地熱發電廠,於地下注入液體導致。另一個獨立研究分析,也認為地震發生的原因可能與電廠相關。

報導指出,傳統的地熱發電需要特定的地質條件支撐,但加強型地熱發電系統(Enhanced geothermal systems, EGS)──也就是此次浦項市使用的形式,可以在次佳的地點進行熱開採,但須透過高壓在深達幾公里的鑽孔中注入液體,促進熱能的提取。同時因研究小組認為主要震源深度只有4.5公里,遠低於韓國一般地震,但與電廠鑽井深度4.4公里相近,且再鑽井完成前五年內,該地點無任何地震,因此認為地熱電廠與浦項地震有相當的關連性。

但韓國延世大學地震學家持反對意見,認為震源深度比電廠的注入井深,是韓國常見的震源深度。同時工廠在地震發生前兩個月已不再注入液體。

相關資訊:

  1. 《Nature》期刊新聞:South Korea’s most-destructive quake probably triggered by geothermal plant
  2. 《Science》期刊官方調查研究小組相關發表:Assessing whether the 2017 Mw 5.4 Pohang earthquake in South Korea was an induced event
  3. 《Science》期刊獨立研究小組相關發表:The November 2017 Mw 5.5 Pohang earthquake: A possible case of induced seismicity in South Korea

對此,國內專家進行回應如下。

馬小康教授(臺灣大學機械工程學系暨研究所):
深度超過4公里以上,確實能誘發規模1-2的地震

對於地質領域的了解不足,無法對「韓國浦項(Pohang)地震與地熱電廠有高度關聯性」之調查報告與報導做出評論。

但過去參訪美國北加州及其他地熱廠,得知深度超過4公里以上,確實能誘發規模1-2的地震,但規模4以上地震,較為少見。誘發地震(Induced Earthquake)亦與地下地質結構息息相關。

宋聖榮教授(臺灣大學地質學系):
依理論計算,韓國EGS計畫所灌注的水量和壓力是不足以引發如此大的地震

構成地熱系統的三要素:溫度、流體和裂隙。地球為一顆發熱體,深度越深溫度越高但流體越少裂隙越稀,所以要開發深層地熱需用人工高壓注水(液裂)產生裂隙形成儲集層,然後取熱發電,此種地熱方式稱為加強型地熱系統(EGS)。因EGS可產生大量的地熱能且是乾淨、可當作基載的電源,不管是地熱豐沛的國家如美國,於2014年提出地熱前瞻FORGE計畫,希望於2050年能建構100GW以上的地熱電廠,供一億個家庭使用,或是地熱蘊藏不佳的國家如法國、德國、瑞士和韓國等,都在積極的發展深層地熱。

EGS在注水創造人工裂隙時,因岩層破裂會發生「誘發地震」,如2007年瑞士Basal地熱EGS計畫誘發3.4的地震,造成部分建物毀損而暫時停止該計畫。針對EGS誘發地震的問題,2014年美國的FORGE計畫和2015年瑞士後Basal EGS計畫,都不約而同的提出高溫水平鑽井和小規模可控制的液裂,以解決EGS所碰到的誘發地震問題。

2017年11月的韓國浦項市(Pohang)發生規模5.5的有感地震,是韓國有地震紀錄以來規模第二大的地震,也是破壞性較大的一次地震。因其震央接近EGS深井注水產生裂隙地區,故韓國地震學家Kwang-Hee Kim等人和瑞士F. Grigoli等人,在世界著名的科學(Science)期刊發表是因EGS注水所誘發的地震,為截至目前為止因注水液裂所發生最大的地震,震驚地熱界,將對未來地熱開發造成深遠的影響。

然而依理論計算,韓國EGS計畫所灌注的水量和壓力是不足以引發如此大的地震,且發生地震的時間為停止注水後的兩個月,所以這些學者都認為注入的水可能進入應力累積已達臨界點的地下未知之活動斷層,以至於引發如此大的地震。從韓國EGS計畫因注水引發規模5.4的地震,學習到從事深層地熱開發時要對當地的地下地質構造有充分的調查研究,繪製地熱區3D高解析度的地質圖,才可避免類似的誘發地震發生。

台灣深部蘊藏豐沛的地熱資源,不僅其是乾淨可再生的能源,也是最重要可當基載的綠色電源。從瑞士Basal-EGS、美國FORGE和韓國EGS計畫的經驗中,未來要從事台灣深層地熱的開發需先從事詳細地熱區的地下地質調查,完成3D高解析度的地質圖,並排出地熱區的優先開發順序。

王守誠博士生(海洋大學應用地球科學所):
誘發地震大部分為無感地震,控制回注壓力即可避免誘發有感地震

誘發地震(Induced seismicity)是近年地震學術圈討論及研究很熱烈的主題,主要原因是美國中西部開採石油(非頁岩氣)使用提高石油採收率技術(Enhanced Oil Recovery,簡稱EOR)導致許多誘發地震發生,引起許多地震學及地質學家進一步研究,因此誘發地震機制已經較為明確,而頁岩氣及地熱開發造成的誘發地震由於比例少、能量低,沒有引起太多討論。

但在地熱領域有瑞士及韓國兩個加強型地熱(EGS)案例引發大眾的專注,原因是這兩處國家極少發生地震,因此科學家難以估算地下應力累積程度,這些誘發地震所釋放的累積應力可能是當地數萬年的所累積,因此缺乏耐震能力的傳統建築物受到極淺層地震較大的破壞,這種誘發地震的機制跟回注流體的壓力有明確關係,因此瑞士已經著手改良工程技術,減少注水壓力即可控制誘發地震,朝向繼續發展地熱發電這種永續乾淨的自主能源。

相關議題其實在國內第一次地熱環評的小組專家會議已有充分討論過。誘發地震大部分為無感地震,控制回注壓力即可避免誘發有感地震,因此需要在工程管理及社會溝通同時兼顧,其實性質很類似建築工程需要避免開挖地下室的鄰損事件。

本文經新興科技媒體中心授權刊登,原文刊載於此

責任編輯:朱家儀
核稿編輯:翁世航


猜你喜歡


挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

挖掘雲端開放架構優勢!Amazon EKS高可用性叢集快速部署容器

我們想讓你知道的是

企業如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署,減輕人力負擔,提升專案服務運作效率?

所謂現代化智慧 IT,所有工程師最希望的境界,莫過於只要輕鬆點幾下設定,系統就會自動跑起來,管理者再也不用隨時待命在機台旁邊,從此工作悠哉又快樂!儘管這樣情境還沒到來,但隨著敏捷式開發的流行,除了 DevOps 人員,有越來越多開發者將 CI/CD 概念融入到工作流程當中,例如從 build code、執行 unit test、到部署應用程式。

透過 AWS 增加雲端技能 在組織發揮影響力

上述種種反覆步驟自動化執行,也就能提昇服務品質、主動通知開發人員以減輕人力負擔,讓專案服務能持續運作。

其中,GitLab 是執行 CI/CD 常用的工具之一,也是開發者使用程式碼儲存庫的地方。為了讓 GitLab Runner 在雲端快速實踐 CI/CD,《AWS 開發者系列》透過影片分享,如何在 Amazon EKS(Elastic Kubernetes Services)上使用 GitLab 創建自動化部署。

以下節錄工作坊影音內容,幫助開發者快速理解如何運用 Amazon EKS 的高可用性且安全的叢集,將修補、部署節點、更新等關鍵任務,全部做到自動化設定。同時影片也會示範 Amazon EKS 搭配 GitLab 如何展開自動部署,幫助工程團隊實踐 CI/CD 價值。

Amazon EKS 對容器管理輕鬆簡單、維運省時省力

容器化服務越來越興盛,當容器(Container)越來越多,在複雜的微服務(Microservice)系統環境之下,運維團隊的管理成本可能相對會增加不少,為了有效調度容器部署, 導入Kubernetes 無疑是近年企業熱門的話題之一。

建構 Kubernetes Cluster 流主要可區分兩大塊,一是安排容器調度的Control Plane、另一則是容器運行時需要用到的 Worker Node。

Control Plane 裡面涵蓋有儲存狀態的 ETCD、CoController manager 、Scheduler 的調度管理、甚至是操作時進行互動的 APIServer,若是自己創建 的 Kubernetes Cluster ,需要自己安裝這些元件,後續仍需要對 Control Plane 進行相關管理、維護、升級工作。為了減少上述 Components 的繁複維護,在透過 AWS EKS 代管的 Kubernete Control Plane 部可以獲得以下三大好處。

Amazon EKS 一鍵式部署,展現三大優勢

第一,Amazon EKS代管的 Control Plane實踐了跨AZ的高可用部署,使用者不需要擔心單一節點故障的風險。

第二,Amazon EKS 支持至少四個 Kubernetes版本,持續跟進每季 CNCF 的發佈,同時 EKS 也完全符合上游 CNCF 規範。

第三,部署 Amazon EKS 之後,可直接使用 AWS 平台上現成的服務工具,在安全性管理、網路設定方面,可以做到無縫整合。

最後 AWS 台灣解決方案架構師也提到,若想在容器環境進行 CI/CD 及應用程式的管理,可以進一步透過 IaC 整合部署 Amazon EKS 叢集,透過使用 Console、把 EKS 變成 Cloudformation 的模板、使用 AWS 所開發出來的 eksctl.io、或指令是採用 AWS CDK 可以讓開發者用自身熟悉的語言,在 AWS 平台整合 CI/CD 工具進行維運及部署 EKS。

打造第一個在 AWS 上的應用程式

了解 Amazon EKS 整合 GitLab ,獲得三面向價值

對開發者而言,想把 Amazon EKS 整合到 CI/CD 工具之一的 GitLab 平台上,可以看到那些實際的優勢?

在 DevOps 開發者示範工作坊當中,GitLab 資深解決方案架構師指出,GitLab 使用到 Kubernetes 技術,主要有三種搭配方法,包含 GitLab Server、GitLab Runner、以及創建 Deployment Environment。

本次示範教學會主要聚焦在 GitLab Runner 如何採取 Auto-scaled 方式進行 Build、Test、Package Apps;以及在 Deployment Environment 運用 Kubernetes 技術,做到 Auto Deploy、Review App。

正因為 Amazon EKS 能夠在 DevOps 過程提供所需要的彈性計算資源,幫助開發者在 GitLab 平台上面獲得以下三個層次的優勢:

  • 在 GitLab 內建的部署工作流程當中,自動生成整套 CI/CD 最佳實踐腳本。
  • Review App 過程,從 Merge Request 中可直接訪問應用程式 /App 的 UI 介面,並且根據 Git branch 名稱、專案名稱,自動生成 Review App 的 URL,以及在 Merge 前的最後防線進行 Approval 檢查。
  • 加速 CI/CD 流水線,GitLab Runner 運行時候還可藉由 Amazon EKS Cluster 進行 Auto-scaled 的支援。

Amazon EKS 整合 GitLab ,需要兩大流程

影片最後,GitLab 資深解決方案架構師示範如何把 Amazon EKS 整合至 GitLab 執行 Auto Deploy,主要可分為兩大區塊流程,第一部分聚焦在 Amazon EKS cluster 的設置,第二部分則執行 Auto Deploy 設置。

第一塊可拆分為四個階段,首先教學怎麼創建 EC2 節點的 EKS cluster,第二階段示範把 EKS Cluster 連接到開發者的 GitLab Instance、Group 或 Project,下一步則使用 Cluster Management Project Template 創建一個 Cluster Management Project,以及最後一階段透過 Cluster Management Project 自帶的 Helm Chart,安裝在 Cluster 所需要的內建 App。

第二塊執行 Auto Deploy 設置,針對需要部署的 App 創建一個 GitLab Project,接著再把 gitlab-ci.yml 添加到 Project,並從 Web IDE 選擇及導入 Auto Deploy 的 CI 模版,讓 GitLab 自動生成最佳實踐的整套流水線。

幫助開發者更了解 Amazon EKS 整合 GitLab 的 QA 系列

Q:使用 Amazon EKS 之後,如何更有效率或優化資源去配置 Worker Node 的機器數量,以及如何有效空管開發維運的成本?

A:Kubernetes 除了本身有 HPA(Horizontal Pod Autoscaling)可根據使用程度自動調整資源流量,另外也能延伸使用 AWS Auto Scaling 方案,針對可擴展資源去設定自動擴展管理。另外在成本管控,雖然 Amazon EKS 會收取額外管理費用,但可透過 AWS 平台的 Calculato r計算每個 EKS 的價格,你會發現自動化部署及管理的費用,相對工程師人力的成本更加便宜。

Q:越來越多客戶考慮把現有 Application 變成容器部署,大多是爲了加快部署的效率,那麼變成容器模式之後,對 CI/CD 的工作流程有什麽影響嗎?

A:運用容器技術最直接的效果,可以讓應用程式的環境更一致化,例如 testing 環節、stage production,讓容器避開一些差異問題。至於 CD 部分要 delivery 一些 usage 不太一樣的時候,容器會幫忙做配置,所以 CI/CD 對容器的效益是相輔相成的。

Q: 客戶在開發流程漸漸會把 Infrastructure 變成代碼或文檔,是不是可以把程式碼跟現有的應用程式的 CI/CD 流水線整合在一起,達到一套完整的 CI/CD 部署流程?

A:觀察目前市場作法,主要分成兩個階段去做整體部署。如果規模比較小的團隊,會把 Infrastructure 代碼跟 App 代碼分開,在管理上會比較靈活;如果企業規模比較大,會有另外一個 Infrastructure 團隊來控制部署事情,這種情况之下,APP 的項目會生成一個 APP package,主要做到 delivery 這個階段爲止。而 Infrastructure 的項目會指定把需要版本的文檔,部署到他們的 Kubernetes Cluster。

填寫表單 找到適合的快速上雲服務與工具!


猜你喜歡