ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

45

COM

MUNITY1

1

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

大半のエンタープライズ・アプリケーションや Web

アプリケーションで、何らかの方式のキャッシュが利用されています。大量のリクエストを受け取るアプリケーションでは、通常、一部のレスポンスをキャッシュに保持しておくと効果的です。これにより、一定の条件下で、同様のリクエストに対して同じレスポンスを送信できます。すべての処理や計算を再実行するのではなく、事前にキャッシュしておいたレスポンスを返すことでCPUリソースを大幅に節約できます。

さまざまな商用ソリューションで、キャッシュの実装が開発用に提供されています。一般に、ソリューションが異なれば付随するトポロジや概念、機能も異なりますが、Java Temporary Caching API により、実装の詳細を意識せずに、キャッシュ操作の共通アプローチを採用できます。本記事では、Javaアプリケーションで

Java Temporary Caching APIを活用する方法の概要を紹介します。

Java 仕様は Java Community Process（JCP）組織によって定義され、各仕様に対して、Java Specification Request（JSR）が提出されます。Java 仕様は、専門家グループの編成に始まり、仕様、リファレンス実装、テスト・スイートの公開へと最終的に至るまで、明確に定義された多くの手順に従って開発されます。

専門家グループを編成してから最終的に仕様が承認されるまでの期間は、短い場合もあればやや長期化する場合もあります。Java Temporary Caching API（JSR 107）は、2001 年には標準化すべき重要分野と考えられていましたが、2014 年3月18日に、ようやく最終リリースにこぎ着けました。

標準化の取り組みの開始から最終リリースまでこれほどの

時間がかかったことには良い点もあります。専門家グループのメンバーやコミュニティから集められたあらゆる経験を活かせたことです。キャッシュ・ソフトウェアごとに使用される用語は少しずつ異なりますが、概念レベルでは標準化できる十分な共通事項があり、こうした共通概念が JSR 107 に取り込まれています。

キャッシュはデータベース呼出しとリンクされること（つまり、データベース呼出しの結果がキャッシュに保持されること）が多いですが、キャッシュの概念はデータベース・アプリケーションの枠を越えた非常に広範なものであることを強調しておきます。実際、キャッシュは、画像や Web サービスからのレスポンスなどを保持するためにも利用できます。JSR 107の定義に従えば、キャッシュ可能なエントリのもっとも汎用的な表現が Java オブジェクトです。

本記事では、Java Temporary Caching API をAmazon DynamoDB サービスで利用する方法について確認していきます。実際には、ほとんどのリレーショナル・データベースや非リレーショナル・データベース、あるいは Javaオブジェクトを生成するあらゆるサービスに対して同じ概念が適用されます。注：本記事で開発するサン

プル・アプリケーションのソース・コードはこちらからダウンロードできます。

Amazon DynamoDBAmazon DynamoDB は、Amazon が提供するクラウドベースの NoSQL データストアです。DynamoDB の機能の概要については本記事では取り上げません。Java Temporary Caching API の動作はDynamoDB 以外の NoSQLまたは SQL データ・ストレージ・システムを使用しても確認でき

Java Temporary Caching APIの概要実装の詳細を意識せずにキャッシュ戦略を利用する

JOHAN VOS

写真： TON HENDRIKS

Johan Vos：1995 年からJava に関わる。ソーシャル・ネットワーキング・ソフトウェア向けの Java ベース・ソリューションに取り組むLodgON の共同創設者。組込み開発とエンタープライズ開発の両方に熱心であり、徹底してJavaFXとJava EEを使用したエンド・ツー・エンドの Java に専念。

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

46

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

ます。DynamoDB の好ましい点の 1 つ

は、テスト中に容易に利用できるローカル・バージョンが提供されていることです。本記事のサンプルでは、このローカル・バージョンを使用します。DynamoDB Local はこちらの説明に従ってダウンロードできます。

ダウンロードした Javaアーカイブ（JAR）ファイルは、リスト1のコマンドで簡単に起動できます。

