Skip to content

Latest commit

 

History

History
597 lines (487 loc) · 53.3 KB

riak-1.3.ja.md

File metadata and controls

597 lines (487 loc) · 53.3 KB
Raw

Riak 1.3.2 リリースノート

Riakの新機能と主な改善点

eLevelDB のコンパクションの整合性チェック

Riak 1.2で、我々はleveldbの壊れたブロックを lost/BLOCKS.bad に、コンパクション中に隔離するようにしました。これは、コンパクションのために A)リードリペアとAAEが裏側でデータをデータを修正しうるにもかかわらず、 B)手動でこれを修正する顧客サポートのエンジニアの工数がかかることを防ぐためです。

残念なことに、ふたつあるデータ破壊チェックのうちひとつしかコンパクション中に動いていなかったことに気づいていませんでした。ファイルのメタデータも含めて全てのブロックに対するCRCチェックです。圧縮のロジックでは、圧縮されたデータブロックに対して hash によるチェックが入っています。CRCチェックの方はデフォルトでは有効になっていません。悲しいことに、 leveldb はCRC以上のことは非常に限られたことしかしません。もし壊れたブロックがたまたま圧縮のhashチェックで全て検出できればから運がよいものの、壊れたディスクのファイルを読むと leveldb / Riak のクラッシュもありえました。

これに対するGoogleの対策はデフォルトでオフになっている paranoid_checks オプションです。残念ながらこれを true にするとコンパクション時のCRCチェックが有効になるだけでなく、リカバリログのCRCチェックも有効になってしまいます。プロセスが落ちた後のリカバリログのCRCチェックは失敗することがありえます。これは既存のコードでも、次に起動したときに活用されます。 paranoid_checks オプションが true になっていると自動リカバリ（の際の修復）が動きません。これは望ましくない挙動です。

そこで、新しいオプション verify_compactions を設けました。paranoid_checks で切り替えていた、バックグラウドで動作するCRCチェックはこの新しいオプションで設定できます。リカバリログのCRCチェックはこれからも paranoid_checks で設定されます。 verify_compactions のデフォルトは true です。 paranoid_checks のデフォルトは false のままです。

注意: CRC計算は高コストです。Riak 1.3 でIntelのハードウェアCRC回路が有効な場合はそれを使うコードが追加されました。Riak 1.2では複数の優先度付けされたスレッドが動作するようになっています。これらの2つの機能によって、バックグラウドのコンパクション処理中の高価なCRC計算のコストの影響を最小限に留めることができています。

Erlang スケジューラ縮退

R16B01以前の全てのErlang/OTPのリリースでは、Erlangのスケジューラがスリープしやすすぎる という問題があります。スリープすることによって、その間の電力消費やスレッド間の リソース競合を減らすことができます。

このリリースのRiak EDSはErlang/OTPの仮想マシンに、スリープしている スケジューラを通常の間隔で起こすためのパッチを必要とします。 +sfwi というフラグが vm.args ファイルに入っている必要があります。この値はミリ秒です。アプリケーションに よってはチューニングが必要になると思います。オープンソース版のRiakでも、 このパッチ（ vm.args の追加フラグ）は推奨されています。パッチは https://gist.github.com/evanmcc/a599f4c6374338ed672e にあります。

過負荷対策 / 負荷制御

Riak 1.3.2 で、過負荷を防御する仕組みを組み込みました。もしRiakノードが 過負荷状態になると、 {error, overload} というレスポンスを返すことで リクエストがキューに積まれたまま放置することはなくなりました。

これまでは、Riakは常にリクエストをキューに保持してきました。過負荷状態が 悪化すると、キューに積まれたリクエストはタイムアウトするまでキューに積まれた ままでした。最終的にはRiakのノードは応答できなくなり、クラッシュしていました。

新しい過負荷対策はこのために用意されました。

app.config で設定可能です。デフォルトの設定は様々なクラスタのサイズでテストされ、 処理可能なリクエスト数はRiakの全てのユーザーを満足させるものです。しかし、 完璧を期して以下に説明しておきます。

