20130907 jaws-ug saitama#2 case_study
DESCRIPTION
2013.09.07 JAWS Saitama #2 CaseStudy Part1.TRANSCRIPT
AWS導入事例
JAWS-UG埼玉 第2回勉強会
2013/09/07
Kazuki Ueki
自己紹介
• 名前:植木 和樹(うえき かずき) • 年齢:36歳 • 出身:新潟県妙高市(単身赴任中)
• 元製造業情報システムG常駐 • 主にUnixサーバエンジニア(監視、保守)
• 資格:IPAITサービスマネージャ
IPA システムアーキテクト • JAWS北陸コアメンバー(JAWS DAYS 2013~) • JAWS埼玉コアメンバー(2013年8月~) • 好きなAWSサービス:SQS
classmethod.jp 2
@czkuk
本日の内容
• 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が動作するか • ディスクの性能(SATA/SAS、回転数、容量) • RAIDレベル(1,5,6、10、ソフト/ハード/フェイク) • ディスクコントローラによる負荷分散 • アプリケーションの特性と必要とされるCPU性能 • ネットワークの冗長化 • ネットワークの速度(100Mbps、1Gbps) • バックアップメディア(ディスク、LTO、DDS) • バックアップの容量、速度 • バックアップソフト(スケジューラ、テープ管理) • 予備機、予備部品 • 既存資産との接続、流用、相性、接続可能性 • 災害対策(ディザスタリカバリ) • etc...etc...
コストのバランスも考えます
導入コスト
運用コスト 保守コスト
良い物を選ぶと高くなる
手作業が多いと高くなる 故障が多いと高くなる
その他:サーバーを安定して運用するために必要なもの
ネットワーク 電源、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
調達~設置までの期間
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