巨大化・複雑化したモノリシックなアプリケーション開発から、サービスを小さい単位に分割し、開発のスピードを上げようとするマイクロサービスが注目されています。アプリ開発のアーキテクチャとして関心はあるのものの、実際にはどのようなメリット・デメリットがあるのかは気になるところ。

そこで、マイクロサービスアーキテクチャを採用して新サービスをリリースしたという株式会社ビズリーチ・CTO室チーフアーキテクトの竹添直樹さんに、お話を伺ってきました。
聞き手は、HTML5 Experts.jp編集部・岩瀬義昌（@iwashi86）さん、HTML5 Experts.jp編集長・白石俊平さんです。

そもそもマイクロサービスって何ですか？

岩瀬：そもそもマイクロサービスとは、どのようなアーキテクチャなのでしょうか。

竹添：システムをがちっとした一枚岩で作るのでなく、コンポーネントに分割して、小さなサービスの集合体として構築するという考え方がマイクロサービスです。各サービス間は疎結合で、HTTPやMessagingなどでつなぎ、通信し合えるように設計します。

　▲ビズリーチの新サービスをScalaで作ってみた～マイクロサービスの裏側 #jissenscala

岩瀬：一般的に、これがマイクロサービスだという代表例はありますか？

竹添：外側から見ているとわかりにくいですが、Amazonさんのシステムがそうですね。チームがそれぞれ独立してサービスを作っていて、裏側はそれぞれマイクロサービスになっているというのは有名です。

　▲株式会社ビズリーチ CTO室 チーフアーキテクト　竹添直樹さん

岩瀬：モノリシックのほうはどうでしょう。

竹添：小さくてまだ立ち上げたばかりのサービスは、モノリシックが多いと思います。そうしたサービスが大きくなるにつれて機動力が落ち、メンテナンスコストも増大するにつれ、マイクロサービス化するという流れが多いのかなと。

岩瀬：ちなみに例えばWordPressは、がっつり一枚岩で作られている印象があるのですが、モノリシックですか？

竹添：マイクロサービスの粒度をどう考えるかによりますね。ブログという一つのサービスと見ることもできるし、アーキテクチャとしてはがっちり一枚岩だと思います(笑)。

岩瀬：確かに、人によって解釈が違うから定義は難しいですね。

　▲HTML5 Experts.jp編集部　NTTコミュニケーションズ 技術開発部所属 岩瀬 義昌さん

竹添：たとえば、決済サービスは呼ぶ側からすれば、マイクロサービスと言えるかと。

岩瀬：たしかに！では、Web制作で最近よく見るシングルページ・アプリケーションはいかがでしょうか？

竹添：フロントエンドがどうあれ、裏側にあるサーバーサイドのシステムが一枚岩かどうかが、マイクロサービスとモノリシックの違いになります。例えば管理者向けの機能とコンシューマ向け機能がそれぞれが独立されたサービスになっていて、APIで必要なデータだけをやりとりする…といった作りがマイクロサービス。フロントエンドとバックエンドのやりとりが、APIでシンプルになっているからといって、マイクロサービスというわけでもないんです。

マイクロサービスのメリットとデメリット

岩瀬：マイクロサービスのメリットって、どんなところだとお考えですか？

竹添：そもそも弊社がマイクロサービスを採用したのは、それぞれのサービスが独立して開発やメンテナンスができるからなんです。全サービスのシステムへの影響を考えなくていいのが、最大のメリットと言えるでしょう。どんなシステムも、運用をずっと続けていくとアーキテクチャが古びてしまうことは避けられません。そのときに全部新しいものに載せ換えるのは、全サービスの停止を伴うことが多いので、リスクも高いしコストもかかる。部分的にメンテナンスしたり、稼働できるというのはいいですね。

運用面やバッチ処理、アップデートも、そのサービスごとに単位で入れ替えたりできる。古いアーキテクチャを差し替えるときや、新しいサービスを立ち上げるときも既存システムを止めずに開発できるので、トライアルもしやすいです。また、SEOが重要なサービスと、業務寄りのサービスとでは目指す方向も、適している技術も違います。サービスごとに技術の選択ができるのは大きいですね。

開発者の問題もあって、全部同じ技術でできるかというとそうでもない。エンジニアによって得手不得手があるので、チームとしてもプロジェクトとしてもスケールしやすい面があるなと。

岩瀬：スケーラビリティはキーワードですね。バックエンドの言語を好きに選べるというのは、生産性も上がるし、組織的なメリットがあると思います。

岩瀬：では、マイクロサービスのデメリットはいかがでしょうか？

竹添：デメリットの部分ももちろんあります。サービスごとに冗長性を考えなくてはいけないので、コストも手間もその分かかります。モノリシックならロードバランサ一つでサービス全体を冗長化できますが、マイクロサービスだとそうもいかないので、オーバーヘッドとかインフラとか運用のコストがかかるのが悩みどころです。

また、実際に開発をやってみるとデバッグが難しいですね。いろんなサービスがつながっているので、どこで落ちたのかがわかりにくい。プログラミング的にも、今まで単純にトランザクションスクリプトで書いていたのがいろんなサービスに分割されていくので、単純にシリアルで呼び出していくとその分遅くなってしまう。

サーバサイドでも、並列に投げられるところはパラレルに取りに行ったりする並列プログラミングや、非同期的な処理を扱うクライアントサイドの知識が求められるようになってきました。慣れていないとキツイかもしれませんね。アプリケーションプログラマに求められるスキルは上がっていると思います。

岩瀬：これまで同期的なコードを書いてきたプログラマが、マイクロサービスでNode.jsなどの非同期な並列プログラミングをしようとしても、前の癖で同期的に書いてしまって、全然パフォーマンスが出ないというのもあり得るわけですね。

ちなみに先ほどデバッグの話が出ましたが、モノリシックに比べて、時間がかかって大変だったということはありますか？

竹添：作っているときはそうでもないんですが、動かしてトラブルがあったときが大変ですよね。結合させてテストしているときや、プロダクションで何か起きたときのトラッキングとか。セッションIDを全部のログに含めるようにするなど、エラーをトラッキングできる仕組みを最初から作っておけばなんとかなるんですけど、それでも難しい時は難しいですね。

岩瀬：設計の段階でわかっていればいいけど、結構大変だってことですね。コツがわかってくるといいのかもしれませんが。

では、サービスの監視についてはいかがでしょうか？
以前、マイクロサービスとして各パーツを構築してみたのですが、クラウド上でサービスを作成・破棄することが多く、監視するサービスが増えて大変でした。もちろん、自動化して監視すればいいと思うんですが、その辺は具体的にどうされてましたか？

竹添：自動で監視できるようにテンプレート化してますね。監視系の運用は、New Relic、Mackerel、SasS、ほかにも使えるものは何でも使ってます(笑)。サーバーの種類に応じて、Webサーバー用やデータベース用などを作ってます。

岩瀬：いろいろ試されているんですね！

マイクロサービスの実践例

岩瀬：ビズリーチでのマイクロサービス実践例について、聞かせてください。

竹添：『スタンバイ』というインターネット上から求人情報をクローリングしてくる求人検索エンジンがそうです。

　　▲求人検索エンジン スタンバイ

垂直方向のアーキテクチャなのですが、コンシューマを向いている部分や、出稿企業に向いている部分、管理的なものや内部のAPIと接続したりといった、マイクロサービスになっています。

バックエンドのいわゆるAPIサーバーなどは、機能別にいろいろあるんですが、フロントも二層に分かれていて、直接HTMLからWebサーバーにアクセスするのではなく、間にAPIをはさんでいます。バックエンドは基本プリミティブに作っていて、フロントのAPIがHTMLを生成して直接返しているところもあります。

岩瀬：共通する処理とかも結構あるんですか？

竹添：認証とかがそうですね。例えばスマホのものであれば、同じようなAPIを共用できます…と言いたいところですが、やはりいろいろ予期せぬことが起こりましたね(笑)。

一応、もともとの思惑としてはチームをスケールさせたいという意図がありました。バックエンドとフロントエンドをきっちり分けて、フロントエンドだけでアプリをメンテできるようにしたかったという意図があったんです。

　▲ビズリーチの新サービスをScalaで作ってみた～マイクロサービスの裏側 #jissenscala

岩瀬：バックエンドはScalaで書かれているんですよね？フロントエンドの人も頑張ってScalaを書かなくちゃならないようなことにはならなかったんでしょうか？

竹添：全員ががっちり（Scalaを）書かなくちゃならない、ということにならないよう、役割分担を決めて、なるべくフロントエンドで修正が完結するようにしています。とはいえどうしても、サーバーサイドのプログラミングが必要になることもあるので、各チーム一人サーバサイドのサポートをできる人を配置したりはしています。その人が作ったパーツを使って、フロントエンドの人がテンプレートを作ったり。

フロントエンドのほうで全部できるのが理想的なんですけどね。開発のライフサイクルが全然違うので。フロントだけデプロイとか、もっと短いスパンでやっていけるといいなと。ちょっと画面を変えるだけなのに、サーバーサイドも落とさなくてはいけないのは避けたいので、将来的はフロントエンドだけで回せるようにしたいと思っています。まだまだ試行錯誤しているところです。

