ONEWEB เป็นแพลตฟอร์มการพัฒนาแอพพลิเคชันที่สร้างขึ้นจากเทคโนโลยี Java EE และรองรับสถาปัตยกรรม 3 ระดับซึ่งประกอบด้วย Web Tier, Application Tier และ Database Tier เทคโนโลยีนี้ ได้รับการพัฒนาให้เป็นแอพพลิเคชันระดับองค์กรที่จะช่วยให้คุณสามารถขยายขีดความสามารถ เพื่อรองรับการเติบโตของธุรกิจของคุณ

ONEWEB ยังรองรับสถาปัตยกรรมคอนเทนเนอร์สำหรับการปรับใช้บนคลาวด์ มีตัวเลือกมากมายให้ผู้ใช้เลือกสถาปัตยกรรม ONEWEB ขึ้นอยู่กับความต้องการทางธุรกิจของคุณ สถาปัตยกรรมมาตรฐานของ ONEWEB ที่ต้องการมีดังนี้

• สถาปัตยกรรมอิสระ (Standalone Architecture)

• สถาปัตยกรรมความพร้อมใช้งานสูง (High Availability Architecture)

• สถาปัตยกรรมคลาวด์ (Cloud Architecture)

คุณต้องพิจารณาประเภทของ environment ที่คุณต้องมีเมื่อต้องการพัฒนาแอพพลิเคชันอันดับแรก คุณสามารถพัฒนาแอพพลิเคชันของคุณบนเครื่องของลูกค้าได้ เมื่อคุณทำงานเสร็จแล้ว จะต้องมีการทดสอบ เพื่อสิ่งนั้น คุณควรมี environment ในการทดสอบ หากแอพพลิเคชันของคุณทำงานได้ดีใน environment ของการทดสอบ และคุณมีความมั่นใจที่จะเผยแพร่ คุณต้องโปรโมตแอพพลิเคชันของคุณใน environment production หากคุณต้องการให้ธุรกิจมีความต่อเนื่อง คุณอาจต้องใช้ Disaster Recovery เป็นแผนสำรองในกรณีที่ environment production ของคุณประสบปัญหาบางอย่าง นี่เป็นสถานการณ์ที่พบบ่อยที่สุดในการพัฒนาแอพพลิเคชัน

Production Environment

ประเภทการใช้งาน (Type of your Application) เป็นแอพพลิเคชันแบบเรียลไทม์หรือไม่ มีการรวมเข้ากับระบบอื่นหรือไม่ ต้องประมวลผลข้อมูลจำนวนเท่าใด มันทำงาน 24 ชั่วโมงต่อวันหรือไม่

ประเภทของธุรกิจ (Type of your Business) ธุรกิจของคุณมีความสำคัญแค่ไหน ใครจะได้รับผลกระทบหากแอพพลิเคชันนี้ล่ม จำนวนของผู้ใช้ (Active user and Name user)

จำนวนผู้ใช้ (ผู้ที่ใช้งานอยู่และผู้ใช้ชื่อ)

จำนวนธุรกรรม (Number of Transactions) จำนวนธุรกรรมภายในระยะเวลาหนึ่ง เช่น จำนวนธุรกรรมในหนึ่งเดือน

ยอมรับการหยุดทำงาน (Accepted downtime) จำนวนเวลาหยุดทำงานในหนึ่งปี และเวลาที่หยุดทำงานที่ยอมรับแต่ละครั้งนานเท่าใด

Disaster Recovery Environment

Disaster Recovery Environment เป็นสิ่งแวดล้อมสำรองสำหรับ environment production ของคุณและไม่สามารถดำเนินการได้เป็นระยะเวลานาน ในการออกแบบ Disaster Recovery Environment คุณต้องพิจารณาประเด็นต่อไปนี้

• RPO (Recovery Point Objective) จำนวนข้อมูลของคุณจะหายไป เมื่อคุณตัดสินใจเปิด Disaster Recovery Environment

• RTO (Recovery Time Objective) ใช้เวลานานเท่าใดเมื่อคุณตัดสินใจเปิด Disaster Recovery Environment

• คุณคาดว่าจะใช้กำลังการผลิต production environment กี่เปอร์เซ็นต์ใน environment การกู้คืนจาก Disaster Recovery Environment

Testing Environment

การทดสอบ environment ใช้สำหรับทดสอบแอพพลิเคชันในการออกแบบการทดสอบ environment คุณต้องพิจารณาประเด็นต่อไปนี้

• มีผู้ทดสอบหรือผู้ที่เกี่ยวข้องกี่คน ที่คุณวางแผนที่จะใช้ในการทดสอบ environment

• คุณต้องรวมเข้ากับระบบกี่ระบบ?

• คุณวางแผนที่จะใช้ข้อมูลเท่าใด ในกระบวนการทดสอบ

High Availability Architecture จะต้องได้รับการพิจารณาสำหรับระบบที่วิกฤตร้ายแรง ซึ่งสามารถทนต่อความล้มเหลวและข้อผิดพลาดจำนวนหนึ่งก่อนที่จะทำงานไม่ถูกต้องอีกต่อไป การออกแบบสถาปัตยกรรมนี้มาจากมาตรฐานหลักของความสามารถของบริการของคุณเพื่อให้เป็นไปตามข้อตกลงระดับการให้บริการ (SLA) ที่คาดไว้

ประเด็นสำคัญในการออกแบบ High Availability Architecture มีดังนี้

หลีกเลี่ยงความล้มเหลวเพียงจุดเดียว (Avoid single points of failure)

