ออกแบบสถาปัตยกรรมแบบที่ปิด technical win

ผู้สัมภาษณ์ DCE ให้น้ำหนักการออกแบบสถาปัตยกรรมมากที่สุด เพราะมันคือสิ่งที่เราจะทำจริงหน้างานทุกวัน ลูกค้าไม่ได้จ้าง DCE มาท่อง service แต่จ้างมาเปลี่ยนความต้องการธุรกิจที่คลุมเครือให้เป็นสถาปัตยกรรมที่ใช้งานได้จริง คุ้มเงิน ปลอดภัย และโตได้ คำถามออกแบบจึงไม่มีคำตอบเดียวที่ถูก ผู้สัมภาษณ์ดู "กระบวนการคิด" ของเรา ว่าเราถามคำถามที่ถูกไหม แยกชั้นระบบเป็นไหม เลือก service พร้อมเหตุผลไหม และเล่า trade-off ออกมาดัง ๆ ได้ไหม คนที่ตอบเก่งคือคนที่ทำให้ผู้สัมภาษณ์รู้สึกว่า "ถ้าให้คนนี้ไปนั่งหน้าลูกค้า เขาออกแบบทางที่ชนะได้"

Google มีกรอบออกแบบที่ DCE ควรอ้างได้ ประกอบด้วยเสาหลักที่ต้องชั่งน้ำหนักพร้อมกันเสมอ:

Reliability (ความน่าเชื่อถือ): ระบบต้องทนความล้มเหลวและกู้คืนได้ ออกแบบด้วย redundancy, multi-zone และ multi-region deployment, health check, autoscaling, graceful degradation ความเชื่อถือได้ไม่ใช่ของฟรี ต้องแลกกับต้นทุนและความซับซ้อน

Security (ความปลอดภัย): ออกแบบแบบ defense in depth ใช้ least privilege เข้ารหัสข้อมูล แยก network และมองเห็นทุกอย่างผ่าน logging ความปลอดภัยต้องคิดตั้งแต่ออกแบบ ไม่ใช่แปะทีหลัง

Cost Optimization (ต้นทุนเหมาะสม): เลือก service และ tier ให้คุ้ม ปรับขนาดให้พอดี (right-sizing) ใช้ committed use discount ปิดทรัพยากรที่ไม่ใช้ และเลือก serverless เมื่อ traffic ไม่สม่ำเสมอเพื่อจ่ายตามใช้จริง

Performance and Scalability (ประสิทธิภาพและการขยาย): รองรับโหลดที่โตได้ ออกแบบให้ scale แนวนอน ใช้ caching และ CDN ลด latency เลือก database และ storage ที่รองรับ throughput ที่ต้องการ

Operational Excellence (ความเป็นเลิศด้านปฏิบัติการ): ระบบต้องดูแลและสังเกตได้ ใช้ monitoring, logging, tracing, automation และ infrastructure as code เพื่อให้ทำซ้ำได้และลดความผิดพลาดจากคน

หัวใจคือเสาเหล่านี้มัก "ขัดกัน" เช่น reliability สูงขึ้นมักดันต้นทุนขึ้น ความปลอดภัยเข้มขึ้นอาจกระทบ performance หรือความสะดวก งานของ DCE คือหาจุดสมดุลที่เหมาะกับ "บริบทของลูกค้ารายนี้" ไม่ใช่ทำทุกเสาให้สุดทุกตัว

นี่คือ playbook ที่ควรท่องให้ขึ้นใจ เพราะใช้ได้กับทุกโจทย์ออกแบบ

ขั้นที่ 1 — เก็บ requirement ก่อนเสมอ (อย่ารีบตอบ):

ถามให้ครบทั้งด้าน functional และ non-functional

• จำนวนผู้ใช้และรูปแบบ traffic: ผู้ใช้พร้อมกันกี่คน มี peak ช่วงไหน traffic สม่ำเสมอหรือกระชาก
• ความต้องการ availability และ SLA: ระบบล่มได้นานแค่ไหน ต้องการ uptime กี่เปอร์เซ็นต์
• RTO และ RPO: กู้คืนต้องเร็วแค่ไหน ยอมเสียข้อมูลย้อนหลังได้แค่ไหน
• ปริมาณและประเภทข้อมูล: ข้อมูลใหญ่แค่ไหน structured หรือ unstructured โตเร็วแค่ไหน
• latency และ geography: ผู้ใช้อยู่ที่ไหน ต้องการตอบสนองเร็วแค่ไหน ต้องมี presence หลายภูมิภาคไหม
• compliance และ data residency: ข้อมูลต้องอยู่ในประเทศไหม มีกฎ PDPA หรือกฎอุตสาหกรรมไหม
• budget: งบประมาณกรอบเท่าไหร่
• ทักษะทีมและ operating model: ทีมดูแลเองได้แค่ไหน ชอบ managed service หรืออยากคุมเอง
• timeline: ต้องเสร็จเมื่อไหร่

