59

Size: px

Start display at page:

Download "59"

れんまつちた
5 years ago
Views:

1 クラウド技術センター技術開発室 IT エンジニア森本淳司 Atsushi Morimoto Google Amazon Microsoftの提供するクラウドサービスを利用したアプリケーション開発を行うとそれぞれのサービスは強みと弱みを持つことがわかる本稿では各クラウドサービスの強みと弱みを明らかにして強みを活かし弱みを補うために複数のクラウドサービスを連携した3 階層のアプリケーション構成を提案するまたアプリケーションを試作することでクラウドサービス同士の連携の実現性を検証し実現することができた 59

2 1. はじめに企業におけるクラウドコンピューティング ( 以下クラウド ) の利用状況認知度は年々確実に増加している 1) クラウドの特性メリットが企業のニーズにマッチするためであろうクラウドの代表的なメリットを示す 2) 情報システムを所有する形態から利用する形態に変えることでシステム投資の低減化を図ることができる従量課金制により初期投資の負荷が少ない必要なときに必要な量だけ利用することができ不用になった場合すぐにやめることができるつまり情報システムコストを変動費化することができる一般にクラウドを適用したアプリケーション開発では GoogleやAmazon Web Services Microsoft などの企業が提供するGoogle ( 以下 ) やAmazon Web Services ( 以下 AWS) Windows Azure ( 以下 Azure) などのサービス ( 以下クラウドサービス ) を利用するしかし Google Amazon Web Services Microsoft が提供するクラウドサービスはすべて同じ機能ではなくそれぞれ強み弱みがある各社クラウドサービスの強みを活かし弱みを補い合うことができればより最適なアプリケーションを開発できるそこで本稿ではクラウドサービスの代表的な特徴を整理し強みと弱みを明らかにするそしてその結果をもとにクラウドサービスの強みを活かし弱みを補い合うことができる構成を提案するまた本提案構成の検証を行うためにアプリケーションを試作した検証においてクラウドサービス間の連携は実績が少なく困難が予想されたので重点的に検証した最後に課題と結論今後の展望を示すなおアプリケーションの試作に用いたクラウドサービスは一般的な開発技術の適用を考慮した結果 App Engine Azure Amazon EC2 Amazon S3 を採用した 2. クラウドサービスの強みと弱みクラウドサービスの強みと弱みを明らかにするためにクラウドサービスの各社 HPおよび文献を調査し代表的な特徴を整理した 3) 4) 5) 6) 7) 8) 2.1. 特徴一覧表 1に各クラウドサービスの特徴を示す表 1 クラウドサービスの特徴 Azure AWS (Google) (Microsoft) (Amazon Web Services) (1) 形態 (2) データストア (3) 制約 (4) 開発言語 PaaS KVS 多数 Java/Python PaaS RDB/KVS 少数.NET(C#/VB) IaaS RDB/KVS 少数 OSに依存 (5) 開発環境 Eclipse Visual Studio ターミナル Windows Vista/7 (6) 無料利用ありなしなし (7) 料金体系従量課金従量課金従量課金 (8) スケーラビリティ自動自動手動 (1) 形態とAzureはPaaS(Platform as a Service) である PaaSはアプリケーションの開発実行環境をサービスとして提供する形態である AWSはIaaS (Infrastructure as a Service) である IaaSはサーバーやネットワークをサービスとして提供する形態である AWSは仮想マシン利用サービスとしてAmazon EC2 ストレージサービスとしてAmazon S3を提供している (2) データストア KVS(Key Value Store) と呼ばれスケーラビリティを活かすことのできるデータストアがあるただしこれはスケーラビリティを確保するためリレーショナルデータベース (RDB) がもつ厳密なACID 特性を有さないではBigTableと呼ばれるKVSを利用できる Windows Azure PlatformにおけるデータストアにはストレージサービスとRDBサービスの2つがある 1つ目のストレージサービスには4 種類のサービスがある大規模なバイナリデータを保存するためのBlob(Binary Large Object) とKVSであるTable アプリケーション間の通信のためのQueue そしてNTFSとして読み書きできるDriveが存在する 2つ目のRDBサービスは部分的な制 60

3 約があるもののクラウド上でSQL Server を実現したものである AWSはAmazon Simple Storage Service (S3) Amazon Elastic Block Store (EBS) Amazon SimpleDB など多数のデータストアを提供している Amazon EBSはAmazon EC2のインスタンスから利用する形態であり Amazon Simple DBはKVSである (3) 制約は制約が多いここでは代表的な制約を紹介するにはリクエストを処理しレスポンスを返すまでの時間が約 30 秒以内でなければならないリクエストタイマーと呼ばれる制約がある制限時間を超えた場合 Exceptionが発生し割り込み処理が行われるまたファイルの読み込みはできるが書き込みはできない制約もある例えばアップロードされたデータをファイルとして保存することはできないそしてアプリケーションが独自にTCP/IPのソケットを開くことができず外部ホストと通信するためにはが提供する機能を用いる必要がある一方と比較してAzure AWSの制約は少ない Azureの代表的な制約事項はログ閲覧の仕組みがないことである MicrosoftはAzure 上のアプリケーションが出力するログを閲覧する仕組みを提供していないよってその仕組みを自作するか別途ツールを利用する必要がある AWSではサービスによって利用できるコンピューティングリソースの上限が決定されている例えばEC2ではインスタンス数の上限は20 個と決まっているただし AWSに申請することでこの上限を変更することは可能である (4) 開発言語 GoogleはJava ランタイム環境とPython ランタイム環境を提供している Javaラインタイム環境ではJavaプログラムをはじめ JVM 上で稼動するScalaプログラムなども実行できる Pythonランタイム環境ではPythonプログラムを実行できる Azureは.NETランタイム環境を提供しているため C# プログラム VBプログラムを実行できるその他にも AzureはFastCGIをサポートしているためPHPプログラムなども実行できる AWSはIaaSであるためクラウド利用者が開発言語や OSなどを自由に選定でき開発の自由度は高い逆を言えばクラウド利用者が準備することはPaaSより多い (5) 開発環境およびAzureの開発には統合開発環境を使用できるではEclipse を Azureでは Visual Studio を利用して開発できるただし Azureのアプリケーションを開発するためには Windows Vista またはWindows 7が必要である AWSはIaaSであるため統合開発環境は特に存在しない例えばAmazon EC2でLinux の仮想マシンを利用する場合は PuTTYなどのターミナルを使用することができるそしてPuTTYからSSH(Secure SHell) でLinux 仮想マシンにリモート接続してサーバー構築を実施できる EC2 でWindows 仮想マシンを利用する場合はリモートデスクトップ接続 (RDP) を利用できる (6) 無料利用は一定のコンピューティングリソースを無料で使用できる Azureにも無料利用プランはあるが期間限定キャンペーンのため無料利用はなしとした (7) 料金体系基本的にすべて従量課金制であるつまり使用した CPU 時間保存したデータ容量データ転送量などに応じて徴収される料金が決定されるは一定量を無料で使用できるが課金を有効にすることでそれ以上のコンピューティングリソースを使用できる Azureは実行環境の仮想マシンのスペックにより料金が異なる A m a z o n E C 2 はサーバーの起動時間で課金され Amazon S3はデータ保存量データ転送量などに応じて課金される (8) スケーラビリティには自動スケーリングの仕組みがある上のアプリケーションは利用するユーザー数などに応じて自動でスケールアウトする Azureで自動スケーリングを実現するには Dynamic Scaling Azure などのツールを利用しなければならない 9) 一方 AWSでスケールアウトを行う場合クラウド利用者が環境を構築しなければならない具体的にはEC2を用いて必要な数の 61

4 仮想マシンを用意するそして負荷分散を実現するためにロードバランサであるElastic Load Balancingを用いる必要がある 2.2. 強みと弱みの一覧 2.1. で整理したクラウドサービスの特徴を強みと弱みに分類しその結果を表 2に示す表 2 クラウドサービスの強みと弱み Azure AWS 強み自動スケーリング無料で利用開始できる.NET 環境を利用できる RDBを利用できる構築自由度が高いさまざまなサービスがあるため用途に合ったものを利用できる弱み実行時間に制限があるなどの制約が多い Windows Vista/7が必要自由度が高い反面設定メンテナンスはユーザーが行うこの構成のメリットの一例としてサーバーの負荷分散やシステムの変更容易性が挙げられる具体的にはフロントエンドでスケーラビリティを活かして多数の処理を実行しバックエンドで負荷の高い処理を実行することで負荷分散を実現できるまたフロントエンドとバックエンドに分割することで変更時の影響範囲を小さくできる表 2で示したクラウドサービスの強みと弱みからフロントエンドとバックエンドの最適な組み合わせを考えるフロントエンドはが適しているこれはの自動スケーリング機能を活かすことができるためであるただしリクエストタイマー制約は図 1の構成全体に影響を及ぼしてしまうが Googleが将来的にリクエストタイマーを延長すると表明しているため本稿ではフロントエンドにを選択した 10) バックエンドはAzureかAmazon EC2が適している AzureはApp Engineのような制約はなくさまざまな処理を実行でき EC2はIaaSであることから目的に合わせたサーバーを構築できるためであるこの選択によりバックエンドではが実現できないファイルの書き込み処理などできる 3. 構成の提案クラウドサービス間を連携する3 階層の構成を提案しそれを実現するために必要な検証ポイントについて説明する 3.1. 構成 3 階層の構成を提案する構成は図 1に示すようにフロントエンドバックエンドデータストアからなるフロントエンドはクライアントとのやりとりを行うプレゼンテーション層でありバックエンドはアプリケーションのロジック部分を担当するビジネスロジック層である 3.2. 検証ポイント図 1の構成を実現するためにはクラウドサービス上のアプリケーション間で連携できなければならないそこで本稿ではRESTを用いてフロントエンドとバックエンド上のアプリケーション同士が連携できるか検証した一般的にアプリケーション間を連携するための技術にはSOAPと RESTがある SOAPと比較してRESTはWebブラウザで URLを指定すると簡単にXMLを取得できるため利用しやすい 11) このことから検証ではRESTを採用したまた RESTの定義はたびたび議論の的になるが本稿では HTTPを用いて指定されたURLに接続するとXMLが返却される通信形態と定義するクライアントフロントエンドバックエンド図 1 クラウドサービス間連携データストア 4. アプリケーション試作による検証 3 章で提案した構成を検証するためにアプリケーションを試作したこの試作アプリケーションはオンライントランザクション向けシステムを想定しており次の機能を提供する画像の登録 62

