よくわかるクラウド
AWS
コスト削減
運用
オンプレミス

AWSクラウドアーキテクチャのベストプラクティス

１．スケールする仕組みを取り入れる
２．障害が発生することを前提として構成する
３．各レイヤーでセキュリティを確保する
４．マネージドサービスを活用する
５．最適なデータベースソリューションを選択する
６．システムの構成要素を疎結合にする
７．こまめにコストの見直しをおこなう
AWS Well-Architectedフレームワークのご紹介
最適なクラウドアーキテクチャを目指すために（まとめ）

本記事では、クラウドアーキテクチャーのベストプラクティスと題し、これだけは押さえておきたいAWSにおける7つのアーキテクチャ設計ポイントについて紹介します。また、最後にまとめとして、効果的なクラウドアーキテクチャの設計・運用のためのベストプラクティスがまとめられたAWS Well-Architectedフレームワークについても紹介していきます。

１．スケールする仕組みを取り入れる

それでは最初のベストプラクティス「スケールする仕組みを取り入れる」から見ていきます。

スケールを取り入れるメリット

AWSにおけるスケールする仕組みとは、ビジネスのニーズ・需要に合わせてコンピューティングリソースを拡大、縮小する仕組みです。例えば、ユーザーからのアクセスが増えて、サーバーの負荷が高くなった場合はサーバーリソースを増やし、逆にアクセスが減って負荷が落ちついた場合は、サーバーリソースを減少させるなど、柔軟にリソースの増減がおこなえます。

リソース不足による機会損失を防ぐ

以下グラフは、とあるシステムに対するエンドユーザーからのリクエスト数と時間経過を表しています。リクエストは常に一定ではなく多くなったり、少なくなったりを繰り返しています。グラフの右側はリクエストのスパイクが発生しており、プロビジョニングしたキャパシティを超えた状態になっています。

プロビジョニングされたキャパシティを超える膨大なリクエストが発生するとリソース不足が発生し、リクエストが処理できない状態になるため、機会損失が発生します。

そこで、データセンターなど従来のオンプレミス環境の場合、見込まれるリクエストの量を想定して、あらかじめ余裕を持ってキャパシティを確保できるようハードウェアリソースを購入する必要があります。しかし、以下グラフ右側のスパイクの最大負荷に合わせて、ハードウェアを購入した場合、ほとんどのリソースは使われない状態となり、結果として無駄が発生し、過剰な投資となってしまいます。

クラウドではプロビジョニングされたキャパシティを柔軟にAuto Scaling

一方、クラウドであればサーバーリソースを実際のリクエスト数に合わせて柔軟に拡大縮小することができます。AWSでは AWS Auto Scaling と呼ばれるサービスが提供されており、リクエストの需要に合わせて自動でサーバーリソースの増減をおこなうことができます。

AWSでスケールを実装するためのAmazon EC2 AutoScaling

AWSで提供されるサービスにはAutoScaling機能を実装できるものがいくつかありますが、ここでは Amazon EC2 の仮想サーバーに関するAutoScaling機能についてご紹介します。

Amazon EC2 AutoScaling とは事前に定義した条件に応じて、Amazon EC2 インスタンスを自動的に追加または削除できる機能であり、通常ロードバランサーと組み合わせて利用します。Auto Scaling には以下のような方法があります。

1.スケジュールに基づくスケーリング

既知の負荷変動に先だって、事前に日時を指定しておくスケジュールに基づくスケーリング

2.動的スケーリング

あらかじめCPU使用率やリクエスト数に関して閾値を設定し、閾値を基準にスケーリング

3.予測スケーリング

機械学習を使ってトラフィックの変動発生を予測して、適正な数のインスタンスをスケーリング

Amazon EC2 Auto Scaling 利用時のポイント

Amazon EC2 AutoScaling を利用する際のポイントとして、Auto Scaling 内の特定のインスタンスをスケールできないような固有の設定を実施しないといったものがあります。例えば、Auto Scaling が設定された一部の Amazon EC2インスタンスのみ使い勝手を良くするためにパッケージを導入したり、独自の設定を入れてカスタマイズしたとします。

