API量産環境の運用事例から分かる、「AWS CDK」「CloudFormation」による本番リプレース、改善のコツ：リクルート事例で分かるIaaS→PaaS移行のコツ（4）

リクルートの情報検索組織において検索APIの基盤をどうやってPaaS中心のシステムに移行したかを紹介する連載。今回は、開発システムを運用する中で気付いた良かった点や改善点、今後の展望を紹介する。

[横山慎，リクルート]

　リクルートの情報検索組織において検索APIの基盤をどうやってPaaS中心のシステムに移行したかを紹介する本連載「リクルート事例で分かるIaaS→PaaS移行のコツ」。これまでの連載では、筆者たちのシステムの目標、それを達成するために導入した原理原則、これまでの技術選定の変遷、開発システムの全体構成とAPI構築の流れについて解説しました。

1. リクルートの情報検索組織が検索APIの基盤をIaaSからPaaS中心にした理由
2. ペットと家畜、KISSの原則、SREの導入――AWS上のシステムをクラウドネイティブ化する際に用いるべき原理原則
3. 検索API量産環境の短期構築、改善事例で分かる、「AWS Codeシリーズ」によるCI/CDパイプライン自動化のコツ

　連載4回目となる今回は、この2年で13の検索／サジェストAPIサービスを本番リリースしてきた実績を踏まえ、開発システムを運用する中で気付いた良かった点や改善点、今後の展望を紹介します。

開発者フィードバックから見えてきた、検索API開発システムの現状課題

　筆者たちのシステムは大別して、「データ連携」「分析処理」「インデックス更新」「Elasticsearch」「検索APIサーバ」といった5つのコンポーネントから成り立っています。

　検索APIのインフラ構成については連載第3回が詳しいので、そちらを参照ください。この開発システムを用いて複数の検索APIを開発、運用したところ、以下のような問題点が見えてきました。

図1　開発者による検索API開発プロセスへのフィードバック

【問題点1】手作業でデプロイ、設定する項目がある

　筆者たちのシステムでは、「AWS Cloud Development Kit」（以下、CDK）によって検索APIを構成するコンポーネントをデプロイしています。Infrastructure as Code（IaC）を推し進めてはいるものの、一部資材はCDKによるインフラ構築に未対応だったり、型化の難しい個別対応がAPIごとに求められたりするケースがありました。マネジメントコンソールから設定項目を手動で埋める作業工程はミスを生みやすく、本番リリース作業に時間がかかる原因の一つになっていました。

【問題点2】デプロイするものが多い上に、依存関係を考慮する必要がある

　一部のデプロイする資材同士には依存関係があります。例えば、ロードバランサーを作成するには、ログを保存する「Amazon S3」バケットを作成した上で、APIサーバを立ち上げる前に「Amazon OpenSearch Service」ドメインを作成してエンドポイントが決まってから作業する必要があるなどです。

　単純にデプロイする資材が多いこともあり、本番リリース作業手順の複雑化につながっていました。リリース前後の諸連絡や動作確認まで含めると、丸一日リリース周辺作業に費やすこともあります。

【問題点3】ライブラリ、ランタイムのサポート終了でデプロイに支障が生じる

　各種ライブラリやランタイムはリリース後数年でサポートが切れてしまうので、一度インフラ構成をコード化した後も定期的にバージョンアップする必要があります。

　検索API開発システムを2年間運用するうちに、徐々に一部コンポーネントにおいて筆者たちによるデフォルト設定が「deprecated」になり、アドホックなバージョン変更が必要になっていました。そして2022年6月には「AWS CDK v1」がメンテナンスモードに入り、本格的にデプロイに支障が生じ始めました。

　保守運用にかかる工数の削減や、AWSのアップデートに付いていくことなどを目的として、この機に全体的なバージョンアップと開発環境の刷新を実施し、リリース済みの旧APIのリプレースを進めていくことにしました。

さらなるデプロイの自動化、簡略化

　こうした開発者からのフィードバックを踏まえ、筆者たちは、開発プロセスを継続して改善し続けています。

　まずは、AWS CDK v2導入によるさらなるデプロイ作業の効率化です。

　先述の通り、AWS CDK v1が2022年6月にメンテナンスモードに入ったので、利用するライブラリをCDK v2に切り替える必要がありました。CDK v2では、v1では未対応だったOpenSearchドメインや「AWS Glue」ジョブにおける「AWS CloudFormation」のIaCファイルが作成可能になります。

