第三回マイクロサービスアーキテクチャ読書会（後半）

第３回MSA読書会（後半）
#MSA読書会

こんにちは！
しょぼちむ
(@syobochim)

後半のもくじ
4.11 マイクロサービスの世界における
DRYとコードの再利用のリスク
4.12 参照によるアクセス
4.13 バージョニング
4.14 ユーザインターフェース
4.15 サードパーティーソフトウェアとの統合
4.16 まとめ

後半のもくじ
4.16 まとめ ⇦ここからいくよ！

4.16 まとめ
４章で言いたいこと
•いかなる代償を払ってもデータベース統合を避けます
•RESTとRPCとの間のトレードオフを理解し、RESTをリクエス
ト / レスポンス統合の優れた出発点と積極的にみなします
•オーケストレーションよりもコレオグラフィを選びます
•ポステルの法則を理解して耐性のあるリーダー（Tolerant
Readers）をつかって破壊的変更を避け、バージョンが必要
ないようにします
•ユーザインターフェースを合成レイヤと考えます

4.16 まとめ
こっちは前半部分

4.16 まとめ
このふたつについてまず説明していきます！

4.16 まとめ

後半のもくじ
4.16 まとめ
このあたりは最後に時間があれば

ポステルの法則を理解して耐性のあるリーダー
（Tolerant Readers）をつかって破壊的変更を避け、
バージョンが必要ないようにします

について書いてあるのが

P73
マイクロサービスに関して話すたびに
バージョニングをどのように行うかを
訊かれました。
人々は「いつかはサービスのインターフェースを
変更しなければならない」という当然の心配をし
変更の管理方法を理解したいと思っている。

この問題を分割し、対策を説明していきます。
•コンシューマ(クライアント)の心持ち
•サービスの心持ち
•バージョンの意味付け
•サービスのバージョンアップ方法

4.13.1 最大限の見送り
「サービス側の変更に影響されないように
気をつけましょう」
というコンシューマ側の心持ちのはなし

「サービス側の変更に影響されないように
気をつけましょう」
というコンシューマ側の心持ちのはなし
影響されない＝バージョンが必要ない

最初から破壊的な変更を避けることが、
破壊的変更の影響を減らす最善の方法です。
クライアントに優れた振る舞いを推奨し、
そもそもサービスと密結合にならないように
しましょう。

たとえば、メールサービスが➡のレスポンスを
おくってくるとき
<customer> 
<firstName>Sam</firstName> 
<lastName>Newman</lastName> 
<email>sam@magpiebrain.com</email> 
<telephoneNumber>555-1234-5678</telephoneNumber> 
</customer>

telephoneNumberをつかわないコンシューマーが、こんな
クラスを作っていて、リクエストに来ている項目をそのま
まバインディングするソースを書いちゃうと。。。
public class Customer { 
public String firstName; 
public String lastName; 
public String email; 
public String telephoneNumber; 
}

メールサービス「メール送信にtelephoneNumberって使っ
てないよね？消します。」
<customer> 
</customer>

メールサービス「メール送信にtelephoneNumberって使っ
てないよね？消します。」
「えっ」
<customer> 
</customer>

メールサービス「メール送信にtelephoneNumberって使って
ないよね？消します。」
「えっ」➡ クラス修正が必要
（telephoneNumberを消すことがコンシューマの破壊的変更
になっちゃう。）
public String telephoneNumber; 
}

たとえばfirstNameとlastNameの階層構造を明確に推測し
ている場合
『customer > firstName』『customer > lastName』
『customer > email』
}

メールサービス「項目増えてきたから階層構造にしてみた
わー。」
<customer> 
<naming> 
<nickName>Magpiebrain</nickName>
<fullName>Magpiebrain</fullName>
</naming>
</customer>

わー。」
「えっ」
<customer> 
<naming> 
<nickName>Magpiebrain</nickName>
<fullName>Magpiebrain</fullName>
</naming>
</customer>

わー。」
「えっ」 ➡ クラス修正が必要
（項目名は変わってないのに。。。）
public Naming naming; 
}
public class Naming { 
…
}

