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導入事例
JAWS-UG埼玉 第2回勉強会
2013/09/07
Kazuki Ueki
自己紹介
• 名前:植木 和樹(うえき かずき)
• 年齢:36歳
• 出身:新潟県妙高市(単身赴任中)
• 元製造業情報システムG常駐
• 主にUnixサーバエンジニア(監視、保守)
• 資格:IPAITサービスマネージャ
IPA システムア...
本日の内容
• 2部構成です
• 第1部「なぜインフラは複雑になるのか」
サーバ1台から始めて徐々に育てていきます
問題を提示して構成を変化させ徐々に複雑化して
いくシステムを見てもらいます
本日の内容
• 第2部「AWS導入事例」
実際の導入事例3件をご紹介します
AWSならではの柔軟さを知ってもらいます
昨今のインフラ技術もご紹介します
第1部 「なぜインフラは複雑になるのか」
キーワード
「データ保全」
「冗長化」
「負荷分散」
第1部の目的
「うわっインフラめんどくせっ」
と思っていただくこと
最小構成:サーバー1台
最小構成:サーバー1台
ハードディスクが壊れるとデータがなくなる
データ保全:ディスク冗長化(RAID)
複数のハードディスクに
同時に書き込む
データ保全:ディスク冗長化(RAID)
複数のハードディスクに
同時に書き込む
オペミスでデータを削除したらデータが消えてしまう
データ保全:バックアップ
データを別の媒体にも
コピーする
データ保全:バックアップ
データを別の媒体にも
コピーする
サーバ自体に障害が起きたらサービスが止まってしまう
冗長化:サーバ2台(コールドスタンバイ)
同じサーバを2台用意し
て故障したら切り替える
ネットワークケーブルを
つなぎ替える
接続している機器は手作業で
ケーブルをつなぎ替える
冗長化:サーバ2台(コールドスタンバイ)
同じサーバを2台用意し
て故障したら切り替える
ネットワークケーブルを
つなぎ替える
接続している機器は手作業で
ケーブルをつなぎ替えるダウンタイムが長い
切り替えに人手が必要
冗長化:サーバ2台(ホットスタンバイ)
同じサーバを2台用意し
て故障したら「自動で」
切り替える
仮想的なIPアドレスを使って
接続先を切り替える
(クラスタソフト導入)
ネットワーク越しにバックアップ
冗長化:サーバ2台(ホットスタンバイ)
同じサーバを2台用意し
て故障したら「自動で」
切り替える
仮想的なIPアドレスを使って
接続先を切り替える
(クラスタソフト導入)
ネットワーク越しにバックアップ
1台の処理性能に限界
(高性能サーバー...
負荷分散:APとDBをわける
APサーバとDBサーバを
分けて必要な性能を低く
おさえる
APとDBで必要な性能が異なるため
適した製品を選択しをコスト削減
AP、DB、Backupの
ネットワークをより
高速なものに
負荷分散:APとDBをわける
APサーバとDBサーバを
分けて必要な性能を低く
おさえる
APとDBで必要な性能が異なるため
適した製品を選択しをコスト削減
AP、DB、Backupの
ネットワークをより
高速なものに
APサーバーの待機系が稼...
負荷分散:ロードバランサー
ロードバランサを入れて
リクエストを振り分ける ロードバランサーで処理を分散する
セッションデータを
キャッシュで共有
負荷分散:ロードバランサー
ロードバランサを入れて
リクエストを振り分ける ロードバランサーで処理を分散する
セッションデータを
キャッシュで共有
JavaScriptやCSS、画像、動画など静的なコンテンツの
配信負荷、データ転送量をおさえたい
負荷分散:CDN(Contents Distribution Network)
静的コンテンツをより
ユーザーに近い場所から
配信し転送コストをさげ
る
一度読み込んだコンテンツを
キャッシュする
負荷分散:CDN(Contents Distribution Network)
静的コンテンツをより
ユーザーに近い場所から
配信し転送コストをさげ
る
一度読み込んだコンテンツを
キャッシュする
ひとまずここまででデータ保全がなされ
可用性が...
「インフラめんどくせっ」
と思っていただけましたか?
さらに、それぞれの構成要素を
要件に応じて
選択する作業があります(泣)
説明では省略しましたがこんなことも考えながらハードウェアを選定します
• 価格、コスト(重要)
• メーカーの保守(平日日中 or 24x365 オンサイト)
• 3年後5年後に必要となるディスク容量
• ハードウェアで目的のOSが動作するか
...
コストのバランスも考えます
導入コスト
運用コスト保守コスト
良い物を選ぶと高くなる
手作業が多いと高くなる故障が多いと高くなる
その他:サーバーを安定して運用するために必要なもの
ネットワーク 電源、UPS
空調、ラック
http://ja.community.dell.com/techcenter/b/weblog/archive/2011/11/11/dell-up...
調達~設置までの期間
OSインストール(2~3時間)
デバイス認識(1~2時間)
ラッキング(3人掛かり)
調達(2~3週間)
発注
【想像してみてください】
このシステムが
あと2つ3つ必要になったら・・・
第1部 完
「うわっインフラめんどくせっ」
と思っていただければ目的達成
でもAWSなら
たった1日で用意できる
あとから見直せる
Amazon Web Services の良いところ
構成を後から変えられる
調達の早さ
ハードウェアを気にしなくて良い
いつでもやめられる
第2部「AWS導入事例」
第2部の目的
「柔軟性」
を感じていただくこと
お客様からWeb掲載の承諾を得ていないので
第二部 資料はJAWS-UG埼玉勉強会 当日
限定の資料とさせていただきました。
ご了承ください
(編集が面倒って理由じゃないんだからねっ)
ご清聴ありがとうございました
classmethod.jp 36
Upcoming SlideShare
Loading in …5
×

20130907 JAWS-UG saitama#2 case_study

1,485 views

Published on

2013.09.07 JAWS Saitama #2
CaseStudy Part1.

  • Be the first to comment

20130907 JAWS-UG saitama#2 case_study

  1. 1. AWS導入事例 JAWS-UG埼玉 第2回勉強会 2013/09/07 Kazuki Ueki
  2. 2. 自己紹介 • 名前:植木 和樹(うえき かずき) • 年齢:36歳 • 出身:新潟県妙高市(単身赴任中) • 元製造業情報システムG常駐 • 主にUnixサーバエンジニア(監視、保守) • 資格:IPAITサービスマネージャ IPA システムアーキテクト • JAWS北陸コアメンバー(JAWS DAYS 2013~) • JAWS埼玉コアメンバー(2013年8月~) • 好きなAWSサービス:SQS classmethod.jp 2 @czkuk
  3. 3. 本日の内容 • 2部構成です • 第1部「なぜインフラは複雑になるのか」 サーバ1台から始めて徐々に育てていきます 問題を提示して構成を変化させ徐々に複雑化して いくシステムを見てもらいます
  4. 4. 本日の内容 • 第2部「AWS導入事例」 実際の導入事例3件をご紹介します AWSならではの柔軟さを知ってもらいます 昨今のインフラ技術もご紹介します
  5. 5. 第1部 「なぜインフラは複雑になるのか」 キーワード 「データ保全」 「冗長化」 「負荷分散」
  6. 6. 第1部の目的 「うわっインフラめんどくせっ」 と思っていただくこと
  7. 7. 最小構成:サーバー1台
  8. 8. 最小構成:サーバー1台 ハードディスクが壊れるとデータがなくなる
  9. 9. データ保全:ディスク冗長化(RAID) 複数のハードディスクに 同時に書き込む
  10. 10. データ保全:ディスク冗長化(RAID) 複数のハードディスクに 同時に書き込む オペミスでデータを削除したらデータが消えてしまう
  11. 11. データ保全:バックアップ データを別の媒体にも コピーする
  12. 12. データ保全:バックアップ データを別の媒体にも コピーする サーバ自体に障害が起きたらサービスが止まってしまう
  13. 13. 冗長化:サーバ2台(コールドスタンバイ) 同じサーバを2台用意し て故障したら切り替える ネットワークケーブルを つなぎ替える 接続している機器は手作業で ケーブルをつなぎ替える
  14. 14. 冗長化:サーバ2台(コールドスタンバイ) 同じサーバを2台用意し て故障したら切り替える ネットワークケーブルを つなぎ替える 接続している機器は手作業で ケーブルをつなぎ替えるダウンタイムが長い 切り替えに人手が必要
  15. 15. 冗長化:サーバ2台(ホットスタンバイ) 同じサーバを2台用意し て故障したら「自動で」 切り替える 仮想的なIPアドレスを使って 接続先を切り替える (クラスタソフト導入) ネットワーク越しにバックアップ
  16. 16. 冗長化:サーバ2台(ホットスタンバイ) 同じサーバを2台用意し て故障したら「自動で」 切り替える 仮想的なIPアドレスを使って 接続先を切り替える (クラスタソフト導入) ネットワーク越しにバックアップ 1台の処理性能に限界 (高性能サーバーは高額)
  17. 17. 負荷分散:APとDBをわける APサーバとDBサーバを 分けて必要な性能を低く おさえる APとDBで必要な性能が異なるため 適した製品を選択しをコスト削減 AP、DB、Backupの ネットワークをより 高速なものに
  18. 18. 負荷分散:APとDBをわける APサーバとDBサーバを 分けて必要な性能を低く おさえる APとDBで必要な性能が異なるため 適した製品を選択しをコスト削減 AP、DB、Backupの ネットワークをより 高速なものに APサーバーの待機系が稼働していないのはもったいない
  19. 19. 負荷分散:ロードバランサー ロードバランサを入れて リクエストを振り分ける ロードバランサーで処理を分散する セッションデータを キャッシュで共有
  20. 20. 負荷分散:ロードバランサー ロードバランサを入れて リクエストを振り分ける ロードバランサーで処理を分散する セッションデータを キャッシュで共有 JavaScriptやCSS、画像、動画など静的なコンテンツの 配信負荷、データ転送量をおさえたい
  21. 21. 負荷分散:CDN(Contents Distribution Network) 静的コンテンツをより ユーザーに近い場所から 配信し転送コストをさげ る 一度読み込んだコンテンツを キャッシュする
  22. 22. 負荷分散:CDN(Contents Distribution Network) 静的コンテンツをより ユーザーに近い場所から 配信し転送コストをさげ る 一度読み込んだコンテンツを キャッシュする ひとまずここまででデータ保全がなされ 可用性が高いシステムができたといえます
  23. 23. 「インフラめんどくせっ」 と思っていただけましたか?
  24. 24. さらに、それぞれの構成要素を 要件に応じて 選択する作業があります(泣)
  25. 25. 説明では省略しましたがこんなことも考えながらハードウェアを選定します • 価格、コスト(重要) • メーカーの保守(平日日中 or 24x365 オンサイト) • 3年後5年後に必要となるディスク容量 • ハードウェアで目的のOSが動作するか • ディスクの性能(SATA/SAS、回転数、容量) • RAIDレベル(1,5,6、10、ソフト/ハード/フェイク) • ディスクコントローラによる負荷分散 • アプリケーションの特性と必要とされるCPU性能 • ネットワークの冗長化 • ネットワークの速度(100Mbps、1Gbps) • バックアップメディア(ディスク、LTO、DDS) • バックアップの容量、速度 • バックアップソフト(スケジューラ、テープ管理) • 予備機、予備部品 • 既存資産との接続、流用、相性、接続可能性 • 災害対策(ディザスタリカバリ) • etc...etc...
  26. 26. コストのバランスも考えます 導入コスト 運用コスト保守コスト 良い物を選ぶと高くなる 手作業が多いと高くなる故障が多いと高くなる
  27. 27. その他:サーバーを安定して運用するために必要なもの ネットワーク 電源、UPS 空調、ラック http://ja.community.dell.com/techcenter/b/weblog/archive/2011/11/11/dell-ups.aspx http://farm4.staticflickr.com/3185/3053134927_a1b5706fc7_n_d.jpg
  28. 28. 調達~設置までの期間 OSインストール(2~3時間) デバイス認識(1~2時間) ラッキング(3人掛かり) 調達(2~3週間) 発注
  29. 29. 【想像してみてください】 このシステムが あと2つ3つ必要になったら・・・
  30. 30. 第1部 完 「うわっインフラめんどくせっ」 と思っていただければ目的達成
  31. 31. でもAWSなら たった1日で用意できる あとから見直せる
  32. 32. Amazon Web Services の良いところ 構成を後から変えられる 調達の早さ ハードウェアを気にしなくて良い いつでもやめられる
  33. 33. 第2部「AWS導入事例」
  34. 34. 第2部の目的 「柔軟性」 を感じていただくこと
  35. 35. お客様からWeb掲載の承諾を得ていないので 第二部 資料はJAWS-UG埼玉勉強会 当日 限定の資料とさせていただきました。 ご了承ください (編集が面倒って理由じゃないんだからねっ)
  36. 36. ご清聴ありがとうございました classmethod.jp 36

×