理想を追い求める！稼働率99.999999999%目指した3層構造のWEBアプリ構成を考える！
はじめに
現代のWEBアプリケーションにおいて、信頼性の高いシステム構築は重要な課題です。「落ちないサイト」を求められることが多い中、理想的な稼働率である99.999999999%を目指したシステム構成はどうなるのでしょうか？
本記事では、3層構造のWEBアプリケーションを題材に、各サービスのSLAを算出し、稼働率99.999999999%を目指した構成を考察します。さらに、その構成にかかるコストを試算し、どの程度の予算で実現可能か、また妥協した場合のコスト削減案を具体的にまとめております。
結果的には、運用だけで年間数千万円規模のランニングコストが必要であることがわかります。本来であれば、ランニングコストに加えて、導入コスト、さらには運用者の人件費もかかってきますので、導入だけで数億、人件費を加えたランニングコストは億に近づくことが予想できます。
この記事を通じて、システム設計や経営判断、もう少し身近な話として、役職者の説明時などで役立つ材料にしてもらえると幸いです。
前提条件
本構成は以下の前提に基づいて設計を行っています。
| 利用者数の想定 | ・ 同時接続数：50,000ユーザー ・ 月間アクティブユーザー数：10,000,000人 |
|---|---|
| データ数の想定 | ・ 毎月のデータ生成量：50TB ・ 総データストレージ：500TB |
| 想定されるアプリの種類 | ・ 動画配信サービス ・ ECサイト ・ 金融取引プラットフォーム |
| セキュリティ要件 | ・ トラフィックの暗号化（TLS 1.3対応） ・ DDoS対策（専用WAF利用） ・ 脅威インテリジェンスの活用 |
| 冗長性要件 | ・ 最低5リージョン構成で、各リージョンに完全な冗長構成を実現 ・ 障害時の自動フェイルオーバー |
これらを基に、99.999999999%の稼働率を目指したシステム構成を検討します。
稼働率とダウンタイムの関係
まず、稼働率とダウンタイムの関係を整理します。稼働率を達成するには、ダウンタイムを最小限に抑える必要があります。
以下の表は、稼働率と年間ダウンタイムの関係を示したものです。
| 稼働率 | 年間ダウンタイム | 月間ダウンタイム | 1週間のダウンタイム |
|---|---|---|---|
| 99.9% | 8時間45分36秒 | 約43分48秒 | 約10分 |
| 99.99% | 52分36秒 | 約4分23秒 | 約1分 |
| 99.999% | 5分15秒 | 約25.9秒 | 約6.05秒 |
| 99.9999% | 31.5秒 | 約2.63秒 | 約0.61秒 |
| 99.999999999% | 31.5ミリ秒 | 約2.63ミリ秒 | 約0.61ミリ秒 |
稼働率が1桁上がるごとに、ダウンタイムが大幅に短縮されることがわかります。ただし、お察しの通り、これを実現するためのコストは指数的に増加します。
理想の3層WEBアプリ構成
構成の概要
稼働率99.999999999%を目指すためには、以下の3層構造が必要です。
※インフラのベースをAWSにしているのは、他サービスに比べて可用性が高いことを強みとしているため、外的要因によるシステムダウンを予防する可能性を少しでも高めるためです。
アプリケーション層
- Kubernetesを利用したコンテナ化とオートスケーリング
- 多リージョン展開 (最低5リージョン)
- グローバルロードバランサーを利用
データベース層
- マルチリージョン対応のRDBMS (Amazon Auroraなど)
- 高速なキャッシュ層 (Redis Enterprise)
インフラ層
- エッジネットワーク (CloudFrontやAWS Global Accelerator)
- 冗長化されたサーバ構成
各層の詳細構成
アプリケーション層
| Kubernetesクラスタ | ・ 各リージョンに最新のインスタンスタイプである c7g.xlarge (Graviton3対応) を5ノードずつ配置 ・ 負荷に応じたオートスケーリングでピーク時には25ノードまで拡張 |
|---|---|
| グローバルロードバランサー | ・ AWS Global Acceleratorを利用 |
データベース層
| Amazon Aurora Multi-Region | ・ プライマリDBを1リージョンに配置し、他4リージョンにリードレプリカを展開 ・ Aurora Global Databaseを活用し、高速なフェイルオーバーを実現 |
|---|---|
| Redis Enterprise Cloud | ・ マルチゾーン構成でキャッシュ性能を最大化 |
ストレージ・キャッシュ
| Amazon S3 | ・ 毎月のデータ生成量50TBに対応するため、合計150TB/月のストレージを確保 |
|---|---|
| CloudFront | ・ エッジキャッシュによる高速化を実現 |
監視と運用
| Datadog | モニタリング |
|---|---|
| PagerDuty | オンコール対応 |
| AWS Backup | 自動バックアップ |
構成イメージ
理想構成のコスト詳細
サービスコスト
以下は、AWSやサードパーティのサービスを用いた場合の月額コスト試算です。
| サービス | コスト計算 | 月額コスト (USD) | 公式サイト |
|---|---|---|---|
| EC2 (アプリ層) | 25ノード x $272 (c7g.xlarge) | $272 × 25ノード = $6,800 | EC2価格ページ |
| Aurora Multi-Region | プライマリ1台 + リードレプリカ4台 | ($920 × 1) + ($345 × 4) = $2,300 | Aurora価格ページ |
| Redis Enterprise | 150GBのマルチゾーン構成 | 150GB × $16 = $2,400 | Redis価格ページ |
| S3 | 150TB/月 | 150TB × $0.023 = $3,450 | S3価格ページ |
| CloudFront | 50TBデータ転送/月 | 50TB × $0.085 = $4,250 | CloudFront価格ページ |
| AWS Global Accelerator | 基本料金 + リージョン使用料 | $100 + (5リージョン × $4) = $120 | Global Accelerator価格ページ |
| Datadog | 100ホスト (1ホスト$18) | $100 × 18 = $1,800 | Datadog価格ページ |
| PagerDuty | 10ユーザー (1ユーザー$40) | 10ユーザー × $40 = $400 | PagerDuty価格ページ |
| 合計 | $21,520 |
合計コスト
- 月額総コスト: $21,520 (約300万円)
- 年間総コスト: $258,240 (約3600万円)
現実的な稼働率99.9%構成とコスト
稼働率99.999999999%ではランニングコストのみで莫大な費用が掛かってしまうので、実際の落としどころとして、稼働率99.9%の構成も検討をしてみました。
構成変更点
| リージョン数の削減 | 5リージョンから2リージョンに削減 |
|---|---|
| リードレプリカ数の削減 | Auroraリードレプリカを1リージョンあたり1台のみに変更 |
| インスタンスタイプの変更 | EC2のインスタンスタイプを中性能なm6g.largeに変更 |
| 監視コスト削減 | Datadogのホスト数を50に縮小 |
新構成のコスト詳細
| サービス | コスト計算 | 月額コスト (USD) |
|---|---|---|
| EC2 (アプリ層) | 10ノード x $96 (m6g.large) | $960 |
| Aurora Multi-Region | プライマリ1台 + リードレプリカ1台 | $920 |
| Redis Enterprise | 50GBのマルチゾーン構成 | $800 |
| S3 | 50TB/月 | $1,150 |
| CloudFront | 20TBデータ転送/月 | $1,700 |
| AWS Global Accelerator | 基本料金 + リージョン使用料 | $60 |
| Datadog | 50ホスト (1ホスト$18) | $900 |
| PagerDuty | 5ユーザー (1ユーザー$40) | $200 |
| 合計 | $6,690 |
- 月額総コスト: $6,690 (約93万円)
- 年間総コスト: $80,280 (約1116万円)
稼働率99.9%のメリットとトレードオフ
- コスト削減: 約75%のコスト削減。
- ダウンタイム: 年間約8時間のダウンタイムが許容される。
まとめ
理想の構成 (99.999999999%)と現実的な構成 (99.9%)の、年間コストと稼働率をまとめると以下のようになります。
| 理想の構成 (99.999999999%) | ・年間コスト: 約3600万円 ・稼働率: 年間約31.5ミリ秒のダウンタイム |
| 現実的な構成 (99.9%) | ・年間コスト: 約1116万円 ・稼働率: 年間約8時間のダウンタイム |
超高可用性システムを設計する際には、コストと可用性のバランスを適切に取ることが重要です。過剰なリスクヘッジや、興味本位だけでのチャレンジなど、現場で無理難題を押し付けられる場合は少なくありません。
そのような場面では、今回の事例のを参考に試算していただき、コストモリモリの構成案と、妥協案（本命）を準備しておくことでより良い方向で進んでくれるはずです。
この記事をシェア
