この記事には広告を含む場合があります。
記事内で紹介する商品を購入することで、当サイトに売り上げの一部が還元されることがあります。
目次
AWSで大規模なサービスを構築する
今回はAWSにて月間1億アクセスに耐えることができるシステム設計を解説します。
想定するシステムはウェブサイトのサービス、iOSアプリとAndroidアプリを提供しているシステムとします。つまりシステムへのアクセス経路としてはPCやスマホのブラウザー、iOSアプリとAndroidアプリのAPIとなります。
システム構成の概要
まずシステムの概要図と利用する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 | リソース監視 |
機能別の解説
では１つずつ機能別にシステムを解説していきます。
ロードバランサーについて
まずは一番インターネットに近いロードバランサー(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にドメインを設定する
https://www.t3a.jp/blog/infrastructure/use_route53/
ウェブサーバーについて
概要図にて記載した主サーバーは常時稼働を前提としたサーバーで、副サーバーは負荷によって増台・減台するサーバーを示しています。
なお今回はウェブサイトとアプリを両立したサービスを前提としているため、サーバーの増台・減台は時間でスケールする想定です。特にアプリへのPUSH通知直後はサーバーへのアクセスが集中するため、事前にサーバーを増台しておきます。
サーバーの増台・減台はLambdaのスクリプトを利用して行う想定をしています。通常のサーバー増台・減台だけであればAuto Scalingの方が使い勝手が良い気がしますが、サーバーの増減時に別のスクリプトや処理を実行したいときにはLambdaの方が便利です。
memcached
主サーバーにはmemcachedをインストールしてキャッシュ機構としても利用しています。
仮に月間100億アクセスになるとmemcached専用のサーバーが必要ですが、月間1億程度のアクセスなら主サーバーとの兼用でもほぼ事足ります。
〇memcachedの使用用途
- セッションの共有するため
- データベースへの負荷を軽減するため
- CDN用のワンタイムパスワード付きURLの保存するため
ウェブサーバーの注意点
ELB経由のアクセスは、初期状態では接続元IPアドレスがローカルIPになります。必ずapache/nginxの設定を調整して、ローカルIPアドレスをグローバルIPアドレスに変更しておきましょう。
nginxに関しては別記事を作成していますので、詳細は下記をご参照ください。
nginxにてELB経由の接続からアクセス元IPを取得する方法
https://www.t3a.jp/blog/infrastructure/nginx-get-remote-ip/
データベースについて
データベースとしては、RDSのMySQL、またはMySQL互換のAuroraを利用します。
バージョンはMySQLの最新版であるMySQL5.7を利用しましょう。MySQL5.6以上で「Alter Table」時にテーブルへのロックが発生しなくなり、MySQL5.7以上でInnoDBでgeometry型が利用できるようになっています。
なおMySQLにて遅延が発生するときは、RDSにIOPSを設定しておきましょう。
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通知機能は遷移していますが、無料で使い勝手の良いFireBaseかOneSignalを利用することをおススメです。
データ解析について
ウェブサーバーからfluentdで検索・解析用サーバーにデータを送信しています。
| ソフト名 | 機能 |
|---|---|
| Apache Solr(ソーラー) | ウェブサーバーへ検索エンジンを提供します |
| Redash | 解析したデータの確認用に設定しています |
サーバーの監視について
サーバーの監視としてCloudWatchを使用しています。
サーバーの監視項目としては、ELBとEC2間の応答で確認できる500系統のエラーを監視対象とすることをおススメです。CPU負荷やメモリー使用率も確認しますが、エラーの有無がサービスを運用する上で一番重要だと考えます。
もちろん監視サーバーとしてNagiosやZabbixを別に設置しているのであれば、CloudWatchと一緒にサービスを監視対象に追加してください。
さいごに
高負荷に耐えるためのシステム構成を説明してきましたが、いかがでしたでしょうか？
大規模サーバーの仕組みを知っておくと、大小の規模に関係なくサーバーを構築するときに広い視野を持つことができます。もしより良いサーバー構成や調整方法をご存知の方はお知らせ下されば嬉しい限りです。
