บันทึกการย้าย Infrastructure จาก Google Cloud Platform ไปยัง AWS

เรามี Product อยู่ตัวนึง ที่หลังบ้านทำงานอยู่บน Google Cloud Platform เดิมอยู่ แต่ด้วยเหตุผลเรื่องของ Business ทำให้เราจำเป็นต้องย้าย Product ตัวนี้จาก Google Cloud Platform มาใช้ AWS แทน

Architecture ที่เราใช้งานอยู่เดิม

ช่วงที่เราเริ่มทำงานบน GCP นั้น เพื่อให้งานนั้นออกมาได้รวดเร็วที่สุดเท่าที่เราจะทำได้ ทำให้เรายึดติดกับเครื่องมือ (Vendor Lock) ของ GCP อยู่ค่อนข้างแนบแน่นอยู่พอสมควร เพราะ GCP Provide ของให้เรา Implement ได้ค่อนข้างง่ายครับ แล้วก็ครบจบในตัวหลายอย่าง สิ่งที่เราใช้งานบน GCP มีดังนี้ครับ

• VM อยู่ 2 ตัว สำหรับรัน Monolithic Application
• GKE (Google Kubernetes Engine) จำนวน 2 Cluster
• CI/CD เราใช้ Google Cloud Build
• Storage เราใช้ Google Storage
• Email Service ใช้ SendGrid (แต่ผูก Billing กับ GCP)
• Logging System เราใช้ Stackdriver Logging
• Container Registry

จะเห็นว่าเราผูกติดกับเครื่องมือของ GCP อยู่พอสมควร เราจะค่อยๆแกะออกมาเรื่อยๆกันครับ

VM ย้ายง่ายสุด เสี่ยวสุดก็ตรง Data

เนื่องจากเรามี Monolithic Application ที่ทำงานอยู่บน VM พร้อมในนั้นมี Database Server อยู่ด้วย การย้าย Application มาฝั่ง AWS ในส่วนของ Application นั้นไม่เท่าไหร่ครับ จะยากก็ตอน Sync Data นี่แหละ แต่เนื่องจาก Transaction บน Production ตอนนั้นยังไม่เยอะมาก ส่วนมากเป็น Transaction บน Development Env ซะมากกว่า เลยรอดตัวไป

ย้ายออกจาก GKE มันไม่ได้ง่ายอย่างที่คิด