このコマンドを実行すると、DynamoDB のローカル・バージョン（DynamoDB Local）が開始され、データベース・ファイルを使用するのではなく、メモリ内でデータベースが実行されます。そのため、DynamoDB Local に送信されるデータはすべてメモリに保存され、サーバーの停止時にはすべてのデータが失われます。この動作は、DynamoDB のクラウド・バージョンとはまったく異なりますが、ローカル・バージョンにアクセスする場合もクラウド・バージョンにアクセスする場合も必要な API は同じです。また、クラウド・バージョンはローカル・バージョンよりも多くの構成作業が必要であり、ローカル・バージョンは無償ですがクラウド・バージョンは有償です。こうした違いから、DynamoDB Local は、ソフトウェア・エンジニアがコード開発プロセスで利用する目的で非常に人気です。

Amazon Web Services SDK（AWS SDK）には、DynamoDBと通信できるAPI が多数含まれています。本記事のサンプルでは、Java オブジェク

トとDynamoDB 内のエントリを直接マッピングする高レベル API を利用します。そのために、保存する Javaオブジェクトに対して、いくつかのアノテーションを利用します。

サンプル・アプリケーションおそらく、Java Temporary Caching API を利用するアプリケーションの大半はエンタープライズ・アプリケーションですが、この API 自体は Java SE 環境でも動作するように設計されています。本記事では説明を単純にするために、Java SE 8プラットフォームで稼働するサンプルを作成します。

サンプル・アプリケーションでは多数の Person インスタンスを作成します。Personクラスのコードをリスト2aおよび 2bに示します。このPersonクラスは典型的な Javaクラスであり、姓、名、年齢のフィールドのほか、主キーを保持するmyKeyフィールドがあります。

@DynamoDBTable(tableName = "Person") アノテーションは、この PersonクラスとDynamoDB 内に作成される「Person」表を関連付けるために利用します。また、@DynamoDBHashKeyアノテーションは、このアノテーションが付加されたメソッド（getMyKey）が、このオブジェクトの DynamoDB でのハッシュ・キーを返すことを示します。

これから作成するサンプルは以下の 3 つの手順を実行します。

1. データストアの作成2. データストアへのデータの挿入3. データストアへの問合せ

すべてのリストのテキストをダウンロード

java -Djava.library.path=./DynamoDBLocal_lib -jar DynamoDBLocal.jar -inMemory

リスト1 リスト2a リスト2b

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

47

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

サンプル・アプリケーションのmainメソッドはごく単純です（リスト3）。

1 つ目のサンプルではキャッシュを利用しません。データの書き込みと問合せはすべて、DynamoDB に直接行います。

createDatabase 関数は、DynamoDB データストアを作成します。リスト4のコードに、DynamoDB データストアの作成方法を示します。DynamoDB 固有の詳細については説明しませんが、概念レベルでは、createDatabase の呼出しにより以下の操作が実行されます。 ■ Amazon DynamoDBと通信するための資格証明（キーとシークレット）を作成する。DynamoDB Local の場合、資格証明の内容は問われませんが、資格証明の指定は必要です。

■ AmazonDynamoDBClient インスタンスとDynamoDBMapperインスタンスを作成する。このDynamoDBMapper インスタンスを後で利用します。

■ データのインデックスを設定するための主キーに使用するキーを定義する。

■ 要求するスループットを指定する（読取り、書込みの各操作について）。これらの値もDynamoDB Local では意味を持ちませんが、指定は必要です。

■「Person」表が存在する場合は削除する。

■「Person」表を作成する。以上で、表が作成され、

DynamoDBMapper オブジェクトの設定が完了しました。次に、表にデータを挿入します。

ランダムな内容の Person インスタンスを 1000 個作成します。これらのインスタンスの myKeyフィールドを、0 から999までのインデックス値を利用して設定します。リスト5のコードは、これらのインスタンスを使用して表にデータを挿入するものです。DynamoDB の高レベル API を利用すれば、オブジェクトの保存は、保存するオブジェクトを引数に渡してDynamoDBMapper インスタンスのsaveメソッドを呼び出すだけの簡単な操作になります。

次に、特定のキーを持つ Personインスタンスを DynamoDB に問い合わせます（リスト6）。DynamoDBMapper に対して1000件のリクエストを実行します。各リクエストでは、特定のキーに対応するPerson インスタンスを検索するようにDynamoDBMapperに依頼します。このキーは 0 から1099までの乱数です。ただし、保存された Personインスタンスのキーの範囲は 0 から999 であるため、リクエストの約10% で空のレスポンスが返される見込みです。

