【レポート】AWS Storage Services の特性理解と選択指針 #AWSSummit

こんばんわ、札幌のヨシエです。 AWS Summit Tokyo 2019 初日のB1-02で行われたセッションのレポートを書きましたのでご査収頂ければと思います。

登壇者

アマゾン ウェブ サービス ジャパン株式会社 技術統括本部 ソリューションアーキテクト 川野 純

ストレージサービスはお客様からのフィードバックを元に、様々な要件・ワークロードに対応するために大幅なラインナップ増加と多数の機能強化が行われています。そのため各ストレージサービスの特性を正しく理解することは、ワークロードに最適なストレージを選択する上で欠かせません。本セッションでは各ストレージサービスの特性とどのユースケースでどのサービスを使うべきかを整理してお伝えします。

目的

• ストレージの特徴を定量的に把握するための指標を整理
• ストレージ仕様をベースに各AWSストレージサービスの特徴と構成・オプションを理解する
• ワークロードの特性に合わせて異彩的なAWSストレージサービスを構成できるようにする

Agenda

• ワークロートにおけるI/O特性とストレージの特性を表す7つの指標
• AWSストレージの種類
• 典型的なワークロードでのストレージサービスの選択例

ワークロードにおけるI/O特性とストレージの特徴を表す7つの指標

どのようなワークロードがあるのか？

• Database
• Databaseへのクエリによる細かいI/Oが発生する
• HPC,機械学習
• 並列にデータの読み込みが発生
• データバックアップ
• 単一の大きいファイルサイズのファイルをシーケンシャル書き込み/読み取りが発生する
• DataLake
• 様々なデータフォーマットが読み込まれ、多種のシステムからアクセスされることで拡張性とパフォーマンスが求められるようなI/Oが発生する

AWSのストレージサービスとしてどのようなものがあるのか？

ブロックストレージ

• ローカルディスク装置、マウントによってアクセス
• EC2 InstanceStore
• Amazon EBS

FileSystem

• 専用プロトコルでのアクセス、複数のサーバーからアクセス
• Amazon EFS
• Amazon FSx for Windows ファイルサーバー
• Amazon FSx for Lustre

オブジェクトストレージ

• 仮想的なコンテナにデータ、属性、メタをカプセル貸して格納
• S3
• Glaicier

7つの指標とは？

• ①耐久性
• データが失われてしまう可能性の指標
• 堅牢性とも言われる
• ②可用性
• データへのアクセスが出来ない時間を示す指標
• ③セキュリティ
• ストレージに格納されるでーたの暗号化やアクセス制御やなどの指標
• ④拡張性
• 容量が足りなくなった時、柔軟にスケールできるのか？
• ⑤パフォーマンス
• 一般的なパフォーマンスを示すのは3つ
• IOPS
• スループット
• レイテンシ
• 一般的なストレージサービスのパフォーマンス特性
• ブロックストレージ
• スループット：低い
• レイテンシ：小さい
• FileSystem(スループット高い:レイテンシ小さい)
• スループット：高い
• レイテンシ：小さい
• オブジェクトストレージ
• スループット：高い
• レイテンシ：大きい
• レイテンシが関わるワークロードでオブジェクトは少し注意が必要
• I/Oパフォーマンスに影響を与える要素
• I/Oサイズ(ブロックストレージ,FileSystem,オブジェクトストレージ共通)
• 一般的にI/Oサイズが大きくなるとスループットが向上し、IOPSが低くなりレイテンシが大きくなる
• 並列度(ブロックストレージ,FileSystem,オブジェクトストレージ共通)
• ストレージサービスの性能を引き出すために重要
• 並列度が多くなるとスループットとIOPSが向上し、ストレージ性能の限界に近づくとレイテンシが大きくなる
• アクセスパターン(ブロックストレージのみ)
• ランダム方式 or シーケンシャル方式
• 物理レイヤーの特性が大きく依存
• FileSystem、オブジェクトストレージでは隠蔽される
• ⑥コスト
• ワークロードに求められるパフォーマンスとコストに見合ったものを選択するべき
• ⑦アクセス方法
• ローカルでマウントディスクのように扱うのか
• 専用クライアントを利用して専用プロトコルによる通信を行うのか
• APIによる通信を行うのか

AWSストレージサービス

ブロックストレージ(ローカル)の特徴

