AIチャットボットの機械学習基盤で得たノウハウを「ServerlessConf Tokyo」で披露
商用サービスのサーバーレス構築は「すごく大変」、リクルートLSが語る
2017年11月28日 07時00分更新
モニタリングなど：サーバーレスでは「全体像」が見えにくい
以上がパイプライン処理の一連の流れだが、今回のシステム基盤ではさらにモニタリングの仕組みや、起動失敗／多重起動などを自動的にリカバリする処理を付け加えている。
たとえば、複数のコンポーネント群を連携させて処理を進めていく仕組みのため、そのままでは「全体」の状況がつかみにくいという。そのために、すべてのステートを「Amazon DynamoDB」に集約し、可視化する仕組みを設けた。
「イベントドリブンのシステムでは、いま処理がどこまで動いているのかがとても追いづらい。この基盤でも、処理を追うならばまずS3を見て、次にLambdaのログを見て、Step Functionsのログを見て……となってしまい、とても大変だ。そうしなくてもいいように、すべてのステートをDynamoDBに書き込んで（Elastic Serchserviceの）Kibanaで可視化し、どのステートにいるかを一元的に見られるようにした」（山田氏）
ステート情報をDynamoDBに集約、Kibanaで一元的に可視化している
なお、S3のイベントトリガによってLambdaがStep Functionsを起動する際、起動に失敗したり、反対に多重起動してしまったりするケースもある。こうしたケースへの対策も行っていると、堤氏は説明した。
まず、起動失敗への対策としてはLambdaのDead Letter Queue（DLQ）を使い、Lambdaが3回試行しても起動できなかった場合にはキューに入れる設定にしている。このキューをCloudWatch Eventsがポーリングし、Step Functionsの起動を再実行する。
LambdaのDLQを使った、Step Functions起動が失敗した場合の対策
また多重起動の防止のために、DynamoDBへのステート書き込みを条件付きINSERTで行うことで、書き込めない（すでに書き込まれている＝起動済み）場合は新たに起動しない仕組みをとっている。
「さらに、S3のイベントトリガでLambdaそのものが起動しない場合もある。それに備えて、DatadogでStep Functionsの監視を行っており、一定時間以上Step Functionsが起動していない場合にはDatadogがアラートを上げる」（堤氏）
管理者へのアラートは、Slack経由で通知する仕組みとなっている。CloudWatch Logsを使ってLambdaやAWS Batchからログを自動収集し、サブスクリプションフィルタとLambdaを使ってエラーログを抽出、自動投稿する。また上述したとおり、Datadogによる監視も併用することで、エラーログを出さないまま長時間処理が停止しているようなケースでもアラートが上がる。
CloudWatch Logsがログを自動収集、エラーログや必要なログを抽出してSlackに投稿
なお“Infrastructure as Code”を実現する仕組みとしては、「Jenkins」でCIサーバーを構築し、構成管理はすべて「Terraform」で書いていると、山田氏は説明した。この部分のみEC2でサーバーを常時稼働させているという。
＊ ＊ ＊
冒頭に挙げたコメントのとおり、山田氏は、サーバーレスアーキテクチャでプロダクション環境を構築するのは「すごく大変」だと述べた。ここまで見てきたとおり、稼働状況のモニタリングや何重ものエラー対策、構成管理など、考えるべき点が多くあるからだ。
だが、それでもなおサーバーレスには多くのメリットがあり、「楽しい」と山田氏は語った。
「ただし（サーバーレスの）コストパフォーマンスはとても良い。そして最初にうまく設計すればとてもよく動く。またインフラについて考える必要がほぼなくなり、アプリ開発に集中することができるとも思う。ぜひ皆さん、これからも一緒に、楽しいサーバーレスの開発をやっていきましょう」（山田氏）
