はじめに クラウドやSaaSの利用拡大に伴い、攻撃者に狙われやすいアタックサーフェスは拡大しています。 さらに、サイバー攻撃は自動化やAI活用により高頻度化・高度化しています。 攻撃側が有利になりやすい状況の中で、防御側は限られたリソースをどこに集中させるかという判断を求められています。その対応策の一つとして、外部公開領域を可視化できるASM（Attack Surface Management）への期待が高まっています。 対象読者 ASM導入を検討しているセキュリティ担当者 ASM導入後の運用設計に悩んでいる方 ASM（Attack Surface Management）導入

SCSKの畑です。 今回は実案件における Redis から Elasticashe（Redis OSS）への移行において直面したいくつかの仕様差異について、どのような対策を取ったのかも合わせて紹介したいと思います。ちなみに移行に関する初回のエントリは以下となります。 Amazon Elasticache 移行方式のまとめ とある案件において 他クラウド IaaS 上の Redis から Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。 blog.usize-tech.com 2026.02.12   差異その1：Elasticache は停止ができない まずはベーシックな内容から。 よく知られていることだと思うのですが、Redis と異なり Elasticache は停止ができません。メモリ上にデータを保持する以上、インスタンスを停止するとデータが失われてしまうが故の仕様かと類推するのですが、停止できないということは一度インスタンスを立ち上げた後は常時課金が発生してしまうことになります。特に性能試験用の環境のように、使用中は本番環境と同様の大きいインスタンスを必要とする環境ではその弊害もより大きくなってしまいます。 Redis も停止すればデータは失われる以上、（データを保持したままの）停止ができないというのは同様と言えるかもしれません。ただ、Redis の場合はデフォルトで起動時にバックアップ（dump.rdb ファイルなど）からのデータロードが可能なため、起動停止を前提とした運用は Elasticache より実施しやすいと言えると思います。 そこで、大きなインスタンスサイズを必要とする環境については、環境を使用していない時間帯はインスタンスサイズを縮小することで課金額を低減しようと考えていたのですが・・ふと、縮小先のメモリサイズより大きなデータが Elasticache 上に存在したらどういう挙動になるんだろう？という疑問が。実運用時においても同じような状況になることが予想できたため事前に検証しておくことにしました。 試しに 10 GB のキャッシュデータを cache.r7g.xlarge のインスタンスにロードした後、t3.micro にサイズを変更してみたところ・・ Failed to scale down to cache node type Replication Group redis-downsize-test because the node has insufficient memory. Please select a different node type or reduce current memory usage and retry のようなエラーが出力されてしまったため、（ある意味予想通りでしたが）縮小できませんでした。よって、Elasticache の（再）作成・削除により起動・停止を代替する方法が唯一の回避策という結論となりました。削除時にデータをバックアップとして残しておいて、それを（再）作成時に使用するような流れです。先述した Redis の挙動を Elasticache で実現しようとするとこうなります、とも言えますね。 直近にリリースした Elasticache で早速この対応が必要となったため、 一旦は AWS CLI で実装することで解決しました 。 ただし、この手法だと各環境ごとに Elasticache の（再）作成コマンドが必要になってしまうためあまり効率が良いとは言えません。本案件における AWS リソース/サービスのデプロイには CloudFormation を使用しているため、将来的にはそちらに移行したいところです。DeletionPolicy あたりを使用すればできるのかしら・・？   差異その2：一括移行の場合 Elasticache をバックアップから新規作成する必要がある 続いてはこちらのテーマ。上記内容（差異その1）とも関連する内容でもあります。 先般のエントリ でも言及していた通り、本案件における Elasticache のデータ移行は一括移行で実施する旨決定したのですが、一括移行において現行環境で取得したバックアップを新環境に移行する際において、そのタイミングでバックアップから Elasticache を新規作成する必要があります。言い換えると、作成済みの Elasticache に対して特定のバックアップをリストアするというオペレーションが行えません。 よって、一括移行のタイミングまで新環境（Elasticache）のエンドポイントが不明な状態になってしまうという懸念点がありました。当日移行（切替）のタイミングでアプリケーション側の各種設定を変更する必要がある訳ですが、その直前まで新環境（Elasticache）のエンドポイントが分からないというのは作業への影響が大きいと考えたためです。 当初この仕様にものすごく違和感があったのですが、Redis の場合も起動時にバックアップ（dump.rdb ファイルなど）のデータを読み込む挙動をしており、実のところ同じ仕様でした。。ただ、仮に同様のシナリオで別の IaaS 上の Redis に移行するケースを考えてみると、移行先サーバへの接続情報（IPアドレス/FQDN）は Redis 移行前に分かっていることになるので、その点においては差異があると思います。 一方で、過去の経験や上記（差異その1）の対応において Elasticache を同じ設定で再作成した場合、再作成前後で必ず同じエンドポイント名となったことから、裏取りも兼ねてエンドポイントの命名規則が分かれば（少なくとも現在の仕様において）事前に新環境でのエンドポイント名を導出することができると考えました。 AWS のドキュメントには該当するような内容がなさそうだったので、大人しく AWS サポートに確認しました。その結果、命名規則に関する公開情報はないという前提において現在の仕様を確認頂くことができたので、以下に共有します。クラスターモードや転送中の暗号化の差異によりエンドポイントの FQDN が異なるというのは正直気付かなかったところです・・ ◆クラスターモード無効・転送中の暗号化が有効 ・プライマリエンドポイント master.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント replica.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード無効・転送中の暗号化が無効 ・プライマリエンドポイント <クラスター名>.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント <クラスター名>-ro.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が有効 ・設定エンドポイント clustercfg.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が無効 ・設定エンドポイント <クラスター名>.<6文字のランダム文字列(※)>.clustercfg.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com (※) 「6文字のランダム文字列」は、同一アカウント・同一リージョンであれば同じ値となる 今回使用するのは 「クラスターモード無効・転送中の暗号化が無効」 のパターンに該当するので、こちらの命名規則を連携して一旦解決となりました。   差異その3：通信暗号化方式と認証方式の組み合わせにおける制約がある さて、ある意味本題というか、相対的に影響が大きかったトピックがこちらとなります。 現行の Redis では 通信暗号化方式：暗号化なし 認証方式：AUTH 認証 という設定だったため Elasticache でも踏襲しようとしたところ、なんと Elasticache の仕様として設定できない ことがわかりました。設定可能な組み合わせは 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 通信暗号化方式：暗号化あり、認証方式：認証なし 通信暗号化方式：暗号化なし、認証方式：認証なし のどちらかに限定されており、どれを選択した場合においても現行 Redis との非互換が発生してしまいます。また、現行 Redis との互換性を考えると、上記 3 つの組み合わせの内、2 についてはどちらの項目も現行 Redis からの変更になるため採用するメリットがないと判断し、それ以外の方式（1 or 3）のメリット・デメリットを整理した上でどちらの組み合わせを採用するかお客さんも交えて検討しました。 Elasticache における方式の組み合わせが限定されている理由として考えられるのは、「通信暗号化なしの場合は認証情報も平文で通信路を流れてしまうため、認証を設ける意味がない」というところだと思います。その意図は理解できるのですが、サービスレベルで組み合わせを限定するほどの意義があるのかというと・・正直ないのでは？というのが個人的な感想です。 ざっくりメリット・デメリットをまとめると以下の通りです。平たく言うと、現行環境と同一にする（ことで影響を抑えたい）項目としてどちらを取るかというような内容ですね。 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 メリット：AUTH 認証に関連するアプリケーションコードの変更が不要 通信暗号化に関連するアプリケーションコードの変更は必要 デメリット：Elasticache への移行により、通信暗号化に伴う性能への影響が生じる可能性あり 通信暗号化方式：暗号化なし、認証方式：認証なし メリット：Elasticache への移行により性能への影響が生じる可能性を相対的に抑えられる（通信暗号化しないため） デメリット：AUTH 認証に関連するアプリケーションコードの変更が必要 結論から言いますと、本案件では性能への影響を重視して 「通信暗号化方式：暗号化なし、認証方式：認証なし」 の組み合わせを選択するになりました。また、現在 AWS へのマイグレーションを先行して実施している別の案件でも同一方式が選択されていたことも理由の一つとなりました。   補足：今回のケースにおける、上記変更に伴うアプリケーションへの影響について 上記にまとめた通り、通信暗号化を有効にする場合・AUTH 認証を無効にする場合どちらもアプリケーションコードの変更はいずれにせよ必要になりますが、実際にどのような変更が必要かはアプリケーション側の実装に依存します。 今回のケースの場合、通信暗号化関連についてはいわゆるアプリケーションのコンフィグ変更が必要でしたが、いずれにせよ移行（切替）時に接続先を Elasticache のエンドポイントに変更する必要があることも鑑みると、影響はほぼなしという判断になりました。 対して、AUTH 認証の無効化については一部のライブラリを使用しているアプリケーションコードにおいて影響がありました。例えば、phpredis ライブラリを使用した以下のような php のコードで AUTH 認証なしのElasticache (Redis) に対して接続しようとすると $redis = new Redis(); $redis->connect($host, $port, $timeout); $authenticated = $redis->auth($password); 以下のように、3行目の $redis->auth($password) 実行部分においてエラーが出力されてしまいます。AUTH 認証が無効であるにも関わらず AUTH コマンドが実行されているという内容ですね。よって、このようなコードについて、対象処理の削除、Elasticache (Redis) に接続できた時点で各種操作ができるようなロジックへの変更などの修正が必要となりました。 PHP Fatal error:  Uncaught RedisException: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct? in /home/ec2-user/redis_test.php:14 ちなみに、AUTH 認証無効の Elasticache (Redis) に接続した状態でこの処理を実行したとしても、もしライブラリ側でエラーを返さないような実装になっていればコード変更が不要になった可能性もあります。そのあたりは使用しているライブラリに依存するところですが、上記については redis-cli のような公式ツールでも同じ挙動になったので、（言い方が適切がどうかはさておき）この実装自体は正しいのかなと思います。   まとめ 1点目・2点目については仕様だけ見てこういうものなのね、と一旦流していたのですが、よくよくユースケースを考えると困るみたいな内容でした。幸いどちらも事前に気づけてひとまず対策できたので良かったです。 トータルで一番影響が大きかったのはやはり3点目です。パラメータレベルでの互換性は事前にチェックしていたのですが、Elasticache においてはパラメータで設定できない内容だったことに加えて、個々の設定（通信暗号化/ユーザ認証）としては可能だけど組み合わせパターンに制約がある、という非互換性はちょっと予見できておらず面食らいました。先述の通りその意図は理解できなくはないんですけど、Redis との互換性を考えるとできるようにしておいても損しないんじゃないかと思うんですけどどうなんでしょうか。Elasticashe（Redis OSS）を選択する以上は、Redis との互換性を最優先するという意図があるでしょうし。 本記事がどなたかの役に立てば幸いです。

