Amazon AWS – 架構與服務

當我們在Amazon Cloud上註冊了一個免費帳號後，興高采烈的按一下左上方Services連結，會出現密密麻麻一堆令人眼花瞭亂的服務及功能，這麼多的項目與產品，各有不同的功能、不同的目的與精密的計費方式，頭一眼看到真是令人望之卻步。

    沒關係，透過本文，希望可讓你可以很快的先瞭解AWS的架構，以及基本的功能和服務。

    下方是AWS的平台架構，該架構演示了AWS所有的服務與產品，我們先從最下方的Infrastructure來看起。

1. Global Infrastructure

1. 目前AWS共有11個Regions，每個Region擁有數個Availability Zones。
• Region指的是一個實際的大範圍地區，例如Western United States（美國西部）與Eastern United States（美國東部）
• Zone指的是資料中心（機房）。
2. 此外目前有52個Edge Locations。
• Edge Location指的是CDN End Points（CDN是Content Distribution Network的縮寫。）
• Cloud Front是AWS中針對Edge Location的服務。
3. 以下是AWS在全球的分佈據點介紹：

4. AWS Edge locations分佈：

    接下來我們再往上看，這些是AWS所提供的各項服務：

2. Networking

• Route53：DNS服務，把名稱 (如 www.example.com) 轉換為電腦用於互相連接的數字 IP 地址 (如 192.0.2.1)。
• Direct Connect：連接本地設施（私人網路）和 AWS 的專用網路連線，例如，我們可以透過此服務將公司內部的應用程式連到AWS的資料庫。
• Virtual Private Cloud（VPC）：將多種的AWS服務運作於自訂的Virtual Private Cloud中，好像擁有個人機房一樣。

3. Compute：有四項主要的服務

• EC2（Elastic Compute Cloud）：可自行調整大小容量的雲端運算服務。
• AutoScaling：與EC2搭配，可依據目前loading自動調整運算服務的大小容量。
• Elastic Load Balancing：針對Web server或Application server，與Route53搭配使用，分配需求到各個服務主機，並且可避開有問題的主機。
• Workspaces：提供VDI桌面服務，例如微軟的Windows 7/8… 等。

4. Storage：

• S3（Simple Storage Service）：可以單獨使用，也可以與其他 AWS 服務搭配使用，最大支援5TB file size。
• Glacier：針對不常存取且可接受數小時擷取時間的資料儲存服務，因此費用較S3更低廉，因此適用於不常存取且大量的資料儲存。
• EBS（Elastic Block Store）：與EC2搭配使用，以提供持久性儲存磁碟區，為資料區塊級（Block level），可建立partition、存放任何filesystem種類的系統及檔案。
• Storage Gateway：與使用者端的應用程式配合使用，屬於一種雲端儲存的服務，在兩者之間提供無縫且安全的整合，並可視需求自動擴展空間。
• Import/Export：針對資料雲端遷移、異地備份、災難復原、交換資料等需求，可將大量資料快速的移入或移出 AWS 雲端，它不透過Internet而使用實體的便攜式儲存裝置來匯出或匯入。

5. Databases：

• RDS（Relational Database Services）：提供常見的關聯式資料庫服務，可讓使用者在雲端設定、操作和擴展資料庫的相關工作；目前提供五大類型的資料庫：MySQL、Oracle、Microsoft SQL Server 、PostgreSQL及 Amazon Aurora。
• DynamoDB：針對近來流行的NoSQL 資料庫所提供，支援文件（Files）和鍵值（Key-Value）等類型的NoSQL資料庫。
• Elastic Cache：一種記憶體內快取的資料庫服務，這項服務可從記憶體內的快取系統中擷取資訊，而不是完全仰賴速度較慢的磁碟型資料庫，目前支援兩種記憶體內快取引擎：Memcached和Redis。

6. Analytics：

• RedShift：一種大型的，以PB為單位的雲端資料倉儲服務，用以處理巨量資料及分析。
• Kinesis：可即時性的針對大型、分散式等資料流進行資料處理，而且每小時內就可以從數十萬個來源持續性的擷取和存放高達數百TB的資料。
• EMR（Elastic MapReduce）：架構在目前最流行的BigData儲存管理雲端平台Hadoop以及MapReduce技術，提供快速且經濟實惠處理大量資料的服務。

7. Applications：

