PurpleCloud Brain AI：AIを使用したOdooパフォーマンスの改善

PurpleCloud Brain AIは、Odooのパフォーマンス問題に対してAI最適化を活用し、プログラムによるデータベース最適化とシステム最適化を提供して、PurpleCloud ホスティングプラットフォーム上のOdooカスタマイズパフォーマンスとOdooモジュールのパフォーマンスを向上させます。 

Odooが毎年より多くの市場シェアを獲得し続ける一方で、デプロイメントの数と管理するデータの一日のボリュームは驚くべき速度で増加しています。その間、多くのユーザー、開発者、およびOdooパートナーがますます多くのパフォーマンス問題に直面しており、そのケースは単なる不快感や遅さから、実装が初期の目的に役立たなくなるほどの受け入れられない動作にまで及びます。 

結果は常に同じです：ユーザーのフラストレーション、緊急に解決策を見つけるためのITチームへの圧力、および高額なコードのリファクタリング。

Portcitiesでは、数年前に新しいAI技術がこれらのパフォーマンス問題にプログラム的に対処するのに必要な成熟度に達していることに気づきました。こうして、Run-Odoo Brainプロジェクトが誕生しました。 ​ ​  

これがその物語です。  

ODOOのパフォーマンス問題

Odooの主な特性は、長期的にパフォーマンス改善と全体的なメンテナンス性を標準化する際に、逆にその欠点にも寄与します：

この段階では、上記の課題の直接的な結果について言及すらしていませんが、以下のようなものを簡単に選び出すことができます：

• データ量の観点からOdoo ERPの負荷を受けるテーブルは、インストールされたモジュールとクライアントが運営しているビジネスの種類に完全に依存します。
• OdooはデータをDROPすることを許可していません。これはつまり、ユーザーが追加し続け、データベースとファイルストアが月や年が経つにつれて成長し続けることを意味します。
• モジュールが多くなるほど、モジュール間の依存関係、テーブル間の制約、そしてPythonで制約されたアクセスが増え、呼び出しが複雑になり、PythonのワーカーとPostgreSQLデータベースの両方に圧力がかかります。
• 利用者が多くなるほど、同時により多くのデータを使う必要があるため、より多くの圧力がかかります。
• APIや自動化は、アクセス頻度と呼び出しごとに処理するデータ量が非常に厳しいため、パフォーマンスを悪化させる要因になるでしょう。

丁寧に言うと、"Open-ERP 7.0"以降のすべてのOdooバージョンでパフォーマンス問題を10年以上トラブルシューティングしてきた後、稼働するすべてのOdooの実装は、早かれ遅かれパフォーマンスの最適化を必要とするだろうと言うでしょう。データ量が少ない非常に小さなデプロイメントは、10年の使用後にはほとんど影響を受けないと正確に言えますが、稼働から6ヶ月も経たないデプロイメントがほとんど使えない状態に陥ったのを目の当たりにしたことがあります。

挑戦が始まりました

しかし、Odooはサードパーティのオープンソース技術の組み合わせであるため、その一般的なパフォーマンス問題のトラブルシューティングには、以下の専門知識を網羅する広範な知識が必要です：

• インフラストラクチャ： すべてのシステム、専用デプロイメント、クラウドプラットフォーム、インスタンスおよびサービスは非常に異なる方法で動作しており、私は企業がユーザー数や関与する操作と比較して理にかなっていない月額ホスティング料金の素のサーバーに巨額の費用を支払っているのを見てきました。
• DevOps: CPU、メモリ、ストレージI/Oの消費方法は重要であり、しばしば見落とされたり無視されたりしますが、パフォーマンスの根本的な原因のいくつかは、間違った仮想化モード、または誤ったカーネル設定やCPU割り当て、メモリ使用法などから発生します…などなど。 
• Odoo Pythonコーディング: Odooアプリストアで利用できるコードや標準的なOdoo開発者が書いたもののほとんどは機能的な側面に焦点を当てています。中規模から大規模な生産システムに与える潜在的な影響を測定する際に、ストレステストや適切な評価が行われているものは非常に少ないです。ログにエラーがなく、エンドユーザーがデモ/テスト/UATが合格したと検証した場合、モジュールは本番環境に投入されます。パフォーマンスの問題は後で発生します。真実は、パフォーマンス中心のアプローチで同じモジュールを書くには、Odoo ORMが実際にデータベースおよびファイルストアと非同期に何をしているのか、Pythonワーカーがコードをどのように消費しているのかを完全に理解する必要があるため、はるかに多くの専門知識が必要です。
• PostgreSQLの知識: PostgreSQLは、能力がその複雑さと対になっている本当に印象的な存在です。設定方法は何百もあり、特定の注意を必要とする設定が何百もあります。しかし、私が遭遇するほとんどの生産システムは、コミュニティパッケージの一般的なインストールに展開されるか、標準のAWS、GCP、およびAzureのオファーを使用しており、標準の一般設定で展開されているため、パフォーマンスが低下しています。   

だから、私たちはここにいて、完全なインフラとフルスタックの専門知識を組み合わせた体系的な分析を必要としています：挑戦が始まりました。しかし、人間にそれを拾わせ、部分的にデプロイを修正するために数百時間も請求可能な時間を費やさせるのではなく、ポートシティーズでは、AIに必要なすべてを教えて数分で行えるようにすることに決めました。私たちのチームの最高のエンジニアが数週間も妄想すらしないことを行います。

チャットGPT：知性を構築する挑戦