1. ความซ้ำซ้อนของฮาร์ดแวร์ (Hardware redundancy) กำจัดจุดล้มเหลวเพียงจุดเดียวในระบบโดยรวมความซ้ำซ้อนของฮาร์ดแวร์ มีเทคนิคมากมายในการออกแบบความซ้ำซ้อนของฮาร์ดแวร์ ใช้มาตราส่วนแนวนอนเพื่อกระจายเซิร์ฟเวอร์แอพพลิเคชันไปยังเครื่องจริงหลายเครื่อง (Active-Active) - เซิร์ฟเวอร์สำรองข้อมูลผู้ใช้ (Active-Standby)

2. ความซ้ำซ้อนของกระบวนการ (Process redundancy) จัดให้มีความซ้ำซ้อนของกระบวนการและการแยกส่วนเพื่อให้เซิร์ฟเวอร์ที่ล้มเหลวไม่ส่งผลกระทบต่อเซิร์ฟเวอร์ที่ใช้งานได้ดีที่เหลืออยู่

โหลดบาลานซ์ (Active-Active) ใช้เทคนิค Load balancing เพื่อให้แน่ใจว่าเซิร์ฟเวอร์แต่ละเครื่องไม่ถูกร้องขอจากไคลเอนต์มากเกินไปในขณะที่เซิร์ฟเวอร์อื่นไม่ได้ใช้งาน

การสนับสนุนเมื่อเกิดข้อผิดพลาด (Active-Standby) สภาพแวดล้อมต้องสามารถประมวลผลคำขอของไคลเอ็นต์ต่อไปได้ แม้ว่าคอมโพเนนต์อย่างน้อยหนึ่งรายการจะออฟไลน์อยู่ก็ตาม

Standalone Architecture เรียบง่าย บำรุงรักษาง่าย และประหยัดงบประมาณมากที่สุด สถาปัตยกรรมนี้เหมาะสำหรับระบบที่มีความสำคัญน้อยซึ่งสามารถยอมรับการหยุดทำงานบางส่วนเพื่อกู้คืนหรืออัปเกรดระบบ สถาปัตยกรรมนี้มีส่วนประกอบ 3 ระดับซึ่งประกอบด้วย Web Tier, Application Tier และ Database ดังแสดงในแผนภาพต่อไปนี้

Web tier ระดับนี้ใช้เพื่อรับคำขอจากไคลเอ็นต์หรือโหลดบาลานเซอร์ จากนั้นประมวลผลคำขอเนื้อหา Static content และส่งต่อคำขอตรรกะทางธุรกิจไปยังเซิร์ฟเวอร์แอพพลิเคชันในระดับแอพพลิเคชัน

Application tier ระดับนี้ใช้เพื่อประมวลผลคำร้องของไคลเอ็นต์ โดยใช้ Application Server Middleware

Database tier ระดับนี้สำหรับบันทึกข้อมูลลงในอุปกรณ์จัดเก็บข้อมูล

ไดอะแกรมสถาปัตยกรรมแบบสแตนด์อโลนด้านบนแสดงเป็นเซิร์ฟเวอร์สามอินสแตนซ์ ซึ่งเป็นข้อดีที่ดีที่สุดสำหรับสถาปัตยกรรม นอกจากนี้คุณยังสามารถใช้ Firewall หรือโครงสร้างพื้นฐานเครือข่ายเพื่อแยกส่วนประกอบแต่ละส่วนเพื่อป้องกันระบบและเพิ่มประสิทธิภาพ แต่ไม่จำเป็นต้องแยกแต่ละคอมโพเนนต์ (เว็บ แอพพลิเคชันและฐานข้อมูล) เนื่องจากคอมโพเนนต์เหล่านี้สามารถทำงานบนเซิร์ฟเวอร์เดียวกันได้ แต่ในกรณีนี้ เซิร์ฟเวอร์ควรมีความจุเพียงพอสำหรับคอมโพเนนต์ทั้งหมด คุณยังสามารถเลือกที่จะแยกเซิร์ฟเวอร์เหล่านี้ออกเป็นสองเซิร์ฟเวอร์ เซิร์ฟเวอร์หนึ่งสำหรับเว็บ ในขณะที่แอพพลิเคชันและฐานข้อมูลบนเซิร์ฟเวอร์ที่สอง การตัดสินใจนี้ขึ้นอยู่กับทรัพยากรและนโยบายความปลอดภัยของคุณอย่างแน่นอน

ONEWEB สามารถตั้งค่าเป็นการกำหนดค่า ที่แตกต่างกันตามความต้องการของลูกค้า ลูกค้าสามารถเลือกผลิตภัณฑ์ที่ต้องการรวมอยู่ในการสมัครสมาชิก

Cloud Architecture เป็นอีกวิธีหนึ่งในการโฮสต์แอพพลิเคชันของคุณ บนผู้ให้บริการระบบคลาวด์ สถาปัตยกรรมประเภทนี้มีประโยชน์มากมาย เช่น ต้นทุนการบำรุงรักษาเซิร์ฟเวอร์ที่ต่ำกว่า ต้นทุนการลงทุนด้านฮาร์ดแวร์ที่ต่ำกว่า เป็นต้น หากคุณกำลังมองหาระบบคลาวด์โซลูชั่นคลาวด์มีตัวเลือกมากมายเช่น PaaS (Platform as a Service), IaaS (Infrastructure as a Service), และ SaaS (Software as a Service) ONEWEB สามารถโฮสต์บนคลาวด์เป็นโซลูชัน PaaS หรือ SaaS ได้ตามความต้องการของลูกค้า

Monitoring in ONEWEB

ONEWEB ใช้ ELK stack สำหรับตรวจสอบโครงสร้างพื้นฐานของคลาวด์รวมถึง platform services.