障害に強く速いストレージ
知念洋樹氏（以下、知念）：続きまして、今度はTKY02のストレージの話に移ります。TKY02ではCinder-Standard、Cinder-Archive、Cinder-Singleの3つ自作のストレージがあります。ほかにもTKY02に関してはアプライアンスのストレージとCephもありますので、そちらも紹介していきます。
まずCinder-Standardについて紹介します。コンセプトは「障害に強く速いストレージ」というところです。
速いストレージを作る上で、まず12本もの多くのNVMeを搭載し、トータル200Gbpsもの帯域をもつネットワークインターフェースを搭載したサーバーが必要になりました。そこでこちらのCinder-StandardはAMD EPYCを採用したストレージとなっています。
なぜAMD EPYCを採用したのかといいますと、豊富なPCIeレーンの恩恵を受けるためです。実際このAMD EPYCが出る前であれば、IntelのXeonを使った場合だとPCIスイッチを介しての接続になったりするので、ハードウェアの限界性能を引き出すのがここまでできなかったかなと思っています。
続いてデータの同期に関してですが、今回は筐体間冗長でDRBDを使用しています。またDRBDでの同期を高速化するために、1つのNVMeを5分割して、トータル60ものDRBDのデバイスを用いて同期をしています。
サービス用のネットワークは、インターコネクトのうち100Gbpsを用意していまして、ノンブロッキングで同期ができるような構成となっています。また、IOに関しても高速に処理ができるように、Cinder-Standard同様、カーネル空間からデータが出てくることがないように設計しています。
そんなCinder-Standardですが、そのいいところは冗長がある高速なストレージが誕生したというところです。冗長がとれた爆速ストレージなんですけれども、こちらの実際の速度ですが、ブロックサイズ4K、random writeでファイルをかけたところ、約70万IOPSを超えるIOを出すことできるという、ちょっと化け物のようなものになっています。エンタープライズストレージでここまで速度が出せるものは、他にはまだ出てきていないのではないかと思います。
もう1つは、約36TBも腹にNVMeに積んでいますけれども、そのデータ領域すべてを約2時間ほどでゼロから同期できます。そこはとても魅力的なものになっていると思います。
保守しやすい構成だったはずが……
続いてまずいところですけれども、ボリューム数が増加したことによってフェイルオーバー時間が長くなっていくということがあります。実際150ボリュームを超えてくるとフェイルオーバーの時間に約2分ほど費やすのが現状です。その原因には、iSCSIのLUNを復元させる処理にとても時間がかかっているということがあります。そういうこともありまして、解決策はボリューム数を削減するしかないというのが実情です。
少し関連しますが、ボリュームサイズの下限を設定しなかったことによって想定していたボリュームサイズより小さいサイズでボリュームが切られることが多く、1ボリュームあたりが小さくなってしまったがために、想定より多くのボリュームが作られてしまいました。そのために大変な問題も起きています。
その影響もありまして、保守しやすい構成だったはずがフェイルオーバー時間に耐えられないということで、保守がちょっとできないものになってしまいました。
実際起きた問題で先ほどとちょっと被りますが、フェイルオーバー時間が長くなりシステムが耐えられないよという声があったり、100Gpbsの帯域を実際に作られているボリューム数で割ってそれをcgroupで制限して提供していたりもしますので、1ボリュームあたりの転送速度がだいたい50MB/s前後までちょっと小さくなってしまい、ユーザーから「遅いよ」ということが伝えられたりもしました。
一度だけ発生したことですが、PSU2発がちょっとした時間差で両方とも死んでしまい、筐体1つ電源喪失することがありました。幸い、その電源喪失した筐体がスタンバイ機ということもあり、ユーザー影響はほぼ出なかったということがありました。
大容量なストレージを安価に構築できた
続いてCinder-Archiveです。Cinder-Archiveのコンセプトは「障害に強く大容量なstorage」というのです。先ほど紹介しましたCinder-Standardのハードディスク版と思っていただければと思います。
今回ベースとなるシャーシをお下がりのサーバーで構築していますので、ハードディスクの調達費用のみで構築できたため、非常に格安なサーバーとなっています。
Cinder-Archiveはバックアップなどコールドデータを置いてもらう目的で構築していますので、IOPSはあまり期待できませんけれども、大きいブロックサイズで保存したりする分には非常にいいものになっているのではないかなと思っています。
そんなCinder-Archiveのいいところですけれども、大容量なストレージを安価に構築できたという点が1つあります。今回お下がりサーバーを調達しましたので、このシャーシ自体も新規調達したとしても、そこまで高いサーバーにはならなかったんじゃないかなと思っています。
まずいところは、ボリューム数が増えるとCinder-Standardと同じようにフェイルオーバーに時間がかかったりとか、そういう問題が出てくるので、そこらへんは注意しなきゃいけないところなんですけれども、そこがまずいところとなっています。
現在、実際に起きた問題はなく、安定稼働しているのが特徴となっています。
最速storage。でも冗長なし
続きまして、Cinder-Singleです。こちらのコンセプトは「最速storage。でも冗長なし」というものになります。
基本的な構成は、先ほど紹介しましたTKY01のCinder-SSDと構成としては、ほぼほぼ同じものになります。そういうこともありまして、外付けのUSBハードディスクを想像してもらい、USBがiSCSIに変わったような構成と思っていただければと思います。基本的な構成はCinder-SSDと変わりませんが、AMD EPYCを採用したり、時代のトレンドを取り入れた構成にはなっています。
こちらのサーバーは、まだリリース前ではあるんですけれども、Cinder-SSDの実績を考慮するとほぼほぼ問題が起きづらいものになるんじゃないかなと考えています。
こちらのいいところですけれども、1つ目は、基本的にNVMeを横に並べているだけのものになりますので、爆速なストレージを安価に構築することが可能になっています。2つ目は、MySQLやHadoopなどミドルウェア側でデータを冗長をとる仕組みをもっているもので使いますと、容量効率がとてもいいストレージとなります。
まだこちらのほうCinder-Singleに関してはリリース前なので、まずいところとか実際に起きた問題はありません。
私からは以上となります。
アプライアンスストレージの紹介
宮元裕樹氏（以下、宮元）：続きまして、アプライアンスストレージを紹介します。
実際手作りのストレージもあるんですけれども、OSブート用の領域としてアプライアンスストレージを2ベンダから入れています。こちらのストレージはすべてオールフラッシュということで、NVMeタイプのものとSASタイプのSSDを利用しています。
2ベンダーのどちらの製品についてもActive-Activeな構成で構えておりまして、A1というシャーシが落ちたとしても、またA2のシャーシが落ちたとしても、どちらのシャーシが落ちたとしてもIOの継続が可能となっています。
次は、重複排除や圧縮も基本的にONの状態で利用しておりまして、実環境ではおよそ4分の1までデータ量が削減できています。
こちらのストレージに関しては、Cinderからすべて、ボリュームの作成や削除、あとスナップショットの機能に至るまで操作が可能となっています。
また、アプライアンスストレージなので当然のことといえば当然のことなんですけれども、安定した構成となっておりまして、今のところ障害は1件も起きておりません。
Cephのストレージ
続きまして、SDSを使ったストレージとして、Cephのストレージを2019年の10月頃から開始したものがあります。そちらもすべてNVMeの構成になっておりまして、1ノードあたり10本のディスクが挿さっており、2つのベンダーのNVMeを利用しています。
サーバーについても、世代としてはNaplesのCPUが入っています。また、ネットワークインターフェースも、25Gの×2本でLAGを組んでいます。
弊社の構成は、どのストレージ内で障害が発生しましてもそれが全体に波及しないように、ストレージ自体を3プールに分けています。それによってメンテナンス自体はプールごとに実施できるため、非常に可用性の高いものとなっています。また、3プール合計で現在数百TBのRAWの容量ですが、実現できています。
Cephなので3レプリカで運用しているのですが、実際のところ使える容量は3分の1になってしまうので、そちらのほうがちょっと残念な点ではあります。
実際、今現在、Cephを使っているバージョンは、13.2.8というMimicのバージョンです。こちらリリース当初は13.2.6を利用していまして、一度ローリングアップデートを実施しました。
Cephを使ったストレージの良かった点は、障害時のIOが縮小しまして、だいたいですけれども、障害が発生した場合でもIOが停止するのが数秒以内で、メンテナンス自体もサービスサイドから見た場合は数秒程度の停止で済むので、非常にメンテナンス計画が立てやすい状態となっています。
今後可能であればメジャーアップデート
また、容量の拡張が非常に容易でありまして、Ceph自体をそのノードにインストールしまして所定のツリーにmoveするだけで容量の拡張ができます。ですが、オブジェクトの再配置にもちろん時間がかかるため、その間はIO性能が低下するという現象が確認されています。そちらのほうですけれども、実際IOに影響を与えるのは、完全に止まるのは1秒程度で、再配置が終わるまでの時間はだいたい半分〜8割程度の性能の低下で済んでいます。
先ほども申しましたが、ローリングアップデートが現実的なため、実際13.2.6から13.2.8のアップデートはほぼ問題なく完了いたしました。実際のところまだメジャーアップデートというのはやっていないためどうなるかわかりませんが、今後可能であればメジャーアップデートのほうも実施していきたいと思っています。
そして実際に導入して起きたことといたしまして、約1ヶ月後ぐらいから、たまにIOが停止するという問題が発生するようになってしまいました。おそらくメモリ関係の問題ではないかと思っているのですが、いったんCephのバージョンアップとかプール自体の拡張、そしてメモリ関係のパラメータの変更をすることで、事象は収束しています。
それ以外に、デメリットというわけではなく、最初からわかっている話ではありますけれども、3レプリカなので利用効率自体がちょっと悪いかなとは思っています。
実際のところ、ユーザーのほうでもMySQLなどデータベース系はレプリケーションしてデータを保存していますので、実際、ストレージ側でも3レプリカ、上のアプリケーション側でも3レプリカみたいな状態で、若干利用効率が悪いなという点は認識しています。そこで、その代替案として、先ほど説明しましたCinder-Singleというのが登場しました。
あとは、実際運用し始めまして半年とちょっとなので、実際規模のほうがどんどん大きくなってきた時に、拡張性がいいのかどうかとか、あと安定性がという問題が発生しないかという点に今後は注目していきたいなと思っています。
ストレージはアプライアンス？それとも手作り？
次に、これまでストレージを手作りしたり、アプライアンスを導入してきたりとかそういうのをしてきて、実際サイバーエージェント内でどういう感想が得られたかなというのをちょっと挙げてみました。
左手にありますとおり、かなりの数のアプライアンスや手作りのストレージ、Cephを導入しています。でも、実際それを評価してみますと、アプライアンス自体は確かにかなり高コストで、たぶん桁が手作りの場合と1桁、2桁違うぐらいのコスト感にはなってきますが、その代わり高い信頼性とか可用性とか保守性が実現されています。また、重複排除や圧縮もすごいため、実際のところ、自分たちで作るよりかは確かに信頼できるのかなと思っています。
次に手作りストレージを実際に作ってみた感想は、やっぱり機器自体は比較的低コストで導入はできるけれども、その運用コストにピンポイントを当てると、ちょっと高めなのかなと考えています。
実際に手作りのほうで作ると、自分たちが必要とするスペックで設計することが可能なのでそのへんは柔軟にできるのですが、信頼性や可用性、保守性自体は自分たちがどこまで作り込むかという問題なのですが、やっぱりアプライアンスレベルというところまでもっていこうとするとかなり厳しいのではないかと思っています。
脱iSCSIをしたい
また最後にSDSの場合です。今回Cephを導入しましたが、コスト自体はたぶんどの構成、ハードディスクとかSASの……SATAのSSDか、あとはNVMeかによって非常にコスト感は変わってくるのかなとは思っているんですけれども、チューニング次第ではけっこう保守性や信頼性、可用性のほうは高いのではないかと思っています。
次に、今後のチャレンジとしまして、まだ実際にこれだという動きはありませんが、今後やっていきたいかなと思っているのは次のとおりとなっています。
実際これまで各ストレージ、Ceph以外はすべてiSCSIで接続していますが、脱iSCSIをしたいなとは考えています。といいますのも、最近はNVMe over Fabricということで、フラッシュを使うのであればそれらのプロトコルを使ったほうが低レイテンシーで高い性能が発揮できるプロトコルが出てきましたので、そちらを導入できればいいかなとは考えています。
実際プロトコルとしてRDMAとかそれを使った、それをEthernet上で展開するRoCEがありますけれども、既存の環境に入れるのはネットワーク的にちょっと難しいかなとは考えています。
それとは別にTCP/IP上で展開する部分に関しては、既存のネットワークと非常に親和性が高いため、実際入れるのは難易度がたぶん変わってくるのかなとは思います。また、OpenStackとの連携自体はやりやすいのではないかと考えています。
弊社内でいくつかのベンダーとベンダーの機器をお借りして検証しているのですが、IOPS自体は100万IOPSぐらいはすごく余裕で超える性能が出る機器でしたので、性能的には非常に魅力的かなと考えています。ですが、ちょっと製品自体はまだ最近出始めた、そもそもProduction Readyかと言われたらまだProduction Readyではないものをお借りしたんですけれども、まだ製品としてはこれからかなと考えています。
使いたい環境に応じて取捨選択が必要
最後にまとめです。
サイバーエージェントのプライベートクラウドにおけるストレージをご紹介しました。アプライアンスとか手作りとかCephの環境をそれぞれご紹介しましたが、それぞれにメリット・デメリットがあり、使いたい環境に応じて取捨選択が必要になってくるのではないかと思います。それにつきましては、本セッションを通じてストレージの選定の参考になればと思っています。
あと、今回のスライドに関しましてはけっこう省略した部分があるので、もっと詳細を知りたいとか、弊社内でも他社の事例というのはあんまり聞いていないので、他社の事例も知りたいので、できればみなさんコンタクトをいただければと思っています。
発表は以上となります。ご清聴ありがとうございました。
