我們擁有一定程度的控制和標準化,而這在現場部署資料中心是無法做到的。
Chad Marino 技術服務執行總監

Kaplan, Inc. 每年為超過 120 萬名的學生提供服務,包括為個人、機構及企業提供高等教育、應試準備、專業教育、英語訓練、大學預科及 K-12 基礎教育等。在它超過 75 年的歷史中,起初是應試準備的先驅,後來成為早期 線上教育 的領導者,現在則是全球教育供應商,以其擴大教育管道以及運用技術與 學習科學 創新以持續提高其學生和合作夥伴的成果而聞名。Kaplan 在超過 30 個國家營運,擁有 22,000 多位專業人員,而且與超過 1,000 個校區、大專院校以及 2,600 多家公司和企業維持合作夥伴關係。Kaplan 是 Graham Holdings Company 的子公司及其最大的部門。

Kaplan 現在由多個部門組成,每個部門有不同的 IT 基礎架構需要和不斷變動的用量模式,其中包括 Kaplan 應試準備部門 (KTP),協助學生準備 SAT、ACT、GRE、GMAT、LSAT、MCAT 等入學考試及專業證照考試。為了支援 KTP,Kaplan 在紐約市的 第一層 共置資料 中心 執行開發和測試環境。當熱帶颶風桑迪 (2012 年大西洋颶風季最致命且最具毀滅性的颶風) 襲捲整個城市之後,託管中心幾乎整整停擺兩星期。

Kaplan 技術服務執行總監 Chad Marino 說:「幸運的是,我們的生產環境仍維持運作,但是擔憂總像陰影一般揮之不去。」Kaplan 的手動備份和復原資源也位於紐約市。「將備份環境與生產環境放在同一個城市,也是我們需要解決的一個重點。」Marino 解釋說。

不僅如此,隨著業務不斷擴張且 IT 架構的複雜程度增加,Kaplan 在遵守支付卡產業資料安全標準 (PCI DDS) 與服務組織控制 (SOC) 規範方面也日趨艱難。Kaplan 需要尋找一個彈性的 IT 基礎架構,不但要具備擴展的能力,還要能提升整體的彈性、安全性及靈活度。

Kaplan 在整個組織內執行 12 個不同的資料中心,而且也開始將應用程式移到 Amazon Web Services (AWS) 以合併基礎設施。Marino 表示:「促使我們移到雲端的其中一個因素是,我們的硬體使用期限即將屆滿,而且資料中心的儲存空間不足。」

AWS 產品的成熟度也吸引了 Kaplan 的注意。「Amazon Relational Database Service (Amazon RDS) 讓 DBA 團隊能夠減少日常維護的時間,轉而將時間運用在增強功能上。而且 Elastic Load Balancing 讓我們不用再使用昂貴、複雜的負載平衡器,同時保留必要的功能。」Marino 表示。

熱帶颶風桑迪促使該公司將 KTP 及其他共享服務、部分 Kaplan 高等教育和 Kaplan 國際部門,共 900 GB 的資料遷移到 AWS。專案經理 Ravi Munjuluri 說:「我們從 2013 年 5 月開始將開發、品質保證及模擬環境移到 AWS。我們在 10 月完成這部分的轉移,然後開始規劃生產遷移。2014 年 1 月,我們開始逐一遷移生產環境中應用程式堆疊的各個部分,將對業務的影響降到最低。最後一波是在 8 月,花了一個週末的時間就完成了。從週五開始,然後週日一早就啟動並執行。」

移到雲端的過程中,Kaplan 遷移了堆疊中約 50 個應用程式及 50 個巢狀子應用程式。在共置資料中心內,部門使用儲存區域網路 (SAN) 將 x86 伺服器、Sun Sparc 處理器及 Solaris 作業系統連接到六個 Oracle Database 10g 和 Windows SQL 資料庫。

Kaplan 將應用程式堆疊遷移到 Amazon Virtual Private Cloud (Amazon VPC),在混用 Amazon Linux Machine Images 和 Amazon Relational Database Service (Amazon RDS) for Oracle 的 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體上託管資料庫。Marino 說:「我們的目標是將所有資料庫完全移到 RDS,以簡化管理並獲得重新調整數量功能。」

Kaplan 使用 Amazon CloudWatch 來監控資源,這項服務會收集和追蹤用量指標以及管理警示。使用 CloudWatch 也能讓公司優化資源,例如,在使用率下降時重新調整執行個體的數量。

Kaplan 團隊使用 Oracle 內建工具設計資料遷移的程序。「我們使用 AWS PERL 指令碼來遷移資料,成效優異。」系統架構和工程總監 Avi Hack 說。透過結合指令碼與 AWS Elastic Beanstalk,該公司可自動化耗時的程序並預先設置遷移環境,讓整個過程更快速、更輕鬆。

在整個遷移過程中,Kaplan 決定利用多個 AWS 區域和可用區域,包含美國、亞太區域和歐洲的部分區域。該公司使用 Amazon Route 53 做為 DNS 解決方案,將使用者流量路由到最近的可用區域, 因此 提高了整個使用者體驗,同時降低延遲。Marino 表示:「使用多個區域允許我們將資料放置在離客戶較近的地方,以獲得更好的最終使用者體驗。」

Kaplan 的萬全準備讓轉移到 AWS 更加順暢。在整個遷移過程中,Kaplan 也倚賴商業級 AWS Support 獲得確認和最佳實務。「解決可能遇到的問題時,我們一定會善用 AWS Support,」Marino 表示。

有來自開發、營運、架構及資料庫團隊超過 250 多位人員參與遷移到 AWS 的工作。Marino 說:「為了規劃這種規模的遷移工作,必須與 IT 的所有團隊共同合作才能順利完成,從開發團隊到基礎設施營運團隊都要參與其中。」

將 KTP 部門移到 AWS 之後,Kaplan 出售舊的設備並關閉資料中心。該公司在遷移到 AWS 的過程中持續為各個部門重新架構應用程式,而現在 Kaplan 將資料中心的數量從 12 個縮減為 4 個設施。

除了更可靠的基礎設施及較少的延遲以外,Kaplan 也能夠更深入地分析應用程式和系統的成本。「透過標記 AWS 中的所有執行個體,我們現在能夠查看特定成本,從應用程式層到與應用程式關聯的每項資源。這可讓我們了解操作應用程式的隱藏成本,」Marino 說。

Kaplan 預計使用 AWS 進一步改善開發程序。Hack 表示:「利用 AWS CloudFormationAWS 命令列界面 (CLI),我們擁有一定程度的控制和標準化,而這在現場部署資料中心是無法做到的。現在我們可以很輕鬆地啟動環境,並在結束時移除它們。」Marino 解釋:「這可讓我們充分利用 AWS 的優勢,同時保留現場部署資料中心的優點,讓開發人員有時間改進在 AWS 上執行的應用程式。」Kaplan 團隊表示他們將繼續尋找將系統和應用程式移出傳統資料中心並遷到雲端的適當機會。

要進一步了解 AWS 如何協助您執行商業應用程式,請瀏覽我們的企業雲端運算詳細資訊頁面。