マイクロサービスの運用に失敗しない５つの方法

今月初めにTakipiのAlex Zhitnitsky氏は，マイクロサービスの実運用でしくじらないための５つの方法について記事を書いた(正確に言うと，氏は“しくじる(mess up)”という表現は使っていないが)。記事の中で氏は，我々が数ヶ月前にレポートしたパネルディスカッションの結論に同社のユーザからの情報を加味して，マイクロサービスを実際に運用する上での主要な問題点と，その解決法について検証する。我々がそこで目にするのは，分散デバッグと，こうした問題を扱いやすいものにするための分散型アプローチが強調されていることである。最初に氏が論じる問題は，監視に関するものだ。

ポイントは賢く監視することです。システムが高度に断片化されているため，何が起きているのかを短時間で把握するためには，集中的な監視とモニタリングが強く求められます。

氏は先日のポッドキャストでも，不正なバージョンのロールバックが必要となった場合として，修正されたマイクロサービスが外部に認識されることによりロールバックの発生が影響を与える，というシナリオについて言及している。氏の結論は次のようなものだ。

教訓その１: モノリスアーキテクチャの監視が難しいと言うのなら，マイクロサービスの監視はその何十倍も難しく，多くの投資を必要とする。

第２の問題として氏が取り上げたのは，Sam Newman氏やAdrian Cockcroft氏といった人たちから，我々が何度も耳にした内容だった。

モノリスアーキテクチャであっても，おそらくログはさまざまな場所に散らばっているでしょう。モノリスとはいってもいくつかのレイヤは必要ですし，それらが別々の場所にログを作るであろうからです。では，マイクロサービスならば - ログはばらばらになります。ユーザトランザクションに関するシナリオを調べようとすれば，何が問題なのかを理解するために，すべてのサービスのさまざまなログを引っ張り出さなくてはならないでしょう。

このことから，氏の第２の教訓が導き出される。

教訓その2: マイクロサービスとは，物事を構成要素ひとつひとつにまで分解することに他ならない。結果的に，運用手順や監視対象もサービス単位に分割されるため，システム全体を対象とするためのパワーは失われる。適切なツールを用いてこれらを再度一元化することが，ここでは課題となる。

第３の問題は，有名なLeslie Lamport 氏による分散システムの定義に関係するものだ – “分散システムとは，まったく知らないマシンのせいで私のプログラムがフェールするシステムである”。Zhitnitsky氏はこれを，“ひとつのサービスが起こした問題が，どこか他の場所でエラーを発生させることがある”と表現している。ここから導き出される教訓は明解だ。

教訓その3: モノリスでは通常，見ている方向が正しいということは分かっている。これに対してがマイクロサービスでは，問題の根源がどこにあって，そこからどのうようなデータを取得すべきかを理解するのは難しい。

分散システムで問題の根本原因を見つけることは，次に発生する問題の基本となるものだ。このような場合にはログが有用だが，解決策のごく一部分に過ぎない。

ほとんどの場合，ログから運良く入手することのできた最初の情報には，たいして役に立つものはありません。ですから普通は，内部で起きているマジックをもっと明らかにするために，次の手掛かりが必要になります。そのためにはいつものログ文をもうひとつ，あるいはふたつ，追加することになります。変更版をデプロイしたら，問題が再現することを祈るだけです。ですがもし再現しなかったら，それは – ログを追加するだけで問題が解決することもたまにはある，ということです。一種の逆マーフィーの法則ですが，それも仕方ありません。

ここに次の教訓がある。

教訓その4: マイクロサービスでエラーの根本原因が複数のサービスにまたがっている場合には，集中型の根本原因検出ツールを用意しておくことが大切だ。

氏が最後にあげる問題点は，サービス間のバージョン管理と依存関係の循環に関するものだ。氏によれば，依存関係の正常性の維持には関して２つの問題がある。

1. サービス間に依存関係の循環があれば，トランザクションがループ内でスタックした場合に，分散型のスタックオーバーフローエラーが発生する可能性があります。2. ２つのサービスが依存性を共有していて，他のサービスAPIをそれらに影響を与える可能性のある方法で変更した場合，全体を一括して更新しなくてはなりません。こうなると，どれを最初に更新すべきなのか分からなくなります。安全に移行するためには，どうすればよいのでしょう？

独立性の高いサービスは，高い移植性や独自のリリースサイクルはもちろんだが，特に再現性に関する複雑性のあることは間違いない。ここに第5の，そして最後の教訓がある。

教訓その5: マイクロサービスアーキテクチャは，依存関係の問題に起因するエラーに対して特に脆弱である。

マイクロサービスに関して議論するには，それを実際に運用しているグループの情報が得られた方がよい。参加者の多くが中核となる問題と，それに対する共通的なアプローチで合意できればなお素晴らしい。