Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

393 views

Published on

WordPressをAWSで構築する際に「落ちない」ことを考慮した構成を想定するパターンとともに紹介していきます。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

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

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

×