「障害に強く、堅くデータ保持」をOpenStackで　サイバーエージェントのプライベートクラウド環境

21世紀を代表する会社を創る

宮元裕樹氏（以下、宮元）：「CyberAgentのプライベートクラウドにおけるストレージ戦略」と題しまして、サイバーエージェントの宮元と知念が発表いたします。

はじめに自己紹介をします。私は宮元裕樹と申します。2019年にサイバーエージェントに入社しました。主にストレージやコンピュートノードといったハードウェア周りの選定や運用を実施しています。趣味は自宅インフラで、自宅内に10Gのネットワークを引いたりサーバーを設置したりしています。

知念洋樹氏（以下、知念）：続きまして、知念洋樹と申します。2017年の7月にサイバーエージェントに入社しまして、ハードウェアの選定やらストレージ製品の選定・構築・運用など手広く従事しています。趣味はアマチュア無線やドライブをしています。

宮元：本日のアジェンダはこのとおりとなっています。まずサイバーエージェントについて紹介します。

サイバーエージェントは「21世紀を代表する会社を創る」というコーポレートビジョンをもち、「メディア事業」「AI事業」「ゲーム事業」の3つの柱で事業を進めています。

サイバーエージェントのプライベートクラウド

次にサイバーエージェントのプライベートクラウドを紹介します。事業部で主に独自のプライベートクラウドをもっておりまして、我々が所属するメディア事業では「Private Cloud Group」（PCG）というグループが運用しています。AI事業部でも「Strategic Infrastructure Agency」（SIA）というグループが運用をしています。

本セッションで紹介するプライベートクラウドは、こちらのメディア事業のプライベートクラウドとなっています。

次にPCGのプライベートの概要を説明します。PCGでは7年ほど前からプライベートクラウドを運用しており、詳細は後ほど発表しますが、これまで3環境を構築し、2環境が現存しています。

2018年から運用しているプライベートクラウドが今現在最新の環境となっており、こちらではコンピュートノードをディスクレスにしたりとか、ネットワークをIP CLOS化をしたりとか、OpenStackの環境をすべてコンテナ化しKubernetes上で動いているなど、先進的な取り組みを行っています。

続きまして、最新のプライベートクラウドの概要図を紹介します。最新のプライベートクラウドでは、コンピュートノードやOpenStackのAPIが動くKubernetesのクラスタはすべてL2のオーバーレイネットワークで動作しており、それらにストレージやファイアウォール、ロードバランサーが挿されています。

各ロケーションにおけるストレージについて、これから紹介いたします。

PCGのプライベートクラウドの概要

知念：替わりましてここからは知念がお伝えします。各ロケーションにおけるストレージの解説といたしまして、これまで弊社のプライベートクラウド環境は大きく3つあります。

まず1つは「TKY00」と言われているところで、今年2020年の頭にクローズしたばかりのロケーションです。こちらではプライベートクラウドのコントローラとして「Clover」という自社開発のものを利用しておりました。インターネット等で「サイバーエージェント Clover」を検索すると各種いろいろ記事が出てきますので、そちらを見ていただければと思います。

このロケーションでは1Uサーバーの腹持ちのディスクをもったサーバーでコンピュートリソースを提供しておりました。また物理サーバーの数も多く、データセンターのワンフロアすべてを貸し切り、約200ラックを使ってTKY00というロケーションを運用していました。

続きまして、「TKY01」と言われているものですが、そちらはOpenStackをコントローラとして用いておりまして、OpenStackのKiloベースで構築されています。現在、約3万vCPU分ものコンピュートリソースをもっているロケーションとなっています。

このロケーションはコンピュートノードの高密度化も行い、2U4ノードの高密度サーバーを多く利用しています。CPUはIntelのXeonのV2とV4の世代のCPUを混在で使っており、1ノード20コア、40vCPUとして使っています。メモリは256GB積んでいます。

続いて、最新の「TKY02」と名づけられているロケーションですけれども、こちらは先ほどのTKY01同様OpenStackをクラウドのコントロールとして利用しています。こちらはOpenStack Queensをベースにして構築しています。

このロケーションから、コンピュートリソースから腹持ちのディスクを完全になくしたディスクレスの構成をとっています。

このロケーションも2U4ノードの高密度サーバーを多く利用しており、CPUはIntel XeonのSkylake世代、1ノード40コア、80vCPU、メモリは512GB載せたノードを利用しています。

現在このロケーションでは約2万vCPU分ものコンピュートリソースがありまして、今12ラックで提供しています。余談ですが、今度はAMD EPYCを採用したコンピュートノードも出てきます。

障害に強く、堅くデータを保持する

話をストレージに戻すと、これまでプライベートクラウド環境では自作のストレージとして提供しているものが6つあります。その知見を少しでも共有できればと思い、簡単にストレージの構成や特徴、良いところ・悪いところ、運用中に起きた問題点などを紹介したいと思います。

自作のストレージと併せてアプライアンスのストレージやCephを用いたSDSのストレージもありますので、そちらも併せて紹介していきます。

最初に、もうクローズしたTKY00の「Ameba EBS」を紹介します。

