秋学期は Decentralized systems engineering とか Distributed algorithms のような授業を履修し，分散システム漬けの日々を送りました． 授業では実際に動くP2Pの分散システムをディアゴスティーニ式に作っていく課題が出され（非常に重く，細かい実装のデザインとデバッグで全ての土日が潰れる），講義で習った内容を理解していくというものでした． このシステムのゴールは，ネットワークで接続された，複数の独立したノード間で合意を取るようなシステムの実装を行うというもの． 実装には Paxos アルゴリズム と呼ばれるアルゴリズムを用いました．

Paxos とは

Paxos アルゴリズムとは，超簡単にいうと “信頼できない（ノードに情報が伝わらない可能性がある）ネットワークで，一つの値をみんなで共有する” ものだと思っています． つまり，パケットが途中で失われたりするような環境でも，誰かが提案した値は全員に伝わるか，あるいは否決されるかのどちらかであることを保証するということです．

課題では，分散システムに関する数々の功績を残した Leslie Lamport 氏 ¹ による Paxos Made Simple の内容に基づき，一件のファイルごとの合意をとるということが求められました．

論文によると， Paxos アルゴリズムは以下のような 2 つのフェーズによって合意を形成します:

Phase 1

• 値を提案するノードが，ある提案番号 n を持つ prepare リクエストをブロードキャストする．
• prepare リクエストを受け取ったノードは，提案番号 n と，過去に受け取って返答したリクエストの提案番号を比べる． n がこれまでのどの番号よりも大きい場合， n より小さい提案番号を持つ提案を受け取らないという promise を送り返す．また，これまでにすでに受け入れた値があれば，それも返す．

Phase 2

• 値を提案するノードが，過半数のノードから promise を受け取った場合，　promise に含まれる，他のノードによってすでに受け入れられた値を見る．もし，そのような値があった場合，そのうち提案番号がもっとも大きい値を提案する値 v とする．そのような値がない場合，任意の値を提案する値 v とする．そして，その値 v を提案番号 n の accept リクエストとしてブロードキャストする．
• accept リクエストを受け取ったノードは， Phase 1 と同様に提案番号 n と，過去に受け取って返答したリクエストの提案番号を比べ，過去に promise を送り返したどの提案番号よりも n が大きい時は，その提案を受け入れる．

Paxos の面白いところは，リーダーのようなものをあらかじめ割り当てることなく動作させることができるという点です． これは，値を提案する権利と，提案を受け取る権利の両方をノードに与えることによって達成されます．提案番号をノードごとにユニークなものにしておく（例えば n 個のノードが存在する場合，ノード k は提案番号を k, n+k, 2n+k…, と増やすように決めるなど）ことなどが考えられます．

Paxos を使って Total Order Broadcast を作る

テスト勉強をしている間，ふとこのような Paxos を使った合意は，例えばネットワークやノードが信頼できないような分散システムでの強い一貫性を保証するようなシステムに使えるのではないかと考えました． アイデアはこうです:

• 任意の個数の Paxos のインスタンスを使って，好きなだけ値を合意する．
• Paxos のインスタンスそれぞれに番号を割り当てる．
• 合意した値を Paxos のインスタンス番号順に並び替えることにより，全てのノードにおいて，同一の順序で値を受け取ることができる．

これは total order broadcast (あるいは atomic broadcast) が持つべき条件を満たしています． これは， Paxos は合意アルゴリズムであることから， termination （全ての故障していないプロセスは，いつかはある値に対し合意する）の条件を満たしていることからいえます． これにより，全ての故障していないノードでは，ある時間 t の時点で合意を行っている Paxos のインスタンス全てにおいて合意が形成されるような時間 t’ があるといえ，これにより，各ノードは Paxos のインスタンス番号に従ってメッセージを順番に受け取っていくことができ， total order broadcast (TOB) の total order 条件（全ての故障していないノードが，同一順序でメッセージを受け取ること）が満たされるからです．

このようなアイデアをベースに， Paxos を使用した TOB のライブラリとしてみました (GitHub のリンクはこちら)． なお，学期中の開発での反省点として，それぞれのコンポーネント同士の依存関係が大きく，バグを見つけるのが非常に大変であったということがありました． そこで，今回はメッセージ幅やり取りを行うモジュール， Paxos 本体， Paxos を使って 1 件の合意をとるモジュール，合意アルゴリズムを使って TOB を実装するモジュールのように，インタフェースを用いて，他の部分をモックして細かくテストできるような構成を意識しました．

ノードを落としてみたらどうなるか，実際の環境で動かしてみるとどうかなど，これからいろいろ試してみたいと思います．

やってみる

取り組む OSS を選ぶ

去年くらいから Rust を少しずつ触っているのですが、便利な開発ツールにいつも感動していました。 今回は rustfmt という、 rust-lang 配下のコード整形ツールのリポジトリを見てみることにしました。

good first issue をみつける

さっそくリポジトリの Issue を見ます。 Open な Issue のうち、 good first issue ラベルでフィルタします。 今回は該当するすべての Issue ですでに議論が行われていました…

ここで諦めかけますが、残った気力で 最新の Issue をのぞいてみます。

Issue の内容を把握する

if let の整形エラーが報告されています:

