ในยุคที่ “Cloud First” กลายเป็นมาตรฐานไปแล้ว หลายคนคุ้นชินกับความสะดวกสบายที่กดเพียงไม่กี่คลิกก็ได้ Database หรือ Kubernetes Cluster มาใช้งาน แต่ในความเป็นจริง หลายองค์กรยังจำเป็นต้องรักษา On-Premise Data Center ไว้ ด้วยเหตุผลด้าน Security, Compliance หรือ Cost Management  โจทย์ที่ท้าทายทีม Platform Infrastructure ของเราคือ: “ทำอย่างไรให้ Hardware เดิมที่มีอยู่ (VMware vSphere & Enterprise Storage) มอบประสบการณ์ (Developer Experience) ที่รวดเร็ว อัตโนมัติ และยืดหยุ่น ได้เหมือนกับการใช้งาน AWS หรือ Google Cloud?” Tweet บทความนี้จะพาไปเปิดเบื้องหลัง Tech Stack และ Design Choices ที่เราเลือกใช้เพื่อเปลี่ยน “Hardware” ให้กลายเป็น “Internal Developer Platform (IDP)” เพื่อให้เห็นภาพการทำงานที่สอดคล้องกัน เราได้แบ่งสถาปัตยกรรมของระบบออกเป็นส่วนสำคัญต่างๆ ดังนี้ครับ   1. The Foundation: Infrastructure as Code (IaC) จุดเริ่มต้นของการทำ Platform คือต้องเลิกทำ Manual Operation ให้ได้มากที่สุด เราเปลี่ยนทุกอย่างให้เป็น Code เพื่อความแม่นยำและ… Continue reading Unlock Cloud Experience on On-Premise: เสก Data Center เดิมให้กลายเป็น Internal Developer Platform แบบ Cloud-Ready

ยุคนี้ใคร ๆ ก็ใช้คลาวด์หลายเจ้า แล้วการจัดการไฟล์จะยุ่งไหม? ทุกวันนี้องค์กรส่วนใหญ่ใช้คลาวด์กันแบบจัดเต็ม AWS, Google Cloud, Azure ไหนจะระบบในองค์กร (On-premises) อีก…

บทความนี้ เราจะโฟกัสที่ขั้นตอนหลังจากที่เราได้ติดตั้งและเซ็ตอัป ELK Stack ให้รันได้เรียบร้อยแล้ว โดยประเด็นสำคัญคือการบริหารจัดการและปรับขนาด (Sizing) ของระบบ เพื่อรองรับปริมาณ Log ที่เพิ่มมากขึ้นอย่างต่อเนื่อง พร้อมทั้งรักษาประสิทธิภาพของทั้งกระบวนการเขียน (Write) และอ่านข้อมูล (Read) ให้ทำงานได้อย่างราบรื่น โดยการติดตั้ง ELK Stack ซึ่งในครั้งนี้ผมจะอ้างอิงตามมาตรฐานการใช้งานทั่วไปตามภาพครับ อย่างแรก เราต้องประเมินปริมาณของ Log (Log volume) ที่จะเกิดขึ้นในแต่ละวันได้คร่าว ๆ ก่อน ว่าจะมีประมาณเท่าไหร่ เพื่อใช้เป็นข้อมูลในการทำ Sizing ของระบบได้ถูกต้อง จากนั้น มาพิจารณาประเด็นหลัก ๆ ที่เราต้องคำนึงถึง ได้แก่   1.Sharding การทำ Sharding ใน Index Pattern ของเเต่ละ Index Type เพื่อกระจายการทำงานไปหาในเเต่ละ Node แบ่งการทำงานให้เท่าๆกัน ไม่ไปหนักที่ Node ใด Node หนึ่ง และ  Scale จำนวนเครื่อง Data Node แบบ Scale Out โดยการ Set จำนวน Shard ในเเต่ละ Index Template นั้น เราต้องประเมินว่า Log Size ในเเต่ละวันมีประมานเท่าไหร่ เพราะ Shard เล็ก หรือ ใหญ่เกินไปจะไม่ดีต่อ Performance ของ Elasticsear… Continue reading เจ็บมาเยอะกับ ELK Stack ที่ Scale ไม่รอด? นี่คือวิธี Sizing และ Scale ที่ได้ผลจริง

