Personal Blog for Work Update

หลายๆ องค์กร มีการใช้งาน BigQuery เป็น data warehouse ที่เก็บข้อมูลส่วนกลางขนาดใหญ่ การออกแบบ data warehouse ให้รองรับการใช้งานจากผู้ใช้หลายกลุ่ม สามารถทำได้หลายวิธี เช่นการ กำหนดสิทธิ์ที่ระดับ dataset  หรือการ สร้าง view เพื่อให้ผู้ใช้ เห็นเฉพาะผลลัพธ์ของ view นั้นๆ โดยไม่สามารถเข้าถึงข้อมูลทั้ง table ได้ อีกกรณีหนึ่งก็คือ การทำ dashboard ให้ผู้ใช้แต่ละคนเข้ามาใช้งาน dashboard เดียวกัน แต่ข้อมูลที่แสดงนั้น จะถูกดึงตามผู้ใช้งานที่กำลังเปิด dashboard อยู่ คือเห็นเฉพาะข้อมูลที่เกี่ยวข้องกับตัวเองเท่านั้น วิธีนี้มีข้อดีคือ เราจะสร้างและดูแล dashboard แค่ตัวเดียว โดยที่ผู้ใช้ก็จะเห็นข้อมูลของตัวเองเท่านั้น ไม่เห็นข้อมูลของผู้อื่น ไม่ต้องทำ dashboard แยกสำหรับผู้ใช้แต่ละกลุ่ม หรือแต่ละคน การ implement ในลักษณะนี้ อธิบายได้ด้วยแผนภาพนี้ครับ ในตัวอย่าง เรามีข้อมูลอยู่ 2 table คือ data_by_region (d) เป็นตัวอย่างข้อมูลที่แสดงเคสผู้ป่วย COVID-19 ในอิตาลี มี schema คือ date : วันที่เจอเคส region_name : ภูมิภาคที่เจอเคส region_acl_table (a) เป็นตารางที่ใช้ระบุว่า user ไหนสามารถดูข้อมูลจาก r...

เมื่อนานมาแล้ว ผมพัฒนา Apps Script ขึ้นมาตัวหนึ่ง เพื่อดึงข้อมูลจาก Reseller API มาตรวจสอบ หากเข้าเงื่อนไขที่กำหนดไว้ script ก็จะส่งอีเมลแจ้งเตือนไปยังทีมงานที่ดูแลข้อมูลชุดนั้น เมื่อเวลาผ่านไปนานเข้า จำนวนข้อมูลที่ต้องตรวจสอบก็เยอะขึ้น และจำนวนอีเมลที่ต้องส่งแจ้งเตือนออกไปก็มากขึ้นเป็นเงาตามตัว จนถึงขีดจำกัดของ script account ที่ผมใช้รัน script เพื่อดึงข้อมูลจาก Reseller API นั้น เป็น G Suite free editon ซึ่งมีข้อจำกัดในการส่งอีเมลที่ 100 ฉบับต่อวัน ซึ่งในบางวันนั้น จำนวนอีเมลที่ต้องส่งออกก็สูงเกินข้อจำกัดนี้ และการที่ระบบส่งอีเมลไม่ได้ ก็ส่งผลให้ทีมงานที่ทำงานกับอีเมลแจ้งเตือนนี้ ทำงานได้ลำบาก reseller account ที่ใช้ส่งอีเมลแจ้งเตือน มีข้อจำกัดที่ 100 ฉบับต่อวัน ซึ่งไม่พอกับความต้องการ ทางออกที่ก้าวข้ามขีดจำกัดนี้ มีอยู่หลายทาง เช่น การเปลี่ยนวิธีการส่งอีเมล แทนที่จะใช้ email service ของ Apps Script ก็สามารถเปลี่ยนไปใช้ SMTP relay อื่นๆ ได้ แต่ก็จะมีองค์ประกอบที่ต้องดูแลเพิ่มเติมเข้ามา ด้วยความที่บริษัทใช้ G Suite Business อยู่แล้ว และเมื่อดูจาก quota อีเมลก็สามารถส่งได้มา...

