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

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

こんにちは!

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

想定する読者

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

はじめに

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

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

サーバーレスの制約

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

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

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

上記の制約から、頻繁に 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.graphqlGraphql のスキーマを定義AppSync
定期実行処理定期的に実行する処理を定義EventBridge
インシデント通知障害発生時の通知処理のワークフローを定義CloudWatchLogs
CloudWatch SubscriptionFilter
SNS
Lambda
CI.CD 設計CI.CD のワークフローを定義CodePipeline
CodeBuild
CodeDeploy
サーバーレスの要件定義で作成する主要な資料一覧

関連記事

まとめ

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

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

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