FinOps: Our Team’s Journey to Save on BigQuery Usage Cost (Over $300!)

บทความนี้เราจะมาเล่า Journey ตั้งแต่การเริ่ม apply concept เรื่อง FinOps ภายในทีม Data รวมถึงสิ่งที่เราได้ research และจนได้ผลลัพท์ที่ทำให้เราเห็นข้อมูลการใช้งานบน BigQuery จนสามารถลด cost ที่ไม่จำเป็นได้มากกว่า 300$

Table of contents 
- FinOps คืออะไร
- แล้ว FinOps เกี่ยวกับทีมอย่างไร
- Our journey
- Ways to get BigQuery Usage
- Dashboard Result
- What we learned from these dashboards
- Summary

FinOps คืออะไร

“FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.”

— FinOps Foundation

หากแปลให้ง่ายขึ้น FinOps คือ practice หนึ่งที่ทำให้คนในทีมสามารถจัดการเรื่อง cost ที่เกิดขึ้นได้ โดยเฉพาะ cost ที่เกิดขึ้นบน cloud

โดยผลลัพท์ที่ทำให้เห็นชัดของ FinOps คือ การนำข้อมูลเรื่อง spending มาดู เช่น ดูว่าที่ผ่านมาโปรเจคนี้มีค่าใช้จ่ายประมาณเท่าไร ทำไมอยู่ๆ cost ก็พุ่งขึ้นมานะ นี่ยังปกติอยู่รึเปล่า

หรือบางโปรเจคที่มีการ query เยอะ เราสามารถจัดสรรการซื้อ service อีกแพคเกจดีไหมเพื่อราคาที่ถูกลงในระยะยาว ทั้งนี้การนำข้อมูลมาดูก็เพื่อ control, optimize, predict ผลที่เกิดเพื่อสร้างผลลัพท์ที่ดีกว่าการปล่อย waste money ไปเฉยๆ

แล้ว FinOps เกี่ยวกับทีมอย่างไร ?

FinOps ไม่ใช่เรื่องของทีมๆเดียว แต่เป็นการทำงานร่วมกันของฝั่ง engineer ที่ดูแล infrastructure เอง, ทีม Finance ที่ดูแลค่าใช้จ่าย และทีม business ที่ต้องมองถึง outcome value และ resource เรื่องคน

หากพูดในมุมองค์กรที่ต้องการ build data-driven แน่นอนว่าคนใช้ข้อมูลอย่าง Data User ไม่ว่าจะเป็น Data Analyst, Data Scientist, Data consumers หรือ Data Engineer เอง ก็สามารถมี awareness ในเรื่อง cost ที่เกิดขึ้นได้ และแชร์ best practice ร่วมกัน เช่น

ทุกคนสามารถรู้ได้ว่าฉันคิวรี่ไปจำนวนเยอะแค่ไหน และสามารถ query เพิ่มได้มากขึ้นอีกแค่ไหน หรือ best practice อย่างหลีกเลี่ยงการใช้ select * from table สำหรับ columnar database ก็สามารถลดปริมาณการ process ได้แล้ว

Our Journey

คราวนี้เราก็ตั้งคำถามว่า เราจะเริ่มเก็บ spending ส่วนไหนก่อนดีนะ ?

จากการ research และสังเกตสิ่งที่เรามีอยู่ในส่วนของภาพ Data Platform ที่เรามี เราสามารถแบ่งประเภทข้อมูลได้เป็น 2 แบบ

1. Data At Rest
   พูดง่ายๆคือข้อมูลที่อยู่กับที่ เป็นข้อมูลที่เน้นการ storage เป็นหลัก เช่นพวก database ทั้งหลาย สิ่งที่เราได้จากตรงนี้คือ sizing และ cost ที่เกิดขึ้นจากการ store
2. Data In Motion
   ส่วนของการ process, compute ทั้งหมด ไม่ว่าจะ analyze ข้อมูลที่ BigQuery, Process ข้อมูลที่ Spark, หรือ server cost อย่าง compute engine, kubernetes engine

และ BigQuery เป็น data warehouse ที่ทำได้ทั้งเป็น storage และ compute (query)

ซึ่งทั้งหมดล้วนมีค่าใช้จ่ายทั้งสิ้น 💸💸💸

แต่เราจะเลือกตัวไหนขึ้นมา monitor ก่อนดีล่ะ ?

Compute (Analysis) BigQuery cost

