QCon Tokyo 2009 参加レポート

DSLとは

Fowler氏が定義するDSLとは、以下の4つを満たすものです。

• 言語である
• 計算プログラムである
• 表現力が限定されている（汎用プログラミング言語と比べて）
• 特定のドメイン（問題領域）にフォーカスしている

DSLを使うと、JavaやC#のような汎用プログラミング言語で記述した場合に比べて、特定の問題の意図をより明確に表現できます。汎用言語の代わりにXMLを使う方法もありますが、XMLではまだまだ読みやすいとは言えません。

外部DSLと内部DSL

DSLの作り方には、「外部DSL（external DSL）」と「内部DSL（internal DSL）」の2つのアプローチがあります。

外部DSL

DSLを実行する専用の言語処理系（コンパイラなど）を独自に作る方法。完全に自由に言語設計できるが、実現するハードルが高い。

内部DSL

既存の汎用プログラミング言語（ホスト言語）の記述力を使って、擬似的にDSLのように見せる方法。DSLの表現力はホスト言語に縛られるが、比較的容易に実現できる。

Rubyは内部DSLを作るのに非常に適した言語ですが、Javaでも「流れるようなAPI（fluent API）」を使って実現できます。

DSLの実行方法

DSLの実行は一般に、まずDSLを解析して意味論モデルを作り、次にそれをコンパイルして実行形式にする（コンパイル型）か、意味論モデルを直接実行する（インタプリタ型）、という流れになります。

言語処理系というとコンパイル型が中心ですが、DSLでは簡便なインタプリタ型の方が流行るだろうとFowler氏は言います。内部DSLであれば、アプリケーションのドメインモデルにDSLの変換ラッパを被せるだけで、インタプリタ型のDSL処理系が出来上がります。

また最近では、「言語ワークベンチ（language workbench）」という面白いDSLツールが登場しています。言語ワークベンチとは、ソースコードでなく意味論モデルが中心にあり、そのモデルをソースコードやUML図など様々なビューに投影（projection）して編集するツールです。まだ実用段階ではありませんが、Intentional Software、JetBrainsのMPS（Meta Programming System）、MicrosoftのOslo、Xtextなどの製品があります。

DSLはユーザが「書く」ための言語ではない

最後にFowler氏が強調したのは、DSLはビジネスユーザが「書く」ための言語だ、という誤解です。これは幻想でしかなく、本当に重要なのは、ビジネスユーザが「読める」という点にある、とのことです。つまり、DSLはシステム開発の一部をビジネスユーザに任せるためのものではなく、ビジネスユーザと開発者とのコミュニケーションを促進するツールなのです。

Amazonのビジネス領域と、提供するWebサービス

Amazonは元々ネットの本屋として登場しましたが、今やクラウドの一大プレイヤーにもなっています。そのため、筆者はAmazonのビジネスがよく分からないでいたのですが、Barr氏はAmazonのビジネスを明確に以下の3つだと定義していました。

1. オンライン書籍販売
2. マーケットプレイス（古本流通市場）
3. Amazon Web Service（AWS）

AWSでは、以下のサービスを提供しています。

• EC2 … 仮想サーバホスティング
• S3 … 分散ストレージサービス
• SQS … メッセージキューサービス
• Cloud Front … コンテンツ配信ネットワーク（CDN）
• Elastic MapReduce … Hadoop ^*1 にビジュアルなインタフェースを提供するサービス

事例紹介

大手企業でS3を採用した事例として、New York Times（NYT）の過去記事閲覧サービスが紹介されました。これは、半世紀以上前からの古い新聞を、紙面をそのまま画像スキャンした形で閲覧できるサービスです。過去記事データのストレージとして、S3が使われています。

NYTのような大企業でもクラウドの利用が進んでいることに筆者は驚きましたが、考えてみれば過去記事閲覧サービスはNYTにとっての中核ビジネスではありません。万一サービスが停止しても、それほど企業価値が損なわれないものとも言えます。米国においても、まだまだそういったリスクの少ないところからの導入が中心なのだな、という印象を受けました。