• SQS（Simple Queue Service）：應用於程式之間進行訊息交換或知會的Message Queue訊息佇列服務。
• SWF（Simple Workflow Service）：一種狀態追蹤器和任務協調器的服務，可協助開發人員建構、執行和調整以平行或連續步驟進行的背景任務；例如，如果應用程式的步驟需要 500 毫秒以上才能完成，並在任務失敗時恢復或重試，這時就需要SWF 服務。
• SNS（Simple Notification Service）：一種推送簡訊收發服務，可將通知推送到Apple、Google、Fire OS和Windows 裝置，也可以透過SMS簡訊或電子郵件將通知傳遞給 Simple Queue Service (SQS) 佇列，或傳遞給任何 HTTP 終端節點。
• SES（Simple Email Service）：純粹針對外寄（out-bonding）的電子郵件發送服務，多用於發送交易電子郵件、行銷訊息等等。
• Elastic Transcoder：即時且快速的線上影音轉檔服務。
• Cloud Search：提供網站或應用程式的網路搜尋功能，它支援34種語言與熱門搜尋功能，例如反白、自動完成及地理空間搜尋。

8. Deployment & Managementr：

• Opsworks：一種應用程式管理服務，用於部署和操作不同形態和規模的應用程式。
• IAM（Identity and Access Management）：控制使用者對AWS服務和資源的存取權限，使用者可使用IAM來建立和管理AWS使用者和群組，並使用各種權限來允許和拒絕他們存取AWS資源。
• Cloud Watch：針對AWS雲端資源和執行的應用程式進行監控的服務，使用者可利用 CloudWatch收集和追蹤指標、監控記錄檔以及設定警示。
• Elastic Beanstalk：只要你的Web應用程式或服務是用Java、.NET、PHP、Node.js、Python、Ruby、Go或Docker所開發的，那麼只需上傳程式碼，從容量佈建、負載平衡、自動擴展到應用程式運作狀態監控的部署，Elastic Beanstalk 都可自動處理。
• CloudTrail：用於記錄帳戶的AWS API 呼叫並提供日誌檔案，所記錄的資訊包括了API 呼叫者的身份、API 呼叫的時間、API 呼叫者的來源 IP 地址、請求參數以及 AWS 服務返回的回應元素等等。
• Data Pipeline：在不同的AWS運算服務或儲存服務之間移轉或處理的服務，例如S3、RDS、DynamoDB、EMR之間等等。
• Cloud Formation：提供一種可讓開發人員和系統管理員建立和管理相關AWS資源集合的簡單方式，並透過有序且可預測的方式對其加以佈建和更新。

　　以上對於Amazon的架構和服務作了大致的介紹，接下來，我會在後續的文章中繼續介紹各項服務的操作及使用方式。

認識密碼學

王旭正教授目前任職於中央警察大學，他曾經撰寫過數本知名的資安相關書籍，可算是國內知名的密碼與資訊安全相關領域的權威，在這本剛剛於本月（三月）所出版的「認識密碼學的第一本書」中，王教授試著用淺顯與故事性的方法介紹密碼的起源與現代密學的發展，讓一般人也能一覽密碼學的奧秘而不被複雜難懂的數學與冰冷理論所嚇著。

如果您沒看過這本書，建議您可以買來看看，如果捨不得或懶得買，那麼，也可以直接瀏覽這幾頁濃縮整理的精華重點，應該涵蓋了書中八成的主要內容吧，看完後也等於讀完該本書了。

Ａ）阿拉伯數字的由來

    阿拉伯數字並非阿拉伯人發現，而是印度人發明，再經由阿拉伯人經由戰爭和貿易而傳播到歐洲地區，取代了原本使用的羅馬數字，所以歐洲人才會稱為「阿拉伯數字」。

    不過，你知道為什麼這些阿拉伯數字會長成這樣子？有什麼緣由或改變嗎？

    其實古代阿拉伯數字的寫法與外觀是有棱有角，與現代的圓弧形有極大的差異，也就是它們所代表的「數」與「角度」存在著一定的規則：有一個角度的就是代表數字「１」，二個角度的代表數字「２」，有三個角度的代表「３」…依此類推，請注意下圖中圓點所標注之處就是數字的角度，而你可以看出「０」是沒有任何角度的。

