さくらのクラウド、新ストレージでは性能限界テストをやりやすく、自社開発をまずは採用。さくらの夕べで参加者に説明

2012年6月26日

さくらインターネットは25日、都内で同社のユーザー会「さくらの夕べ」を開催。冒頭で同社代表取締役社長 田中邦裕氏は、さくらのクラウドのストレージ障害について「そもそも製品選択のところで十分にできなかった。その結果、ストレージの性能が十分でなかったなどのトラブルにつながった。大変申し訳ありませんでした」と、参加者の前で頭を下げました。

トラブルの経緯を説明後、新ストレージの概要を発表

fig

さくらの夕べの前半では、今日公開された「さくらのクラウド・ストレージに関する報告書」に沿ってトラブルの経緯や原因などが説明されました。

fig

トラブルに至った原因として、自社で十分なテストができなかったこと、ベンダに依存したことで自社での問題解決ができなかったこと、などがあらためて示されました。さくらのクラウドのストレージ障害については、以下の関連記事をご参照ください。

続いて、現ストレージの代替となる新ストレージの概要が紹介されました。

新ストレージはさくらインターネットの自社開発。iSCSI対応となり、現ストレージが1台当たり数千ユーザーを収容するのに対して1ストレージ当たり数百ユーザー規模のものになる予定。小規模化により、性能限界のテストがやりやすくなると同時に、万が一障害が発生しても問題を局所化できる利点があるとのこと。

「ポイントは自社で作ったというところではなく、最大負荷時にどのような挙動になり、お客様が使ったときにどのような問題が発生しうるかが把握できるのがポイントだと思っていて、それをいちばん早く提供できるのが自社開発によるストレージでした」(田中社長)。

新ストレージについてPublickeyが取材で得た情報では、ストレージ用のIAサーバにLinuxを載せたもので、InfiniBand接続でのiSCSI対応。

iSCSIを採用した理由としてQoSを管理しやすく、ユーザーごとのトラフィックの上限を管理することで、より公平なリソース配分が実現できると説明されました。InfiniBand用ドライバソフトウェアは既存のサーバで使われている実績のあるもので、なにか問題が発生した場合にはカーネルレベルまで自社で追えるとのことです。

fig

新ストレージは本日よりベータテストが開始され、9月中旬に課金開始を目指すとのこと。現行ストレージから新ストレージへは一年程度の移行期間を想定し、最終的には新ストレージへ全面移行する予定です。

参加者の一問一答

新ストレージについての説明のあとは、会場の参加者との一問一答が行われました。

質問 事前の検証では自社開発のストレージなどよりもアプライアンスのストレージの方が優位性があると、その時点では判断されたのだと思うが、その当時はなぜそう考えていたのか?

田中社長 ひとことでいうと、リスクの移転をしようとしてしまった、というのが挙げられると思います。自社で作ったストレージでは、問題が起きたときに自社で解決できないかもしれないと思っていまして、そこで問題を解決してくれる外部に頼ってしまったことが大きな間違いだったと思います。

システム開発をするに当たって、分からない部分はベンダに頼って構築する、ということはあると思いますが、パブリッククラウドではエンドユーザーがいます。そこで問題が起きたときに、自社で解決できないかもしれないという不安感があり、そのリスクの回避や時間をお金で買おうという、これがベンダを頼る理由のひとつだと思います。それに乗ってもらえるベンダを探して、しかし結果としては乗ってもらえなかったと。

質問 弊社でクラウドの移転先を探していて、さくらのクラウドも候補だった。現状ではたぶんまだ本番用には使ってはいけないようだが、いつ頃から本番として使えそうか。

田中社長 先ほど、今年の9月頃に課金が再開できればというお話をしましたが、しっかりと動作の保証ができるという判断は、この9月の正式課金頃になるかなと思っています。

質問 自社でストレージを作るということは、既存のストレージベンダに対抗することになるのか、とすると何を目指すのか?

田中社長 ストレージベンダの製品を買うより自社で作った方が安い、と勘違いされやすいのですが、自社で作る方が安いと言うことはないです。ただ自社で作った方が動きが把握できて、トラブルシュートのときにも外部にボトルネックを生じないために自社で作るという判断を今回はしました。

しかしメーカー製品の方がトータルとしての性能や機能やコストパフォーマンスは高いと思っていますので、まずは自社製ストレージですが、その先にメーカー製の選択肢を捨ててはいません。

質問 現ストレージに数千ユーザーを収容していたという説明だったが、そもそも詰め込み過ぎだったということはないのか。あるいは特定ユーザーが重い処理をしてリソースを寡占していたことなどはなかったのか。

田中社長 現ストレージは非常にパフォーマンスが高いもので、5000から6000ユーザー入ると想定していたものから低めに設計したので、もともと詰め込んだつもりはありませんでした。

ただし、現ストレージは事実上ユーザーごとのトラフィック制限はできていなくて、高性能なストレージなので、やってきたトラフィックを全部吸い込んで処理しようとしてしまっていたことはありました。

そこで新ストレージでは、ユーザーごとのIOPSやバンド幅などが管理できるように設計しています。現ストレージではひとりがストレージを占有できる状況にありましたが、新ストレージでは1つのストレージごとに比較的少数ユーザーを収容するのに加えて、1ユーザー当たりのバンド幅もしっかり制限できるようにします。

あわせて読みたい

クラウド ストレージ さくらインターネット




タグクラウド

クラウド
AWS / Azure / Google Cloud
クラウドネイティブ / サーバレス
クラウドのシェア / クラウドの障害

コンテナ型仮想化

プログラミング言語
JavaScript / Java / .NET
WebAssembly / Web標準
開発ツール / テスト・品質

アジャイル開発 / スクラム / DevOps

データベース / 機械学習・AI
RDB / NoSQL

ネットワーク / セキュリティ
HTTP / QUIC

OS / Windows / Linux / 仮想化
サーバ / ストレージ / ハードウェア

ITエンジニアの給与・年収 / 働き方

殿堂入り / おもしろ / 編集後記

全てのタグを見る

Blogger in Chief

photo of jniino

Junichi Niino(jniino)
IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。
詳しいプロフィール

Publickeyの新着情報をチェックしませんか?
Twitterで : @Publickey
Facebookで : Publickeyのページ
RSSリーダーで : Feed

最新記事10本


<!- script for simple analytics events -->