การตัดสินใจด้านอินฟราฯ (แทบ) ทั้งหมดที่ชอบ/เสียใจ หลังดูแลอินฟราของสตาร์ตอัปมา 4 ปี

 (cep.dev)
87 คะแนน โดย xguru 2024-02-28 | 4 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทำเครื่องหมายทุกการตัดสินใจเป็น Endorse(เห็นด้วย) และ Regret(เสียใจ)

การเลือก AWS

  • การเลือก AWS แทน Google Cloud: เห็นด้วย กับการเลือก AWS เพราะ AWS ให้ความสำคัญกับลูกค้า ขณะที่ Google Cloud ให้ความรู้สึกพึ่งพาหุ่นยนต์และระบบอัตโนมัติมากเกินไป
  • EKS: เห็นด้วย กับการใช้ EKS เพราะมีการผสานรวมกับบริการของ AWS ได้ลึก และ Kubernetes เองก็พัฒนาไล่ทันในหลายด้านแล้ว (เช่น ผสานรวมกับ Route53 ผ่าน externaldns)
  • EKS managed add-ons: เสียใจ ที่ใช้ EKS managed add-ons เพราะจำเป็นต้องปรับแต่งการติดตั้ง และหลังจากเปลี่ยนไปใช้ helm chart ก็พบว่าดูแลจัดการได้ดีกว่า

ฐานข้อมูลและแคช

  • RDS: เห็นด้วย กับการใช้ RDS ข้อมูลคือส่วนที่สำคัญที่สุดของอินฟรา และค่าใช้จ่ายของ RDS ก็คุ้มค่า
  • Redis ElastiCache: เห็นด้วย กับการใช้ Redis เพราะมีประสิทธิภาพมากทั้งสำหรับแคชและงานใช้งานทั่วไป
  • ECR: เห็นด้วย กับการย้ายจาก quay.io ไป ECR เพราะ ECR เสถียรกว่าและผสานรวมด้านสิทธิ์การเข้าถึงได้ลึกกว่า

เครือข่ายและซัพพอร์ต

  • AWS VPN: เห็นด้วย กับการใช้ AWS VPN เพราะตั้งค่าและทำความเข้าใจได้ง่ายมาก ใช้ Okta เพื่อจัดการสิทธิ์การเข้าถึง VPN และประสบการณ์ใช้งานก็ดีมาก
  • AWS Premium Support: เสียใจ เพราะค่าใช้จ่ายของ AWS Premium Support สูงมาก และถ้าภายในทีมไม่ได้ขาดความรู้เรื่อง AWS ก็ไม่คุ้มค่า
  • Control Tower Account Factory for Terraform: เห็นด้วย กับการผสานรวม AFT เพราะช่วยทำให้การสร้างแอ็กเคานต์เป็นอัตโนมัติและช่วยทำมาตรฐานแท็กให้สม่ำเสมอ

การทำกระบวนการอัตโนมัติ

  • การทำ postmortem อัตโนมัติด้วย Slack bot: เห็นด้วย กับการทำกระบวนการ postmortem ให้เป็นอัตโนมัติ เพราะช่วยกระตุ้นให้คนลงมือเขียน postmortem
  • การใช้ incident template ของ PagerDuty: เห็นด้วย กับการใช้เทมเพลตเมื่อเกิด incident และยังปรับแต่งได้บ้างด้วยความยืดหยุ่นของ Notion
  • การทบทวนตั๋วของ PagerDuty เป็นประจำ: เห็นด้วย กับการทบทวนการตั้งค่า alert อย่างสม่ำเสมอ เพื่อให้มั่นใจว่าแม้แต่ alert ที่ไม่สำคัญก็จะไม่ถูกเพิกเฉย
  • การจัดการ postmortem ใน Datadog หรือ PagerDuty: เสียใจ ที่ใช้เครื่องมือจัดการแบบรวมศูนย์สำหรับ postmortem เพราะทั้งสองอย่างปรับแต่งกระบวนการภายหลังได้ยาก คิดว่าการใช้เครื่องมือที่ทรงพลังกว่าอย่าง Notion ดีกว่า

