主流のマイクロサービス マニア: 導入に伴う課題の増加

ほんの数年前まで、マイクロサービスは、新興のアプリ アーキテクチャがもたらす可能性と機会に興奮した開発者の間で話題になっていたものでした。

今日では、私たちネットワーク関係者でさえも、 Lightstep の最新の調査が宣言しているように、企業において AI がほぼ主流となっているため、AI について語っています。 真剣に。 2018 年のアプリケーション配信の現状レポートでは、ネットワーク関連の役割でも、アプリケーション サービスがコンテナーで提供されることを望んでいることがわかりました。 したがって、前述の Lightstep の調査で、回答者の 91% がマイクロサービスを使用しているか使用を計画しているだけでなく、86% が 5 年以内にマイクロサービスがデフォルトになると予想していることが判明しても、驚くべきことではありません。

課題がないと言っているわけではありません。 実際、Lightstep の調査では回答者の 99% がマイクロサービスの使用時に課題があると報告しています。 回答から判断すると、マイクロサービスではほぼすべてがより困難 (そして場合によっては高価) になると言えます。

調査では、ログ集約コストの上昇 (21%)、データの増加への対処方法がわからない (17%)、問題のトラブルシューティングが難しい (73%) など、ビジネスと運用の両方の課題が指摘されました。

しかし、さらに憂慮すべきなのは、「マイクロサービス環境における問題の根本原因を特定する際に問題に直面した人の 98% が、それが直接的なビジネスへの影響があると報告している」という調査結果です。  

これは、ネットワーク側にいるのか、DevOps 側にいるのかに応じて、通常「可視性」または「観測可能性」という用語を使用して、他の場所でも繰り返される重要な課題の 1 つです。

どちらも本質的には同じ機能を表します。つまり、メッセージがネットワークを介してクライアントからサービスへ、そしてサービスからクライアントへ移動するときに何が起こっているかを確認できるということです。 コンテナ環境内では、関係するサービスの範囲と規模が大きいため、これは特に困難です。

従来の 3 層 Web アプリでは、追跡する必要があるログ セットが 3 つとシステムが 3 つあります。 マイクロサービス アーキテクチャでは、Web クライアントとモバイル クライアントの両方で使用される可能性のある API が前面に配置される可能性があり、追跡する必要があるさまざまなサービスが数十または数百ある場合があります。

スケーリング モデルは依然として同じです (クローンを使用して水平方向にスケールアウトします) が、コンテナー環境内の規模は大幅に大きくなります。 それは、10 個ではなく 100 個の穴があるモグラ叩きをするようなものです。 特定のトランザクションがたどった経路を把握するのは、控えめに言っても困難です。 特に道が消えてしまった場合。 結局のところ、ほとんどのコンテナ環境の前提は、手動による介入を待つのではなく、迅速に失敗してインスタンスを置き換えることです。

この課題に対処するにはいくつかの方法があります。 まず第一に、トレースとトラブルシューティングを支援する計測機器です。 このアプローチは新しいものではありませんが、コンテナ環境の不安定な性質により、より困難になっています。 それでも、トレース要素 (一意の識別子を持つカスタム HTTP ヘッダーなど) を挿入すると、エラーやパフォーマンスの問題を追跡するときに運用に大きなメリットをもたらす可能性があります。 これは通常、ネイティブ コンテナ スケーリング オプションの機能ではありませんが、サービス メッシュでは、サービスの一部としてこれに取り組んでいます。

2 つ目は、障害のあるマイクロサービスを隔離して、運用担当者と開発者が障害の原因となった状態のシステムを調査できるようにする機能です。 検疫は基本的に、問題のあるコンテナをアクティブな環境から削除して、呼び出しが送信されないようにし、分析と検査のためにコンテナを存続させます。 

魔法の杖はありませんが、マイクロサービス ベースのデプロイメントでコンテナを追跡および隔離できれば、平均解決時間 (MTTR) を短縮し、ビジネスへの影響を軽減するのに大いに役立ちます。