Developers Summit 2011での発表資料 小野和俊 氏 / 松本幹 氏 / 中村研二 氏 / 宮崎貴司 氏 / 渡辺俊史 氏 / 内藤浩史 氏 MIJS製品技術強化委員会では2010年度の活動として、エンタープライズアプリケーションをクラウド上で動作させるための各種調査や実証実験を行っています。このセッションでは、ロック、トランザクション、読み取り一貫性など、エンタープライズシステムに求められる各種要件を含む「英会話教師予約システム」をWindows Azure、Google App Engine、Force.com、AWSそれぞれを用いて構築した実証実験に関する報告を行います。

1. クラウド上での エンタープライズアプリケーション開発 小野 和俊 MIJS 製品技術強化委員会 17-C-2

3. CAP 定理と NoSQL

4. エンタープライズシステムと クラウド 即時一貫性がない = 使えない？ RDBMS を選べば「これまで通りに」システムを構築することができる しかし、 NoSQL を活用してこそクラウドの恩恵を最大限に受けることができる ・ NoSQL 縛りでエンタープライズアプリ開発 ・同一アプリを複数プラットフォームで

5. 課題の要件 特定の要件を決めた英会話の講師予約システムを作成して、以下項目を検証すること ロック制御 トランザクション 読み取り一貫性 極力 RDBMS を使わず、 NoSQL を使用する

6. 検証プラットフォーム Windows Azure Google App Engine Force.com Amazon Web Services

7. デモ

8. クラウド上での エンタープライズアプリケーション開発 Windows Azure 編 宮崎 貴司 MIJS 製品技術強化委員会 17-C-2

9. 環境 今回検証に利用した Windows Azure のサービスは以下の赤枠の範囲である Web Role Worker Role BLOB QUEUE TABLE DRIVE Service Bus Access Control SQL AZURE VM Role Data Sync

10. Azure Storage のおさらい Azure Storage のテーブルは以下が必須項目です PartitionKey ：ノードを指定 RowKey ：テーブルの RowID Timestamp ： 読み取り専用 PartionKey が同じ場合には同じノードに格納される ノード１ ノード 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. 検証の課題 Windows Azure プラットフォーム上において、特定の要件を決めた英会話の講師予約システムを作成して、以下項目を検証すること ロック制御 トランザクション 読み取り一貫性 No 検証項目 要件 1 ロック制御 同じ日に二人の生徒が講師を予約できない 2 トランザクション 講師は指名を受けると報酬として手当てがもらえる 3 読み取り一貫性 指名ランク付け作業完了までは新ランキングが見えない

12. データモデル 予約・手当データ例 講師データ例 主要なデータモデルは以下のとおりです 予約日 講師所属 - 登録日 予約日 予約講師名 予約生徒者 手当 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. 検証結果＜ロック制御＞ 要件 楽観的ロックを実現するためには、エンティティのバージョンを確認する必要がある 同じ日に二人の生徒が講師を予約できない Azure Storage ロック制御 悲観的ロックを実現するためには、 Azure Storage で制御することはできないため、アプリケーションで制御する必要がある 今回の対応 予約テーブルのキーを講師予約日と予約講師のキー情報で一意キーとしているため、楽観的ロックをバージョン確認を行わずに要件を実現した

14. 検証結果＜トランザクション＞ 要件 講師は指名を受けると報酬として手当てがもらえる データモデル例では、予約情報と手当情報は分けて設計されていた 予約情報 手当情報 Azure Storage トランザクション制御 同じ PartionKey 内かつ 1 クエリ内のみサポートされ、異なる PartionKey や複数テーブル間でのトランザクションはサポートされない 今回の対応 予約情報と手当情報を一つのテーブルにし、１クエリで予約＆手当情報を取得、登録、更新、削除できるようにし、データの整合性が崩れないようにした 予約＋手当情報

15. 検証結果＜読み取り一貫性＞ 要件 指名ランク付け作業完了までは新ランキングが見えない Azure Storage 読み取り一貫性制御 Azure Storage はダーティーリードは行われない トランザクションは、同時に実行される他のトランザクションからのコミット されていない変更を認識せずに、クエリの実行が開始される前にコミットされた変更のみを認識する 今回の対応 指名ランク付けを行うデータを同じテーブル、同じ 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 予約と手当の２つのテーブルに まとめて書き込みたい・・・ グローバルトランザクションを利用して まとめて put する。 （ slim3 でトランザクションを管理）

22. 読み取り一貫性 6/7 バッチ実行中に集計中ランキングが 表示されないようにしたい ・・・ 集計トランザクションテーブルに 集計ランキング結果を。 集計ステータステーブルに 集計ステータスを。

23. 結論 7/7 フレームワークを使おう。 頭を柔らかくしよう。

24. クラウド上での エンタープライズアプリケーション開発 Force.com 編 松本 幹 MIJS 製品技術強化委員会 17-C-2

25. 環境 CRM SaaS 今回検証に利用した SalesForce.com の サービスは、 force.com Force.com Heroku VMforce