SCSKの畑です。 とある案件において 他クラウド IaaS 上の Redis から Amazon Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。   背景 前回のエントリでも軽く触れた通り Redis は KVS のため、例えばキャッシュのような揮発性の高いデータのみが格納されているようなケースではデータの移行要件がないこともありますし、移行対象のデータがあるとしても新しく立てた Elasticache にアプリケーション/バッチなどから必要なデータを改めて入れ直すなど、現行の Redis からデータを移行する必要がないことも多いと思います。 ただ今回の案件については、現行の Redis からデータを移行する要件がお客さんとの会話等などから明確であったため、それを踏まえて Redis から Elasticache（Redis OSS）へのデータ移行方式を検討することとなりました。 なお、当初は Elasticache（Valkey）への移行も検討されましたが、今回の案件では非互換の可能性を極力排除して AWS への移行（リフト）のみにフォーカスしたいというお客さんの意向もあり、Redis OSS を採用することとなりました。   Amazon Elasticache の移行方式  Elasticache への移行方式は以下3種類となります。一括移行 or 初期移行＋差分移行という考え方そのものは RDBMS などと同じですね。 ちなみに、初期移行は差分移行を開始する前に現行環境から新環境にデータを移行する工程、差分移行は現行環境の更新データを初期移行直後の時点から新環境に対して継続的にレプリケーションする工程をそれぞれ指します。一括移行は言葉通りの意味ですね。 一括移行 初期移行＋差分移行（AWS マネージド） 初期移行＋差分移行（RIOT などの外部移行ツール） 当初は初期移行＋差分移行の選択肢として DMS を使えると思っていたのですが、改めて調べるとサポートされているのは移行ターゲットのみであることが分かり、今回のケースでは採用できませんでした。 Sources for AWS DMS - AWS Database Migration Service Use the listed data stores as sources for different AWS DMS features. docs.aws.amazon.com Elasticache における一括移行は、移行元の Redis で save コマンドなどで rdb ファイルのバックアップを取得して S3 に転送・配置した上で、そのバックアップを使用して新しく Elasticache のインスタンスを立ち上げる流れとなります。 バックアップから新しいキャッシュへの復元 - Amazon ElastiCache Valkey から既存のバックアップを新しい Valkey キャッシュまたはノードベースのクラスターに復元し、既存の Redis OSS バックアップを新しい Redis OSS キャッシュまたはノードベースのクラスターに復元できます。また... docs.aws.amazon.com 対して、初期移行＋差分移行の方式は、AWSマネージドの方式と、RIOTなどの外部移行ツールを使用する方式の2種類があります。AWSマネージドの方式については、以下 AWS ドキュメントに一通りの記載があります。 Valkey または Redis OSS のオンライン移行 - Amazon ElastiCache オンライン移行を使用して、セルフホスト型 Valkey または Redis OSS から Amazon ElastiCache にデータを移行します。 docs.aws.amazon.com 外部移行ツールを使用する場合は、ある意味当然ながらそのツール仕様に準じます。今回移行方式としては採用しなかったのでざっくり調べた程度ですが、ツールとしては Redis 公式？の RIOT が最もメジャーなようです。 Redis Input/Output Tools (RIOT) redis.github.io 必ずしも Elasticache 固有の内容ではありませんが、それぞれの移行方式の特徴についても簡単にまとめておきます。 一括移行 メリット 移行（切替）当日に移行対象の全データを現行環境から新環境に移行する方式のため、初期移行＋差分移行と比較して相対的に手順がシンプル 移行に要するトータルの工数も（一般的に）少ない デメリット 移行（切替）当日の所要時間・工数は初期移行＋差分移行と比較すると多くなる このため、移行（切替）時のスケジュールが一括移行の所要時間に収まらない場合は、スケジュールを見直す or  初期移行＋差分移行方式を採用する、の2択となる 初期移行＋差分移行 メリット 一括移行と比較して、移行（切替）当日の所要時間・工数は少ない 差分移行に使用する製品・サービス（例えば DMS など）によっては差分移行中に現行環境/新環境間のデータ整合性チェックを実施することも可能 移行（切替）当日に現行環境/新環境間でデータの整合性をチェックできるのが理想だが、移行対象のデータが大きい場合は移行（切替）時のスケジュールに収まらなくなる可能性があるため、このような方式で整合性チェックを行うことも選択肢に入ってくる デメリット 移行方式における制約や注意すべき事項が多い 初期移行において現行環境からデータを移行する際、現行環境への影響を考慮の上で具体的な方式・手順を決定する必要がある 初期移行は現行環境のシステムが稼働している状態で実施することが方式の特性上ほぼ前提となるため 逆に言うと、初期移行時に現行環境のシステムを停止できるのであれば事実上一括移行が可能と言えるため、この移行方式をわざわざ採用する必要がない 差分移行に使用する製品・サービスにおける各種制約に抵触していないかを確認する必要がある 制約に抵触することの影響度合いはケースバイケースだが、方式自体の採用可否に影響する場合もある 差分移行の特性上現行環境と新環境が相互通信できる必要があるため、通信経路の確立や帯域制限などが方式上のネックになる場合もある 上記内容も相まって、移行に要するトータルの工数は（一般的に）多い   今回採用した Amazon Elasticache の移行方式  結論から言うと、今回は「一括移行」を採用しました。上記で移行方式の特徴をまとめた通り、一括移行の採用可否は実質的に移行（切替）当日の想定スケジュールに一括移行の所要時間が収まるかどうかですが、検証環境で時間を計測したところ無事に収まりそうなことが分かったためです。具体的な所要時間の試算は以下のような流れで行いました。 ちなみに今回はデータベース（MySQL）の移行も同時に行うのですが、時間的にはそちらがボトルネックになるということも理由の一つでした。データベースの移行所要時間内に収まっていれば大丈夫だろうということで。 まず、今回移行対象となる Redis は 2 個あります。キャッシュサイズはそこそこ差があり、大きい方が約 100 GB だったため、ほぼ同じサイズのキャッシュデータをオンプレミス仮想環境上の Redis に用意した上で、Redis から rdb ファイルにバックアップする所要時間、及び S3 上のバックアップを Elasticache for Redis OSS にリストアする所要時間をそれぞれ計測しました。 Redis から rdb ファイルにバックアップ： 20 分 rdb ファイルのサイズは約 98 GB お客さんの IaaS 環境上ではもう少し早くなりそうですが（10-15分程度）、試算では上記計測値を使用 S3 から Elasticache for Redis OSS にリストア： 35 分 インスタンスサイズは cache.r7g.8xlarge 一括移行の所要時間としては上記に加えて Redis サーバから S3 へのバックアップファイル転送時間がプラスされますが、こちらはお客さんの IaaS 環境上で試算したところ 20 分程度見ておけば良さそうということで、合計で 20 + 20 + 35 = 75 分となりました。もう 1 個のキャッシュサイズは小さいため、トータルの所要時間への影響はほぼないと判断しています。 また、先述の通りバックアップを使用して Elasticache インスタンスを新しく作成する手順となるため、作成後に単体テスト・動作確認を実施する方針となりました。直列で作業する前提で 1 個につき 30 分かかるとしても 2 個で 60 分、合計すると 135 分 となります。 移行（切替）当日の想定スケジュールにおいて、データベース/Elasticache の移行に使用できる時間は 最大 6 時間 であるため、無事 Elasticache については時間内に一括移行できる見立てとなりました。 ただし、一括移行において「 バックアップを使用して新しく Elasticache を作成する 」という手順（仕様）により別の課題も想定されたため別途対策が必要になりました。そのあたりの話はまた別エントリでしたいと思います。 なお、このような検討過程であったため差分移行については真剣に検討するまで至らなかったのですが、ざっくり調査した内容及び所感を以下にまとめておきます。（真剣に検討していないのであくまでも参考程度で・・） AWS マネージド 初期移行および差分移行の両方をカバーしており、使用方法自体も非常に簡単  そもそもコンソール/コマンドから設定できる項目も必要最低限（実質的に移行元 Redis への接続情報のみ） https://docs.aws.amazon.com/cli/latest/reference/elasticache/start-migration.html その反面、使用に際しては様々な制約があるため、特に本番環境の移行で使用できるケースは限定的と思われる 特に「 転送（接続）時のSSL無効化 」や「 認証の無効化 」が必要なため、移行元の Redis でこれらの制約を満たさない場合は使用できない（今回の案件でもこの時点で採用 NG）  https://docs.aws.amazon.com/ja_jp/AmazonElastiCache/latest/dg/Migration-Prepare.html 移行対象の論理データベースやデータをフィルタリングするような機能はない レプリケーション開始時にターゲットとなる Elasticache のキャッシュデータが削除される仕様も良し悪し レプリケーションが失敗した場合の再試行自体は行いやすい反面、失敗した時点から再開するようなことはおそらくできないものと思われる（自動復旧した場合は別かも？） 外部ツール（RIOT） AWS マネージドの場合と比較して、認証や転送（接続）時の SSL が有効な場合も対応可能 RIOT が動作する中間サーバを用意する必要あり レプリケーション動作モードに scan と liveonly、及び 両方を併用した live の3種類がある scan は実質的な初期移行、対象の key や type、回数などをオプションとして指定可能 liveonly は実質的な差分移行（レプリケーション）だが、ドキュメント曰くデータの整合性を保証しないとのこと NW 障害時に Redis 上データの更新通知を RIOT が受け取れなかったり、Redis 上の大量データ更新時に　Redis 自身が大量データの更新に追随できない（更新通知を送れない）可能性がある レプリケーション動作時の挙動も dump/restore コマンドを使用するモード、及びデータタイプにより異なるコマンドを使用するモードの 2 種類がある模様 こちらは特別な理由がない限り前者で良さそう（デフォルトも前者） もし今回の案件で使用せざるを得ない場合は上記制約との兼ね合いで RIOT になりますが、設計には正直骨が折れそうです。。 ちなみに RIOT 自体はメンテナンスを終了しており、後継ツールとして RIOT-X が開発されているようです。 RIOT-X :: RIOT-X redis.github.io   まとめ Elasticache に限った話ではありませんが、このようなデータ移行についてはまず一括移行できないかどうかを優先して考えるべきです。逆に言うと、初期移行＋差分移行は対象システムの重要度や特性に基づく移行要件、及びデータ量などを鑑みた場合に（ある意味）やむを得ず選択する方式というくらいの位置づけで考えて良いと思っています。もちろん、DMS を始めとして初期移行＋差分移行に使用できる製品・サービスはここ 10 年くらいで大分充実してきているので、取り得る選択肢が広がっているのはいいことですが。 最も、Elasticache（Redis）はインメモリベースであるため、一般的な RDBMS のようなディスクベースの製品・サービスと比較して相対的に高速にデータ移行できるであろう点も踏まえると、一括移行する方針により倒しやすいとは思います。。 本記事がどなたかの役に立てば幸いです。