石川 和彦 の記事一覧

皆さまこんにちは。GMOインターネットグループ株式会社の石川です。2011年のお名前VPS（KVM）から始まり、アプリクラウドbyGMO、ConoHa等と続き10年以上様々なサービスが稼働するストレージ環境の構築/運用・保守を担当しています。今まであまり表に出てこなかったストレージというキーワードでこれまでどのようなストレージを使っていて今後どうなっていくのかを書いてみようと思います。 2011年 この時期に一番採用されていたのは、サーバー内蔵のローカルストレージでした。 ローカルストレージというのはサービスを提供している各サーバーに組み込まれているストレージのことです。普段皆さんが仕事やプライベートで利用しているパソコンと同じでパソコンの筐体の中にはCPU・メモリ等と同じようにHDDやSSDが搭載されています。 単一の筐体の中にHDDやSSDが搭載されている点でいえば、パソコンと大きな違いはほとんどありませんが、大きく異なる点があります。通常、ノートパソコンでは1台、デスクトップ型のパソコンでも2台程度のSSDまたはHDDが搭載されていますが、私達が提供しているサービスが稼働しているサーバでは、2.5インチサイズで10本。2Uのサイズになると24本ものSSDまたはHDDを搭載することが出来ます。さらにはは32本の2.5インチスロットを持っているサーバもあります。 そのため、1台のサーバで10本ある2.5インチのスロットを全部に7.68TiBのSSDを搭載するとそれだけで、76.8TiBものストレージを利用することができるようになります。 24本の2.5インチスロットがあるサーバに7.68TiB x 24本搭載するとその容量は184.32TiBとなり、1台のサーバ上で100TiBをも超えるストレージ領域を作ることが出来てしまいます。 この当時はサーバ向けのSSDはまだ出始めたばかりで、容量も少なく価格も非常に高価でしたのでSSDではなく、SASのHDDをよく使っていました。 ローカルストレージは利用するにあたり特別な知識がなくても手軽に利用しやすい反面、複数本のディスクの故障に弱かったり、2台以上のサーバで稼働しているアプリケーションで共通のストレージ領域を参照したい場合においては、特別なソフトウェアを介して共有の仕組みを実装したりなどする必要があるため、サービスが順調に成長し、稼働するサーバ台数が増えることで運用上の負担が多くなっていきました。 2013年 ~ 2015年 この年から、ローカルストレージ環境で運用していたサービスにおいて、運用上の様々な問題が出てきたこと、SSDの普及が始まり2011年よりも安価に調達できるようになってきたため、SSDを利用したNFSストレージを自社構築を行い、サービスで利用するようになりました。 ローカルストレージとの大きな違いとして、複数台のサーバから1つのストレージへアクセスが集中するため、複数台のNSFストレージを用意してストレージへの負荷分散を取っていました。 また、このときから初めてVPSのバックアップ機能と呼ばれる機能提供をはじめたことで万が一NFSストレージに障害が起きてしまい、お客様が保存していたデータにアクセスが出来なくなってしまっても、別のHDDで構築したNFSストレージ上にあるデータから復旧できるようになりました。 この頃から私達が構築するすべてのストレージ環境では、お客様のサーバが稼働するストレージとは別にバックアップ用途のための大容量ストレージも用意するようになりました。 また、NFSストレージでディスクの共有ができるようになったことで、お客様に提供しているVPSが稼働している物理サーバの故障やメンテナンス時においても予備のサーバを備えておくことで、VPSを予備サーバに移動させてから故障対応/メンテナンスを行えるようになり、お客様に対してもサーバメンテナンスで長時間VPSが利用出来なくなる。といった影響が出にくくなり、お客様に対しても私達自身においても運用・保守の観点での負担が少なくなりました。 しかしながら、私達の提供するサービスをご利用頂くお客様の利用傾向として、ストレージには非常に高負荷となるディスクへの書き込み処理が想定以上に多いことが判明し、NFSストレージでのサービス提供において更なる対応が必要ということが判明しました。 2016年 ~ 2022年 NFSストレージを導入したことで、運用への負担、サーバメンテナンスでのお客様への負担が少なくなりましたが、その反面書き込みが非常に多いという状況においてNFSストレージの利用を継続することは困難と判断しました。そこでローカルストレージに近いレイヤーでお客様のVMへストレージサービスを提供できるiSCSIのアプライアンスストレージを導入いたしました。 iSCSIは昔からサーバでは標準的に利用されている、SCSIコマンドというディスクアクセスの命令をTCP/IPのネットワーク上での通信を行い、高速なディスクアクセスを提供するための規格です。 iSCISとよく比較される規格として、FC（Fibre Channel）がありますが、こちらはTCP/IPとはまた別のFibre Channel Protocolという規格のネットワーク上でSCSIコマンドによるディスクアクセスを提供します。FCを利用するためにはサーバにはFC-HBA、ネットワーク構築にはFC Switch（またはSAN Switch）と呼ばれる機器を光ケーブルで接続する必要がある点と、これらの機器を運用するための特別な知識/経験が必要となり導入への敷居は高くなります。 iSCSIはFCのような特別なネットワークの知識が必要無く、従来のTCP/IPのネットワーク機器を使うのでネットワーク技術者が多い弊社においては導入への難易度はほとんどありませんでした。 iSCSIのストレージを導入したことで、サーバからの大量の書き込み要求に対しても、NFSストレージで発生していた、ストレージが高負荷状態になることも解消され、ローカルストレージ、NFSと過去のストレージ環境で問題/懸念となった事象が解消されました。 2022年 ~ 現在 iSCSIストレージの導入で一旦はストレージを利用するにあたっての性能・運用/保守への課題がすべて解決されたように見えますが、実はそうではありませんでした。iSCSIのアプライアンスストレージという製品の性格上、提供元であるストレージメーカーでは製品寿命というものがあり、無期限に長く使える訳ではありません。（ストレージに限らずすべての工業製品には寿命という物があるため、このアプライアンスストレージだけ。という固有の問題ではありません。） また、ストレージを使うソフトウェア。とく我々がよく使うOpenStackやKubernetesには個別のストレージ事にドライバというものが提供されいるということと、これらのソフトウェアのアップデートのスピードはアプライアンスストレージのOSのバージョンアップよりも遥かに早く、数年で現在稼働中のアプライアンスストレージのOSがサポート外になってしまう。という懸念があります。 また、アプライアンスストレージはハードウェアとソフトウェアがセットで開発されている都合上、導入・維持に関しての金銭面でのコストというのも見過ごせない要因となります。 そこで、2022年から私達は、オープンソースで開発されているストレージソフトウェアである、Cephの導入を検討し始めました。Cephはブロックストレージ・共有ファイルシステム・オブジェクトストレージの3つのストレージサービスを1つのソフトウェアで提供することができ、そのソフトウェアも標準的なLinuxOS上で動作するため、アプライアンスのストレージを導入したときにくらべ導入に関するコストも低く抑えることができる点。オープンソースで開発されていることから、OpenStackやKubernetesのアップデートへの追従、更にはこれらのソフトウェアを開発している人たちがストレージ機能を提供する際にCephを使って開発していることもあり、ドライバの開発についても問題なく動作する状態で提供されているため、導入することのメリットが多数ありました。 Cephに関しては2022年から使いはじめたこともあり、まだ2年ほどしか利用していませんが、これまで使ってきた様々なストレージ製品と遜色ない安定性・性能を提供出来ており安心して利用できています。 最後に 今回初めて技術系の記事作成を担当させていただくことになり、記事のネタを考えたり、実際に書いてみましたが、ここでは書き足りていないくらいストレージの導入には様々なトラブルがありました。 次回このような機会がありましたら導入時に実際にあったトラブルや、運用で起きたこと等普段表には中々出て来ないような内容にも触れてみたいと思います。