本当に手前味噌な話ですけど、STFさん。今回も「あー、俺いいソフトウェア書いた」と満足できたので、この記事を書きます。ちなみにSTFとはみんな大好きPerlで書かれた分散オブジェクトストレージです。(github)
tl;dr;
去年の夏くらいに「お、そろそろ今ある物理ストレージサーバーのディスク容量一杯になるぞ」という状態が観測されたので 追加のストレージを導入していただいて、そこから「現在格納されているオブジェクト群を新しいストレージにまた均等に均す」というオペレーションを開始しました。もちろんシステムを停止させることができればあっという間に終わる仕事なんですが、ユーザーのデータがのっているので当然止めるわけにはいかないです。そこで
tl;dr;
- ああ、俺いいコード書いた
- 8ヶ月間最初のスクリプトをキックする以外何もしてないけど、18億個のデータを無事格納しおえた
去年の夏くらいに「お、そろそろ今ある物理ストレージサーバーのディスク容量一杯になるぞ」という状態が観測されたので 追加のストレージを導入していただいて、そこから「現在格納されているオブジェクト群を新しいストレージにまた均等に均す」というオペレーションを開始しました。もちろんシステムを停止させることができればあっという間に終わる仕事なんですが、ユーザーのデータがのっているので当然止めるわけにはいかないです。そこで
- システムはオンラインのまま、遅延等を発生させずに
- 全てのデータを新しいストレージサーバ群も含めた形で均す
という作業を行う必要がありました。
まぁ実はこれ、やるの初めてじゃないので何も恐れる事はありませんでした。ただ前回は10億個のファイルを移動させ、今回は約15~18億個のファイルを移動させるというだけの事です(ファイル数に幅があるのは15億個くらいの状態で始めたんだけど、このオペレーションが終わる頃には18億個になっていたから)。
STFは自分が書き始めたものではないのは知っている人は知っていると思いますが、自分がSTFに手を入れるようになった後大幅な機能改修を行った際につけた今でもこれが一番よかったと思う機能がオブジェクトのリペア機能です。これはQ4MのキューにオブジェクトのIDを突っ込むと、システム全体のストレージクラスタの数や状態に合わせて、そのオブジェクトを正しく分散・格納し直すというものです。オブジェクトは基本3個のコピー(エンティティ)を一組として機能しているのですが、そのリペアワーカーにかければエンティティがかけていても補修するし、保存されているクラスタが間違っていたら入れ直すのです。
この機能があるおかげで、ストレージの追加をしてデータを均したい場合(今回のようにディスク容量が圧迫されていなければ均す必要さえもないですが)でもただ単純にオブジェクトのIDを順番にこのワーカーに突っ込んでいくだけでいつのまにか全てのデータがキレイに並び直されるわけです。今回も若いIDから全てのデータをリペアワーカーに突っ込んでいくスクリプトをただただひたすら動かし続けました。ただしオンラインのままこの作業を行うので全速力でリペアをするわけにはいかないので、ワーカーはスロットリングされています。そのせいでこのオペレーションはタイトルの通り8ヶ月かかりました。
実際のデータの増減が見られるグラフがこちらです。これは1ストレージクラスタの格納エンティティ数をGrowthForecastに記録していたものです。去年の10月末〜11月始めごろにデータ量がピークになり、そこから減っていくのがわかります。同時に新規データの書き込みもあるのですが、他のクラスタに均されていくデータ量のほうが多いのでクラスタからはデータが減っていき、処理が終わった6月頃から今度は一転してデータは増加傾向にあります。
他にはこんなクラスタもありました。これはクラスタを構成する一つのストレージがこのオペレーションのちょっと前にクラッシュしたため、サーバーの入れ替えを行っていたのですが、そのせいでその一つのストレージだけエンティティ数が少ないところから始まっています。これも6月時点で全てのストレージが均一化されているのがわかります。
一方こちらは新規に追加したクラスタです。こちらは6月から急にデータの増加量が減っていますが、これは他のクラスタからの移動が途絶えたためです。
このようにリペアを8ヶ月行い続け、データが均されました。この話の一番強調すべき点は、僕はこの8ヶ月間最初にIDをワーカーにつっこむスクリプトをキックした以外はろくすっぽこのデータ量遷移のグラフさえ見ていなかったことです。スクリプトを起動させ、あとはたまに思い出した時に様子を見る以外は完全に放っておきました。今回処理が終わっているのに気づいたのも実は久しぶりにグラフの存在を思い出したからです(もちろん、システム異常があればそれはアラートで通知されますのでそういう意味では放置ではありません)。見たらすでに終わってました。
ガンガン進化するシステムももちろん素敵ですが、何もしないでも期待どおり普通に動き続けていてくれる。そんなシステムも素敵ですよね。
以上、手前味噌のSTF推し記事でした。
まぁ実はこれ、やるの初めてじゃないので何も恐れる事はありませんでした。ただ前回は10億個のファイルを移動させ、今回は約15~18億個のファイルを移動させるというだけの事です(ファイル数に幅があるのは15億個くらいの状態で始めたんだけど、このオペレーションが終わる頃には18億個になっていたから)。
STFは自分が書き始めたものではないのは知っている人は知っていると思いますが、自分がSTFに手を入れるようになった後大幅な機能改修を行った際につけた今でもこれが一番よかったと思う機能がオブジェクトのリペア機能です。これはQ4MのキューにオブジェクトのIDを突っ込むと、システム全体のストレージクラスタの数や状態に合わせて、そのオブジェクトを正しく分散・格納し直すというものです。オブジェクトは基本3個のコピー(エンティティ)を一組として機能しているのですが、そのリペアワーカーにかければエンティティがかけていても補修するし、保存されているクラスタが間違っていたら入れ直すのです。
この機能があるおかげで、ストレージの追加をしてデータを均したい場合(今回のようにディスク容量が圧迫されていなければ均す必要さえもないですが)でもただ単純にオブジェクトのIDを順番にこのワーカーに突っ込んでいくだけでいつのまにか全てのデータがキレイに並び直されるわけです。今回も若いIDから全てのデータをリペアワーカーに突っ込んでいくスクリプトをただただひたすら動かし続けました。ただしオンラインのままこの作業を行うので全速力でリペアをするわけにはいかないので、ワーカーはスロットリングされています。そのせいでこのオペレーションはタイトルの通り8ヶ月かかりました。
実際のデータの増減が見られるグラフがこちらです。これは1ストレージクラスタの格納エンティティ数をGrowthForecastに記録していたものです。去年の10月末〜11月始めごろにデータ量がピークになり、そこから減っていくのがわかります。同時に新規データの書き込みもあるのですが、他のクラスタに均されていくデータ量のほうが多いのでクラスタからはデータが減っていき、処理が終わった6月頃から今度は一転してデータは増加傾向にあります。
他にはこんなクラスタもありました。これはクラスタを構成する一つのストレージがこのオペレーションのちょっと前にクラッシュしたため、サーバーの入れ替えを行っていたのですが、そのせいでその一つのストレージだけエンティティ数が少ないところから始まっています。これも6月時点で全てのストレージが均一化されているのがわかります。
一方こちらは新規に追加したクラスタです。こちらは6月から急にデータの増加量が減っていますが、これは他のクラスタからの移動が途絶えたためです。
このようにリペアを8ヶ月行い続け、データが均されました。この話の一番強調すべき点は、僕はこの8ヶ月間最初にIDをワーカーにつっこむスクリプトをキックした以外はろくすっぽこのデータ量遷移のグラフさえ見ていなかったことです。スクリプトを起動させ、あとはたまに思い出した時に様子を見る以外は完全に放っておきました。今回処理が終わっているのに気づいたのも実は久しぶりにグラフの存在を思い出したからです(もちろん、システム異常があればそれはアラートで通知されますのでそういう意味では放置ではありません)。見たらすでに終わってました。
ガンガン進化するシステムももちろん素敵ですが、何もしないでも期待どおり普通に動き続けていてくれる。そんなシステムも素敵ですよね。
以上、手前味噌のSTF推し記事でした。