Tsuyoshin blog

所属団体とは関係なく、個人的なblog

マクロサービスアーキテクチャを数回読んだ

はじめに

今でも割と語られてるかな?マイクロサービスアーキテクチャを数回は読んだ。まぁそのアウトプットではないが色々と思うところやメモ的なものをここに残しておく

マイクロサービスアーキテクチャ

マイクロサービスアーキテクチャ

各章ごとに気になった文や内容を自分なりにまとめていこうと思います

1章:マイクロサービス

まぁマイクロサービスとはいかなるものか的な内容。その中でも今までとは違う点では下記あたりがあるのかなぁと感じた

  • より多くの技術的な決断を下さす必要がある点
  • すべて正しい決断となるわけではないが、たとえ間違えたとしても影響は局所的になる

2章:進化的アーキテクト

マイクロサービスアーキテクチャに限った事ではないけど、アーキテクトが日進月歩なので変化は激しい。その中で一番気をつけなければいけないのは考え方を固定化させ硬直する事。これは常に自分が間違っているかもしれないという問いを自分自身に問いながら進まなければいけない事を意味する。

スタートアップで事業を立ち上げる立場にある人は割と当たり前だし、その姿勢をシステム設計にも適用しなければならないという事を改めて感じた。

3章:サービスのモデル化方法

  • 技術的な概念に基づいたモデリングよりビジネス的なサービスによって境界づけられたモデリングのが適している

またモデリングによる分割が時期尚早な場合が存在する。特にスタートアップ時期ではまた固まりきらない事業フェーズ(ビジネスサイドでよく言うフィジビリ時期)の時とかは注意なのかな

4章:統合

ここは結構内容の重い話が多かったと思う。まずは

  1. いかなる代償をはらってもデータベース統合は避ける

今までの経験上、データベースのテーブルスキーマの変更を伴う改修はやっぱり気を使うし、それなりにパワーを消費するのでちょっと避けてる部分があった。でも変化を受け入れ、柔軟に対応する上ではこのあたりも受け入れてやっていかないとなと感じた

でも弊害というかそれぞれで分割されたデータベースを持つということは独立性を高め、変更を恐れなくなるとは思うけど。同じ内容のデータを複数持つことになったり、データベース間で同期をとりたい場合やトランザクションで整合性をとりたい場合はでてくるよなぁー。

そうなると共有のライブラリ(API)でデータの更新や参照するような仕組みは完璧に補えるわけではないけど案として浮かぶ。