การถามคำถามเหล่านี้คือสิ่งที่ผู้สัมภาษณ์อยากเห็นมากที่สุด เพราะมันแสดงว่าเราคิดแบบ advisor ไม่ใช่เดา

ขั้นที่ 2 — แยกชั้นระบบ (decompose):

แบ่งระบบเป็นชั้นมาตรฐานเพื่อจัดการความซับซ้อน

• Presentation / frontend layer: ส่วนที่ผู้ใช้เห็น เว็บ mobile
• Application / compute layer: ตรรกะธุรกิจ API
• Data layer: database และ storage
• Integration layer: messaging, API gateway, event
• Networking layer: VPC, load balancer, CDN, การเชื่อม on-prem
• Security layer: IAM, encryption, WAF, perimeter
• Observability layer: monitoring, logging, alerting

ขั้นที่ 3 — เลือก service ให้แต่ละชั้นพร้อมเหตุผล:

จับคู่ความต้องการกับ service GCP โดยอธิบายว่าทำไมเลือกตัวนี้ ไม่เลือกตัวอื่น

ขั้นที่ 4 — ออกแบบ availability และ scaling:

ตัดสินใจ multi-zone หรือ multi-region, autoscaling แบบไหน, จุดไหนเป็น single point of failure แล้วกำจัดอย่างไร

ขั้นที่ 5 — ใส่ security และ networking:

แยก public กับ private, วาง IAM, encryption, firewall, perimeter

ขั้นที่ 6 — คิด cost และ operations:

ประเมินต้นทุนคร่าว ๆ มองหาจุดประหยัด วาง monitoring และ automation

ขั้นที่ 7 — เล่า trade-off และทางเลือก:

อธิบายว่าทำไมออกแบบแบบนี้ ทางเลือกอื่นเป็นอย่างไร แลกอะไรกับอะไร ปิดด้วยคุณค่าทางธุรกิจ

เตรียมเล่ารูปแบบเหล่านี้เป็นแม่แบบ แล้วปรับตามโจทย์

Pattern A — Web application 3-tier ที่ scale ได้:

ผู้ใช้เข้าผ่าน Cloud Load Balancing (global, HTTPS) ที่มี Cloud CDN ด้านหน้าเพื่อ cache static content และ Cloud Armor ป้องกัน DDoS และ WAF ชั้น compute ใช้ Cloud Run หรือ GKE ที่ตั้ง autoscaling ตามโหลด ชั้น data ใช้ Cloud SQL สำหรับ relational ทั่วไป หรือ Spanner ถ้าต้อง global ไฟล์และ media เก็บใน Cloud Storage เสริม Memorystore เป็น cache ลดภาระ database ทั้งหมดอยู่ใน VPC ที่แยก subnet มี IAM และ monitoring ผ่าน Cloud Observability จุดขายคือ autoscaling ทำให้รับ traffic พีคได้โดยไม่ต้องจ่ายเต็มตลอดเวลา

Pattern B — Data analytics platform:

ข้อมูลจาก source ต่าง ๆ เข้าผ่าน Pub/Sub (streaming) และ batch ingestion ผ่าน Dataflow ทำ ETL/ELT เก็บข้อมูลดิบใน Cloud Storage (data lake) และข้อมูลที่พร้อมวิเคราะห์ใน BigQuery (warehouse) ทำ orchestration ด้วย Cloud Composer ต่อ BI ด้วย Looker และทำ ML ด้วย BigQuery ML หรือ Vertex AI จุดขายคือ serverless ทำให้ไม่ต้องดูแล cluster และ scale ตามข้อมูลอัตโนมัติ

Pattern C — Microservices บน Kubernetes:

แตกแอปเป็น microservices รันบน GKE (autopilot ถ้าอยากให้ Google จัดการ node) ใช้ horizontal pod autoscaling, internal load balancing ระหว่าง service, Artifact Registry เก็บ image, Cloud Build และ Cloud Deploy ทำ CI/CD จัดการ secret ด้วย Secret Manager จุดขายคือความยืดหยุ่นในการ deploy และ scale แต่ละ service อิสระ ข้อแลกเปลี่ยนคือความซับซ้อนในการดูแลสูงกว่า ต้องมีทีมที่พร้อม

Pattern D — Hybrid / multicloud:

เชื่อม on-premises กับ GCP ผ่าน Cloud Interconnect หรือ Cloud VPN ใช้ GKE Enterprise หรือ Anthos บริหาร workload ข้ามสภาพแวดล้อมจากที่เดียว เหมาะลูกค้าที่ย้ายทุกอย่างทันทีไม่ได้ หรือมีข้อจำกัด compliance ให้บางส่วนต้องอยู่ on-prem จุดขายคือไม่ต้อง all-in ทันทีและลด vendor lock-in