Riakには2種類の過負荷対策が組み込まれています。どちらも異なる設定です。 ひとつめはノードあたりの get と put の同時実行数を制限するものです。これは riak_kv/fsm_limit という項目で設定できます。デフォルトは 50000 です。 この最大値は get と put それぞれで制御されますので、デフォルトではトータルで 100000 まで扱えることになります。

ふたつめの過負荷対策は、各 vnode 毎のメッセージキューの長さを制限するものです。 これは riak_core/vnode_overload_threashold という項目で設定できます。 デフォルトは 10000 です。

どちらの設定も、 app.config で undefined とすると過負荷対策それ自体を 無効化することができますが、これは推奨しません。 app.config から項目を消すなど して設定しなかった場合、前述のデフォルト値が採用されます。

過負荷対策と同時に /stats に表示される新しい統計値を導入しました。

dropped_vnode_requests_total の統計値は vnode の過負荷制御部分で無視された メッセージの数を表しています。

get/put の過負荷対策については、いくつか新しい統計値があります。以下のものは get についてのものですが、同様のものが put についても追加されています。

node_get_fsm_active と node_get_fsm_active_60s の統計値は そのノード上のそれぞれ直近1秒、1分で有効な get のリクエスト数を表します。 node_get_fsm_in_rate と node_get_fsm_out_rate は直近1秒で リクエスト処理の開始と終了を終えたものの数をあらわします。さいごに、 node_get_fsm_rejected, node_get_fsm_rejected_60s と node_get_fsm_rejected_total はそれぞれの時間幅で無視されたリクエスト数を表します。

ヘルスチェック無効化

ヘルスチェックの機能は Riak 1.3.0 でリリースされましたが、 1.3.2 で無効化されました。 過負荷対策の仕組みが同様の役割をより安全に果たしているからです。特に、ヘルスチェックの アプローチは、ノードが遅いために発生してしまった過負荷状態からはうまく復帰できましたが、 クラスタ全体の処理能力を超えた負荷スパイクに対しては脆弱でした。つまり、2番目の場合には、 ヘルスチェックのアプローチ（負荷を別のノードに分担する）は、問題を悪化させます。

解決された Issues / PR

既知の問題

  • riak_kv/400 If the node owns fewer than 2 partitions, the following warning will appear in the logs riak_core_stat_q:log_error:123 Failed to calculate stat {riak_kv,vnode,backend,leveldb,read_block_error} with error:badarg Fixed in master

Riak 1.3.1 リリースノート

Riakの新機能と主な改善点

2i Big Integerエンコーディング

1.3.1以前の全てのバージョンのRiakでは、2iのintの範囲指定は 2147483647 (0x7fffffff) 以上の結果を全て返すことができませんでした。これはRiakが内部でデータをeleveldbに 格納するためのエンコーディングライブラリ sext [1] の問題に由来するものと判明しました。 sext はソート順を保ったままErlangのタームをバイナリにシリアライズするものです。 大きな整数の場合はこれがうまくいきませんでした。 2iの実装がこの機能に依存しているため、範囲検索が影響を受けていました。

sextの問題は修正され [2] 、Riak 1.3.1 に含まれています。新しくRiak 1.3.1 を インストールした場合はこの恩恵を受けることができますが、大きな整数のエンコーディングは 多少の非互換性をもたらします。1.3以前のRiakを使ってディスクにすでに書かれた 2147483647 以上の整数のインデックスがある場合には、正しい値を返すために上書きする必要があります。

Riak 1.3.1は riak-admin の一部としてノードの稼働中にインデックスを上書きする ツールを含んでいます。インデックスが全てのノードで上書きされたあとは、範囲検索は 正しい結果を返すようになるでしょう。このツールは、大きな整数をインデックスを含んでいる かどうかにかかわらず、2i を使うクラスタが全て 1.3.1 にアップグレードしたあとに 適用されなければなりません。

Riak ノードでこの上書きを実行するためには:

