จาก SSH สู่ REST: การปรับปรุงไปป์ไลน์ข้อมูล EMR ของ Slack ให้ทันสมัยโดยขับเคลื่อนด้วยความปลอดภัย

• แพลตฟอร์มข้อมูลของ Slack มี Operator ที่อิง SSH มากกว่า 700 ตัว สำหรับรันไปป์ไลน์ข้อมูลสำคัญ เช่น การทำดัชนีค้นหารายวันและงานวิเคราะห์ โดยทุกงานต้อง เชื่อมต่อ SSH โดยตรง ไปยังคลัสเตอร์ AWS EMR ฝั่งโปรดักชัน ทำให้เกิดพื้นผิวการโจมตีด้านความปลอดภัยในวงกว้าง
• การพึ่งพา SSH นี้ไม่เพียงสร้างความเสี่ยงด้านความปลอดภัย แต่ยังเป็นอุปสรรคสำคัญต่อการทำโครงสร้างพื้นฐานให้ทันสมัย เช่น การย้ายไปยัง Spark on Kubernetes, EMR on EKS และการปิดโครงการ Whitecastle ให้เสร็จสมบูรณ์
• ทางออกคือการใช้ YARN Distributed Shell เพื่อให้สามารถรันคำสั่งเชลล์ใดๆ ก็ได้ภายในคอนเทนเนอร์ YARN และรวมการส่งงานทั้งหมดผ่าน Quarry ซึ่งเป็น REST gateway ภายในของ Slack
• มีการ ย้ายงานมากกว่า 700 งานใน 8 data region โดยไม่มี downtime (zero downtime) และกำจัด SSH ได้ครบ 100% ภายใน 3 ไตรมาส
• ผลลัพธ์คือ ลดพื้นผิวการโจมตี เพิ่มความเชื่อถือได้ของงาน และปรับปรุงการมองเห็นระบบ พร้อมวางรากฐานสำหรับ การทำ Whitecastle ให้เสร็จสมบูรณ์และโครงสร้างพื้นฐานรุ่นถัดไป เช่น Spark on Kubernetes

---

ภูมิหลัง: การก่อตัวของแพลตฟอร์มข้อมูลที่อิง SSH

• แพลตฟอร์มข้อมูลของ Slack ซึ่งสร้างขึ้นราวปี 2017 เลือกใช้ แนวทาง SSH เพราะเป็นเส้นทางที่ตรงที่สุดสำหรับให้ Airflow รันงานบนคลัสเตอร์ EMR
  • ใช้ SSHOperator เชื่อมต่อไปยังโหนดมาสเตอร์ของ EMR แล้วรันคำสั่งอย่าง spark-submit
• หลังจากนั้นแต่ละทีมก็สร้าง Operator แบบกำหนดเองที่อิง SSH เพื่อรองรับการใช้งานหลายรูปแบบ ไม่ใช่แค่ Spark แต่รวมถึง MapReduce, AWS CLI และสคริปต์ Python แบบกำหนดเอง
• ผลลัพธ์คือมี งานที่อิง SSH มากกว่า 700 งานสะสมอยู่ในสภาพแวดล้อมโปรดักชัน

ต้นทุนที่แท้จริงของแนวทาง SSH

• ความเสี่ยงด้านความปลอดภัยที่อาจเกิดขึ้น

  • การเชื่อมต่อ SSH โดยตรงไปยังคลัสเตอร์คอมพิวต์ทำให้ พื้นผิวการโจมตีขยายใหญ่ขึ้น
  • การ กระจายและหมุนเวียนคีย์ ข้าม orchestration worker ทั้งหมดเพิ่มภาระในการปฏิบัติการ
  • เพื่อการตรวจสอบแบบละเอียด จำเป็นต้อง เชื่อมโยงวิเคราะห์ log จากหลายระบบ
  • การจัดการสิทธิ์ซับซ้อนขึ้นจาก security group เฉพาะทางและการตั้งค่าแบบกำหนดเอง

