Timers Tech Blog

グローバルな家族アプリFammを運営するTimers inc (タイマーズ) の公式Tech Blogです。弊社のエンジニアリングを支える記事を随時公開。エンジニア絶賛採用中!→ https://timers-inc.com/engineering

実戦で使える AWS Lambda, SNS, Kinesis 等を使ったサーバーレス設計パターン #reinvent #reinvent2019

はじめに

CTOのあまどです。先週までラスベガスでAWS re:Invent 2019 に参加しました。re:Inventはもちろんですがポーカーの大会に二戦出場・二戦とも優勝という好成績を残せたのがかなり嬉しかったです。
今回はre:Inventの中でも特にサーバーレス系セッションで面白かった内容を紹介したいと思います。

AWS re:Invent 2019 の雰囲気

AWS re:Invent は毎年ラスベガスで行われるAWSの一大カンファレンスです。2016年には30,000人の参加者だったこのイベントは毎年1万人ずつのペースで増え、今年は65,000人以上が参加するというとてつもない規模のカンファレンスになっています。
AppleWWDCが6,000人、GoogleGoogle I/Oが5,000人程度という数字からも規模の違いが想像できるかと思います。

f:id:timers-tech:20191205202129j:plain
カンファレンス後のパーティーは広大な敷地に複数のステージを設営し、野外フェス化させていました

ラスベガスは都市人口が65万人程度しかないのに対して観光客は2018年で4,200万人訪れている、アメリカの代表的な観光都市の一つです。
しかし4,200万人なので平均すると1日11.5万人程度の観光客です。それに対し re:Invent 参加者は 12/1 ~ 12/6 の間は 65,000人いるので、つまり住民の数を加味してもざっくり計算して「街を歩けば12人に1人はre:Invent参加者」という状態です。実際夜のラスベガスを出歩いたりカジノでふとテーブルに座ると結構な確率で参加者バッジを首からぶら下げてる人に遭遇しました。

ラスベガス中心の交差点では巨大なRedisの広告が

Serverless architectural patterns and best practices (ARC307) セッション概要

今回参加したセッションの中で特に面白かったのは「Serverless architectural patterns and best practices (ARC307)」です。
すでに世に広く普及しているLambdaを中心としたサーバーレスなシステムのアーキテクチャを、いくつかのわかりやすい設計パターンに分けて紹介するセッションでした。航空券予約システムのケーススタディHSBC銀行の実例なども折り込みながらサーバーレスで複雑なシステムを設計する時のベストプラクティスを解説してくれる実用的なセッションでした。

下記でいくつかのパターンやケースを紹介していきます。

設計パターン1: The comfortable "REST" (快適なREST)

f:id:timers-tech:20191203122906j:plain
サーバーレスアーキテクチャパターン 快適なREST
API Gateway + Lambda + DynamoDB の一般的なサーバーレスAPIを中心に据えて、その周りに運用を助けるためのモニタリングやロギングのプラクティスを固めたアーキテクチャです。