riak-admin reformat-indexes [<concurrency>] [<batch size>]

concurrencyオプションは同時に何個のパーティションを上書きするかを決めます。 特に指定されない場合はデフォルトで2となります。 batch size は一度に何個の キーを変更するかを指定します。デフォルトは100です。 負荷がかかっていなければ concurrencyを上げると、もっと早く終わらせることができるでしょう。 batchを 下げると、負荷がかかっている場合に他の操作のレイテンシが改善するでしょう。 上書きが終了すれば、結果はログに表示されます。 もし上書きが失敗していたら再実行してください。 この場合、上書きしていないキーだけを上書きしようとします。

もし1.3.1から1.3へのダウングレードをしたい場合には、ダウングレード後も正しく動作するために インデックスを古いエンコーディングに再フォーマットしなおさないといけません。 これをするためには、--downgrade フラグを riak-admin reformat-indexes に与えます。

riak-admin reformat-indexes [<concurrency>] [<batch size>] --downgrade

concurrencyとbatch sizeのパラメータはアップグレードの場合と同様です。

[1] https://github.com/uwiger/sext

[2] https://github.com/uwiger/sext/commit/ff10beb7a791f04ad439d2c1c566251901dd6bdc

bitcaskの起動時間の改善

vnodeを並列に起動しない問題を改善しました。マルチコアのマシンで動作するとき、 バックエンドにbitcaskを使っている場合は起動時間がかなり改善するでしょう。 我々のクラスタでは桁違い(~10倍)の性能が出たこともあります。

PR/PW の挙動

これまでのRiakでは get と put の PR/PW が指定された場合、指定された数のプライマリが オンラインかどうかだけをチェックしていましたが、 vnode が本当に応答したかどうかまでは確かめて いませんでした。もしPW=2だった場合、ひとつのプライマリとひとつのフォールバックに書き込み成功すれば、 もうひとつのプライマリへの書き込みに失敗しても成功の応答を返していました。

Riak 1.3.1では、PRとPWでは、指定された数のプライマリが結果を返すまでは待つようになりました。 これは、 PR+PW > N かつ全てのリクエストが成功したら書き込んだデータが必ず読めるようになったことを 保証するということです（その間に他の書き込みや、修復不能なレプリカ障害がない限り）。

失敗したPWは用意に部分書き込みになりうることを忘れないでください。この変更は純粋に、 read/write の成功で保証される内容を強化したものです。詳細は以下のプルリクエストのリンクをご覧ください。

解決された Issues / PR

Riak 1.3.0 リリースノート

Riakの新機能と主な改善点

アクティブ・ アンチエントロピー(Active Anti-Entropy)

Riak 1.3の新機能です。 Riakは今回アクティブ・アンチエントロピー(AAE) サブシステムを組み込みました。これはRiakクラスター全体に渡るデータの検証と修復を行うものです。 AAEシステムはデータの欠落、不一致を確認するために、データレプリカ間で定期的に情報を交換します。不良レプリカが見つかると、これを直すためにAAEはread repairを実行します。AAEは完全に自動化されており、多くのデータ消失シナリオ（ディスク故障、古いバックアップからのリストア、bit不良など）を防ぐ新たなレイヤーとなります。

AAEはハッシュツリー交換を使って実装されています。これによりデータレプリカ間で交換されるデータ量は、Riakに保存された全データではなく、不整合となっているデータに比例します。すべてのデータが同期されている場合(通常の状態)、素早く、かつ極めて低いオーバーヘッドで情報を交換します。このためAAEは、クラスタへほぼ影響を与えることなく、１分間に複数回の交換を行えます。

AAEのハッシュツリーは通常のRiak K/Vデータとは分離されたLevelDBインスタンスに永続化されます。まっさらなRiak1.3クラスタを初めて起動すると（もしくは以前のリリースからアップグレードすると）各パーティションデータを参照することでハッシュツリー情報を生成します。デフォルトでRiakは各ノードで１時間毎にひとつのハッシュツリーを生成します。パーティションデータの参照に一時間以上かかる場合、Riakは必要に応じて次のハッシュツリー生成を開始します。ただしデフォルトでは同時に生成するハッシュツリーは2つまでです。