しかし、Auto Scaling が設定されていますので、リクエストの需要が減ったタイミングでインスタンスが自動的に削除される可能性があります。特定のインスタンスが削除されないように設定することもできますが、柔軟にスケーリングできるというクラウドの特性を生かすためにも、インスタンスは入れ替えや破棄を容易にするため、機能を均一にすることが推奨されています。

２．障害が発生することを前提として構成する

Amazon.comのCTO（最高技術責任者）である Werner Vogels の言葉に ”Everything fails, all the time (全ての物はいつか必ず壊れる)” があります。

クラウドといえども、実際には物理的なサーバー上で稼働しているため、ハードウェア機器の故障や災害による障害は発生するものであり、その前提で耐障害性の高いシステムを構築する必要があるというメッセージになります。

単一障害点とは？

耐障害性が高いシステムを構築するポイントとして単一障害点を排除する方法が挙げられます。単一障害点とは、システムを構成する要素のうちの一カ所が停止することで、システム全体に影響が及ぶ箇所のことを指します。

単一障害点を排除する

例えば、以下図の通信の入り口となる Route53 は AWS の DNSサービスであり、名前解決したアクセスがロードバランサーを経由してweb/appサーバーに到達し、さらに単一のデータベースと通信をします。

web/app サーバーは二台で冗長化されていますが、その先のデータベースが単一になりますので、仮にデータベースに障害が発生した場合はweb/app サーバー側にも影響が及びサービス提供ができない状態になります。さらにもう一つ問題は、システム全体がシングルアベイラビリティゾーンで構成されているという点です。

アベイラビリティゾーンとは

まず、アベイラビリティゾーンという用語についてですが、アベイラビリティゾーンは複数データセンターからなるデータセンター群のことを指します。また、一つのリージョン（地域）の中に複数のアベイラビリティゾーンがあり、以下、日本の東京リージョンの例では、三つのアベイラビリティゾーンが利用できます。

AWSでは、データセンターの障害に備えて複数のアベイラビリティゾーンにまたがったシステムを構築することを推奨しており、このような構成をマルチAZと呼びます。
AWSの監視・運用作業代行

シングルアベイラビリティゾーン（シングルAZ）構成での問題点

以下図のように、システム全体が一つのアベイラビリティゾーン（シングルAZ）で構成されていると、アベイラビリティゾーン単位での障害が発生した場合にシステム全体のダウンが免れない状態になります。

単一障害点を排除するベストプラクティスの構成

以下の図は、ベストプラクティスの構成です。ロードバランサーを経由したアクセスはアベイラビリティゾーンをまたいで冗長化されており、かつ Auto Scaling によって管理されている web/app サーバーに到達します。

データベースは、AWS が提供する Amazon RDS というデータベースサービスを利用しており、プライマリーとセカンダリー（スタンバイ）がそれぞれ別のアベイラビリティゾーンに設置されています。プライマリーからセカンダリーには常にデータの同期が行なわれており、プライマリーに障害が発生した場合には、自動的にセカンダリーへのフェイルオーバーが実施されます。

データベース障害発生時の切り替え

Amazon RDS ではデータベースインスタンスの接続に DNS形式の接続情報を使用しており、フェイルオーバーが発生した場合には、自動的にこの接続情報をスタンバイ側に切り替えます。そのため、web/app サーバーは自動的にフェイルオーバーと接続先の切り替えがおこなわれます。

関連記事：AWSのAmazon RDSとは？サービスの特徴や料金について解説

３．各レイヤーでセキュリティを確保する

3つ目のベストプラクティスとして「各レイヤーでセキュリティを確保する」について見て行きます。

責任共有モデルについて

まずは、クラウドにおけるセキュリティの考え方となる「責任共有モデル」について簡単に解説します。以下図のオレンジ色の部分はクラウド事業者が責任を持ちセキュリティを担保する範囲になります。一方、水色の部分はクラウドを利用するユーザー側でセキュリティ対策を施し守っていく範囲です。

二つのレイヤーについて、クラウド事業者とユーザーがそれぞれ担当する範囲において必要なセキュリティ対策をおこなっていくことで、サービス全体のセキュリティを担保する考え方を「責任共有モデル」と呼びます。

ユーザーの責任範囲

今回は、ユーザーの責任範囲について詳しく見て行きます。