必要な項目のみ定義する、や、フィールドの場所（構造）
を曖昧にしておく、など、サービスとコンシューマの結合
を小さくすれば、リーダー(Reader)が関心のない変更を無
視することができる！！！

耐性のあるリーダー（by Martin Fowler）
•http://martinfowler.com/bliki/TolerantReader.html
•https://uramoto.wordpress.com/2015/09/21/マイクロサー
ビスのデザインパターン/

XPath
•https://msdn.microsoft.com/ja-jp/library/
ms256086(v=vs.120).aspx

ポステルの法則
https://ja.wikipedia.org/wiki/ジョン・ポステル
「送信するものに関しては厳密に、受信するものに関して
は寛大に」
「人にやさしく、自分にきびしく」

4.13.2 破壊的変更の早期の把握
「コンシューマへの変更の影響を出す前に
検知しましょう」
というサービス側の心持ちのはなし

「コンシューマへの変更の影響を出す前に
検知しましょう」
というサービス側の心持ちのはなし
影響を出さない＝バージョンが必要ない

コンシューマ駆動契約
で
問題を早期に検出する

コンシューマ駆動契約の詳しいはなしは
７章を発表する人にお任せしますが。。。

こんポステルの法則を理解して耐性のあるリーダー
コンシューマー（ヘルプデスク）が期待する動作を
顧客サービスがテストとして書いて動作を保証する。
そのテストが、コンシューマーとの契約になる。
ヘルプデスクの
コンシューマ駆動契約の
テスト範囲

サービスやライブラリをテストすることで、
この動きはまずいぞ！
(契約違反だぞ！すなわち破壊的変更！！)
というのを検知することができる。
※テストを書いているので、
破壊的変更の特定も簡単！！

破壊的変更が入ったら、
•顧客サービスが破壊的変更を回避する
•破壊的変更を受け入れてコンシューマの担当者たちと相
談する

このあたりが、
「バージョンが必要ないようにします」
という話でした。
それでもコンシューマが
サービスの破壊的なバージョニングに
対応しなきゃいけないことが
絶対にある
じゃあ、どう運用していけば
いいんだろう？

4.13.3 セマンティックバージョニングの利用
コンシューマとサービス間で
「変更の種類をわかりやすいようにしましょう」
というルールを作るはなし

変更の種類をわかりやすくする手段のひとつが
セマンティックバージョニング
http://semver.org/lang/ja/

MAJOR.MINOR.PATCH
•MAJOR：後方互換性のない変更
•MINOR：後方互換性のある新機能の追加
•PATCH：既存機能にバグ修正が行われた場合
※他にも細かいルールがサイトには書いてあるよ。

使っている側はバージョンを見るだけで、変更に
どの程度の影響があるのかを判断できる。
明確なルールがあることで、
サービスを提供する側と受け取る側の情報交換の
プロセスを簡略化することもできる。

4.13.4 異なるエンドポイントの共存
サービス側の変更によって
コンシューマーになるべく変更を
与えないようにしましょう
（影響を制限する）

•独立してリリースできるようにしたい。
•コンシューマーに同時アップグレードを強要し
たくない。

•独立してリリースできるようにしたい。
•コンシューマーに同時アップグレードを強要し
たくない。
そうだ！エンドポイントの新旧両方のバージョン
を公開すればいいんだ！！！

•提供する機能のエンドポイントを拡張して新旧両方をサポート！
•コンシューマの移行が済んだらAPIを縮小して古い機能を取り除
く！

•新しいインターフェースをできる限り早く公開できる
•コンシューマに移行する時間を与える

ルーティングする手段
•リクエストヘッダのバージョン番号
‣URIが不透明になるので、クライアントにURI
テンプレートをハードコードしなくて済む
•URIのバージョン番号（/v1/customer と /v2/
customer）
‣物事が非常に明確になり、リクエストのルー
ティングを簡素化できる

ただし、バージョンが3つ以上になると辛い
エンドポイントに合わせた
コードとテストを用意しなきゃいけないので
メンテが大変になっちゃう。

