麻酔なしで本番環境にJavaコードをパッチする

ここでは、Odnoklassnikiプロジェクトのさまざまなサービスの開発に役立つ多くのツールの1つのデバイスについて説明します。 社内では「ホットコード置換」（HCR）と呼ばれ、このツールは、運用サービスを停止することなく実行する際の重大で単純なバグを修正するように設計されています。 これは非常に重要な機能です。これは、修正された新しいバージョンのジャンクサービスをレイアウトするというかなり退屈で時間のかかるプロセスを回避し、各ホストの可用性のアテンダントが十分に長い間停止するのを回避し、キャッシュのフラッシュを回避できるためです。



一般に、多くの時間を節約し、エラーが検出された瞬間から修正までの間隔を数時間から数分に短縮します。 ほとんどの場合、計画どおり、コードの軽微なエラーが修正されます。たとえば、プログラマーがnullをチェックするのを忘れ、一部のユーザーはサイトでの特定のアクションによってエラーが発生します。 つまり、メソッド内の複数の行を変更して修正を実行する場合です。 また、このような小さな変更のために、同僚の注意をそらし、生産のために何時間も手間をかける必要がなくなりました。



例：





簡単に修正できます：





もちろん、次の更新を待たずに、はるかに多くの変更を加え、同時に新しいクラスを追加し、マネージャーが同時に要求する変更をすばやく行うことができます。 しかし、これはすでに、ムッシューが倒錯について多くのことを知っているならです。



さらに、互いに「パッチ」を無限に配置することができます。



ただし、このツールは全能ではなく、Javaクラスが提供する標準機能java.lang.instrument.Instrumentationとそのメソッドvoid redefineClasses（ClassDefinition ... definitions）に基づいています。



Instrumentation.redefineClassesは、以前にロードされたクラスを新しいバイトコードに置き換えます。 異なる依存関係を持つ複数のクラスを同時にオーバーロードできます。 オーバーロードは、既存のクラスインスタンスを変更せず、継承を変更せず、インスタンスまたはクラスフィールドに影響しません。 メソッドの本体、定数と属性のプールのみを変更できます。 新しいクラスまたはサブクラスを追加できます。 メソッドシグネチャ、インスタンスフィールド、およびクラスフィールドは変更できません。 互換性のない変更を行おうとすると、redefineClassesは原則として機能せず、エラーをスローします。 クラスがオーバーロードされると、コードのオーバーロードされたセクションの実行が中断されず、次回同じメソッドが呼び出されたときに新しいバイトコードが使用されることに注意してください。 したがって、内部に無限に長いサイクルがあるメソッドのコードを修正しようとすると、実際の置換はこのサイクルが終了した後にのみ発生します。



非常に単純な場合：メソッドとポイント内でのみコードを変更できます。



そして、メソッドが完了するまで修正されないwhileループの例を次に示します。







主な困難は、確立されたすべての作業プロセスに適合するツールであるOdnoklassnikiエコシステムで機能するツールを作成することでした。 これは、何百ものホスト上のすべてのサービスと一貫して透過的に対話するだけでなく、柔軟で使いやすいものです。 このツールは、本番環境で継続的に発生する多数の実験、作業、更新に対処する必要があります。



開発者/管理者の観点から、本番環境でバグを修正しようとするパッチをインストールするプロセスはどのように見えますか？ コード内のエラーを見つけて修正するプロセスは省略します。



1.コードを修正するために、GITに別のブランチが作成されます。 バージョン管理の使用は、利便性のためだけでなく、その後の調査のためにも非常に重要です。



2. TeamCityがパッチビルドプロセスを起動します。 最初に、指定されたブランチからプロジェクトアセンブリが作成され、次に、新しいアセンブリが実稼働環境にインストールされたアセンブリと比較されます。 これを行うために、アーカイブからすべてのファイルを抽出し、矛盾を比較し、変更または追加されたファイルのみを選択するビルドツールのプラグインを作成しました。 この場合、両方のアセンブリのJavaコンパイラのバージョンは同じである必要があります。 コンパイラの別のバージョンでは異なるファイルが作成され、ほぼすべてのプロジェクトファイルがパッチに含まれます。 必要なファイルのみが取得される小さなアーカイブを作成することは非常に重要です。 これにより、パッチを多数のサーバーに配信するプロセスが大幅に高速化されます。 ビルドプロセスは、プロジェクトコードのパッチに適しているだけでなく、プロジェクト内のパッチを適用したライブラリを置き換えることもできます。 2つのアセンブリの内容を比較すると、ライブラリ（jarファイル）に違いが見つかります。



3.ビルドが成功した場合、パッチは特別なリポジトリに送信され、結果ウィンドウでキー（またはハッシュ）が発行されます。これは、パッチを一意に識別するために必要です。







何度も何度もパッチを適用でき、同じバージョン番号のビルドはハッシュが異なります。



4.次に、すべてのアクティビティが設定サービスに転送されます。通常のUIでは、どのサービス、どのホスト、どのバージョンのアプリケーションにパッチを適用するかを指定できます。







