検索API量産環境の短期構築、改善事例で分かる、「AWS Codeシリーズ」によるCI/CDパイプライン自動化のコツ：リクルート事例で分かるIaaS→PaaS移行のコツ（3）

リクルートの情報検索組織において検索APIの基盤をどうやってPaaS中心のシステムに移行したかを紹介する連載。今回は、API開発システムの全体構成と構築の流れについて解説する。

[佐藤万莉，リクルート]

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

　連載3回目となる今回は、下記のように情報検索API（以下、API）の開発システムの全体構成とAPI構築の流れを解説します。

• システムの概要
• API開発全体に関わるインフラ構築とジョブの実行環境
• API構築の手順を追いながら、システムがどのように共通化、自動化されているか、その結果、開発者が何をしているかの紹介
• リリース前に実施するIntegration Testと性能試験
• 検索のユーザー体験のブラッシュアップについて、これまでの案件から改善例の紹介

　われわれのシステムはクラウドネイティブ化を進めることで、API構築作業のうちユーザー体験やアルゴリズム以外の作業をできるだけ自動化しようとしていますが、いまだその途中にあり、手動で対処している作業があります。クラウドネイティブ化を進めているチームでどのように開発しているかの参考になれば幸いです。

想定読者

• クラウドネイティブな開発基盤を活用してAPIを量産する体制に関心がある方
• クラウドネイティブな開発基盤を活用してAPI量産環境を短期間で立ち上げるまでの実例を知りたい方
• APIを立ち上げてから改善する方法に関心がある方

情報検索API開発システム全体構成

　前回のおさらいです。われわれのシステムは下記5つのコンポーネントから成り立っています。

コンポーネント	機能	目的
データ連携	検索対象のデータやログなどのデータに関するETL（Extract、Transform、Load）処理	検索対象の取得と検索品質を向上させるデータの取得
分析処理	データ分析処理（主にTransform処理）	検索品質向上のための前処理（自然言語処理やクラスタリングなど）
Index更新	検索エンジンElasticsearchへのIndexを格納するETL処理	Indexの更新
Elasticsearch	全文検索エンジン	検索機能の実行
検索APIサーバ	RESTfulなAPIの提供	検索品質を向上させるクエリの解釈や他のAPIからの情報を利用

　API構築はこれらのコンポーネントを立ち上げる作業です。API構築の手順は下記のように各コンポーネントと対応付けられます。

順序	コンポーネント	対応する手順
1	データ連携	参照するデータファイルをテーブルに格納する
2	分析処理	SQLを実行して検索対象のデータをテーブル形式で作成する SQLだけでは実行困難で複雑なデータ加工（自然言語処理や機械学習など）
3	Index更新	Google BigQueryのテーブルをElasticsearchにロードしてIndex作成
4	Elasticsearch	Elasticsearchを管理する 検索クエリを作成する
5	検索APIサーバ	検索APIを実装、デプロイする

　API構築の手順を説明する前に、手順全体に共通するインフラ構築とジョブの実行環境について説明します。

インフラ構築

　インフラ構築では、前掲の5つのコンポーネントを立ち上げます。第1回、第2回で触れたように、われわれのシステムでは、ユーザー体験やアルゴリズムの試行錯誤以外のタスクを、フォーマット化／テンプレート化することを目標の一つに置いていました。

　従って、われわれのシステムではInfrastructure as Code（IaC）を促進し「AWS Cloud Development Kit」（以下、CDK）を導入してインフラ構築部分をコード化しました。API構築に必要なインフラを統一することで、インフラ構築部分を共通モジュール化し、APIごとに異なる部分のみ環境変数で定義しています。

　現在、われわれのシステムは、下記のようなインフラから成り立っています。

図1

機能	構成するインフラ
資材（データやログ）を配置する	Amazon S3
テーブル	Google BigQuery
ジョブ	AWS CodePipeline AWS CodeBuild AWS CodeDeploy
検索エンジン	Amazon Opensearch Service
検索API	Amazon Elastic Container Service（ECS） AWS Fargate
ロードバランサー	ALB（Application Load Balancer）

　CDKは、共通モジュールとして「Construct」部分にインフラ構築部分を定義しています。開発者は、APIの構築するリソースごとに「Stack」を作成します。Stackでは環境変数のみ定義し、インフラ構築部分は「Construct」を呼び出しています。共通化を進めた結果、開発者はStackの環境変数を定義して「cdk deploy」コマンドだけでインフラ構築が完了するようになりました。

　同様に、「cdk destroy」コマンドによって、構築したインフラを全削除できます。これは、除却するときだけでなく開発環境をリセットして本番環境の構築リハーサルをするときにも役立ちます。

　余談ですが、「AWS CDK Intro Workshop」をやってみるとCDKの書き方のイメージがつかみやすいと思います。

ジョブの実行環境

　われわれのシステムでは、「AWS CodeBuild」（以下、CodeBuild）を使ってSQL実行やデータのロードなどのジョブを実行しています。CodeBuildの仕組みはこちらを参照してください。

　ジョブの実行環境はDockerイメージを使用しています。このDockerイメージはAmazon Web Services（AWS）、Google Cloud Platform（GCP）、Elasticsearchなど機能ごとに独立しています。

　CodeBuildジョブのビルド仕様ファイル（＝buildspec）は「GitHub」から呼び出した共通のスクリプトを使用しています。buildspecからはチームで独自に開発したPythonコマンドを実行しています（各手順で実行しているコマンドの詳細は後述します）。テーブルの参照先、検索エンジンのURLなどAPIによって変わる部分はbuildspecに環境変数として渡しています。この環境変数は、CDKでCodeBuildジョブを構築する際にStackで定義された環境変数から設定しています。また、「Google BigQuery」（以下、BigQuery）やAWSの各サービスにアクセスするための認証情報はbuildspecに記述したくないので「AWS Secret Manager」から呼び出しています。

情報検索APIを立ち上げるまでの流れ

　構築手順を説明します。前のセクションで説明したインフラを全て構築した状態からスタートします。各セクションでは、手順の他に、自動化できる点とそうでない点に焦点を当てます。

データを連携させてテーブルに格納する

　この手順では、「AWS Glue」（以下、Glue）を使って後続の分析処理に必要なデータファイルをBigQueryテーブルにロードします。例えば、下図左のndjson形式のファイルは下図右のBigQueryテーブルになります（図2）。Glueジョブの仕組みはこちらを参照してください。

図2