投稿元:
レビューを見る
マイクロサービスに取り組む上で必要であろうことが幅広く書かれていて、トレードオフを踏まえていろんな方法提案してくれる本。ただし、選ぶのは読者である。近年の流行りものを浅く広くな感じともいえるかもしれないので、流行を学ぶにも使えるかもしれない。DDDなどの前提知識があるとなお読みやすい。Akkaやerlangなどのアクターモデルを考慮するとどうなってくるのか個人的に気になった。
投稿元:
レビューを見る
Thought Works が最新、最高の知見をもって送る、現段階では最高の一冊。
マイクロサービスを実現するための手法をThought Works の過去の様々なプロジェクトや、Antifragile の代表例である Netflix などの事例に照らして解説する。そこには、今まで Thought Works が唱えてきた様々な開発手法(オーガニックなアーキテクチャの成長、「ドメイン駆動」、自動構築、自動テスト、継続的デプロイなどなど)や、設計思想(サーキットブレーカーや行き過ぎない抽象化)、最新のコンテナ技術、オープンソース・ソフトウェア(ごく一部の例を上げれば、Logstash や Consul、Swagger などが紹介されている)が登場し、これらの粋を集めて実現されるマイクロサービスはまさに現段階におけるシステムアーキテクチャの到達点の一つと言っていいだろう。
大量かつ広範囲にわたるデータを必要とするレポーティング・アプリケーションへの対応や、セキュリティの章など、今一つ歯切れの悪い個所も目立たなくはないが、それが今の最新アーキテクチャの限界といったところか。本としては、参考文献(reference)が無いのが痛過ぎる。
投稿元:
レビューを見る
「原則とプラクティスの結合」が参考になります。
多様な技術スタックを駆使して設計したシステムを、具体的にどう実装すれば良いの?というところをハッキリさせよと言っているのかなと解釈しました。
「HTTP上のHMAC」も非常に参考になりました。
最近流行っていて名前だけよく聞いたJSON Web TokenがHMAC(Hash-based message authentication code)に属する技術であることを学習できて、良かったです。
投稿元:
レビューを見る
オライリー本(特に訳本)って苦手なのだけど、ちょうど興味ある内容だったので、ほぼ全部通しで読むことができた。
章ごとにトピックが分かれているので、気になるトピックだけ読むのも可能。
--
マイクロサービス:2週間で書き直せるもの
ひとつのサービス内ではDRYは破らないけど、サービス全体としてはDRYの違反には寛大に対処
ストーリーではなくジャーニーでテストする
--
「実践テスト駆動開発」
投稿元:
レビューを見る
テストの章はとても興味深かったが、原文なのか日本語訳なのかわからないけど、めちゃんこ読みにくかった。
投稿元:
レビューを見る
自分はサービスを分割する粒度やAPIの実装は理解している(つもり)。
通信プロトコルの選定やアクセス権限周りの設計が苦手なのでもっと勉強したい。
投稿元:
レビューを見る
メリットだけでなく、デメリットや適用すべきでないケースもしっかり書かれていて、導入検討時などには良さそう。
投稿元:
レビューを見る
ブログに記載
https://budougumi0617.github.io/2018/06/26/review-microservices-architecture/
投稿元:
レビューを見る
小さいから障害も最小限だし、変更もしやすくデプロイ頻度あがる
各サービスでいろんな技術を使えるし、置き換えも容易になりモダンな環境を維持しやすくなる
スタブやドライバを使い、自分のサービスと連携するサービスとの境界をテストする
連携するサービスの障害から影響を受けないように適切にチェックする。タイムアウト、サーキットブレーカーや監視強化など
投稿元:
レビューを見る
イベント駆動+CQRS、コレオグラフィは依存関係逆転の法則と根本的な考え方は同じで、これまでのアーキテクチャ理解をもって応用可能だと思う。
一方で
SSOゲートウェイへの権限委譲、
冪等性の考慮、
CAP定理を理解した上でのトレードオフ
あたり具体的な実践に使えるところあたりは、これまでのCRUDアーキテクチャの考え方とは異なるところなので、パラダイムシフトが必要だと感じる。
手元に置きながら実践と読み返しを繰り返すことになるであろう一冊。読み応えあり。
投稿元:
レビューを見る
開発効率化の検討のため読んでいますが、マイクロサービス化は思ってた以上に奥が深いです。この本では、マイクロサービスのデザインパターンが定義されています。一口にマイクロサービスといっても、システムに応じた最適化が必要ってことが学べます。
進化的アーキテクチャの考え方が、分かりやすくおもしろかったです。ソフトウェアのアーキテクチャは、建築に例えられることが多いですが、それは誤りだとあります。建築は最終型を不変なものとして設計されるのに対し、ソフトウェアは都市計画に近く、構築しながらも常に目指すものが変わっていく、という考え方。マイクロサービス化は都市の区画整理にあたり、都市が小さい頃は区画整理されておらず、ごった煮の状態なんだけどそれでも機能していて、都市が成長していくどこかのタイミングで、役割ごとに区画整理されていく、みたいな。つまりシムシティってことか。
ちょっとだけ、システム開発の難しさか紐解けた気がしました。(難しいことに変わりはない)
投稿元:
レビューを見る
マイクロサービスアーキテクチャは、現在のシステム設計を行ううえでは、避けて通れない概念であり、本書は、その最初のステップとなるべきだと思う。
以下のような気付きがあった。
・マイクロサービスの粒度をどうするのか?という疑問へのヒントがある。「2週間で書き直せるもの」といった回答も可能である。また、その疑問への回答として、役に立つ概念が「コンウェイの法則」である。それは、「システムの構造は、組織のコミュニケーション構造に倣った構造になる」という法則である。その法則に従えば、どんな組織にも適用する正解はない。その組織構造に従って、マイクロサービスの粒度も変わってくるのである。
・本書では、Netflix社とAmazon社のシステムに関して、よく引き合いに出されている。これらの企業は、マイクロサービスアーキテクチャにおけるトップランナーなのだろう。
本書を読んで、以下のようにしていきたいと思う。
・「2週間で書き直せるもの」をサービス粒度の指針にする、という考え方は、個人レベルのあらゆる作業に関しても適用できるのではないか?ある人はブログは4時間程度かけて一定のものを作るべき、というかもしれない。しかし、1日に4時間もそれに時間をあてられない人は、15分でひとつのブログ記事を書く、というのが正解なのかもしれない。そういった、有名な人がいっていることを自分にそのまま当てはめるのではなく、一旦、自分の生活に置き換えて変換する、ということを行うようにしよう。
投稿元:
レビューを見る
マイクロサービスとしてサービス構築する際に考えなければいけないことを広くまとめていた。内容は「構築にあたってのアーキテクチャをどうするか」だけにとどまらず、デプロイ、テスト、運用体制にいたるまで含まれている。
「新規サービスではいきなりマイクロサービス化は目指さない」、「データベース結合は最悪手段」など、今までのモノリシックな考え方と異なる考え方で、良い面悪い面含めて実業務に当て込まないといけないと感じた。
実務としてDockerやKubernetesで実現するサービスに関わるのであれば、設計イメージを持つために最終章のまとめだけでも読むと良いと思う。
投稿元:
レビューを見る
マイクロサービスがどういうアーキテクチャを指しているのか改めてどう定義されていたりしているのか興味を持ちました。
その為、この書籍からスタートして肉付けをしていこうと思い手に取りました。
内容としては、肥大化したコードベースを分割統治するアプローチに言及していました。
その分割方法やメリット、デメリットについて展開していました。
出版した段階の情報の鮮度と現在の情報鮮度は別で突き合わせる必要があると認識しています。
しかし、大枠の概念や定義について自分の中に落とし込むことができました。
まずは、どんな概念なのかということを押さえたい場合は有用なのかなと思いました。
投稿元:
レビューを見る
マイクロサービスのお勉強。
モノシリックシステムの中では多くの場合、抽象化を行いモジュールを作成することでコードの凝集性がより高まるようにして、修正や実装が困難にならないようにしています。凝集性(関連するコードが集まるようにすること)は、マイクロサービスについて考える際に重要な概念です。…『プログラマがしるべき97のこと』…。この定義では、「変更する理由が同じものは集める、変更する理由が違うものは分ける」としています。
■主な利点
・技術異質性
・回復性
・スケーリング
・デプロイの容易性
・組織面の一致
・合成可能性
・交換可能にするための最適化
SOAは、大規模なモノリシックアプリケーションの課題に有効な手法として登場しました。SOAは、ソフトウェアの再利用性が促進を目指す手法です。
■優れたサービスにするためには
疎結合と高凝集性
■境界づけられたコンテキスト
この考え方は、どのドメインも複数の境界づけられたコンテキストからなり、それぞれの境界づけられたコンテキストには外部と通信する必要のないものと、外部の他の境界づけられたコンテキストと共有されるものがあります。境界づけられたコンテキストには明示的なインターフェースがあり、そのインターフェースが他のコンテキストと共有するモデルを決定します。
私が好きな境界づけられたコンテキストの別の定義は、「明示的な境界によって強制される特定の責務」です。
■オーケストレーションとコレオグラフィ
オーケストレーションでは、オーケストラの指揮者のように中枢部に頼ってプロセスを推進します。コレオグラフィでは、バレエで周りの動きに合わせて自分の動きを決めるダンサーのように、システムの各部分にジョブを知らせ、詳細に対処させます。
…
このオーケストレーション手法の欠点は、顧客サービスが中央監督機関になり過ぎることです。…
一般に、コレオグラフィ手法に向かう傾向が強いシステムの方が、疎結合で柔軟性があり、変更を受け入れることがわかっています。しかし、システム境界にまたがるプロセスの監視と追跡には追加の作業が必要です。
私たち開発者がよく耳にする略語の1つがDRY(Don't Repeat Yourself)です。…DRYのより正確な意味は、システムの振る舞いと知識の重複を回避することです。…
DRYは、再利用可能なコードの作成につながります。
ポステルの法則は、「送信するものに関しては厳密に、受信するものに関しては寛大に」というものです。
■統合まとめ
・いかなる代償を払ってもデータベース統合を避けます。
・RESTとRPCとの間のトレードオフを理解し、RESTをリクエスト/レスポンス統合の優れた出発点と積極的にみなします。
・オーケストレーションよりもコレオグラフィを選びます。
・ポステルの法則を理解して耐性のあるリーダーを使って破壊的変更を避け、バージョンが必要ないようにします。
・ユーザーインタフェースを合成レイヤと考えます。
モノリシックアプリケーションのデプロイは、かなり簡単なプロセスです。しかし、相互依存するマイクロサービスでは全く別の困った事態となります。デプロイは、適切に行わないと複雑になってしまい、悲惨な目に合う分野の1つです。
■デプロイまとめ
まず、サービスを他のサービスとは独立してリリースする機能を維持することに重点を置き、どの技術を選んでもこの機能をサポートするようにします。私はマイクロサービスごとに1つのリポジトリを持つことを大いに好んでいますが、マイクロサービスを別々にデプロイしたければ、マイクロサービスごとに1つのCIビルドが必要だと、より強く確信しています。
次に、可能ならホスト/コンテナごとに1つのサービスに移行してください。可動部の管理をより安価で簡単にするために、LXCやDockerといった代替技術を調べますが、どの技術を採用しても、すべてを管理するには自動化の文化が重要であることを理解してください。すべてを自動化してください。AWSのようなプラットフォームを利用できるようになると、自動化の際に大きな利点となります。
■テストまとめ
・フィードバックが高速になるように最適化し、それに応じてテストの種類を区別します。
・コンシューマ駆動契約を使って、できる限りエンドツーエンドテストが必要ないようにします。
・コンシューマ駆動契約を使用し、チーム間の対話の焦点を提供します。
・テストへのさらなる労力の投入(MTBFの最適化)と本番環境での迅速な問題検出(MTTRの最適化)との間のトレードオフを理解しようとします。
セキュリティにおいては、認証はある関係者が確かに名乗っている本人であることを確認するプロセスです。人に対しては、通常はユーザ名とパスワードを入力させることで、ユーザを認証します。…一般に、抽象的に認証対象の人や物について話すときには、その関係者をプリンシパル(主体)と呼びます。
認可は、プリンシパルとプリンシパルに許されている動作をマッピングするメカニズムです。多くの場合、プリンシパルを認証するときに、私たちはプリンシパルに何を実行させるべきかを判断するための情報を与えられます。
■マイクロサービスの原則
1.ビジネス概念に沿ったモデル化
経験上、ビジネスで境界づけられたコンテキストに基づいて構築されたインタフェースの方が、技術的概念に基づいたインタフェースよりも安定性があります。システムが稼働するドメインをモデル化することで、より安定したインタフェースの構築を図れるだけでなく、ビジネスプロセスの変化を簡単かつ適切に反映できるようにもなります。
2.自動化の文化の採用
サービスが常に正常に動作するように保証するのは、モノリシックシステムよりも複雑なので、自動テストが不可欠です。統一されたコマンドライン呼び出しでどこでも同じようにデプロイするのが効果的であり、これは継続的デリバリを採用して本番品質のチェックインごとにフィードバックを迅速に得るために重要です。
3.内部実装詳細の隠蔽
サービスが他のサービスとは独立して進化する能力を最大化するには、実装詳細を隠すことが不可欠です。境界づけられたコンテキストをモ���ル化すると、共有すべきモデルと隠すべきモデルを調べる上で有効です。また、サービスはデータベースを隠して、従来のサービス指向アーキテクチャ(SOA)で生じる最も一般的な結合の1つに陥らないようにしデータポンプやイベントデータポンプを使ってレポートのために複数のサービスからデータを集約すべきです。
可能であれば、技術非依存のAPIを選んで、さまざまな技術スタックを自由に利用できるようにしてください。そしてRESTの使用を検討してください。RESTは内部実装詳細と外部を正式に分離しますが、たとえリモートプロシージャコール(RPC)を使っていても、この考え方を取り入れることができます。
4.すべての分散化
マイクロサービスが可能にする自律性を最大化するには、サービスを所有するチームに意思決定と制御を委譲する機会を常に追い求める必要があります。これにはまず可能な限りセルフサービスを採用し、必要に応じてソフトウェアをデプロイできるようにし、開発とテストをできる限り容易にし、これらの作業を行うために別々のチームが必要ないようにします。
5.独立したデプロイ
常にマイクロサービスを単独でデプロイできるように努めるべきです。破壊的変更が必要なときでも、バージョン付けされたエンドポイントを共存させてコンシューマが徐々に変更できるように努めるべきです。…
ホストごとに1つのサービスというモデルを採用すると、あるサービスのデプロイが別の無関係なサービスに影響を与える副作用が減ります。デプロイとリリースを分離するブルーグリーンやカナリアといったリリーステクニックの使用を検討し、リリースが失敗するリスクを減らしてください。
6.障害の分離
マイクロサービスアーキテクチャはモノリシックシステムよりも回復性を備えますが、それはシステムの部分障害を把握して考慮した場合に限られます。下流呼び出しが失敗し得るという事実を理解していなければ、システムは破滅的な連鎖障害に見舞われ、以前よりもはるかに脆弱となります。
7.高度な観測性
システムが正しく機能しているかどうかを確認するには、1つのサービスインスタンスの振る舞いや1台のマシンの状態の観察では不十分です。代わりに、何が起こっているかを統合的に見通す必要があります。セマンティック監視を利用してシステムが正しく動作しているかどうかを確認し、システムに合成トランザクションを投入して実際のユーザ動作をシミュレートします。ログと統計データを集約し、問題が起こったときに原因を突き止められるようにします。また、面倒な問題の再現や本番環境でのシステムの対話の確認に関しては、相関IDを使ってシステムへの呼び出しを追跡できるようにします。
■マイクロサービスを使用すべきでない場合
…ドメインの理解度が低いほど、サービスにとって適切な境界づけられたコンテキストを見つけにくくなります。既に述べたように、サービス境界を間違えると、サービス間連携で多くの変更をしなければならなくなります。これはコストのかかる作業です。ドメインを理解していないモノリシックシステムを開発する際は、まずはシステムが担当することの把握に時間をかけ、そしてサービスを分割する前に明��なモジュール境界を特定するようにしてください。
新規開発も困難です。これは、ドメインに対する知識が不足しているだけではありません。存在しないものを分割するよりも、存在するものを分割する方がはるかに簡単です。そこで、やはりまずモノリシックから始め、安定したら分割を検討してください。
マイクロサービスで直面する多くの課題は、大規模になると悪化します。…REAやGiltがしばらく時間を費やしてマイクロサービスを大量に使えるようになった話をしました。これらの話は徐々に始めて変更に対する組織の欲求や能力を理解することの重要性を植え付け、マイクロサービスを適切に採用することができます。