AWSを利用したアプリ開発

対象
• オンプレミス環境をクラウド環境に移行を検討中の方
• システムのリニューアルに合わせて、サーバーレス化を検討中の方

これを読んだら得れること
• サーバレスを実現するにあたり、AWSのどのサービスを組み合わせれば良いか分かる。
•膨大なAWSサービスの中から、Webアプリ構築に使えるサービスの概要を知れる。

Transcript

1. サーバーレスを可能にする AWSサービスの概要
2. 2 当ドキュメントのスコープ ✓ AWSのサービスから、Webアプリケーションの構築に使えるサービスの紹介 ✓ サービスをシステムアーキテクチャーの要素別に区分して機能の簡単な紹介と共にメ リットとデメリットを提示し、比較できるようにする ※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示） ✓ 実際のWebサービスを作るために、AWSのサービスを組み合わせたアーキテクチャー例 を提示 ✓ AWSのサービスから、Webアプリケーションの構築に 使えるサービスの紹介 ✓ サービスをシステムアーキテクチャーの要素別に区分して 機能の簡単な紹介と共にメリットとデメリットを提示し、 比較できるようにする ※ただし、IoT、AIに関するAWSサービスは対象外（今後別文書として提示） ✓ 実際のWebサービスを作るために、AWSのサービスを組み 合わせたアーキテクチャー例を提示
3. 目次 1. AWSサービス紹介 • ネットワーキング • コンピューティング • データベース • ストレージ • アプリケーション統合 • セキュリティ • 開発者ツール・DevOps • その他 2. サービス構成例 3. AWSにおける開発・デプロイ
4. 4 1. 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の知識が必要
17. 17 2. サービス構成例
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に昇格
20. 20 レガシー構成から段階的にサーバレス化 VPC Client ✓ APIのエンドポイントをAPI Gatewayに集約する事で、バックエンドに 異なるアーキテクチャを採用可能。フロントはバックエンドの構成を意 識する必要が無い API Gateway EC2 Fargate Lambda RDS DynamoDB Fargate レガシー SQS Lambda ※サブネットの 表記は割愛 機能単位で 段階的に移行が可能 コンテナ化 サーバレス
21. 21 画像アップロード時にサーバレスでサムネイル自動作成 Client S3 Lambda ✓ S3に画像がアップロードされると、S3のトリガーで Lambdaが起動される。 ✓ Lambdaで、アップロードされた画像のサムネイル画像 を作成し、S3に保存する。
22. 22 オンプレミス資産との連携 VPC On-premise Private Subnet EC2 Public Subnet - C EC2 Internet Gateway VPN Gateway Router VPN Connection Internet Server RDS ✓ オンプレミス資産とAWSをVPNで繋げる ✓ 外部（インターネット）との接続を別サブネットにする事で セキュリティを担保
23. 23 AppSyncによる完全サーバレス化 Client DynamoDB AppSync Aurora Serverless S3 Cloud Front Cognito ✓ AppSync(GraphQL)を使用する事で単純なCRUDはLambda無しで可能 ✓ 複雑な処理はLambdaで対応 Lambda Document DB フロントエンド ユーザー管理認証
24. 24 3. AWSにおける開発・デプロイ
25. 25 DevOps ✓ コードがGithubにプッシュされると、自動的にビルド、デプロイが 実行される。　※上図にはテストを含んでいない。 CodePipeline CodeBuild CodeDeploy S3 ECR Source Code Github Fargate Source Artifact Build Register Deploy (Pull) Blue/Green Deploy
26. 26 Cloud9を使ったリモート開発 Cloud9 EC2 Lambda Build Client Client Cloud9 EC2 Client Build ペアプログラミング ペアプログラミング ✓ クライアントからブラウザ経由でコードエディタ等のIDEが使用可能 ✓ 共同編集、ペアプログラミングが可能 ✓ Cloud9からLambdaのローカルテストやデプロイが可能