Your SlideShare is downloading. ×
0
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
【17-C-2】 クラウド上でのエンタープライズアプリケーション開発
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

【17-C-2】 クラウド上でのエンタープライズアプリケーション開発

7,205

Published on

Developers Summit 2011での発表資料 …

Developers Summit 2011での発表資料

小野和俊 氏 / 松本幹 氏 / 中村研二 氏 / 宮崎貴司 氏 / 渡辺俊史 氏 / 内藤浩史 氏

MIJS製品技術強化委員会では2010年度の活動として、エンタープライズアプリケーションをクラウド上で動作させるための各種調査や実証実験を行っています。このセッションでは、ロック、トランザクション、読み取り一貫性など、エンタープライズシステムに求められる各種要件を含む「英会話教師予約システム」をWindows Azure、Google App Engine、Force.com、AWSそれぞれを用いて構築した実証実験に関する報告を行います。

Published in: Technology, Business
0 Comments
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
7,205
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
106
Comments
0
Likes
5
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • まず初めに Windows Azure プラットフォーム全体についておさらいしたいと思います。 Windows   Azure プラットフォームは主に 3 つのサービスがあります。 Windows Azure と SQL Azure と AppFabric の3つです。 今回利用したのは Windows Azure だけですので、 Windows Azure についてもう少し説明します。 Windows Azure の構成要素としては Compute サービスと Storage サービスに分かれます。 Compute サービスは Web サーバである WebRole とバッチサーバである WorkerRole があります。 また、 Storage サービスは TABLE 、 BLOB 、 DRIVE 、 QUEUE の4つあります。 今回利用したのは WebRole と TABLE 、 BLOB になります。 今回の検証のメインとなる TABLE について、もう少し説明致します。
  • TABLE のキーは、 PartitionKey と RowKey の二つです。 PartionKey というのは非常に重要になりますので、覚えておいてください。 PartionKey の値が異なるデータは、別のサーバに格納され、簡単にスケールアウトできるようになっています。しかしながら、一回のクエリで複数の PartionKey を含むデータを問い合わせる必要がある場合には、パフォーマンスが落ちますので要注意が必要です。基本は必ず PartionKey を指定してクエリを投げます。
  • 合宿の目的は省略致して、デモを見せたいと思います。
  • データモデルを簡単に説明します。 テーブルは講師マスタと予約テーブルの二つです。 予約テーブルのキーは予約日と講師がキーとなっています。
  • ここからは検証結果について説明します。 Azure のロック機構は特にありません。ロックを実現するためにはアプリケーションで実装してやる必要があります。 今回要件を満たすため、予約テーブルのキーとして、予約日と講師として、同じ日に講師を予約できないようにしました。
  • トランザクションについて説明します。 Azure のトランザクションは限定的です。 同じ PartitionKey 内かつ1クエリ内のみサポートされ、異なる PartitionKey や複数テーブル間でのトランザクションはサポートされません。 そのため、今回は要件を満たすために、予約テーブルと手当テーブルを一つのテーブルにまとめて、予約と手当の整合性が崩れないようにしました。
  • 読み取り一貫性について説明します。 Azure において読み取り一貫性は担保されます。 コミットされていない情報は読めません。 要件を満たすために、指名ランク付けを行うデータを同じ PartionKey をセットしました。これで複数行でのトランザクションが確保でき、ランク付け作業が完了するまではコミットされないようにして、実現しました。
  • Transcript

    • 1. クラウド上での エンタープライズアプリケーション開発 小野 和俊 MIJS 製品技術強化委員会 17-C-2
    • 2.  
    • 3. CAP 定理と NoSQL
    • 4. エンタープライズシステムと クラウド <ul><li>即時一貫性がない = 使えない? </li></ul><ul><li>RDBMS を選べば「これまで通りに」システムを構築することができる </li></ul><ul><li>しかし、 NoSQL を活用してこそクラウドの恩恵を最大限に受けることができる </li></ul>・ NoSQL 縛りでエンタープライズアプリ開発 ・同一アプリを複数プラットフォームで
    • 5. 課題の要件 <ul><li>特定の要件を決めた英会話の講師予約システムを作成して、以下項目を検証すること </li></ul><ul><ul><li>ロック制御 </li></ul></ul><ul><ul><li>トランザクション </li></ul></ul><ul><ul><li>読み取り一貫性 </li></ul></ul><ul><li>極力 RDBMS を使わず、 NoSQL を使用する </li></ul>
    • 6. 検証プラットフォーム <ul><li>Windows Azure </li></ul><ul><li>Google App Engine </li></ul><ul><li>Force.com </li></ul><ul><li>Amazon Web Services </li></ul>
    • 7. デモ
    • 8. クラウド上での エンタープライズアプリケーション開発 Windows Azure 編  宮崎 貴司 MIJS 製品技術強化委員会 17-C-2
    • 9. 環境 <ul><li>今回検証に利用した Windows Azure のサービスは以下の赤枠の範囲である </li></ul>Web Role Worker Role BLOB QUEUE TABLE DRIVE Service Bus Access Control SQL AZURE VM Role Data Sync
    • 10. Azure Storage のおさらい <ul><li>Azure Storage のテーブルは以下が必須項目です </li></ul><ul><ul><li>PartitionKey :ノードを指定 </li></ul></ul><ul><ul><li>RowKey :テーブルの RowID </li></ul></ul><ul><ul><li>Timestamp : 読み取り専用 </li></ul></ul><ul><li>PartionKey が同じ場合には同じノードに格納される </li></ul>ノード1 ノード 2 ノード 3 PartionKey RowKey 項目 1 … 項目 N Timestamp ノード 1 125634327 2000 … 雑誌 2010/10/5 ノード 1 1472899292 5000 … 参考書 2010/10/22 ノード 2 123456789 1000 … 本 2010/10/10 ノード 3 7732830930 3000 漫画 2010/10/26
    • 11. 検証の課題 <ul><li>Windows Azure プラットフォーム上において、特定の要件を決めた英会話の講師予約システムを作成して、以下項目を検証すること </li></ul><ul><ul><li>ロック制御 </li></ul></ul><ul><ul><li>トランザクション </li></ul></ul><ul><ul><li>読み取り一貫性 </li></ul></ul>No 検証項目 要件 1 ロック制御 同じ日に二人の生徒が講師を予約できない 2 トランザクション 講師は指名を受けると報酬として手当てがもらえる 3 読み取り一貫性 指名ランク付け作業完了までは新ランキングが見えない
    • 12. データモデル <ul><li>予約・手当データ例 </li></ul><ul><li>講師データ例 </li></ul><ul><li>主要なデータモデルは以下のとおりです </li></ul>予約日 講師所属 - 登録日 予約日 予約講師名 予約生徒者 手当 20101010 大手町店 -20101010101011678 2010/10/10 10:10:11 山田太郎 斉藤次郎 1000 所属 講師登録日 講師名 誕生日 ランク イメージ URL サムネイル URL 大手町店 20101010101011678 山田太郎 2010/10/13 1 http://xxxxx http://xxxxx 予約・手当テーブル 予約日 : PatitionKey 講師所属 - 講師登録日 : RowKey 講師予約日 予約講師名 予約生徒者 手当て 講師テーブル 所属 : PartionKey 講師登録日 : RowKey 講師名 誕生日 ランク 写真 URL 写真サムネイル URL
    • 13. 検証結果<ロック制御> <ul><li>要件 </li></ul>楽観的ロックを実現するためには、エンティティのバージョンを確認する必要がある 同じ日に二人の生徒が講師を予約できない <ul><li>Azure Storage ロック制御 </li></ul>悲観的ロックを実現するためには、 Azure Storage で制御することはできないため、アプリケーションで制御する必要がある <ul><li>今回の対応 </li></ul>予約テーブルのキーを講師予約日と予約講師のキー情報で一意キーとしているため、楽観的ロックをバージョン確認を行わずに要件を実現した
    • 14. 検証結果<トランザクション> <ul><li>要件 </li></ul>講師は指名を受けると報酬として手当てがもらえる データモデル例では、予約情報と手当情報は分けて設計されていた 予約情報 手当情報 <ul><li>Azure Storage トランザクション制御 </li></ul>同じ PartionKey 内かつ 1 クエリ内のみサポートされ、異なる PartionKey や複数テーブル間でのトランザクションはサポートされない <ul><li>今回の対応 </li></ul>予約情報と手当情報を一つのテーブルにし、1クエリで予約&手当情報を取得、登録、更新、削除できるようにし、データの整合性が崩れないようにした 予約+手当情報
    • 15. 検証結果<読み取り一貫性> <ul><li>要件 </li></ul>指名ランク付け作業完了までは新ランキングが見えない <ul><li>Azure Storage 読み取り一貫性制御 </li></ul>Azure Storage はダーティーリードは行われない トランザクションは、同時に実行される他のトランザクションからのコミット されていない変更を認識せずに、クエリの実行が開始される前にコミットされた変更のみを認識する <ul><li>今回の対応 </li></ul>指名ランク付けを行うデータを同じテーブル、同じ PartitionKey のレコードで保持し、トランザクションを確保できるようにし、指名ランク付け更新が完了するまで、新しい指名ランクを参照できないようにした。
    • 16. クラウド上での エンタープライズアプリケーション開発 Google App Engine 編  内藤 浩史 MIJS 製品技術強化委員会 17-C-2
    • 17. 環境 Google App Engine 1/7 データストア アプリケーション 実行環境 (python / java) slim3
    • 18. 検証課題 2/7
    • 19. 検証課題 ① ロック制御ができていること ② トランザクションを考慮した 作りになっていること ③ 読取一貫性に応じた 作りになっていること 3/7
    • 20. ロック制御 4/7 同一日付に講師が 予約されない為には・・・ 予約 ID (キー)を日付+講師 ID で生成。             + 登録されたデータに付与される「 version 」で 楽観的排他を実現。 ( slim3 で付与・チェックが可能)
    • 21. トランザクション 5/7 予約と手当の2つのテーブルに まとめて書き込みたい・・・ グローバルトランザクションを利用して まとめて put する。 ( slim3 でトランザクションを管理)
    • 22. 読み取り一貫性 6/7 バッチ実行中に集計中ランキングが 表示されないようにしたい ・・・ 集計トランザクションテーブルに 集計ランキング結果を。 集計ステータステーブルに 集計ステータスを。
    • 23. 結論 7/7 フレームワークを使おう。 頭を柔らかくしよう。
    • 24. クラウド上での エンタープライズアプリケーション開発 Force.com 編  松本 幹 MIJS 製品技術強化委員会 17-C-2
    • 25. 環境 CRM SaaS <ul><li>今回検証に利用した SalesForce.com の サービスは、 force.com </li></ul>Force.com Heroku VMforce
    • 26. 予約システム作成により以下を検証 ① ロック制御ができること ② トランザクションを考慮した 作りになること ③ 読取一貫性に応じた  作りになること
    • 27. Force.com の特徴 <ul><li>ステップ1 MVC モデルを基本とし、全ての UI/ データ操作の ユーティリティが存在する </li></ul><ul><li>ステップ2 上級者向けに細かくロジックの修正や追加・削除が 可能 </li></ul>ロック制御もトランザクション制御も、読取一貫性も すべてフレームワークが面倒みてくれる 簡単にアプリを作成できる仕掛けが満載
    • 28. <ul><li>処理の中核を担う「 Model 」、表示・出力を司る「 View 」、 入力を受け取ってその内容に応じて View と Model を制御する「 Controller 」の 3 要素の組み合わせでシステムを実装する方式。 </li></ul>MVC フレームワークとは? Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者
    • 29. Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者 ステップ1:ノンプログラミングで開発 GUI からテーブル を作成可能 入力パターンチェック なら Excel と同じ感覚で 簡単に作成可能 最小セットは、 最初から作成済み テーブルを作成すると、自動で作成される
    • 30. Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者 ステップ2:上級者向けカスタマイズ <ul><li>独自ロジックを Java ライクな言語で追加可能 </li></ul>Apex コード Apex コード
    • 31. 例: Apex コード <ul><li>独自クエリ言語である SOQL をダイレクトに操作可能 </li></ul><ul><li>作成したロジックを、指定したタイミング ( CRUD 操作の前後)で実施可能 </li></ul>public class YoyakuUtil{         public static void isDuplicated(Yoyaku__c[] yList){         YoyakuLockManager__c[] l = [SELECT Lock__c FROM YoyakuLockManager__c FOR UPDATE ];         Yoyaku__c target = yList[0];         for(Yoyaku__c y:[SELECT TeacherID__c,YoyakuDate__c FROM Yoyaku__c                           WHERE YoyakuDate__c = :target.YoyakuDate__c                             AND GirlID__c = :target.GirlID__c  AND ID <> :target.ID ] ) {             target.addError(‘ 重複してます’ );             break; }                 target.UserID__c = UserInfo.getUserId();         }   } Apex コードでレコードへの登録重複チェックの例 SOQL を ダイレクトに使用
    • 32. まとめ <ul><li>MVC フレームワークを装備し、かつカスタマイズ 性も高く、生産性が高いことを実感 </li></ul><ul><li>ロック制御・トランザクション制御・読取一貫性 については、何の心配もない </li></ul>
    • 33. CAP 定理上の位置づけ 一貫性 ( C) 可用性 ( A) 通信断耐性 ( P) RDBMS Azure Table AWS RDS BigTable BerkeleyDB MongoDB AWS SimpleDB Azure Storage
    • 34. Amazon SimpleDB の概要 <ul><li>AWS クラウド上で稼働する NoSQL DB( ドキュメント指向 ) </li></ul><ul><li>Erlang で実装された分散型 DB </li></ul><ul><li>REST によるアクセスが基本。 Java, PHP, C#, VB.Net API も AWS により提供されている </li></ul>
    • 35. SDB のデータ構造 Amazon SimpleDB ドメイン アイテム アトリビュート バリュー itemID itemType instrcutorName customerName reserveDate i3-2010-08-31-08 I3 Cindy 高木浩二 2010-08-31 I3-2010-08-31-09 I3 Jacob 安藤裕子 2010-08-31
    • 36. SimpleDB の制限 Amazon SimpleDB ドメイン … 最大 100GB アイテム 最大256アトリビュート 最大 1024byte ( テキスト型のみ ) 最大 100 ドメイン アイテム x アトリビュート < 10 億件 itemID itemType instrcutorName customerName reserveDate i3-2010-08-31-08 I3 Cindy 高木浩二 2010-08-31 I3-2010-08-31-09 I3 Jacob 安藤裕子 2010-08-31
    • 37. SimpleDB のクエリ <ul><li>SQL ライクだが、下記の構文のみサポート </li></ul><ul><ul><li>クエリ結果は 2500 件以下、または1 MB 以内 </li></ul></ul><ul><ul><li>クエリは5秒以内 </li></ul></ul><ul><ul><li>述部 (Predicate) は20個以内 </li></ul></ul><ul><ul><li>1述部に 20 比較まで </li></ul></ul><ul><ul><li>1述部には1 attribute のみ </li></ul></ul>select output_list from domain_name [where expression ] [ sort_instructions ] [limit limit ]
    • 38. 排他制御 String itemId = &quot;i3-&quot; + date; UpdateCondition condition = new UpdateCondition(); condition.setExists(false); condition.setName(&quot;itemId&quot;); sdb.putAttributes(new PutAttributesRequest()      .withDomainName(DOMAIN_NAME)      .withItemName(itemId)      .withExpected(condition)      .withAttributes(          createRepAttribute(&quot;itemType&quot;, &quot;i3&quot;), … . putAttribute に条件をつけて、ユニーク制約を実現 楽観的排他制御も実装可能
    • 39. トランザクション概要 <ul><li>トランザクション分離は提供されておらず、 READ_UNCOMMITTED 相当 </li></ul><ul><li>コミット、ロールバックの概念はない </li></ul><ul><li>デフォルトの読み取り操作は、直近に書かれたデータを読み取る保証はない。 </li></ul><ul><li>ただし、 2010 年 2 月より、 Consistent Read オプションを提供し、読み取り時に指定することで読み取り操作以前に書き込まれたデータの取得を保証することができるようになった。 </li></ul>
    • 40. Consistent Read: 同時読み書き <ul><ul><li>デフォルト:読み取り 1 は 10,20,NULL のいずれか! </li></ul></ul><ul><ul><li>Consistent Read=true :読み取り 1 は 10 か 20->Tx 分離なし! </li></ul></ul>出所: Amazon Web Service
    • 41. Consistent Read: 同時書込み <ul><li>読み取り 1, 2 ともに CR=true でも値は 10 または 20 ! </li></ul><ul><ul><li>クライアントからは書き込み 2 が後に見えても、サーバ側の処理順は異なるかもしれず、結果として、書き込み 1 と 2 のどちらが後かは呼出し側からはわからない </li></ul></ul>出所: Amazon Web Service
    • 42. 講師予約システム設計ポイント <ul><li>ドメイン間の join Query はできない </li></ul><ul><ul><li>-> 非正規化し、関連する項目はなるべく1ドメインに統合する </li></ul></ul><ul><li>ドメイン間のトランザクションなし </li></ul><ul><ul><li>-> 一貫性を求められるデータは1ドメインに統合する </li></ul></ul><ul><li>楽観的排他制御ができるのは 1PutAttribute だけ! </li></ul><ul><ul><li>-> 例えば予約と手当は1アイテムに統合すべき </li></ul></ul>
    • 43. 講師予約システム実装方針 <ul><li>ロック制御 </li></ul><ul><ul><ul><li>予約時にアイテム ID で Conditional Update (既に存在すれば失敗)を行い楽観的排他制御を行う </li></ul></ul></ul><ul><li>トランザクション </li></ul><ul><ul><ul><li>全てのデータを1ドメインに格納 </li></ul></ul></ul><ul><ul><ul><li>予約と手当は1アイテムとして登録 </li></ul></ul></ul><ul><li>読み取り一貫性 </li></ul><ul><ul><ul><li>トランザクション分離がないため、バッチ処理中に書き込まれたデータは除外する必要がある。過去時間でフィルタリングし、実績を集計することにして対応 </li></ul></ul></ul>
    • 44. 実装中にわかったこと <ul><li>Item#getAttributes() が返す Attribute の順序は定義順とは無関係 </li></ul><ul><li>既存のアイテムに put するとバリューは上書きではなく追記 </li></ul><ul><li>クエリ中に存在しない Attribute 名を指定してもエラーにならない </li></ul><ul><ul><ul><li>定型的なスキーマを必要としない柔軟性の裏返し </li></ul></ul></ul><ul><li>Attribute の Value が Null だと、クエリに指定してあっても SelectResult に Attribute が設定されてこない </li></ul><ul><li>Value はテキスト型のみで、集計関数がない </li></ul><ul><ul><ul><li>ソートはサポートされているが、 UTF-8 の辞書順のみで、データ型を考慮したソートはアプリ側に委ねている </li></ul></ul></ul>
    • 45. まとめ <ul><li>NoSQL には RDBMS とは異なる「オプション」が用意されている </li></ul><ul><li>NoSQL ベースでも工夫次第でエンタープライズアプリケーションは構築可能 </li></ul>

    ×