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

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

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

4 1. AWSサービス紹介

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

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 コンピューティング サービス 区分・概要 メリット デメリット 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しか対応していない Aurora Serverless Auroraの サーバレス版 ● インスタンス管理が不要で自動的にスケーリング する ● 常時起動でも通常の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の知識が必要

17 2. サービス構成例

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 コンテナによるマイクロサービス化　※サーバレスではない 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に昇格

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

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

22 オンプレミス資産との連携 VPC On-premise Private Subnet EC2 Public Subnet - C EC2 Internet Gateway VPN Gateway Router VPN Connection Internet Server RDS ✓ オンプレミス資産とAWSをVPNで繋げる ✓ 外部（インターネット）との接続を別サブネットにする事で セキュリティを担保

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

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

25 DevOps ✓ コードがGithubにプッシュされると、自動的にビルド、デプロイが 実行される。　※上図にはテストを含んでいない。 CodePipeline CodeBuild CodeDeploy S3 ECR Source Code Github Fargate Source Artifact Build Register Deploy (Pull) Blue/Green Deploy

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

No content