อื่นๆ

  • การประชุมติดตามค่าใช้จ่ายรายเดือน: เห็นด้วย กับการประชุมรายเดือนเพื่อตรวจสอบค่าใช้จ่าย SaaS เพื่อเช็กว่าค่าใช้จ่ายเหมาะสมหรือไม่และดำเนินการที่จำเป็น ใน AWS จะจัดกลุ่มรายการตามแท็กและแยกตามแอ็กเคานต์ และแนะนำว่าไม่ควรดูเฉพาะ AWS แต่ควรตรวจสอบแหล่งค่าใช้จ่ายหลักทั้งหมดของบริษัท
  • ไม่ได้ใช้ FaaS ให้มากกว่านี้: เสียใจ ที่ไม่สามารถใช้ FaaS ได้เต็มที่ เพราะไม่มีตัวเลือก FaaS สำหรับงาน GPU แม้ว่างาน CPU หลายอย่างน่าจะย้ายไปทำบน FaaS ได้ อีกข้อดีที่ซ่อนอยู่ของ Lambda คือการติดตามต้นทุนได้ง่ายมากและแม่นยำสูง
  • GitOps: เห็นด้วย กับการใช้ GitOps ตอนนี้ใช้อยู่กับหลายส่วนของอินฟรา และลงทุนพัฒนาเครื่องมือเพื่อช่วยให้เข้าใจสถานะการ deploy
  • ให้ความสำคัญกับประสิทธิภาพของทีมก่อน: เห็นด้วย กับการให้ความสำคัญกับการเพิ่มประสิทธิภาพของทีม ไม่เคยเสียใจเลยที่ลงทุนเวลาไปกับ automation หรือ documentation
  • หลายแอปพลิเคชันใช้ฐานข้อมูลเดียวกัน: เสียใจ ที่ให้หลายแอปแชร์ฐานข้อมูลเดียวกัน เพราะก่อให้เกิดปัญหาหลายอย่าง

การนำ SaaS มาใช้

  • นำ identity platform มาใช้ช้าเกินไป: เดิมใช้ Google Workspace ในการกำหนดสิทธิ์ แต่ เสียใจ ที่ไม่ได้นำโซลูชันด้าน identity อย่าง Okta มาใช้ให้เร็วกว่านี้ เพราะ Okta ผสานรวมได้ดีและช่วยแก้ปัญหาด้านความปลอดภัยกับ compliance
  • Notion: เห็นด้วย กับการใช้ Notion สำหรับเขียนเอกสาร เป็นตัวเลือกที่ยอดเยี่ยมและใช้งานง่ายกว่าสิ่งที่เคยใช้ในอดีตมาก (เช่น Wikis, Google Docs, Confluence ฯลฯ) โดยแนวคิดเรื่อง database สำหรับจัดระเบียบหน้าต่างๆ มีประโยชน์มาก
  • Slack: เห็นด้วย กับการใช้ Slack เพราะมีประสิทธิภาพในฐานะเครื่องมือหลักสำหรับการสื่อสาร

เครื่องมือและบริการสำหรับการพัฒนา

  • ย้ายจาก JIRA ไป Linear: เห็นด้วย กับการใช้ Linear แทน JIRA เพราะมองว่า JIRA ซับซ้อนและหนักเกินไป
  • ไม่ใช้ Terraform Cloud: ไม่เสียใจ ที่ไม่ได้ใช้ Terraform Cloud เพราะไม่สามารถอธิบายความคุ้มค่าของค่าใช้จ่ายได้ จึงย้ายไปใช้ Atlantis และเพิ่ม automation ที่ต้องการเข้าไปใน CI/CD pipeline
  • GitHub Actions for CI/CD: เห็นด้วยในระดับหนึ่ง (Endorse-ish) กับการใช้ GitHub Actions เพราะ action ใน marketplace และไวยากรณ์ใช้งานง่าย แต่ข้อเสียคือรองรับ self-hosted workflow ได้จำกัด