Ｂ）密碼學的母親－質數

    質數其實跟密碼、網路安全有很深的關連性，就是因為它們不能再做因數分解，才能用來當作保護機制，這牽連到中國古代一個跟質數密碼相關的故事：

    韓信幫劉邦統一江山後，生性猜忌的劉邦開始害怕韓信有了兵力後會趁機造反，因此在一次宴席中，劉邦特意詢問韓信兵力的狀況，韓信一聽便理解其言外之意，於是想出一個避重就輕的回答：

    「我不知道我總共有多少士兵，但我只知道三個一數會剩兩個，五個一數會剩三個，七個一數會剩兩個。」…    劉邦聽了之後一頭霧水，在旁的軍師也算不出總共有多少兵力，於是韓信憑著過人的機智逃過一劫。

    在這故事中，韓信講的「三個一數」「五個一數」和「七個一數」都是質數，就是有名的「中國剩餘定理」，也就是常聽到的餘式定理，簡單來說，韓信的總兵力就是同時可以滿足這三個條件的數目。

只要所有除數彼此互質，就可以用「中國剩餘定理」來計算可能的數目，而同樣的，如果我們增加了更多的條件，也就是再加上諸如「11個一數」或「13個一數」，那麼，就需要更多的時間來計算出答案了。

所以，根據下列的原則

「５」「７」「１１」 → 除數，不能公開

「２」「３」「４」 → 餘數，可公開

「３６７」 → 所要保密的最終的答案

因此從這個角度來看，這是一個很好用的密碼應用，例如，如果我們和另外兩位朋友私底下用「５」「７」「１１」當作代號－這是除數，而且也是我們彼此之間知道而已，另外用「２」「３」「４」－也就是餘數，作為在網路上傳遞訊息用的數字，此數字被別人知道也沒有關係，而答案「３６７」則是我們要保密的數字，不能被外界知道，除非「５」「７」「１１」這組數字被洩露出去了。

Ｃ）近代密碼學的兩大門派

    大家應當都很清楚，對稱式(Symmetric)與非對稱式密碼系統兩者最大的差異在於加密和解密用的是不是同一組密碼，舉例來說，如果上鎖和開鎖用的不是同一把鑰匙（也就是所謂的金鑰），那麼它就是非對稱式密碼系統，反之則稱為對稱式密碼系統。

目前最知名且還廣為使用的對稱式密碼，就是DES與AES。

１）對稱式加密：

DES（Data Encryption Standard）：DES是近四十年來最廣為應用的金鑰密碼系統，它利用長度為56位元的金鑰來對長度為64位元的區塊進行加密演算，但由於目前的電腦處理速度成長相當迅速，使得採用56位元長度金鑰的DES已不夠安全，出現了一種3-DES的變形，它會進行三次的加/解密運算，也就是相當於使用了56x3=168位元長度的金鑰作加密。

AES（Advanced Encryption Standard）：AES發展於2000年，一開始目標便以取代DES為目的，它可選擇三種金鑰長度：128、192、256位元進行加密，對於明文區塊容量也更大128位元，因此可說是目前對稱式密碼系統中最安全的，例如，目前普遍使用的藍芽4.0版就是利用128位元的AES進行資料加密。

２）非對稱式加密：

又稱「公開金鑰密碼系統」，概念是建立在數學的單向函數上，單向的意思類似單行道，行進方向只有一個，換言之不會有出現逆向行駛的可能；所以公開金鑰可以很大方的公開於網路上，無需擔心被反向破解；我們也可以把公開金鑰密碼系統想像成喇叭鎖，就更容易理解了，任何人只要按下鎖頭都可以把門鎖上，但是要把門打開，就一定要找到對的鑰匙。

例如RSA就是有名的公開密碼應用，它是利用「對極大數作質因數分解的困難度」這樣單向函數概念而產生，也就是建立在針對一個極大的數字作質因數分解的困難度上，我們平常上網使用的SSL這類對於網路資料送所進行的加密方式，就是一種應用RSA的例子。

３）混合公開金鑰：

對稱式加密的優點是加解密速度快，而非對稱式的優點則是安全性高，在實際應用上，我們常常取兩者的優點，截長補短做成混合系統。

Ｄ）數位簽章－避免資料遭受竄改或偽造

    上述的密碼系統可以保護資料不被竊取，然而，卻無法保證其所保護的內容是正確無誤、原汁原味沒有被掉包或修改過的，因此，我們必須要使用另一項功能，來保證資料的真實性，也就是「雜湊函數」（Hash）。

    如上圖所示，無論輸入為空值或任何數值，都會傳回不同且一定長度的資訊，而且你無法從傳回的資訊反推算出原來訊息，所以Hash函數具有三種特殊的性質：

「單向性」：只能得到單向的得到右邊輸出結果，但是無法反推回去。

「抗碰撞」：不同的文字有不同的輸出結果，不會有不同文字卻具有相同輸出結果的情況。

