ผมยังไม่ได้ใช้ Amazon EC2 เป็นเรื่องเป็นราวเลย อาศัยว่าเก็บข้อมูลตรงโน้นตรงนี้ไปเรื่อย ๆ แล้วก็มาสะดุดอยู่เรื่องหนึ่ง ซึ่งตัวผมเองก็สงสัยมาตั้งนานแล้ว นั่นก็คือเรื่องของ Nameservers ซึ่งจะใช้ชี้หา Amazon EC2

สำหรับคนที่ทำเว็บไซต์ (คง) จะทราบว่า การที่เราจะผูก URL เข้ากับ Server นั้น เราจะเป็นจะต้องผูกเข้ากับ Primary Name Server และ Secondary Name Server ยกตัวอย่างเช่น ns1.yourdomain.com หรือ ns2.yourdomain.com

จากการเข้าไปอ่านในกระทู้ของคนที่พูดคุยเรื่อง Amazon EC2 ของสหรัฐก็เลยทำให้รู้มานิด ๆ ว่า เราสามารถจะจ่ายตังค์เพื่อเช่าใช้บริการ Global DNS Service จาก Nettica ได้ ซึ่งจะทำให้เราผูก URL สวย ๆ ของเรา เข้ากับ Instance บน Amazon EC2 ได้อย่างไม่ยากเย็นนัก!!!

คือให้ URL เราผูกเข้ากับ DNS ที่ Nettica, แล้วให้ Nettica ชี้มาที่ Instance บน Amazon EC2 อีกทอดหนึ่ง!!!

แล้วผมก็รู้แค่นั้น … แต่ก็ยังเก็บความข้องใจเอาไว้ เพราะสงสัยว่าปรกติมันมี Primary กับ Secondary นี่หว่า แล้ว Instance แต่ล่ะตัวของ Amazon EC2 ที่เปิดใช้ มันมีแค่ 1 Elastic IP Address เอง แล้วมันจะผูกเป็นทั้ง Primary และ Secondary ได้ยังไง???

ความโง่ไม่เคยปรานีใคร … เพราะในที่สุดผมก็เพิ่งจะได้รู้ว่า วิธีการที่ถูกต้องก็คือ ถ้าอยากจะตั้ง Web Server โดยการใช้ Amazon EC2 เราจำเป็นต้องเปิด 2 Instance เพื่อจะได้มี 2 Elastic IP Address โดยให้ตัวนึงเป็น Master และอีกตัวก็เป็น Slave จากนั้นถึงจะค่อยกำหนด Primary Name Server และ Secondary Name Server เพื่อผูกเข้ากับ 2 Elastic IP Address ดังกล่าว เป็นอันได้คำตอบ!!!

สรุปว่าต้องจ่าย 2 เด้ง ซึ่งขอบอกเลยว่า หลังจากดีดลูกคิดรางแก้วแล้วพบว่า … มันแพงกว่าการเช่าซื้อ Dedicated Server ตัวนึงซะอีก (อันนั้นจ่ายตังค์ยังได้ของ อันนี้จ่ายตังค์ได้แต่บริการ T-T)

ทีนี้ก็ต้องมานั่งทบทวนว่า จริง ๆ แล้วเราอยากได้ขุมพลังของ Amazon EC2 เพื่ออะไรกันแน่? ซึ่งถ้าึคิดได้ว่าเพราะปัญหาด้าน CPU ของ Shared Hosting ที่จำกัด คือมีการจำกัดไม่ให้ใช้เกิน 20% ติดต่อกัน 15 วินาที ทำให้ไม่สามารถใช้ Query ที่สลับซับซ้อนและหนักหน่วงได้ งั้นปัญหามันก็อยู่ที่การประมวลผลเพื่อสืบค้นข้อมูลสินะ???

ดังนั้น ข้อสรุปของการใช้ Amazon EC2 อย่างประหยัดเพื่อแก้ปัญหาในย่อหน้าบนก็คือ ควรจะเปิดเพียงแค่ 1 Instance โดยให้มี Web Server และ Database Server ทำงานอยู่บน Instance เดียวกัน และเปิดให้มีกลไก Web Service (ซึ่งเราต้องสร้างขึ้นเอง) ทำงานอยู่บน Instance ดังกล่าว เพื่อทำหน้าที่สืบค้นข้อมูลจากฐานข้อมูล โดยการดึงขุมพลังจาก Amazon EC2 เท่าที่มันจะทำได้

จากนั้นก็ให้ Front-end ของเรา ซึ่งทำงานอยู่บน Shared Hosting (ที่อื่น) เป็นด่านหน้าเพื่อติดต่อกับผู้ใช้ และช่วยสร้างคำขอเพื่อค้นข้อมูล โดยการส่งคำขอไปยัง Web Service ซึ่งทำงานบน Amazon EC2 ที่เราเปิด Instance ผ่าน Elastic IP Address (อันแสนจะขี้เหร่) อีกทอดหนึ่ง เป็นอันเสร็จกระบวนความ!!!

