uehaj's blog

Grな日々 - GroovyとかGrailsとかElmとかRustとかHaskellとかReactとかFregeとかJavaとか -

JJUG CCCいってきました

JJUG Slim3 Grails Cloud

JJUG CCC Springに本日行って参りました。
はっきり言って大変参考になりました。心底面白かったです。発表者の皆さん、JJUGの幹事／運営の皆さまありがとうございました。

以下、聴講させていただいた幾つかのセッションについてメモを書いたのでおいておきます。正確ではないことに加え、脳内補完してるので、発表内容と異なる可能性があります。あしからずご了承ください。
あと、都合にて午前中のセッションは聞けませんでした。残念。基調講演も聞きたかったのにー。

Agileモデリング for Cloud/浅海さん

Cloud Grails GAE

本エントリは、エントリ「JJUG CCCいってきました」の一つです。セッションのメモ書きです。元の発表資料: B-2.pdf

(すんません、途中から入りましたのでメモも途中から）

  • SimpleModeler
    • CSVをScalaDSLに変換
      • マインドマップに変換
      • Grails Domainクラス定義(Groovy)に変換
      • GAE/Pythonアプリに変換(DjangoのView/Controller)
      • GAE/Jアプリに変換
      • クラス図に変換
      • ステートチャート図(ガード付きネストあり)に変換
  • まとめ
    • UMLを使ったMDAはうまくいかない。UML図書くのは面倒だから。
      • text/DSLならうまくいく（はず）
    • 実装技術がかわっても業務システムを移行させることができるのは画餅ではない実際の利点 
 [感想] 私見として思うUMLの他の問題は、実行可能ではなかったこと。
       UML2.0で実行可能性のために、OCLが持ち込まれて複雑怪奇化した。
       SimpleModelerではOCL相当情報は不要なのか？(それで実行可能か？)
       CRUDだけのScaffoldは実アプリケーションと言えない。
       ER図相当なものだけが引き継げてもあんまりうれしくない。
       あとラウンドトリップ開発は？

全体感想

Cloud

本エントリは、エントリ「JJUG CCCいってきました」の一つです。

感想を一言で言うと：

１０年に一度の技術の大転換点キター。

クラウドコンピューティング、というより正確にはGAE/J的な非連続的クラウドコンピューティングについて、と言った方がいいのだが、感じるのは、さまざまなピースがぴたっとはまり始めているということ。複数のトレンド(Grid、仮想化、P2P、DSL、)が合流し、１カ所に力が集中し、ある水流が水柱として天に立ち上がっていく光景を想起する。ちなみに同じ種類のものを前回感じたのは、90年代末期のJava OneとかJava Business Expoとか。

一個一個のバズワードが、振り返ってみると歴史の必然として整理され直されて、「堰を超えようとする瞬間の力の張りつめ」を感じる。これだからIT業界はやめられない。

「堰」っていうのは、具体的に言うと「RDBMSの怨霊」、もっと長期的に言うと「ダートマスからの脱出」じゃなくて「フォン・ノイマンの呪縛」。真の並列コンピューティングの時代がやっと始まったのだ（たぶん）。

GAE上でスケールするWebアプリを書くには/サイオステクノロジー松尾さん

GAE

本エントリは、エントリ「JJUG CCCいってきました」の一つです。セッションのメモ書きです。もとの発表資料: A-3-1.pdf, A-3-2.pdf

スケールするために

  • 無駄な繰り返しを避ける
    • 繰り返されるクエリ結果はmemcacheでキャッシュする(読み込みデータのための)
  • 大きなリザルトセットは避ける
    • メモリ上で大量のデータのソートやフィルタはしない。小さくとって、小さく処理。

チューニングのために知っておく方がいい数字

  • 書き込みはコスト高い。ほんとの最低でも1ms。データ量に応じさらに悪化。
  • 読み込みは速い。25micro second。1秒に4GBのスループット。

EntityとKind

  • 実体は「分散ソートアレイ」と呼ばれるもの。多数のマシン上で実行。
  • EntityはKeyとvalueをもつ。
    • valueは、プロパティのキー+バリューをずらりとシリアライズして突っ込んでいるだけ(たぶん)。検索はindex経由で(indexが張れるのはblob, text以外のデータ型)。
    • keyは（１）Kindのクラス名＋ID、（２）文字列型のいずれか。後から変更不可。500バイト制限がある。
  • 関連はRelationプロパティで表現
    • OneToMany, ManyToMany可
    • 癖がある。単純なリレーションではない。

EntityGroup

  • 親子関係
  • 書き込みに関してEntity Group単位で排他制御される。
  • 書き込み排他の実現方法はロック（＋解除されるまで待つ）ではなく楽観ロック＋自動リトライで実現（root Entiyに最終更新時刻を記録し、書き込み前に取得した値から変化していれば自動リトライ）。コード上は意識しなくていいが、競合が頻発すると遅くなるorタイムアウトを引き起こす。

EntityGroupの落とし穴

  • 大きく作ると遅くなる(EntityGroupに含まれるデータ量が多いと同時アクセスが生じる確率が高まり遅延の確率が高まる)
  • データの利用パターンに合わせて小さくする。
  • Entity Groupをまたがったクエリはロックされない。 (疑問：Entity Groupをまたがるということはクエリ対象が別マシンにまたがる可能性もある？分散クエリになって遅くなる可能性もある？）

カウンタを作ってみよう

  • Memcacheは駄目。1000件しかクエリできない。
  • Entityを使う。しかし頻繁にupdateされると遅い。
    • →「分散カウンタ」。同じEntityGroupに所属しないn個のカウンタを作って、インクリメントする際にはランダムにn個のうち１個を選んで増加。カウント値を得るときにクエリして合計する。

ブログを作ってみよう

  • エントリに関して
    • ページネーションは難しい。EntityのKeyのIDは重複はないが番号が飛ぶ（稠密ではない）のでページングには不適切。
    • エントリをブログ全体の子供にして、ブログに番号を持たせる。
      • → 記事の投稿は頻繁ではないのでOK。
  • コメントに関して
    • エントリと同じ方式だと、炎上したときなどに大量コメントの登録更新が遅延して困る。
    • 「時刻+ユーザ名+コメントID」をキーとしてソートする。コメントIDのカウンタをユーザの子にしてGroup化する。
      • → 同じユーザが頻繁には投稿できないのでOK。

GAEのPython版とJava版の違い。

  • Pythonの方が優れているところ
    • 一年前からやってるから機能的に多い。
      • ランチャがある(MacOS用のみ)
      • ローカル環境の(秘密のURLで見れる）admin画面/APIがある
      • Remote API/一括アップロードAPIがあって、速い。
    • 動的言語の利点として
      • Expandoで動的プロパティ追加サポート。
      • PolymorphicQuery可(親クラスに対してクエリすると子クラスもとれる）
    • 記述量小。
    • 起動速度(ワームアップ)速い
  • Javaの方が優れているところ
    • Embededクラス（インクルード）
    • OwnedRelationを設定するとEntity Groupが設定。親を消すとカスケーディング自動削除(JDOレイヤで実装されているので、低レベルAPIでは対応しない。またadmin画面でも対応しない)
    • 実行速度速い
    • Python版には「トランザクション内ではクエリ不可」という制限があるのでキー取得を外でやる必要があるが、Java版ではJDOで隠蔽されている。
 [感想] 本編もPython系との比較編も大変に面白かった。
       GAEならではの難しさはある、という話だが、
       聞いた限り手に負えそうな感じ（根拠なし）。
       ただ確かに、RDMSチューニングの話で感じるときのある
       「バッドノウハウの集積体／集合体／集大成的感覚」
       に比べて、プログラミング的に
       知的で健康的で面白い、やりたい〜という
       気になる。

Slim3 for GAE/J ひがさん

Slim3 GAE

本エントリは、エントリ「JJUG CCCいってきました」の一つです。

（補足）のところが主に自分で考えたところ。でも他にも暗に補完してると思うのでそこんとこよろしくお願いいたします。

はじめに

  • Amazon EC2は仮想化サービスであり既存技術と連続
  • Google AppEngineは既存技術に対する制約が大きく連続性がない

制約とは

  • Threadが使えない
  • ContextClassLoaderが使えない
  • セキュリティが厳しい。seculity.policyの設定が厳しい。
    • → Spring 2.5からコンポーネントスキャンというのをやってアノテーションを読み取るのだがそれは動かない。
    • Struts2の式言語はOGNLを使うがセキュリティマネージャを設定していると駄目
      • → nullにすれば良い
  • ファイルに書き込みできない
    • Apache Commonsのファイルアップロードはテンポラリファイル書き込みがデフォルトなので動かない。Commons upload 1.2.1では、なんとかイテレータ使えばメモリ上でストリーミング取得できる。

常識もかわってくる

  • 従来、セッションはメモリを食うから多用するなというのが常識だったが、GAEのセッションはMemcacheサービスを介してBigTableに保存される。ので、どしどし使っていい（かも）。

GAE登場に伴うフレームワークの位置づけの変化

  • 高度なことをやればやるほどローカルと本サーバの違いに遭遇しやすい。
  • DIもなくていい
    • でもテストは？
      • → アプリのレイヤで試験の仕組みを作り込まなくてもGAEがある程度サポートするのでDIがなくても試験はやりやすい。たとえばGAEでは
        • ローカルでクエリできる。
        • スタブ（モック）の仕組みをGAEが既に持っている。
        • BigTableはローカルではある種のメモリ上DBで動作するのでデータの消去が簡単。
        • 実環境上ではGoogleアカウント、ローカル環境ではあるアカウントを表すクラスにスタブ（モック）される。
  • スキーマのマイグレーションはいらない。なぜならスキーマがないから。(補足)
  • ORマッピングやDBの差異に関する相当な問題が解決される。(補足)
  • FWないので見通しが良くなる
  • FWなしでも生産性低くならない。
  • ただ、上記は「現在の」GAE/Jが、プレビュー段階でありドキュメンテーションおよび機能が成熟していないことによる。現状では高機能なFWではまって問題追求するようなコストがかかるので、それをさけるための判断として、である（長期的にもこうであるとは限らない。）

Slim Struts

  • Slim3はSpring対応だったが、Slim3 for GAEはSpring使用しない。
  • AOPなし、DIなし。
  • （ローカル実行時の）ホットデプロイはコントローラのクラス(ActionClass)のみに限る。（ユーザ定義クラスのホットデプロイはContextClassLoaderの制限があるのでできない）
  • 設定ファイルレスでアノテーションベースでサクサク開発できる

JDOとJPA

  • JPAは、RDBMSを抽象化して差異を吸収する。対象はRDBMS。
  • JDOは、永続化を抽象化する。いままでもRDBMSに限定されていなかった (実体としては主にRDBMSを対象としていたが）。今回、DataNucleousの人たちがBigTableに対応させた。
  • なのでBigTableにはJDOが向いている。現状のJPAはほんとに「似せただけレベル」にちかい。いずれにせよごく一部しか使ってない。

JDOについて

  • JDOはいままでマイナーなものであった。
  • JDOの仕様は結構大きい(JPAと同じぐらい)が、GAEで使う限り、知るべきことは限定的(APIを10個ぐらい覚えておけば用が足りる)。
  • JDOメソッドの基本（主に使うものはこんだけ）
    • makePersistant(INNSERT/UPDATE)
    • deletePersistant（DELETE）
    • query(クエリによる検索)
    • get(キーによる検索)
  • JDOアノテーション。こんだけですよこんだけ(主に使うのは)。
    • @PersistanceCapable
    • @PrimaryKey
    • @Persistant
    • @NotPersistant
  • 永続化対象
    • 数値はプリミティブも可だがnullになれるのでWrapperおすすめ。
    • char型だめ。String使う。Unicode2.0のサロゲートペアの関係か？(補足)
    • BigDecimal, BigIntegerだめ。
    • enum全然おっけー。ちと意外。
    • 日付に関しては、java.sql.*はだめ。JDBCがサポートされてない。
      • → H2の人たちがJDBC/BigTableを作ってる。
        • → でも、その上にORマッピングを動かすのはいかがなものか？

BigTable

  • 複雑なクエリは使えない（ORとIN、NOT EQUALが使えないよ）
  • なので自然とJavaで処理することになる。その結果見通しは良くなる。
    • CPUパワーはスケールする。複雑なクエリはスケールしない。(補足)
  • トランザクションは親子関係を持ったエンティティ間のみ

Slim3JDO

  • LocalJDOTestCase
    • GAE提供のテストクラスのサブクラス
    • DBの後始末処理をしてくれる。
  • JDOTemplate
    • 宣言的トランザクションではなく、インナークラス定義を持ったメソッドで実装する。
      • toLong()といったnullを考慮した変換メソッドなどもあるよ
    • 流れるようなインターフェース
      • JavaによるDSL
      • aptをうまく使ってコンパイル時にメタデータを生成(補完にも利用)。
      • タイプセーフ。IDEでメソッド名補完。

GAE/Jでの開発の仕方

  • ERモデリングはいらなくなる（スキーマないので）。
  • コードがJavaに集約される。
  • 快適。
  • シンプルなFWでよい。FWなくてもいいぐらい。
  • FWの意義が減る。GAEプラットフォームの機能で代替されるということか（補足）

その他TIPS

  • Eclipseプラグイン使うべき。
    • → 「ホワイトリスト」という機能がありGAEで使えないクラスを使うと警告してくれる。 (こんだけのためでも使う価値あり)
  • GAEアプリはディレクトリ構成が決まっている(src/,war/)。Mavenを使うとはまりがちなので正式サポートされるまで待った方がいいかも。でも、Googleの人はmavenが嫌いかも。antとかシンプルなのが好きかも。
 [感想] 興味の主眼であります。
今、GAEのドキュメント読みはじめたんですが、
水先案内的実用情報として役立つことこの上無し。
Slim3 for GAEについては便利なライブラリ的に
つかえそうに思った。

Grailsでシステムを作る感覚/山田さん

Grails

本エントリは、エントリJJUG CCCいってきましたの一つです。セッションを聞いてのメモ書きです。元の発表資料：BOFB-1-4.pdf

前置き

  • Grailsではドメインクラスからトップダウンに生成するのでRailsよりGAEに対して相性がよい。
  • SunがOracleに買われた話とGAE/Jが話題ですね

ドメインとは

  • ドメイン＝支配。同じ宗教を持った人の国。同じ性質を持ったものの集合。
  • 典型的なドメイン3つ：
    • (1) 問題ドメイン(何かを売りたい)
    • (2) 解決ドメイン(ソフトウェアをどう作ればいいか，ハードは、認証は、技術)
    • (3) プロセスドメイン(開発プロセス)

開発者の仕事は(1)と(2)の橋渡し。Javaを書くからお金がもらえるのではない。
(1)を(2)に変換するという仕事。

  • Grailsで開発するときに最初にすること：ドメインを見つける。
    • (1)ワークフロー，組織構造
    • (2)データ構造、画面遷移
    • (3)テスト方法、構成管理
    • アプリケーション固有のドメイン

何を対象とするの？という話。

  • Grails組み込みのドメインの例（Grailsそのものは解決ドメインに属する）
    • core logging urlmapping, ..

ドメインを表す言語(DSL)を作ろう

    • 概念クラス（ドメインクラス、モデル）はGrails組み込みで用意されている
    • ワークフローは作らないとならない。
    • マスタ画面テストは概念クラスの言語を流用できる？
  • 「DSLを作る」＝ドメインを定義する、ということの具体的な形。
  • DSLは組み合わせられる。概念クラスを定義するためのDSLに制約やORMのDSLを組み込める。

DSLによる仕様と実装の分離

  • DSLは実装方法を含まない。「What」しかない。実装方法、すなわち「HOW」は、
    • 既にあるJava技術でまかなえないか
    • NO→JVM上の他の言語技術でまかなえないか
    • NO→JVM上じゃなくてもいいから他の言語で
    • NO→自分で作る（GroovyだからDSL実現サポートあり）
  • できたDSLの処理系を使って、「仕様をコンパイル」して実システムを作る。
  • 「what+how+アダプタ」＝プラグイン
  • プラグイン分類(MDAを参考に)：
    • プラットフォーム独立プラグイン
    • プラットフォーム特化プラグイン
  • システムを作る＝ドメインを作りくみあわせる
  • 現実の問題に近いドメインは再利用しやすい(本当か？)

DSLを介して役割の分担が実現される

    • 言語仕様(DSL仕様)設計
    • 言語処理系(プラグイン)の実装
    • 業務を記述する(ドメインを書き下す)
    • システムを構築する（ドメインを組み合わせる）
 [感想] Grailsについて、自分にとって新たな
視点で大局的概観が得られた。こういう話がで
きるのは今、山田さんならでは。
ただ、現実と理想は違うとは思うけど、
理想の話も重要。理想の話が重要。