「擴張性」：就算是微小的差異或改變，也會得到和原來差異極大的輸出結果。

應用在資訊的傳送上，如果我們將原來的資訊先使用Hashj函數產生出摘要資訊，再將此摘要資訊連原始訊息一併傳送給對方，那麼，對方只要比對自己產生的摘要資訊與所接收的是否一致，即可驗證資料是否正確以及完整；一般在生活的應用上，這種將Hash驗證與金鑰系統作結合的功能，稱之為「數位簽章」，如下方是利用雜湊函數應用的數位簽章流程。

Ｅ）憑證－避免中間人攻擊

    不過，經過數位簽章過的資訊，尚無法解決一個俗稱「掉包」的風險，也就是駭客在中途將公開金鑰掉包，替換為自己的公開金鑰，這就是所謂的「中間人攻擊」。

要怎麼來預防中間人攻擊呢？從上面的流程中，我們可看出問題的所在，是公開金鑰沒有被認證，如果我們能在取得金鑰的同時就進行比對，確認這把金鑰是誰發出的，就可以防止此金鑰中途被人掉包。

憑證

    憑證就是在公開金鑰上，再加上數位簽章，就可以認證該金鑰是誰所擁有的。

    不過，它需要一個公正及受信賴的第三方（憑證機構，我們稱為Certification Authority，CA），針對使用者的個人身份資料以及使用者本身的公鑰，進行簽署認證的動作，若正確無誤，則核發數位憑證，而此憑證為了保證有效性，因此有一定的使用期限，並非永久有效。

   

開源的語音辨識WIT.ai

    今年的2015元旦剛過不了一個星期，Facebook便宣佈收購了語音辨識公司WIT.ai，這家公　司為一新創公司，成立雖僅18個月，但其語音技術根據百度（Baidu Inc.）的測試結果，比起蘋果的Siri、微軟的Cortana還要更加精確，相當接近百度（自家作的調查，當然要充胖一下）或 Google Google now語音助手的表現，無怪乎祖克伯要以迅雷不及掩耳的速度收購這家剛誔生的公司，作為與Apple和Google在語音AI領域相對抗的武器。

WIT.ai強調的是開放與免費使用，並利用使用者回饋的數據作為改善的參考；截至目前統計，已經有6000多位開發者透過WIT.ai所免費提供的API，在其程式中加入語音辨識的功能，以便開發出各式類型的App與應用環境，而其語音識別技術與資料庫在免費提供user使用的情況下，利用使用者與開發者自主回饋的資訊，作為WIT.ai自我改良的方式、並使其語音識別效率更加精確。

WIT.ai能作什麼？

    在WIT.ai首頁上，直接開宗明義的列出它能協助完成的事：

1. Mobile apps：如果你是App開發者，可以使用WIT.ai的語音服務，讓你的App具有語音控制的功能，讓使用者能夠透過手機發送或執行語音相關命令。
2. Home automation：當WIT.ai成功解析了你所送出的語音命令，那麼就可以透過智慧家居設備來執行相對應的動作。
3. Wearable devices：穿戴式設備由於體積小，與使用者的輸出入介面受到限制，因此高度依賴語音命令的動作方式。
4. Robots：無論是在工廠生產線或家庭、娛樂用的機器人，皆可透過語音方式讓機器人去執行相對應的行為，讓人感覺機器人似乎擁有聽覺與智慧的能力。
5. Messenger Agents：目前各科技大廠皆推出語音助手的服務，透過對話的方式處理部份help desk的工作，並提供即時性的協助；只要在個人的console上建立完善的語音命令資料庫，WIT.ai也可以作到這點。

WIT.ai為何免費？

　　最可貴的一點：WIT.ai是免費的，想想看，一般人若要建置一套自有的語音識別系統，往往要從零開始搜集龐大的語音樣本資料庫，並進行後續的處理、分析訓練、建置模型等等，這些都需要龐大的時間與人力門檻，因此限制住了像個人開發者、中小型企業等對於語音相關領域的開發與投入。

然而透過免費提供給眾多開發者應用在各種領域的專案，並將結果集中維護到線上的資料庫，這樣大量透過開發者在console對於語音識別結果的回饋，WIT.ai經由這樣集體智慧的概念，具備了自我學習並自動改良語音識別的能力，因此其辨識的準確度不下於諸如Google now、Apple Siri、Microsot Cortana、Amazon Echo等等科技大廠語音助手的識別能力。

