值得注意的七條有關AWS EFS效能

您是否使用過Amazon EFS？它的主要用途是讓您能夠為那些基於 的應用負載和程式，構建出基於雲端的網路檔案系統。由於EFS的結構和功能都類似於本地的基礎架構，因此您可以輕鬆地傳輸各種既有的檔案。不過，在您打算將任何應用負載移入EFS之前，請先對EFS進行“試駕”，並在移入之後，定期執行各項效能方面的最佳化。

當然，有過實際專案經驗的小夥伴都知道：在大多數情況下，效能並不是一門精確的科學，而且會涉及到應用的各個真實環境與使用狀態。因此，在最佳化效能時，我們往往無法一蹴而就，需要持續、甚至反正地進行自動化或人工等方面的設定和嘗試。

在本文中，您將學習到AWS EFS的基本概念，如何對其進行配置和試用，以及如何透過七個重要方面，來保持EFS的應用負載能夠平穩高效地持續執行。

彈性檔案系統（Elastic File System，EFS）是AWS中的一種儲存服務，可被用於在雲端重新建立網路檔案系統。基於網路檔案系統v4（NFSv4）的EFS，主要是針對基於Linux的應用負載和程式而設計的。您可以順暢地將其與AWS的其他服務、以及本地資源整合使用。

與其他儲存服務相比，AWS EFS能夠提供的功能最接近本地現有的檔案儲存（具體請參見--https://cloud.netapp.com/blog/ebs-efs-amazons3-best-cloud-storage-system）。透過它，您可以輕鬆地將本地現有的檔案結構轉移到雲端，並享有如同訪問本地檔案那些進行各種流暢操作的體驗。為了達到該目的，您既可以透過在EC2（Elastic Compute Cloud）中託管應用程式，然後將例項附加到EFS上，也可以將EFS用作獨立的檔案系統。

在EFS中，您可以選擇如下兩種訪問方式：

· 標準訪問（Standard Access）是針對您的基本應用負載而設計的。其特點是以較高的成本換取較低的訪問延遲。

· 不頻繁訪問（Infrequent Access）專為需要長時間存放，卻鮮少使用的檔案而設計。其特點是：以較低的成本換取較高的訪問延遲。

當然，無論您選用哪一種訪問方式，EFS都是按照使用收費的。也就是說，它僅收取您實際使用的儲存和傳輸頻寬的費用。

在將檔案傳輸到EFS之前，您往往需要試用該服務。據此，您不但可以熟悉其相關的配置，評估其執行的效能，而且能夠透過與當前的本地系統作比較，更全面地預估在使用EFS時所需要的資源配置水平。下面，讓我們從EFS提供的“免費套餐（free tier）”開始吧。

免費的EFS tier提供了可以使用12個月的5 GB儲存空間。如果您手頭已經具有了可以將檔案系統掛載到的EC2中的例項，那麼EFS的試用並不困難。當然，如果您不喜歡該“套餐”的話，也可以選用一種適用於EC2的免費tier，它提供的750小時使用時長，足夠讓您從容地完成各項測試。

為了建立自己的demo，您可以透過 行介面（CLI）、或管理控制檯（Management Console）來建立各種資源。具體有關如何使用管理控制檯來設定和連線相應的服務，我們在此就不贅述了。如果您感興趣的話，可以透過連結-- ，去參考AWS的相關文件。

值得一提的是，請您在試用過程中，儘可能實際地去模擬對於目標檔案系統的各種使用操作。例如：您可以新增多個例項，使用單執行緒和多執行緒兩種方式去編寫檔案，以及採用標準和不頻繁兩種訪問方式去訪問各類資料。

一旦您決定了採用EFS服務，那麼就需要將自己的關注點轉移到確保能夠獲得最大投資回報上。以下是我為您總結的七條有關最佳化和提升AWS EFS效能的重要提示。並且您無需為那些不需要的資源支付額外的費用。

