AWSアーキテクチャ設計の基本的なケース

後ほど出てくるWell-Architected Freamworkという5つの考え方に則るようにする(厳守ではない)のが基本となるけれども、常に意識するべきところを大雑把に挙げるとセキュリティ・可用性・負荷分散と言ったところ。

1リージョンに2つのAZを作る(3つ以上はコスト効率が増えるに従って悪化する)

主な理由としてはレプリケーションによる可用性の確保またはELB(ロードバランサー)による負荷分散。
前者の場合は

EC2インスタンス
DB

を2つのAZでレプリケーションし、さらに元のAZの方にはS3でバックアップを取るなどすることで冗長構成を組み、実現していくといった形。

Q. VPCはいくつ作ればいいの？

A. 2つ以上のVPCでアーキテクチャを設計して可用性を確保するのが基本となる。

あとは単純に開発環境と本番環境とでVPCを分けるなど。

1つのVPCで設計する場合

可用性が下がるがアイデンティティ管理(IDやパスワードなどのユーザアカウントを一元的に管理する)やハイパフォーマンスコンピューティングで利用が検討される。
小規模開発の場合はVPC管理の手間を考えると2つ以上必要ないケースもある。

VPCの分け方は？

マルチVPC方式(1アカウントで複数のVPCをシステムやサービスによって複数設置する)
マルチアカウント方式(必要なVPCの数だけアカウントを用意して、アカウントに使用する部署などを割り振る)

VPCの連携(接続)ってどうするの？

VPCPeeringを使う。
ただし、既知の通り1:1接続しかできないので1対以上のVPC接続が必要な場合は都度新しくVPCPeeringを設定するかTransit Gatewayを使用する。
また、オンプレ環境との接続の場合はオンプレ環境の窓口となるVPCとのPeering関係に注意する(オンプレ環境と接続したくないVPCは窓口となっているVPCと連携していないか確認する)

サブネットの分割はどうするの？

パブリックサブネットとプライベートサブネットが1つずつ1AZに存在させるのが基本。
インターネットゲートウェイへのルートをプライベートサブネットにつけたものがパブリックサブネットなので、逆に言うと完全にインターネットから隔離する場合はパブリックサブネットはいらないということになる。

Well-Architected Freamwork

以下の5つの設計原則に則ったアーキテクチャ設計のことを指す。

Reliability(信頼性はあるか)
Performance Efficiency(パフォーマンス効率は考えられているか)
Security(セキュリティは適切であるか)
Cost Optimization(コスト最適化は図れているか)
Operational Excellence(運用上の優秀性)

Well-Architected Freamworkの意義・目的

ベストプラクティスを利用することで最適解や改善点を把握する。
参考であり、厳守というものではないが沿うようになるべく努力するといった感じ。
大雑把な例としては以下の通り。

要件定義の場合

AWSを利用したシステム・アプリの案件の場合、ホワイトペーパーを利用して適切かつ最適な要件定義を図る。

設計の場合

ホワイトペーパーを確認しつつ、適切な設計を検討する。

構築時の場合

リリース前にAWSのインフラ構成にリスクや改善点がないかホワイトペーパーに基づいて確認する。

運用時の場合

定期的にホワイトペーパーに沿ったレビューを実施し、リスクや改善点がないか確認をする。

Well-Architected Freamworkの5つの原則

Reliability(信頼性はあるか)

ポイントとしては以下の点となる。

インフラストラクチャサービスの障害復旧の自動化など障害に対する被害の軽減設計ができているか
復旧手順を作るだけではなく、テストした上で検討しているか(いざというときにちゃんと復旧できるように)
需要の変化に応じた水平方向へのスケーラビリティが出来ていて、高可用性は確保できているか
キャパシティの推測はしない(見積もりは拡張性・冗長性を考えて適切に行い、運用時にもモニタリングを行い適宜適切に調整する)
モニタリングと自動化は常に適切に行なっているか

また、基盤・変更管理・障害管理という3つの視点からそれを担うサービスを大別することができる。
代表的なものは以下の通り。

基盤

