AWS導入事例

JAWS-UG埼玉 第2回勉強会

2013/09/07

Kazuki Ueki

自己紹介

• 名前:植木 和樹（うえき かずき） • 年齢:36歳 • 出身:新潟県妙高市（単身赴任中）

• 元製造業情報システムG常駐 • 主にUnixサーバエンジニア（監視、保守）

• 資格：IPAＩＴサービスマネージャ

IPA システムアーキテクト • JAWS北陸コアメンバー（JAWS DAYS 2013～） • JAWS埼玉コアメンバー（2013年8月～） • 好きなAWSサービス：SQS

classmethod.jp 2

@czkuk

本日の内容

• ２部構成です

• 第１部「なぜインフラは複雑になるのか」

サーバ１台から始めて徐々に育てていきます

問題を提示して構成を変化させ徐々に複雑化していくシステムを見てもらいます

本日の内容

• 第２部「AWS導入事例」

実際の導入事例３件をご紹介します

AWSならではの柔軟さを知ってもらいます

昨今のインフラ技術もご紹介します

第１部 「なぜインフラは複雑になるのか」 キーワード 「データ保全」

「冗長化」

「負荷分散」

第１部の目的

「うわっインフラめんどくせっ」 と思っていただくこと

最小構成：サーバー１台

最小構成：サーバー１台

ハードディスクが壊れるとデータがなくなる

データ保全：ディスク冗長化（RAID）

複数のハードディスクに同時に書き込む

データ保全：ディスク冗長化（RAID）

複数のハードディスクに同時に書き込む

オペミスでデータを削除したらデータが消えてしまう

データ保全：バックアップ

データを別の媒体にも コピーする

データ保全：バックアップ

データを別の媒体にも コピーする

サーバ自体に障害が起きたらサービスが止まってしまう

冗長化：サーバ２台（コールドスタンバイ）

同じサーバを２台用意して故障したら切り替える

ネットワークケーブルを つなぎ替える

接続している機器は手作業で ケーブルをつなぎ替える

冗長化：サーバ２台（コールドスタンバイ）

同じサーバを２台用意して故障したら切り替える

ネットワークケーブルを つなぎ替える

接続している機器は手作業で ケーブルをつなぎ替える ダウンタイムが長い

切り替えに人手が必要

冗長化：サーバ２台（ホットスタンバイ）

同じサーバを２台用意して故障したら「自動で」

切り替える 仮想的なIPアドレスを使って 接続先を切り替える （クラスタソフト導入）

ネットワーク越しにバックアップ

冗長化：サーバ２台（ホットスタンバイ）

同じサーバを２台用意して故障したら「自動で」

切り替える 仮想的なIPアドレスを使って 接続先を切り替える （クラスタソフト導入）

ネットワーク越しにバックアップ

１台の処理性能に限界 （高性能サーバーは高額）

負荷分散：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 オンサイト） • ３年後５年後に必要となるディスク容量 • ハードウェアで目的のOSが動作するか • ディスクの性能（SATA/SAS、回転数、容量） • RAIDレベル（１，５，６、１０、ソフト/ハード/フェイク） • ディスクコントローラによる負荷分散 • アプリケーションの特性と必要とされる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インストール（２～３時間）

デバイス認識（１～２時間）

ラッキング（３人掛かり）

調達（２～３週間）

発注

【想像してみてください】 このシステムが

あと２つ３つ必要になったら・・・

第１部 完

「うわっインフラめんどくせっ」 と思っていただければ目的達成

でもAWSなら たった１日で用意できる

あとから見直せる

Amazon Web Services の良いところ

構成を後から変えられる

調達の早さ

ハードウェアを気にしなくて良い

いつでもやめられる

第２部「AWS導入事例」

第２部の目的

「柔軟性」 を感じていただくこと

お客様からWeb掲載の承諾を得ていないので 第二部 資料はJAWS-UG埼玉勉強会 当日 限定の資料とさせていただきました。

ご了承ください

（編集が面倒って理由じゃないんだからねっ）

ご清聴ありがとうございました

classmethod.jp 36