スカイアーチセミナー：【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法
•
1 gostou•765 visualizações
今回は、Web制作・SI企業向けのセミナーになります。 突然サーバー管理を任せられてしまった！ 他の会社はどうやって運用しているのだろうか・・・ 本当にこの運用方法は正しいのだろうか・・・ 日々のサーバー運用に、不安や悩みを抱えていませんか？ 今回はそんな方のためにセミナーを開催いたします！
Recomendados
Mais conteúdo relacionado
Semelhante a スカイアーチセミナー：【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法
Semelhante a スカイアーチセミナー：【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法 (20)
Mais de 株式会社スカイアーチネットワークス
Mais de 株式会社スカイアーチネットワークス (14)
スカイアーチセミナー：【Web制作・SI企業様向け】サーバー管理が怖くなくなる方法
- 1. 思いがけずサーバー管理まで任されてしまったWeb制作・SI企業 ご担当者様の為のご担当者様の為の 『サーバー管理・運用が怖くなくなる方法』『サーバー管理・運用が怖くなくなる方法』 株式会社スカイアーチネットワークス 営業本部 リーダー営業本部 リーダー 岡田 行司岡田 行司 (お か だ こ う じ) 1
- 3. プロフィール 岡田 行司 / Koji Okada 株式会社スカイアーチネットワークス株式会社スカイアーチネットワークス 営業本部 リーダー • 2008年 スカイアーチネットワークス入社 • データセンター担当営業を行い、全国60社150か所のデータセンターを提案• データセンター担当営業を行い、全国60社150か所のデータセンターを提案 • 2009年より内部監査も担当し、現在5年目。情報セキュリティ、個人情報保 護、ITサービスマネジメントの視点からシステム提案を実施。護、ITサービスマネジメントの視点からシステム提案を実施。 • 2012年営業本部 リーダーに就任。担当顧客数No.1/売上No.1 • 信念：顧客のなんとなくを、しっかり形にして提案する事。• 信念：顧客のなんとなくを、しっかり形にして提案する事。 • 趣味：散歩 3
- 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
- 9. まず抑えたいサバカン超基本 1.監視1.監視 ～異常事態はすぐに気付こう～ 2. バックアップ ～異常事態はすぐに直そう～ 3. セキュリティ3. セキュリティ ～異常事態の発生を抑えよう～～異常事態の発生を抑えよう～ 9
- 10. 1．監視 • 監視の問題点 – なにをどこまで監視すればいいか？ • 監視ポイントを増やす – 多角的にサーバー状況を監視でき、異常に気付きやすい。– 多角的にサーバー状況を監視でき、異常に気付きやすい。 – サービスに影響が無くてもアラートが出る為、緊急対応が必要 なアラートを見落とすなアラートを見落とす • 監視ポイントを減らす• 監視ポイントを減らす – アラートが少ないので緊急時のアラートが埋もれない – アラート受信後、どこに異常が出ているのか切り分けが必要– アラート受信後、どこに異常が出ているのか切り分けが必要 10
- 12. 1.監視 • サバカン屋の主要監視設定 • Ping監視• Ping監視 • ポート監視 • DB監視 • URL監視• URL監視 • NFSマウント監視 • DISK容量 等• DISK容量 等 サービス(サイト閲覧)に直結する監視のみ アラートを上げる 12
- 13. 1.監視 • ほとんどやらない監視 • メモリ閾値• メモリ閾値 • CPU閾値 • トラフィック監視 等 ⇒アラートが上がってもそれ自体どうしようもない⇒アラートが上がってもそれ自体どうしようもない (サーバーの増強が必要) ⇒cactiによるグラフ取得で代用する⇒cactiによるグラフ取得で代用する 13
- 15. 1.監視 対応 一次切り分け リモート対応 エスカレーション （原因調査） エスカレーション – インフラや開発会社 – お客様への状況報告 動作確認 腕の 見せどころ 動作確認 改善提案 見せどころ 15
- 16. まず抑えたいサバカン超基本 1.監視1.監視 ～異常事態はすぐに気付こう～ 2. バックアップ ～異常事態はすぐに直そう～ 3. セキュリティ3. セキュリティ ～異常事態の発生を抑えよう～～異常事態の発生を抑えよう～ 16
- 17. 2.バックアップ • 監視バックアップの問題点• 監視バックアップの問題点 – どこの領域をどの間隔で何世代、どこに保存すればいいか？ • 領域• 領域 – データ：コンテンツ / データベース / ログ – イメージ：OSから丸ごと全て取得 • 頻度と世代 – イメージ：OSから丸ごと全て取得 – 1日1回 / 1ヶ月に1回 • 保存先 – 1日1回 / 1ヶ月に1回 – 7世代 / 31世代 • 保存先 – サーバー内 / バックアップサーバー – ファイルサーバー– ファイルサーバー – オフィスのPC 17
- 18. 2.バックアップ • 領域• 領域 イメージデータ イメージ 1回のデータが大きい データ 1回のデータが少ない 不要なデータも取得 ファイル単位でのリカバ 必要なデータのみ取得可 ファイル単位でのリカバ ファイル単位でのリカバ リができない リストアに時間がかかる ファイル単位でのリカバ リができる リストアが早い リストアに時間がかかる 初期化からも直ぐに復旧 可 リストアが早い 初期化からのリカバリ時 はサーバー構築が必要 可はサーバー構築が必要 18
- 20. 2.バックアップ • 保存先• 保存先 ⇒保存先により、メリットデメリットがあります。 メリット デメリット サーバー内 ・すぐにデータ復旧ができる ・イメージでの取得ができないサーバー内 ・すぐにデータ復旧ができる ・イメージでの取得ができない ・全データ消失リスク有 専用バックアップサーバー ・別筺体に保存 ・スムーズな復旧 ・予め大容量HDD確保の必要性 ・容量不足時、サーバー追加orリプ レースレース ・バックアップサーバー故障時、デー タ消失の可能性あり クラウドファイルサーバー(S3/nifty ・自動で2重、3重の複製を作成する ・青天井で高コストの可能性クラウドファイルサーバー(S3/nifty クラウドストレージ 等) ※クラウドサーバー利用想定 ・自動で2重、3重の複製を作成する ・利用した容量のみ費用を支払う ・イメージ取得が簡単 ・青天井で高コストの可能性 ・コンパネ操作やAPI連携など知識が 必要 ・転送速度がやや遅い ローカルPC ・遠隔地保管ができる ・紛失、盗難のリスクローカルPC ・遠隔地保管ができる ・紛失、盗難のリスク 20
- 21. 2.バックアップ • データとイメージを使い分けて、最適化 – データ：– データ： • 日々のコンテンツ、DBを取得 • 7世代～31世代 – イメージ：– イメージ： • サイトへの新機能実装前後 • セキュリティアップデート前後 都度取得ができているか確認は必須です。都度取得ができているか確認は必須です。 21
- 22. まず抑えたいサバカン超基本 1.監視1.監視 ～異常事態はすぐに気付こう～ 2. バックアップ ～異常事態はすぐに直そう～ 3. セキュリティ3. セキュリティ ～異常事態の発生を抑えよう～～異常事態の発生を抑えよう～ 22
- 23. • 不正アクセスを防ぐ対策 3.セキュリティ • 不正アクセスを防ぐ対策 – ファイアウォール – アクセス権管理 インターネット – アクセス権管理 – 脆弱性管理 ○ × – 教育 • 不正アクセスを前提とした対策 ○ • 不正アクセスを前提とした対策 – 暗号化 – ログ取得 社内– ログ取得 – バックアップ • イメージ取得 ○ 社内 個人 情報 • イメージ取得 ○ 23
- 24. 3.セキュリティ ハッキング攻撃の傾向と変化 ２０００年～ ２００４年～ 現在～ 対象 不特定多数 （ユーザーやサービス、組織） 不特定多数 （ユーザーやサービス、組織） 特定ユーザー、サービス、組織 （企業や制御システム、政府・公的機関）（ユーザーやサービス、組織） （ユーザーやサービス、組織） （企業や制御システム、政府・公的機関） •スクリプトやツール •マルウェア・スパイウェア •スパムメール •フィッシングサイト •標的型攻撃（APT攻撃） •ゼロデイ攻撃やソーシャル・エンジニアリ •ブルート・フォース攻撃 •バッファオーバーフロー •DoS攻撃／DDoS攻撃 •ルートキット •ボットネット •SQLインジェクション ングなどを複合的に利用した非常に高度で 複雑な攻撃 •外部攻撃型 方法 •DoS攻撃／DDoS攻撃 •SQLインジェクション •XSS （クロスサイト・スクリ プティング） •フェイク・アラート –DoS攻撃／DDoS攻撃 –脆弱性を悪用した攻撃・侵入 •内部侵入型•フェイク・アラート •内部侵入型 –ゼロデイ攻撃を利用した不正プログ ラムを、メールやUSB経由で内部端 末に送り込み、内部から情報搾取や末に送り込み、内部から情報搾取や 攻撃を試行 24
- 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
- 31. 3.セキュリティ • 改ざんへの対応 – FWでFTPやSSH接続のIP制限 – コンパネへのIP制限、認証、ポート変更– コンパネへのIP制限、認証、ポート変更 – 改ざん検知サービスの利用– 改ざん検知サービスの利用 31
- 32. 振り返り • 皆様が管理されるサーバーはいかがですか ？？ • 監視、バックアップ、セキュリティの設計• 監視、バックアップ、セキュリティの設計 、設定について振り返ってみましょう。 32
- 34. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ～安定稼働させる為のヒント～ 5.クラウド活用5.クラウド活用 ～クラウドを利用する為のポイント～～クラウドを利用する為のポイント～ 34
- 35. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ～安定稼働させる為のヒント～ 5.クラウド活用5.クラウド活用 ～クラウドを利用する為のポイント～～クラウドを利用する為のポイント～ 35
- 36. 4.サーバー安定稼働 1. 【増強・増設】を最短・最速 – 拡張可能なインフラ選択– 拡張可能なインフラ選択 – 負荷分散の運用ノウハウ 2. 【チューニング】でサーバーの最適化2. 【チューニング】でサーバーの最適化 インフラ 運用 36
- 37. サイト概要 4.サーバー安定稼働 サイト概要 • 提供サービス• 提供サービス – 健康食品販売サイト • サーバー構成 – ＬＢ ：ＥＬＢ １– ＬＢ ：ＥＬＢ×１ – ウェブ：ＥＣ２×２– ウェブ：ＥＣ２×２ – ＤＢ ：ＲＤＳ×１ ウェブ ウェブ ＤＢ 37
- 38. 1．【増強・増設】を最短・最速 4.サーバー安定稼働 1．【増強・増設】を最短・最速 スケールアップ • スケールアップ• スケールアップ – ＤＢ ウェブ ウェブ • スケールアウト – ウェブ：２台＋３台 ウェブ ウェブ ＤＢ– ウェブ：２台＋３台 – ＤＢ ：１台＋１台 スケールアウト – ＤＢ ：１台＋１台 ウェブ ウェブ ウェブ ＤＢスケールアウト 38
- 41. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – NFSサーバーの導入 • コンテンツの一元管理ができる• コンテンツの一元管理ができる • コンテンツ同期不要 • NFSに負荷がかかる可能性有 負荷分散 ウェブウェブウェブ ウェブ NFS 高負荷 41
- 42. 4.サーバー安定稼働 • ウェブのスケールアウト対策• ウェブのスケールアウト対策 – コンテンツ同期スクリプトを作成 • lsync+rsync• lsync+rsync • 知識が必要 負荷分散負荷分散 ウェブウェブウェブ ウェブ コンテンツ アップロード コンテンツ同期 42
- 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
- 51. 次に抑える応用編 4.サーバ安定稼働4.サーバ安定稼働 ～安定稼働させる為のヒント～ 5.クラウド活用5.クラウド活用 ～クラウドを利用する為のポイント～～クラウドを利用する為のポイント～ 51
- 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
- 56. 5.クラウド活用 • 代表的なサービス,機能 – サーバー– サーバー – ロードバランサー – FW– FW – RDBMS(DB) – キャッシュ – オブジェクトストレージ– オブジェクトストレージ – オートスケール – テンプレート作成– テンプレート作成 56
- 57. 5.クラウド活用 • クラウド選定時の注意点 – 定額制か、従量制か？– 定額制か、従量制か？ – PaaSサービスを利用するか？– PaaSサービスを利用するか？ – エンタメ系？エンタープライズ系？ – コントロールパネルでできる事は？– コントロールパネルでできる事は？ システム要件に応じたクラウド選定を！ 57
- 58. 5.クラウド活用 • クラウド導入のポイント• クラウド導入のポイント • 適用範囲の設定が必要 • クラウドサービスの特徴を把握する • 経産省ガイドライン等を活用し、• 経産省ガイドライン等を活用し、 セキュリティリスクをコントロールセキュリティリスクをコントロール 58
- 60. 6.まとめ • 超基本 – 監視・バックアップ・セキュリティ– 監視・バックアップ・セキュリティ • やる事をおさえたら後は毎日実施• やる事をおさえたら後は毎日実施 • 継続運用実施で、クライアントも安心• 継続運用実施で、クライアントも安心 60
- 61. 6.まとめ • サーバー安定稼働 – スケールアップ– スケールアップ – スケールアウト– スケールアウト • 初期の設計段階で、考慮が必要 • 中長期の展望を見せる事でクライアン トも安心！トも安心！ 61
- 62. • クラウド活用 – 特徴を理解し、まずは使ってみよう– 特徴を理解し、まずは使ってみよう • 貴社の課題はクラウド向きか？• 貴社の課題はクラウド向きか？ • スケールアップ、スケールアウトとク• スケールアップ、スケールアウトとク ラウドの相性はバツグン！ 62
- 63. 6.まとめ • 運用に正解無し • PDCAサイクルでシステムに合った管理を• PDCAサイクルでシステムに合った管理を 行いましょう。行いましょう。 – P：設計・設定 – D：監視及び障害対応 – C：原因調査– C：原因調査 – A：改善提案 63