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.

Infraengineer In The Datacenter

2,327 views

Published on

福岡ゆるっとIT交流会 vol.8「インフラエンジニアの話を聞こう」講演資料

Published in: Internet
  • Be the first to comment

Infraengineer In The Datacenter

  1. 1. データセンターに生息する インフラエンジニアの話 これまでとこれから 2018/11/1 (C) Copyright 1996-2018 SAKURA Internet Inc さくらインターネット研究所 鷲北 賢さくらインターネット株式会社
  2. 2. 自己紹介 • 鷲北 賢(わしきた けん) • 1998年4月入社 • バックボーンのお守りからサービス開発まで ─ 初期の専用サーバ、データセンター構築 ─ オンラインゲームプロジェクト ─ さくらのクラウド開発マネージャー、などなど • 2009年より、さくらインターネット研究所 所長 ─ 仮想化技術の研究(Linux KVM) ─ 高性能リソースを分割するより小型計算機を集めて高性能化する ほうに興味あり • @ken_washikita、https://facebook.com/ken_washikita 2
  3. 3. 3 さくらにとって インフラとは? 3
  4. 4. 比較的低レイヤなインフラの例 • 土地、建物
  5. 5. 比較的低レイヤなインフラの例 5 • 電力、空調 • 非常用設備
  6. 6. 比較的低レイヤなインフラの例 • ラック、ケーブル • ゲート、警備 6
  7. 7. さくらでは「ハード」と呼ばれるインフラの例 • サーバ • ネットワーク • ストレージ 7
  8. 8. システム/ソフトもインフラかな? 8
  9. 9. 9 なんてやってると 話が まとまらない
  10. 10. 10 そこで クラウドを支える インフラの話
  11. 11. 11 さて時代は CLOUD NATIVE ですが
  12. 12. 12 AWS上に さくらのクラウドを 構築するわけには いかないワケです
  13. 13. 13 全部 ハードウェアで 作るしかない
  14. 14. 14 インフラエンジニアと プログラマの 出番
  15. 15. 15 というわけで これでわかる さくらのクラウド の作り方
  16. 16. さくらのクラウド(初回MTGのアジェンダより) • しっかりとしたサーバ基盤を作る ─ PaaS、SaaSをホストできるIaaSとする ─ ex) さくらのレンタルサーバをホストする • サーバ/ネットワーク/ストレージを仮想化する • 時間課金を実現する • ミーティングは短く
  17. 17. VMをホストするサーバ • ハイパーバイザを準備(KVMを採用) • オーダーが来たらポンと作成する • サーバはCPUとメモリ を提供 • ネットとディスクは 別に作成する ホストサーバ VM
  18. 18. ディスク領域を保持するストレージ • ストレージ上に領域を切り出しVMに ディスクとして接続 • サーバとストレージを分離することで 柔軟性を確保 18 ホストサーバ VM disk ストレージ
  19. 19. 仮想ネットワークのエッジ • VMホストの仮想ポートをホスト内の OVSに接続 • OVSを物理ポートを 介してクラウドL2網へ • 問題はプロトコル 19 ホストサーバ OVS VM 物理回線の内に 仮想ポート・仮想SW・ 仮想回線リンクを通す VM
  20. 20. テナント分離のための仮想ネットワーク(1) 20 このような仮想システムをIaaS上に展開する場合 ルータ FW LB Webサーバ Webサーバ DBサーバ DBサーバ VPN インターネット VPN
  21. 21. テナント分離のための仮想ネットワーク(2) 21 網内でユニークなVLANを各回線に割り当てる VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106ルータ FW LB Webサーバ Webサーバ DBサーバ DBサーバ VPN インターネット VPN
  22. 22. テナント分離のための仮想ネットワーク(3) 22 VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106 ルータ FW LB WEB WEB DB DB VPN ホストサーバA ホストサーバB ホストサーバC L2網(コアスイッチ、エッジスイッチ、仮想スイッチ) 仮想スイッチ 仮想スイッチ 仮想スイッチ インターネット VPN VMをホストサーバに配置し、割り当てたVLANに接続
  23. 23. 物理構成はこんな感じ 23 エッジスイッチ エッジスイッチ エッジスイッチ エッジスイッチ ホストサーバ ホストサーバ ホストサーバ ホストサーバ ルータ ルータ ルータ ルータ インターネット VPN 仮想スイッチ 仮想スイッチ 仮想スイッチ仮想スイッチ VM VM VM VM VM VM VM VM コアスイッチ コアスイッチ たくさんのVLANを 通しておく LAG bonding タグVLAN タグVLAN タグVLAN
  24. 24. APIとUI • 構成要素の制御はすべてAPIで行う • UI(コンパネ)はAPIを叩くインター フェースとして構成 24 APIUI ホスト サーバ ストレージ ネットワーク
  25. 25. 2011年のスケジュール 25 3 4 5 6 7 8 9 10 11 12 3/2 社長に呼び出される 3/10 キックオフミーティング 担当ごとに調査・検討 仕様摺り合わせ/UIデザイン合宿 機材選定・テスト 発注・構築準備 API/UI開発 βサイト構築 オープンβ@大阪 発注・構築準備 石狩サイト構築 API/UIデプロイ API/UIデプロイ 11/15 サービス開始 デバッグ・テスト
  26. 26. 11月のスケジュール 26 10/31 1 2 3 4 7-14 11/15 機材納品・開梱 ホストサーバOSイメージ作成 機材設置・電源投入 config/接続 ネットワーク単体試験 バックボーン接続試験 テスト・イメージコピー ホストサーバ単体試験 結合試験 後片付け システム起動 最終試験 石 狩 IDC 開 所 と 同 時 に リ リ ー ス デプロイ開始
  27. 27. サーバの開梱と設置 27 • 本来ならDCOPが納品受 付してくれる • しかしOPチームが存在 しないので通路で開梱 • キッティングルームが 整備されていないので 通路で組立 • 負荷がゼロなので空調 ファンが回っていない ※ 第3号棟は超すばらし い設備が整っています
  28. 28. ラッキング後のサーバ 28 • 本来ならDCOPチーム のすばらしいラッキン グ作業で組み上がる • しかし(以下同文) • 研究所のヘルプ要員と 新規事業室の開発要員 が組み上げた ※ 後で「配線ルール違 反」と怒られました
  29. 29. ルータとスイッチのセットアップ 29 • 一応キッティング ルームで作業中 • ところが机がないの で台車で作業してい るありさま • 車で20分のところに PCショップがあって ケーブルやキーボー ドは充実している • ホームセンターで安 全靴も買える
  30. 30. ところでイメージコピーっていう工程はなに? 30
  31. 31. 本来のホストサーバ構築 31 • KickstartとAnsibleで全自動化されている ─ラッキングした後、電源を入れるだけ ADMIN-SW [1] [2] [3] [4] HOST-1 HOST-2 HOST-3 HOST-4 1. 電源を入れるとSWにMACが聞こえてくる 2. show mac tableで対応表を取得 3. 割当ラックとポート番号からサーバ名とIP アドレスを決定 4. ホストをブートしKickstartでOSをセット アップ 5. Ansibleでサーバ個別の設定を実行 クラウドシステムに組み込み PXEBOOT TFTP server
  32. 32. サーバ担当が直面した現実 32 • だが、インフラが整っていることが前提 ─管理ネットワークが存在し、 ─TFTPサーバが存在し、 ─完全に動作するパッケージがあって、 ─MACアドレステーブルが完備していれば。 • しかし(以下同文) ─当時の石狩IDCには文字通り「何もナイ」
  33. 33. サーバ担当がやったこと 33 ① 仮組みしたシステムで ホストのマスターを作成 ② マスターを物理 コピーして2台に 増やして…
  34. 34. サーバ担当がやったこと 34 ③ 倍々に増やし、10台の コピーマシンで120台まで コピーし続けた
  35. 35. 35 おわかり いただけましたか?
  36. 36. CLOUD NATIVEの時代 36
  37. 37. 37 ユーザは クラウドサービスを 謳歌
  38. 38. 38 しかし インフラ屋は そうはいかない
  39. 39. CLOUD NATIVEの時代なのに… • どのようなクラウドサービスも、裏では ハードで動いている • 物理インフラ無しでは何もできない • さくらのクラウドの場合 ─32,000VMを収容するために 1500台のホストと4PBのストレージを運用 • 今もせっせと機材を構築し続けている 39
  40. 40. 40 インフラエンジニアの スキルセット
  41. 41. さくらインターネットの場合 • パブリック・サービスが多い ─特定用途にチューニングできない ─あらゆる用途で及第点を取らなければならない ─ 機材の性能を安定かつ最大まで搾り取る • 垂直統合されたデータセンター事業者 ─単一事業者が土地をもち、コンパネを開発する ─ すべてのコストをコントロールできる
  42. 42. 例:サーバ選定業務 • サービス仕様理解 ─ サーバスペックへの落とし込み • 機種選定 ─ 候補選定、手配 ─ テスト設計、実施 ─ 結果の報告、検討、決定 • 調達 ─ 調整、納品、検品 • 設置 ─ ラック設計、配線設計 ─ 手配、実施 42 用途はもちろんだが 提供価格に対する 集積度やパーツ構成 を加味してスペック を決定する さくらには特定事業者 への依存がなく 節目ごとに3~4社のコ ンペを実施する 技術面だけでなくコス トで導入断念というこ ともよくある 運用しやすさも選定の際の 大きな要素でDCOPの反対で 機種変更になることも 逆にサービス側エンジニアの 意見でラック仕様を変更する こともある
  43. 43. 例:ネットワークエンジニア • 実は分業が進んでいる ─ BORDER/InterDC/Service • サービスは「先端的、柔軟」 ─ 仕様や顧客要望に応じて変化が求められる ─ ネットワーク以外の機材も絡むため、障害対応体制も若干異なる • ボーダーは「保守的、堅実」 ─ 安定運用が絶対命題 ─ そのために手間をかけた運用ルールを自らに課して実行している ─ 一方でDDOS自動検知システムを自作するなど「さくららしさ」も忘れない • 利用しているプロトコルは多種多様 ─ eBGP、iBGP、OSPF、MPLSなど • 利用している機材も多種多様 ─ Brocade(Foundry)、Juniper、ARISTA、Apresia(伝統的にCISCOが苦手) 43
  44. 44. 44 こんな調子で トピックを拾って いってもいいんですが
  45. 45. 45 きりがないんで やめときます
  46. 46. 一般論で言うと • 基礎知識として; ─ サーバ/ネットワーク/ストレージ ─ バランスの取れた幅広い知識が必要 • その上で専門知識として; ─ 特定分野や、開発/運用/管理などの職種ごとのスペ シャリストとして知識を深める • 自分の領分と隣接分野、さらにその先まで ─ 広げていかないと話が通じない、納得できない 46
  47. 47. ただしインフラという言葉は変化する… • ITサービスにおけるインフラ(アプリサイトやゲーム) ─ 高負荷処理/アプリ固有処理/超多数セッション処理 • 情報システムにおけるインフラ(ビジネスサイトや金融、官公庁) ─ ゼロダウンタイム/DR/多重バックアップ/物理セキュリティ • HPCにおけるインフラ(大学や研究機関) ─ 超高集積/インターコネクティビティ/特殊冷却 • クラウド基盤上の「インフラ」 ─ サービス理解(仕様と実装)/インタークラウド 47
  48. 48. インフラ担当者の領分も変化する… 48 Business Logic UI(Presentation) Data Access Infrastructure
  49. 49. インフラの定義も変化する… • Immutable Infrastructure ─サーバのライフサイクルは短くなる一方 ─FaaSの登場で時間単位どころか分・秒単位に • Infrastructure as Code ─CLOUD NATIVEはインフラをプログラムする ─デプロイまで何時間もかかるシステムなんて 誰も使わない 49
  50. 50. インフラエンジニアの二極化 50 先端『サービス』は どんどん進むが レガシーシステムは 注目されなくなる
  51. 51. インフラエンジニアの二極化 51 『サービス』ではフォロー できないシステムは存在し これらは変わらず物理イン フラやミドルウェアで支え られる
  52. 52. 52 あなたは どちら? どっちがいいとかいう話ではありません
  53. 53. 53 おしまい

×