「HRMOS採用」では、採用に関するデータをElasticsearchに保存し検索機能で利用しております。 以前はEC2インスタンスにインストールしたElasticsearchを利用していましたが、スケールやメンテナンスしづらいことからAWSのマネージドサービスであるAmazon OpenSearch Serviceへの移行を行いました。

移行の際には、ユーザに安心・安全な利用をしていただけるように、下記の4つの観点に気をつけました。

この記事では、特に ダウンタイムなしで移行完了 に至った3つの工夫を紹介します。

※以降、Elasitcseasrch=ES、Amazon OpenSearch Service=AOSと記載します

はじめに

「HRMOS採用」とは？

「HRMOS（ハーモス）」シリーズは、利用中企業数約1000社超の人財活用プラットフォームです。シリーズの一つである採用管理クラウド「HRMOS採用」は、採用業務の一元管理を通じて、オペレーション業務の効率化と、採用スピードの向上を実現できるクラウドサービスです。データによる採用活動の可視化・分析により、数値データを根拠とした戦略的な意思決定を実現し、効果的な採用につなげることができます。

採用に関するデータ（応募者のプロフィール情報や履歴書情報、選考過程でのデータなど）は基本的にRDSにて永続化しておりますが、一部のデータをESに保存し検索性及び検索速度向上に利用しております。

なぜ移行を行ったのか？

以前までは自前で用意したEC2インスタンスに直接ESをインストールしクラスタを構築しておりましたが下記のような課題がありました。

これらの作業は工数がかかるものが多く、さらにダウンタイムを発生させる必要がある作業もあったため運用コストやリスクが高くなっておりました。 また、ESを利用している部分は「HRMOS採用」にとって重要な機能であるため

利用できなくなる期間 = 利用ユーザ全員の採用業務が停止している期間

となってしまいます。

そのため、極力ダウンタイムを避け、ユーザにできるだけ安心・安全に継続して利用していただき、かつ我々の運用負荷も下げるためにマネージドサービスであるAOSへ移行を決定しました。

移行フローの工夫

「HRMOS採用」ではスクラムというフレームワークを取り入れており、複雑性の高い課題を1スプリント（1週間）で終わらせることができる単位まで細分化しながら開発を進めています。（基本的に週次で定期的なリリースを行っております） かつ、冒頭で挙げていた「移行の際に気をつけていた4つのこと」を満たすために下記のフェーズに区切り進めました。

  1. 調査/設計
  2. AOSの構築
  3. Writer機能の実装
  4. Reader機能の実装
  5. ESの停止

特に、Writer機能の実装 と Reader機能の実装 のフェーズを分けた背景には下記のような観点が挙げられます。

このようなプロジェクトの進め方および、段階的なリリース計画がダウンタイムなしで移行完了につながった1つ目の工夫として挙げられます。

それでは次項以降でそれぞれのフェーズごとに発生した課題や解決方法などを紹介していきます。

各フェーズの工夫

調査/設計

今回のプロジェクトでは下記2つの要件がありました。

これらの要件を満たすため、下記の観点で調査及び設計を行いました。

上記の調査により、大幅にバージョンを上げた場合、ESで適用している設定のままではmappingやanalyzerを期待通り動作させられないことが判明しました。

主な変更点および代替の設定は下記です。

このように代替となる設定を行うことでこれを期待通り動作させ、機能要件を落とすことなく設計をすすめることができました。

AOSの構築

ここでは、前章で設計した内容や、ベストプラクティスを参考にAOSを構築することを目指しました。

ベストプラクティス以外に独自で工夫した点としては、「障害発生時を考慮したスナップショット取得及びリストア方法の確立」が挙げられます。 もともとAWS側管理のS3へ自動でスナップショットを取得する機能は提供されていましたが、下記理由で我々管理のS3へもスナップショットを取得するようにしました。

また、構築を進めていく上で下記の点に大きくハマってしまいました。

弊社ではAWSとエンタープライズサポート契約を行っているため、TAM（Technical Account Manager）の方へ随時相談に乗っていただいた結果、上記課題を解決することができました。 改めて関係者の方々には感謝申し上げます。

Writer機能の実装

Writer機能としては大きく分けて2つの機能が存在しています。

ここでは、最終的にESとAOSで データの整合性が取れていること を目指し進めていました。 そこで、下記の手順を踏むことによりデータの整合性を担保しました。 また、これらはダウンタイムなしでの移行の実現に大きく寄与した工夫の一つです。

これにより、実際にユーザ影響のあるReader機能を置き換えるまでにはデータの整合性がとれた状態を作ることができたため、移行完了時にデータのロスト（今まで見えていたものが見えなくなっているなど）の報告なく完了に至ることができました。

Reader機能の実装

前のフェーズでESとAOSに入っているデータの整合性は確認できているので、このフェーズでは同じクエリを再現することができるかどうかに注力することができました。

しかし、今回は元々使っていたESのバージョンから大幅なバージョンアップとなってしまったため、mappingの際と同様にクエリの書き方が変わっている箇所が多々ありました。

クエリの書き換えにおいては機能要件を満たせる範囲内での変更に収まったのですが、一部挙動が変わってしまう箇所が発生してしまいました。 原因としてはESとAOSで設定不備により一部のmappingがずれてしまっていたことでしたが、アプリケーション側で差分を吸収できたため最終的には挙動を変えることなく移行できました。

この手の移行を行う際には、設計・調査段階で実際に投げているクエリベースでの検証を行っておくことを推奨します。

また、冒頭で示した4つの観点のうち「機能・非機能ともに劣化がないこと」の要件の一つとして「パフォーマンスの劣化が起きていないこと」を挙げていたため、想定されるリクエスト数の数倍程度で負荷テストをすることで下記に挙げる基準を満たせるか評価しました。

上記の評価結果から、パフォーマンスの劣化が起こっていないことが確認できたため、特にチューニングを行うことなく移行に踏み切ることができました。

ESの停止

最後に不要なESを残しておくことはコスト面やセキュリティ面でも懸念があったため、数週間様子見を行った後に下記2点を確認した上でESの停止を行いました。

上記の確認を行った結果、特に問題が発生することなく安全に停止を行うことができました。

まとめ

この記事では、EC2にインストールして自前で管理していたESをマネージドサービスであるAOSへ移行するまでにいたった課題や解決方法を紹介してきました。 ダウンタイムなしで移行を完了できた理由としては、下記3つの工夫が寄与していると考えています。

最後に今後の展望を述べてこの記事を締めたいと思います。

現状、「HRMOS採用」ではSLOを定めており、各APIのレイテンシなどの監視を行っています。（参考：円滑なエラーバジェット運用に向けた取り組み）

そこで、エラーバジェットの安定稼働のためAOSを更に活用し、ユーザにとってより安心安全なサービスづくりができるのではないかと考えております。

濵野 雅史
濵野 雅史

2018年新卒入社のエンジニア。HRMOS採用でアプリケーション開発経験を経て、現在はSREとして従事。キャンプとお酒と音楽が好き。