makopi23のブログ

makopi23が日々の生活で感じたことを気ままに綴るブログです。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

「第3回 マイクロサービスアーキテクチャ読書会 #MSA読書会」に参加しました

2016/7/16(土) 「第3回 マイクロサービスアーキテクチャ読書会 #MSA読書会」に参加してきました。

DoorKeeper
https://architect-club.doorkeeper.jp/events/48267

場所は住友不動産新宿グランドタワー14Fです。
参加者は40人くらいでしょうか。

以下の書籍をターゲットとした読書会なのです。

マイクロサービスアーキテクチャ
Sam Newman
オライリージャパン
売り上げランキング: 3,746


今回が3回目ですが、一応これまで全部参加してます。
ウチの部署で開発してるフレームワークがマイクロサービスを意識してたりするので、この本で勉強しようと思った次第なのです。

今回は4章が範囲でした。以下、個人的メモ。


第4章前半: @tenten0213 さん


Msa読書会#3前半 from Takehito Amanuma


4.1.1 破壊的変更を回避する
  • JAX-RSのObject Mapperの設定で、未定義のプロパティがあっても無視する設定を入れておく。

4.1.4 内部の実装詳細を隠す
  • case文やif文でサービスをスイッチさせるのは辛い・・・

4.3 共有データベース
  • DBスキーマ変更のタイミングでコンシューマ側を壊してしまう可能性がある。
  • ロジックが分散して凝集性と疎結合が失われる。

4.5 オーケストレーションとコレオグラフィ
  • 図4-3のオーケストレーションの例で、顧客サービスは「神サービス」と呼ばれることがある。
    • 神サービス = 各サービスのハブとなるサービス
    • 命令されたことだけやるサービス = ドメイン貧血症のCRUDサービス
  • コレオグラフィ = 各サービスが、顧客作成イベントを購読(subscribe)している。
    • ビジネスプロセスがシステムに暗黙的になってしまう。
    • 各サービスの監視が必要。
  • 監視をするプロダクトの例
    • Zabbix ・・・ 統合監視ソフトウェア
    • Zipkin ・・・ ネットワーク的に分散したAPIコールを分析して可視化
  • 読書会主催者の川島さんのQiita記事


ディスカッション No.1
 お題:オーケストレーションとコレオグラフィ、どちらを採用すべき?



各テーブルでディスカッション。私のテーブルや他のテーブルでは以下の様な意見が出ました。
  • コレオグラフィは各サービスがポーリングするので、ポーリング間隔が長いと遅延が発生するのでは?
  • コレオグラフィってオンラインバッチとかキューっぽいのかな。
  • 最初はオーケストレーションで設計して、サービスが増えてくるとコレオグラフィに切り替えるのが現実的では。

(つづき)

4.6.2 ローカル呼び出しはリモート呼び出しとは異なる
4.7.2 アプリケーション状態エンジンとしてのハイパーメディア(HATEOAS)
  • さまざまなRESTの形式を比較したリチャードソン成熟度モデル
  • Lebel 0(開始点):
    • URIとHTTPメソッドが1:1
    • 例:失敗してもStatus Codeは 200 で、レスポンスボディのXMLの属性名<appointmentRequestFailure>で失敗を知らせる。
  • Level3
    • 状態と振る舞いを公開する。
    • クライアントが次にやるべき振る舞いを<link>のrelやurlで示す。
    • HATEOAS

4.7.3 JSONか、XMLか、他の何かか
  • HAL(Hypertext ApplicationLanguage)が一番使われている。
    • JSON用のハイパーリンクの一般的な標準や規則を提供する。
  • その他の仕様としてSIRENとかJSON APIなどがあるが、デファクトスタンダードは無い。戦争になっている。

4.7.5 HTTP上のRESTの欠点
  • フレームワークによってはPUT/DELETEに未対応のものある。
  • スタブを簡単に自動生成、というのが使えない。とはいえライブラリでサポートしてくれるものある。(例: stubby4j)

