2013.09.07 JAWS Saitama #2 CaseStudy Part1.

1. AWS導入事例
JAWS-UG埼玉 第2回勉強会
2013/09/07
Kazuki Ueki

2. 自己紹介
• 名前:植木 和樹（うえき かずき）
• 年齢:36歳
• 出身:新潟県妙高市（単身赴任中）
• 元製造業情報システムG常駐
• 主にUnixサーバエンジニア（監視、保守）
• 資格：IPAＩＴサービスマネージャ
IPA システムアーキテクト
• JAWS北陸コアメンバー（JAWS DAYS 2013～）
• JAWS埼玉コアメンバー（2013年8月～）
• 好きなAWSサービス：SQS
classmethod.jp 2
@czkuk

3. 本日の内容
• ２部構成です
• 第１部「なぜインフラは複雑になるのか」
サーバ１台から始めて徐々に育てていきます
問題を提示して構成を変化させ徐々に複雑化して
いくシステムを見てもらいます

4. 本日の内容
• 第２部「AWS導入事例」
実際の導入事例３件をご紹介します
AWSならではの柔軟さを知ってもらいます
昨今のインフラ技術もご紹介します

5. 第１部 「なぜインフラは複雑になるのか」
キーワード
「データ保全」
「冗長化」
「負荷分散」

6. 第１部の目的
「うわっインフラめんどくせっ」
と思っていただくこと

7. 最小構成：サーバー１台

8. 最小構成：サーバー１台
ハードディスクが壊れるとデータがなくなる

9. データ保全：ディスク冗長化（RAID）
複数のハードディスクに
同時に書き込む

10. データ保全：ディスク冗長化（RAID）
複数のハードディスクに
同時に書き込む
オペミスでデータを削除したらデータが消えてしまう

11. データ保全：バックアップ
データを別の媒体にも
コピーする

12. データ保全：バックアップ
データを別の媒体にも
コピーする
サーバ自体に障害が起きたらサービスが止まってしまう

13. 冗長化：サーバ２台（コールドスタンバイ）
同じサーバを２台用意し
て故障したら切り替える
ネットワークケーブルを
つなぎ替える
接続している機器は手作業で
ケーブルをつなぎ替える

14. 冗長化：サーバ２台（コールドスタンバイ）
同じサーバを２台用意し
て故障したら切り替える
ネットワークケーブルを
つなぎ替える
接続している機器は手作業で
ケーブルをつなぎ替えるダウンタイムが長い
切り替えに人手が必要

15. 冗長化：サーバ２台（ホットスタンバイ）
同じサーバを２台用意し
て故障したら「自動で」
切り替える
仮想的なIPアドレスを使って
接続先を切り替える
（クラスタソフト導入）
ネットワーク越しにバックアップ

16. 冗長化：サーバ２台（ホットスタンバイ）
同じサーバを２台用意し
て故障したら「自動で」
切り替える
仮想的なIPアドレスを使って
接続先を切り替える
（クラスタソフト導入）
ネットワーク越しにバックアップ
１台の処理性能に限界
（高性能サーバーは高額）

17. 負荷分散：APとDBをわける
APサーバとDBサーバを
分けて必要な性能を低く
おさえる
APとDBで必要な性能が異なるため
適した製品を選択しをコスト削減
AP、DB、Backupの
ネットワークをより
高速なものに

18. 負荷分散：APとDBをわける
APサーバとDBサーバを
分けて必要な性能を低く
おさえる
APとDBで必要な性能が異なるため
適した製品を選択しをコスト削減
AP、DB、Backupの
ネットワークをより
高速なものに
APサーバーの待機系が稼働していないのはもったいない

19. 負荷分散：ロードバランサー
ロードバランサを入れて
リクエストを振り分ける ロードバランサーで処理を分散する
セッションデータを
キャッシュで共有

20. 負荷分散：ロードバランサー
ロードバランサを入れて
リクエストを振り分ける ロードバランサーで処理を分散する
セッションデータを
キャッシュで共有
JavaScriptやCSS、画像、動画など静的なコンテンツの
配信負荷、データ転送量をおさえたい

21. 負荷分散：CDN（Contents Distribution Network）
静的コンテンツをより
ユーザーに近い場所から
配信し転送コストをさげ
る
一度読み込んだコンテンツを
キャッシュする

22. 負荷分散：CDN（Contents Distribution Network）
静的コンテンツをより
ユーザーに近い場所から
配信し転送コストをさげ
る
一度読み込んだコンテンツを
キャッシュする
ひとまずここまででデータ保全がなされ
可用性が高いシステムができたといえます

23. 「インフラめんどくせっ」
と思っていただけましたか？

24. さらに、それぞれの構成要素を
要件に応じて
選択する作業があります（泣）

25. 説明では省略しましたがこんなことも考えながらハードウェアを選定します
• 価格、コスト（重要）
• メーカーの保守（平日日中 or 24x365 オンサイト）
• ３年後５年後に必要となるディスク容量
• ハードウェアで目的のOSが動作するか
• ディスクの性能（SATA/SAS、回転数、容量）
• RAIDレベル（１，５，６、１０、ソフト/ハード/フェイク）
• ディスクコントローラによる負荷分散
• アプリケーションの特性と必要とされるCPU性能
• ネットワークの冗長化
• ネットワークの速度（100Mbps、1Gbps）
• バックアップメディア（ディスク、LTO、DDS）
• バックアップの容量、速度
• バックアップソフト（スケジューラ、テープ管理）
• 予備機、予備部品
• 既存資産との接続、流用、相性、接続可能性
• 災害対策（ディザスタリカバリ）
• etc...etc...

26. コストのバランスも考えます
導入コスト
運用コスト保守コスト
良い物を選ぶと高くなる
手作業が多いと高くなる故障が多いと高くなる

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. 調達～設置までの期間
OSインストール（２～３時間）
デバイス認識（１～２時間）
ラッキング（３人掛かり）
調達（２～３週間）
発注

29. 【想像してみてください】
このシステムが
あと２つ３つ必要になったら・・・

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

31. でもAWSなら
たった１日で用意できる
あとから見直せる

32. Amazon Web Services の良いところ
構成を後から変えられる
調達の早さ
ハードウェアを気にしなくて良い
いつでもやめられる

33. 第２部「AWS導入事例」

34. 第２部の目的
「柔軟性」
を感じていただくこと

35. お客様からWeb掲載の承諾を得ていないので
第二部 資料はJAWS-UG埼玉勉強会 当日
限定の資料とさせていただきました。
ご了承ください
（編集が面倒って理由じゃないんだからねっ）

36. ご清聴ありがとうございました
classmethod.jp 36