AWS EC2メール送信制限にハマりそうになったので書く

AWSのEC2インスタンスから外部のメールサーバを使ってメール送信する機能を含むアプリを構築していたときの備忘録。
デプロイし終わって簡単に送信テストを行なって疎通OK、いざ本番移行前のテストでデータ作って送信しようとしてみたところ、
メールサーバとのコネクションタイムアウトで失敗する。
全滅するわけでなく、何回かに一回は成功。
telnetで直接会話してみるもタイムアウト、ときどき成功。

ググったら基本中の基本のようで...

EC2からメール送出するなら先に申請しておくんだ！！
http://il-all.blogspot.jp/2012/03/ec2.html

どうやらEC2インスタンスの外にSMTPサーバに対して数十回メール送信すると、制限がかかってしまうとのこと。
解決策は以下

  1. SMTPポート(25)をやめて、Submissionポート(587など）でメールを送信するようにする
  2. AWSサポートページからメール送出上限解除の申請を行う
  3. SES(SimpleEmailService)を使う

のいずれか。
スパムサーバ避けなんですね。
メール送出上限解除の申請は、通常１、２営業日かかるんだそう。作業が深夜だったこともあり、ビジネスサポートに泣きついて、
特急でやってもらいました。
でもよく考えてみたらSubmissionポートあければいいじゃん、ということで急遽qmailをメンテして事なきを得ました。
サポートに相談したところ、25番ポート以外は特に制限していないとのことでした。

OSX(Lion)で、VirtualDocumentRoot を設定したのでメモ

WEBアプリケーションを開発するとき、localhost:8080とかlocalhost:9000とかで頑張っていたんですが、
進行中の開発モノと、メンテナンス中のサイトを交互に作業してると、URLの切替が段々うざったくなってきたんで、
ホスト名だけですっきりブラウズ出来るようにしたくなってきました。

http://hoge.localhost　とか　http://fuga.localhost
をサーバの再起動なくブラウザでアクセスしたい、というのがゴール

参考にしたところ
http://d.hatena.ne.jp/y-kawaz/20110725/1311610727:VirtualDocumentRootを使って複数ドメインをスッキリ管理（Apache）

１．apacheの設定変更
１）httpd.confを編集。
httpd-vhosts.confを有効にするため、以下の行のコメントを外します。
> sudo vi /etc/apache2/httpd.conf

# Virtual hosts
Include /private/etc/apache2/extra/httpd-vhosts.conf

２）httpd-vhosts.confを編集。
既存のexampleはコメントアウトします。
>sudo vi /etc/apache2/extra/httpd.conf

#
# ServerAdmin webmaster@dummy-host.example.com
# DocumentRoot "/usr/docs/dummy-host.example.com"
# ServerName dummy-host.example.com
# ServerAlias www.dummy-host.example.com
# ErrorLog "/private/var/log/apache2/dummy-host.example.com-error_log"
# CustomLog "/private/var/log/apache2/dummy-host.example.com-access_log" common
#

#
# ServerAdmin webmaster@dummy-host2.example.com
# DocumentRoot "/usr/docs/dummy-host2.example.com"
# ServerName dummy-host2.example.com
# ErrorLog "/private/var/log/apache2/dummy-host2.example.com-error_log"
# CustomLog "/private/var/log/apache2/dummy-host2.example.com-access_log" common
#

で以下を追加して最終的に以下に

NameVirtualHost *:80

ServerName *
VirtualDocumentRoot "/Users/ksaka-ew/Vhosts/%0/htdocs"

Options All
AllowOverride All
Allow from all

３）apache再起動
>sudo apachectl restart

４）サイトに応じたディレクトリを作る
>mkdir -p /Users/ksaka-ew/Vhosts/hoge.localhost/htdocs
ディレクトリの配置場所はどこでもOKです。
hoge.localhostの部分はアクセスしたいホスト名を入れます。

２．ホスト名を引けるようにする
hoge.localhostを127.0.0.1で引きたい。
１）hostsに下記行書き加えてエントリを追加
>sudo /etc/hosts

127.0.0.1 hoge.localhost

２）DNSキャッシュをクリアしてhostsを読込み
>dscacheutil -flushcache

これで終わりです。
/Users/ksaka-ew/Vhosts/hoge.localhost/htdocsの下にindex.htmlを置くなどして
>curl hoge.localhost
とやるなり、ブラウザで http://hoge.localhost/index.html にアクセスしてみてください。

Magento Cafe Tokyo #３にいってきた(2012-03-17)

いつものごとくメモ漏れ、勘違いご容赦ください。

Magentoケーススタディ(フロントエンド・バックエンド編)

西　宏和氏‏ @hirokazu1225

  • カテゴリを作ってもナビにでない
    • ルートカテゴリとサブカテゴリを理解しよう
      • １つのショップに複数のルートカテゴリを登録できる
      • 有効フラグ-Off、カテゴリに登録しないOnになってない？

  • 商品を登録したのに表示されない
    • 商品と在庫の関係を理解しよう
      • 在庫フラグと在庫数は別
      • 表示対象ー＞検索、カテゴリ
      • 有効フラグ-Offになってない？
  • カテゴリに商品が出ない
    • 商品とカテゴリ・サイトの関係を理解しよう
    • 特にマルチサイトのとき
      • 表示させるサイトの選択
      • サイトのカテゴリ
      • ※マルチサイトの場合、登録したサイトからしか会員ログインできない
        • フロントから登録後管理画面から設定できない
  • 税の設定がよくわからない
    • 税区分と税率の関係を理解しよう
      • BtoCの場合は内税とすべき。楽チン。税金が変わっても商品価格を変えるだけ
      • BtoBの場合は会社ルールを考慮する必要あり。切り捨て、切り上げなどなど
        • Magentoでやるのはややこしい
      • 外国では品目や地域によって税率が異なることも多い
      • 出荷する地域や購入者の地域で課税するのかなどなど
  • デザインテーマの変え方がわからない
    • テンプレートとスキンの関係を理解しよう
      • デザイン
        • default/blankを使う。JSやCSSが最小限の状態ー＞これを変更するのが楽
      • 設定ー＞デザイン
      • パッケージやテーマを変更する
      • テンプレートとレイアウトは同じものを使うことが多い
      • レイアウトのみ変更（カスタマイズ）するのも手
      • 標準の動き。現在テーマにパーツがない場合、どこに戻るか設定する
base/default ←最後にはここを使う
default/default ↑ここをみて
default/iphone ←ここにないと
      • ※base/defaultをカスタマイズしているとバージョンアップしたときに巻き戻るなど
  • Magento Connectが動かない
    • サーバの環境と設定を再確認しよう
      • →Webサーバ実行ユーザがファイルの書き込みできていいの？
      • インストールに失敗することがある
      • ローカルないしテストサーバでダウンロードしておき、ファイルアップロードする方法を推奨
    • 手動でダウンロードするには。
      • downloader/.cacheの下にダウンロードされる
      • ただし、依存性がある場合は手動で修正する必要がある
      • だめなら、ソース読め
  • 配送料金表の登録方法がわからない
    • 設定画面のスコープを1段下げるとでてくる
      • 設定ー＞配送方法ー＞料金表→CSVでエクスポートしてからインポートする。
      • CSVにはロケールと料金が書き込める。CSVのロケールが合わないとだめ。英字表記注意
  • 住所表示の変更方法がわからない
    • 設定画面で変更可能
      • 設定ー＞顧客ー＞顧客設定→住所表記テンプレートを書き換える

  • 余計なバナーを消したい
    • layoutのcatalog.xmlを編集して削除
      • app/design/frontend/base/default/catalog.xml
  • エクステンションのインストールに失敗したらサイトが見れなくなった
    • Root/maintenance.flagを削除する！
      • index.php　53行に　メンテナンスファイルがあると503.phpを返すようになってる
  • エクステンションインストールしたのに設定画面にアクセスできない
    • 権限を保存しなおせばOK

  • Basic認証をかけたら画像をアップできなくなった
    • MagentoはFlashUploaderを使っているがBasic認証が通らない
    • NoFlashImageUploaderを使おう
      • ただし、CMS機能には非対応。複数コンテンツを同時アップロードできない
  • スマホだけで別のテーマで表示したい
    • UserAgentでテーマ切り替えする機能を利用するのが楽。ただし不完全
    • →キャッシュ使うとUserAgentでの切り替えができなかったり
    • →iOS、androidでもPCサイトが見るのは無理
    • →別々のサイトをつくってあげるほうが楽チン

  • ウェブサイトストア　ストアビューの住み替え
    • 同一サイト＝マルチストア
    • マルチサイト＝マルチストア（ドメインが変わってもOK、会員情報を完全にわけることができる)

