ブログ | NGINX

新しいオープンソースのモダンアプリリファレンスアーキテクチャ

NGINX-F5 水平黒タイプ RGB の一部
ダミアン・カリーのサムネイル
ダミアン・カリー
2021年8月24日公開

NGINX では、ここ数年間、アプリケーションを真に最新かつ適応性の高いものにする必要性、つまり、移植性、クラウド ネイティブ性、回復力、拡張性、更新の容易さなどを重視して議論してきました。 最近では、最新のアプリの作成と配信を容易にする 2 つの概念が注目を集めています。 1 つ目はPlatform Opsです。ここでは、企業レベルのプラットフォーム チームが、開発チームと DevOps チームが業務を遂行するために必要なすべてのツールをキュレート、保守、接続、保護します。 2 つ目はシフトレフトです。これは、開発ライフサイクルの早い段階で、本番環境レベルのセキュリティ、ネットワーク、監視をアプリケーションに統合することを意味します。 開発者は、以前は ITOps に属していた機能に対してより多くの責任を負うことになりますが、同時に、それらの機能をどのように実装するかについて、より多くの選択肢と独立性を持つことになります。

これは良いように聞こえますが、実際には、プラットフォーム オペレーションを実装し、インフラストラクチャと運用ツールを「シフトレフト」することは困難です。 1 つには、ますます多くのアプリが、コンテナ化された環境で高度に分散された方法で、増加している Kubernetes オーケストレーション エンジンの 1 つを使用してデプロイされるようになっています。 企業はまた、クラウド間の違いやクラウドとオンプレミス環境の違いに煩わされることなく、複数の環境にアプリを展開したいと考えています。

モダンアプリのための「ゴールデンイメージ」

当然のことながら、当社の顧客とコミュニティは、直面している課題に対して当社に支援を求め続けています。 彼らはあらゆる利点を望んでいますが、セキュリティ、ネットワーク、可観測性とパフォーマンス監視、スケーリングなど、すべての要素をまとめるには実際の作業が必要です。 結果として得られるプラットフォームを実稼働環境に十分耐えられるほど堅牢にするには、さらに多くの作業が必要です。 彼らは疑問に思う。 「なぜ、単一のリポジトリから起動できる最新のアプリ用の『ゴールデン イメージ』がないのでしょうか?」

それは良い質問です。私たちはそれを、良い答えを見つけることへの挑戦として捉えました。 まず、質問をより具体的な言葉で言い換えました。 顧客やコミュニティは次のことを尋ねていると思います。 「さまざまなソフトウェア製品をよりまとまりのあるものに統合し、スタックを調整して適切な構成と設定を確立し、作業とトラブルを軽減するお手伝いをしてもらえませんか? また、基盤となるサービスや機能の違いによる構成の大幅な変更を行わずに、異なるクラウドでアプリケーションを簡単に実行できるようになりますか?」

私たちは、これらの疑問に真に答えるソリューションは、数百の企業のパートナーやすべての主要クラウドベンダーだけでなく、コミュニティ全体に有益であり、まさにゼロサムではない勝利であると考えています。 理想的なソリューションは「おもちゃ」ではなく、Kubernetes 環境で実行される実際の運用アプリケーションにデプロイできる、堅牢でテスト済みのコードです。 そして率直に言うと、私たちは誰でも GitHub から私たちの成果物を盗めるようにしたいと考えています。

早速ですが、本日、 NGINX Sprint 2.0で、私たちはソリューションのリリースを発表しました。これは、モダン アプリ向けのオープン ソース アーキテクチャおよびデプロイメント モデルである、モダン アプリ リファレンス アーキテクチャ(MARA) の最初のイテレーションです。 気に入っていただき、使用していただき、盗んでいただき、さらには改良したりカスタマイズしたりするために修正したりフォークしていただければ幸いです。 この投稿では、私たちが構築したものとその仕組みについて説明します。

NGINX モダン アプリ リファレンス アーキテクチャのトポロジを示す図
NGINXモダンアプリリファレンスアーキテクチャ

現代の適応型アプリケーションの定義

まず、理想的な最新の適応型アプリケーションを定義しましょう。 マイクロサービスで構成され、コンテナ化され、クラウドネイティブの設計原則（疎結合、拡張が容易、インフラストラクチャに縛られない）に準拠している場合もありますが、必ずしもそうである必要はありません。 現代のアプリケーションの精神の一部は、インフラストラクチャの抽象化を活用するように特別に設計することです。 この定義は単純ですが、すべてのリファレンス アーキテクチャの基本テンプレートを確立するため重要です。

最新のアプリケーション アーキテクチャの主要な柱には、移植性、スケーラビリティ、回復力、俊敏性などがあります。

  • 移植性- 複数の種類のデバイスやインフラストラクチャ、パブリック クラウド、オンプレミスにアプリケーションを簡単に展開できます。
  • スケーラビリティ- アプリは、世界中のどこでも、需要の急増や減少に合わせて、迅速かつシームレスにスケールアップまたはスケールダウンできます。
  • 回復力– アプリは、異なる可用性リージョン、クラウド、またはデータセンター内の新しくスピンアップされたクラスターまたは仮想環境に正常にフェールオーバーできます。
  • 俊敏性– 自動化された CI/CD パイプラインを通じてアプリを迅速に更新できます。最新のアプリの世界では、これはコード速度の向上とコードプッシュの頻度の増加も意味します。

