2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

AWSにおいてのサーバーレス[SAA]

Last updated at Posted at 2022-09-14

はじめに

元々はバックエンドエンジニアとして開発を主な業務としおりましたが、ここ最近AWSを触れる機会が増えて
きたためサーバーレスについて今回記事を作成いたしました。

また、SAA取得のための勉強に伴いLambda, API Gateway, ECS(Fargate, EKS, ECR)などの
サーバレスサービスが頻出のためサーバーレスについての備忘録として残しておきます。

そもそもサーバーレスとは?

開発者がサーバーのリソースを意識しない、つまりサーバーの管理・運用が不要である
というこうことで実際にはサーバーが存在しています。

サーバーレスのメリット

  • サーバーの運用が不要
    • サーバーやOSなどのインフラに対するプロビジョニング・維持管理の作業が不要となります。これまで、それらの作業に費やしていた手間や時間を大幅に削減することが可能です。
  • 利用した分だけの課金
    • サーバーレスは、IaaSなどの他のクラウド利用形態と違い、利用した時間や実行回数に応じて課金がされます。例えばAWS Lambdaは、Lambda関数のリクエスト数(実行回数)と、Lambda関数のメモリに応じた実行時間に対する課金体系です。
  • 柔軟なスケーラビリティ(Scalability)
    • 事前に必要なキャパシティを考慮しなくても、リクエスト数や負荷によって自動的にスケーリング(拡張/縮退)されます。
  • 可用性(Availability)・回復性(Recoverability)の向上
    • 多くのサーバーレスのプラットフォーム/コンポーネントには、冗長化の構成などを意識しなくても、デフォルトで可用性と耐障害性機能が備わっています。

サーバーレスのデメリット

  • 既存のコードが使えない
    • LambdaやCloudfunctionには既存のアプリケーションコードをそのまま移行することはできず、ある程度の変換が必要になります。
  • ベンダーロックイン
    • サーバレスアーキテクチャはクラウドベンダーをまたがって開発することが前提となっていません。また、一度開発したアプリケーションを他クラウドベンダーへ移行することは推奨されません。例えば、1PB(ペタバイト)のデータを1か月Amazon S3に配置しておく料金と、GCSなどの外部ストレージに転送する料金では、後者のほうが高くなります。

AWS上でよく使用されるサーバーレスアーキテクチャ

システムを作ろうとした際に必要なものとして思い浮かべるのは、APIサーバー、DBサーバーだとおもいます。
よくある構成として、画面から必要な情報をサーバーに問い合わせる、もしくは必要な情報をサーバーに送信する、サーバーはデータをDBに保存、DBから取得する、といったものを思い浮かべると思います。
AWS図.drawio.png
AWSで言うとEC2上にAPIサーバーを構築し、そこにビジネスロジックを実装、RDSに静的なデータを保存する、という構成になります。
ほとんどの場合この構成でシステムの作成が可能となっております。

しかし、この構成の場合EC2が稼働中はずっと課金されますし、サーバーのメンテナンスの必要もあります。
APIサーバーなら1日にほとんど呼ばれないなんてこともあります。
無駄な課金を避けたい この時の解決策の一つがサーバレス設計になります。
以下の設計をみてください。

AWSサーバーレス.drawio.png

API GatewayとはAPIサーバーの機能を提供するサービスです。
例えば、REST APIの場合、API呼び出しのエンドポイントや呼び出す際のメソッド(GETやPOSTなど)が決まれば、APIの呼び出しができます。
その部分をAPI Gatewayは担当します。イメージとしてはNode.jsのExpressの部分を丸っと提供しているイメージですね。

次に、Lambda上にビジネスロジックを記載します。
API Gatewayに対してAPI呼び出しがあると、そのパスに紐づくLambdaが実行されます。
このLambdaは様々なサービスと連携することができるので、サーバーレスが成り立っています。
つまり、Lambdaからデータベースへのアクセスができるので、DBからのデータ取得、DBへのデータ書き込みができるのです。

では、API呼び出しの一連の流れの具体例を見てみましょう。

https://xxx.yyy/user へGETメソッドでユーザデータの取得をする
https://xxx.yyy/user へGETにアクセスがあると、API Gatewayは対応するLambda関数を呼び出す
Lambda関数はPythonでビジネスロジックが実装されており、DBから必要なデータを取得し、整形してデータを返す
もちろん、上記はEC2を使っても同じことはできます。
ただし、API Gatewayを使うことでAPI部分のミドルウェアを開発者が管理する必要がありません。
画面から操作するだけでAPIサーバーの部分が自動的に作成され、開発者が意識するのはAPI呼び出し後のLambdaの部分のみです。
API Gatewayの課金も、APIの呼び出し時のみなので、APIが呼ばれなければ料金はかかりません。
Lambdaも従量課金なのでAPIが呼ばれなければ料金はかかりません。
また図ではRDSとして記載していますが、DynamoDBの場合は、オンデマンドキャパシティを使用することで最大料金を下げることができます。

最後に

サーバーレス構成の場合は学習コストがありますが、料金を下げる場合がほとんです。
また、SAAにおいてもコスト効率を意識した設計ができることは重点ポイントして
問題に出題されるので念頭に置いておくといいと思います。

今回の記事が少しでも参考になれば嬉しいです。

参考記事

2
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
2
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?