4.13.5 複数のサービスバージョンの同時使用
「わざわざエンドポイントを
分けるってめんどくさくない？
二つのバージョンのサービスを
用意しておけばいいじゃん
時間が出来たら移行しよう」

古いコンシューマのトラフィックを
旧バージョンにルーティングし
新しいバージョンのトラフィックを
新バージョンにルーティングする

でも
これはアンチパターン

サービス内の内部のバグを修正する必要があると
2つを直さなくちゃいけなくて大変
振る舞いをミドルウェアのどこかか
一連のnginxスクリプトに
配置しなければいけなくなるので
システムの振る舞いを検証するのが大変
データが旧バージョンと新バージョンの
どちらで作られたものかがわからない

サービス内の内部のバグを修正する必要があると
2つを直さなくちゃいけなくて大変
振る舞いをミドルウェアのどこかか
一連のnginxスクリプトに
配置しなければいけなくなるので
システムの振る舞いを検証するのが大変
データが旧バージョンと新バージョンの
どちらで作られたものかがわからない
コードベースを
分岐させるのはやめよう。
（http://12factor.net/ja/）

短期間だけこの方法をとるのはいいよ。
ブルーグリーンデプロイや
カナリアリリースなどをする場合はOK
（詳しくは7章を担当する人が話してくれます。）
ブルーグリーンデプロイ
http://www.atmarkit.co.jp/ait/articles/1312/03/news033_2.html
カナリアリリース
http://www.nttdata.com/jp/ja/insights/trend_keyword/
2013061301.html

ローリングメンテナンス
http://www.itmedia.co.jp/im/articles/
0701/26/news124.html
みたいに、数分や数時間だけバージョンを
共存させることはありますよね。

Netflixでも古いコンシューマを変更するコスト
が高すぎる場合、特にレガシーデバイスがまだ
APIの旧バージョンに縛られている場合に備えて
「慎重に」利用している。

4.13.4 と 4.13.5を比べてみよう
4.13.4

4.13.4 と 4.13.5を比べてみよう
4.13.4
エンドポイントは
複数のバージョンに対応しているが、
裏のロジックは1つ。
古いバージョンのリクエストを受け取ったエンド
ポイントは、新しいバージョンの形式に変換して
から裏のロジックに流す。

4.13.4 と 4.13.5を比べてみよう
4.13.5

4.13.4 と 4.13.5を比べてみよう
4.13.5
エンドポイントのみならず、
裏のロジックも新旧存在する。
つまり、アプリケーションそのものが
2つある状態。

バージョンのお話はここまで！

説明したこと
•コンシューマ(クライアント)の心持ち
•サービスの心持ち
•バージョンの意味付け
•サービスのバージョンアップ方法

ディスカッションします？

•現場で「バージョンが必要ないように」って実
現してますか？
•まだしてないひとは、どうすればいいと思いま
すか？
•サービスとコンシューマ間の情報共有で何か工
夫してますか？

ユーザインターフェースを合成レイヤと考えます
について書いてあるのが

すべてのマイクロサービスを
顧客が理解できるものにまとめる場所

前まで
GET / POST経由でサーバ側で処理。
サーバ側プログラムがページ全体を描画して
クライアントブラウザに送信。
クライアントブラウザは少しの処理しかしない。

最近
JavaScriptがもろもろやってくれる。

4.14.1 デジタルへ向けて
最近は、
Web・モバイル・デスクトップアプリケーション・
ウェアラブル端末など、
いろんな媒体でWebサイトが見られている。

顧客がどのように対話するか
正確には予測できない
かつ
デバイスによって
見たいコンテンツも違う

そこで、ユーザインターフェースを
合成レイヤだと考える。
提供するさまざまな機能を
組み合わせる場所

4.14.2 制約
でも、ユーザインターフェースって
いろんな種類があるから、
ただまとめればいいわけでもないですよね？

4.14.2 制約
たとえば、それぞれのデバイスの使い方は
タブレットでは右クリックできない
スマホでは親指だけで操作したい
みたいに。

