サーバーレス開発チームがAWSの要件定義方法を紹介！クラウドサーバーこそ事前設計が大切🤔

こんにちは！

今回はサーバーレス開発チームによるサーバーレスアーキテクチャの要件定義についてご紹介していきます。ガイドライン的な内容になりますので、ぜひ参考にしてください！

想定する読者

• サーバーレスアーキテクチャの要件定義をしたいヒト
• サーバーレスの要件定義方法について知りたいヒト
• AWS における要件定義のノウハウを知りたいヒト

はじめに

サーバーレスとは、サーバーの管理をしなくていいということです。そのため今まで必要だったインフラ周りの運用作業はすべてクラウドプロバイダがマネージドしてくれました。

しかしそんなサーバーレスな製品たちはすべて完璧なわけではありません。それぞれに活躍できる場所をアーキテクトがしっかり設計することで真にクラウドネイティブなアプリケーションを構築できます。それでは解説していきましょう。

サーバーレスの制約

サーバーレス製品には必ず制約があります。そのためサーバーレスはアプリケーションにとっての「銀の弾丸」ではありません。アーキテクトや開発者自身が、制約の中で最大限に活用するという意識を持ちながら扱わなければならないのです。

例えば AWS のサーバーレスアーキテクチャにとって必要な Lambda ですが、これには以下のような制約があります。

リソース	デフォルトのクォータ	引き上げることができる最大
同時実行数	1,000	数万
アップロードされた関数 (.zip ファイルアーカイブ) とレイヤーのストレージ。各関数バージョンとレイヤーバージョンは、ストレージを消費します。	75 GB	Terabytes
コンテナイメージとして定義された関数のストレージ。これらのイメージは Amazon ECR に保存されます。	「Amazon ECR サービスクォータ」を参照してください。
Virtual Private Cloud (VPC) ごとの Elastic Network Interfaces注記このクォータは、Amazon Elastic File System (Amazon EFS) などの他のサービスと共有されます。「Amazon VPC クォータ」を参照してください。	250	数百

上記の制約から、頻繁に Lambda が呼び出されるようなサービスでは、サポートに問い合わせて同時実行数などを事前に引き上げる必要があります。これは SQS などのサーバーレス製品でも同じです。しかしながらなんでも制約を引き上げれるわけではないので、この点は要件と照らし合わせて利用可否を決定していってください。

サーバーレス製品を扱う際には、要件によってクォータを引き上げるかどうかを判断する必要性が常にあります。要件定義の際はこれらを考慮し、本番運用に向けてあらかじめ準備することが必須となります。

サーバーレスはすべてをマネージドしてくれない

サーバーレスといえど、すべてをマネージドしてくれるわけではありません。サーバーレスによってサーバーに関連する管理運用作業はクラウドプロバイダが行うので不要となりますが、制約の引き上げやアプリケーションのログ管理、アラートの設定などは当然ながら利用者が準備する必要があります。

ただ IaaS 製品に比べるとサーバーレス製品の運用負荷は明らかに下がっておりますので、意識して見なければいけない箇所は必然的に少なくなります。

ここで伝えたいのはサーバーレス製品でアプリケーションを構築したからよしなにやってくれるという認識で設計を行うのではなく、不足している運用体制をよく考えて基盤を整えることが重要といったことになります。

サーバーレスに適さないユースケース

サーバーレスだからといってアプリケーションやインフラに関するすべての課題を払拭してくれるわけではありません。Lambda を例にすると、適さないユースケースは以下のようなものが挙げられます。

適さないユースケース	解決策
リクエストの処理に15分以上かかる場合	Fargate を利用する 小さな処理に分割して複数の Lambda でロジックを実装する
大容量のファイルを取り扱う場合	Fargate を利用する
ハイスペックな CPU とメモリが必要な場合 GPU が必要な場合	EC2 を利用する

このように Lambda だけでは対応しきれない処理があるのは事実です。しかしサーバーレス製品は Lambda だけでなく Fargate や SQS、Step Functions などもあるので、これらを組み合わせて実現できないかを検討してほしいです。

要件を定義していくなかでサーバーレスに適さないユースケースに当てはまる場合、対応策を早めに考えておかなければ複雑なアーキテクチャとなってしまいますので、必ずこれを意識しながら要件定義を進めてください。

サーバーレスアーキテクチャにおける認証認可

