はじめに
はじめまして、CyberAgent group Infrastructure Unit（CIU）に所属している知念です。普段は、データセンターの運用、サーバや、ストレージ機器の調達から運用までを担当しています。
今回は、Cycloud の新基盤の全貌に迫る連載シリーズの第二回として、Cycloudの新基盤を支えるハードウェア基盤についてお届けします。
本稿では、10年以上にわたり運用してきたプライベートクラウドのハードウェア更新を題材に、前世代からの改善点を交えながら、新基盤で実現した性能向上とコストメリットについてご紹介します。
サーバ機器の変貌
今回のポイント： CPUの高コア化に合わせて、2U4Nodeから1Uサーバへ設計を見直しました。
これまで
これまで、プライベートクラウドのサーバとして、2U4Nodeサーバをメインに採用してきました。採用理由は、1ラックあたりのCPU密度を高め、フットプリントを抑えるためです。
サーバ例1
- CPU: Intel Xeon 6138 x2 (80vCPU)
- Mem: 512GB
- NIC: 25GbE x2port
サーバ例2
- CPU: AMD EPYC 7352 x2 (96vCPU)
- Mem: 1024GB
- NIC: 25GbE x2port
このようなサーバを、1シャーシに4Node、1ラックあたり最大 9シャーシ 36Node 搭載しています。
そのため、1ラックあたり、80vCPU x 4Node x 9シャーシ = 2880vCPU もの計算リソースを搭載しています。
時代の変化
時代の変化と共に、1つのCPUあたりのCore数が増え、現在は100coreを超えるCPUもリリースされています。
CPUの高コア化が進んだ結果、従来と同じ2U4Node構成では、1シャーシあたりに収容される計算リソースが大きくなりすぎるという課題が見えてきました。シャーシ障害が発生した場合、一度に影響を受けるVM数も増えてしまい、利用者に不便を強いることになってしまう問題がありました。
そこで、新リージョンでは10年以上ぶりに1Uサーバへ回帰しました。
サーバ例3
- CPU: AMD EPYC 9655P (192vCPU)
- Mem: 768GB
- NIC: 100GbE x2port
このようなサーバを、1ラックあたり最大20台搭載しています。
そのため、1ラックあたり、192vCPU x 20Node = 3840vCPU と1Uサーバに回帰したにもかかわらず、これまでの世代より多くの計算リソースを搭載することができました。
これは、半導体生産技術の進化によるCPUの高集積化・高性能化が進んだことによるものです。
今までより少ないフットプリントでより多くの計算リソースを提供できるため、コスト面でもメリットが出せるようになっています。
さらに、1台のサーバでこれまでの4倍ものネットワーク帯域が使えるようになりましたので、より多くのコンテンツ配信ができるようになっております。
ストレージ機器の変貌
今回のポイント：ストレージは「種類を増やす」のではなく「一つで応えられる」方向で見直しました。
これまで
これまで、用途に応じたストレージ機器を用意し、適材適所でストレージを選択できるように、4種類のストレージを提供してきました。
- 高速で冗長性有り (VMのroot領域用)
- 高速で冗長性無し (DBクラスタやキャッシュ用)
- ほどほどの性能と冗長性あり (一般用途用)
- 性能は低いが大容量で冗長性有り (保管用)
ですが、利用者からすると種類が多く、どのストレージを選択したら良いか迷う状況を作ってしまいました。
新しいリージョンでは
新しいリージョンでは、ストレージの種類を1つにし、全ての用途に答えることができるストレージを用意しました。
時代の変化
時代の変化と共に、プライベートクラウドでも求められるストレージの種類が変わってきました。これまではBlockストレージを用意し提供していれば良かったのですが、ファイルストレージの性能向上に伴い、プライベートクラウド基盤でもファイルストレージが求められるようになりました。
今回、新リージョンでは、ファイルストレージをVMのバックエンドに利用する構成を取りました。新たな取り組みです。
採用したストレージ構成
- All Flash Storage
- Protocol: NFS v4.2
- Mount option: nconnect=8,tcp,noresvport
ファイルストレージのメリット
ファイルストレージを採用したことによるメリットが大きく2つあります。
- (利用者向け) メンテナンス時のI/O停止時間が従来比で約1/5まで短縮
- (運用者向け) iSCSI環境で発生していた問題からの脱却
特に利用者向けのメリットはとても大きいと考えています。
これまでのブロックストレージでは、ネットワーク冗長化を実現する都合上、メンテナンスや障害時に10秒程度のI/O停止が必要でした。
ファイルストレージを採用したことで、ストレージ機器のフェイルオーバー時間のみでI/Oを再開できる構成となり、メンテナンス時の停止時間を大幅に短縮できました。
これまでよりストレージ機器への帯域も太くなっていますので、ネットワーク帯域を多く利用するワークロードにも対応できるようになっています。
最後に
HWチームでは、今後も利用者の皆さまに安心して使っていただける安定した基盤を提供できるよう、ハードウェアの選定から保守運用まで継続して改善を進めて参ります。
新リージョンをご利用いただく中で、Compute・Storage基盤の進化を体感していただければ幸いです。
次回予告
次回は「Cycloud 新基盤の全貌 第三回 NW 編」の紹介をします
連載記事一覧
本シリーズでは、各チームが新基盤構築における技術的挑戦を公開しています。他のレイヤーの知見については、ぜひ連載の他の記事も併せてご覧ください。
Cycloud 新基盤の全貌 第一回 新リージョン基盤の全体像
Cycloud 新基盤の全貌 第二回 HW 編
Cycloud 新基盤の全貌 第三回 NW 編
Cycloud 新基盤の全貌 第四回 IaaS 編
Cycloud 新基盤の全貌 第五回 ComputeController 編
Cycloud 新基盤の全貌 第六回 LB 編
Cycloud 新基盤の全貌 第七回 KaaS 編
Cycloud 新基盤の全貌 第八回 FrontEnd 編
各レイヤの Cycloud の新基盤に関して、より詳細な仕様や設計思想を知りたい方は、上記各チームの Developers Blog 記事をぜひご一読ください。