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でサーバーを常時稼働させているという。
＊ ＊ ＊
冒頭に挙げたコメントのとおり、山田氏は、サーバーレスアーキテクチャでプロダクション環境を構築するのは「すごく大変」だと述べた。ここまで見てきたとおり、稼働状況のモニタリングや何重ものエラー対策、構成管理など、考えるべき点が多くあるからだ。
だが、それでもなおサーバーレスには多くのメリットがあり、「楽しい」と山田氏は語った。
「ただし（サーバーレスの）コストパフォーマンスはとても良い。そして最初にうまく設計すればとてもよく動く。またインフラについて考える必要がほぼなくなり、アプリ開発に集中することができるとも思う。ぜひ皆さん、これからも一緒に、楽しいサーバーレスの開発をやっていきましょう」（山田氏）
本記事はアフィリエイトプログラムによる収益を得ている場合があります
