「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介

「落ちない」AWSのインフラ構成、
システム要件にあわせたパターンをご紹介
1
2019.05.10
道玄坂 WordPress Meetup #1 〜絶対に落ちてはいけないウェブサイト24時〜
NHN テコラス株式会社マネージドサービス事業部瀧川真之

自己紹介
2
瀧川真之
NHNテコラス株式会社マネージドサービス事業部プリセールス
• 監視のエンジニアから→SE→プリセールス・営業と渡り歩いてきました。
現在はAWSはじめ、クラウド全般・オンプレのMSP(監視・運用)を主に扱って
います。
• AWS歴 5-6年となります。
• Webサービス系、エンタメ系業界のお客様を中心に担当をしています。

アジェンダ
3
• AWSについて
• 「落ちない」の定義
• パターン０：最小構成
• パターン１：冗長化/リージョン内
• パターン２：スパイク負荷対応
• パターン３：冗長化/リージョン間（DR）
• まとめ

AWSとは？
Amazonが提供する
世界シェアNo.1のパブリッククラウドサービス
米調査会社ガートナーの2018年8月発表
• AWSを利用するメリット
⁃ 継続的な値下げ
◦過去10年で60回以上の値下げ
⁃ サイジングからの解放
◦スケールできるから使った分だけ課金
⁃ 無料枠を利用して検証ができる
⁃ 頼れるセキュリティ
◦第三者機関による認証をうけたコンプライアンス要件に準拠
⁃ 日本最大級のコミュニティ JAWS-UG
◦日本語の技術情報も豊富
4

6
そもそも “落ちない” とは・・・

7
ダウンタイムは
どのくらい許容される
のか？
突発的なアクセス集中
が予測されるのか？
日本災害時もサイト存続は
必要か？

コストとのトレードオフ
8
コストリスク
最小構成のサイト！(ダウンタイム有)
まずは基本の落ちないサイト！
日本が災害でも落ちないサイト！
アクセスが急増しても落ちないサイト！

コストとのトレードオフ
9
コストリスク
パターン０：最小構成
まずは基本の落ちないサイト！
日本が災害でも落ちないサイト！
アクセスが急増しても落ちないサイト！
パターン1：冗長化/リージョン内
パターン2：スパイク負荷対応
パターン3：冗長化/リージョン間

パターン０：最小構成
10

パターン0：最小構成パターン
11
想定要件
• 一定のダウンタイムが許されるサイト
• 定量的なアクセスのみで突発的なアクセスが想定されないサイト
• コスト重視（スモールスタートなど）

12
AWS Cloud
VPC
Availability Zone
Snapshot
EC2
Backup
管理者
ユーザー

13
想定要件
• 一定のダウンタイムが許されるサイト
• コスト重視（スモールスタートなど）
要件担保の為、必要な施策
• インスタンス障害時の迅速な復旧（MSPサービス等の活用）

パターン１：冗長化/リージョン内
14

パターン①：冗長化/リージョン内
15
想定要件
• ダウンタイムが許されない
• 同一リージョン内での可用性が必要（AWSメンテナンス回避など）

16
AWS Cloud
VPC
Availability Zone
Snapshot
EC2
Availability Zone
EC2
管理者
rsync
RDS MySQL
(Master)
RDS MySQL
(Slave)
Multi-AZ

17
想定要件
• 冗長化構成（EC2、RDS）
• ELBによる負荷分散
• リソース状況の監視、片系障害時の対応（即時ではないが、対応は必要）

パターン２：スパイク負荷対応
18

パターン②：スパイク負荷対応
19
想定要件
• イベントや時間帯によって突発的なアクセスが想定されるサイト

Auto Scaling group
20
AWS Cloud
VPC
Availability Zone
Snapshot
EC2
Availability Zone
EC2
管理者
RDS MySQL
(Master)
RDS MySQL
(Slave)
EC2
S3
ELB
Cloud Front
静的コンテンツ、画像、プラグインなどのデータは
S3にオフロード
（別途専用プラグインが必須：W3-Total-Cacheなど）

