DoorKeeper
https://architect-club.doorkeeper.jp/events/48267
場所は住友不動産新宿グランドタワー14Fです。
参加者は40人くらいでしょうか。
以下の書籍をターゲットとした読書会なのです。
マイクロサービスアーキテクチャ
posted with amazlet at 16.07.17
Sam Newman
オライリージャパン
売り上げランキング: 3,746
オライリージャパン
売り上げランキング: 3,746
今回が3回目ですが、一応これまで全部参加してます。
ウチの部署で開発してるフレームワークがマイクロサービスを意識してたりするので、この本で勉強しようと思った次第なのです。
今回は4章が範囲でした。以下、個人的メモ。
第4章前半： @tenten0213 さん
4.1.1 破壊的変更を回避する
- JAX-RSのObject Mapperの設定で、未定義のプロパティがあっても無視する設定を入れておく。
4.1.4 内部の実装詳細を隠す
- case文やif文でサービスをスイッチさせるのは辛い・・・
4.3 共有データベース
- DBスキーマ変更のタイミングでコンシューマ側を壊してしまう可能性がある。
- ロジックが分散して凝集性と疎結合が失われる。
4.5 オーケストレーションとコレオグラフィ
- 図4-3のオーケストレーションの例で、顧客サービスは「神サービス」と呼ばれることがある。
- 神サービス ＝ 各サービスのハブとなるサービス
- 命令されたことだけやるサービス ＝ ドメイン貧血症のCRUDサービス
- コレオグラフィ = 各サービスが、顧客作成イベントを購読(subscribe)している。
- ビジネスプロセスがシステムに暗黙的になってしまう。
- 各サービスの監視が必要。
- 監視をするプロダクトの例
- 読書会主催者の川島さんの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 非同期アーキテクチャの複雑さ
- 壊滅的フェールオーバー by Martin Flowler
ディスカッション No.2
マイクロサービスアーキテクチャに適用するならどっち？ - リクエスト/レスポンス
- イベントベース
テーブルごとにディスカッションし、いくつかのテーブルに発表いただきました。出た意見は↓
- リクエスト・レスポンスでも非同期にできる。イベントベースも非同期。なので使い分けは場合によるのでは。
- 2択を出しつつも、両方とも使うんじゃないの。
- マイクロサービス間は「イベントベース」にして、クライアントからの呼び出しはRESTで「リクエスト/レスポンス」にする。
- 両方を同居させてマイクロサービスを作るのかなぁ。
- 非同期でもリクエスト/レスポンスはできる。
（つづき）
4.10 Rx（Reactive Extentions）
- Rx実装の例
第4章後半： @syobochim さん
4.13.1 最大限の先送り
4.13.5 複数のサービスバージョンの同時使用
- 有名なサイト「The Twelve-Factors App」に、２つを直すのはダメ、と書いてある。
- 4.13.5は、エンドポイントもサービスも両方とも旧新２つをサポートする。
- それに対し「4.13.4 異なるエンドポイントの共存」は、エンドポイントのみ２つ持ち、サービス自身は１つのみ存在する。
ディスカッション No.3- 現場で「バージョンが必要ないように」って実現してますか？
- まだしてない人は、どうすればいいと思いますか？
- サービスとコンシューマ間の情報共有で何か工夫していますか？
各テーブルでディスカッションし、その後いくつかのテーブルでその内容を紹介いただきました。出た意見↓
- Googleや「駅すぱあと」が公開しているAPIは、URIにバージョンが入っている。
- インタフェースが変わるなら、バージョンが上がる、というよりも、そもそも別サービスじゃね？
- メジャーバージョンアップって、そもそも別サービスじゃね？（破壊的変更だし）
- でも、セキュリティ対策で、Getでクエリパラメータで送っていたのをPostに変えたくらいなら、別サービスにするんじゃなくてバージョンアップだよね。別サービスとは言えなくね？
（つづき）
4.14.5 フロントエンド向けのバックエンド（BFF）
- 主催者の川島さんのQiita： マイクロサービスアーキテクチャにおけるAPIコールの仕方とHTMLレンダリング
4.15.5 ストラングラー（絞め殺し）パターン
- ストラングラーアプリケーション by Martin Fowloer
- 上から下へ根を伸ばしていって、最後に絞め殺す。
- Isomorphic Survival Guide
- P.62で、フロントエンドをクライアントとサーバに置いている。
- 初回はサーバで初期表示を作り、次からはクライアントで初期表示させる。でもサーバとクライアントで言語別だと辛い。
ディスカッション No.4
ユーザインタフェースの合成、どの手法を使っているか
出た意見↓
- UIを分けて人を割り当てると、少人数のプロジェクトだとキツイかもしれない。
- etc
感想
事前に4章は全部読んでから参加したのですが、内容が結構難しくて、あまり理解できないところも多々ありました。
ですが読書会で説明を聞いたりディスカッションすることで、1人で本を読むだけでは理解ができなかった箇所の大半を解決することができました。
お二人の発表者さん、具体例で説明してくださったり、深入りして調べてきた内容を紹介してくださったりと、参加者にわかりやすく説明する姿勢が素晴らかったですね。
参加する前と後で、理解度が雲泥の差です。感謝。
あと、お二人ともスライドの作りというか、絵が個性的でした。
例えば書籍P.53で「コレオグラフィ」をダンスに例え、各サービスがダンスで自分の役割を全うする話が出てきますが、それを説明するスライドは「ダンスの絵」になっていたりｗ
スライドの内容に合った絵は、内容をイメージ付けると共に、和ませてくれます。
とても有意義で質の高い勉強会でした。関係者の皆様、ありがとうございました。
- 関連記事
-
- 「エンタープライズアジャイル勉強会 2016年7月セミナー」に参加しました
- 「第3回 マイクロサービスアーキテクチャ読書会 #MSA読書会」に参加しました
- NaITE #15「えくす・でぃ・でぃ・ぴぃ概論＆入門ワークショップ」に参加しました
