スカイアーチセミナー：【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法

1. 思いがけずサーバー管理まで任されてしまったWeb制作・SI企業ご担当者様の為のご担当者様の為の『サーバー管理・運用が怖くなくなる方法』『サーバー管理・運用が怖くなくなる方法』株式会社スカイアーチネットワークス営業本部リーダー営業本部リーダー岡田行司岡田行司 (おかだこうじ) 1

2. 本日のゴールサーバー管理の基本を理解し、サーバー管理の基本を理解し、サーバー管理を行う基礎を築きあげる！サーバー管理を行う基礎を築きあげる！ 2

3. プロフィール岡田行司 / Koji Okada 株式会社スカイアーチネットワークス株式会社スカイアーチネットワークス営業本部リーダー • 2008年スカイアーチネットワークス入社 • データセンター担当営業を行い、全国60社150か所のデータセンターを提案• データセンター担当営業を行い、全国60社150か所のデータセンターを提案 • 2009年より内部監査も担当し、現在5年目。情報セキュリティ、個人情報保護、ITサービスマネジメントの視点からシステム提案を実施。護、ITサービスマネジメントの視点からシステム提案を実施。 • 2012年営業本部リーダーに就任。担当顧客数No.1/売上No.1 • 信念：顧客のなんとなくを、しっかり形にして提案する事。• 信念：顧客のなんとなくを、しっかり形にして提案する事。 • 趣味：散歩 3

4. ワークシート • サーバー管理で困っている事を書き出してみましょう。(5分程度)てみましょう。(5分程度) 4

5. 問題点 (サーバー管理あるある) 当たり前のようにサーバ管理も行う前提で、案件が進んでいるサーバーに詳しい社員案件が進んでいるがいない夜間・休日に落ちてても気付かクラウドを使うちだけは大丈夫！！大丈夫…… ない脆弱性対策大丈夫？クラウドを使え？ 24時間稼働が必要既に乗っ取られ顧客「サーバーなんて勝手に動既に乗っ取られているかもなんて勝手に動いてるの？」 5

6. リスク損失 / 費用例対策サーバー管理がなぜ必要か障害発生時の機会損失売上1,000万円/月のサイトが、障害で為す術がなく、1日止まったら…？原因の切り分け、迅速に復旧！障害の早期復旧（＋予防）リスク損失 / 費用例対策情報漏洩・1000万円/30日=33.3万円・信用失墜原因の切り分け、迅速に復旧！ 1件、発生してしまったら？機密性の高いシステム構築情報漏洩 1件、発生してしまったら？平均7505万7636円 *2012年5月シマンテック調査セキュリティに配慮した設定。万が一の際は迅速に対応！機密性の高いシステム構築技術者の教育コスト構築セミナー*に参加したら？・受講料 8.4万円・人件費 3,000×20時間＝6万円約3,000台の構築ノウハウで、最適化した構成でご提供！専門事業者のノウハウ活用・人件費 3,000×20時間＝6万円 *KENスクール「LAMP構築セミナー」料金最適化した構成でご提供！レスポンス低下による機会損失ページの反応が0.1秒 0.3秒で表示されていたサイト、最適化されずに、0.6秒になっていたら？増強・増設、チューニング！最適化した構成の必要性ページの反応が0.1秒遅くなると、売上が1%落ちる *amazon.com調べ最適化されずに、0.6秒になっていたら？・1,000万円/月×3%＝30万円/月増強・増設、チューニング！ 6

7. 目次超基本編 1. 監視超基本編 1. 監視 2. バックアップ 3. セキュリティ3. セキュリティ応用編 4. サーバー安定稼働応用編 5. クラウド活用 6. まとめ6. まとめ 7

8. まず抑えたいサバカン超基本 1.監視1.監視～異常事態はすぐに気付こう～ 2. バックアップ～異常事態はすぐに直そう～ 3. セキュリティ3. セキュリティ～異常事態の発生を抑えよう～～異常事態の発生を抑えよう～ 8

