USENIXを読んだときの勉強メモです。自分が面白いと思ったところを中心にしたり、個人的に調べた内容が入っていたりするので正確かつ完全な情報は上記論文や関連文献等を直接読んでいただければと思います。検出するScaleCheckという手法が提案されています。bugsとはノードが数台〜数十台程度では顕在化せず、数百台以上の大規模クラスタになって初めて顕在化するようなバグのことを指しています。bugsを実際に数千台規模のクラスタを組むのではなく、1台のマシン上で上記のような問題を潜在的に抱えているかどうかを確認する方法を提供します。論文ではScaleCheckの提案のみならず、実際に1台のマシンのみを用いてCassandra,Riak等のシステムに適用し、10個の既知のバグ+4個の新しいバグを検出することに成功したことも述べられています。大規模サービスを運営する企業で運用されているクラスタは、そのノード数も巨大になりがちで論文では以下のような例が挙げられています。bugsと呼称し、cloud-scale時代に発生するようになった新世代のバグであると呼んでいます。実際に巨大なクラスタで発生するバグとしては以下のような実例が挙げられています。1000ノード単位で顕在化するバグが存在するようです。cassandraの内部処理でノード数依存でO(N3)の処理があり、計算に0.1~4sec程度時間が必要になった事例が挙げられています。いったことがあると、gossipプロトコルで最新のノード情報を取得するまでに時間がかかりすぎ、あるNodeが故障<->復旧の各状態を高速に繰り返すflappingと呼ばれる問題を引き起こします。いった問題はノード数が少ないと影響がでにくいため、クラスターが大きくなった時に初めて顕在化する問題だとされています。1台のマシンでその問題を検知するためのScaleCheckの提案につながったというわけです。bugsの原因は何なのか?を考える必要があります。これはノード数に依存するようなデータ構造のループのことです。ScaleCheckのSFindでは、メモリ消費の増加傾向からこのループ構造を検出します。実際には上記以外にもファイル、パーティション、テーブルなど様々な軸で、スナップショット、マイグレーションなど様々なワークロードについて問題を検出するようです。bugsを検出できると思われますが、一方で様々なハードルがあるため1台のマシンでテストを行えるようにしたいところです。実際にそれを行うためには下記のような様々な困難を解決する必要があります。STestでは上記をSPC+GEDA+PILというテクニックで解決し、1台での大規模テストを行えるようにしています。詳しく説明すると長くなりすぎるため下記では要素のみの紹介とし、具体的な解説は論文に譲りますので興味がある方はそちらを御覧ください。ナイーブに1台に複数プロセスを立てるのだと50ノード程度しか立たないため今回の目的には向かないようです。Cluster(SPC)として1プロセスに複数ノードを立てる(つまりスレッドでノードを管理する)手法が導入されています。単純なSPCを行うと、イベントキューやワーカープールがノードごとに作られるためリソースを多大に消費します。Architecture(GEDA)を導入します。GEDAはグローバルなイベントハンドラを用意し、ノードごとの通信をグローバルイベントキューへのキューイングとして表現します。各ノードはグローバルなキューからイベントを取得し処理を行うだけです。Illusion(PIL)というテクニックを導入しています。PILは画像を見ると何をしたいかがわかりやすいと思います。実際にいくつかのミドルウェアで検証を行い、既知のバグや新しいバグを検知しているようです。新種のバグとしては以下の物が挙げられています。問題設定として様々なミドルウェアに潜む巨大なクラスタで発生するバグを包括的に捉えるのは興味深く感じました。おいて提案されています。同一の著者グループによる研究のようなので、より深く問題を理解するためにはこちらもみておくと良いでしょう。ScaleCheckは任意のミドルウェアにすぐ適用できるフレームワークではなく、ミドルウェア側の実装修正が必要になっています。LOCレベルなので、そこまで大きな変更を加えずに対応することが可能そうです。testingを民主化すると表現しているのですが、巨大企業に所属していなくても大規模ミドルウェアの開発に貢献しやすくなるという点で意義深いと思いました。*3FASTあたりの論文を読むと堅牢な分散システムが崩壊していくのはよく見られる(?)*4のですが、実運用では細かいところを追いきれずある程度信用してしまっている側面もあるかと思います。どのようなミドルウェア・ファイルシステムでも完璧に障害が起きないようにするのは非常に難しい(はずな)ので、どのような問題が起きうるのか?を研究を通して学んでいくだけでも、(実際にそのテクニックや技術を使うことがなくても)実運用に役立つ視点や、考え方を得られるのではないかなと思っています。結びの言葉を書いてたら去年も同じようなことを書いていました。だいたいよくわからないブログところで、社内からそもそもgossip部分がスケールしないのはアーキテクチャ的に見えてるしループ改善してもすぐ帯域やCPUで限界が来そう*5という指摘がありました。いった部分をどう乗り越えるかは論文の対象外ではありますが、現実の厳しさを感じつつこの記事を終わりたいと思います。*1:1クラスタじゃないと思いますが10万のcassandraって何に使ってるのか気になりますね*2:筆者はCassandraに詳しくないため前提や最新バージョンでの修正状況などを把握できていません。10台程度で500ノード建てられるので、そちらでもみたいなところはありますが、ソロコントリビューターでも気軽に貢献できることを目指すとなるともう少しハードルを下げたいと思うので。昨日はyasuharu51...2017-12-10CombiningTreeで数を数える第二のドワンゴアドベントカレンダー10日目です。»プロフィール間違ったことが書いてあったら@matsu_charaまでご連絡ください。Languageに入門(3)はてなブログをはじめよう!matsu_charaさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。