26. 予約システム作成により以下を検証 ① ロック制御ができること ② トランザクションを考慮した 作りになること ③ 読取一貫性に応じた 作りになること

27. Force.com の特徴 ステップ１ MVC モデルを基本とし、全ての UI/ データ操作の ユーティリティが存在する ステップ２ 上級者向けに細かくロジックの修正や追加・削除が 可能 ロック制御もトランザクション制御も、読取一貫性も すべてフレームワークが面倒みてくれる 簡単にアプリを作成できる仕掛けが満載

28. 処理の中核を担う「 Model 」、表示・出力を司る「 View 」、 入力を受け取ってその内容に応じて View と Model を制御する「 Controller 」の 3 要素の組み合わせでシステムを実装する方式。 MVC フレームワークとは？ Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者

29. Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者 ステップ１：ノンプログラミングで開発 GUI からテーブル を作成可能 入力パターンチェック なら Excel と同じ感覚で 簡単に作成可能 最小セットは、 最初から作成済み テーブルを作成すると、自動で作成される

30. Controller View と Model を制御 View 結果画面を表示 Model ビジネスロジックを構築 DB 利用者 ステップ２：上級者向けカスタマイズ 独自ロジックを Java ライクな言語で追加可能 Apex コード Apex コード

31. 例： Apex コード 独自クエリ言語である SOQL をダイレクトに操作可能 作成したロジックを、指定したタイミング （ CRUD 操作の前後）で実施可能 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. まとめ MVC フレームワークを装備し、かつカスタマイズ 性も高く、生産性が高いことを実感 ロック制御・トランザクション制御・読取一貫性 については、何の心配もない

33. CAP 定理上の位置づけ 一貫性 （ C) 可用性 （ A) 通信断耐性 （ P) RDBMS Azure Table AWS RDS BigTable BerkeleyDB MongoDB AWS SimpleDB Azure Storage

34. Amazon SimpleDB の概要 AWS クラウド上で稼働する NoSQL DB( ドキュメント指向 ) Erlang で実装された分散型 DB REST によるアクセスが基本。 Java, PHP, C#, VB.Net API も AWS により提供されている

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 アイテム 最大２５６アトリビュート 最大 1024byte ( テキスト型のみ ) 最大 100 ドメイン アイテム ｘ アトリビュート ＜ 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 のクエリ SQL ライクだが、下記の構文のみサポート クエリ結果は 2500 件以下、または１ MB 以内 クエリは５秒以内 述部 (Predicate) は２０個以内 １述部に 20 比較まで １述部には１ attribute のみ 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. トランザクション概要 トランザクション分離は提供されておらず、 READ_UNCOMMITTED 相当 コミット、ロールバックの概念はない デフォルトの読み取り操作は、直近に書かれたデータを読み取る保証はない。 ただし、 2010 年 2 月より、 Consistent Read オプションを提供し、読み取り時に指定することで読み取り操作以前に書き込まれたデータの取得を保証することができるようになった。

40. Consistent Read: 同時読み書き デフォルト：読み取り 1 は 10,20,NULL のいずれか！ Consistent Read=true ：読み取り 1 は 10 か 20->Tx 分離なし！ 出所： Amazon Web Service

41. Consistent Read: 同時書込み 読み取り 1, 2 ともに CR=true でも値は 10 または 20 ！ クライアントからは書き込み 2 が後に見えても、サーバ側の処理順は異なるかもしれず、結果として、書き込み 1 と 2 のどちらが後かは呼出し側からはわからない 出所： Amazon Web Service

42. 講師予約システム設計ポイント ドメイン間の join Query はできない -> 非正規化し、関連する項目はなるべく１ドメインに統合する ドメイン間のトランザクションなし -> 一貫性を求められるデータは１ドメインに統合する 楽観的排他制御ができるのは 1PutAttribute だけ！ -> 例えば予約と手当は１アイテムに統合すべき

43. 講師予約システム実装方針 ロック制御 予約時にアイテム ID で Conditional Update （既に存在すれば失敗）を行い楽観的排他制御を行う トランザクション 全てのデータを１ドメインに格納 予約と手当は１アイテムとして登録 読み取り一貫性 トランザクション分離がないため、バッチ処理中に書き込まれたデータは除外する必要がある。過去時間でフィルタリングし、実績を集計することにして対応

44. 実装中にわかったこと Item#getAttributes() が返す Attribute の順序は定義順とは無関係 既存のアイテムに put するとバリューは上書きではなく追記 クエリ中に存在しない Attribute 名を指定してもエラーにならない 定型的なスキーマを必要としない柔軟性の裏返し Attribute の Value が Null だと、クエリに指定してあっても SelectResult に Attribute が設定されてこない Value はテキスト型のみで、集計関数がない ソートはサポートされているが、 UTF-8 の辞書順のみで、データ型を考慮したソートはアプリ側に委ねている

45. まとめ NoSQL には RDBMS とは異なる「オプション」が用意されている NoSQL ベースでも工夫次第でエンタープライズアプリケーションは構築可能