10. 1．監視 • 監視の問題点 – なにをどこまで監視すればいいか？ • 監視ポイントを増やす – 多角的にサーバー状況を監視でき、異常に気付きやすい。– 多角的にサーバー状況を監視でき、異常に気付きやすい。 – サービスに影響が無くてもアラートが出る為、緊急対応が必要なアラートを見落とすなアラートを見落とす • 監視ポイントを減らす• 監視ポイントを減らす – アラートが少ないので緊急時のアラートが埋もれない – アラート受信後、どこに異常が出ているのか切り分けが必要– アラート受信後、どこに異常が出ているのか切り分けが必要 10

11. 1.監視監視が多いと… 監視が少ないと…監視が多いと… ・細かくわかる監視が少ないと… ・埋もれない・細かくわかる・埋もれる・埋もれない・切り分けが必要バランスのよい監視が必要バランスのよい監視が必要 11

12. 1.監視 • サバカン屋の主要監視設定 • Ping監視• Ping監視 • ポート監視 • DB監視 • URL監視• URL監視 • NFSマウント監視 • DISK容量等• DISK容量等サービス(サイト閲覧)に直結する監視のみアラートを上げる 12

13. 1.監視 • ほとんどやらない監視 • メモリ閾値• メモリ閾値 • CPU閾値 • トラフィック監視等 ⇒アラートが上がってもそれ自体どうしようもない⇒アラートが上がってもそれ自体どうしようもない (サーバーの増強が必要) ⇒cactiによるグラフ取得で代用する⇒cactiによるグラフ取得で代用する 13

14. 1.監視 • Cacti (モニタリングツール) 蓄積しグラフ化する事で、管理を簡素化する蓄積しグラフ化する事で、管理を簡素化する 14

15. 1.監視対応一次切り分けリモート対応エスカレーション（原因調査）エスカレーション – インフラや開発会社 – お客様への状況報告動作確認腕の見せどころ動作確認改善提案見せどころ 15

17. 2.バックアップ • 監視バックアップの問題点• 監視バックアップの問題点 – どこの領域をどの間隔で何世代、どこに保存すればいいか？ • 領域• 領域 – データ：コンテンツ / データベース / ログ – イメージ：OSから丸ごと全て取得 • 頻度と世代 – イメージ：OSから丸ごと全て取得 – 1日1回 / 1ヶ月に1回 • 保存先 – 1日1回 / 1ヶ月に1回 – 7世代 / 31世代 • 保存先 – サーバー内 / バックアップサーバー – ファイルサーバー– ファイルサーバー – オフィスのPC 17

18. 2.バックアップ • 領域• 領域イメージデータイメージ 1回のデータが大きいデータ 1回のデータが少ない不要なデータも取得ファイル単位でのリカバ必要なデータのみ取得可ファイル単位でのリカバファイル単位でのリカバリができないリストアに時間がかかるファイル単位でのリカバリができるリストアが早いリストアに時間がかかる初期化からも直ぐに復旧可リストアが早い初期化からのリカバリ時はサーバー構築が必要可はサーバー構築が必要 18

19. 2.バックアップ • 頻度と世代• 頻度と世代 ⇒当然、頻度高く、世代を多く取得するとコスト増⇒当然、頻度高く、世代を多く取得するとコスト増バックアップ取得時は、サーバーが高負荷状態に。対象サイトの更新頻度は？ ⇒更新しないのに毎日取得しますか？ ⇒更新が多いのに月に1回ですか？対象サイトに担保する完全性は？対象サイトに担保する完全性は？ ⇒何日前までのデータがあればよいですか？ 19

