【AWS】SAA資格取得のための学習用備忘録(AWSのアーキテクチャ設計)

AWSにおけるアーキテクチャ設計

AWSが考える適切な設計というものは、ベストプラクティスという形でホワイトペーパーなどで公開されている。

ただしここには膨大な数の文書が存在し、その対象も多岐にわたる。

効率的に学習するには、まず基本的な考え方であるAWS Well-Architectedフレームワーク(AWSによる優れた設計のフレームワーク)を読み学習するのが効果的。

回復性の高いアーキテクチャ

Well-Architectedフレームワークでは、回復性の高いアーキテクチャは信頼性の柱とも表現されている。

信頼性とは、サービスの障害からの復旧、負荷に応じた自動的なリソースの調整、あるいはインスタンスやネットワークに生じた障害の軽減を考慮されたシステム。

★回復性の高いアーキテクチャを設計するための知識は、試験範囲の中でも大きな比重を占める

回復性の高いアーキテクチャの構成要素

信頼性・回復性の高いアーキテクチャの構成要素は次の5つ。

・復旧手順のテスト

・障害からの自動復旧

・スケーラブルなシステム

・キャパシティ推測が不要であること

・変更管理の自動化

復旧手順のテスト

逆説的に思えるかもしれないが、クラウド環境はオンプレミス環境に比べると専用の環境を用意しやすいと言える。

オンプレミスの場合、例えばネットワーク機器や負荷分散装置のようなものは、システム間で共用で使われていることが多くある。

クラウドの場合は、これらの設備も仮想的に専有できる。

そのため、障害の発生をシミュレーションしやすく、復旧手順のテストも容易になる。

全ての要素のテストをすることや、障害復旧の自動化の設計も可能となる。

障害からの自動復旧

AWSでは、主要なリソースの状況をメトリクスとして追跡することが可能。

また、閾値を設けて、負荷状況などが超過した場合にトリガーを設定することが可能。

それによりリソースの追加や、問題の発生したリソースの自動的な交換などの設定ができる。

これが障害からの自動復旧。

障害からの自動復旧は、小さな労力でシステムの運用面で多大な効果をもたらす。

このアーキテクチャの設計には、まず閾値の検知にCloudWatchを利用する。

インスタンス単体での障害復旧の場合、CloudWatchの自動復旧(Auto Recovery)を利用することで、インスタンスもしくはインスタンス内のOSなどの障害を検知して自動復旧することが可能となる。

自動復旧は、ELBなどのロードバランサー配下のインスタンス群に適用されることが少なくない。

その場合はAuto Scalingと組み合わせ、ELBから定期的にヘルスチェックを行い、一定期間の応答がない場合は自動的にインスタンスを切り離し、新たなインスタンスを追加する。

負荷増大などのリソース不足の場合は、新たなインスタンスを起動してロードバランサー配下のリソースの総量を増やす。

DBの場合は、RDSを使ってマルチAZ構成をとることが基本となる。

マスターとスタンバイの構成となっていて、マスター障害時に自動的にスタンバイがマスターに昇格して復旧する。

このあたりの処理にはDNSの切り替えを利用する。

DNSの切り替えは、AWSのサービス全般に適用できる復旧方法。

Black Beltオンラインセミナーで詳しく紹介されているため、読んで理解することをおすすめ。

スケーラブルなシステム

オンプレミスの場合、リソースの総量はあらかじめ用意した分しかない。

そのため、スケーラブルなシステムを作るのは非常に困難。

これに対してクラウドは、需給に応じてリソースを増減することが容易。

そのため、スケーラブルなシステムを構築することが、信頼性の観点からもコストの観点からも重要となる。

スケーラブルなシステムを検討する際は、まずは水平方向の拡張(スケールアウト)が可能な仕組みを考える。

スケールアウト可能なアーキテクチャとは、インスタンスを単純に追加していけば、システム全体の処理能力が上がるという構造。

この構成には2つのポイントがある。

1つは、増減するサーバーに状態を持たないように(ステートレスに)すること。

例えばセッションのようなここのユーザーの状態をインスタンスに持つと、ユーザーごとの処理は特定のサーバーでしかできない。

これを防ぐのがステートレスなサーバー。

