実行中のサーバーでアプリケーションコードを更新する

多くの組織は毎日、負荷の高いシステムの作業を維持する必要に直面しています。膨大な数の操作は、その適切な機能に依存します。 このような状況では、サーバーコンポーネントまたはソフトウェアアプリケーションコードの更新のためにシステムが中断される状況を想像することは困難です。 そして、Facebookでの写真のアップロードやビデオの再生の停止が重要でない場合、金融、軍事、または航空宇宙産業では、処理操作の最小限の遅れでさえ悲惨な結果になります。

これらのオペレーションの規模をよりよく理解するには、銀行がクライアントに数百万ドルの支払いをすることができなかったか、またはヒースロー空港の制御システムのいずれかが離陸中にアップグレードすることを決定したことを想像してください。 このようなシナリオは、今日の現実ではほとんど受け入れられません。

それでも、必然的にアプリケーションサーバーを更新する必要があります-これから逃れることはできません。 そして、それらへの一定の負荷を考えると、更新中のアプリケーションの中断のない動作の問題はこれまで以上に重要になります。

更新中にアプリケーションをスムーズに動作させるには何が必要ですか？

この問題を解決するにはいくつかの方法があります。

1. 過剰な数のアプリケーションサーバーまたは環境（クラスター）を作成する。
2. アプリケーションサーバーまたは直接アプリケーションの特別な機能。

近年、鉄の安価化、クラスターの開発傾向、過剰なアプリケーション、複雑な分散システムでの作業に必要なその他のリソース（データベース、追加ディスク（異なるタイプのRAID）、信頼性などのために同じリソースのネットワークインターフェイス）。

ただし、この記事では、2番目のオプション、つまり、負荷がかかっても機能し続ける別のサーバー上のアプリケーションコードを更新する可能性に焦点を当てたいと思います。

誰がそのようなソリューションに興味があるのでしょうか？

過剰な数のアプリケーションサーバーまたは環境を作成すると、より高い信頼性が得られますが、それに比例して多くのリソースが必要になります。 さらに、このようなクラスターの動作を保証することははるかに困難です。 要するに、これは常に正当化されるわけではありません。特に、リソース集約度の問題がはるかに深刻な小さなソリューションの場合です。

この点で、クラスタリングのないアプリケーションは別のニッチを占有し、過剰な数のアプリケーションサーバーまたは環境を使用する際のいくつかの困難を回避できます。そのようなアプリケーションはリソースの消費と使いやすさに明らかにメリットがあるからです。

複雑なアプリケーションの開発の機能

複雑なアプリケーションの開発の原則の1つは、モジュールが疎結合されているモジュール式アプリケーションの構築です。 Javaの世界では、彼らはそのようなテクノロジーをJDK 7に含めることを望んでいましたが、後にJava 8と一緒にリリースすることを決めましたが、現在の発表から判断すると、2017年3月のJava 9よりも早くジグソーモジュールの相互作用のメカニズムとして表示されます。

モジュール方式の原理のおかげで、そのようなアプリケーションは、負荷がかかっていても動作中に更新できます。 最新のJavaバージョンのリリースを待ちたくない人は、アプリケーションを開発するためにモジュラーアプローチを取ることができます。この技術はOSGiと呼ばれ、その最初の仕様は2000年代初頭に登場しました。 クラスタリングなしで負荷のかかったアプリケーションコードを更新することは、PCとモバイルデバイスの両方に適用できます。 さらに、必要なリソース（CPU、メモリ、ディスク）が少なくなり、セットアップとテストにかかる時間が短縮されます。

しかし、雲はどうですか？

クラウドサービスの人気が高まっているため、このトピックに触れずにはいられません。
更新の問題を解決するには、実際に仮想IPアドレスを作成し、そこから複数のアプリケーションノードへの分散を構成し、それらを順次更新します。 さらに、異なるバージョンのアプリケーションがシステムに同時に存在します。 これは、アプリケーションの思慮深い設計を考えれば可能ですが、それらに追加の要件を課します。 実際、アプリケーションはデータから完全に独立している必要があり、ステートフルであってはならず、システム内の異なるバージョンの可用性が許容されるように設計する必要があります。 実際、これには複数のアプリケーションの同時操作が含まれ、それらの管理に追加のコストがかかります。 ただし、クラウドテクノロジーとOSGiは相互に排他的ではないことに注意してください。 OSGiアプローチは、クラウドで使用することもできます。クラウドでは、特に鉄からの抽象化が伴います。

