AIチャットボットの機械学習基盤で得たノウハウを「ServerlessConf Tokyo」で披露

商用サービスのサーバーレス構築は「すごく大変」、リクルートLSが語る

　「ちょっとした処理をすぐに動かせるので、サーバーレスは楽しい。ただし、商用サービスのプロダクション（本番）環境をサーバーレスで動かすことを考えるのは、すごく大変だ」――。

　11月3日に開催された「ServerlessConf Tokyo 2017」では、リクルートライフスタイル（リクルートLS）の山田雄氏とNTTデータの堤崇行氏が、新しい商用サービス提供のために必要となった機械学習基盤をサーバーレスアーキテクチャで構築した経験をもとに、設計段階から考えておくべき多くの留意点を説明した。

セッションタイトルは「Step FunctionsとAWS Batchでオーケストレートするイベントドリブンな機械学習基盤」

リクルートライフスタイル ネットビジネス本部 データ基盤チームの山田雄氏

NTTデータ ITサービス・ペイメント事業本部 方式基盤統括部の堤崇行氏

「じゃらんnet」の新サービスを支える機械学習基盤の構築

　同セッションで取り上げられたシステムは、リクルートLSの新サービス「トリップAIコンシェルジュ」を支えるバックエンドシステムだ。セッションではまずリクルートLSの山田氏が、新サービスの背景やシステム要件などを説明した。

　リクルートLSでは今年6月、旅行予約サイト「じゃらんnet」に情報を掲載する宿泊施設向けの新サービスとして、このトリップAIコンシェルジュを発表した。現在は一部宿泊施設がテスト運用を開始しており、正式リリースは2018年春の予定だ。

　トリップAIコンシェルジュは、じゃらんnetの予約完了画面に追加されるチャットボットサービスである。予約客からのさまざまな問い合わせに対し、宿泊施設スタッフに代わってAIが自動で、かつ即座に回答することで、予約客へのサービス品質を向上させると同時に、宿泊施設スタッフの業務負担を軽減する狙いがある。

リクルートLSの新サービス「トリップAIコンシェルジュ」の概要（プレスリリースより）。宿泊施設への問い合わせをチャットボットが自動回答する

　このAIコンシェルジュは、予約客の質問内容を蓄積し学習することで、回答できる内容の幅と回答精度が高まっていくことが大きなアピールポイントになっている。質問ログデータはいったんオンプレミス環境に保存されるが、その大量のデータからの機械学習処理はAmazon Web Service（AWS）クラウドで行う仕組みだ。

　そこで、オンプレミス環境とクラウド環境の間をセキュアにつなぎ、機械学習を定期的かつ確実に自動実行させるインフラが必要となった。それが、今回サーバーレスアーキテクチャで構築したシステムである。

商用サービス基盤に求められる要件、サーバーレスでどうクリアするか

　ビッグデータ分析基盤の構築や運用を手がけてきた山田氏は、つねづね「基盤エンジニアが運用業務に割く時間が長すぎる。現在は業務時間の80％を運用に割いているが、本来は運用が20％、開発が70％というのが理想」だと考えてきたという。そのため、今回の基盤構築においても「どうやって運用コストを下げるか」を主眼に置きながら、設計を進めることになった。

　そもそも、今回のシステム基盤に求められる機能はシンプルだ。オンプレミス環境から質問ログデータがアップロードされたら、それを使って機械学習処理を実行し、生成された学習モデルのデータをオンプレミス環境に返す。つまり“データのインプット→処理→アウトプット”という一連の処理を自動的に行うパイプラインを構築すればよい。

今回構築した基盤を抽象化した図。本来の目標は、図の中心にあるパイプラインの構築

　ただしこの基盤は、社内で利用するものではなく、トリップAIコンシェルジュという商用サービスの一部をなすコンポーネントである。サービスは今後、長期にわたって運用／利用される可能性があり、その間には機能追加も必要になってくるかもしれない。そのため、この基盤には次に挙げる5つの要件が求められたと、山田氏は説明する。

（1）スケーラビリティ：「サービスを長年提供するうちに、データ量は右肩上がりで増えていく。数年後のデータ量はほぼ予測不可能。さらに、サービスの利用が突然スパイクする（急増する）かもしれない。スケーラビリティは絶対条件だった」
（2）可用性：「今回は日時バッチで定期実行するシステムなので“24×365の可用性”までは必要ないが、それでもSPOF（単一障害点）は作らないほうがいい。また、エラー発生時に自動で処理を再実行してくれる仕組みであれば、運用の継続性が高まる」
（3）メンテナンス性：「設計段階から運用のあり方を考えておくべき。構成はすべてコード化する、ログは自動収集するなど、メンテナンスが楽になることはすべてやったほうがいい。そのために開発コストが増えたとしても、運用コストの削減効果のほうが大きい」
（4）堅牢性：「商用サービスなので、セキュアな設計が必須。同時に、将来的な機能追加にも対応する“変化に強い基盤”であることも求められた」
（5）コスト性：「予算取りの際にはクラウドサービスの利用料金だけを考えてしまいがちだが、実際には運用コストが莫大なものになってしまうことも多い。特に、基盤系は運用コストも念頭に置いておいたほうがよい」

　リクルートLSでは、運用コストの低さやスケーラビリティといった観点から、今回の基盤をサーバーレスアーキテクチャで構築することにした。複数のマネージドサービス間を疎結合で構成することにより、常時サーバーを立てておくクラウドの利用コストも運用コストも抑えられる。同時に、サービスの成長に応じて柔軟に基盤を拡大できるスケーラビリティも実現する。そもそもパイプラインの自動処理は、イベントドリブンなサーバーレスアーキテクチャに向いている。

　しかしその一方で、サーバーレスアーキテクチャで可用性やメンテナンス性の要件を満たすためには、データ処理を行うパイプラインに加えて、処理全体の進捗状況を監視する仕組み、エラーや障害の発生時にも自動再実行する仕組み、コードによるインフラ構成管理の仕組みなども求められることになったという。

具体的なシステム構成図。黄色の枠内がパイプライン処理を行う部分で、そのほかは稼働監視や処理の進捗監視、構成管理、管理者へのアラートを行う部分

　最終的に、このシステム基盤は「Amazon Lambda」「AWS Step Functions」「AWS Batch」「Amazon S3」などのマネージドサービス群により構成されることになった。同セッションでは山田氏、堤氏それぞれが、そのシステム構成を紹介しながら、各コンポーネントにおいて留意した課題やその対策を説明していった。