このように豊富なパラメーターは、必要なレベルの設定の柔軟性を提供します。これは、多くのサーバーの大きな動物園で非常に重要です。 サーバーの一部では、アプリケーションのバージョン番号が異なっており、このコードにパッチを当てる必要はまったくないとしましょう。 または、検証のために、Hot Code Rreplaceが最初に単一のサーバーまたはサーバーのグループで起動され、次にアプリケーションのすべてのインスタンスに分散されます。



5.構成の変更により、選択したサービスは、インストールする必要のあるパッチの種類、バージョン、および検証ハッシュに関する情報を受け取ります。 考えは、すべてのサービスが「パッチをインストール」コマンドを受信し、それから独立して動作するということです。 独自にバージョンを比較し、バージョンが一致し、パッチのハッシュが欠落しているか異なる場合にのみ、リポジトリからパッチアセンブリを個別にダウンロードします。 ダウンロードプロセス自体はHTTPを介して行われ、リポジトリアドレス、ダウンロード試行回数、および再試行間の待機時間をすばやく変更できます。



6.各アプリケーションは、アセンブリのハッシュをローカルで検証し、展開します。 同時に、各ファイルは、Instrumentation.getAllLoadedClasses（）によって返された配列の中で配列内に存在するかどうかをチェックし、すべての新しいクラスとファイルは新しいクラスと一時クラスパスに書き込まれます。 redefineClassesメソッドをパススルーします。



7.プロセス全体：アプリケーションのパッチ適用の必要性に関するシグナルの到着、そのダウンロード、検証、解凍、およびアプリケーションは、アプリケーションの一般ログと独自のログの両方で詳細に記録されるため、不必要なジェスチャーなしでプロセスを監視できます。



8.パッチの正常な適用後、プロセスは、パッチのハッシュを含む特別に構成された行を追加することにより、アプリケーションのバージョンをパッチが適用されたバージョンに変更することで終了します。 ホストのバージョンが予期したバージョンに変更されていない場合は、そのホストのホットコード置換ログに移動し、そこで起こったことを確認します。 これらが通信の問題である場合は、パッチコマンドを安全に繰り返すことができ、目的のホストが再試行します。



アプリケーションにパッチを適用できない可能性のある問題は何ですか？ それらのかなりの数があり、それらの中で、私は最後にインストルメンテーションクラスの機能を置きます。 これまで、redefineClassesの厳密な条件を満たさない曲がったコードは、アプリケーションに影響を与えることなく、常にJVMによってフラッシュされていました。 redefineClassesメソッドを使用すると、JVMはアプリケーションを完全に停止しますが、このプロセスには一瞬かかります。 怖くないからです



最も危険な瞬間は、追加の再訓練によって決定されたサーバーへのパッチの配信です。 ただし、再トレイが役に立たない場合は、コマンドを繰り返してパッチを呼び出すことができ、各ホストはプロセスを繰り返しますが、必要な場合にのみパッチをインストールします。 パッチが以前にインストールされていないか、ハッシュキーが変更されている場合。



修正プログラムが1つのエラーを修正し、新しいエラーを追加する場合の別の潜在的な問題。 このリスクを最小限に抑えるために、まず、限られた数のサーバーにパッチをアップロードし、ログ、チャートを確認して結果を監視します。 その後、修正を他のホストに展開します。



アプリケーションまたはサーバーを再起動するとどうなりますか？ これは、すべてのクラスメートアプリケーションのロジックに既に組み込まれています。アプリケーションの最初の1つはHCRモジュールです。 また、初期化中にアプリケーションにパッチを適用する必要性に関する情報が通知された場合、パッチが最初に適用されます。



そして、Hot Code Replaceの構成について少し説明します。

1. JavaAgent。 JavaAgentは、誰かが忘れた場合 、これはアプリケーションが追加パラメーターを使用して起動するときにJVMによって取得される、特別に形成された別個の* .jarアーカイブです。たとえば、-javaagent：/path/to/lib/my-agent.jar Javaagent-の追加機能のおかげそして、コード置換マジックを使用することが可能です エージェント内でjava.lang.instrument.Instrumentationクラスを使用できます。 しかし、余分なコードで彼（エージェント）を詰まらせませんでした。 エージェントの更新は重要なタスクですが、Instrumentationクラスのインスタンスをユーティリティクラスの静的フィールドに移動するだけです。 したがって、すべての操作は、アプリケーション内のどこからでも開始できます。
2. 構成サービス-アプリケーションの構成を担当するため、各アプリケーションで最初に初期化されます。 Hot Code Replaceの主な機能が隠されているのはそこです。 アプリケーションを起動するか、特定のアプリケーションのHCR構成を変更すると、バージョンの互換性がチェックされ、上記のすべての操作が実行されます。
3. TeamCityおよびビルドスクリプト-「パッチ」を簡単に作成し、変更または追加されたクラスとリソースのみを保存します。

このツールの利点は何ですか？ 1つは、製品の重大なエラーを修正する速度です。 ログから、リリースを待つのではなく、同僚がだんだんとHCRを使用し始めたことがわかります。 次はアプリケーションの速度です。 アプリケーションを停止する必要はありません。JVMは一瞬だけフリーズし、すべてのオブジェクトはその場所に残り、動作を続けます。



そして、当社の開発者は、サーバーの数や負荷に関係なく、本番環境で即座に独立して、自由に、そして楽しく癒し、間違いを直しました。