さいごにAWSで大規模なサービスを構築する今回はAWSにて月間1億アクセスに耐えることができるシステム設計を解説します。想定するシステムはウェブサイトのサービス、iOSアプリとAndroidアプリを提供しているシステムとします。システムへのアクセス経路としてはPCやスマホのブラウザー、iOSアプリとAndroidアプリのAPIとなります。Advertisementシステム構成の概要まずシステムの概要図と利用するAWSの機能一覧を記載します。機能別の解説では1つずつ機能別にシステムを解説していきます。ロードバランサーについてまずは一番インターネットに近いロードバランサー(ELB)のお話から始めましょう。月1億アクセスとなると1日の平均334万アクセスになります。アクセス数は時間帯ごとにばらつきがあり、特にPUSH通知やCMなどの告知によるアクセスの急激な増加はウェブサーバー1台では耐えれません。前面にロードバランサ―(ELB)を設置して、複数台のウェブサーバー(EC2)へ負荷を分散させます。Balancer」を利用します。Balancer」を利用します。ロードバランサー(ELB)を使用するためRoute53でドメイン管理を行い、ACMでロードバランサー(ELB)にSSLを設定しましょう。Manager)でSSLを提供してもらえるウェブサーバーの死活監視(ヘルスチェック)を行うことができる各ウェブサーバーへ均等(または適切)に負荷をかけることができる状況に応じてウェブサーバーを増台・減台するができるRoute53に関しては別記事を作成していますので、詳細は下記をご参照ください。[AWS]Route53を使用してELBにドメインを設定するhttps://www.t3a.jp/blog/infrastructure/use_route53/ウェブサーバーについて概要図にて記載した主サーバーは常時稼働を前提としたサーバーで、副サーバーは負荷によって増台・減台するサーバーを示しています。今回はウェブサイトとアプリを両立したサービスを前提としているため、サーバーの増台・減台は時間でスケールする想定です。アプリへのPUSH通知直後はサーバーへのアクセスが集中するため、事前にサーバーを増台しておきます。サーバーの増台・減台はLambdaのスクリプトを利用して行う想定をしています。Scalingの方が使い勝手が良い気がしますが、サーバーの増減時に別のスクリプトや処理を実行したいときにはLambdaの方が便利です。memcached主サーバーにはmemcachedをインストールしてキャッシュ機構としても利用しています。仮に月間100億アクセスになるとmemcached専用のサーバーが必要ですが、月間1億程度のアクセスなら主サーバーとの兼用でもほぼ事足ります。〇memcachedの使用用途セッションの共有するためデータベースへの負荷を軽減するためCDN用のワンタイムパスワード付きURLの保存するためELBで複数台のウェブサーバーを設置するときは、セッションを共有させるためにmemcachedやNFSを利用しましょう!ウェブサーバーの注意点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を利用しましょう。Table」時にテーブルへのロックが発生しなくなり、MySQL5.7以上でInnoDBでgeometry型が利用できるようになっています。MySQLにて遅延が発生するときは、RDSにIOPSを設定しておきましょう。書き込みが秒間数千リクエストに達するとIOPSの上限に関係なく、RDSがフリーズする現象を確認しているので注意しましょう。RDSがフリーズするのは物理限界の可能性があるため、データベースをAuroraに移行するか、memcachedでデータベースの負荷を十分に下げましょう。CDN(コンテンツデリバリネットワーク)についてCDNは専用の配信ネットワークを利用して、ユーザーに最も近い配信拠点から高速にデータを配信する仕組みです。CDNを利用して、サーバーの負荷軽減、及びデータの高速配信のために全ての画像データ全ての動画データアプリの更新用データを配信します。ユーザーがデータを抽出したり、不正な利用を防ぐためにデータサーバーはCloudfront以外からのアクセスを拒否して、Cloudfrontへの接続もワンタイムパスワードを必須とします。データサーバーとしてEC2を利用していますが、S3(クラウドストレージ)でも問題ないかと考えています。以前のS3では連続アクセスに耐えることができませんでしたが、最近では改善されてS3も十分なレスポンス数が捌けることが分かっています。は高いリクエスト率に自動的にスケールされます。リクエストを達成できます。SNS」を記述していますが、最近ではOneSignalを使用しています(苦笑)。OneSignalと使用するPush通知機能は遷移していますが、無料で使い勝手の良いFireBaseかOneSignalを利用することをおススメです。データ解析についてウェブサーバーからfluentdで検索・解析用サーバーにデータを送信しています。解析したデータの確認用に設定していますサーバーの監視についてサーバーの監視としてCloudWatchを使用しています。サーバーの監視項目としては、ELBとEC2間の応答で確認できる500系統のエラーを監視対象とすることをおススメです。CPU負荷やメモリー使用率も確認しますが、エラーの有無がサービスを運用する上で一番重要だと考えます。監視サーバーとしてNagiosやZabbixを別に設置しているのであれば、CloudWatchと一緒にサービスを監視対象に追加してください。さいごに高負荷に耐えるためのシステム構成を説明してきましたが、いかがでしたでしょうか?大規模サーバーの仕組みを知っておくと、大小の規模に関係なくサーバーを構築するときに広い視野を持つことができます。良いサーバー構成や調整方法をご存知の方はお知らせ下されば嬉しい限りです。アルバイトでゲーム開発に携わりIT業界入り。組み込みや業務系のソフト開発を経験して、その後レンタルサーバー会社にてインターネットの根幹の知識を得る。今ではスマホアプリの開発やWeb開発、インフラの構築に従事中。WordPress.。