Pattern E — Serverless event-driven:

event เข้ามา trigger Cloud Functions หรือ Cloud Run ประมวลผลแล้วเขียนผลลง Firestore หรือ BigQuery ใช้ Pub/Sub เป็นกระดูกสันหลังเชื่อม component จุดขายคือจ่ายตามใช้จริง scale ลงถึงศูนย์ เหมาะ workload ที่มาเป็นช่วง ๆ

• ออกแบบเพื่อความล้มเหลว (design for failure): สมมติทุกอย่างพังได้ จึงต้องมี redundancy และ failover ไม่มี single point of failure
• Stateless ดีกว่า stateful สำหรับ compute: ทำให้ scale แนวนอนง่าย เก็บ state ไว้ที่ data layer หรือ cache
• Loose coupling: ใช้ messaging และ API คั่นระหว่าง component เพื่อให้แก้หรือ scale แยกส่วนได้
• Managed service first: เลือก managed service ก่อน self-managed เพื่อลดภาระดูแล นอกจากมีเหตุผลชัดที่ต้องคุมเอง
• Right-sizing และ autoscaling: อย่า over-provision เริ่มพอดีแล้วให้ scale อัตโนมัติ
• Multi-zone เป็นพื้นฐานของ HA, multi-region เป็นพื้นฐานของ DR และ global latency
• Security และ observability เป็นส่วนหนึ่งของการออกแบบตั้งแต่ต้น ไม่ใช่ของแถม
• Infrastructure as code: ออกแบบให้ provision ซ้ำได้ด้วยโค้ดเพื่อความสม่ำเสมอ

สิ่งที่แยกคำตอบระดับสูงคือการเล่า trade-off ตัวอย่างคู่ที่ต้องเทียบได้:

• Cloud Run กับ GKE: Cloud Run ง่ายและ serverless เหมาะทีมเล็กและ workload ไม่ซับซ้อน; GKE ยืดหยุ่นและคุมได้ละเอียดเหมาะระบบใหญ่ที่มีทีม platform แต่ภาระดูแลสูงกว่า
• Cloud SQL กับ Spanner: Cloud SQL ถูกกว่าและคุ้นเคยเหมาะ regional; Spanner แพงกว่าแต่ได้ global scale และ strong consistency
• Multi-region กับ single-region: multi-region ให้ availability และ latency ดีกว่าแต่ต้นทุนและความซับซ้อนสูงกว่า เลือกตาม SLA และงบจริง
• Managed service กับ self-managed: managed ลดภาระแต่ยืดหยุ่นน้อยและอาจ lock-in มากกว่า
• Monolith กับ microservices: microservices ยืดหยุ่นและ scale แยกส่วนได้แต่ซับซ้อนกว่ามาก อย่าแนะนำ microservices กับทุกคน ถ้าทีมเล็กหรือระบบยังไม่ใหญ่ monolith ที่ดีอาจเหมาะกว่า

การพูด trade-off แสดงว่าเราเข้าใจว่าทุกการตัดสินใจมีต้นทุน ซึ่งคือวุฒิภาวะที่ผู้สัมภาษณ์มองหา

โจทย์: "ลูกค้าค้าปลีกมีเว็บ e-commerce รันบน on-premises เจอปัญหาเว็บล่มช่วงแคมเปญลดราคาใหญ่ และอยากเริ่มทำ analytics พฤติกรรมลูกค้า จะออกแบบบน GCP อย่างไร"

ขั้นเก็บ requirement (ถามก่อน): traffic พีคช่วงแคมเปญสูงกว่าปกติกี่เท่า; downtime ที่ธุรกิจทนได้คือเท่าไหร่ (RTO/RPO); ฐานข้อมูลเดิมเป็นอะไรขนาดเท่าไหร่; ผู้ใช้กระจุกในประเทศหรือหลายภูมิภาค; มีข้อมูลบัตรเครดิตที่ต้อง compliance ไหม; ทีมมีทักษะ Kubernetes ไหม; งบและ timeline

สมมติคำตอบ: พีคสูงกว่าปกติสิบเท่าเฉพาะช่วงสั้น ๆ, RTO หนึ่งชั่วโมง RPO ห้านาที, ฐานข้อมูล relational ขนาดกลาง, ผู้ใช้ส่วนใหญ่ในประเทศ, มีข้อมูลการชำระเงินต้อง compliance, ทีมยังไม่ถนัด Kubernetes, งบจำกัด

