[AWS]月間1億アクセスに耐えるシステム設計を解説する

[AWS]月間1億アクセスに耐えるシステム設計を解説する

AWSで大規模サービスを構築する

今回はAWSにて月間1億アクセスに耐えることができるシステム設計を解説します。

想定するシステムはウェブサイトのサービス、iOSアプリとAndroidアプリを提供しているシステムとします。つまりシステムへのアクセス経路としてはPCやスマホのブラウザー、iOSアプリとAndroidアプリのAPIとなります。

Advertisement

システム構成の概要

まずシステムの概要図と利用するAWSの機能一覧を記載します。

システムの概要図

利用するAWSの機能一覧

AWSサービスの名称 機能
ELB(Elastic Load Balancing) ロードバランサ―
ACM(Certificate Manager) AWS専用のSSL
Route53 DNS
EC2(Elastic Compute Cloud) ウェブサーバー
Lambda サーバーレスのタスク実行
CloudFront CDN(コンテンツデリバリネットワーク)
RDS(Relational Database Service) データベース
SNS(Simple Notification Service) Push通知
CloudWatch リソース監視

 

機能別の解説

では1つずつ機能別にシステムを解説していきます。

ロードバランサーについて


まずは一番インターネットに近いロードバランサー(ELB)のお話から始めましょう。

月1億アクセスとなると1日の平均334万アクセスになります。アクセス数は時間帯ごとにばらつきがあり、特にPUSH通知やCMなどの告知によるアクセスの急激な増加はウェブサーバー1台では耐えれません。前面にロードバランサ―(ELB)を設置して、複数台のウェブサーバー(EC2)へ負荷を分散させます。

ロードバランサー(ELB)には「Application Load Balancer」を利用します。もし以前からAWSを利用していた環境であれば「Classic Load Balancer」を利用します。ロードバランサー(ELB)を使用するためRoute53でドメイン管理を行い、ACMでロードバランサー(ELB)にSSLを設定しましょう。

〇ロードバランサ―(ELB)を設置するメリット

  • ACM(Certificate Manager)でSSLを提供してもらえる
  • ウェブサーバーの死活監視(ヘルスチェック)を行うことができる
  • 各ウェブサーバーへ均等(または適切)に負荷をかけることができる
  • 状況に応じてウェブサーバーを増台・減台するができる

 

Route53に関しては別記事を作成していますので、詳細は下記をご参照ください。

[AWS]Route53を使用してELBにドメインを設定する

 

ウェブサーバーについて


概要図にて記載した主サーバーは常時稼働を前提としたサーバーで、副サーバーは負荷によって増台・減台するサーバーを示しています。
なお今回はウェブサイトとアプリを両立したサービスを前提としているため、サーバーの増台・減台は時間でスケールする想定です。特にアプリへのPUSH通知直後はサーバーへのアクセスが集中するため、事前にサーバーを増台しておきます。
サーバーの増台・減台はLambdaのスクリプトを利用して行う想定をしています。通常のサーバー増台・減台だけであればAuto Scalingの方が使い勝手が良い気がしますが、サーバーの増減時に別のスクリプトや処理を実行したいときにはLambdaの方が便利です。

memcached

主サーバーにはmemcachedをインストールしてキャッシュ機構としても利用しています。
仮に月間100億アクセスになるとmemcached専用のサーバーが必要ですが、月間1億程度のアクセスなら主サーバーとの兼用でもほぼ事足ります。

〇memcachedの使用用途

  • セッションの共有するため
  • データベースへの負荷を軽減するため
  • CDN用のワンタイムパスワード付きURLの保存するため
ELBで複数台のウェブサーバーを設置するときは、セッションを共有させるためにmemcachedやNFSを利用しましょう!

ウェブサーバーの注意点

ELB経由のアクセスは、初期状態では接続元IPアドレスがローカルIPになります。必ずapache/nginxの設定を調整して、ローカルIPアドレスをグローバルIPアドレスに変更しておきましょう。

nginxに関しては別記事を作成していますので、詳細は下記をご参照ください。

nginxにてELB経由の接続からアクセス元IPを取得する方法

 

データベースについて


データベースとしては、RDSのMySQL、またはMySQL互換のAuroraを利用します。
バージョンはMySQLの最新版であるMySQL5.7を利用しましょう。MySQL5.6以上で「Alter Table」時にテーブルへのロックが発生しなくなり、MySQL5.7以上でInnoDBでgeometry型が利用できるようになっています。

なおMySQLにて遅延が発生するときは、RDSにIOPSを設定しておきましょう。

書き込みが秒間数千リクエストに達するとIOPSの上限に関係なく、RDSがフリーズする現象を確認しているので注意しましょう。

RDSがフリーズするのは物理限界の可能性があるため、データベースをAuroraに移行するか、memcachedでデータベースの負荷を十分に下げましょう。

 

CDN(コンテンツデリバリネットワーク)について


CDNは専用の配信ネットワークを利用して、ユーザーに最も近い配信拠点から高速にデータを配信する仕組みです。CDNを利用して、サーバーの負荷軽減、及びデータの高速配信のために

  • 全ての画像データ
  • 全ての動画データ
  • アプリの更新用データ

を配信します。

なおユーザーがデータを抽出したり、不正な利用を防ぐためにデータサーバーはCloudfront以外からのアクセスを拒否して、Cloudfrontへの接続もワンタイムパスワードを必須とします。

データサーバーとしてEC2を利用していますが、S3(クラウドストレージ)でも問題ないかと考えています。以前のS3では連続アクセスに耐えることができませんでしたが、最近では改善されてS3も十分なレスポンス数が捌けることが分かっています。

Amazon S3 は高いリクエスト率に自動的にスケールされます。たとえば、アプリケーションでバケット内のプレフィックスごとに 1 秒あたり 3,500 回以上の PUT/POST/DELETE リクエストと 5,500 回以上の GET リクエストを達成できます。

引用元:https://docs.aws.amazon.com/ja_jp/AmazonS3/latest/dev/request-rate-perf-considerations.html

 

PUSH通知について


AWS内のサービスでまとめるためにPush通知用に「Amazon SNS」を記述していますが、最近ではOneSignalを使用しています(苦笑)。

自社製のPush通知サーバー → Amazon SNS → FireBase → OneSignal

と使用するPush通知機能は遷移していますが、無料で使い勝手の良いFireBaseかOneSignalを利用することをおススメです。

 

データ解析について


ウェブサーバーからfluentdで検索・解析用サーバーにデータを送信しています。

ソフト名 機能
Apache Solr(ソーラー) ウェブサーバーへ検索エンジンを提供します
Redash 解析したデータの確認用に設定しています

 

サーバーの監視について

サーバーの監視としてCloudWatchを使用しています。
サーバーの監視項目としては、ELBとEC2間の応答で確認できる500系統のエラーを監視対象とすることをおススメです。CPU負荷やメモリー使用率も確認しますが、エラーの有無がサービスを運用する上で一番重要だと考えます。

もちろん監視サーバーとしてNagiosやZabbixを別に設置しているのであれば、CloudWatchと一緒にサービスを監視対象に追加してください。

 

さいごに

高負荷に耐えるためのシステム構成を説明してきましたが、いかがでしたでしょうか?
大規模サーバーの仕組みを知っておくと、大小の規模に関係なくサーバーを構築するときに広い視野を持つことができます。もしより良いサーバー構成や調整方法をご存知の方はお知らせ下されば嬉しい限りです。

Advertisement

インフラカテゴリの最新記事