More Related Content
Similar to サーバレスを可能にするAWSサービスの概要 (20)
サーバレスを可能にするAWSサービスの概要
- 5. 5
ネットワーキング
サービス 区分・概要 メリット デメリット
VPC 仮想プライベート
クラウド
● 仮想ネットワークを簡単に構築可能
● 細かいセキュリティ設定が可能
● サブネット、ルートテーブルなど最低限のネットワーク
の知識が必要
VPN 仮想プライベート
ネットワーク
● オンプレミスネットワークとVPC間でセキュアな
接続が可能
● 専用線接続サービス(DirectConnect)も用意され
ている
● オンプレを外部ネットワークと接続する事になるのでセ
キュリティ設定を密に行う必要がある
Route 53 DNS ● DNSサーバ構築、管理が不要
● 可用性、拡張性に優れている
● AWSの他サービスとの連携が容易
● 利用料金が掛かる(ただし非常に安価)
CloudFront CDN(コンテンツ
デリバリーネット
ワーク)
● 世界中へ高速にコンテンツを配信可能
● エッジロケーションにより負荷が分散される
● キャッシュにより、オリジンサーバへの負荷を低
減する
● CloudFrontとは別にS3やEC2等、コンテンツを格納す
るサーバ・サービスが必要
- 6. 6
ネットワーキング
サービス 区分・概要 メリット デメリット
Elastic Load
Balancing
ロードバランサー ● アプリのトラフィックを複数のターゲット(EC2、
ECS、Lambda等)に自動的に分散可能
● ELBをSSL終端とする事でサーバ(EC2等)のSSL対
応が不要となる
● Network Load Balancerを使用すれば固定IPでの
運用が可能
● (あえて書くなら)ELBの利用料金が掛かる
API Gateway サーバレスで
APIを公開
● RESTfulAPI、WebSocketAPIをサーバレスで公開
可能
● Lambdaと組み合わせて完全サーバレスのAPIを公
開できる
● スロットリング設定によりバックエンド側の負荷
を制御可能
● データ量等の制約を意識する必要がある
● Lambdaと組み合わせる場合、Lambda側の制限と合わ
せて設計する必要がある
- 7. 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. 8
データベース
サービス 区分・概要 メリット デメリット
RDS RDB ● サーバ構築、管理が不要
● 様々なRDBMSから選択が可能
● Auroraに比べてフェイルオーバーに時間が掛かる
Aurora MySQL、
PostgreSQL互換
● パフォーマンス、可用性、信頼性に優れる
● MySQL、PostgreSQLと互換性がある
● コストが若干高い
● MySQL、PostgreSQLしか対応していない
Aurora
Serverless
Auroraの
サーバレス版
● インスタンス管理が不要で自動的にスケーリング
する
● 常時起動でも通常のAuroraに比べて料金が安い
● DataAPIを使う事でLambdaとの相性問題も改善さ
れる
● キャパシティが0の状態でアクセスすると30秒〜1分程
度の待ちが発生する(コールドスタート)
DynamoDB NoSQL ● サーバ構築、管理が不要
● スケーリングが容易
● Lambdaとの相性が良い
● RDBからの移行は設計からの見直しが必要
● 複雑なクエリが使えないので業務要件に合わせた採用検
討が必要
DocumentDB MongoDB互換 ● サーバ構築、管理が不要
● スケーリングが容易
● Lambdaとの相性が良い
● MongoDBと互換がある
● RDBからの移行は設計からの見直しが必要
● DynamoDBに比べる柔軟なクエリが使えるが、業務要件
に合わせた採用検討が必要
- 9. 9
データベース
サービス 区分・概要 メリット デメリット
RedShift DWH
(データウェアハウス)
● 大量データの分析、集計を高速に行える
● S3上のデータを集計する事も可能
(RedShift Spectrum)
● RDBと比べ
● SQLの並列実行に弱い
● 頻繁に更新するデータには向かない
ElastiCache インメモリ
キャッシング
● サーバ構築、管理が不要
● 超高速アクセス
● 頻繁に更新されるセッション情報などに有用
(DynamoDBだと都度課金が発生する為)
● データの永続化ができない為、他のサービスとの併用な
ど検討が必要
- 10. 10
ストレージ
サービス 区分・概要 メリット デメリット
S3 オブジェクト
ストレージ
● 99.999999999%の耐久性
● データ容量の制限なく保存が可能
● 静的Webホスティングが可能
● 非常に安価
● サーバサイド処理を含むサイト構築は不可
EBS EC2用ブロック
ストレージ
● 4つのボリュームタイプから用途に合わせて選択が
可能
● ボリュームサイズの増加が容易なので、最初から
最大サイズを確保する必要がない
● インスタンス間の共有ができない
● EBS内でデータを永続化すると、単一障害点となってし
まう
EFS ファイル
ストレージ
● EC2、ECS、Fargate間で共有が可能
● 自動で伸縮する為、容量を決める必要が無い
● EBSに比べてコストが高い
S3 Glacier アーカイブ用
オブジェクト
ストレージ
● アーカイブや長期バックアップを目的としている
為、S3より更に安価
● データ取得に数分〜数時間を要するので常時アクセスす
る用途では使用できない
● 3ヶ月未満のデータを削除すると早期削除料金が発生す
る
- 11. 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. 12
開発者ツール・DevOps
サービス 区分・概要 メリット デメリット
CloudFormation コードによる
AWSリソース
の構築・管理
● コード(JSON/YAML)でAWSリソースを自動構築、
管理する事ができる
● コードをインフラの設計書とみなす事ができる
● 環境の複製が簡単に短時間で行える
● CloudFormation独自の記述方法にラーニングコストが
掛かる
CloudWatch リソース、ア
プリのモニタ
リング
● サーバ、コンテナのログをCloudWatchに出力可
能。ローカル保存しない事で、サーバ、コンテナ
のスケーリングが容易になる。(ログの消失を防
ぐ)
● ルールを使って各種処理の定期実行が可能
● 各リソースのメトリクスをグラフィカルに確認可
能
● アラームを設定し、メトリクスのしきい値を超え
た時にアクションを起こす事ができる(Lambdaを
使ってSlackに通知する等)
● 短時間に大量のログを出力(APIをCall)すると、スロッ
トリングが発生し、ログの抜けが発生する
● 大量のログを出力すると意外に料金が高い。
- 13. 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. 14
開発者ツール・DevOps
サービス 区分・概要 メリット デメリット
Cloud9 ブラウザで
使用できるIDE
● サーバ構築、管理が不要
● コードエディタ、デバッガー、ターミナルをブラ
ウザ上で使用できる
● コードエディタを共有しペアプログラミングやリ
アルタイムレビューが可能
● Lambda関数のローカルテスト、デバッグが可能
● ローカル端末の性能に影響を受けない開発が可能
● 利用中はEC2の利用料金が掛かる
- 15. 15
その他
サービス 区分・概要 メリット デメリット
SNS pub/sub
メッセージング
● サーバ構築、管理が不要
● HTTP、Email、SQS、Lambdaと簡単に連携が可能
● モバイル端末へのプッシュ通知が行える
● SQSとの連携で疎結合かつ、並列処理が簡単に行
える
● (あえて書くなら)クラウドネイティブな設計思想が必
要
SQS メッセージキュー ● サーバ構築、管理が不要
● 複雑な処理を分割しやすい(疎結合・マイクロ
サービス化)
● 大量データ処理のスケーリングが容易
● 標準キューでは順序保証が無く、複数回同じメッセージ
が配信される事がある。(要件に合わせてFIFOキュー
を検討すれば良い)
Kinesis データストリーム ● 複数のコンシューマ(読み込む側の処理)
● 大量のログ、イベントデータの収集、リアルタイ
ム解析等に向いている
● SQSと比べて読み書きの実装がやや煩雑
● スケーリングを自前で行う必要がある(ライブラリは公
開されている)
SES メールサービス ● サーバ構築、管理が不要
● SMTPインタフェースを使う事で既存のメール送信
ロジックを流用可能
● バウンス(配信障害)を放置するとSESの利用停止措置を
取られる事がある(適切な処理は必要)
● 送信済みメールを一覧表示するような機能が無い為、必
要であれば自前でアプリを構築する必要がある
- 16. 16
その他
サービス 区分・概要 メリット デメリット
AppSync GraphQL ● サーバ構築、管理が不要
● アプリのオフライン対策を自前で行う必要がない
(オフライン時に発生した更新のみ自動同期す
る)
● DynamoDB、ElasticSearch、Lambda、外部
WebAPIといった複数データソースからのデータ取
得が可能
● GraphQL及びAppSyncの知識が必要
- 18. 18
オンプレからの移行が容易な構成 ※サーバレスではない
Public Subnet - A
VPC
Private Subnet - A
EC2
ALB
RDS(Master)
Client
✓ オンプレミスで稼働中のレガシーシステムの移行が容易
✓ 冗長化する事で可用性を高める(単一障害点を無くす)
✓ EC2は負荷に応じてオートスケーリングする
Public Subnet - C
EC2
Private Subnet - C
RDS(Slave)
Auto Scaling group
EC2をオートスケーリングに対応させるには
● EC2にアプリ情報を永続化させない
● EC2上にログを保持しない
● EC2上にセッション情報等を持たない
EC2を使い捨てできる状態にする事が重要!
障害発生時は自動的に
Masterに昇格
- 19. 19
コンテナによるマイクロサービス化 ※サーバレスではない
Public Subnet - A
VPC
Private Subnet - A
Fargate
ALB
RDS(Master)
Client
✓ Fargate(コンテナ)でマイクロサービス化
✓ Fargateは負荷に応じてオートスケーリング可能(設定が容易)
Fargate
Public Subnet - C Private Subnet - C
Fargate
RDS(Slave)
Fargate
ALB
障害発生時は自動的に
Masterに昇格