Pythonは技術的負債か Rust移行でシステム起動が60秒から1秒へ：Wasmerが実証
ソフトウェアベンダーのWasmerは、7年間運用したDjangoベースのバックエンドをRustへ全面移行した。インフラ利用効率は90%向上。AIをどのように活用し、どのような教訓を得たのか紹介する。
システムの性能問題が発生したとき、多くの企業はサーバやクラウドリソースを追加して対応する。CPUやメモリを増強すれば、短期的には問題を解決できるからだ。しかし、その方法が永続的な解決策になるとは限らない。
ソフトウェアベンダーWasmerは、まさにその限界に直面した企業の1つだ。同社は約7年間にわたり、PythonのWebフレームワーク「Django」を利用してバックエンドシステムを運用してきた。しかし利用者の増加とともにシステム負荷が高まり、インフラコストと運用負荷が急速に膨らんでいた。
ピーク時には、本番環境を維持するために220CPUと800GBのメモリを消費していたという。同社は当初、インフラを増強することで問題を解決しようとした。しかし最終的には「お金では解決できない壁」に突き当たり、バックエンド全体をRustで書き直す決断を下した。
移行後の結果は劇的だった。CPU使用量は89％、メモリ使用量は92％削減され、API応答時間も大幅に短縮された。本稿では、Wasmerの事例を基に、情シス担当者が学ぶべきシステム刷新のポイントを整理する。
Django環境の限界突破から得られる4つの教訓
併せて読みたいお薦め記事
リプレースの関連記事
- “もう1つのSAP問題” SAP Commerce 2205保守終了で考えるEC基盤の選定ポイント
- AWSのサービスが多すぎて困惑 「自社に合った技術」を選ぶためのフレームワークを同社エンジニアが紹介
WasmerはDjangoそのものを否定しているわけではない。同社はDjangoによって7年間にわたりサービスを成長させてきた。
一方で、システムの規模が拡大するにつれて幾つかの課題が顕在化した。
特に問題となったのが、GraphQL（クエリ言語）を中心としたAPI処理だった。同社によると、Djangoではオブジェクト関係マッピング（ORM）で非同期処理を利用できるものの、データベース接続やカーソルの非同期対応には制約がある。そのため、GraphQLと組み合わせた際にレスポンス性能の低下を招いていた。
さらに深刻だったのが、長年にわたって蓄積した技術的負債だ。
Wasmerでは、納期を優先する中で型定義を省略するなどのショートカットが繰り返され、複数の開発者が異なる設計思想で改修を重ねた。その結果、コードベースは複雑化していた。同社は当時のコードを「フランケンシュタインのような状態だった」と表現している。
加えて、社内にPythonの専門家がほとんど存在しなかったことも保守性を悪化させる要因となった。問題が発生した際に深く分析できる人材が限られ、特定のチームへ負荷が集中していたという。
こうした状況は、多くの企業システムにも共通する。パフォーマンス低下の原因はサーバ性能不足ではなく、技術的負債や設計上の問題にあるケースが少なくない。
CPU89％減、メモリ92％減を実現
Wasmerは7年間運用してきたDjangoバックエンドをRustへ全面移行した。
移行前後を同じトラフィック条件で比較した結果、インフラ利用効率は大幅に改善した。
| 指標 | Django | Rust | 変化 |
|---|---|---|---|
| CPU数 | 220 | 24 | 89％削減 |
| メモリ | 800GB | 64GB | 92％削減 |
| API応答時間（p95） | 120ミリ秒 | 30ミリ秒 | 75％改善 |
| 起動時間 | 60秒超 | 約1秒 | 約60倍高速 |
| DB接続数 | 数千 | 数百 | 3〜5倍削減 |
| クエリ速度 | 基準値 | 5〜10倍高速 | 5〜10倍改善 |
特に起動時間の改善は顕著だった。Django環境では最悪の場合60秒以上かかっていた起動処理が、Rustでは約1秒で完了するようになった。
データベース接続数も大幅に減少している。従来は常時数千の接続が発生していたが、移行後は数百程度に抑えられた。データベースへの負荷軽減は、安定運用やコスト削減にもつながる。
さらに注目すべき点は、Rust環境ではまだキャッシュを実装していないにもかかわらず、クエリ処理が5〜10倍高速化していることだ。
AIが変えた「リプレースは危険」という常識
今回の事例で特に注目したいのが、移行期間の短さである。
一般的に、大規模システムの全面リプレースは数年単位のプロジェクトになりやすい。特に7年間運用してきたシステムを別言語へ移行する作業は、多くの企業にとって現実的ではない。
しかしWasmerは、生成AIを活用することで移行作業を大幅に効率化した。
AIはPythonで記述されたモデルやビジネスロジックのRustへの変換を支援した。さらに、Python版とRust版でデータベース構造や動作が一致していることを確認する検証ツールの開発にも利用された。
結果として、実質1人のエンジニアがフルタイムで約3カ月取り組むことで移行作業の大部分を完了できたという。
GraphQLが移行リスクを大幅に下げた
Wasmerの移行が比較的スムーズに進んだ理由の1つが、GraphQLによるAPI設計だった。
バックエンドは完全に別の技術スタックへ置き換えられたが、GraphQLのインタフェースは維持された。その結果、フロントエンドや外部クライアントの修正は不要だったという。
企業システムの刷新では、利用部門や周辺システムへの影響が課題になる。しかしAPIを適切に抽象化しておけば、内部実装を大幅に変更しても利用者への影響を最小限に抑えられる。
今回の事例は、将来的なシステム刷新を見据えたAPI設計の重要性も示している。
成功の理由は「Rustだから」ではない
Wasmerは、今回の成果を単純に「Rustのおかげ」とは説明していない。
確かにRustの強力な型システムや低いメモリ消費量、非同期処理性能は大きな要因だった。しかし同社によれば、アーキテクチャを整理し、長年蓄積した複雑さを取り除いたことも大きな効果をもたらしたという。
バックエンドは、データベース、GraphQL、認証、キャッシュ、タスク処理などを独立したモジュールとして再設計された。これによって責務が明確になり、保守性も向上した。
つまり今回の事例は、「言語を変えれば速くなる」という単純な話ではない。リプレースを技術的負債の解消機会として活用したことが成功の大きな要因だった。
Rust移行にもデメリットはある
一方で、Rustへの移行はメリットばかりではない。
まず、ビルド時間が長くなった。コンパイル時の検査が厳密なため、開発中の反復速度はPythonより低下する。運用面でも変化があった。
Python環境では「python manage.py shell」を利用して本番環境でスクリプトを実行し、データ確認や一時的な修正ができた。しかしRustではそのような柔軟な運用が難しい。そのため、コード変更やリリースプロセスをより慎重に管理する必要がある。
さらに、多くの開発者が利用しているDjango Adminのような標準管理画面も存在しない。WasmerはAIを活用して独自の管理画面を構築したが、そのための追加開発は避けられなかった。
情シスが学ぶべき4つの教訓
今回の事例から情シス担当者が学べるポイントは4つある。
1．クラウド費用やサーバ費用を増やしても解決できない問題が存在すること
運用コストが異常に膨らみ始めた場合は、アーキテクチャや技術選定そのものを見直すべきタイミングである可能性がある。
2．自社のスキルセットに合った技術を選定すること
Wasmerはチーム全体がRustに精通していたため、バックエンドもRustへ統一することで属人化を解消できた。このように、自社のスキルセットに合った技術を選定することで、その後の問題を解消しやすくなる。
3．AIを活用したリプレースは現実的になりつつある
コード変換やテスト作成、仕様比較といった作業は、既にAIが大きく支援できる領域になっている。
4．リプレースは単なる言語を変えての再実装ではなく、技術的負債を整理する絶好の機会
Wasmerの事例は、「Rustがより優れている」という話ではない。老朽化したシステムを抱える企業が、AIを活用しながらどのように技術的負債を解消し、運用コストを削減できるのかを示した事例だ。
Copyright © ITmedia, Inc. All Rights Reserved.