作ろうと思った背景

とあるMysqlのテーブルのデータ量が増加することによって、サービスの一部機能に影響がでてきそう箇所があったので事前に検知して対応できるようにしたかった。

作りがあまり良くないので、snapshotからデータベースを立てて、indexをつけるためにAlter tableをしないと、クエリが帰ってこない状態だった状況だった。

毎月or気になった時に、上記の作業をすることがとてもムダだと思ってなんとかしたいと思った。

処理概要

①CloudWatch Events - Scheduleを使って起動（毎日3時に起動）
②S3にあるファイルから、SQLに保存しているクエリに必要なデータを取得（あらかじめ取得しておいた日付と検索開始地点のプライマリーキー）
③RDSに接続して対象のデータが何件あるか検索
④カスタムメトリクスを使って、件数をプロット
⑤毎月or気になった時に一回④のカスタムメトリクスを確認

なぜlambdaを使ったの？

・今の監視処理に入れる
・新しくサーバを立てて実装する
・lambdaを使う

の選択肢の中で、

「新しくサーバを立てて実装する」は、お金もかかるし、サーバを運用しないといけなくなるので却下。

「今の監視処理に入れる」は、プラスのお金はかからないし、サーバの運用が増えるわけでもないし、これを活用するのがいいかなと思った。

そんな中
「lambdaを使う」判断をしたのは、主な理由はサーバレスを試して見たいから。
将来、「この処理するなら運用コストもかかるし、単純にサーバ代とられるし、サーバいらなくない・・・？」みたいな話が出た時に

サーバレスにするためのに学習していきたかったし、工数も大きく変わらないし、コア機能ではなかったためやってみる判断をした。

学んだこと

• VPCにおかないとRDSに接続できないので、VPCにおいてかつ、NAT ゲートウェイを使っているが、NAT ゲートウェイ自体にお金かかるし、lambdaの起動が遅くなるのでほんとは使いたくない
  
• lambda functionをzipで固めるときに、ディレクトリで固めると階層が一つ深くなるので動かなくなる
  
• Mysqlを動かすためにどこかのサーバでyumをしてそのファイルを持ってくるみたいなことやったけど、めんどくさかった。RDSとは相性よくないな・・・と思った
  
• サーバレスの運用方法を決めてずに、lambda functionが増えて行くと手をつけられない秘伝のたれ達が生まれるであろうことが実感できた
  

今後の話

• サーバレスの運用についてを学ぶ
  わけわからないものが勝手に動いているとか、数年先に何してるかわからなくて止められなくなるみたいな状態になり逆に運用コストがかかってしまう状態を防ぐため（SAM?, Serverless flamewark?,）
  
• サーバレスの開発の流れを学ぶ
  とりあえず、Lambdaの画面を使って開発をして、Testボタンを押してテストを実施していたが、どのエディターを使ってどうテストするのが早いのかは知りたいなと思ったため
  
• 本格的に活用したいと思ったときはNAT ゲートウェイの間借りは変えたい
  今後lambda functionを作って行くなら、NAT ゲートウェイを間借りしている状態はやめて、lambda function用に一個作りたい。間借りしたままにするとややこしいことになるため