การเลือกเทคโนโลยี

  • Datadog: เสียใจ ที่ใช้ Datadog เพราะค่าใช้จ่ายสูงมาก และโมเดลค่าใช้จ่ายไม่เหมาะกับ Kubernetes cluster และบริษัท AI
  • PagerDuty: เห็นด้วย กับการใช้ PagerDuty เพราะตัวผลิตภัณฑ์ดีและราคาสมเหตุสมผล
  • Schema migration by Diff: เห็นด้วยในระดับหนึ่ง กับการใช้เครื่องมือสำหรับ schema migration เพราะข้อมูลสำคัญและ schema migration อาจมีความเสี่ยง
  • Ubuntu for dev servers: เห็นด้วย กับการใช้ Ubuntu สำหรับเซิร์ฟเวอร์พัฒนา เพราะรองรับได้ดีและมีแพ็กเกจส่วนใหญ่ที่ต้องการ
  • AppSmith: เห็นด้วย กับการใช้ AppSmith สำหรับ automation กระบวนการของวิศวกรภายใน โดยโฮสต์เองและถือว่าน่าพอใจพอสมควร ตอนแรกเคยพยายามใช้ retool เพื่อการผสานรวมที่ลึกกว่า แต่ในเวลานั้นยังไม่สามารถอธิบายความคุ้มค่าของราคาสำหรับการผสานรวมเพียงไม่กี่อย่างได้
  • helm: เห็นด้วย กับการใช้ Helm v3 แม้จะมีปัญหาเรื่องการ deploy CRD และการฝึกนักพัฒนา แต่ก็ถือว่าดีพอสำหรับการแพ็กและ deploy Kubernetes object
  • helm chart in ECR(oci): เห็นด้วย กับการเก็บ helm chart ใน OCI registry เพราะมีปัญหาน้อยกว่าวิธีเดิมที่ใช้ S3 และปลั๊กอิน
  • bazel: ยังไม่แน่ใจ กับ bazel เพราะดูเหมือนจะมากเกินไปสำหรับการ deploy บริการ Go และ GitHub Actions ก็ใช้งานง่ายกว่าสำหรับวิศวกรจำนวนมาก
  • ไม่ได้ใช้ OpenTelemetry: เสียใจ ที่ส่ง metrics โดยใช้ DataDog API โดยตรง และแนะนำให้เริ่มใช้ OpenTelemetry ตั้งแต่แรก
  • เลือก renovatebot แทน dependencyabot: เสียใจ ที่ไม่ได้คิดเรื่องการอัปเดต dependency ให้ทันสมัยตั้งแต่เนิ่นๆ แม้ Renovatebot จะปรับแต่งได้ แต่การตั้งค่าและดีบักก็ซับซ้อน
  • Kubernetes: เห็นด้วย กับการใช้ Kubernetes เพราะจำเป็นต้องมีวิธีโฮสต์บริการที่รันระยะยาว และ Kubernetes ก็ได้รับความนิยมและทำงานได้ดี
  • การซื้อ IP ของตัวเอง: เห็นด้วย กับการซื้อ IP block ของตัวเองเมื่อต้องทำงานกับพาร์ตเนอร์ภายนอก เพราะช่วยให้สามารถให้ whitelist เป็น CIDR block ที่ใหญ่ขึ้นแก่พาร์ตเนอร์ภายนอกได้
  • เลือก Flux สำหรับ k8s GitOps: ไม่เสียใจ ที่เลือก Flux เป็นเครื่องมือ GitOps สำหรับ Kubernetes แม้ว่าจะยังต้องพัฒนาเครื่องมือเพื่อช่วยให้เข้าใจสถานะการ deploy
  • Karpenter for node management: เห็นด้วย กับการใช้ Karpenter เมื่อใช้ EKS เพราะเชื่อถือได้มากกว่าและคุ้มค่ากว่า autoscaler อื่นๆ
  • การใช้ SealedSecrets: เสียใจ ที่ใช้ SealedSecrets เพราะทำให้ซับซ้อนสำหรับนักพัฒนา และยังทำให้สูญเสีย automation เดิมของ AWS สำหรับการหมุนรหัสผ่าน
  • การใช้ ExternalSecrets: เห็นด้วย กับการใช้ ExternalSecrets เพื่อซิงก์รหัสผ่านจาก AWS -> Kubernetes เพราะนักพัฒนาเข้าใจได้ง่าย และสามารถสร้าง/อัปเดตรหัสผ่านใน AWS ได้สะดวกด้วย terraform
  • การใช้ ExternalDNS: เห็นด้วย กับการใช้ ExternalDNS เพื่อซิงก์รายการ DNS จาก Kubernetes -> Route53 และแทบไม่มีปัญหาเลยตลอด 4 ปีที่ผ่านมา
  • การใช้ cert-manager: เห็นด้วย กับการใช้ cert-manager สำหรับจัดการใบรับรอง SSL เพราะใช้งานง่ายมากในการออกใบรับรอง Let's Encrypt และไม่มีปัญหา
  • Bottlerocket for EKS: เสียใจ ที่รัน EKS cluster บน Bottlerocket เพราะมักเกิดปัญหา networking CSI และดีบักได้ยาก
  • การเลือก Terraform แทน CloudFormation: เห็นด้วย กับการใช้ Terraform เพราะขยายไปยังผู้ให้บริการ SaaS รายอื่นได้ง่ายกว่า และมีไวยากรณ์ที่อ่านง่ายกว่า CloudFormation
  • ไม่ใช้โซลูชัน IaC แบบ code-first: ไม่เสียใจ โดย Terraform และ CloudFormation ใช้ไฟล์ข้อมูล ขณะที่ Pulumi หรือ CDK อธิบายอินฟราด้วยโค้ด และข้อจำกัดของ HCL ใน Terraform ก็ช่วยลดความซับซ้อนได้
  • ไม่ใช้ service mesh: ไม่เสียใจ แม้ service mesh จะดูน่าสนใจ แต่บริษัทต่างๆ มักประเมินความซับซ้อนต่ำเกินไป คำแนะนำทั่วไปด้านอินฟราคือ "ยิ่งน้อยยิ่งดีกว่า"
  • Nginx load balancer for EKS ingress: ไม่เสียใจ และ เห็นด้วย กับการใช้ Nginx เพราะแม้จะเก่า แต่เป็นเทคโนโลยีที่เสถียรและผ่านการพิสูจน์แล้ว
  • homebrew for company scripts: เห็นด้วย กับการใช้ homebrew เพื่อแจกจ่ายสคริปต์ของบริษัท เพราะดีพอสำหรับการแจกจ่ายสคริปต์และไบนารีให้ทั้งผู้ใช้ Linux และ Mac
  • Go for services: เห็นด้วย กับการใช้ภาษา Go สำหรับบริการต่างๆ เพราะวิศวกรใหม่เรียนรู้ได้ง่ายและโดยรวมเป็นตัวเลือกที่ดี

