クラウド アプリケーション コンテナの左向き監視アプローチ

弾力性のあるコンテナ化された環境では、非効率的なコードは非常にコストがかかります。左監視アプローチと可観測性ソリューションは、この問題の解決に役立ちます。

シフトレフトは、ソフトウェア開発ライフサイクルの早い段階でのテスト、監視、自動化を重視するソフトウェア開発および運用のアプローチです。シフトレフトの目的は、問題が発生する前に検出し、問題を迅速に解決して発生を防ぐことです。

スケーラビリティの問題やエラーを早期に特定すると、より迅速かつコスト効率よく解決できます。非効率的なコードをクラウド コンテナーに移動すると、自動スケーリング機能が有効になり、毎月の請求額が増加する可能性があるため、非常にコストがかかる可能性があります。さらに、問題を特定、隔離、修正できるようになるまで、緊急モードになります。

問題の説明

実稼働環境に重大な影響を及ぼす可能性のある潜在的なアプリケーションの問題を回避できた事例を紹介します。

2022 年の Kubernetes レポートでは、チームが Kubernetes、AI における K8s、クラスターの可観測性などをどのように活用しているかについての洞察が提供されます。

最近のアプリケーションの変更に伴う UAT インフラストラクチャのパフォーマンス レポートを確認しています。これは、MariaDB をバックエンドとして使用し、Apache リバース プロキシと AWS アプリケーション ロード バランサーの背後で実行される Spring Boot マイクロサービスです。新しい機能は正常に統合され、すべての UAT テスト ケースに合格しました。しかし、MariaDB パフォーマンス ダッシュボードのパフォーマンス グラフが、デプロイ前のパターンから逸脱していることに気付きました。

以下はイベントのタイムラインです。

8 月 6 日 14:13 に、Tomcat が埋め込まれた新しい Spring Boot jar ファイルを使用してアプリケーションが再起動されました。

14:52 に、MariaDB のクエリ処理速度は 0.1 クエリ/秒から 88 クエリ/秒に増加し、さらに 301 クエリ/秒に増加しました。

さらに、システムの CPU 使用率は 1% から 6% に増加しました。

最後に、JVM が G1 Young Generation Garbage Collection に費やした時間は 0% から 0.1% に増加し、このレベルに留まりました。

アプリケーションは、UAT フェーズ中に異常に 300 クエリ/秒を発行し、設計要件を大幅に超えました。新しい機能によりデータベース接続が増加し、クエリ量が大幅に増加しました。ただし、監視ダッシュボードには、新しいバージョンが展開される前は問題の測定値が正常であったことが示されています。

解決

これは、JPA を使用して MariaDB をクエリする Spring Boot アプリケーションです。アプリケーションは、最小限の負荷で 2 つのコンテナーで実行されるように設計されていますが、10 個のコンテナーまで拡張できます。

1 つのコンテナが 1 秒あたり 300 件のクエリを生成できる場合、10 個のコンテナすべてが実行されている場合、1 秒あたり 3000 件のクエリを処理できますか?データベースには、アプリケーションの残りの部分のニーズを満たすのに十分な接続がありますか?

開発者のワークベンチに戻って Git の変更を確認するしかありません。

新しいミューテーションは、テーブルから少数のレコードを取得して処理します。これはサービス クラスで確認するコードです。

 List<X> findAll = this.xRepository.findAll();

いいえ、ページングなしで Spring の CrudRepository の findAll() メソッドを使用するのは非効率的です。ページネーションは、取得するデータの量を制限することで、データベースからデータを取得するのにかかる時間を短縮するのに役立ちます。これは、私たちが最初に学んだリレーショナル データベース (RDBMS) の教育で学んだことです。さらに、ページングは​​、メモリ使用量を低く抑えてデータの過負荷によるアプリケーションのクラッシュを防ぎ、前述の問題の説明で述べたように、Java 仮想マシンのガベージ コレクションのワークロードを軽減するのに役立ちます。

このテストは、1 つのコンテナー内の 2000 件のレコードを使用して実行されました。このコードがコンテナあたり約 200,000 件のレコードを含む本番環境にデプロイされた場合、チームに大きなストレスと不安を引き起こす可能性があります。

メソッドに WHERE 句を追加した後、アプリケーションが再構築されました。

 List<X> findAll = this.xRepository.findAllByY(Y);

通常業務を再開しました。 1 秒あたりのクエリ数は 300 から 30 に減少し、ガベージ コレクションのワークロードは元のレベルに戻りました。さらに、システムの CPU 使用率も削減されます。

学習とまとめ

サイト信頼性エンジニアリング (SRE) に携わる人なら誰でも、この発見の重要性を理解するでしょう。重大度レベルを 1 に上げずに対策を講じることができました。この欠陥のあるパッケージが本番環境に導入された場合、顧客の自動スケーリングしきい値がトリガーされ、追加のユーザー負荷がなくても新しいコンテナが起動される可能性があります。

この物語には3つの要点があります。

まず、潜在的な問題を特定するために使用できるイベントの履歴を提供するため、最初から可観測性ソリューションを有効にするのが最適です。この履歴がなければ、ガベージ コレクションの割合が 0.1% で CPU 消費量が 6% であることを真剣に受け止めず、コードが本番環境にリリースされて悲惨な結果を招く可能性があります。監視ソリューションの範囲を UAT サーバーに拡張すると、チームは潜在的な根本原因を特定し、問題が発生する前に防止できるようになります。

2 番目に、パフォーマンス関連のテスト ケースはテスト プロセス中に存在し、可観測性の経験を持つ人物によってレビューされる必要があります。これにより、コードの機能とパフォーマンスがテストされるようになります。

3 番目に、クラウド ネイティブのパフォーマンス追跡テクノロジは、高い使用率や可用性などに関するアラートを受信するのに非常に役立ちます。可観測性を実現するには、適切なツールと専門知識を準備する必要がある場合があります。楽しいコーディングを！