4.14.2 制約
中核のサービスは同じでも
それぞれのインターフェースがもつ制約に
サービスを適用させる必要がある。

じゃあ、どういう風に
webサイトを作っていけば
いいんでしょう？

じゃあ、どういう風に
webサイトを作っていけば
いいんでしょう？
※いろんなサイトを例に出したりしますが
「そうじゃないぞ！！！」
という方（中の人とか）がいたら
教えてください。。。

4.14.3 API合成
まずはよくあるサイトの作り方
UIにAPI呼び出しを行わせて
すべてをUIコントロールにマッピングする

4.14.3 API合成

4.14.3 API合成
この方法の３つの欠点
•サービスの作成者とユーザインターフェース
の作成者が違う
•通信が多くなる可能性がある
•デバイスごとにレスポンスを調整できない

4.14.3 API合成
P81 段落１つめ

4.14.3 API合成
P81 段落２つめ

4.14.3 API合成
P81 段落３つめ

4.14.3 API合成
•デバイスごとにレスポンスを調整できない。
•小さな変更でも、複数のチームに変更リクエストをお
こなわないといけなくなる。
•サービスの担当者たちはサービスのユーザへの見せ方
に関わらない。

4.14.3 API合成
顧客サービス担当者「サービス変更したからUI
もあわせて変更して！」
UI担当者「はーい」

4.14.3 API合成
レコメンデーションサービス担当者「サービス
変更したからUIもあわせて変更して！」

4.14.3 API合成
UI担当者「いま顧客サービスの方を修正してい
るから。。。」

4.14.3 API合成
UI担当者「いま顧客サービスの方を修正してい
るから。。。」
レコメンデーションサービス担当者「こっちの
方が急いでるんだけど…。」

4.14.3 API合成
つらい

4.14.3 API合成
顧客サービス担当者「この項目の桁数を変えよ
うと思う。画面への影響ないか確認して。」

4.14.3 API合成
web UI担当者「わかったよ。」
モバイル UI担当者「わかったよ。」

4.14.3 API合成
顧客サービス担当者「リリースしたいんだけど
確認おわった？」

4.14.3 API合成
web UI担当者「終わった」
モバイル UI担当者「まだだよ。」

4.14.3 API合成
web UI担当者「終わった」
モバイル UI担当者「まだだよ。」
リリースできない

4.14.3 API合成
•デバイスごとにレスポンスを調整できない。

4.14.3 API合成
１つの画面を表示するために
３つのサービスを
呼び出さないといけない
❶ ❷
❸

4.14.3 API合成
たとえば（１）
ヘルプデスクアプリではWeb画面で見る
顧客記録を全部見たい
移動店舗ではモバイルアプリで見る
店舗で買ったことがある顧客記録だけ見たい

4.14.3 API合成
たとえば（２）
http://qiita.com/api/v2/docs#ユーザ
レスポンスでいろんな情報が返ってくる
web画面で見るならいいけど
スマホで見るときはここまで情報はいらないかも

では、欠点を補うためには
どうしていけばいいでしょう

4.13.4 UI部品合成

サービスにUIの部品を直接提供させ
その部品を集めてUIを作成する

UIコンポーネント

たとえば
http://syobochim.hatenablog.com/
twitterのところがwidgetになっている

たとえば
急遽つけたので、
かなり雑です。。。

たとえば
デザインを決めているのは
ブログの管理者でもはてなさんでもなく
twitter！

たとえば
デザインを決めているのは
ブログの管理者でもはてなさんでもなく
twitter！
widget系が多い。
このモデルを適用しているサイトは少ない

サービスを変更するチームが
UI部品の変更も行う

サービスを変更するチームが
UI部品の変更も行う
➡
変更をすぐに公開できる

ただし、注意があります

ユーザエクスペリエンス（ユーザ体験）を
他のサービスと一貫させないと
使いにくくなっちゃう。

「えっ、この部品は更新するために
下にスクロールすればいいのに、
こっちの部品は更新ボタンを押すのか。。。」

「えっ、この部品は更新するために
下にスクロールすればいいのに、
こっちの部品は更新ボタンを押すのか。。。」
わかりにくい！！！！