具体的には、Webサーバーの場合はセッションを外部のサービスに出す。

AWSのサービスの場合は、ElastiCacheを利用することが一般的だが、DynamoDBを利用する場合もある。

もう1つは、ここのリソースのサイズをできるだけ小さくすること。

リソースサイズが大きいと、負荷がかかっていない状態での無駄が大きくなる。

また、リソースを追加した際にも過剰なリソースを追加することになる。

小さな単位でリソース追加できることはクラウドの大きな利点。

キャパシティ推測が不要であること

オンプレミスでは、あらかじめ用意した物理機器以上の性能を出すことができない。

そのため事前のキャパシティ推測が重要になる。

これに対して、クラウドはリソース追加が用意なためキャパシティ推測の重要性は低下する。

一方で、クラウドの場合でも、アーキテクチャのキャパシティ設計は重要。

これは、水平方向に追加(スケールアウト)できるリソースは何か、あるいは垂直方向に拡張(スケールアップ)しないといけないリソースは何かを正しく知ること。

一般的にWebサーバーやアプリケーションサーバーはスケールアウトが容易。

これに対してDBサーバーはスケールアウトは難しく、スケールアップすることが多い。

DBサーバーの一般的なスケーリングとしては、以下がある。

・参照系と更新系を分離する

・参照系はリードレプリカを利用し、スケールアウト可能

・更新系はスケールアップして処理性能をアップさせる

1台のリソースDBに対して作成できるリードレプリカの上限は決まっているため注意が必要。

MySQLやPostgreSQLでは5台まで。

Auroraの場合は最大15台まで設定可能。

また、Auroraの場合は、デフォルトでリード(読み込み)エンドポイントとライト(書き込み)エンドポイントが用意されている。

RDSのマルチAZ構成のように通常時に全く利用されないスタンバイのようなリソースがないだけ、リソースの利用効率が高くなる。

またRDBMS以外の選択肢として、DynamoDBがある。

DynamoDBの特徴として、性能を設定値で増減させるということが可能。

また性能自体も自動で増減させることができるため、キャパシティの柔軟性がより上がる。

変更管理の自動化

AWSではリソースの増減が用意。

その恩恵を受けるためには、変更管理の自動化が必要。

つまり、リソースの追加時に、追加されたリソースが他のサービスと同じ設定・アプリケーション・データを持っている必要があるということ。

構成管理の自動化には、CloudFormationやAMI、OpsWorksがよく利用される。

試験でよく問われるのはAuto Scaling時のインスタンス構成。

AMIを使うパターンの場合は、常にAMIを最新の状態に保つゴールデンマスター方式。

それ以外に、インスタンス起動時に最新のソース・コンテンツを取得するパターン。

このパターンの場合は、ソース・コンテンツの取得方法の他に、起動後に即ELBに組み込まれて不整合が発生しないようにするための手法が問われる。

それ以外のパターンとしては、サーバーからデータを排除して、NASのような共有のコンテンツ置き場をマウントするパターンがある。

NASの実現方法として、AWSにはEFSやFSxがある。

★回復性の高いアーキテクチャは5つの要素で構成される：復旧手順のテスト、障害からの自動復旧、スケーラブルなシステム、キャパシティ推測が不要であること、変更管理の自動化

パフォーマンスに優れたアーキテクチャ

パフォーマンスに優れたアーキテクチャとは、リソースを効率的に使用し、需給や技術の進化に合わせて効率的に利用すること。

そのためには、適切なリソースの選択と確認、リソース状況のモニタリング、トレードオフの判断が必要。

リソースの選択

パフォーマンスに優れたアーキテクチャの第一歩は、適切なリソースの選択。

主なリソース種別としては、コンピューティング、ストレージ、データベース、ネットワークがある。

コンピューティングリソース

代表的なリソースであるコンピューティングリソースの場合、インスタンス・コンテナ・関数(Faas:Function as a Service)の選択肢がある。

常駐型のプロセスが必要な場合は、インスタンスもしくはコンテナを利用する。

イベント駆動の非常駐型のプロセスの場合は、関数型のリソースを利用する。

インスタンス型のサービスにはEC2やElastic Beanstalkがあり、コンテナ型のサービスにはECSがある。

関数型のサービスにはLambdaを利用する。

