AWSで用意されているサービスを学ぶために、この本を読んでみました。
様々な定番業務システムを例にどのようなサービスを組み合わせて構築するのか、わかりやすく書いてあったので
ポイントをまとめました。
1章 Webシステム
1-1. パターン1: キャンペーンサイト
- アクセス数は多くないと想定すると高いマシンスペックは要求されない。
→LAMP環境が動く最小構成でスタート(例: t3.medium)。運用しながら必要に応じてスケールアップを検討する。 - 短期間限定での公開、かつコスト優先という前提。
→冗長化やバックアップは考えない。
1-2. パターン2: コーポレートサイト
- マーケティングやコミュニケーションのツールとして重要度が高い。
→複数のEC2インスタンスとELBを組み合わせてWebサーバーを冗長化。
→RDSのレプリケーションによるDBの冗長化。 - 静的コンテンツを中心に閲覧する。
→CDNとS3を使ったキャッシュした静的コンテンツの配信でEC2の負荷を下げる。 - 安定的なレスポンスが求められる。
→「EBS最適化利用」と「プロビジョンドIOPS」の利用により専用のネットワーク帯域を確保。 - 数年単位の長期間の利用が想定される。
→年単位でインスタンスの利用を予約する「リザーブドインスタンス」を使い、利用料金を割引。
1-3. パターン3: 性能重視のイントラWeb
- 時期によって負荷が変動する環境下でもレスポンスを確保したい。
→CloudWatchでインスタンスを監視し、処理能力の低下をトリガーにAuto Scalingで自動スケールアウト。 - ピーク時でも数秒以内のレスポンスを確保したい。
→Amazon ElastiCacheでインメモリーでキャッシュし、参照頻度の高いデータに高速にアクセスできるように。 - 高速なRDSを利用。RDS for AuroraはRDS for MySQLの最大5倍の性能。
1-4. パターン4: 可用性重視のイントラWeb
- 災害時にも業務継続できるようにしたい。
→同リージョン内でもAZをまたいだ構成にする。
→CloudWatchで障害を検知してEC2の自動復旧。
→リージョン間の冗長化。(RDSやS3のレプリカ機能、Route53のDNSフェイルオーバー機能)
→予算に応じたバックアップ方式を選定する。(Active/Active, Active/Stanby)
2章 ストレージシステム
2-1. パターン5: バックアップ
- オンプレミスの複数社内システムのバックアップをAWSに取りたい。
→Storage Gatewayが稼働するバックアップ用のストレージをオンプレミスに用意し、S3に自動バックアップ。 - 容量の大きな画像ファイルやデータベースファイルのバックアップ。
→SGの従量課金を抑えるためS3のAPIを使ったスクリプトでアップロードする。 - ログファイルとデータベースファイルは長期間保存する。
→S3の機能でバージョン管理しつつ、保持期間を超えたファイルはGlacierにアーカイブすることでコストを抑える。 - 重要データをセキュアにバックアップしたい。
→専用線(Direct Connect)を使う。相互接続ポイントまでは通信事業者の専用線接続サービスを使う。
2-2. パターン6: ファイルサーバー
- AWS環境のシステムのファイル管理にファイルサーバーを使う。
→アプリケーションからEFSをファイルサーバーとして利用。 - オンプレのイントラネットで使うファイルサーバーは容量が大きく、頻繁に利用する少数のファイル、長期間保存する大量のファイルがある。
→S3にバックアップを作成し、高頻度にアクセスされるファイルはオンプレにキャッシュする。(階層型ストレージ) - 営業担当者がモバイル端末からファイルへアクセスする。
→権限管理、アクセスログの取得などができるWorkDocsを利用する。WorkDocsへのログイン認証はSimple ADを利用する。3章 データ分析システム
3-1. パターン7: 構造化データの分析
- 構造化データ(今回はRDBに格納されたデータ)を分析するシステムを素早くスモールスタートさせたい。
→Redshiftを利用した分析を行う。既存システムのDBからのデータ取得はAWSパートナー製品のFlydata syncを使う。必要なテーブルのみ選択してRedshiftへデータ連携できるのでコストが抑えられる。
→Redshiftへの接続はTableau Desktopを使うことで接続のための開発が不要になる。
→まずは最小サイズのクラスターで構築し、必要に応じてスケールアウトさせる。 - 経済統計や国勢調査など外部データも分析対象として取り込みたい。
→AWSがオープンデータを提供するEBSパブリックデータセットというサービスを利用。EC2にアタッチしてS3に一旦格納してからRedshiftへ格納する。3-2. パターン8: 非構造化データの分析
- アクセスログやアプリケーションログなどの非構造化データを分析するシステムを構築したい。そのためにログの集約、分析できる形式に変換する必要がある。
→FluentdでログをS3に集約、Amzon EMRとHiveでログをクレンジングし分析に必要な情報のみを抽出、変換する。 - マーケティング担当がアドホックな分析を、他部門が定型的な分析をする。
→Tableau Desktopでアドホックな分析を実施。定型的な分析結果はTableau Serverで公開する。3-3. パターン9: AIとIoT
- 部品の検査工程のうち目視でチェックしている一部の工程をAIで代替したい。検査装置が撮影した画像をAI処理して良品、不良品の判定を行う。
→検査の判定をエッジ側で行うことでネットワーク遅延による判定が間に合わないことを避ける。
→AWS Greengrassで機械学習のインフラ管理を効率化。エッジとクラウドで強調処理をするアーキテクチャーを実現する。 - 機械学習の開発、実行環境の管理を効率的に実現したい。(フレームワークを柔軟的に変えながら最適なアルゴリズムを探していきたい)
→SageMakerを使うことで事前にセットアップされたフレームワークごとの実行環境を自動構成。
4章 アプリケーションの高速開発
4-1. パターン10. サーバーアプリの高速開発
- テスト、デプロイの自動化、省力化することで、ユーザーの反応を見ながら頻繁に修正版のリリースを行いたい。
→CIのマネージドサービスCodePipelineを使ってビルド、テストを自動化、AWS CodeDeployを使ってビルドされたアプリケーションファイルを自動的にEC2インスタンスにデプロイ。 - リリース時にサービスを停止したくない。
→実行環境をコンテナ化し、ECSにデプロイすることで無停止リリースを可能にする。(Blue-Green Deployという手法: 新バージョンをデプロイしポート番号を変更、ELBからの転送ポートを切り替える)4-2. パターン11. モバイルアプリの高速開発
- 開発効率を上げるためにアプリケーションの開発者だけで更新作業を進められるようにしたい。
→AWS Mobile SDKを使うことでモバイルアプリからS3に直接アクセス可能に、サーバーアプリケーションの開発を不要に。 - 物理デバイスを使ったテストを効率化したい。
→AWS Device Farmを使い、AWSのセンターにある物理デバイスを使ってテスト。物理デバイスを保有せずにテストを実行。 - 海外拠点に短期間で、開発・検証・本番環境を展開したい。
→Amazon CloudFormationを使ってテンプレートからインフラを構築、短期で環境構築を行う。5章 クラウドネイティブ
5-1. パターン12. サーバーレスのインフラ
- 新規事業への参入はタイミングが重要、他社に先駆けて顧客開拓を行うため短期間でのシステムが必要。
→動的コンテンツ: AWS Lamda、AWS API Gatewayを利用してEC2を使わずに迅速にWebサイトを構築する。
→静的コンテンツ: AWS CloudFront、Amazon S3を利用してEC2を使わずにコンテンツを配信。
→マネージドサービスのため運用管理やオートスケールはAWSが管理。(EC2とELBの組み合わせの場合、WebサーバーやELBのセットアップが別途必要)5-2. パターン13. マイクロサービスの運用基盤
- アプリケーションの高速開発・リリースを行うためにマイクロサービス化したい。
→EKS(オーケストレーションサービス)でマイクロサービスのコンテナへのリソース割当や実行スケジュールの管理を自動化。EKSを使うことでKubernatesのインフラ構成を意識することなく構成済みの環境を利用できる。
→Fargateで実行環境のプロビジョニングを行う。クラスター内のEC2を自動的に管理。6章 ハイブリッドクラウド
- 既存システムはオンプレで構築しているが、事業継続のために災害対策サイトを用意したい。ただし別のオンプレ環境を用意するのはコストが掛かりすぎる。
→VM Importを使ってオンプレの仮想マシンと同じ構成をEC2上に作成する。DBMSが動作するEC2インスタンスを起動してレプリケーション機能でオンプレと同期する。 - 年に数回、リクエストが集中しCPU不足になることに対処したい。
→ピーク時にオンプレのロードバランサーがAWSのにリクエストを振り分ける。更にCloudWatchでEC2のCPU使用量がしきい値を超えた場合はEC2インスタンスを追加起動しスケールアウト。