ThoughtWorks社のRubyプロジェクト

TWは、2006〜2008の3年間で、41件のRubyプロジェクトをやっています。規模の平均は20人×1年間（＝240人月）で、もっとも大規模なプロジェクトは自社製品Mingle（アジャイルプロジェクト管理ツール）の開発プロジェクトで、約20人×30ヶ月（≒600人月）です。

Rubyは本当に使えるのか？

「次もRubyを使いたいか？」との質問をプロジェクトの参加メンバに聞いたところ、Yes＝36人、No＝5人でした。Noと答えた人の理由は、「Rubyを導入しても生産性が変わらなかった」「他システムとの統合が面倒くさい」「社会的な原因から」というものでした。

こうした経験から、Rubyは簡単、柔軟で、効率性が高く、アジャイル開発に非常に向いていると言えます。ただし、Rubyを導入する際は、以下のポイントが重要です。

• Rubyを導入してから実際に生産性が向上するまでには、必ず生産性が落ち込む「谷」がある。それを予期すること
• 「谷」を緩和するには、経験者をチームに入れることが重要。とくに、動的言語での設計経験、メタプログラミングの経験が重要
• メタプログラミングの濫用は控えること。また、標準クラスライブラリの恣意的な拡張（monkey patching）は控えること。もし拡張したいなら、拡張したことが明確になるように、module を class_eval を使って追加した方がよい

Rubyのコードベースは扱いにくいのではないか、という意見もあるようですが、実際にはそのようなことはありません。ただし、最初は優秀なメンバで構成された小チームで始めて、次第にコードベースを大きくしていくのがいいようです。

Rubyのパフォーマンス

Rubyは確かに遅いです。しかし、パフォーマンスの問題はDBアクセスに起因するものがほとんどで、システム全体で考えればRubyによる影響は低いと言えます。

Mingleは確かに遅く、高性能なマシンでないと動きませんが、その代わりにチームの生産性は高くなっています。製品が高性能なマシンを必要とすることと、チームの生産性を上げることとの間にはトレードオフがありますが、Mingleチームは生産性を優先しています。マシンの性能向上ペースは速いので、長い目で見て製品の遅さは問題にならないとの判断からです。

ActiveRecordに関するノウハウ

ActiveRecordを使ったデータアクセス層のテストをどうするか、という問題があります。テスト対象メソッド以外でも実際にDB接続すると遅いため、TWではメソッド単位でスタブを作ってテストをします。この方法で、Mingleでは2000テストが10分ほどで終了します。

ActiveRecordはデータアクセス層を抽象化できるのがメリットですが、パフォーマンス上の理由から、だいたい20％は直接SQLを書きます。抽象化が一部崩れてしまいますが、ある程度は仕方ないものと認識しています。

クラウドを支配する「CAP定理」

クラウドの技術的特徴は、拡張性（Scalability）と可用性（Availability）です。拡張性の実現には、スケールアップよりスケールアウトが重要になります。可用性を実現するには、複数のレプリカを作り冗長化する必要がありますが、そのとき整合性（Consistency）が問題になります。

「CAP定理」とはUC BerkleyのEric Brewer教授が考案した定理で、Consistency、Availability、Partition-tolerance（分割耐性）のうち2つの性質しか両立できない、というものです。クラウドでは分割（「P」）は必須なので、アプリケーションに応じて「C」と「A」のトレードオフをしていかなければなりません。

「クラウドはエンタープライズの基幹システムには向かない」「クラウドはコンシューマ向けのもの」というのは誤解で、「C」（整合性）優先なのか「A」（可用性）優先なのかをしっかり認識することで、エンタープライズにクラウドを採用することも十分可能です。

「結果整合性（Eventual Consistency）」という考え方