そういうのを回避するために
リビングスタイルガイド
を作りましょう

そういうのを回避するために
リビングスタイルガイド
を作りましょう
HTMLやCSS、画像といった資産を共有してある程
度の一貫性を持たせる
http://getbootstrap.com/javascript/
動くものがあると簡単にイメージを共有できる

解決できるか確信が持てない大きな課題

サービスが提供する機能が
ウィジェットやページに
きちんと収まらないことがある。

サービスが提供する機能が
ウィジェットやページに
きちんと収まらないことがある。
対話の形式が横断的になるほど
このモデルが当てはまる場合が少なくなり
単なるAPI呼び出しに戻る場合がある

こういうことが苦手
ゼクシィは
需要がタブごとに別れている
http://zexy.net/
（タブを各サービスとする）

こういうことが苦手
ゼクシィは
需要がタブごとに別れている
http://zexy.net/
（タブを各サービスとする）
サイトの右上の検索機能を使うと
各サービスを混合した結果が出てくる
（対話の形式が横断的）

でもこのふたつは
解消できていない

『4.14.5 フロントエンド向けのバック
エンド(BFF)』はここの二つの話

4.14.5 フロントエンド向けのバックエンド(BFF)
サーバ側集約エンドポイントの
APIゲートウェイを用意する！
https://www.ogis-ri.co.jp/otc/hiroba/
others/SilliconValley5/

APIゲートウェイで
サービスを順番に呼び出して
結果を組み合わせる

サーバとの通信が一回で済む

https://twitter.com/kawasima/status/
753483914954485761
サーバとの通信が一回で済む

AWSにも
API Gateway管理サービスがある
http://docs.aws.amazon.com/ja_jp/
apigateway/latest/developerguide/
welcome.html

でも
サーバ側エンドポイントの振る舞いが
多くなりすぎたとき
大惨事になることがある

でも
サーバ側エンドポイントの振る舞いが
多くなりすぎたとき
大惨事になることがある
全てのサービス向けの
１つの巨大なレイヤをもつのは
影響が大きくなりすぎるので問題

たとえば
一つのサービスに破壊的変更があったとき
ブラウザもモバイルもネイティブアプリも
すべてのクライアントに影響が出ちゃう
APIゲートウェイ自体が死んだ時の影響も
すごく大きい

•サービスの作成者とユーザインターフェースの
作成者が違う

BFF(フロントエンド向けのバックエンド)
Backends For Frontends
http://samnewman.io/patterns/architectural/
bff/

ここが分かれた

サーバーに組み込まれた
ユーザインターフェースの部品

各デバイスごとの表示を
細かくわけましょう！

デバイスごとに表示を変えることができる
たとえばGoogle

検索結果がwebとスマホで
少し違う

検索結果がwebとスマホで
少し違う
➡
「スマホ対応」のサイトを優先

特定のユーザエクスペリエンスの提供に
特化した振る舞いだけを管理すること。
さもないと
入り込むべきではないロジックが
入り込む恐れがある。

4.14.6 ハイブリッド手法
Webサイトは部品ベースの組み立てをして
モバイルアプリケーションはBFFを使う
という企業もある。
ユーザに提供する基盤となる機能の
凝集性を維持することが必要

https://www.thoughtworks.com/insights/blog/
bff-soundcloud
ちなみに
「4.15.5 ストラングラー（絞め殺し）パターン」
についても書いてる

4.15.5 ストラングラー（絞め殺し）パターン
http://bliki-ja.github.io/
StranglerApplication/

http://bliki-ja.github.io/
StranglerApplication/
昔からやっている
「古いシステムを徐々に新しいシステムに
移行していきましょうね」
のかっこいい言い方

古いシステムへの呼び出しを
インターセプトする。
呼び出しを既存のシステムに
ルーティングするか
自分で記述した新しいコードに向けるかを
判断できる。

でも、ハイブリッドよりも。。。
BFFで作った層とクライアントで
同じ言語、同じ実装で動かす
isomorphic
https://speakerdeck.com/koichik/isomorphic-
survival-guide