• ปัญหาด้านการปฏิบัติการ

  • งานไม่ได้ถูกกระจายออกไป แต่รันตรงบนโหนดมาสเตอร์ของ EMR ทำให้เกิด การแย่งใช้ทรัพยากร
  • เมื่อ Kubernetes Pod รีสตาร์ต การเชื่อมต่อ SSH ถูกตัดและงานล้มเหลว
  • งานที่ใช้เวลานานอาจยังรันต่อหลังการเชื่อมต่อสิ้นสุด กลายเป็น zombie process
  • เมื่อการเชื่อมต่อหลุด ไม่สามารถยืนยันได้ว่างานสำเร็จหรือล้มเหลว

• ปัจจัยที่ขัดขวางการทำให้ทันสมัย

  • ไม่สามารถเข้าสู่ Spark on Kubernetes และ EMR on EKS ได้ (ต้องกำจัดการพึ่งพา SSH ก่อน)
  • ไม่สามารถย้ายคลัสเตอร์ EMR ตัวสุดท้ายในบัญชีหลักไปยังบัญชีย่อยได้ ทำให้ โครงการ Whitecastle ยังไม่เสร็จ
    • Whitecastle คือโครงการของ Slack ที่ย้ายโครงสร้างพื้นฐาน AWS ไปยังบัญชีย่อยเพื่อเสริมความปลอดภัยและการแยกเครือข่าย
  • ไม่สามารถสร้าง การมอนิเตอร์งานและการมองเห็นระบบที่เหมาะสม ได้

• กรณีตัวอย่าง — ทีม Search Infrastructure

  • ไปป์ไลน์ที่สร้างดัชนีค้นหา Solr รายวันจากข้อมูลระดับเทราไบต์ ซึ่งเป็นแกนหลักของฟังก์ชันค้นหาของ Slack
  • ไปป์ไลน์นี้พึ่งพาการส่งงานผ่าน SSH จึงเผชิญปัญหาความเชื่อถือได้ทั้งหมดข้างต้น

แนวคิดพื้นฐานของการส่งงานผ่าน REST

• ข้อจำกัดโดยเนื้อแท้ของ SSH

  • การเชื่อมต่อ SSH เป็น การเชื่อมต่อโดยตรงแบบมีสถานะ หากการเชื่อมต่อถูกตัดจากเหตุอย่าง Pod รีสตาร์ต คำสั่งอาจยังรันต่อ ล้มเหลว หรือทิ้ง process ที่ไม่มีเจ้าของไว้
  • และไม่มีวิธีที่เชื่อถือได้ในการเชื่อมต่อกลับเข้าไปเพื่อตรวจสอบสถานะ

• ทางเลือกแบบ REST

  • เอนจินคอมพิวต์สมัยใหม่อย่าง YARN, Trino และ Snowflake รองรับ การส่งงานผ่าน HTTP API
    • POST คำของาน → คืนค่า job ID
    • GET สถานะงาน → ตรวจสอบว่าอยู่ระหว่างรัน เสร็จแล้ว หรือ ล้มเหลว
    • DELETE งาน → ยกเลิกได้อย่างถูกต้อง
  • วงจรชีวิตของงานถูก จัดการฝั่งเซิร์ฟเวอร์ แม้ไคลเอนต์จะรีสตาร์ต งานก็ยังรันต่อและยังตรวจสอบสถานะได้

• บทบาทและข้อจำกัดของ YARN

  • สำหรับเวิร์กโหลด Hadoop เช่น MapReduce, Spark และ Hive นั้น YARN ทำหน้าที่เป็น resource manager และมี REST API ให้ใช้งาน
  • แต่สำหรับ งานที่อิง CLI มากกว่า 300 งาน ซึ่งรันคำสั่งเชลล์ทั่วไปอย่าง aws s3 sync หรือ hadoop distcp นั้น ไม่มี REST API ที่พร้อมใช้ในทันที
  • กุญแจสำคัญในการแก้ปัญหานี้คือ YARN Distributed Shell