21
想定要件
• 冗長化及びオートスケールによる負荷分散
• S3、CloudFrontによる静的コンテンツのオフロード対応（EC2オートスケール対応の為）
• リソース状況の監視、障害時の対応（即時ではないが、対応は必要）

パターン３：冗長化/リージョン間
22

パターン③：冗長化/リージョン間
23
想定要件
• 日本国内リージョン障害時もサービス継続提供が必須（DR）

Auto Scaling
group
24
AWS Cloud
VPC
Availability Zone
SnapshotEC2
Availability Zone
EC2
RDS MySQL
(Master)
RDS MySQL
(Read Replica)
EC2
Region
(Tokyo)
Region
(Singapore)
VPC
RDS MySQL
(Slave)
EC2
VPC
Peering
AMI
Snapshot
AMI
Cloud Front
Global Accelerator
S3 ELB
ELB S3
管理者 EC2
リージョン間レプリケーション

25
Auto Scaling
group
AWS Cloud
VPC
Availability Zone
EC2
Availability Zone
EC2
RDS MySQL
(Master)
RDS MySQL
(Read Replica)
EC2
Region
(Tokyo)
Region
(Singapore)
VPC
RDS MySQL
(Slave)
EC2
VPC
Peering
AMI
Snapshot
AMI
Cloud Front
Global Accelerator
S3 ELB
ELB S3
管理者 EC2Snapshot
Cloud Front、Global Acceleratorのヘルスチェッ
ク機能により、メインリージョンダウン時にセ
カンダリリージョンへ切り替わる
メインリージョンのMasterの反応が無くなった場合、
Read Replicaがスタンドアローンとして機能

26
想定要件
• 日本国内リージョン障害時もサービス継続提供が必須（DR）
• リージョン内、リージョン間冗長化及びオートスケールによる負荷分散
• S3、Cloud Frontによる静的コンテンツのオフロード対応（EC2オートスケール対応の為）
• Cloud Front、Global Acceleratorによるリージョン障害時の切替構成
• 必要に応じて、切替サイト先での冗長化、管理インスタンス構築

参考：AWSベストプラクティス
https://aws.amazon.com/jp/blogs/architecture/wordpress-best-practices-on-aws/

まとめ
28
• 「落ちない」定義を定める
• コストとのトレードオフを考える
• AWSの機能・制約を理解した上で、要件にあったパターンを構成
• 環境構成でカバー不可部分は、必要に応じて運用で対応
とは言え、インフラ設計・運用を抱えながら
Webサイトの運営をするのは大変・・・

まとめ
29
そんな方は・・・
インフラについてプロに任せるのも一つの手です！

NHNテコラスマネージドクラウドサービス
－30－
国内外の主要クラウドを中心とした設計・構築・監視・運用を代行するマルチクラウド
対応のマネージドサービスです。
お客様ごとに構築要件や監視項目をカスタマイズし、パターンに囚われない柔軟な対応
が可能です。
提案・設計
詳細設計・構築
移行支援
監視・運用 24/365サポート障害対応
お客様の要件をヒアリ
ングし、サービス用途
に合わせて設計します。
弊社のエンジニアが、
豊富な経験と知識を活
かし、環境を構築しま
す。
オペレーターではなく
弊社SEで構成された
MSPチームが直接監視
運用を行う為、迅速な
対応を実現します
お客様の止められない
システムを24時間365
日有人監視し続けます。
障害検知時には、迅速
に弊社MSPチームより
お客様へ通知を行い、
一次切り分けや障害対
応を行います。
監視・運用初期構築
担当営業
ITアーキテクト
専属エンジニア MSPチーム

AWSの運用についてもっと知りたい方へ
31
AWS社も
登壇！

32
ご清聴ありがとうございました。

「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介

More Related Content

What's hot

Similar to 「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介

More from NHN テコラス株式会社

「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介

Editor's Notes