2018-12-21

設計サンプルで学ぶ、AWS構築の原則 - Webアプリアーキテクチャのベストプラクティスを理解する

AWS入門者に向け、同サービスのエキスパートである、クラスメソッドの八幡豊さんが、Webアプリケーション開発のためのAWS構築の基本を解説します。広範な領域をフォローするAWSですが、広範ゆえに、なにをどのように選ぶべきか……。こんなお悩みを持つ方はぜひご一読を。

クラウドコンピューティングサービス・Amazon Web Services（以下、AWS）は、数多くの高機能なクラウドサービスを簡単に利用できることから、多くの企業が導入しています。AWSの知識を身につけることは、いまやエンジニアにとっての必修科目です。

そのサービス範囲は広範にわたることから、「なにを」「どうやって」使うかのかが重要な知識になってきます。AWSの各サービスのポテンシャルを引き出すためには、それぞれの長所・短所を理解し、適切なアーキテクチャを構築していく必要があります。

今回は、企業向けのAWS支援コンサルティングを専門とするクラスメソッド株式会社の八幡豊さんにご登場いただき、AWSを用いてWebアプリケーションのアーキテクチャを構築する際の鉄則を解説していただきました。累計1,000社以上、4,000アカウント以上の支援実績を誇る同社の考える“ベストプラクティス”を、ぜひご覧ください。

八幡豊さん：大学卒業後、SIerに入社し、ERPシステムの運用、開発に携わる。その後、Web系技術への興味から2015年にクラスメソッド社に入社し、ソリューションアーキテクトとして、プリセールスやクライアントのコンサルティングを担当する。

【ノウハウ1】Auto ScalingやMulti-AZを活用し、耐障害性を高める
【ノウハウ2】デプロイ・構成管理は可能な限り自動化する
【ノウハウ3】AWSリソースへのアクセスや権限を管理し、セキュリティを高める
【ノウハウ4】適切な種類のインスタンスを選び、コストを最適化する
【ノウハウ5】監視ツールを使い分け、システムの状態を可視化する
実例に学ぶ、Webアーキテクチャのベストプラクティス
「正しく知ること」が良いアーキテクチャを生む

【ノウハウ1】Auto ScalingやMulti-AZを活用し、耐障害性を高める

──いくつかの観点に基づいてお話を伺わせてください。まずは「障害に強いシステム」を構築するために、どのようなツールやアーキテクチャを用いるのが有効かを教えていただけますか？

八幡　耐障害性を高めるには、需要に合わせてEC2の台数を増減できるAmazon EC2 Auto Scaling（以下、Auto Scaling）や、Amazon RDS（以下、RDS）を複数のアベイラビリティーゾーンに配置できるMulti-AZなどの機能を使うことが効果的です。

Webアプリケーションを運用するなかで、突発的に何かのアクシデントが起きてサービスを継続できない状態に陥るリスクが存在します。例えば、アクセスが急増してサーバが高負荷に耐えられなくなる、災害などで特定のデータセンターが稼働しなくなるなどです。このような事態に備えるために、Auto ScalingやMulti-AZが有効なんです。

Auto Scalingを入れておけば、監視している値が一定の閾値を超えた場合に自動的にスケールアウトしてくれるため、各サーバにかかる負荷を一定以下に抑えることができます。また、特定のアベイラビリティーゾーンで障害が発生しても、すぐに新しいインタンスを起動してサーバ台数を一定に保つことができるんです。

──Webサーバを冗長構成にしているけれど、Auto Scalingは導入していない場合もあると思います。Auto Scalingを導入する際に気をつけるべき点があれば教えてください。

八幡　「Auto Scalingを活用することを前提に、運用フローを整備していく必要がある」という点には注意が必要です。Auto Scalingでは、スケールアウトのときに新しいインスタンスが立ち上がります。この際に「新インスタンスにどのような手段で最新のモジュールを反映させるか」を考えておく必要があります。

例えば、最新のモジュールがデプロイされたマシンイメージを常に用意しておき、それをメンテナンスしていく、あるいは新インスタンス起動時に最新のアプリケーションをデプロイするなどの仕組みを運用に組みこむ必要があります。