4.8.1 技術選択
  • エンドポイント側で対処していきましょう。ミドルウェアに依存しすぎないこと。

4.8.2 非同期アーキテクチャの複雑さ


ディスカッション No.2
 マイクロサービスアーキテクチャに適用するならどっち? 
  • リクエスト/レスポンス
  • イベントベース


テーブルごとにディスカッションし、いくつかのテーブルに発表いただきました。出た意見は↓
  • リクエスト・レスポンスでも非同期にできる。イベントベースも非同期。なので使い分けは場合によるのでは。
  • 2択を出しつつも、両方とも使うんじゃないの。
  • マイクロサービス間は「イベントベース」にして、クライアントからの呼び出しはRESTで「リクエスト/レスポンス」にする。
  • 両方を同居させてマイクロサービスを作るのかなぁ。
  • 非同期でもリクエスト/レスポンスはできる。

(つづき)

4.10 Rx(Reactive Extentions)

第4章後半: @syobochim さん


第三回マイクロサービスアーキテクチャ読書会(後半) from Mizuki Wada



4.13.1 最大限の先送り
  • XPath ・・・ あいまいにデータを指定できるので、フィールド構造を曖昧にできる。
  • 耐性のあるリーダー by Martin Fowler

4.13.5 複数のサービスバージョンの同時使用
  • 有名なサイト「The Twelve-Factors App」に、2つを直すのはダメ、と書いてある。
  • 4.13.5は、エンドポイントもサービスも両方とも旧新2つをサポートする。
  • それに対し「4.13.4 異なるエンドポイントの共存」は、エンドポイントのみ2つ持ち、サービス自身は1つのみ存在する。



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


各テーブルでディスカッションし、その後いくつかのテーブルでその内容を紹介いただきました。出た意見↓
  • Googleや「駅すぱあと」が公開しているAPIは、URIにバージョンが入っている。
  • インタフェースが変わるなら、バージョンが上がる、というよりも、そもそも別サービスじゃね?
  • メジャーバージョンアップって、そもそも別サービスじゃね?(破壊的変更だし)
  • でも、セキュリティ対策で、Getでクエリパラメータで送っていたのをPostに変えたくらいなら、別サービスにするんじゃなくてバージョンアップだよね。別サービスとは言えなくね?

(つづき)

4.14.5 フロントエンド向けのバックエンド(BFF)


4.15.5 ストラングラー(絞め殺し)パターン
  • ストラングラーアプリケーション by Martin Fowloer
    • 上から下へ根を伸ばしていって、最後に絞め殺す。
  • Isomorphic Survival Guide
    • P.62で、フロントエンドをクライアントとサーバに置いている。
    • 初回はサーバで初期表示を作り、次からはクライアントで初期表示させる。でもサーバとクライアントで言語別だと辛い。



ディスカッション No.4
 ユーザインタフェースの合成、どの手法を使っているか


出た意見↓
  • UIを分けて人を割り当てると、少人数のプロジェクトだとキツイかもしれない。
  • etc


感想


事前に4章は全部読んでから参加したのですが、内容が結構難しくて、あまり理解できないところも多々ありました。
ですが読書会で説明を聞いたりディスカッションすることで、1人で本を読むだけでは理解ができなかった箇所の大半を解決することができました。

お二人の発表者さん、具体例で説明してくださったり、深入りして調べてきた内容を紹介してくださったりと、参加者にわかりやすく説明する姿勢が素晴らかったですね。
参加する前と後で、理解度が雲泥の差です。感謝。

あと、お二人ともスライドの作りというか、絵が個性的でした。
例えば書籍P.53で「コレオグラフィ」をダンスに例え、各サービスがダンスで自分の役割を全うする話が出てきますが、それを説明するスライドは「ダンスの絵」になっていたりw
スライドの内容に合った絵は、内容をイメージ付けると共に、和ませてくれます。

とても有意義で質の高い勉強会でした。関係者の皆様、ありがとうございました。
スポンサーサイト

FC2Ad

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。