整合性については、「結果整合性（Eventual Consistency）」という概念が重要になります。これは、一時的に不整合が発生することはあっても、一定時間経てば整合性は回復し、長い目で見れば整合性が保たれているという性質です。MicrosoftのAzureは、アーキテクチャレベルで結果整合性を実現する仕組みが採用されています。

結果整合性の概念は、eBayアーキテクトのRandy Shoup氏のセッションでも登場しました。クラウド技術者の間では、すでに共通認識となっている概念のようです。

ACIDに代わる「BASEトランザクション」

DBトランザクションについては、ACID ^*2 の代わりに「BASEトランザクション」という概念が重要になります。BASEとは、以下3つの性質を指します。

Basically Available

基本的に可用性を優先する。

Soft-state

（HTTPプロトコルのように）状態は外部にあり、外部入力を受け続けることで正しい状態が得られる。

Eventually consistent

上記の結果整合性のこと。

たとえば、クラウド上で並行処理をする場合、可用性を上げるためには、いかに排他ロックを掛けない設計にするかが重要になります。この場合、アーキテクチャにキューを導入することで、可用性を優先しつつ、並行処理の順序性を実現できます。

クラウドのACID属性については、GoogleのGregor Hohpe氏のセッションではBASEとは異なる概念が提案されています。ぜひそちらも参照してください。

世界的不況の中で求められるもの

昨年来の世界的不況により、企業のコストカットが進んでいます。その流れから、エンタープライズ開発ではシンプルなものが好まれるようになります。YAGNI（You Aren't Gonna Need It）で必要なものだけを作る「リーン開発」が今後さらに普及するでしょう。

これから重要になるのは「開発者」です。90年代までは、IBM、Sunなどシリコンバレーのベンダが主導権を握ってきましたが、現在は技術的な選択肢が膨大なため、それを取捨選択する開発者が主役になります。

OSSもさらに普及するでしょう。OSSは、コミュニティベースで開発されるため、本質的にシンプルなものだけがコミュニティに受容され、生き残るからです。OSSの時代には、国の違いが重要でなくなる一方で、言語の違いは非常に重要になります。

Springの今後の戦略

Springが今後取り組もうとしている課題は、以下の通りです。

• Javaの開発やデプロイの簡素化
• Java開発の「大きな絵」、統一されたビジョンの提供

Javaの開発／デプロイは、Ruby on RailsやDjangoに比べると、まだまだ複雑です。Springは、Grails、Spring tc Server／dm Serverなどに力を入れて、この課題を解決しようとしています。

Javaには非常に多くのOSSの選択肢がありますが、Microsoft Visual Studioのような統一感が欠落しています。部品同士が緊密に調整されることで、心地よく高級感ある乗り心地を実現するトヨタのLexusのような、「大きな絵」＝統一されたビジョンがJavaには必要です。Springは、そうしたビジョンをJava開発者に提供するプレイヤーになることを、今後の戦略としています。

エンタープライズJava開発も、これからはリーンの時代になるでしょう。

新しいACID

プラットフォームとしてのインターネットは、疎結合、拡張性、標準準拠、耐障害性、無限の計算資源、普遍性などの夢のような性質をもたらします。その代わりに開発者は、コールスタック、トランザクションなどのシンプルなプログラミングモデルが存在しない、計算上の前提や確実性、順序性をもたない、などの難しい問題に対処しなければなりません。

新しい時代のACID属性 ^*3 は、DBトランザクションの性質ではなく、計算の順序に関するものになります。

Associative（結合性）

(A + B) + C = A + (B + C)。処理（+）をどの順番で実行しても、結果が同じになること。

Commutative（交換性）

A + B = B + A。処理の方向（A → B or B → A）を入れ替えても、結果が同じになること。

Idempotent（べき等性）

A^2 = A。処理が何回実行されても、1回だけ実行された場合と結果が同じになること。

Distributed（分散性）

計算処理が分散していること。クラウドにおいては自明の性質。