　当時の筆者たちのシステムでは、手作業でデプロイが必要なものとして以下の点が残っていたので、この機にcdk deployコマンドだけでインフラを構築できるよう資材整備を進めました。

• 「Amazon Virtual Private Cloud」（VPC）内に作成したOpenSearchドメインに、開発社内環境からアクセスするためのロードバランサー
• APIの可用性をチェックするテスト用の「locust」サーバを立ち上げる「Amazon Elastic Container Service」（ECS）の「cluster」と「service」
• Git上の「Elasticsearch Index/Search template」をOpenSearchドメインに自動登録するバッチ

　併せて、「CloudFormation Stack」を作成するコードとテストコードを共通化しました。

　複数のAPIの開発やリリースを経て実装ノウハウが蓄積されたことで、API個別の実装が必要な箇所と、要件によらずに共通の実装が可能な箇所との切り分けが可能になり、共通化がさらに推進されました。開発者は設定ファイルを1つ用意するだけでAPIを構成するコンポーネントをデプロイできるようになりました。

共通化と疎結合性のバランスの維持

　「デプロイするものが多い」「デプロイに依存関係がある」といった問題については、究極的には「依存関係を考慮して順番に資材を全てデプロイするバッチやシェル」を作成すれば解決するように思われます。

　こういったバッチやシェルがあれば、検索APIを新規作成するのに必要な作業は「バッチ実行ボタンを1回押す」のみになります。筆者たちの目標は、開発期間の多くを検索のユーザー体験のブラッシュアップに注げるよう、APIの構築プロセスの共通化を進めることです。これは理想の姿の一つです。

　しかし、この仕組みを構築することだけを最優先にしてしまうと、コンポーネント同士の凝集性が高まります。

　検索のユーザー体験を左右する部分については、修正や試行錯誤が容易である必要があります。修正が多くのコンポーネントに影響を与える可能性が上がり、試行錯誤のペースが鈍化する恐れがあります。

　筆者たちは、リクルートのさまざまなサービスを情報検索という機能軸で横断的に改善するミッションを持っています。「あるサービスで成果を上げた機能を他サービスに横展開する」といった業務が定期的に発生します。こういった業務を滞りなく推進する上でも、機能追加、改善が容易なアーキテクチャになっていることが求められます。

　この理想を実現するために、筆者たちは現在、デプロイ資材の統合や共通化ではなく、APIを構成している個々のコンポーネントをボトムアップ的に改善することに軸足を置いて、開発を進めています。

　実験的な新しい機能を導入する際は、その部分だけコンポーネントを差し替えて検証することが容易になるように、疎結合なコンポーネントの集合で検索APIのアーキテクチャを構成しています。

図2　標準的な検索APIのアーキテクチャ

　検索APIの新規開発業務では、まずこの標準的なアーキテクチャで構成されるAPIをデプロイした後、APIのリクエスト／レスポンスのインタフェースを調整したり、Elasticsearchクエリやインデックスの設計を見直したりして検索ロジックの品質をブラッシュアップさせるのが一般的な流れです。このため、データの源泉となる「Google BigQuery」のテーブルや検索クエリ、APIサーバを立ち上げるDockerイメージを都度更新しています。

図3　検索ロジックのブラッシュアップの一例

　APIの開発システムそのものの改善業務においても同様で、新機能を持つコンポーネントを差し替えたり、追加したりすることで、技術検証を進めています。

　例えばElasticsearchインデックスの元となるBigQueryテーブルやスキーマさえ期待通りなら作成方法に制約はないので、「Google Cloud Dataflow」を導入したり、前述のような「Google Cloud Run」を活用した高度なデータ加工についても導入を検討したりしています。

　応用的なアーキテクチャの他の例としては、複数APIサーバ構成があります。この形を採用すると、開発システムの大枠の構成を変えることなく、ベクトル化をはじめとした高度なリクエスト整形を事前に行うことができます。

　検索対象となるインデックス側のテキストのベクトルは、あらかじめ準備してBigQueryテーブルに格納しておけるとして、クエリ側のテキストのベクトル化を担うAPIサーバを構築しておきます。検索APIサーバは、ベクトル変換APIのレスポンスを踏まえて検索エンジンにベクトル検索クエリを投げるような構成にすることで、昨今需要が高まっているベクトル検索機能を実装することができます。

　検証の末、現在ではリクルートの複数のサービスでベクトル検索機能が利用されています。

図4　コンポーネントを差し替えたり、追加したりすることで、機能改善を図る例

検索APIのリプレース