Burst credits是EFS最容易被忽視的方面之一。這些credits被設計為在流量較高的時候，暫時提高您的應用效能。但是，它們只會持續較短的時間，並且需要一段時間才能夠恢復。因此，這就意味著如果credits被用完了，那麼應用的效能就可能會突降。

每個EFS卷通常是以0.5 MB/s的傳輸速率開始的。Burst credits可以將吞吐量補充並拉昇到100 MB/s，且持續7.2分鐘。而增加此類指標的唯一方法是：增加EFS卷中儲存的資料量。也就是說，在最高可達到10 GB的資料量時，您可以持續獲得良好的效能

非同步寫入操作可以讓您透過消減資料傳輸的部分路徑，來減少寫入操作所產生的延遲。在啟用非同步寫入之後，資料會先被緩衝到某個EC2的例項中，再寫入EFS。

不過，值得注意的是，此項操作可能會影響資料的一致性。因此，如果您要求檔案系統保持實時同步的話，最好不要採用該操作方法。

如果您直接嘗試著在EFS中執行應用程式的話，則可能會碰到效能不佳狀況。畢竟，EFS並非被設計為執行或託管應用程式。它既無法執行針對大檔案的讀取，又無法為管理程式碼庫、或部署應用程式提供所需的速度。

相反，您應該從EBS（Elastic Block Store）和EC2處託管或執行應用程式（請參見-- ），併為附件檔案重新儲存EFS。例如，您可以讓EFS只提供的內容，而將其對應的服務限制在EC2中，以確保應用能夠獲得預期的效能。

跟蹤平均I/O吞吐量，可以幫助我們確定現有應用的瓶頸，進而設法壓縮儲存的區域。例如：如果某一個應用程式需要用到多個檔案，那麼我們就可以將這些檔案組合為一個，進而減少對於吞吐量的需求。相反，針對那些頻繁請求多個小檔案的操作，很可能會在較短的時間內迅速達到並超出預先設定的吞吐量限制。

可見，透過減少可能的檔案請求數量，我們可以降低每秒鐘的I/O操作。這不但有助於減少延遲的開銷，而且能夠保持一定的效能區間。

由於沒有可用的快照功能，因此如果您想在EFS中建立備份的話，則可能會遇到困難。通常，您必須使用AWS Backup服務，或是執行EFS-to-EFS來進行備份。不過，無論採用哪種方法，您都需要儲存好各種備份的副本，並嚴密監控備份所需要的儲存空間。

此外，在建立備份時，您最好安排在非工作時間，並以限速複製的方式進行建立。這樣不但可以避免影響到各項標準操作的效能，而且可以防止意外burst credits的發生。

在使用EFS時，您可以選擇兩種效能模式：

· 通用意圖（General Purpose） - 提供較低的吞吐量，以換取較低的延遲操作。它被設計為用於標準化的任務，例如：web主機或內容管理。而且，這是EFS的預設效能設定。

· 最大I/O（Max I/O） — 提供較高的吞吐量，以換取較高的延遲。它被設計為用於處理繁瑣的計算任務，例如：媒體處理或大資料分析（請參見--）。

EFS被設計為允許大規模的併發連線，並且可以同時附加多達上千個EC2例項。據此，您可以透過分擔不同的應用程式與負載，來顯著地提高整體效能。當然，在配置這些連線時，您仍然會受到各個卷的總吞吐量、以及傳輸速度的限制。

Amazon EFS雖然是一個功能強大的工具，但是與許多其他自配置（self-configured）的服務一樣，它仍然需要您定期進行最佳化。為了避免不必要的開銷，您應該定期監視EFS的burst credits和平均I/O吞吐量。同時，為了確保具有最佳的效能，您既可以使用非同步寫入操作，又應當避免從EFS上直接執行應用程式。此外，為了避免產生額外的計費，您不但需要管理好各種備份，而且要為應用負載選擇正確的效能模式。最後，您還可以利用併發連線來提高整體效能。

原文地址：