Apps Script มี function UrlFetchApp.fetch() สำหรับเรียก http request ไปที่ service อื่นๆ ได้ ซึ่งสามารถนำมาใช้เรียก API ภายนอกได้เช่นกัน แต่หากเรามีข้อมูลจำนวนมาก และต้องเรียก UrlFetchApp.fetch() หลายๆ ครั้ง จะทำให้ระบบทำงานช้าและเกินข้อจำกัดของ Apps Script ไป ( document ระบุไว้ว่าได้ 6 นาที) วันนี้ผมจะมาแนะนำวิธีแก้ปัญหาในกรณี้นี้กันคับ account ที่ผมใช้งาน ตกอยู่ในกลุ่มที่มีข้อจำกัด 6 min/execution เมื่อการเรียกทีละ request ไม่ตอบโจทย์ เรื่องเริ่มมาจากผมมีโปรเจกต์ที่มีข้อมูลชื่อโดเมน จำนวนประมาณ 1,400 รายการ ที่ต้องการดึงค่า DNS มาตรวจสอบอะไรบางอย่าง ด้วยการเรียก http request ไปที่ https://dns.google.com/resolve?name=%DOMAIN%  โดยการแทนค่า %DOMAIN% ด้วยโดเมนที่ต้องการ และนำค่าที่ได้จาก API มาทำงานต่อ หลังจากที่เตรียมชื่อโดเมนทั้ง 1,400 รายการลง array เรียบร้อย ก็เริ่ม process ข้อมูลใน array ทุกตัว โดยแต่ละตัวก็จะมีการเรียก UrlFetchApp.fetch() 1 ครั้ง ผลที่ได้ออกมาคือ เริ่มรันตอน 2020-03-17 17:41:48.049  script สามารถทำงานจนถึง record ที่ 1047 ที่เวลา 2...

องค์กรที่ใช้งาน Google Apps จะมีผู้ดูแลระบบ ที่คอยดูแลผู้ใช้งานในระบบ Google Apps เช่น การสร้างบัญชีผู้ใช้สำหรับพนักงานใหม่ การแก้ไขชื่อ นามสกุล และอีเมล เมื่อพนักงานมีการเปลี่ยนชื่อ หรือนามสกุล (เช่น กรณีพนักงานแต่งงานและเปลี่ยนนามสกุล) การ suspend ผู้ใช้ที่พ้นสภาพพนักงาน หรือการลบบัญชีที่ไม่ใช้งานแล้ว เพื่อจะได้นำ license มาใช้งานต่อไป การสร้าง แก้ไข ลบ user คืองานพื้นฐานของ admin และมีกำหนดเป็นหัวข้อในการสอบใบรับรองด้วย การจัดการส่วนนี้สามารถทำได้ผ่านหน้า Control Panel ของระบบ Google Apps ซึ่งองค์กรที่มีพนักงานไม่มากนัก มักจะมีการเปลี่ยนแปลงส่วนนี้ไม่บ่อย ผู้ดูแลระบบสามารถจัดการงานส่วนนี้ได้จากหน้า Control Panel โดยไม่ลำบาก ส่วนในองค์กรขนาดใหญ่ มักจะมีการเปลี่ยนแปลงข้อมูลพนักงานเกือบทุกวัน และวันหนึ่งก็มีจำนวน transaction เยอะและหลายรูปแบบ ซึ่งองค์กรในระดับนี้มักจะมี directory กลางขององค์กร ที่เป็นศูนย์รวมของบัญชีผู้ใช้ของทุกระบบในองค์กรนั้นๆ ได้แก่ LDAP (Lightweight Directory Access Protocol) server เช่น Microsoft Active Directory directory กลางสำหรับจัดการข้อมูล user, g...