エンジニアリング

エンジニアリング

Mythexの開発と運用について。何が壊れ、どう直したかも含めて。

• 再公開に失敗しても、動いているバックエンドは消えない — 再公開に失敗すると、アプリのライブAPIが削除されたり、壊れた新バージョンが動き続けたりする恐れがありました。Mythexが失敗した公開を元に戻す仕組みに加えた3つの修正をご紹介します。
• サーバーごとではなく、一度だけ鳴るアラート — 1日1回のはずのアラートが、ある日の午後に5回届きました。サーバーが2台あってデプロイがあると、メモリ内の重複排除が機能しなくなる理由と、共有ストアでそれを修正した方法です。
• 待たせずに、より大きなワークスペースへ移行する — 2GBへ移行したあと、ワークスペースの4分の1が1GBのままでした。最初の修正では、1人のユーザーが7分待つことになりました。何を変更し、さらにどう変更し直したかをご紹介します。
• データベースの課金は、実際の使用量で決まる — 以前は各アプリのデータベース費用を見積もっていましたが、その見積もりは両方向に外れていました。今では、すべてのデータベースを計測された使用量に基づき、1時間単位で課金しています。
• 公開直後にクラッシュするアプリを検出する — 3件の公開が、APIが起動のたびに数秒でクラッシュしているにもかかわらず、ヘルスチェックを通過しました。原因は、最大5件しか保持しないリストでクラッシュを数えていたことでした。
• 画像を多用するエージェントのターンをメモリ内に収める — カタログのスキャンを見続けていたエージェントのターンが、952 MBでメモリ不足になりました。保持が長すぎた3つの別々の原因と、その修正方法を説明します。
• 長いエージェントのターンをコンテキストウィンドウ内に収める — サブエージェントは、モデルに拒否されるほど大きくなったり、余裕を確保するために早々に止まったり、ロシア語のトークンを数え間違えたりしていました。長い作業を完了させた3つの修正です。
• スマートフォンがスリープしてもチャットを維持する — スマホはスリープし、タブを切り替え、作業中にネットワークを失います。2つのバグのせいで、チャットが止まったり、あとから返信が途中までしか表示されなかったりしました。その見つけ方と修正方法です。
• 重いチャット1つが、私たちのAPIを停止させかねなかった話 — 9月28日、本番のAPIサーバー2台が同時にメモリ不足になりました。最初の対策はメモリの増設でしたが、本当の修正は、チャット履歴を件数ではなくサイズで読み込むことでした。
• Publishを2回押しても、公開は1回になりました — 同じアプリへの公開リクエスト3件が84ミリ秒差で届き、それぞれがデプロイ全体を実行していました。どの公開を通すかをデータベースに決めさせ、ほかの公開には正直に伝える仕組みに変えました。
• 自社サイトを直して得たSEOの教訓 — FAQマークアップの重複、Googleに表示された誤ったサムネイル、誰もクリックしなかったテンプレートページ、エッジで拒否されていたパス。mythex.aiで見つけて直したことです。
• 静的サイトは、再公開の間も稼働し続けるようになりました — 以前は静的サイトを再公開すると、新しいビルドをアップロードする前に公開中のファイルを削除していました。今は、新しいサイトが配置されるまで古いサイトが配信され、変更は数秒で反映されます。
• 進行状況のラベルに潜んでいたメモリ不足によるクラッシュ — AIエージェントが大きなファイルを1つ書いている最中に、メモリ不足で停止しました。原因はモデルでも並列のサブエージェントでもなく、ステータスラベルが41,000回再送されていたことでした。
• サーバーを凍結させた、スワップファイルの欠如 — 本番サーバーはクラッシュせずに応答しなくなりました。メモリ不足によるkillはなく、スワップのないマシンでページキャッシュがスラッシングしていたのです。何が起きたか、何を変えたかを説明します。
• 死んだ接続を使わずに、データベースを起こす — スリープから目覚めた公開アプリは、スリープ中に死んでしまったデータベース接続を使おうとして、最初のリクエストを10〜12秒保留していました。それを2.3秒まで縮めた方法です。
• 自分たちのサービスに、自分たちがレート制限をかけていた — APIのアドレスごとのレート制限が、私たち自身のサービスを1人の忙しいユーザーのように扱っていて、本番環境で429エラーが出始めました。原因の見つけ方と修正方法です。
• Mythexのサーバーを、ARMに移した理由 — 重い処理がプロジェクトごとのサンドボックスに移ると、サーバーのメモリ使用量は3分の1になりました。より小さなARMインスタンスで、コストは約30%下がりました。その方法です。
• デプロイを502エラー0にした方法 — デプロイと競合するウォッチドッグと、サーバーが去るより遅れてトラフィックを止めたロードバランサー。両方を見つけて直し、デプロイごとの502を10件からゼロにした方法です。