NGINX モダン アプリ リファレンス アーキテクチャ バージョン 1.0.0 の発表

2021 年 8 月の Sprint 2.0 で NGINXモダン アプリケーション リファレンス アーキテクチャ(MARA) を発表したとき、私たちは設計目標を率直に示しました。 私たちは、Kubernetes で実行され、セキュリティ、スケーラビリティ、信頼性、監視、イントロスペクションをサポートするように設計された最新のアプリケーション アーキテクチャの例を作成したいと考えました。 このプロジェクトは、時間のかかる統合作業なしで機能コンポーネントを組み合わせる「プラグ アンド プレイ」アプローチを使用して、さまざまなインフラストラクチャに展開可能である必要がありました。

Sprint 以降の数か月間、私たちはロードマップに沿って前進してきました。 他のプロジェクトと同様に、私たちも成功と失敗を経験し、その成功を MARA に取り入れながら、学んだ教訓のリストを増やしてきました。 これらの問題を文書化し、これらの教訓を念頭に置いて設計することで、他の人が同じ問題に遭遇しないようにしたいと考えています。

私たちは最近、プロジェクト ディレクトリを再編成し、環境のインスタンス化と破棄のプロセスを変更するMARA バージョン 1.0.0でマイルストーンに到達しました。 重複したコードを排除し、将来の追加に簡単に対応できるディレクトリ構造を作成し、管理スクリプトを標準化しました。 このバージョンは MARA の歴史において重要なポイントとなるため、私たちは立ち止まってコミュニティに進捗状況を報告し、学んだ重要な教訓のいくつかを書き留め、今後のロードマップに関する情報を提供したいと考えました。

テレメトリ – メトリクス、ログ、トレース

MARA の中心的な貢献者は、大規模なソフトウェアの実行経験があり、運用、エンジニアリング、管理の観点からサービスを提供するために何が必要かを理解しています。 アプリケーションが誤動作し、問題が何であるかを正確に判断する簡単な方法がない場合に感じる不安感を、彼らは知っています。 DevOps の世界で広まっている引用文は、この問題を簡潔にまとめています。 「マイクロサービスのデバッグは、一連の殺人ミステリーを解くようなものです」。

これを念頭に置いて、私たちは短期ロードマップにおいて可観測性の追加を最優先事項としました。 このコンテキストにおける可観測性には、ログ管理、メトリック、およびトレース データが含まれます。 ただし、データを収集するだけでは十分ではありません。データを詳しく調べ、環境で何が起こっているかについて有意義な決定を下す必要があります。

トレースのオプションを調査した結果、テレメトリ データ、ログ、メトリック、トレースの全範囲をサポートしているOpenTelemetry (OTEL) にたどり着きました。 私たちは、OTEL エージェントがすべてのトレース データを収集、処理、重複排除してから、それを OTEL コレクターに渡して集約およびエクスポートし、ワークフローの最後に視覚化システムを使用してデータを使用可能にする実装を構想しました。 このアプローチにより、OTEL 標準を活用して初期の段階 (収集、集計など) を簡素化しながら、データの表示と分析に関してユーザーに幅広い選択肢が提供されます。

実装は 2 段階で構築しました。

1. 環境内のOTELコレクターを管理するためにKubernetes用のOpenTelemetry Operatorをデプロイする

2. Bank of Siriusアプリケーションをインストルメント化してトレースとメトリックを出力する

MARA のオリジナルバージョンでは、ログ記録にElasticsearchとFilebeat を使用していましたが、これをGrafana Lokiに置き換えることも検討しましたが、当面は元の選択を維持することにしました。 メトリクスの面では、当初使用していた特注の Prometheus 構成を、コミュニティが管理するkube-prometheus-stack Helm チャートに置き換えることで、 PrometheusとGrafanaに基づく元のデプロイメントを修正する必要があることに気付きました。このチャートは、Grafana、ノード エクスポーター、Kubernetes 環境の管理に適した一連の事前構成済みダッシュボードとスクレイプ ターゲットを含む完全な Prometheus 環境を構築します。 これに加えて、 F5 NGINX Ingress Controllerと Bank of Sirius アプリケーション用のダッシュボードもいくつか追加しました。