したがって、クラウドサーバーを使用すると、OSGiの原則に従ってアプリケーションモジュールを個別のクラウドノードに分割し、各ノード上のすべてのモジュールで本格的なアプリケーションを起動して冗長性を確保できます。 これらの方法のどれを選択するかは、主に組織のリソースに依存します。

OSGi仕様とジグソーパズルの主な違いは何ですか？

もちろん、今後のJavaアップデートを考慮してOSGi仕様を使用することの適切性を理解するためには、これらのソリューションがどのように異なり、互換性があるかどうかを理解する必要があります。 以下の表を見てみましょう。

OSGi	ジグソーパズル
2000年から存在し、有効性が実証されている完全に機能するメカニズムです。	開発中です。Java9まで利用できません。
別の仕様です。	Java 9プラットフォームに完全に統合されます
かなり使いにくい	JPMSは、OSGiよりも使いやすいことを目指しています。 それにもかかわらず、非モジュラーに基づくモジュラー製品の作成が複雑さの主な原因です。 したがって、ジグソーパズルはOSGiをはるかに簡単にする可能性が低い
外部からは見えないため、内部モジュールクラスをロードすることはできません。 つまり、私のモジュールのクラスローダーは、他のモジュールから明示的にインポートされたタイプだけでなく、私のモジュールの内部タイプのみを見ることができます	同じブートローダークラスにあるため、各タイプは他のタイプを認識します。 確かに、JPMSは二次チェックを追加して、ロードされるクラスがロードしようとしている型にアクセスできることを確認します。 他のモジュールからの内部型は、パブリックと宣言されていても、実際にはプライベートです
複数のバージョンのアプリケーションを同時に操作できます	一度に1つのモジュールの複数のバージョンを持つことはできません。
製品ライフサイクル管理があります	製品ライフサイクル管理なし
リアルタイムの動的モジュール性	静的展開モジュール
内容が相互に重複するモジュールを持つことが許可されています	内容が互いに重複しているモジュールを持つことは不可能です

基本的な互換モードでは、OSGiフレームワークとキットは「名前のない」Jigsawモジュール内に完全に存在します。 OSGiは、強力なレジストリと動的ブートに加えて、すべての分離機能を引き続き提供します。 OSGiへの投資は安全です。これは、新しいプロジェクトの仕様が引き続き優れた選択肢になるためです。

OSGi仕様で作業することの特性は何ですか？

OSGi仕様は、コンポーネントが疎結合環境で動作するモジュラーアプリケーションの使用に基づいており、アプリケーション間の対話パスは構成ファイルで構成されます。 このようなアプリケーションモデルにより、ノードはコンポーネントであり、ブランチはノード間の接続であるネットワーク（グラフ）と見なすことができます。 この接続では、一方向または双方向のいずれかです。

そのようなプログラムのコードを更新する場合、最初に次の点を分析する必要があります。

1. 更新する必要があるノード。
2. 影響を受けるアプリケーションブランチ。

分離された分散環境でのコンポーネントの相互作用には、主に同期（サービス経由）と非同期（メッセージ使用）の2つの方法があることに注意することが重要です。

それらは次のように機能します。疎結合環境では、サービスを使用するか、メッセージを使用するか、両方を使用して相互にやり取りできる特定の数のモジュールがあります。 特定のモジュールの更新中、メッセージはキューに蓄積され、サービスは宛先モジュールが更新されるまで途中で待機します。

サービスの分析は、OSGiフレームワークのオープンな実装を介して実行され、メッセージの分析はアプリケーションコード（この場合、リアルタイムフレームワーク（RTF）アプリケーションについて説明します）を使用して行われます。 これにより、コンポーネントインタラクションルートのどの時点でメッセージを一時的にキューに蓄積する必要があるか（コンポーネントがインタラクションする）を理解したり、呼び出されたサービスを一時的に中断したりして、アプリケーションアプリケーションコードを更新した後すぐに作業を続けることができます。 その結果、アプリケーションコードは次のバージョンに更新されますが、メッセージはキューに蓄積され、サービスはスタンバイ状態になります。つまり、更新中に影響を受けるルートは使用できなくなります。 したがって、アプリケーションサーバーを再起動する必要はありません。これにより、アプリケーションのアクセス不能時間が大幅に短縮されます。 さらに、アプリケーションは更新中に一時停止した場所から正確に動作し続けるため、キャッシュを再度ダウンロードする必要はありません。

効果的な作業を行うには、接続されていないコンポーネントの相互作用ルートが最大になるようにアプリケーションを設計し、それらが更新されたときに、そのようなルートと提供サービスが機能し続けるようにすることが重要です。

