A-Listers

David Heinemeier Hansson氏（Railsの開発者。以下DHH）が37signalsのブログに公開したRunning beta in productionというエントリによると、同社ではBasecampの開発に使われる6つのベータサーバーがすべて単一の本番環境のデータベースを参照して動いているそうです。

DHH氏曰く、「自分がいいアイデアだと思ったものが本当にそうなのかを知るには、実際のデータを対象に自分たちが日々使ってみることが必要」とのこと。

Basecampでは新機能や改良の開発、技術的なアップグレードなどを継続的に行なっており、そのために同一の本番環境のデータベースを参照する6個の異なるベータサーバーが運用されています。通常、開発中の機能は開発用のデータベースと共に運用するのがセオリーだと思いますが、DHH氏は「実際の重要なデータとともに不満を感じながら使わないかぎりは、そういった機能をきちんと評価することは不可能だと気づいた」とのことで、このような構成になっているそうです。

最初は、実際にサービスの運用に使っているものとは物理的に異なるサーバーに本番のデータを複製しているのではないか、とも思ったのですが、コメント欄にて「All beta envs and production share the same prod database.」という37signalsスタッフのコメントがあるので、やはり実際にサービスで利用しているデータベースにベータサーバーを接続しているということで間違いないようです。

また、6つのベータサーバーをどのように使い分けるのかの手順はシンプルで、どのサーバーでどのブランチのコードを走らせているかは、開発者が適宜、開発用のチャットルームのタイトルに反映させているそうです。ブログエントリに掲載されたスクリーンショットでは、以下のようなルームタイトルになっていました。

• staging: riakcs
• beta: project_templates
• b1: redis-resque-upgrade
• b2: tags-mini
• b3: bcx-ios-compose [reserved for bcx-ios]
• b4: email-in-phone
• b5: rails4

エントリではstagingの位置づけには触れられていませんが、それ以外のbetaからb5までのサーバーはすべて本番のデータベースに接続していると考えてよさそうです。

開発者は、ベータサーバーが必要なときはルームタイトルの「b1」の部分を「b1: redis-resque-upgrade」のようにサーバー名とブランチ名に書き換え、ベータサーバーでの作業が終わったら「b1: available」のように変えることで、シンプルに運用しているようです。

このようなスタイルの運用で気になるのが、データベースマイグレーション（スキーマの変更など）をどのように適用するか、というところだと思います。

それについてはコメント欄でいくつかやりとりがされていて、基本的には、

• 本番データベースに接続されたステージング環境でマイグレーションのテストを行う
• その後、それを本番環境にもロールアウトする

という運用のようですが、この際、ステージング環境が接続する本番データベースというのが、本番データベースの複製なのか実際に運用しているデータベースそのものなのかについては残念ながら言及がありませんでした。

個人的にはかなりアグレッシブな運用だと感じたのですが、データベースマイグレーションを注意深く行うようにすればアリなのかもしれませんね。

サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。

ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない

このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。

• 当初は有益だが、長期的にみると良い結果以上の悪い結果を招く。
• 確証があり繰り返されている別の解決方法がある。

当初は良さそうに見えたORMがいざ使ってみると問題が明らかになり、しかもその時には切り替えるわけにもいかなくなるというのが彼の主張です。彼による皮肉がたっぷりの論説の最後に付いていたまとめリストは下記のとおり。

• ORMはSQLベースのモデルよりも最初のうちはシンプルで理解しやすく、手早く書く事ができる。
• 効率はどんなプロジェクトでも最初の頃は十分。
• 不幸にもそれらのアドバンテージはプロジェクトが大きく複雑になると消失し、抽象化は破綻し、開発者はSQLを使わなければならなくなる。
• ORMの抽象化はほぼ100％のプロジェクトで破綻する。
• オブジェクトはリレーショナルなクエリの結果を表現するのには不適切。
• 不適切にクエリをオブジェクトにマッピングすることによって、ORMを廃止しない限り簡単には修正できない非効率性がアプリケーションのあちこちにばらまかれる
• リレーションを保存する代わりにORMを全てに適用する場合、設計をよく考える必要がある。
• データが元々オブジェクトならば、NoSQLにオブジェクトを記録する方がリレーショナルデータベースよりも早い。
• データが元々リレーショナルならリレーショナルデータベースに対するオーバーヘッドになるだけ。
• リレーショナルなクエリはモデルレイヤーに隠蔽する。ただしAPIの設計は汎用化の誘惑に打ち勝ってアプリケーションに必要なデータを返すようにする。
• オブジェクト指向設計はリレーショナルなデータを効率的に表現できない。これはORMが解決できないオブジェクト指向デザインの根本的な制限だ。

ORMを使った事がある人にとっては心当たりがありまくりな主張ではないでしょうか。意外と長文なんですが原文を読んでもらう方がORMが良さそうにみえて問題が起こり、そしてその解決方法などのより正確な主張がわかります。また元の記事には現時点で47のコメントが付いており盛り上がっています。
さて、みなさんはORMを次のプロジェクトでも使いますか？

via:http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

関連:
データベースの間違った使い方10項目 « A-Listers
いきあたりばったりのアーキテクチャと教訓 － Publickey

一般的なシステムで広く利用されているリレーショナルデータベースですが、システムの進化と共にデータベースの構造も複雑になりがちです。RestMQの作者、Gleicon Moraes氏の公開したスライドがシステムが複雑化していく様子をわかりやすく説明した上で「アンチパターン」を提示していました。

それによるとデータベースのアンチパターンは以下の通り。

• 動的なテーブルの作成
• テーブルをキャッシュとして使う
• テーブルをキューとして使う
• テーブルをログとして使う
• 分散したグローバルなロック
• ストアドプロシージャ
• 使われない項目
• JOIN地獄
• ORMによって繰り返されるクエリ
• 負荷のコントロール

どれも理由があって採用されるデザインですが、確かに後に問題を引き起こした経験もあり耳が痛い感じですね。スライド内ではそれぞれの問題についての解決策としてMongoDBやRestMQなどの利用を進めています。「本来の使い方をしていない」という事の例として「レースカーのようにドリフトする鴨の画像」が使われていたのもユーモラスです。

他のページの画像も面白くタメになる内容なのでご覧になってみてください。

via:http://www.slideshare.net/gleicon/architecture-by-accident