จุดเปลี่ยน: YARN Distributed Shell

• Spark มี Livy REST API และ Hive มี HiveServer2 อยู่แล้ว จึงย้ายได้ค่อนข้างง่าย
• แต่สำหรับงาน MapReduce และงานอิง CLI มากกว่า 300 งาน กลับเป็น โจทย์ยากเพราะไม่มี REST API ที่พร้อมใช้

• ข้อกำหนด

  • ต้องการ โซลูชันแบบ REST ที่เรียบง่าย และเข้ากับสถาปัตยกรรมได้อย่างเป็นธรรมชาติ
  • ต้อง ใช้กลไก authentication/authorization เดิมที่มีอยู่ โดยไม่ต้องสร้างชั้นความปลอดภัยแบบกำหนดเอง
  • ต้องใช้ โปรโตคอลโอเพนซอร์ส (YARN API มาตรฐาน) ไม่ใช่โซลูชันปิด
  • ต้องมี ความซับซ้อนต่ำที่สุด เพื่อหลีกเลี่ยงการสร้างและดูแลโครงสร้างพื้นฐานสำหรับรันงานแบบกำหนดเอง

• ทางเลือกที่พิจารณาแล้วทิ้ง

  • สร้าง wrapper service แบบกำหนดเอง สำหรับรันคำสั่งระยะไกล
  • ใช้เฟรมเวิร์กสำหรับรันคำสั่งระยะไกลอย่าง Ansible, Salt
  • เพิ่ม job type ใหม่ใน YARN ตั้งแต่ต้น
  • ทุกแนวทางไม่เหมาะสมเพราะซับซ้อนเกินไป ต้องทำความปลอดภัยแบบกำหนดเอง และเพิ่ม dependency ใหม่

• การค้นพบ YARN Distributed Shell

  • สามารถใช้ org.apache.hadoop.yarn.applications.distributedshell.ApplicationMaster เพื่อ รันสคริปต์เชลล์ใดๆ ก็ได้ภายในคอนเทนเนอร์ YARN
  • เป็นฟีเจอร์ที่มีอยู่แล้วใน YARN และใช้ REST API ชุดเดียวกัน จึง ไม่ต้องมีชั้นความปลอดภัยแบบกำหนดเอง

• วิธีการทำงาน

  • 1. อัปโหลดสคริปต์คำสั่งไปยัง S3 เช่น aws s3 sync /tmp/data/ s3://bucket/output/
  • 2. ส่งไปยัง YARN ด้วยการตั้งค่า Distributed Shell
    • กำหนด application-type เป็น MAPREDUCE และใส่ตัวแปรแวดล้อมอย่าง DISTRIBUTEDSHELLSCRIPTLOCATION, DISTRIBUTEDSHELLSCRIPTLEN, DISTRIBUTEDSHELLSCRIPTTIMESTAMP ใน am-container-spec
  • 3. YARN จัดสรรคอนเทนเนอร์ ดาวน์โหลดสคริปต์ และรันให้
    • YARN จัดการ ข้อจำกัดด้านทรัพยากร เช่น memory/vCore, การแยกคอนเทนเนอร์, retry และ fault tolerance, การยกเลิกอย่างถูกต้อง และการจัดการ log ผ่าน YARN UI
• การตัดสินใจนี้ทำให้สามารถรันได้ทุกอย่างในคอนเทนเนอร์ YARN ไม่เฉพาะเวิร์กโหลด Hadoop แต่รวมถึง aws s3 sync, hadoop distcp และสคริปต์ Python แบบกำหนดเองด้วย

โซลูชัน: Quarry

• Quarry คือ gateway สำหรับการส่งงานแบบ REST ของ Slack ที่สร้างขึ้นเพื่อส่งงานไปยังเอนจินคอมพิวต์หลายแบบ เช่น EMR/YARN, Trino และ Snowflake
• ระบบนี้ได้แก้ปัญหาเรื่อง authentication, reliability และ visibility ไว้แล้ว และ ตรงกับเป้าหมายการเลิกใช้ SSH อย่างพอดี

