このページの本文へ

前へ 1 2 3 次へ

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

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

2017年11月28日 07時00分更新

文● 大塚昭彦/TECH.ASCII.jp

  • この記事をはてなブックマークに追加
  • 本文印刷

モニタリングなど:サーバーレスでは「全体像」が見えにくい

 以上がパイプライン処理の一連の流れだが、今回のシステム基盤ではさらにモニタリングの仕組みや、起動失敗/多重起動などを自動的にリカバリする処理を付け加えている。

 たとえば、複数のコンポーネント群を連携させて処理を進めていく仕組みのため、そのままでは「全体」の状況がつかみにくいという。そのために、すべてのステートを「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でサーバーを常時稼働させているという。

* * *

 冒頭に挙げたコメントのとおり、山田氏は、サーバーレスアーキテクチャでプロダクション環境を構築するのは「すごく大変」だと述べた。ここまで見てきたとおり、稼働状況のモニタリングや何重ものエラー対策、構成管理など、考えるべき点が多くあるからだ。

 だが、それでもなおサーバーレスには多くのメリットがあり、「楽しい」と山田氏は語った。

 「ただし(サーバーレスの)コストパフォーマンスはとても良い。そして最初にうまく設計すればとてもよく動く。またインフラについて考える必要がほぼなくなり、アプリ開発に集中することができるとも思う。ぜひ皆さん、これからも一緒に、楽しいサーバーレスの開発をやっていきましょう」(山田氏)

前へ 1 2 3 次へ

カテゴリートップへ

ピックアップ