これは、OTEL を実装するために必要な膨大な作業のほんの簡単な概要です。 他の人が同じ急峻な学習曲線を登る手間を省くために、私たちはブログの「OpenTelemetry を最新のアプリ リファレンス アーキテクチャに統合する - 進捗レポート」でプロセス全体を文書化しました。

デプロイメントオプション – Kubeconfig

MARA の初期バージョンでは、デプロイメント環境としてAmazon Elastic Kubernetes Service (EKS) を選択しました。 それ以来、多くのユーザーから、コスト上の理由から、ラボやワークステーションなど、リソースをあまり必要としない「ローカル」環境で MARA を実行したいという声が寄せられています。 移植性は当初のプロジェクトの主要な目標でした (そして今もそうです)。そのため、これは私たちがそれを達成できることを証明するチャンスでした。 タスクを容易にするために、最低限の要件を満たす任意の Kubernetes クラスターで実行できるデプロイメント手順を設計することにしました。

最初のステップとして、 kubeconfigファイルを読み取って Kubernetes クラスターと通信する新しい Pulumi プロジェクトを MARA に追加しました。 このプロジェクトは、Pulumi Kubernetes プロジェクトとインフラストラクチャ プロジェクト (後者の例としては、AWS や Digital Ocean のプロジェクト) の間に位置しています。 実際には、kubeconfig プロジェクトを作成すると、新しいインフラストラクチャ プロジェクトを統合するための障壁が低くなります。 インフラストラクチャ プロジェクトが kubeconfig ファイル、クラスター名、クラスター コンテキストを kubeconfig プロジェクトに渡すことができれば、MARA デプロイメント手順の残りの部分はシームレスに機能します。

テストでは、 K3s 、 Canonical MicroK8s 、 minikubeなど、CPU とメモリの要件が少なく、インストールが簡単なKubernetes ディストリビューションをいくつか使用しました。 ディストリビューションはすべて、 2 つの CPUと 16 GB の RAMを搭載した Ubuntu 21.10 を実行する仮想マシン (VM) に展開されました。 さらに、すべてのディストリビューションは、永続ボリュームと Kubernetes LoadBalancer サポートを提供するように構成されました。

このプロセスで最も困難だったのは、プロジェクトの一部であるカスタムビルドの NGINX Ingress コントローラーに使用されるプライベート レジストリを操作することでした。 (MARA をデプロイする場合は、NGINX Open Source または NGINX Plus に基づく標準の NGINX Ingress Controller と、このカスタムビルドの NGINX Ingress Controller を使用できることに注意してください。) プラットフォームに依存しないアプローチを採用するために、レジストリ ロジックをAmazon Elastic Container Registry (ECR) から切り離す必要があることがわかりました。この作業は現在進行中です。 また、出力アドレスのホスト名を取得するためのロジックはAWS Elastic Load Balancing (ELB) に特有のものであり、他のユースケースに適用するには書き直す必要があることにも気付きました。

MARA 管理スクリプトと Pulumi プロジェクトでは現在、上記の問題を回避するために特定のロジックを使用しています。 現時点では、Kubernetes 構成ベースのデプロイメントでは、公式 NGINX レジストリの NGINX Ingress Controller (NGINX Open Source または NGINX Plus のいずれかに基づく) を使用する必要があります。

クラウドベースの展開に必要なリソースが提供されないローカル展開に対応するために、MARA 構成ファイルにいくつかのチューニング パラメータを追加しました。 ほとんどのパラメータは、 Elastic Stackのさまざまなコンポーネントに対して要求されるレプリカの数に関連しています。 テストが進むにつれて、展開環境のリソース制約に基づいて MARA を微調整するためのパラメータが追加されます。

これらの変更を実施することで、K3s、MicroK8s、Minikube へのデプロイを正常に実行でき、 Azure Kubernetes Service (AKS)、 Digital Ocean 、 Google Kubernetes Engine 、 Linode 、Rancher のHarvesterでロジックを正常にテストできました。 詳細については、 MARA プロバイダー ステータス ページおよびMARA を参照してください。 お近くのワークステーションで実行中 私たちのブログで。

