ご挨拶

今まで当サイトでは、技術情報の詳細に立ち寄らず、弊社提供サービスの動向についての情報提供を主に掲載しておりました。

このたび、FLOSS プロフェッショナルサポート の拡充に伴い、弊社が有している技術情報を、当サイトでも発信していくこととなりました。

まずは先日プレスリリースを行いましたRook/Ceph クラスタ構築支援サービスに関連し、弊社が提供している各種サービスの基盤として実運用されている Kubernetes クラスタを題材に、Rook/Ceph クラスタのベンチマーキングやチューニングの実際を開示していこうと考えております。

具体的なパラメータ等つきましては、弊社サービスご契約者のみ開示となる部分もあるかと思います。Rook/Ceph を導入しようとしている方々、また導入してみたものの満足いく性能が出せずお悩みの方に参考情報となれば幸いに思います。

弊社 K8s クラスタの概要

nodepool

弊社では Azure Kubernetes Service (AKS) を用いてクラスタを運用しています。 3AZ 構成です。基幹部分に関しましては、各 Availability Zone (AZ) 毎に、それぞれ以下のような構成を取っています。

mode	VMサイズ	インスタンス数	用途
System	D4v5	1〜2	AKS が提供する DaemonSet等リソース優先
User	D8v5	1〜2	Rook/Cephクラスタ専用 (taint)

加えて、AZ を指定しない汎用の nodepool が存在します。各サービスやバックエンドのデータベースは、この nodepool にデプロイされます。

mode	VMサイズ	インスタンス数	用途
User	D4asv5	1〜	汎用(Spot instance に向かないもの)
User	D4v4	0〜	汎用(Spot instance)
User	virtual-node	0〜	Azure Container Instance 直結

AKS や AWS EKS クラスタの場合、Managed Disk (AWS の場合は EBS) は AZ に縛られるため、汎用 nodepool であっても、AZ 毎に用意するのが一般的です。しかしながら、弊社クラスタにおける Pod は、 Rook/Ceph が提供する RBD や CephFS をストレージとして利用するようルール化してあります(Rook/Ceph クラスタ自身は除く)。よって、Pod らにストレージの AZ 縛りが発生しません。

パブリッククラウドで自社サービスを運用している方ならご承知かと思いますが、特定の AZ のみ VM リソースが枯渇するという症状は、しばしば起こります。ノードのオートスケーリングが想定されている場合には、サービスレベル低下に直結するかもしれません。 Pod が AZ に縛られないことで、クラウド側の事情でのサービスレベル低下リスクを低減できます。 このメリットは、コストを掛けてでも Rook/Ceph を導入検討する、動機づけとなるかもしれません。

storage

Rook/Ceph クラスタが利用するストレージには、 Azure Managed Disk Standard_HDD を用いています。 弊社クラスタでは、ディスクを 6 つ束ねてクラスタリングしています。

Standard_HDD のスペックは IOPS が最大 500、同スループットが最大 60MB/s です。率直なところ、他のストレージソリューションと比して、単体性能としては大幅に見劣りします。しかし、あえてこの選択をしています。

このクラスタでのベンチマーク性能に関しましては、本記事に続くエントリで明らかにしていきます。

まとめ

本記事では、後に続くベンチマーク記事の前提となる、弊社サービス運用環境について概説しました。「サービスのほぼ全部のストレージで Rook/Ceph を利用している」という点を除くと、一般的な AKS クラスタと言えるかと思います。

次回以降、この環境でベンチマークを取っていく予定です。