イベントへの参加経緯
AWSについて、資格やハンズオンで学習することが多かったので、もっと生の経験から学びたい！というモチベーションがありました。
また、今までの2年間の自分のAWS経験をアウトプットする機会が欲しかったこともあり、compassを彷徨っていたらぴったりそうなアジェンダのイベントがあり、申し込みしました。
また、最近友人同士で勉強会を開いており、もっと参加者を増やしたり会の雰囲気を良くするにはどんなことが必要かも知りたくて参加しました。
自分が参加したパートで話していたことを補足しながらまとめてみます！
イベントリンク:
https://yumemi.connpass.com/event/343066/
アジェンダ一覧：
①失敗から学ぶ！本当にあったしくじり話
②マルチアカウント管理のベストプラクティス
③こんなサービス欲しい！AWSにあったら嬉しいサービス
④あなたの会社でやっているコスト最適化術
参加したアジェンダ 失敗から学ぶ！本当にあったしくじり話
前提
まず、Lambdaとは？
サーバレスなコンピューティングサービスで、インフラの管理をAWSに委託することができ、自動でスケールし稼働した分(リクエスト回数と処理の実行時間)だけ課金が発生するサービスです。
APIGatewayやS3,SQSなどのイベントソースと組み合わせてイベントに反応して関数を実行することができるサービスです。
このように便利なサービスではありますが、同時実行数や処理可能時間、メモリ量なとに制限があります。
そのため、大きなメモリが必要であったり、処理に多くの時間がかかる動作を行いたいときは別のコンピューティングサービスを使用する必要があります。
下記画像はニーズに応じてどのコンピューティングサービスを使用するべきか簡単にまとめられているものです。
ちなみに、このサービスは自分もとてもお世話になっていますが、同時実行数の制限に将来怯えることになるなあと思っています。
次にSQSです。
マイクロ化したアプリケーション同士を柔軟性高く非同期に繋げるためのサービスです。
イメージで説明すると、下図のようにSQSがない状態だとせっかくアプリケーションを細かく分割しても、そのアプリケーション同士が密結合になっており、柔軟性が低い状態です。
そこで、このアプリケーション間にSQSを挟みます。すると、アプリケーション同士が疎結合化し、非同期処理を実現したりリトライなどのエラーハンドリングを容易にすることができます。
しくじり談：SQS/Lambdaの無限ループでコスト大
上記のようにSQS-Lamdba構成は一般的なアーキテクチャではあるのですが、
機能の設定を誤って大変なことを起こしてしまった事例があったようです。
具体的には、Lambda(ここでいうapp2)の処理時間が長期化しており、SQSで設定する「可視性タイムアウトリトライ」(設定した秒数が経過しないと、リトライを行わないようにする設定)を超えてしまっていたようです。
そのような状況で、Lambdaでエラーが発生してSQSにメッセージが残り続けていると大量の回数SQSのメッセージをトリガにLambdaが起動してしまい、ランニングコストが跳ね上がってしまう、という事態につながったということでした。
イベントの感想
今回紹介した話題だけでなく様々な失敗エピソードを共有できてとても楽しかったし学びになりました。
かっこいい成功エピソードはネット上にもたくさんありますが、このような失敗エピソードはオフラインだからこそしゃべれる内容だし、自分も同じ失敗をしないようにAWSリソースを確認する観点を養うことができたと感じました。
今後もこのようなイベントに積極的に参加したり、機会があればイベントの運営側もやってみたいと思いました。
イベントを開催していただいた三社様、イベント運営いただいた方々ありがとうございました！