スクリーンショット 2016-06-06 14.51.59

こんにちは。商品本部デジタルマーケティング室の 作野 浩之 です。

前回の記事に引き続き、
先日、AWS Summit TokyoDevelopers Conference で発表した「タウンワークにおけるサーバーレスアーキテクチャデザイン」の詳細について、お話しようと思います。
今回お話するのはAWS Lambdaを利用した具体的なインフラの管理コストの削減方法です。

おさらい:Lambdaの特徴

Lambdaはイベントドリブン型のアプリケーション実行基盤です。
今回の AWS Summit では色々な会社がLambdaを推していました。それくらい便利で勢いのあるサービスという事なのではないでしょうか?

ざっと、特徴を挙げると以下のようになります。

  • サーバーレス
  • 勝手にスケールしてくれる
  • イベントドリブンな実行環境
  • Scheduled eventに対応

最も大きな特徴としては、やはり「サーバーレスで勝手にスケールしてくれる」事ではないかと考えています。
サーバを自前で建てて、何か処理を行おうと思うと環境構築に時間がかかったり、環境の差分に苦しんだり、運用に時間を使ったりと色々と大変な事が多いです。その点、上述した大変な事に使っている時間を全て"コード"(つまりはビジネスロジック)に集中させる事ができるLambdaという物は劇的にインフラの管理コストを削減してくれます。

どういった時にLambdaを使えば良いのか?

今回の発表で強烈に意識した事は、「Lambdaを使った汎用的な管理コスト削減方法を持ち帰ってもらう」事でした。
というのも、「Lambdaを知っている・使ってみたいと考えている人は多い一方で、実際に使っているという人はとても少ない」という話を聞いたからです。それ故、割りと簡単にでき、それでいて汎用的なLambdaの使い方を紹介する事で、皆様に便利なサービスの恩恵を受けて欲しいと思いました。

Case.1 ストリームデータ処理

スクリーンショット 2016-06-10 17.41.17

まずはじめは、前編にも掲載したように、ストリームデータの処理に対してLambdaを利用しています。

  • ログデータが飛んできた時に、API GatewayからKinesisへ送る
  • Kinesisから即座にログを流す
  • ある程度の間隔を開けてログをS3に保存する

以上の3つの用途別にLambdaを利用しています。

このように、Kinesisにログデータを集約しておき、目的に応じてLambdaを分けて利用するという処理を行う事で、ログデータを非常に柔軟に取り扱う事ができます。

Case.2 (小さな)バッチジョブ

スクリーンショット 2016-06-10 17.42.32

次の例は、Lambdaを使用してバッチジョブを実装したという例です。
今回のプロジェクトでは特徴量の保存先としてDynamoDBを使用しているのですが、DynamoDBは日付を指定して、過去のレコードをパージするなどの柔軟なパージを行うことができません。
そこで、データが溜まりすぎる事を防ぐために、ユーザの特徴を格納するテーブルを週ごとに作成し、保存するテーブルを切り替えています。

ここで、問題となってくるのがDynamoDBの操作です。
テーブルを週次で管理すると、Capacityの上げ下げやテーブルを作成したり、削除したりするなど非常に細やかな操作をDynamoDBに対して行う必要があります。これらの処理の1つ1つはとても軽い処理で、数秒または1秒以下で終わるようなものです。言い換えると、わざわざサーバを立ててcronでやるか?という性質のバッチなので、LambdaのScheduled eventを使ってこれらの処理を行っています。Lambdaではcron式も使用できるので、時間の指定も非常に柔軟に行う事ができます。

Case.3 インテグレーション 他サービスとの連携

他サービス(Slack)との連携の例です。

スクリーンショット 2016-06-10 17.46.27
異常検知をするとなった際に、通知先をEmailアドレスに設定している方は多いと思いますが、Emailは他の業務のコミュニケーションにまぎれてしまう可能性が非常に高いです。
そこで、Lambdaを用いてSlackに通知を飛ばすように設定したという例です。
モニタリング対象サービスに対してCloudWatch + SNSを連携させる事は一般的な通知と同様なのですが、SNSの後にSlackに通知を送るLambdaを挟んでやって、LambdaのEvent Sourcesに該当のSNSトピックを指定します。このようにすると、SNSトピックが発行されたタイミングでLambdaがキックされ、Slackの指定のチャンネルに対して通知を行う事ができます。

これは、導入してみてすぐに効果を実感したLambdaの利用例で、導入も非常に手軽に行う事ができるので、ぜひ参考にして頂ければ、と考えています。

スクリーンショット 2016-06-10 17.45.28

使用料金がバーストする事を防ぐという例です。
AWSは従量課金なので、十分にサービスの課金ポイントを把握していなかったり、サービスについて詳しく知らなったりすると、使用料金がバーストして請求書を見て青くなるという事もありえます。
そういう不幸な事態を防ぐために、毎日使用料金をSlackに通知するという仕組みも導入しています。これは、スケジュールドイベントを使って請求レポートから今月の使用料金を計算して、指定のチャンネルに送るだけです。なので、これも非常に簡単に導入する事ができます。

これで、いつもと違うような料金の推移を見せた時に、実際にどんな事にかかっているのかを分析しようとするモチベーションにつながります。
単純にサービスが拡大した結果であれば、素直に喜べばいいのですが、「何か明らかに意図しない挙動の結果コストが上がっていた」などという事をすぐに検知できるようになります。

これも簡単にできる割には効果が大きく、前日の2倍ものコストがかかっていた時には、メンバー全員が青くなってボトルネックの調査をして、すぐに解決する事ができた、という事も実際にプロジェクトを進めていく上でありました。

まとめ

上記の例のようにサービス間の連携を行う際に、Lambdaを利用するというケースが今回のプロジェクトでは非常に多かったです。Lambdaは汎用的に使用できるので、今回のプロジェクトに限らず、活用できる場面は多くあると考えています。面倒な準備が不用で非常にクイックに始める事ができるので、積極的に導入して頂ければ、すぐに手間だと思っていた作業を失くす事ができるかもしれません。