พอถึงตรงนี้ก็คิดว่าต้องมีค่าใช้จ่ายสองก้อน ก้อนหนึ่งจ่ายเพื่อ Shared Hosting รายปี กับอีกก้อนหนึ่งจ่ายเพื่อ Amazon EC2 สำหรับ 1 Instance แบบรายเดือน แต่คิด ๆ ดูแล้วก็น่าจะดีกว่าจ่ายเพื่อ 2 Instance แน่ ๆ (เพราะอันนั้นแพงกว่า)…

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

กับอีกประเด็นหนึ่งก็คือ Web Service เป็นสิ่งที่เราต้องสร้างขึ้นเอง และมันจะดีกว่าถ้าเราไม่ต้องสร้างจากฐานรากทั้งหมด เพราะมันเสียเวลา … ดังนั้นจะต้องใช้ตัวช่วย ซึ่งมันคงไม่มีอะไรดีกว่าการหา Web Service Framework ซักตัวนึงมาแบ่งเบาภาระ … ว่าแล้วก็หา (เอา PHP นะ) แล้วก็พบอยู่ตัวนึงนั่นก็คือ NuSOAP

หลังจากดู ๆ แล้วก็พบว่า … โอย งบชิบเป๋งเลย นี่แม้กระทั่งได้ Web Service Framework มาแล้ว ยังต้องเสียเวลามาทำความเข้าใจวิธีการใช้งานมันอีกเหรอเนี่ย T-T เศร้าจิต

[tags]Amazon EC2, Web Service, NuSOAP[/tags]

Related Posts

3 thoughts on “Amazon EC2 กับ Web Service

  1. ดูๆ แล้ว พวก cloud นี่ น่าจะเหมาะสำหรับใช้เป็น background/batch มากกว่าอะครับ (ตอนนี้นะ)

    ส่วนเรื่อง webservice นี่
    ถ้าพี่ไท้ไม่ได้ซีเรียสเรื่องมาตรฐานอะไร
    (รวมถึงจะใช้ php อย่างเดียว)
    ก็ใช้ serialize ใน php เลยครับ

    ทำ class สำหรับเก็บคำสั่ง+parameters ซักตัวนึง
    เสร็จแล้วก็ทำ serialize แล้วก็ยัดไปฝั่ง service เลยครับ

    เขียนเร็ว โค้ดเนียน รันไม่อืด และไม่ปวดหัว 😀

  2. ตอนแรกก็ใช้ nusoap แหละครับ ตอนหลังทนความช้าไม่ไหวเลยไม่เอาแล้วใช้
    ใช้แบบนี้แทนครับ
    สรุปคือ return เป็น xmlล้วนๆ ดีกว่า

    ฟาก client.php

    $base = ‘http://127.0.0.1/workspace/claimcenter/server.php’;

    $params = array(‘f’ => ‘chklogined’
    , ‘id’ => $id
    ,’password’ => $password
    ,’db1′ => $db1);

    $xml = simplexml_load_string(file_get_contents($base . ‘?’ . http_build_query($params)));

    foreach ($xml->rec as $rec) {
    if ($rec->user != ”) {
    $_SESSION[‘user’] = (string) $rec->user;
    header(“Location: search.php”);
    } else {
    header(“Location: login.html”);
    }
    }

    ฟาก server.php
    $funcname = isset($_GET[‘f’]) ? $_GET[‘f’] :’nocall’;
    $ret = call_user_func($funcname);
    echo $ret;

    function chklogined() {
    global $dbh;

    $id = $_GET[‘id’];
    $user = isallow($id);
    $password = $_GET[‘password’];
    $sql =’select ID from ‘.DB2.’.’.TABLE5.” where ID=$id and Password=password(‘$id$password’)”;
    $data = pxml();
    $data .= “\n”;
    $result = $dbh->query($sql);
    if ($result)
    foreach ($result as $row) {
    $data .= “\n”;
    $data .= ”.$user.”.”\n”;
    $data .= “\n”;
    }
    $data .= “\n”;
    return $data;
    }

  3. ดูเหมือนว่า “ความเร็ว” จะเป็นประเด็นใหญ่ที่คุณ AMp กับคุณ atip หยิบยกขึ้นมา ซึ่งจากการตรวจสอบโค้ดของ NuSOAP แล้วผมก็พบว่า … จริงว่ะ!!! เพราะบางครั้ง พอจะทำอะไรที่เป็นมาตรฐานมาก ๆ มันก็เลยกลายเป็นช้าไป T-T

    หรือสูงสุด ฤา จะคืนสู่สามัญอ่ะเนี่ย?

ใส่ความเห็น

อีเมลของคุณจะไม่แสดงให้คนอื่นเห็น ช่องข้อมูลจำเป็นถูกทำเครื่องหมาย *