Romi チームの OpenSearchのコスト最適化事例

本資料は、6/7(水) に開催された
【MIXI × Money Forward × NewsPicks共同開催】AWSコスト最適化夏祭り
における、Romiの加藤による発表資料です。
　
YouTube のアーカイブもありますので、是非、こちらもご覧ください。
https://youtube.com/live/5XY7KgzMU0E?feature=share

#AWSコスト夏祭り

Transcript

1. ©MIXI
   Romi チーム OpenSearch コスト
   最適化事例

   株式会社MIXI Vantageスタジオ Romi事業部 開発グループ
   加藤 修悟
   

   View Slide

2. ©MIXI
   自己紹介！

   加藤 修悟 a.k.a. ろぐみ

   

   21新卒 3年生

   Romiという会話AIロボットを作ってます 

   

   主な領域:

   - サーバーサイド

   - Webフロントエンド

   - インフラ(AWSまわり) 

   

   最近 ハイラルに住んでます 

   

   

   View Slide

3. ©MIXI
   Romiと ？

   ● ディープラーニングを応用した会話AIロボット 

   

   (従来) ルールベース中心 

   

   - 人手で書くシナリオ

   - すぐに脱線する

   - 人手に 限界がある 

   - パターンを試しきったらおもちゃ感 

   (Romi) ディープラーニング中心 

   

   - 大量 データから学習 

   - より柔軟、文脈を考慮して会話可能

   - 時間、季節、記憶、好みも加味 

   - (我々も)何を話すかわからない 

   よろしく ！
   

   View Slide

4. ©MIXI
   文脈を考慮？

   ● 過去 会話履歴が必要 

   ○ OpenSearchで読み書き！ 

   ○ 直近 会話履歴を会話AIサーバーへ送信 

   

   Romiサーバー
   OpenSearch
   

   View Slide

5. ©MIXI
   あれ？OpenSearch高くない？？？

   ● GPUインスタンスが1番高い 

   ○ それ そう

   ● 2番目がOpenSearch…? 

   ○ Romiで 2クラスター使用 

   ■ サーバー ログ

   ■ 会話 ログ

   

   にしても高い

   GPUインスタンス
   OpenSearch
   

   View Slide

6. ©MIXI
   Why?

   ● OpenSearch インスタンスサイズがリッチすぎ 

   

   

   以上！！
   

   View Slide

7. ©MIXI
   Why インスタンスサイズがリッチ?

   ● クエリ そこまで重くない 

   ● 平均的な速度も問題ない 

   ● たまに謎タイムアウトする 

   ○ いったんリッチなインスタンスにして 力で解決した

   

   

   View Slide

8. ©MIXI
   どこがネック？

   ● シャード数が700個オーバー → 多すぎ 

   ○ シャードが多いとヒープを食い潰して遅くなる 

   ○ シャード数 インデックス 数に原則比例 

   ● 1シャードあたりが使う容量が小さすぎ 

   ○ 目安 10〜50GB/shard 

   ○ Romiチームで 当時数10〜数100MB/shard 

   

   ⇒ インデックス 切り方を変えよう！
   

   index
   shard shard
   doc doc doc doc doc doc
   

   View Slide

9. ©MIXI
   インデックス 切り方

   ● 元々: log-YYYY-mm-dd 

   ○ 日単位で切る

   ○ これで数10〜数100MB/shard ということ ・・・ 

   ● 作戦: log-YYYY-mm 

   ○ 月単位で切る

   ○ 30GB/shard 程度に余裕で収まりそう！ 

   ○ 日付単位で切ったインデックスをマージすれ 良さそう 

   ■ _reindex API

   

   

   View Slide

10. ©MIXI
    ● ダブルライトしよう！ 

    ○ 2つクラスターを用意 

    ○ スナップショットを取れ クローンが作れる 

    ○ 同一ID ログをダブルライト 

    ■ UUIDあたりを使え OK 

    

    

    

    

    サービスを止めたくない

    クラスターA(元々あるや
    つ)log-YYYY-mm-dd

    クラスターB(A クローン) 

    log-YYYY-mm にマージ 

    

    View Slide

11. ©MIXI
    ダブルライト

    ● 最初 Aから読み込み 

    ● クローン作成、マージ 間にA書き込まれたデータをBに追記 

    ○ ダブルライト開始まで 空白埋め 

    ○ elasticdumpが便利

    ○ 同一ID も 無視して追記できる(重複ログを防止) 

    ● すべて完了したら読み込みをBにスイッチ 

    クラスターA(元々あるや
    つ)log-YYYY-mm-dd

    クラスターB(A クローン) 

    log-YYYY-mm にマージ 

    

    View Slide

12. ©MIXI
    インスタンスサイズを下げる

    ● OpenSearch Blue/Greenデプロイが可能 

    ● 少しずつ下げて様子見 

    

    

    View Slide

13. ©MIXI
    どれだけ安くなった？

    ※ リザーブドインスタンス 購入も含む 

    Before
 After

    OpenSearch OpenSearch
    

    View Slide

14. ©MIXI
    まとめ

    ● 1シャードあたりが使っている容量を確認しよう 

    ○ 10〜50GB程度がパフォーマンス○ 

    ● ↑が適切な値になるようにインデックスを切ろう 

    ● サービスを止めたくない場合 頑張ってダブルライトしよう 

    

    View Slide