ステップ 2: チームを正しく編成する

ここまでは、マイクロサービスの構築はほとんど技術的な問題のように見えたことでしょう。たとえば、コードベースを複数のサービスに分割し、故意に失敗してネットワークの問題から回復するための適切なパターンを実装し、データの一貫性を確保し、サービス負荷を監視する必要がある、などです。把握するべき新しい概念がたくさんあります。しかし、無視してはならないのは、チームの編成方法を再構築する必要があるということです。

コンウェイの法則は真実であり、あらゆるタイプのチームで観察されます。ソフトウェア チームがバックエンド チーム、フロントエンド チーム、運用チームで編成されて、それぞれが独立して作業している場合は、フロントエンドとバックエンドのモノリスが別々に作成されて大したコミュニケーションもないままに運用チームに渡され、本番環境に移ります。このタイプのチーム構造はマイクロサービスには適していません。なぜなら、各サービスは独自の製品として扱われて、他のサービスとは独立してリリースされる必要があるためです。

代わりに、担当しているサービスの開発と維持に必要なすべての能力を持つ、小規模な DevOps チームを作る必要があります。この方法でチームを編成するのには、大きなメリットがあります。まず、開発者が本番環境におけるコードの影響をより深く理解します。これによって、より質の高いリリースが作成されて、問題が顧客にリリースされるリスクを軽減できます。次に、コードの改善とデプロイ パイプラインの自動化にすべてのチームが一緒になって取り組むため、各チームが当然の習慣としてデプロイを行うようになります。

ステップ 3: モノリスを分割してマイクロサービス アーキテクチャを構築する

サービスの境界を特定してチームの再構築方法を理解したら、モノリスを分割してマイクロサービスの構築を始められます。その時に考える重要なポイントは次のとおりです。

RESTful API でサービス間の通信をシンプルに保つ

まだ RESTful API を使用していない場合は、今が採用の好機です。Martin Fowler は、ユーザーには「賢いエンドポイントと愚直なパイプ」が必要と説明しています。つまり、データを変換せずに送信するだけなど、サービス間の通信プロトコルはできる限りシンプルでなければなりません。魔法はエンドポイント自体で起こります。エンドポイントはリクエストを受け取って処理し、回答を返します。

マイクロサービス アーキテクチャは、コンポーネントの緊密な結合を避けるためにできるだけ物事を単純に保とうとします。場合によっては、非同期メッセージベースの通信でイベントドリブン アーキテクチャを使用していることがあります。しかし、もう一度 RabbitMQ のような基本的なメッセージ キュー サービスを調べて、ネットワーク経由で送信されるメッセージが複雑にならないようにする必要があります。

境界づけられたコンテキストまたはデータ ドメインにデータを分割する

モノリス アプリケーションは、アプリケーションのすべてのビジネス機能に対して単一のデータベースを使用します。モノリスをマイクロサービスに分割すると、この単一のデータベースはもはや意味をなさない可能性があります。中央データベースは、増加するトラフィックのボトルネックになる可能性があります。特定のサービスがデータベースに高い負荷をかけると、他のサービスがデータベースにアクセスできなくなる場合があります。さらに、複数のチームが同時にスキーマを変更しようとすると、単一のデータベースがコラボレーションのボトルネックになる可能性があります。したがって、マイクロサービスのデータ ニーズに対応するには、データベースの分割やデータ ストレージ ツールの追加が必要になる場合があります。

モノリシック データベース スキーマのリファクタリングは、デリケートな操作になる可能性があります。各サービスに必要なデータセットと重複するデータセットを明確に特定することが重要です。このスキーマ プランニングは、ドメイン駆動設計のパターンである境界づけられたコンテキストによって実行できます。境界づけられたコンテキストは、システムへの入出力情報を含む自己完結型のシステムを定義します。

このシステムでは、ユーザーが注文にアクセスする際に顧客情報を確認するのと同じテーブルから、請求システムで管理される請求書にデータを入力できます。これは論理的で単純に見えますが、マイクロサービスでは発注システムがダウンしていても請求書にアクセスできるように、これらのサービスを分離する必要があります。これによって、請求書テーブルを他のテーブルとは無関係に最適化または進化できます。つまり、各サービスが必要なデータにアクセスできるようにするために、それぞれ独自のデータストアを持つことになる可能性があります。