リファレンスアーキテクチャの設計

私たちは、最新のアプリの定義と展開パターンの基本要件を満たすプラットフォームを作成したいと考えていました。 技術的な目標とは別に、私たちは最新のアプリ設計の原則を説明し、コミュニティに Kubernetes へのデプロイを奨励したいと考えました。 そしてもちろん、開発者、DevOps、プラットフォーム運用チームが試したり、変更したり、改善したりできる「盗用可能な」コードを提供したいと考えていました。 つまり、私たちが提供したいのは次のようなことです。

  • 簡単に導入でき、本番環境にも対応できるKubernetesアーキテクチャは、単なるおもちゃではありません。
  • パートナー製品がKubernetes上でどのように機能するかを強調するプラットフォーム
  • Kubernetes Ingress コントローラーを簡単に構築および展開するためのプッシュボタン
  • 将来の製品および提携の統合のためのテスト環境
  • プラグイン可能なデプロイメントフレームワーク
  • 発見と採用を簡素化するオープンソースコードの単一リポジトリ

ここでは、プラットフォームの最初のバージョンで行った設計とパートナーシップの選択について説明します (次のバージョンの計画については、 「バージョン 2 でのさらに多くの統合と柔軟性の向上」を参照してください)。 私たちは、リファレンス アプリをパートナーに開放することが、パートナーとコミュニティの両方のエンゲージメントを促進する鍵であると強く信じています。

コードの展開方法

サンプル アプリケーションをインストールしてデプロイするには、起動スクリプトを呼び出すコマンドを 1 つ発行し、次の Pulumi プロジェクトが指定された順序で実行されます。 各プロジェクト名は、リポジトリのルート ディレクトリを基準としたディレクトリ名にマップされます。 詳細については、 README を参照してください。

vpc - EKS で使用する VPC とサブネットを定義してインストールします └─eks - EKS をデプロイします
└─ecr - EKS クラスターで使用するために ECR を構成します
└─kic-image-build - 新しい NGINX Ingress Controller イメージをビルドします
└─kic-image-push - 前の手順でビルドしたイメージを ECR にプッシュします
└─kic-helm-chart - NGINX Ingress Controller を EKS クラスターにデプロイします
└─logstore - Elastic ログ ストアを EKS クラスターにデプロイします
└─logagent - Elastic (filebeat) ロギング エージェントを EKS クラスターにデプロイします
└─certmgr - cert-manager.io Helm チャートを EKS クラスターにデプロイします
└─anthos - Bank of Anthos アプリケーションを EKS クラスターにデプロイします

バージョン2ではさらに多くの統合と柔軟性が実現

当社の最初の取り組みでは、Kubernetes 環境に必要なすべての統合が提供されない可能性があることを認識しています。 Platform Ops は、スマートな選択（ただし無制限ではない）を実現します。 プラットフォーム オペレーション、DevOps、および開発者チームが新しいリファレンス プラットフォームを試用し、採用しやすくするために、近い将来、次のような多くの改善を計画しています。

  • Digital Ocean、OpenShift、Rancher、vSphere、その他のKubernetes環境を立ち上げる

  • NGINX Controller>と統合して、NGINX Plus Ingress Controllerを管理および監視します。

    [編集者注– NGINX Controller は現在F5 NGINX Management Suiteです。]

  • NGINX App Protectのすぐに使える構成を提供する
  • BIG-IP 、クラウドサービス、 VolterraなどのF5製品およびサービスとの統合
  • NGINX Service MeshとIstioベースのAspen Meshとの統合
  • Terraformやその他の自動化ツールとネイティブに統合
  • その他のCI/CDオプションのサポート
  • インフラストラクチャとアプリケーションサービス用に個別のクラスタまたは複数のクラスタを展開する

私たちの取り組みが、他のリファレンス プラットフォームのフレームワークとなり、あらゆる種類の差別化された最新アプリケーションを構築するための「盗用可能な」出発点となることを願っています。 Kubernetes は、最新のアプリケーションの構築と、プラットフォーム運用およびシフトレフト文化の強化の両方において非常に強力なメカニズムであるため、リファレンス アーキテクチャが拡張可能でプラグ可能であるほど、より優れたものになります。 私たちは、コミュニティの皆さんが私たちの仕事についてどう思うか、そしてさらに重要なことに、それを使って何を構築するかを知るのを楽しみにしています。

リファレンスアーキテクチャの使用を開始する

弊社のリファレンス プラットフォームをダウンロードして、ぜひお試しください。 あなたのご意見や、次に何を構築してほしいかをお知らせください。 プルリクエストは大歓迎です。 私たちは、コミュニティとすべての開発者に恩返しできる、次世代のモダンで適応性に優れた「盗用可能な」アプリケーションの開発で、皆さんと協力したいと考えています。

関連記事

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

F5 NGINX に関するブログ投稿をもっと読む ›

「このブログ投稿には、入手できなくなった製品やサポートされなくなった製品が参照されている場合があります。 利用可能な F5 NGINX 製品およびソリューションに関する最新情報については、 NGINX 製品ファミリーをご覧ください。 NGINX は現在 F5 の一部です。 以前の NGINX.com リンクはすべて、F5.com の同様の NGINX コンテンツにリダイレクトされます。"