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

1. データセンターに生息する
インフラエンジニアの話
これまでとこれから
2018/11/1
(C) Copyright 1996-2018 SAKURA Internet Inc
さくらインターネット研究所 鷲北 賢さくらインターネット株式会社

2. 自己紹介
• 鷲北 賢（わしきた けん）
• 1998年4月入社
• バックボーンのお守りからサービス開発まで
─ 初期の専用サーバ、データセンター構築
─ オンラインゲームプロジェクト
─ さくらのクラウド開発マネージャー、などなど
• 2009年より、さくらインターネット研究所 所長
─ 仮想化技術の研究（Linux KVM）
─ 高性能リソースを分割するより小型計算機を集めて高性能化する
ほうに興味あり
• @ken_washikita、https://facebook.com/ken_washikita
2

3. 3
さくらにとって
インフラとは？
3

4. 比較的低レイヤなインフラの例
• 土地、建物

5. 比較的低レイヤなインフラの例
5
• 電力、空調
• 非常用設備

6. 比較的低レイヤなインフラの例
• ラック、ケーブル
• ゲート、警備
6

7. さくらでは「ハード」と呼ばれるインフラの例
• サーバ
• ネットワーク
• ストレージ
7

8. システム／ソフトもインフラかな？
8

9. 9
なんてやってると
話が
まとまらない

10. 10
そこで
クラウドを支える
インフラの話

11. 11
さて時代は
CLOUD NATIVE
ですが

12. 12
AWS上に
さくらのクラウドを
構築するわけには
いかないワケです

13. 13
全部
ハードウェアで
作るしかない

14. 14
インフラエンジニアと
プログラマの
出番

15. 15
というわけで
これでわかる
さくらのクラウド
の作り方

16. さくらのクラウド（初回MTGのアジェンダより）
• しっかりとしたサーバ基盤を作る
─ PaaS、SaaSをホストできるIaaSとする
─ ex) さくらのレンタルサーバをホストする
• サーバ／ネットワーク／ストレージを仮想化する
• 時間課金を実現する
• ミーティングは短く

17. VMをホストするサーバ
• ハイパーバイザを準備（KVMを採用）
• オーダーが来たらポンと作成する
• サーバはCPUとメモリ
を提供
• ネットとディスクは
別に作成する
ホストサーバ
VM

18. ディスク領域を保持するストレージ
• ストレージ上に領域を切り出しVMに
ディスクとして接続
• サーバとストレージを分離することで
柔軟性を確保
18
ホストサーバ
VM disk
ストレージ

19. 仮想ネットワークのエッジ
• VMホストの仮想ポートをホスト内の
OVSに接続
• OVSを物理ポートを
介してクラウドL2網へ
• 問題はプロトコル
19
ホストサーバ
OVS
VM
物理回線の内に
仮想ポート・仮想SW・
仮想回線リンクを通す
VM

20. テナント分離のための仮想ネットワーク（１）
20
このような仮想システムをIaaS上に展開する場合
ルータ FW
LB
Webサーバ Webサーバ
DBサーバ DBサーバ
VPN
インターネット VPN

21. テナント分離のための仮想ネットワーク（２）
21
網内でユニークなVLANを各回線に割り当てる
VLAN101 VLAN102
VLAN103
VLAN104
VLAN105
VLAN106ルータ FW
LB
Webサーバ Webサーバ
DBサーバ DBサーバ
VPN
インターネット VPN

22. テナント分離のための仮想ネットワーク（３）
22
VLAN101
VLAN102
VLAN103
VLAN104
VLAN105
VLAN106
ルータ FW LB WEB WEB DB DB VPN
ホストサーバA ホストサーバB ホストサーバC
L2網(コアスイッチ、エッジスイッチ、仮想スイッチ)
仮想スイッチ 仮想スイッチ 仮想スイッチ
インターネット VPN
VMをホストサーバに配置し、割り当てたVLANに接続

23. 物理構成はこんな感じ
23
エッジスイッチ エッジスイッチ エッジスイッチ エッジスイッチ
ホストサーバ ホストサーバ ホストサーバ ホストサーバ
ルータ ルータ ルータ ルータ
インターネット VPN
仮想スイッチ 仮想スイッチ 仮想スイッチ仮想スイッチ
VM VM VM VM VM VM VM VM
コアスイッチ コアスイッチ
たくさんのVLANを
通しておく
LAG
bonding
タグVLAN
タグVLAN
タグVLAN

24. APIとUI
• 構成要素の制御はすべてAPIで行う
• UI（コンパネ）はAPIを叩くインター
フェースとして構成
24
APIUI
ホスト
サーバ
ストレージ
ネットワーク

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. 11月のスケジュール
26
10/31 1 2 3 4 7-14 11/15
機材納品・開梱
ホストサーバOSイメージ作成
機材設置・電源投入
config/接続
ネットワーク単体試験
バックボーン接続試験
テスト・イメージコピー
ホストサーバ単体試験
結合試験
後片付け
システム起動
最終試験
石
狩
IDC
開
所
と
同
時
に
リ
リ
ー
ス
デプロイ開始

27. サーバの開梱と設置
27
• 本来ならDCOPが納品受
付してくれる
• しかしOPチームが存在
しないので通路で開梱
• キッティングルームが
整備されていないので
通路で組立
• 負荷がゼロなので空調
ファンが回っていない
※ 第3号棟は超すばらし
い設備が整っています