• ความสามารถของ Quarry

  • Authentication: ใช้โทเค็นระหว่างบริการแทน SSH key
  • การส่งงาน: ส่งงานไปยัง YARN, Trino และ Snowflake ผ่าน REST API
  • การติดตามสถานะ: มอนิเตอร์สถานะงานฝั่งเซิร์ฟเวอร์
  • การจัดการวงจรชีวิต: ยกเลิกและเก็บกวาดผ่าน REST API ได้อย่างถูกต้อง
  • การมองเห็นระบบ: ให้ structured logs, metrics และ tracing สำหรับการส่งงานทั้งหมด

• การเปลี่ยนแปลงด้านสถาปัตยกรรม

  • ก่อนหน้า: Airflow → SSH Connection → EMR Master Node → Execute Command
  • หลังจากนั้น: Airflow → Quarry REST API → YARN ResourceManager → EMR Container
  • Airflow Operator ส่ง HTTP request ไปยัง Quarry แทนการเปิด SSH connection จากนั้น Quarry ส่งงานเข้า YARN และ poll สถานะ
  • แม้ Airflow Pod จะรีสตาร์ต งานก็ยังคงอยู่ เพราะ Quarry เป็นผู้รักษาการเชื่อมต่อไว้

• จุดแข็งของ Quarry

  • รองรับ YARN Distributed Shell จึงกลายเป็น gateway สำหรับส่งงานแบบอเนกประสงค์
  • ไม่ว่าจะเป็น Spark job, Hive query หรือ shell script ก็ผ่าน REST API ชุดเดียวกัน
  • ตัดทั้ง credential แบบ SSH และการเข้าถึงคลัสเตอร์โดยตรงออกไป เหลือเพียง REST call ที่มี authentication และการติดตามงานฝั่งเซิร์ฟเวอร์

เส้นทางการย้ายระบบ

• เนื่องจากมีงานโปรดักชันมากกว่า 700 งานใน 8 data region ที่แยกจากกัน แต่ละแห่งมีการตั้งค่าเครือข่ายและข้อกำหนดด้านอธิปไตยข้อมูลแตกต่างกัน อีกทั้งยังมีเวิร์กโหลดสำคัญอย่างการทำดัชนีค้นหาที่ต้อง ไม่มี downtime จึงจำเป็นต้องวางแผนอย่างเป็นระบบ

• แนวทางแบบเป็นเฟส

  • Phase 1 – พิสูจน์แนวคิด (PoC): ตรวจสอบแนวทางที่อิง Quarry ด้วยงานนำร่อง พัฒนา Quarry Operator ตัวแรก และทดสอบในสภาพแวดล้อม dev
  • Phase 2 – ตรวจสอบด้านความปลอดภัย: ทำงานร่วมกับทีมความปลอดภัยเพื่อวางแผนเลิกใช้ credential และยืนยันว่าแนวทาง REST ตรงตามข้อกำหนดด้านความปลอดภัย
  • Phase 3 – ขับเคลื่อนด้วย OKR: กำหนดเป็น Key Result เพื่อให้ผู้บริหารมองเห็นความคืบหน้า และในเฟสนี้ก็ บรรลุ milestone การย้าย 80%
  • Phase 4 – ย้ายครั้งใหญ่: หลายทีม เช่น Search Infrastructure, Data Engineering & Analytics และ ML Services ย้ายเวิร์กโหลดที่เหลือในทุก region แบบขนานกัน
  • Phase 5 – เก็บงานขั้นสุดท้าย: ปิด DAG ที่ตกหล่น เลิกใช้ legacy SSH Operator ทั้งหมด และทำได้ครบ 100%

• ตัวเลขการย้ายระบบ

  • ย้ายงานมากกว่า 700 งาน ครอบคลุม Operator 7 ประเภท
  • ใช้ rollout แบบมีการประสานงานไปยัง 8 data region ที่แยกจากกัน
  • 5 ทีมเปลี่ยนมาใช้ Operator ใหม่
  • บริการสำคัญต่อธุรกิจ ไม่มี downtime
  • ตั้งแต่งานนำร่องชุดแรกจนถึงการกำจัด SSH ครบ 100% ใช้เวลา 3 ไตรมาส