โดยเมื่อเรากองทุกอย่างมารวมกันแล้ว พบว่าสิ่งที่เราอยากรู้มากที่สุดคือเราอยากรู้ว่า Data Users มีการ query มากน้อยเพียงใด ยิ่งตอนนี้เรามี Data Analytics Bootcamp ที่เราต้องการสร้างคนในองค์กรเพิ่มทักษะเกี่ยวกับ Data

และปัจจุบันมีโปรเจคมากมาย อย่าง Data Analyst เองในบางครั้งก็ต้องดูหลายๆโปรเจคควบคู่กัน รวมไปถึงดูแล Data users ด้วย

เบื้องต้นจริงๆแล้วฝั่ง Data Analyst เองก็มี dashboard ที่เก็บ bigquery usage อยู่แล้ว แต่เป็นเพียงไม่กี่โปรเจคที่ active มากๆ ซึ่งในการสร้าง dashboard นั้น Data Analyst จำเป็นต้อง request ขอ BigQuery Resource Viewer role เพื่อที่จะมีสิทธิเข้าถึง job usage นั่น

หากจำนวนโปรเจคไม่เยอะก็คงจะไม่มีปัญหา แต่หากเรามีเยอะระดับหนึ่งคงจะปวดหัวไม่น้อย

หากเรามี 100 โปรเจค เราก็ต้องสร้าง 100 dashboards และ allow accessให้ Data Analyst คนที่ monitor เข้าถึงเพื่อสร้าง dashboard ใน 100 ครั้ง

Research, Research, Research

ดังนั้นเราถอยหลังกลับมาหนึ่ง step และไตร่ตรองดูว่าเราสามารถทำให้ process ตรงนี้ดีขึ้นได้อย่างไร

• เราจะทำเป็น dashboard กลางดีไหม
• ทำยังไงให้ลด overhead การ allow access, และลด human access
• ทำยังไงให้ทุกอย่างเป็น automation

รวมถึงเราได้ลอง research ว่า มีวิธีใดบ้างที่เราสามารถดึง Analyzed Usage ได้บ้างนะ

Ways to get BigQuery Usage

หลังจาก research พวกเราได้มาหลักๆ 3 วิธี

1. BQ’s information_schema.jobs_by_project
   วิธีนี้เป็นการใช้ view ที่ BQ provide มาให้ โดยหากเราใช้ view นี้ query ภายในโปรเจคนั้นๆก็จะเห็นข้อมูล job ที่เกิดขึ้น
   แต่ข้อเสียคือจะ query ดู usage ของโปรเจคอื่นไม่ได้ ซึ่งท่านี้ก็เป็น view ที่ Data Analyst ใช้เช่นกัน
2. Cloud Logging sink
   Cloud logging เป็น service ที่เก็บ log ทั้งหมดภายในโปรเจคนั้น โดยที่เราสามารถเลือกที่จะให้มันพ่น log ลงมาที่ sink แล้วนำมาเก็บไว้ที่ cloud storage ข้อดีของมันคือ logging ใช้ได้หลาย services ไม่ได้มีแค่ BigQuery อย่างเดียว แต่ข้อเสียที่ตามมาคือ log ค่อนข้างใหญ่ และเราต้องใช้เวลาแกะข้อมูลเพิ่ม
3. Cloud Billing exported to BQ

Cloud Billing เป็น options ที่ทุกคนต้องพุ่งเป้ามาเช็คแน่นอน เพราะ Cloud Billing จะบอกถึง cost การใช้งานในแต่ละ service ที่ครอบคลุมทุกอย่างที่ใช้ใน cloud เลย

และ GCP เขาก็คิดมาแล้ว เขาเลยสร้าง visualization template ให้ เพื่อสะดวกแก่ลูกค้าของเขา เพียงแค่ให้ไป allow ดึงข้อมูล Cloud Billing ลง BigQuery เท่านั้นเอง

แต่ข้อเสียคือ วิธีนี้ยังไม่ตอบโจทย์เราสำหรับ Data Users ที่อยากรู้ cost per query ที่ละเอียดถึง job level

ดังนั้น สุดท้ายแล้วด้วยวิธีการ implement และในเวลาที่จำกัด วิธี -information_schema.jobs_by_project จึงเป็นวิธีที่ fit กับเรามากที่สุด ทั้งความรวดเร็วและกินพื้นที่ใช้งานน้อย (น้อยกว่า cloud logging เยอะเลย)

จนเกิดเป็น pipeline หน้าตาแบบนี้

simple pipeline we made

สิ่งที่เราปรับเปลี่ยนพาร์ทของการดึงข้อมูลให้ดีขึ้นคือ