• インスタンスとストレージサービスの間の接続を考慮する
• EC2とEBSはNW経由で接続されており、最近のインスタンスではEBSとの専用帯域幅が確保される
• ~1750MiB/s
• ブロックストレージには数種類存在しており、それぞれで特性を持っている
• EC2インスタンスストア
• 一部のインスタンスでは一時的なローカルディスクを持っている
• これはインスタンスが起動しているホストのディスク領域を使用しており、インスタンスタイプによってSSD(暗号化可能）とHDD(暗号化不可能）のものがある
• インスタンスごとにマウントが違う
• SSDベース(同一AZ内で冗長)
• EBS 汎用 SSD(gp2)
• EBS プロビジョンド IOPS SSD(io1)
• HDDベース(同一AZ内で冗長化)
• スループット最適化 HDD(st1）
• Cold HDD(sc1）
• EBSの性能について
• I/Oリクエストを出す側(EC2インスタンス)とI/Oリクエストを受ける側(EBS)でそれぞれ特徴を持っている
• IOリクエストを出す側(EC2インスタンス
• インスタンスタイプやサイズによって、EBS帯域幅が異なる
• Nitro対応しているインスタンスは24時間につき30minバーストが可能
• I/Oリクエストを受ける側(EBS)
• EBSのバースト機能
• 容量に応じたベースラインパフォーマンスがある
• ストレージ容量が少ない場合、突発的なI/Oリクエストが来た場合に備えてバーストクレジットを消費しI/Oリクエストを処理できる
• gp2,st1,sc1で利用可能
• オーバーサイジングせずにパフォーマンスやコストのバランスが取れた構成になる
• (補足)クラッシュ整合性スナップショット
• パフォーマンス改善を目的として複数のEBSをソフトウェアRAIDを組んでいる環境でバックアップを取得する際には静止点を確保する必要があった
• この制限が最近のアップデートによって緩和され、問題点なくバックアップが取れるようになった

EBSで組んだRAIDもバックアップ可能。複数のEBS間でクラッシュ整合性のあるスナップショットが取れます

FileSystemの特徴

• EBSとは違って、共用ネットワーク帯域幅でアクセスする
• EC2やDB間のアクセスにも影響が出てくる

EFS

• LinuxサーバーからNFSv4クライアントでアクセス
• どのようなストレージなのか？
• データは複数AZに分散されている(冗長性、可用性を考慮)
• FileSystemは複数のサーバーにまたがって分散
• 単一の名前空間を用いて、マウントターゲットにアクセスしてデータアクセスが実現できる
• 保管データも伝送データも暗号化ができ、SecurityGroupでアクセス制御を実施することが可能
• パフォーマンスモードが2つある
• 汎用(推奨設定)
• 基本的には汎用モードを推奨
• CloudWatchメトリクスのPercentIOLimitが100%に近い状態が続くようであれば最大IOを検討する
• 最大I/Oモード
• 何百台、何千台がアクセスする際にレイテンシよりもスループットを優先してスケールさせるモード
• バーストモデル
• FileSystemの使用容量に合わせてスループットが増加
• バーストは容量に応じて最大12h
• プロビジョンドスループット
• 容量に依存せずにスループットを指定出来る
• 容量は少ないが、ベースライン性能よりもスループットが必要な時に選択される
• EFSの特性
• 性能を引き出すためには並列化が必須
• １つのインスタンスは最大250MiB/sec
• FileSystem性能を最大に引き出すには並列化が必要
• 分散ファイルストレージ
• 個々のI/O処理やファイル操作にはレイテンシがある
• I/Oサイズが小さい処理はオーバーヘッド影響が出やすい
• 即時整合性モデル
• 属性キャッシュの影響で反映に3秒ほど待つことがある
• (補足)コスト指標に影響が出そうなUpdate
• EFS低頻度アクセスストレージアクセスの登場
• ファイルサイズが128KiB以上勝つ30日間アクセスや変更がないファイルが対象
• ユーザー側で作業は不要
• バーストモードを使っていると標準ストレージクラスの容量に対してベースラインが変わるので注意が必要

FSx Windows

• SMB 2.0-3.11でアクセス
• 1AZで提供
• サーバーは冗長化されていないが、ストレージが冗長化構成となっている
• 伝送中、保存ファイルの暗号化が可能
• 最大で64TiB
• DFSレプリケーションを使用して高可用性構成が取れる
• メンテナンスウィンドウがあるので、そこに重複しないようにする
• 名前空間によるペタバイトレベルのFileSystemの構築が可能
• 1GiBあたり750KiBのスループットなので少ないストレージ容量ではキャパシティ指定にd注意が必要
• キャッシュが利用でき、小さいファイルで繰り返し使われる際はキャッシュを利用可
• リードレプリカを使うことでスケールアウト構成を取れる（読み取り負荷を分散)
• シャーディングによる、スケールアウト構成も取れる(読み取りも書き込みも同じぐらいのワークロード)

FSx for Luster

• Luster Clientでアクセスする
• Lusterも単一AZで使われる
• S3からデータを取得して使用する
• リポジトリに依存する
• レイテンシ、スループットが早い
• 1secごとに課金が入るのでコスト最適化がしやすい
• LusterはメタデータがMDTファイルは分割されており、OST(Object storeage target)に格納される
• 1つのOSTは3600GiB単位まで使える
• 1Tibごとに299MiB/secのスループット
• hsm_restoreコマンドでプリロード
• 初回ロードでレイテンシがかかるのでhsm_restoreを使用することが推奨
• hsm_actionで完了したかも確認したほうが良い
• メンテナンスウィンドウに注意
• 長時間のジョブには注意

オブジェクトストレージ

• ネットワーク経由でアクセスされる
• S3は容量制限なく使える
• シームレスに連携出来る
• S3はRESTサービスであり、REST APIまたはラップしてるSDKでアクセスする
• VPCエンドポイント経由でアクセスすることが出来る
• 3つ以上のAZに分散される
• アップデートによってリクエストレートが向上
• ほとんどのユースケースでプレフィックに数文字入れなくてもOK
• S3は結果整合性モデル
• リクエストレイテンシが変動
• 容量 + リクエスト数課金
• シンプルなRESTサービスAPIアクセス

AWSのストレージサービス

• 様々なワークロードにおけるI/Oで選択肢が変わる
• OLTP環境
• データファイルがランダムアクセスされる
• EBS種別としてgp2が推奨
• トランザクションログファイル データファイル同様にgp2が推奨
• アーカイブログファイル
• EBS種別としてst1が推奨
• CMSコンテンツ共有
• EFSを利用して全体の工数削減も実現できる
• Windowsでは利用できないが、Linux環境で動いている場合はEFSが推奨される

最後に

ストレージサービスのセッションとして整理されたセッションでした。 日頃より、データ保存の観点でディスク特性や使途を考慮して環境作成を作る点は最重要項目として考えておりましたが改めて特性を考慮して使用する点を振り返る機会になりました。

今後はよりよい環境作りを目指して、定期的に仕様を振り返っていきたいと思いました。