キャリテク!マガジン
- TOP
- キャリテク!マガジン
- クラウドエンジニアの基礎力を身につけよう-ストレージ設計の勘所
クラウドエンジニアの基礎力を身につけよう-ストレージ設計の勘所
こんにちは。株式会社パイプラインの濱田です。
前回、クラウド(IaaS)のサイジングについて取り上げましたが、今回は少し踏み込んで解説していきたいと思います。
ストレージのサイジングはオンプレミスの知見が生きる
そもそも、なぜサイジングが必要なのかについて立ち返りたいのですが、ハードウェアを買い切るオンプレミスと違い、ブラウザ操作やプログラミングにより、システムのスケーリングが容易であることは、クラウドを利用するメリットの1つです。
では、なぜクラウド利用にあたってサイジングが必要なのでしょう。
- ストレージ容量を増やすにはオンプレミスでも扱うようなコマンド操作でパーティション操作が必要である
- ストレージの転送速度(IOPS)を変更したい場合、その反映に時間がかかる場合がある
- 一度増量したストレージ容量を減らすことはできないため、永続的にデータが増えるのか、一時的なデータ量の増加なのかを見極める必要がある
ですので、ストレージの設計は、現時点で必要なストレージ容量と消費する容量の増加率をある程度計算するのがよいでしょう。
ストレージ設計の優先度を整理しよう
とは言え、新規サービスなどで消費するストレージ容量が読めない場合、事前の設計において以下要件を明確にしておくことをおすすめします。
- 性能要件を優先すべき用途はどれか
- 耐障害性を優先すべき用途はどれか
- ある程度妥協できる用途はどれか
例えばアプリケーションを乗せるストレージについては性能要件が最優先されるでしょうし、読み込みがメインであればキャッシュに頼れる(メモリに乗せられる)けれども書き込み性能も求めるのであれば高IOPSなストレージが求められます。
一方、ログのように監査要件が厳しい用途であれば、耐障害性が求められます。
こういう用途こそ、クラウドベンダーが高可用性を謳うオブジェクトストレージ活用をおすすめします。
では、ある程度妥協できる用途は何かといえば、OSやミドルウェアのように、ユーザー独自”ではない”データであるとか、冗長化させておくなどの手段でカバー可能な用途が考えられます。
アプリケーションも、再デプロイすればよいデータと割り切ることもできます。
しかし、ユーザーが生成するデータについては、二度同じデータを生成することが困難なものばかりです。
また、拡張性についても考慮ができるとなお良く、
- データの増量が見込まれるディレクトリはどこか
- 読み書きの速度が重要視されるディレクトリはどこか
- データの保全性が求められるディレクトリはどこか
- 運用フェーズにおけるメンテナンス性が意識できているか
Ⅰ. ダウンタイムを最小限にできるか
Ⅱ. オペレーションの安全性を考慮できるか
Ⅲ. 不測の事態にロールバック可能か
あたりを考慮できればよいかと考えます。
リアルタイムですべてのデータを保全することにコストメリットを感じない場合でも、定時処理でデータをオブジェクトストレージへ逃がすなどの運用対処もできますし、クラウドならではの運用設計を行うことができれば、オンプレミスではできない、あるいはコストがかかるような運用も安価に実現可能でしょう。
なお、蛇足ではありますが、かつてオンプレミスでは必須であったRAIDの知見も、クラウド環境の運用においては優先度が下がります。
その理由ですが
- そもそもRAIDはバックアップではなく、ディスクの物理的な冗長化を行うことで故障対応開始までの業務継続を期待できることが目的の1つである。
- 性能向上を目的としたRAID0を組むなら、最適なストレージを選定しましょう。
- 責任共有モデルを思い出してください。クラウド環境のハードウェア保守はあなたの仕事ではありません。
おおよそ上記に収斂(しゅうれん)されます。
最後にお知らせです。このコラムを掲載いただいている京セラグループのAltXはエンジニア未経験者を積極的に採用しています。AltXは未経験者向けの研修が手厚い事でも知られています。
AltXへの入社に興味がある方は、以下のURLにある技術キャリアセミナーで、入社後の研修やお仕事など、個別に質問できますので、実際にお話を聞いてみるとよいと思います。興味がある方は以下をご覧の上、是非ご参加ください。
https://www.altx.co.jp/careetec/seminar/tokyo/