サービス メッシュとアプリのモダナイゼーション
コンテナ熱は衰えることなく続いています。 しかし、applicationsやアーキテクチャの観点から見ると、それはあなたが考えている意味とは異なるかもしれません。
コンテナをマイクロサービスと同一視する傾向が依然として残っています。 ここで言う「同等」とは、「互換的に使用する」という意味です。
これは誤った仮定です。
ご存知のとおり、現在、コンテナのかなりの割合が、既存のapplicationsを展開するために使用されています。 Container Journal で指摘されているように、IDC の調査では、コンテナの半分未満 (46%) が新しいapplicationsに使用されていることがわかりました。 残りは既存のapplicationsを実行していました。 （ソース： IDC の調査により、コンテナがミッション クリティカルなアプリケーションを推進していることが判明) この奇妙な組み合わせについてよく引用される説明は何でしょうか? 近代化。
クラウド ネイティブとして構築されている「新しい」applicationsの数はまだ比較的少なく、Cap Gemini の調査によると 5 分の 1 未満であることを指摘する調査や研究は数多くあります。 Diamanti の最近の調査によると、IT リーダーの 31% が、レガシーapplicationsの最新化を目的としてコンテナに注目していることがわかりました。 これは驚くことではありません。 私たちは、5 つの異なる世代のapplicationアーキテクチャをサポートする多世代 IT の時代に生きています。
つまり、コンテナにデプロイされる可能性のある従来のアプリが数多く存在し、今後もさらに増えていくことになるでしょう。
私は、コンテナやサービス メッシュなどの関連テクノロジが実際に近代化の取り組みに役立つため、これは良いことだと考えています。
サービスメッシュによる監視の近代化
ご存知ない方のために説明すると、可観測性は、Cindy Sridharan が「分散システムの可観測性」で詳しく説明しているように、一般的に受け入れられている 3 つの柱で構成されています。
- イベントログ
- メトリクス
- 痕跡
このトピックに関するコンテンツは豊富にあり、ログによって生成される大量の運用データやテレメトリの送信に固有の課題も含まれているため、ここでは取り上げません。 観測可能性の可能性を最大限に引き出すには、これら 3 つすべてが必要であると言えば十分でしょう。
また、この最新の点、つまりトレースに関しては、既存のレガシーapplicationsは不利な立場にあると述べるだけで十分でしょう。 ご存知のとおり、ほとんどのシステムには、トランザクションの発生から完了までの過程を追跡するために必要なテレメトリを送信する機能が備わっていませんでした。 applicationのアーキテクチャや環境に関係なく、イベント ログとメトリックの生成と取得がはるかに簡単になります。 これらは、ほぼすべての Web およびapplicationプラットフォームの標準オプションです。 しかし、計装は？ これは通常、リアルタイムのトラフィックを可視化する埋め込みコードまたはエージェントを意味します。
これはサービス メッシュが提供できる機能の 1 つです。
思い出していただければ、サービス メッシュは主にコンテナ オーケストレーション環境内のサイドカー プロキシで構成されています。 これらのプロキシは基本的に、コンテナーのすべての通信 (入出力) をプロキシします。 そうすることで、これらのプロキシはサービスを拡張するだけでなく、完全な監視を可能にするためにトラフィックを計測するのに最適な場所も提供します。 コンテナ環境を通過するメッセージを拡充し、詳細なタグやその他のメタデータを含めることができるため、システムは複数のシステムやサービスにわたってトラフィックを追跡し、相関関係を把握できるようになります。
何よりも素晴らしいのは、applicationをほとんど変更せずにこれを実現できることです。 Java アプリなどの場合には、コードを変更せずに適切な機能を挿入するための構成ベースのオプションがあります。
既存のapplicationsからトレースを発行する機能は、真の可観測性を追求する上で重要な機能です。 既存のapplicationsをコンテナにデプロイする場合は、サービス メッシュがそれらの最新化にどのように役立つかを検討してください。