元RX-7乗りの適当な日々 このページをアンテナに追加 RSSフィード Twitter

RX-7(FD3S)WRX STI関連のキーワードで検索されて来られた方へ。
右サイドのカテゴリ『』をクリックすると関連する項目だけが表示されます。
日々の写真は『Flickr』で公開しています。

2014/02/13

デブサミ2014「さくらのクラウド開発と運用、裏話的な何か」講演メモ #devsumi


クラウドサービスがどのように作られることになったか、とかどのように開発されたかの裏話。生々しい話も所々出てきて面白かったです。

運用の部分、時間がなくなってしまって割愛されていたのですが、そっちも是非聞きたかったです。


「さくらのクラウド開発と運用、裏話的な何か」

  • 鷲北 賢 氏
    • @ken_washikita
  • さくらインターネット研究所
    • 所長
    • さくらのクラウド開発チームリーダー兼務

「中間管理職PMの立場でお話します。」


さくらインターネット

データセンターを中心とした事業。

  • ハウジング
  • レンタルサーバ
  • 専用サーバ
  • VPS
  • クラウド(IaaS)

2009/05

  • 「さくらはVPSをやらない」と高らかに宣言(したように見えた)
    • 社長が当時の@ITにて
  • 現実として、社内に仮想化サービスを検討するプロジェクトは皆無
  • 社長の記事のおかげで、「やっちゃいけないんだな…」という空気が醸成

2009/07

  • 研究所設立
  • 面白いことは何でもやるをモットー
  • 当初は、IPv6実装とか硬めのテーマが主流
  • 仮想化技術をやらないのは個人的にやばいと思っていたので、自ら研究テーマに選んだ。

2009年頃のクラウド事情

  • EC2がすごいともっぱらの評判
  • 個人で試すことが多かった
  • 実験で立てたサーバを消し忘れて「クラウド破産」する例も
  • 当時、アメリカではEC2を使ったサービスは続々リリースされていたが、国内では事例が少なかった
    • 勉強会では、法律も違うしデータを差し押さえられるのでは、という議論もあった
  • ただサーバを作ったり消したりするだけでも楽しい、という雰囲気

仮想化されたサーバサービスはすごい

  • 時間単位でサーバが借りられる、これだけで破壊的
  • どうやってサービスを実装しているか想像するだけでも楽しい恐ろしい
    • 例えば、1日で1000台つくって1時間で解約、というスケールに対応する必要がある
    • 途方もないリソースプールをどう用意するのか
  • 真面目に取り組まないと到底作れないと焦った

研究所の方針

  • Linux KVMを採用
  • ネットワーク設計は独自に設計
    • 当時のCloudStack, OpenStackはまったくスケールしなかった
  • ストレージ仮想化は、、、決め手に欠くまま2年が過ぎた

2010/01

  • 社長が突然「クラウドやろう」と言い出した
  • 社長個人サイトがアクセス津波でえらいことになってた
    • 社長はEC2を使って対処。悔しかったw

さくらインターネットの怖いところ

  • 日曜プログラミングの延長で、社長がプロトタイプを作る
  • 動くものを使ってデモ。エンジニアは逃げ場がなくなるw

VPSプロジェクト発足

  • 社長のプロトタイプを受けて開発部がプロジェクトを担当
  • ハードウェアの選定
  • コントロールパネルと課金系の構築
  • 研究所の役割
    • KVMの性能評価等はレポート化していた
    • スーパーバイザーとしてMTGに参加

2010/09、VPSリリース

  • 6ヶ月でサービスにもっていった開発部すげぇ、と思った
  • リリース後もすごいスピードでユーザが増えて大変なことになってた
  • 現在は、5万を超え、6万に迫るVM数(!)

2011/03/02

  • AWS東京リージョン開設
  • 即座に社長の呼出がかかった
  • 研究所と新規事業室でクラウドを作ることに
    • 企画と開発はVPSにかかりっきり
    • プログラマもPMも全然足りない
  • プロジェクト発足キックオフの翌日が大地震…