一度ハッシュツリーが作られると、Riakへ送られるwriteに従って最新の状態に保たれます。しかしK/Vデータとハッシュツリー間の乖離を防ぐために、ツリーは定期的に期限が切れて無効となり、再生成されます。ツリーの再生成はbit不良のような見えにくいデータ破損も防ぎます。デフォルトでツリーは１週間で期限が切れて再生成されます。

今まで述べた内容（およびその他の項目）は app.config にて設定できます。AAEに関する設定項目は riak_kv セクションにあり、どのようなオプションが選択可能かについてのコメントがついています。

AAEの動作状況を知るのに、Riakは riak-admin aae-status コマンドを提供します。AAEのステータス出力は、エクスチェンジ、エントロピーツリー、そして修復した鍵の3項目に分かれます。

================================== Exchanges ==================================
Index                                              Last (ago)    All (ago)
-------------------------------------------------------------------------------
0                                                  3.8 min       4.1 min
91343852333181432387730302044767688728495783936    3.3 min       7.8 min
182687704666362864775460604089535377456991567872   2.8 min       8.3 min
274031556999544297163190906134303066185487351808   2.3 min       6.3 min
365375409332725729550921208179070754913983135744   1.8 min       5.5 min
<snip>

エクスチェンジの項目では、各K/Vパーティション間のAAEによる情報の交換についての情報を示しています。 Last の列は、パーティションとそのsiblingレプリカのどれかの間で、いつ最も新しい情報の交換が行われたかについて示しています。 All の列では、パーティションがすべてのsiblingレプリカとやり取りを終えてからどれだけ経っているかについて示しています。簡単にいえば、All の列はそれぞれのパーティションがどれだけ古くなっているかについての時間の上限を示しています。具体的には、パーティションの中のデータについて、そのデータのすべてのレプリカが無効になっていない限り、 All で示された値よりも古いデータでは失われたり不整合が起こっていたりすることはないということです。

================================ Entropy Trees ================================
Index                                              Built (ago)
-------------------------------------------------------------------------------
0                                                  22.1 min
91343852333181432387730302044767688728495783936    22.6 min
182687704666362864775460604089535377456991567872   22.3 min
274031556999544297163190906134303066185487351808   22.9 min
365375409332725729550921208179070754913983135744   22.3 min
<snip>

エントロピーツリーの項目では、パーティション毎に、いつハッシュツリーが作られたかを示しています。AAEの情報の交換に参加する前に、各パーティションにはハッシュツリーが作られなければなりません。前述の通り、これらのツリーは作成後（デフォルトでは）1週間で無効となり再作成されます。

================================ Keys Repaired ================================
Index                                                Last      Mean      Max
-------------------------------------------------------------------------------
0                                                     0         0         0
91343852333181432387730302044767688728495783936       87        21        87
182687704666362864775460604089535377456991567872      0         0         0
274031556999544297163190906134303066185487351808      0         0         0
365375409332725729550921208179070754913983135744      0         0         0
<snip>

修復した鍵の項目では、AEによって成された修復についての情報を示しています。これには最新の情報の交換で修復された鍵の数、またすべての情報の交換でなされた修復についての平均値と最大値が含まれています。

注: すべてのAAEの状態情報はメモリ中にあり、ノードの再起動でリセットされます。ツリーの作成情報のみが永続的に残ります。これはツリー自身が永続的だからです。

