AWSクラウド構築テンプレートサービスの『WEB/AP+DBサーバ（Linux版）』を解説します

ウィスキー、シガー、パイプをこよなく愛する大栗です。

先日、初期費用無料で導入できる「WEB/AP＋DBサーバ」構成の提供を開始しました。これは弊社のAWS総合支援サービスであるメンバーズの一環で提供しているサービスなのですが、その構成について解説をしたいと思います。

メンバーズとは？

弊社クラスメソッドが提供するAWS総合支援サービスがメンバーズです。

メンバーズ ｜ クラスメソッド株式会社

大きな特徴として、以下のものがあります。

• コストパフォーマンス
  • 初期費用無料、代行手数料無料
  • 弊社にてAWSエンタープライズサポート、損害保険に加入済み
  • AWS利用費ディスカウント（EC2利用費10%OFF¹、CloudFrontアウトバウンド通信費64%OFF²）
• セキュリティ
  • MFA設計やファイアウォール設定などのセキュリティ自動チェックを実施しています。
• サポート
  • 日々追加される新しい機能をいち早く調査し常にベストプラクティスを提供できるように、サポートや情報発信(Developers.IOなど)を行っています。

メンバーズには以下のラインナップがあります。ラインナップによって提供サービスの内容が異なりますので、詳しくはメンバーズのページを御覧ください。

• メンバーズ・フルサポート
  セキュリティ、ログ、バックアップ、チェックなど重要なサポートを受けたい方向け。
• メンバーズ・バウチャー
  年間の予算枠が決まっていてその中でAWSを活用したい方向け。
• メンバーズ・スタート
  最も安くAWSを使いたいが、万が一の場合のサポートを受けたい方向け。

初期費用『無料』のAWSクラウド構築テンプレートサービス

AWSクラウド構築テンプレートサービスは初期費用『無料』³で、AWS環境の構成をセットアップ済みの状態で提供するサービスとなります。ご提供する構成は標準構成、CMS、セキュリティ、IoTなど多岐に渡ります。こちらは、『メンバーズ・フルサポート』が提供するサービスの一環となります。

『WEB/AP+DBサーバ（Linux版）』テンプレート

『WEB/AP+DBサーバ（Linux版）』テンプレートは標準的なAWSのLB-WEB/AP-DBの構成となっています。この中にクラスメソッドが持つノウハウを詰め込んでいます。EC2を配置するサブネットがパブリックな構成とプライベートな構成の2種類が有るのですが、プライベートな構成について解説します。

AWS による優れた設計のフレームワーク(AWS Well-Architected Framework)で述べている、以下の4本柱ごとに内容を解説します。

• セキュリティ
• 信頼性
• パフォーマンス効率
• コストの最適化

なお、本構成で対象としているお客様は、AWSに不慣れであったり、専任のAWS構築/運用者がいらっしゃらない企業様を想定しております。

セキュリティ

プライベートネットワーク構成では、外部からWEB/APサーバへ直接アクセスすることはできません。http/httpsのアクセスはALBを経由しますし、メンテナンス用のSSH接続はBastionサーバを経由する必要があります。DBサーバやキャッシュサーバは、外部からアクセスも外部へのアクセスもできないDatastoreサブネットに配置します。

ファイアウォール設定では、セキュリティグループでアクセス制御を実施しています。ALBはhttp/httpsのアクセスを許可、WEB／APサーバはALBからのhttpとBastionサーバからのSSHのみ許可、RDS/ElastiCacheはWEB／APサーバからのみのアクセスを許可しています。
AWSのファイアウォールにはネットワークACLもあります。スタティックなパケットフィルタであるためメンテナンスの手間がかかるのでネットワークACLでは制限を行っていません。

Bastionサーバは標準構成ですが、SSHでのアクセスである必要がなければ停止してしまうのも良いでしょう。各EC2には各種AWSサービスのエージェントががインストール済みなので、アプリケーションのデプロイであればCodeDeployを使用したり、メンテナンス作業であればEC2 Run Commandを使用したり、SSHを使わずに実施できます。

WEB/APサーバはEC2を使用しているため、自前でOSの管理が必要となります。特にセキュリティチェックが頭痛の種でしょう。本構成ではAmazon Inspectorのエージェントが導入済みなので、毎月自動でセキュリティ評価をすることも簡単にできます。

