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

そこで、マイクロサービスアーキテクチャを採用して新サービスをリリースしたという株式会社ビズリーチ・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側が両方対応しないと対応できないんじゃないかなと思う。これらの技術の変化に対応できるようにフルスタック、両方できるようなエンジニアが増えてくると心強いんじゃないでしょうか。

楽天では、10月26日に「Rakuten Technology Conference 2013」を開催し、多くの方にご来場頂きました。ご参加者の皆様、ありがとうございました！

私が所属している「HTML5 Project Team」が担当したセッションでは、今回制作を担当したカンファレンスのサイトについて発表をしました。技術者の祭典ということもあり、HTML5やフロントエンドの技術をふんだんに盛り込み、皆さんご存知の賑やかな楽天市場とはひと味違ったクールなサイトに仕上げました。ご覧頂けましたでしょうか？

当日のセッションの内容と重複しますが、今回は、HTML5の活用事例として、このサイトがどのような技術で作られたのか、セッションでも使用したスライドを交えて紹介していきます。

「Rakuten Technology Conference 2013」サイトのコンセプトと要求仕様

このサイトでは、よくあるカンファレンスのサイトと同じく、講演者の紹介やタイムテーブルなどを公開しています。メインのターゲットユーザーはエンジニアで、日頃はPCをよく使い、最新のスマートフォンを持ち歩いていると想定しました。また、情報だけでなく技術面でもアピールする機会にしたかったこともあり、過剰なほどにあらゆる技術を盛り込んでいます。

サイトを構築する上で、いくつか要求仕様がありました。

• 情報の更新が頻繁に行われる
• SEOを考慮する
• サーバサイドスクリプトは使用しない

これらを満たすために、

• 都度、複数のHTMLを編集するのではなく、スタッフから受け取ったデータ（JSON）からHTMLを生成する。
• サーバサイドスクリプトが使えないので、ローカルで生成する。

という方針を定め、様々な技術を使って実現しました。

活用した技術

コンテンツ自体にもHTML5をはじめとした最新技術が使われていますが、制作面においても、最新のツールを駆使して効率化を図りました。

Canvasを使ったインタラクティブな背景

サイト全体にタイルをモチーフとした背景を採用していて、PCでご覧頂くと、マウスの動きに合わせてハイライトとされ、タイルが微妙に移動していることがわかるかと思います。この背景部分は、Canvas で描画しています。PC向けにはタイルは固定幅ですが、タブレット向けでは画面幅に合わせてタイル幅を調整しています。また、Canvasの処理部分にはCreateJSを使用しています。

CSSによるスムーズなインタラクション

トップページの「M」のタイルをクリックすると、実行委員長からのメッセージが表示されます。このとき、委員長の顔のタイルが拡張して、それに合わせて他のタイルが追いやられるようなアニメーションを行っています。この動きはCSSによって実現されていて、スマートフォンでも同様に動きます。これ以外にも、様々な場面でCSSによるアニメーションを使用しています。

スマートフォン最適化とレスポンシブWebデザイン

当日会場でスマートフォンからタイムテーブルを確認することを考慮し、スマートフォン対応をしました。タイムテーブルは縦横に長いコンテンツのため、スマートフォンとの相性は悪いのですが、時間帯ごとに横スクロールするようにして、閲覧性を確保しました。

各デバイスへの対応は、レスポンシブWebデザインで行いました。PCとスマートフォンでレイアウトが大きく異なるので、かなり苦戦しました。

また、それぞれの表示ごとにJavaScriptの処理も異なっているため、ウィンドウ幅を監視して、表示の切り替わり時にそれぞれ適切な処理を実行するような仕組みも取り入れました。

お気に入りのセッションをブックマークできるWeb Storage

タイムテーブルで、お気に入りのセッションをブックマークできる機能を追加しました。ブックマークするとブラウザのlocalStorageに保存され、いつでもお気に入りのセッションだけを表示できます。

また、ページ上部のSpeakersやUpdatesの部分に、赤枠の数字が表示されますが、これは、前回閲覧したときのデータをlocalStorageに保持し、今回読み込んだデータ数の差を表示して、何件更新されたかを示しています（表示すると消えます）。

PCで登録したブックマークをカンファレンス当日にスマートフォンで呼び出せるように、URLでその情報を引き継げるようにはしていたのですが、UIを提供できませんでした。来年はその辺りも提供できればと思っています。

PhantomJS + UnderscoreJSで更新負荷を下げる

PhantomJSは、コマンドラインから呼び出せるWebKitエンジンで、今回は、テンプレートとデータからHTMLを生成する処理で利用しました。テンプレートエンジンはUnderscore.jsを利用しました。

講演者の情報やセッションの時間などの情報は開催日まで頻繁に更新があり、その度にHTMLを修正しているとかなりの手間となります。そのため、それらの情報をまとめるカンファレンススタッフに、データをJSON形式で記述して納品してもらうようにしました。納品されたJSONファイルをUnderscore.jsでテンプレートに適用して、HTMLを出力しました。

データは構造化されているため、例えばタイムテーブルのデータを更新すると、タイムテーブルだけではなく、その講演者のページの情報も同時に変更されます。また、セッションの場所の名称が変更されたときも、１箇所修正するだけで、すべての名称が新しいものに置き換わります。

レスポンシブ対応がシンプルに記述できるSass / Compass

CSSの生成には、おなじみSassとCompassを使用しました。Sass内でif文を使って各デバイスの判定ができるようにして、レスポンシブ対応がシンプルに記述できました。

Gruntによる処理の自動化

PhantomJSでのHTMLの生成、Sass/Compassのコンパイル、ファイル操作などはGruntを使い自動化しました。PhantomJSの呼び出し部分は、いいモジュールを見つけられなかったため、シェルコマンドを呼び出すタスクを書きました。

このように、目的に合わせた最新技術に挑戦して、今回の「Rakuten Technology Conference 2013」のサイトを作り上げていて、私たちも様々な収穫がありました。まだ、パフォーマンスやユーザビリティなどで不十分な点もあるので、今後の課題として取り組みたいと思っています。

また、「サーバでスクリプト使えなくても、ローカルでRubyやPHPとか使えば楽じゃね？」という話もありますが（汗）、そこは我々「HTML5 Project Team」ということで、今回はフロントエンドの技術だけにこだわってみました。来年は、NodeベースのWebサーバに移行して、より簡単にサイトを更新できるようなことも考えています。

今後もこのような挑戦を続け、そこで得ていく知見を楽天のサービスに活かして行きたいと思っています。またこのような形で、いつもお世話になっているコミュニティにも還元できれば幸いです。今後ともよろしくお願いします。

このセッションのビデオはYouTubeにアップされており、使ったスライドもSlideShareで公開されています。もしよろしければそちらもご覧ください。