ไปป์ไลน์ข้อมูลหลายมาร์เก็ตเพลซ: จัดการบัญชีผู้ขายข้ามภูมิภาค

การขยายไปป์ไลน์ข้อมูล Amazon จากหนึ่งมาร์เก็ตเพลซเป็นสามแห่งไม่ใช่แค่เรียกโค้ดเดิมสามครั้ง มาร์เก็ตเพลซสหรัฐฯ ญี่ปุ่น และเยอรมนีต่างกันในเรื่องพื้นฐานที่มากกว่าความต่างของเขตเวลา รายงานประเภทเดียวกันอาจมีรูปแบบต่างกัน ต้องตัดสินใจให้ชัดว่าจะแปลงสกุลเงินในขั้นตอนใดและใช้อัตราใด รูปแบบวันที่ไม่สอดคล้องกันทั้งในการตอบกลับจาก API และไฟล์ที่ดาวน์โหลด อีกทั้งโครงสร้างบัญชีแบบรวมกับแบบแยกภูมิภาคมีผลต่อข้อมูลที่ชุดข้อมูลรับรองแต่ละชุดเข้าถึงได้

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

ความแตกต่างที่แท้จริงระหว่างมาร์เก็ตเพลซ

รายงานที่เปิดให้ใช้ต่างกันมากกว่าที่เอกสาร SP-API ชวนให้เข้าใจ บางประเภทใช้ได้ทุกมาร์เก็ตเพลซ บางประเภทมีเฉพาะอเมริกาเหนือ สหภาพยุโรป หรือปลายทาง API บางภูมิภาค ตัวอย่างเช่น รายงานการปฏิบัติตามข้อกำหนด VAT มีเฉพาะมาร์เก็ตเพลซในสหภาพยุโรปและไม่มีรายงานเทียบเท่าในอเมริกาเหนือ ในทางกลับกัน รายงานสินค้าคงคลัง FBA บางประเภทมีโครงสร้างคอลัมน์ต่างกันระหว่าง Amazon.co.jp กับ Amazon.com แม้ใช้ ID ประเภทรายงานเดียวกัน สคีมาที่ได้ก็ต่างกันตามปลายทาง API ของมาร์เก็ตเพลซ

การจัดการวันที่และเวลาเป็นแหล่งข้อผิดพลาดที่สังเกตยากอยู่เสมอ API ของ Amazon คืนเวลาใน UTC แต่คอลัมน์วันที่ในไฟล์รายงานที่ดาวน์โหลดมักใช้เขตเวลาท้องถิ่นของมาร์เก็ตเพลซโดยไม่ระบุชัด หากรายงานใช้เวลาท้องถิ่น ไฟล์สำหรับมาร์เก็ตเพลซญี่ปุ่นจะมีวันที่เป็น JST ส่วนรายงานเดียวกันของเยอรมนีจะใช้ CET หรือ CEST ตามช่วงปี ขณะที่คอลัมน์อื่น เช่น posted-date-time ในรายงานการชำระยอดเงิน V2 มีเอกสารระบุว่าใช้ UTC โค้ดที่ตีความคอลัมน์วันที่ทั้งหมดเป็น UTC จะทำให้การรวมข้อมูลตามวันที่คลาดเคลื่อนหนึ่งวัน ซึ่งตรวจพบยากเพราะข้อมูลดูถูกต้องในเบื้องต้น

สกุลเงินเป็นความต่างที่มีผลต่อการดำเนินงานมากที่สุด Amazon ชำระยอดเงินเป็นสกุลเงินท้องถิ่นของมาร์เก็ตเพลซ ได้แก่ USD สำหรับสหรัฐอเมริกา JPY สำหรับญี่ปุ่น และ EUR สำหรับเยอรมนี ไปป์ไลน์ที่เก็บจำนวนเงินดิบโดยไม่กำกับสกุลเงินอย่างชัดเจนจะสร้างปัญหาคุณภาพข้อมูลที่สะสมตามเวลา กว่าจะพบข้อผิดพลาดอาจต้องแก้ข้อมูลย้อนหลังหลายเดือน การออกแบบที่ถูกต้องคือเก็บรหัสสกุลเงินคู่กับจำนวนเงินทุกค่า และแปลงในขั้นวิเคราะห์ แทนการฝังการแปลงไว้ในชั้นดึงข้อมูล

สถาปัตยกรรมที่ขับเคลื่อนด้วยการตั้งค่า

หัวใจของไปป์ไลน์หลายมาร์เก็ตเพลซที่ดูแลง่ายคือชั้นการตั้งค่าที่รวมคุณสมบัติเฉพาะของแต่ละแห่งไว้ในที่เดียว แทนการกระจายตรรกะเงื่อนไขไว้ทั่วโค้ดดึงข้อมูล แต่ละมาร์เก็ตเพลซมีชุดการตั้งค่าที่ระบุปลายทาง API การอ้างอิงข้อมูลรับรอง เขตเวลาท้องถิ่น รหัสสกุลเงิน ประเภทรายงานที่รองรับ และค่าที่ใช้แทนรูปแบบมาตรฐานสำหรับรายงานซึ่งต่างจากสคีมาอ้างอิง

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

แนวทางนี้ยังช่วยให้แบบจำลองข้อมูลชัดเจน เมื่อรหัสสกุลเงิน เขตเวลา และความต่างของรูปแบบรายงานอยู่ในไฟล์การตั้งค่าแทนความคิดเห็นในโค้ด ทุกคนที่ทำงานกับไปป์ไลน์จะเห็นข้อมูลเหล่านี้ ไม่ใช่เฉพาะนักพัฒนาที่เคยจัดการกรณีเฉพาะแต่ละกรณี

