GiltにおいてPlayフレームワークをどのように活用しているのか、Giancarlo Silverstrinが紹介してくれています。

単一のRailsアプリからマイクロサービスに切り替える過程で、JVM + Java -> JVM + Scalaと開発基盤を変遷。現在、本番環境には、250+サービス。

マイクロサービスへの展開時には、バックエンドのRailsアプリは残すかたちで既存の資産の有効活用。webレイヤでには75+個のアプリ（コード約7万行）がある。リソースとUIテーストを共有したアプリの組み合わせで、Giltのサイトは構成されている。

フラッシュセール（毎日昼12時から限定ブランドアイテムのセール）のサイトゆえに、在庫は限られているので大切な情報。Play + WebSocket APIを利用して、リアルタイムの在庫情報をサイトに反映させる仕組みを構築している。その他、検索 / 商品のリスティング / 在庫 & 販売管理システムなどでPlayを利用。

Playを採用したメリットとしては、

• 非同期処理 & non-blockingアーキテクチャ: マイクロサービスだとアプリはネットワークからの返信をまっている時間がほとんど。Giltでは、コントローラーは最大15件のリクエストを平行して送れるようにしている。かつて32個のインスタンスを使用していたアプリが、Play採用で、8個まで減らすことができた。導入に際しては、「なぜコントローラーの中でブロックしてはいけないか？」を理解したり、「どうして、これをしなくてはいけないか？」を学んだり、非同期コミュニケーションの処理のためにプラスアルファの工数がかかったり、と慣れるまでの時間は必要。コールバック処理でコードが収拾つかなくなる問題は、Scala Futuresを使うことでうまく対処できた。また、Playのスレッドプールを理解し、いつどこでブロックするかについては、ドキュメントをよく確認されたし。
• スケーラビリティ: JVMはakkaを使えば、高い並列処理能力をだせる。マルチプルCPU/コアをうまく活用できる。Node.jsのようなシングルスレッドではないので、マシンの能力を使ったスケールがしやすいと思う。Giltの標準サーバは、コアが16個。一方で、shared-nothingアーキテクチャゆえに、突然想定外のキャパが必要になるのが心配。幸い、Giltはアプリのサイズが様々なので、柔軟にクラウドも使えるようにしている。
• 生産性が高い: "Developer Happiness"のKPIも社内で計測しているが、満足度は高い。コードの自動リロード機能は、コンパイル=>サーバ再起動の煩わしさから解放してくれる。また、PlayのJSONライブラリは、MVCをわかりやすく変換してくれるよくできた抽象化レイヤなので重宝している。さらに、全体的にドキュメントはよくまとまっている。例外は、JSONライブラリの箇所。ちょっと新しいユーザにはわかりづらい。

一方で、Playを利用しないケースとしては、

• Playのテンプレ言語は、Scalaベースでかなりパワフル。タイプセーフ。しかし、Giltとしては、ユーザの体験をもっと動的にしたいので、クライアント側でページの一部をレンダリングして、ページ全体の再読み込みは避けたいという事情がある。典型的なパターンは、ユーザのファーストビューはサーバ側でレンダリングし、それ以降はクライアント側でのレンダリングになる。
• Viewレイヤはシンプルにしたいという方針がある。ロジックはコントローラに移したい。そこで、テンプレとして、handlebars.scalaを使っている。おかげで、クライアントとサーバでテンプレが共有できる。
• 多くのアプリが静的リソースを共有している。リソースは、個別のレポでそれぞれのツール（多くは内製のrakeスクリプト。Gruntに移行しつつある。）を使ってビルドしている。ビルド/リリースのプロセスの中で、sbtを拡張して、それらのツールを呼び出すようにしている。

今後、GiltのマイクロサービスのアプリはPlayがデフォルトになると思う。HTMLのレンダリングが不要な場合でも、両方のレイヤで同じフレームワークを使えるのは便利。

また、Giltで開発中のAPI Docも紹介したい。これは、REST APIをJSONで記述できるもの。スキーマであり、PlayとRubyのシンプルなクライアント、Play向けのルートファイル、及びドキュメントを生成することができる。Swaggerとの違いは、API DocはREST APIのエンドポイントにものすごく特化したつくりになっている。Swaggerはもう少しフレキシブルだという理解。

#gilt #playframework #scala