ユーザーは、以下クラウド「内」のセキュリティに対する責任があります。
・アカウント管理
・ファイアウォール
・脆弱性対策
・データ暗号化

では、ユーザーはどのようにこれらの責任を果たしていけばよいのか、確認していきましょう。

AWSが提供するセキュリティサービス

AWSにはセキュリティに関する様々なサービスが提供されており、ユーザーはこれらを組み合わせて実装し、ユーザーの責任範囲に対して、対策を実施することができます。各レイヤーでセキュリティを確保するという観点から実装例を見て行きたいと思います。

AWS Identity and Access Management (IAM)：アカウント管理

AWS Identity and Access Management 通称 IAM は AWS のサービスとリソースに対する認証・認可をおこなうサービスで、AWS にアクセスする際の認証と認可をつかさどる機能になります。

例えば、マネジメントコンソール（AWSの管理画面）にログインする際のパスワードの設定や、AWSリソースやユーザーに対するアクセス制御などAWSを使う上で必ず利用する重要なサービスです。ユーザに対する多要素認証(MFA)や、プログラムからのアクセス時にも使用します。

AWS WAF(Web Application Firewall)：ファイアウォール

Web Application Firewall(WAF) はウェブアプリケーションに対する攻撃から保護するファイアウォール機能であり、AWS が提供するサービスになります。

SQLインジェクションやクロスサイトスクリプティングといった一般的なウェブ攻撃に対する保護ルールが提供されています。また、ユーザーが独自に定義したIPアドレス制限、同一IPアドレスからの接続数の制限などの設定も可能です。Amazon CloudFront、Application Load Balancer、Amazon API Gateway に設定可能です。

セキュリティグループ：ファイアウォール

AWSには、ネットワークのファイアウォールとして「セキュリティグループ」という機能があり、AWSリソースへのトラフィックを制御する仮想ファイアウォールの役目を果たします。

デフォルトでは全てのトラフィックが許可されておらず、ホワイトリスト方式で許可設定をおこないます。具体的には、プロトコル、ポート範囲、アクセス元のIPアドレスや紐づけられているセキュリティグループの名前を指定して許可設定をおこなっていきます。

Amazon Inspector：脆弱性対策

脆弱性対策には、Amazon Inspector が用意されており、Amazon EC2 インスタンスと Amazon ECR(コンテナレジストリ)に保管されたコンテナイメージに対して自動で脆弱性を検証・管理することができます。

Amazon EC2インスタンスやコンテナイメージに含まれているソフトウェアの脆弱性とネットワークのセキュリティリスクを継続的にスキャンしてくれます。他のAWSサービスと連携して、脆弱性検出時にアラートを通知できますので、リスクを放置することなくすぐに対策をすすめられます。

AWS Key Management Service(AWS KMS)：データ暗号化

データの暗号化には、AWS Key Management Service 通称 AWS KMS が用意されており、暗号化に使う鍵の作成と管理をおこなうサービスとなります。

AWS上のサービスでの暗号化のほとんどの場合に、AWS KMS が利用されます。AWS KMS の操作履歴はすべて AWS CloudTrail というログサービスに記録されますので、コンプライアンス要件にも対応できます。
AWS上のセキュリティ対策・ガバナンス強化　マネージドセキュリティ

４．マネージドサービスを活用する

続いて、「マネージドサービスを活用する」について見ていきます。AWS におけるマネージドサービスとは、インフラの運用・管理や耐障害性、高可用性、セキュリティの担保を AWS 側でおこない、ユーザーはそのテクノロジーをサービスとして利用できるものという位置づけになります。

例えば、Amazon RDS は、インフラの管理・運用やソフトウェアの保守をユーザー側でおこなう必要がなく、クラウド内でデータベースのセットアップ、運用、およびスケールを簡単におこなうことのできるマネージド型サービスになります。ほかにも、オンプレミスではユーザーが行っていた運用・管理を AWS 側でおこなうマネージドサービスが多数用意されています。

マネージドサービスのメリット

オンプレミスでデータベースを運用する場合と、AWS のマネージドサービスである AmazonRDS を比較してみたいと思います。

上記図は、左からオンプレミス上でデータベースを構築する場合、Amazon EC2 上にデータベースを構築した場合、データベースのマネージドサービスである Amazon RDS を利用した場合の表であり、それぞれユーザーと AWS が管理する範囲について示したものとなります。