สถานะ YAML แยกตามมาร์เก็ตเพลซ

การติดตามสถานะด้วย YAML ที่ใช้กับไปป์ไลน์มาร์เก็ตเพลซเดียวขยายไปใช้กับหลายแห่งได้ตามธรรมชาติ แต่ต้องเลือกโครงสร้างไฟล์สถานะอย่างตั้งใจว่าจะใช้หนึ่งไฟล์ต่อมาร์เก็ตเพลซ หรือไฟล์เดียวที่แบ่งส่วนตามมาร์เก็ตเพลซ

ควรแยกไฟล์สถานะต่อมาร์เก็ตเพลซอย่างยิ่ง วิธีนี้ช่วยให้ไปป์ไลน์แต่ละแห่งทำงานอิสระโดยไม่แย่งใช้ไฟล์สถานะ รีเซ็ตหรือดึงข้อมูลซ้ำเฉพาะแห่งได้โดยไม่กระทบที่อื่น และสอดคล้องกับโครงสร้างไดเรกทอรีที่เก็บไฟล์ข้อมูลแยกตามมาร์เก็ตเพลซ ไดเรกทอรีสถานะที่มีไฟล์ YAML หนึ่งไฟล์ต่อแห่ง ได้แก่ state/us.yaml, state/jp.yaml และ state/de.yaml สื่อความหมายได้ในตัวดีกว่าไฟล์รวมที่มีส่วนซ้อนกัน

สคีมาของไฟล์สถานะควรระบุรหัสมาร์เก็ตเพลซให้ชัด แม้ชื่อไฟล์จะบอกอยู่แล้วก็ตาม เมื่อตรวจไฟล์ระหว่างแก้ปัญหาหรือตรวจสอบย้อนหลัง ข้อมูลที่ระบุซ้ำนี้จะขจัดความกำกวมว่ากำลังตรวจข้อมูลของมาร์เก็ตเพลซใด

นิยามรายงานผ่านทะเบียนกลาง

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

ทะเบียนทำหน้าที่หลายอย่างพร้อมกัน เป็นแหล่งอ้างอิงเดียวสำหรับ ID ประเภทรายงานที่ Amazon เปลี่ยนหรือเลิกใช้เป็นครั้งคราว บันทึกความต่างของสคีมาตามมาร์เก็ตเพลซ ทำให้จัดการด้วยโปรแกรมได้ง่ายแทนเงื่อนไขที่กระจายอยู่ และรองรับการตรวจสอบไฟล์ที่ดาวน์โหลดทุกไฟล์เทียบกับสคีมาที่คาดหวัง โดยแจ้งความคลาดเคลื่อนให้ตรวจสอบแทนการเขียนลงดิสก์โดยไม่แจ้งอะไร

ทะเบียนยังช่วยให้วิเคราะห์ช่องว่างของข้อมูลได้ เมื่อมีรายการประเภทรายงานที่คาดหวังและไฟล์สถานะ YAML ของแต่ละมาร์เก็ตเพลซ สคริปต์ง่าย ๆ ก็ระบุได้ว่ารายงานใดขาดหาย ไม่เป็นปัจจุบัน หรือเกิดข้อผิดพลาดซ้ำ พร้อมกันทุกมาร์เก็ตเพลซ หากไม่มีทะเบียน การวิเคราะห์นี้ต้องอาศัยความเข้าใจโค้ดดึงข้อมูล แทนการค้นจากโครงสร้างข้อมูลเพียงอย่างเดียว

ประเด็นการดำเนินงานเมื่อขยายระบบ

การดึงข้อมูลจากสามมาร์เก็ตเพลซพร้อมกันมีประเด็นเรื่องเวลาที่ไปป์ไลน์แห่งเดียวไม่ต้องรับมือ เวิร์กโฟลว์สองรอบที่ขอรายงานตอนเย็นและดาวน์โหลดตอนเช้าต้องคำนึงว่า “ตอนเย็น” และ “ตอนเช้า” ของสหรัฐฯ ญี่ปุ่น และเยอรมนีตรงกับเวลา UTC ที่ต่างกัน การรันตามตารางเดียวที่เหมาะกับเยอรมนีจะขอรายงานในเวลาที่ไม่สะดวกสำหรับญี่ปุ่น และอาจพลาดจุดเปลี่ยนวันทำการของสหรัฐฯ

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

ขีดจำกัดอัตราการเรียกใช้เป็นอีกประเด็นที่สำคัญขึ้นเมื่อมีหลายมาร์เก็ตเพลซ SP-API กำหนดขีดจำกัดอัตราการเรียกใช้แยกตามการดำเนินการสำหรับแต่ละคู่ของผู้ขายและแอปพลิเคชัน โดยบัญชีผู้ขายหนึ่งบัญชีสามารถครอบคลุมหลายมาร์เก็ตเพลซในภูมิภาคเดียวกันได้ ไปป์ไลน์ที่ขอรายงานถี่ ๆ พร้อมกันทั้งสามแห่งอาจใช้โควตาร่วมหมด ซึ่งไปป์ไลน์แห่งเดียวไม่เจอ การติดตามขีดจำกัดอย่างชัดเจนต่อผู้ขาย แอปพลิเคชัน และการดำเนินการ ไม่ใช่ต่อมาร์เก็ตเพลซ ช่วยป้องกันข้อผิดพลาดจากการจำกัดคำขอที่วินิจฉัยได้ยาก