IAM
VPC
AutoScaling(リソースを自動で適切に調整する機能やサービス、例えばS3におけるライフサイクル管理など)
ELB(ロードバランサー、EC2インスタンスの負荷分散に用いる)
CloudFormation(環境構築をテンプレートで自動化する)

変更管理

Cloud Trail
AWS Config

障害管理

Cloud Watch

Performance Efficiency(パフォーマンス効率は考えられているか)

要件に対してのリソースの最適化によるインフラの効率化という視点。
ポイントとしては以下の点となる。

システム要件を満たすためのコンピューティングリソースの効率化を図れているか
システム要件やAWSサービスの進化に応じてAWSインフラの効率化を促進しているか(AWSサービスの追加や更新に従って設計を見直しているか)
先端技術の一般化に対応しているか
グローバル化を即座に達成しているか
サーバレスアーキテクチャ設計を検討しているか
サービスについて実験的な運用を積極的に行って、新しいサービスやインフラ設計に対応しているか

この項目はコンピューティング、ストレージ、データベース、容量と時間のトレードオフという4つの視点から構成される。

コンピューティング

Auto Scaling
Lambda

ストレージ

EBS
S3
Glacier
EFS

データベース

RDS
Dynamo DB
Elastic Search
Aurora
Redshift

容量と時間のトレードオフ

Cloud Front
Elastic Cache

Security(セキュリティは適切であるか)

AWS内のデータ・システム・アセット(資産)の保護とモニタリングによってセキュリティを高めるという視点。
ポイントは以下の通り。

すべてのレイヤーでセキュリティを適用しているか
アクセス追跡・モニタリングを確実に実施しているか
条件ドリブン(条件を設定してそれを起点としたアクション)のアラートをトリガーとしてセキュリティイベントへの応答を自動化しているか
AWS責任共有モデルに基づく対象範囲の保護に集中できているか
セキュリティのベストプラクティスを自動化しているか
ソフトウェアベースのセキュリティ設定を使用し、迅速でコスト効率の良いスケーリングを安全に実行しているか
仮想サーバーのカスタムベースラインイメージによる新サーバーへの適用を自動化しているか(Cloud Formation)
インフラストラクチャ全体のテンプレ化による管理を行っているか、つまり適切なセキュリティ設定を行ったインフラ環境をテンプレート化して再現性を取れるようにしているか(Cloud FormationやDocker)

項目を構成するのはデータ保護、権限管理、インフラ保護、検出制御の4つ。

データ保護

ELB
EBS
S3
RDS
KMS(暗号キー作成)

権限管理

IAM
MFA

インフラ保護

VPC(ネットワーク制御)

検出制御

Cloud Trail
Cloud Watch
AWS GuardDuty
Amazon Inspector

Cost Optimization(コスト最適化は図れているか)

不必要なリソースの削除や最適な料金選択によりコストを削減するという視点。
ポイントは以下の点。

不必要なリソースを削減しているか
透明性のある費用賦課が成されているか
マネージド型サービスの利用によるコスト削減
固定の償却コストを変動コストへと転換しているか
スケールによるコストメリットは適切であるか
データセンターへの投資不要化(クラウドインフラの利用をするならいらないのでは？という考え)

構成項目は需要と供給の一致、コスト効率の高いリソース、支出の認識、継続した最適化の4点。

需要と共有の一致

Auto Scaling

コスト効率の高いリソース

EC2購入方式
Trusted Advisor

支出の認識

Cloud Watch
見積もりツール

継続した最適化

AWS最新情報
Trusted Advisor

Operational Excellence(運用上の優秀性)

運用上の優秀性とは計画変更が起こった場合や予期せぬイベントの発生時において、自動化された運用実務及び文書化されレビューされた手順があること。
ポイントは以下の通り。

コードに基づく運用実施がなされているか
ビジネス目的に沿った運用手順であるか
定期的かつ小規模で増加的な変更実施は行われているか
予期せぬイベントへの応答テストは適切に行われているか
運用イベントと障害からのフィードバックはなされているか
運用手順が常に最新であるか

構成する項目は準備、運用、進化の3点。