Java Temporary Caching API の概要これまで、データの保存と取得のリクエストはすべてDynamoDB システムに対して直接実行しました。ここでは、Java Temporary Caching API の概要を説明します。コードを見る前

に、JSR 107 に定義されているおもなクラスを以下に示します。 ■ CacheProvider：Java Temporary Caching API の実装を含むクラス

■ CacheManager ■ Cache ■ Entry ■ Expiry次に、データストアへのデータの

挿入に使用したサンプル・コードを修正し、キャッシュ機能を追加します。修正後のコードをリスト7に示します。このコードでは、データストアにデータを挿入する前に、Cache インスタンスを作成します。そのために、まず CachingProvider への参照を取得する必要があります。この参照の取得を行うコードをリスト8に示しま

すべてのリストのテキストをダウンロード

public static void main(String[] args) { createDatabase(); populateDatabase(); queryDatabase(); }

リスト3 リスト4 リスト5 リスト6

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

48

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

す。Java Temporary

Caching API は JSR 107で定義されていますが、この API 自体に具体的な実装は含まれていません。この API は実行時にJava ServiceLoaderを利用して、クラスパスに CachingProvider の実装があるかを確認します。

本記事のサンプルでは、JSR 107 のリファレンス実装（Maven Central から取得可能）を利用します。このリファレンス実装が含まれるJARファイルには META-INF/servicesディレクトリがあり、このディレクトリに CachingProvider 実装の参照が含まれています。

JSR 107 に準拠した別の実装がクラスパスにある場合は、その実装が利用されます。その場合でも、サンプル・コードでは JSR 107 仕様で定義された APIしか利用していないため、コードを変更する必要はありません。サンプル・コードでは実装固有のAPIや機能は利用していません。

CachingProvider を取得した後は、CacheManager を取得する必要があります。この取得を行うコードをリスト9に示します。

CacheManager インスタンスを取得したら、Cache インスタンスを作成できます。キャッシュには Personのインスタンスを保持する必要があ

ります。Cache に格納されるエントリは、キーと値で構成されます。このサンプルの場合、Person の myKeyフィールドをキーとして使用し、Person 自体を値として使用するのが適切です。リスト10のコードでは、キャッシュを作成し、必要な構成を実行します。

キャッシュの構成はMutableConfigurationインスタンスで定義します。MutableConfigurationクラスの流れるような

API を使用して、さまざまな構成ポリシーを設定できます。この場合の流れるような APIとは、setメソッドの戻り値が MutableConfiguration インスタンス自体であることを意味しています。

本記事のサンプルでは、以下のように設定します。 ■ setTypes 文（リスト10）では、キャッシュのキーが Long 型で値がPerson 型であることを指定する。

■ setExpiryPolicyFactory 文では、キャッシュ・エントリの有効期間を定義する。Cache インスタンスを作成するた

めには、CacheManager インスタンスの createCacheメソッドを、キャッシュの名前（personCache）と構成用のオブジェクトを引数に渡して呼び出します。

キャッシュを作成するコード以外には、追加するコードは 1 行だけです。Person インスタンスを作成する forループで以下の行を追加します。

この行で、実際に Person インスタンスをキャッシュに格納します。ただし、キャッシュの一般的な問題として、キャッシュに追加したデータがキャッシュ内にまだ存在しているかを確認する術はありません。このサンプルの構成では、キャッシュ・エントリを最大 1 時間キャッシュ内に保持する

cache.put(person.getMyKey(), person);

共通アプローチJava Temporary Caching APIにより、実装の詳細を意識せずに、キャッシュ操作の共通アプローチを利用できるようになります。

すべてのリストのテキストをダウンロード

private static void populateDatabaseCache() {

CachingProvider cachingProvider = Caching.getCachingProvider(); CacheManager cacheManager = cachingProvider.getCacheManager();

MutableConfiguration<Long, Person> config = new MutableConfiguration<Long, Person>() .setTypes(Long.class, Person.class) .setExpiryPolicyFactory(AccessedExpiryPolicy.factoryOf(ONE_HOUR)) .setStatisticsEnabled(true);

cache = cacheManager.createCache("personCache", config);

Random age = new Random(); DynamoDBMapper mapper = new DynamoDBMapper(client); for (long i = 0; i < 1000; i++) { String f1 = UUID.randomUUID().toString(); String f2 = UUID.randomUUID().toString(); Person person = new Person(i, f1, f2, age.nextInt(100)); mapper.save(person); cache.put(person.getMyKey(), person); } }