インスタンスとコンテナの使い分けについては、色々な考え方があるため一概にはいえないが、原則的に「アプリケーションの可用性を高めたい」「アプリケーションのOSとの依存度を下げたい」といった場合はコンテナ型を選ぶケースが多い。

ストレージリソース

ストレージのアーキテクチャが問われる際には、まずインスタンスに紐づいたブロックストレージであるかどうかを考える。

この場合はEBSが基本となる。

これに対して、リソースをオブジェクト(ファイル)単位で扱えれば良い場合は、オブジェクトストレージであるS3が最適になる。

EBSとS3の比較では、スケーラビリティやコスト、耐久性の面でS3の方が優位になる。

そのため、アーキテクチャ設計においてS3を利用できるのであれば、S3を優先する。

S3とEBSの違いはオブジェクトストレージかブロックストレージかが前提になっていることが多いため、そこをどのようにS3に変更するかが設計のポイント。

データベースリソース

DBの選択については、RDBMSかNoSQLかの選択が第一。

次に大容量のデータ処理の場合は、DWHであるRedshiftが考えられる。

RDBMSとNoSQLは、特性の違いがあるだけで優劣は存在しない。

そのため、RDBMSが得意とするもの、NoSQLが得意とするものを、それぞれ把握しておく必要がある。

RDBMSは汎用的に使いやすいため、まずはNoSQLの特性を押さえると良い。

しかし一口にNoSQLと言っても、ドキュメント指向、列指向、KVSなど様々なタイプがある。

AWSでは、大量データ処理の場合は列指向のDWHであるRedshift、KVSの場合はインメモリデータベースでもあるElastiCacheを考える。

それ以外の汎用NoSQLであればDynamoDBが選択肢となる。

RDBMSの選択肢としてはRDSとAuroraの2種類がある。

Auroraは基本的にはRDSの上位互換サービスになる。

それぞれの特性の違いを把握した上で、アーキテクチャを検討するようにする。

ネットワークリソース

パフォーマンスの要素として、ネットワークは非常に重要。

一方で、AWSのサービスとしては、ネットワーク自体のパフォーマンスはAWSが管理する領域のため、ユーザー自身ですることはない。

そのため、ネットワークに関するアーキテクチャについては、インスタンスのネットワークに関する知識を問われる。

具体的には、インスタンスごとのネットワーク帯域の限界に関する問いと、EBS最適化に関する問い。

まず、EC2インスタンスには、インスタンスごとにネットワーク帯域の限界が定められている。

CPUやメモリに余裕があるのにパフォーマンスが出ない場合は、インスタンスのネットワーク帯域の限界に達している可能性がある。

帯域の上限を上げるには、より帯域が広いインスタンスタイプに変更する。

またインスタンスからEBSへのアクセスは、ネットワーク経由となる。

ネットワークのボトルネックになりやすい箇所に対して、EC2ではEBS最適化インスタンスというものが設けられている。

これは、通常のネットワーク経路とは別に、EBS専用のネットワークを用意するオプション。

ネットワークのパフォーマンスを問う問題はこの2つが多いため、それぞれ把握しておく。

リソースの確認とモニタリング

システムを構築した後も、継続的な確認とモニタリングが必要。

AWSのサービスは常に進化しているため、構築時点のサービスでは実現できなかったものも新たなサービスで実現できる場合がある。

このため、最適なリソースを使っているか、継続的な確認が必要となる。

また、システムが一定の閾値の中で利用されているかをモニタリングすることも重要。

そして、閾値を超えた場合には適切な対処が必要になる。

モニタリングにはCloudWatchを利用し、自動対処にはSQSやLambdaを利用する。

トレードオフの判断

トレードオフの判断とは、どこで処理するかの決定。

具体的には、キャッシュの活用。

代表的なキャッシュの使い方としては、DBのキャッシュとコンテンツのキャッシュがある。

DBのキャッシュにはElastiCacheを利用するのが一般的。

コンテンツのキャッシュにはCloudFrontを利用する。

★パフォーマンスに優れたアーキテクチャは、リソースを適切に選択し、それを継続的にモニタリングし、キャッシュを活用することで実現できる

セキュアなアプリケーションおよびアーキテクチャ