サーバーレスアーキテクチャにおいてセキュリティを強固にするために重要なのは、各リソース間での認証認可となります。サーバーに関するセキュリティは AWS の責任範囲となりますが、そのリソースにアクセスさせるかさせないかは利用者の責任となるからです。

まず意識してほしいのは、サーバーレスでなくてもセキュリティホールに繋がりかねない IAM の権限管理の徹底です。IAM のロールやポリシーを設計する際は、必ず最小権限にしましょう。不必要な権限を与えすぎた場合、それはインシデントに繋がる可能性を与えてしまうことになりかねないので注意してください。

次に意識してほしいのは、各リソースのポリシーです。S3 のバケットポリシーや SQS のポリシーのように、リソースが保持しているポリシーがありますので、こちらにおいても不必要な権限を与えず、最小権限の原則を徹底しましょう。

API に対する認証認可について

API Gateway や AppSync の認証認可には Cognito を利用しましょう。IAM ロールでの認証認可もできますがその場合、ユーザー情報の管理やきめ細かいアクセス管理ができにくくなってしまいます。Cognito 以外だと Lambda Authorizer、サードパーティ製品だと Auth0 などを利用するのも選択肢です。

なお Cognito の設計をする際は、設定値は今後変更しないことを念頭に置きながら要件を決定していくことが重要です。Cognito は変更が効かない箇所がかなり多いので、はじめに構築した設定値を変えために作り直す必要があったりします。あとから変更が効かない箇所については事前に調べて、Cognito の柔軟性を確認してください。

サーバーレスにおけるデータストアの選択

サーバーレスアーキテクチャにおけるデータストアは主に DynamoDB が利用されます。DynamoDB の利点は、RDBMS と比べてスケーリングに優れていること、またSLAがグローバルテーブルの場合 99.999％ と高可用性なところです。

DynamoDB の特性上、高負荷なアクセスの場合自動にスケーリングする Lambda との相性は抜群です。RDS の場合、最大同時接続数の問題などから Lambda との相性はさほどよくはありません。

しかしながら近年AWSからリリースされた、Amazon Aurora Serverless 、Amazon RDS Proxy はこの問題を解決するサービスであるため、サーバーレスにおいて RDBMS を利用したい場合はこれらの選択肢を考慮して設計してください。

サーバーレスの要件定義で作成する主要資料の紹介

私たちが通常、サーバーレスの開発プロジェクトで作成する資料を一部紹介いたします。

資料名	概要	関連するAWS製品
認証認可設計	ユーザーのサインアップ/サインインの方法等々を定義 ※ 利用者の一覧定義を含む	CognitoUserPool
構成案/プロトタイピング	構成案とプロトタイピングを使用しどのようなデータアクセスがされるかを定義
データストアー設計	構成案をもとにどのようなデータが必要となるのかを定義	DynamoDB OpenSearch
アクセス数	サービスの利用者一覧をもとに日/月単位でDAU/MAU/UU、同時アクセス数を定義	Lambda 及びサーバーレス製品全般
機能一覧	機能名と概要をリストアップ
API 定義	Graphql または RestAPI 形式にて API をリストアップ	AppSync APIGateway
scheme.graphql	Graphql のスキーマを定義	AppSync
定期実行処理	定期的に実行する処理を定義	EventBridge
インシデント通知	障害発生時の通知処理のワークフローを定義	CloudWatchLogs CloudWatch SubscriptionFilter SNS Lambda
CI.CD 設計	CI.CD のワークフローを定義	CodePipeline CodeBuild CodeDeploy

関連記事

• AWS Fargateのユースケース＆Lambda関数との使い分けを解説！サーバーレスとコンテナーサービスの思考フロー🤔
• AWSの利用費用を下げるときの思考フロー＆テクニックを紹介！運用コストを見直しましょう
• サーバーレスエンジニアがLambdaのオートスケーリングとスロットリング対策について解説します🤔！
• AWS Fargateで考えるコンテナセキュリティ！コンテナ管理の高度な思考🤔

まとめ

サーバーレスアーキテクチャを実践する上では、とにかく事前に制約と利用可否を確認することが重要です。設計を行う際にはぜひ上記で指摘しているポイントを考慮してみてください。

このブログでは、AWS の記事をどんどん公開しておりますので、ご興味のある方は他の記事もご覧いただければと思います。

AWS に関する開発は、お気軽にお問い合わせください。