さくらのクラウド開発と運用（九州インフラ交流勉強会（Kixs） Vol.005）
•
0 likes•616 views
2017年9月2日(土)に福岡で開催された「九州インフラ交流勉強会（Kixs） Vol.005」の講演資料です。
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to さくらのクラウド開発と運用（九州インフラ交流勉強会（Kixs） Vol.005）
Similar to さくらのクラウド開発と運用（九州インフラ交流勉強会（Kixs） Vol.005） (20)
More from さくらインターネット株式会社
More from さくらインターネット株式会社 (20)
Recently uploaded
Recently uploaded (9)
さくらのクラウド開発と運用（九州インフラ交流勉強会（Kixs） Vol.005）
- 1. さくらのクラウド 開発と運用 裏話的な何か 2017/9/2 さくらインターネット株式会社 さくらインターネット研究所 鷲北 賢 (C) Copyright 1996-2017 SAKURA Internet Inc
- 2. 自己紹介 • 鷲北 賢（わしきた けん） • 1998年4月入社 • バックボーンのお守りからサービス開発まで − 初期の専用サーバ、データセンター構築 − オンラインゲームプロジェクト − CTO兼取締役、などなど • 2009年より、さくらインターネット研究所 所長 − 仮想化技術の研究（Linux KVM） − さくらのVPS開発ヘルプ • 2011年より、さくらのクラウド・プロデューサー兼務 • @ken_washikita@mstdn.jp • https://facebook.com/ken_washikita 2
- 3. 1. さくらのクラウド開発に至る経緯 2. 開発チーム体制とスケジュール 3. システム概要と運用のポイント 3
- 4. さくらインターネット • インターネットインフラの提供を事業ドメインとし 大阪、東京、北海道に5つのデータセンターを展開 4 1996年12月に現社長の田中邦裕が、 舞鶴高専在学中に学内ベンチャーとして創業。 1999年8月に株式会社を設立。10月には、 第1号となるデータセンターを本町に開設。 2005年10月に東京証券取引所 マザーズ市場に上場。 2011年11月、北海道石狩市に国内最大級の 郊外型大規模データセンターを開設。 石狩データセンター開設2011 東証マザーズ上場2005 さくらインターネット創業1996 ・最初のデータセンター開設 1999 ・株式会社を設立 2015年11月に東京証券取引市場第一部に 市場変更。 東証一部に市場変更2015 商 号 さくらインターネット株式会社 本社所在地 大阪市中央区南本町一丁目8番14号 設立年月日 1999年8月17日 （サービス開始は1996年12月23日） 上場年月日 2005年10月12日（マザーズ） 2015年11月27日（東証一部へ市場変 更） 資 本 金 22億5,692万円 従 業 員 数 495名（連結）（2017年3月末）
- 7. サービスラインアップ 7
- 8. 1. 開発に至る経緯 8
- 10. 2009年5月のこと… • 「さくらはVPSをやらない」 と高らかに宣言（したように 見えた） • 事実、社内に仮想化サービス を検討するプロジェクトは皆 無 • 社長の記事のおかげで「やっ ちゃいけないんだな…」とい う空気が醸成 • Xenのファンだった一部のエ ンジニアは隠れて使うように なった 10 http://www.atmarkit.co.jp/ad/sakurainet/200905/doujima.html
- 11. 2009年7月、研究所設立 • 研究所スタート − 古参のエンジニアとして所長を拝命 • 「面白いと思ったことはなんでもやる」をモットーに • 当初は「データセンターにおけるIPv6実装」とか、割 と硬いテーマをやったり • しかし「仮想化技術をやらないのはヤバい」と個人的 に思っていた • そこで自ら選んだのが「仮想化技術の研究」という テーマだった 11
- 12. 2009年ごろのクラウド事情 • AWS EC2がすごいともっぱらの評判 • 個人で試す人が多かった • 勉強会も花盛り • 実験で立てたサーバを消し忘れて「クラウド破産」する例も • アメリカでEC2を使ったサービスが次々にリリース − 日本国内ではまだ少なかった − 勉強会では「法律も違うし、データを差し押さえられるリスクは？」と いう懸念が真剣に議論されていた • ただサーバを作ったり消したりするだけでも楽しい − というのはエンジニアの陥りやすいワナ 12
- 13. 仮想化されたサービスのすごさ • 時間単位でサーバが借りられる、これだけで破壊的 − さくらのサービスはすべて月額課金だった − 初期費用も高く、投資金額が割高に見えた • どうやってサービスを実装しているか、想像するだけ でも楽しい恐ろしい − 単に仮想サーバを作るだけの話ではない − 一日のうちに1000台作って1時間で解約、というスケール に対応しなければならない − 途方もないリソースプールをどうやって用意するのか… • 調査を進めるほど、難易度の高さに焦りがつのった 13
- 14. さくらインターネット研究所の取り組み • サーバ仮想化 − Linux KVMに着目 − 隠れXenユーザがいるのは知っていたので、違うことをやりた かった − Xenより汎用性が高いのが好ましかった （Minixが動いたのが個人的なお気に入りポイント） − VMwareは高くて買えない、と思っていた（実際高い） • ネットワーク仮想化 − EC2のネットワークが理解できない（笑） − 従来のインフラに慣れていると分かりづらい − 当時のCloudstack、Openstackはまったくスケールしなかった − ネットワーク設計を独自にやる必要があると判断 • ストレージ仮想化 − 一応テーマに選んでいたが、決め手に欠くまま2年間過ぎた − 後々痛い目にあう原因に… 14
- 15. 2010年1月 • 社長が突然「クラウドやろ う」と言い出した • 社長個人のサイトが、アクセ ス津波でえらいことに − EC2にサーバ作って対処して いた − なんか悔しい − さくらでも仮想サーバをやら ないといかん • そんなこと突然言われても… • （笑）じゃ済まないよ… 15 http://www.atmarkit.co.jp/ad/sakurainet/1008vpsinterview/vpsinterview.html
- 18. さくらのVPSプロジェクト発足 • 社長のプロトタイプを受けて開発部がプロジェクトを担当 • ハードウェアの選定と構築 − ホストサーバとネットワークを設計・構築 − VPSであるため、ネットワークはL3のみ（グローバルIP割り当て） − ストレージも仮想化しない • コントロールパネルと課金システム − 仮想サーバの起動／停止／削除等の基本コマンド − シリアルコンソール機能を実装 − 課金はレガシーに月額単位、初期費用もアリ • 研究所の役割 − KVMの性能評価とEC2との比較はすでにレポート化していた − 社長のプロトタイピングのお手伝いはしたが、コードは書いてない − スーパーバイザーとしてミーティングに参加する程度 18
- 19. 2010年9月、さくらのVPSリリース • 6か月でリリースした開発部すごい • リリース後すごいスピードでユーザが増えて大変なこ とに − サーバが足りない （物理） − マネージャーや執行 役員すら駆り出して、 サーバのセットアッ プと追加をやった 19
- 20. 2. さくらのクラウド開発 20
- 21. 2011年3月2日 • AWS東京データセンター開設のニュースが流れた • 即座に社長に呼び出された • 研究所と新規事業室でクラウド作ってくれない？ − 企画と開発はVPSでかかりきり − プログラマもPMも全然足りない • 新規事業室とは… − 社長・副社長直轄の、新サービス企画・開発チーム − 製品リリースに向けたPM担当者がいなかった • 新規事業室＋研究所のジョイントプロジェクト発足 − 最初のチームミーティングは3月10日 − 翌日、地震でえらいことに 21
- 22. 最初のミーティングのアジェンダ • プロジェクト・ミッションの定義 − クラウドと呼ぶに相応しいサービスの開発 ➢ 今後開発するサービスをすべて収容可能なIaaS基盤を作る ➢ 最終的にはIaaSを基盤としたPaas、SaaSを目指す • VPSの問題点 − ネットワーク柔軟性がない − ストレージも固定化、不便 − 時間課金できない • 提案 − ネットワークを中心にサービスを考え直す − 物理と論理をきちんと煮詰める − Demo or Dieをモットーとし、まず制作にとりかかる • ミーティングについて − 定例は週1回、30分以内を目標に − 検討事項や提案があったら都度ミーティングを招集すること • スケジュール案、その他 22
- 25. 開発の流れとメンバーの役割 • ネットワークは基本設計がすでに出来上がっていた − VLANを使ったレガシーな設計だが、ほかに手段がなかった − 具体的な機材選定に着手 − 仕様の詳細化とテストを繰り返した • ホストサーバはVPSの運用実績を元に再設計 − 元々のレポートを、VPSのノウハウを借りて手直し • ストレージはゼロから検討 − 一時期分散ストレージを試していたが性能不足だった − プロジェクトスタート後も悩みの種 • APIとDBはプロトタイプをベースに再設計 − 機能洗い出しから実装まで一貫して担当 − ホストサーバ、ネットワーク機器、ストレージを操作する • 課金システム − さくら社内で一番ややこしい部分 − 時間課金を実装するのは初めて − 既存の課金システムと切り離し、売上データだけやり取りするように構成 • UI（コントロールパネル）は自由度MAXで − 最初に「APIをたたいてUIを作る」「APIを公開したらユーザでもコンパネが作れる」と決めた − きっちり分担したおかげでいろいろ捗った 25
- 26. 開発スケジュール 4月 担当ごとに調査、検討を開始 5月 連休を使って合宿、UIデザインfix 6月 機材選定とテスト、DB/API設計など 7月 機材発注と構築準備、UIモックアップ 8月 βサイト構築、プログラムの結合 9月 オープンβ開始 10月 正式リリースに向け機材調達 11月 石狩IDCで構築開始 26
- 27. そして構築へ • 石狩データセンター開所が決定 − 2011年11月15日 − ならばクラウドも同じ日にリリースだ！ • でも竣工、引き渡しは11月1日 − それまでは施主と言えども立入禁止 • 構築どころか、搬入／開梱からすべてを2週間で完成 させないといけないことが判明 • ペンキの匂い漂うラックルームでセットアップ開始 27
- 28. 当時の工程表 28 31 1 2 3 4 5 7～ 11/15 機材納品・開梱 ホストサーバOSイメージ作成 機材設置・電源投入 config/接続 ネットワーク単体試験 バックボーン接続試験 テスト・イメージコピー ホストサーバ単体試験 結合試験 後片付け システム起動 最終試験 石 狩 IDC 開 所 と 同 時 に リ リ ー ス
- 29. サーバ設置風景 29
- 30. 開梱作業 30
- 31. ディスクコピー 31
- 33. サーバラック 33
- 34. ネットワーク機材 34
- 35. サービススタート、直後にトラブル • 11月15日に無事リリース • 想定の2倍のスピードでVM増加 − 性能試験のためにちょっと借りるケースが多かった − ガンガン回されるので負荷も大きくて困った • 2か月でストレージが限界に − 増強予定を前倒し、2セット目を確保 − しかし根本的な解決にならず • ストレージシステム作り直し − 新規募集停止・課金停止措置 − 大規模ストレージをやめ、小型ストレージへ転換 − プロトコルも見直して再設計、APIも追加開発 35
- 36. 絶え間ない機能追加・増強 • 2012年 − ストレージの安定運用と信頼回復 − ホストサーバのクラッシュ対策 − APIとシステムの安定化 • 2013年 − パケットフィルタ、ロードバランサ、API公開 − SSDストレージサービス − node-sacloud（CLI） − IPアドレス追加機能、スタティックルーティング対応 − VPSからのデータマイグレーション、4TBまでのプラン追加 − SLA導入、時間単位課金制導入、サーバプラン見直し − ハイブリッド接続機能 − 第2ゾーン提供開始 • 2014年 − スタートアップスクリプト − 新コンパネ（ver3.1） − VPC機能（ルータアプライアンス）提供開始 − CoreOS対応 − Microsoft SQL Server対応 − sandboxゾーン提供開始 − サーバ作成フォーム・リニューアル − マップ表示機能エンハンス − APIクライアントライブラリ公開 − 障害・メンテナンス情報配信メールアドレスの登録機能 • 2015年 − サーバ環境（アカウント）とユーザの分離 − オブジェクトストレージのアカウント統合 − メンテナンス対象サーバのマーク機能 − サーバ作成簡単モード − ディスクパーティション拡張機能 − 二段階認証 − 東京リージョン開所 − GSLB機能リリース − DNSサービス開始 − アクセスレベル設定機能リリース − KUSANAGI対応 − 新コンパネ（ver3.2） − クラウドカタログ機能リリース − WAF提供開始 − オブジェクトストレージ・キャッシュ機能 − 専用サーバ東京リージョンとの ハイブリッド接続提供開始 • 2016年 − シンプル監視サービス開始 − VPCルータ・ハイスペックプランリリース − コンパネ機能改善 − 英語版コンパネリリース − 西新宿・代官山IDCとのハイブリッド接続開始 − Webアクセラレータ提供開始 − イベントログ提供開始 − VPSとのブリッジ接続開始 − 割引パスポート提供開始 − 36コア/224GBプランの提供開始 • 2017年 − 公開鍵暗号生成機能提供開始 − Windowsにてディスク修正機能リリース − SideGuard lite公開 − ルータ250Mbpsプラン追加 − サーバ停止時非課金リリース − Mastodonスタートアップスクリプト提供開始 − セールスアナリシスプラン提供開始 − Plesk提供開始 − ローカルルータ機能提供開始 − 専有ホストプラン提供開始 36
- 39. 3. システムと運用 39
- 40. さくらのクラウド・物理構成 40 エッジスイッチ エッジスイッチ エッジスイッチ エッジスイッチ ホストサーバ ホストサーバ ホストサーバ ホストサーバ ルータ ルータ ルータ ルータ インターネット VPN 仮想スイッチ 仮想スイッチ 仮想スイッチ仮想スイッチ VM VM VM VM VM VM VM VM コアスイッチ コアスイッチ たくさんのVLANを 通しておく LAG bonding タグVLAN タグVLAN タグVLAN
- 41. VLANによるプロビジョニング 41 ルータ FW LB Webサーバ Webサーバ DBサーバ DBサーバ VPN インターネット VPN このような仮想システムを、IaaSインフラ上に展開する場合
- 42. VLANによるプロビジョニング 42 ルータ FW LB Webサーバ Webサーバ DBサーバ DBサーバ VPN インターネット VPN 網内でユニークなVLANを各回線に割り当てる VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106
- 43. クラウド上に配置された状態 43 VLAN101 VLAN102 VLAN103 VLAN104 VLAN105 VLAN106 ルータ FW LB WEB WEB DB DB VPN ホストサーバA ホストサーバB ホストサーバC L2網(コアスイッチ、エッジスイッチ、仮想スイッチ) 仮想スイッチ 仮想スイッチ 仮想スイッチ インターネット VPN VMをホストサーバに配置し、割り当てたVLANに接続
- 44. データセンター／サーバの運用といえば… • 従来の物理サーバによるサービス − 障害発生時の対応のため24/365でエンジニアが必要 − 短時間で異常を検知、対応フローを開始する − 復旧作業を完了できないとサービスが停止してしまう 多大なコストで 対応体制を構築する 必要がある 44
- 45. クラウド（仮想化）による運用の変化 • 仮想リソースの障害 ≒ 設定・ソフトの問題 − 再設定、設定変更で修正できる − 再起動、再割当の時間が非常に短くできる − 現地オペレーションを縮小、あるいは撤廃できる • 自動化／ツール化が（比較的）容易 − 物理作業では手順書が必須だった − 自動化により、手順書をバッチ処理／プログラムで代替 − 手動作業によるミスも減少し、メリットも多い − 深夜作業や時限作業も容易 • 課題はまだ多い − 運用ツールの拡充はまだまだこれから 45
- 46. 物理サーバサービスとの運用体制の比較 • ネットワーク機材管理は負担軽減 − 元々運用経験が豊富な分野で、新サービスであるほど改善 が進んでいる − 設置／設定が完了すれば安定運用できる設計 − ファームウェアのアップデート・メンテナンスは不可欠 • サーバ管理は大きく変化 − 従来通り監視は重要だが、即時対応の必要は低減した ➢ サーバ故障を検知すると他の装置へ移動させる仕組み − 故障した装置の交換などの物理作業が不要になった − 必要な作業もコンソール（遠隔）で実施可能 − 物理作業は営業日等のムリのないスケジュールで実施可能 − 自動化ツールを随時開発、運用負荷低減を続けている 46
- 47. おしまい 47