BT

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

| 作者: Mark Little フォローする 12 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2016年7月6日. 推定読書時間: 4 分 |

原文(投稿日:2016/06/19)へのリンク

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

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

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

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

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

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

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

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

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

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

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

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

ここに次の教訓がある。

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

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

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

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

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

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

 
 

この記事を評価

関連性
形式
 
 

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT