私の Gerrit リポジトリを NFS サーバに置くべきですか?
こんにちは、合同会社もなみ屋 FLOSS プロフェッショナルサポートチームです。
我々が提供するサポートサービスの対象には、 Kubernetes 上で Gerrit レビューシステムの構築を支援するパッケージである、 k8s-gerrit が含まれております。
k8s-gerrit を用いてプロダクションレベルの Gerrit サービスを構築する際には、幾つか留意事項があるのですが、それらのうち最も重要で深刻なのはストレージです。 本稿では、ストレージ周りの留意点について解説します。
k8s-gerrit とストレージの関係
k8s-gerrit では master-replica 構成が想定されており、複数 replica や master の HA 化のため ReadWriteMany (RWX) のストレージ利用がデフォルト設定となっています。 当チームも、基本的には RWX の採用をお勧めします。
Gerrit と NFS との相性
ここで、RWX ストレージ候補とし筆頭に上がるのが NFS です。 k8s-gerrit 自身も Helm chart に NFS サーバのデプロイを支援するコードが含まれており、また、多くのクラウドサービスでマネージドされた NFS が提供されています。AWS EFS など、高スループット低レイテンシをうたうサービスもあり、魅力的であることは、確かかもしれません。
一方、ソースコード管理リポジトリと NFS とは相性が悪いことが経験則として知られています。Gerrit (Git) に限らず、Subversion や CVS でも同じことが言えます。
他社技術ブログの引用となりますが、WANdisco 社の主張をここに紹介します。 (WANdisco 社は、Git が流行する前に大きなシェアを誇った Subversion の開発で名を馳せ、最近は Git の同期分散を実現する GitMS や Gerrit-multisite-plugin で存在感を見せています。 )
「Should I store my repository on an NFS server? (私のリポジトリを NFS サーバに置くべきですか?)」
記事は、以下のとおりに結論付けられています。
This article makes a strong and forceful argument against the use of NFS in WANdisco deployments, or in any system running critical SCM applications. While the use of NFS is not proscribed — given that it mostly works, we hope that the case that we have made will discourage you from running with it. However, if you must run with it, then make sure that you have contingency plans to deal with service disruption that may result from it.
抄訳します。
この記事では、WANdisco 製品や重要な SCM アプリケーションを実行するシステムでの NFS の使用に反対する、強力な主張を行っています。 NFS がほとんど機能することを考えると、NFS の使用は禁止されていませんが、私たちの事例があなたの NFS 採用の思いとどまらせることを願っています。 ただし、それを実行する必要がある場合は、それによって生じる可能性のあるサービスの中断に対処するための緊急時対応計画を必ず立ててください。
企業の公式技術ブログにしては強い口調ですが、当チームも同感です。
Gerrit で NFS が向かない理由
上記引用元にも言及がありますが、特に Gerrit では NFS が向かない明確な理由があります。 Gerrit が内部で使っている JGit は、ロック取得のため mtime へのアクセスを頻繁に行います。 つまりファイルシステムのメタデータのアクセスが増えます。
一方、NFS はメタデータへのアクセス性能が伸び悩みます。これはプロトコル設計レベルの事情が絡み、NFS に準拠している限り、つきまとう困難です。
そして、NFS の悩ましいところは「ほとんど機能する」ところです。結果、こんなシナリオになりがちです。
- 事前の評価では「問題なし」と評価された。
- Gerrit 運用開始。
- Gerrit の同時利用者が増え始めたところで、メタデータアクセスが増える。
- サービスレベル低下で NFS の限界が顕在化する。
どうしても NFS を使いたい場合
言うまでもなく、事前のベンチマーキングは必須です。 しかし、ストレージのベンチマーク用ソフトウェアには、大きく2種類あり使い分ける必要があります。
- スループット性能を探る。
- メタデータへのアクセス性能を探る。
OSS での前者の有名どころは fio です。fio は広く使われており使い所を間違えなければ有用ですが、メタデータへのアクセス性能を図る用途には向きません。(にも関わらず NFS の性能評価でもよく見かけます)
後者の有名どころは bonnie++ です。計測結果の Sequential Create Random Create の値、特に各 Read の性能が、Gerrit のロック機能にとっては重要になります。
参考情報
当チームが以前 Azure FileShare (NFS) を対象として、bonnie++ を用いて実計測した例が、別記事にまとまっています。
Metadata パフォーマンス比較 - CephFS vs NFS - Monami-ya LLC, Japan
k8s-gerrit 向けの NFS の代替は?
順不同で、下記のような製品が代替候補として上がります。
- Rook/Ceph
- BeeGFS
- Lustre
- GlusterFS
- NetApp ONTAP
NetApp ONTAP は Azure や AWS などいくつかのクラウド事業者がマネージドサービスを提供しています。 その他はオープンソースであり基本的には自前の運用管理が必要になりますが、サポートを表明している企業もありますので、必要に応じて利用する手はあります。
サポート承ります
合同会社もなみ屋では、FLOSS プロフェッショナルサポートの一環で k8s-gerrit に関する技術支援を行っています。また、Rook/Ceph のオーケストレーター Rook もサポート対象です。ご興味のある方は是非お問い合わせください。