AWSのアーキテクチャの中でも、セキュリティは非常に重要な要素となる。

AWSにおけるセキュリティには、主に2つの観点がある。

AWS利用に関するセキュリティと、構築したシステムのセキュリティ。

AWS利用に関するセキュリティ

AWS利用に関するセキュリティの大前提は、AWSマネジメントコンソールやAPIへのアクセス制限。

AWSへのアクセスにはIAMを利用する。

このIAMへの権限付与がポイントとなる。

原則としては次の3点。

・利用者ごとのIAMユーザー作成

・最小権限の原則

・AWSリソースからのアクセスにはIAMロールを使う

まず利用者ごとのIAMユーザー作成。

AWSには、アカウント作成時に作られたAWSルートアカウントがある。

AWSルートアカウントは、利用者の追跡やアクセス制限が難しいため、原則としては通常の運用には使わない。

ユーザーごとにIAMユーザーを発行し、パスワードポリシーの設定や多要素認証(MFA)を設定する。

ユーザー本人にしか利用できないようにすることで、誰がリソースを操作したのかも追跡できるようになる。

操作の追跡にはCloudTrailを利用し、設定履歴の確認にはAWS Configを利用する。

次に最小権限の原則。

IAMユーザーやIAMロールには、必要な操作権限を最小限にすることが重要。

例えば通常の開発者にはネットワークの操作権限は不要で、運用者にはインスタンスの起動停止のみで十分な場合が多い。

業務で必要な権限以外を与えないことで、万が一アクセス権を奪われた場合でも、被害を最小限に抑えられる。

さらに、IAMロールの活用も有効。

ロールは、AWSリソースなど、サービスに対して付与できる。

例えば、EC2インスタンスにロール(インスタンスプロファイル)を付与することにより、そのインスタンスのプログラムからAWSを操作できるようになる。

プログラムにIAMユーザーのアクセスキー・シークレットアクセスキーを付与すると、キー流出の危険性はどうしても高くなる。

できる限りロールを使うようにする。

また、異なるAWSアカウント間でのサービス利用として、クロスアカウントロールの利用もある。

構築したシステムのセキュリティ

システムのセキュリティについては、オンプレミスと同じ部分も少なくない。

1つは、レイヤーごとの制御。

これは、レイヤーごとに最善の防御策を講じること。

ネットワークレイヤーで防御しているのでインスタンスやOSでは防御しない、というのではなく、それぞれのレイヤーに防御施策を講じることが重要。

当然のことながら、レイヤーが異なればベストプラクティスも異なる。

そのため、前提となる知識は非常に広い範囲に及ぶ。

ネットワークレイヤーの保護ではVPCが前提となり、セキュリティグループやネットワークACLをどのように活用するかがポイントとなる。

あるいは、S3などのAWSリソースにインターネットを経由しないでアクセスするためのVPCエンドポイント/プライベートリンクをどのように利用するかも重要。

また、インスタンスを直接インターネットに接続しないようにするため方策として、ELBやNATゲートウェイの使い方を問われることもある。

もう1つはデータの保護。

これについては、バックアップやバージョニングの他に暗号化がある。

バックアップについては、EBSやS3上のデータをどのようにバックアップするかが問われる。

バックアップの設問に多いのが、データのライフサイクル。

S3のライフサイクル機能を使えば、一定期間が過ぎたら低頻度アクセスにする、もしくはS3 Glacierに移行する、そして不要になったら削除するといったことが可能になる。

また、オペレーションの失敗からデータを保護するには、S3のバージョニングが有効。

データの保護については、暗号化の観点もある。

データの暗号化には、EBSやS3の暗号化機能を使う場合と、KMSを使う場合がある。

両者の違いは、暗号化の鍵の管理の主体。

ユーザーが主体的に管理する場合はKMSを利用する。

コスト最適化アーキテクチャ

コスト度外視で堅牢なシステムを作ったとしても、ビジネス上の目的を達成することは困難。

そのため、コストの最適化もアーキテクチャ設計の上で重要な要素。

AWSをはじめとするクラウドは、大規模な設備投資やネットワーク設備の共用など、規模の経済・スケールメリットを活かして、自前で構築・運用するよりも低価格でサービスを提供している。

そのため、さらにアーキテクチャ上の工夫によるコスト最適化を問われる。

