こんにちは、エムスリーエンジニアリングG・AIチームの大瀧です。
この記事では、推薦システムの改修/プロセスの改善に至ったエピソードをお話させて頂こうと思います。
現在機械学習を活用したシステムを開発・運用している方や、 これから開発・運用を行おうとする方と知見を共有できれば幸いです。
大瀧は今年2月にエムスリーにジョインし、 Archimedesというシステムで初めてプロダクションレベルのコードを書くことになりました。
振り返ってみるとWEB × 機械学習な領域なら当たり前に発生し得ることばかりなのですが、 SIerで研究開発をしていた私の目線からは学び・知見に満ちた経験でした。
Archimedesについて
この記事の主役は、Archimedesという名前で呼ばれているシステムです。 M3 Tech Blogを見てくださっている方の中には、覚えてくださっている方がいるかもしれません。 2018年1月に紹介させて頂いた、ニュース記事推薦システムです。
推薦アルゴリズムの性能が認められ、エムスリーにおけるいくつかのメディアで利用されています。 そんなArchimedesに、パフォーマンス上・モデル開発効率上の問題が発見されました。
1. パフォーマンス上の問題
Archimedesはリリース以降、多くのメディアに関わらせて頂いております。ニュース・臨床記事・掲示板、それらのメルマガにサイト内での記事推薦...などなど、多くの場所で急速に活用されるようになりました。 活用されていく中で、理想と現実の間に乖離が生まれてきました。
理想のArchimedes
- 活用場所が増えても、学習・推論時のパフォーマンスに影響がない。AWSを利用しているので、インフラの機能で負荷の変化に対していい感じに動作してくれる。
現実のArchimedes
- 推論時に要求されるパフォーマンスを満たせなくなった。
Archimedesは社内のメール配信システムから呼び出され、ユーザーごとに事前に計算しておいたオススメ記事を出力する形で動作しています。
メルマガ配信システムはユーザーにとって都合の良い時間（仕事が終わる時間など、様々）を逃さぬよう、並列にArchimedesを呼び出します。
そのためArchimedesには、短時間に高い負荷がかかることになります。
Archimedesは事前にjmeterを用いた負荷試験等を実施しておりましたが、
コミュニケーション上のミスからある時間帯において負荷試験時に想定していた以上の負荷がかかるようになってしまいました。
負荷増に伴いArchimedesのレスポンス時間が伸び（メルマガが届くのが遅くなり）、コネクションプールを使い尽くし...様々な事件が起きました。
対策
実際には実施していないものも含め、メリット・デメリットの2側面からAIチームが検討した対策を見ていきましょう。 皆様のチームなら、どの対策を実施するでしょうか？
メルマガ配信の並列度を下げる
Archimedesへのアクセスの並列度が想定以上に大きい...せや、小さくすればええんや！
- メリット：実施コストがとても低いです。初期対応として実施されたのも、この対策。
- デメリット：送信対象数を変化させずに並列度を下げるため、メルマガ送信にかかる時間は伸びてしまう。メルマガの送信は早すぎても遅すぎても良いことがない。特に遅い場合は迷惑に感じることも多いため、この対策を長期に渡って継続することはビジネスに悪い影響を与えることが予想される。
メルマガ配信のタイミングをうまいことズラす
1つの配信だったメルマガを複数の時間帯に分割したり、同時に送信される複数のメルマガ同士で送信時間を調整したりすることで並列数を下げよう！
- メリット：実装が発生せず、設定の変更で実施することが可能。
- デメリット：新しいメルマガが追加されるたび、再スケジューリングする必要が生まれる。サービスがスケールしなくなるため、未実施。
APIサーバーの再実装
Archimedesには、事前に計算しておいた推薦記事リストをDBから引っ張りレスポンスを作る/返す箇所があります。 パフォーマンス低下の一因であるにも関わらず、チューニングできる人が現在のAIチームにいない「危ない」部分でした。 パフォーマンスの問題が起きるまでは触る必要のない箇所でしたが、ビジネスに関わる問題が発生したなら話は別です。
- メリット：活用場所がさらに増えても、推論時のパフォーマンスには影響が出ない。メンテナンスすることが可能な人がチーム内に複数人いる状態を作ることができる。
- デメリット：新規実装が必要。
エムスリーのAIチームでは最終的に、この選択肢をとることとしました。
学んだこと
"話には聞いたことがあるけど自分の周りで起きるとは思っていなかったこと" である、
"想定以上の負荷がかかりシステム障害が発生"
を経験した私（スケールアウトはしているのに！）。
類似事例を発生させないためにも、振り返りを実施しました。
関係者との（本当に小さな）合意形成のミスから急速に負荷が高まり、障害に至りました。
「タスクの終了/開始の合意の形成に失敗した」と捉えると、私はあるタイミングではプロジェクト管理の基本の「キ」で躓いていたように思います。
（少し遠くから見た）タスクの状態・プロジェクトの状態を確認するタイミングが開発プロセスには必要であると私は考え、
現在はJIRAのチケットに合意状態を書く、プロジェクト開始前にも合意先を明確にするなど対策を実施しています。
きっとこの対策も、近い将来私に新たな学びを与えてくれるハズです。
2. モデル開発効率上の問題
現在活躍中のArchimedesですが、改善の余地はまだまだ存在します。 日々改善にチャレンジしているのですが...理想と現実の間に乖離があることが見えてきました。
理想のArchimedes モデル開発スタイル
モデルが追加された場所、パラメータが変更された部分、データが追加された場所だけ再実行
現実のArchimedes モデル開発スタイル
一部データ、一部条件でのみキャッシュが有効
Archimedesについて性能改善のアイデアが湧いた際はオフラインテストを実施することになっており、 その中でより良い結果を出すため/より正確に検証するために様々なパラメータの組み合わせを試します。
モデルのハイパーパラメータやテストの設定を変更するたびにデータの読み込みや全モデルの学習が発生する状態になっており、 キャッシュの弱さがモデル開発のボトルネックになっていました。
対策
Archimedesのコードに修正を加えて、必要な部分にキャッシュ機能を加える
Archimedes専用に、必要な機能をきめ細やかに作成する方針がこちらです。
- メリット：目的を達成するための工数は（比較的）小さい。
- デメリット：他のシステム・プロジェクトで同様の問題が発生する。
機械学習向けのフレームワークを作成する
キャッシュ機能等、共通で必要になる機能を提供するモジュールを作成する対処方法ですね。
- メリット：複数のプロジェクトで恩恵を受けることができる。
- デメリット：目的を達成するために必要な工数 +αが必要。
この問題に関しては、チームの状況によって正解が異なると思います。 エムスリーのAI・機械学習チームは複数のプロジェクトを進める/システム・モデルを開発するチームであるため、 機械学習システム全般での利用を考えたモジュールを作成することにしました。
現在もluigiをベースとしたパイプラインフレームワーク/module群を開発しております。 Archimedes以降に開発されたシステムには既に採用され、モデル開発の効率は格段に向上しました（Archimedesは移行中）。
↓チームリーダーによる解説記事↓
学んだこと
このケースにおける本当の失敗は、私は改善に至るまで時間がかかった点/改善せずにモデル開発を進めていた時期があった点であると考えています。
2月にジョインした頃、私はエムスリーの開発/ビジネススピードはまさに目が回るようだと感じていました。
スピードが不足しているなら、高速化するための策を練るべきだと当然考えることでしょう。
振り返り、記事を書いている今は当たり前に発見できるこの対策が、しばらくの間私には見えていなかったのです。
現在は広い視野でタスクの洗い出し/優先順位決定が行えるよう、少し異なるプロジェクトを担当しているメンバーと共に振り返りを実施しています。
（こちらの施策の効果は現在確認中です...！）
最後に
Archimedesに色々な問題が発生し、改修/プロセス改善を実施することになったエピソードを紹介致しました。 みなさまのチームなら、開発初期にどのような検討/プロセスの策定を行うでしょうか？ 機械学習システムの開発プロセスはまだまだ未開拓な領域であると思いますが、 それ故切り拓く面白さがあると思います。 機械学習システム開発についての苦い思い出を共有することで、 より良い機械学習システム開発プロセス誕生の一助になれれば幸いです。
merpayさんと機械学習の活用状況について共有させて頂いたイベントのレポート記事も合わせてどうぞ
We are hiring
エムスリーでは、共に医療 × テクノロジーの未来を切り拓いてくれる仲間を募集中です！