5 類似画像の参照本稿では表 3 が示すように 2 つの構成について検証した表 3 検証構成パターン S3に保存されている画像のURLを直接参照させたこれより処理時間を節約することができる Amazon EC2 の役割フロントエンドバックエンドデータストア 1) EC2 S3 2) Azure S3 Java アプリケーション Apache Tomcat データストアは両構成ともAmazon S3を選択した選択理由は画像を保存するためにデータベースを利用するよりファイル形式でストレージに保存するほうが容易なためである図 3 EC2 構成 Fedora 8 Amazon EC 検証構成パターン 1( EC2 S3) クライアント Google REST Amazon EC2 図 2 EC2 S3 連携 REST Amazon S3 本節では表 3の検証構成パターン1) について解説する利用したクラウドサービスは3つありフロントエンドにバックエンドにAmazon EC2 データストアにAmazon S3を利用した検証した構成を図 2に示す Google の役割 Google にはJava 版とPython 版の2 種類がある検証ではJava 版であるGoogle for Javaを用いたはクライアントから画像登録を要求されたとき画像をEC2に送信して登録を依頼するそして画像登録の成功可否をクライアントに返却する同様に類似画像の検索を要求されたときは EC2に類似画像の取得を依頼しその結果をクライアントに返却する画像処理は時間がかかるためクライアントがWebブラウザで画像を参照した場合の画像取得ではEC2を経由せず Amazon EC2はとAmazon S3の中継役をバックエンドで行う EC2 基盤上にはLinuxやWindows などのOSをインストールできその上で自由なサーバー構築を実現できる検証ではLinux OSにFedora 8を WebアプリケーションサーバーにApache Tomcat を選択したこの構成を図 3に示す Tomcat 上で稼動する Javaアプリケーションはからの要求に応じてS3に画像を保存する処理を行いまた類似度結果をS3 から取得しに返却する処理を行う一般的に EC2は処理に時間のかかるビジネスロジックを担当することができる Amazon S3の役割 Amazon S3では画像データの保存および類似度結果の保存を行うこれら処理を行う際 AWSが提供している各種言語 (Java C# etc) 用のREST SOAPライブラリを使用できる今回の検証で用いたS3 操作用ライブラリは Amazon S3 Library for REST in Java である EC2 間連携上のJavaアプリケーションとEC2 上の Javaアプリケーションで通信を行ったしかし App Engine 上のアプリケーションはソケットを開くことができず外部ホスト ( ここではEC2 上のJavaアプリケーション ) と通信するにはURLフェッチJava APIを利用し 63

6 て HTTP HTTPS 接続する必要がある URL フェッチ Java APIの利用には2つの方法がある Java 標準ライブラリのjava.netの利用の低レベルAPIの利用 2つの方法の違いは例外を発生させることができるか否かである URLフェッチサービスは送信するリクエストと受信するレスポンスのデータサイズを制限している制限するデータサイズを超えた場合 Java 標準ライブラリの java.netは通知なしで切り捨てられる一方低レベル APIを利用する場合は通知なしで切り捨てるか例外を発生させるかを選択できる試作アプリケーションではユーザビリティの観点から例外処理を正しく行う必要があるための低レベルAPIを利用したなお java.net 低レベルAPIともにURLフェッチサービスは約 5 秒以内に外部ホストに接続できないとタイムエラーになる EC2 上のJavaアプリケーションはからのリクエストに応じるシンプルなサーブレットである App EngineよりEC2 上のサーブレットが指定するURLに画像登録のリクエストが来るとS3に登録を行いそして成功可否をXMLに記述して返却するリクエスト中にある画像のデータサイズは不確定のためGETを利用せず POST を利用したまた画像類似度取得のリクエストが来ると S3から画像類似度を取得し画像が保存されているS3の URLをXMLに記述して返却するではJAXB を用いてXMLとJavaの変換を行った以上よりEC2の指定するURLにが接続し HTTP 通信することでクラウドサービス間の連携をREST で実現できた 4.2. 検証構成パターン 2( Azure S3) クライアント Google REST Windows Azure 図 4 Azure S3 連携 REST Amazon S3 本節では表 3の検証パターン2) について解説する基本的な構成は4.1. と同じである検証した構成を図 4に示す異なる点はバックエンドを担当するクラウドサービスにAzureを採用した点であるここではEC2との相違点などAzureを中心に解説する Windows Azureの役割 Windows Azureは.NETアプリケーションなどを稼動させるための実行環境である Azureの役割はと同様にとAmazon S3の中継役である Azureはクラウドによるスケーラビリティを確保するために Webロール Workerロールと呼ばれる役割の異なるプログラムで構成される WebロールはASP.NETで構築されるWebアプリケーションまたはWCF(Windows Communication Foundation) で構築されるWebサービスである一方 Workerロールは非同期処理やバッチ処理などバックエンドで働く処理を行うアプリケーションプログラムである検証ではクラウド用のWCFである WCF Service Web Role を利用した WCFの.NETアプリケーションがApp Engineからの要求に応じてS3の操作を行うこのS3の操作では.NETアプリケーションからEC2やS3を操作するためのライブラリを含む AWS SDK for.net を使用した Azure 間連携上のJava アプリケーションと Azure 上の.NET アプリケーションで通信を行った基本的なコンセプトはと同じであるつまり側の仕組みは Azureが指定するURLに接続しHTTP 通信を行うそして Azureが返却するXMLをJavaに変換する異なる点はAzure 側で WCF Service Web Role を利用したことである.NETが提供するライブラリを使用することでクラウドサービス間の連携をRESTで実現できたのEC2ではに返却するためのXML 応答の仕組みを独自に作成した Javaアプリケーションで RESTを実現するためには仕組みを独自に構築するだけではなくフレームワークを利用する方法もある一般的に EC2はIaaSであるためサーバーの設定構築をクラウド利用者が行わなければならないがフレームワークの選定などにおいて自由度の高い開発を行うことができる一方 PaaSであるAzureは実行環境を提供しているためIaaSと比較して開発自由度は低いものの RESTなどの機能を実 64

