tdtshのブログ

IaaSプロバイダはどうやってマーケットを広げるのか？ PaaSレイヤを提供するのは簡単だが、そうすると顧客にはロックインされるという懸念が持ち上がる。顧客が管理の主導権を持てるというIaaSの利点でを維持したまま、どうやってPaaSの利点である、熟練を要する運用業務を顧客から不要にする、ということを提供できるだろうか

その答えは運用を容易にするツールの提供だ。それはIaaS上に用意された、優れた（ベストプラクティスな）インフラで、可用性とスケールを実現するものだ。

これがまさにAWS Elastic BeanstalkがTomcatを用いて行ったことである。

IaaSとPaaSの違いはなくなろうとしている － Publickey

個人的にはベンダロックインよりも、運用がどれだけ容易になるかが最大の関心事だったりする。
運用にもスケールするかどうかが含まれていると考えています。

昨今のWEBサービス開発は、php等のスクリプト言語で作るのがあたりまえです。
初期の開発者の単価が抑えられ、ホスティングサービス等を利用しやすいから。

で、幸運にもWEBサービスが流行ったら、フロントエンドのWEBアプリケーションも色々と性能改善をしつつ機能追加とかするのも大事ですけれど、ある程度の規模を超えるとストレージのレイヤ（データベース側）でがんばってスケールさせる必要が出てくる訳で、ミドルウェア含むインフラ層にもエンジニアを惜しみなく投入して、あの手この手で分散化する必要が出てきます。

最近は知りませんが少なくとも私の知る限り、php は Apache等のhttpデーモン のプロセスまたはスレッドにくっついて動く訳でして、永続的接続とかいう仕組みは有っても、アプリケーション全体でDBコネクションの数を制御したり、プーリングしたり、使いまわしたり、データベースアクセス専門のオブジェクト(DAO)をこさえて使いまわす、なんて事が簡単には出来ない訳でして、そこはもう Java Servlet の方が1階層タンデムな分そこのへんの作りこみが楽だから、ある程度の規模までならデータベースアクセスの観点からパフォーマンス面で有利だと思う訳でして、私がWEBアプリケーションとしてはマイナーな Java を選ぶ理由の1つです。

TCP/IPのコネクションを張るのはそこそこリソースを消費する訳だから、php でApacheのプロセス（スレッド）上減数に合せてコネクションを貼りっぱなし、なんて構成を最初はとったりする訳ですが、RDBMSサーバ側のリソースも結構ふんだんに用意する必要がありますし、規模が大きくなってくると、最近は安くなったとはいえスケールアップさせるのはソコソコ金がかかるんで、水平に垂直に分割したりレプリケートさせたりキャッシュしたりインフラ層でイロイロやらないといけないんで、安定させて性能を出すにはそれなりのコツというか、DBAなんていう職業が成立してしまう位イロイロな匠の技がある訳ですし、24時間365日運用するには、やはり訓練もドキュメンテーションもそれなりに必要になってきます。

で、最初の「運用がどれだけ容易になるか」の話ですが、こういう「インフラ系エンジニア」の下働きは、それなりに優秀な人材を集めなければいけないしコストがかかります。WEBサービスもマネタイズできないと単なるボランティアですからやはり収益性は大事な訳です。

誤解を恐れずに言うならば、インフラ系エンジニアは「システムの能力を最大限に引き出し（必要に応じて向上させて）たり、セキュリティ含むITをとりまくあらゆるリスクを軽減する為にイロイロとがんばる」訳ですが、それで収入が増えるとか言う事は無い、と考えられる事が多いわけです。特に経営層に。

これらはだんだんとコモディティ化してきているから、もし外注できるなら、どうせ金かけるなら優秀なソフトウェアエンジニアを中に雇いたい訳です。サービスをより良くするスピードこそ、競争力であり、収入を増やす為に必要だからです。

こういう事を書くと世の中のインフラ系のエンジニアの方を敵に回しそうなんで一応書いておきますが、価値を生むとか生まんとか以前に情報システムは運用してナンボ、作るだけじゃダメな訳で、運用管理も誰でも簡単に出来る訳じゃないです。Salesforceの様に、運用こそ差別化の最大要因だと言い切ってしまいたい所です。

さらにさまざまな問題を回避する事で、問題が発生した場合に損失しうる企業価値を損なわずにすむという面もありますんで、一概に要らないと言っている訳では無くて、AmazonやGoogleとかが、規模の原理を活かして、自社の優秀なエンジニアと運用のベストプラクティスを、IaaSやPaaSで提供しはじめている訳ですから、少なくともWEBサービスにおいては、ストレージ層も含めて「スケールする」インフラがセットで提供されはじめた今、「事業」として考えた場合、「外注」されやすい分野である事は間違いないでしょう。