さらに、APIに影響を与えることなく更新しやすくするために、APIを実装から分離する必要があります。 なんで？ 比較のために：アプリケーションサーバーは通常、数分で、理想的な場合-20〜30秒で起動し、実行中のサーバーのコンポーネントの更新には2〜5秒しかかかりません。すべてのサービスデータをメモリ（キャッシュ）に再度読み込む必要はありません。

負荷のかかったコードを更新するためのリアルタイムフレームワーク（RTF）アプリケーション

RTFは、モジュールベースのアプリケーションであるOSGi仕様に基づいた商用Netcracker製品です。 OSGi仕様自体は、特定の依存関係によって接続された多くのモジュールの作業のいくつかのバージョンを同時に持つ機能のみを提供しますが、モジュール間の同期および非同期接続の構築とコンポーネントの更新作業は、RTFアプリケーション自体の能力の範囲内です。

RTFの特徴は 、OSG​​iの機能を拡張し、運用中にアプリケーションのソースコードを更新できるだけでなく、負荷がかかった状態でも実行できることです。 つまり、「アプリケーションを一時停止」し、更新されたアプリケーション上ですでに通常モードでリクエストを実行し、実行を続けることができます。

また、コンポーネント間でメッセージを送受信するための軽量のトランスポートを提供し、データベースにメッセージを保存せずにJavaで実装されます。 このようなトランスポートを使用すると、疎結合コンポーネントの分散システムでコンポーネントの相互作用を整理できます。 コンポーネントの相互作用のメカニズムは、次の図を使用して説明できます。


コンポーネントは直接対話しないことに注意してください-各コンポーネントはメッセージの受信者に関する特別な知識を持っていません。 同時に、メッセージでは<key-value>という形式のデータセットを送信できます。これは、送信者と受信者の両方にとって十分に抽象的です。

メッセージは、それぞれ送信ポートと受信ポートを使用して、受信ポートを介して送信されます。 メッセージを送信するためのルート設定は特別なxml構成ファイルで定義されますが、メッセージのフィルターを追加で設定できますが、オプションの1つはいくつかのパラメーターまたはその値の有無を使用することです。

RTFの使用例

RTFテクノロジーは新しいものではなく、その有効性を繰り返し実証しています。 1つの例は、RTFアプリケーションに基づいてAxiaの請求サービスをゼロから設定することです。 実装はスタンドアロンで、つまりクラスタリング機能を使用せずに実行されました。 この場合、支払い処理の仕様ではわずかなエラーや操作の遅延が許容されないため、コンポーネントの更新中でもシステムの安定した動作を確保することがこれまで以上に重要でした。

最近、MANO（管理およびオーケストレーション）の多数の開発が進行中です。 この場合、RTFテクノロジーを使用して、システムモニター（ハードウェアの状態を監視）とネットワーク仮想化モニター（VNF）を操作します。 すべての作業がオープンスタックで実行されることは注目に値します。これにより、RTFテクノロジーとクラウドサービスの完全な互換性が再び確認されます。 例としては、日本の通信事業者であるNTTドコモのネットワーク仮想化に関するNEC / Netcrackerの取り組みがあります。 このプロジェクトにより、企業はコアネットワークの電力を柔軟に変更できるようになり、機器の障害が発生した場合の復旧時間も大幅に短縮できます。

結論

この記事では、OSGi仕様を満たす商用RTFアプリケーションサーバーの例を使用して、負荷がかかっているサーバーでアプリケーションコードを更新する方法の1つを示します。 RTFを使用すると、アプリケーションを構成するモジュールの相互作用を一時停止し、すべてのメッセージとサービス（同期呼び出し）をキューに入れて待機し、必要なモジュールを更新して、中断の瞬間からアプリケーションを起動できます。 同時に、アプリケーションが動作したデータは消えませんでした。 説明されているコードの更新方法は、何らかの理由でクラスタリングを使用せず、アプリケーションを複製したくなく、構成とテストのリソースを節約したい人に主に適しています。 良い例は、Axiaの請求システムの開発です。

同時に、RTFテクノロジーは、クラスターとクラウドサーバーを使用している企業でも効果的に使用されています。 RTFのおかげで、要求の更新時に数秒間処理されず、更新後すぐにアプリケーションが動作し続けるため、アプリケーションを継続的に使用できます。 これにより、組織はデータの一部を失うことなく、アプリケーションコードを柔軟に更新できます。 さらに、実行中のサーバーでモジュールを更新するのに2〜5秒しかかからないため、アップグレード後にアプリケーションをダウンロードする時間が大幅に節約されます。その後、サービスデータをキャッシュに再度読み込む必要はありません。