Ruby語言的雲端運算平台:Heroku

你的網站是否曾經遇過下列狀況?面對突如其來的流量,主機一時承受不了便導致服務中斷、當機,錯失許多寶貴的商機。
評論
評論

你的網站是否曾經遇過下列狀況?

  1. 面對突如其來的流量,主機一時承受不了便導致服務中斷、當機,錯失許多寶貴的商機。
  2. 為了應付各種可能的狀況,公司幫你的部門準備了很好的機器,但平常使用率極低
  3. 已經預料到下個月要進行的行銷活動將會帶來大量訪客,但卻無計可施,到底是要從程式優化做起還是調整架構、採購設備做起?
    涉及採購的話又要看有沒有預算,即使有預算,為了一次活動添購機器,結束後機器使用率是非常低的,不如把這些錢當成 IT 人員的績效獎金。

如果你曾經遇過上述情況,或許你需要的就是這個年代最熱門的名詞:雲端運算。雲端運算沒有唯一解,也未必是最佳解(尤其在某些廠商打著雲端運算的旗號但實際上根本沒做到雲端)。今天筆者要分享的是眾多雲端運算架構的其中一個選擇:Heroku(根據官方網站的解釋,Heroku 發音是 Her-O-Koo)。

筆者曾在過去的幾篇文章提過 Heroku 這個有趣的平台:

育成創投先鋒:Y Combinator

Heroku:提供給 Ruby/Rack 相容的雲端技術平台,可輕易做到延展性架構,目前是許多 Ruby on Rails 開發人員喜愛的平台

網路創業實例:意外起飛、24 小時累積 10,000 名用戶的 Rapportive

Rapportive 的服務是放在知名廠商 Heroku 上,對於突然湧進的流量只需要增加 Dynos 的數量(Heroku 提供服務的基本單位),基本上你是不需要修改你的程式的;當然,程式的優化、調整可以在同樣能耐的硬體等級上容納更多人。

使用 Heroku、不需要調整程式、只需要增加 Dyno 數量?真的有這麼美好嗎?事實上 Rapportive 就是這麼辦到的,在來自全世界的流量突然湧進時,Rahul Vohra 手邊沒有電腦,於是他隨即拿起 iPhone 並且利用 Nezumi 這個設計來管理 Heroku 的應用程式,將 Rapportive 的 Dynos 增加到 20 個,就這麼簡單,可能不到一分鐘吧?!系統的能耐馬上就提昇了。

Cardinal Blue 的 Facebook 應用程式開發經驗分享:使用 Ruby on Rails 與 Heroku

使用 Ruby on Rails 並搭配知名的 Ruby 雲端運算平台:Heroku,特色是應用程式隨著流量的成長,無需擔憂系統管理(System Administration)或是硬體水平擴展的問題,Heroku 提供了優越的 Scalability 能耐,透過簡單的應用程式指令或是 Web 介面便可依照需求調整所需的硬體資源。(類似 Amazon EC2 Instance 的計費方式,每小時有一定額度的費用)