impl EarlyLintPass for NeedlessContinue {
    fn check_expr(&mut self, cx: &EarlyContext<'_>, expr: &Expr) {
        // 長い pattern です。ここが整形できない様子。
        if let ExprKind::Loop(body, label, ..) | ExprKind::While(_, body, label) | ExprKind::ForLoop { body, label, .. } =
            &expr.kind
            && !in_external_macro(cx.sess, expr.span)
        {
            check_final_block_stmt(cx, body, label, expr.span.ctxt());
        }
    }
}

max_width = 120 と設定したときに、 if let ExprKind::Loop(body, label, ..) | ExprKind::While(_, body, label) | ExprKind::ForLoop { body, label, .. } = （122文字）がうまく整形できないようです。 = の長さ（2文字です）が考慮されていないために、 if let と = の間の整形に文字数を使い過ぎてしまうようです。

この Issue には1年前にアサインされている人がいますが、Pull request がそのままになっています。 これを見てみると、コードレビューを受けた後、 Git の操作まわりでつまずいてしまっているようです。 怒涛の force push の跡。 初心者の方でしょうか（自分もはじめてのプルリクエストで同じことをしてしまったら、パニックになってしまうと思います）。

Contributor の方がやさしく指導されていますが、その後心が折れてしまったのか目立った動きはありません。 その後、別の方が何度かやり取りされていますが、やや殺伐とした雰囲気です（ヒィー）。

しかし、ほとんど修正が完了している Pull request が放置されているのはもったいない。 代わりに自分が取り組むことにします。

Fork/Clone してくる

ここから実際の作業に入ります。 この辺は OSS Gate で手取り足取り教えていただいたので余裕です（ あのときの Pull request はまだマージされていませんが…）。

まずは rustfmt を Fork してきます。 手元のマシンに Clone します。

nishimi@MacBook-Air ~ % ghq get git@github.com:ynishimi/rustfmt.git
...
warning: the following paths have collided (e.g. case-sensitive paths
on a case-insensitive filesystem) and only one from the same
colliding group is in the working tree:

  'tests/source/reorder_modules/ABCD/mod.rs'
  'tests/source/reorder_modules/abcd/mod.rs'
  'tests/source/reorder_modules/ZYXW/mod.rs'
  'tests/source/reorder_modules/zyxw/mod.rs'
  'tests/target/reorder_modules/ABCD/mod.rs'
  'tests/target/reorder_modules/abcd/mod.rs'
  'tests/target/reorder_modules/ZYXW/mod.rs'
  'tests/target/reorder_modules/zyxw/mod.rs'

ファイルシステムが case-insensitive であることによるファイルの衝突が生じました😢 case-sensitive なボリュームを作成して、 Clone しなおします。

エラーを再現する

準備ができたら、エラーを確認していきます。 Contributing.md を見て、まずはソースコードから rustfmt を実行する方法を調べます:

cargo run --bin rustfmt -- path/to/file.rs

Issue にあったコードをコピーしてきて rustfmt を実行してみると、確かにエラーが生じました:

nishimi@MacBook-Air rustfmt % cargo run --bin rustfmt -- ../test_fmt/src/test.rs 
   Compiling rustfmt-nightly v1.8.0 (/Volumes/dev/rustfmt)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 2.41s
     Running `target/debug/rustfmt ../test_fmt/src/test.rs`
Warning: the `version` option is deprecated. Use `style_edition="2024"` instead.
error[internal]: line formatted, but exceeded maximum width (maximum: 120 (see `max_width` option), found: 122)
 --> /Volumes/dev/test_fmt/src/test.rs:3:3:121
  |
3 |         if let ExprKind::Loop(body, label, ..) | ExprKind::While(_, body, label) | ExprKind::ForLoop { body, label, .. } =
  |                                                                                                                         ^^
  |

warning: rustfmt has failed to format. See previous 1 errors.

コードを修正する

では、コードを修正していきます。 git checkout -b max_width_split で作業用のブランチを作成しました。

今回はすでにレビュー済みの Pull request が存在しているため、これを参考に修正していきます。 Pull request でも触れられていましたが、今回の変更はStyleEdition::Edition2027以上でのみ有効となるように Gate しておきます。

テストを作成する

rustfmt では テストケースの作成 が必要のようです。 ./tests/source/ 下に整形前のコード、 ./tests/target/ に整形後のコードを置きます。

cargo test を実行し、エラーが生じないことを確認できました！

Pull request を作成する

これまでの変更をコミットして、 Pull request を作成します。 今回はもととなる Issue と Pull request に触れながら、変更点をまとめました。

Merge されるのを待つ

無事 Merge されました☺️ 今回は簡単な修正でしたが、自分のコードが rustfmt で動いているというのは嬉しいものです。

わかったこと

初心者もいる

今回実際にコントリビューションを行ってみて最も感じたのは、自分が思っているよりも初心者の方が多いということでした。 自分が Pull request を作成するにあたって、過去に Merge されたものをいくつか確認しましたが、 Description を描き慣れていない人やコードレビューでガッツリコメントされている人、途中で他の Contributor に助けてもらう人など、いろいろな人がいました。 また rustfmt リポジトリは Contributor の方がやさしくコメントをしてくださるので、あまり経験がない人でも気負わずにコントリビューションが行える環境であると感じました。

Issue は意外と放置されている

今回扱った Issue のように、何らかの理由で放置されているものは意外とたくさんあるように感じました。 放置されている Issue を拾っていくのは OSS のコントリビューション経験が浅い方でも比較的取り組みやすいと思います。

むすび

普段使っているツールの中身を見たり、修正を加えたりするのは楽しい作業でした。 今後も自分ができる範囲でコントリビューションを行っていきたいです。