準備

Cloud Formation
Codeシリーズ
Runbook Playbook

運用

System Manager
Service Catalog
Cloud Trail
AWS Artifact
AWS GuardDuty
Cloud Watch
AWS Config
API Gateway

進化

継続的かつ段階的な改善のために時間とリソースを割り当てて、運用の有効性と効率性を向上させるという意識を持つ。

AWSのベストプラクティス

Well-Architected Freamworkと重複するところもあるが、それと合わせて11の原則がベストプラクティスとして定義されている。

スケーラビリティの確保

需要の変化に対応できるアーキテクチャを設計するべきであるという原則。
関連する主要なサービスは以下の通り。

EC2 AutoRecovery
EC2 AutoScaling
Cloud Watch
RDS
DynamoDB

パフォーマンス効率と考え方は近い。

環境の自動化

システムの安定性・整合性及び組織の効率性を改善するため主要プロセスを自動化するという原則。
関連する主要なサービスは以下の通り。

Cloud Formation
Codeシリーズ(CodeCommit、CodeBuild、CodeDeploy,CodePipeline)
ECS(AWS上でDockerを使えるサービス)
Elastic Beanstalk
OpsWorks
Cloud Watch

使い捨てリソースの使用

サーバーなどのコンポーネントを一時的なリソースとして利用・設計するようにするという原則
関連する主要なサービスは以下の通り。

EC2
Auto Scaling

コンポーネントの疎結合

コンポーネント間の相互依存を減らした構成とすることで、1つのコンポーネント変更や障害の影響を削減するという原則。
関連する主要なサービスは以下の通り。

ELB(ロードバランサーでシステム間の直接結合ではなく、ロードバランサーを介した結合をおこなう)
SNS
SQS

サーバーではなくサービス(サーバレスを求める)

マネージド型サービスとサーバレスアーキテクチャにより効率的な設計と運用を実現しようという原則。
関連する主要なサービスは以下の通り。

Lambda
SNS
SQS
ELB
SES
DynamoDB
Amazon API Gateway
Amazon Cognito

最適なデータベースを選択する

ワークロードに応じた最適なデータベースを利用する。
関連する主要なサービスは以下の通り。

RedShift
RDS
DynamoDB
Aurora
Elasticsearch

増大するデータ量に対して対応する

IoTとビックデータを活用するのが当たり前になった昨今、絶えず増加するデータの保持を効率的に実施するべきであるという原則。
関連する主要なサービスは以下の通り。

S3
Kinesis
Glacier

単一障害点の排除

AWSのサービスの多くは高可用が保証されているものが多い(マネージドなサービスが多い)が、以下のサービスにおいてはELB等で設計することで高可用性を図らないといけない。

EC2
Direct Connect
RDS
ELB(上記のようなサービスを設計する際の負荷分散しつつ結合するという役割を担う)

コスト最適化

Well-Architeced Frameworkのコスト最適化に同じ。

キャッシュバックを利用する

繰り返し取り出すデータやコンテンツについてはキャッシュを利用するようにする。
関連する主要なサービスは以下の通り。

Cloud Front
Elastic Cache

セキュリティの確保

Well-Architected Frameworkのセキュリティに同じ。

設計を考えてみる

この段階ではまだ全てのサービスを網羅しておらず、また理解度も低いので今後のためにどういう点に注目するべきなのかを押さえておくの目的としていくつか例を見てみる。

ケース1 可用性と冗長性とネットワークのセキュリティ

VPC(10.0.1.0/16)
AZ1、パブリックサブネット(10.0.5.0/24)、EC2、NATゲートウェイ、エンドポイント
AZ2、プライベートサブネット(10.0.10.0/24)、EC2(DBサーバーとして利用したい)
S3(エンドポイントを介してAZ2のインスタンスに繋がっている)

これを改善しようとすると以下の点が問題点として挙がる。

パブリックサブネットにEC2インスタンスが存在している
DBサーバーとしての利用なのにレプリケーションがなされていない
EC2インスタンスがDBになっている

基本的な解決としては

