OpenAI / Codex：PerlからPythonへの重要なインフラの移行

デジタル トランスフォーメーションは、デジタル ディスラプションと呼ばれることもあります。長い年月を経て発生してきた主要なテクノロジの変化は、初期の段階で何らかの悪影響を及ぼしていないかぎり、特定することは困難です。では、ミッションクリティカルなサービスに悪影響が及ぼされる可能性がある場合、テクノロジ スタックを進化させるにはどうしたらよいでしょうか。

これは、NetAppでDevOps / テスト インフラを担当する社内チーム、BAEROにとって頭の痛い課題でした。BAEROは、開発者がコードを送信する前のビルドやテストに使用するツールやサービスを提供しています。BAEROの役割は、開発者の迅速な対応、品質問題の早期発見、NetApp^®製品のリグレッションからの保護を支援することです。私たちはこのミッションをサポートするために、長年にわたって大量のソフトウェアを構築してきましたが、これらのソフトウェアは新しい製品や機能が追加されるたびに、新しい環境に対応できるよう進化する必要があります。 

たとえば、NetApp ONTAP^®は現在Amazon FSxに含まれていますが、この機能を提供するには、ONTAPの開発者がリリース前に新しい機能をAWSで実行、テスト、デバッグしなければなりません。これらの要件に対応するために、BAEROはサービスとインフラを拡張してAmazon FSxと連携できるようにしました。大抵の場合、BAEROがサポートを迅速に追加できれば、NetApp開発者もコードのリグレッションをその分すばやく自動検出できます。

BAEROは、サポートは迅速に提供する必要がある一方で、NetApp開発チームが24時間体制で使用しているインフラは維持しなければならないという、バランスを取るのが難しい課題に悩まされています。現在使用されているBAEROのインフラ コードには、比較的新しいPythonと、数年前に作成され必要に応じて拡張されてきた強靭なPerlコードやライブラリが混在しています。残念なことにPerlのライブラリ エコシステムはPythonほど豊富ではなく、Perlを積極的に利用している開発者も少ないため、NetAppの新機能や製品をPerlコードでサポートするのは困難です。

一方、Pythonを使用すれば、開発チームでの迅速な対応が可能になり、次世代のNetApp製品を適切にサポートすることができます。とはいえ、果たしてミッションクリティカルなサービスを中断することなく、Perlで作成されたコードベースをPythonに変換することは可能なのでしょうか。

2021年8月にOpenAI / Codexが公開されたことにより、人工知能と機械学習を使用してコードを他の言語に変換する可能性が広がりました。たとえばBAEROの場合、PerlコードベースをPythonに変換できるようにはなりましたが、すべての製品で期待どおりの結果が得られるわけではなく、エラーがないか確信が得られるまで検証する必要がありました。Codexは実際の本番環境でもスムーズに機能するでしょうか？開発者グループよりも迅速かつ簡単にコードベースを変換できるでしょうか？それらを実証するには、（願わくばゼロになるまで）エラー検証を行うことが唯一の方法でした。

テストには、単体テストを実行し、解釈して結果を返すユーティリティ「run_utest.pl」を採用しました。また、このユーティリティはスクリプトとして、元々の設計を超えて進化してきました。元のコードは必要に応じて拡張され、コアダンプ分析、ファジング、コード カバレッジ、または特定のまれな障害が発生した場合の即時診断が追加されました。実際のランタイム環境で何年にもわたって拡張され続けたPerlスクリプトは、結果として巨大で複雑になりすぎ、検証にはとてつもなく時間がかかるようになりました。スクリプトは単体テストによる品質向上の要であり、あらゆる開発者によって1日に何百回も使用されるものなので、新しい言語に変換される場合は、スクリプトの正確さが損なわれないようにすることが非常に重要です。 

最初にCodexでコードを変換したとき、Codexには長所と短所があり、優れた変換が行われることもあれば、非常に品質の悪い変換が行われる場合もあることがわかりました。そのため、Codexを使用する場合は、作業の途中で開発者が正しい変換であるかどうかを検証し、エラーを修正しなければなりませんでした。そうは言っても、Codexは新しいPythonスクリプトを一から書くよりも検証が簡単で、有効な結果も得られました。