最初のMTG

  • プロジェクト・ミッションの定義
  • VPSの問題点
  • 提案
    • ネットワーク中心にサービスを考え直す
    • Demo or Dieをモットーとし、まず制作に取りかかる

構成

  • 物理はネットワークを中心に設計
  • APIが中心
    • 全リソースをコントロール)

開発の流れ

  • ネットワークの基本設計は出来上がっていた
  • ホストサーバはVPS運用実績を元に再設計
  • ストレージはゼロから検討
  • APIとDBはプロトタイプをベースに再設計
  • 課金システム
    • 時間課金を実装するのは初めて
    • 既存の課金システムと切り離して実装、既存とは売上データだけをやりとり
  • UI(コントロールパネル)は自由度MAXで
    • 当時、20歳くらいの若者が実装

開発スケジュール(2011)

  • 4月に調査・検討を開始
  • 9月にオープンβ開始
    • 大阪で30台規模
  • 11月に石狩IDCで構築開始

最初の段階は120台のサーバを準備。夏までに検証した上で発注。


リリース直前

  • クラウドのリリースが2011/11/15(石狩IDCの開所日と同時)リリースに決定
  • 石狩IDCの竣工、引き渡しが11/11...
  • 実際は、10/31から作業(納品・開梱)
  • 幸いトラブルはなく、オンスケでリリースできた

11/15サービススタート

  • 当初予定の2倍のスピードでインスタンス増加
  • 2ヶ月でストレージが音をあげはじめた
    • 前倒しで機材追加するも根本解決にならず
  • ストレージシステムの作り直し
    • 新規受付停止
    • 課金も停止

その後

2012年には、ストレージも安定運用・回復。

その後も、リリースを続け、2013年には第2ゾーンの提供開始。サービス拡充中。


インスタンス増減の状況

  • 多くはインスタンスを作ってから、すぐに消される、の繰り返し
    • 定着率は12〜13%
    • 純増を続けている

運用の話(のところで、あと5分)

(以降、色々割愛されていたので、メモを取れたところだけ。)


仮想リソースの障害

  • 従来の物理サーバによるサービスでは、24/365体制で多くのコストが必要だった
  • 仮想リソースでは、設定・ソフトの問題がほとんどなので、設定変更で対応できる
  • 再起動・再割当の時間が非常に短い

障害対策

  • 1点の物理障害が、クラウドのどこの障害につながるかが非常にわかりづらい
  • 極力シングルポイントをなくす
    • 障害が発生しても、自動的に復旧する構成に
    • ただちに影響が出ない設計
  • すべてのコンポーネントを監視する

はてなユーザーのみコメントできます。はてなへログインもしくは新規登録をおこなってください。

トラックバック - http://d.hatena.ne.jp/rx7/20140213/p5

オススメ (一部は、最近読んでいる本とも言う)
Chef実践入門 ~コードによるインフラ構成の自動化 (WEB+DB PRESS plus) クラウド Amazon EC2/S3のすべて~実践者から学ぶ設計/構築/運用ノウハウ~ [Web開発者のための]大規模サービス技術入門 ―データ構造、メモリ、OS、DB、サーバ/インフラ (WEB+DB PRESS plusシリーズ) エキスパートのためのMySQL[運用+管理]トラブルシューティングガイド [24時間365日] サーバ/インフラを支える技術 ~スケーラビリティ、ハイパフォーマンス、省力運用 Linux-DB システム構築/運用入門 (DB Magazine SELECTION) キャパシティプランニング ― リソースを最大限に活かすサイト分析・予測・配置 スケーラブルWebサイト 実践ハイパフォーマンスMySQL 第3版 ウェブオペレーション ―サイト運用管理の実践テクニック (THEORY/IN/PRACTICE) SQLアンチパターン インターネットのカタチ―もろさが織り成す粘り強い世界― ハイパフォーマンス ブラウザネットワーキング ―ネットワークアプリケーションのためのパフォーマンス最適化 Linuxの教科書―ホントに読んでほしいroot入門講座 (IDGムックシリーズ)