岩瀬：フロントとサーバーサイドのライフサイクルの長さの違いって、重要ですね。最近のフロントエンドでも、AngularやReactとかいろいろ流行があるから、必要に応じて対応していかなくてはいけない部分もありますよね。

竹添：とはいっても、現実的には厳しいところもあります。フロントで完結できずに、サーバーサイドのエンジニアがサポートしなくてはいけない部分はどうしても出てきます。サーバサイドをサポートするエンジニアが少なくてボトルネックになってしまったり、PCとスマホで同じようなAPIを共有できると思っていたら、画面に引きずられて、結局画面のAPIが増えて再利用できなかったりすることもありました。パフォーマンスとか工数面で考えると、レイヤーが増えていくのでいい結果が出なかったり、JSONの処理にCPUを使うなどの性能面の課題もありましたね。

結局、時間的にチューニングしている余裕もないし、直接データベースをいじってしまうこともありました（苦笑）。工数的にも、想定よりかかってしまいましたね。

岩瀬：その辺の開発はホント大変ですよね…。アーキテクチャは毎回試行錯誤されているのだと思いますが、次に設計するときはもっとうまくいきそうですか？

竹添：実は、ここに来るまで何度かチャレンジはしているんです。最初はモノリシックに作って、それをバラしたり。この『スタンバイ』というサービス自体も、最初から大規模で開発することがわかっていました。工数の都合で密結合となっている部分もありますが、最終的には落ち着くんじゃないかと思っています。次からは、あらかじめ手を打って切り離せるところもあるんじゃないかと。

岩瀬：サービスのどの部分が、マイクロサービスに変えていきやすかったといったことはありますか？

竹添：今作っているサービスは、（モノリシックなサービスを）部分的に切り離してマイクロサービス化していったのではなく、一回捨ててマイクロサービスで構築し直したんですよね。既存の安定したサービスの隣や上とかに、新たなマイクロサービスを乗っけていくのであればまだやりやすいのですが、仕様もゆるい状態で全てのサービス開発が並列で進んでいくのが難しいところでした。最初はこの機能とこの機能だけとか縛りを設けて、少しづつ拡張していくとか、一個ずつサービスを作っていくことができればやりやすいと思います。

マイクロサービス導入の選定ポイントは？

竹添：こないだ海外のScalaのカンファレンスに行ってきたときに聞いたのですが、「HootSuite」というSNSのクライアントツールを作っている会社が、PHPのモノリシックなアプリケーションからScalaのマイクロサービスにリプレイスしているという話がありました。

それによると、まず最初に手をつけたのが、認証系だったそうです。なぜかというと一番難しいところだから。最も難しいところから一番最初にやれば、ほかのところもできるでしょうという考え方なんですよね。我々は経験値があまりないので、簡単なところからやろうとするけど、強いチームで「頑張ってやるんだ」という覚悟があれば、あとはできるだろうと。

岩瀬：難しいところからやるって度胸ありますね（笑）。

竹添：コードを静的解析して、どこが一番複雑かを分析してるんですね。リファクタリングと同じでダメなところからつぶしていく考え方じゃないかと。

岩瀬：マイクロサービスはパーツが多いので、モノリシックなサービスに比べて壊れやすいと思うのですが、何か設計のポイントはありますか？

竹添：ユーザー向けのサービスで、一個壊れると止まってしまうようなところは、必ず冗長化させるようにしています。ただ、全部冗長化させるとコストがかかるので、社内向けのシステムやバックエンドで動いているバッチ処理など、1日くらい止めてもいいサービスならゆるめにするとか、強弱をつけて冗長化しています。

岩瀬：クリティカルなところはかなり力を入れているんですね。

竹添：検索サービスは弊社のサービスとしてかなりメインになっていくので、スケールすることが前提です。コストをかけても実装しておくようにしていました。

岩瀬：マイクロサービスは冗長化しておくように、頑張って作らないといけない部分もありますよね。

竹添：弊社はAWSを使っているのと、冗長化についてはかなり学んでいるので、その辺はなんとかなっています。もちろん、エンタープライズのミッションクリティカルなものと比べると、やりきれていない部分もありますけどね。本当なら相乗りさせられるものはしたほうが運用も楽になるし、コストも下げられると思いますが、まだそこまでやりきれてない。

岩瀬：今回はマイクロサービスで作ったけど、次回はモノリシックで作ったほうがいいとか判断に悩むことがあると思うのですが、何か選定ポイントはありますか？

竹添：開発のときのオーバヘッドや、インフラコストで見ると、短期的にはデメリットのほうが大きいと思っています。どこかで損益分岐点はあると思うんですが。とりあえずスモール仕立てでやってみようとか、成功するかまったくわから状況なら、モノリシックで作って、後から大きくなったタイミングでマイクロサービスにしてもいいのではないでしょうか。

ただ、Webのサービスが大きくなるときはビジネスとして勝負時だし、攻めどきなので、 その事業が大きくなるタイミングでシステムを止めてコアアーキテクチャを変えるという判断は簡単にはできません。経営判断が必要になるかと。

もしリソースがあるなら、現状のモノはエンハンスを続けながら、マイクロサービスで作りなおすなど、体制を組むという選択肢もあるが難しいですね。特に企業向けのサービスをやっていると、機能的に変わってしまうとか、デグレードしてしまうのは、許されない面もあるので。最初からこれだけ大きなサービスにするというように決められたら、マイクロサービスで作るという判断もできると思います。

大きくなったタイミングで経営判断もあるが、あきらかにスケールすることが見えていればマイクロサービスにするほうがいい。ある程度大きくなってくると、プロダクトとしても、チームとしてもマイクロサービスでないとスケールできない。モノリシックだとレガシー化してしまうので、新しい技術も入れられないし、新陳代謝していかないと新しい人も入ってこない。両面的に健全ではないです。

岩瀬：例えば新しくチームメンバーが増えたとき、モノリシックなら全体像が見えるけど、マイクロサービスは全体像が見えにくくて困る…といったことはないのでしょうか？

竹添：それはもちろんありますね。ただ、ひとつひとつのサービスのインターフェイスが明確であれば、それほど問題はないはずです。サービス開発を立ち上げたばかりだと難しいところもありますが、なんとか頑張って、インターフェイスだけはちゃんとしようと思っています。まだそこまで到達していない過渡期ではありますが…。

岩瀬：インターフェイスは、ほぼJSONでやりとりしているようですね。JSONのスキーマはどのように定義しているのでしょうか？JSON Schemeを使ったりしているのでしょうか？

竹添：インターフェースは、内部ではScalaのオブジェクトで定義しています。JSONを直接さわることはほぼありませんね。ただそれだと、（Scalaを知らない）フロントエンジニアにとってはハードルが高いので、そこもカバーできるようなものがあるといいのですが。型定義の強いTypeScriptにトライしているチームもありますね。

白石：インターフェース定義がJSONを前提としていないということは、他のシリアライズ方法に切り替えることも難しくなさそうですね。先ほど、JSONのシリアライズ・デシリアライズ処理の負荷の話が少し出ましたが、例えばそれをJavaのシリアライゼーションやProtocol Bufferに置き換えたりすることで、処理負荷を軽減することもできるんでしょうか。

竹添：その辺も研究はしています。ただ扱っているデータがテキストが多いので、バイナリ形式にしてもあまり速くならないんですよね。MessagePackとかも試しましたが、あまり変わらなかったので、今は使いやすさでJSONを選んでいます。コンパクトな情報でやりとりしているところは、プロトコルを変えたりとか、今後検討の余地はありますが。

白石：マイクロサービスのAPI設計はどのように行うのですか？サービス同士が複雑な依存関係を持たないように設計するには？

竹添：マイクロサービスの設計を適切に行うのはなかなか難しいですが、あるまとまった処理を他の部分から独立させうるかどうか、複数のサービスから利用されうるかどうか、といったところがひとつの判断基準になると思います。その上で、データベース処理を必要とするかどうかによって、ライブラリとして実装するか、サービスとして実装するか判断する感じでしょうか。データベースアクセスを伴わないなら、ライブラリとして配布すればいい。データベースアクセスを伴うのであれば、マイクロサービスにすることを考えますね。

白石：データベースって、どうしているんでしょうか。マイクロサービスごとに別々のデータベースを持っているのか、それともひとつのデータベースを複数のマイクロサービスが共有しているイメージでしょうか？

竹添：いえ、マイクロサービスごとにデータベースは分けています。

白石：じゃあ、トランザクションはどうするんですか？

竹添：マイクロサービスごとに切ってますね。

白石：マイクロサービスをまたがるような処理を、ひとつのトランザクション内で行いたいという場合はありませんか？

竹添：それぞれのマイクロサービスを、適切な粒度で切っているので、基本的には大丈夫かと。もっと大きくなって出てこないとは言い切れないかもしれませんが、そうなったら外側の仕組みでなんとかするかんじですね。

白石：SOAPという選択肢はないですか？WS-Transactionとかあると思いますが。

