คลังเก็บป้ายกำกับ: web application

การติดตั้ง Web Application บน Infrastructure แบบเปิด

หลายคนเขียน Web Application เป็น, หลายคนเขียนเกมแบบ Web Application ได้ และหลายคนก็เขียน Web Application ไว้ทำงานบน Facebook Platform ได้ แต่ก็ไม่น่าเชื่อว่ามีอยู่หลายคนที่กลับไม่รู้ว่าจะจัดวาง Infrastructure ให้กับ Web Application ของตนเองยังไงดี เพื่อให้ผู้ใช้งานจากทั่วทุกสารทิศในโลกกลม ๆ ใบนี้ เข้าถึง Web Application ที่ตัวเองสร้างขึ้นได้!!!

งั้นมาดูวิธีของผมกันดีกว่า เอาแบบจากประสบการณ์จริงกันไปเลย

  1. ต้องเลือกก่อนว่าจะเอา Web Application ของเราไปขับเคลื่อนที่ไหน อย่างกรณีของผม ผมใช้บริการ Cloud Computing ของ Amazon Web Services เป็นตัวจัดการเรื่องนี้ โดยเน้นใช้งานแต่บริการของ Amazon EC2 เพื่อเอามาทำเป็น Instance Server จำนวน 2 Instance ให้ Instance นึงไว้ขับเคลื่อน Application และอีก Instance นึงไว้ขับเคลื่อน Database โดยผมเลือกใช้งานโซนแคลิฟอร์เนียเหนือ และเลือกใช้ Image แบบ LAMP หมายเลข ami-1d6a3858 ซึ่งเป็น LAMPStack ที่มีระบบปฏิบัติการเป็น Ubuntu รุ่น 10.04 แบบ 32 bit สอดไส้ด้วย PHP รุ่น 5.3 มี Virtual Core 1 ECU และ RAM 1.7 GB (เล็กชิบเป๋ง)
  2. จากนั้นก็โยนโค้ดไว้ที่ Application Instance และโยนฐานข้อมูลไปไว้ที่ Database Instance โดยที่ Database Instance จะพิเศษหน่อย เพราะผมจะไม่ใช้เนื้อที่ของ Database Instance เพื่อเก็บฐานข้อมูล แต่จะใช้ Amazon Elastic Block Store ที่ผมผูกไว้กับ Database Instance เป็นตัวเก็บข้อมูลแทน
  3. พอได้ขุมพลังในการขับเคลื่อนและได้ทำการเชื่อมโยง Application Instance กับ Database Instance ผ่านการ Configure อะไรหลาย ๆ อย่างแล้ว ทีนี้ก็ต้องมาดูเรื่อง Domain บ้าง โดยผมได้จดโดเมนเอาไว้ก่อนเรียบร้อยแล้วที่ Go Daddy
  4. คราวนี้ก็ต้องเอา Domain ที่จดทะเบียนไว้ ไปผูกโยงเข้ากับ Application Instance ที่เตรียมเอาไว้ก่อนแล้ว โดยผมได้เลือกใช้บริการของ Dynamic DNS แบบ Custom DNS Package จากนั้นก็ Configure ไำอ้เจ้า CNAME กับ A-Records เพื่อเชื่อมโยงระหว่างชื่อ Domain กับเลข IP ของ Application Instance เข้าไว้ด้วยกัน
  5. และท้ายที่สุด ก็ต้องกลับไป Configure ที่ Go Daddy เพื่อบอกให้มันรู้ว่า ตกลง Domain ที่ผมจดทะเบียนไว้ มันเชื่อมโยงไปยัง Primary Name Server ใด ซึ่งในที่นี้ก็คือ Primary Name Server ของ Dynamic DNS นั่นเอง โดยผมใส่ลงไป 5 Name Server เลย ใช้มันให้คุ้ม ทำ Load Balancing แบบเว่อร์ ๆ เพราะผมเสียดายมาก เนื่องจาก Package ที่จ่ายตังค์ไป มันเปิดให้เรากำหนด DNS ได้ถึง 75+ Domain แต่ประทานโทษ ผมใช้มันสำหรับ Domain เดียว โคตรเสียดายตังค์เลย T-T

เมื่อเราทำมาถึงขั้นตอนนี้ ก็ถือว่าทุกอย่างเรียบร้อยหมดแล้ว คราวนี้เราก็จะสามารถลองใช้งาน Web Application ของเราได้ โดยการเปิด Web Browser แล้วพิมพ์ URL ของ Domain เราเข้าไป แล้วรอซักชั่วอึดใจมด จากนั้น Web Application ของเราก็จะปรากฎขึ้นมา … อย่างสวยงามเลยทีเดียวเชียว!!!