การออกแบบที่เสนอ: เนื่องจากพีคกระชากสูงเป็นช่วง ๆ และทีมไม่ถนัด Kubernetes จึงเลือก Cloud Run สำหรับชั้น application เพราะ autoscale ตาม traffic และ scale ลงเมื่อหมดแคมเปญ จ่ายตามใช้จริงคุมงบได้ ด้านหน้าใช้ Cloud Load Balancing กับ Cloud CDN cache หน้าสินค้าเพื่อลดภาระ backend และ Cloud Armor กันโจมตีและกรอง traffic ฐานข้อมูลใช้ Cloud SQL พร้อม read replica เพื่อรับโหลดอ่านช่วงพีค และตั้ง automated backup กับ cross-region replica ให้ตรง RPO ห้านาทีและ RTO หนึ่งชั่วโมง รูปภาพสินค้าและ static asset ย้ายไป Cloud Storage ข้อมูลการชำระเงินแยก subnet ปิด public access ใช้ encryption และ IAM เข้ม จัดการ compliance ด้วย VPC Service Controls และ audit logging สำหรับ analytics ส่ง event พฤติกรรมผู้ใช้ผ่าน Pub/Sub และ Dataflow เข้า BigQuery แล้วทำ dashboard ด้วย Looker Studio โดยไม่กระทบระบบ transaction หลัก ทั้งหมด monitor ด้วย Cloud Observability

การเล่า trade-off: เลือก Cloud Run แทน GKE เพราะทีมยังไม่พร้อมดูแล Kubernetes และ workload ยังไม่ซับซ้อนพอจะคุ้มความยุ่งยาก; เลือก Cloud SQL แทน Spanner เพราะผู้ใช้กระจุกในประเทศและงบจำกัด ยังไม่จำเป็นต้อง global scale; แยก analytics ออกจาก transaction เพื่อไม่ให้ query หนักทำให้ระบบขายช้า

ปิดด้วย business value: ระบบไม่ล่มช่วงแคมเปญอีกต่อไปเพราะ autoscaling, จ่ายเท่าที่ใช้จึงคุมต้นทุน, ปลอดภัยตาม compliance, และได้ analytics พฤติกรรมลูกค้าที่ช่วยวางแผนแคมเปญถัดไป

ถาม: "ออกแบบระบบรองรับผู้ใช้ทั่วโลกหลายล้านคน" ตอบ: เริ่มถาม requirement, แล้วเสนอ global load balancing + CDN + compute ที่ autoscale + Spanner สำหรับ global data + multi-region + caching พร้อม trade-off เรื่องต้นทุน

ถาม: "ระบบควรใช้ multi-region เมื่อไหร่" ตอบ: เมื่อ SLA และ RTO/RPO เข้มจนต้องทน region ล่ม หรือผู้ใช้กระจายหลายภูมิภาคจนต้องลด latency โดยต้องชั่งกับต้นทุนที่สูงขึ้น

ถาม: "จะกำจัด single point of failure อย่างไร" ตอบ: redundancy หลาย zone, load balancer, database replica, stateless compute, health check และ automated failover

ถาม: "ลูกค้าอยากได้ microservices ทั้งหมดเลย ควรแนะนำอย่างไร" ตอบ: ถามว่าทีมพร้อมไหมและระบบจำเป็นแค่ไหน ถ้ายังไม่พร้อมอาจเริ่มจาก modular monolith หรือแตกเฉพาะส่วนที่ได้ประโยชน์ก่อน อย่าแนะนำ microservices เพราะเป็นเทรนด์

รีบเสนอ service ทันทีโดยไม่ถาม requirement; เสนอสถาปัตยกรรมที่ over-engineer เกินความจำเป็นและงบของลูกค้า; ไม่เล่า trade-off ทำให้ดูเหมือนท่องคำตอบ; ลืม security และ observability; แนะนำ microservices หรือ multi-region กับทุกโจทย์โดยไม่ดูบริบท; ออกแบบโดยไม่คิดว่าทีมลูกค้าจะดูแลไหวไหม; ลืมโยงกลับไปที่คุณค่าทางธุรกิจ ทำให้ฟังดูเป็นเทคนิคล้วน

การออกแบบสถาปัตยกรรมคือหัวใจของ DCE ใช้กรอบ Architecture Framework ห้าเสาที่ต้องชั่งน้ำหนักให้เหมาะกับบริบทลูกค้า ทำตาม playbook เจ็ดขั้นโดยเริ่มจากถาม requirement เสมอ มี reference pattern ในหัวห้าแบบไว้ปรับใช้ เล่า trade-off ให้คมเพราะนั่นคือสิ่งที่แยกคำตอบระดับสูง อย่า over-engineer และอย่าลืมว่าทีมลูกค้าต้องดูแลไหว ปิดทุกการออกแบบด้วยคุณค่าทางธุรกิจเสมอ เพราะ technical win เกิดเมื่อลูกค้าเห็นว่าโซลูชันแก้ปัญหาธุรกิจของเขาได้จริง