また、Auto Scalingではスケールイン時にインスタンスが消えてしまうので、ログファイルのようにアーカイブしておくべきファイルをなんらかの手段で保存しておく必要があります。例えば、Fluentdを使ってログを集約する、ログ収集ツールを使ってAmazon S3（以下、S3）に置くなどが有効です。これらの運用コストがかかることを念頭に置き、Auto Scalingを導入する・しないを検討してみてください。

──もう一方のMulti-AZ機能はどのようなメリットがありますか？

八幡　RDSのMulti-AZ機能をオンにしておくことで、複数データセンターをまたいだ冗長構成が簡単に取れます。

Multi-AZ構成にしておくことは、メンテナンスイベントへの耐性を高める上でも役立ちます。メンテナンスイベントとは、RDSに対して基盤側のセキュリティパッチなどを自動反映させるもので、このイベントが起きると、データベースのダウンタイムが発生します。

RDSをMulti-AZ構成にしておくと、スタンバイ側からメンテナンスが行われ、その後にフェイルオーバーが起こります。つまり、ダウンタイムをフェイルオーバーの期間だけに留められるんです。そういった面でも、Multi-AZ構成にしておくことはメリットが大きいですね。

【ノウハウ2】デプロイ・構成管理は可能な限り自動化する

──アプリケーションのリリースプロセスにおいて、導入した方がいいツールやアーキテクチャはありますか？

八幡　最近、「CI/CDパイプラインを作りたい」というニーズをうかがうことが多いのですが、AWSにはそれを実現できるツールも用意されています。AWS CodeCommit（以下、CodeCommit）、AWS CodeBuild（以下、CodeBuild）やAWS CodeDeploy（以下、CodeDeploy）、AWS CodePipeline（以下、CodePipeline）などの、いわゆる「Codeシリーズ」と呼ばれるサービス群です。

CodeCommitはGitリポジトリのホスティングサービスです。SaaSでいえば、GitHubやGitLabなどに相当するものになります。そこにcommitされたモジュールをビルド&テストをするためのサービスがCodeBuild、ビルドした成果物をEC2などにデプロイするのがCodeDeployで、これらは連携可能になっています。連携のコントローラーとして利用するのがCodePipelineです。

これらのサービスを組み合わせることで、簡単かつ低コストでCI/CDパイプラインを作成でき、アプリケーションのデプロイを自動化できます。

──デプロイ作業を最適化したいというニーズは、なぜ増えているのでしょうか？

八幡　アプリケーションのリリースサイクルが早くなっているからだと思います。常に改善を続けてユーザーニーズを取りこむことが、サービスのバリューに直結する時代になっています。こうした背景から、改善のスピードを上げるために、リリース作業の自動化・効率化が必須になってくるんです。

また、環境構築系の作業を効率化したいというニーズも増えています。その場合には、AWS CloudFormationを使うのがおすすめです。これはAWSの構成をコード化して管理できるもので、いわゆるInfrastructure as Codeを実現するためのサービスです。過去に構築したことのある環境と同等の環境を、すぐに構築することが可能になります。

【ノウハウ3】AWSリソースへのアクセスや権限を管理し、セキュリティを高める

──セキュリティを高めるために、有効な手段はありますか？

八幡　AWSにおいてセキュリティを高めるには、まずAWS Identity and Access Management（以下、IAM）を使ってリソースへのアクセスを管理するのが大前提になります。といっても、難しいことはありません。原則として、「IAMのロールによって最低限の権限だけを付与する」というルールを守るだけです。IAMロールを利用することで、永続キーではなく有効期限付きの一時キーを用いてアクセスできます。

AWSは近年、セキュリティに関するサービスをかなり充実させています。WebアプリケーションファイアウォールのAWS WAF、APIの呼び出し記録とログファイル送信ができるAWS CloudTrail、AWSの構成変更を記録・通知してくれるAWS Config、APIの操作ログやVPCの通信ログをモニタリングして不正な動きがないかを検知してくれるAmazon GuardDutyなど、数多くのサービスがあります。

それから、当社がリリースしているインサイトウォッチというサービスも、セキュリティを高めるには有効です。これはAWSの各種設定がCISのベンチマークやIAMのベストプラクティスに沿っているかを、網羅的に自動チェックできるツールです。

全項目を人間の目でチェックするのは非常に手間ですし、漏れも発生します。ツールによる自動チェックを行えば、運用の負担がかなり軽減できます。

【ノウハウ4】適切な種類のインスタンスを選び、コストを最適化する