代表的なコスト最適化策がいくつかあるため、確認。

需給の一致

コスト最適化の大前提が、需給の一致。

つまりピーク時に備えて、あらかじめ大量のリソースを用意しないということ。

クラウドのアーキテクチャは、オンプレミスに比べるとこの点が大きく異なる。

現実的には、AWSといえども数秒〜数分といった短期間に急激にリソースを増加させるシステムを作るのは困難。

そのため、ある程度のリソースの余裕は持たせる必要はあるが、理想的に作れば、オンプレミスとの比較という意味では需給をほぼ一致させることができる。

この需給の一致を実現するためには、CloudWatchでリソース状況のメトリクスを計測し、EC2であればAuto Scalingでリソースの調整を行うのが基本となる。

インスタンス購入方法によるコスト削減

AWSならではのコスト削減策として、インスタンスの買い方がある。

通常使うインスタンスはオンデマンドインスタンスと呼ばれ、この費用が定価にあたる。

これに対して、1年間もしくは3年間の利用を約束することで3~7割程度の割引を受けられるのがリザーブドインスタンス。

さらに、その時間でのAWSの余剰リソースを入札性で買うのがスポットインスタンス。

常時値引きされているわけではないが、値引き幅は大きく、最大9割引くらいに達することもある。

この3つの方法を用途に応じて組み合わせて購入するのが、インスタンス購入方法によるコスト削減。

まずリザーブドインスタンスについては、常時使っていることを前提とした価格体系となっている。

そのため、事前に計画されていて確実に使うものだけに適用されるように購入するのが戦略となる。

次にスポットインスタンス。

スポットインスタンスは値引き幅が大きい反面、入札額を上回った場合は強制的に利用を中断させられるなど、制約もある。

対策としては、スポットインスタンスに適したアーキテクチャに利用するということが推奨される。

1番適合するのがEMRなどの分散処理との組み合わせ。

EMRは、フレームワークとしてジョブが中断した時に、別のインスタンスで同じジョブを実行させるようになっている。

認定試験でも、分散処理のコスト削減策としてスポットインスタンスの利用を問われることも少なくない。

また、常時起動しているマスターノードのみリザーブドインスタンスを購入する、というパターンもある。

なお、リザーブドインスタンス購入の推奨値は、Trusted Advisorのコストの項目で確認できる。

併せて覚えておく。

アーカイブストレージの活用

インスタンス利用料以外のコストで大きな割合を占めることが多いのがストレージ。

ストレージには、主にブロックストレージであるEBSとオブジェクトストレージであるS3がある。

コスト削減の余地が多いのはS3。

S3には、アクセス料は高いが保存料が安いという低頻度アクセスクラスとS3 Glacierがある。

利用頻度が低いものを、S3のライフサイクル機能を使ってS3 Glacierにアーカイブするのが定番のコスト削減策。

ただし、S3 Glacierは復元料が高く時間もかかるので、数ヶ月以上経過したログデータなど、利用する可能性が低いものに対して適用するのが一般的。

通信料

AWSでは、AWSに入ってくるインバウンドの通信は無料だが、AWSから外に出ていくアウトバウンドの通信は有料。

サービスの性質によっては、通信料がかさむケースもある。

その場合は、CloudFlontを使った通信料の最適化が必要。

CloudFlontは、通常のデータ転送料に比べて転送料を抑えることができる。

一方で、転送する地域によって転送料は変わるため、一部地域では高額となる場合がある。

カッカウクラスを選ぶことによって、転送料が高い地域ではCloudFlontを使わないという選択肢もある。

コストの把握

コストの最適化には、コスト自体を正しく把握する必要がある。

AWSでは、月次の請求以外にも、コンソールなどで現在の利用額を常時確認できる。

また、AWSから能動的に通知を得る方法として、CloudWatchとSNSの組み合わせがある。

この2つを使うことにより、月内にあらかじめ定めた以上の金額に達した場合、メールなどで通知を受けることが可能となる。

★認定試験ではアーキテクチャ上の工夫によるコスト最適化が問われる。コスト最適化は、リソースの需給を一致させる、適切なインスタンスを購入する、アーカイブストレージを活用するなどの工夫で実現できる