このへんは本でも指摘されてるけど今まではDRY(Don't Repeat Yourself)という言葉があるように重複するコードを書くことは必要以上にコードが増え、可読性も落ちて良くないとされてきた。けどマイクロサービスでは同じマイクロサービス単位内ではDRYだけど、別の境界づけられたサービスではokという事だった。

むしろ、結合を産んでしまうので同じライブラリだが、それぞれ独立して持つべきという感じ。1つのマイクロサービスは1つの独立した会社として見た方が腑に落ちるかも

次に

  1. オーケストレーションよりコレオグラフィ

音楽で言うところの指揮者がいてオーケストラによる演奏とコレオグラフィ(振付け師)による舞台みたいな対比

少々概念的な話で

  • オーケストレーションは、中央の指揮者が他のサービスを呼び出し等を行い処理する動き
  • コレオグラフィはそれぞれのサービスが自律的に動き、他のサービスに働きかけていく感じ

まぁSVNとGitみたいな感じかな。でも全てコレオグラフィに寄せることはできないので思考としてそう持つべきという内容と理解

次に

  1. ポステルの法則(英語: Postel's law)

ジョン・ポステル - Wikipedia

送信するものに関しては厳密に、受信するものに関しては寛容に

なんかこの言葉だけでとてもしっくりきてしまった。今のAPIを活用したクライアント実装はすでにこれだなと。

5章:モノリス(一枚岩)の分割

ここでも改めて思ったけど、データベースの分割はむずいなーと感じた。サービス(ビジネス)モデルに基づいた分割が全然理解できてないんだろーなー。

本の中でもトランザクションがが必要な時は、キューやログファイルを使い後でリトライの仕組みを裏で幾つか持ち、結果整合性(eventual consistency)で保つことと。。。

むしろお手間な感じがしてしまった。

ここは結構いろいろな意見があるだろうし判断に難しいところなので本でも下記のような言い方をしてた

本当に一貫性を維持したい状態に遭遇したら、まずは分割を避けるためにあらゆる手を尽くします。本当に精一杯やってみてください。本当に分割を進める必要がある場合にはそのプロセスの完全に技術的視点から離れ、トランザクション自体を表す具体的な概念を実際に作成してください

やり尽くした上での選択なんだろう。

あとはデータポンプ、イベントデータポンプといったワードも出てきてETLと呼ばれるような手法も活用すべきだと。

ETLで思い浮かぶのはtalendとかかな。。。

jp.talend.com

6章:デプロイ

ここでは改めて自動化重要性を感じた。インフラのイミュータブルサーバの話から、アプリケーションのビルド、各種自動テスト等々本当にどれもスキップできない構成がある中で効率的に且つ何度も回す必要があると。

7章:テスト

まずはモックとスタブの違いはわかりづらく、ここをしっかり抑える必要がる。

  • モックとは

    • ユーザーインターフェイスの振る舞いを模倣したもの。。。。個人的な理解でいうと、例えばPHPUnitgetMockBuilderというメソッドがある。まぁこの振る舞いをモックと理解している getMockBuilder
  • スタブとは

    • テスト時の呼び出し時にあらかじめ用意された結果を返す。通常はテスト用にプログラムされたところ以外では使わない。接続先のサービス(API)のインターフェースが変われは追随する必要がある

原文を一応あげておくけどMartin Fowlerの説明はちょっと分かり難い?英語の問題もあるけど。 martinfowler.com

必然的に疎結合が多くなるのでテスト時はスタブ化してテストしてくことは必須でThoughtWorks社から便利なツールが色々ある様子

あとはE2Eテストの存在がある。今のチームでもE2EテストではCapybaraを試してみてるが、やはりメンテコストが結構かかる。でもやらないわけにはいかないし、メンテして1日終わってしまう事もある。

ここで初めて複数のチームが共有所有する事がベストプラクティスではないかとある。今まで独立性、自律性に重きを置いた思考であったが、E2Eテストに関しはちょっと違う。

次に

ここは具体的な方法をもっと知りたいなぁー。会社によって色々とやり方あり出し。そーいやリーンスタートアップってゆう本にもこのワード出てきてた。

リーン・スタートアップ

リーン・スタートアップ

すべて完璧な状態でリリースは結構難しくて、平均故障間隔と平均修復時間のメトリックスを気にしながら絶妙なバランスが必要。そのサービスが担う役割によって当然話は変わってくるけど基本的にこのトレードオフの関係を理解しておくこと

8章:監視

  • 相関IDを活用

サービスの疎結合と高凝集性があるので障害・不具合が出てきた時に追いかけて、特定しづらくなる。そこで相関IDを活用して効率化を図る

  • 合成監視

一般的なCPUやメモリのメトリックではわからない。偽イベントを生じさせてそこから得られる結果からシステムが正常に稼動しているかを推し量る考え方でセマンティック監視とも呼ばれるみたいです。この観点は今まであまりなかったのでプロダクトに生かしたいなと。

9章:セキュリティ

境界内のアクセスに対するセキュリティはほぼなく、暗黙的に信頼のもとにできている

ここで出てくるセキュリティの項目は割と一般的な項目であり、様々な役割のサービスごとに最適なセキュリティ対策を実施すべし。ですべてにおいて厳しいセキュリティ項目を設けなくとても良い。

  • 間違っても自分で暗号化実装をしてはならぬ

間違っても手を出しません。

10章:コンウェイの法則とシステム設計

ここはなかなか重い話だなぁ。結局はソフトウェアは人が作るし、運用していくのは人、組織であるからコンウェイの法則はまぁその通りと思う

でも逆向きのコンウェイの法則の話があったけど、業態のパラダイムシフトが必須の状態が追い風となってると思う。こう言ったものがセットでないとなかなか厳しいなぁと感じた。

会社によってシステムアーキテクチャがどの程度の発言権があるかによるが、日本の場合は当事者がファンダーとかでない限り、この考えを浸透させるのは厳しいだろうな。

システムアーキテクトと組織構造がセットで、その2つを一致させないとツライという話。。。想像しただけでもツライよね。

11章:大規模なマイクロサービス

  • Swaggerの話が出てきてふと社内勉強会の内容を思い出した。下記です。ちょっと点が繋がった

www.slideshare.net

  • CAP定義

整合性(consistency)、可用性(availability)、分断耐性(partition tolerance)があり、トレードオフの関係値になっている。頭文字をとってAP,CPシステムという感じになりケースバイケースで判断していく

本書を読んでのまとめ・感想的なもの

  • 何度読み返したかわからないけど、今回この本を読んで残ったものはコンウェイの法則,DBの分割(整合性の分割)の部分かなぁ。ムズすぎ。
  • DBの分割はコストもかかるし、かなり慎重にすべきだなぁー
  • 会社ってどこもセールスの人がいてそれなりの営業的な文化がある
    • よくその文化の中の文脈で一枚岩というワードが出てきてone for all的にチームとして頑張ろうという流れがある。別に普通に賛成なんだが、たまにその事がモノリスの弊害のようになってて、逆に効率が悪いというかってゆう場面を思い返した。協調性がないって思われそうだから何も言えないけど。そーゆー落とし穴は誰かが気をつけなければいけない。
  • 自律的なチームはまさにそうで、専門性をどんどん高めていかないといけないし、どうしてもモクモクとやる姿が多くなっちゃうよなー
  • 他の手法、考え方でもそうだけど、決して銀の弾丸ではない