JSUG Spring in Summer 〜夏なのにSpring に参加してきました

　今週は久々に平日2回目の勉強会参加となりました（夏休み2発目で、平日休めたので）
　
　お題の通り初参加（？）のJSUGになります。正直最近Javaから離れてるので
リハビリの為に色々話を聞きたいな、という若干残念な動機ですが(^^;;

　さて、場所は東京駅すぐ隣の東京八重洲グラントウキョウサウスタワー、
前回来たのはAgileSamuraiBaseCampのお手伝いの時なので、今回2回目となります。
（ココのエレベータの23階まで上がるヤツが壁がガラス張りで上昇スピードも
早くて、若干ゾクッとくる感じなんだなー）

　さて、プログラム（タイムテーブル）は下記の通りでしたが、

http://www.springframework.jp/summer/timetable

自分は、R1-1.オープニングセッション、R1-2.MSAの設計、
で、ホントはR2-3に参加したかったけど、トイレで並んでたら
休み時間終わってて戻った頃には既に始まってたから途中参加は諦めて
ココで早めの昼食。41Fの休憩室からぼんやりと新宿の方を眺めながら
日本で一番売り上げが上がっているとかいう33Fのセブンイレブンで買った
おにぎりなどを食べて午後に備えました。
で、折角なんでR1-4.超高速開発ツールWagbyの技術基盤の話を聞いて
R1-5.キーノート The Macro of Microservices、
R1-6.Spring DIと大規模プロジェクト、春は来るのか本当に？
R1-7.The Bootiful Application
R1-8. 【前半】 Spring Framework/Boot/Data徹底活用〜Sprnig Data Redis編〜
【後半】 Spring適用のアンチパターンとベストプラクティス（仮）
R1-9.The Bootiful Microservice
てな感じで、午後からは結局Room1の一角に陣取ってずっと最後までそこにいた感じでした。

　と、長い前フリはこれ位にして内容を書こうかと思うのですが、
全部書くとなると相当長くなるので、個人的に一番興味があり、面白かった
R1-2.の鈴木雄介さんのセッションの内容についてメモ書きを。

　⇒　既に資料もアップして下さってるので、それと合わせながらなら
　　　少しくらいは内容（ライブ感）が伝わるかな、と。

講演資料は http://www.slideshare.net/yusuke/jug2015 に。

（以下、「⇒」の部分は僕の私見等です）

- - - - -

【マイクロサービスアーキテクチャ（MSA）の設計】

P.3（Agenda)
・MSAは去年位から流行り出した言葉だが、今年も広がっていくと予想している。

P.5（MSAとは？）
・MSAという言葉自体はファウラーのブログに紹介されたのがキッカケでブレイクした。
　⇒　http://martinfowler.com/articles/microservices.html のことではないかな、と。

P.6（MSAの２つの側面）
・MSAには9つの特徴があるが、大きく「技術面」「文化面（姿勢・態度等）」の2つに分類できると考えている。

P.7（MSAの技術面）
・これまで「開発」では「コンパイルが通った（ソフト・機能を作る）」という事が、ある意味ゴールになっていた。
　それと比較して「サービス」は「機能を提供し続ける」ことである。
　「機能」は成功しているが、「サービス」では失敗している、ということもある。例えば
　遅すぎて使えない、等の場合である
・「機能」＝「ファンクション、フィーチャー」、「サービス」＝「○○ビリティ（非機能っぽい考え方）」
　言い換えると「機能を提供し続ける為の考え方」とも言える。
　そして、サービス自体がその裏側のサービスによって構成されているというのがMSAの考え方である
・昔はシステムを止めてデプロイ、という手段が取れたが、最近では「稼動しているシステム
　（サービス）に対して」（そのサービスを動かしたまま）システムを追加していく、という状況になっている。
・システム開発が「静的なもの」から「動的なもの」へ移り変わってきている。
　言い換えると単純にシステム同士を繋ぐ、という考え方から「動いているサービスを（動かしながら）
　協調動作させる」という考え方に変わってきた。
・そこで重要になってくるのが、協調動作させる為のメッセージ・ルール、いわゆるプロトコルである。
・また、それらのサービスをどうやってマネージするかも重要。今までと違い、「Aというサービスは
　○○という機能を提供してるので自由に使って下さい」というスタンスになるので、Aというサービスは
　自分自身に対しては責任を持てるが、（外部アクセス等に対しての）リソースのコントロール等は難しい
・だから、（サービスをマネージしていく為には）サービスを継続的に稼動監視・障害検知していく事が重要になってくる。
　また、Aサービスが勝手にVerUpしてしまうと、利用者がついていけなくなってしまうので、如何に
　過去のサービスのインタフェースを維持しながら新しいサービスを提供するか、も工夫がいる

