クラウドコンピューティングサービスは、従来にない拡張性を持ち、好きなときに好きなだけのリソースを使えるシステム基盤を提供するものです。しかし、その特性を生かすには、クラウド事業者ごとに異なる設計のルールを守らなければなりません。

　そこで本連載は、米Googleのサービス「Google App Engine」に焦点を当て、その「デザインパターン」について解説をします。ここでは、クラウドサービスの特性を生かしたり、制約を回避したりするための設計ノウハウをデザインパターンと呼んでいます。

　今回解説する設計ノウハウを「デザインパターン」と呼ぶことに、違和感を持つ読者もいるかもしれません。「これこそクラウド設計のデザインパターンだ」と言えるものは、今後さまざまな知見が集まって確立していくのだと思います。現在はその知見が少しずつたまってきている段階でしょう。今回の連載が、そうした知見の一つになってほしいと考えています。

　クラウドコンピューティングサービスの代表例であるGoogle App Engineは、リリースされてからもうすぐ3年になります。事例が増えてきて、その設計ノウハウも徐々に明らかになってきました。筆者は、いくつかの業務システムをGoogle App Engine上に構築した経験があり、そうした経験を共有する勉強会を定期的に開催しています。そこで得られたノウハウを紹介していきましょう。

　第1回では、「画面設計で制約を回避する」ための設計ノウハウを紹介します。従来のプラットフォームでは「実装するのが当たり前」の機能でも、Google App Engineでは実装が難しいものがあります。Google App Engineでのアプリケーション開発に慣れない間は、特に意識せずに、実装が難しい機能を画面設計に含めてしまいがちです。すると実装フェーズになって初めて「あれ、これはどうにも実装が難しい」ということになってしまいます。

　つまり、どのように画面を設計するかという段階で、ユーザーと協議し、実装が難しいような要素を盛り込まないように注意する必要があるのです。そのための設計ノウハウを二つ紹介しましょう。

表示する検索件数に上限を設ける

　一つ目は、検索結果を表示するページでは、検索件数の表示に上限を設けるというものです。「101～200件目/3523件」というように検索結果の全件数（3523件）を示したり、「3ページ目/235ページ」のように検索結果の全ページ数（235ページ）を示したりすることはよくあると思います。Google App Engineでは、このような画面設計で注意が必要です。

　Google App Engineの分散データベースサービスである「Datastore」には、RDBでは当たり前の集計関数がありません。データの件数を取得する機能が別途用意されていますが、対象数が多い場合には、数秒～数十秒かかることがあります。検索結果の数が数百件以内などと分かっている場合を除き、次のような画面設計をお勧めします。

  • 特定件数までは正確に表示するが、それを超える場合は「×件以上あります」程度の表示にとどめる
  • 特定件数を超えた場合には、検索結果を表示せず、さらに結果を絞り込むための検索条件を入力するように促す

　検索結果の数が多い場合、正確な件数はあまり意味がないことが多いのではないでしょうか。「たいていのアプリケーションで表示されているから」といった理由で、正確な件数やページ数を表示しようとすると、長い処理時間がかかってしまいます。検索処理を並列実行して、その結果を集約するというように処理時間を短くする方法もいくつかありますが、実装が複雑になり時間と工数がかかります。その工数をかけるだけの価値があるのかをしっかりと見極める必要があります。