本質的に、Codexは非常に高速ですが、変換能力は完全ではありません。変換プロジェクトを高速化するためには、安全に使用する方法を見つけ出す必要がありました。変換されたコードは最初から完全に（または完全に近い形で）動作することが求められていました。「run_utest.pl」は通常のビルドで頻繁に使用されているため、「平常時」の状況を検証するのは簡単ですが、Perlバージョンで処理される（記述時に検証済みの）多くのコーナーケースやエラー パスは、検証がはるかに困難です。これらは、デプロイ時にPython変換で正常に動作する必要があり、エラーの発生は許されません。 

私たちは、新しいPython変換のリスクを軽減または排除することを重視しました。理想的には、エラーパスと平常時の状況の両方を検証する一連のテストを実施したかったのですが、残念ながら元のコードではバッキング テストがなかったので、新しいコードを手作業でテストし、新しいバージョンがデプロイされた後に問題が発生しないかを監視することで安定性を確認しました。 

変換のリスクには、以下の方法で対処しました。

• 途中でリファクタリングせずに、コードを直接変換：これにより、レビュー担当者はコードが両方の言語で同じ動作をするかどうかを容易に検証できます。また、機能テストとパフォーマンス テストを（機能ごとに）並行して行うこともできます。
• 少しずつ変換、テスト、レビュー、送信：レビュー対象のコードのサイズが小さいため、レビュー担当者は問題を見つけやすくなり、開発者はゆっくりでも着実に検証を進めることができます。 
• 古いコードと新しいコードを同じ入力でテスト：新しいコードは古いコードと同じように動作するため、出力時の違いを調査しました。
• 膨大な数の単体テスト：コードを1行ずつくまなくテストすることに重点を置きました。すべてのエラー パスを検出することは本質的に難しいですが、pytestではさまざまな種類のモックを利用できるため、コードのすべての行を検証できることもあります。

最終的に、新しいバージョンでは元のバージョンよりもはるかに優れたテストを行うことができ、すべてのコードを検証することで、平常時では現れなかった多くのエラー パス変換の問題を発見できました。

現在のところ、このポートには十分な機能が備わっており、単体テスト ワークフロー全体を実行できます。デプロイ前に単体テストのカバレッジ（0% -> 80%以上）を向上させる作業が継続されています。驚いたのは、元のPerl実装にバグがあったことです。Perlコードにはある種の終了コードが含まれていました。この問題は、現在の単体テスト インフラに潜んでいます。ごくまれな問題ですが、実際に発生しています。元々は変換に伴う問題のように見えましたが、調査の結果、PythonバージョンはPerlバージョンよりも厳格であることがわかりました。この問題を見つけられただけでも、変換プロジェクトが意義あることであったと言えるでしょう。

高いカバレッジでの単体テストと（Perl出力と並行して検証された）徹底的な統合テストを何度も繰り返し実施して、Pythonバージョンのrun_utestを単体テストの対象の約5%にデプロイしました。

元のPerlバージョンのrun_utestに潜んでいた単体テストのエラーを修正後は、100%になるまで時間をかけてデプロイしていく予定です。

OpenAI / Codexで非常に良い結果が得られたことで、準備は十分に整いました。OpenAI / Codexは、BAERO開発チームの可能性を言葉どおり変化させました。以前であれば、Pythonで新しいプロジェクトを記述しながらPerlのインフラを維持して、対応できない箇所が出てきた場合はPythonで書き直したりしていたかもしれません。NetAppの開発ツールボックスにOpenAI / Codexが含まれたことで、数多くのインフラ ソフトウェアの変換を検討できるようになり、プロジェクトを成功させるための青写真もできました。

まとめると、以下のことが言えます。

OpenAI / CodexはBAEROの作業を高速化させます。
OpenAI / Codexは、NetAppの開発者が新機能を迅速にテストできるよう支援します。
OpenAI / Codexは、NetAppが高品質なソフトウェアをより迅速にお客様に提供できるよう支援します。 

PerlからPythonへのコード変換は、ほんの始まりに過ぎません。OpenAI / Codexは、NetApp製品の新しい機能、拡張性、およびパフォーマンスのメリットを最大限引き出し、促進させる可能性を秘めています。

OpenAI / Codexの導入はまだ始まったばかりですが、ベータ版には今すぐこちらからアクセスできます。OpenAI / Codexによる適切なテストやプロセスでリスクを管理することで、従来のコードを新しい言語に変換するプロセスはすでに加速し始めています。