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 のようなディスクベースの製品・サービスと比較して相対的に高速にデータ移行できるであろう点も踏まえると、一括移行する方針により倒しやすいとは思います。。 本記事がどなたかの役に立てば幸いです。

こんにちは。LINEヤフーでプライベートクラウドのインフラを担当している井上です。LINEヤフーの膨大なトラフィックとデータを支えているのは、私たち自らが開発・運用している大規模なプライベートクラウド...

はじめに ISMAP ポータルサイトに、「 生成AIサービスに関する留意点について 」が追加されていますが、その内容について考察したいと思います。 この内容に基づけば、AWS としてはAmazon Bedrock のような生成AI開発基盤を通じて提供される生成 AI サービスの位置づけに関し、Amazon Bedrock上で動作する個々の生成 AI モデルについては、必ずしも ISMAP に登録されている必要がないと考えます。 本記事では、この更新内容と Amazon Bedrock 、生成 AI モデル(*1)の関係について解説します。 (*1) 生成 AI モデル： 生成 AI モデルは「基盤モデル」と称されることもありますが、本記事では ISMAP ポータルの表記に合わせて、「生成 AI モデル」という表記に統一しています。 ISMAP とは ISMAP ( Information system Security Management and Assessment Program ) は、政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、もってクラウドサービスの円滑な導入に資することを目的とした制度です。政府情報システムにおいてクラウドサービスを利用する際には、原則として ISMAP に登録されたサービスを選定することが求められています。 ISMAP ポータルサイトより引用： 「 ISMAP ポータルサイト 制度案内 」 URL: https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0010005 本制度は、「政府情報システムにおけるクラウドサービスのセキュリティ評価制度の基本的枠組みについて」（令和2年1月30日サイバーセキュリティ戦略本部決定）に基づき、国家サイバー統括室・デジタル庁・総務省・経済産業省が運営しています。独立行政法人情報処理推進機構（ IPA ）は、本制度の制度運用に係る実務及び評価に係る技術的な支援を行います。 ISMAP ポータルサイトの重要な更新 2026 年 1 月 9 日(記事公開追記)、ISMAPポータルサイトのページに、生成AIサービスに関する以下の内容が掲載されました。 ISMAPポータルサイトより引用： 「 生成AIサービスに関する留意点について 」 URL: https://www.ismap.go.jp/csm?id=kb_article_view&sysparm_article=KB0011070 【クラウドサービス事業者、生成 AI モデル提供者向けの周知事項】 クラウドサービス事業者が生成AIサービスをSaaSとして提供する場合には、当該SaaSは原則としてISMAP等クラウドサービスリストに登録が必要となります。これは生成AIサービスを外部連携で利用する場合においても同様です。 なお、ISMAPに登録されていない生成AIサービスをISMAPに登録されているIaaS、PaaSを用いて提供しても、当該生成AIサービスはISMAPに登録されているサービスと同等とみなすことはできません。 ただし、クラウドサービス事業者が、生成AIモデルを提供する事業者から生成AIモデルの提供を受け、当該生成AIモデルの扱うデータに対してセキュリティ管理機能を適用する自らの生成AI開発基盤において生成AIサービスを提供する場合（PaaSに相当）に、当該生成AI開発基盤を言明対象範囲に含めてISMAPに登録したときには、通常は当該生成AIサービスが取り扱うデータのセキュリティは、ISMAPのセキュリティ要件を満たす状態とみなされます。この場合において、クラウドサービス事業者が生成AI開発基盤を言明対象範囲に含めてISMAPの登録を行う場合には、提供される個々の生成AIモデルを言明対象範囲に含める必要はありません。また、提供される生成AIモデルは必ずしもISMAPに登録されている必要はありません。 この場合において、生成AI特有のリスクについては、ISMAPにおける管理基準とは別に、生成AI開発基盤をISMAP言明対象範囲に含めたクラウドサービス事業者において措置を講じることが必要です。具体的な措置については、「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」の調達チェックシート等を参考にしてください。なお 、ISMAP登録に関する審査基準等については、「ISMAPクラウドサービス登録規則」等において定めており、詳細はISMAPポータルサイトの制度規程等をご確認下さい。 Amzaon Bedrock と生成 AI モデルの位置関係 Amazon Bedrock の特徴の一つとして、 生成 AI モデルが AWS の内部環境に持ち込まれており、お客様のデータが生成 AI モデル開発事業者に提供されることはありません。 これは、政府情報システムにおいて機密性の高いデータを扱う上で重要なポイントになると思います。 [ ご参考： Amazon Bedrock のよくある質問 セキュリティ ] この仕組みにより、以下のセキュリティ上の利点が実現されています: データの機密性保持: お客様の入力データや生成結果が外部の生成 AI モデル開発事業者に送信されることはありません モデル学習への不使用: お客様のデータが生成 AI モデルの学習に使用されることはありません 統一されたセキュリティ管理: Amazon Bedrock の ISMAP 準拠のセキュリティ管理機能により、すべての生成 AI モデルへのアクセスが保護されます ISMAP の評価対象の適切な理解 ISMAP は政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、もってクラウドサービスの円滑な導入に資することを目的とした制度であり、クラウド基盤上で動作するアプリケーションやデータそのものは評価対象ではありません。これは生成 AI サービスにおいても同様です。 重要なのは、 データのセキュリティを管理する責任がどこにあるか という点です。 Amazon Bedrock の場合下記になります。 Amazon Bedrock (生成 AI 開発基盤): ISMAP の言明対象範囲に含まれ、データのセキュリティ管理を担当 生成 AIモデル: Amazon Bedrock 上で動作し、AWS 内部に配置されているため、ISMAP への個別登録は不要 この構造により、お客様は複数の生成 AIモデルを柔軟に選択・利用しながら、ISMAP のセキュリティ要件を満たした環境でサービスを提供できます。 Amazon Bedrock が提供する生成 AI 特有のリスクへの対応 ISMAP のセキュリティ要件への対応に加えて、生成 AI 特有のリスク(ハルシネーション、プロンプトインジェクション、バイアスなど)について、「行政の進化と革新のための生成 AI の調達・利活用に係るガイドライン」の調達チェックシート等を参考に、適切な措置を講じることが推奨されています。 Amazon Bedrock では、以下のような機能を提供しており、これらのリスクへの対応を支援しています: Guardrails for Amazon Bedrock : 有害なコンテンツのフィルタリング、個人情報の保護 モデル評価機能: 力品質の評価とモニタリング 監査ログ: AWS CloudTrail による詳細なアクセスログの記録 まとめ Amazon Bedrock は ISMAP の言明対象範囲に含まれており、政府情報システムにおいて安心してご利用いただける生成 AI 開発基盤です。ISMAP ポータルサイトの更新により、生成 AI 開発基盤が ISMAP に登録されている場合、その上で動作する個々の生成 AI モデルは必ずしも ISMAP に個別登録されている必要はないという見解が示されました。 Amazon Bedrock の特徴である「生成 AI モデルの AWS 内部への配置」により、お客様のデータは生成 AI モデル開発事業者に送信されることなく、モデル学習にも使用されません。これにより、機密性の高い政府情報を安全に取り扱いながら、最新の生成 AI 技術を活用することが可能です。 政府機関の皆様におかれましては、ISMAP に準拠した Amazon Bedrock を活用することで、セキュリティ要件を満たしながら、生成 AI による業務効率化やイノベーションを推進していただけます。   アマゾン ウェブ サービス ジャパン 合同会社 執行役員 パブリックセクター 技術統括本部長 瀧澤 与一 参考リンク ISMAP ポータルサイト Amazon Bedrock 製品ページ 行政の進化と革新のための生成 AI の調達・利活用に係るガイドライン