パートナーとのコラボレーション

私たちのパートナーは、MARA との取り組みを非常に好意的に受け止め、支援してくれており、多くのパートナーがこのプロジェクトについて詳しく知りたい、自分の製品でこのプロジェクトを活用する方法や機能の追加方法について尋ねてきました。

私たちは、使いやすさと Python のサポートを理由に、 Pulumi をMARA の中核部分として選択しました。Python は非常に人気のある言語であるため、大規模なコミュニティで MARA コードを簡単に理解できます。 さらに、Pulumi の活気あるコミュニティとプロジェクトへの関与は、私たちが MARA で実現したいと願っているコミュニティ関与のモデルとなりました。

2021 年後半、当社はSumo Logicと協力し、NGINX Ingress Controller を使用したクラウド監視ソリューションに MARA を組み込みました。 これは、MARA がプラグ可能であるという当社の主張をテストするチャンスでした。 課題は、MARA の Grafana、Prometheus、Elastic を Sumo Logic ソリューションに置き換えることでした。 他のデプロイメントで使用したのと同じロジックを使用してソリューションを正常に立ち上げ、Sumo Logic SaaS に接続するだけでなく、環境からメトリックを取得するように構成できたことを嬉しく思います。

OpenTelemetry との取り組みの一環として、当社はLightstepと協力し、OTEL コレクターを簡単に再構成して、トレースとメトリックを Lightstep の SaaS サービスにエクスポートできるようにしました。 これは、OTEL が可観測性の未来であると強く信じているため、私たちがさらに調査したい分野です。

これまでに学んだ教訓

これまでに私たちが学んだ最大の教訓は、モジュール式アプローチの賢明さです。 Sumo Logic を使用した作業により、MARA コンポーネントをうまく組み合わせることができることが示されました。 OTEL を環境にさらに完全に統合するにつれて、さらなる確認が得られると期待しています。 以前、スタックのリソースフットプリントを削減するため、ログ管理環境として Elasticsearch を Grafana Loki に置き換えることを検討していると述べました。 とはいえ、すべてをマイクロサービス化するという極端さを追求するのではなく、「実用的なモジュール性」を推奨します。 たとえば、多くのアプリケーションのログを処理できる特殊なサービスを持つことは理にかなっています。しかし、ログの収集、保存、視覚化のために個別のマイクロサービスが必要であることはあまり明らかではありません。

また、関連するパラメータを省略するのではなく、構成に明示的に含めてデフォルトを設定すると便利であることもわかりました。 これは管理者にとって 2 つの点で便利です。デフォルトを覚えておく必要がなく、構成内の適切な場所に正しい構文で既に表示されているパラメータを変更するだけで簡単に変更できます。

私たちが学んだもう一つの痛い教訓は、一部のソリューションが人気なのは、それが最高だからではなく、インストールが最も簡単だったり、チュートリアルが最も優れているからであるということです。 だからこそ、設計プロセス中に自分の仮定に疑問を持ち、同僚に相談することが非常に重要です。オープンなコミュニケーションの文化は、問題を早期に特定して修正するのに大いに役立ちます。

そうは言っても、うまく機能するロジックを実装しても、それが行き詰まったり、他の問題を引き起こしたりすることが何度かありました。 たとえば、Pulumi 経由でアプリケーションのデプロイを開始したとき、 ConfigMapsに YAML マニフェストを使用し、変数の更新にはPulumi 変換を利用していました。 これは機能しましたが、保守性などいくつかの理由から理想的ではありませんでした。 次のイテレーションでは、 kube2pulumi を使用してマニフェストを Pulumi コードに変換し、それを使用して ConfigMap を構築することで、コードの読みやすさと保守性が向上しました。

マージによってデプロイメント YAML に無効な設定が挿入されたときに、別の教訓が始まりました。 コードが構文的に正しく、期待どおりに動作することを確認するために、YAML の大部分を書き直して慎重にレビューする必要がありましたが、これはイライラさせられる時間のかかるプロセスでした。 将来の問題を回避するために、GitHub プッシュ プロセス中に、汎用 YAML と Kubernetes 固有のlintingと検証の両方を自動化しました。