บางคนคงคิดว่า "เฮ้ย ก็ใช้ K8S อยู่แล้วหนิ ย้ายบ้านนี่โครตง่ายเลย เอาไฟล์ yml ยัดใส่ Cluster ใหม่ก็ได้แล้วป่ะวะ" ตอนแรกผมก็คิดแบบนั้นครับ แต่ชีวิตมันไม่ได้สวยงามขนาดนั้นหนะสิ :(

อย่างที่บอกครับ เราเสพติดความง่ายของ GCP มาเยอะ ตอนย้ายออกนี่เหมือนเป็นบาปที่ตัวเองต้องชำระเลยทีเดียว เนื่องจากอย่างที่รู้ๆกันครับ K8S มันพัฒนาโดย Google พี่แกก็เลยทำเครื่องมือที่โครตแจ่มมาให้อยู่แล้วใน GKE ไม่ว่าจะเป็นการเชื่อมต่อกับ Stackdriver Logging, Wizard สำหรับติดตั้ง Application ชื่อดังบน Cluster และอื่นๆอีกมากมายครับ

ทางผม ก็ Vendor Lock เพราะบริการพวกนี้อยู่พอสมควรเหมือนกัน

• เราติดตั้ง Kong API Gateway ผ่าน Wizard ของ GKE
• เราใช้ Redis ผ่าน Wizard ของ GKE แล้วใช้ Image ที่ GKE Fine tune มาให้แล้ว
• เราใช้ Logging System เป็น Stackdriver Logging ซึ่งตัว GKE มันส่ง Log ไปเก็บไว้ที่นี่อยู่แล้ว
• CI/CD อย่าง Cloud Build สามารถเชื่อมต่อกับ GKE ได้เลย เพียงแค่ Setup IAM ให้ถูกต้องเท่านั้น ง่ายมาก
• Container Registry ก็เช่นกัน เชื่อมต่อกับ GKE ได้ง่ายๆ ด้วยการ Setup IAM

หลังจากที่ต้องทำการย้ายออก ผมก็เริ่มหา Solution บน AWS ว่าสิ่งที่ GCP มีให้พวกนี้ ทาง AWS มีให้เราเหมือนกับทาง GCP ไหม เราก็พบว่า ทาง AWS ก็พอมีทางออกให้เราอยู่พอสมควรเหมือนกัน

• Logging System จะถูกแทนที่ด้วย AWS CloudWatch แทน ใช้แทนกันได้
• Container Registry ทาง AWS ก็มี Elastic Container Registry (ECR) ให้
• GKE สามารถแทนที่ด้วย Elastic Kubernetes Service (EKS) ได้

ส่วนที่เหลือ ไม่มีเครื่องมืออะไรมาช่วย ก็คงต้องช่วยตัวเองละครับ :( เขียน yml ไป deploy วนไป

เรื่องมันดูเหมือนจะจบใช่ไหมครับ? ยังครับ มันยังไม่จบแค่นี้...

ขั้นตอนแรกสำหรับที่ใช้งาน คือเราต้องสร้าง Cluster EKS บน AWS ขึ้นมา แล้วเราก็พบว่า AWS คิดค่า Control Plane เรา 0.10 USD/ชั่วโมง แต่ทาง GCP ไม่คิด! (ปัจจุบันเหมือนจะคิดแล้วนะ ถ้าจำผิด) แต่นั้นไม่สำคัญ พอลองกดสร้าง Cluster ขึ้นมา บอกตรงๆว่ามันเข้าใจยากมาก!!

ผมอาจจะเสพติดมาจาก GKE ก็ได้ แต่ตัว EKS นี่กว่าจะ Connect เข้า Cluster ได้นี่ ใช้เวลาไปเยอะพอสมควร แล้วก็เครื่องมือไม่ได้เยอะเท่า GKE ด้วย คือสิ่งที่มีใน GKE นี่หายไปเยอะเลยเมื่อใช้ EKS โดยรวมแล้ว ผมไม่ประทับใจเป็นอย่างมาก สำหรับ EKS แล้วมันก็จบด้วยการ "ติดตั้งเองแบบ on-premise บน EC2" ด้วย kops

ชีวิตก็เหมือนจะจบ ยังครับ ปัญหามันยังไม่หมดแค่นี้ ด้วยความที่เราติดตั้งเองด้วย Kops มันทำให้เราต้องติดตั้ง Monitoring Service เองทั้งหมด แต่ก็รู้สึกโอเคกว่าตอนใช้ EKS เพราะรู้สึกว่าอย่างน้อย เราก็สามารถควบคุมมันได้

ปัญหาต่อมาคือเรื่อง Persistent Storage กับเรื่อง Ingress บน K8S เพราะถ้าเราใช้ Management Service ของ Cloud ไอเรื่องพวกนี้ มันจะกลายเป็น Automate ไปเลย แค่เขียน yml ยัดเข้าไปเท่านั้น แต่ตอนนี้มันไม่ใช่ เพราะเราใช้ on-premise!

ก็ต้องไล่หาทางออกกันไป ด้วยการใช้ NFS บน Control Plane Node กับติดตั้ง Ingress ให้ Expose IP ผ่าน EC2 Worker Node ทั้งหมด แล้วเราก็ไป Set loadbalance ที่ DNS เป็น Round-robin DNS แทน

หลังจากนั้นทุกอย่างก็เข้าที่เข้าทางขึ้น จากนั้นก็มาไล่เก็บรายละเอียด Service บางอย่างที่ทำผ่าน Wizard ของ GKE มา พวก API Gateway และ Redis Cache หลังจากอะไรเรียบร้อยก็เปลี่ยน DNS จาก GCP มา AWS เป็นอันเสร็จ

ย้าย Git จาก Github มาใช้ Gitlab

ช่วงที่เราใช้งาน Github นั้น เรายังเสียเงินใน Plan เสียเงิน เพื่อใช้ Private Repository อยู่ ตอนที่เราย้ายจาก GCP เรามีการใช้ CI/CD ด้วย เลยพยายามหา CI/CD Tools ที่สามารถ Integrate กับ Git ได้แบบแนบแน่น ไม่ต้องเสียเวลา Setup เยอะ และต้องยืดหยุ่นในการ Setup Environment Builder ด้วย เลยไปตกลงปลงใจกับ Gitlab เพราะตอบโจทย์ทุกข้อ

สิ่งที่ต้องย้าย คือต้อง Migrate CI script ใหม่ จาก Google Cloud Build เป็น Gitlab CI อันนี้ไม่มีปัญหาเท่าไหร่ เพราะ Gitlab CI เราเลือกใช้ Docker Driver เป็นหลัก ซึ่งมันค่อนข้างยืดหยุ่นอยู่แล้ว เลยไม่มีปัญหาอะไร

ย้าย Storage จาก Google Cloud Storage เป็น AWS S3

เรื่องนี้ไม่หนักมาก เนื่องจาก Data บน Production ช่วงที่เราย้ายยังไม่เยอะ เลยไม่มีปัญหาอะไรมาก ก็ค่อยๆย้ายกันไป ผมเขียน Script Migrate ระหว่าง 2 Cloud Provider แล้วค่อยๆย้ายไปเรื่อยๆ ทุกอย่างผ่านไปด้วยดีสำหรับเรื่อง Data

เนื่องจากเรามี Application Service ที่ Implement การเชื่อมต่อ Storage ไปที่ Google Cloud Storage เอาไว้ ทำให้เราต้อง Implement ระบบเพิ่ม เพื่อให้สามารถใช้งาน AWS S3 ได้ โดยโจทย์ของเราคือ ต้อง Backward Compatibility กับ Data เดิม คือ User และ Service อื่นๆต้องเรียกด้วยวิธีการเดิม โดยไม่รู้สึกถึงความเปลี่ยนแปลงหลังบ้าน ซึ่งอันนี้เราก็ผ่านมาได้โดยไม่มีปัญหาครับ

หลังจากนั้นเราก็ใช้ CDN Set Cache จาก Google Cloud Storage ไปเป็น AWS S3 แทน สำหรับ Public Bucket Storage (เรายังเลือกใช้ Cloudflare แทนจะใช้ CloudFront อยู่ดี)

หลังจากเราแน่ใจในระบบแล้ว เราจึงย้าย DNS ของ Development Environment มาที่ AWS แล้วทดสอบระบบทุกส่วน ว่าระบบทุกส่วนทำงานได้ตามปกติแล้ว ซึ่งต้องบอกเลยว่า เราไม่ได้ทำทีเดียวทั้งหมด เราค่อยๆย้ายมาเรื่อยๆ ค่อยๆถอดออกทีละส่วน จนพาออกมาได้ทั้งหมด หลังจากเราแน่ใจทั้งหมดแล้ว เราจึงตัดสินใจเปลี่ยน DNS ของ Production Environment จาก GCP ไป AWS

ระบบเรา Golive บน AWS มาเดือนกว่าๆละ ลูกๆของเราไม่มีอาการงอแงเลยจากที่ผ่านมา ทำงานได้นิ่งมาตลอด ขอให้นิ่งแบบนี้ไปเรื่อยๆเลย

ปิดท้ายด้วยการขายของ 555555

Divergent Thinking Co,Ltd กำลังมองหา Front-End Developer (React Native) ที่สนใจมาทำอะไรตื่นเต้นๆด้วยกัน ใครที่คิดว่าตัวเองเก๋า มีความรับผิดชอบเป็นหนึ่ง ลองส่ง CV มาคุยกันได้ที่ [email protected] นะครับ :)