7 現する場合には.NETのライブラリを活用し効率的な開発ができる 5. まとめクラウドサービスの強みを活かし弱みを補い合うため3 階層の構成を考案したまたその構成の中で必須技術となるクラウドサービス間 ( フロントエンドとバックエンド間 ) の連携を実現できた以下に試作アプリケーションに対する課題と対策今後の展望そしてクラウド利用における注意を述べる 5.1. 課題とその対策提案する構成を実用する場合は次のような課題を解決しなければならない 1) リクエストタイマーによる処理時間の制約リクエストタイマー制約は将来的に延長されると仮定して3 章の構成を提案したしかし現時点でリクエストタイマー制約を回避する方法を考えておかなくてはならない回避策としてクライアントとバックエンドとの接続を非同期にする方法である時間のかかる処理を行ったバックエンドは結果を一時的にキューと見立てたBigTableなどのデータストアに処理結果を保存するクライアントは Ajaxなどでポーリングしてそのデータストアにある処理結果を取得する 2) URLフェッチサービスの接続制限時間が外部ホストと通信するためのURLフェッチサービスには規定された時間 ( 約 5 秒 ) 以内に接続できない場合はタイムアウトエラーになるという制約があるしたがってタイムアウトエラーが発生したときにリトライを行い再接続する仕組みが必要である 5.2. 今後の展望 1) 構成の有用性を検証提案した構成をもとにアプリケーションを開発することはできたがそれぞれのクラウドサービスの強み ( 自動スケーリングなど ) が有効に機能するかまでは検証できなかった今後は構成の有用性を検証するためにの自動スケーリングの効果などを測定していきたい 2) 社内システム-クラウド間連携クラウドの利用が活発化するにともない社内システムに保存している機密情報の活用方法や既存システムの活用方法が必要になるつまり社内システムとクラウドサービスの連携は必須である画像類似度の計算はHadoop クラスタの効果を測定するためバッチ処理として自社内で行ったファイアウォールがあるためクラウドサービスから社内システムには接続できないそこで社内システムからAmazon S3に接続して画像を取得し Hadoopクラスタで画像類似度の計算を行いその結果を再度 Amazon S3に保存した今後は社内システムからクラウドサービスに接続するプル方式だけではなくクラウドサービスから社内システムに接続するためのサービスであるWindows Azure AppFabricなどの技術を検証していきたい 5.3. クラウド利用における注意全体的な注意として Azure AWS の SLA( サービスレベルアグリーメント ) 目標復旧時間 (Recovery Time Objective) を考慮すると稼動できるアプリケーションはすべてノンミッションクリティカル向けになるまたデータストアとしての BigTableなどを利用する場合リアルタイムなデータ更新を必要とするアプリケーションの開発は困難である 12) なぜならスケールアウトに強みのあるクラウドでネットワークの遅延なしにデータの一貫性を保つのは困難なためであるアプリケーションをクラウド化する場合これらクラウドサービスの特性と実現するアプリケーション特性とを十分考慮する必要がある本稿のデータは2010 年 1 月 -9 月時点のものであるクラウドサービスの変化は早いため各クラウドサービスを利用する際にはデータ等の必要事項を注視しなければならない参考文献 1) インプレスジャパンインターネット白書 2010 インプレスコミュニケーションズ (2010) 2) IPA 独立行政法人情報処理推進機構クラウドコンピュー 65

