この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ども、大瀧です。
今回のre:Invent参加で個人的にアツかったテーマのひとつが、EC2のブロックストレージ周りのセッションで濃いものが聞けたことです。3日目と4日目に行われた以下のセッションから、現時点でのブロックストレージのベストプラクティスが見えてきそうだったので、セッションから得られたことを自分なりにまとめてみました。
- STG402 - Advanced EBS Snapshot Management [11/14 17:30 Murano 3303]
- STG401 - NFS and CIFS Options for AWS [11/15 10:15 Venetian B]
ちなみに、プレゼンターはどちらもAWSでパートナーSAを務めるCraig Carlです。軽快な語り口で、Q&Aもスピーディーに答えていました。そのせいで、議論がヒートアップすると全然聞き取れなかったんですが(汗
うまく聞き取れなかったところや、個人的見解を多分に含みますので間違いやご表記などがあれば、ぜひご指摘ください。
EBSのバックアップ戦略
EBSはEC2インスタンスに接続して使うブロックストレージ。OS/アプリケーションからは見えませんがEC2インスタンスとは独立したネットワークタイプのディスクのため、インスタンスに障害が発生したとしても他のインスタンスに接続し、データを復旧させることができます。
ただ、EBSのAFR(Annual Failure Rate:年間平均故障率)は0.1%〜0.5%と定義されており、定期的なバックアップが必須です。EBSのバックアップとして、スナップショット機能を標準で利用することができます。EC2 APIをコールすることでディスクベースのバックアップを手軽に取ることができます。
スナップショットは自動で差分バックアップになるため(恐らく、AWS側のストレージで重複排除を施している)、異なる時点で複数回スナップショットを取得したり、スナップショットをコピーしたりしても課金対象は差分のみになります。
整合性の取り方
バックアップの取得で必ず課題に挙がるのが、整合性の取り方です。スナップショットでは、APIコールを実行してからレスポンスが返ってくるまでを静止点として、ユーザーがデータの整合性を確保する必要があります。スナップショットのステータスは、レスポンス後もしばらく取得中の状態が続きますが、内部ではCOW(Copy on Wirte)で静止点が保たれるため、APIからのレスポンスを受け取ったあとはI/Oを発行して構いません。
実際の運用で確実に静止点を確保するのであれば、EC2にスクリプトを配置し以下の流れで処理を行うのが良いでしょう。
- I/Oの停止処理 : DBの停止やディスクのアンマウントなど
- スナップショットAPIのコール : レスポンス待つようにすること
- I/Oの停止処理 : DBの開始やディスクのマウントなど
複数スナップショットの世代管理
APIコールで手軽にスナップショットを取得する他に、リージョン間でのスナップショットのコピー機能などスナップショットはあっという間に増えていきます。また、スナップショットから新たなEBSを複製し、そこからまたスナップショットを作成するといった、スナップショットの親子関係も複雑になっていきます。また、後述のRAIO構成を組むと、RAIDグループ内の全ディスクの整合性を同時に確保しなければなりません。
そこで、ある程度のスナップショットを管理する場合には、複数スナップショットを管理するツールの活用を検討しましょう。
- arche(現在はNot found。近日リリース予定)
- raidformer.py
- ec2-consistent-snapshot
archeのデモ。EC2インスタンスにタグを付加し、コマンドを実行するとタグの設定に従ってスナップショットの作成やローテーションが自動で実行されます。
コマンドを実行したところ
Management Consoleで見る、デモの設定例
ファイルサーバー(NFS/CIFS)の構成パターン
ファイルサーバーやRDBMSなど、ディスクの性能が求められるケースでは、EC2のインスタンスタイプおよびEBSの性能オプションで対策します。
インスタンスタイプ
EC2インスタンスタイプは、CPUやメモリの他にネットワーク帯域がタイプ別に定められています。ハイエンドのタイプの方がローエンドのものより多くのネットワーク帯域を確保できます。
EBS Optimized Instance
EBSはネットワークディスクのため、通常の構成ではEC2インスタンスのネットワーク通信の帯域とEBSのI/Oの帯域が共有されます。EBS Optimized Instanceは、EBS専用の帯域を確保することで、I/O帯域の安定化が期待できます。これも、インスタンプタイプによって帯域幅が定められています。
PIOPSとRAID0の組み合わせ
基本は、EBS Optimized Instance + PIOPSです。ただし、PIOPSの設定には上限があるため、それを超える性能が必要になる場合は複数のEBSを束ねるRAIO0を検討します。冗長性を意識するとRAIO5/6を選びがちですが、EBSのノードが確実に分散する保証はなく、RAID5/6で分散するべき複数のデータが同一ノードに配置されてしまう可能性があり、RAID5/6による冗長性は期待できません。EBSボリュームは、ユーザーからは見えませんがハードウェアレベルの冗長性は確保されているとのことなので、RAID構成にするのであれば、RAIO0で問題ありません。
1ボリュームずつ扱うのは管理が煩雑になるため、先ほどのraidformer.pyが活用できます。
インスタンスストアとEBSの組み合わせ
EC2のディスクとして、EBSのほかにインスタンスストア(通称Ephemeral Disk)があります。インスタンスストアは、EC2インスタンスを実行する物理ホストにあるローカルボリュームで、高い性能とシーケンシャルアクセスに強いという特徴があります。ただし、ローカルボリュームという性質からEC2インスタンスのStop/Restartのタイミングで、ディスクのデータが毎回消去される揮発性ストレージです。このため、インスタンスストアにファイルサーバーなどのデータを保存することはできません。
そこで、インスタンスストアに書き込みつつ、EBSにデータに保存することでインスタンスストアをキャッシュ領域のように活用することができます。セッションでは、同期方法としてDRBDをasynchronous replicationで動作させる例が紹介されていました。
ただ、DRBDの非同期モードによるEBSへのデータ保存にかかる時間には、気をつけなければならないですね。
ファイルサーバーのクラスタリング
ファイルサーバーをSPOFにしないよう、クラスタ構成を検討するケースもあります。セッションでは、NFSもしくはSambaサーバーをPacemakerでクラスタ化し、DRBDのsynchronous replicationでディスクを同期させる構成が紹介されていました。
データサイズが大きい場合は、分散ファイルシステム
EBSボリュームは最大1TBのため、RAID0でEBSボリュームを束ねたとしてもデータサイズが極端に大きい場合は賄いきれない場合があります。そんなときに検討するべきなのが、分散ファイルシステムです。セッションでは、GlusterFSやMS DFSなどが挙がっていました。
注意点として、GlusterFSはサイズの小さい大量のファイルだとパフォーマンスが低下することを挙げていました。
パートナープロダクトの活用
様々なディスク/ストレージ関連のプロダクトがAWSパートナーより提供されています。セッションでは、以下が紹介されていました。個人的には、最後のZadara(ザダーラ)をウォッチしていきたいと思いました。
Red Hat Storage
GlusterFSの商用版です。Red Hatのサポートが付きます。
Maginatics/SoftNAS
セッションで紹介したアーキテクチャに近い製品2つですね。
Zadara VPSA
Private Storage as a Serviceという、Direct Connectの専用線接続と、ストレージのスペース貸しがセットになった製品です。東京リージョンでもKVH社のスペースで展開されており、トライアルが可能です。
ただ、トライアルでどこまで試せるのか、課金が発生しないのかがよくわからなかったため、帰国してから検証してみたいと思います。
15