要るとか要らないとか言う以前に、土俵というか、世の中のルールというかが変わって来たぞ、と。

そういう観点で、Google App Engine と AWS Elastic Beanstalk を比べると、App Engineの方が楽そうなんだよなぁ。
でも、既存システムの移行の難易度で言うと、格段にBeanstalkの方が楽そうだなぁ。
App Engineの方がスケールしそうだしなぁ。でもAWSの方が自由度高いしなぁ。

と、これからは、クラウドをコーディネートする力が求められそうですね。
纏まりなくてすいません。

久々にERダイアグラムを書く機会がありました。
手元にツールが無くて、何かいいのないか探してたら、よさげなもの発見。

WWW SQL Designer

phpなサーバがあれば、ダウンロードしたzipを展開して置くだけ。
成果物はXMLでExport/Importできる。

今まで紙とペンでやってましたけど、こりゃあ良いです。
がっつり作りたい時はちゃんとしたのんが欲しくなりますが、分析フェーズとかちょこっとER図を書きたい時にはめちゃめちゃ便利です。
ブラウザにブックマークしとくだけですし。

参考サイト

ER図作成ツールを2つ紹介 | アイビースター

ウノウラボ Unoh Labs: ブラウザでER図が描ける「WWW SQL Designer」紹介

floatingdays: WWW SQL Designerのインストール＆設定

RDBMSを長くやっている人ほど、app engineのデータストアの概念で混乱する可能性が高いと思います。
自分もまだ時々判らなくなるので、一発整理しておきます。

まず、Entity (エンティティ) と聞くと、Codd博士のERモデルや、IDEF1Xとかの拡張ERモデルを思い浮かべてしまいます。
いわゆるリレーショナル・データモデリングにおける「実態」を表すEntityは、RDB上のスキーマの設計の元になるもの、と刷り込まれているんです。

ですが、app engine の話をするとき、Entityという言葉は文字通り実体のほう、RDBにストアされた個々のインスタンス、つまり行、タプルをイメージするべきの様です。

私だけでしょうか。微妙に混乱します。

このへんの微妙な言葉のニュアンスから、Entity Group と リレーションを混同してしまうという弊害があるんじゃないでしょうか。
実は私もそうでしたので。

Entity Group は Entity (＝オブジェクト、≒タプル) を保存するときに決まる(決める)もの。
リレーションはデータクラスで定義し、Entityに保存する時に決めるもの。

エンティティグループはリレーションではない

祖先とか親とか子とかいう単語が出てくるので誤解しがちだけど、エンティティグループは、１：多のようなリレーションを表現するものではない。

トランザクションによりACID特性を保障したいときに設定するもの。

リレーションはkeyをコレクションで持ったり、Slim3のModelRefなどを使って表現する。
app engineのエンティティグループ – 理系のためのTIPS集

あとkindという言葉も、これからGAEを学ぼうとする人には鬼門になるかもしれません。

Google App Engineの本とか記事とかを読んでいると良く出てくるんですけど、日本語のGoogle Codeのドキュメントを見ても、kindの説明はありません。原文で読むとなんとなく判ってきます。

整理しておきます。

Entity (エンティティ)
	App Engine データストア内のデータ オブジェクト。
	key と プロパティ がセットされる。
	リレーショナルデータモデルで言うところのタプル。
	RDBMSで言うところの行、レコード。
	Javaでデータモデルを定義し、そのモデルのインスタンスを生成してDatastoreに
	保存したら、それがエンティティ。

プロパティ
	名前のついた値。Entityには1つ以上のプロパティがある。
	そのデータ型は整数、浮動小数点値、文字列、日付、バイナリ データなど。
	Jデータクラスのフィールドと(ほぼ)同義。

データクラス
	Javaでデータモデルを定義たクラス。

kind
	正確にはEntity's kindでしょう。
	Datastoreに保存されたエンティティのデータクラスの種類。
	リレーショナルモデルで言うところのスキーマ。
	RDBMSで言うところのテーブル。

slim3(App Engine/Java)のお勉強をしながら、良くあるパターンのブログサービス的なWEBアプリケーションを作っています。

ブログサービスの概念モデリングは、[ブログ] – [記事] – [コメント] の 3階層で Header-Detailになる事が多いと思います。

今までRDBMSばっかりやってたのですが、過去は3層で考えた概念スキーマをそのまま論理スキーマにしちゃって問題無かったです。

と言うか今でも私は正規化バンザイ派、概念スキーマをそのまま論理スキーマにしちゃえ派です。このへんは佐藤正美さんのT字形ER手法に強く影響されました。