オンプレミスの場合はデータセンターのファシリティ（施設、設備）の部分から全ての工程について対応が必要となります。そして、Amazon EC2でデータベースを運用すると物理的な部分に関して AWS に運用を任せることができますが、OS のパッチ当てからはユーザー側で対応が必要となります。

右側の Amazon RDS は、マネージドサービスとして提供されていますので、ユーザー側で担当する工程は一番上の、アプリケーションの最適化のみとなり、ユーザーはより付加価値の高い活動に専念することができるようになります。

マネージドサービスをさらに活用する

Amazon EC2 インスタンスのようなコンピューティングリソースも、マネージドサービスが展開されています。以下の図では、上部のサービスになるほどAWSが管理する範囲が広くなりますので、ユーザーはリソース上で動くアプリケーションのみの開発に専念できる環境となります。

Amazon Web Servicesブログ：「【開催報告】そろそろマネージド、クラウドネイティブで行こう!サーバーレスへのチャレンジ」
セミナー「オープニング & サーバーレス概要」資料より引用

例えば、これまでのウェブサーバー上での処理をAPIでおこなえる場合は、Amazon API Gateway や受け付けた API リクエストを処理するために AWS Lambda というマネージドサービスを取り入れていく方法もあります。従来、AmazonEC2などでおこなっていた処理をサーバーレスのマネージドサービスを取り入れることができれば、サーバーリソースの維持やメンテナンスなど管理、運用のコストをさらに減らすことができます。

ここで紹介されているのは、一例であり、必ずしもサーバーレスを当てはめるのではなく、適材適所でサーバーレスのサービスを取り入れられないかを考えていくことが大切になっていきます。

５．最適なデータベースソリューションを選択する

続いて５つ目のベストプラクティスとして「最適なデータベースソリューションを選択する」について解説します。AWSでは “Purpose-built Databases” という扱うデータの特性、目的に合わせて、最適なデータベースを選択していく考え方を提唱しています。

AWSが提供するデータベースサービス

AWSには以下図にあるようにさまざまなデータベースサービスが用意されています。

例えば、複雑なクエリやトランザクションが発生するのであれば、リレーショナルデータベースサービスである Amazon RDS や Amazon Aurora を利用し、また、高いスループットやスケーラビリティが要求されるのであれば、NoSQL である Amazon DynamoDB を選択するなど、必要な処理と、求められる要件に合わせて適切なデータベースサービスを検討していくことが大切になります。

６．システムの構成要素を疎結合にする

ベストプラクティスの6つ目として「システムの構成要素を疎結合にする」について見ていきます。

疎結合・密結合とは

疎結合とはシステムを構成する要素（コンポーネント）同士の結びつきや依存関係が弱く、仮に1つのコンポーネントで障害や変更が発生しても、他のコンポーネントには影響を及ぼさず、引き続き機能する状態の事をいいます。

密結合とはその逆の状態で、1つのコンポーネントで障害が発生すると、他のコンポーネントでも障害が発生し、場合によってはアプリケーション全体が停止してしまうような状態を指します。

疎結合なアーキテクチャ

以下図は、疎結合なアーキテクチャーの一例になります。Webサーバーとアプリケーションサーバーのつなぎ目に、ロードバランサーを配置し、仮にアプリケーションサーバーに障害が発生した場合に、ロードバランサーが異常を検知して、障害が発生したサーバーにトラフィックを流さないよう自動的に制御します。こうすることで、システム全体としては処理を継続できますので、一つのコンポーネントに障害が発生した場合もサービス全体に影響を及ぼさない構成となります。

App serverに障害が発生した場合

また、サービスへの需要が増してサーバーを増設したい場合に、従来のアプリケーションサーバーのマシンイメージから新たにサーバーを起動し、ロードバランサーの振り分け対象に登録するだけで柔軟にスケーリングがおこなえるのも、疎結合な構成のメリットとなります。

App serverを拡張（スケーリング）する場合

疎結合化に利用できるAWSサービス例：Amazon SQS