ในยุคที่ระบบขององค์กรย้ายขึ้นคลาวด์กันแทบทั้งหมด การเก็บไฟล์เอกสารสำคัญขององค์กร ไม่ว่าจะเป็น Word, PDF หรือไฟล์อื่น ๆ ไว้กับผู้ให้บริการคลาวด์เพียงรายเดียว ณ วันนี้อาจจะไม่ใช่คำตอบที่ดีนัก เพราะนั่นหมายถึง “ความเสี่ยง” ทั้งหมด ก็จะถูกรวมอยู่ที่จุดเดียวเช่นกัน   ดังนั้น เพื่อไม่ให้ความเสี่ยงทั้งหมดไปกองอยู่ที่คลาวด์เดียว เราอาจจะต้องกระจายไฟล์เอกสารสำคัญไปยังผู้ให้บริการคลาวด์รายอื่นด้วย เพื่อให้สามารถทำ Disaster Recovery (DR) ได้เมื่อเกิดเหตุไม่คาดคิด   แต่!!! ทันทีที่คุณเริ่มมองหาระบบจัดเก็บไฟล์ที่รองรับทั้ง Multi-Cloud, Hybrid Cloud หรือแม้แต่ On-Premise คุณจะเจอปัญหาว่า แต่ละผู้ให้บริการมี API ไม่เหมือนกันแทน  ไม่ว่าจะเป็น AWS S3, Azure Blob, Google Cloud Storage หรือค่ายอื่น ๆ ซึ่งนั่นหมายความว่าคุณต้องมานั่งแก้โค้ดกันจนน่าปวดหัว และแน่นอน… มันคือวงจรที่ดูเหมือนจะไม่มีวันจบสิ้น   ถ้าคุณไม่อยากให้ชีวิตของ Dev หรือ Ops ต้องมานั่งแก้โค้ดและ Deploy ซ้ำๆ ทุกครั้งที่เปลี่ยนระบบจัดเก็บไฟล์ เพื่อซัพพอร์ต API ใหม่ ๆ ตลอดเวลา   “MinIO คือคำตอบที่คุณกำลังตามหา”   เพราะ MinIO ถูกออกแบบ… Continue reading อยากเก็บไฟล์สำคัญไว้ทุกที่? ให้ MinIO ช่วยซิงค์และลดความเสี่ยงได้!

  เราจะมาเล่าถึง Solution ที่ SCB TechX เรื่องการ Monitor Backup ใน Multi-Cloud Environment ที่มีความซับซ้อนด้วยการใช้ Script Exporter เนื่องจากแต่ละ Cloud Provider มีบริการ Backup เแยกเป็นของตัวเอง ทำให้การติดตามสถานะ Backup แบบ Centralized เป็นเรื่องที่มีความ challenge เพื่อให้เข้าใจง่าย เราจะเล่าเรื่องโดยใช้ STAR methodology ครอบคลุม Situation, Task, Action และ Result 1. SituationSCB TechX มีการจัดการ Workload อยู่บนสภาพแวดล้อม Multi-Cloud ซึ่งทำให้การ Monitor งาน Backup ในแต่ละ Cloud เป็นเรื่องยาก เพราะแต่ละ Cloud มีบริการ Backup ของตัวเอง เราจึงต้องการโซลูชันแบบ ศูนย์กลางเดียว (unified centralized solution) ที่สามารถ Monitor และตรวจจับการแจ้งเตือนข้าม Multi-Cloud ได้ 2. Task สร้าง Solution ที่มีความ Automate และยืดหยุ่น สำหรับ Monitor Backup ใน Multi-Cloud Environment แสดงสถานะ Backup ผ่าน Grafana dashboards เชื่อมต่อระบบแจ้งเตือนเข้ากับ PagerDuty 3. Action ได้พัฒนา Flow การ Monitor แบบ Cetralized โดยใช้ Script Exporter ทำการรัน Python Script เพื่อเรียก API ของ AWS Boto3 / Azure … Continue reading เมื่อ Metric มันขัดใจ… ก็ต้องจัดให้ตรงใจด้วย Script Exporter

คุณเคยเหนื่อยกับการจัดการ Kubernetes Cluster เองไหม? Node Up, Node Down, Load Balancer ปวดหัวสุดๆ! ตอนนี้ AWS มีตัวช่วยสุดเจ๋งชื่อ EKS Auto Mode – ปล่อยให้ AWS เป็น Ops ของคุณ ทำงานแทนทุกอย่าง แล้วคุณแค่โฟกัสไปที่โค้ดและไอเดียของคุณ Cluster ทำงานเอง เรานั่งชิล EKS Auto Mode ช่วยให้คุณ ไม่ต้องมานั่งปรับ Node หรือคิดว่าจะ Scale ยังไง เพราะ AWS จะจัดการทุกอย่างให้เองคุณแค่ Deploy แอป แล้วนั่งชิล ๆ รอ AWS จัดการให้ NodePool Auto – ง่ายกว่าที่คิด ด้วย EKS Auto Mode คุณสามารถสร้าง NodePools และ NodeClasses แบบปรับแต่งเอง หรือใช้ Default NodePools ก็ได้ ระบบจะคำนวณ resource ให้เหมาะสมโดยอัตโนมัติ พร้อมกับ: Compute อัตโนมัติ – Node เลือก AMI ที่เหมาะสม, เปิด GPU Support, ปิด SSH/SSM Auto Scaling – ใช้ Karpenter ตรวจจับ Pods ที่ไม่สามารถ Schedule และเพิ่ม Node ใหม่อัตโนมัติ Load Balancing อัตโนมัติ – Integration กับ AWS Elastic Load Balancing จัดการ Application & Network LB แบบ Production-ready Storage อัตโนมัติ – ตั้งค่า Ephemeral Storage, Volume Size, Encryption, และ Deletion Policy ให้ … Continue reading EKS Auto Mode: ให้ AWS เป็น Ops ของคุณ

คุณควรรู้จักกับ LocalStack — เครื่องมือที่ช่วยให้เราสามารถจำลอง AWS มารันบนเครื่องตัวเองได้เหมือนมี AWS เวอร์ชันส่วนตัวเลยทีเดียว…

ในยุคที่เทคโนโลยีคลาวด์และการพัฒนาแอปพลิเคชันมีการเปลี่ยนแปลงอย่างรวดเร็ว การจัดการ Infrastructure เป็นสิ่งสำคัญอย่างยิ่ง และ Opentofu คือหนึ่งในเครื่องมือที่ตอบโจทย์การจัดการนี้ได้อย่างมีประสิทธิภาพ