おはなししたこと
•API合成
•UI部品合成
•APIゲートウェイ
•BFF(フロントエンド向けのバックエンド)
•ハイブリッド手法
•isomorphic

ではディスカッションタイム！
•いま紹介した手法のどれかをつかっていますか？
•いま業務で作っているサービスはどの手法を当
てはめればいいと思いますか？

4.16 まとめ
まとめに関する説明が終わったのですが
ここ話してないです。
•4.11 マイクロサービスの世界におけるDRY
とコード再利用性のリスク
•4.12 参照によるアクセス
•4.15 サードパーティソフトウェアとの統合
(4.15.5 ストラングラーパターンは話しましたが…)

4.16 まとめ
まとめに関する説明が終わったのですが
ここ話してないです。
それぞれ、さらっと話ていきます！

4.16 まとめ

DRY (Don't Repeat Yourself)
コードの重複を避けるようにすること

DRY (Don't Repeat Yourself)
コードの重複を避けるようにすること
システムの振る舞いと
知識の重複を回避すること

重複コードを抽象化して
複数の箇所から呼び出すような
共通ライブラリを作成する

マイクロサービスとコンシューマを
過度に結合すると危険！
マイクロサービスの小さな変更が
コンシューマへの不要な変更を
引き起こしてしまうかも…！

変更したよ！
やったー！

変更したよ！
やったー！えっ
えっえっ

共有コードをサービス境界外で使うと
結合の可能性を招きます
ログライブラリなど、
外部から見えないものはOK

一つのマイクロサービス内ではDRYを
やぶらないけど
すべてのサービスに渡るDRYの違反には
寛大になろう!!!
DRY違反よりもサービス間の結合の方が
害があるよ

4.11.1 クライアントライブラリ
ただし、一部の共通的な処理は
それぞれのサービスで実装するのではなく
クライアントライブラリで共通化すると
制御が簡単になることもある。

4.11.1 クライアントライブラリ
Netflixのクライアントライブラリ
https://github.com/Netflix/ribbon
サービスの検出・故障モード・ロギング
など
実際のサービス自体の性質とは
関係ないところに対処する

ドメインエンティティに関する情報を
渡す方法について

あるタイミングの
顧客データ

ここの
顧客データは
最新なの？

他のサービスから
更新されているかも

じゃあどうすればいいの？

実際に使う
タイミングで
情報をとる

変更が入っても
平気！

常に顧客サービスにアクセスして
特定のCustomerに関連する情報を
調べていると
顧客サービスの負荷が大きくなりすぎる
情報が新しいと考えられる期間を知らせると
キャッシングを大いに活用して
負荷を減らせる

4.15 サードパーティソフトウェアとの統合
自分では制御できないシステムに
対する統合

自分では制御できないシステムに
対する統合
•Excel（オフィス生産性ツール）
•OS
•給与システム
など
わざわざ構築するのはしんどい

4.15.1 制御の欠如
ツールの拡張に使えるプログラミング言語は
提供ベンダによる
統合とカスタマイズの作業を
チームに取り戻すことが大切

4.15.2 カスタマイズ
カスタマイズが可能なツールもある
でも
カスタマイズのコストは
新規に構築するよりも
高くなってしまう場合があるので注意

4.15.2 カスタマイズ
複雑なカスタマイズをするよりも
組織のやり方を変更する方が
理にかなっている

4.15.3 統合スパゲティ
ツールとの統合方法も課題
サービス間の統合方法を
入念に検討することが重要

4.15.4 思い通りにする
自分が制御するプラットフォーム上で
全てのカスタマイズを行い
ツール自体を使うコンシューマの数を
制限することで
状況を自分の思い通りにする

持ってないひとは是非！

ありがとうございました

第三回マイクロサービスアーキテクチャ読書会（後半）

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to 第三回マイクロサービスアーキテクチャ読書会（後半）

Similar to 第三回マイクロサービスアーキテクチャ読書会（後半） (6)

第三回マイクロサービスアーキテクチャ読書会（後半）