オペレーショナルエクセレンスを備えたアーキテクチャ

AWSは、継続的にサービスを提供することに重きを置いている。

そのため、オペレーション(運用)は非常に重要な要素。

AWSの場合でもオンプレミスと同様に、事前の運用計画や設計が重要なことは言うまでもない。

その上で、AWSのサービスを組み合わせることにより、より素晴らしい運用を実現できる。

コードによるオペレーション(Infrastructure as Code)

AWSでは、運用の負荷軽減・品質の維持のために運用の自動化を支援している。

これはInfrastructure as Code とも呼ばれ、繰り返される手順を自動化することができる。

対象として、システム構築、システム構成の管理・変更に加え、障害などのイベントへの対応も含まれる。

これを支援するサービスも多岐にわたり、構成を管理するCloudFomationを筆頭に、EC2に管理サービスとデプロイツールを付けたElastic Beanstalkや、アプリケーションのライフサイクルを支援するCodeCommit、CodeDeploy、CodePipelineなど、様々なものがある。

試験対策としては、Elastic BeanstalkやCode系サービスによるアプリケーションのデプロイ方法をしっかり押さえておくと良い。

障害時の対応

障害時の対応も運用面における非常に重要な要素。

AWSは、本番同等のシステムを簡単にコピーして再現することや、擬似的に障害をシミュレートする方法など、障害時の対応の設計・訓練がしやすい仕組みになっている。

アーキテクチャとして問われるのは、障害の検知方法と障害への対応方法。

検知方法としてはCloudWatchとSNSとの組み合わせ、対応方法としてはEC2のAuto RecoveryやAuto Scalingによる復旧を押さえる。

RDSのマルチAZの挙動も重要。

また、障害の挙動が説明され、その原因を問われることもある。

変更の品質保証

運用においてシステムの変更(リリース)は重要なイベント。

事前に十分な準備をしていたとしても、何らかの問題が発生する可能性は否めない。

その際の被害の軽減策としては、ロールバックの方策やユーザーごとの分割リリースなどがある。

試験でも比較的よく問われるため、それぞれのリリース方法を押さえておく。

まず、ロールバックしやすいリリース方法として、ブルーグリーンデプロイメントがある。

これは、稼働中のシステム(ブルー)に対し、リリース後のシステム(グリーン)を別に用意し、切り替えることでリリースする方式。

AWSの実現方法としては、Route53による宛先の変更や、ELBの向き先のインスタンスの変更、ECSのコンテナを使う方法などがある。

次にユーザーごとの分割リリースとして、ローリングデプロイメントやカナリアデプロイメントがある。

ローリングデプロイメントはリソース中の一部のリソースを、カナリアデプロイメントは最小のリソースセットを切り替える方法。

実現方法としては、Route53の加重ルーティングが一般的だが、ELBのターゲットインスタンスに混ぜ込むという方法もある。

★オンプレミスと同様、AWSでもオペレーション(運用)は重要な要素。各種サービスを利用した自動化の方法、障害への対応方法、リリースの方法などをしっかり理解しておく必要がある

まとめ

アーキテクチャ設計

・回復性の高いアーキテクチャを設計するための知識は、試験範囲の中でも大きな割合を占める

・回復性の高いアーキテクチャは5つの要素で構成される：復旧手順のテスト、障害からの自動復旧、スケーラブルなシステム、キャパシティ推測が不要であること、変更管理の自動化

・パフォーマンスにすぐれたアーキテクチャは、リソースを適切に選択し、それを継続的にモニタリングし、キャッシュを活用することで実現できる

・AWSのセキュリティには2つの観点がある。1つはAWS利用に関するセキュリティで、これにはIAMを利用する。もう1つは構築したシステムのセキュリティで、これにはセキュリティグループ、ネットワークACL、バックアップ、バージョニング、暗号化などを利用する

・認定試験ではアーキテクチャ上の工夫によるコスト最適化が問われる。コスト最適化は、リソースの需給を一致させる、適切なインスタンスを購入する、アーカイブストレージを活用するなどの工夫で実現できる

・オンプレミスと同様、AWSでもオペレーション(運用)は重要な要素。各種サービスを利用した自動化の方法、障害への対応方法、リリースの方法などをしっかり理解しておく必要がある