อัพเดท Tech Stack ที่ใช้ที่ Wongnai Q1 2019
ห่างหายไปนานหน่อยครับ รอบที่แล้วก็ตั้งแต่ปี 2017 ผมก็ได้รับคำแนะนำจาก Krist Wongsuphasawat ว่าควรจะบอกด้วยว่าได้ลองอะไรมาแล้ว ดีไม่ดีอย่างไรบ้าง มารอบนี้ผมก็จะลองทำดูหน่อย แยกๆเป็นหัวข้อตามนี้ครับ Cloud Providers, Infrastructure, Programming Languages, Data Stores, Message Queue Brokers และเครื่องมืออื่นๆที่เราใช้ใน Wongnai แล้วก็จะสรุปตอนท้ายว่าอันไหนใช้ดีสำหรับเรา อันไหนยังต้องลองดูต่อไป และอันไหนที่คิดว่าไม่เหมาะกับเรา
Cloud Providers
สิ่งหนึ่งที่เราพยายามทำมาตลอด คือ เรื่อง vendor lock-in ซึ่งต้องระวังมากๆกับ Cloud Providers เพราะ แต่ละเจ้าชอบออกของดีๆใช้ง่ายๆมาให้ใช้อยู่เรื่อย อย่างไรก็ตามในปี 2018 เราเริ่มใช้งาน service ที่ทำให้เกิด vendor lock-in บ้าง เช่น BigQuery
Amazon Web Services
เป็น Cloud Provider แรกที่เราเริ่มใช้งานหลัง ย้าย CAT ที่เราต้องวาง Server เอง จุดเด่นของ AWS คือ มี Managed Services ที่พร้อมใช้ และยังใช้ protocol ทั่วๆไปที่เราสามารถลงใช้งานเองได้ที่เครื่องเราเพื่อทดสอบก่อนด้วย การย้ายจาก on-premise ไป AWS แทบจะทำได้ทันทีเลย ยกเว้นเรื่องย้ายข้อมูลนะครับ เจ็บหนักอยู่
ปัจจุบันเรามี production service มากกว่า 90% อยู่ที่ AWS
ปัญหากวนใจที่เจอกับ AWS คือ เราต้องลงและอัพเกรด Kubernetes Cluster เอง (ด้วย kops) เพราะเราไม่ค่อยชอบ Managed Kubernetes ของ AWS สักเท่าไรนัก
Google Cloud Platform
จุดเด่นที่เห็นได้ชัดของ GCP คือ มี Managed Kubenetes Cluster ให้ใช้ ใช้แล้วอุ่นใจกว่าลง Cluster เองเยอะเลย แทบจะ one-click up เลยทีเดียว ง่ายมาก Document ต่างๆก็อ่านเข้าใจง่าย ทำมาเพื่อ Developer เลยก็ว่าได้
GCP เป็นน้องใหม่มากๆเมื่อเทียบกับ AWS ยิ่งพูดถึงใน Singapore ด้วยแล้ว Service หลายๆอย่างไม่มีให้ใช้ด้วยซ้ำ บาง service รอนานจนถึงกับเลิกรอไปแล้วเลย Managed Services หลายตัวที่เป็น Opensource ก็ค่อนข้างเก่า ตามไม่ทันคู่แข่งเลย
Development environment ของเราอยู่ที่ GCP ทั้งหมดเลย และมีทำ VPN เชื่อมกับ AWS เนื่องจากมีการโอนข้อมูลระหว่าง data center ด้วย
Infrastructure
Kubernetes
Kubernetes ทำให้เราทำ Microservice ง่ายขึ้นมากๆ ยังขอยกให้เป็นพระเอกจนถึงทุกวันนี้ ปัจจุบันเราใช้ Kops ลงและอัพเกรด Kubernetes Cluster บน AWS และใช้ Managed Kubernetes บน GKE ซึ่งยังไม่ได้ทำ Autoscale เลยครับ เราต้องคอยเปิดเครื่องเพิ่มสำหรับช่วงหยุดยาวเพื่อรับ Traffic ที่เพิ่มขึ้น
Istio
ก่อนหน้านี้เราเคยทดลองใช้ Service Mesh อีกตัวนึงคือ Linkerd ลองใช้ได้ไม่นานก็ต้องปิดไปก่อน เพราะ เจอปัญหา connection แปลกๆ แล้วเราก็ไม่สามารถ ตรวจสอบอะไรได้เลย หลังจากนั้นเราก็ได้โอกาสลอง service mesh อีกรอบ แล้วก็เลือกลอง Istio แทนเนื่องจากดูจากคนที่ช่วยสนับสนุนแล้วดูน่าไว้เนื้อเชื่อใจกว่าของ Linkerd
เราเริ่มจากลองใช้งาน v0.9 ใน Development Environment ก็พบปัญหากวนใจเรื่อง Connection GRPC หลุดอยู่บ่อยๆ ทีม Architect ก็ช่วยกัน TCPDump มาตรวจสอบจนแก้ปัญหาได้ เราก็ได้ฤกษ์ เอาขึ้น Kubernetes ฝั่ง AWS ซึ่งเปิดใช้งานใน Beta Environment โดยไม่เจอปัญหาอะไรเลย และมีบาง Service ใน Production ก็ใช้งานแล้วด้วย
แต่เมื่อเราต้อง Upgrade เป็น v1.0 เราก็เจอปัญหาแปลกๆอีก คือ Connection ที่ต่อกับ MySQL หลุดบ่อยๆ แต่ดันเป็นเฉพาะใน Dev Environment เท่านั้น ไม่เจอใน Beta ยิ่งทำให้งงเข้าไปใหญ่
เหตุการที่ลดความมั่นใจของเราลงอีกครั้ง คือ ตอนที่เรา Upgrade Istio จาก v0.9 มาเป็น v1.0 ทำให้ cluster เราล่มไปหลายชั่วโมง โดยที่ไม่สามารถเข้าใจได้เลยว่าเกิดอะไรขึ้น สิ่งที่เราพบ ณ ตอนนั้นคือ เป็นที่ protocol ในการ sync state ของ route table ซึ่งจริงๆอาจจะเป็น Bug ของ Kubernetes เอง ไม่เกี่ยวกับเลย Istio ก็ได้ อย่างไรก็ตามเราก็ใช้งาน Istio v1.0 ได้ต่อมา โดยไม่เจอปัญหาเพิ่มเติม
ล่าสุดเราได้ลอง Upgrade Istio บน GKE เป็น 1.0.5 เพื่อเตรียมจะใช้งานบน Production ก็พบปัญหาเพิ่มขึ้นอีก คือ Envoy ไม่สามารถต่อกับ Service ได้ถ้า Service มี Pod ใหม่มาต่อแล้ว Pod เก่าตายไป ทำให้แผนการใช้ Istio บน Production ถูกหยุดไป และต้องปิด Istio บน GKE ทิ้งไปก่อน เพื่อให้ Developer ยังทำงานประจำวันได้ปกติ (Beta ยังใช้ v1.0 ได้ปกติอยู่) เราเดาว่าอาการเหล่านี้เกิดจากการ Upgrade มาเรื่อยๆจาก v0.9 แล้วมี Configuration สักอย่างค้างอยู่
ทำไมถึงไม่ใช้ Managed Istio? หลายๆคนน่าจะมีคำถามนี้ คำตอบคือ เนื่องจาก Kubernetes Cluster บน AWS เราลงเอง ไม่มี Managed Istio แน่ๆ เราจึงพยายามให้ Dev Environment เหมือนกับ Production มากที่สุด
Cloudflare
CDN ที่ช่วยลดค่าใช้จ่าย Data ได้เยอะมาก ระบบก็ไม่ค่อยจะล่มสักเท่าไหร่ ส่วนมากจะติดที่ Internet Provider ในประเทศซะมากกว่าที่ บางครั้งโหลดข้อมูลไม่ได้หรือช้าไปบ้าง
Programming Languages
Java
ภาษาที่ Back-end Service ที่ Wongnai ส่วนใหญ่ใช้ ซึ่งข้อดีคือ มี Tools และ Library ให้ใช้เยอะมาก Performance ก็เร็วในระดับที่น่าพอใจเมื่อเทียบกับความง่ายตรงไปตรงมา ข้อเสียที่เห็นชัดๆ คือ ความกินจุ ต้องการ memory เยอะมากๆ
เราเพิ่งจะเปลี่ยนจาก Java 8 มาใช้ Java 11 สำเร็จทุก projects เมื่อต้นปีนี้เอง สดๆร้อนๆเลย ใช้เวลาในการแก้โน่นแก้นี่อยู่ 2 เดือนกว่าๆ เหตุผลที่จะต้องอัพเกรดมาเป็น Java 11 คือ
- เราไม่อยากให้ในอนาคตเกิดปัญหาที่ ต้องการจะใช้ Library หรือ Tools อะไรบางอย่างแล้วติดว่าต้องเป็น Java 9+ ทำให้ไม่สามารถใช้งานได้ทันที ต้องเสียเวลามากเพื่ออัพเกรดเป็น Java 9 ซึ่งมีการเปลี่ยนแปลงระหว่าง Java 8 ไป Java 9 เยอะมากๆ Package javax หลายๆอย่างถูกดึงออก และใช้ Jigsaw แทน
- OracleJDK 8 จะเลิกออก Update ปลายปีหน้า (ธันวาคม 2020) และ OpenJDK 8 จะยาวถึงปี 2023 (จริงๆเราใช้ OpenJDK)
- Java 11 เป็น Long Term Support Version ล่าสุด
- การ Upgrade ไป Java LTS version ถัดๆไป(13) น่าจะง่ายกว่าการกระโดดจาก 8
Framework หลักที่เราใช้คือ Spring Framework ที่ช่วยให้ Component Reuse ง่ายขึ้นเยอะมาก
Javascript/Typescript
Javascript เป็นภาษาที่เหมาะกับ front-end มาก เพราะสามารถเขียน Server ที่ทำ Server Side Rendering ได้ และ ยังเขียน Code ที่รันใน Browser ได้อีกด้วย Developer ไม่ต้องเปลี่ยนวิธีคิดเลย ตอนนี้ที่ Wongnai ใช้ NodeJS 10 อยู่
เราเคยใช้ Flow อยู่ช่วงนึงแล้วสุดท้ายก็เปลี่ยนกลับมาใช้ Typescript จริงๆแล้วเคยลองใช้ Typescript ตอนช่วงแรกๆที่หันมาใช้ React แต่ตอน Compile มันช้ามากๆ เลยไม่ได้ใช้ต่อ ตอนนี้ก็กลับมาใช้ใหม่ เหตุผลก็ไม่มีอะไรมาก คือ เวลาที่ใช้ในการ Compile ไม่ได้มากเหมือนตอนที่เราเคยลองครั้งแรกแล้ว และ Typescript มี Ecosystem ที่ดีขึ้นเรื่อยๆตลอดปี 2018 ในขณะที่ความนิยมใน Flow ดูเหมือนว่าจะลดลง
HTML5 + CSS3
ทั้ง HTML5 และ CSS3 ก็เหมือนถูกมัดมือชก ยังไงก็ต้องใช้มันในการทำ Web Application อยู่แล้ว เราจะสนใจ Browser ใหม่ๆเป็นหลัก
Kotlin
Wongnai Android App ถูกเขียนด้วย Java มาก่อน แต่หลังจากที่มี Kotlin ทีม Android ก็พยายามจะเขียนเป็น Kotlin ที่สั้น สวย และ ปลอดภัยกว่า
สิ่งที่เห็นชัดที่สุดน่าจะเป็น Optional ที่บังคับให้เราจัดการกับ null ทำให้ Code มีระเบียบขึ้น โอกาสเกิด Bug น้อยลง
ปัจจุบัน Code ส่วนใหญ่ประมาณ 80% ยังคงเป็น Java แต่ว่า Code ใหม่ๆทั้งหมดจะเป็น Kotlin แล้ว และค่อยๆทยอยเปลี่ยนไปเรื่อยๆ เมื่อมีโอกาสต้องไปแก้ Code ส่วนนั้นๆ
Swift / Objective C
ภาษาที่น่าจะมาใช้แทน Objective-C ช่วยให้เขียนง่ายและปลอดภัยขึ้น มี Optional เหมือน Kotlin และ มี Value Type ให้ใช้ ทำให้เวลาเปลี่ยน State มีความปลอดภัย และ ไม่ต้องสนใจเรื่อง De-allocation มากนัก อีกทั้งการต่อ String ก็ทำได้ง่ายกว่ามาก Swift ยังมี Playground ให้เล่น ทำให้ลองใช้ Library ใหม่ๆก็ทดลองได้รวดเร็ว ยิ่งไปกว่านั้น iOS Developer ที่หัดเขียนจะเริ่มที่ Swift มากกว่า Objective-C ทำให้หาคนที่เขียน Objective-C ยาก
ข้อเสียของ Swift เมื่อเทียบกับ Objective-C คือ การ Compile Code ที่ช้า และ IDE ทำงานได้ช้ากว่ามาก
อย่างไรก็ตามเราก็ยังใช้ Objective-C อยู่บ้าง เพราะ มีบางครั้งเราต้องการเปลี่ยน behavior บางอย่าง ของ UIKit โดยการ inject code เข้าไปใน framework
ปัจจุบัน Code ของ Wongnai อัตราส่วน Swift : Objective-C คือเกือบเท่ากัน Swift แซงมาหน่อยนึงแล้ว
Python
ภาษา Script ที่เหล่า Data Scientist นิยมใช้งาน ยิ่งไปกว่านั้น วินได้เอา django มาปล่อย ช่วยให้ Front-end Developer ทำ CRUD Data Service ง่ายขึ้นเยอะ
Project ส่วนมากที่เราใช้ Python จะพยายามใช้ python 3 มากกว่า python 2.7 ซึ่งจะเลิก Support ในปี 2020 รวมถึง Project ERP ที่เราใช้ Odoo ด้วย
Go
ภาษาที่ใครๆก็พูดถึงเมื่อปีที่แล้ว คำอธิบายง่ายๆ คือ Non-blocking แบบ Static Typed เหมาะกับทำโปรแกรมที่ต้องรับ/ส่ง Remote Call อย่าง API Client หรือ API Server ข้อดีอีกอย่างคือ Compile แล้วเอาไปใช้งานได้เลย ไม่ต้องมี Dependencies อื่นๆให้วุ่นวาย สามารถแปะไปกับ Docker Image ไหนก็ใช้งานได้เลย ทำให้เหมาะกับงาน Infra เรามีใช้ Go ทำโปรแกรมเล็กๆช่วยงาน Infra เป็นหลัก และ มีทำพวก Service ที่ต้องการ I/O เยอะๆแต่ไม่ Block ด้วย
Groovy
เราใช้ Groovy ช่วยเขียน test และ dynamic script ครับ ข้อดีคือเรียก class/method ของ Java ได้เลย เพราะรันบน JVM
PHP
มีใช้อยู่ Project เดียว ซึ่งเป็น Yii Framework และไม่ค่อยมีคนอยากจะไปแตะสักเท่าไรนัก ยังดีที่มี requirement ใหม่ๆบ่อยๆ
Datastores
MySQL
Relational Database หลักที่เราใช้งาน เกือบทุก Service ที่ต้องการ ACID จะใช้ MySQL เราใช้งาน MySQL มาตั้งแต่ต้น มีเข้าใจการทำงานของมันค่อนข้างมาก สามารถ Tune Performance ได้คล่อง ถ้าไม่จำเป็นก็ไม่ค่อยอยากไปใช้งาน Relational Database ตัวอื่นๆเท่าไรนัก
Postgres
อย่างที่บอกไปก่อนนี้แล้วว่าเราไม่ค่อยอยากจะใช้ RDBMS อื่นๆนอกจาก MySQL นัก Postges เป็น RDBMS ตัวเดียวที่ไม่ใช่ MySQL ที่เราใช้อยู่ เพราะเราต้องการจะใช้ Odoo ที่เราใช้เป็น Software ERP ช่วยเรื่องการทำงานของฝ่ายขายเป็นหลัก
ปัญหาที่เจอคือ การ Upgrade Version ของ Postgres ถึงแม้ว่าเราจะใช้ Managed Service อย่าง RDS ก็ตาม แต่ก็ยังเจอปัญหาตอน Upgrade Database Version อยู่ดี
Solr
ช่วงแรกที่เราต้องการใช้ Inverted Index เพื่อใช้ในการค้นหาร้านอาหาร เราใช้ Lucene ซึ่งถูก Embedded ใน Code Java เราเลย แล้วก็เปลี่ยนมาใช้ Solr ที่แยก Service ออกมาทำให้ Scale แยกจาก Web Server ได้
ข้อดีของ Solr คือ มี Schema ของ Document ที่ชัดเจน ส่วน ข้อเสียของ Solr คือไม่มี Managed Service เลย อีกทั้งการ Scale Cluster ของ Solr จำเป็นต้องระบุ Shard และ Replica เองตอนซึ่งยากกว่าอีกเจ้ามาก
Elastic Search
Wongnai ยังไม่มี Service ไหนใช้ Elastic Search เลย จริงๆแล้วเคยคิดจากย้ายจาก Solr ไป Elastic Search เพราะ Solr ดูแลยากกว่ามาก และ AWS ก็มี Managed Service ให้ใช้งานอีกด้วย แต่สุดท้ายก็ไม่ได้ย้ายไป เพราะ ถ้าว่าด้วย Features ในการทำ Index แล้วไม่ต่างกันเลย ทั้งคู่ใช้ Lucene ในการทำ Inverted Index เหมือนกัน
อย่างไรก็ตาม Blognone Jobs เป็น Service ที่ใช้ AWS Elastic Search ในการค้นหาข้อมูลต่างๆ
ZooKeeper
ก่อนนี้ตอนที่ยังไม่ได้ใช้ Kubernetes เราใช้ ZooKeeper ในการจัดการ State ของ Node ใน Cluster เช่น ทำ Leader Election เป็นต้น แต่หลังจากที่เรามี Kubernetes เราสามารถรัน Pod แยกออกมาที่ทำหน้าที่เป็น Leader ได้เลย ไม่จำเป็นต้องใช้ ZooKeeper แล้ว
อย่างไรก็ตาม Solr ยังจำเป็นต้องใช้ ZooKeeper อยู่ เราเลยยังไม่สามารถเลิกใช้ ZooKeeper ได้
Cloud Storage — S3 / Google Cloud Storage
ใช้เก็บไฟล์ใหญ่ๆที่ไม่ควรเก็บไว้ใน Relational Database เช่น รูป, วีดีโอ, Log, Static File
BigQuery
ใช้เก็บข้อมูลเยอะๆ ที่เราต้องการให้ Query ง่ายๆ เช่น Access Log , Event Log โดยเราจะมี process ที่คอยย้ายข้อมูลที่ต้องการจาก AWS ข้ามไป Google BigQuery ผ่าน VPN
Redis
เป็น Key-value ที่เก็บข้อมูลใน memory เหมาะกับการทำ cache มาก Wongnai ใช้ AWS Managed Redis ทำ Cache, Feed และ State Management ง่ายๆ
InfluxDB
เราเคยใช้ InfluxDB เก็บข้อมูลที่เป็น Time series อย่าง Metric ต่างๆของ Application โดย Push จาก Service เข้าไปเลย
ปัญหาที่พบคือ InfluxDB Scale-out ไม่ได้ และเมื่อมีการใช้งานหนักๆ InfluxDb จะไม่ไหว ตอนนี้เราเปลี่ยนมาใช้ Prometheus ในการเก็บ Metrics แทนแล้ว
Cassandra
เราเคยใช้ Cassandra เป็นที่พัก Log และ Event ทั้งหมดก่อนจะ export ออกไปเก็บที่ S3 เพราะ Cassandra เป็น Column Family Database ที่ รับ Load Write ได้เยอะมากๆ
สุดท้ายเราก็เลิกใช้งาน เพราะ การ Maintain ค่อนข้างลำบาก เราไม่เคย Upgrade Version มันเลย และเจอปัญหาว่า Java Library ของ Cassandra เกิด Conflict กับ Library ตัวอื่นๆที่เราเปลี่ยนตอน Upgrade เป็น Java 11 ตอนนี้เปลี่ยนมาใช้ RabbitMQ เพื่อพัก Event ก่อนที่จะโยนไป BigQuery และเอา Log ไปเก็บที่ Graylog แทน
Message Queue Brokers
RabbitMQ
เริ่มแรกสิ่งที่เราคาดหวังจาก Message Queue คือ มันต้องทำทั้งสองอย่างนี้ได้
- Distributed Task Queue — ใช้กระจายงานให้กับ Worker หลายๆตัว โดยต้องไม่ process message ซ้ำกัน
- Event Pub/Sub Queue — Publisher ส่ง Message ให้กับ Subscribers ที่รอรับ Message อยุ่
ทีม Architect ได้ลอง Evaluate ทั้ง RabbitMQ และ Kafka ดู แต่ดูเหมือนว่า Kafka จะไม่ตอบโจทย์ข้อแรกที่เราต้องการ อาจจะทำได้แต่ต้องมี Service อื่นมาช่วยด้วย และเรายังไม่มี Usecase ที่ต้องใช้งาน Kafka ณ ตอนนี้ แต่ก็เป็นไปได้ว่าจะเอามาใช้ในอนาคตหากเราต้องทำ Data pipeline หนักๆเอง
RabbitMQ ช่วยให้เราทำงานที่ต้องมี Workers หลายๆตัวได้ง่ายขึ้นมาก เรายังใช้มันเป็นที่พักของ Event ต่างๆ ก่อนจะนำไป process หรือ นำไปเก็บใน BigQuery แทน Cassandra อีกด้วย
Monitoring Tools
Sentry
เราใช้ Sentry เพื่อเก็บ Error จากทั้ง Server และ Browser ซึ่ง Alert ที่ Sentry ส่งเข้า Email และ Slack Channel ช่วยให้เรารู้ว่าเกิด Error ขึ้น และแก้ไขได้เร็วขึ้น
Firebase
ทั้ง Android และ iOS ติดตั้ง Firebase Crashlytics SDK เพื่อเก็บ Error เมื่อเกิด Crashes ในเครื่องที่ Users ใช้ นอกจากนี้แล้วเรายังใช้ Firebase ช่วยทำ A/B Testing ในฝั่ง App Client อีกด้วย
Graylog
ตัวเก็บ Log จาก EC2 ทุก Node ที่ทำงานอยู่ ตัว Graylog ใช้ Elastic Search ในการเก็บ Log เพื่อจะ query ได้ไวๆ เมื่อเราต้องการตรวงสอบ Bug ต่างๆ
ปัญหาที่เจอคือ เราไม่สามารถเก็บ Log จำนวนมากได้นานนัก Elastic Search ใช้พื้นที่ในการเก็บเยอะมากๆ ปัจจุบันเราสามารถเก็บ Log ทั้งหมดได้เพียงแค่ 5 วันย้อนหลังเท่านั้น
X-Ray
เราเริ่มใช้ X-Ray เพื่อดูว่า Service ไหนของเราที่ช้า สามารถอ่านได้จาก รีด-microservice-performance-บน-aws-ตอนที่-1 X-Ray สามารถสร้าง Service Map ให้เข้าใจง่ายๆ ชี้ให้เห็นว่า Service ไหนช้า Service ไหนเร็ว
ปัญหาที่เจอคือ X-Ray Client ที่ทาง AWS ให้มากับ AWSSDK ไม่ค่อยดีเท่าไรนัก ในช่วงแรกๆที่ใช้เราต้อง Reflection เพื่อแก้สิ่งที่ไม่ถูกต้องเองด้วยซ้ำ เพราะไม่ได้ Opensource ให้เราแก้ (แต่ตอนหลังก็มี Opensource แล้ว)
อย่างไรก็ตาม เราก็ต้องถอด X-Ray ออกเนื่องจากพบว่า Client Library ของ NodeJS ทำให้เกิด Memory Leak เพื่อใช้งานกับ async/await ทำให้เราไม่เห็น Trace ที่อยู่ใน React SSR อีกต่อไป
Jaeger
Jaeger ทำหน้าที่เหมือน X-Ray เลย สาเหตุหลักที่เราย้ายมาใช้ Jaeger เพราะ เราเริ่มลองใช้ Istio และ Istio ก็ใช้ Jaeger พอดี ไม่มีเหตุผลที่เราจะใช้ Tracer ที่ต่างกับ Istio
Jaeger ตอบโจทย์เรื่องหา Service ที่ช้าได้ดี แต่เรื่อง UI ยังทำได้เข้าใจยากกว่า X-Ray มาก อ่านเรื่อง Jaeger เพิ่มเติมได้ที่นี่ครับ
Prometheus
ใช้เก็บ Metrics ต่างๆ แทน InfluxDB Prometheus เป็น Pull Model ตรงข้ามกับ InfluxDB ซึ่งน่าจะทำงานได้มีประสิทธิภาพมากกว่า InfluxDB สำหรับ Service ที่เรามีทั้งหมด อีกเหตุผลก็คล้ายๆกับการย้ายมาใช้ Jaeger คือ Istio สามารถเปิดการใช้งาน Prometheus ได้เลย
ในเชิงการใช้งานจริงๆ Developer Implement และ ทดสอบ Metrics Endpoint ที่ให้ Prometheus มาเก็บข้อมูลได้ง่ายกว่า Push Model มาก ส่วนการ Query ก็น่าจะหนักพอๆกันกับ InfluxDB นั่นแหล่ะ
Grafana
ใช้ทำ Dashboard ต่างๆ โดยเฉพาะ Metrics ที่เก็บไว้ที่ Prometheus และ InfluxDB รวมถึง Query โดยตรงไปยัง AWS ด้วย
สิ่งที่คิดว่า Grafana ยังทำได้ไม่ดีนัก คือ การ Alert ที่ยังทำได้ไม่ซับซ้อนเท่าไร ไม่สามารถทำงานบางอย่างที่เราต้องการได้ เช่น ยังไม่สามารถ Alert จาก Trend ของ Graph ที่เปลี่ยนไปจนผิดปกติได้ แต่ถ้าใช้ตาดูก็จะเห็น
Others
GitLab
เริ่มแรกเลยที่ Wongnai ลง git แล้ว serve ผ่าน HTTP ด้วย Apache Httpd ซึ่งค่อนข้างยุ่งยากมาก จึงเปลี่ยนมาเป็น gitolite ที่ง่ายขึ้นมาอีกนิด แต่พอเริ่มมี user เยอะขึ้นจึงเปลี่ยนมาใช้ gogs
ปัจจุบันเปลี่ยนมาใช้ GitLab ซึ่งสะดวกสบายกว่าเดิมเยอะมาก สามารถทำ Code Review ได้แบบ Online เลย มี GitLab CI ช่วยในการ Build Change ได้ และ ทำ Deployment ได้เลยหลังจาก Build Branch หลักเสร็จ
Jenkins
เราเคยใช้ Jenkins ในการ Build Code ทุก Project แต่ในปัจจุบันหันมาใช้งาน GitLab CI แทนแทบจะทุก Project แล้ว เหลือแค่ไม่กี่ Project เท่านั้นที่ยังใช้งานอยู่ รวมถึง iOS App ที่ต้อง Build บน Mac Mini ที่ Office ด้วย ทำให้ยังจำเป็นต้องใช้ Jenkins อยู่
ถึงแม้ว่า Jenkins จะทำ Build ที่ซับซ้อนกว่าได้ แต่เหตุผลหลักที่ย้ายไปใช้ GitLab CI แทน เพราะ GitLab CI สะดวกสบายกว่ามาก และยังติดกับตัว GitLab ทำให้สามารถดึงค่าของ Change บางอย่างมาช่วยในการ Build ได้อีกด้วย
Sonarqube
เนื่องจาก Developer ทุกคนจะต้องทำ Code Review ให้กับเพื่อนๆในทีม และการทำ Code Review ก็ใช้เวลาไม่น้อยด้วย เราลองเอา Sonarqube มาช่วยวิเคราะห์ Code เบื้องต้นก่อน จากการทดลองใช้สักพักนึงยังไม่เห็นผลอะไรมากนัก ยังคงต้องลองใช้ ปรับโน่นปรับนี่กันต่อไปก่อน
Project Eastern
https://github.com/wongnai/eastern เป็น เครื่องมือที่เราใช้ทำ Template สำหรับ Deployment Descriptor ของ service ที่จะ deploy บน Kubernetes
Vault
หลักๆแล้วเราใช้ Vault ซ่อน Password ของ Production Service ต่างๆ เช่น Database Password หรือ API Secret ซึ่งก่อนหน้านี้เราเก็บ Password ไว้ด้วย Secret ของ Kubernetes
GRPC
ที่ Wongnai เราจะให้ระหว่าง Service คุยกันด้วย GRPC เสมอ เพื่อความลด Overhead ที่ไม่จำเป็น สิ่งที่ดีอีกอย่าง คือ Protobuf ที่ต้องเขียนเสมอเป็นการบังคับเราให้มี Schema ของ Service ที่ชัดเจนโดยอัตโนมัติ
ข้อเสียอย่างเดียว คือ เมื่อเทียบกับ HTTP REST แล้วเทสยากกว่ามากๆ ไม่สามารถเอา Browser มาใส่ URL แล้วเทสได้ง่ายๆได้อีกต่อไป
GraphQL
เราไม่ได้เปิด GraphQL ให้ Client ใช้โดยตรงนะครับ แต่ใช้ GraphQL ใน api-gateway ที่รับ REST API เพื่อช่วย Aggregate ข้อมูลจาก Service ต่างๆได้ง่ายขึ้น
Apache Nifi
เราเริ่มใช้ Nifi มาโยกข้อมูลจาก Database Schema นึงไปยังอีก Schema นึง โดยให้ Nifi อ่านจาก Binlog ของ MySQL เพื่อให้ทีม Data Scientist เอาข้อมูลไปคำนวณต่ออีกที ปัญหาที่เจอคือเรื่อง Performance ซึ่งยังไม่ดีเท่าไรนัก
Matomo
เราได้ทดลองใช้ Matomo ใน Production มาได้สักพัก เพื่อเก็บ Impression/Click Rate ของ Ad จริงๆคาดไว้ตั้งแต่แรกแล้วว่า Matomo ไม่น่าจะไหว เพราะ Scale out เพื่อ Aggregate Data ไม่ได้ แต่ก็อยากลอง แล้วก็พบว่าไม่ไหวจริงๆ คาดว่าเราน่าจะต้อง Implement ระบบที่ทำข้อมูลพวกนี้เองในอนาคตอันใกล้
สรุป
ขอสรุปอีกทีให้เข้าใจง่ายตามนี้นะครับ
- ทดลองใช้— Istio, Jaeger, Sonarqube
- ใช้ได้ดีและใช้ต่อไป — Kubenetes, Prometheus, Cloudflare, BigQuery, Redis, Cloud Storage, MySQL, Postgres, Solr, Elastic Search , Zookeeper, Grafana, Graylog, Sentry, RabbitMQ, GraphQL, Vault, GRPC, GitLab, Project Eastern
- ยังไม่พอใจนัก ต้องหาของมาแทน— Apache Nifi, Jenkins, Matomo
- เลิกใช้—Flow, Linkerd, Cassandra, InfluxDB, X-Ray
จาก Q1 2017 เรามีของเพิ่มมาให้ใช้หลายอย่างเลย หลายๆอย่างได้ไปต่อ บางอย่างก็ต้องเลิกใช้ ในปีนี้เราก็น่าจะได้ทดลองใช้ของใหม่มาที่มาช่วยให้ Developer ทำ Features แปลกๆใหม่ๆต่อไปเช่นเคย
พื้นที่โฆษณา: Wongnai รับ Developers จำนวนมากอยู่เรื่อยๆ ทั้ง Full-time, นักศึกษาฝึกงาน และ สหกิจ นะครับ ใครสนใจสมัครได้เลยที่นี่