──金銭的なコストを下げるには、何をすべきでしょうか？

八幡　Webアプリケーションの場合、発生する費用の多くはEC2インスタンスのコストでしょう。費用を下げるために、リザーブドインスタンスを使うことをおすすめします。リザーブドインスタンスとは、1年または3年の単位で年契約を結ぶことで、利用料をディスカウントできるものです。OSやインスタンスタイプによって割引率が異なりますが、平均で40%程度、最大で75％の割引が可能になります。

──75％！相当に安くなりますね。

八幡　EC2の他に、RDSやAmazon ElastiCache、Amazon DynamoDBなどもリザーブドインスタンスあるいはリザーブドキャパシティの利用が可能です。

他にもスポットインスタンスという種類もあり、上手に使うことでコストを削減できます。これは、AWSの余剰インスタンスを入札制で購入することで、通常のオンデマンドインスタンスよりも安価に利用できるというものです。

──リザーブドインスタンスもスポットインスタンスも、とても便利に思えます。それぞれにデメリットはありますか？

八幡　リザーブドインスタンスはStandard RIというプランの場合、インスタンスタイプを途中で変更できないんです。購入してしばらく経ってから「もっと性能が良いインスタンスタイプにしたい」と思っても、変更がききません。Standard RIよりもディスカウント率が低くなってしまいますが、Convertible RIというインスタンス変更可能なプランもあります。

一方、スポットインスタンスは、入札制のため「市場価格が自分の入札価格を上回ると、インスタンス利用権がなくなってしまう」というリスクがあります。常に稼働させ続けるサーバには向きません。検証用サーバとして使うとか、Auto Scalingでオンデマンドインスタンスと組み合わせて高負荷時だけ動かすサーバにするなどの工夫が必要になってきます。

【ノウハウ5】監視ツールを使い分け、システムの状態を可視化する

──システムを安定稼働させるには、状態を監視することも必要です。良いツールはありますか？

八幡　AWS標準の監視ツールとして、Amazon CloudWatchが利用できます。 AWSの各リソース状況を監視できるので、ファーストステップとして導入してみてください。

ただし、Amazon CloudWatchはOSのイベントやミドルウェアのプロセスなどの監視ができません。それらの情報をモニタリングする場合は、サードパーティー製品を導入する方が良いです。たとえば、MackerelやDatadog、New Relicなどです。

Mackerelはシンプルで使いやすい監視ツールで、どんな企業であっても導入しやすいと思います。AWSとのインテグレーション機能もどんどん追加されているので、「AWSと組み合わせる」という意味合いでは非常に相性の良いツールです。

Datadogは多機能な監視ツールで、AWS以外のクラウドサービスとのインテグレーション機能が強い印象があります。New Relicはアプリケーションの処理性能やインフラのリソース状況などを計測できます。それぞれに特徴があるので、自社サービスの要件に合ったものを使ってみてください。

実例に学ぶ、Webアーキテクチャのベストプラクティス

八幡　大事にしていただきたいポイントをいくつか解説したので、ここからは前述のようなポイントを守った場合の「Webアプリケーションのアーキテクチャ例」を図とともに紹介していきたいと思います。

サービスをいくつかのフェーズに分け、「リリースしたばかりでユーザーが少ない状態から、サービスの規模が大きくなるにつれてアーキテクチャをどう成長させていくか」というテーマで図表を作ってきました。

フェーズ1. 初期構成

＜使用サービス＞

AWS：Amazon EC2、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager

これが最初期のアーキテクチャになります。Webアプリケーションを構築するにあたり、最低限必要なものだけをピックアップしている状態です。WebサーバとしてEC2インスタンスを立て、データベースはRDSを利用します。できれば、AWSオリジナルのRDBMSであるAmazon Aurora（以下、Aurora）を導入してください。

──MySQLやPostgreSQLよりもAmazon Auroraを推奨されるのはなぜですか？

八幡　パフォーマンスに優れるというメリットの他、高速なフェイルオーバーやストレージの自動拡張など運用面のメリットもあります。AWSサービスとのインテグレーションも魅力です。例えばAurora MySQLにはネイティブ関数やストアドプロシージャからAWS Lambdaをキックする機能やS3に直接データをインポート&エクスポートする機能があります。