บทความที่เกี่ยวข้อง

4 ความคิดเห็น

 
nicewook 2024-02-28

ทั้งเนื้อหาและคอมเมนต์ล้วนมีคุณค่ามากครับ
 
mhj5730 2024-02-28

โอ้โห....นี่เป็นข้อมูลเชิงปฏิบัติที่หาได้ยากมากจริง ๆ
 
xguru 2024-02-28

ความคิดเห็นจาก Hacker News

  • ค่าใช้จ่ายส่วนเพิ่มของการใช้ RDS นั้นคุ้มค่า

    • ค่าใช้จ่ายส่วนเพิ่มของการใช้ RDS นั้นแพงแบบเกินจริงจนได้แต่หัวเราะทุกครั้งที่พิจารณาจะใช้แทนคลัสเตอร์ SQL Server แบบ colocated ด้วยต้นทุนที่สูงเกินกว่าที่เต็มใจจะจ่ายมาก ซึ่งสามารถครอบคลุมค่า rack แบบ colocation, AWS Direct Connects, เซิร์ฟเวอร์, SAN, ไลเซนส์ SQL Server, สัญญาบำรุงรักษา และเงินเดือนของ DBA ภายในแบบเต็มเวลาได้เลย
    • ต้นทุนรวม 12 เดือน: 547,441.85 USD
    • เมื่อมาร์กอัปสูงมากพอที่จะจ่ายเงินเดือนพนักงานประจำได้หนึ่งคนหรือมากกว่า ก็ควรพิจารณาจ้างคนแทนการขยาย RDS แบบไม่คิดหน้าคิดหลัง คุณกำลังจ่ายแพงมากเมื่อใช้ RDS และควรทบทวนการตัดสินใจที่ทำไว้ตั้งแต่ช่วงเริ่มต้นบริษัท

  • ความเห็นนี้อาจไม่เป็นที่นิยม แต่ Google Cloud ดีกว่า AWS และ Google Cloud Run ทำให้การรัน Docker container บนคลาวด์เป็นเรื่องเหมือนฝัน ชื่อบริการเรียบง่ายกว่า มีบริการสำคัญที่ต้องรู้จักน้อยกว่าชุดบริการอันซับซ้อนของ AWS และ UI ก็ใช้งานเข้าใจง่ายกว่า ข้อเสียคือมีชุมชนน้อยกว่าเลยมีบทสอนน้อย หาคนมีประสบการณ์ยากกว่า และมีเครื่องมือจาก third-party น้อยกว่า แนะนำให้ลองใช้

  • การใช้ EC2 + ASG เป็นประสบการณ์ที่ดีมาก มันเรียบง่ายในเชิงแนวคิด: เอา image ไป launch ใน ASG แล้วตั้งนโยบาย auto scale แทบไม่มีอะไรให้ต้องกังวล ในทางกลับกัน การใช้ k8s เป็นงานใหญ่ตลอดเวลา ต้องตั้งทั้งทีมขึ้นมาดูแล k8s ต้องนำแนวคิดนับสิบของ k8s เข้ามาใช้ หรือไม่ก็ลงทุนเป็นคน-ปีใน "platform engineering" เพื่อซ่อนแนวคิดของ k8s ต้องออกแนวทางปฏิบัติและ SDK รวมถึงตัวตรวจสอบสารพัดเพื่อให้ใช้งาน k8s ได้ "อย่างถูกต้อง" และถึงอย่างนั้นก็ยังต้องเขียน YAML กับโค้ดอีกนับหมื่นบรรทัดเพื่อทำ operator บางครั้งก็อดสงสัยไม่ได้ว่า k8s มัน intrusive เกินไปหรือเปล่า

  • ความเห็นเกี่ยวกับผลิตภัณฑ์ SaaS

    • ไม่เข้าใจการย้ายจาก JIRA ไป Linear เลย Linear ก็โอเค แต่บ่อยครั้งจะเจอว่ามันทำบางอย่างไม่ได้ หรือไม่ก็ไม่รู้ว่าต้องทำยังไง
    • โดยทั่วไปแนะนำให้ใช้ Terraform Cloud การปล่อยให้ระบบที่ทำเองโตต่อไปเรื่อย ๆ อาจโอเคในช่วงสองสามปีแรก แต่ระยะยาวอาจมีต้นทุนตามมา
    • ค่อนข้างเห็นด้วยกับการใช้ GitHub Actions สำหรับ CI/CD แต่ขอเสนอให้ใช้ GitLab แทน
    • ไม่เห็นด้วยอย่างมากกับความเห็นเรื่อง Datadog มันเป็นเครื่องมือ monitoring/observability ที่ดีที่สุดในตลาด ข้อร้องเรียนที่พบบ่อยที่สุดคือเรื่องราคา แต่ส่วนใหญ่เป็นกรณีที่ตั้งค่า Datadog ผิดจนค่าใช้จ่ายพุ่งระเบิด
    • เห็นด้วยกับความเห็นเรื่อง Pagerduty Pagerduty แพงกว่า Opsgenie ประมาณ 10 เท่า แต่ไม่ได้ให้ความสามารถที่ดีกว่า ตอนต่อสัญญากับ Pagerduty พอถามเซลส์ว่ามีฟีเจอร์อะไรที่ Opsgenie ไม่มี คำตอบคือพวกเขาพยายามวางตัวเองเป็นแบรนด์พรีเมียมในตลาด ดังนั้นจึงพอใจกับการใช้แบรนด์ทั่วไปสำหรับการรายงานเหตุการณ์

  • นึกภาพนักพัฒนายุค 90s/00s มาอ่านรายการนี้แล้วคงงงกับความซับซ้อนและศัพท์ต่าง ๆ

  • เป็นเรื่องอ่านที่น่าสนใจ แต่ไม่แน่ใจว่าผู้เขียนเสียใจมากพอถึงขั้นต้องเขียนบล็อกหรือเปล่า

  • รู้สึกอยากลองย้อนกลับไปใช้เซิร์ฟเวอร์ยักษ์เครื่องเดียวราคา $100k แล้วรันทุกอย่างอยู่ในกล่องเดียว

  • ผมเรียนรู้พื้นฐานของ Kubernetes / EKS ได้สำเร็จ แต่กำลังคิดจะย้ายไป ECS Kubernetes ซับซ้อนเกินความต้องการของเรา ควบคุมด้วยอะไรอย่าง CloudFormation ได้ยาก load balancer ที่ provision จาก add-on ก็อ้างอิงจากภายนอก Kubernetes ได้ยาก logging จาก EKS Fargate ไป Cloudwatch ดูเหมือนจะไม่ทำงานแม้ทำตามเอกสารแล้ว และ metric CPU/หน่วยความจำก็ไม่ทำงานเหมือนบน EKS EC2 ดูเหมือนว่าจะต้องใช้ ADOT ด้วย พอลองทำสภาพแวดล้อมใหม่บน ECS กลับใช้เวลาแค่ 1/10 และทุกอย่างทำงานได้ดี

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

  • ฐานข้อมูลแบบ kitchen sink ที่ทุกคนใช้งานร่วมกันเป็นปัญหาที่พบบ่อย และก็ยังถูกทำซ้ำอยู่เรื่อย ๆ พอบริษัทเติบโตขึ้น มันจะกลายเป็น technical debt และคอขวดด้านประสิทธิภาพอย่างมาก การใช้ managed DB อย่าง RDS ทำให้สามารถแยกดูแลคลัสเตอร์ DB ตามแอปหลักแต่ละตัวได้ง่าย