เอาเป็นว่าใครก็ตามที่ยังไม่รู้ ก็คงได้รู้แล้วเน้อะ อ้อ แล้วอีกอย่าง สิ่งที่ต้องรู้อีกอย่างหนึ่งก็คือ ไอ้ข้างบนที่ผมเล่ามา มันต้องเสียตังค์ด้วยอ่ะ T-T แพงซะด้วยสิ ดังนั้น ถ้าคิดจะขับเคลื่อน Web Application แล้วล่ะก็ อย่าลืมหาตังค์มาเลี้ยงมันด้วยเน้อ

สายลมหวนกลับ

ช่วงนี้ผมกำลังหา Mobile Application มาลงบน Samsung Galaxy Cooper ของผมครับ และผมก็พบกับปัญหาสองอย่างในระหว่างติดตั้งและใช้งาน Mobile Application

โดยปัญหาอย่างแรกคือปัญหาคลาสสิค นั่นก็คือ พื้นที่จัดเก็บของเครื่องไม่ค่อยจะพอ เพราะถึงแม้จะมี Mobile Application หลาย ๆ ตัว ที่อนุญาตให้เราย้ายไปติดตั้งที่ SD Card ได้ แต่นั่นก็ไม่ใช่ App ทุกตัวที่จะทำได้ แถมยิ่ง Mobile Application มีการปรับรุ่นให้ทันสมัยยิ่งขึ้น มันก็มีขนาดใหญ่โตยิ่งขึ้นไปอีก!!!

ส่วนปัญหาอย่างที่สองอ่ะเด็ดกว่า นั่นคือ ผู้ผลิต Mobile Application ไม่รู้จะรีบไปไหน (สงสัยจะกลัวตกเทรน) ก็เลยตั้งหน้าตั้งตาทำให้ App ของตัวเองทันสมัยกันใหญ่ ผลก็คือ มันใช้ไม่ได้ มันล่ม มันบังคับให้ปิดตัวเอง และก็ไม่อยากจะเชื่อว่าแม้แต่ Facebook for Android เองก็มีปัญหากับเขาเหมือนกัน (หลังจากปรับรุ่นแล้ว)

เมื่อเป็นแบบนี้ ผมก็เลยหันไปใช้บริการของ App นั้น ๆ ผ่านทางเว็บบราวเซอร์ในลักษณะ Web Application แทน!!!

มันทำให้ผมเห็นว่า รูปแบบของ Application จะเริ่มหันเหจากเดิม คือ …

Desktop Application -> Web Application -> Mobile Application

ไปเป็น …

Desktop Web Application -> Mobile Web Application -> Mobile Application

ส่วน Desktop Application ก็คงจะล้าสมัยไปตามระเบียบ เพราะสัดส่วนมันคงจะน้อยลงไปเรื่อย ๆ เนื่องจากตลาดผู้บริโภคหันไปจับกลุ่มที่ Tablet กับ Smart Phone แทน

ตอนนี้ผมเลยเริ่มเห็นแล้วว่า วิธีการควบคุมต้นทุนสำหรับการสร้าง Mobile Application (ที่น่าจะดี) ก็คือ การสร้างให้มันเป็น Mobile Web Application และละทิ้งการสร้าง Mobile Application ที่ยึดโยงต่อระบบปฏิบัติการใด ๆ (Android หรือ iOS หรือ webOS หรือ บลา ๆ ๆ) ซึ่งจะตอบโจทย์ในเรื่องของอรรถประโยชน์และต้นทุนการผลิตมากกว่า (สำหรับการทำเป็นงานอดิเรก)

ผมใช้อะไรทำเกม?

การทำเกม Facebook แบบ Web-based Application ต้องใช้เครื่องมือหลายอย่าง และแต่ล่ะอย่างก็มีผู้ใจบุญสุนทานจัดสร้างเอาไว้ให้ใช้ (ขอขอบคุณเป็นอย่างยิ่ง) ดังนั้น เพื่อเป็นการแบ่งปัน ผมจึงขออธิบายว่าผมใช้เครื่องมืออะไรบ้างในการพัฒนาเกม โดยมีรายละเอียดดังต่อไปนี้

Container

  1. EasyPHP เอาไว้ทดสอบโปรแกรม

Editor

  1. Notepad++ เอาไว้เขียนโปรแกรม
  2. Photoshop CS5 เอาไว้วาดรูป

Software Developerment Kits

  1. Facebook PHP SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย PHP
  2. Facebook Javascript SDK เอาไว้ต่อเชื่อมกับ Facebook ด้วย Javascript เพื่อเสริมลูกเล่นในการตอบโต้
  3. jQuery ใช้เพราะขี้เกียจมาทำ Javascript Framework เอง (โดยเฉพาะ AJAX นี่ ขี้เกียจทำเองมากกกกกกกกก)
  4. jQueryUI เอาไว้ทำพวก Dialog, Slide และ Tab