WEB/APサーバでは、OS内の情報をCloudWatchへ出力していますが、AWS API用のアクセスキーを設定せずにIAM Roleを使用しています。IAM Roleを使用することでアクセスキーの保持が必要なくなりセキュアにAWSへアクセスできます。

信頼性

基本的な構成として、ほぼ全てのリソースをMulti-AZ(複数データセンタ構成)にしています。これによりデータセンタレベルの大規模障害が発生してもサービス提供を継続することが可能となります。構築する主なリソースは以下のようになります。

• Route 53(DNSサービス)：DNSサーバが世界中に分散されているため、極めて高い可能性(可用性100%のSLA)が確保されています。
• ALB(ロードバランサ)：データセンタ(Availability Zone:AZ)毎に分散されて配置しています。
• EC2(仮想サーバ)：AZ毎に1または2台を配置して、合計2または4台の構成にして冗長性を図っています。またAuto Recoveryを設定しており、物理サーバに異常があっても自動復旧します。
• RDS(DBサーバ)：RDSはMySQLまたはPostgreSQLを選択可能で、Multi-AZ構成としています。あるAZにRDSが配置されると、もう片方のAZに同期スタンバイレプリカを自動的に構成します。Multi-AZ構成のRDSは可用性99.95%の可用性⁴となります。
• NAT Gateway：NAT Gateway自身が冗長性を持たせて実装されていますが、各AZに配置することで高い可用性を期待できます。

冗長性以外にも、EC2への設定を追加しています。CloudWatchメトリクスではOS内部の情報を収集することはできません。そこで、メモリ使用量とディスク使用率をカスタムメトリクスとして、CloudWatchへ集約しています。カスタムメトリクスに設定することで弊社の監視サービスであるクラスメソッドモニタリングサービスくらもんでメモリ使用量やディスク使用率を監視することができるようになります。 CloudWatchからアラート通知や自動復旧処理を追加することが可能です。さらにCloudWatch Logエージェントをインストールしているため、ログをCloudWatch Logsへ集約可能です。

パフォーマンス効率

WEB/APサーバは、本来はAuto ScalingによってWEB/APの負荷に応じて動的に台数を変更する構成をお勧め致します。しかし、アプリケーションがレガシーなアーキテクチャの場合は、負荷に応じて自動でEC2が追加や破棄をすることでアプリケーションに不都合な場合があります。本構成では幅広いお客様の環境で使用可能にするため、通常のEC2について必要なインスタンスタイプ/台数を選択して起動する構成をしています。
WEB/APサーバで使用するインスタンスファミリーは最新世代のM4やC4を選択しましょう。メモリを多く使用する場合にはM4、CPUを多く使用する場合にはC4となります。なお、Auto Recoveryを有効化するためにインスタンスストアを使用していません。そのため、インスタンスストアがあるというM3やC3の利点を生かせないので選択不要です。
インスタンスストアが無いものとしてT2もあります。T2はCPU性能がバーストしますが、バーストが終わるとベースラインのCPU性能しか発揮できない、本番環境での使用はお勧めいたしません⁵。

DBサーバではRDSを使用しています。そのため、数クリックでインスタンスサイズを大きくしたり、リードレプリカを追加したりすることができます。
なお、大規模な構成が必要である場合は高多重度なアクセスを捌くことができるAuroraをお勧めします。⁶

コストの最適化

コストの最適化という面でも、Auto Scalingにすると負荷に応じたリソースのみを使用するので必要のないコストが発生しないため、望ましい構成です。しかし前述の通り、幅広いお客様の環境で使用可能にするため、通常のEC2を起動しています。そのため利用状況を分析して、必要なリソースを現状に合わせる必要があります。
しかし、ご安心ください。キャパシティが不足している場合は「クラスメソッドモニタリングサービスくらもん」でキャパシティ不足のアラートを通知しますし、キャパシティが余っている場合には毎週ご送付する『AWSご利用分析レポート』の「使用率の低いEC2インスタンス」をご覧頂くことでキャパシティ調整も容易です。

さいごに

いかがでしょうか？本構成は弊社のAWSに関するノウハウを詰め込んで作成しております。セキュリティ、信頼性、パフォーマンス効率、コストの最適化に優れた構成を初期費用『無料』でご利用可能です。是非お申し込みください。

AWSクラウド構築テンプレートサービス