システムの性能問題が発生したとき、多くの企業はサーバやクラウドリソースを追加して対応する。 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の専門家がほとんど存在しなかったことも保守性を悪化させる要因となった。 問題が発生した際に深く分析できる人材が限られ、特定のチームへ負荷が集中していたという。 こうした状況は、多くの企業システムにも共通する。 パフォーマンス低下の原因はサーバ性能不足ではなく、技術的負債や設計上の問題にあるケースが少なくない。
