LoginSignup
16
12

More than 5 years have passed since last update.

ディップAdvent Calendar 2018Day 18dip-net
@haya-miinディップ株式会社

オンプレのバックアップをS3に保存する

Posted at

はじめに

現在オンプレ環境（データセンター）で稼働しているシステムのバックアップをAWSのS3に保存しようという試みをしています。
その設計思想と検証したことについてまとめたいと思います。

現状

弊社のデータセンターで稼働しているシステムについては、ざっくり以下の方法でバックアップを取得しています。

１．各サーバーから前日分のログをDC内のバックアップサーバーに収集（一次バックアップ）
２．DC上のバックアップサーバーからAWS上のバックアップサーバー（EC2）にバックアップを転送（二次バックアップ）
３．AWS上のバックアップサーバーからGlasierに転送（三次バックアップ）

Glasierを使うと運用コストは抑えられるメリットはあるのですが、格納したログを取り出すときお金も時間もかかってしまいます。

要件

バックアップファイルをスムーズに取り出したい！

なんやかんやで時々ログ調査があるので、ログファイルを取り出すときのストレスから解放されたい

バックアップ環境が複数ある状況をやめたい！

一次、二次、三次とバックアップファイルを転送に転送を重ねているのでメンテナンス時に関わるスクリプトが多くて大変

AWS上のバックアップサーバー（EC2）をやめたい！

今後バックアップファイルの容量が増えるに伴い、EBSだとコストがかさむのでS3にしたい

システム構成検討

DBのバックアップファイルは容量が大きいので、DC - AWS間のファイルの転送はDirectConnect経由でグローバルは使わないようにする必要があります。
そこで検討したのは以下2つの構成です。

  • StorageGatewayを使用する
  • AWS上にプロキシサーバーを構築し、プロキシ経由で格納する

私の考えたそれぞれの構成のメリット・デメリットは以下の通りです。

StorageGatewayを使用する

image.png

【メリット】

  • ストレージ（S3）にファイルを格納・取り出す際にクライアントのOSコマンドでできる（awsコマンド不要）

【デメリット】

  • S3の料金の他、StorageGatewayのリクエスト料金+EC2の料金がかかる

プロキシ経由で格納する

image.png

【メリット】

  • 1つプロキシ環境をたてておけば、他用途でDC→S3にDirectconnect経由で格納したいときにも使える
  • プロキシサーバー自身は通信をプロキシしているだけなので安価なインスタンスタイプで構築できる

【デメリット】

  • AWS CLIを使用してファイルを格納するので、OSコマンドに比べて自由度が低い

弊社では検討の末、ファイルの格納・取出し時の利便性を重視し、StorageGatewayを使用することとなりました。

StorageGatewayを使ってみよう！

StorageGatewayとは

その名の通り、NFSクライアント（DCのバックアップサーバー）とサーバー（S3）を繋ぐゲートウェイです。
使い方としては、NFSクライアントサーバーからゲートウェイをマウントして使用します。
※対応プロトコルとしてはNFSとSMBがあるので、Unix、Windows問わず使えます。

一番のメリットとしては前項でも記載しましたが、クライアントサーバーからゲートウェイ領域に対してクライアント側のコマンドで操作できるという点かと思います。
awsコマンドを使用しないので、バックアップ収集スクリプトも現在使用しているものをほとんどそのまま流用できます。

ストレージゲートウェイはオンプレ環境にVMで構築するか、AWS上にEC2で構築するか選ぶことができますが、
今回の要件である、DC - AWS間の通信をグローバルに出さないで行う場合は、オンプレ側にゲートウェイを構築すると パブリック仮想インターフェイス を作成しなければならないので、今回はEC2でゲートウェイを作成します。

StorageGatewayの構築方法

AWS管理コンソールのサービスからStorageGatewayを選択し、構築を開始していきます。

1．ゲートウェイの選択

  • 今回はゲートウェイのサービスの中でも「 ファイルゲートウェイ 」を使用するので、ファイルゲートウェイを選択します。

001_ゲートウェイ作成_開始.JPG

2．ホストプラットフォームの選択

  • ゲートウェイのホストを選択します。今回はEC2で作成するので、EC2を選択し、「 インスタンスの起動 」をクリックします。EC2の作成画面が別ウィンドウで開きます。

002_ゲートウェイ作成_タイプ選択.JPG

3．EC2作成

  • 以下要件に沿ってEC2を構築します。ストレージゲートウェイを使用する条件を満たすインスタンスタイプは m4.xlarge 以上となりますので、インスタンスタイプはそれ以上で検討しましょう。
  • リソース要件： https://docs.aws.amazon.com/ja_jp/storagegateway/latest/userguide/ec2-gateway-file.html?shortFooter=true
  • キャッシュに割り当てる用のEBSを追加するのを忘れないように注意！（最低150GB用意すること）
  • 必要に応じてゲートウェイをクライアントからマウントするためのセキュリティグループを設定しましょう。

003_ゲートウェイ作成_EC2作成.JPG

4．ゲートウェイ接続確認

  • EC2作成後、IPを確認しファイルゲートウェイ作成画面に戻ります。次のページに進み、先ほど作成したEC2のIPを入力し、接続確認を行います。

005_ゲートウェイ作成_EC2接続.JPG

