精読「マイクロサービスアーキテクチャ 第2版」(第Ⅰ部 基礎 - 第１章 マイクロサービスとは？)
マイクロサービスアーキテクチャ 第2版
マイクロサービスの設計、実装、運用に必要なベストプラクティスや最新技術を解説した、実践的なガイドブックです。これを読めば、マイクロサービスに関してそれっぽい会話もできますよ。
関連記事
マイクロサービスの概要
- ビジネスドメインを中心にモデル化された、独立してリリース可能なサービス
- サービスは機能をカプセル化し、ネットワーク経由で他のサービスからアクセスできるようにする（情報隠蔽[1]の概念を採用している）
マイクロサービスの重要な概念
独立デプロイ可能性
- マイクロサービスの概念で一番重要
- データベースの共有はこれを妨げる最も大きな問題
ビジネスドメインに基づくモデル化
- ドメイン駆動設計[2]と同じ考え方を使って、サービス境界を定義する
マイクロサービスごとの状態の所有
- データと振る舞いをカプセル化すると、ビジネス機能の凝集度が高くなる
- データベースの共有は極力しない
サイズ
- マイクロサービスのサイズは明確な基準はないが、一例としては自分が理解できるサイズに抑えるべき（つまり、人や状況を強く依存する）
- 著者はサイズについて気にしないよう勧めていて、それより①いくつのマイクロサービスを扱うことができるか、②マイクロサービス境界をどのように定義すればすべてが結合した乱雑な状態にならずにマイクロサービスを最大限に活用できるか、この２つのトピックに充填を置くことがはるかに重要だと考える
柔軟性
- 今後直面するかもしれないあらゆる問題を理論的に解決できるようなアーキテクチャが理想
- マイクロサービスは、多くの軸（組織、技術、スケール、堅牢性）で柔軟性を生み、コストに見合う魅力がある
- マイクロサービスの採用は、スイッチを切り替えるというより、ダイヤルを回すこと（ダイヤルを上げ、マイクロサービスを増やせば、柔軟性は高くなる）
アーキテクチャと組織の連携
- 一般的な３層アーキテクチャは、コンウェイの法則[3]が働いている好例で、縦割りの組織では階層を超える変更が発生するときに、より複雑になる
- チームをストリームアラインドチーム[4]にすることで、より変更を容易にできる
コンウェイの法則
ストリームアラインドチーム
モノリス
単一プロセスモノリス
すべてのコードを「単一プロセス」としてデプロイするシステム
- すべてのコードが単一プロセスに埋め込まれる
- ただ、小規模組織では意味をなすアーキテクチャ
- 組織やモノリスが大きくなるにつれて、モジュラーモノリスにつながる可能性がある
モジュラーモノリス
単一プロセスが別々のモジュールで構成されている、単一プロセスモノリスのサブセット
- デプロイするには、すべてを結合する必要がある
- 多くの組織にとって、モジュラーモノリスは優れた選択肢
- うまくやれば[5]、分散マイクロサービスアーキテクチャの課題を回避しながら、高度な並列作業を可能にする[6]
- 課題はデータベースが共通であること
分散モノリス
複数のサービスから構成されているものの、何らかの理由でシステム全体をまとめてデプロイする必要があるシステムのこと
- 分散システムと単一プロセスモノリスの両方の欠点が、利点は十分にない
- 情報隠蔽やビジネス機能の凝集に重点が置かれない環境で現れる
- モノリスだとデリバリ競合[7]の問題に直面しがち
- モノリスには多くの利点[8]があるため、アーキテクチャスタイルとして適切なデフォルトの選択肢とも言える
実現技術
ログ集約と分散トレーシング
ログ集約[9]と分散トレーシング [10]は、マイクロサービスが抱える分散システムゆえのトラブルシューティングの難しさを解決する
コンテナとkuernetes
マイクロサービスをコスト効率よく運用するには仮想マシンよりコンテナが良く、コンテナオーケストレーションプラットフォームとしてKubernetesのようなものを使おう
ストリーミング
マイクロサービスアーキテクチャを使う人々の間では、大量データになることが多いものを簡単にストリーミング[11]して処理できる製品が人気となっている
パブリッククラウドとサーバレス
パブリッククラウドのマネージドサービスを利用することで多くの管理作業を削減できる（特にサーバレスはコードをデプロイするだけなので便利）
マイクロサービスの利点
技術の異種性
内部の技術実装を隠蔽することで、サービスごとに適した技術スタックを選択できる
堅牢性
アプリケーションの堅牢性を向上させる重要な概念はバルクヘッド（隔壁）であり、サービス境界は明らかなバルクヘッドになる
バルクヘッドとは？
バルクヘッドは船にある隔壁を指す。船にバルクヘッドがない場合、ある区画で浸水が発生すると船全体が広がって沈没してしまう。バルクヘッドがあれば浸水が特定の区画に限定され、船全体を守ることができる。
リソースを適切に分離して分散システムのレジリエンスを高める「バルクヘッド」 /
バルクヘッド／ Bulkheadより
スケーリング
必要なサービスだけ効率的にスケーリングできる
デプロイの容易性
モノリスは全体をデプロイする必要があるが[12]、マイクロサービスでは独立してデプロイできる
組織との連携
１つのコードベースで作業する人数を抑え、チームの規模と生産性のスイートスポット[13]に到達できる
合成可能性
マイクロサービスとは、外部の第三者から利用可能なシステムの接合部を公開している状態
マイクロサービスの課題
開発者体験
開発者がローカル環境で複数のマイクロサービスを実行しようとした場合、リソースの制限があり、実行できるサービスの数が限られる
技術の過負荷
マイクロサービスアーキテクチャの導入では、新技術を慎重に選び、複雑さを段階的に高めることで、効率的に開発を進めることが重要
コスト
マイクロサービスアーキテクチャは、短期的にはコストが増加し、主に収益増加を目指す場合に有効であり、コスト削減の手段としては適してない
レポート
データが分散されるためレポートが難しくなり、リアルタイムレポートには新しい技術の採用や、中央データベースへのデータ送信が必要になることがある
監視とトラブルシューティング
マイクロサービスアーキテクチャは複数のプロセスが存在するため、単一のサービスの停止やCPU使用率の上昇の影響を理解することが難しい[14]
セキュリティ
サービス間のデータ転送によるセキュリティリスクが高まるため、データ保護やエンドポイントのセキュリティ強化が必要
テスト
エンドツーエンドテストの範囲が広くなり、テストのコストや信頼性が低下するため、契約駆動テストや本番環境でのテスト、プログレッシブデリバリ技術[15]の導入が必要になる
遅延
以前は１つのプロセッサ[16]上でローカル実行されていた処理が、別のマイクロサービスに分割されることがあるため、ネットワークを介してシリアライズ[17]、転送、デシリアライズを行う必要がある文遅延を悪化させる恐れがある
データ一貫性
データ一貫性を確保するためには、分散システムにおける課題[18]に対処し、サーガや結果整合性などの概念を活用し、漸進的に分解を進めることが重要
マイクロサービスを使うべきか
役立たない場合
特に小規模なチームやスタートアップにおいて、マイクロサービス税[19]を負担するにはリソースが限られているため、アーキテクチャ上の成約となる課題を理解してからマイクロサービスに移行すべき
効果的な場所
システムを柔軟に進化させることができ、急成長している企業やSaaSアプリケーションにおいて、開発者が独立して作業しやすく、スケールや新技術の導入にも対応しやすい利点がある
まとめ
マイクロサービスアーキテクチャは、高い柔軟性を提供するが、その複雑さが正当化されるべきである。適切に理解し実装することで、特に大規模組織は強力で生産性の高いシステムを構築できる
参考
-
コンポーネント内に可能な限り多くの情報を隠蔽し、外部インターフェースを介して公開する情報をできるだけ抑える ↩︎
-
ソフトウェアが動作する実世界のドメインを、うまく表現できるようにコードを構造化する ↩︎
-
システムを設計する組織は、そのコミュニケーション構造をそっくりまねた構造の設計を生み出してしまう ↩︎
-
ビジネスドメインや組織の仕事の継続的な流れ（ストリーム）に沿って構成されたチームで、組織の根幹を担うチームタイプ ↩︎
-
モジュール境界が明確に定義され、より単純なデプロイトポロジーを使うこと ↩︎
-
Shopifyは、マイクロサービス分散の代わりに、モジュラーモノリスをうまく使いこなしている ↩︎
-
一部の変更の影響が想定外の部分へ波及する等 ↩︎
-
単純なデプロイトポロジーにより、分散システムに関する多くの落とし穴を回避できる、開発者のワークフローが単純になりいろんな工程が大幅に簡素化できる等 ↩︎
-
すべてのサービスからログを収集して集約し、ログを分析する中心的な場所を提供する ↩︎
-
複数の差０ビスにわたるトレースを分析し、ボトルネックを検出する ↩︎
-
Apache Kafkaが事実上の標準となっている ↩︎
-
100万行のモノリシックアプリケーションのうち１行を変更したら、その変更をリリースするためにアプリケーションの全体をデプロイする必要があるため ↩︎
-
最適な領域 ↩︎
-
１つのプロセスでCPU使用率100%の状態が続いただけで、午前３時に誰かを起こす必要があるか？ ↩︎
-
新しいソフトウェアを徐々にリリースしながら、リリースに伴う影響を最小限に抑えるソフトウェア開発やDevOps/SREの戦略。カナリアリリースや機能フラグ、A/Bテストなどの技術を組み合わせて、段階的に新機能をリリースする手法 ↩︎
-
実際にデータや命令を処理するハードウェアのこと、またはCPUのこと ↩︎
-
直列化。オブジェクトを一連のビットに変換すること ↩︎
-
複数のプロセスやデータベース間でデータの一貫性を維持することが難しく、従来のトランザクション管理手法がそのまま適用できない点 ↩︎
-
マイクロサービス自体のデプロイ、管理を行うためだけに必要な作業等 ↩︎
Discussion