28. ラッキング後のサーバ
28
• 本来ならDCOPチーム
のすばらしいラッキン
グ作業で組み上がる
• しかし（以下同文）
• 研究所のヘルプ要員と
新規事業室の開発要員
が組み上げた
※ 後で「配線ルール違
反」と怒られました

29. ルータとスイッチのセットアップ
29
• 一応キッティング
ルームで作業中
• ところが机がないの
で台車で作業してい
るありさま
• 車で20分のところに
PCショップがあって
ケーブルやキーボー
ドは充実している
• ホームセンターで安
全靴も買える

30. ところでイメージコピーっていう工程はなに？
30

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
• だが、インフラが整っていることが前提
─管理ネットワークが存在し、
─TFTPサーバが存在し、
─完全に動作するパッケージがあって、
─MACアドレステーブルが完備していれば。
• しかし（以下同文）
─当時の石狩IDCには文字通り「何もナイ」

33. サーバ担当がやったこと
33
① 仮組みしたシステムで
ホストのマスターを作成
② マスターを物理
コピーして2台に
増やして…

34. サーバ担当がやったこと
34
③ 倍々に増やし、10台の
コピーマシンで120台まで
コピーし続けた

35. 35
おわかり
いただけましたか？

36. CLOUD NATIVEの時代
36

37. 37
ユーザは
クラウドサービスを
謳歌

38. 38
しかし
インフラ屋は
そうはいかない

39. CLOUD NATIVEの時代なのに…
• どのようなクラウドサービスも、裏では
ハードで動いている
• 物理インフラ無しでは何もできない
• さくらのクラウドの場合
─32,000VMを収容するために
1500台のホストと4PBのストレージを運用
• 今もせっせと機材を構築し続けている
39

40. 40
インフラエンジニアの
スキルセット

41. さくらインターネットの場合
• パブリック・サービスが多い
─特定用途にチューニングできない
─あらゆる用途で及第点を取らなければならない
─ 機材の性能を安定かつ最大まで搾り取る
• 垂直統合されたデータセンター事業者
─単一事業者が土地をもち、コンパネを開発する
─ すべてのコストをコントロールできる

42. 例：サーバ選定業務
• サービス仕様理解
─ サーバスペックへの落とし込み
• 機種選定
─ 候補選定、手配
─ テスト設計、実施
─ 結果の報告、検討、決定
• 調達
─ 調整、納品、検品
• 設置
─ ラック設計、配線設計
─ 手配、実施
42
用途はもちろんだが
提供価格に対する
集積度やパーツ構成
を加味してスペック
を決定する
さくらには特定事業者
への依存がなく
節目ごとに3～4社のコ
ンペを実施する
技術面だけでなくコス
トで導入断念というこ
ともよくある
運用しやすさも選定の際の
大きな要素でDCOPの反対で
機種変更になることも
逆にサービス側エンジニアの
意見でラック仕様を変更する
こともある

43. 例：ネットワークエンジニア
• 実は分業が進んでいる
─ BORDER／InterDC／Service
• サービスは「先端的、柔軟」
─ 仕様や顧客要望に応じて変化が求められる
─ ネットワーク以外の機材も絡むため、障害対応体制も若干異なる
• ボーダーは「保守的、堅実」
─ 安定運用が絶対命題
─ そのために手間をかけた運用ルールを自らに課して実行している
─ 一方でDDOS自動検知システムを自作するなど「さくららしさ」も忘れない
• 利用しているプロトコルは多種多様
─ eBGP、iBGP、OSPF、MPLSなど
• 利用している機材も多種多様
─ Brocade(Foundry)、Juniper、ARISTA、Apresia（伝統的にCISCOが苦手）
43

44. 44
こんな調子で
トピックを拾って
いってもいいんですが

45. 45
きりがないんで
やめときます

46. 一般論で言うと
• 基礎知識として；
─ サーバ／ネットワーク／ストレージ
─ バランスの取れた幅広い知識が必要
• その上で専門知識として；
─ 特定分野や、開発／運用／管理などの職種ごとのスペ
シャリストとして知識を深める
• 自分の領分と隣接分野、さらにその先まで
─ 広げていかないと話が通じない、納得できない
46

47. ただしインフラという言葉は変化する…
• ITサービスにおけるインフラ（アプリサイトやゲーム）
─ 高負荷処理／アプリ固有処理／超多数セッション処理
• 情報システムにおけるインフラ（ビジネスサイトや金融、官公庁）
─ ゼロダウンタイム／DR／多重バックアップ／物理セキュリティ
• HPCにおけるインフラ（大学や研究機関）
─ 超高集積／インターコネクティビティ／特殊冷却
• クラウド基盤上の「インフラ」
─ サービス理解（仕様と実装）／インタークラウド
47

48. インフラ担当者の領分も変化する…
48
Business Logic
UI(Presentation)
Data Access
Infrastructure

49. インフラの定義も変化する…
• Immutable Infrastructure
─サーバのライフサイクルは短くなる一方
─FaaSの登場で時間単位どころか分・秒単位に
• Infrastructure as Code
─CLOUD NATIVEはインフラをプログラムする
─デプロイまで何時間もかかるシステムなんて
誰も使わない
49

50. インフラエンジニアの二極化
50
先端『サービス』は
どんどん進むが
レガシーシステムは
注目されなくなる

51. インフラエンジニアの二極化
51
『サービス』ではフォロー
できないシステムは存在し
これらは変わらず物理イン
フラやミドルウェアで支え
られる

52. 52
あなたは
どちら？
どっちがいいとかいう話ではありません

53. 53
おしまい