P.8（MSAの文化面）
・「開発」から「サービス運営」への考え方のシフト。
　単に機能を提供すればよい、では無く「サービスを運営していく」ことが興味の関心事となってきた。
・「ドメイン毎の自主性を認め、標準化を否定する」。つまりドメインに応じた考え方を取る、ということ。
　ファウラーも「標準フレームワークは必要ない」という事を書いている。
　⇒　固有のドメイン（例えば会計システムと在庫管理システムとECサイト）では、それぞれ必要とされる、
　　　適した技術が違うのが当然であり、それぞれ（のドメイン）にあった技術を用いればよい、ということ。
　　　そして、それを上手く連携させていくかがキモだ、という風に理解しました。

P.9（MSAの背景）
・良くAmazonの仕組みが例として出される。いまやそこらのエンタープライズよりも巨大で複雑な
　ウェブサービスになっている。
・物流は（倉庫があるので）あまり変化しない（できない）が、フロントは顧客に合わせて変化する。
　なので、それぞれ個別にサービスを再構築していく必要がある。
　それが必然的にMSAに向かわせた。
　⇒　向かった結果、MSAになったという風にも言えるかな、と。

P.10（MSAの背景）
・クラウドや仮想化技術もAmazonが（彼ら自身が必要とした結果）、作り出したサービスである。
　コードでサービスが管理できるということも大きな変化である
　⇒　仮想化技術を利用して、かつChefやAnsibleとかでサーバ・インフラを準備するということかな、と。
・APIの組み合わせによる動作構成パターン（例えばクラウドパターンとか）の代表例がパブリッククラウドサービス。

P.11（MSAとは）
・結局MSAは理想論（理論）としての結果ではなく、現実解として出てきた結果である。
　⇒　デザインパターンの成り立ちとも共通するところがあるなー、と。
・ただ、言葉になったことによって、（過去に「アジャイル」がそうであったように）理想論的になりつつあるので
　皆さんはそれに流されないようにして欲しい。
　
P.13（MSAを理解する）
・（鈴木さん的理解では）MSAは技術論というよりも技術管理論である。
　「MSAという優れた技術があって、それを使えば皆ハッピーになる」、ということではない。
　
P.14 （MSAを理解する）
・「マイクロ」ということに惑わされず（＝粒度ではなく）、「関係性」に注目するのが大切。
　要は「複雑化してしまっているものをどうやって管理するんだ」ということ。
　
P.15（SOAとMSA）
・SOAは理想（こうあるべき）。
　MSAは現実解（結果、こうなった。部分最適の結果）。ある種の諦め、割り切りともいえる。

P.16（システム統治としてのMSA）
・MSAへの流れを政治の流れと重ねると面白い。（各個別のシステムの）乱立〜SOA〜MSAの流れ。
　SOAを成功させるためには企業全体を見渡して全体最適化が出来る人が必要。そういう人がいて、
　尚且つ安定したビジネス領域であれば上手くいく。
　そうでない場合、そういうアーキテクトがいない、もしくはビジネスが激しく変化するという場合では
　中々上手く行かない。そこで出てきたのがMSA。
　ただし、「有識な市民」がそれぞれの場所に必要。

P.17（MSAの適用）
・単純にMSAの方がSOAよりも良い、というわけではない。それはアジャイルと同じ。
・また、「ウチのシステムはExc●lで動いているんだ」とか「APIアクセスには申請が必要」とか
　「協調していく」という姿勢じゃないシステム・人に囲まれてしまうと上手く行かない。