ความท้าทายที่พบระหว่างการย้ายระบบ

• Challenge 1 — ความล้มเหลวจาก Virtual Memory Check

  • ระหว่างย้าย DAG สำหรับ export ข้อมูล งานที่เคยรันปกติผ่าน SSH กลับ ล้มเหลวด้วยข้อผิดพลาด vmem check
  • สาเหตุ: SSH รันงานตรงบนโหนดมาสเตอร์ จึงหลบเลี่ยงการบังคับใช้ทรัพยากรของ YARN แต่ Quarry ส่งงานเข้า YARN อย่างถูกต้อง ทำให้คอนเทนเนอร์ที่เกิน virtual memory limit ถูกปฏิเสธ
  • วิธีแก้: ปิด vmem check ทั้งคลัสเตอร์ตามแนวปฏิบัติของ AWS — "yarn.nodemanager.vmem-check-enabled": "false"
    • สอดคล้องกับคำแนะนำของ AWS ที่ว่าการคิดบัญชี virtual memory บน Linux ไม่น่าเชื่อถือ และการจำกัดด้วย physical memory เพียงพอแล้ว
  • บทเรียน: SSH เคยซ่อนปัญหาหลายอย่างไว้ ดังนั้นเมื่อเปลี่ยนมาส่งงานเข้า YARN อย่างถูกต้อง ต้อง คาดการณ์ปัญหา resource limit ที่ไม่เคยเห็นมาก่อน และทดสอบใน dev ให้เพียงพอ

• Challenge 2 — การแยกเครือข่ายและปัญหาการเชื่อมต่อ EKM

  • เมื่อย้ายงาน search infrastructure ฝั่ง dev จากคลัสเตอร์ dev ไปยังคลัสเตอร์วิเคราะห์ staging เกิด EKM (Enterprise Key Management) connection timeout
  • ข้อผิดพลาด: Unable to execute HTTP request: Connect to sts.amazonaws.com:443 failed: connect timed out
  • สาเหตุ: คลัสเตอร์เดิมมีเส้นทางเครือข่ายไปยัง endpoint สำหรับจัดการคีย์อยู่แล้ว แต่ คลัสเตอร์วิเคราะห์ staging ซึ่งอยู่ใน network segment ที่เข้มงวดกว่า ไม่มี connectivity เทียบเท่า ทำให้เผยให้เห็น dependency ด้าน network topology ที่ไม่ได้ระบุไว้ในค่าคอนฟิกงาน
  • วิธีแก้: ย้ายงาน search infrastructure ไปยังคลัสเตอร์ dev ETL ที่สามารถ route ไปยังบริการ dev ได้ ขณะที่งานที่ต้องใช้ production Hive catalog ยังคงอยู่บน staging และขยายขนาดคลัสเตอร์ dev ETL เพื่อรองรับเวิร์กโหลดเพิ่มเติม
  • บทเรียน: network topology สำคัญมาก ต้องเข้าใจการแยกเครือข่ายและขอบเขตบัญชีก่อนตัดสินใจว่างานใดควรรันบนคลัสเตอร์ใด