リスト7 リスト8 リスト9 リスト10

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

49

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

ように明示的に指定していますが、キャッシュの実装によって、指定よりも早くキャッシュからエントリが削除されることもあります（キャッシュのサイズが危険域に達した場合など）。この最大キャッシュ・サイズの問題は、実装のアーキテクチャ次第で非常に複雑となる場合があります。最適なキャッシュ・サイズを決める内部要因や外部要因が数多く存在するため、最大キャッシュ・サイズを明示的に設定することは、多くの場合意味を成しません。そのため、JSR 107 では、最大キャッシュ・サイズを設定するメソッドは定義されていません。

キャッシュからデータを取得する際には、そのデータがキャッシュからすでに削除されている可能性を考慮する必要があります。リスト6では、DynamoDB に対して、特定のキーに対応するPerson オブジェクトがあるかを問い合わせています。キーは 0 から1099までの Long 値です。1000 以上のキーを指定した場合は、対応する値が見つからないという結果が DynamoDB から返され、そのキーに関連付けられた Person が存在しないことが分かります。しかしながら、問い合わせ対象がキャッシュの場合には、同じような処理フローだけでは不十分です。特定のキーに属するPersonインスタンスが、キャッシュにはなくてもDynamoDB にはあるという可能性が少なからずあります。Personインスタンスがキャッシュから削除されたケースがこれに該当します。

キャッシュに特定の Person インスタンスがあるかを問い合わせるために、以下のメソッドを利用します。

このメソッドが Person インスタンスを返す場合はそこで終了ですが、このメソッドが null を返す場合でも、DynamoDB データストアにPerson インスタンスが存在する可能性がまだ残っています。この場合のDynamoDB への問合せには、リスト6と同じコードを使用することになります。

リードスルー・キャッシュと ライトスルー・キャッシュの利用前項までは、キャッシュとDynamoDB を互いに独立した状態で利用しました。Person インスタンスをキャッシュに格納し、さらに手動で DynamoDB にも格納しました。また、データの取得時には、まずキャッシュに問い合わせて、キャッシュに存在しない場合のみ、手動でDynamoDB に問い合わせました。

一般的に、キャッシュではリードスルー操作とライトスルー操作も利用できます。簡単に説明すると、ライトスルー操作では、キャッシュに書き込まれるデータは（DynamoDB のような）永続ストレージにも保存されます。また、リードスルー操作では、データはキャッシュから読み取られ、キャッシュ内に存在しない場合は永続ストレージから取得されます。このアプローチの利点は、要求し

たオブジェクトがキャッシュから返さ

Person p = cache.get(KEY)

れない場合に、アプリケーション・コード側で永続ストレージそのものに毎回問い合わせる必要がないことです。

JSR 107 では、このリードスルー /ライトスルー機能を利用できるようになっています。前述のサンプルを修正して、この機能を実行する方法を示します。リードスルー /ライトスルー機能の

有効化は、構成プロセスで行います。キャッシュの構成を指定するために利用した MutableConfiguration オブジェクトを、リードスルー /ライトスルー操作を指定するためにも利用

できます。ライトスルーの指定方法をリスト11aと11bに示します。

このコードから分かるとおり、MutableConfiguration.setCacheWriterFactory() メソッドの引数に CacheWriter の Factoryを渡しています。この Factory はCacheWriterクラスを作成します。さらに、CacheWriterクラスを独自に拡張して、この CacheWriter の各メソッドを DynamoDB への API 呼出しにマッピングします。キャッシュ内でエントリが追加、更新、または削除されるたびに、CacheWriterの対応するメソッドが呼び出されま