これによって、一部のデータがデータベース間で重複するために新たな問題が発生します。境界づけられたコンテキストによって、共有または重複データを処理するための最適な戦略が見つかります。イベントドリブン アーキテクチャを採用すれば、複数のサービス全体でデータを同期できます。たとえば、顧客が個人情報を更新した際にアカウント サービスから発生するイベントを請求と配達追跡の各サービスでリッスンするようにします。これらのサービスは、イベントを受信するとそれに応じてデータストアを更新します。このイベントドリブン アーキテクチャでは他のすべての依存サービスは理解不要なため、アカウント サービス ロジックをシンプルに保てます。サービスは実行した内容を単にシステムに伝えて、他のサービスはそれをリッスンして必要に応じて動作します。

また、すべての顧客情報をアカウント サービスに保存して、外部キー参照のみを請求と配達サービスに保持できます。その後、既存のレコードを複製する代わりに、アカウント サービスとやり取りして関連する顧客データを取得できます。これらの問題に対する普遍的な解決策はないので、それぞれの特定のケースを調べて何が最良のアプローチかを判断する必要があります。

障害に備えたマイクロサービス アーキテクチャの構築

どのようにマイクロサービスがモノリシック アーキテクチャよりも大きなメリットを実現できるかを見てきました。サイズが小さく機能が特化されたマイクロサービスは、分かりやすさも突出しています。マイクロサービスは切り離されているため、システムの他のコンポーネントを壊したり他のチームの開発を遅らせたりするのを恐れることなく、サービスをリファクタリングできます。また、他のサービスのニーズに制約されることなく必要に応じてさまざまなテクノロジーを選択できるため、開発者の柔軟性が高まります。

要するに、マイクロサービス アーキテクチャを持つことで、各ビジネス機能を簡単に開発して維持できるようになります。しかし、すべてのサービスを俯瞰してどのように相互作用させればアクションを実行できるかを考えると、物事はより複雑になります。システムには複数の障害点が存在し、それに対応する必要があります。サービスが応答しないケースについて考えるだけでなく、ネットワーク応答の遅延に対処できる必要があります。障害からの回復も時には難しい可能性があります。復旧後に稼働したサービスが保留中のメッセージによってフラッディングしないようにする必要があるためです。

モノリシック システムから機能を抽出し始めるときは、最初から障害を考慮した設計になっていることをご確認ください。

マイクロサービスのテストを容易にするために監視を重視する

テストは、モノリシック システムと比較した際のマイクロサービスのもう 1 つの欠点です。単一のコードベースとして構築されるアプリケーションは、テスト環境を稼働させる必要はそこまでありません。ほとんどの場合、テスト スイートを実行できるようにするには、データベースと一体化されたバックエンド サーバーを起動する必要があります。

マイクロサービスの世界では、物事はそんなに簡単ではありません。ユニット テストに関しては、モノリスとあまり違いがなくそれほど難しくありません。しかし、統合とシステム テストに関しては、物事は遥かに難しくなります。複数のサービスをまとめて起動して、さまざまなデータストアを稼働させなければならない場合があります。また、モノリスでは不要なメッセージ キューをセットアップに含めなければならない場合があります。このような状況では、機能テストの実行には遥かにコストがかかります。不確定要素の数が増えると、起こり得るさまざまなタイプの障害を予測することは非常に困難になります。

監視によって、問題を早期に特定して適切に対応できます。さまざまなサービスの基準を理解することで、サービスがダウンしたときだけでなく予期せぬ動作をしているときにも反応できるようにする必要があります。マイクロサービス アーキテクチャを導入するメリットの 1 つとして、システムが部分的な障害に対して耐障害性があることがあげられます。これによって、Pizzup アプリの配達追跡サービスに異常が見え始めても、モノリシック システムほど悪い状況には陥らないでしょう。アトラシアンのアプリケーションは、他のすべてのサービスが適切に反応することで、ライブトラッキングを復元しながら顧客からのピザ注文を受け付けられるように設計する必要があります。

継続的なデリバリーを活用してデプロイの摩擦を軽減する

モノリシック システムを本番環境に手動でリリースすることは面倒で危険な作業ですが、できることです。もちろん、このアプローチはお勧めしません。すべてのソフトウェア チームがあらゆる種類の開発で継続的なデリバリーを活用することを推奨しますが、プロジェクトの開始時にはコマンド ラインによって最初のデプロイを自分で行う場合があります。

1 日に複数回デプロイする必要があるサービスの数が増えている際は、このアプローチは持続可能ではありません。したがって、マイクロサービスへの移行の一環として、リリース障害のリスクを軽減するために継続的なデリバリーを活用して、さらにチームがアプリケーションのデプロイに立ち往生するのではなく、アプリケーションの構築と実行に集中できるようにすることが重要です。また、継続的なデリバリーの実践は、本番環境への移行前にサービスが受け入れテストに合格したことを意味します。もちろんバグは発生しますが、時間の経過とともに堅牢なテスト スイートが構築されて、リリースの品質に対するチームの自信が高まります。