20. 2.バックアップ • 保存先• 保存先 ⇒保存先により、メリットデメリットがあります。メリットデメリットサーバー内・すぐにデータ復旧ができる・イメージでの取得ができないサーバー内・すぐにデータ復旧ができる・イメージでの取得ができない・全データ消失リスク有専用バックアップサーバー・別筺体に保存・スムーズな復旧・予め大容量HDD確保の必要性・容量不足時、サーバー追加orリプレースレース・バックアップサーバー故障時、データ消失の可能性ありクラウドファイルサーバー(S3/nifty ・自動で2重、3重の複製を作成する・青天井で高コストの可能性クラウドファイルサーバー(S3/nifty クラウドストレージ等) ※クラウドサーバー利用想定・自動で2重、3重の複製を作成する・利用した容量のみ費用を支払う・イメージ取得が簡単・青天井で高コストの可能性・コンパネ操作やAPI連携など知識が必要・転送速度がやや遅いローカルPC ・遠隔地保管ができる・紛失、盗難のリスクローカルPC ・遠隔地保管ができる・紛失、盗難のリスク 20

21. 2.バックアップ • データとイメージを使い分けて、最適化 – データ：– データ： • 日々のコンテンツ、DBを取得 • 7世代～31世代 – イメージ：– イメージ： • サイトへの新機能実装前後 • セキュリティアップデート前後都度取得ができているか確認は必須です。都度取得ができているか確認は必須です。 21

23. • 不正アクセスを防ぐ対策 3.セキュリティ • 不正アクセスを防ぐ対策 – ファイアウォール – アクセス権管理インターネット – アクセス権管理 – 脆弱性管理 ○ × – 教育 • 不正アクセスを前提とした対策 ○ • 不正アクセスを前提とした対策 – 暗号化 – ログ取得社内– ログ取得 – バックアップ • イメージ取得 ○ 社内個人情報 • イメージ取得 ○ 23

24. 3.セキュリティハッキング攻撃の傾向と変化２０００年～２００４年～現在～対象不特定多数（ユーザーやサービス、組織）不特定多数（ユーザーやサービス、組織）特定ユーザー、サービス、組織（企業や制御システム、政府・公的機関）（ユーザーやサービス、組織）（ユーザーやサービス、組織）（企業や制御システム、政府・公的機関） •スクリプトやツール •マルウェア・スパイウェア •スパムメール •フィッシングサイト •標的型攻撃（APT攻撃） •ゼロデイ攻撃やソーシャル・エンジニアリ •ブルート・フォース攻撃 •バッファオーバーフロー •DoS攻撃／DDoS攻撃 •ルートキット •ボットネット •SQLインジェクションングなどを複合的に利用した非常に高度で複雑な攻撃 •外部攻撃型方法 •DoS攻撃／DDoS攻撃 •SQLインジェクション •XSS （クロスサイト・スクリプティング） •フェイク・アラート –DoS攻撃／DDoS攻撃 –脆弱性を悪用した攻撃・侵入 •内部侵入型•フェイク・アラート •内部侵入型 –ゼロデイ攻撃を利用した不正プログラムを、メールやUSB経由で内部端末に送り込み、内部から情報搾取や末に送り込み、内部から情報搾取や攻撃を試行 24

25. 3.セキュリティ「ウェブ改ざん」の被害（ＩＰＡ) ウェブ改ざんの「原因分類」ウェブ改ざんの「原因分類」（2012年1月～2013年5月）新たな手口の追加による “ウェブ改ざん連鎖”の拡大“ウェブ改ざん連鎖”の拡大 25

26. 3.セキュリティなぜ事故は起こるのか？時期、対象サービス消失機密概要時期、対象サービス消失機密概要 2009年 3月 Google Docs ○ 意図しない相手とドキュメント共有、脆弱性 4月 Core IP Networks LLC ○ サーバーー押収 6月 Vaserv.com ○ ウェブサイト消失、脆弱性6月 Vaserv.com ○ ウェブサイト消失、脆弱性 10月 Sidekick ○ データ消失、SANのアップグレードに失敗 2010年 5月 Amazon Web Service ○ システムダウン、データ消失 2月 Gmail ○ メール消失 2011年 2月 Gmail ○ メール消失 5月 NTT WebARENA ○ サーバーー接続不可 6月 Dropbox ○ パスワード不要でアクセス可能 7月 Distribute ○ 顧客データ消去7月 Distribute ○ 顧客データ消去 9月 InMotion Hosting ○ インデックスファイル改ざん 2012年 1月さくらのクラウド ○ データ消失 6月ファーストサーバーー ○ ○ 手￥順ミスにより、5676件、99.6%の顧客データ消失6月ファーストサーバーー ○ ○ 手￥順ミスにより、5676件、99.6%の顧客データ消失 2013年 3月 Evernote ○ パスワードハッキング 5月 Yahoo!JAPAN ○ 外部アクセスにより、最大2200万件のYahooIDが抽出 26 2014年 6月ベネッセコーポレーション ○ 内部アクセスにより、最大2260万件の顧客個人情報が流出 2009～2014年報道より抜粋