同じくACIDの再考でありながら、上述の丸山不二夫氏が示したBASE属性とは異なる切り口なのが面白いところです。丸山氏はあくまでDBトランザクションにこだわって新しい性質を再定義していますが、Hohpe氏は計算の順序という別の観点に注目して、そこに同じ頭字語のACIDを見出しています。

スターバックスは2フェーズコミットをしない

クラウドでは、2フェーズコミットによる分散トランザクションを実現することは困難です。私たちエンタープライズ開発の技術者はトランザクションなしでどうやってアプリケーションを作るのかと疑問に思いますが、現実世界を見ると、意外に多くの振る舞いがトランザクションなしで成立しています。Hohpe氏は、一例として、スターバックスにおけるドリンク注文処理を紹介します。

スターバックスでは、レジで注文を受けると、客がお金を払う前からドリンクを作り始めます。スターバックス側がきちんとドリンクを提供できることと、客側がお金を払えることの両方を確認してから、ドリンクとお金を同時に交換するという意味での「2フェーズコミット」は行われません。ドリンクを作ったのに客が財布をもってなかった、といった不整合を未然に防ごうとするのではなく、不整合が起こったら以下の3つの方法で柔軟に対処するのです。

やり直し（Retry）

作ったドリンクに客からクレームがあった ⇒ 作り直す

補償（Compensation）

コーヒーメーカーの故障で注文のドリンクを作れなかった ⇒ お金を払い戻す

損金処理（Write-off）

客がお金をもってなかった ⇒ ドリンクを廃棄する

なお、この話題については、Hohpe氏のブログ記事「スターバックスは2フェーズコミットをしない」（筆者翻訳）でより詳細に議論されています。ぜひそちらも参照してください。

Googleのクラウドプログラミングスタック

こうした新しい考え方を必要とするクラウドに対して、Googleは以下のプログラミングスタックを提供します。

• GFS - 分散ディスクストレージ
• Bigtable - 分散共有メモリ
• MapReduce - 分散プログラミングの抽象化
• Sawzall - 分散処理用のDSL

また、上記のプログラミングスタックを利用するための開発環境Google App Engineに、2009年4月にJava版が登場しました（これまではPython版だけでした）。

5つのベストプラクティス

大規模ウェブサイトのアーキテクチャでは、次の5つの特性が重要になります。

• 拡張性（Scalability）、可用性（Availability）、応答時間（Latency）、管理容易性（Manageability）、コスト（Cost）

これらの特性を実現する大規模ウェブサイト構築のベストプラクティスが、以下の5つです。

1. すべてを分割せよ（Partition everything）
2. どこでも非同期を使え（Asynchrony everywhere）
3. すべてを自動化せよ（Automate everything）
4. あらゆるものが落ちると思え（Remember everything fails）
5. 不整合を受け入れろ（Embrace inconsistency）

ベストプラクティス1：「すべてを分割せよ」

「分割しない限り、スケールできない（If you can't split it, you can't scale it）」 ― すべての問題を、データ、負荷、使用方法に基づいて管理可能なチャンクに分ける必要があります。

Functional Segmentation（機能による細分化）パターン

まず始めに、処理とデータは「機能」単位で分割する。

Horizontal Split（水平分割）パターン

サーバのクラスタ化によって処理の負荷分散をしていても、データソースが単一だとそこがボトルネックになる。その場合、データをその主キーに基づいて分割（shard）する。主キーの分割方法には、範囲毎に分割する、法（modulo）を使う、ルックアップする、などがある。

上記2パターンの帰結として、以下のプラクティスが導かれます。

No Session State（セッションに状態はもたせない）

ユーザセッションは複数チャンクにまたがるので、アプリケーション層には一切セッション状態を保持させない。

ベストプラクティス2：「どこでも非同期を使え」

システムの性能を最大限に活用するために、できる限り非同期処理を活用します。

Event Queue（イベントキュー）パターン

ユースケースの実現は、すべてイベントキューを通して行う。ユースケースを実行するアプリケーションはイベントだけを発行し、具体的な処理はイベントを待ち受ける別コンポーネントが行う。