• เราทำให้ทุก step เป็น automation ทั้งหมด ควบคุมโดย Airflow
• หากมีโปรเจคใหม่เกิดขึ้น เพียงแค่ให้ service account ตัวที่เราใช้สำหรับ FinOps มี access BigQuery Data Editor, BigQuery Job User และ BigQuery Resource Viewer

เท่านี้เราก็สามารถดึง usage ได้และ ลด human access

และในส่วนปลายทางคือ เราปรับ dashboard เป็นใน 2 perspective

1. For Personal

personal cost dashboard

หน้า report นี้เราทำสำหรับทุกคน เพื่อที่ทุกคนจะมี cost transparency และ awareness โดยที่ทุกคนสามารถเข้ามาดู

• cost ที่เกิดขึ้นที่เฉพาะตัวเองที่ query ไป
• เห็นยอดเงินและจำนวน byte ที่ billed ไป
• โดยแบ่งออกเป็นแต่ละโปรเจคที่ join
• รวมถึงหน้าตา SQL ที่รันไปด้วย

เช่น ฉันเพิ่งคิวรี่ไปเมื่อวาน อยากรู้จังว่ามันกิน cost ไปเท่าไร ก็สามารถมาเช็คดูได้

2. For Admin

Team perspective, one of admin pages

หน้านี้ของ admin จะเป็นหน้าที่รวม cost ที่เกิดจากทุกๆในโปรเจคที่เราเก็บทั้งหมด มีทั้งรูปแบบ overall project ทั้งหมด, มุมมองของทีม (ตามรูปด้านบน), มุมมองการ query ต่อวันของแต่ละคน และแสดงการ query ในหลักนาทีว่ามีอะไรบ้าง

ซึ่ง report จะเข้าถึงได้เฉพาะบางคน โดยตอนนี้เราให้เป็น data engineers, data analysts, และ data scientist เพราะทุกคนคือคนที่สามารถ take actions ได้ดีที่สุดเมื่อเห็น cost

What we got from these dashboards

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

โดยพอเราลองเข้าไปเช็ค query ดู ซึ่ง dashboard สามารถดูหน้าตา SQL ที่รันภายในวันนั้นได้ เราก็ไปตามหาต้นตอที่ถูกรัน พบว่ามันเป็น scheduled query ที่ถูกเซ็ตไว้และไม่ได้ใช้แล้ว !

โดยเฉพาะในโปรเจค development ที่มีการ explore เพื่อทำ POC ซึ่งปกติแล้วจะมี cost การ query น้อยมากๆ เรากลับพบว่าที่มาผ่านมา 6–7 เดือน cost พุ่งทะยานสะสมๆขึ้นโดยที่เราไม่รู้ตัวด้วยซ้ำ 😱😱😱

one of projects we noticed the weird behavior

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

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

นอกจากนี้หลังจากที่ implement เสร็จเราก็คอยมา monitor กันเรื่อยๆ ก็ทำให้เห็น usage คร่าวๆของแต่ละโปรเจค เห็นว่าบางโปรเจคมีคนเยอะ,คนน้อย รวมทั้งมีกรณีที่อยู่ๆ cost ก็พุ่งมาเยอะกว่าปกติ และเมื่อหาปรึกษาคุยกันถึงต้นเหตุ เราก็จัดการคิด next step ถัดไปว่าจะจัดสรรการใช้งานให้ suitable กับเคสนั้นอย่างไร เปลี่ยน package รูปแบบการ query จาก on-demand เป็น flex slots หรือเพิ่ม query engine ตัวอื่นๆช่วย support หรือไม่

Summary

ในบทความทุกคนได้เข้าใจคำว่า FinOps และ FinOps ในรูปแบบที่เราใช้กับทีม data โดยเราริเริ่มจากความต้องการคนในทีม นั่นคือ BigQuery Analytics Usage

ในฝั่ง data engineer เรา research ถึงวิธีการหาข้อมูลก้อนนี้และปรับให้เป็น automation และลดภาระที่ทำให้ analyst ต้อง monitor หลายๆโปรเจค

และเราได้เรียนรู้จากข้อมูลที่เรามีว่ามีสิ่งผิดปกติเกิดขึ้น และสามารถลด cost ที่ไม่จำเป็นบางอย่างได้ รวมถึงทุก role ได้ปรึกษาแก้ไขปัญหาร่วมกัน เพื่อ support เคสที่ต้องมีการใช้งานปริมาณมาก เพื่อที่เราจะบริหารและจัดสรรได้อย่างมีประสิทธิภาพ