で、App Engineで作ろうとするじゃないですか。
時間が作れ次第おっかなびっくりやっているので遅々として進まない訳ですが。

まずは記事のCRUDを作ってみて、それは上手くいきました。
で、最近やっと後回しにしていたリレーションシップとトランザクションに取り掛かっているわけです。

「Google App Engine （のKVS）では非正規化を恐れるな」なんて聞いていたものですから、記事Entityの親にあたるブログEntityについては、記事Entityの中に「ブログ名」として繰り返し項目にしちゃえばいいかと、結構簡単に考えていました。

で、いざやってみると、使い物にならない感じなんですね。

まず、記事Entity内で繰り返し項目になっちゃった「ブログ名」を、Distinctして取得したいと思ったんですが、Slim3では（App Engineでは）出来ません。

ならばGroup By で、とも思ったんですが、それもありません。

マニュアルは一度読んでるし、GAEの本も2冊ばかり読んだんですが・・・なんとなく判った気でいるのと、実際に手を動かして困ってみるのとでは、頭に入り方が大違いですね。

ならばと、Slim3の機能を使ってブログEntityと記事Entityを双方向1対多関連にしました。

これで目出度く ブログの一覧は取得出来る様になりました。当たり前ですが。

仕様として、記事Entityは、親であるブログEntity（カテゴリ）の変更というか、付け替えが出来ます。

普通にトランザクションでこれをやろうとすると、com.google.apphosting.api.ApiProxy$ApplicationException がスローされました。

これは自分のコードの書き方が悪いだけでして、異なるEntity Group での更新をしようとした事が原因、という事まではすぐに判りました。

本題はココからでして・・・

ブログEntityはオーナーだけが変更できます。
記事もオーナーだけが書けます。

RDBMS脳では、[ブログ] – [記事] – [コメント] の 3階層 の外側に、[オーナー]Entityがいて、[ブログ]の外部キーになっているか、[オーナー・ブログ]連関テーブルがあるか、そんな感じです。

App Engineでは同一Entityグループでしかトランザクションが使えない。
Entityグループが同一なら物理的な格納位置が近くなる（らしい）。

もしかして、[オーナー]でEntityグループをくくった方が良いのか？？？？

[オーナー] – [ブログ] – [記事] – [コメント] の 4階層？？？

Hibernate的に考えると、オーナークラスのプロパティでブログをSetとかのコレクションクラスで持たせてlazy loadingさせて、あとは記事、コメントと・・・そんな感じ？

それでスケールするのか・・・・？

この4階層の論理スキーマで良いのか、自信が持てないです。 <- イマココ

幸い、Slim3には「グローバル・トランザクション」なるものがあり、異なるEntity Group間での更新も出来る筈です。（まだ試していない）

一貫性を重視するか、スケーラビリティを重視するかで、論理スキーマが変わってきそうな気がします。

もうしばらく悩みそうです。

マイクロソフトのAccess 2010では、ODBCを通じてクラウド上のリレーショナルデータベースであるSQL Azureに直接接続可能だと、MS Officeチームのブログのエントリ「Access 2010 and SQL Azure」で紹介されています。
Access 2010 and SQL Azure – Microsoft Access – Site Home – MSDN Blogs

この機能を使えば、社内でSQL Serverの運用をすることなく、Access 2010から大規模なリレーショナルデータベースの機能を利用することができるようになります。」

Access 2010からODBCでクラウドのSQL Azureに接続可能。そのメリットは？

JetエンジンのままAccessを多人数で使うのは、排他制御の面でも、性能の面でも、あまり宜しくないんですけど、現場によっては結構重宝されていますよね。

自動でシュリンクしないからファイルがどんどん肥大化するし、しょっちゅう壊れるし。
せめてMSDE、今で言うとSQL Server Express Editionですかね、を使って欲しい訳です。

データベース管理者にとっては、SQL Serverのデータメンテナンスなど管理業務をAccessから行うことでずっと便利になるという指摘もいただきました。たしかに、それもぐっと楽になりそうです。

ODBCドライバさえあれば、OracleでもDB2でもデータ管理は出来ますね。
SQL大好きな私にとってAccessのクエリを使うのは苦痛なんですけど、エンドユーザにはGUIで操作できるAccessは結構使いやすいみたいですね。

RDMBSはコモディティ化した感があります。
今後のデータストアのプラットフォームは、完全にクラウド上での覇権争いになってきました。
KVSで無くRDBMSじゃ無いと駄目な案件を、SQL Azure と VM Forceが受け皿になっていきそうな予感。

どうするOracle陣営。