全体の感想モノリスとマイクロサービスの比較から始まり、どのようにマイクロサービスに移行していくか、設計や実際の運用する上での話などが一通り網羅されていて、全体感を掴めました。一方で、個別の細かいレベルでのツールや技術の選定や導入、運用方法は別途学ぶ必要があると思います。マイクロサービスの導入によって生まれる課題も想像以上にあるので、安易に流行ってるというだけで導入するのは危ないなと思いました。マイクロサービスやってるバックエンドエンジニアには前提となる知識が網羅されていて、必読な感じの本に思えました。マイクロサービスの経験のないチームで導入の検討をしているときは特に参考になると思います。今回は英語版を読んだのですが、いつもの5倍前後ぐらい時間がかかった気がします。効率がかなり悪かったので、今後は暇な時期か日本語版がないときだけにしようかと思います。最後に次のアクション概要、気になったところ前提として、私はマイクロサービス歴は数ヶ月で、モノリスでの経験も中規模程度で、モノリスでかなり苦しんだ経験もないです。その中で、気になったところを中心にまとめました。銀の弾丸などないマイクロサービスも良いところばかりでないので、考慮した上で導入すること。不正確な比較よく建設の設計者に例えられるが、ソフトウェアエンジニアは歴史が浅く、何か明確になるような比較対象を求めがちだが、役割に誤解を招いて幅を狭めるのでよくない。進化するアーキテクト像もし例えるなら、市の設計者が適切である。市は外部の影響を受けるし、長期的な時間を見越してみんながハッピーになれるよう考える必要がある。地域や、インフラ整備なども似ている。区画指定zone間でのやり取りに気を配るべき。zone内での技術等はzoneに任せるべき。原則に基づいたアプローチビジネス的な戦略を把握する考える形では、アーキテクトは関わらないことが多い。偉大なソフトウエアは偉大な人から生まれるので、人を育てるのは重要。マイクロサービスはモノリスよりもサービスのライフサイクルや成長を自主的に把握しやすいので、相性がいい。技術だけしか興味を持ててないのは、成長の半分にしか貢献できてない。優れたサービスにするには各サービスが他のサービスとの調整なしに、独立してデプロイでき、影響範囲を局所化するために、疎結合と高凝集性が重要。境界づけられたコンテキストDDDなどを参考に、ドメインを切り分けていく。一気にサービスを独立させるのではなく、まずはモノリスでモジュールレベルで分解して検討していく。誤ってサービスを切り分けると開発コストがよりかかるため、モノリスで十分様子を見てからサービスを独立させる。共有データベース以下の理由からアンチパターン。オーケストレーションとコレオグラフィオーケストレーションだとシンプルだが、それぞれのレスポンスを束ねる神サービスができて、密結合になりがちもう一方では、それぞれの処理を各サービスに委譲できて疎結合サービスになるが、全体で適切に処理が行われたか監視しないといけない。バージョニング原則として、破壊的な変更はなるべく行わないこと。Readerを使って変更に強くする。protobufでネームスペースを使うと、変更がないバージョン変更が辛いので、オススメしない。サードパーティソフトウェアとの統合カスタマイズベンダーの提供するカスタマイズを行うには、スクラッチで作るよりもコストがかかりうる。ベンダー側に合わさせるのではなく、ベンダーに合わせる。アップグレードで動かなくなることも多々ある。CMSの例カスタマイズしようとして、秘伝のCSSなどができがち。コンテンツの取得、更新をAPI経由で行い、フロントエンドは自前で対応するとよい。CRMの例CRMは社内の組織に大きく影響を及ぼし、後々に肥大化する。CRMのサービスは何でも対応できて、巨大で一つに集約されてしまう。facadeパターンで、ドメインの関心ごとにサービスをつくり、外部からはシンプルなインターフェースで使えるようにする。レガシーなサービスとの共存リプレイスや機能削除を行おうにも、どこが使われてるか不明で、進めにくい。他のパターンと同様に中間のサービスを用意して、直接参照しないようにする。徐々にリプレイスもでき、ビッグバンリリースを避けれる。全体としては以下の順に進める。例:外部キー関係の削除DBは別々にして、API経由で参照する。パフォーマンスが低下するかもしれないが、トレードオフなので、どれだけパフォーマンスが求められるか考慮する。外部キー制約が失われるが、別のサービスで監視するなどの工夫が必要。データを本当に削除してもよいかなどの挙動の取り決めも必要。例:共有データ別々のサービスが同じデータを参照する場合は、そのデータのサービスを別途切り分ける。例:共有テーブル列の多いテーブルはそれぞれのサービス毎に縦に分割する。データベースリファクタリング他の例はデータベース・リファクタリングを読むべし。トランザクション境界DBが分割されると、整合性を保つのに工夫が必要。あとでリトライして、結果整合性を担保するロールバックを実現するために、delete文を発行する分散トランザクション上述の方法だと、複雑なものに対応できなくなる。2段階コミット1段階目でそれぞれのDBでコミットできるか確認する2段階目で全てokなら実際に各DBで実行し、NGなら実行しない1つでも障害が起こると死んでしまうなどの欠点がある。デプロイサービス毎にリポジトリを分割すべき。パターンでは、ユーザ名・パスワードをセキュアに管理する必要があり、そこが厳密には難しい。サービス間をHTTPSで通信を行う場合には、それぞれのサーバのSSL証明書を用意する必要がある。境界内のすべてを許可する一旦ネットワーク内に侵入されてしまうと、中間者攻撃を防げないので、あまりよろしくない。HTTP(S)ベーシック認証HTTPの場合は、ベーシック認証の情報がセキュアでないため、基本的にはHTTPSで行うべき。節約する不必要なデータを削除することは、データを盗まれる可能性を減らす上に節約につながる。逆コンウェイの法則の事例等が紹介されていた。大規模なマイクロサービスマイクロサービスで、扱うサーバやノードが増えれば増えるほど、問題の起こってる状態は増える。GoogleやNetflixでは、自らエラーを発生させてシステムが動き続けるかどうかの確認を行なっている。アンチフラジャイルな組織ハードウェアやネットワークに問題が起こる前提で、反脆さに強い分散システムをつくる必要がある。タイムアウトを適切に設定することサーキットブレーカータイムアウトや5xxエラーが増えた時に、サービス間の通信を遮断して即座にエラーを返すようにする仕組み。遮断している間に、少しだけリクエストを送って回復したかを検知して、回復したは復旧する。「一貫性(Consistency)」「可用性(Availability)」「分断耐性(Partition-tolerance)」の3つを同時に完璧に満たすのは不可能だという定理。分散システムにおいては、分断耐性を犠牲にすることはできない。そのため、通信の遅延が起こった際に、システムの要件に応じて一貫性と可用性のトレードオフのバランスを取ることが求められる。動的サービスレジストリ下記のサービスが紹介されていた。最後にマイクロサービスにすることは、決断ではなく旅のように長くコツコツやっていくつもりで対応すること次のアクション概要はわかった気にはなれたので、サービス運用しながら学んでいこうと思います。サービスの切り分けや、サービス間のデータの整合性の保ち方などは特にもう少し深堀りたいなと思います。マイクロサービスの課題も少しは掴めたので、k8sで何を解決しているのかをもう少し理解したいと思います。」を読んだ「ベゾス・レター:アマゾンに学ぶ14ヵ条の成長原則」を読んだ月別アーカイブはてなブログをはじめよう!hacking15dogさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。