27. 3.セキュリティなぜ事故は起こるのか？ • セキュリティ上のリスクデータの分散共有データの分散共有 × A社 B社 C社 × × × ×仮想化アウトソーシング × × × ハイパーバイザ仮想OS × ？OS × ？ 27

28. セキュリティ対策のレイヤー 3.セキュリティセキュリティ対策のレイヤーセキュリティ診断 •ツールやサービスの利用 • 脆弱性診断ネットワークレイヤー •セキュリティポリシーに基づき、侵入検知・防御（IP制限） • Firewall • IPS •セキュリティポリシーに基づき、侵入検知・防御（IP制限） •ブラックリスト実装 • IPS システム（アプリケーション）レイヤー • システムシステム（アプリケーション）レイヤー •要求仕様に基づき、セキュリティ・プログラミング •ホワイトリスト定義 • システム • ファイル改ざん検知 •ホワイトリスト定義 • ログ監査 28

29. 3.セキュリティ • 脆弱性への対応• 脆弱性への対応 – 脆弱性診断– 脆弱性診断 • 第三者により、脆弱性がないか評価する – 不要なサービスの停止– 不要なサービスの停止 – JPCERTの情報を的確に取得– JPCERTの情報を的確に取得脆弱性は突然発見されます。日々確認が必要。脆弱性は突然発見されます。日々確認が必要。 29

30. 3.セキュリティ • DOS攻撃への対応監視システムが、ポートの接続不可を検知（ダウンアラート） • DOS攻撃への対応監視システムが、ポートの接続不可を検知（ダウンアラート）ログで、アクセス元のＩＰアドレスを確認ポートの直接アクセス？ログで、アクセス元のＩＰアドレスを確認海外？同一ＩＰ／同一ネットワーク？不正アクセス FWで、特定ＩＰを規制アクセス集中か攻撃かの見極めが重要 30

31. 3.セキュリティ • 改ざんへの対応 – FWでFTPやSSH接続のIP制限 – コンパネへのIP制限、認証、ポート変更– コンパネへのIP制限、認証、ポート変更 – 改ざん検知サービスの利用– 改ざん検知サービスの利用 31

32. 振り返り • 皆様が管理されるサーバーはいかがですか？？ • 監視、バックアップ、セキュリティの設計• 監視、バックアップ、セキュリティの設計、設定について振り返ってみましょう。 32

33. 振り返り監視判定監視判定監視ポイントはちょうどよいかアラートは直ぐに気付けるか障害時の対応方針が明確か障害時の対応方針が明確かサーバーのリソースは最適かバックアップいつまでの状態に戻せるかいつまでの状態に戻せるか戻し方が明確か戻せるものと戻せないものが明確かバックアップデータはどこにあるかバックアップデータはどこにあるかバックアップデータの複製があるかセキュリティ FWなどを利用しているかFWなどを利用しているかアクセス権を分けているか PWは複雑か脆弱性の管理を行っているか脆弱性の管理を行っているか IP制限を実施しているか 33

34. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働～安定稼働させる為のヒント～ 5.クラウド活用5.クラウド活用～クラウドを利用する為のポイント～～クラウドを利用する為のポイント～ 34

36. 4.サーバー安定稼働 1. 【増強・増設】を最短・最速 – 拡張可能なインフラ選択– 拡張可能なインフラ選択 – 負荷分散の運用ノウハウ 2. 【チューニング】でサーバーの最適化2. 【チューニング】でサーバーの最適化インフラ運用 36

37. サイト概要 4.サーバー安定稼働サイト概要 • 提供サービス• 提供サービス – 健康食品販売サイト • サーバー構成 – ＬＢ：ＥＬＢ１– ＬＢ：ＥＬＢ×１ – ウェブ：ＥＣ２×２– ウェブ：ＥＣ２×２ – ＤＢ：ＲＤＳ×１ウェブウェブＤＢ 37

38. 1．【増強・増設】を最短・最速 4.サーバー安定稼働 1．【増強・増設】を最短・最速スケールアップ • スケールアップ• スケールアップ – ＤＢウェブウェブ • スケールアウト – ウェブ：２台＋３台ウェブウェブＤＢ– ウェブ：２台＋３台 – ＤＢ：１台＋１台スケールアウト – ＤＢ：１台＋１台ウェブウェブウェブＤＢスケールアウト 38

