Movatterモバイル変換

サーバーレスを可能にするAWSサービスの概要

2当ドキュメントのスコープ✓ AWSのサービスから、Webアプリケーションの構築に使えるサービスの紹介✓ サービスをシステムアーキテクチャーの要素別に区分して機能の簡単な紹介と共にメリットとデメリットを提示し、比較できるようにする※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示）✓ 実際のWebサービスを作るために、AWSのサービスを組み合わせたアーキテクチャー例を提示✓ AWSのサービスから、Webアプリケーションの構築に使えるサービスの紹介✓ サービスをシステムアーキテクチャーの要素別に区分して機能の簡単な紹介と共にメリットとデメリットを提示し、比較できるようにする※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示）✓ 実際のWebサービスを作るために、AWSのサービスを組み合わせたアーキテクチャー例を提示

目次1. AWSサービス紹介● ネットワーキング● コンピューティング● データベース● ストレージ● アプリケーション統合● セキュリティ● 開発者ツール・DevOps● その他2. サービス構成例3. AWSにおける開発・デプロイ

5ネットワーキングサービス区分・概要メリットデメリットVPC 仮想プライベートクラウド● 仮想ネットワークを簡単に構築可能● 細かいセキュリティ設定が可能● サブネット、ルートテーブルなど最低限のネットワークの知識が必要VPN 仮想プライベートネットワーク● オンプレミスネットワークとVPC間でセキュアな接続が可能● 専用線接続サービス(DirectConnect)も用意されている● オンプレを外部ネットワークと接続する事になるのでセキュリティ設定を密に行う必要があるRoute 53 DNS ● DNSサーバ構築、管理が不要● 可用性、拡張性に優れている● AWSの他サービスとの連携が容易● 利用料金が掛かる（ただし非常に安価）CloudFront CDN(コンテンツデリバリーネットワーク)● 世界中へ高速にコンテンツを配信可能● エッジロケーションにより負荷が分散される● キャッシュにより、オリジンサーバへの負荷を低減する● CloudFrontとは別にS3やEC2等、コンテンツを格納するサーバ・サービスが必要