竹添：ないですね。フロントがスマートフォンのアプリだったり、JavaScriptだったりするので、フロントエンドから使いやすいフォーマットということで。トランザクションが必要なところが切り出せているのと、参照系がほとんどなので現段階では問題として浮上していませんね。出てきたときには、大きな課題になるかもしれませんが。

白石：マイクロサービス・アーキテクチャと、アジャイル開発との相性はいかがでしょう？特に、複数の小さなチームが連携しなくてはならないとなると、それぞれのチームがアジャイルに独立して進めるのは難しいのでは…と思ったのですが。

竹添：私たちもスクラムで開発していますし、マイクロサービスとアジャイル開発の相性は良いと思っています。マイクロサービス間で、密に連携しなくてはならないという状況はそれほど多くないですし、そうした必要が生じた場合は、マイルストーンを置いて調整します。

白石：例えばサービスに一個の機能を追加するとき、チームを横断した変更が必要になったりしませんか？

竹添：チームとしてはマイクロサービスごとに（フロントエンドからデータベースまで）縦に分けているので、チーム内で完結しますね。そして、それぞれのチームの中でフロント・サーバーなどの役割分担があります。ひとつひとつのサービスの粒度も、小さいものから大きいものまであります。単機能のサービスもあれば、大きなWebアプリケーションだけど一つのマイクロサービスというものまであって、その中でスクラムを回すかんじですね。

白石・岩瀬：いろいろ試行錯誤やチャレンジをされているお話を伺い、マイクロサービス・アーキテクチャ実践のポイントが見えてきた気がします。本日は貴重なお話をありがとうございました！

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、エンタープライズ・アーキテクチャについて取り上げます。

