はじめに
CTOのあまどです。先週までラスベガスでAWS re:Invent 2019 に参加しました。re:Inventはもちろんですがポーカーの大会に二戦出場・二戦とも優勝という好成績を残せたのがかなり嬉しかったです。
今回はre:Inventの中でも特にサーバーレス系セッションで面白かった内容を紹介したいと思います。
AWS re:Invent 2019 の雰囲気
AWS re:Invent は毎年ラスベガスで行われるAWSの一大カンファレンスです。2016年には30,000人の参加者だったこのイベントは毎年1万人ずつのペースで増え、今年は65,000人以上が参加するというとてつもない規模のカンファレンスになっています。
AppleのWWDCが6,000人、GoogleのGoogle I/Oが5,000人程度という数字からも規模の違いが想像できるかと思います。
ラスベガスは都市人口が65万人程度しかないのに対して観光客は2018年で4,200万人訪れている、アメリカの代表的な観光都市の一つです。
しかし4,200万人なので平均すると1日11.5万人程度の観光客です。それに対し re:Invent 参加者は 12/1 ~ 12/6 の間は 65,000人いるので、つまり住民の数を加味してもざっくり計算して「街を歩けば12人に1人はre:Invent参加者」という状態です。実際夜のラスベガスを出歩いたりカジノでふとテーブルに座ると結構な確率で参加者バッジを首からぶら下げてる人に遭遇しました。
#reInvent #RedisLive found another one! pic.twitter.com/F6brNDPxiT
— Amiram Mizne (@AmiramMizne) December 4, 2019
ラスベガス中心の交差点では巨大なRedisの広告が
Serverless architectural patterns and best practices (ARC307) セッション概要
今回参加したセッションの中で特に面白かったのは「Serverless architectural patterns and best practices (ARC307)」です。
すでに世に広く普及しているLambdaを中心としたサーバーレスなシステムのアーキテクチャを、いくつかのわかりやすい設計パターンに分けて紹介するセッションでした。航空券予約システムのケーススタディやHSBC銀行の実例なども折り込みながらサーバーレスで複雑なシステムを設計する時のベストプラクティスを解説してくれる実用的なセッションでした。
下記でいくつかのパターンやケースを紹介していきます。
設計パターン1: The comfortable "REST" （快適なREST）
- X-Ray と CloudWatch Logs & metrics でロギングとプロファイリングをしやすくしておく
- CloudWatch 埋め込みメトリクスフォーマット が新しくリリースされ、さらに詳細なロギングがラクになった
- 認証はCognitoで行う
- 機密クレデンシャルは Secrets Manager に保存
- Lambda Power Tuning というOSSツール を使うとLambdaのメモリやCPUの最適化ができ、コスト節約にもつながる
設計パターン2: The "cherry-pick" （GraphQL API）
AppSyncのGraphQLを中心に据え、柔軟性をもったDB選定ができるパターンです。
- データソースにLambdaを使うことで複雑なロジックにも対応
- API(Cognito)で認証認可を行う。個別のデータのフィールドレベルの認可も行うことが可能
- AppSyncに最近リクエストキャッシュも搭載された ので性能向上が見込める
設計パターン3: Call me, "Maybe" （Webhook）
SlackやGitHubなど別クライアントからWebhookを受けた時、特に同時実行が多い場合にも考慮し効率的に処理するパターンです。
- Lambdaの同時実行数をコントロールするためにKinesisを活用するのが良い。API Gateway から直接Lambdaに連携せず、間にKinesisを挟む
- LambdaはDLQよりも、最近登場した Lambda Destinations を使う方がおすすめ。DLQは失敗したイベントが追加の情報なくそのまま転送されるだけだが、Lambda Destinations が失敗したイベントを転送する場合は失敗した理由などのコンテキスト情報も付加してくれ扱いやすい。
- センシティブなデータはLambdaをミドルウェア的に挟むことでマスキング/難読化をかけることができる。 dazn-lambda-powertools はまさにその用途のオープンソースなLambdaコードなので、そのまま使える
設計パターン4: The big "Fan" （ファンアウト）
並列度の高いリクエストやジョブを設計する際の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" （ストリーミング）
APIからとにかく大量にデータを受けて、どんどんS3に流し込むようなシステムの設計パターンです。特にS3のデータをAthenaで分析するユースケースなどが想像されるものです。ペイロードの内容によって違うS3バケットに投入したい、というちょっと複雑な要件もスマートに設計することができます。
- API Gateway から SNS を直接連携する
- Lambdaはただのルーティングの役割として「どのSNSはどのKinesis Data Firehoseに転送するか」をハンドリングするだけ。複数のSNSが全て同じLambdaを呼び出すようにしておけば、コーディング量は最小で済む
- センシティブなデータは先述された
dazn-lambda-powertoolsで難読化
設計パターン6: The "Strangler" （マイグレーション）
オンプレやレガシーな環境からクラウド/サーバーレスに移行していく際のスマートで効率的な設計パターンです。
- まず既存のAPIの手前にAPI Gatewayを挟む
- 移行していけるAPIから一つずつ新しいサーバーレス環境にルーティングを振っていく
- API Gateway に Lambdaでカスタムの認証機構を連携することが可能
- CloudWatch Logs & metrics , X-Ray でレガシー環境と新環境のロギング・トレーシングは統一化するのが大事。複数環境で複数のロギングを監視するのは大変になる
その他参考リンク
セッションの中で後学のために有効なリンクも紹介されていました。自分もまだ深くは見れていませんが、時間を見て少しずつ勉強していこうと思います。
- Serverless Microservice Patterns for AWS
- 今回紹介されたような設計パターンやそれ以外の合計17のサーバーレスなマイクロサービスを構築するための設計パターン週の記事。
- AWS Serverless Airline Booking
- 100%サーバーレスで作った航空券予約システム（デモアプリケーション）の完全なソースコードと設計図。
まとめ
大小様々なサービスやビジネスがサーバーレスな設計を導入していく中で、API Gateway - Lambda - DynamoDB のようなシンプルな設計では足りないというのが知られ始め、業界全体として知見が増えています。
今回 AWS re:Invent 2019 でこのようなセッションや、その他ワークショップや様々な人との情報交換から「サーバーレスが本当に普及しており、新たな技術分野として体系的知識が出来上がり始めている」というのを肌で感じることが出来て非常によかったです。
ぜひ皆さまもスケーラブルで安定性の高いサーバーレスな設計を目指す際の参考にして頂ければ幸いです。
積極採用中！！
子育て家族アプリFammを運営するTimers inc.では、現在エンジニアを積極採用中！
急成長中のサービスの技術の話を少しでも聞いてみたい方、スタートアップで働きたい方など、是非お気軽にご連絡ください！
採用HP: http://timers-inc.com/engineerings
