BLOG
マイクロサービス時代のモニタリング

迅速性の高まりにつれて増大する複雑さの管理

DockerとDevOps革命のおかげで、マイクロサービスはアプリケーションを構築して展開する新しい方法として浮上しました。マイクロサービスのトレンドを受け入れる理由はたくさんあります。

マイクロサービスを採用する場合は、マイクロサービスアーキテクチャには多くの部品があることも理解しておく必要があります。 インシデント管理に関して言えば、マイクロサービスとモノリシックアーキテクチャの間に重要な違いがあります。 部品が多いほど、アプリケーションとインフラストラクチャの健全性と継続性を維持するために、監視と管理がより複雑になります。

マイクロサービスがいかにIT監視の課題を増やすか、そして増大する複雑さを組織がどのように処理すべきかを探ってみましょう。

マイクロサービスの定義

マイクロサービスは、他のマイクロサービスと組み合わせて完全なアプリケーションを形成する小さなアプリケーションコンポーネントです。 Dockerを使用してアプリケーションをデプロイする場合は、複数のコンテナで構成されている可能性があります。各コンテナは個別のマイクロサービスを実行します。

DevOpsはソフトウェアの継続的デリバリーを奨励しているため、マイクロサービスはこの数年間で普及してきました。管理者はアプリケーション内の特定のマイクロサービスの問題を追跡できるため、マイクロサービスとして配備されたアプリケーションは管理しやすくなります。アプリケーションの特定のコンポーネントへの更新では、アプリ全体ではなくそのマイクロサービスだけを再起動できるため更新するのも簡単です。以上のような理由から、マイクロサービスは継続的デリバリーを容易にします。

2013年にDockerが導入されたことで、マイクロサービスへの関心が高まりました。Dockerコンテナは、マイクロサービスのための便利なビルディングブロックを提供し、モノリシックアーキテクチャに従って設計されたレガシーアプリケーションをマイクロサービスモデルに移植しようとする際に容易な移行パスを提供します。

複雑さ：マイクロサービスのトレードオフ

マイクロサービスを採用している組織は、インフラに追加する複雑さを考慮する必要があります。モノリシックアプリケーションがマイクロサービスアプリケーションに変換されると、管理者が監視すべきパーツが増大します。

たとえば、フロントエンドとデータベースがそのアプリケーション専用の仮想サーバ上で単一のアプリケーションとして実行される、モノリシックなWebアプリケーションを考えてみましょう。このアプリケーションの監視は比較的簡単です。その一部がダウンすると、アプリ全体がダウンします。監視するホストは1つだけであり、対処するアラートも1つだけです。このようなアプリは、異なるポート間の接続やサーバとデータベースのプロセスを監視することで事足ります。

ここで、コンテナのセットとしてデプロイされた同じアプリを考えてみましょう。単一の仮想サーバでアプリケーションを単純なプロセスとして実行する代わりに、フロントエンドとデータベースのレイヤーを異なるプロセスとして実行しているアプリです。Dockerはたくさんのプロセスを起動します。スケールアウトするようなアプリでは、おそらく何百ものコンテナがそれぞれのプロセスを担当するでしょう。コンテナの数はアプリケーションの要求に応じて絶えず変化します。さらに、アプリケーションの統計を収集するなどのタスクを担当するコンテナも抱えることになります。アプリケーションの可用性とパフォーマンスを保証するには、Dockerデーモン自体はもちろんのこと、これらすべてのコンポーネントを監視する必要があるため複雑です。

念のために言えば、私はマイクロサービスが悪いアイデアであるとは全く考えていません。上記の例では、マイクロサービスバージョンのWebアプリケーションは、モノリシックバージョンよりもはるかに拡張性と機敏性が高くなります。スケールアウトの敏捷性には、監視作業を増やすだけの価値があります。

マイクロサービスを効果的に監視する方法

効果的なマイクロサービス監視戦略には、2つの事実に注意が必要です。

明らかなのは、マイクロサービスでは監視すべきコンポーネントが増えているということです。しかし利用するインシデント管理プラットフォームが多数のアラートを処理したり、トライアルを支援したり、適切な人にルーティングしたりする能力を十分に備えていれば、これはさほど大きな問題ではありません。さらに、マイクロサービスではアラートの量がはるかに多くなるため、インシデント管理プラットフォームではアラートノイズを減らす必要があります。関連するアラートをグループ化したり、必要な対応を関連付ける一方、対応不能なアラートは抑制する必要があります。

もう1つ、やっかいな事実は、マイクロサービスが複雑になると、管理者にとってインシデント管理の役に立つ情報の量も増えることです。これは良いことです。モニターするコンポーネントが増えれば、対処すべきデータが増えますが、その余分なデータを活用して問題を特定することができます。モノリシックアプリに関連するアラートは、単にそのアプリのどこかに何か問題があることだけを伝えるため、問題の内容を正確に把握することはあなたの努力次第です。しかし、マイクロサービスでは、個々のDockerコンテナからのアラートにより、管理者は事件の原因となったアプリ内の正確なマイクロサービスを特定することができます。そして、アプリケーションが依存する他のコンテナを中断することなく、そのコンテナのインシデントを解決できます。

マイクロサービスは、インシデント管理チームにチャレンジとチャンスの両方を提供します。インフラストラクチャはより複雑になりますが、インシデント対応をより効果的かつ容易に行うことができます。マイクロサービスのモニタリングの鍵は、モノリシックなアプリの監視とマイクロサービスで構成されたアプリの監視の違いを理解し、マイクロサービス対応のインシデント管理ソリューションとワークフローを適切に配置することです。