• Challenge 3 — ความซับซ้อนของหลาย region

  • ด้วยข้อกำหนดด้านอธิปไตยข้อมูล Slack จึงรันคลัสเตอร์ EMR ใน 8 data region ที่แยกจากกัน การเลิกใช้ SSH จึงแทบเท่ากับ การย้ายระบบ 8 ชุดแบบขนาน

  • ปัจจัยความซับซ้อน

    • การจัดการคอนฟิก: แต่ละ region ต้องมีคอนฟิก Quarry, endpoint ของคลัสเตอร์ และกฎการ route เครือข่ายของตัวเอง
    • ภาระการทดสอบ: การเปลี่ยนโค้ดทุกครั้งต้องยืนยันผลในทั้ง 8 region
    • การดีพลอยแบบลำดับ: ไม่สามารถปล่อยพร้อมกันได้ ต้อง rollout แบบค่อยเป็นค่อยไปตาม region
    • ปัญหาเฉพาะราย region: ความต่างของคอนฟิกเครือข่าย กฎด้านอธิปไตยข้อมูล และเวอร์ชันของคลัสเตอร์

  • วิธีรับมือ

    • ตรวจสอบแนวทางใน region นำร่องเดียวก่อน โดยมากเป็น region ฝั่งสหรัฐฯ
    • จัดทำเอกสารข้อกำหนดคอนฟิกของแต่ละ region
    • สร้าง Quarry Operator ที่รู้จัก region
    • rollout แบบค่อยเป็นค่อยไป และนำบทเรียนของแต่ละ region มาปรับใช้
    • ติดตามความคืบหน้าการย้ายระบบแยกตาม region
  • บทเรียน: โครงสร้างพื้นฐานหลาย region ไม่ได้ยากแค่คูณ N แต่ยังมี failure mode เฉพาะของแต่ละ region เพิ่มเข้ามาด้วย จึงต้องเผื่อเวลาสำหรับการประสานงานข้าม region และการดีบักเฉพาะพื้นที่ให้เพียงพอ

ผลลัพธ์

• กำจัด SSH ได้ครบ 100% โดยงานโปรดักชันทั้งหมดเปลี่ยนมาใช้การส่งงานแบบ REST ผ่าน Quarry

• ผลลัพธ์ด้านความปลอดภัย

  • ยกเลิกการเข้าถึงผ่าน SSH จากคลัสเตอร์ EMR ฝั่งโปรดักชันทั้งหมดใน 8 data region ที่แยกจากกัน ลดพื้นผิวการโจมตีลงอย่างมาก
  • แทนที่การกระจาย SSH key ด้วย authentication แบบ service-to-service token และได้ audit trail ที่เหมาะสมผ่าน REST API logging
  • การส่งงานทั้งหมดมี structured logs ผ่าน Quarry
  • ย้ายคลัสเตอร์ EMR ตัวสุดท้ายในบัญชีหลักของ AWS ไปยังบัญชีย่อย ทำให้ โครงการ Whitecastle เสร็จสมบูรณ์
  • การยกเลิก security group แบบพิเศษและการจัดการสิทธิ์ที่ซับซ้อนช่วย ทำให้ compliance ง่ายขึ้น

• การปรับปรุงด้านการปฏิบัติการ

  • ขจัดการแย่งใช้ทรัพยากรบนโหนดมาสเตอร์ โดยงานที่ไม่ใช่ Hadoop ทั้งหมดรันใน คอนเทนเนอร์ YARN แบบกระจายพร้อมการจัดสรรทรัพยากรที่เหมาะสม
  • แม้ Kubernetes Pod ฝั่งไคลเอนต์จะรีสตาร์ต งานก็ยังคงอยู่ ทำให้ ความเชื่อถือได้ของงานดีขึ้นอย่างมาก zombie process หายไป และสามารถยุติงานได้อย่างถูกต้องผ่าน REST API
  • Quarry API ให้ สถานะงาน/log/metrics แบบมีโครงสร้าง ทำให้ติดตามวงจรชีวิตงานทั้งหมด ตรวจสอบ log ของคอนเทนเนอร์ YARN และดีบักด้วยเครื่องมือที่เหมาะสมได้

• การวางรากฐานสำหรับอนาคต

  • การกำจัดการพึ่งพา SSH ทำให้ สามารถย้ายไป Spark on Kubernetes ได้
  • สถาปัตยกรรมแบบ REST สอดคล้องกับแนวปฏิบัติแบบ cloud-native
  • เทียบกับการตั้งค่า SSH ที่ซับซ้อนแล้ว Quarry Operator เรียบง่ายและดูแลรักษาง่ายกว่า ช่วยให้ onboarding ทีมใหม่สะดวก
  • ช่วย decouple Airflow ออกจากรายละเอียดเชิงโครงสร้างพื้นฐานของ EMR
  • ทำให้การส่งงานทั้งหมดเป็นมาตรฐานผ่าน Quarry รองรับการเปลี่ยนแปลงในอนาคตได้ง่ายขึ้น
