こんにちは、SREグループです。
「Chatwork」では、メッセージ検索にAmazon OpenSearch Serviceを利用しています。
今回は、2025年2月頃に実施したOpenSearchのインスタンスタイプ移行についてお話したいと思います。
特徴
「Chatwork」のメッセージ検索は、以下のような特徴を持っています。
- キャッシュが効きにくい
- チャットメッセージということもあり、ユーザーごとに検索条件や対象データが異なるため、検索結果のキャッシュがほとんど効きません
- ストレージ性能への依存
- キャッシュが効かない分、ストレージのI/O性能が検索速度に直結します
- 継続的なデータ増加
- メッセージ数は日々増加するため、定期的なデータノードのスケールアウトが必要です
課題点
これまでi3というSSDを内蔵したストレージ最適化のインスタンスタイプを使用していましたが、いくつかの課題を抱えていました。
1. 世代の古さによる性能効率の低下
i3というインスタンスタイプはかなり以前から利用しており、ストレージ最適化の中では現行世代という括りにはなっていますが、他の種類のインスタンスタイプに比べるとパフォーマンス効率は劣っている可能性がありました。
2. スケーリングコストの増大
レイテンシーを一定に保つためには、i3のままではデータ量の増加に応じて多くのデータノードを追加する方法しかなく、台数ばかりが増えていく状況になっていました。
3. 代替案の不在
同じストレージ最適化のインスタンスタイプはi3以外の選択肢がない中で、スケーリングコストの課題を解決するために2024年2月頃にr6gのインスタンスタイプへの移行を試みました。
しかし、EBSのIOPSが急増し、かえってパフォーマンスが劣化してしまいました。
スループットを上げる運用も考えられましたが、コストが見合わないという判断で断念しました。
実際のところi3は内蔵ストレージのため、ストレージのメトリクスが提供されておらず、正確に判断できなかったという背景もありました。
転機：i4iインスタンスタイプの登場
こういった経緯で次世代のインスタンスタイプが出ることを待ちわびていたところ、2024年9月に新しいストレージ最適化インスタンスタイプi4iが発表されました。
すぐにでも変更したかったのですが、RI（リザーブドインスタンス）の購入タイミングに合わせる必要があったため2025年2月頃まで待っていました。
移行の実施
実際の変更は以下のような手順で行いました。
- 新環境の構築
- 既存のi3のクラスターと同じ構成で、i4iにした新しいOpenSearchクラスターを構築
- データ復元と新規登録
- 既存クラスターのスナップショットから初期データを復元
- メッセージデータの投入用や管理系のアプリケーションも同様に別途作成し、ダブルライトのような状態を構築
- 段階的な切り替え
- ArgoRolloutsを活用してカナリアリリースでアプリケーションの設定を切り替え
結果
移行後、以下の改善が確認されました。
- ピーク時のスパイクが軽減し、レイテンシーが安定
- レイテンシー（SearchLatency）やデータノードのCPU負荷が減少（CPU負荷は約30%減少）
- インスタンスタイプの単価は1.1倍ほど上がりましたが、データノードの追加が当面不要なため、長期的に見るとコスト面でも軽減する見込み
まとめ
今回のi4iへの移行により、パフォーマンスの向上とコスト効率の改善を実現することができました。 予想以上の改善が見られたので、こういった定期的なインフラの最適化の重要さを再認識しました。
お知らせ
最後にお知らせです。
7月11日、12日に開催される「SRE NEXT 2025」にプラチナムスポンサーとしてブース出展します🎉
二日目の12日にはスポンサーセッションも行いますのでぜひご参加ください！
SRE NEXT 2025 詳細
- 公式サイト：https://sre-next.dev/2025/
- 会場：TOC有明
- 日時：2025年7月11日(金)、12日(土)