最後に、メインライン ブランチが常に実行可能であることを確認することが当初からの私たちの目標でした。 新しいプロジェクトをチェックアウトして、メンテナーがメインラインに導入した問題を解決しなければならないときは、イライラします。 残念ながら、Bank of Sirius サブモジュールを使用した次の例を含め、私たちはこれに何度か失敗しました。

• 誤って URL スキームをssh://からhttps://に変更するのを忘れてしまいました。 私たちは皆、GitHub への接続にssh を使用しているため、これは問題ではありませんでした。 しかし、GitHub の SSH キーを持っていないユーザーは、サブモジュールを初期化しようとしたときにエラー メッセージが大量に表示されました。
• 管理スクリプトの 1 つのリリースは共通パッケージに依存していましたが、私たちはそれが私たちのマシンと同じようにすべてのユーザーのマシンにインストールされていると誤って想定していました。
• 起動ロジックの書き換え中にサブモジュール ソースのチェックを忘れてしまいました。 サブモジュールには、Bank of Sirius をデプロイするために必要なマニフェストが含まれていますが、残念ながら、これらのマニフェストが利用できないときにスローされるエラーと警告は非常にわかりにくく、根本的な原因を発見するまでに、奇妙な動作をデバッグする数日間の旅を始めることになりました。

次は何か

今後数か月の開発には、NGINX Ingress Controller ビルドのリファクタリング、レジストリ プッシュ、Ingress ホスト名/IP アドレス ロジックなど、大きな計画があります。

MARA のスタンドアップごとに気づいたことの 1 つは、NGINX Ingress Controller に対するスキャンと攻撃がいかに早く発生し始めるかということです。 このため、NGINX Ingress Controller と NGINX App Protect WAF を MARA に統合し始めました。 これにより、App Protect によって生成されたログを最適に管理する方法を決定するという課題と機会がもたらされます。

今後数か月以内に行う予定のもう 1 つの変更は、すべてのモジュールが Pulumi と Kubernetes の両方からではなく、Kubernetes からシークレットを取得するようにすることです。 つまり、すべてのモジュールが共通のシークレット リポジトリを使用し、管理者がシークレットの設定方法を制御できるようになります。 ユーザーが選択したリポジトリからシークレットを読み取り、対応する Kubernetes シークレットを作成するための新しいモジュールを作成しています。

MARA には現在、負荷を生成するツールが含まれています。これは、Bank of Sirius の元となった元の Bank of Anthos アプリに付属するLocustベースのツールをアップグレードして若干変更したバージョンです。 私たちが作成している新しいテスト ツールである Cicada Swarm は、負荷を生成するだけでなく、設定したしきい値をメトリックが超えた時点を追跡してレポートするため、クラウド内のソフトウェア製品の迅速なパフォーマンス テストのためのフレームワークになります。 並列化技術を使用して、必要な信頼レベル、より高い精度、カスタマイズ可能な回帰分析を備えたテスト結果を提供し、CI/CD パイプラインでのビルドの成功または失敗を判断します。

最後に、負荷テストの影響をどのように測定するかについて話さずに負荷テストについて言及することはできません。これはテレメトリに戻ります。 私たちは OpenTelemetry の可能性に興奮しており、より包括的な実装がすぐに実現することを期待しています。 完全な実装がなくても、テストを実行し、その影響を測定し、データが示す内容に基づいて運用上の決定を下せるようにすることが私たちの目標です。

いつものように、プルリクエスト、問題、コメントを歓迎します。 MARA の目標は、コミュニティが協力してさまざまな潜在的なソリューションについて議論し、試行し、テストし、反復することで、最新のアプリケーションを最適に展開および管理する方法について理解を深めることです。

関連記事

この投稿はシリーズの一部です。 今後 MARA に機能が追加されるにつれて、その詳細をブログで公開していきます。

• 新しいオープンソースのモダンアプリリファレンスアーキテクチャ
• OpenTelemetry をモダン アプリ リファレンス アーキテクチャに統合する – 進捗レポート
• マーラ： お近くのワークステーションで実行中
• NGINX モダン アプリ リファレンス アーキテクチャのバージョン 1.0.0 を発表(この投稿)