kenju's blog

About Programming and Mathematics

『Amazon Web Services 定番業務システム 12 パターン設計ガイド』読書メモ

Why reading this book?

今のチームになってから、仕事で AWS の各種サービスの特性を生かしたログ基盤の設計やアプリケーションを作成する機会が増えてきた。Kinesis Streams や DynamoDB/DynamoDB Streams, Lambda や Redshift など、なんども使用して慣れてきたサービスが増えてきた一方で、AWS のサービス群を俯瞰して整理したいと思うことがあった。

今週は、設計パターンを浅く広く振り返りたい&情報蒐集したいという気持ちになったため、読んでみた。これはその備忘録。

Chapter 1. Web System

Pattern 1. Campaign Site

VPC 内に EC2 instance をたて、Gateway では Route53 でルーティングし、EC2 には EBS を仮想ストレージとして attach するパターン。最小限の構成で、普通の LAMP application や簡単な業務システムを構築するときの、基本パターン。

Pattern 2. Corporate Site

EC2 instance を ELB で冗長化したり、CloudFront 経由で S3 にある静的コンテンツを配信したり、RDS をそれぞれの別の AZ に Master/Slave でレプリケーションしたり、といった冗長化の観点をさらに加えた Web サイト構築のためのパターン。

業務アプリケーションでも、性能要件や非機能要件がより求められる場合の基本パターン。

ポイントは、SSL Termination を ELB で終端させると、EC2 instance 側で SSL 証明書の管理や HTTPS 通信時の SSL Handshake が不要となるため、EC2 instance cost を削減できるという点。その他、AMI(Amazon Machine Image)をテンプレとして作って複数 EC2 instance を作成するとかにも言及。

RDS を別々の AZ に冗長化するときは、"Multi-AZ" を使えば簡単に冗長化できるのは、マネージドサービスの利点。ただし、Multi-AZ を利用するとデータ更新処理にかかる時間が長くなる点に注意。

Pattern 3. Intra Net for Performance

Auto Scaling を生かしたプロビジョニング、キャッシュと Aurora を利用して DB アクセスがボトルネックにならないような性能要件を満たすためのパターン。On-Premise 環境と AWS 環境間のネットワーク接続を AWS Direct Connect を利用することで、ネットワークの帯域確保も意識している。

AWS Aurora は、AWS Summit Tokyo 2018 に参加した時にその高可用性と耐障害性、パフォーマンスを支える設計思想に関する講演があったので聞いてきたけれど、裏でかなり独自の仕組みを工夫していて、非常に技術的にも優れたプロダクトという印象を持っている。その一部は、"Amazon Aurora: Design Considerations for High Throughput Cloud-Native Relational Databases" という論文や、Blackbelt などで広く公開されているので、興味を持っている方いたら是非読んでほしい。

Pattern 4. Intra Net for Availability

可用性にシビアな業務システムを作るときのパターン。Route 53 で、別々の Region に作成したサイトを障害時に備えてルーティングする仕組みを実現している。例えば、メインの東京リージョンが落ちた場合、バックアップ用のシンガポールリージョンにルーティングする、という工夫。

DB のレプリケーションは、Multi-AZ や S3 の "CRR" (Cross-Region Replication) を用いれば、追加でコードを書く必要なくコードを複製させることができる。

ポイントは、サービスが落ちる前提で設計すること。CloudWatch でメインサイトをモニタリングしつつ、EC2 の自動復旧させる仕組みも利用する。また、Route 53 の自動切り替えは、DNS Failover 機能を使う。

Chapter 2. Storage System

Pattern 5. Backup

AWS Storage Gateway を利用した On-Premise 環境におけるデータの S3 バケットへのバックアップや、Amazon Glacier を利用した長期保管など、バックアップ関連のパターンを紹介した節。ここでも、先に紹介された AWS Direct Connect を使って、バックアップやリカバリー要件を満たす選択もある。

Pattern 6. File Server

EC2 instance に NFS server を構築する他、複数の EC2 からマウントできる共有ファイルシステムAmazon EFS を利用したファイルサーバの事例が紹介されている。Amazon EFS は、先日の AWS Summit Tokyo 2018 でも、Tokyo Region にきたことが話題となっていた。また、Amazon WorkDocs を利用したドキュメントの共有も紹介されていた。

Chapter 3. Data Warehouse

Pattern 7. Analysis for Structured Data

Redshift を中心にした分析システムの構成パターン。Redshift には COPY 命令を用いて S3 からロードする。

Pattern 8. Analysis for Un-Structured Data

Fluentd で収集したアクセスログを S3 Bucket に読み込み、Amazon EMR でログデータを整形、整形後のデータを Redshift に取り込み、Tableau で分析するという一連の流れ。Web アクセスログやアプリケーションログを分析するためのパターンの一つ。Tableau は自社でも使っているが、基本的な使い方さえ覚えれば、SQL を書けない社員もダッシュボードを作れるし、比較的高機能だし、非常に便利。

ETL の Transform 部分である EMR の部分はいくつか選択肢があるだろうけれど、EMR は使ったことはない。

Chapter 4. Cloud Native

Patten 9. Serverless Infrastructure

典型的なサーバレス Web システムの構成。静的リソースは CloudFront からの S3 経由で、動的リソースは CloudFront -> API Gateway -> Lamda 経由で返却するパターン。永続化するデータは、とりあえずなんでもよいので外部ストレージに Lambda から保存すればよくて、この本では RDS が紹介されていた。この例では、Lambda Function 作成用の開発向け EC2 instance を立てる例が紹介されていたが、今は Serverless Framework や SAM を使えば良いと思う。

このパターンの場合、Lambda は stateless のため、何らかの状態を保存したい場合は RDS や DynamoDB, S3 などの外部リソースを使う必要がある。要件に応じた外部ストレージを使えば良い。

Chapter 5. Application Development

Patten 10. Server Application Rapid Development

CodePipeline や CodeDeploy を利用することで、CI や自動デプロイを自動化するためのパターン。EC2 instances は ECS を用いて、コンテナーを実行するクラスターを管理している。

Patten 11. Mobile Application Rapid Development

アプリケーション部分は他の節とそこまで違いはないが、Amazon CloudFormation を用いて海外拠点でも日本同様の開発環境を即時に構築できる工夫や、Amazon Device Farm を利用した自動テストの実行、AWS Mobile SDK を利用する開発事例などが盛り込まれた Pattern.

Chapter 6. Hybrid Cloud

Patten 12. Integration with On-Premise Environment

On-Premise 環境とのハイブリッド AWS クラウド環境を築くための工夫が盛り込まれた Pattern. Direct Connect を用いたネットワーク通信路の確保や、VM Import を用いた災害時のサイト環境構築、Auto Scaling & CloduWatch を用いたピーク時のオフロード環境など、今までの節の工夫を総合的に盛り込んだ事例紹介となっている。