私たちが初めてChatGPTで遊び始めたとき、AIが標準的なトピックを説明し解決するのに驚異的な能力を持っていることにすぐに気づきましたが、より複雑なタスクを与え始めると、非常に限界があることを実感しました。 

結果は決して満足のいくものでなかったが、連続した試みは高いコストを伴った：より多くの推論、より多くの誤った回答、より多くの言い訳、より多くの再実行など。

私たちは愚かになって、堂々巡りをしていました。

私たちは迅速に失敗から学び、AIの効率を活用する唯一の方法は次のルールを適用することだと気づきました：

• 適切な「推論構造」を事前に提供し、無駄で空虚な創造的逸脱を制御するために、固定された予め定められた経路のフローを含む、弾力性のあるAIモデルを構築する。
• 一般的な「誤解」を避け、誤解や無意味な推奨につながる一貫した構文でAIのキューイングを改善します。
• ベストプラクティスを強化する関連コード、例、出版物を指摘することでAIの知識を増やします。
• 各分析およびトラブルシューティングセッションで遭遇したAIの使用ケースをフィードします。各データベースには新しい予期しないケースや課題が伴います。これを活用することは、最良の推奨を行う際にシステマティックに的を射る関連性を持つパターン検出手法を学び、改善する素晴らしい機会です。 

私たちは、すべてのAIがこれらの基本的原則に導かれた同じ流れ作業アプローチを必要とするという結論に達するまで、多くの異なるAIで遊びました。結局のところ、重要なのは犬自身ではなく、犬をどのように教えるかです。

報酬の収集

最終的に、数ヶ月にわたる徹底的な研究開発とテストの後、ここにそれがありました：BRAIN 0.1が誕生しました。 

私たちは、約2年間の運用データを含むデータベースで中程度から重度のパフォーマンス問題に影響を受けた大規模なOdoo 16デプロイメントでこれを実行することを決定しました。要約すると、これが結果です：

全体的なパフォーマンスの向上

BRAIN AI は、最適化前後の Odoo バックエンドの平均応答時間を比較し、ログで確認した後、平均実行時間が 1184 ms から 293 ms に減少したことを測定しました。これは基本的に、速度が X4 の比率で向上したことを意味します。 

機能 / モジュールごとのパフォーマンス改善評価

📒 会計とファイナンス

モジュール: account, account_reports, account_accountant, l10n_*

改善点: 請求書一覧、調整、財務報告、ダッシュボードのパフォーマンス。

👥 人事 & 給与

モジュール: hr, hr_expense, hr_payroll, hr_holidays, hr_attendance

改善: 従業員記録への迅速なアクセス、経費追跡、および給与明細の生成。

🛒 販売 & CRM

モジュール: sale, crm, contacts

改善：顧客検索、見積もり、および注文リストの応答性。

📦 在庫と購入

モジュール：在庫、購入、製品

改善：製品検索、転送操作、購入注文のナビゲーション。

🌐 ウェブサイト、ポータル＆マーケティング

モジュール: ウェブサイト、ポータル、メール

改善: ポータル検索、ウェブサイトの読み込み、チャッター/メッセージのパフォーマンス。

🔐 アクセス制御とシステム

モジュール: ベース、ウェブ、設定

改善: より速いUIの読み込み、権限チェック、アクセスルールの評価。

🛠️ 技術的 / 背景ジョブ

モジュール: base_automation, queue_job, bus

改善: Cronジョブ、非同期キュー、ログ/イベントアクセス。

パフォーマンス改善の要約

アクションと成果物

要するに:

• 22分の実行サイクル。
• インフラストラクチャーレベルで実行された12のアクション
• データベースレベルで実行された680のアクション
• 23のデータベース設定が変更されました
• 3つのOdoo構成設定が変更されました
• さらなる改善のための16のコーディングおよびインフラストラクチャの推奨事項
• 変更内容を詳細に説明した460ページの完全な詳細報告書の作成。

これは堅実な例ですが、この記事を書くときに大規模な展開で驚くべき17.5倍の速度向上があり、「あきらめようとしている」というOdooの物語を「この展開を拡張し、私たちの新しいバックボーンとして使用するつもりです」に変えました。

それでも、グループCTOでありBrainの発起人として、私はまだその「プロアクティブ」な知能に満足していません。もっと多くを学び、より多くのデータを「体験」する必要があります。この時点での正直な評価は、長期的に私たちが期待する能力の約30％から40％を修正しているということです。確かに、「練習は完璧を作る」と言われています。  

製品ロードマップについてもっと知る

​Brain による日々の成果を踏まえ、最適化プロセスにAIを導入することが正しい判断であったと、私どもは確信を深めております。BRAIN AIは近日中に、当社のPurpleCloudホスティングプラットフォームで展開される全てのデプロイメントにおいて利用可能となり、完璧なSLAと質の高いユーザーエクスペリエンスを必要とする中規模から大規模のお客様にとって、重要な資産となることでしょう。

その一方で、パフォーマンスの問題はOdooの展開とアップグレードのライフサイクルを通じて進化する問題であるため、私たちは今や、任意の展開でBrainを一度だけ使用することを許可するだけでなく、BRAIN AIを「アップグレード版」の健康チェックの機能を持つエージェントのように振る舞う恒久的なサービスとして統合する方向にシフトしています。

• リアルタイムで問題や遅延を監視し、検出します。
• 対策を動的に実装します。
• ユーザーの行動、問題、解決策について自動報告します。
• 推奨事項を作成します。

​ ​ to explore the PurpleCloud Cloud Platform powered by Brain AI today!