5．ゲートウェイのアクティブ化

  • EC2との接続確認がとれたら、ゲートウェイのタイムゾーン、ゲートウェイの名前を入力し、アクティブ化します。

006_ゲートウェイ作成_アクティブ化.JPG

6．ディスク作成

  • ファイルゲートウェイのキャッシュに割り当てるローカルディスクを選択します。rootディスクではないEBSを選択する必要があります。ディスクを作成したらゲートウェイの作成は完了です。

007_ゲートウェイ作成_ディスク作成.JPG

7．ファイル共有の作成

  • ゲートウェイに紐づけるファイル共有（ストレージとして使用するS3の指定）を作成します。「ファイル共有の作成」をクリックし、S3のバケット名と使用するプロトコルを設定します。
  • S3バケットは後から作成もできますが、事前に作っておくとスムーズです。

009_ファイル共有の作成_S3指定.JPG

8．S3の権限設定

  • S3のストレージクラスやIAMを設定します。IAMは「新しいIAMロールを作成する」で作成するとストレージゲートウェイの運用に必要なだけの権限のロール・ポリシーが生成されるので便利です。

010_ファイル共有の作成_S3権限設定.JPG

9．ファイル共有作成確認

  • ファイル共有の作成内容を確認し、問題なければ作成を完了させます。NFSクライアントのIP帯制限は必要に応じて設定してください。

011_ファイル共有の作成_確認.JPG

10．ストレージゲートウェイのマウント

  • 作成したファイル共有の詳細部にクライアントからのマウントコマンドが記載されているので確認します。クライアントからマウントができれば完成です！

012_ファイル共有_マウントコマンド作成.JPG

StorageGateway検証

StorageGatewayを使用するにあたり、以下検証を行いました。

  • どのLinuxコマンドでファイルの格納・取り出しが可能か？
  • 大容量データ格納時の挙動（NWトラフィック、ファイルが格納されるタイミング）
  • S3での操作内容（ライフサイクルでのファイルのローテート等）はすぐにストレージゲートウェイに反映されるのか

※ゲートウェイサーバー（EC2）は仮想アプライアンスなのでSSHログインができません。負荷を確認する際はCloudWatchで確認する必要があります。

弊社環境はLinuxOSがメインなので、Linuxサーバーをクライアントにして検証を行っています。
上記確認した結果を以下にまとめます。

使用できるLinuxコマンド

  • cp、rm、mv、cat、moreなんでもできそう
  • キャッシュがあればGlasierに入ったものについても同様に操作できるが、キャッシュが無くなった場合にはGlasierに入ったものについてはゲートウェイのマウントポイント上からの操作は不可。AWS管理画面からダウンロードする必要がある。

大容量データ格納時の挙動
検証用大容量ファイル：248G

  • 検証①　どのタイミングでS3にオブジェクトとして格納されるのか

    • 検証方法
      オンプレのバックアップサーバーのローカルからゲートウェイをマウントしている領域に大容量ファイルをcpで配置する
    • 検証結果
      転送途中のものもS3に格納される（ストレージゲートウェイに格納完了するまでS3に転送しないわけではない）

  • 検証②　大容量ファイル転送時の負荷はどこにかかるのか

    • 検証方法
      検証①と同じ
    • 検証結果
      CPU使用率は40~50%程度ではあるが、NWトラフィックがけっこう出る。（詳細は検証③の結果参照）
      ボトルネックはNWトラフィックになりそう。

  • 検証③　ゲートウェイのEC2のインスタンスタイプを上げると転送速度も速くなるのか

    • 検証方法
      インスタンスタイプがm4.xlarge、m5.xlargeのゲートウェイを作成し、それぞれ大容量ファイルを転送した時のゲートウェイのNWトラフィックと転送速度を比較する。
    • 検証結果
      インスタンスタイプ（NWトラフィックの最大量）を上げるとNWトラフィックが出る分、転送速度が速くなる
インスタンスタイプ NWトラフィック（DC→AWS） NWトラフィック（GW→S3） 所用時間
m4.xlarge 400Mbit/sec前後 2.5～3Gbyte 104m36.070s
m5.xlarge 550～600Mbit/sec前後 4Gbyte 73m29.273s

S3での変更のストレージゲートウェイへの反映

  • ゲートウェイ経由ではなく、S3上で行われた変更はキャッシュクリアをしないとゲートウェイ側に反映されない
    • ライフサイクルでバックアップファイルの世代管理をする時等
  • ゲートウェイのキャッシュクリアはAWS管理コンソール上から行うか、AWS API、またはAWS CLIにて実施可能
    • AWS CLIでキャッシュクリアする場合はawsコマンドのバージョンが 1.15.xx 以上である必要がある
[aws-cli]
aws storagegateway refresh-cache --file-share-arn [ファイル共有のARN]

最後に

ストレージゲートウェイは作る分には簡単なので気軽に検証できてよいなと感じました。また、ログの調査を行う際もファイルをローカルに落としてくる必要が無いので楽だなと感じます。
ただ、運用費はそれなりにかかるので、参照することが滅多にないものについてはプロキシ経由での格納でも問題ないのかなとも思います。

まだ運用開始していないのでこれから新しい課題が出てくるかもしれませんが、DCのバックアップをS3に上げる方法を検討をされている方はご参考ください。

16
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
16
12