Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

インフラ運用の観点から考えるAWS~運用における利点と移行のポイント~

1,090 views

Published on

2018年9月20日に開催された「AWS Cloud Express Roadshow in Nagoya」にて講演した内容となります。

Published in: Technology
  • Be the first to comment

インフラ運用の観点から考えるAWS~運用における利点と移行のポイント~

  1. 1. Copyright © NHN Techorus Corp. インフラ運用の観点から考えるAWS ~運用における利点と移行のポイント~ 2018.09.20 AWS Cloud Express Roadshow in Nagoya NHN テコラス株式会社 マネージドサービス事業部 逢坂文哉
  2. 2. 自己紹介 逢坂 文哉(おおさか ふみや) NHNテコラス株式会社 マネージドサービス事業部 西日本(浜名湖以西?)担当プリセールスエンジニア 兼 営業 AWS認定 ソリューションアーキテクト プロフェッショナル 前職はオンプレミスのシステム導入・保守エンジニア 好きなAWSサービス:Simple Monthly Calculator, EC2, VPC JAWS-UG Sales 運営メンバー(いいだしっぺ) 2
  3. 3. 会社概要 3 社 名 N H N テ コ ラ ス 株 式 会 社 NHN Techorus Corp. 所在地 本社 〒105-6322 東京都港区虎ノ門一丁目23番1号 虎ノ門ヒルズ森タワー22階 大阪オフィス 〒530-0001 大阪府大阪市北区梅田1 丁目11-4 大阪駅前第4ビル5階 設立 2007年4月 代表者 代表取締役社長 加藤 雅樹 資 本 金 21億円 事業内容 ITインフラ・ソリューション事業 各種会員 ・ 資格 届出電気通信事業者 ICANN公式レジストラ APNIC Member ISMS/BS7799 取得(2005年3月)、ISO27001 認証取得、ISO27017 認証取得 n h n - t e c h o r u s . c o m
  4. 4. 沿革 4 2000.04 株式会社オン・ザ・エッヂにて 「データホテル」事業提供開始 2014.09 NHNグループ入り 2004.08 有限会社SAVAWAY設立 2013.12 NHNグループ入り 2000.09 ハンゲームジャパン株式会社設立 2015.06 40億円の増資、資本金21億円 2015.07 オフィスを東新宿本社(ESS)に統合 (技術部門) 2017.05 SAVAWAY 会社分割による子会社化 本社オフィスを虎ノ門ヒルズに移転 2015.01 3社統合 新生テコラス誕生 2015.10 商号をNHN テコラス株式会社に変更 10年以上の実績を持つ3社が統合、2015年1月にテコラス株式会社としてスタート。 2015年10月より「NHN テコラス株式会社」に商号変更。
  5. 5. 日本国内のNHNグループ 5 NHN テコラス株式会社 NHNグループにおける、BtoBビジネスの中核企 業として「ITインフラソリューション事業」を 中心に、お客様のビジネスの成功を支援する各 種ソリューションを提供しています。 2007年4月2日 設立 代表取締役社長 加藤雅樹 NHN PlayArt 株式会社 「LINE:ディズニー ツムツム」や「妖怪 ウォッチ ぷにぷに」など人気のスマートフォン 向けゲームの開発・運営をしています。グロー バルな展開と新たな価値の創造に挑戦し、オリ ジナリティあふれる魅力的なサービスを提供し ています。 2015年10月1日 設立 代表取締役社長 加藤雅樹 NHN comico株式会社 エンターテイメントプラットフォーム 「comico」を運営しています。縦スクロールで 読み進められる形式やフルカラー表現など、ス マートフォンに最適化した閲覧環境が特長で、 連載作品の書籍化、アニメ・映画化をはじめと するメディアミックス展開を行なっています。 2017年6月1日 設立 代表取締役社長 加藤雅樹 NHN SAVAWAY株式会社 複数モール一元管理サービス「TEMPOSTAR」 やネットショップ構築サービス「CARTSTAR」 など、各種ネットショップ支援サービスを展開 しています。 2017年5月1日 設立 代表取締役社長 康泳權 NHN ハンゲーム株式会社 PCとスマートフォンでサービス展開するゲーム ポータルサイト「ハンゲーム」のゲーム事業を 中心に、「PC・スマートフォン向けゲームの開 発」「コミュニティ・アバター事業」「web サービス支援業務」を行っています。 2009年1月5日 設立 代表取締役社長 丁佑鎭 代表取締役社長 黄載皓 NHN キャピタル株式会社 NHNグループのコーポレートベンチャーキャピ タルとして、ハンズオン型の投資育成事業を展 開。各領域で優れたアイデア、技術を持つベン チャー企業に対し、NHNグループが国内外で保 有するアセットやノウハウ等、質の高いバ リュークリエーションサービスを提供します。 2017年7月12日 設立 代表取締役社長 加藤雅樹 NHN JAPAN株式会社 2013年4月1日 設立 代表取締役社長 泉 忠宏
  6. 6. ソリューション・ポートフォリオ 6 パブリッククラウドブローカー 物理占有ホスティング テコラスCDN クラウドコネクティビティ マネージドサービス クラウドオフィス SEサービス ネットワーク/配信 IaaS&物理ホスティング ・監視対応 ・セキュリティ ・バックアップ ・障害一次対応 ・ログ集計 ・24時間365日 ・設計、構築 ・各種チューニング ・運用設計 ・障害二次対応 ・構成レビュー ・新規技術採用支援 フルマネージドサービス データサイエンス Microsoft製品を核とした クラウド業務アプリ活用の 設計・移行コンサルテーション データ解析・活用で企業変革を 支援する分析、コンサルテーション AWSを中心に主要クラウドを 直接契約より安く安心に クラウドマーケットプレイス 大規模Game/Webサービス実績多数 『フルマネージド・ホスティング』 クラウド接続から大容量専用線、 グローバル対応のCDNサービスまで コンサルテーション 大幅割引 大幅割引
  7. 7. 導入実績 7 NHN テコラスのITインフラサービスは多くのお客様に選ばれています 全国・大規模サービス 公共・教育機関 テクノロジー・スタートアップ
  8. 8. AWS請求代行サービス 8 AWS利用料を大幅割引 サポート・各手数料は無料 お支払いは請求書・翌々月末 EC2の主要インスタンスやCloudFrontなどが 割引価格でご利用いただけます。 AWSビジネスサポート相当を無料でご提供。 請求代行手数料などの手数料も無料です。 AWSを支払いを日本円建て・請求書払いで。 お支払いは翌々月末払いになります。 NHN テコラスは、APNアドバンストコンサルティングパートナーです。 AWSからオンプレミスまで、ITインフラ事業者として17年以上の実績。 導入/移行から運用、データ活用までお困りのことがありましたらご相談ください。 ※アマゾンウェブサービス、AWS およびAmazon Web ServicesロゴはAmazon.com, Inc. またはその関連会社の商標です。
  9. 9. マネージドサービス 9 ご提供イメージ OS Middleware/DB Application NHN テコラス運用範囲 作業の依頼 報告 回答 当社MSPチーム 24/365稼動 障害切り分け 一次対応 エスカレーション 依頼作業 キャパシティ管理 二次対応 各種お問い合わせ対応 当社SEチーム 平日10:00 – 18:00稼働 障害対応 ※ SEによるエンジニアサポートはオプション契約となります。 障害発生時のエスカレーション 対応報告 障害状況の確認 お客様 AWS環境の「初期導入、システム移行支援、監視・運用」までフルサポート トレーニングされた 専任スタッフによるオペレーション お客様に合わせた 柔軟なカスタマイズ対応 業務の明確化、効率化による スピーディーな対応 専任SEによる信頼とお客様との円滑なコミュ ニケーションの実現。経験豊富なエンジニアに よる高いスキルとノウハウをご提供致します。 お客様システムに合わせた独自監視プログラム の作成や、お客様業務に合わせたオペーレー ションを実施しております。 営業とお客様担当のエンジニア、オペレーショ ンエンジニアの体制を構築。それぞれの業務フ ローを効率化する事でスピーディーな対応を実 現しております。
  10. 10. ビッグデータ活用 10
  11. 11. 11 インフラ運用の観点から考えるAWS ~運用における利点と移行のポイント~
  12. 12. AWSと言えば? 12 データ活用 サーバレス IoT コンテナ 機械学習 AI
  13. 13. AWSと言えば? 13 Magic Quadrant for Cloud Infrastructure as a Service, Worldwide 出典:https://www.gartner.com/doc/reprints?id=1-2G2O5FC&ct=150519&st=sb EC2 VPC 覚えておきたいAWSサービス
  14. 14. ITインフラの運用とは? 14 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス 運用する範囲
  15. 15. ITインフラの運用とは? 15 障害の検知、復旧対応、「予防」 すべての障害を予め防ぐことは不可能 障害発生時の影響範囲をどれだけ減らすか
  16. 16. ITインフラの運用とは? 16 障害発生時の影響範囲を減らす コストの増大 トレードオフ ビジネスへの影響度から妥協点を探す
  17. 17. AWSへの移行とは? 17 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 PaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 SaaS/BaaS
  18. 18. AWSへの移行とは? 18 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS
  19. 19. 19 インフラ運用の観点から考えるAWS ~運用における利点と移行のポイント~
  20. 20. アジェンダ 20 ・コストについて ・移行先の設計と移行方法について ・移行後の運用について ・事例の紹介
  21. 21. コストについて 21
  22. 22. インフラ移行の時に考えないといけない5W1H 22 • Why? 何のために移行するのか? 移行の目的を明確化する • What? 何を移行するのか? IT資産を棚卸しした上で、移行対象のシステムを明確にする • Where? どこに移行するのか? 移行先の選定と設計 • How? どうやって移行するのか? 移行方法・ツールの選定 • When? いつまでに移行するのか? 移行までのタイムリミットの明確化 • Who? 誰が移行作業し、誰が運用するのか? 運用開始後も含めた担当者(or アウトソース先)の明確化
  23. 23. インフラ移行の時に考えないといけない5W1H 23 Why? 何のために移行するのか?
  24. 24. 何のためにAWSに移行するのか? 24 古いHWの更改 DCの閉鎖 拠点の引越 IT資産の棚卸 コスト削減 古いSW・MWの更改 柔軟な拡張性の獲得 開発効率化 新しい技術の採用 サービスレベルの向上 ITインフラを移行する目的 移行先をAWSにする目的+
  25. 25. 何のためにAWSに移行するのか? 25 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS 総務部管理 情シス管理 事業部管理
  26. 26. 何のためにAWSに移行するのか? 26 ハイパーバイザー 物理筐体 ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS /36
  27. 27. 何のためにAWSに移行するのか? 27 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS トータルコストで考えれば、かなりのコスト削減になる! TCO計算ツールも活用!
  28. 28. 運用する範囲 何のためにAWSに移行するのか? 28 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS インフラを運用・管理する人的コストは削減できるが、 ゼロになるわけではない
  29. 29. 何のためにAWSに移行するのか? 29 AWS上で稼働する システムに障害は 起きない? 障害は起きます! 障害発生時の影響範囲をいかに減らすか AWSはそのための機能を提供してくれている
  30. 30. 何のためにAWSに移行するのか? 30 出典:https://aws.amazon.com/jp/compliance/shared-responsibility-model/ AWSの責任共有モデル AWSの責任範囲を考えることが重要
  31. 31. 何のためにAWSに移行するのか? 31 AWSは障害発生時の影響範囲を減らすための 機能(選択肢)を提供してくれている 耐障害性 コスト トレードオフであることに変わりはない 「コスト削減」ではなく 「コスト最適化」と捉えた方がよい
  32. 32. 何のためにAWSに移行するのか? 32 古いHWの更改 DCの閉鎖 拠点の引越 IT資産の棚卸 コスト最適化 古いSW・MWの更改 柔軟な拡張性の獲得 開発効率化 新しい技術の採用 サービスレベルの向上 ITインフラを移行する目的 移行先をAWSにする目的+
  33. 33. 何を移行するのか?どこに移行するのか? 移行先の設計と移行方法について 33
  34. 34. インフラ移行の時に考えないといけない5W1H 34 What? 何を移行するのか? Where? どこに移行するのか?
  35. 35. 何を移行するのか?どこに移行するのか? 35 6つのアプリケーション移行戦略 • 再プラットフォーム化 (「リフト、手直し、シフト」) • 再ホスト (「リフトアンドシフト」) • 再購入 (「使用廃止、購入」) • リファクタリング/再設計 • リタイア • 保持 出典:https://aws.amazon.com/jp/cloud-migration/
  36. 36. 何を移行するのか?どこに移行するのか? 36 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 PaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 SaaS/BaaS or or
  37. 37. いつまでにAWSに移行しなければいけないのか? 37 ITインフラを移行する理由 移行先をAWSにする目的 古いHWの更改 DCの閉鎖 拠点の引越 IT資産の棚卸 コスト最適化 古いSW・MWの更改 柔軟な拡張性の獲得 開発効率化 新しい技術の採用 サービスレベルの向上 + とにかく機を逸してはいけない!
  38. 38. 何を移行するのか?どこに移行するのか? 38 リフトアンドシフト
  39. 39. 何を移行するのか?どこに移行するのか? 39 リフト まずはできるだけそのまま移行 EC2 VPC
  40. 40. 何を移行するのか?どこに移行するのか? 40 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 オンプレミス コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 PaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 SaaS/BaaS リフト シフト
  41. 41. Amazon Elastic Compute Cloud 41 AWSの仮想サーバのサービス • 細かな単位でのサーバスペックや台数の増減が短時間で可能 • 地理的に離れたデータセンター(AZ)をまたいだサーバ配置が簡単に • 基本的に利用した分だけの完全従量課金 stop • イメージの持ち込みや仮想ネットワークアプライアンスの導入も可能
  42. 42. ポイントをおさえればEC2の従量課金は怖くない 42  コンピューティング  ライセンス  ストレージ  トラフィック まずはカリキュレータを触ってみましょう!
  43. 43. Amazon Virtual Private Cloud 43 EC2を配置する 仮想ネットワークサービス • IPやサブネットを事由にに設計できるローカルネットワーク • FW機能(セキュリティグループ)は無料で使える • 拠点とのVPN接続や専用線接続も可能 →オンプレミスのネットワークをそのまま表現できる
  44. 44. AWSの設計 44 ONU ONU FW FW SW SW SW SW LB LB WEB/AP WEB/AP DB DB ルータ ルータ DMZPrivate Public Subnet Public Subnet Private Subnet Private Subnet LB LB WEB/AP WEB/AP DB DB 基本的な設計を変えずにそのまま持ち込めるので まずはEC2とVPCで考えてみる Availability Zone Availability Zone
  45. 45. AWSの設計 45 Public Subnet Public Subnet Private Subnet Private Subnet LB LB WEB/AP WEB/AP DB DB PaaS(マネージドサービス)への置き換えを考えてみる 考えないといけないこと ・LBのVIPってどうなる? ・LBがアクセス増のボトルネックに? ・DBのデータ同期はどうする? ・DB障害時の切り替えは? ・DBのバックアップは?Availability Zone Availability Zone
  46. 46. AWSの設計 46 Public Subnet Public Subnet Private Subnet Private Subnet WEB/AP WEB/AP 再設計の必要性が少なく、メリットが明確な部分だけ マネージドサービスの導入を検討 Elastic Load Balancer マネージドロードバランサー Availability Zone Availability Zone • AZとまたいだ配置・振り分け可能 • VIPの切り替え等は意識しなくてよい • 高負荷時は自動でスケール • レプリケーション設定は数クリックで • 障害時の切り替えは自動 • 無停止の自動バックアップ Relational Database Service マネージドデータベース
  47. 47. どうやって移行するのか? 47 Step1 アプリケーション稼働確認 Step2 データ移行 Step3 切り替え 完全従量課金なので 計画段階で実施してしまう 無料枠に収まるかも? ダウンタイムが許容できるのであれ ば難しく考えずにダンプ/リストア ダウンタイムNGやデータ容量が多 い場合はツールの利用を検討 DNSレコードの切り替えが王道 Route53やCloudFrontを先行導入 しておくと切り替えがスムーズ AWS DMS AWS SMS AWS Snowball
  48. 48. 移行後の運用について 48
  49. 49. 運用のポイント① 49 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS 障害の検知・復旧対応は引き続き必要 Cloud Watchのデフォルト監視だと不足あり 初めは手動対応→徐々に自動化 EC2&VPCも進化し続けているので 新機能は常にチェックして、採用
  50. 50. 運用のポイント② 50 コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 IaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 PaaS コンテンツ アプリケーション MW/ランタイム OS ハイパーバイザー 物理筐体 ラック/空調 物理スペース ネットワーク/電源 SaaS/BaaS シフト(最適化)を継続し続ける
  51. 51. 事例の紹介 51
  52. 52. Webサービスプロバイダー様 AWS移行+運用サポート事例 概要 6ラック分の物理サーバをEC2&VPCに移行 移行のポイント ブラックボックス化してしまっていたシステム構成を移行を期に棚卸し 調査 1~2ヶ月 検証/環境構築 1ヶ月 移行 1~2ヶ月 移行メリット システム構成の明確化 ランニングコストの圧縮
  53. 53. 自治体様 災害時情報共有システム AWS移行+運用サポート事例 協業パートナー 株式会社ファルコン様 概要 災害時情報共有システムの更新に伴いホスティン グサービスからAWSへ移行 移行のポイント データセンター内のシステムとの連携 NFSサーバの冗長化 mongoDBの冗長化 ログインセッションの管理 移行メリット 災害発生時・訓練時の柔軟なスケールアウト 平常時のインスタンス数を抑えられた マルチAZで地理的冗長性を確保 バックアップ・リストアがシンプルに WEP/APP WEP/APP DB DB NFS NFS 東京リージョン データセンター VPN接続
  54. 54. ミズノ株式会社様 コーポレートサイト 運用サポート事例 ブラックボックス化している情報を整理、コストを最適化。安定したAWSの運用を実現 ■導入前の課題 ■導入後の効果と今後の展望 ■お客様構成一例 ■NHNテコラスを選んだ理由 ・AWSをコーポレートサイトのインフラとして利用しているが、専門スキルを持った人材が 少ないために、MSP事業者にAWSの運用を任せきりの状態であった。 ・現状の構成・設定や稼働状況などを全く把握できておらず、障害発生のリスクに 対応できない状況であった。また運用管理コストの高さも課題になっていた。 ・用途によって運用のサービスレベルを分けた提案により、他社よりも明確に コストの削減が見込めた。 ・AWSのサービス構成の最適化提案により「AWSを熟知している信頼できるMSP事業者 だ」と認識できた。 ・丁寧なアセスメントとレポートにより構成情報がクリアに。 ・依頼に対する対応が非常に早いので待ち時間のストレスがなくなった。 ・現環境の改善ポイントが明確になったため、最適化を進めていくことが可能に。 社名 ミズノ株式会社 事業内容 総合スポーツメーカー 設立 1906年4月1日 従業員数 5,273名(2017 年3月31日時点、連結) ・3割の運用コスト削減に成功。 ・綿密な運用設計とドキュメント作成で運用内容が明確化。
  55. 55. まとめ 55
  56. 56. まとめ 56 ・コストについて →コスト削減ではなくコスト最適化 ・移行先の設計と移行方法について →リフトアンドシフト(とくにかく始める) ・移行後の運用について →継続的シフト(最適化)を忘れない
  57. 57. n h n - t e c h o r u s . c o m 57 ご静聴ありがとうございました!
  58. 58. 58 https://cloudnavi.nhn-techorus.com/archives/395

×