cloudpackの村主さん、サーバーレスのハマリどころを語る
続いて「サーバーレスアーキテクチャのアンチパターンと活用方法」をテーマにLTを披露したのは、アイレット（cloudpack）の村主壮悟さん。数多く紹介されたサーバーレスの失敗パターンの一部を紹介していこう。
アイレット（cloudpack） グループリーダー サポートエンジニア 村主壮悟さん
まずは「SDKを使わずにクライアントからAWSサービスにリクエストを投げる」というアンチパターン。これに関しては、可能な限りクラウドが止まるのを前提にリトライ処理などが組み込まれているSDKを使うのが吉だという。逆に言えば、SDKを使わない場合は、リトライ処理が必要で、クライアント側は失敗回数が増えるにつれ待ち時間を指数関数手的に増やす「Exponential Backoff」、Lambdaに関しては3回失敗した後にSQSやSNSにメッセージを投げる「Dead Letter Queue」を利用するのが推奨されるという。
可能な限りリトライ処理などが組み込まれているSDKを使う。
「とりあえずLambdaで」とLambdaを数多く使うのも、やはり推奨できないという。これはEC2よりも高価になる場合があるからだ。「256MBのメモリで1500万回実行し、毎回の実行時間が200ミリ秒だった場合、利用料は約11ドル。これを毎日実行するような場合は毎月で約330ドルかかることになり、EC2より高くなる」と村主さんは指摘。EC2のような運用がなくなるため、Lambdaは検討に値するが、処理量が多い場合はきちんと見積もりをした方がよいという指摘。あと、Lambdaには秒あたり100という実行制限が1アカウント単位でかかるので、上限に対して注意が必要だという。
Lambdaの方がお高い場合もあるので、見積もりをきちんとしておく
次の「重いバッチもLambda」に関しては、最長5分間という処理時間制限が引っかかる。5分以上かかる場合は、SQS（キューイング）やDynamoDB（KVS）、S3（ストレージ）などを間に挟みつつ、別のLambdaに処理を渡す方法がオススメだという。12月にリリースされた「StepFunctions」もこうしたLambdaの数珠つなぎで役にだつ。
時間制限に関しては、API Gatewayにも同様の制限がある。API Gatewayは30秒でタイムアウトしてしまうので、必ず処理を返す必要がある。そのため、「基本的にはフロントのLambdaでレスポンスを返し、非同期で後続のLambdaで処理を継続させる。処理が終わったら、SNSでユーザーに通知するといったことが必要」（村主さん）だという。
API Gatewayのタイムアウトにも注意が必要
その後、村主さんは「1つのlambdaで多数の処理」「監視をしない」「バックエンドにDynamoDB」「直接kinesisに投げる」「LambdaのバックエンドにRDS」などさまざまなアンチパターンを披露。「ハマリどころはいろいろある」（村主さん）とのことで、便利なAWSのマネージドサービスも実行数やキャパシティなどに限界があるため、エラーやスパイク、データロストなどを起こす可能性があり、どのパターンでも設計での一手間や監視、通知などが必要というのが村主さんの論だ。最後、村主さんは「全部サーバーレスである必要はない。RDSにいい機能があるのに、KVSですごく頑張っちゃう感が出てしまう。みんなでハマってベストプラクティスを作っていきましょう」と語って、LTをまとめた。