　AWS CDK v1のメンテナンスモード移行に伴い、開発環境のアップデートに加え、リリース済みのAPIについてもCDK v2版を作り直した上でのリプレースが必要になりました。このプロジェクトを進めるに当たり、次の2つのポイントを意識しました。

• 何かあっても切り戻せるように、安全にリプレースを進める
• 既存APIと同じ機能を保証しつつ、改善もする

何かあっても切り戻せるように、安全にリプレースを進める

　まず意識したのは、何かあっても切り戻せるように、安全にリプレースを進めることです。本番稼働中のAPIの中にはリクルートの大規模なサービスで運用されているものもあるので、障害を起こさないように細心の注意を払う必要がありました。

　リプレースを安全にする工夫について説明するために、筆者たちのチームでは「cdk」コマンドを実行することでCloudFormationを基にアプリケーションをデプロイしているので、CDKについて少し深掘りしておきます。

　cdkコマンドでアプリケーションを作成するには、「cdk bootstrap」コマンドを最初に実行して、「CDKToolkit」スタックを用意しておく必要があります。

　CDKToolkitスタックでは、「cdk deploy」コマンドでアプリケーションをデプロイする際に使用するさまざまなアセットやコンフィグが定義されています。またCloudFormationのテンプレートにはmodern／legacyの2パターンがあり、cdk deployコマンドでアプリケーションをデプロイする際にどちらのテンプレートを使用するかはCDKToolkitで定義されています。modern／legacyは柔軟に切り替えられるようなものではなく、CDK v2ではmodernテンプレートしか使えなかったり、CDK v1ではどちらでも使えるものの、CDKToolkitの使い分けが必要になったりといった制限があります。

　テンプレートの異なるCDKToolkitスタックでは、アプリケーションのデプロイ時に使用する資材や権限なども異なってくるので、modernテンプレートを新たに導入、共存させる対応が既存の環境にどれだけ影響を与えるのか、予測が難しいところがありました。また共存できたとしても、運用面でもアプリケーションをデプロイするたびにどちらのCDKToolkitを使用するかを都度指定しなければならない点が気になりました。

　以上を踏まえ、今回のリプレースではAWSアカウントを新設し、CDK v2に対応した検索APIはそちらで一から構築することにしました。既存の環境に手を加えず、何かあっても切り戻せる状態を維持しました。結果、VPCやセキュリティグループ、「AWS Identity and Access Management」（IAM）など、作り直しが必要な資材や設定こそ多くありましたが、安全に移行できるようになりました。

既存APIと同じ機能を保証しつつ、改善もする

　リプレースの安全性に注意を払う一方で、既存APIと同じ機能を保証しつつ、改善もすることを意識しました。

　前述の通り検索APIのアーキテクチャは、疎結合なコンポーネントの集合で構成されています。リプレース版の開発に当たっては、同じ機能を持つAPIを構築する前提の下、特定のコンポーネントを差し替えて挙動に差分が現れないかどうかを確認する形で、以下のようなさまざまな技術検証、アーキテクチャ改善も並行しました。

• 「dbt」（data build tool）を導入し、ワークフローの可視化やデータ加工処理、バリデーションチェック処理を共通化
• 「OpenSearch Custom Package」を導入し、サービス特有のカスタム辞書を作成、更新、利用するパイプラインを整備
• 新たに利用可能になったOpenSearchのエンジンバージョンやインスタンスタイプを技術検証
1. 互換性観点：既存のクエリやパイプラインを引き続き利用できるかどうか
2. パフォーマンス観点：応答速度の向上やインフラコストの削減などの恩恵があるかどうか

最後に

　今回は、検索APIの開発システムを運用してみて得られた学びや改善点について説明しました。ここまで4回にわたり、リクルートの情報検索組織が手掛ける検索システムのクラウドネイティブ化のための取り組みについて紹介しました。簡単に振り返ります。

　筆者たちは、まず、情報検索機能の開発、提供を続ける中でスコープを明確にした上で、ユーザー体験やアルゴリズムに関わる部分に集中するために、システム製造業務のテンプレート化を目標に掲げました。この目標を達成すべく、さまざまなシステム構成を検討してきており、今もなお改善を続けているところですが、現在のアーキテクチャは「サービスをコンポーネント化し、個々のコンポーネントではクラウドサービスを徹底的に利用する」ことを重視した構成にすることで、フレキシブルかつスケーリングの容易なシステムを構成しています。

　採用した技術やシステム設計、システム設計を練る上での考え方などが、読者の皆さまの参考になれば幸いです。