P.18（MSAと開発プロセス）
・昔は技術の方に柔軟性が無かった分、イテレーションに分割して開発するなどのプロセスに
　柔軟性を持たせて対応してきた（＝都度考え直す事で、誤った選択をできるだけ避けるように工夫してきた）。
・大きな全体を作っていく場合に、部分から作っていかざるを得ない（から、イテレーションで細かく区切って作っていこう）
　という考え方がアジャイルのアプローチだった。
・MSAではそれにプラスして、技術的に判断を遅らせる事が可能になったのでWFのアプローチも取れるようになってきた。
　例えばキャパシティプランニングは昔は悩ましい事の一つだったが、今なら悩まなくて済むような技術的
　選択肢を選べるようになってきた。
　⇒　AWSとかのクラウド、仮想化技術、ですね。
・厳密にアジャイルをやろうとすると、結構大変。むしろWFよりも堅苦しくなったりする。
　予想可能な領域や、（変化しにくい・させにくい）他システムとの連携部分であったり、マスタ関連の話は
　むしろWFの方が適している（合理的）。
　⇒　禿同ってヤツですね。個人的にアジャイルの方向性・考え方は好きだけど、「アジャイルだったら何で出来る」
　　　なんてのは、贔屓の引き倒しになるんじゃなかろうか、と。
・この10年くらいで技術面と文化面が相互に影響しあいながら出てきた結果がMSAと考えると良い。

P.20-21（MSAのデザイン）
・（省略）

P.22（ドメインの発見）
・DDDの罪と言えば罪になってしまうが、「ドメインというものがある」という前提で始めてはダメで、
　色々探した結果「ドメインを発見する」という結果形と考える方が良い。
　ドメインがあるからそれに従って管理していきましょう、というのは間違い。
　⇒　↑でも出ましたが、デザパタ的な考え方なのかな、と。
・ドメインの境界を探すということについて、例えば車を例にしてみる。
　「タイヤ」は（地面と車の境界だが、取替えのきく）「ゴム」で出来ている。何故なら
　（走れば走るほど）削られていく為である。昔の馬車などは
　木で車輪と車軸が一体で作られていた為、交換しようとしたら丸ごと交換する必要があった。
　言い換えると「変化の境界」をそこに見出し、（取替えのしやすい）適したアーキテクチャを適用したと言う事。
・とは言うものの、（システム開発における）変化の境界というのは大体の場合、不明確。
　ただ、一度線を引いたらそれがずっと続く（維持する圧力が内外からかかってしまう）

P.23-24（品質特性）
・（省略）

P.25-26（プラットフォームの利用）
・プラットフォームは動的な資産をどうやって管理していくか、ということ。
　プラットフォームは広ければ広いほど有効。
・（プラットフォームの範囲については資料参照）
　結局AWSの提供しているサービスの事。良く練られている。
　
P.27（ドメインとプラットフォーム）
・ただ、あまりにもプラットフォームで引き取りすぎるとドメイン自体のコードは減るかもしれないが
　逆にドメインの独自性がどんどん無くなっていく。
　結局その辺りのバランスが重要。
・ドメインの固有性・独立性をドコまで保障するか、みたいな点で今後のアーキテクトは悩む事になるだろう

P.29（MSAの実例）
・MSAの例として分かりやすいのはECサイト。例えばとある企業が既存システムにECサイトを追加しよう、
　みたいな話を想像してもらうと良いかもしれない。

P.30（ECサイトのドメイン設計）
・買わせるための属性（例えばどうやって商品検索するか）と売るための属性（クレジットカード情報の
　入力とか、住所入力とか）は違う。

P.31（サービス配置例）
P.32-33（ECサイトの構成）
・サービスの配置パターンは大体似てくる。また、MSAの事例としても分かりやすい。
・サービスごとに開発アプローチや技術もそれぞれのサービス・ドメインに適した形のものがある。
　それらを分割・統治するというのがMSAの考え方。

P.34（実例から実践へ）
・「正解は無い」。結果的に「MSAになった」というほうがよい。
　いいデザインをしたら結果的にMSAになるし、いいプロセスを選択していけば
　「結果的に」アジャイルになったというのと一緒で、手段を目的化しないように。

P.36（Springについて）
・ブームになってるけど、Spring Bootだけではない。

P.37〜（まとめ）
・「良識のある市民」の存在も非常に重要。いない場合、いる場所（システム）に寄せる、といったような
　対応も必要かも。
・「MSAにする」ではなく「MSAになる」のが健全。
　単にGoogleがやってるからその方法を真似したら上手く行く、というわけではない。

- - - - -