マイクロサービスのアンチパターン

一枚岩のアプリケーションの主な問題はスケールし難いということだ。しかし、これはアプリケーションの観点だけではなく、チームがスケールし難くなることが重要だ。QCon LondonカンファレンスでTammer Saleh氏は、マイクロサービスの一般的なアンチパターンについて語り、マイクロサービスへ移行する主な理由はチームにある、と話した。

小さなアプリケーションと小さなチームであれば、一枚岩のアプリケーションでも問題ない。しかし、アプリケーションが成長し、携わる開発者の数が増えるとひとつのコードベースで開発を続けられなくなる。マイクロサービスへ移行することでコンウェイの法則が作用するようになるのだ。

Saleh氏によれば、マイクロサービスでアプリケーションを構築するのはとても難しく、失敗の仕方もさまざまだ。もっとも一般的な失敗はマイクロサービスから出発してしまうことだ。氏の考えでは、あらゆるシステムは、可能な限りシンプルに始めて、チームやビジネスの観点から必要であれば、より複雑な解決策に移行するのが良い。企業にとってもっとも重要なのは興味深い設計パターンを探索することではなく、市場であり、売り上げだ。まずは一枚岩のアプリケーションで始めて、必要に応じてそこからサービスを抽出するのが氏の提唱する解決策だ。また、マイクロサービス開発には一定の税がかかることも指摘している。

トラフィックのスパイクに対応するには、ピークロードをさばくために十分な数のサーバを維持する必要がある。しかし、トラフィックとサーバの増大は最終的にはデータベースのオーバロードになる。ひとつの解決策として、キューを使って、トラフィックを均一にする方法が考えられる。キューをバッファとして使うのだ。これによって、通信は非同期になり、複雑さが増す。リクエストとレスポンスのサイクルがなくなり、クライアントは非同期のレスポンスに対応しなければならないからだ。しかし、Saleh氏にとっては、これは計算リソースにお金をかけすぎないようにするために必要なステップだ。

運用の観点から考えると、複数のサービスが特定のひとつのサービスと通信しようとする場合、そのサービスが応答を返さないと問題になる。診断、修復も難しい。あらゆるリクエストが入ってくるサービスだからだ。たくさんのサービスがリクエストを送ってくるとこのような問題が発生する。解決策はダウンしているサービスにリクエストが行かないようにするサーキットブレーカーだ。通常時はサーキットブレーカーはすべてのトラフィックを通過されるが、障害を見つけるやいなや、障害を起こしたサービスがレスポンスを返すようになるまで、アクセスされないようにする。

また、マイクロサービスには新しいテストパターンもある。典型的なパターンは、テスト対象のサービスが利用しているサービスのモックを作るやり方だ。最終的にはそれぞれのチームが利用しているすべてのサービスのモックを作ることになる。これは、過剰な開発だ。Saleh氏の経験からすると、解決策はそれぞれのチームが自分たちのサービスのモックを作ることで、ひとつのサービスにひとつのモックがあるようにする方法だ。そして、さらなる改善として、それぞれのチームが、そのサービスを利用するサービス向けにクライアントを作っておくの責任を持つサービスのクライアントを作っておく。そのクライアントが実際の通信を処理し、モックも含む。この方法の利点は、サービスがプロトコルについて完全に制御し、必要に応じて変更できることだ。

2015年のブログ記事で、Stefan Tilkov氏は一枚岩のアプリケーションから始めることに対して異論を唱えている。氏の考えでは、十分に大きいシステムなら始めからサブシステムに分けるべきだ。

Ben Christensen氏は今年の始めのプレゼンテーションでサービスチームが作ったクライアントライブラリを使うリスクについて語っている。サービスにアクセスするための唯一の公式な方法になってしまうのだ。

QConの参加者はSaleh氏のプレゼンテーションを閲覧できる。InfoQの読者にも公開されるだろう。