Manual (อันนี้สำคัญมาก ถ้าไม่มีนี่ ถึงขนาดหูหนวกตาบอดเลยทีเดียว)

  1. Tags HTML เอาไว้หารายละเอียดของ Tag HTML เพราะผมไม่เคยจำ
  2. Javascript ไอ้เจ้า Javascript ผมก็ไม่เคยจำ
  3. MySQL 5.1 ลำพังคำสั่ง SQL พื้น ๆ น่ะจำไม่ยากหรอก แต่ถ้าเป็นพวกคำสั่งเล็ก ๆ น้อย ๆ เนี่ย จำไม่ได้อ่ะ T-T
  4. CSS นี่ผมก็ไม่จำ เวลาจะใช้ก็ค้น ๆ เอา
  5. Facebook Graph API พอดีผมเริ่มมาทำ Facebook App ตอนที่ Facebook เปลี่ยน Core API มาเป็น Graph API พอดี ก็เลยไม่ต้องไปอ่านของเก่า ดีเหมือนกัน
  6. Facebook Javascript API จำไม่ได้อ่ะ ไม่เคยจำ อาศัยอ่าน ๆ แล้วทำตาม
  7. Regular Expression เอาไว้ค้นไวยากรณ์ประหลาด ๆ ที่ไม่ค่อยได้ใช้บ่อยนัก
  8. PHP ต้องใช้ เพราะไม่เคยจำคำสั่ง

ส่วนที่เหลือก็เป็นจินตนาการ ความคิดสร้างสรรค์ และก็ความอึด (เพราะต้องทำซ้ำเป็นร้อย ๆ ครั้ง เพื่อให้ได้ผลลัพธ์ที่ถูกต้องแม่นยำ ทำซ้ำได้ และเป็นวิทยาศาสตร์)

มารผจญ

หลังจากตั้งอกตั้งใจเจียดเวลาหลังเลิกงานมาเขียนเกมแบบ Web Application บน Facebook ทำให้ผมได้รู้เรื่องสำคัญอย่างหนึ่งว่า …

มารที่มารบกวนผม ทำให้ผมพัฒนาเกมฯที่ว่าไปไม่ถึงไหน ไม่ใช่กลไก Facebook, ไม่ใช่ jQuery และไม่ใช่ PHP หากแต่เป็น Web Browser!!!

มันเป็นเรื่องที่แย่มาก ที่ Web Browser ที่ใช้โดยคนส่วนน้อย ไม่ว่าจะเป็น Firefox, Chrome, Opera หรือ Safari ไม่เคยสร้างปัญหาจุกจิกให้กับผมเลย ในขณะที่ Internet Explorer ซึ่งเป็น Web Browser ที่ใช้โดยคนส่วนใหญ่ กลับสร้างปัญหาจุกจิกให้กับผมได้มากมายอย่างยิ่ง

ไอ้อะไรที่ทำบน IE ได้ จะทำบนตัวอื่น ๆ ไม่ได้ และไอ้อะไรที่ทำบนตัวอื่น ๆ ได้ กลับไม่สามารถทำบน IE ได้!!!

เคล็ดอย่างหนึ่งที่ผมพบก็คือ IE เป็น Art ตัวแม่!!! มันจะคอยจับผิดไอ้โน่นไอ้นี่อยู่ตลอดเวลา แต่ไม่เคยบอกเราจริง ๆ แม่น ๆ หรือตรง ๆ ตำแหน่ง ว่าไอ้ที่มันบอกว่าผิดอ่ะ มันตรงไหนกันแน่ บอกอ้อม ๆ อยู่นั่นแหล่ะ ที่สำคัญยังเถรตรงติงต๊องอีกต่างหาก ไอ้บางอย่างที่ Web Browser ตัวอื่นเขาหยวน ๆ มันก็ไม่หยวน

ส่วนไอ้บางอย่างที่ชาวบ้านเขาไม่หยวนแต่มันกลับหยวน!!!

T-T ผมเพิ่งจะได้เข้าใจอย่างลึกซึ้งก็ช่วงนี้นี่แหล่ะ ว่าความรู้สึกเสน่หาต่อ IE ของเหล่าคนไอทีไทยนั้นมันเป็นแบบนี้นี่เอง!

วิธีใช้ Amazon EC2 เพื่อประมวลผล Facebook Application

