皆さん、こんにちは。飯田秀樹と申します。私は、株式会社オープンストリームでSEとして働いております。
当社は、 2年前より、PaaS、IaaS等のクラウドサービスを活用した開発プロジェクトに注力しており、私も1年以上前からGoogle App Engineを使ったシステム構築にプロジェクトリーダーとして従事しております。
今回の記事は、私が実際に経験したGoogle App Engine（GAE）による初めての開発プロジェクトでの経験に基づき、全く経験のなかった環境やツールに戸惑いながらも開発を進めた成果をまとめたものです。
GAEを使った開発は私自身も初めてであり、実際は困難の連続でした。特に今までのWEBアプリ開発とは、全く違うプラットフォーム特性に大変苦労をいたしました。そうした苦労の数々を皆さんと共有出来れば幸いです。
さて今回は「要件定義編」ということで書かかせて頂きますが、この間にもGoogle App Engine（以下「GAE」のバージョンもかなりアップしております。
当時は課題と考えられていたものでも今は既に解決されていたり、満たす機能が提供されている部分もありますのでそのあたりも書いていこうと思います。前回も書かせていただきましたが、この記事の内容が、これからGAEに取り組むの方の一助になればれば幸いかと思います。
要件定義
要件定義とはとは、お客様の「～～がしたい」を開発ベンダーが「～～が必要です」に置きかえていくフェーズです。
PaaS系のクラウドサービスを利用する場合、要件定義の中で「機能要件」「非機能要件」を検討する際にPaaS特有の制約が多く存在しGAEの場合も
「GAEだとこうやってできます」
「GAEだとこうしなくてはいけません」
さらには「GAEでは出来ません」
を検討し、明確にお客様に伝えなくては、あとで問題やリスクになることもあるかと考えます。
その辺を踏まえて、私の経験をもとに、この記事を書いていきたいと思います。
機能要件に関してBigTableを使うということ
システム化したい業務には、様々な要求が存在します。しかしながら、GAEの使用を前提にシステムを構築する場合、最も注意すべき点は、BigTableを使ってデータモデルを実現しなければならないことです。
BigTableには、設計時に適切な非正規化が必要になりますので、要件定義の時点で意識しておくことが大事かと思います。
BigTable上で、無理矢理リレーショナルモデルを意識した設計を行うと、
レスポンスの悪化
BigTableからの取得は高速だが結果アプリケーション内でデータ組み立てる必要があり処理が遅くなる。
課金額の増加
APIのCall数が増え、課金額に影響が出る
など、後で大変なことになることが考えられます
BigTableによる実現が難しい要求が存在する場合、GAEでは
「Google Cloud SQL」https://developers.google.com/cloud-sql/という機能が提供されており、「MySQL」が利用できます。BigTableとMySQLを組み合わせ、それぞれの特性にあった機能を実現できますので、実現性の幅は大きく広がったと思います。
ライブラリの使用制限
お客様からヒアリングしながら、頭の中では「あのライブラリを使えばこの機能が実現できるな～」とか考える方たも多いかと思います。ところが、いざ具体化する際に「GAEでは使えません」という場合がよくあります。
というのはGAEのアプリケーションからアクセスできるクラスは以下に制限されているからです。
「JRE クラスのホワイト リスト」https://developers.google.com/appengine/docs/java/jrewhitelist?hl=ja
実際にあった例を挙げてげてみましょう。
「画像を扱いたい」という要件について「Java6にある「javax.imageio.*」を使うつもりで要件定義を進めましたが、調べたところ「javax.imageio.*」はホワイトリストに入っておらず、要件の再検討整を余儀なくされました。
「要件として確定したけど、ライブラリが使えない。。。力技でもどうしようない。。。」
GAEでの開発では、このような事にならないようにホワイトリストを常に確認しながら要件定義を進めることが重要です。
また、別の例では、Excelの操作が必要な場合、「POI」は使えませんでしたが「jexcelapi」は使うことができました。「POI」が使えない原因としてはホワイトリストに無いライブラリを利用してるのかもしれません。
GAEでは、GoogleAppsのスプレッドシートを使うのがスマートなのでしょう。
しかしながらExcelでの”読み込み/吐き出し”という要望はやはり根強いと思います。そういった要件がある場合は注意が必要かと思います。
ちなみに「jexcelapi」も読み込めるファイルが「2003形式」までだったりと色々ありますが、それはまた別のお話ということで割愛させていただきます。
非機能要件
非機能要件といっても様々ありますが、ここでは「非機能要件」そのものに対して、アレコレ語るわけではございません。私もまだまだな人間でございます。
GAEで開発を行うにあたり、Googleのインフラ、アーキテクチャ、運営に依存する部分多い中、開発側が関与できる箇所において
「GAEを使ったプロジェクトで非機能要件を考えるときの注意点」
という形で本章をすすめさせて頂きますので、皆様もその視点で読んでいただければ幸いです。
「可用性」に関して
インフラは全てGoogle任せとなってしまいます。私が携わっていた期間（約1年）は大きい障害はなかったですが、定期的なメンテナンス等は何回かありました。そんな時に
「Googleの都合なのでわかりません。」
というわけにもいきませんので、メンテの情報を翻訳して関係者通達する等のエスカレーションフローは決めておく必要があります。とはいえなにかあっても「待つ」しかないのがもどかしいところです。
「Google App Engine Downtime Notify」https://groups.google.com/forum/?fromgroups#!forum/google-appengine-downtime-notify
上記のGoogleグループではメンテナンスによる事前のスケジュールも含めて、ダウンタイムの通知が行われており、このグループのメーリングリストに参加すると、通知メールが配信されます。
注意すべき点は、配信時刻とダウンタイムの時間が太平洋標準時であり、日本時間の16時間前となります。
運用・保守担当は、Googleから配信される情報を活用することが重要と考えます。
「性能・拡張性」に関して
通常、GAEに準拠した適切なアプリケーションであれば、GAEの機能によって負荷の増減に対して柔軟に処理性能が増減されますが、それでもパフォーマンスが悪化する場合があります。
その場合は「データストアの設計」や「処理方式」、「コーディング」に問題があることがほとんどです。
GAEを使ってシステムを開発する場合、GAEの特性にあった設計、処理方式に落とし込む必要があります。
拡張性に関して言えば、自動スケーリングがありますので問題はないかと思います。
セキュリティ面に関して
普通にGAEを使う場合は、インターネット上であればどこからでも見れるアプリになります。その場合、
「社内システム」や「業務システム」の場合に
「見えるのはちょっと困る」
ということになるかと思います。ログイン画面を設けて特定のユーザしかログインできない状態だとしても
そのログイン画面は全世界公開です。
その為、GAEを社内システム等に使う場合はSSOと連携させるケースがスタンダードなようです。またデータの配置場所に関しては データは全てGoogleが管理しており、「内部統制」等が厳しい企業様には向かない可能性もあります、こうした制約については、なるべく早い時期にユーザ企業様と共有し、理解を求める必要があります。
「移植性」に関して
もしもGAE導入の内容が既存のシステムの「置き換え」だった場合、一番の壁になると思われるのが
RDB⇔BigTable間のデータ移行
になるのではないでしょうか。非正規化のBiｇTableに対して既存のRDBのデータを移行する場合は作業工数はかなりのものになる覚悟が必要かと思います。
「運用性・保守性」に関して
「可用性」の項とも関連しますが、メンテナンスや障害があった場合の情報入手、通知の仕組みを確立することが大事なのと同様に
・データのバックアップ
・「Log」の保管
等の課題があります。バックアップに関しては、今現在バックアップの機能が管理ツールから提供されていますので問題ないと考えますが、Logに関しては保存日数、保存サイズは管理画面で指定できるものの
個別のファイルとしては取得できない状態です。地道にコピー＆ペーストするのも現実味がないですし、別途ファイルに吐きだすにしてもアプリ内で保持できるファイルのサイズにも制限があります。考えられる手としてLog情報もデータストア内に保存してしまうという手もあります。Logの取得と保存に関しては、まだ決定打が無いのが現状です。
この記事を書き終わるまでにも、Google App Engineに色々な機能が追加され、進化しています。より顧客のニーズにあった要件定義ができるようになったかと思います。GAEをうまく利用することで、開発/運用コストは軽減できることは、もはや色々な事例やサイトで紹介されています。そのメリットをいかせず、要件定義で自らの首をしめてしまわないように、我々は、新機能についての調査や検証を続けることでGAEの可能性を最大限に引き出していかなくてはならないと、考えさせられております。
次回は設計編で考えております、かなりの遅筆ですが、その間に追加された機能等があれば、それも踏まえて書いていければと思います。