Ameba EBSのコンセプトは「障害に強く、堅くデータを保持する」というものになります。こちらはClusterLVMを使ったおもしろい構成となっておりまして、今回紹介するストレージで惟一オートマチックにVMにボリュームがアタッチされる機構がなく、VMから直接iSCSIをしゃべらせてつなげるタイプのものになっています。

そして、サービスインから終了まで永久にβ版として稼働しいたため、一切課金したことがなく、ユーザーとしては利用する分にはウハウハなストレージだったのではないかなと思います。

Cinder-HDDは保守がしやすい

続きまして、TKY01の「Cinder-HDD」と「Cinder-SSD」について紹介していきます。

まずはCinder-HDDですけれども、TKY01はOpenStackベースで構築されていますので、OpenStack Cinderで制御できるかたちで作っています。コンセプトは先ほど紹介しましたAmeba EBSと一緒です。「障害に強く、堅くデータを保持」ということになっています。

そのAmeba EBSの進化系ということもあり、基本的な構成はあまり変わりませんが、大きく変わったところは、ClusterLVMが廃止されて、mdraidに置き換わったところです。

また、容量とIOのバランスを保つためにストアサーバーとゲートウェイサーバーが完全に独立したかたちとなっており、容量が欲しければストアサーバー、IOが欲しければゲートウェイサーバーを増設するということで、柔軟な構成がとれるものになっています。現在、ストアサーバーは8台、ゲートウェイサーバー22台で稼働しています。

続いてCinder-HDDの良いところですけれども、まず1つに保守がしやすいこと、もう1つが横にスケールさせやすいというものがあります。

保守がしやすいというのは、言うまでもなく、すべてが二重化されているため、その恩恵を受けたかたちとなっています。そうは言いつつも、ゲートウェイサーバー、フェイルオーバーさせたりする必要が出てきまして、そういう時はIOが一時的に止まったりしますが、そこは許容してもらわないといけないところです。

もう1つの横にスケールさせやすいというのは、容量が必要であればストアサーバーを、IOが欲しければゲートウェイサーバーを増やすことで対応できるというところから来ています。

Cinder-HDD のまずいところ

まずいところですけれども、mdraidの同期が遅いというのがあります。ストアサーバーをメンテナンスした際に場合によっては一から再度データを同期させなきゃいけないというものがあり、その時にユーザーからのIOのパフォーマンスを保持するためにmdraidの同期スピードを遅くしているため、そこから出てきている問題です。

続いて実際に起きた問題ですが、ゲートウェイサーバーがカーネルパニックで半死にしたりすることがあり、その時ハートビートは通り続ける状態になっているのですが、ハートビートが通り続けるが故にkeepalivedが死の判定をせず、フェイルオーバーが発生しないということがありました。

この問題を解決するために、Zabbixでこれらのサーバーを監視していますので、Ping監視がアウトになったらこの対象のゲートウェイサーバーを電源オフするというスクリプトを実行することで、フェイルオーバーが実行されるようになんとかやっています。

もう1つがエンクロージャやRAIDカードのファームウェアに起因するバグを引いてしまい不備が出てしまったとき、ベンダーからは「ファームウェアをアップグレードしろ」の一点張りでした。SASのエンクロージャを利用しているのですが、そちらがちょっと推奨と違う使い方というのもあり、騙し騙し使っているという感じにはなります。切れてしまったらその都度ゲートウェイサーバーでつなぎ直してあげるというのをよくやっています。

最速storage。でも冗長はありません

続きまして、TKY01のCinder-SSDの紹介をしていきます。こちらのコンセプトは「最速storage。でも冗長はありません」です。外付けのUSBハードディスクを想像してもらえると、とてもわかりやすいかと思います。単純にUSB接続がiSCSI接続になったと思ってもらえれば、そのとおりの構成になっています。

高速なIOに耐えられるストレージを用意するために、今回NVMeを利用しています。また、高速にIOを処理するために、基本的にカーネル空間からIOの必要な処理が出てこないように、全部カーネル空間に閉じ込めるようなソフトウェア構成をしています。なるべく速度が落ちる部分を排除したいというところからやっています。

そんなCinder-SSDですけれども、良いところは、簡単なしくみのため不具合が起きづらいというところです。いかんせん実際ハードウェアとカーネル空間で動いているものしかなく、間に介入するものもとても少ないので、非常に安定したものになっています。

まずいところは、保守がしづらいというところです。保守がしづらいというのも冗長化されていないというところから来るものでして、利用者には事前に通知をしてボリュームの離脱処理をしてもらってから保守作業を行っているため、その調整にはちょっと手間がかかります。けれども、利用者が協力的にしていただいているのでなんとか保守等もやっていけているという感じです。

実際に起きた問題ですけれども、まず1つはカーネルのバグを引いてしまって、カーネルアップデートを全台行うという祭りを行いました。このバグを引いてしまうとOSが再起動してしまうがためにこのCinder-SSDを安定して運用できないということで、泣く泣く全台カーネルアップデートをするということを行いました。

続いて、シャーシのバックプレーンにバグがありまして、NVMeが突如見えなくなるということも起きました。こちらは正常に動作するものと取り替えてもらって、今は安定して稼働しています。

（後半につづく）