マイクロサービスの旅で得た経験を共有する

数年前より、様々な実践者がマイクロサービスを採用するようになるにつれて、その学んだ教訓を紹介しようとしてくれている。ソフトウェアエンジニアであるPiotr Gankiewicz氏も、マイクロサービスへの旅に乗り出しており、これまでに学んだいくつかの教訓を今まさに共有しようとしてくれている。もちろん、あらゆる経験と同様に、そのすべてがあなた自身の努力に直結するわけではないが、それでも知る価値はある。Piotr氏は

それほど遠くない昔に、マイクロサービスの世界に飛び込むことにしました。私は長い間、このアーキテクチャパターンを適用する機会を探り、ついにそうすることができました。新しいことに挑戦し、自分自身で（苦労しながら）学んできた三ヶ月が経った今、私の経験を分かち合う良い機会だと思っています。

と言う。氏はAPIマネジメント（ゲートウェイ）を含む、いくつかの中核的なシステムの設計的側面をおさえることからはじめ、「サービスバス（Service Bus）」の概念を、それを厳密に定義することなくストレージサービス（Storage Service）を説明に加えて紹介する。

[...] 読み取り専用データベース（CQRSはここに詰め込む）にオブジェクトを保存するには、UserCreated、InvoicePaidなどのあらゆる種類のイベントを購読する必要があります。そして、特定の（マイクロ）サービスと対話し、データを取得してデータベースに保存する必要があります。先のシナリオでは、あなたのAPIはイベントを購読し、データをマッピングし、データベースに保存することに責任を負うようになります。違いますか？ほとんどの場合、これではだめです。私はマイクロサービスでのAPIの完全な分離である後述の解決方法を好みます。それは、イベントを購読し、（マイクロ）サービスからデータを取得し、オブジェクトをフラット化する方法を知っている、いわゆるストレージサービスを用います。APIはデータを取得するためにストレージサービスへのHTTPリクエストを実行するだけで済みます。また、それがどの内部データベースやキャッシュ、または世界の果てにあるサービスからのものであるかどうかは全く気にする必要がありません。

最後に、氏が学んだ教訓（氏は「ヒントとコツ」と呼ぶ）を提示する前に、サービスの定義とともに設計的側面を結論づける。その一部には次のものが含まれる。

各（マイクロ）サービスは、独自のドメインモデル、リポジトリ、ビジネスロジックなどを持っています。インフラストラクチャ全体で共通するのは、サービスバスと一連のコマンドとイベントだけです。

ヒントやコツには、以降のいくつかの点が含まれている。まず最初は、マイクロサービスにとってサイズが重要であると信じる人たちに向けた「サービスは小さく保たなくてはならない」というものだ。

まったく異なるタスクを実行し、同じスコープで無関係の責務を管理する肥大化したマイクロサービスよりも、単一のドメインに重点を置く小さなマイクロサービスを多数持つ方がよいでしょう。 最も一般的な例は、ユーザーアカウントの作成/検証、メッセージの送信、製品の管理、支払いの処理などです。各ドメインは、独自のエンティティを持つ別個のサービスに適合します。

マイクロサービス、イベントソーシング、CQRSについて他の人たちが述べるように、Piotr氏もCQRSは非常に重要だと考えている。

戻り値のないコマンドを送信し、冪等なクエリを実行します。これはCQRSに従うということです。このパターンに準じれば、読み書きの操作を分けるだけで、アプリケーションをスケールすることがはるかに簡単だとすぐに知ることができます。

次に、データの話題に戻って、当該のサービスのデータベースを選択することは非常に重要であるということだ。これは他の人たちの間でも議論されてきたことである。

（単一のインスタンスではなく、異なるノード上で実行される同じサービスの多数のインスタンスが存在する可能性がある）各サービスには、独自のデータベースが必要です。単一障害点（システム全体の単一の巨大なデータベース）を排除するだけでなく、最も重要なことに、特定のタスクに最適なデータベースを自由に選ぶことができるのです。トランザクションに大きく依存する金融業務ではSQLを使用したり、何百万ものJSONドキュメントを格納するためにNoSQLデータベースを使用することもできます。

Piotr氏は、他にもリクエストトラッキング（氏は経験の中でどのように取り組んできたかを例示している）や（HTTPによる）非同期メッセージングアプローチ、新しいサービスを容易にデプロイする方法（恐らくCI/CDに遠回しに言及している）、エンドツーエンド（E2E）テストを書くことなどもカバーする。 「フェールオーバ、サービスディスカバリ、その他の有用なメカニズムを含めること」について最後に述べた。

何かが不調になったときに、システム全体がクラッシュしないようにするか、少なくともその一部だけをクラッシュさせるようにします。（Pollyのような）再試行ポリシーやConsulなどのサービスディスカバリツールが含まれていることを確認し、資格情報を例えば、VaultやAzure Key Vault、私のオープンソースプロジェクトであるLockboxなどを使って集中管理するようにしてください。

Piotr氏が説明している多くのことは、過去数年間に他の多くの人が話してきたことに類似しており、マイクロサービスで開発する際には何が上手くいき、何が上手くいかないのか私達の共通理解を深めていくことができそうだ。しかし、Piotr氏が学んだ教訓のいくつかを説明してきたが、彼が開発したアプリケーションが（負荷下におけるスケーリングや耐障害性などについて）どれほどうまく動作しているのかを示すものではない。続報に期待したい。