HCS は NGINX を使用して柔軟なフロントエンドapplication層を構築します

多様な利害関係者とユーザーを抱えるオランダの政府機関は、ワークフローを紙ベースのプロセスから最新のデジタル インフラストラクチャに移行したいと考えていました。 これにより、当局はより迅速に行動し、ユーザーと従業員の生活が簡素化されるでしょう。

挑戦ですか? 当局は、参加する各地域が独自のプロセスと要件を作成することを許可しました。 当初、代理店は、多数のカスタマイズを備えた包括的なモノリシックapplicationを作成するために多大な労力を費やしました。 最初の取り組みは、過剰なカスタマイズの重圧の下で失敗しました。つまり、「千の要件による死」です。 HCS 社オープンソースと Red Hat® テクノロジーを専門とするオランダの IT コンサルタント会社である が、異なるアプローチで機関のプロセスをデジタル化する新しい方法を試すために選ばれました。

シンプルな再構築: 構成可能なマイクロフロントエンド、コンテナ、マイクロサービス

同社の DevOps チームは、HCS の主任サイト信頼性エンジニア (SRE) である Benoit Schipper 氏と協力してこのプロジェクトに取り組みました。 彼らは一緒に、解決しようとしている問題をより深く検討することから始めました。 政府関係者から弁護士、会計士、一般市民に至るまでのユーザーは、機関アプリにログインし、プロジェクトやプロセスのステータスを確認し、PDF をアップロードする必要があります。 Benoit 氏とチームは、ソリューションの出発点としてシンプルな基盤を構築することを決定しました。 ブノワ氏は次のように説明しています。「私たちはそれを見て、『非常に汎用的なものを作ろう。そして、特別なリクエストがあれば、その汎用的な基盤から構築できる』と言いました。」 DevOps チームは、既存のインフラストラクチャ内と、将来必要になる可能性のある追加の場所やapplicationsの両方でスケーラビリティを確保し、基盤を将来的にも使いやすくしたいと考えていました。

Benoit 氏とチームはその将来をホワイトボードに描き、バックエンドの小さく個別のサービス (マイクロサービス) にマッピングされたさまざまなapplicationsに構成できる、非常に小さな (マイクロ) フロントエンドの新しいアーキテクチャに到達しました。 「マイクロサービスを選択したのは、そのアーキテクチャであれば、規模が拡大したときにクラウドに移行して拡張する準備が整っているからです」と Benoit 氏は言います。 「私たちはパズルを、くっつけることができる小さなピースに分割しました。」

実装に関する最初の決定は、専用環境の Microsoft Windows サーバーから、構成可能で柔軟なマイクロサービスに適したクラウド内のコンテナーベースの環境に移行することでした。 チームはコンテナ プラットフォームとしてRed Hat OpenShift® を選択しました。

OpenShift が有利な要因は 2 つありました。 まず、RedHat は政府との協力において長年の経験があったため、設計に対する政府の承認を得るのが容易でした。 2 番目に、OpenShift には、マイクロサービスとマイクロサービス アーキテクチャの構築と保守を容易にするために設計された、次のような多くのツールとapplicationsが含まれています。

• Red Hat Ceph® Storage – S3 準拠の API 経由でアクセスできる BLOB ストレージ サービス
• Red Hat AMQ Broker – ワークロードとapplicationの状態を管理し、ワーカーをキューイングするためのメッセージバスサービス
• Kubernetes の組み込み認定サポート – HCS と機関が Kubernetes がコンテナ オーケストレーションに適したツールであると判断した場合、将来の保証のために重要

Windows から Linux、.Net Core、NGINX オープンソースまで

コンテナに移行するということは、Windows サーバー上で実行されていた同機関の以前の .Net バックエンドを置き換えることを意味しました。 幸いなことに、コンテナ向けに最適化された .Net のバージョンである.Net Coreへの移行は簡単でした。 さらなる利点として、代理店の開発者は使い慣れた Windowsapplication言語とフレームワークでコーディングを継続できます。

DevOps チームは、.Net Core バックエンド サービスにアクセスするための REST API のコア セットを構築しました。 API は、applicationの機能とロジック、およびマイクロフロントエンドを結び付ける接着剤のようなものです。 フロントエンド環境については、強力なコミュニティを持つ堅牢で信頼性の高い JavaScript フレームワークとして政府機関に広く受け入れられていることから、チームはAngularJS を選択しました。

フロントエンドとバックエンドの間で行き来するトラフィックと API 呼び出しのための統合ルーティング レイヤーを作成するために、チームはさまざまなオプションを検討した後、その汎用性からNGINX Open Source を選択しました。 代理店の Web サイトのページは、コンテンツ要素を取り込み、同じ CSS ロジックを使用して複数のバックエンド サービスを「スキン化」することで、マイクロ フロントエンドとして即座に構築されます。 ユーザーにとっては、すべてが同じapplication内で行われているように見えますが、「実際には、NGINX によるスマート プロキシと書き換えを使用しています。フロントエンドに適切な情報を画面に表示するために、NGINX 経由でバックエンド API 呼び出しを行っています」と Benoit 氏は説明します。

applicationをパブリック インターネットに公開するために、Benoit は、機関の DMZ で実行されている仮想マシン上に、Web サーバーおよびリバース プロキシとしてF5 NGINX Plusインスタンスを導入しました。 彼は、NGINX Plus が最適な理由を次のように説明しています。 「TLS 1.3 が必要だったので、すぐに移行したいと考えていました。 専用アプライアンスに比べて手頃な価格で、ライセンスの追加も簡単にできました。」