その他、疎結合化に利用できるAWSのサービスとしてフルマネージド型のメッセージキューイングサービスとなるAmazon SQSをご紹介します。例えばアップロードした動画をサイズ変換して、処理結果をユーザーにメール通知する処理を考えた場合、以下のように処理と処理のつなぎ目にAmazon SQSを利用する方法も考えることができます。

７．こまめにコストの見直しをおこなう

最後に7つ目のベストプラクティス「こまめにコストの見直しをおこなう」についてご紹介します。

AWS Trusted Advisor

クラウドの特徴として、リソース増減などのスペック変更が容易にできます。定期的にリソース利用状況の棚卸しをして、必要以上のスペックを使っているインスタンスがないか、また、検証などで一時的に作成したインスタンスをそのままにしていないかなどを確認して、コストが無駄にかかるのを防ぐ必要があります。

そこで、リソース利用状況のモニタリングをするAWSサービスとして、AWS Trusted Advisor が提供されていますのでご紹介します。AWS Trusted Advisorのコスト最適化レコメンド機能は、AWSのマネジメントコンソールから使用頻度の低いリソース一覧を確認できます。レコメンドに沿って無駄をなくした場合にどれぐらい節約できるのかなどの予測も表示されます。

AWS Trusted Advisorの一部の機能は、標準で付帯する無料のAWSのサポートプラン「ベーシック」で利用できますが、ご紹介するAWS Trusted Advisorのコスト最適化レコメンド機能は、有料の「ビジネス」もしくは「エンタープライズ」の場合のみに利用できる機能となりますのでご注意ください。

請求代行リセールサービス

コストを削減する方法として、AWSパートナーが提供する請求代行サービスを利用する方法があります。NHNテコラスでも手数料は無料でAWS 利用料金が 8%割引 になる 請求代行のAWSリセールサービス を取り扱っており、簡単にコストを削減することが可能です。

また、エンタープライズ相当の技術サポートが無料で付きますので、AWS Trusted Advisorのコスト最適化レコメンド機能を利用できます。すでに、AWSを利用中の方もアカウントの移管だけで、8%割引となりますので、是非、NHNテコラスの請求代行サービスの利用をご検討ください。

AWS Well-Architectedフレームワークのご紹介

最後に「AWS Well-Architectedフレームワーク」についてご紹介いたします。

こちらは、AWSとAWSを利用するユーザーが長年の経験の中で培ってきたクラウドにおけるベストプラクティスを集めたものとなります。以下図の６つのカテゴリーから構成されており、それぞれに具体的な行動指針や、設計原則が定義されています。AWS上に構築したシステムでワークロードがどの程度ベストプラクティスに則っているのかを AWS Well-Architected フレームワークと照らし合わせることで確認できます。

NHNテコラスでは、AWS Well-Architectedフレームワークに基づいたワークロードの診断サービス Well-Architected レビュー を提供しております。診断には公式のフレームワークに加えて、当社独自の自動ツールを利用しております。本番サービス開始前の確認、運用中のシステムに対するリスクや改善項目の洗い出しの目的にも有用な診断となりますので、詳細は気軽に当社までお問い合わせください。

最適なクラウドアーキテクチャを目指すために（まとめ）

クラウドにおけるアーキテクチャーのベストプラクティスとして以下7つについてご紹介しました。

・Auto Scalingでスケールする仕組みを取り入れる
・障害が発生することを前提としてマルチAZで構成する
・AWSのセキュリティサービスを活用して、各レイヤーでセキュリティを確保する
・マネージドサービスを取り入れる
・データの特性に合わせてデータベースを選択する
・システムの構成要素を疎結合にする
・定期的にコストの見直しをおこなう

最後に、まとめとしてAWS Well-Architectedフレームワークをご紹介しました。

今回は基本的なベストプラクティスをご紹介しましたが、最適なアーキテクチャはシステム運用をすすめていくと変化していくものです。AWS Well-Architectedフレームワークを含め、数あるベストプラクティスを踏まえた上で、自社のワークロードに適したあり方を検討して行く必要があります。

当社のプロフェッショナルサービスでは、AWS Well-Architectedフレームワークや過去の実績からのナレッジを踏まえた上で、お客様のワークロードに最適なアーキテクチャをご提案いたします。AWS環境の構築や運用に関してのお困りごとがございましたらお気軽にご相談ください。