![JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）P.3 P.4
Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり
Spring Data RESTは、それを使えばも
のの5分でRESTful APIが作れる、それく
らい手軽なプロジェクトです。Entityと
Repositoryを定義すると、それだけで
Endpointが設定されます。自前でロジッ
クを書く必要は皆無。POST/GET/PUT/
PATCH/DELETE全て自動設定。その上、
統一されたRequest/Responseフォーマ
ット（HATEOAS）で処理されます。
これは便利そう。しかし、実際のプロ
ジェクトでは使えるのか？やってみなけ
ればわかりません。ということで、当社
で試してみました。
当時開発していたアプリケーションの
アーキテクチャは三層構造となっており、
UI、BL、DAに分離していました。デー
タ変更時の影響を局所化するため、ひと
つのデータにつきひとつのアプリケーシ
ョンのみアクセス可能とします。アーキ
テクチャの特徴としては、APIをたくさん
作ること。DAは基本的にシンプルな
CRUDのみとし、BLから同じように使え
る構造を目指しました。つまり、BLが複
数のDAにアクセスする構造です。DAが
シンプルなCRUDのみの提供なので、
Spring Data RESTが向いていると考え、
ここに適用しました。
しかし、導入当初から違和感が発生。
まずはURIです。楽天市場のようなサー
ビスのイメージで解説します。
Spring Data RESTで作ると、イメージ
AのようなURIとなります。これは想定と
違う、と気付きました。描いていたのは、
イメージBのような階層構造です（上が
いなければ下が存在しないので）。
ただ、まあこれでもやりたいCRUDは
できる、とそのまま開発を続けました。
すると、おかしいことが追加で2つ出てき
ました。例えばあるItemのPricesをまと
めて更新するなど、リソース横断のデー
タ更新をしたくなったとき。設定された
Endpointはひとつずつしか操作できない。
じゃあ個別に更新するか？その場合エラ
ー時どうする？ロールバックには、呼び
元でトランザクション管理が必要となる。
もう1つの問題は、BLのモデルとDBの
モデルが一致しないこと。Spring Data
RESTが生成するEndpointのIFはDBのデ
ータ構造のままなので、性能改善のため
にDB設計を変えると、玉突きでBLの作
りも変更が必要になります。
ここまできて、一度立ち止まって考え
てみました。シンプルなCRUD以外の要
件も出てきたし、BLとDAを分離させた
かったのに、密結合になってしまった。
ということで、BL、DAはもうできてい
たのですが、Spring Data RESTをやめる
決断をしました（！）。
我々のアプリにはその制約の強さが合
いませんでしたが、コンセプトが合致す
るアプリであれば、活用できるでしょう。
マイクロサービスはなぜ必要なのか？
本当に必要なのか？そして、どうしたら
うまくいくのか？失敗するのはなぜか？
今日は、そういったことを、自分なりの
経験と知識で咀嚼してお話します。
まず、マイクロサービスってなんでし
ょう？各サービスは、固有の責務をもっ
た機能をコンポーネント（部品化）した
ものですね。その規模が小さい＝マイク
ロ。そして、データが統合されず、サー
ビスごとにデータを持つのが特徴です。
マイクロサービスアーキテクチャとは
何か。マイクロサービスは単独で存在す
るのではなく、 メッセージによるコラボ
を行いつつ、全体でひとつの仕事をする、
自律分散協調のアーキテクチャです。
これを聞いて、何か思い浮かびません
か？実はこれ、20年くらい前に作ったオ
ブジェクト指向入門のスライドの流用。
「オブジェクト」を「マイクロサービ
ス」に変えただけなんです。つまり、特
に目新しい考え方ではないんですよね。
製品やソフトのバージョンUPの間隔が短
くなっているので、 段階的仕様追加に柔
軟に対応でき、仕様変更に強い構造にす
べき。これも当時のスライドからそのま
ま流用したものです。顧客と開発者、開
発者、開発チーム同士のチームワーク 。
これもそう（ただこの点でひとつ違うの
は、一個のマイクロサービスで一個の開
発チーム体制をとるべきとされているこ
と。アプリ開発者のみでなく、インフラ
担当者やデータベース管理者も同じチー
ムメンバーに入れるものとされる）。
おおよそ同じということはつまり、オ
ブジェクト指向でうまくいかなかった開
発がマイクロサービスでうまくいく、な
APACHE CAMEL + HAWTIO + SPRING BOOT による
モダンなインテグレーションマイクロサービス
マイクロサービスの利点ってなんでし
ょう？「小さい」「カスタマイズしやす
い」「テストが容易」などですね。過去
に喧伝されてあまり浸透しなかった類似
アーキテクチャに「SOA」というものが
ありますが、マイクロサービスはこれと
どう違うのでしょうか。
SOAは、各システムの間に挟む「ES
B」と呼ばれるシステム連携基盤を作る
という思想です。各アプリケーションは
ESBにつなげば、あとはよろしくやって
もらえるという。ESBの中にスマートさ
があるわけです。マイクロサービスはそ
うではありません。各サービスが個々に
持っているつなぎの部分にスマートさ、
つまり連携ロジックを持たせます。ESB
のようなハブではなく、それぞれがそれ
ぞれを直接呼び出してやりとりしようと
いう考え方。
30代後半の人たちは、結構このマイク
ロサービスってばかばかしいという考え
方をお持ちの方も多いようです。そもそ
も、このESBは当時の「バズワード」で
した。なぜかというと、マイクロサービ
スのように個々が好き勝手にやりとりし
合ってしまうと、どこがどうつながって
いるかわからなくなってメンテナンスで
きなくなってしまうよねと（インテグレ
ーション・スパゲティと呼ばれる状態）。
だから、ハブとなるESBを導入しましょ
うという考え方だったんです。
そんな中、なぜマイクロサービスはヒ
ットしているのでしょうか。理由は「コ
ンウェイの法則」（注：メルヴィン・コ
ンウェイの提唱する「システムを設計す
る組織は、その構造をそっくりまねた構
造の設計を生み出してしまう」という法
則）にあると思います。管理するサービ
スが小さくなれば、チームも小さくなる。
５人とかそういう規模で作成からリリー
スまでをできるようになるということ。
仮にインテグレーション・スパゲティに
なったとしても、個々のチーム単位では
管理しやすくなるところに価値を見出さ
れているのでしょう。
ここでApache CamelというJavaのイン
テグレーションフレームワークについて
紹介します。4.8メガ程度という軽量さに
加え、流れるようなインターフェースで
きれいにルーティングできるというのが
特長です。また、書きやすさだけでなく、
280超の接続コンポーネントが用意されて
おり、大抵の外部サービスに標準でつな
げることもできます。
Apache Camelができること、具体的
に説明しましょう。HTTP/RESTで受け
取ったリクエストをTwitterにツイートし
たり、Apache ActiveMQから受け取った
JMSメッセージを、データ内容に応じて
「MongoDBに登録する」または「Twilio
を使ってスマホにSMSで通知する」、と
いったことができます。また、「Enterpr
ise Integration Patterns」というシステ
ム間連携のベストプラクティスをまとめ
たバイブルとも言える書籍があり、そこ
には６５のデザインパターンが掲載され
ているのですが、Apache Camelはそれら
を完全にサポートしています。
Apache Camelを使い始めるには、
Camel IN ACTION2という書籍が12月に
出版となりますので、ぜひご一読を。英
語版のみですが、苦手な方はJapan Cam
el User Group（JCUG）にて読書会も開
催しますので、ぜひそちらにもご参加く
ださい。
Spring Boot の本当の理解ポイント
Spring Bootを理解するためには、まず
Springを理解しましょう。では、Spring
とは何か。様々なプロジェクトの集合体
であり、ベースとなっているのはSpring
Frameworkです（下図参照）。そのSpri
ng Frameworkに入っているものは、DI,
AOP,JDBC,TX,MVCなどたくさんありま
すが、特にDIが根幹であることは覚えて
おきましょう。最新バージョンは5.0であ
り、今年9月にリリースされました。
Spring Frame
workには使いに
くい点がひとつあ
ります。それは
CoC（注：Conve
ntion over Config
uration、「設定よ
り規約」）でない
ということ。「あ
らかじめ規約を決めておくことで、設定
させることを極力減らす」という考え方
ですが、それが適用されていない。つま
り、大量の設定記述が必要であり、その
まま使おうとすると本来したかった開発
がなかなか始められないという問題です。
Spring Boot は、Spring Frameworkに
CoCを導入したものです。あらかじめお
すすめの設定が記述済にしてある、いわ
ば設定のかたまり。これによって、開発
者はすぐに開発を始めることができます。
Spring Bootとは何か、はっきりいってこ
れだけです。
では、設定とは何か。それは「Bean定
義」です。Spring Frameworkには「コン
テナ」（DIコンテナ）と呼ばれる、イン
スタンスを管理する入れ物があります。
Beanとはそのコンテナで管理されている
インスタンスを指します。「Beanを定義
する」とは、「このクラスのインスタン
スをBeanとしてね」とコンテナに教える
こと。では、その定義の方法は？
XMLによる定義、クラスによる定
義（@Componentの付加）、メソッドに
よる定義（@Beanの付加）の3種。この
いずれかを行うだけで、簡単にBean定義
を行うことができます。
定義されるBeanには、「FWを動かす
ためのBean」と、「アプリケーションを
構成するBean」の２種類があります。
Spring Bootはその前者のBeanをあらか
じめ用意してくれているため、セットア
ップが最小限でできるということなので
すが、後者のBeanにはノータッチです。
Spring Bootは設定のかたまりであり、
Spring Frameworkがもともとできること
を簡単にしただけ。今日これだけは覚え
て帰ってください。
https://tadayosi.github.io/jjug2017-camel_hawtio_springboot/reveal.js/index.html#/
https://www.slideshare.net/masatoshitada7/spring-boot-jjug
JavaがメインテーマのJJUG、Spring FrameworkがメインテーマのJSUG。といっても、他方の領域
にまたがったセッションもありますし、区別はさほどありません。また、両カンファレンスともに、
用意された講演は硬軟様々で、初心者から上級者まで誰が来ても満足できる懐の広さは同じです。
懇親会の食べ物はどちらも豪華でおいしいし、お祭りとしての熱さも甲乙つけがたい。そもそも
Spring Festで講演された谷本さんはJJUGの方ですし、勝ち負けなんて話ではないでしょう（！）。
どちらのイベントも多くの学びがあり、大変楽しいです。参加するだけで、必ず技術者として一歩
前進できます。これを読んでくださった皆様も、ぜひ、次回は両方参加してみてください。
イメージA）
「Item」のCRUD
「/Items[POST/GET] 」、「/Items/{id}[GET/PUT/PATCH/DELETE] 」
「各ItemのPrice」のCRUD
「/Prices[POST/GET] 」、「/Prices/{id}[GET/PUT/PATCH/DELETE] 」
イメージB）
「各ItemのPrice」のCRUD「Items/{id}/Prices」
んてありえないということです。大体、
モノリスとマイクロサービス、どちらが
簡単でしょう？ドメイン分析をしたり、
機能境界を考えるより、これまで通りモ
ノリスを作る方がそれは楽ですよね。
今はまだ、技術論は存在しても、開発
の方法論は抜けているんです。「サービ
スとして分割するためにドメイン駆動開
発のシステム境界の考えは役に立つ」な
んて言って、場面だけ切り取られてもな
かなか活用できるものではありません。
「マイクロサービスはアジャイルで開発
するんです」って言うのは簡単だけど、
じゃあ具体的にどうやるのか？そもそも
動くものをアジャイルでまず作って、と
いうスタイルは、エンタープライズ系の
マイグレーションには向かないでしょう。
今はまだ、どうやって開発するのか？ど
うすればうまくいくのか？が確立されて
いないので、経験のある人たちが試行錯
誤しているのが現状なのです。
それでもマイクロサービスを適用した
い。その動機はなんでしょうか。大きく
分けて2つあるでしょう。1つはモノリス
が持つ問題。コード肥大化で全貌の把握
が困難、細部の修正でも大量のリグレッ
ションテストが発生、デプロイも大変、
ということで導入を検討するケース。も
う1つは、時代的な背景。ビジネスの変化
に対応しやすいというところでしょう。
その動機をもとにマイクロサービスを
導入するにあたり、まず理解しておきた
いこと。それは、複雑なシステムは簡単
にはならないということ。ハローワール
ドを出すのに100ステップのコードがある
というなら、それは複雑なんじゃなくて
作りを間違っているだけですし、そうい
うことではなくアプリが複雑なら、それ
は業務のプロセスの問題でしょう。ひと
つひとつのサービスをシンプルにしたと
ころで、全体のつながりはやはり複雑に
なるものです。これが大前提。
次に成功の鍵を考えてみます。成功の
鍵その1としては、レガシーシステムが複
雑すぎることを認め、マイクロサービス
化をあきらめること。古いIBM社のシス
テムを使っていたとしても、ハードを新
しくすれば動きますし、下手にJavaと
RDBで刷新するより速いことも多いです。
それでも導入したい場合。成功の鍵そ
の2としては、事前にしっかり準備するこ
と。まずは、データモデルの整理。ここ
がぐちゃぐちゃだと、そもそもマイクロ
サービス化しようとしても手がつけられ
ません。複雑なSQLを使わずとも扱える
ようにすることです。
そして次のポイントは、一度にマイク
ロサービス化しないこと。変更が多い部
分から少しずつ抜き出して開発すべき。
あとは、数を増やしすぎないこと。数
百のサービスを作るような事例が書籍に
載っていますが、その数のチーム管理は
厳しいでしょう。個人的にはマイクロよ
り「ミニ」ぐらいがよいと思っています。
また、完全にSoRの分野だと、成功し
にくいでしょうね。SoEに行き過ぎても微
妙。SoRとSoEの間くらいのところが適し
ているのではないでしょうか。各所で事
例を聞いても大体そのような印象です。
ということで、色々な意味でまだまだ
課題が多いマイクロサービス。でも、オ
ブジェクト指向やドメイン駆動開発も古
くから続いていますし、この技術もエン
ジニアとして学ぶ価値はあると思います。
日本一やさしく説明する予定のマイクロサービス入門
JJUG #3 JSUG #3
高橋 勲（@ricto_H20DIT） 楽天株式会社
JJUG #4 JSUG #4
長谷川 裕一（@hasedanna） Starlight&Storm / 日本Springユーザ会多田 真敏（@suke_masa） 株式会社カサレアル
佐藤 匡剛（@tadayosi） レッドハット株式会社
https://www.slideshare.net/rakutentech/spring-data-restapi
https://www.slideshare.net/HasegawaDanna1/spring-fest-2017
総評 - JJUG vs JSUG、結局どちらの勝利？](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a JJUG vs JSUG - 2大Javaコミュニティ 開催カンファレンスレポート
Similar a JJUG vs JSUG - 2大Javaコミュニティ 開催カンファレンスレポート (17)
Último
Último (9)
JJUG vs JSUG - 2大Javaコミュニティ 開催カンファレンスレポート
- 1. JSUG開催「Spring Fest 2017」 企業の導入実績も多い人気FW、Spring Framework のコミュニティ、JSUG（Japan Spring Framework User Group）の年次開催イベント。今年の開催は 11/24（金）と、平日の方が都合がつくという方に は参加しやすい日程。テーマを区切っているので、 Spring Frame work に特化した 具体的な事例や 活用情報が聞け、 Springユーザー には実務に直結 する話題が多い のもうれしいポ イントでしょう。 JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）P.1 P.2 ２大Javaコミュニティ 開催カンファレンス比較 日本最大級のJavaコミュニティである「JJUG」と、最も有名なJava FrameworkであるSpring Fra meworkのコミュニティ「JSUG」。その2つのコミュニティが、この11月にそれぞれ大規模カンフ ァレンスを開催しました。この記事では、双方のセッションレポートを左右に対比する形で掲載す ることで、同時に読み比べができる形式としています。ぜひ、読むことでそれぞれを追体験してい ただきながら、両イベントの比較をしてみてください。（SOMPOシステムズ株式会社 西野大介） VS JJUG開催「JJUG CCC 2017 Fall」 半年に一度開催しているJJUG（Japan Java User Grouop）のカンファレンス。今年は11/18（土） に開催（基本的に土曜開催）。前回実績で1000人 超が参加したとされる巨大なJavaのお祭り。特定 FWに限定されない全般的なJava技術情報が集まる。 「書ける」から「できる」になれる！ - Javaメモリ節約ノウハウ話 ドメイン駆動設計のためのSpringの上手な使い方 今回のテーマは速度向上ですが、アル ゴリズムなどよりももっと低レイヤーで の工夫の仕方です。 メモリ不足は安定したサービス運用の 大敵です。メモリの使用量を誤るOutOf Memoryエラーが出たり、そこまでいか なくてもスループットは落ちていきます。 まず、Javaの基本データ型はその大き さにより1～8バイトであることはご存知 だと思います。オブジェクト型の場合、 どのオブジェクトも、メモリブロックの 先頭に必ず管理用のデータ領域を持って います。二種類あり、ひとつはオブジェ クトの状態を管理するもの（_mark）、 もうひとつはクラスデータへの参照情報 （_klass）。32bit VMの場合4バイト、 64bit VMの場合8バイト（*1）、それぞ れで消費します。 *1 _klassでは、64bit VMでもCompress edOops（オブジェクト参照を圧縮する仕 組み）が有効な場合は4バイトとなる 具体例で説明しましょう。用語を管理 する辞書クラスを作り、そこにString配 列を持っているとしましょう。String配 列はStringにアクセスし、Stringは実態の 構造であるchar配列にアクセスするとい うネスト構造になります。これ、ひとつ ひとつに間接的な情報のメモリ管理が発 生するので、想定している以上にメモリ を消費してしまいます。 じゃあ、どうやったらメモリ使用量を 削減できるでしょうか。ひとつは、メモ リ消費の大きい参照型の使用をやめ、基 本データ型の配列にすべて押し込むこと です。String配列ではなくchar型の配列 に全ての単語情報を登録し、各単語の区 切り位置などはint型の配列として別で持 つことで 判別できるようにします。これ により、テストコード上はメモリ使用量 が1/3になりました。ですが...当然、ソー スの可読性とメンテナンス性は犠牲にな ります。バグ混入や、実装工数の肥大化 も懸念されるでしょう。 じゃあどうするか？推奨したいのは、 一般に公開されている省メモリコレクシ ョンライブラリの活用です。fastutilや Eclipse Collections、kolobokeなど、実 績のあるライブラリが多数公開されてい ます。自力で難しい工夫をするより、懸 念や課題は少ないでしょう。 最後に、メモリ節約には限界があると いうことにも触れておきます。いくらが んばってもメモリに乗らないものは乗り ません。何をどれくらいメモリに乗せる かや、スコープ・ライフサイクルの意識 が大事ですし、そのためにもメモリ使用 量の見積もり・計測のノウハウは持って おくべきです。その上で、乗らないもの はあきらめて一時ファイルやDBを使う割 り切りも時に必要。結局は適材適所です。 DDD（ドメイン駆動設計）は、価値の あるシステムを構築する方法ですが、唯 一の手段ではありません。成長し価値を 加え続けるソフトウェアであれば有用で す。その逆では効果が低いでしょう。 DDDの基本は4点。１）当たり前です が、開発者がドメインを学ぶということ。 なぜそれが基本か。モデルと実装を一致 させることが大事なのです。開発者自ら がドメインの知識を広げる、つまり、業 務の用語や言い回しを覚える。スタート は表面的な言葉の理解からですが、しだ いに深い洞察へと進む。その際、継続的 に学習することが重要で、理解し終えた と思いこまないことが肝要です。 そして、学んだことを必ずコードで表 現すること。ドメインの知識をExcelに書 いていては、技術者として不適切です。 知識の増加がコードにあらわれる。値や コレクション、区分といったオブジェク トで表現する必要があります。 ２）モデルと実装を一致させること。 モデルとは、選び抜かれた重要な側面、 本質的な知識です。対して実装は、重要 ではないが省略できない細部の記述から なる大量・網羅的な記述であり、選び抜 かれたとは言えない肥大化・重複したコ ードとの戦いであります。 つまり、モデルと実装は相反した要素 なんですね。実装を考えなければきれい なモデルはいくらでも作れます。でも、 それは何の役にも立ちません。実装する と無駄に複雑化してしまうのであれば、 そのモデルは捨てるか改善しなければな りません。いいモデルとは、実装と関連 付けさせることで実装を整理させること ができるものです。最初から適合しない ので、試行錯誤の繰り返しが必要です。 ３）深いモデルの探求。基本データ型 からクラス定義に変えたら楽になった。 というような探求を続けることです。私 が手ごたえを感じている例は、BeanVali dationをどんどん活用すること。例えば 有効期限などのようなチェックをロジッ クではなく宣言的に定義することで、正 しい状態が何か説明しやすくなりました。 ４）巨大な複雑さに立ち向かう。DDD に銀の弾丸はなく、地道な積み重ねが必 要。多くの時間とエネルギーを消費しま す。そして、巨大で複雑になると大体パ ワーポイントなどの資料が出てくるので すが、じゃあこの単純化された絵はコー ドとしてどう落ちるのか？が常に重要。 それができる人材がいないなら、絵に描 いた餅でしかありません。とにかく、ド メインについて学んだ開発者は、初日か らそれをコードで表現してみることです。 Spring Bootのように、動くアプリ作成が 導入後すぐにできるツールを活用し、効 果的にDDDに取り組んでください。 ついにきたリアルタイムSpark ビッグデータ処理の新定番「SnappyData」とは Spring BootとSpring Cloudで始めるマイクロサービス 皆さんはビッグデータの処理基盤に満 足していますか？複数プロダクトの組み 合わせが必要で複雑、データ連携にも時 間がかかる。キャッシュすると速いけど、 インタラクティブな分析はパフォーマン スが悪いし...と色々課題があります。 そして従来処理との組み合わせ。業務 はRDBでデータ管理し、分析はTERADA TAなどのDWH。一方でビッグデータは mongoDBなどNoSQLを使用し、分析に hadoopなどを使用。これらを組み合わせ てシステムを成り立たせているので、ツ ギハギです。Sparkが出てきてからかなり シンプルになったものの、まだMEMSQL などとの組み合わせが必要でした。 SnappyData、これを使えばもっとシン プルになります。SnappyDataは、データ ベース機能を備えたSpark。別の製品と組 み合わせないとデータ保持できないとい うSparkの課題を補完したものです。Spa rkとインメモリDB（GemFireXD）を統合 し、独自機能を付加しています。 特長は、Sparkをさらに高速化できると いうこと。4つのキーワードで説明します。 １）インメモリDB。従来のSpark+何ら かのデータストアを使う方式と異なり、 データ保存にディスクを使わずメモリで 完結しているため、速い。２）データ形 式。Sparkと同一のデータ形式で保存して おり、取得・保存時にシリアライズや型 変換が発生しないため、速い。３）クラ スタ統合。SparkとインメモリDBのクラ スタを統合でき（別も可）、データの移 動・コピーなしでデータ処理できるため、 速い。４）SQL高速化。SparkSQLの一部 の内容を変更して高速化するため、速い。 これらの特長は、例えばクレジットカ ードの不正使用をリアルタイム検知する ようなシステムの実現に効果的でしょう。 ストリームデータ、トランザクション、 アナリティクスを全てSnappyDataで処理 できます。 高速化のための工夫がたくさんなされ、 統一されたシンプルな構成を持つSnappy Data。ぜひ試してみてください。 マイクロサービスにすると、モノリス に比べて「Agility（機敏さ）」が向上す るといいます。なぜか。例えて言うなら、 モノリスは「絵を描く」ことに近く、対 してマイクロサービスは「ジオラマを作 る」ようなもの。ジオラマって、プラモ デルを自由に配置して、好きな場所に動 かしたり、回り込んで違う角度から撮影 することが簡単にできますよね。絵で同 じことをやろうとすると、位置を少し動 かすだけでも消してから描き直すという 作業が必要になります。Agilityの向上と いうのはこういうことです。 では、なぜこういった考えが必要にな ってきたのか。アメリカを中心に行われ る手法ですが、ビジネスを始める際にま ず仮説を立てます。ここに広告を出せば これだけ収入が増えるのではないかとか。 それを検証するために、システムの修正 をできるだけ早く済ませたい。アプリの 開発速度が上がるほど、多くの仮説を試 せるようになります。それに応えられる のがマイクロサービス、ということです。 マイクロサービスにまず取り組んでみ るなら、Spring Frameworkは適していま す。すぐに早く始めるには、Spring Boot を使いましょう（注：JJUG #4参照）。 Springにはマイクロサービスに適した機 能が豊富です。例えば、@RestController （クラスに付加するとパブリックメソッ ドの戻り値が全てJSONで返るようにな る）のようなアノテーションも揃ってい ますし、Spring Cloudのようにクラウド ネイティブなアプリを作るツールの集合 体もあります。Spring Cloud Eurekaを使 って各サービスの物理的な配置場所を Eurekaに管理させることにより抽象化さ せれば、スケーリングが容易になります。 また、一部のサービスが落ちても稼働を 継続させるには非同期化が基本となり、 そのためにはメッセージをenqueueしな ければなりませんが、Spring AMQPを使 うと簡単に実装できます。こういった技 術を少しずつ取り入れてみて、技術者と してステップアップしていってください。 https://www.slideshare.net/JSUXDesign/java-82338809 https://www.slideshare.net/MasakiYamakawa/20171118-jjug-snappydata/1 https://www.slideshare.net/masuda220/spring-82650951 増田 亨(@masuda220) 有限会社システム設計 / ギルドワークス株式会社 JJUG #1 JSUG #1 JJUG #2 猪鼻哲也 株式会社ジャストシステム 山河 征紀 ウルシステムズ株式会社 JSUG #2 谷本 心（@cero_t） Acroquest Technology株式会社 / 日本Javaユーザーグループ
- 2. JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社） JJUG vs JSUG 2大Javaコミュニティ 開催カンファレンス比較 | 取材・構成・文：西野大介（SOMPOシステムズ株式会社）P.3 P.4 Spring Data RESTを利用したAPIの設計と、作り直しまでの道のり Spring Data RESTは、それを使えばも のの5分でRESTful APIが作れる、それく らい手軽なプロジェクトです。Entityと Repositoryを定義すると、それだけで Endpointが設定されます。自前でロジッ クを書く必要は皆無。POST/GET/PUT/ PATCH/DELETE全て自動設定。その上、 統一されたRequest/Responseフォーマ ット（HATEOAS）で処理されます。 これは便利そう。しかし、実際のプロ ジェクトでは使えるのか？やってみなけ ればわかりません。ということで、当社 で試してみました。 当時開発していたアプリケーションの アーキテクチャは三層構造となっており、 UI、BL、DAに分離していました。デー タ変更時の影響を局所化するため、ひと つのデータにつきひとつのアプリケーシ ョンのみアクセス可能とします。アーキ テクチャの特徴としては、APIをたくさん 作ること。DAは基本的にシンプルな CRUDのみとし、BLから同じように使え る構造を目指しました。つまり、BLが複 数のDAにアクセスする構造です。DAが シンプルなCRUDのみの提供なので、 Spring Data RESTが向いていると考え、 ここに適用しました。 しかし、導入当初から違和感が発生。 まずはURIです。楽天市場のようなサー ビスのイメージで解説します。 Spring Data RESTで作ると、イメージ AのようなURIとなります。これは想定と 違う、と気付きました。描いていたのは、 イメージBのような階層構造です（上が いなければ下が存在しないので）。 ただ、まあこれでもやりたいCRUDは できる、とそのまま開発を続けました。 すると、おかしいことが追加で2つ出てき ました。例えばあるItemのPricesをまと めて更新するなど、リソース横断のデー タ更新をしたくなったとき。設定された Endpointはひとつずつしか操作できない。 じゃあ個別に更新するか？その場合エラ ー時どうする？ロールバックには、呼び 元でトランザクション管理が必要となる。 もう1つの問題は、BLのモデルとDBの モデルが一致しないこと。Spring Data RESTが生成するEndpointのIFはDBのデ ータ構造のままなので、性能改善のため にDB設計を変えると、玉突きでBLの作 りも変更が必要になります。 ここまできて、一度立ち止まって考え てみました。シンプルなCRUD以外の要 件も出てきたし、BLとDAを分離させた かったのに、密結合になってしまった。 ということで、BL、DAはもうできてい たのですが、Spring Data RESTをやめる 決断をしました（！）。 我々のアプリにはその制約の強さが合 いませんでしたが、コンセプトが合致す るアプリであれば、活用できるでしょう。 マイクロサービスはなぜ必要なのか？ 本当に必要なのか？そして、どうしたら うまくいくのか？失敗するのはなぜか？ 今日は、そういったことを、自分なりの 経験と知識で咀嚼してお話します。 まず、マイクロサービスってなんでし ょう？各サービスは、固有の責務をもっ た機能をコンポーネント（部品化）した ものですね。その規模が小さい＝マイク ロ。そして、データが統合されず、サー ビスごとにデータを持つのが特徴です。 マイクロサービスアーキテクチャとは 何か。マイクロサービスは単独で存在す るのではなく、 メッセージによるコラボ を行いつつ、全体でひとつの仕事をする、 自律分散協調のアーキテクチャです。 これを聞いて、何か思い浮かびません か？実はこれ、20年くらい前に作ったオ ブジェクト指向入門のスライドの流用。 「オブジェクト」を「マイクロサービ ス」に変えただけなんです。つまり、特 に目新しい考え方ではないんですよね。 製品やソフトのバージョンUPの間隔が短 くなっているので、 段階的仕様追加に柔 軟に対応でき、仕様変更に強い構造にす べき。これも当時のスライドからそのま ま流用したものです。顧客と開発者、開 発者、開発チーム同士のチームワーク 。 これもそう（ただこの点でひとつ違うの は、一個のマイクロサービスで一個の開 発チーム体制をとるべきとされているこ と。アプリ開発者のみでなく、インフラ 担当者やデータベース管理者も同じチー ムメンバーに入れるものとされる）。 おおよそ同じということはつまり、オ ブジェクト指向でうまくいかなかった開 発がマイクロサービスでうまくいく、な APACHE CAMEL + HAWTIO + SPRING BOOT による モダンなインテグレーションマイクロサービス マイクロサービスの利点ってなんでし ょう？「小さい」「カスタマイズしやす い」「テストが容易」などですね。過去 に喧伝されてあまり浸透しなかった類似 アーキテクチャに「SOA」というものが ありますが、マイクロサービスはこれと どう違うのでしょうか。 SOAは、各システムの間に挟む「ES B」と呼ばれるシステム連携基盤を作る という思想です。各アプリケーションは ESBにつなげば、あとはよろしくやって もらえるという。ESBの中にスマートさ があるわけです。マイクロサービスはそ うではありません。各サービスが個々に 持っているつなぎの部分にスマートさ、 つまり連携ロジックを持たせます。ESB のようなハブではなく、それぞれがそれ ぞれを直接呼び出してやりとりしようと いう考え方。 30代後半の人たちは、結構このマイク ロサービスってばかばかしいという考え 方をお持ちの方も多いようです。そもそ も、このESBは当時の「バズワード」で した。なぜかというと、マイクロサービ スのように個々が好き勝手にやりとりし 合ってしまうと、どこがどうつながって いるかわからなくなってメンテナンスで きなくなってしまうよねと（インテグレ ーション・スパゲティと呼ばれる状態）。 だから、ハブとなるESBを導入しましょ うという考え方だったんです。 そんな中、なぜマイクロサービスはヒ ットしているのでしょうか。理由は「コ ンウェイの法則」（注：メルヴィン・コ ンウェイの提唱する「システムを設計す る組織は、その構造をそっくりまねた構 造の設計を生み出してしまう」という法 則）にあると思います。管理するサービ スが小さくなれば、チームも小さくなる。 ５人とかそういう規模で作成からリリー スまでをできるようになるということ。 仮にインテグレーション・スパゲティに なったとしても、個々のチーム単位では 管理しやすくなるところに価値を見出さ れているのでしょう。 ここでApache CamelというJavaのイン テグレーションフレームワークについて 紹介します。4.8メガ程度という軽量さに 加え、流れるようなインターフェースで きれいにルーティングできるというのが 特長です。また、書きやすさだけでなく、 280超の接続コンポーネントが用意されて おり、大抵の外部サービスに標準でつな げることもできます。 Apache Camelができること、具体的 に説明しましょう。HTTP/RESTで受け 取ったリクエストをTwitterにツイートし たり、Apache ActiveMQから受け取った JMSメッセージを、データ内容に応じて 「MongoDBに登録する」または「Twilio を使ってスマホにSMSで通知する」、と いったことができます。また、「Enterpr ise Integration Patterns」というシステ ム間連携のベストプラクティスをまとめ たバイブルとも言える書籍があり、そこ には６５のデザインパターンが掲載され ているのですが、Apache Camelはそれら を完全にサポートしています。 Apache Camelを使い始めるには、 Camel IN ACTION2という書籍が12月に 出版となりますので、ぜひご一読を。英 語版のみですが、苦手な方はJapan Cam el User Group（JCUG）にて読書会も開 催しますので、ぜひそちらにもご参加く ださい。 Spring Boot の本当の理解ポイント Spring Bootを理解するためには、まず Springを理解しましょう。では、Spring とは何か。様々なプロジェクトの集合体 であり、ベースとなっているのはSpring Frameworkです（下図参照）。そのSpri ng Frameworkに入っているものは、DI, AOP,JDBC,TX,MVCなどたくさんありま すが、特にDIが根幹であることは覚えて おきましょう。最新バージョンは5.0であ り、今年9月にリリースされました。 Spring Frame workには使いに くい点がひとつあ ります。それは CoC（注：Conve ntion over Config uration、「設定よ り規約」）でない ということ。「あ らかじめ規約を決めておくことで、設定 させることを極力減らす」という考え方 ですが、それが適用されていない。つま り、大量の設定記述が必要であり、その まま使おうとすると本来したかった開発 がなかなか始められないという問題です。 Spring Boot は、Spring Frameworkに CoCを導入したものです。あらかじめお すすめの設定が記述済にしてある、いわ ば設定のかたまり。これによって、開発 者はすぐに開発を始めることができます。 Spring Bootとは何か、はっきりいってこ れだけです。 では、設定とは何か。それは「Bean定 義」です。Spring Frameworkには「コン テナ」（DIコンテナ）と呼ばれる、イン スタンスを管理する入れ物があります。 Beanとはそのコンテナで管理されている インスタンスを指します。「Beanを定義 する」とは、「このクラスのインスタン スをBeanとしてね」とコンテナに教える こと。では、その定義の方法は？ XMLによる定義、クラスによる定 義（@Componentの付加）、メソッドに よる定義（@Beanの付加）の3種。この いずれかを行うだけで、簡単にBean定義 を行うことができます。 定義されるBeanには、「FWを動かす ためのBean」と、「アプリケーションを 構成するBean」の２種類があります。 Spring Bootはその前者のBeanをあらか じめ用意してくれているため、セットア ップが最小限でできるということなので すが、後者のBeanにはノータッチです。 Spring Bootは設定のかたまりであり、 Spring Frameworkがもともとできること を簡単にしただけ。今日これだけは覚え て帰ってください。 https://tadayosi.github.io/jjug2017-camel_hawtio_springboot/reveal.js/index.html#/ https://www.slideshare.net/masatoshitada7/spring-boot-jjug JavaがメインテーマのJJUG、Spring FrameworkがメインテーマのJSUG。といっても、他方の領域 にまたがったセッションもありますし、区別はさほどありません。また、両カンファレンスともに、 用意された講演は硬軟様々で、初心者から上級者まで誰が来ても満足できる懐の広さは同じです。 懇親会の食べ物はどちらも豪華でおいしいし、お祭りとしての熱さも甲乙つけがたい。そもそも Spring Festで講演された谷本さんはJJUGの方ですし、勝ち負けなんて話ではないでしょう（！）。 どちらのイベントも多くの学びがあり、大変楽しいです。参加するだけで、必ず技術者として一歩 前進できます。これを読んでくださった皆様も、ぜひ、次回は両方参加してみてください。 イメージA） 「Item」のCRUD 「/Items[POST/GET] 」、「/Items/{id}[GET/PUT/PATCH/DELETE] 」 「各ItemのPrice」のCRUD 「/Prices[POST/GET] 」、「/Prices/{id}[GET/PUT/PATCH/DELETE] 」 イメージB） 「各ItemのPrice」のCRUD「Items/{id}/Prices」 んてありえないということです。大体、 モノリスとマイクロサービス、どちらが 簡単でしょう？ドメイン分析をしたり、 機能境界を考えるより、これまで通りモ ノリスを作る方がそれは楽ですよね。 今はまだ、技術論は存在しても、開発 の方法論は抜けているんです。「サービ スとして分割するためにドメイン駆動開 発のシステム境界の考えは役に立つ」な んて言って、場面だけ切り取られてもな かなか活用できるものではありません。 「マイクロサービスはアジャイルで開発 するんです」って言うのは簡単だけど、 じゃあ具体的にどうやるのか？そもそも 動くものをアジャイルでまず作って、と いうスタイルは、エンタープライズ系の マイグレーションには向かないでしょう。 今はまだ、どうやって開発するのか？ど うすればうまくいくのか？が確立されて いないので、経験のある人たちが試行錯 誤しているのが現状なのです。 それでもマイクロサービスを適用した い。その動機はなんでしょうか。大きく 分けて2つあるでしょう。1つはモノリス が持つ問題。コード肥大化で全貌の把握 が困難、細部の修正でも大量のリグレッ ションテストが発生、デプロイも大変、 ということで導入を検討するケース。も う1つは、時代的な背景。ビジネスの変化 に対応しやすいというところでしょう。 その動機をもとにマイクロサービスを 導入するにあたり、まず理解しておきた いこと。それは、複雑なシステムは簡単 にはならないということ。ハローワール ドを出すのに100ステップのコードがある というなら、それは複雑なんじゃなくて 作りを間違っているだけですし、そうい うことではなくアプリが複雑なら、それ は業務のプロセスの問題でしょう。ひと つひとつのサービスをシンプルにしたと ころで、全体のつながりはやはり複雑に なるものです。これが大前提。 次に成功の鍵を考えてみます。成功の 鍵その1としては、レガシーシステムが複 雑すぎることを認め、マイクロサービス 化をあきらめること。古いIBM社のシス テムを使っていたとしても、ハードを新 しくすれば動きますし、下手にJavaと RDBで刷新するより速いことも多いです。 それでも導入したい場合。成功の鍵そ の2としては、事前にしっかり準備するこ と。まずは、データモデルの整理。ここ がぐちゃぐちゃだと、そもそもマイクロ サービス化しようとしても手がつけられ ません。複雑なSQLを使わずとも扱える ようにすることです。 そして次のポイントは、一度にマイク ロサービス化しないこと。変更が多い部 分から少しずつ抜き出して開発すべき。 あとは、数を増やしすぎないこと。数 百のサービスを作るような事例が書籍に 載っていますが、その数のチーム管理は 厳しいでしょう。個人的にはマイクロよ り「ミニ」ぐらいがよいと思っています。 また、完全にSoRの分野だと、成功し にくいでしょうね。SoEに行き過ぎても微 妙。SoRとSoEの間くらいのところが適し ているのではないでしょうか。各所で事 例を聞いても大体そのような印象です。 ということで、色々な意味でまだまだ 課題が多いマイクロサービス。でも、オ ブジェクト指向やドメイン駆動開発も古 くから続いていますし、この技術もエン ジニアとして学ぶ価値はあると思います。 日本一やさしく説明する予定のマイクロサービス入門 JJUG #3 JSUG #3 高橋 勲（@ricto_H20DIT） 楽天株式会社 JJUG #4 JSUG #4 長谷川 裕一（@hasedanna） Starlight&Storm / 日本Springユーザ会多田 真敏（@suke_masa） 株式会社カサレアル 佐藤 匡剛（@tadayosi） レッドハット株式会社 https://www.slideshare.net/rakutentech/spring-data-restapi https://www.slideshare.net/HasegawaDanna1/spring-fest-2017 総評 - JJUG vs JSUG、結局どちらの勝利？