　　它的作法是，使用者（開發人員）需要先收集一系列希望讓電腦能夠識別的字串和口語，集中在一個稱為「Expressions」的資料夾中，然後提供眾多的語音樣本訓練電腦讓它知道這些語音都是屬於該「Expressions」，因為不同人有不同的腔調發音與口吻，因此，愈多的樣本與「Expressions」資料愈能讓識別結果更精確。因此和GitHub 這類的程式分享平台相同，WIT.ai亦充分的利用了網路的分享功能，藉由免費提供語音識別功能給開發者，同步的要求開發人員必須分享彼此的「grammar」和樣本以增進識別精確度，而達到一舉兩得的效果。

　　不過，由於需要回到線上的資料庫分析取用並回饋，因此，我們可以預想到WIT.ai的一大缺點，就是必須要先連網才能使用相關的語音控制功能，如果沒有網路連線或設備不具連網功能，那麼就無法使用WIT.ai了，坦白說，這是一個致命的缺點，也是WIT.ai目前無法廣泛流行的原因，因為若需要設備在使用時必須先連網、或者必須持續的連網，那麼，它的使用範疇和應用環境就會大大的受限，而且也增加了開發的成本與功能複雜性。事實上，如果WIT.ai考量的是為了維護一套集中的資料庫、避免被自由散發利用、或者可立即更新、資料回饋等等，其實可考慮將龐大的語音資料庫預先分門別類，各別開放讓使用者依需求類型下載，且其下載的語音資料庫是經過加密無法反解譯的，或者乾脆考慮下載資料庫不連網使用者需付費等方式，應該都是可行的方向。

開始試用看看

1. 登入GitHub帳號：WIT.ai使用GitHub來認證並建立個人專屬的控制平台（Wit console），因此必須要先擁有GitHub帳號才行，若您還沒有GitHub帳號可以到https://github.com申請，成功登入後，您便擁有專屬的Wit console（網址https://wit.ai/{您的GitHub帳號}）。

下方是我的Wit console，點擊右上方的帳號名稱可新增一個instance。

2. 建立Instance和Expression：這是比較複雜的部份，在建立所有的expression之前，我們必須先思考，想要用聲音來啟動什麼命令？

有兩個方式：

1. 想像一下一個人應該說什麼話，然後將這個話語對應到什麼設備應作出什麼反映。
2. 看看設備上的功能，能用什麼適當的指令來啟動它？要用什麼口語聲音來啟用這些指令？

例如，我們想要控制溫度，所以我們可能會說：

        「What's the current temperature?」

        「I want to set the temperature to 71 degrees.」

        「Is it me or it is hot here?」

        「Set the temperature to 64 degrees at 10pm.」

        「I am hot!」

    以上這些都可算是口語上想要控制溫度的指令，所以我們把它們都輸入到expression當中，Intent則輸入：Temperature。

然後，我們可以先用keyin文字的方式來測試WIT.ai可否辨識；請在Console中的文字欄，輸入剛剛expressions中的任一句，例如「It’s cold」，你會發現WIT.ai告訴我們這句話的意圖是”Temperature”，由於透過文字而省略了語音的因此，如果是透過語音方式，我們必須提供愈多的樣本愈好，才能抓到正確的意圖。

另外要注意的是，這些我們自己透過語音來測訓並訓練的結果是會自動提供給其它WIT.ai會員使用的，如果你不想公開，那麼就必須付費才不會公開給外界。

WIT.ai支援那些開發工具？

1. WEB API：我們可以透過cURL，使用HTTP URL語法、或以JQuery來傳送命令並接收回傳結果，這種方式可用於大部份的環境，如網站、WEB App、iOS、Android、Windows…等等。

Ex：JQuery+JSON的範例，送出” set an alarm in 10min”的命令，此段亦可為一個語音物件.

收到的回應亦是json格式，intent是”alarm_set”，”entities”的值是”on”，有一個”datetime”的值是”2015-03-16T23:22:13.000-07:00 ~ 2015-03-16T23:22:14.000-07:00 “，因此，我們會發現，當我們告訴WIT.ai ” set an alarm in 10min”這句話，它能夠正確的告訴我們詳細的資訊：alarm_set、on以及一組相距十分鐘的時間值，我們就可以在程式中依使用者的語音作出正確的人工智慧行為，而且個人開發者或小公司就可以作到。

2. 其它分別針對不同平台的API或SDK：如iOS API、Android SDK、Windows API、WEB API、Raspberry Pi API、Node.js API、Ruby SDK、Python SDK、C API、Rust API等等。