Benoit 氏は、同社にとって「NGINX は Web サーバー、プロキシ、およびapplication層の基本的な API ゲートウェイとして機能します」と強調しています。 まさに、ほぼ何でもできるスイスアーミーナイフ™です。 だから私たちはそれを使うのです。」 たとえば、アップロードされた PDF を取得するには、ユーザーは自分のアカウントにアップロードされたドキュメントから必要な PDF を選択し、PDF 配信applicationはCeph オブジェクト ストアに接続されたバックエンドの PDF 取得サービスにリクエストを送信します。 Ceph は、オブジェクト ストア内の PDF の場所の一意の URL を返します。ユーザーはこの URL をクリックして、表示またはダウンロードします。

applicationはミッションクリティカルであるため、チームはすべてのapplicationsが少なくとも 2 つのクラスターで実行されるアクティブ/アクティブの高可用性アーキテクチャを設計しました。 これにより、すべてのサービス、マイクロフロントエンド、API に冗長性が提供され、いずれかのクラスターで障害が発生した場合でも、それらが継続して機能することが保証されます。

パフォーマンスを向上させ、複数のサービスにまたがる複合applicationsのコントロール プレーンを有効にするために、チームは AMQ Broker メッセージ バスを使用してサービスのトピックとキューを構成します。 「したがって、バックグラウンドで実行できるものはすべてバックグラウンドで実行します」と Benoit 氏は言います。 「メッセージが届き、メソッド データを調整する必要がある場合、何かを処理したり、プロセスを実行するワーカーを見つけたりできるリスナーがあります。」 クラスター全体のユーザーの状態の一貫性を確保するために、チームは既存の高可用性Microsoft SQL Serverデータベース インフラストラクチャを保持し、ポッドの状態を維持し、セッションの永続性を実現しました。

可観測性、拡張性、柔軟性を考慮した設計

可観測性のために、Benoit はクラウド ネイティブ ダッシュボードとしてGrafana を推奨しました。 NGINX メトリクスを取得するために、DevOps チームは各ポッドとペアになったサイドカーでNGINX Prometheus Exporter を活用します。 エクスポーターは、NGINX オープンソーススタブ ステータス モジュールとNGINX Plus APIからレイヤー 4 メトリックをスクレイピングし、それぞれを文字列と照合してキーと値のペアを作成し、そのペアをPrometheusにプッシュします。 そこから、ペアは開発者と DevOps チームにのみ公開される別の Grafana インスタンスに公開されます。 「すごいですね。 すべての NGINX Open Source および NGINX Plus インスタンスにわたってダッシュボードを構築し、メトリックを 1 か所で収集できます。 DevOps チームが制御します。 「何が実行されているかを確認し、問題があればアラートを受け取ることができます」と Benoit 氏は言います。

チームは、applicationのパフォーマンス管理にもメトリックを使用します。 Prometheus は、applications内の例外と未処理の接続に対してアラートを生成し、実行中のワーカーが十分でないことを通知します。 Benoit は、メトリクスを OpenShift の自動スケーリング機能にリンクしました。 彼は次のように説明しています。「特定の数のワーカー向けに NGINX セットアップを構成し、必要な RAM と CPU を計算しました。 ベースラインに対して負荷がかかりすぎると、OpenShift が自動的にスケールアップしてアラートを送信します。」

侵入テストにより、applicationsが強力なコンテンツ セキュリティ ポリシー (CSP) を使用していないことが判明したため、チームは CSP をインラインで適用するためのポリシーを使用して NGINX Open Source と NGINX Plus を構成することができました。 また、コンテナ プラットフォームから JSON ログ情報を取得し、履歴分析と記録保持のためにSplunkログ プラットフォームに送信するカスタム構成も設定しました。

開発者エクスペリエンスの向上

HCS は、Google Analytics とLighthouseを使用するフロントエンド開発者向けに、NGINX 構成にコード化された Lighthouse チェックを代理店のパイプラインに組み込むことを可能にしました。 「GZIP 圧縮ライブラリに変更することで、パフォーマンスを大幅に向上できることがすぐにわかりました」と Benoit 氏は語り、その結果、applicationのレイテンシが 60% 改善されました。

さらに、新しいアーキテクチャにより、開発者はリアルタイムの動作を詳細に把握できるため、エンドユーザーと直接連絡を取ることができるようになりました。 「フィードバック ループははるかに高速で、何かが起きて変更が必要になった場合でも、わずか 1 日で本番環境に導入できます。 「これは政府にとっては非常に速いことだ。これまでは変化に何ヶ月、あるいは何年もかかっていた」とブノワ氏は言う。 「当社の開発者にとって、これは昼と夜の違いのようなものです。」

技術スタック

• バックエンド– .Net Core
• フロントエンド– AngularJS
• ネットワーク(Web サーバー、リバース プロキシ、API ゲートウェイ、Ingress コントローラ、グローバル ロード バランサ) – NGINX Open Source 、 NGINX Plus 、 F5 BIG‑IP 、 HAProxy (OpenShift 上)
• データベース– Microsoft SQL Server 、 Red Hat Ceph Storage 、 Lighthouseデータ用のInfluxDB
• CI/CD – Azure DevOps
• インフラストラクチャ– Red Hat OpenShift 、Linux コンテナ
• メッセージング– Red Hat AMQ Broker (Active MQ オープンソース)
• 可観測性とメトリクス– Grafana 、 Prometheus
• ロギング– Splunk

始める

NGINX Plus 上に技術スタックを構築して、このプロジェクトの素晴らしい結果を再現してみませんか? 今すぐ30 日間の無料トライアルを開始するか、使用事例についてご相談ください。