設計パターン2: The "cherry-pick" (GraphQL API

f:id:timers-tech:20191203123341j:plain
サーバーレスアーキテクチャパターン GraphQL

AppSyncのGraphQLを中心に据え、柔軟性をもったDB選定ができるパターンです。

設計パターン3: Call me, "Maybe" (Webhook)

f:id:timers-tech:20191212155401p:plain
サーバーレスアーキテクチャパターン webhook

SlackやGitHubなど別クライアントからWebhookを受けた時、特に同時実行が多い場合にも考慮し効率的に処理するパターンです。

  • Lambdaの同時実行数をコントロールするためにKinesisを活用するのが良い。API Gateway から直接Lambdaに連携せず、間にKinesisを挟む
    • Lambda自体の同時実行数パラメータで制限をしてしまうと溢れた場合は単純なThrottleを発生させてしまう。一方、Kinesisをその手前に挟むことで、Kinesisの方で大量なイベントを全てバッファし、1秒に1回程度の頻度でLambdaを発火させてくれるようになる。
  • LambdaはDLQよりも、最近登場した Lambda Destinations を使う方がおすすめ。DLQは失敗したイベントが追加の情報なくそのまま転送されるだけだが、Lambda Destinations が失敗したイベントを転送する場合は失敗した理由などのコンテキスト情報も付加してくれ扱いやすい。
  • センシティブなデータはLambdaをミドルウェア的に挟むことでマスキング/難読化をかけることができる。 dazn-lambda-powertools はまさにその用途のオープンソースなLambdaコードなので、そのまま使える

設計パターン4: The big "Fan" (ファンアウト)

f:id:timers-tech:20191203124437j:plain
サーバーレスアーキテクチャパターン ファンアウト

並列度の高いリクエストやジョブを設計する際のSNS, SQS, Kinesis などを組み合わせて Lambdaコンシューマを実行させるパターンです。

  • API Gateway は必ずLambdaに結びつける必要はなく、直接AWSサービスと連携できる。そのため API Gateway -> SNS というフローが作れる
  • SNSをLambdaのトリガーにすると1SNS 1Lambdaの実行になってしまいコストや同時実行数が膨れ上がるので、SQSを挟むのをおすすめする。SQSの場合は10件バッファしてからLambdaを実行することができる。
  • SNSの内容によって実行されるLambdaコンシューマが複数ある場合は、毎回全種類のLambdaが実行されないように受信側で Message Filtering を設定する。そうする事で受信するLambdaコンシューマは自分に関係のあるSNSメッセージしか受信しないようになり効率的。
  • 入力ペイロードが大きかったり(~1MB) スループットが非常に高い場合は API Gateway と連携させるのは SNSではなくKinesisの方が適している。(図の上半分側)

設計パターン5: They say "I'm a Streamer" (ストリーミング)

f:id:timers-tech:20191212155510p:plain
サーバーレスアーキテクチャパターン ストリーミング

APIからとにかく大量にデータを受けて、どんどんS3に流し込むようなシステムの設計パターンです。特にS3のデータをAthenaで分析するユースケースなどが想像されるものです。ペイロードの内容によって違うS3バケットに投入したい、というちょっと複雑な要件もスマートに設計することができます。

  • API Gateway から SNS を直接連携する
  • Lambdaはただのルーティングの役割として「どのSNSはどのKinesis Data Firehoseに転送するか」をハンドリングするだけ。複数のSNSが全て同じLambdaを呼び出すようにしておけば、コーディング量は最小で済む
  • センシティブなデータは先述された dazn-lambda-powertools で難読化

設計パターン6: The "Strangler" (マイグレーション

f:id:timers-tech:20191203125326j:plain
サーバーレスアーキテクチャパターン マイグレーション

オンプレやレガシーな環境からクラウド/サーバーレスに移行していく際のスマートで効率的な設計パターンです。

  • まず既存のAPIの手前にAPI Gatewayを挟む
  • 移行していけるAPIから一つずつ新しいサーバーレス環境にルーティングを振っていく
  • API Gateway に Lambdaでカスタムの認証機構を連携することが可能
  • CloudWatch Logs & metrics , X-Ray でレガシー環境と新環境のロギング・トレーシングは統一化するのが大事。複数環境で複数のロギングを監視するのは大変になる

その他参考リンク

セッションの中で後学のために有効なリンクも紹介されていました。自分もまだ深くは見れていませんが、時間を見て少しずつ勉強していこうと思います。

まとめ

大小様々なサービスやビジネスがサーバーレスな設計を導入していく中で、API Gateway - Lambda - DynamoDB のようなシンプルな設計では足りないというのが知られ始め、業界全体として知見が増えています。
今回 AWS re:Invent 2019 でこのようなセッションや、その他ワークショップや様々な人との情報交換から「サーバーレスが本当に普及しており、新たな技術分野として体系的知識が出来上がり始めている」というのを肌で感じることが出来て非常によかったです。

ぜひ皆さまもスケーラブルで安定性の高いサーバーレスな設計を目指す際の参考にして頂ければ幸いです。

積極採用中!!

子育て家族アプリFammを運営するTimers inc.では、現在エンジニアを積極採用中!
急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください!
採用HP: http://timers-inc.com/engineerings

www.wantedly.com

Timersでは各職種を積極採用中!

急成長スタートアップで、最高のものづくりをしよう。

募集の詳細をみる