AAEに関する注意事項:

  1. ツリーは情報の交換が起こる前に作成されていなければなりません。ツリーはデフォルトでは1時間に1度作られるため、すべてのツリーが作られるまでには1.3について最初の起動またはアップグレードが起こってから 「ring_size / number_of_nodes 時間」かかります。そしてこの時間がAAEがすべてのデータを保護するまでにかかる時間となります。

  2. 一般にツリーの作成にはCPU一つを可能ならば100%使用しますが、Riakの性能には最小限の影響で済みます。BitcaskをK/Vデータに使う際、ツリーの作成中は list_keys, list_buckets, および Riak EEの fullsync 複製戦略にかかる遅延時間が増える可能性があります。一度ツリーができれば、1週間後にツリーが無効になり再作成されるまで、これらの問題は起こることはありません。

  3. データの不整合や損失のない正常なクラスタでも、AAEでは時々少量（1つか2つ）の鍵を修復することがあります。これはあるノードに対しての書き込みが発生している際に、AAEがその同じノードに同時に情報の交換をする際に起こります。例えば、ある書き込みがノードAに到達済みでノードBへ向かっている途中にAAEが実行されると、ノードAへの書き込みは見えてもノードBに対するものは見えないため、強制的に修復を行います。AAEは読み込み修復のための読み込みしか要求しませんから、この振る舞いは全く安全です。

  4. AAEはRiak K/Vの機能であり、Riak Searchのデータは保護しません。

MapReduce Sink バックプレッシャー

MapReduce には Riak Pipe によりステージ間バックプレッシャーが導入されました。Riak 1.3 より前は sink まではバックプレッシャーは適用されませんでした。PB/HTTP エンドポイントは pipe の出力レートをすべて捌けると仮定されていたためです。Riak 1.3 では、 sink までバックプレッシャーを拡張し、エンドポイントでも処理あふれがなくなりました。バックプレッシャーは sink バッファのソフト上限と、ワーカによる上限チェック間隔にてチューニング可能です。これらは Riak コンソールから application 環境変数を設定するか、app.config ファイルの riak_kv セクションで設定できます (以下、デフォルトを示します):

{riak_kv,
 ...
 %% Soft cap on the MapReduce sink's buffer,
 %% expressed as a positive integer number of messages
 %% (one message is used per MapReduce result)
 %% MapReduce sink バッファのソフト上限。
 %% メッセージ数を正整数で設定します。
 %% (MapReduce 結果ひとつがメッセージひとつに対応します)
 {mrc_sink_buffer, 1000},

 %% Period at which a MapReduce worker must check
 %% the sink's buffer cap, expressed as an integer
 %% number of messages to send before waiting on
 %% an clear-to-send acknowledgement
 %%   0 = wait for acknowledgement of each message
 %%   1 = wait every other message
 %%   'infinity' = never wait for acknowledgements
 %% MapReduce ワーカが sink のバッファ上限をチェックする間隔。
 %% 送信可能確認応答を待つまでのメッセージ数を整数で指定します。
 %%   0 = すべてのメッセージに対して確認応答をまちます
 %%   1 = メッセージひとつおきに確認応答を待ちます
 %%   ‘infinity’ = 確認応答を待ちません

 {mrc_sink_sync_period, 10}
}.

IPv6 サポート追加

Riak Handoff と Protocol Buffers インターフェイスは IPv6 アドレスで待受可能になりました(HTTP インターフェイスはすでに IPv6 をサポートしています)。アドレスの指定は "::1" (localhost を表します) のような文字列形式でも、{0,0,0,0,0,0,0,1} (同じく localhost を表します) のような 8-タプルによる 16 バイトアドレスの指定でも可能です。IPv4 アドレスもどちらの形式でも表せます(ただし後者の形式は 4-タプルで 4 バイトです)。 注意: Riak ノード名には適用されません。クラスタメンバー管理の IPv6 サポートについては、 inet_dist_* 設定を参照ください。 Erlang documentation

Luke 削除

Riak 1.2 リリースで廃止予定とされた luke application は、このリリースで取り除かれました。

riak getpid 追加

riak stop にバグ(修正されたバグ一覧に入っています)があり、修正の際に Riak 自身の PID 取得方法を変更しました。バグを修正しているとき、Riakで提供されていないスクリプトに頼りたくないシステム管理者にとっては、getpidはとても便利に思えたためです。 riak getpid ではその名の通り実行中の Riak の PID を返すようにしました。失敗時には終了コード 1 で終了します。これは小さな機能ですが ps や、 grep, awk を使う時間を節約してくれるでしょう。