6ネットワーキングサービス区分・概要メリットデメリットElastic LoadBalancingロードバランサー ● アプリのトラフィックを複数のターゲット(EC2、ECS、Lambda等)に自動的に分散可能● ELBをSSL終端とする事でサーバ(EC2等)のSSL対応が不要となる● Network Load Balancerを使用すれば固定IPでの運用が可能● (あえて書くなら）ELBの利用料金が掛かるAPI Gateway サーバレスでAPIを公開● RESTfulAPI、WebSocketAPIをサーバレスで公開可能● Lambdaと組み合わせて完全サーバレスのAPIを公開できる● スロットリング設定によりバックエンド側の負荷を制御可能● データ量等の制約を意識する必要がある● Lambdaと組み合わせる場合、Lambda側の制限と合わせて設計する必要がある

7コンピューティングサービス区分・概要メリットデメリットEC2 仮想サーバ ● オンプレミスからの移行が容易● 既存資産を活かし易い● スケーリングが容易● サーバの管理を自前で行う必要があるLambda サーバレスでコードを実行● サーバ構築、管理が不要● AWSの様々なサービスから呼び出せる● APIGatewayやAppSyncと連携しサーバレスなWebAPIを提供可能● ステートレスなので、コネクションプールを使用できずRDS(RDB)との相性が悪い。コネクションの枯渇が発生しやすい。→ Aurora ServerlessであればOK。● 既存資産を活かしにくいECS コンテナ ● 1サーバで複数のコンテナを起動できるのでマイクロサービスの提供が容易● コンテナを動かす為のサーバ(EC2)が必要● Docker等のコンテナを構築する知識が必要Fargate コンテナ ● コンテナを動かすサーバの管理が不要● マイクロサービスの提供が容易● スケーリングが容易● Docker等のコンテナを構築する知識が必要● EC2の同一スペックに比べてコストが若干割高。ただしFargateはAWSの重要サービスである為、値下げされる事が多い。AWS Batch バッチ処理 ● サーバの管理が不要（自動起動、停止）● 必要な時に必要なリソースを利用可能● JP1のようなサードパーティ製のようなリッチなジョブスケジューラ機能が無い

8データベースサービス区分・概要メリットデメリットRDS RDB ● サーバ構築、管理が不要● 様々なRDBMSから選択が可能● Auroraに比べてフェイルオーバーに時間が掛かるAurora MySQL、PostgreSQL互換● パフォーマンス、可用性、信頼性に優れる● MySQL、PostgreSQLと互換性がある● コストが若干高い● MySQL、PostgreSQLしか対応していないAuroraServerlessAuroraのサーバレス版● インスタンス管理が不要で自動的にスケーリングする● 常時起動でも通常のAuroraに比べて料金が安い● DataAPIを使う事でLambdaとの相性問題も改善される● キャパシティが0の状態でアクセスすると30秒〜1分程度の待ちが発生する（コールドスタート）DynamoDB NoSQL ● サーバ構築、管理が不要● スケーリングが容易● Lambdaとの相性が良い● RDBからの移行は設計からの見直しが必要● 複雑なクエリが使えないので業務要件に合わせた採用検討が必要DocumentDB MongoDB互換 ● サーバ構築、管理が不要● スケーリングが容易● Lambdaとの相性が良い● MongoDBと互換がある● RDBからの移行は設計からの見直しが必要● DynamoDBに比べる柔軟なクエリが使えるが、業務要件に合わせた採用検討が必要

9データベースサービス区分・概要メリットデメリットRedShift DWH(データウェアハウス)● 大量データの分析、集計を高速に行える● S3上のデータを集計する事も可能(RedShift Spectrum)● RDBと比べ● SQLの並列実行に弱い● 頻繁に更新するデータには向かないElastiCache インメモリキャッシング● サーバ構築、管理が不要● 超高速アクセス● 頻繁に更新されるセッション情報などに有用（DynamoDBだと都度課金が発生する為）● データの永続化ができない為、他のサービスとの併用など検討が必要

10ストレージサービス区分・概要メリットデメリットS3 オブジェクトストレージ● 99.999999999%の耐久性● データ容量の制限なく保存が可能● 静的Webホスティングが可能● 非常に安価● サーバサイド処理を含むサイト構築は不可EBS EC2用ブロックストレージ● 4つのボリュームタイプから用途に合わせて選択が可能● ボリュームサイズの増加が容易なので、最初から最大サイズを確保する必要がない● インスタンス間の共有ができない● EBS内でデータを永続化すると、単一障害点となってしまうEFS ファイルストレージ● EC2、ECS、Fargate間で共有が可能● 自動で伸縮する為、容量を決める必要が無い● EBSに比べてコストが高いS3 Glacier アーカイブ用オブジェクトストレージ● アーカイブや長期バックアップを目的としている為、S3より更に安価● データ取得に数分〜数時間を要するので常時アクセスする用途では使用できない● 3ヶ月未満のデータを削除すると早期削除料金が発生する

11セキュリティサービス区分・概要メリットデメリットIAM AWSのアクセス管理● AWSの各リソース(サービス)に対するアクセス管理を行う事が可能● ユーザー単位で細かい権限管理が可能● アクセスエラーが発生した時に原因の究明が難しい（慣れが必要）Cognito アプリのアクセス管理● アプリのサインアップ、サインインを簡単に実現できる● Google、Facebook等のIDプロバイダと連携が可能● Oauth2.0、OpenIDConnect等のアクセス管理をサポートしている● バックエンドリソースのアクセス管理が可能● (あえて書くなら）Cognitoに関する専門知識の習得が必要WAF Webアプリケーションファイアウォール● SQLインジェクション、クロスサイトスクリプティングなど一般的な攻撃をブロック可能● 特定のトラックパターンを除外可能● 事前設定済みのマネージドルールを利用可能● マネージドルールはブラックボックス化されている為、誤認識された時に対処が難しい。ACM SSL証明書の発行・管理● ELB、CloudFrontで使用できるSSL証明書を無料で発行できる● SSL証明書が自動更新される● 外部発行のSSL証明書を可能● EC2では利用できない。(前段のELBで利用する事でセキュリティは担保可能)

12開発者ツール・DevOpsサービス区分・概要メリットデメリットCloudFormation コードによるAWSリソースの構築・管理● コード(JSON/YAML)でAWSリソースを自動構築、管理する事ができる● コードをインフラの設計書とみなす事ができる● 環境の複製が簡単に短時間で行える● CloudFormation独自の記述方法にラーニングコストが掛かるCloudWatch リソース、アプリのモニタリング● サーバ、コンテナのログをCloudWatchに出力可能。ローカル保存しない事で、サーバ、コンテナのスケーリングが容易になる。（ログの消失を防ぐ）● ルールを使って各種処理の定期実行が可能● 各リソースのメトリクスをグラフィカルに確認可能● アラームを設定し、メトリクスのしきい値を超えた時にアクションを起こす事ができる(Lambdaを使ってSlackに通知する等)● 短時間に大量のログを出力(APIをCall)すると、スロットリングが発生し、ログの抜けが発生する● 大量のログを出力すると意外に料金が高い。

13開発者ツール・DevOpsサービス区分・概要メリットデメリットCodeCommit プライベートGitリポジトリ● サーバ構築、管理が不要● AWSならではのセキュリティ、高可用性を持つGitリポジトリが使用できる● ソースコード管理までAWSに依存してしまう。LambdaのようにAWS有りきのプロジェクトであれば良いか。CodePipeline 継続的デリバリー ● サーバ構築、管理が不要● Gitリポジトリの更新をトリガーとして、ビルド、テスト、デプロイまで自動化する事が可能● 手動の承認を入れる事が可能なので、誤って本番環境にリリースする事を防げる● CodeBuild、CodeDeploy等、他のサービスと合わせて知識が必要CloudBuild ビルド、テストの自動化● サーバ構築、管理が不要● ビルド、テストを自動で行う事が可能● 並列ビルドが可能（自動スケール）● CodeBuild、CodeDeploy等、他のサービスと合わせて知識が必要CodeDeploy 自動デプロイ ● サーバ構築、管理が不要● EC2、Fargate、Lambda、オンプレミスサーバへアプリを自動デプロイ可能● Blue/Greenデプロイが選択可能● CodeBuild、CodeDeploy等、他のサービスと合わせて知識が必要

14開発者ツール・DevOpsサービス区分・概要メリットデメリットCloud9 ブラウザで使用できるIDE● サーバ構築、管理が不要● コードエディタ、デバッガー、ターミナルをブラウザ上で使用できる● コードエディタを共有しペアプログラミングやリアルタイムレビューが可能● Lambda関数のローカルテスト、デバッグが可能● ローカル端末の性能に影響を受けない開発が可能● 利用中はEC2の利用料金が掛かる

15その他サービス区分・概要メリットデメリットSNS pub/subメッセージング● サーバ構築、管理が不要● HTTP、Email、SQS、Lambdaと簡単に連携が可能● モバイル端末へのプッシュ通知が行える● SQSとの連携で疎結合かつ、並列処理が簡単に行える● (あえて書くなら）クラウドネイティブな設計思想が必要SQS メッセージキュー ● サーバ構築、管理が不要● 複雑な処理を分割しやすい（疎結合・マイクロサービス化）● 大量データ処理のスケーリングが容易● 標準キューでは順序保証が無く、複数回同じメッセージが配信される事がある。（要件に合わせてFIFOキューを検討すれば良い）Kinesis データストリーム ● 複数のコンシューマ(読み込む側の処理)● 大量のログ、イベントデータの収集、リアルタイム解析等に向いている● SQSと比べて読み書きの実装がやや煩雑● スケーリングを自前で行う必要がある（ライブラリは公開されている）SES メールサービス ● サーバ構築、管理が不要● SMTPインタフェースを使う事で既存のメール送信ロジックを流用可能● バウンス(配信障害)を放置するとSESの利用停止措置を取られる事がある（適切な処理は必要）● 送信済みメールを一覧表示するような機能が無い為、必要であれば自前でアプリを構築する必要がある

16その他サービス区分・概要メリットデメリットAppSync GraphQL ● サーバ構築、管理が不要● アプリのオフライン対策を自前で行う必要がない（オフライン時に発生した更新のみ自動同期する）● DynamoDB、ElasticSearch、Lambda、外部WebAPIといった複数データソースからのデータ取得が可能● GraphQL及びAppSyncの知識が必要

18オンプレからの移行が容易な構成　※サーバレスではないPublic Subnet - AVPCPrivate Subnet - AEC2ALBRDS(Master)Client✓ オンプレミスで稼働中のレガシーシステムの移行が容易✓ 冗長化する事で可用性を高める（単一障害点を無くす）✓ EC2は負荷に応じてオートスケーリングするPublic Subnet - CEC2Private Subnet - CRDS(Slave)Auto Scaling groupEC2をオートスケーリングに対応させるには● EC2にアプリ情報を永続化させない● EC2上にログを保持しない● EC2上にセッション情報等を持たないEC2を使い捨てできる状態にする事が重要！障害発生時は自動的にMasterに昇格

19コンテナによるマイクロサービス化　※サーバレスではないPublic Subnet - AVPCPrivate Subnet - AFargateALBRDS(Master)Client✓ Fargate(コンテナ)でマイクロサービス化✓ Fargateは負荷に応じてオートスケーリング可能(設定が容易)FargatePublic Subnet - C Private Subnet - CFargateRDS(Slave)FargateALB障害発生時は自動的にMasterに昇格

20レガシー構成から段階的にサーバレス化VPCClient✓ APIのエンドポイントをAPI Gatewayに集約する事で、バックエンドに異なるアーキテクチャを採用可能。フロントはバックエンドの構成を意識する必要が無いAPI GatewayEC2FargateLambdaRDSDynamoDBFargateレガシーSQS Lambda※サブネットの表記は割愛機能単位で段階的に移行が可能コンテナ化サーバレス

21画像アップロード時にサーバレスでサムネイル自動作成Client S3 Lambda✓ S3に画像がアップロードされると、S3のトリガーでLambdaが起動される。✓ Lambdaで、アップロードされた画像のサムネイル画像を作成し、S3に保存する。

22オンプレミス資産との連携VPCOn-premisePrivate SubnetEC2Public Subnet - CEC2 InternetGatewayVPNGatewayRouterVPNConnectionInternetServerRDS✓ オンプレミス資産とAWSをVPNで繋げる✓ 外部（インターネット）との接続を別サブネットにする事でセキュリティを担保

23AppSyncによる完全サーバレス化ClientDynamoDBAppSyncAuroraServerlessS3CloudFrontCognito✓ AppSync(GraphQL)を使用する事で単純なCRUDはLambda無しで可能✓ 複雑な処理はLambdaで対応Lambda DocumentDBフロントエンドユーザー管理認証

243. AWSにおける開発・デプロイ

25DevOps✓ コードがGithubにプッシュされると、自動的にビルド、デプロイが実行される。　※上図にはテストを含んでいない。CodePipelineCodeBuildCodeDeployS3ECRSource Code GithubFargateSource ArtifactBuildRegisterDeploy(Pull)Blue/GreenDeploy

26Cloud9を使ったリモート開発Cloud9 EC2LambdaBuildClientClient Cloud9 EC2ClientBuildペアプログラミングペアプログラミング✓ クライアントからブラウザ経由でコードエディタ等のIDEが使用可能✓ 共同編集、ペアプログラミングが可能✓ Cloud9からLambdaのローカルテストやデプロイが可能

サーバレスを可能にするAWSサービスの概要

Movatterモバイル変換

Change Language

サーバレスを可能にするAWSサービスの概要

Embed presentation

Recommended

More Related Content

What's hot

Similar to サーバレスを可能にするAWSサービスの概要

More from Fixel Inc.

サーバレスを可能にするAWSサービスの概要