阪本です。
おなじみRedHat社が主催する、JBossとApache Camelのカンファレンス「JUDCon 2013 ＆ CamelOne 2013」がアメリカ・ボストンで開催されたので、参加してきました！
JUDConは2010年から、CamelOneは2011年から開催されている、参加者が1000人に及ぶカンファレンスで、JBoss関連プロダクトやCamelの最新情報・事例をいち早く手に入れることができます。
今年のボストン開催では、6/10と6/11にセッションが行われました（JUDConはブラジル等でも開催されています）。
その中で発表があった、いくつかのセッションを簡単に紹介します。
Common JDG Architectures
JDG＝JBoss Data Grid の略。
Webアプリケーションに対して、キャッシュ（JDG）を組み込むときのアーキテクチャパターンについて紹介。
最も単純なパターンは、Service/DAOとDBの間にキャッシュを挟むパターン。
Webアプリケーションに組み込む（＝WebアプリケーションとキャッシュのJava VMが同じ）ため、
メモリ制限がある。
次は、Webアプリケーションがロードバランサによって冗長化されているパターン。
各アプリケーションサーバ内にそれぞれキャッシュを組み込む形。
この場合は、キャッシュ同士がレプリケーションを行う。
キャッシュデータが分散保持されているとき、キャッシュサーバごとに保持するデータが異なるため、
キャッシュへの効率よいアクセス（取得したいデータを保持するキャッシュにアクセス）を行うには、
キャッシュへの接続方法としてHot Rodを用いる。
BigDataに向いている。
次は、上のアーキテクチャに加え、JDG Clusterを組み込むパターン。
片方のWebアプリケーションに対してデータ更新を行うと、
各Webアプリケーション間でデータの矛盾が一時的に生じることになるが、JDGが古いデータを自動で無効化してくれる。
この構成は高負荷なサイトに向いている。
最後に、JDG Clusterを複数構築して、クロスサイトレプリケーションを行うパターン。
片方のクラスタを更新可能、もう片方のクラスタを読み取り専用にするのが安全な構造。
2つのクラスタのキャッシュが同時に更新される場合、どちらのデータを優先するかは議論が必要。
複数のデータセンタなどに向いている。
また、複雑なSQLをDBに発行する場合、代わりにキャッシュに発行する方がよいとされる。
Apache Luceneを用いる。（個人的には、DBでFull Scanが発生していなければ、DBアクセスの方がよい気がする。）
NoSQL - Scaling Beyond Traditional SQL with Cassandra
SQLを用いてスケーリングを行う事例。
RHQ（JBossミドルやTomcat、Apacheなどを管理するソリューションを提供するアプリ）を例に説明。
RHQは、管理対象のTomcatサーバなどにAgentを入れ、AgentからRHQ Serverに情報を吸い上げる形で動作する。
情報を吸い上げる間隔は30秒だが、データ量を抑えるため、古いデータは数段階に分けて間引きされる。
RHQのアーキテクチャはもともと、データ保存にRDBを用いていたが、
情報が30秒ごとに1000台以上のAgentから送られてくるため、データの書き込みに負荷がかかる。
そこで、Javaで実装されており、CQL（Cassandra Query Language）があり、ツールが揃っているCassandraを採用。
既存のDBはそのまま残し、間引きされる前の生データのみCassandraに入れる。
パフォーマンスを出すなら、この構成がよいとのこと。
（個人的追加：ちなみに、DBが性能ボトルネックとなっていたZabbixもCassandra対応していますが、RHQとほぼ同じ事象だと思われます。）
Working with Apache Camel from HTML5 via hawtio
Apache Camelをはじめ、ActiveMQやInfinispan等のOSSを、Webで統合的に管理するソフトウェア「hawtio」がなんと無料！
このツール（というかiPaaS（Integrated PaaS）と呼んでいた）は、
- Camelコンテキストの追加 とか
- ルールの作成 とか
- バージョン管理・動的バージョン切り替え とか
- ルール実行状況確認 とか
- デバッグ・値チェック とか
ができてしまうスグレモノ！
プラグインを入れることで、いろんな機能を追加することもできるらしい。
Camelを使っている人は、これは使いこなすとかなり効率的に作業ができますね。