• หลังใช้งานในโปรดักชันเป็นเวลา 2 ปี ก็ยืนยันได้ว่าสถาปัตยกรรมนี้ตัดสินใจถูกต้อง ทั้งในด้านความปลอดภัย ความเสถียรในการปฏิบัติการ และความยืดหยุ่นของโครงสร้างพื้นฐาน

บทเรียนที่ได้รับ

• สิ่งที่ได้ผลดี

  • การย้ายแบบค่อยเป็นค่อยไป: rollout ตามลำดับ Dev → GovDev/CommDev → Prod และย้ายทีละประเภทของ Operator ทำให้สั่งสมบทเรียนได้เป็นขั้นตอน
  • ความร่วมมือระหว่างทีมที่แข็งแรง: Search, Analytics, Data Engineering, ML, Marketing และทีมอื่นๆ ทำงานร่วมกัน รีวิวโค้ดอย่างรวดเร็ว และสื่อสารผ่านช่องทางกลาง
  • การติดตามความคืบหน้าด้วยข้อมูลวิเคราะห์: สร้างแดชบอร์ดความคืบหน้าการย้ายระบบครอบคลุมทุก region และใช้ query จากฐานข้อมูล Airflow เพื่อระบุงานที่ยังอิง SSH อยู่

• สิ่งที่อยากทำต่างออกไปหากเริ่มใหม่

  • ควรทำแผนที่ network topology ล่วงหน้า: ปัญหาการแยกเครือข่ายอย่าง EKM connection เพิ่งถูกพบในช่วงท้าย จึงควร จัดทำเอกสารขอบเขตบัญชีของ Whitecastle และการ route เครือข่ายก่อนเริ่มย้ายคลัสเตอร์
  • ควรทดสอบ resource limit ตั้งแต่เนิ่นๆ: ปัญหา vmem check เพิ่งเกิดช่วงท้าย จึงควร ใส่การทดสอบ resource limit ของ YARN เทียบกับ SSH ตั้งแต่เฟสนำร่องแรก
  • ควรสื่อสารข้อจำกัดของ Operator ล่วงหน้าให้มากกว่านี้: ในช่วงท้ายเมื่อเริ่มจำกัดการใช้ SSHOperator ใหม่ บางทีมยังไม่รับรู้ จึงควร ประกาศล่วงหน้าให้ผู้ใช้ Airflow ทุกคนชัดเจนกว่าเดิม

• แนวปฏิบัติที่ดีสำหรับการย้ายระบบขนาดใหญ่

  • สร้างระบบมอนิเตอร์ก่อนเริ่มย้าย: ควรมีแดชบอร์ดตั้งแต่เนิ่นๆ เพื่อรู้จำนวนงานที่เหลืออยู่เสมอ และใช้ query จาก Airflow DB ช่วยติดตาม
  • ทดสอบหลายสภาพแวดล้อม: ทดสอบใน Dev, CommDev และ GovDev เพื่อจับปัญหาเฉพาะสภาพแวดล้อมก่อนถึงโปรดักชัน โดยเฉพาะ การทดสอบข้ามขอบเขตบัญชีเพื่อค้นหาปัญหาการแยกเครือข่ายล่วงหน้า
  • เลิกใช้ Operator แบบค่อยเป็นค่อยไป: เช่น CrunchExecOperator และ S3SyncOperator ควร เลิกใช้ทีละตัว โดยให้แต่ละขั้นเป็นมินิโปรเจกต์ที่มีการทดสอบและการยืนยันผลในตัวเอง แม้จะช้ากว่าแต่ช่วยลดความเสี่ยงได้มาก