HTML5・モバイル・IoT・ウェアラブルなどビジネス環境が激変する中、エンタープライズ・アーキテクチャはどういう課題を抱えていて、どうあるべきなのか。今回は、JJUG (日本Javaユーザーグループ）でご活躍中のお二人に話を伺うことにしました。

アーキテクチャを主軸に第一線で活躍しているグロースエクスパートナーズ株式会社 執行役員の鈴木雄介さんと、「流しのアーキテクト」を自称する株式会社アーキテクタス 代表取締役の細川努さんを交えて、エンタープライズ開発出身の白石俊平編集長がさまざまなトピックスをぶつけていきます。

XML Webサービスは今どうなったのか

白石：とりあえず、昔話から軽く聞いてみたいですね。まずは、エンタープライズ内のシステム間連携でよく話題に上がる、SOAPとRESTについての現状について、どうお考えでしょうか？

鈴木：SOAPは下火だと思われがちですが、私の知る限り、今でもよく利用されています。RESTとJSONの組み合わせも当然よく使われているんですが、（SOAPは）WSDLで型定義ができるので、それなりにかたいシステム間連携だったりすると、WSDLがあるほうがコードの自動生成もできるし、非常に楽なのでよく使われています。

　　 ▲グロースエクスパートナーズ株式会社 執行役員 鈴木雄介さん

細川：とはいえ、SOAPの上位レイヤで規定されているWS-ReliabilityだとかWS-Securityなどの様々なプロトコルは、あまり使われていない印象です。

白石：では、システム間連携などではプレーンなSOAPがよく使われているということですね。

鈴木：まあSOAPもRESTも用意する、というパターンが多いんじゃないでしょうか。オブジェクトモデルは同じで、それをSOAPでもJSONでも表現できるように設計しておくというパターンは、比較的多いような気がします。

細川：あと僕が気になるのは、スケーラビリティなんですよね。SOAPだとちょっと気になるのはやっぱりシリアライズ・デシリアライズの処理が重いし、トラフィックも増大するじゃないですか。そういった意味だとやっぱりREST + JSONのほうにもメリットがありますね。本来だったら使い分けみたいなところが重要なんですけど、いまだにSOAP一択という開発現場も多い。

　　　▲株式会社アーキテクタス 代表取締役 細川努さん

白石：どっちかに寄せちゃったほうが考えることが少なくて、楽ってこともあるかもしれないですね。

鈴木：一長一短…というとつまらない話になってしまいますが（笑）、実際のところそういう結論になっちゃいますね。HTML5が盛り上がっている現在、JavaScriptと相性が良いJSONにはすごく価値がある。一方で例えば、日付型をどう扱うんだとか、型定義やコードの自動生成がしづらいというJSONには苦手な分野もあるのですが、SOAPはそういう部分に強い。「SOAPはXMLだからダメ・ダサい」ということは、実際のシステム開発には全く当てはまらないと思いますよ。

エンタープライズアーキテクチャパターンは今も有効か

白石：アーキテクチャという点では、マーティン・ファウラーのエンタープライズ アプリケーションアーキテクチャパターンが昔は王道だったかとと思うんですが、それは今も有効なんでしょうか？

鈴木：あれは普遍的なものなので、時代が変わったからといって使えなくなってしまうようなものではありません。ただ、昔と比べると今はWeb API主導型のアプリケーションが主流になりつつありますね。クライアントのマルチデバイス化は当然エンタープライズでも相当重要なので、「サーバー側はAPIを提供するだけ」というスタイルに移行しつつあるのは、Webでもエンタープライズでもまったく変わらないと思います。

白石：具体的には、JAX-RSを利用するとか？

鈴木：JAX-RSもありますし、JSON用のバインディングAPIもJava EE 7で標準化されたので、何の違和感もなく使えますね。

細川：エンタープライズ アプリケーションアーキテクチャパターンは非常に洗練されていたのですが、実際のエンタープライズ・アプリケーションはもっと泥臭いです（笑）。 例えばマーティン・ファウラーの提唱するモデルだと、プレゼンテーションレイヤからデータレイヤまでが3、4層ぐらいなんですが、実際はビジネスロジックだけで3層以上に分けたりとか、ビジネスロジックとプレゼンテーションの間にいろいろ挟んだりとか、端から端まで数えると下手したら10層ぐらいあるものも実際のプロジェクトでは山ほどありました。

白石：僕もそういうプロジェクトをやったことがあります。なんか別のメソッドを呼び出してるだけのメソッドが大量にあったり（笑）。

細川：そうそう。なので、どちらかというとほんとに綺麗なレイヤリングはできてなかったというのが現実ですね。最近、６〜７年以前につくられた数十万ステップくらいのシステムをいくつか実際に解析してみたんですけど、結構面白い結果が出たんですよ。サーバーサイドJava（JavaEE）としては最新ではなく、まだJ2EEと呼ばれていた頃のシステムです。どのシステムも、一番複雑度が高いのはビューとデータアクセス（永続化）、アーキテクチャ共通系のモジュールです。ビジネスロジックの部分は量は膨大なんですけど、複雑度自体は比較的シンプルなんです。

何が言いたいかというと、古い世代のサーバーサイドJavaは、ビューとアーキテクチャ制御に作り込みが必要で、そこのところが本当に大変だった。例えば、ビューのところのバリデーションなんかは、かなり作り込みが必要で、簡単な画面作るのも相当手間がかかってたんですよね。結局は、かつてのJava EE（J2EE）って、エンタープライズ系プログラマーが本来集中すべき業務上のロジックにあんまり集中できていなくて、もっと簡単にできるはずのところに手間がかかっていたのが現実だったんじゃなかったかなと。

白石：ほんとにそうですよね。オブジェクトの変換とか、別のメソッド呼び出すだけとか、ファサード作ってそこに一生懸命集めるだけとかやっていて、なにやってるんだろうこれは…とか思っていました。

細川：以前はそうでしたね。そのレガシーなところが今はみんなの足を引っ張ってる（笑）。現在は、それがどれだけ良くなってるか、というところですよね。

白石：今の流れをまとめると、ビューの複雑なところっていうのが、だんだんクライアント側に寄ってきていて、ようはHTML5でリッチクライアント化されてきて、サーバー側はAPIを提供しているだけになっていると。

鈴木：大きくはそうです。ただ、エンタープライズシステムの場合、とにかくシステム間連携が多くて、1つの企業の中でいろんなシステムがあって、ほとんどのシステムが関連付いているのが当然になっています。そうするとクライアント側からするといろんなシステムにいちいちログインして使うのは面倒くさいので、どうやってシンプルに使うのかというのが今の大きなテーマになっていると思います。サーバー間で連携したり、クライアント側でアグリゲーションしたりというのが今の課題としてあって、エンタープライズの場合は、そこがシンプルにならないので、それがひとつの前提になっています。

白石：なるほど。そのシステム間連携がさきほどおっしゃっていたようにXMLベースだったり、RESTだったりという感じですね。

鈴木：はい。企業って、いろんなユーザーといろんなシステムがあるので、いわゆる一般コンシューマー向けのECサイトのようなシステムもあれば、例えば人事システムみたいなものもありますよね。人事システムだと、人事部だけが使うのでユーザーが10人しかいなかったり、でも社員数10万人を支える人事システムっていうと相当でかいっていうものだとか。じゃあその2つが同じアーキテクチャで、同じ作り方でいいんですかっていうと全然そうじゃないですよね。

企業の中のさまざまなシステムの中で、HTML5に合うものもすごく増えてますし、HTMLの可能性が広がったことでやれることもすごく増えましたが、一方でそれが銀の弾丸ではないです。ここはRESTでつくったらいいよねとか、ここはWSDLがちゃんとあってSOAPでやったほうがいいよねっていうのがある。そこは全体の中での選択してやっていけばよいことです。エンタープライズの人って古めかしい人印象があるかもしれないですけど、新しいことも古いこともやらきゃいけないので、そういう意味ではちゃんとまともにやっている人は、それを両方うまくバランスよくやっていますね。

エンタープライズとモバイル

白石：最近のエンタープライズ業界に疎くて、初心者的な質問で申し訳無いのですが、モバイルをエンタープライズで使うというのはもうかなり普通に行われていることなんでしょうか。

鈴木：そうですね。モバイル、タブレット、PC、専用の機器とか、何を何に使うといいよねっていうユースケースはちゃんと考えなきゃいけないですが、モバイルはものすごく重要なツールとして使われています。

白石：エンタープライズでモバイルといえば結構HTML5が使われているという話を聞くのですが、実際そうなんですか？コンシューマ向けだと、ネイティブアプリが全盛です。

鈴木：そもそもモバイルという文脈で求められる操作性とか機能が、エンタープライズの場合はそんなにネイティブでやらなくてもいいようなものが多いので、HTML5がフィットしてるんじゃないかと思います。例えば、ゲームはネイティブアプリがいいといわれますが、別にあそこまでビジュアル的なものとか、細やかな操作性はあんまり求められることはないと。

なので、HTML5でやるっていうのは多いんじゃないでしょうか。Webアプリであれば、リリースも楽ですしね。去年ぐらいまでは写真とか音声とかでいろいろやろうとすると、まだまだHTML5では制約が多いということでネイティブアプリという選択もありましたが、そうした制約もブラウザが進化してきてだんだん問題にならなくなってきています。

白石：なるほど。ちなみに、そうしたHTML5で書かれた業務アプリは、ハイブリッドアプリとしてインストールする形が多いのか、それともWebサイトとしてURLでアクセスする形で作るんでしょうか。

鈴木：それは両方あります。どちらにも利点があるので。

クラウドがアーキテクチャに与えた影響は？

白石：これも初心者的な質問で恐縮です。クラウドがエンタープライズのアーキテクチャに与えた影響はありますか。

鈴木：もちろんあります。クラウドができたことで一番大きかったのは、PaaSという概念ができたことですね。あるニーズに特化したものっていうのは共有化されたものが使われるべきだっていう概念がはっきりしたのはPaaSのおかげです。例えばAWSのラインナップを見て貰うとわかるんですが、CDNありますねだとか、ロードバランサありますねだとか、ストレージ、サーバーノード、認証認可とか、メールの配信サービスとか、ああいうものはPaaSとしてみんなが共有して使うべきだという概念ができた。

なので、そういうプラットフォームを用意してその上にアプリケーションを作って、アプリケーションはUIを含めてそれだけに特化して、なるべくプラットフォームの機能をうまくつかってやっていくていうアイデアは、今のエンタープライズでも浸透している考え方だと思います。

細川：開発者視点でいうと、開発者ができる領域が増えてきましたね。従来だと、サーバ構築とソフトウェア開発は別々のものでしたが、プログラマーがだんだんとクラウドを前提にして、環境を構築するようになってきた。そうすると、同時にパフォーマンスだとかセキュリティだとかをエンジニアが自分で考えなきゃいけない時代になってきていて、Webエンジニアだとかエンタープライズエンジニアとかの区別はなくなってきている。そういう意味では、フルスタックで両方できなきゃまずいんじゃないでしょうか。

鈴木：もうそれはエンタープライズでも間違いなくそうですね。

細川：もうひとつの特徴としては、昔は大規模＝エンタープライズということが多かったんですが、今ではコンシューマー向けとかゲームだとか、そっちのほうがより大規模なんですよね。それを実現しているのがやっぱりクラウドなのかと思っています。そういった意味でも、これからはWebエンジニアこそ大規模を得意にならなきゃいけないんじゃないかと。サーバーとクライアントのメッセージの単位なんかもパフォーマンスに大きく影響するので、そういったところも、かなりノウハウを積まないといけなくなってきています。

エンタープライズ・アーキテクチャの未来像

白石：IoTとかウェアラブルとかを見据えて、今後どういうふうにエンタープライズ・アーキテクチャが変わっていくべきか、ご意見はありますか？

鈴木：IoTを真剣にやろうとすると、先ほど細川さんが言っていた大規模っていうのがエンタープライズに戻ってくるんですよね。対応するデバイスの数が、今まではユーザーが数万人ですんだのが、億になるかもしれない。例えば、すべてのダンボール箱にチップがついたらどうなるんだろうっていう世界を考える。そうすると日本で流通しているダンボール箱は何箱あるんだとか、ものすごいクライアントの数になってしまう。そうなってくると、エンタープライズがまた大規模な性能を頑張らないといけなりますね。

例えば、わかりやすい例でB2Bのケースを考えると、トラックをトレースする仕組みを作ることになったとします。じゃあ全国にあるトラックを全台管理しますとなったときに、全部で何台あるのか。1台のトラックにセンサーがいくつついているのかということになると、センサーが車輪それぞれにあって、それぞれのタイヤのすり減り方を計測して、運転手が寝てるんじゃないかというのを監視するセンサーがあって、速度・加速度をとるセンサーがあって…というようにトラックにすごい数のセンサーがある。

そして、トラックを1万台管理します、データを500msごとに取るとすなると、ものすごい数になる。つまり、B2BでIoT、ウェアラブルというのはB2Cのスケーラビリティをエンタープライズでもう1回頑張らないといけないということになる。今、Webの人が大規模で頑張っているテクノロジーセット、例えば大量のストリームを処理しながらイベントドリブンでやるっていうのは昔からエンタープライズにあって、それがWeb側ですごく実用化されて使われていたのが、またエンタープライズに戻ってくる。そういう流れが未来にはやってくるんじゃないかなと考えています。

白石：なるほど。ちなみに、もう実際にIoTの案件とか発生しているんでしょうか。

鈴木：相談はかなり増えてきてますね。まだ実証実験ぐらいが多いという感覚ですが。今は車がうまくいっていて、ホンダの事例がわかりやすいです。日本中の車のブレーキの発生情報を集めてるんですけど、それを解析すると事故が発生しやすい曲がり角がわかるんですよね。みんながたくさんブレーキを踏んでいる曲がり角がどこかっていうのを提供しているんですよ。そしたらそれを元に道路の信号とか標識とかを改善するってことをやっています。

まとめ

白石：本日は、エンタープライズ・アーキテクチャについて様々なご意見をいただき、誠にありがとうございました。最後に、読者に向けて一言お願いします。

鈴木：自分たちの生活を考えると、やっぱりエンタープライズ業界の会社が自分達の生活を支えてるわけじゃないですか。それがより便利になったり、役立つようになったり、世の中が進化するっていうのはとても大事なことだと思うんですよ。なので、それが実現されるためにはどうしたらいいのかっていうときに、エンタープライズとかWebとかそういう区切りはどうでもよくて、どうやれば本当に価値がでるのか、そういうのを考えるのが面白い。

ただ、社会基盤として変えてはいけないところもエンタープライズにはどうしてもあるので、それをどのように変えずに、より新しいことにトライしながら今あるものの価値をより高めるのかというところが大事ですね。なので「エンタープライズwww」という風潮はよろしくないと思います（笑）。

細川：2点あって、ひとつは、今までのエンタープライズ開発は、ユーザーの言われたものを作るという風潮が多かったんですが、今後はユーザーと一緒につくるっていうのは大事になってくるんじゃないかと考えています。そういう意味ではエンタープライズ業界もWeb業界と同じようにUXとか、よりユーザーが求めるものは何かというところを柔軟に対応してかなきゃいけない。エンタープライズもWebに学ばなきゃいけないということ。

もうひとつは、今後、変化がたくさんあって、それに対応するためにエンタープライズ側、Web側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。

特集企画「アプリケーションアーキテクチャ最前線」では、さまざまな視点からアプリケーションアーキテクチャをエキスパートたちに語っていただきます。今回は、今話題のAngularJSなどのJavaScript MVCフレームワークの台頭と進化、そして新しいアーキテクチャであるFluxとそのフレームワークであるReactなどについて、既に先行して学んでいるエキスパートたちにその知見を聞いてみました。

今回はフレームワーク対決ということで、エキスパートたちがAngularとReactという陣営に分かれ、それぞれのフレームワークについて疑問点をぶつけたり、議論したりする仮想パネルディスカッションという形式でお伝えします。単なるパネルディスカッションとは違って、キーワードは「プロレス」です。まさかりの投げ合い、disり合いOKという形で、NGワードは「適材適所」「ケースバイケース」などです。白熱した議論をお楽しみください！

　　▲議論が白熱する選手たち。左から、久保田光則さん、金井健一さん、増井雄一郎さん、小林徹さん

選手入場（自己紹介）

白石：さて、それではプロレスを始めていきましょうか（笑）。まずは、皆さんの簡単なプロフィールと一押しのフレームワークなどを教えてください。

（React陣営）
小林：小林徹（@koba04）と申します。前職でソーシャルゲームを作っていました。そのときはBackboneとかAngularとかを使っていて、今はReact.jsに興味があって、業務でも使っていこうかと思っています。　　　　　　　　

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　
増井：増井雄一郎（@masuidrive）です。一押しのフレームワークは、ReactとFluxなんですが、ReactはViewのライブラリなので、Fluxになるのかなと。複雑なことをやるのは嫌いなので、なるべくシンプルに書けるということでReactとFluxの組み合わせは気に入っています。あとは自由度が高いという点も気に入っています。

（Angular陣営）
金井：金井健一と申します。フリーランスで、AngularJS Japanユーザーグループの管理人をしています。一押しはAngularですね。Angularは何がいいかというと、フルスタックなところで、悪い面もありますが良い面のほうが多いんじゃないかと思います。学習コストが高いというのもよく言われますが、それだけ機能が多岐に渡っているということなので、いったん使いこなせればすごくいいフレームワークだと思います。

久保田：久保田光則と申します。アシアルという会社でエンジニアをやっています。会社ではOnsenUIというフレームワークを作っています。3年か4年くらい前からずっとJSとかフロントエンドばっかりやってきていて、ちょっと前はKnockoutJSがいいなと思っていたんですけど、気がついたらずっとAngularJSばっかり書いていました（笑）。Angular2は野心的な方針で、いろんなものを取り込んで最高のものにしていこうという気概が感じられるので注目していかないとなと思っています。

お互いのフレームワークへの疑問点など

白石：このパネルディスカッションの今後の流れとしては、僕のほうからは何かコントロールするということはないので、レフェリーみたいなものだと思ってください（笑）。自由にやっていただければと思います。それでは、今回の本題ということで、お互いのフレームワークについて疑問点だったり、disったりということをお願いします。

小林：Angularは、1.04ぐらいのときに使っていて、実際にプロダクトに使ったんですが、結構情報がなくて辛かった思い出があります。DirectiveってよくわからないのでシンプルにControllerとかScopeとかで頑張ってやったという印象がありますね。

金井：当時は、結構そうかも。ただ今は、ドキュメントも充実してきているので今はさほど辛くはないかなと思いますね。Reactはルーティングとかバインディングとかその辺はどこまでできるんですか？

増井：React自体はほんとにViewだけなので、まったくそこはケアしないですね。Fluxは考え方なので、実はすごい小さいんですよ。Dispatcherだけなので数百行ぐらいしかない。あとそこにどうやってルーティングをやるかというのは、React Routerとか外部のコンポーネントを組み合わせて使うので、標準では持っていないです。そこは大きく違いところだと思います。

僕はAngular使っていないんですが、会社（トレタ）のほうでは、PC向けの機能は全部Angularで作ってるんです。でもそこの中の人に聞くと、CRUDみたいなよくあるアプリケーションは結構楽にできて、Angularがなかったら短期間では作れなかったと思うと言われました。ただ、そういうパターンからはずれてしまうとすごい書きにくいかもしれなくて、拡張していくとき、パターンが複雑化してきたときに本当に耐えうるのかが不安と聞きました。そういう傾向ってどうなんですかね？

久保田：何もかもScopeとかで管理しようとすると結構はまりどころ多いなというイメージがありますね。細かいインタラクションとか、例えばドラッグ＆ドロップを直接使いたいときって、結局DOMを触るしかなくて、DOM触るにはDirectiveっていうものが用意されています。Directiveは、ある程度DOMに対してのいろんな機能を追加するとか、細かいDOMの操作を担当するものなんですよ。全部Controllerで管理しようとするとすごいぐちゃぐちゃになったりするんですけど、ちゃんと自分でDirectiveを作って管理すると扱いやすいと思います。

増井：なるほど。あと、Angular1系と2系ってはたから見てると、2系が年末だか来年だかに出て、結構互換性がないっていう話で、1系は捨てちゃうっていうことを聞いてそこはちょっと怖いかなっていう印象はありますね。

金井：2系が主流になって、1系が減ってこない限りはサポートするという話ですね。なので、そこは早いうちにアップデートしないといけないかもしれません。

増井：でもアップデートってまるまる書き直しなんですよね？

久保田：ng-japanでもアナウンスされてましたが、Angular2とAngular1を共存する方法はあって、1系のコードと2系のコードを混在させることができるようですね。

今からフレームワークを採用するとしたらどちらを使う？

増井：今から新しくプロジェクト始めるときにどのフレームワークで作ろうかみたいなときに、実際に作る人は悩むんですかね。

白石：実際、今作ろうと思っているものがあるんですが、悩みますね。

金井：なんでそこはAngularじゃないんですか（笑）。

白石：Angularはでかくて複雑すぎて怖いんですよね。しかもAngular2が迫っているという。この今のタイミングで採用するのはちょっと怖い。

増井：そういう意味では、僕はReact.jsがなくなっても、React.jsと同じものを書ける自信があるんですよ。FluxとReact.jsをまるっとFacebookがやめました、明日からReactはありませんと言われたときに、僕はReact全体をメンテナンスできる。まるっと同じものを作れっていわれたら、まあ頑張って作れる。Angularは作れる気がしない。

金井：作れる気はしないですね（笑）。

増井：僕は結構そこが怖くて。なので、大きいフレームワークは採用しにくいっていう面があります。あと、MVCの上にMVCを乗っけるというのは、その考え方はすごくToo Muchかなと。サーバーサイドは、サーバーサイドでMVCを作っていて、さらにクライアントサイドでMVCを作るわけじゃないですか。MVCの2階建てはアーキテクチャとして本当にいいのかっていうのはすごく思っていますね。

そもそもモデルをデータベースから作って、ちゃんとAPIにしているはずなのに、それをさらにもう一回モデルとして扱う、あんまり効率的じゃないんじゃないかっていう。Reactだけに限ると、MVCのVしかないので、そもそも書いて読んだJSONをそのままViewで表示するってことをやったりするんです。だけど、実はAPIが揃ってると結構なWebアプリケーションで、そもそもモデルまでおこさなくてもいいんじゃないかっていう気がするんですよ。

金井：JSONをとってきて出すっていうのはAngularでもできるので、それはアプリの設計によるのかなという気がしています。Angularの場合は、さらにそこから変更もできるという利点があります。

増井：それにしてはToo Muchすぎるんじゃないかと。

金井：それだけしたい場合には確かにそうですね。

増井：結構なケースがそれで済むんじゃないかっていう気はしていて。実はクライアント側でMVCが必要なほど複雑な処理するケースってそんなに多いのかなと。

久保田：まあでも実際には、もちろんアプリの要件によると思います。ハイブリッドアプリって結局JSでなんでもやるので、API叩けばそれで終わりというわけじゃなくて、むしろJSのほうでいろんなことを書かなきゃいけないって感じになるので、API叩けばそれで終わりっていう感じにはならないですよね。

APIってネットワーク越しにやるんでそれってすごく重たいし、あんまりやりたくないっていうのはモバイルアプリだと多いです。そもそもモバイルアプリだとネットワーク繋がらないってこともあるので、それを解決するにはローカルのほうでデータを保持して、繋がったら同期をとるっていう感じになるので、モデルがないとちょっと辛いという感じになりますね。

JSXは気持ち悪い？

白石：JSXがキモいんですけど…。

増井：あれは気持ち悪いんですよ実際（笑）。キモいっていうのはまったく異論ないんですけど、あれはあれで理にかなっていると思っています。DOM操作がなんで難しいかっていうとそもそもこのDOMをみたときに、これがいつどこで書き換わるかわからないし、さらにこのボタンを押したときにどこで何が起こるかわからない、イベントは1個じゃなくて100個でも張れるので。っていうのに対してJSXの場合はそういうのを一応ビューとロジックを同じところに書くことで、さらにイベントリスナーを1対1にすることによって、そういう複雑性を省きましょうという考え方なので、気持ち悪いことは認めつつ、理にはかなっているかなと。

1番の問題は、HTMLしか書けない人がこれを触れないっていう。コーダーと分離ができないっていう点ですよね。ただこれはもっと根本的な問題で、Reactは画面の一部をコンポーネントとしてスコープを作りましょうっていう考え方で、HTMLを切ってるんじゃなくて、プログラミングスコープを切ってるんですよ。それって見た目のデザインとはちょっと違って、アーキテクチャのデザインの話なので、見た目とロジックを切り離すっていうところに、そもそも無理があるじゃないかっていうことですね。

金井：そこらへん（画面の一部をコンポーネントとしてスコープを作る）は、Angularも目指すところは同じかもしれないですね。

増井：そのやり方が違うってだけなんでしょうね。

久保田：ちょっといいですか。別にJSXって気持ち悪くなくないですか。

小林：私も全然違和感ない（笑）。

白石：人によるんだ。

増井：僕も去年からReactを知ってたのに触ってなかったのは、JSXです（笑）。あれで毛嫌いして触らなくて、でもあんまり話題になってるので去年の年末年始から本格的に触ってみたというのがあります。あれは僕個人も気持ち悪いです（笑）。

小林：ぱっと見たときに、あれ（JSX）がやりたいフレームワークなのかなと思っちゃうんですよね。

増井：日本でのReactの評価は、Virtual DOMっていう技術キーワードとJSXという見た目にすごく左右されている印象がありますね。

Virtual DOMって本当に早いんですか？

白石：Virtual DOMって本当にそんなに早かったりするんですか。ぱっと考えると差分をComputeとする計算処理も必要だし、フロントのDOMと仮想DOMって2つ持っているメモリも喰いそうだなと思うんですけど、実際はどうなんですか？

小林：実際は何が一番早いかっていうのはやっぱりDOMを直接触るのが一番早いっていうのは間違いなくて、でもそれってコードとしても複雑になるじゃないですか。モデルのデータの変更された部分だけをどういう風に反映するのかっていうところが煩雑になる。Virtual DOMだと、ひとつの状態をもっておいて、パっと更新すると差分だけを綺麗に反映してくれるので、DOMを直接触るよりは遅いですが、該当部分のDOMを全部入れ替えるよりは早いという感じです。最速ではない。

白石：最速ではないと。わりとプログラマーがいい加減な処理をしてもいいってことですね。

増井：Reactはとりあえずざっくり書けば、そこそこ速いっていうような考えですね。

久保田：最近、Atomで内部でReact使ってたけどパフォーマンスのために削除したっていう話がありましたね。

白石：え、そうなんですか。もう使わなくなっちゃったんだ。

小林：最初のやつがちゃんと構造化されていなくて遅かったのをReactにして、ちょっと速くなって。そこをベースにDOM職人が頑張ってやったらさらに早くなったっていう感じですね。

Angularは謎のルールが多い

白石：Angularを触ったり調べたりしたときに僕的には謎のルールがすごい多くてとっつきにくかった。例えば、$変数が多すぎ。何々のときは$なんとかが多くて、なんだこれはっていう（笑）。

金井：あれ何なんでしょうね。$$とかあるしね（笑）。

白石：Dependency Injectionを実装したのはいいんだけど、まず引数の名前で当てるからminifyしないでねとか、minifyしてもいいように別の書き方も発明したよとか配列で指定できるようになったりとか。なんかもう歴史上の問題かもしれないんですけど、謎ルールが多すぎる感があるんですけど。そこらへんはどうなんでしょう？

久保田：やっぱりそこは気持ち悪いなと思います。でも昔からずっと実務上の必要からそういうのが増えてきたのかなと思いますね。あとから来た方がどうしたもの洗練されたものになっていくので…。

増井：Angularっていつできたんでしたっけ？

金井：結構前で、2009年ですね。

増井：そんなに前なんだ！

金井：Angular1が2012年ぐらいなので、そこで注目された感じですね。2009年にできたフレームワークが5年くらい経って実用になりつつも、辛くなってきたということでAngular2を開発しているということだと思います。Angularのいいところっていうのは、その時々で結構先のことを見据えてやろうとしていて、1系だとWeb Componentsを実装したくてDirective作ったりしてるし、Object.observe()欲しいよねっていって2way bindingを実装してみたりとか。どんどん攻めてるんですよね。

増井：そういうイメージはありますね。

実はReactは大きい

白石：ちなみにフレームワークの大きさでいうとどうなんでしょう。

増井：ReactってViewのライブラリだけのくせにすごいでかいんですよ。へたしたらjQueryよりでかい。

金井：フレームワークのサイズが大きいと、モバイルのユースケースで叩かれませんか、重いとか。Angularは相当叩かれた覚えがあります（笑）。

増井：とはいっても画像ひとつ分ぐらいですからね。Reactも実際よくあるReactのダメなところに「でかい」っていうのはいろいろ言われていて、でも現実ユーザーからそういう話があがってるわけではなく、数字で見てっていう部分があります。あと、Reactはサーバーサイドレンダリングを持っているので、ファーストビューはサーバーサイドで出しちゃって、その後にJS読み込むっていうことができるので、そういう意味では十分早いですね。面倒くさいですけど、やろうと思えばできます。

白石：今、ダウンロードしてみたんですけど、Angularがminify時で126KBで、Reactが121KBという結果に。

増井：しかも、AngularはMVCで、ReactはVだけで、ですからね（笑）。

金井：やれること全然違う。（Angularは）ルーティングからバインディングからすべてできるのに（笑）。

検索可能にするサーバーサイドレンダリング

増井：Reactのひとついいところは、サーバーサイド生成ができるのでぐぐったときに引っかかるんですよね。クローラーは基本的にはJSを実行しないので、みんなテンプレートにはじめから引っかかりそうなキーワードを入れたりとかして頑張るんですけど。でもReactはサーバーサイド（Node.js）でReactエンジンを実行してHTMLを生成することができるんですよ。そうすると例えば、基本的な部分をファーストビューで表示すると、JSが実行されなくてもHTMLで画面が見えて、JSが実行されると残りの部分が表示されるという段階的にできるですよ。

そうすれば、検索エンジンに引っかかるし、JSがもし（ブラウザで）動作しなくても本文はちゃんと読めるというメリットがあります。といってもそれをやるには、それなりに考えて書かなきゃならなきゃいけなかったり、その実行エンジンをいろいろセットアップしなきゃいけないので、手放しでできるっていうわけでもないんですが。

小林：海外はやっぱりReact導入してるところは、サーバーサイドレンダリングもやっているところが多いですね。海外のほうがサーバーにNode.jsを使うのは結構一般的で、日本だとあんまりないから意外なんですけど。サーバーサイドレンダリングできるからReact採用してるっていうとこも結構ありますね。BBCとか。

増井：ぐぐれるっていうのはでかいですからね。

白石：なるほど。じゃあAngularのほうは、どうですか？

久保田：まあAngular2に期待ですね。Angular2のレンダリングのアーキテクチャについて設計文書が公開されていて、その中でVirtual DOMを使いますと言っています。

小林：Ember.jsも次のバージョンでHTMLbarsとsimple-domを組み合わせてサーバーサイドレンダリングできるようになる予定で、これからのフレームワークはサーバーサイドレンダリングはついてきそうな気がしますね。

久保田：あと、ちょっと面白いと思ったのがサーバーサイドレンダリングだけでなく、Viewの処理をWeb Workerでやりたいっていう点ですね。

増井：Web WorkerはReactでもやるっていってますね。そんなに進んでないですが。

白石：確かに仮想DOMは、本物のDOMじゃないからWorkerでいじれるし、間のメッセージングにコストがかからなければ割と早そうですね。

増井：そこ（Reactの仮想DOM）の差分の計算までWorkerでやってしまうので、それなりの速度がでるはずですね。ChromeもServiceWorkerとか機能を強化してるのでたぶんそういうのに合わせてるんだろうなと思います。

開発速度・生産性の比較

小林：たぶんReact使っても開発速度って上がらない。書く量も結構増えますね。

増井：むしろ下がります（笑）。プログラムでひとつ大事なところは、1年後に触れるかどうかだと思っていて、よくプログラムは書くより読む時間、回数のほうが多いので読むことを考えて書くべきだって言う考えがありますよね。時間がかかっても読みやすく書いて、それによってコード量が増えるのはプログラムとしてしょうがないんじゃないかっていう考えがあって、Reactはそういう考えに近いですね。なので記述量は減らないし、同じの書いたら5〜10倍ぐらいになっちゃっていう話もあって、あきらかにめんどくさいです。

金井：AngularJSは、預ける部分が大きいので、勝手にやってくれる。コード量は圧倒的に減りますね。なのでCRUD系作るときはすごく早いです。

おわりに

このように議論はすごく白熱して、興味深いトピックスが目白押しでした。楽しんでいただけましたでしょうか。今回は「議論は平行線だった」ということで終わりたいと思います。

おはようございます。編集長の白石です。

昨日（2015年4月30日）、isomorphic tokyo meetupに参加してきました。

というのも実は近々、HTML5 Experts.jpでは「Webアプリケーション・アーキテクチャ」に関する特集を行う予定なのですが、そこでキーワードとして挙げられていたのがisomorphic。 サーバサイドとクライアントサイドでコードの共有を促進するのが主な目的の一つ、というところまでは理解できたのですが、実際のところ、アーキテクチャはどう変わるのか？ それを探りたいと思っていたところ、ちょうどよくイベントの開催がアナウンスされていたので、急遽取材させていただきました。

取材を快く受け入れてくださった、主催のYosuke FURUKAWAさん、本当にありがとうございました。

この記事では、トップバッターで講演されていたkoichikさんの講演内容を中心にご紹介して、isomorphicに触れるきっかけとなる記事を目指します。

なお、本日の講演者の皆様による資料はこちらになります。

isomorphic tokyo meetupの発表資料

「Isomorphic Survival Guide」(by koichik)

Isomorphic Survival Guide

「Isomorphic Web development with Scala & Scala.js」(by TanUkkii)

Isomorphic web development with scala and scala.js

「実践isomorphic (+ Electron)」(by mizchi)

実践Isomorphic(+ Electron)

「Unified Interface on Isomorphic JavaScript」 (by axross)

Unified Interface on Isomorphic Javascript

「やみくも isomorphic から抜け出すために足りてないもの」 (by Jxck_)

※資料は後日公開だそうです。

今日のスライドがちょっと片手間すぎるので、公開はいろいろ直してからにします。 #isomorphic_meetup

— Jxck (@Jxck_) 2015, 4月 30

koichikさんによる「Isomorphic Survival Guide」つまみ食いレポート

koichikさんの「Isomorphic Survival Guide」は、まずIsomorphicという言葉の語源からでした。ギリシャ語で「同じ」という意味を表す「isos」という言葉と、「形」という意味を表す「morphe」という言葉を合わせたものだそうです。

isomorphicの語源

同じ成り立ちの言葉として、「metamorphic」や「polymorphic」があるとのこと。オブジェクト指向の世界で頻繁に用いられる「ポリモーフィック」という言葉が、isomorphicと同様「-morphic」で終わる単語だと気づいたのはこの時が初めてで、ハッとしました。

“-morphic”で終わる言葉はほかにも

で、isomorphicが語られるときには、「クライアントとサーバの間でのコード共有」や「フロントエンドとバックエンドの間でのコード共有」と紹介されることが多いですが、そもそもクライアントとフロントエンド、サーバとバックエンドが同じ意味の単語なのか、そこには人による解釈の違いもあれば、指している意味合いの違いもある、と指摘。

クライアント・サーバという用語とフロントエンド・バックエンドという用語は同一ではない

この講演においては、クライアントとサーバはネットワークの「こちら側」と「あちら側」、フロントエンドとバックエンドは情報の入出力を「人間相手に行う」のか「ストレージ相手に行う」のか、という意味で取り扱う。

本講演における用語の定義

例えば90年ごろの「C/Sシステム」（いわゆる「クラサバ」）は、クライアントのWindowsマシン上で「人間向け」（フロントエンド）の処理も「ストレージ向け」（バックエンド）の処理も行われていました。このように、クライアント＝フロントエンド、サーバ＝バックエンドという対応関係は時代によって変遷してきており、J2EEが提唱した三層アーキテクチャやRIAなど、様々なアーキテクチャと製品が模索されてきました。

C/Sシステム

フロントエンドとバックエンドの変遷

isomorphicに挑戦してきた様々なフレームワーク

こうした中、少しでも開発から無駄をなくすために、クライアント／サーバ、フロントエンド／バックエンドの間でコードを共有できないかという可能性が探られてきました。

「isomorphic」という単語は、筆者としては最近になって聞くようになったのですが、実は2011年にリリースされた 「Flatiron」というフレームワークが提唱した概念だったそうです。4年近くも前から使われていた用語だったのですね。

Flatiron

しかし、Flatironはそれほど普及することなく現在に至ります。その後もYahoo!の「Mojito」や、一時期大きな話題になった（今でもアクティブに開発されていますが）Meteorなど、様々なプロダクトがisomorphicなアプローチにチャレンジしてきました。しかしこれらがあまり大きく普及しなかった要因は、「（プロダクト利用者にとっての）どんな課題を解くのか」が不明瞭だったり、ニッチ過ぎたり、先進的すぎたりしたことにあると指摘。

どんな課題を解くのかが重要

そんな中、Airbnbが2013年に公開した「Rendr」 は、SPA (Single Page Application)の「初期表示が遅い」「SEOが弱い」という課題を解決すべく生み出されたもので、 かなり実用的でした。

Rendr(Airbnb)

RendrはBackbone.jsを拡張してisomorphicな環境を実現するものでした。Rendrは、以下のように様々な可能性を切り開きました。

• サーバサイドにおけるフロントエンドレイヤをJavaScriptで提供することで、クライアントとサーバのコード共有を実現しやすい
• サーバサイドにおけるフロントエンドレイヤがセッション管理を行うことで、バックエンドのAPIをステートレスに保つことができる
• サーバサイドにおけるフロントエンドレイヤがAPIゲートウェイとしてデータ変換を行ったり、様々なバックエンドAPIを組み合わせて フロントエンドに提供する（オーケストレーション）ことを可能にする
• 上記のことから、（サーバサイドにおける）フロントエンドとバックエンドの疎結合な関係や、バックエンドの実装をJavaScript に縛られず自由に開発できるようになり、ステートレスなマイクロサービスが協調して一つのサービスを作り上げるという構成を構築しやすい

Rendr的なIsomorphicの可能性

Reactの波に乗れ！

ですが、Rendrがリリースされた時期はAngularJSが人気を獲得した時期と重なっており、残念ながら大きな話題にはなりませんでした…。しかし今、「仮想DOM」というキャッチーなキーワードを引っさげ、Reactが登場するや、非常な人気を博して今に至ります。

Reactの仮想DOM

しかしReactはあくまでビューだけに特化したライブラリ。アプリケーションアーキテクチャとしては、Facebookが 「Flux」を提唱していますが、公式な実装が提供されたのはFluxの一部分 のみであったため、独自実装が乱立する事態となっています。

Flux

Fluxを用いたアプリの基本的な構成は以下のようになります。 フロントエンド部分に限ってみると、処理の流れが綺麗に一方向（unidirectional）になっているのがわかります。

Flux的アプリの基本要素

そして何よりReactが期待されているのは、仮想DOMの仕組みを応用したisomorphicなアーキテクチャ。クライアントでは仮想DOMを実際のDOMツリーに変換しますが、サーバサイドでは仮想DOMからHTML文字列を出力するようにできるので、クライアントとサーバのどちらでも同様のコードが実行できるわけです。

Reactに関係するisomorphicなライブラリには、以下の様なものがあります。

Reactに関係した、Isomorphicなライブラリ

Flummoxも期待のライブラリ。

Flummox

Yahoo!が開発中のFluxibleは、比較的重量級なアプローチの、isomorphicなFluxアプリケーションコンテナ。

Fluxible

Fluxibleが使用する「Fetchr」は、バックエンド（の窓口となるWeb API）へのアクセスを、クライアントサイドとサーバサイドで同様のコードを用いることを実現します。正しくセットアップしていれば、Fluxアプリケーションのisomorphic化を促進できると期待されています。

Fetchr

まとめ

isomorphicなアーキテクチャは長い間模索されていましたが、これまでいまいち波に乗り切れていませんでした。しかし今はReactが非常に人気を博し、isomorphicなアーキテクチャの実現に対して、多くの人々が注力しています。

マイクロサービスとの相性も非常に良いと考えられ、今後大きな潮流になっていくのは間違いないでしょう。

まとめ

Reactの波に乗り遅れるな！

HTML5の時代となり、フロントエンドの重要性が増してきています。業務システムにおいても、HTML5を本格的に適用する事例が増えてきました。このような環境において、バックエンドを含めた次世代アーキテクチャのベストプラクティスを模索するというのが本記事の趣旨です。

本記事では、HTML5時代におけるアーキテクチャの概要を提示した上で、アーキテクチャ実装の具体例として、「OData＋UIフレームワーク」を採用した事例を紹介します。その上で、このアーキテクチャを採用した場合のメリットと、今後の課題について記述していきます。

HTML5時代における業務システムアーキテクチャのポイントとは

業務システムにおけるHTML5化の流れについては、「JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例」にて、エキスパートの佐川夫美雄さんが語っているように、HTML5時代において「JavaScriptフレームワークを用いたWebアプリケーション」が主流となることは、私自身も間違いないと感じています。

佐川さんが記事の中で語っているように、従来はブラウザで表示するためのHTMLをバックエンドが作成していましたが、今後はデータのみを返して、フロントエンドでHTMLを組み立てる方法が、今後は主流となっていくことでしょう。
その上で、どのようなアーキテクチャになるのかを考えてみると、フロントエンドとバックエンドを切り離した俯瞰図を描けるかどうかが、大きなポイントとなります。

こちらにアーキテクチャ俯瞰図を記載します。

では、大きな3つの構成要素について見ていきましょう。

1.フロントエンド

フロントエンドはAjaxの普及以降、大規模・複雑化が進んでいます。最近では、「Backbone.js」「AngularJS」に代表される「クライアントMV*フレームワーク(※)」と呼ばれるライブラリをベースに構築されることがほとんどです。その場合、UIは「Bootstrap」など「CSSフレームワーク」と呼ばれるUIのみの特化したライブラリを組み合わせることが主流です。また、「Sencha」に代表される、UIコンポーネントと呼ばれるUI部分を含んだオールインワンタイプの「UIフレームワーク」を利用するケースもあります。

(※)クライアント側フレームワークはMVC、MVVM、MVWなど複数の考え方が存在しているため、それらをまとめて「MV*」と表現しています。

2.バックエンド

HTML5時代のバックエンドは機能特化型で進化してきました。フロントエンドに対してWeb APIを公開し、主に、永続化やトランザクション・認証管理・サーバーサイドキャッシュなどの用途で利用されます。また、セキュリティ上の理由でフロントエンドに配置できないビジネスロジックを配置します。そのため、従来のオンプレミス環境にとどまらず、クラウド上に構築されたり、BaaS、（モバイルに特化した）mBaaSなど、クラウドサービスを利用するケースもあります。

フロントエンドから見たバックエンドは、「JavaEE7（JAX-RS）」「Node.js」「Ruby on Rails」など、どんな言語やフレームワークで実装されているかは、あまり重要な違いではありません。重要なことはバックエンドがどのようなWeb APIを公開しているかということです。

3.通信

通信は主に軽量で、JavaScriptでの扱いが容易なJSONが主流となっています。ただし、システム間連携といったユースケースに代表されるような、厳密にデータ型を指定したい状況ではXMLの使用も一考に値します。

業務システムアーキテクチャのポイント

このように、HTML5時代における業務システムアーキテクチャのポイントとは、バックエンドとフロントエンドを切り離し、Web APIを経由してデータアクセスしていることです。そして、特に重要なことはWeb APIのインターフェースをどのように設計するかです。

バックエンドとフロントエンドを分割するアーキテクチャを採用した場合のメリットは、並行開発ができるということがあります。そして重要なことは、両者を紐づける制約がWeb APIのインターフェースであるため、インターフェースさえ守って入れば、片方に影響を与えることもなく、もう片方を作り替えることができるということです。例えば、オンプレミス上で構築してある古いバックエンドを、クラウド上に他の言語で再構築するようなことも可能です。

バックンドのWeb API化は、ビジネス変化の激しい今日において、業務システムが安全に変化し続けるための最重要要件だと考えています。

業務システムにおいてWebAPI設計を難しくする3つのポイント

HTML5時代の業務システムは、WebAPIを介した疎結合なアーキテクチャに移行していくのがトレンドであることは先ほど述べた通りです。フロントエンドとバックエンドの並行開発を成功させるためには、正しいWebAPIを早期に設計することが重要です。

WebAPI自体は、Web2.0時代にブームがあったように古い歴史のある技術であり、ノウハウが蓄積されている部分もありますが、ここでは業務システムにおいてWebAPI設計を難しくする3つのポイントについて提示した上で、WebAPI設計をどのようなスタンスで進めて行くべきか記述します。

1. データアクセス条件の多様性

売上データのWebAPIを例に説明すると、業務システムでは同じ売上データを取得する際に、様々な条件を与えます。これは、業務システムを利用するユーザーに多様性があるためです。例えば、拠点・店舗・地域・売上日・担当者・品目などの項目が挙げられます。さらに画面ごと、ユーザのロールごとに細かく条件が異なる場合も存在し、多様性を考慮した設計が必要です。これらの条件はWebAPIのURLパラメータとして定義される項目です。

URLパラメータを設計した後に並行開発していくのですが、当初から正しいURLパラメータを設計することは難しく、必ず後の工程に変更が入ります。

2. データアクセス時のエンティティ間の関連

データアクセス先が、複数のマスタデータ（エンティティ）を結合したデータを返すことも特徴です。これは、業務システムが扱うデータが、複数のエンティティに正規化された上で保持されているためです。売上データに対する店舗などのマスターデータをイメージしていただければ、分かりやすいかと思います。

こちらも実際に実装してみると過不足が多く見つかるポイントです。

3. トランザクション処理

WebAPIはステートレスの前提で作られているため、WebAPIをまたがるトランザクション処理は苦手です。特にロールバック処理を行いたい場合は、WebAPI単独で処理が完結してしまうため、以前の処理を打ち消すWebAPI呼び出しを行う必要があります。

そのためトランザクション処理を行う場合は、WebAPIとバックエンドの処理の間にトランザクション処理を担うレイアーを作成するような工夫が必要で、業務のトランザクションを考慮したWebAPI設計が必要です。

WebAPI設計にて取るべきスタンスとは

業務システムにおいてWebAPI設計を難しくするポイントについて説明しました。フロントエンドとバックエンドを繋ぐWebAPIは両者の影響を受けやすく、将来を見越して設計することが難しいこと、理解していただけたかと思います。そのため、WebAPIの設計は「最初に設計を固める」より「作りながら育てる」というスタンスで取り組むべきだと考えます。

次は、HTML5時代のアーキテクチャを実現する具体例として、「OData＋UIフレームワーク」の組み合わせを紹介します。

作りながら育てるWebAPI設計を実践するための1つの選択肢「OData」

WebAPI設計は「作りながら育てる」と提示しましたが、終わらないタスクほど嫌われるものはありません。実際の業務システムの開発においては、将来の変更も見越した網羅性のあるWebAPI設計を行って、後の変更の影響を最小限に止める方が現実的です。

最初に網羅性のある設計ができ、変更にも柔軟という、そんな都合の良いものが果たしてこの世の中に存在するのでしょうか？　そこで、注目したものがODataです。

ODataとは 「Webアプリケーションにおける、データアクセス方法を標準化したプロトコル」です。Microsoft、IBM、SAP、Citrix社など中心となりデータアクセスプロトコルの業界標準となるよう動いています。WebAPI版のODBCやO/Rマッパーのようなものと言えばイメージしやすいと思います。

ODataはHTTPをベースにしているため、一つ一つのデータアクセスは通常のHTTPでのWebAPIとなんら変わりませんが、次に代表されるようなデータアクセスに関する様々な指定をURLパラメータとして標準で定義しています。

• 順序指定：$orderby
• ページング：$skip(開始位置）$top(取得件数)
• フィルタ：$filter
• 部分取得：$select
• 関連エンティティ取得：$expand

URLパラメータの詳細はこちらを参照ください。

このように、URLパラメータでデータアクセス方法を柔軟に変更できるため、従来は大掛かりな変更が必要であったWebAPIの変更が、URLパラメータで吸収できることが多くなります。従来のWebAPI設計が変化に弱い硬直的なものだとすると、ODataを利用したWebAPI設計は変化に強く柔軟なものです。

しかし、OData特有のURLパラメータを生成することが非常に面倒であるため、今日まであまり普及しなかったことも事実です。最近ではdata.js、Breeze.jsなどOData対応のJavascriptライブラリが登場し、UIフレームワークのOpenUI5と融合することで状況が変わったと考えています。

ODataとUIフレームワークの融合がもたらすメリットとは

ODataとUIフレームワークが融合することの最大のメリットは、データアクセスからUIへの結果反映まで、難易度が高く繊細な部分をUIフレームワークで隠蔽できることです。

UIコンポーネントに対してODataとのマッピングを施すことで、UIフレームワーク側でユーザの操作(ページングやフィルタ処理など)があった際、自動的にバックエンドへデータアクセスするためのURLを生成します。さらに、バックエンドから取得したデータはUIフレームワークが自動でUIコンポーネント側へ変更を反映します。

私が携わったシステムでは、UIフレームワークとODataを組み合わせることによって、データアクセスとUIへの結果反映の部分のコード量を、大幅に削減することができました。こちらが、ODataとUIフレームワークを適用した場合のアーキテクチャの概要図です。

（※）ODataを利用するためにはOData仕様に準拠しているWeb APIを実装しているバックエンドが必要です。これをODataServiceと呼んでいます。

ODataとOpenUI5を利用した実装例とチュートリアルについては、私が作成したOpenUI5とODataを使ってWebアプリケーションを作るに一通り記載したものがあります。参照していただければ雰囲気がつかめると思います。

上の紫の部分がODataとUIフレームワークを組み合わせることによって隠蔽される部分です。フロントエンドが得意なエンジニアが少ない、業務システム開発の現場にてこれだけ実装する範囲を隠蔽できるのであれば、現実味のある選択肢の1つではないでしょうか？

そんなに甘くないぞ！バックエンドのOData化。救うのは.NET系エンジニア

一見、幸せになれそうに見える「OData+UIフレームワーク」アーキテクチャですが、最大の課題はバックエンドのOData化です。私の携わったシステムでは「SAP Netweaver Gateway」というSAP社の製品を導入することでバックエンドのOData化を実現しています。

現在、もっとオープンかつ手軽な方法でOData化が実現出来ないか模索しています。中でもMicrosoftの「ASP.NET Web API 2.2」は少ないコード量でODataを生成することができ、今最も注目しているOData化の方法です。 今後は、「.NET」系のノウハウとコラボレーションしていき、より簡単にバックエンドのOData化が実現できるようしていきたいと考えています。

さいごに

今回は、いくつか有効性を検証しているアーキテクチャの中で、「OData＋UIフレームワーク」という、一般的にあまり知られていないアーキテクチャを紹介しました。今後、様々なUIフレームワークがODataを標準でサポートし、より選択肢が増えることになれば、一気に業務システムのHTML5化におけるデファクトになる可能性があると感じています。

また、業務システムを切り口にした場合、一般的なWeb開発では注目されないテクノロジーに注目することも、なかなか興味深いです。

HTML5時代の業務システムにおいて有効なアーキテクチャはいくつも存在すると思います。これを機に、このような議論が業界内で進むことを期待しています。そして、日本のエンタープライズITをより良いものにしましょう！