Message Multicast（メッセージマルチキャスト）パターン

主データの更新はすべてメッセージとしてマルチキャストされ、主データに依存するデータ（検索インデックスなど）は必要な更新メッセージだけを受け取って自身の状態を更新する。

ベストプラクティス3：「すべてを自動化せよ」

最もコストが掛かるのが人間です。人手が介在することで、拡張性や応答性も低下します。そのため、マシンを最大限に利用して自動化し、人手の作業を排除します。

Adaptive Configuration（適応型設定）パターン

システム間のやり取りにもSLA（サービスレベル契約）を定め、SLAに基づいてシステムが設定を自動調整できるようにする。

Machine Learning（機械学習）パターン

ユーザやデータからのフィードバックループによりシステムが機械学習し、ユーザに最適な情報を自動的に提示できるようにする。

ベストプラクティス4：「あらゆるものが落ちると思え」

あらゆるものが落ちることを前提に設計することで、システムの耐障害性を高めます。

Failure Detection（障害検出）パターン

システムの全動作のログを取る（eBayでは1日に2TB以上のログになる）。また、障害の監視と通知を自動化する。

Rollback（ロールバック）パターン

システムに対するすべての変更を、巻き戻せるようにする。すべての機能を、中央の設定管理を通じてON／OFFできるようにする。

Graceful Degradation（段階的な縮退運転）パターン

外部リソースの利用状況を常に評価し、重要でない機能が停止したときは無視して稼働できるようにする。重要な機能が停止したときは、リトライまたは利用を後回しにできるようにする。

ベストプラクティス5：「不整合を受け入れろ」

クラウドの前提であるCAP定理を理解して、受け入れることが必要です。いかなる時もシステムに不整合が起こらない「即時整合性（Immediate Consistency）」と、まったく整合性を保証しない状態との間には、幅広いレベルでの「結果整合性（Eventual Consistency）」があります。即時整合性が本当に必要なシステムは、たとえ金融システムであっても、意外に少ないはずです。分散トランザクションでなく、結果整合性を積極的に使うようにします。

エンタープライズ開発の「次の2年」は？

Kniberg氏：

北欧ではScrumによるアジャイル開発の導入が進んだが、今度はコード品質などの技術的問題が表面化している。XPのプラクティスのようにコード品質の向上に直結するものが、今後は重要になっていくだろう。また、ソフトウェア開発だけでなく、ソフトウェア導入後も含めた全体的なバリューチェーンの改善が重要になってくる。

Hohpe氏：

トレンドによって新しいものが付加されることはあっても、原則は変わらず、何度も繰り返す。開発者は、まずそうした原則に注目することが大事だ。その上でトレンドを予想すると、クラウド／SOAの登場によって、コンポーネントやサービスの構成が重要になるので、開発時でなく実行時の比重が大きくなる。そのため、これからは「ランタイム（実行時）」の技術が重要になってくるだろう。

Shoup氏：

大企業のプラクティス（分散化、パーティショニング）が中小企業にも浸透してきている。また、開発ツール、プラットフォームもヘテロジニアス（異種混合）な環境になってきている。多様な選択肢の中から、最適なものを見極めていくことが重要だ。最後に、クラウド技術はこれまでコンシューマ向けが中心だったが、今後は銀行などの大企業や、政府機関でも採用が進むだろう。同時に、中小企業でも利用が進むだろう。

Shiemann氏：

ソリッド（統合）化とフラグメント（細分）化という、相反する2つの動きに注目したい。90年代のJavaはJ2EEという統合化へと向かったが、OSSの登場以降は細分化の方向にも進んでいる。一方で、OSSでもOSS同士のアライアンスという形で、統合化の動きが出てきている。こうした動向は非常にエキサイティングだ。

Marinescu氏（Fowler氏、Johnson氏）：

Martinは、これからはプロジェクトで複数のDSLを使う時代が来る、と言っていた。Rodは、リーン開発がこれから重要になる、と言っていた。