「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介
•
3 j'aime•8,432 vues
WordPressをAWSで構築する際に「落ちない」ことを考慮した構成を想定するパターンとともに紹介していきます。
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à 「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介
Similaire à 「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介 (20)
Plus de NHN テコラス株式会社
Plus de NHN テコラス株式会社 (20)
Dernier
Dernier (9)
「落ちない」AWSのインフラ構成、システム要件にあわせたパターンをご紹介
- 1. 「落ちない」AWSのインフラ構成、 システム要件にあわせたパターンをご紹介 1 2019.05.10 道玄坂 WordPress Meetup #1 〜絶対に落ちてはいけないウェブサイト24時〜 NHN テコラス株式会社 マネージドサービス事業部 瀧川 真之
- 2. 自己紹介 2 瀧川 真之 NHNテコラス株式会社 マネージドサービス事業部 プリセールス • 監視のエンジニアから→SE→プリセールス・営業と渡り歩いてきました。 現在はAWSはじめ、クラウド全般・オンプレのMSP(監視・運用)を主に扱って います。 • AWS歴 5-6年となります。 • Webサービス系、エンタメ系業界のお客様を中心に担当をしています。
- 3. アジェンダ 3 • AWSについて • 「落ちない」の定義 • パターン０：最小構成 • パターン１：冗長化/リージョン内 • パターン２：スパイク負荷対応 • パターン３：冗長化/リージョン間（DR） • まとめ
- 4. AWSとは？ Amazonが提供する 世界シェアNo.1のパブリッククラウドサービス 米調査会社ガートナーの2018年8月発表 • AWSを利用するメリット ⁃ 継続的な値下げ ◦過去10年で60回以上の値下げ ⁃ サイジングからの解放 ◦スケールできるから使った分だけ課金 ⁃ 無料枠を利用して検証ができる ⁃ 頼れるセキュリティ ◦第三者機関による認証をうけたコンプライアンス要件に準拠 ⁃ 日本最大級のコミュニティ JAWS-UG ◦日本語の技術情報も豊富 4
- 5. 「落ちない」の定義 5
- 10. パターン０：最小構成 10
- 11. パターン0：最小構成パターン 11 想定要件 • 一定のダウンタイムが許されるサイト • 定量的なアクセスのみで突発的なアクセスが想定されないサイト • コスト重視（スモールスタートなど）
- 13. パターン0：最小構成パターン 13 想定要件 • 一定のダウンタイムが許されるサイト • 定量的なアクセスのみで突発的なアクセスが想定されないサイト • コスト重視（スモールスタートなど） 要件担保の為、必要な施策 • インスタンス障害時の迅速な復旧（MSPサービス等の活用）
- 15. パターン①：冗長化/リージョン内 15 想定要件 • ダウンタイムが許されない • 定量的なアクセスのみで突発的なアクセスが想定されないサイト • 同一リージョン内での可用性が必要（AWSメンテナンス回避など）
- 16. パターン①：冗長化/リージョン内 16 AWS Cloud VPC Availability Zone Snapshot EC2 Availability Zone EC2 管理者 rsync RDS MySQL (Master) RDS MySQL (Slave) Multi-AZ
- 17. パターン①：冗長化/リージョン内 17 想定要件 • ダウンタイムが許されない • 定量的なアクセスのみで突発的なアクセスが想定されないサイト • 同一リージョン内での可用性が必要（AWSメンテナンス回避など） 要件担保の為、必要な施策 • 冗長化構成（EC2、RDS） • ELBによる負荷分散 • リソース状況の監視、片系障害時の対応（即時ではないが、対応は必要）
- 19. パターン②：スパイク負荷対応 19 想定要件 • ダウンタイムが許されない • イベントや時間帯によって突発的なアクセスが想定されるサイト • 同一リージョン内での可用性が必要（AWSメンテナンス回避など）
- 20. 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. パターン②：スパイク負荷対応 21 想定要件 • ダウンタイムが許されない • イベントや時間帯によって突発的なアクセスが想定されるサイト • 同一リージョン内での可用性が必要（AWSメンテナンス回避など） 要件担保の為、必要な施策 • 冗長化及びオートスケールによる負荷分散 • S3、CloudFrontによる静的コンテンツのオフロード対応（EC2オートスケール対応の為） • リソース状況の監視、障害時の対応（即時ではないが、対応は必要）
- 23. パターン③：冗長化/リージョン間 23 想定要件 • ダウンタイムが許されない • イベントや時間帯によって突発的なアクセスが想定されるサイト • 日本国内リージョン障害時もサービス継続提供が必須（DR）
- 24. 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. パターン③：冗長化/リージョン間 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. パターン③：冗長化/リージョン間 26 想定要件 • ダウンタイムが許されない • イベントや時間帯によって突発的なアクセスが想定されるサイト • 日本国内リージョン障害時もサービス継続提供が必須（DR） 要件担保の為、必要な施策 • リージョン内、リージョン間冗長化及びオートスケールによる負荷分散 • S3、Cloud Frontによる静的コンテンツのオフロード対応（EC2オートスケール対応の為） • Cloud Front、Global Acceleratorによるリージョン障害時の切替構成 • 必要に応じて、切替サイト先での冗長化、管理インスタンス構築
- 28. まとめ 28 • 「落ちない」定義を定める • コストとのトレードオフを考える • AWSの機能・制約を理解した上で、要件にあったパターンを構成 • 環境構成でカバー不可部分は、必要に応じて運用で対応 とは言え、インフラ設計・運用を抱えながら Webサイトの運営をするのは大変・・・
- 30. NHNテコラス マネージドクラウドサービス －30－ 国内外の主要クラウドを中心とした設計・構築・監視・運用を代行するマルチクラウド 対応のマネージドサービスです。 お客様ごとに構築要件や監視項目をカスタマイズし、パターンに囚われない柔軟な対応 が可能です。 提案・設計 詳細設計・構築 移行支援 監視・運用 24/365サポート 障害対応 お客様の要件をヒアリ ングし、サービス用途 に合わせて設計します。 弊社のエンジニアが、 豊富な経験と知識を活 かし、環境を構築しま す。 オペレーターではなく 弊社SEで構成された MSPチームが直接監視 運用を行う為、迅速な 対応を実現します お客様の止められない システムを24時間365 日有人監視し続けます。 障害検知時には、迅速 に弊社MSPチームより お客様へ通知を行い、 一次切り分けや障害対 応を行います。 監視・運用初期構築 担当営業 ITアーキテクト 専属エンジニア MSPチーム
Notes de l'éditeur
- 「落ちないAWSのインフラ構成、システム要件に合わせたパターンを紹介」ということで、 WordPressをAWSで構築する際に「落ちない」ことを考慮した構成を想定するパターンとともに紹介していきますので おつきあいください。
- 自己紹介
- 本日のアジェンダとなります。
- AWSを知っている方いらっしゃいますでしょうか？－－－ すでに利用されている方いらっしゃいますでしょうかーー ありがとうございます。 ご存知だとは思いますがAWSについて簡単に紹介いたします。
- では早速本題に入っていきたいと思います。 まず「落ちない」の定義を考えたいと思います。
- 落ちない！と一言で言っても、さまざまな定義や条件によってと捉え方が異なってくると思います。
- ダウンタイムは許容されるのか アクセス集中を考慮しなければならないか どの規模までを担保すればよいのか など、Webサイトの規模とサービス要件によって様々な「落ちない」要件を考え、インフラ構成に落とし込んでいく必要があります。
- 「落ちない」要件を極めれば、どこまでもリッチな構成をつくっていくことはできます。 ですが、コストとリスクのトレードオフとなることを考慮しなければなりません。 コストをどこまでかけれるのか（かけたくないのか）、そこまでの要件は必要ないのか。 今回は４つの「落ちない」要件別に構成を紹介していきます。
- それぞれ、下からパターン０の最小構成 基本構成として、パターン１のリージョン内の冗長化 アクセス急増に耐える、パターン２のスパイク負荷対応 そして、最後にDRの観点も含めた、パターン３のリージョン間の冗長化について話していきます
- EC2 1台の最小構成となります
- 想定要件を担保する為には迅速な復旧が必要となります。
- ではここから