39. １．【増強・増設】を最短・最速 4.サーバー安定稼働スケールアウト１．【増強・増設】を最短・最速ウェブスケールアウトマスターＤＢマスターレプリケーションスケールアップＤＢスレーブスケールアウト 39

40. 【ウェブ】対応 4.サーバー安定稼働ウェブは、スケールアウトし易い【ウェブ】対応ウェブは、スケールアウトし易いただし、コンテンツの同期に配慮が必要 40

41. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – NFSサーバーの導入 • コンテンツの一元管理ができる• コンテンツの一元管理ができる • コンテンツ同期不要 • NFSに負荷がかかる可能性有負荷分散ウェブウェブウェブウェブ NFS 高負荷 41

42. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – コンテンツ同期スクリプトを作成 • lsync+rsync• lsync+rsync • 知識が必要負荷分散負荷分散ウェブウェブウェブウェブコンテンツアップロードコンテンツ同期 42

43. 【ＤＢ】対応 4.サーバー安定稼働ＤＢは、一筋縄にいかない【ＤＢ】対応ＤＢは、一筋縄にいかない 43

44. 【ＤＢ】スケールアウトの難しい理由 4.サーバー安定稼働【ＤＢ】スケールアウトの難しい理由ＲＤＢＭＳ（リレーショナルデータベース）ＲＤＢＭＳ（リレーショナルデータベース） – スケールアップ（増強）が得意負荷分散の方針 △○ △○スケールアップ（増強） △スケールアウト（増設） ○ 44

45. ＤＢのスケール設計 4.サーバー安定稼働対策例１：キャッシュサーバーの利用ＤＢのスケール設計マスター更新系スレーブ参照系 Cache 更新系参照系対策例２：テーブルの分割対策例２：テーブルの分割購買情報会員情報商品情報会員情報 45

46. 4.サーバー安定稼働多彩なオプションとスケールアウトとスケールアップのスケールアウトとスケールアップの合わせ技合わせ技＋＋＋ 46

47. ２．【チューニング】でサーバーの最適化 4.サーバー安定稼働 • ウェブ２．【チューニング】でサーバーの最適化スケール結果を元に • ウェブ – 同時接続数スケール結果を元にサーバーの最適化 • ＤＢ – セッション数サーバーの最適化 – セッション数 – メモリ– メモリ • 増強 – CloudFront ウェブウェブＤＢ 47

48. シナリオによる負荷テスト 4.サーバー安定稼働シナリオによる負荷テストシナリオ送信負荷をかける応答 ★サイトシナリオ作成 ★サイトシナリオの実行 ★負荷と閾値状況(WWWサーバー) 1000010001 総リクエスト同時リクエスト項目 ★サイトシナリオ作成 ★サイトシナリオの実行 ★負荷と閾値状況(WWWサーバー) アクセス状況(閾値) ・平均値・最大値 300 400 500 リクエストの処理時間(ミリ 40000040004 50000050005 30000030003 20000020002 1000010001 9項目以降は、大きく変化・平均値・最大値 0 100 200 300リクエストの処理時間秒) 90000090009 60000060006 80000080008 50000050005 70000070007 5000 9000 9項目以降は、大きく変化処理時間が掛かる 0 1 2 3 4 5 6 7 8 9 10 リクエストの処理時間テスト項目 90000090009 10000001000010 11000001100011 48

49. サイトレスポンス計測して、ボトルネック解析 4.サーバー安定稼働サイトレスポンス計測して、ボトルネック解析 ●：コンテンツエラー ●：正常●：正常 ●：応答なし最適化前最適化後 – 負荷テスト実施、ページ毎のレスポンスをグラフ化– 負荷テスト実施、ページ毎のレスポンスをグラフ化 – ボトルネック特定、解析レポート 49

50. リソース利用状況の可視化、最適化 4.サーバー安定稼働リソース利用状況の可視化、最適化 – 数値の可視化で、リソース最適化の材料を増やす – 不要リソース・コスト削除、ボトルネック調査で運営指針設定– 不要リソース・コスト削除、ボトルネック調査で運営指針設定 50