8 ティング社会の基盤に関する研究会報告書 /08/13 3) Google Code Google /09/10 4) AWS Amazon Web Services /09/10 5) Windows Azure Windows Azure Platform /09/10 6) ( 株 ) グルージェント Google for Java[ 実践 ] クラウドシステム構築技術評論者 (2009) 7) 株式会社日立システムアンドサービス酒井達明 Windows Azureアプリケーション開発入門日経 BP 社 (2010) 8) TIS 株式会社 SonicGarden 並河祐貴安達輝雄クラウド AmazonEC2/S3のすべて実践者から学ぶ設計 / 構築 / 運用 Visual Studio Windows Vista Visual C# Visual Basicは米国 Microsoft Corporationの米国およびその他の国における商標または登録商標です Javaおよびその関連製品名は Oracle Corporation( 旧 Sun Microsystems, Inc.) およびその子会社関連会社の米国及びその他の国における商標または登録商標です PythonはPython Software Foundationの登録商標です Eclipseは Eclipse Foundationの商標または登録商標です Linuxは Linus Torvalds 氏の日本およびその他の国における商標または登録商標です Fedraは Red Hat,Inc. の商標または登録商標です Apache Tomcat Tomcat Hadoopは The Apache Software Foundationの商標または登録商標ですその他の会社名製品名およびサービスはそれぞれ各社の商標または登録商標ですノウハウ日経 BP 社 (2009) 9) msdn Windows Azure Dynamic Scaling Sample /09/09 10) Google Product Roadmap /09/10 11) XML コンソーシアムエンタープライズシステムのためのWeb /09/13 12) 伊藤孝行クラウドコンピューティング技術 /PI10_03_cloudcomputing.pdf 2010/08/ Google Google は Google Inc. の商標または登録商標です Amazon は Amazon.com,Inc. またはその関連会社の商標です Amazon Web Services AWS Amazon EC2 Amazon Simple Storage Service Amazon S3は Amazon Web Services,LLCの商標または登録商標です Microsoft Windows Windows Azure SQL Server 66

XML Consortium 2009/5/8 XML Consortium Enterprise2.0 アプリを支えるクラウド基盤としての Windows Azure XML コンソーシアム Web 2.0 部会日立ソフト宮崎昭世 Microsoft MVP for Development Pl

XML Consortium 2009/5/8 XML Consortium Enterprise2.0 アプリを支えるクラウド基盤としての Windows Azure XML コンソーシアム Web 2.0 部会日立ソフト宮崎昭世 Microsoft MVP for Development Pl Enterprise2.0 アプリを支えるクラウド基盤としての Windows Azure XML コンソーシアム Web 2.0 部会日立ソフト宮崎昭世 Microsoft MVP for Development Platforms - ASP/ASP.NET Agenda クラウドとは Windows Azure とは Windows Azure 開発環境 Windows Azure の開発