クラウド時代に必要なインフラスキル / Capabilities for IaaS

Transcript

1. Copyright © NHN Techorus Corp. クラウド時代に必要なインフラスキル NHN テコラス株式会社 ⾓ 俊和
2. Page 2 ⾃⼰紹介 ⾓俊和（すみ・としかず） •  NHNテコラス株式会社 執⾏役員 •  IaaSブランド「CloudGarage」事業責任者 •  経歴：通信キャリア・メディア企業にて開発、事業統括等  10年以上インフラ事業やってます。元Webエンジニア。 •  趣味：ロードバイクで⻑距離⾛ること、プログラミング •  Twitter: @techsmith8 •  facebook: toshikazu.sumi
3. Page 3 会社紹介 データセンター／インフラ提供17年⽬の⽼舗事業者。 設計・構築・運⽤をワンストップで提供。 【主なサービス内容】 •  ホスティングサービス（物理／仮想） •  コロケーションサービス •  インフラ設計・構築・運⽤（MSP) •  インテグレーション •  構築・運⽤設計 •  技術導⼊・運⽤⽀援 •  H/W最適化 •  事前検証、負荷テスト、チューニング •  プロジェクトマネジメント 東京都内に2箇所の⾃社運営iDC 「データホテル」はインターネット 黎明期から続く⽼舗ブランド。 イ ン タ ー ネ ッ ト 黎 明 期 か ら の 1 7 年 以 上 に 及 ぶ ⻑ い 経 験 と 、 管 理 稼 働 サ ー バ 数 10,000台 以 上 を 誇 る 豊 富 な 実 績
4. Page 4 アジェンダ •  ITインフラの種類と特性 •  ITインフラの賢い使い⽅ •  エンジニアが⾝につけるべきインフラスキルとは
5. Page 5 ITインフラの種類と特性
6. Page 6 ITインフラの特性１：ITインフラサービスの種類と性質 OS仮想化技術の登場により、ハードウェアのサービスだったITインフラ は、「クラウド」になった。「クラウド」サービスは増加し続けている。 ＜ITインフラサービスの歴史＞ •  90年代：インターネットデータセンターサービス誕⽣  （ハウジング／コロケーション／ホスティング） •  1999：Vmware誕⽣（初のx86仮想化） •  2006：Amazon Web Services •  2007：Heroku •  2008：Google App Engine •  2010：Microsoft Azure •  2011：AWS東京リージョン開設 •  2011：さくらのクラウド •  2011：Firebase ※後にGoogleが買収 •  2013：Google Compute Engine •  2014：AWS Lambda
7. Page 7 ITインフラの特性１：ITインフラサービスの種類と性質 クラウドの登場によりインフラは乗り換えやすいものになった。 •  OS仮想化技術の登場によりハードウェアのサービスだったITインフラは、  「クラウド」になった。 •  ハードウェアインフラに⽐べると、クラウドインフラの⽅がデータ移 動・複製がしやすい。 •  サービス事業者も多く、インフラ環境の移動がしやすい時代になった。
8. Page 8 ITインフラの特性２：システム環境 •  利⽤者の端末・ネットワーク性能は年々⼤きく進化していく。 •  サーバー・インフラに求められる性能が⾼くなっていく（速度・容量） •  ⼀度構築したインフラ環境の性能は変わらない。 •  スペック・性能はそのまま •  インフラサービスの料⾦もそのまま •  必然的に利⽤者側とサーバー側でのGAPが⽣まれる。  （遅い・⾜りないと感じるようになる） •  ※そもそも、システム構築当初の負荷予想は⼤抵外れる。 •  インフラ性能に過不⾜が発⽣する（⼤きすぎ or 少なすぎ） 開発・構築したシステムは、年⽉が経過するとインフラ環境 の性能が⾒合わなくなる
9. Page 9 ITインフラの特性３：システム環境 開発・構築システムは、時間が経過すると再構築・移動することが 難しくなる •  構築当時のバージョンではインストールできないこともある •  脆弱性問題などで提供が終了している •  OSSを最新バージョンにするとシステム全体が動かなくなることもある。 •  そもそも構築当初に検証していないバージョン •  当初の構築ノウハウが失われているケースも多い •  担当者が退職している •  ドキュメントを残していなかった
10. Page 10 ITインフラの特性：まとめ •  ITインフラサービスの特性： •  「仮想化技術」の登場によりインフラは「クラウド」にな り、乗り換えやすいものになった •  システム環境の特性： •  時間が経過すると、インフラ環境の性能が⾒合わなくなる。 変更／移動したほうが良い •  システムは時間が経過すると再構築・移動することが難し くなる 乗り換えやすい便利インフラが増えているが、 ⼀度開発したシステムは、時間が経つと動かしづらくなるため、 最新のインフラサービスへの移動が難しい。
11. Page 11 ITインフラの賢い使い⽅
12. Page 12 ITインフラの賢い使い⽅ ＜ポイント＞ 1.  性能が⾒合わなくなったらインフラを乗り換える •  初期構築時：スキルと要件に応じてインフラサービスを選ぶ •  性能に⾒合わなくなっていることを検知する •  変化に応じて、適切なインフラサービスに移動する。 2.  移動しやすい設計にしておく 性能が⾒合わなくなったら、インフラを乗り換えた⽅が良い。 それがクラウド時代のインフラの賢い使い⽅。
13. Page 13 インフラサービスを乗り換える 1. 初期構築時：スキルと要件に応じてインフラサービスを選ぶ •  要件とスキルを踏まえて、⾃社で管理するインフラレイヤを決める •  スキル：どのレイヤまで管理できるインフラエンジニアがいるか。 •  システム要件：どのレイヤまで作らないと要件に対応できないか •  可⽤性要件：どのレイヤまでの障害を許容・コントロールするべきか DC DC DC DC DC DC H/W H/W H/W H/W H/W OS OS OS OS Middleware Middleware Middleware Apps (backend) Apps (backend) Program ハウジング ホスティング IaaS PaaS BaaS FaaS Equinix, NTT, KDDI AWS, GCP, Microsoft Azure Heroku, レンタルサー バー Google Firebase AWS Lambda 代表的な サービス インフラサービスは、提供レイヤ ごとに細かく分かれている
14. Page 14 インフラサービスを乗り換える •  インフラサービスの選び⽅（スキル別） •  HWとNWに詳しいエンジニアがいる➝ハウジング、ホスティング •  OSとNWとMWに詳しいエンジニアがいる➝IaaS •  M/W周りに詳しいエンジニアがいない➝PaaS, BaaS, FaaS •  代表的なインフラサービス •  IaaS：aws, Microsoft Azure, GCP •  PaaS：Heroku, webhosting（レンタルサーバー） •  BaaS：Google Firebase, Milkcocoa •  FaaS：AWS Lambda
15. Page 15 インフラサービスを乗り換える 2. 性能に⾒合わなくなっていることを検知する •  環境の変化に伴い、性能／コストの過不⾜などが問題になる •  外部環境の変化 •  利⽤者環境の変化（ガラケー➝スマホ等）➝性能が不⾜ •  想定よりもアクセスが多い➝性能が不⾜ •  想定よりもアクセスが少ない➝性能が過剰（無駄なコスト） •  機能要件の変更（システムの修正） •  変化／問題を検知・計測・予測することが⼤切 •  稼働状況の監視 •  プロセス監視、外形監視、バッチ処理など •  リソース利⽤状況モニタリング •  CPU, MEM, HDD, NW帯域など •  ビジネスKPIの把握 •  PV、Session、CV、売上など
16. Page 16 インフラサービスを乗り換える •  代表的な監視ツール •  OSS：Zabbix, Nagios, Sensu •  サービス：Mackerel, PagerDuty, Datadog
17. Page 17 インフラサービスを乗り換える 3. 変化に応じて、適切なインフラサービスに移動する。 1.  変化した状況に応じて要件を再定義。 •  変化を検知・予測することで、リソースが不⾜する前に移動の要否を判断 できる。（キャパシティプランニング） 2.  適切なインフラサービスを選定（選び⽅は最初と同じ） 3.  システムを移⾏する •  移⾏しやすい設計にしておく必要がある。 ※要件に合わなくなったインフラを放置すると、  「負の遺産」になっていきます。
18. Page 18 移動しやすい設計にしておく •  移動しやすいシステムとは ※＝ポータビリティ（可搬性、移植性）の⾼い設計 •  モノリシックではなくマイクロサービス •  モジュール化 •  疎結合 •  作業⼿順のコード化 •  下位技術レイヤの抽象化（仮想化） ITインフラは環境の変化に伴い、変化していく必要がある。 エンジニアは、ポータビリティの⾼い、変化に強い設計を意識するべき
19. Page 19 移動しやすい設計にしておく 構成要素ごとに独⽴したコンポーネントを組み合わせる設計を意識するこ とで、システムのポータビリティを⾼めることができる。 ポータビリティを⾼める技術の例 技術レイヤ 技術要素 ツール、技術例 アプリ 再利⽤性・可読性の⾼いコードを書く オブジェクト指向、MVC、Flux アーキテクチャ システムを細かいコンポーネントに分 割して設計しておく。 Web Application Framework, Microservice architecture, Single Page Application ミドルウェア インフラの構築時に構成管理ツールを 利⽤する。再構築が容易になる Chef, Ansible, Puppet OS 仮想OSを使う。インフラ環境が「イ メージ」として持ち運びできる状態に なる。 VMware, KVM, OpenStack, Docker, Vagrant, kubernetes
20. Page 20 ポータビリティの⾼い設計のその他のメリット ポータビリティの⾼い設計はその他のメリットも多い。 ポータビリティを意識することで、柔軟性の⾼いシステムが作れる。 •  ポータビリティの⾼い設計のその他のメリット •  拡張性が⾼い •  透明性が⾼い •  属⼈化しづらい •  再利⽤性が⾼い
21. Page 21 移動しやすい設計にしておく OSSに致命的な脆弱性が発覚。対策 バージョンは後⽅互換性がないため、 対応するとシステムが動かなくなる ⾼負荷を想定して ⾼価なインフラ機器で構築したものの、 アクセスが来なくてスカスカ。 インフラのランニングコストが無駄 バージョンアップするとどこに影 響が出るかわからない中、システ ム全体の修正・検証作業に突⼊... （突貫作業へ） 再構築するのも⼿間とコストがか かるので、インフラコストは 無駄だけど、そのまま放置。 事例 対処 本番と同⼀構成の開発環境が必要に なった。⼿順が整理されていないので 同じ環境を再現するのはかなり⼤変 時間が無いので、本番環境で 無理やり開発をやることに。 （セキュリティなどトラブルの温床） ポータビリティの低いシステムの場合（実話）
22. Page 22 移動しやすい設計にしておく OSSに致命的な脆弱性が発覚。対策 バージョンは後⽅互換性がないため、 対応するとシステムが動かなくなる ⾼負荷を想定して ⾼価なインフラ機器で構築したものの、 アクセスが来なくてスカスカ。 インフラのランニングコストが無駄 マイクロサービス／疎結合になっ ていれば、当該コンポーネントの みの検証でOK。 構成管理ツール を⽤いて構築していれば、 異なる環境で 簡単に再構築できる。 事例 対処 本番と同⼀構成の開発環境が必要に なった。⼿順が整理されていないので 同じ環境を再現するのはかなり⼤変 ポータビリティの⾼いシステムの場合
23. Page 23 まとめ •  クラウドにより、インフラは乗り換えしやすいものになった。 •  ITインフラは時間が経過すると負の遺産になる •  状況が変化したらインフラを積極的に乗り換えるべき •  エンジニアは、変化に強い設計を意識するべき インフラは固定的なものではなく、動かせるものだと考えるべき。 システム全体のポータビリティを⾼めることができるスキルが⼤切。
24. Page 24 最後に宣伝 ※開発者向けにインスタンス無料利⽤のご案内をしております 是⾮ブースにお⽴ち寄りください。
25. Page 25 Thanks!