• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
20120914 aws summit_lt
 

20120914 aws summit_lt

on

  • 2,113 views

 

Statistics

Views

Total Views
2,113
Views on SlideShare
732
Embed Views
1,381

Actions

Likes
0
Downloads
3
Comments
0

5 Embeds 1,381

http://blog.serverworks.co.jp 1355
http://www.newsblur.com 23
http://s.deeeki.com 1
http://cache.yahoofs.jp 1
http://translate.googleusercontent.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    20120914 aws summit_lt 20120914 aws summit_lt Presentation Transcript

    • VPCではじめるスケールアウトするインフラ構築株式会社シャノンPlatform Technology 藤倉 和明2012/9/14
    • 自己紹介 株式会社シャノン 藤倉 和明 インフラエンジニア - twitter : @fujya - facebook : http://www.facebook.com/k.fujya 好きなAWSのサービス: VPC 初めて触った時はクラウドサービスでここまで柔軟なネットワークが組 めるのか!と感動しました。 2
    • 自社紹介 株式会社シャノン 2000年創立 マーケティングプラットフォームというサービスをSaaS型で提供しています 見込み顧客管理システムです イベント・展示会・セミナー管理に強み 数万件のイベントで採用実績 主に企業のマーケティング部門で使っていただいています 導入企業様 3
    • マーケティングプラットフォームが抱えていた課題1,800,000,000 指数関数的に増え続けるサーバ負荷1,600,000,000 ・顧客数増1,400,000,000 ・既存顧客のデータ量増1,200,000,000 ・利用方法・機能の多様化 etc…1,000,000,000 800,000,000 600,000,000 許容値 400,000,000 許容値を超えたらサービス 200,000,000 停止の恐れあり 0 4
    • マーケティングプラットフォームが抱えていた課題 パート2※とある1日実際のサーバ負荷値(CPU時間の合計値/30分) ・ピーク負荷は1日のウチ10~30分程度 ・平常時と比べて約10倍の要求 オンプレミス環境のキャパシティ キャパシティを超えた負荷要求 = サービス停止の恐れ
    • マーケティングプラットフォームが抱えていた課題 サービスの成長に合わせてプラットフォー ムを拡張させる必要がある が物理的な限界がある サービスが落ちないようにピーク負荷に合 わせてプラットフォームを構築する必要が ある が普段は10倍ぐらい無駄がでる 6
    • 増える続ける負荷、スパイクする負荷・・・AWSで解決? AWSならボタン一つでサーバリソースの追 加できる スパイクする負荷にはスケールアウトで対 応まさに夢の様なプラットフォーム!これで全部解決!! でも・・・ 7
    • 今までの積み上げてきた資産・仕組みはどうする? 既存のハードウェア資産はどうする? 既に数百万~数千万の資産でサービスを構築している 様々なフレームが既に組んである バックアップ セキュリティ 冗長構成 既存のフレームと同等以上のサービスレベルは 保証しなければならない 移行コストがネックになる・・・ 8
    • やりたいこと既存の資産を活用しつつ瞬時にサーバリソースを一時的にだけ増やしたい それ、VPCならできるよ! って偉い人が言っていた 9
    • という訳で構築しましたオンプレミス環境 Amazon Web Services 監視サーバ ①APIで負荷を監視 ②負荷がしきい値を超えた ③指定したAMIで らインスタンスの起動のAPI インスタスを起動 コール VPNルータ ④定期的に負荷がし高負荷の時のみAWS側に きい値を下回って無サーバを効率良く起動 いかチェック 10
    • VPC導入までは約3ヶ月 導入期間:約3ヶ月 (工数は2人月程度) 社内に検証環境構築 AWSのAPIコールプログラムの開発 既存アプリケーションとの接続検証 本番ネットワーク構築 リリース! 11
    • 導入時にハマったポイント その1 なぜかやたら金が掛かる問題 (いわゆるクラウド破産) 気づいたら月額の利用料金が高額になっていた さらに新規インスタンスが起動できなくなっていた 原因 インスタンスの停止はTerminate → 追加EBSが削除されていなかった EBSの課金が凄いことになってた 対策 起動時にEBSにDeleteOnTerminateを指定する 12
    • 導入時にハマったポイント その2 ネットワークの問題 LANと同じ用途で利用するとパフォーマンスが思うように 出ない場合がある 原因 LANでのネットワークレイテンシ 0.1msec~0.2msec程度 インターネットVPNを超えるレイテンシ 5msec~15msec 1往復なら 大したこと無いけど100往復なら? LAN = 0.1秒~0.2秒 VPN = 5秒~15秒 対策 ネットワークを超える処理の回数を減らす 遅いことを許容する作りにする(非同期処理 等) 13
    • 導入時にハマったポイント その3 スケールアウトの上限値 簡単に何十台も起動できるから、たくさん起動させてみた ら一定の台数でアプリケーションエラーになった 原因 データベースのmax_connectionsの上限値まで使い切っ ていた 対策 上限値を設計し起動する台数を制御するように修正 14
    • 色々と乗り越えて導入の効果 パフォーマンス 約2倍! コスト 約75%削減! 15
    • まとめ VPCを使えば既存の資産を活用しつつ AWSのリソースが使えるようになる 移行ではなくattachするだけ 短期期間でオンプレミス環境がスケール アウトするプラットフォームに成長できる 高い費用対効果 結論:VPC最高! 16
    • おわり ご清聴ありがとうございましたイベント・セミナーでお困りの方は、AWSでスケールアウトできるマーケティングプラットフォームをヨロシクお願いします! 17