GENIEE TechBlog
🔍

検索基盤の改善に取り組んだら、エンジニアリングの楽しさに向き合うことができた。

に公開

はじめに

GENIEE で SFA/CRM[1] の 開発をしている浜村と申します。SRE(Site Reliability Engineering) チームのリーダーを務めています。

私の担当するプロダクトの根幹は「データ」です。有難いことに多くのお客様に利用していただき、データ量が日々増加していく中で、検索という当たり前の処理を支えるために、検索基盤の改善に取り組みました。実際のアプローチも織り込みつつ、私が感じたエンジニアリングの楽しさを共有します。

背景

私の担当するプロダクトでは一部の検索処理に対して OpenSearch(Amazon OpenSearch Service) の基盤を利用しています。
自由に項目(カラム)が作成できたり、データの更新がユーザーの操作・自動化処理・外部連携などで頻繁に発生したりするプロダクトの仕様もあり、

  • 「データのリアルタイム性(データ更新から検索結果への反映までの遅延)」
  • 「検索速度(クエリ実行から結果返却までの応答時間)」
  • 「運用コスト効率」

を高レベルに鼎立させる必要がありました。

課題

私がプロダクトに携わった段階で OpenSearch はすでに導入されてはいましたが、チューニングや運用のノウハウが十分に蓄積されておらず、データ量や更新頻度、検索頻度などが高まるにつれて、検索やデータ更新に関していくつかの課題が徐々に生じてきました。
しかしながら、ボトルネックの特定は容易ではありませんでした。
Amazon OpenSearch Service はマネージドサービスであるため、システムメトリクスなどは手軽に確認できる環境ではありましたが、メモリや CPU の負荷が明確に上昇しておらず、根本的な原因の特定が難しい状況でした。

アプローチ

明確な計測情報が得られない中で、事後的な要約にはなりますが「推測の上で実験のサイクルを回す」アプローチを取りました。
例えば、EBS ボリュームの最適化、メインのデータベースからの同期システムのスケールアップ、OpenSearch 自体のスケールアップなど、様々な施策を小さく試しながら、効果の有無を確認していきました。これらの施策には3つの特徴がありました:

  1. "効果がある可能性"がある
  2. リグレッションのリスクが低い
  3. 効果がなかった場合に容易に元に戻せる

このように実験としてのリスクが低かったため、基本的なリスク回避策を併用しながら、仮説検証のサイクルを速く回すことができました。

以上のようなアプローチを繰り返し検証して行った結果、最終的に 「データノードのスケールアウト」「プライマリシャードの分割数の増加」 の2つの施策が効果的であることが判明しました。
更に検証を重ねた結果、シャード分割を適切に実施していればデータノード自体の性能はそこまで高くなくてよいことも分かり、シャード分割を適切に実施することで高性能なデータノードが不要になり、スケールアウトとスケールダウンを組み合わせることで、コスト効率の良い基盤運用が可能になりました。
結果として、コストを比較的抑えつつも、リアルタイム性と検索速度の両方で大幅な改善を確認することができました。

学び

この経験を通して2つの学びがありました。

1つは、マネージドサービスであっても、システムの基本的な原理に基づいた設計と運用が重要である ということです。
本来、マネージドサービスは運用の手間を削減してくれます。しかし、性能やスケーラビリティを最大化するには負荷特性に応じた設計が不可欠です。今回の場合、OpenSearchのシャード分割戦略を理解することで、初めて効果的な改善が可能になりました。クラウドネイティブなサービスが増える中でも、システムの基本原理を理解することの重要性を改めて認識しました。

もう1つは、効かなかった施策にも価値があった ことです。
「施策を実施しても効果がなかった」という事象は、今回はボトルネックではなかったことが分かったという知見と、運用的なナレッジの蓄積という2つの価値をもたらします。実際、別の要因で一時的にパフォーマンスが低下した際、まさに過去に行った施策を試してみた結果、パフォーマンス低下が改善されたこともありました。

今回の改善では地道な実験を繰り返しました。最終的な変更は小さなものでしたが、その過程でシステムの挙動を深く理解できました。このような思考錯誤の中で効果的な改善策を見つけ出し、最終的にパフォーマンス改善という成果を得られたことは非常に満足感がありました。
「プロダクト開発」の文脈では、ユーザーに直接価値を提供する機能開発やバグの修正などが注目されがちですが、この記事で述べたような取り組みも、プロダクト開発とそれに伴う価値提供の喜びの1つだと感じています。

エンジニアリングは、楽しい。

脚注
  1. 商談、日報などの営業活動に必要な情報や顧客情報をデータベースとして管理することで、企業の経営戦略や営業活動の促進をサポートするアプリケーション ↩︎

GitHubで編集を提案
GENIEE TechBlog
GENIEE TechBlog

Discussion