Magentoケーススタディ(チューニング編)

株式会社フラッツCTO　天方氏

  • 背景
    • Magentoのパフォーマンスについての相談をうけた
    • リリース基準を満たせず、何度かあったリリース期日にリリースできない状態が続いていた
  • サイトの特徴
    • SKU数　約4500
      • 将来的には数十万件
  • 検索条件の軸が非常に多い
      • 商品に検索からはいる
    • スループット要件があった(25Request/Sec以上)
  • バージョン
    • Magento1.4.2
    • Apache2.2+mod_php
    • PHP5.2x+APC
    • MySQL5.1
  • ハード構成
  • サーバスペック
    • ロードバランサ（DNSラウンドロビン）
    • WEBサーバx3　仮想サーバXeon2.4G
    • DBマスタ（更新系）　仮想サーバｘ１Xeon2.4G Mem8GB
    • DBスレーブｘ３（検索系はWEBサーバ：DBスレーブ＝１：１） 物理サーバx2 i3 16GB、仮想サーバ--x1 Xeon2.4 8GB

  • パフォーマンス測定（改善前）
    • 22-24req/sec(トップページ、商品検索、空ページ）
    • abコマンドで測定
  • 問題点
    • request/secの目標値の２５以上に届いていない
    • ページの表示が遅い
    • クエリキャッシュが効いての数字。効かないとさらに遅い
  • DBマスタの設定を変更する
    • my.cnf

key_buffer=512m ->16m
innodb_buffer_pool_size=768m->4G (DBスレーブは10GB)
など

  • その他
    • テーブルが一部MyISAMになってえいるのをInnoDBにした
    • 複数のエンジンを使うとメモリを多く消費する
  • 結果
    • ほとんど変わらない。。。
  • 再調査
    • CPU負荷
      • DBマスタの負荷が４００％いっぱいいっぱい
    • mysql-slow.logを確認
      • Insert・Updateで詰まってる
    • もしかしてDBマスタの更新系トランザクションの性能限界？
      • セッション情報をDBに更新していた。ー＞DBマスタへの負荷で一杯
  • Memcache設定
    • app/etc/local.xmlに追加する
  • Webサーバの一台にmemcacheを設定して他のWebサーバから共有した
  • 結果
    • 32-36req/sec(速くなった。要件クリア）
    • （クエリキャッシュが効いている状態）
  • 検索ページはクエリキャッシュが効く前
    • 0.26req/sec
    • ApacheSolrなど入れる必要あるかも
  • 課題
  • 検索
    • 検索クエリの最適化
      • ApacheSolr組み込み
    • 総合対策
      • MagentoCE1.6へ変更（パフォーマンス向上する）
      • MagentoEnterpriseEdition変更（劇的に向上する）
  • 教訓
    • セッションをDB管理する場合は、DBマスタのトランザクション性能に気をつける
    • Magentoの標準は日本語検索弱い。日本語検索はApacheSolrを使うなど
    • PHPは5.3のほうが速い　ZendServer CE PHP5.3+APCも考慮
    • MySQL５．５のトランザクション性能が高い
    • 複数WEBサーバの場合、画像NFSを使うこともあるがWEBサーバに画像をおいてrsync同期とかCDN導入するなど
    • MagentoEEの導入
      • 本家のMagentoCEとEEの性能比較のPDFを見てみると良い*1
      • EE１ライセンス１００万/年ぐらい。CE４０インスタンスで使っている事例あり。EEなら数台になるかも
    • ログ取得を有効にしているとページみるごとに１Insert走る。PVを置いと一日でGB超える（上記では無効にしてた）
      • cf.AWS EC2ラージインスタンスで実測。MagentoEE 100req/sec、MagentoCE 12req/secぐらい
      • メモリは最低４GB。APCでキャッシュするならMemoryほしい。管理画面が遅い
      • APCのキャッシュをMagentoのキャッシュ置き場として使う。
    • ROOT/.htaccessにJS,CSSはキャッシュするように設定。ただしCDN使う場合はダメ
    • エクステンションを使うなど*2
      • セッション情報の保存に、当初memcacheを使っていたが、ロードバランサでセッションが切れる問題があった
      • →WEBサーバごとに独立したmemcacheを設定していた

Magentoケーススタディ(カスタマイズ編)

西　宏和氏‏ @hirokazu1225

  • default/blankを複製してカスタマイズ
    • 余計な装飾がない
    • バージョンのあわないテーマを導入すると壊れることがある。
    • アップデートすると問題が発生することがある
  • エクステンションの競合
    • rewriteは１回しかできない
    • エクステンションAとエクステンションBが同じクラスを拡張している場合、どちらかしか使われない
    • クラスの継承関係は自動で解決しない
      • コードを読んで自力で調整

  • インデックスが更新できない
    • ゴミデータがどこかにある(外部キー張ってるのに)→データベースをみて解決するしか
    • Magentoのシステムログをみて解決する
    • インデックスが更新できないとURLが更新できない
    • 「商品とカテゴリとURL書き換えインデックス」「EAVカテゴリストラクチャをflatstructureに変換したインデックス」でよく起きる
      • →DBを見るか、プログラム追いかけるか

  • データが大きすぎるとApacheやPHPがタイムアウトする
    • 商品点数が５万件超えてくると起きる。
    • shell/indexer.phpを実行する
      • →但しファイルのパーミッションがWEB実行ユーザ以外で実行するとオーナーが不適切になることがある
  • 商品登録でエラーがでる
    • カスタムオプション周りでエラーが出ることがある
    • 下記あたりにゴミがある。

catalog_product_option
catalog_product_option_title
catalog_product_option_type_price
catalog_product_option_type_title
catalog_product_option_type_value

  • バージョンを上げたいんだけど
    • coreいじってないですか？

base/default
default/default
default/modern
default/blank
default/iphoneあたり

  • いれてるエクステンションは最新ですか？
    • 有料の場合は、買い直すなど
    • 無料の場合は、バージョンアップに対応してないなど
  • OK?じゃあテスト環境でテスト
    • ２回目からはきっとスムーズにできるよ

QAコーナー

Q.osCommerceからの乗せ換えをしたいが、どのパッケージを選べばいいの？

  • Magentoは、eBayの資本がはいって、コミュニティの窓口として位置づけられている。すぐに開発が停まることはない。
  • ZenCartは、バージョンアップ停滞。中の人も現状で満足してる（？）
  • EC-Cubeは箱をあけたらすぐ使える。小型店舗向け。ベトナムやUSに展開といっているが???? 今後もコアには手を入れない方針。再設計はちょっとありえない。多言語対応、ダウンロード販売は無理。

Q.多言語化やダウンロード販売をしたいが？

Q.材質や大きさなどと細かく入力して注文するフォームは可能？

Q.CMSとの連携エクステンションっていいのある？

  • 単純にリンクさせるタイプと、MagentoのAPIを呼び出すリッチタイプとがある。typo3はWordPress連携リッチタイプ、ただし重い。Joomla!やDrupalの連携エクステンションもあり。

*1: http://www.magentocommerce.com/knowledge-base/entry/magento-zend-server-benchmarks あたりも

*2: Lightspeed Full Page Caching(http://www.magentocommerce.com/magento-connect/lightspeed-full-page-caching.html)

JAWS-UG Summit2012にいってきた　(2012-03-03)第二日目 その４

上司にAWS利用を承認させる３つの方法 (クラウドワークス 大石氏)

  • 目的
    • せっかく勉強会に来ているんだから、ネットや本で勉強できないことを知りたい！
    • AWSを勉強しても、仕事で使わないと身につかない
  • クラウドワークス社では
    • 2007年　導入開始
    • 2008年　社内サーバ購入禁止
    • 2010年　全開発サーバがAWSに
  • 上司が貼る典型的な３つのネガキャン
    1. セキュリティは？
    2. 事例は？
    3. コストは青天井なんでしょ？
  1. セキュリティ
    • よくある誤解：クラウドってセキュリティが不安
    • 一般的あシステムの脅威：
    • 外部：攻撃者のアタック、データ漏洩（アクセス権の設定ミス）
    • 内部：データの盗難
  1. 場所がわからない？
    • 仮想マシン同士が情報を意図せず共有しているのでは？
    • Amazonの内部セキュリティ
      • セキュリティの第三者認証
      • 場所は明かさない、見学させない
      • 特許技術によるXenの拡張
        • 同一物理サーバに存在する仮想マシン同士がファイル共有しない特許技術をもってる
    • 外部は利用者がアプリケーションと設定で防御
    • 内部はAWSが防御
  1. 上司に逆質問
    1. 会社存続に、不可欠なものは？
    2. ...(書ききれなかった)
    • 答え:お金
  1. なぜ大切なお金を銀行に預けるのか？
    • セキュリティ
    • 可用性
      • 預けた支店が事故を起こしても口座情報は保持
    • 利便性
      • ATMカードでどこからでもアクセス
  1. クラウドも銀行と同じ
    • セキュリティ
      • データ盗難は８０％が内部犯行。
    • 可用性
      • バックアップやフェイルオーバー
    • 利便性
      • インターネット越しにどこからでもアクセス
  1. 事例(日本赤十字社)
    • 震災時サーバがダウンした。被災者、ボランティア
    • AWS EC2とCloudFrontでキャッシュした。→以降ダウンしなくなった
    • 義援金募集システム→環境構築２時間、システム開発４８時間
      • ３・１４ダウン・打ち合わせ
      • ３・１５サイト復旧
      • ３・１６義援金募集システム開始
    • 事実
      • 震災後の迅速な義援金の募集にAWSが役立った。
  1. 料金が青天井？
    • 転送量200GB $40
      • 転送量は料金の最大２５％を占める程度
    • AWS方向へのトラフィックは無料
      • そもそもサーバのスペックを超えるアウトバウンドは発生しない
      • →それ以上はサーバが負荷に耐えられない
    • 国内クラウドとの比較
      • CPUや料金が安い
      • 比較対象はAWS EC2サービスのみ。AWSは圧倒的なサービス群に追随できていない
    • EC2相当のサービスを使った場合
      • インスタンスを複数台立ち上げて、AWSサービス同等のソフトをインストールして構築する必要がある
      • AWSではインストール時間不要、サーバの台数が減る
      • 総合的コストやセットアップ時間や運用の手間が安い・短い

JAWS-UG Summit2012にいってきた　(2012-03-03)第二日目 その３

RIAとクラウド (横田氏　classmethod代表取締役）

  1. 時間がないのでRIAの話はしませんw
  1. なぜUIとサーバ側をわけるのか？
    • UI側：増え続けるクライアント、画面サイズに合わせた情報量
    • ライフサイクルの違いをAPIで吸収
    • サーバ側：データ構造やロジックの定義には時間がかかるが変化は少ない。応答スピードの対応が必要
  1. 良いレスポンスのために
    • サービスを止めない
    • EC2,ELB,AutoScaling,CloudWatch,RDSなど
    • ボトルネックを解消する
    • リクエスト数を減らす、ディスクIOを減らす、DBアクセスを減らす
  1. リクエスト数を減らす1
    • ファイルをまとめる
    • CSS/JSをひとつにする
    • CSSの画像スライスで１ファイルにする
    • 適切な場所に配置
    • HTMLの上部にCSS、下部にJSを配置
    • 静的HTMLにCSS・JSを書かない
    • JSライブラリを非同期に読み込む
    • 静的ファイルをすべてEBS上に置く
    • HTML、CSS,JS、画像、動画、大容量ファイルなどはS3かCloudFrontにおくことでEC2へのリクエストが減る
    • 多くの場合、ELBを併せて使っているのでELBへの負荷が減る
  1. リクエスト数を減らす２
    • S3に静的ファイルを置くとき
    • HTML/CSS/JSはgzip圧縮する
    • 画像はExpires　Cache-Controlを長めに設定
    • S3とCloudFrontどっちに置く
    • S3はストレージサービス。長期保存用
    • 東京リージョンに置けばそこそこスピードが出るが高速にデータをダウンロードしたければCloudFront
    • アクセス制限を付与したい場合は、S3
    • 認証つきURLならCloudFront/S3
    • CloudFrontのエッジロケーションが大阪にもできた
    • ネットワーク遅延を解消するため高価が大きい
    • CloudFrontはS3 Originヘッダを引き継ぐためキャッシュや圧縮が有効であれば引き継ぐ。コスト面のメリット大きい
  1. S3/CloudFrontへの配備
    • 手作業はめんどくさい
    • キャッシュ設定
    • Gzip圧縮
    • アップロード
    • 公開設定
    • アクセス制限
    • ビルドツールの活用
      • ant
      • S3Cmd
      • S3Sync
  1. リクエス数を減らす３
    • Webサーバで自動生成されるページのHTMLを修正できない場合
    • Apache/nginx等のUriRewriteを使って３０４転送
    • すべて静的なWebページの場合
    • ColudFrontのカスタムOriginを設定する
    • Route53のIPアドレス変更の浸透は数秒オーダー
    • TTLを短く設定するなど
  1. ディスクIOを減らす１
    • EC2とEBSはネットワークで接続されている
    • インスタンスサイズが大きいと割り当てられるネットワーク帯域が太くなる（SmallよりLargeが太い）
    • ネットワーク帯域をたくさん使ってしまうと応答が遅くなる
    • EBSはディスクなのでIOが大量に発生すると遅くなる
      • ログを大量に出力するとIOが大量発生
    • サービス系は常にカイゼンのために本番系でもデバッグログを出力していることもよくある
    • ディスクへの書き込みを減らす
    • ログはログサーバ（Fluentd等）を利用
    • ディスクアクセスを高速化したい場合
      • 大きいEC2インスタンスを使う
      • RAID0を組む
        • ２つのEBSボリュームをマウント
        • MdadmでRAID0化
    • EBSを使わずにEphemeral Disk を使う（EC２のローカル）
  1. DBアクセスを減らす2
    • とりあえず負荷を減らす
    • リードレプリカを用いる
      • 検索・更新を分ける
    • シャーディングする
    • DBに何でも入れてしまう傾向
    • DBのIO減らしてAWSのサービスを利用
    • SPOFの無いAWSサービス群
    • サービスそのものが高可用性.DynamoDB,SimpleDBなど
    • DBへの問い合わせ回数を減らす
      • キャッシュ機構を使う.ElasticCache
      • データベースにRDBMSを使わない
      • DynamoDB、SimpleDB
    • 操作ログや履歴はファイルへ.S3の利用

JAWS-UG Summit2012にいってきた　(2012-03-03)第二日目 その２

ここからはパターン実践編。仮想シナリオをもとにパターン適用していきます。

クラウドデザインパターン コンテンツ配信編 (Amazon 片山氏 @c9katayama)

  1. シナリオ
    1. 雲の写真を載せるブログサイト開始
    2. はじめは個人的に開始
    3. 動画や過去画像集も公開
    4. まさかの大人気
    5. まさかの海外展開
  1. ブログサイトの開始
  1. 動画・過去画像集を公開
    1. 課題
      • サイズが大きく、ダウンロード負荷の高いコンテンツの配信
      • EC2のスケールアップ・アウトが費用がかかる
      • データ容量は未知数
    1. そこで「WebStorageパターン」ですよ
      • アクセス不可の高い動画や画像コンテンツをS3に逃すパターン
      • S3のDNS名をCNAMEに登録して仕様
      • S3のWEBサーバ機能を利用
      • EC2を複数立てるより安価
    1. パターン適用
  1. まさかの大人気
    • アクセス増加によりアクセスできない状況に
    • EC2やELB導入は費用がかかる
  1. そこで「DirectHostingパターン」ですよ
    • HTML、画像、CSSなど静的コンテンツをすべてS3でホスティング
    • EC2はコンテンツ更新とコメント投稿や動的ページだけで使用
    • JSONPを使用し、EC2から表示用の差分データだけを取得して画面更新する方法も可能
  1. パターン適用
    • MTで生成したファイルをすべてS3へ定期保存
    • サイトのメインDNSをS3へ割り当て、訪問者はS3へ
  1. S3マウントのソリューション
    • S3へデータコピーするOSSを利用する
    • S3FSなど
  1. まさかの海外展開
    1. 課題
      • 海外のマニアがサイト発見
      • 海外の有名ニュースサイトへの掲載が決定
      • 掲載までに海外の対応を行う
    1. そこで「Cache　Distributionパターン」ですよ
      • ユーザに近い場所からの配信
      • 世界各地のエッジサーバを利用し、オリジンサーバのコンテンツをキャッシング
      • AmazonCloudFrontを利用
    1. パターンの適用
      • ３つのサブドメインを利用
      • ブログコンテンツ（www)、動画・画像(data)、コンテンツ管理コメント投稿(mt)
      • S3から配信するデータは、S3のファイルをCloudFrontへ展開
      • メインコンテンツをS3＋CloudFrontにしたので更新が遅い（最大１時間など）
      • CloudFrontへの初回アクセスは遅い。更新後、バッチでクロールしておくなど
  1. 最終型
    • コンテンツ＝S3
    • 画像・動画＝CloudFront＋S3
    • Blog投稿＝EC2
  1. 重要なのは、最初だけでなく周期的なカイゼン

クラウドデザインパターンEC編 (玉川氏)

  1. シナリオ
    • 雲グッズ販売サイト開始
    • ECサイトをとりあげ「可用性」「耐障害性」を高めるパターンを中心にQWSを使用した実装方法を解説
  1. 初期
  1. FloatingIPパターン
    1. 課題
    • 利用ソフトのバージョンアップが必要
    • テスト環境でバージョンアップし、懸賞して、本番環境とのIPアドレス入れ替えを行う
    1. 解決
      • EIPでサーバに静的IPを振って、切り替える。Route53を使えばDNSの伝播は一瞬
  1. Server Swappingパターン
    1. 課題
      • サーバに障害が発生して、速やかに復旧したい
      • 以前取得したマシンイメージを元に仮想サーバをたてる
      • （壊れた）本番環境の最新データを持つディスクを移行して、復旧する
    2. 解決
  1. Multi-Serverパターン
    1. 課題：
      • Webサーバが落ちてもシステム全体で稼働し続けるようにしたい
      • Multi-Serverパターンを適用し、Webサーバを冗長化する
    2. 解決
      • ロードバランサ（ELB)
      • WEBサーバ（EC2)ｘ２の冗長構造
      • DBサーバ（RDS）
      • の３層構造にする。

RDSとは,クラウド上でのRDBMSサービス.作成が簡単

    1. パターンの適用
      • DBデータをダンプする
      • 作成したRDSのDBインスタンスにインポートする
      • ECCudeのデータベースの接続情報をRDSに書き換える
      • ロードバランサの起動
        • ECCUBEでSSLをサポート、ELBでも対処可能だがECCUBEを使う。
        • ELBでもSSLの解除は可能。ELB-EC2間の通信は平文でも暗号でも対応できる
      • ヘルスチェックの設定
      • ELB配下にEC2を追加
      • 切り離しテストも可能
  1. DBReplicationパターンの適用
    1. 課題：
      • DB部分のSPOF(単一障害点)を解消したい
    2. 対応
      • RDSでマルチAZを設定。障害時に自動でスタンバイサーバのレプリカDBに切り替わる
  1. Multi-Datacenterパターンの適用
    1. 課題
      • サーバレベルだけでなくデータセンタレベルの障害にも対応できるようにする
    2. 対応
      • ロードバランサ以下のレイヤをマルチリージョンで設定する。
      • EC2から異なるリージョンのRDSへ接続は可能（遅延はある3-5ms）
  1. 最終型
    • ELB（ロードバランサ）
    • （異なるリージョン）のAZ(AbilityZone)にEC2-RDSを２台配置
    • RDSはMultiAZとして、一台をスタンバイとし、２台のEC2はメインサーバに接続する
  1. その他適用可能なパターン
    • Multi-Region
    • DeepHelthCheck

デザインパターン　キャンペーンサイト編（鈴木氏 cloudpack(iret社)　@suz_lab）

  1. シナリオ
    • ECサイトが大人気
    • さらなる販促のためのキャンペーンサイト
    • アクセス急増のため順次パターンを適用
    • WordPressを使用
  1. キャンペーンサイト解説
    • スモールスタート
    • EC2 1インスタンスで開始
    • EIPで静的IPを振って。Route53でDNSに登録
  1. CloneServerパターン
    • サーバのクローン
    • 現状のシステムを変更することなく容易にスケールアウト
    • マスタEC2がSPOF
    • ファイルアップロードなどはマスタで
    • マスタのAMIをEC２に展開。
      • ファイルはマスタにアップし、rsyncで定期的にスレーブに同期
    • クローン用AMIを作成
      • rsync/MySQLの調整
      • 起動したままAMIのスナップショットをとる
      • スレーブインスタンスをEC2で起動し、AMIを適用して、設定を調整
      • ELBを設定して負荷分散、マスタとスレーブを格納
  1. ScaleOutパターン
    • サーバ数の動的増減
    • 手動/Auto ScalingでAMIから起動
      • CloudWatchでしきい値監視し、AutoScalingを設定していて自動スケールアウト（EC2インスタンス起動、コンテンツ同期、ELB格納など）
    • ELBの利用を前提
    • ただし、急なトラフィック増には対応しきれない
  1. NFS Sharingパターン
    • 共有コンテンツの利用
    • リアルタイムで共有コンテンツを反映
    • 共有コンテンツを頻繁に変更
    • セットアップが容易
    • ただし、NFSサーバがSPOF
    • NFSでリアルタイム同期
  1. NFSReplicaパターン
    • 共有コンテンツの複製
    • NFS部分のパフォーマンス問題
    • ローカルディスクのコンテンツをコピー
    • NFSサーバが落ちていても読み取りは可能
    • 読み取りはローカルディスク(rsync) -> EBSよりも高速
    • 書き込みはNFS
    • 読み取り・書き込みのディレクトリを分けてシンボリックリンクで使い分ける
  1. Read Replicaパターン
    • 読み取り専用のDBを作成
    • 頻度の高い読み込みの複製
    • DBの読み取りクエリの負荷分散
    • データ解析用途で利用することも可能
    • 非同期レプリケーションになることを注意
    • HyperDB（WordPressプラグイン）で読み書きの分散
    • RDS化
    • WEBコンソールでRead専用レプリカを作成可能
    • その他MySQLProxyを使うなど
  • 課題：アクセスは静的コンテンツがほとんどだった！
  1. URLRewritingパターン
    • 静的コンテンツの退避
    • 静的コンテンツのアクセスをS3/CF(CloudFront)に
    • mod_ext_filterやNginxでURLの書き換え（WEBサーバ側で静的コンテンツのURLを書き換えてS3へ振る）
    • CloudFrontの場合は、コンテンツがキャッシュ

JAWS-UG Summit2012にいってきた　(2012-03-03)第二日目 その1

2日目はデザインパターン編に参加しました。AWSマイスターリターンズ編は、あとでここ読んで復習。次回はハンズオンに参加したいところ。

AWSクラウドデザインパターン概要編（玉川氏）

  1. AWSメリット
    • 瞬時のリソース調達、ピーク対応が楽
    • 広大なバックボーン、画像配信
    • 柔軟なリソース調整、
    • AWSにおまかせで運用が楽
  1. (AWSを使う上で貯まってきた)既存ノウハウを伝えたい（暗黙知→形式知）
  1. パターン例
    • FloatingIPパターン
      • サーバ障害時やパージョンアップ時に瞬時にサーバ切り替えを行いたい場合に利用
      • EIPの付け替えを行いサーバを切り替える
      • EIP（ElasticIP) 動的IPアドレス切り替え
    • CloneServerパターン
    • JobObserverパターン
    • 現在４５パターンある。あと３つ追加してCDP48にしたい
    • 他にもパターンがあれば、みなさんにもWiki編集して追加して欲しい
  1. パターンを活用した実装シナリオ
    • 画像動画配信サイト->MovableType
      • 大量のユーザに配信したい
    • ECサイトー＞ECCube
      • 可用性、耐障害性を高くしたい
    • キャンペーンサイトー＞WordPress
      • 突発性アクセス増加に耐えたい
  1. クラウドアーキテクティング原則
    • できるだけサービスを利用
    • 机上実験よりも実証実験
    • スモールスタートからスケールアウト
    • 変化に対し全レイヤで対処
    • 故障のための設計(Design for Failure)
    • 最初だけでなく周期的なカイゼン