以上三段介紹點出了 Heroku 的兩個重點:

  • Heroku 是提供給 Ruby 語言的平台,簡單來說如果你使用 Ruby 撰寫了 Rack-based 的應用程式,就可以部署到 Heroku 上(包括知名的 Ruby on Rails,或是 SinatraMerbRamazeCamping
  • Heroku 提供了易於設定的雲端架構,即使應用程式的流量、效能需求突然成長,也可直接透過簡單的介面來強化服務的能耐

Heroku 目前不僅是全球知名的雲端服務提供商,也經常是被人們拿出來談論的 YCombinator 成功案例(Heroku 是 YCombinator 的創投、育成團隊)。

Heroku 服務起源

Heroku 最早在 2007 年產品上線並且開始提供服務,當時提供的服務定位與現在非常不同,筆者曾在 2007 年底撰寫過一篇 Heroku:線上撰寫 Rails 程式初體驗 ,你可以發現當時 Heroku 的產品訴求為提供一個可以讓程式設計師直接在網頁介面中撰寫 Rails 程式的平台(雲端 Coding),然而當時使用的印象並不十分良好,綁手綁腳的開發環境,實際上一個複雜的 Web application 大概很難在那樣的環境達成;如果不用 Heroku 提供的開發環境,只是單純使用 Hosting 的話,實際上也不是挺好用。也因此,在這個階段,Heroku 對於許多使用 Ruby/Rails 的應用程式開發者來說,就是一個免費的主機環境。

從上圖(這是 2008 年到 2009 年,在 Heroku 上的應用程式數量)我們可以發現 Heroku 的應用程式數量有著穩定的成長,在 2009 年的一月份,Heroku 部落格上發表了一篇重要的公告 ,上面提到 Heroku 平台上已經有超過 20,000 個應用程式,從企業用軟體到 Web 2.0 網站、iPhone 應用程式的後台等各種用途的應用程式都有,各式各樣的應用程式都在 Heroku 平台上持續穩定的提供服務,這同時也是給 Heroku 經營團隊最好的測試環境。

在這段期間,Heroku 團隊發現人們要的其實是一個穩定的商用平台(免費、付費似乎沒那麼重要),同時間 Heroku 也發現他們還要持續開發更多大家想要的功能,當然也必須移除一些根本用不到的功能。Ruby on Rails 的線上開發環境顯然就是被移除的功能,當時 Heroku 將原有的線上開發環境移到 HerokuGarden(目前已經不存在),也就是說,當初 Heroku 認為最重要的功能之一在歷經了一年多的努力後,市場證明了這其實是不需要的。

筆者在 關於創業,你必須知道的 13 件事 曾經提到:

「產品上線後才是另一個開始」、「產品上線後才是真正的開始」,事實上,在我們尚未真正推出產品前,我們做的事情很簡單:關在會議室中假設人們應該會喜歡什麼功能、不喜歡什麼功能。如果能盡早推出產品、持續調整路線,可以讓我們少走些冤枉路,即使是推出產品來證明自己想法錯誤,也是一種收穫、一種讓想法進化的方式。

顯然,Heroku 在產品上線後,發現提供一個免費的 Ruby on Rails 線上開發環境並不重要,大家感興趣的是雲端的平台、方便的部署以及可以讓大家付錢買到更多資源的服務,對 Heroku 團隊來說,這肯定是在正式上線前都沒有機會的。記住:產品上線後才是真正的開始。

Heroku 平台現況

Heroku 本身是架構在 Amazon 所提供的雲端架構上,對於不想將心思或人力投入在系統管理、架構上,但又希望可以使用 Amazon EC2 雲端服務的團隊來說,Heroku 是個很好的選擇,你可以將心思專注投入在應用程式開發上,而不用擔心如何去處理 Amazon 雲端架構的設定與管理。

目前 Heroku 上共有超過 85,000 個應用程式,許多 知名的服務都在上面運作 ,包括:

只要你是開發 Ruby on Rails 或是其他 Rack-based 的應用程式,你就可以將服務部署到 Heroku 上,簡單易用的後台可以讓你輕鬆的調整服務目前分配到的資源,畫面如下:

只要滑鼠輕鬆點個幾下、拖曳畫面右方的 Dynos 設定(這是 Heroku 提供運算資源的基本單位),就可以完成資源的調整;畫面上也會即時算出目前所分配到的資源預估的每月花費。然而,以 Dynos、Workers 來說,都是以「每小時計價」的,也就是說當服務的流量已經撐過高峰並開始下滑,可以視預算或實際資源的需求,隨時調整 Dynos、Workers 的設定來控制每月的成本。

持續進步的 Heroku

Heroku 在早期提供的服務還不多,例如想要發送郵件、進行排程作業、連接自有的資料庫(Heroku 預設是本身提供的 PostgreSQL),不過顯然隨著募資、營收增加,Heroku 已經有越來越棒的服務,舉例來說,在 Heroku Add-ons 可以看到以下服務:

  • websolr:這是基於 Apache Solr 打造的企業級搜尋引擎,如今在 Heroku 上你可以輕易地整合 websolr 的服務在你的 Rails 應用程式,提供全文檢索的功能給使用者
  • New Relic:New Relic 是一家專門提供應用程式監控的廠商,可以即時掌控應用程式的效能、執行狀況、錯誤、資料庫分析等等,目前 Heroku 上也直接提供 New Relic 的整合服務
  • Amazon RDS:使用 Amazon RDS 作為應用程式資料庫
  • Cron:在 Heroku 上進行排程作業
  • Deploy Hooks:每次部署新版應用程式後都可以透過 Email hook, basecamp hook, IRC hook, Campfire hook, HTTP Post hook 來發送訊息給團隊成員,告知有新版程式部署完成
  • Hoptoad:Hoptoad 是專門提供給 Rails 程式的應用程式例外監控工具,可以在程式發生例外的時候第一時間通知維護團隊,並且有專屬的網頁介面來追蹤例外發生時的所有環境變數、相似的錯誤以及目前處理的狀況。目前在 Heroku 上也可以輕易地整合這個服務。
  • Mamcache:如果有些特定的資料需要放在記憶體裡面來達到最佳的存取效能,memcache 是你最好的選擇之一,目前 Heroku 上也開始提供 Heroku 的容量租用。
  • Moonshado SMS:國外的簡訊服務提供商,Heroku 可直接整合
  • Sendgrid:國外的電子郵件提供商,如今在 Heroku 上可輕易地整合
  • Custom Domains:自定域名(通常預設是 you-app-name.heroku.com)以及子網域 wildcard(例如 *.your-domain-name.com)

持續進步的 Heroku,在最近還推出了各種 NoSQL 的服務,包括:

  • CouchDB
  • MongoDB
  • Redis

另外也有像 Nezumi 這樣的應用程式,可以協助你在僅有手持裝置(iPhone)

的時候,快速改變服務資源配置的 iPhone 應用程式:

誰適合採用 Heroku?

  • 已經使用或是正在評估採用 Ruby on Rails 作為主要開發框架的團隊
  • 想要採用雲端技術,卻沒有相關經驗或資源,也沒有專職系統管理人員的團隊
  • 單純想要一個免費的主機空間的團隊(不過免費的用起來個人認為經驗不是挺好)

你可以試算看看,自己要提供的服務規模、長期的主機成本與維護成本,以及在流量成長過程中將心力投入在調整機器架構、效能的成本,有些人或許會覺得 Heroku 乍看之下很貴,但筆者認為如果在人力有限的情況下,應該讓人力投入在真正重要的事情上,Heroku 或許是個不錯的選擇。


Akamai 服務上新,於邊緣處推動快速創新

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用 Akamai 提供的 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。
評論
評論

在雲計算技術還沒有大規模普及前,絕大部分企業和組織都需要自建數據中心,或通過託管的方式來部署自己的硬體基礎架構,並在此基礎上為員工和客戶提供服務。取決於業務或其他方面的諸多要求,此時需要部署的數據中心可能有很多個,並廣泛分佈在不同地區,藉此為客戶提供流暢的體驗,並透過多個數據中心保障連續性。在發展的過程中,隨著「雲端」的出現,讓各個組織的計算開始集中。

而當在線直播、無人駕駛、智能家電、物聯網等應用開始陸續深入我們的工作和生活,情況又不同了。以往透過雲平台集中運行和服務的模式,因為距離導致的網絡延遲已經對用戶的使用體驗產生極大影響。為了提供更敏捷、靈活、快速、可靠的體驗,企業需要從最貼近用戶的地方提供服務。因此,邊緣計算就成為最有效的解決方法。

透過將數據的收集、分析和處理等工作,由「雲中心」重新分散到最接近用戶的邊緣位置,企業可以就近為用戶提供服務,通過延遲更低的響應打造更出色的用戶體驗。

「無服務器」的出現,帶來計算方式的革新

以前,當組織需要上線一套業務系統時,首先需要採購並部署相應的服務器硬體,並且要負擔服務器日常運維過程中的管理、維護、補丁安裝、配置等繁瑣任務。

上雲前,組織需要在自己的數據中心,以硬體服務器的方式執行這一系列工作;上雲後雖然簡單許多,但依然需要面對雲服務商提供的虛擬服務器,從本質上來看相關負擔仍相當繁重。

無服務器(Serverless)技術的出現,讓組織可以在不需要考慮服務器的情況下,構建並運行由微服務構成的創新式應用程式與和服務。藉此不僅可以省略基礎架構管理任務,還能為幾乎任何類型的應用程式或後端服務構建無服務器應用程序,更方便、靈活地構建出具備極高可用性的應用。

Akamai EdgeWorkers :為創新賦能

Akamai EdgeWorkers 為開發團隊提供豐富功能和工具來創建新的微服務,利用Akamai 超過 25 萬台分佈式服務器組成的網絡,在邊緣執行安全而快速的計算,並在邊緣暫存內容,以實現快速交付。

當開發團隊在邊緣開啟代碼時,他們會將數據、見解和邏輯推送到更靠近最終用戶的位置。Akamai 的高性能、可擴展式實施模型,可確保數據和計算不會被延遲問題困擾,進而避免對數字化體驗產生負面影響。

在該服務幫助下,開發者可直接在 Akamai 的全球分佈式平台上快速、迭代地創建和部署新服務,以解決問題和自定義交付。

長期以來,Akamai 在邊緣計算的創新和成功實施皆具有優勢。自 1998 年起,便開始為 Akamai 內容交付網絡(CDN)的客戶推出自定義交付邏輯,其他里程碑還包括 2001 年的 Edge Site Includes 、2002 年的 Edge Java 以及 2014 年的 cloudlet 應用程式。

目前, Akamai 在全球擁有超過 4100 個入網點,為 EdgeWorkers 用戶提供出色的邊緣基礎架構規模和範圍,開發人員可以在靠近最終用戶和他們的數字化接觸點的地方部署代碼,以實現盡可能低的延遲。EdgeWorkers 同樣獨立於雲,客戶可以選擇利用 CDN 供應商或雲供應商平台上的無服務器計算功能。在 Akamai 幫助下,客戶可以在整個混合雲或多雲環境中部署單一的無服務器計算平台。

更多相關資訊:https://www.akamai.com/solutions/edge

本文章內容由「猿聲串動」提供,經關鍵評論網媒體集團廣編企劃編審。