ผมเขียนภาพข้างล่างนี้ขึ้นมาอย่างพื้นฐานและง่ายที่สุด เพื่อแจกแจงว่า ถ้าหากเราต้องการใช้ Amazon EC2 เพื่อประมวลผล Facebook Application แล้วล่ะก็ มันจะมีรูปภาพออกมาเป็นยังไง?

อธิบายภาพข้างบนสั้น ๆ ได้ดังนี้

  1. คุณต้องติดตั้ง Facebook Canvas เป็น, เข้าใจใน Facebook Graph API และเข้าใจใน Facebook Client Libraries (ทั้งหมดฟรี)
  2. คุณต้องจดทะเบียน Domain (เสียตังค์) กับ Domain Registrar (Domain ที่ว่าก็คือ ไอ้พวก http://www.yourdomain.com อะไรเทือกนั้นแหล่ะ) เช่น Godaddy เป็นต้น
  3. คุณต้องจดทะเบียน DNS (เสียตังค์) กับ DNS Provider เพื่อที่คุณจะได้ผูก Domain ของคุณเข้ากับ Amazon EC2 ได้
  4. คุณต้องสมัครเพื่อใช้งาน Amazon EC2 (ไม่ต้องเสียตังค์) แล้วเข้าไปสร้าง Application + Db Instance (เสียตังค์ตามการใช้งาน) โดยสร้างขึ้นมาแค่ Instance เดียวก็พอ (ต่อไปถ้าคุณเก่ง คุณสามารถสร้างเยอะ ๆ ก็ได้นะเออ)
  5. คุณต้องสร้าง Elastic IP ขึ้นมา (เสียตังค์) เพื่อให้ Instance ของคุณ สามารถติดต่อกับโลกภายนอกได้ โดยสร้างแค่ IP เดียวก็พอ (ก็ใช้แค่ Instance เดียวไง ก็เลยใช้แค่ IP เดียวก็พอ)
  6. บังเอิญว่า Instance ใน Amazon EC2 เป็นพวกความจำสั้น ดังนั้น ถ้ามันโดน Restart หรือ Terminate เมื่อไหร่ล่ะก็ มันจะลืมทุกอย่างไปหมดเลย (รวมทั้ง Code และ DB ด้วย) ดังนั้น น่าจะเป็นการดี หากเราจะสร้าง Elastic Block Store ขึ้นมา (เสียตังค์) เพื่อเอามาเป็นที่พักข้อมูลจาก Instance เผื่อว่า Instance มันล่มหรืออะไรยังไง มันจะได้มีตัวสำรอง
  7. แต่ถ้าคุณคิดว่า Elastic Block Store จะไม่ชัวร์ กลัวว่าตัวมันเองก็อาจจะล่ม คุณก็สามารถจะติดตั้ง Snapshot To S3 (เสียตังค์) เพื่อให้มันทยอยโอนข้อมูลของคุณ ไปเก็บไว้ใน Bucket (เสียตังค์) ของ Amazon S3 ก็ได้ (คุณต้องสมัครเพื่อขอใช้ Amazon S3 อันนี้ฟรี ไม่เสียตังค์)

สรุปว่าจะประมวลผล Facebook Application บน Amazon EC2 ก็ต้องจ่ายพอตัวเหมือนกัน แต่ถ้าทำออกมาดี ๆ ก็น่่าจะคุ้มอ่ะนะ เพราะถ้าให้ไปประมวลผลบน Shared Hosting ก็คงไม่ได้ เพราะทรัพยากรจำกัดจำเขี่ยเหลือเกิน เกิดผีเข้าผีออก มีคนเข้า Facebook Application ของเราเยอะขึ้นมา ไปทำ Shared Hosting เขาล่ม เดี๋ยวเขาจะเฉดหัวออกมาแทบไม่ทัน

ส่วนจะไปประมวลผลบน Dedicated Server หรือ Virtual Private Server ก็ยุ่งยาก ต้องติดตั้งทุกอย่างเองทั้งหมด (Amazon EC2 มันเทพ สั่งสร้าง Instance โป้งเดียว มันติดตั้งระบบปฏิบัติการและปรับแต่งทุกอย่างให้หมดเลย)

ยิ่งเป็น Co-Location ก็ยิ่งแล้วใหญ่ เพราะเดี๋ยวนี้ฮาร์ดแวร์มันทันสมัยขึ้นแทบทุกวี่ทุกวัน จะให้เช่าซื้อ Server มาเป็นของตัวเองมันจะไม่คุ้ม แบบว่ายังไม่ทันไร Server ที่มีก็ตกยุคซะแล้ว หรือถ้าไม่ตกยุค แต่ต้องมาอัด RAM ทำ Server Farm เองก็หลังแอ่นเหมือนกัน