この図ではコスト重視のためシングルインスタンス構成になっていますが、できればこの段階でロードバランサーを入れていただくことを推奨します。Webサーバを直接インターネットに晒さないで済む、無料のSSL証明書を使える、SSL処理をオフロードできるなどのメリットがあるからです。DNSについては、AWSのマネージドサービスであるAmazon Route 53を使ってください。

また、AWS ConfigやAWS CloudTrail、Amazon GuardDutyは比較的低コストで利用できるので、セキュリティ対策の一環として早いタイミングでの導入をおすすめします。

フェーズ2. CDN利用

＜使用サービス＞

AWS：Amazon EC2、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager、Amazon S3、Amazon CloudFront、AWS WAF

──次のフェーズでは、アーキテクチャのどのような点が変わりますか？

八幡　CDNサービスであるAmazon CloudFront（以下、CloudFront）を導入しています。画像やCSS、JSファイルなどの静的アセットをS3に保存し、CloudFrontを経由してアクセスさせることでキャッシュを活用します。そうすることで、Webサーバの負荷を下げつつ、サイト全体の高速化も期待できます。

この仕組みは、できれば初期のうちに導入していただく方が良いです。CloudFrontを入れることで、AWS WAFの機能を利用しやすくなるためセキュリティも堅牢になります。

フェーズ3. 冗長構成

＜使用サービス＞

AWS：Amazon EC2、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager、Amazon S3、Amazon CloudFront、AWS WAF

八幡　次に、耐障害性とパフォーマンスを高めるため、ロードバランサーの後段に2台のWebサーバを配置してRDSはMulti-AZ構成にしています。サービスが停止しにくくなり、満たせる要件も増えてきますが、自動復旧という点ではまだ課題が残ります。そこで次のフェーズでは、先ほどお話ししたAuto Scalingを組みこんでいきます。

フェーズ4. Auto Scaling

＜使用サービス＞

AWS：Amazon EC2 Auto Scaling、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager、Amazon S3、Amazon CloudFront、AWS WAF、Amazon ElastiCache

ミドルウェア：Fluentd

八幡　Auto Scalingを入れたことで、急激なアクセス増加や障害などに強くなります。また、AuroraはRead Replicaによる負荷分散が可能なので、参照系の機能だけRead Replica側を読ませる対応をアプリ側で行うことで、スケールアウトが可能になるんです。

このアーキテクチャでは、各Webサーバのログ集約のためにFluentdを導入しています。セッション管理が必要であれば、Amazon ElastiCacheを導入するのが良いと思います。ここまでできれば、相当数の要件を満たせるはずです。

フェーズ5. デプロイ自動化 & コンテナ化

＜使用サービス＞

AWS：Amazon EC2 Auto Scaling、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager、Amazon S3、Amazon CloudFront、AWS WAF、Amazon ElastiCache、Amazon CodeCommit、AWS CodeBuild、AWS CodeDeploy、AWS CodePipeline、 Amazon Athena、Amazon QuickSight

ミドルウェア：Fluentd

＜使用サービス＞

AWS：AWS Fargate、Amazon Aurora、Elastic LoadBalancing、AWS Certificate Manager、Amazon S3、Amazon CloudFront、AWS WAF、Amazon ElastiCache、Amazon CodeCommit、AWS CodeBuild、AWS CodePipeline、Amazon EC2 Container Registry、Amazon CloudWatch Logs、Amazon Kinesis Data Firehose、Amazon Athena、Amazon QuickSight

八幡　次のフェーズではより発展させ、CodeCommitやCodeDeploy、CodeBuild、CodePipelineなどを用いてデプロイ自動化の仕組みを組みこむのも良いと思います。

さらに、最近ではDockerなどのコンテナが活用されるケースも増えています。Webアプリケーションのアーキテクチャを構築する際の選択肢として考えてみてください。

──コンテナ化にはどのようなメリットがありますか？

八幡　ハードウェアリソースを有効活用できることです。一般的な仮想マシンVMと比べてコンテナは消費リソースが少なくなります。1台のサーバー上で複数のコンテナを稼働させることができるため、インフラコストの削減が期待できます。

さらに、アプリケーションを含めて環境をパッケージングできるので、デプロイやロールバックがやりやすい、環境のポータビリティが向上するというメリットがあります。

今回お見せしたようなアーキテクチャを、システム要件や予算、メンバーのスキルレベルなどに応じて使い分けてください。