はじめに

下記に耐えたアプリインフラは、AWSでカジュアルに構築できた

  • 1つのAWSアカウントの中で、ひとつのアプリを動かす
  • 1日のPVはおおよそ1000万PV/Day
  • 1日のPV変動は激しく、多いときは、4万PV/min程度

どの辺がカジュアルかというと、エンジニア工数2日、サーバ費用も激安なところ

ネットワーク図とアーキテクチャ概要

ネットワーク図

アーキテクチャ個別詳細

ELB

  • CNAME by Route53
    • Route53は、AWSが提供するDNSサービス
  • ELB PreWarning
  • Not MultiAZ
  • Health Check

App

  • InstanceType
    • c1.xlarge
  • Disk
    • Data Volume : Ephemeral.
  • Running MiddleWare
    • Rails
    • Nginx
    • Passenger
      • CPUコア数を元にチューニングする(c1.xlargeのコア数は8)
    • NFS(Client)
  • Database Sharding

DB(Master)

  • InstanceType
    • m1.xLarge
  • InstanceOption
    • Launch as an EBS-Optimized instance
  • Storage Device
    • Data Volume : EBS.500G
  • Running MiddleWare
    • MySQL

DB(Slave)

  • InstanceType
    • m1.xLarge
  • InstanceOption
    • Launch as an EBS-Optimized instance
  • Storage Device
    • Data Volume : EBS.500G
  • Running MiddleWare
    • MySQL

DB(Backup)

  • InstanceType
    • m1.Large
  • Storage Device
    • Data Volume : EBS.500G
  • MySQL
    • mysqldump(hourly 3time,daily 30time)
      • dumpオプション、要チェック
    • push S3
  • S3cmd
  • パフォーマンスはあまり求められない。安全性重視のmysql optionでOK(innodbflushlogattrxcommit, syncbinlogなど)
  • バックアップポリシー
    • 1D分を30日分、4h毎を3日間

Code

  • InstanceType
    • m1.Large
  • Storage Device
    • Data Volume : EBS.200G
  • Running MiddleWare
    • Memcached
    • MySQL
    • NFS(Server)
      • AppよりReadOnlyでマウントされるため、logファイルなどは事前にシンボリックリンクに張り替えておく

Log

  • InstanceType
    • m1.Large
  • Storage Device
    • Data Volume : EBS.500G
  • Running MiddleWare
    • fluentd
    • mongodb

Instance 共通仕様

  • AMI
    • 全Instanceは、共通のAMIから起動している。
    • OSはAmazonLinux
    • Installed MiddleWare
      • MySQL
      • Rails
      • Nginx
      • Passenger
      • memcached
  • InstanceOption
    • Detailed Monitoring: True
    • Shutdown Behaviour: Stop
    • Termination Protection: True
  • 設定ファイル
    • 起動したInstanceは、githubから起動スクリプトをダウンロードする。その後、自分に設定されたTag情報を元に、任意のスクリプトを実行し、自身で設定を行う。
  • 起動Zone
    • 全てZoneA(但し、BackupサーバのみB)

監視対象

  • CloudWatch
    • ELB
      • Latency (Seconds)
      • RequestCount (Count)
      • UnHealthyHostCount (Count)
    • EC2
      • CPU
    • Billing
  • Nagios
    • Disk Usage
    • Memory Free
    • MySQL slow-queries
    • MySQL long-running-procs
    • MySQL table-lock-contention
    • MySQL slave-lag

リスクとなりうる要素の把握

SPOF (Single Point Of Failer)を理解し、不具合発生時の手順を確立しておく

  • ELB
    • 障害によるロスト
  • DNS
  • NFS
  • Master DB
  • EBS
  • バックアップファイルのリストアチェック

コスト管理

  • リザーブドインスタンス
    • 実際のサービスがリリースされ、ある程度長期的なリソースの予測が立てられる状況に落ち着き次第、購入を検討する
    • コストダウンを期待するために、理由が無い限り、Zone・Instance Typeは統一させることが望ましい。
  • 定期的に費用内訳を確認し、想定を超えるものがないか確認
  • うまくリソースを配置すれば、1ヶ月あたりXX万円という驚きの安さを実現できる。

運用で役立つツールの紹介

リリース前重点テスト事項

  • Master-Slaveのクエリが正しく分散されているか?
    • Master,Slave各々で下記tcpdumpコマンドで発行クエリをモニタリングする
  • BackupDumpは正常に行われているか?
    • データのリストアを定期的に実施する
  • タグ付け
    • Instance,Volume,EIPへ正しくタグ付けを行う

その他

  • リソースの上限解放申請を事前に行う
    • 初期アカウントでは、EIPは5,Instanceは20、EBSはXまでとなっている
  • 有料サポートの加入を検討する
  • Consolidate Billingで支払いをひとつのアカウントに集約する

調べること

  • Passenger,Nginx,MySQLは改善の余地有る
  • IOPSが、読み込みと書き込みどちらに効くのか、検証が必要


blog comments powered by Disqus

Categories

Tags

iPhone Sales

Books

Pinboard