config.WriteThrough(true);config.setCacheWriterFactory(new Factory<CacheWriter< Long, Person>>() { @Override public CacheWriter<Long, Person> create() { CacheWriter<Long, Person> writer = new CacheWriter<Long, Person>() {

@Override public void write(Cache.Entry<? extends Long, ? extends Person> entry) throws CacheWriterException { mapper.save(entry.getValue()); }

@Override public void writeAll(Collection<Cache.Entry<? extends Long, ? extends Person>> clctn) throws CacheWriterException { clctn.forEach((Cache.Entry ce) -> mapper.save(ce.getValue())); }

リスト11a リスト11b

すべてのリストのテキストをダウンロード

ORACLE.COM/JAVAMAGAZINE ///////////////////////////// JULY/AUGUST 2014

JAVA TECH

50

COM

MUNITY

JAVA

IN A

CTIO

NAB

OUT US

blog

//enterprise java /

す。そのため、ストレージに関するすべての操作は、キャッシュに対してのみ実行するだけで済みます。CacheWriterFactory を使用することで、キャッシュに対する変更が DynamoDB にも書き込まれるようになります。

CacheWriterFactoryと同様に、CacheLoaderFactoryも指定できます。CacheLoaderFactory から返されるCacheLoaderを使用することで、、キャッシュからエントリを取得するように要求した場合に、そのエントリがキャッシュにないときは、DynamoDB に対して問合せが行われます。このサンプルでは、CacheLoader からオーバーライドした実装内で、DynamoDB に問合せを送信します。リスト12のコードで

は、前述の例で用いたMutableConfiguration インスタンスに、リードスルー操作を追加しています。このコードから分かるとおり、CacheLoader の loadメソッドで、リスト6とまったく同じ操作を実行しています。このメソッドでは、DynamoDB に対する問合せを作成し、指定されたキーを用いてPersonを取得しようとしています。

CacheLoader、ひいてはリードス

ルー操作を利用することで、開発者は多くの場合、キャッシュ・ロジックではなくアプリケーション・ロジックに集中しやすくなります。リードス

ルー機能がなければ、キャッシュへの問合せの結果が返されない場合は毎回、永続ストレージに問い合わせる必要があります。CacheLoaderを利用することで、この問合せ操作が CacheLoaderに委譲されるため、一度だけコーディングすればよくなります。

まとめ本記事では、JSR 107について簡単に説明しました。この仕様は、ほとんどのキャッシュ・プロバイダが提供する機能に対する共通アプローチを提示します。本記事では単純な取得操作と保存操作のみを取り上げ、さらに

リードスルーとライトスルーの概念について簡単に説明しました。詳しく見るに値する内容はほかにも多数あります。関心を持たれた皆さんは、Javadoc の詳細をご確認ください。

JSR 107 の最大の功績は、アプリケーションの開発において、特定の実装に依存しないキャッシュ戦略を採用できるようになったことです。一部のキャッシュ・ソフトウェア・プロ

バイダはすでに JSR 107 に準拠した実装を提供しており、他のプロバイダも今後追随すると思われます。開発時には、JSR 107 で提供される機能のみを利用することをお勧めします。実行時には、クラスパスに（無償または商用の）具体的な実装を追加することで、その実装が自動的に利用されます。</article>

LEARN MORE• Amazon DynamoDB• JSR 107• 仕様とリファレンス実装

config.setReadThrough(true)config.setCacheLoaderFactory(new Factory<CacheLoader<Long, Person>>() { public CacheLoader<Long, Person> create() { return new CacheLoader<Long, Person>() { public Person load(Long k) throws CacheLoaderException { Person hashKeyValues = new Person(); hashKeyValues.setMyKey(k); DynamoDBQueryExpression<Person> queryExpression = new DynamoDBQueryExpression<Person>().withHashKeyValues(hashKeyValues); List<Person> itemList = mapper.query(Person.class, queryExpression); if (itemList.size() == 0) { return null; } else { return itemList.get(0); } } public Map<Long, Person> loadAll(Iterable<? extends Long> itrbl) throws CacheLoaderException { Map<Long, Person> answer = new HashMap<>(); itrbl.forEach((Long k) -> answer.put(k, load(k))); return answer; } }; }})

リスト12

すべてのリストのテキストをダウンロード

JAVA EE以外にもおそらく、Java Temporary Caching APIを利用するアプリケーションの大半はエンタープライズ・アプリケーションですが、このAPI自体はJava SE環境でも動作するように設計されています。