สารบัญ6 หัวข้อหลัก
- 1.บทที่ 1 จาก Server และ Client สู่สถาปัตยกรรมบริการ
- 2.บทที่ 2 ฮาร์ดแวร์ ระบบปฏิบัติการ ตัวตน และพื้นที่จัดเก็บ
- 3.บทที่ 3 ความพร้อมใช้ สมรรถนะ และการสังเกตการณ์
- 4.บทที่ 4 การสำรอง กู้คืน เสริมความมั่นคง และบริหารวงจรชีวิต
- 5.บทที่ 5 ระบบคลาวด์ การย้ายบริการ และ FinOps
- 6.บทที่ 6 Server และ Cloud ในระบบนิเวศเทคโนโลยีดิจิทัล
บทที่ 1 จาก Server และ Client สู่สถาปัตยกรรมบริการ
Server หมายถึงฮาร์ดแวร์หรือกระบวนการซอฟต์แวร์ที่ให้ Service แก่ Client ผ่านช่องทางสื่อสาร ส่วน Client คือผู้เรียกใช้ความสามารถนั้น บทบาทจึงขึ้นกับความสัมพันธ์ ไม่ได้ติดอยู่กับเครื่องชนิดใดชนิดหนึ่ง Application server อาจเป็น Server เมื่อให้ API แก่ Browser แต่เป็น Client เมื่อเรียกฐานข้อมูล เครื่องเดียวกันยังอาจให้หลายบริการได้ ขณะที่บริการเดียวอาจกระจายอยู่หลายเครื่อง การวางระบบจึงต้องระบุบทบาท Interface และผู้ใช้บริการให้ชัดก่อนนับจำนวนอุปกรณ์ มิฉะนั้นจะมองข้าม Dependency ที่ซ่อนอยู่
Service คือความสามารถที่มีข้อตกลงการใช้งาน เช่น Web, File, DNS, Database หรือ Identity ส่วน Workload คือชุด Application, Data, Dependency และ Traffic ที่ใช้ทรัพยากรเพื่อสร้างผลลัพธ์หนึ่ง Host หมายถึงเครื่อง ระบบปฏิบัติการ หรือ Hypervisor ที่รองรับสิ่งซึ่งรันอยู่ Instance คือหน่วยที่กำลังรันของ VM, Container หรือ Process และ Node คือสมาชิกหนึ่งตัวใน Cluster คำเหล่านี้ไม่ควรถูกใช้แทนกัน เพราะการสำรอง Host ไม่ได้แปลว่า Workload พร้อมใช้ หากข้อมูล เส้นทางเครือข่าย หรือตัวตนยังมีจุดล้มเหลวเพียงจุดเดียว
Server แต่ละบทบาทมีภารกิจและความเสี่ยงต่างกัน Web server รับคำขอ HTTP และอาจดูแลเนื้อหาคงที่หรือ Reverse proxy Application server รันตรรกะธุรกิจ Database server ดูแล Transaction กับความคงทนของข้อมูล File server ให้บริการแฟ้ม Directory server ดูแลบัญชีและนโยบาย ส่วน DNS, DHCP, Mail, Proxy, Load balancer, Backup และ Monitoring ทำหน้าที่สนับสนุนเส้นทางบริการ การรวมบทบาทอาจประหยัดทรัพยากรในระบบเล็ก แต่เพิ่มขอบเขตความเสียหาย การแยกบทบาทจึงต้องพิจารณาภาระงาน ความสำคัญ การดูแล และต้นทุนร่วมกัน
สถาปัตยกรรมแบบสองชั้นให้ Client ติดต่อ Server หรือฐานข้อมูลโดยตรง จึงเริ่มต้นง่ายแต่เกิด Coupling และข้อจำกัดด้านสิทธิเมื่อระบบโต แบบสามชั้นแยก Presentation, Application และ Data ทำให้กำหนดนโยบายและขยายแต่ละชั้นได้ ส่วน N-tier เพิ่มบริการ Cache, Queue หรือ Integration ตามความจำเป็น Monolith รวมองค์ประกอบหลักไว้ในการ Deploy เดียวจึงเข้าใจและทำ Transaction ภายในง่าย ขณะที่ Microservices แยกบริการตาม Domain และ Deploy อิสระ แต่ต้องรับภาระ Distributed transaction, Observability และแพลตฟอร์มที่ซับซ้อนกว่า
บริการ Stateless ไม่เก็บสถานะระยะยาวที่จำเป็นต่อคำขอถัดไปไว้ใน Instance เดิม จึงกระจายงานและ Failover ได้ง่ายขึ้น แต่ State มิได้หายไป เพียงย้ายไปอยู่ฐานข้อมูล Cache หรือ Client บริการ Stateful ต้องออกแบบการทำสำเนา การแบ่งข้อมูล ความสอดคล้อง และการกู้คืนให้สัมพันธ์กับลักษณะข้อมูล การสื่อสารแบบ Synchronous เข้าใจง่ายแต่เสี่ยง Cascade timeout เมื่อปลายทางช้า ส่วน Queue หรือ Event ช่วยแยกเวลาและรองรับยอดพุ่ง แต่ต้องควบคุมข้อความซ้ำ ลำดับ การประมวลผลซ้ำได้อย่างปลอดภัย และ Dead-letter
Control plane เป็นส่วนกำหนด State, Policy และ Orchestration ขณะที่ Data plane เป็นส่วนรับส่งหรือประมวลข้อมูลจริงตามคำสั่ง การแยกนี้ช่วยเห็นว่าหน้าบริการยังตอบได้แต่ระบบบริหารอาจเสีย หรือกลับกัน Control plane ที่ถูกยึดอาจเปลี่ยนระบบจำนวนมากพร้อมกัน Endpoint เช่น IP กับ Port, URL, Socket หรือ API เป็นจุดสัมผัสของบริการ จึงควรมีเจ้าของ สัญญาการใช้ การยืนยันตัวตน การจำกัดอัตรา และการติดตาม ระบบที่ดีไม่ได้เริ่มจากซื้อ Server แต่เริ่มจากอธิบายเส้นทางผลลัพธ์และขอบเขตความเชื่อถือให้ตรวจได้
ชั้นของบริการคอมพิวเตอร์แม่ข่าย
- 1Client และช่องทางใช้งาน
- 2Web และ Application
- 3Data และบริการพื้นฐาน
- 4Host, Network และ Control plane
บทที่ 2 ฮาร์ดแวร์ ระบบปฏิบัติการ ตัวตน และพื้นที่จัดเก็บ
การเลือก Server hardware ต้องเริ่มจาก Workload, SLO, การเติบโต และ Failure domain ไม่ใช่เลือก Clock หรือ RAM สูงสุดเพียงค่าเดียว Tower เหมาะกับพื้นที่ขนาดเล็กและขยายตรงไปตรงมา Rack server จัดวางหนาแน่นในศูนย์ข้อมูล ส่วน Blade หรือ Modular ใช้ Chassis, Power และ Fabric ร่วมกันจึงประหยัดพื้นที่แต่เพิ่ม Shared dependency และ Lock-in CPU ต้องพิจารณาจำนวน Core, Memory channel, ISA, NUMA, Virtualization และผลต่อ License ขณะที่ Storage, NIC และ HBA ต้องสัมพันธ์กับรูปแบบ I/O ไม่ใช่พิจารณาความเร็วบนสเปกแยกส่วน
ECC memory ช่วยตรวจหรือแก้ความผิดพลาดบางรูปแบบเมื่อทั้ง Platform และ Module รองรับ แต่ไม่แทน High Availability หรือ Backup แหล่งจ่ายไฟและพัดลมแบบ Redundant ลดความเสี่ยงได้ต่อเมื่อเชื่อมกับ Feed, UPS, PDU และทางลมที่แยก Failure domain จริง Hot-swap หมายถึงเปลี่ยนส่วนที่ออกแบบรองรับขณะระบบทำงาน มิได้อนุญาตให้ถอดอุปกรณ์ใดก็ได้ ส่วน BMC หรือ Out-of-band management ให้ Console, Power และ Sensor จากระยะไกล จึงเป็นสิทธิสูงที่ต้องแยก Management network ใช้บัญชีเฉพาะ MFA การอัปเดต และการบันทึก
Linux และ Windows มีเครื่องมือกับค่าเริ่มต้นต่างกัน แต่หลักบริหารเหมือนกัน ได้แก่ Inventory, Approved image, Identity, Secure baseline, Patch, Configuration, Logging, Backup, Monitoring, Change และ Recovery บริการพื้นหลังควรมีเจ้าของ Dependency วิธีเริ่ม ระบบฟื้นตัว และบัญชีเฉพาะ การเข้าถึงระยะไกลต้องจำกัดแหล่ง ใช้กุญแจหรือใบรับรองและผ่าน Jump host ตามความเสี่ยง งานตามเวลาต้องไม่ฝังรหัสผ่านไว้ใน Script และต้องมีการแจ้งเมื่อทำงานล้ม การดูแลจึงเป็นวงจรต่อเนื่อง ไม่ใช่ตั้งค่าครั้งแรกแล้วปล่อยไว้
Identity ต้องแยกบัญชีบุคคล บัญชีท้องถิ่น Service account และ Managed identity ออกจากกัน Service account ไม่ใช่บัญชีที่เจ้าหน้าที่ใช้ร่วมกัน แต่เป็นตัวตนของ Service หรือ Task ซึ่งควรจำกัด Host, Logon และ Privilege พร้อมหมุน Credential ตามวงจร Secret เช่น Password, API key, Token, Private key และ Connection string ต้องไม่ถูก Hard-code, Commit หรือเขียนลง Log หากแพลตฟอร์มรองรับควรใช้ Vault, KMS หรือ Managed identity โดยกำหนด Policy, Audit, Rotation และ Recovery บัญชี Break-glass ต้องแยก เก็บปลอดภัย เฝ้าระวัง และทดสอบตาม Runbook
พื้นที่จัดเก็บต้องเลือกจากหน่วยข้อมูลและความหมายที่โปรแกรมต้องการ DAS ให้ Block แก่ Host โดยตรง NAS ให้ File ผ่าน SMB หรือ NFS ส่วน SAN ให้ Block ผ่านเครือข่ายจัดเก็บและต้องควบคุม Multipath, Zoning กับการประสาน File system Object storage เก็บ Object พร้อม Metadata ผ่าน API เหมาะกับการขยายและ Lifecycle แต่ไม่ใช่ POSIX file system หรือ Block โดยตรง Local NVMe มี Latency ต่ำแต่ผูกกับ Host ส่วน Software-defined storage กระจายข้อมูลหลาย Node แลกกับความซับซ้อนของ Network, Quorum และ Failure domain
RAID, Snapshot, Replication และ Backup แก้เหตุเสียหายคนละแบบ RAID กับ Replica เน้นความพร้อมใช้เมื่ออุปกรณ์หรือ Node ล้ม Snapshot ช่วยย้อนสถานะในระบบเดิมอย่างรวดเร็ว แต่ยังพึ่ง Storage และสิทธิบริหารชุดเดิม Replication อาจคัดลอกการลบ ความเสียหาย หรือ Ransomware ไปยังปลายทาง Backup จึงต้องแยกเวลา Failure domain และ Credential พร้อมพิสูจน์การ Restore Encryption ปกป้องข้อมูลเมื่อกุญแจมีวงจรที่เชื่อถือได้ ส่วน Thin provisioning, Deduplication และ Tiering ต้องติดตาม Capacity, Performance กับเวลาและค่าใช้จ่ายเรียกคืน ไม่ใช่เปิดแล้วถือว่าประหยัดเสมอ
| ชั้นโครงสร้าง | คำถามก่อนออกแบบ | ความเสี่ยงที่ต้องควบคุม |
|---|---|---|
| Compute และ Memory | Workload ใช้ Core, RAM, NUMA และ License อย่างไร | Saturation, Error และเพดานการขยาย |
| Power, Cooling และ BMC | มีทางสำรองและ Management network แยกจริงหรือไม่ | Shared failure และสิทธิบริหารระดับสูง |
| OS และ Service | Image, Baseline, Patch, Log และ Recovery ใครดูแล | Drift, บัญชีเกินสิทธิ และงานค้าง |
| Identity และ Secret | เป็นบัญชีคน Workload หรือฉุกเฉิน และหมุนอย่างไร | ใช้ร่วม ฝังรหัส และถอนสิทธิไม่ครบ |
| Storage และ Data protection | ต้องการ Block, File หรือ Object และยอมเสียข้อมูลเพียงใด | ข้อมูลสูญ ความเสียหายถูกทำซ้ำ และกู้คืนไม่ได้ |
เนื้อหาสรุปนี้จัดทำขึ้นเพื่อการศึกษาส่วนบุคคล ห้ามคัดลอก ทำซ้ำ หรือนำไปใช้เพื่อวัตถุประสงค์ทางการค้าโดยไม่ได้รับอนุญาต