AZ1にプライベートサブネットを作ってEC2インスタンスをそちらに移す
両AZのプライベートサブネットで同じ構成にしてELBで負荷分散する
EC2を直接DBサーバーとせず、RDS(自動フェイルオーバーの機能がついた仮想DBのセットアップサービス)を使う

この3点である。
よって先程の構成は以下の構成となる。

VPC(10.0.1.0/16)
AZ1、パブリックサブネット(10.0.2.0/24。NATゲートウェイ設置)、プライベートサブネット(10.0.4.0/24。EC2、RDS)
ELB
AZ2、プライベートサブネット(10.0.5.0/24。EC2、RDS)
S3(AZ1のプライベートサブネットに接続)

より改善点を上げるならAZ2にもパブリックサブネットを作り、そこにもNATゲートウェイを設置して両AZのプライベートサブネットからそれぞれのNATゲートウェイにも接続できるようにすることでさらに可用性を上げるということもできる(どちらかのAZが潰れても片方のAZにフェイルオーバーできる)

ケース2 オンプレミス環境とAWSの接続

自社のデータセンターとAWSのVPC環境を接続する……というのは今はそう珍しいことではないのではよくあるユースケースということになる。
VPCのところでオンプレミスとの接続については少し触れたが、改めて何点か特徴を上げる。

接続方法としてはVPNまたはDirect Connectが主に選択される
VPNには主たるものとしてClient VPNとサイト間VPN、用途によってはVPN CloudHub、EC2インスタンス経由によるAWSマーケットプレイスでのサードパーティ製ソフトウェアによるVPN接続などオプションのような方法もある。
サイト間VPNは簡単な例だとオンプレ側のサーバーにも任意の設定を行い(これがCustomer Gatewayとなる)、VPC側に作ったVirtual Private Gatewayと接続を行う
対してClient VPNはフルマネージド型なのでClient VPN エンドポイントを作ってあとは接続の設定をするだけでいい。ただし、オンプレ側のサーバー及びクライアントの証明書とキーは必要になる(相互認証に使う)
Direct Connectは専用線での接続になるのでVPNに比べてセキュアであるが、費用面でも扱える人材という意味でもコストがかかる
サイト間VPNは基本的なVPN接続になるので、複雑な多拠点間の構成からDirect Connectとの共存、多拠点間での接続かつ本社:支社=1:1ではなく、拠点同士でもネットワークを作りたいという場合にCloudHubを併用したりと様々なケースが存在する。

閑話休題、例題として挙げられたのは

自社のデータセンターとVPCがVPNゲートウェイを介して、VPN接続がなされている
ゲートウェイはオンプレ側に1つ、VPNゲートウェイ内に2つ存在している状態

という前提条件であった。
ここで問題なのはデータセンター側にゲートウェイが1つしか存在しないことで、つまりこのゲートウェイが障害等で使えなくなるとVPC内のAWSサービスとの接続はできなくなり、サービス自体がすべてストップしてしまう危険性があるということである(こういう障害点のことを単一障害点という)。
なので解決策としては以下が挙げられていた。

オンプレ側にもゲートウェイを増設して、VPNゲートウェイ側のゲートウェイそれぞれと接続することで、VPN接続を二重にする

ケース3 環境の分離

これは私でも簡単な解決方法がわかるケース。
例としては

単一VPCないに2つのAZにそれぞれPbサブネット1、Prサブネット1を配置して冗長性を持たせている環境がある
そこにさらに同じような環境2つ作る(結果、1AZにPbサブネット3、Prサブネット3となる)

解決策としては

環境ごとにVPCを作る、あるいはそもそもアカウントを分ける

ということが挙げられる。

終わりに

AWSを運用する、及び学習する上で必ずどこかのタイミングここに立ち返るべきポイントだと感じた。
正直、Udemyの講座を受けてるだけでは3割くらいしか理解はできないだろうなと受講している実感としては感じていて、やはりサービスをざっと押さえたあとは模擬問題を解きつつ、ユースケースやサービスの相関関係を考えながらドキュメントやホワイトペーパーを見ないといけないなと思いました。