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