52. 5.クラウド活用 • クラウドって？ – 利用したい時に利用したいだけ– 利用したい時に利用したいだけ – 直ぐに利用できる– 直ぐに利用できる – サイズ変更も楽々 – ハードウェアが壊れても直ぐに復旧– ハードウェアが壊れても直ぐに復旧 – オプションが豊富で、組み合わせ自由– オプションが豊富で、組み合わせ自由 52

53. 5.クラウド活用 • デメリットは？ – 毎月の費用が変動– 毎月の費用が変動 – サーバー管理は必要– サーバー管理は必要 – 物理サーバーより高くなる事もある 53

54. 5.クラウド活用セキュリティは？ • セキュリティは？• セキュリティは？ – クラウドそれ自体は安全です– クラウドそれ自体は安全です例：取得認証 AWS ・HIPAA(米国医療基準) AWS ・HIPAA(米国医療基準) ・SOC1/SSAE16/ISAE1402 /SOC2 /SOC3 (内部統制) ・PCI DSS(カード会社基準) ・ISO27001(情報セキュリティ) 等・ISO27001(情報セキュリティ) 等ニフティクラウド・ISO27001 ・SOC2 ・PCI DSS 等・PCI DSS 等利用サーバーのセキュリティ対策が重要利用サーバーのセキュリティ対策が重要 54

55. 5.クラウド活用 • ガイドラインの活用「クラウドサービス利用のための情報セキュリティ • ガイドラインの活用「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」（経済産業省） http://www.meti.go.jp/press/2013/03/20140314004/20140314004-2.pdf セキュリティの観点から、1）利用者、2）クラウド事業者に必要なセキュリティの管理策をまとめた文書。「ISO/IEC27002:2005」をベースに、利用の視点から15個にわたる大項目にまとめている。ポイントアウトソーシングの留意点と大きく変わらない。リスアウトソーシングの留意点と大きく変わらない。リスクを定期的に確認していく。 55

56. 5.クラウド活用 • 代表的なサービス,機能 – サーバー– サーバー – ロードバランサー – FW– FW – RDBMS(DB) – キャッシュ – オブジェクトストレージ– オブジェクトストレージ – オートスケール – テンプレート作成– テンプレート作成 56

57. 5.クラウド活用 • クラウド選定時の注意点 – 定額制か、従量制か？– 定額制か、従量制か？ – PaaSサービスを利用するか？– PaaSサービスを利用するか？ – エンタメ系？エンタープライズ系？ – コントロールパネルでできる事は？– コントロールパネルでできる事は？システム要件に応じたクラウド選定を！ 57

58. 5.クラウド活用 • クラウド導入のポイント• クラウド導入のポイント • 適用範囲の設定が必要 • クラウドサービスの特徴を把握する • 経産省ガイドライン等を活用し、• 経産省ガイドライン等を活用し、セキュリティリスクをコントロールセキュリティリスクをコントロール 58

59. 次に抑える応用編 6.まとめ 59

60. 6.まとめ • 超基本 – 監視・バックアップ・セキュリティ– 監視・バックアップ・セキュリティ • やる事をおさえたら後は毎日実施• やる事をおさえたら後は毎日実施 • 継続運用実施で、クライアントも安心• 継続運用実施で、クライアントも安心 60

61. 6.まとめ • サーバー安定稼働 – スケールアップ– スケールアップ – スケールアウト– スケールアウト • 初期の設計段階で、考慮が必要 • 中長期の展望を見せる事でクライアントも安心！トも安心！ 61

62. • クラウド活用 – 特徴を理解し、まずは使ってみよう– 特徴を理解し、まずは使ってみよう • 貴社の課題はクラウド向きか？• 貴社の課題はクラウド向きか？ • スケールアップ、スケールアウトとク• スケールアップ、スケールアウトとクラウドの相性はバツグン！ 62

63. 6.まとめ • 運用に正解無し • PDCAサイクルでシステムに合った管理を• PDCAサイクルでシステムに合った管理を行いましょう。行いましょう。 – P：設計・設定 – D：監視及び障害対応 – C：原因調査– C：原因調査 – A：改善提案 63