この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは。
AWS事業本部コンサルティング部の芦沢(＠ashi_ssan)です。
2022/5/10に開催されたJAWS-UG朝会 #33にて「AWS DataSyncを構築/運用してわかったこと」というタイトルでLT登壇しました。
LT資料はこちら
内容
今回のLTは、業務でDataSyncの設計・構築を行ったことをきっかけにLTのテーマにしようと思い立ちました。
時間の関係もありましたが、「DataSyncとは」についてあまり触れられず、視聴者の皆さんを若干置いてけぼりにしてしまった覚えもあるので、本エントリではDataSync自体についての内容を補足したいと思います。
DataSyncについて
DataSyncとは、オンプレミス-S3間、S3-S3間のようなストレージ間でのデータ転送を簡単にセキュアに実行できるマネージドサービスです。
DataSyncの特徴として、以下の4つが挙げられます。
- 高速データ転送
- 簡易な操作性
- セキュアで高信頼な通信
- 低コスト
ここから登壇資料では触れられなかったDataSyncの特徴について補足します。
みなさんお馴染みのBlackbeltの資料にとてもわかりやすくまとまっていたので、以降の説明のために画像を引用しています。
高速データ転送を実現するために以下のような技術が使われているそうです。
- マルチセッション
- 通信データ圧縮
- エンドポイントのロードバランス
マネージドサービスなので詳しい内部の構造についてはわかりませんが、実際使っていてもスループットが高速かつ安定していたイメージです。1
簡易な操作性とあるように、構築や運用にかかる操作がとても単純かつ簡単です。
- オンプレミス-AWS間の通信の場合でも、オンプレミス側にエージェントを準備できれば簡単にセットアップが可能です。
- AWS側の作業もマネジメントコンソールから3ステップ(エージェント作成、ロケーション作成、タスク作成)で設定を完了させることができます。
- タスクのスケジュール機能もあるので、自動化も簡単です。
伝送経路のTLS暗号化、保存データ暗号化、自動再送によってセキュアで高信頼な機能を実現しています。
s3 syncなどCLIでデータ転送を実行することもできるかと思います。暗号化は問題ないかと思いますが、マルチセッションによる並列化や自動再送などCLIで実行する場合に難しいところをDataSyncを使えば考慮する必要がなくなります。
DataSyncは低コストで利用可能なことも特徴です。
DataSyncを利用して転送したデータに課金されるので、オンプレミス-AWSの上り下りにどちらにも課金が発生します。
DataSyncの構造として、転送元から転送先にデータを送信するのでオンプレミス→AWS、AWS→オンプレミスどちらでも課金は発生しますよ、といったら伝わりやすいでしょうか？
※DataSyncの料金にはコピーされたデータの AWS DataSync 料金に課金される、と記載がありました。
オンプレミスからAWSへデータ転送するAWSのサービスとして、他にSnowballやStorage Gatewayというものが思い浮かんだ方もいるかもしれません。
公式ドキュメント(BlackBelt、よくある質問)等を参考に以下のように比較をまとめてみました。
- DataSync
- オンラインで大量ファイルを移動
- Snowball Edge(Snow Family)
- オフラインで大量のファイルを移動
- Storage Gateway
- クラウドストレージへのアクセスを提供
DataSyncとStorage Gatewayの違いについてあまりわかっていなかったのですが、以下のBlackBeltにあるDataSync、Storage Gatewayを併用した構成を見て理解できました。
運用してみて分かったこと
続いて、実際のDataSyncを運用する中で出会った事象について紹介します。
DataSyncの構築後にタスクの異常終了をメール通知させられるようにEventBridge + SNSで設定しました。
設定のやり方などはこちらのブログにまとめております。
設定後、エージェントの異常によりタスクが失敗したときに通知がされませんでした。
公式ドキュメントのタスク実行ステータス：Errorの項目では以下と記載がありました。
この値はデータ転送が失敗したときに返されます。VerifyMode オプションが設定されていない場合、このステータスは [TRANSFERRING (転送中)] フェーズの後に生じます。それ以外の場合は、[VERIFYING (検証中)] フェーズの後に生じます。
この事象は、エージェントの異常によるタスクの異常終了はTRANSFERINGより前のステータス(おそらくLAUNCHING)の時点で起きてしまったことによるものと想定し、実際のステータスがEventBridgeでトリガーできるErrorではなかったことではないか、と考えました。
対策として、以下の2つを検討しました。
- タスクの成功(Success)で通知させるようにEventBridgeの設定を変更
- タスクの成功メールが毎日来る状態を正常、メールが来なかったら異常と判断
- そのままにする
- エージェント異常のパターンは別途エージェントのステータスで通知設定することでカバー
前者は運用不可が増えることを懸念して後者を選びました。
今回のような異常時に通知されない例外が発生する可能性はありますが、それを許容した形です。
まとめ
この登壇を通じて、DataSyncはいいぞ、タスクの通知設定をするときは少し気をつけよう、といったことが伝わっていたら嬉しいです。
感想&終わりに
本エントリでは、JAWS-UG朝会#33で登壇したLTの内容をレポートしました。
負荷が少ないだろうと思ってLTをこれまで主にやってきましたが、登壇資料を作っていると伝えたいことがどんどん増えてくるので、そろそろ20-30分枠の登壇も積極的に参加していきたいな、と思います。
以上、芦沢(＠ashi_ssan)がお送りしました。
- Direct Connectの利用や10Gbps回線の使用など、AWS構成やローカルネットワーク要件にもよるかと思います。 ↩
3