Riaknositic のデフォルト同梱

Riaknostic が Riak パッケージに含まれるようになり、利用しやすくなりました。1.3 より前のバージョンでは、ユーザは riaknostic を別途ダウンロードする必要がありましたが、1.3 では riak-admin diag がすぐに使えます。

SmartOS 1.8 の追加サポート

SmartOS 1.6 に加え、1.8 向けのパッケージが利用できるようになりました。

ヘルスチェック

Riak 1.3 で新規導入されました。Riak Core はヘルスチェックサブシステムを含むようになり、ノードを特定の条件で監視し、その条件に依ってサービスを無効化あるいは有効化します。

ヘルスチェックを有効化するには app.config の riak_core セクションに新しい設定を追加してください:

%% Health Checks
%% If disabled, health checks registered by an application will
%% be ignored. NOTE: this option cannot be changed at runtime.
%% To re-enable, the setting must be changed and the node restarted.
%% ヘルスチェック
%% 無効の場合、application が追加したヘルスチェックは無視されます。
%% 注意: このオプションは実行中に変更できません。
%% 有効化するには設定を変えた後にノード再起動が必要です。
{enable_health_checks, true},

Riak は KV vnode のメッセージキュー長をモニターするヘルスチェックを登録します。kv ヘルスチェックを設定するには app.config の riak_kv セクションに新しい設定を追加します:

%% This option configures the riak_kv health check that monitors
%% message queue lengths of riak_kv vnodes. The value is a 2-tuple,
%% {EnableThreshold, DisableThreshold}. If a riak_kv_vnode's message
%% queue length reaches DisableThreshold the riak_kv service is disabled
%% on this node. The service will not be re-enabled until the message queue
%% length drops below EnableThreshold.
%% このオプションで riak_kv vnode のメッセージキュー長のヘルスチェックを
%% 設定します。値は 2-タプルで {有効化しきい値、無効化しきい値}です。
%%  riak_kv vnode のメッセージキュー長が無効化しきい値に達すると riak_kv 
%% サービスが無効化されます。有効化しきい値より下に値が下がるまでは
%% サービスは再度有効化されません。

{vnode_mailbox_limit, {1, 5000}}

注意: kv ヘルスチェックは Riak Search や Riak Pipe vnode には適用されません。

バケットプロパティのリセット

HTTP インターフェイスを通じて、バケットプロパティをデフォルト設定へリセット出来るようになりました。バケットプロパティは、クラスタ内のゴシッププロトコルにより、 Riak のリング構造体として保存されます。すでに使われていないバケットのプロパティのリセットや、デフォルト設定で使われているバケットのリセットによりゴシップで転送されるデータを削減できます。

syslog へのログ出力サポート

Riak 1.3 では syslog へのログ出力をサポートします。有効にするには riak の app.config で lager の下にある handlers セクションへ次のような設定を追加します:

{lager_syslog_backend, ["riak", daemon, info]}

この設定では、info レベル以上のすべてのメッセージを、 daemon ファシリティへ向けて、 ‘riak’ アイデンティティでログ出力します。さらなる情報は lager_syslog ドキュメントをご覧ください。

https://github.com/basho/lager_syslog

Installation Notes

インストールの注意点

RHEL/CentOS/Fedora ユーザは、RPM ツールが expect への依存を追加したため、次のようなメッセージが出た場合には:

$ sudo rpm -i riak-1.3.0rc1-1.el5.x86_64.rpm
error: Failed dependencies:
    /usr/bin/expect is needed by riak-1.3.0rc1-1.x86_64

Riak RPM を yum からインストールすることで依存性を自動解決できます:

$ sudo yum -y install riak-1.3.0rc1-1.el5.x86_64.rpm
Preparing...                ########################################### [100%]
   1:expect                 ########################################### [100%]
   2:riak                   ########################################### [100%]

解決された issues/ PRs