本記事は 2026 年 6 月 2 日に公開された “ Announcing durability for Amazon ElastiCache for Valkey ” を翻訳したものです。 Amazon ElastiCache は数十万のお客様にサービスを提供し、Valkey、Memcached、Redis OSS のワークロード全体で毎秒数十億のリクエストをマイクロ秒のレイテンシーで処理しています。多くの組織では、ElastiCache のマルチ AZ レプリケーションと自動フェイルオーバーがレジリエンスの要件を満たしていますが、お客様がキャッシュだけでなく永続的なデータストアとして ElastiCache を採用するケースが増えるにつれ、データ損失が主要な懸念事項となっています。 本日、 Amazon ElastiCache for Valkey の耐久性機能の提供開始を発表します。これにより、データ損失を許容できないワークロードに ElastiCache を使用できるようになります。 この記事では、耐久性がどのように機能するかを説明し、アーキテクチャを詳しく見ていき、耐久性が ElastiCache でお客様が期待するマイクロ秒単位のレイテンシーを損なわないことを示すパフォーマンス結果を共有します。 耐久性の仕組み ElastiCache の耐久性は、マルチ AZ トランザクションログを使用して、インフラストラクチャ障害時の高速リカバリと再起動によるデータ保護を提供します。ElastiCache は 2 つの耐久性オプションを提供しています。ゼロデータ損失を設計した同期書き込みと、マイクロ秒単位の書き込みレイテンシーを実現する非同期書き込みです。 同期書き込み は、データ損失が許容できない場合に適した選択肢です。ElastiCache は、クライアントに応答する前に、マルチ AZ トランザクションログ内の少なくとも 2 つのアベイラビリティーゾーン (AZ) にデータを永続化します。確認応答された書き込みはすべて永続的であり、書き込みレイテンシーは 1 桁台のミリ秒です。プライマリノードは強い整合性を持ち、プライマリでの読み取り操作は常に最新のデータを返します。この整合性はフェイルオーバー時にも保持されます。同期書き込みは、RAG アプリケーション向けのナレッジベース、AI エージェントの長期メモリ、AI エージェントのワークフロー状態、決済トークン化、ストリーミングメタデータ、ゲームプレイヤーの状態、リアルタイム在庫管理など、書き込みの損失が誤ったアプリケーション動作を引き起こす場合に最適です。 非同期書き込み は、データが復旧可能であるものの、ソースからの再構築が遅い、または運用コストが高い場合に適した選択肢です。非同期書き込みでは、クライアントへの応答後にデータが Multi-AZ トランザクションログに永続化されるため、追加コストなしでマイクロ秒単位の書き込みレイテンシーを維持できます。万が一障害が発生した場合、最大 10 秒間のコミットされていないデータが失われる可能性があります。潜在的なデータ損失を制限するため、ElastiCache は耐久性ラグを監視します。これは、まだログに永続化されていない最も古い書き込みからの経過時間です。このラグが 10 秒に達すると、プライマリノードはログが追いつくまで書き込みの受け入れを停止します。非同期書き込みは、セッションストア、ゲームのリーダーボード、リアルタイム分析、事前ロードされたデータセットなど、数秒間の最近の書き込みを失うことは許容できるものの、より大きなギャップが生じると調整にコストがかかる場合に最適です。 耐久性を有効にしていない ElastiCache は、データがオンデマンドで簡単に再構築できる場合に適しています。元となるデータベースに基づくリードスルーキャッシュ、レート制限カウンター、または欠落したエントリをその場で取得または再計算できるワークロードに使用してください。 同期書き込みと非同期書き込みの両方で、マイクロ秒単位の読み取りレイテンシーが維持されます。いずれのオプションでも、レプリカノードは結果整合性を持ち、レプリカからの読み取り操作は常に最新の書き込みを反映するとは限りません。次の表に、2 つの耐久性オプションをまとめます。   同期書き込み 非同期書き込み 標準的な読み取りレイテンシー マイクロ秒 マイクロ秒 標準的な書き込みレイテンシー 1 桁ミリ秒 マイクロ秒 データ損失に関する保証 データ損失ゼロ。確認された書き込みはすべて、少なくとも 2 つのアベイラビリティーゾーンにわたって永続化されます 万が一障害が発生した場合、最大 10 秒間の確認された書き込みが失われる可能性があります。 一般的なユースケース RAG アプリケーションのナレッジベース、AI エージェントの長期メモリとワークフロー状態、支払いトークン化、リアルタイム在庫管理 セッションストア、ゲームリーダーボード、リアルタイム分析、事前ロード済みデータセット アーキテクチャ 次の図は、Multi-AZ のトランザクションログを使用した ElastiCache の耐久性がどのように機能するかを示しています。 同期書き込み 同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信した場合: プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 書き込みは、少なくとも 2 つのアベイラビリティゾーンにまたがる Multi-AZ トランザクションログに永続化されます。 永続化が確認されると、プライマリはクライアントに成功レスポンスを返します。 これは、クライアントが成功レスポンスを受け取った後、その書き込みが永続化されることを意味します。プライマリノードがその直後に障害を起こしても書き込みは失われず、新しいプライマリへのフェイルオーバー後を含め、プライマリからの今後のすべての読み取りにその書き込みが反映されます。トレードオフは書き込みレイテンシーです。各書き込みはトランザクションログへの AZ 間ネットワークラウンドトリップが発生するため、数ミリ秒の書き込みレイテンシーが生じます。 非同期書き込み 非同期書き込みが設定されたクラスターにクライアントが書き込みコマンドを送信する場合： プライマリノードがメモリ内で書き込みコマンドを受信して実行します。 プライマリはマイクロ秒のレイテンシーで即座にクライアントに応答を返します。 バックグラウンドで、書き込みは Multi-AZ トランザクションログに書き込まれます。 クライアントが成功レスポンスを受信した時点では、書き込みはプライマリノードのメモリ内にのみ存在します。まだトランザクションログには書き込まれていません。書き込みが永続化される前にプライマリノードに障害が発生すると、その書き込みは失われます。これが非同期書き込みの基本的なトレードオフです。マイクロ秒単位の書き込みレイテンシーと引き換えに、データ損失が発生しうる限られた時間枠が存在します。 非同期書き込みの耐久性バッファ 非同期書き込みによる潜在的なデータ損失を制限するため、ElastiCache は最大 10 秒の耐久性バッファを強制します。プライマリノードは、受け入れられたがまだ Multi-AZ トランザクションログに永続化されていない最も古い書き込みの経過時間を継続的に追跡し、この値を DurabilityLag メトリクスとして Amazon CloudWatch に公開します。 この経過時間が 10 秒未満である限り、ノードは通常通り新しい書き込みを受け入れ続けます。バッファが 10 秒を超えて増加した場合、例えばトランザクションログへの一時的なネットワーク輻輳が原因である場合、プライマリは追いつくまで一時的に受信する書き込みコマンドを拒否します。この期間中も読み取り操作はマイクロ秒のレイテンシーで提供され続けます。トランザクションログが追いつき、耐久性ラグがしきい値を下回ると、手動介入を必要とせず書き込みが自動的に再開されます。実際には、ほとんどの書き込みは 10 秒のしきい値内に十分永続化され、ほとんどのクラスターは通常の動作条件下で拒否状態に入ることはありません。非同期耐久性クラスターにトラフィックを送信するようにクライアントを構成する場合、一時的に拒否された書き込みコマンドに対して指数バックオフによる自動リトライを有効にすることをお勧めします。Valkey の公式オープンソースクライアントライブラリの 1 つである Valkey GLIDE をお勧めします。これは信頼性と高可用性を考慮して設計されています。GLIDE は指数バックオフによる自動リトライとアベイラビリティーゾーン認識ルーティングをサポートしています。クライアント構成のベストプラクティスについては、 Best practices: Valkey/Redis OSS clients and Amazon ElastiCache を参照してください。 障害シナリオ ElastiCache の耐久性は、以下の障害タイプから保護します。 プライマリノードの障害。 プライマリノードに障害が発生した場合、ElastiCache は自動的にレプリカへのフェイルオーバーをトリガーします。レプリカはトランザクションログから追いつき、その後新しいプライマリとして書き込みを受け入れ始めます。障害が発生したノードは置き換えられ、ログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、プライマリが障害を起こす前にトランザクションログにすべての書き込みが記録されていない可能性があるため、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。 リードレプリカの障害。 リードレプリカに障害が発生した場合、障害が発生したノードは置き換えられ、選択された耐久性オプションに関係なく、Multi-AZ トランザクションログから同期されます。データ損失は発生しません。 シャード全体の障害 (シャード内のすべてのノード)。 シャード全体に障害が発生した場合、すべてのノードが置き換えられ、Multi-AZ トランザクションログから同期されます。同期書き込みでは、データは失われません。非同期書き込みでは、最大 10 秒間の確認応答済みの書き込みが失われる可能性があります。コミットされたデータが復元された後、置き換えられたノードの 1 つが自動的に新しいプライマリとして選出されます。 パフォーマンス分析 ElastiCache の耐久性を有効にした場合と無効にした場合のスループットと読み取り/書き込みレイテンシーを測定し、それらを比較しました。その結果、ElastiCache で耐久性を有効にしても、お客様が ElastiCache に期待するマイクロ秒単位のレイテンシーが損なわれないことを実証しました。 テスト方法 r7g.4xlarge ノードを使用して、耐久性なし、同期書き込み、非同期書き込みの Valkey 9.0 for Amazon ElastiCache クラスターを起動しました。各クラスターは、1 つのプライマリノードと 1 つのリードレプリカで構成され、テスト実行前にサンプルデータが事前に投入しました。Valkey のデフォルトのパフォーマンス測定ツール ( valkey-benchmark ) を使用して、300 万個のキーでコマンドパイプラインなしで実行し、プライマリノードと同じ AZ 内の 10 個の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを使用してクラスターにトラフィックを向けました。一般的なお客様のワークロードパターンを代表する混合ワークロード (80% 読み取り、20% 書き込み) を使用して、50K と 100K TPS の 2 つのスループットレベルでテストしました。ElastiCache クラスターはマルチ AZ 分散システムであるため、同一のセットアップでも下の表の数値からある程度のばらつきが観察される場合があります。 次の表は、r7g.4xlarge ノードにおけるすべての ElastiCache オプションの読み取りおよび書き込みレイテンシーを比較したものです。 ワークロード (80% 読み取り、20% 書き込み) ElastiCache オプション ノードタイプ 読み取り P50 読み取り P90 書き込み P50 書き込み P90 50K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 260 µ s 301 µ s 147 µ s 185 µ s 50K TPS 非同期書き込み r7g.4xlarge 245 µ s 289 µ s 112 µ s 152 µ s 50K TPS 同期書き込み r7g.4xlarge 245 µ s 288 µ s 2.15 ms 2.36 ms 100K TPS 耐久性機能なしの ElastiCache r7g.4xlarge 263 µ s 301 µ s 160 µ s 196 µ s 100K TPS 非同期書き込み r7g.4xlarge 245 µ s 286 µ s 128 µ s 158 µ s 100K TPS 同期書き込み r7g.4xlarge 879 µ s 992 µ s 2.72 ms 3.12 ms 重要なポイント: すべてのオプションでマイクロ秒の読み取りレイテンシーを維持します。同期か非同期かに関わらず、耐久性は両方のスループットレベルでマイクロ秒の読み取りパフォーマンスを維持するため、実際のユースケースの大半を占める読み取り中心のワークロードに適しています。 非同期書き込みは、耐久性を有効にしていない ElastiCache と同等のレイテンシーを実現します。50K TPS と 100K TPS の両方で、読み取りと書き込みのレイテンシーはいずれもマイクロ秒レベルです。追加料金なしで耐久性を追加でき、一般的なワークロードレベルでのスループットへの影響はごくわずかです。データ損失ゼロを必要としないすべてのワークロードに対して、非同期書き込みをデフォルトとして推奨します。このオプションは、レイテンシーのペナルティなしで耐久性を提供します。 同期書き込みは、中程度のスループットでマイクロ秒の読み取りレイテンシーを維持します。50K TPS では、読み取りレイテンシーは 300 µ s 未満のままです。100K TPS では、システムがトランザクションログへのより高い並行性を処理するため、読み取りレイテンシーはサブミリ秒 (879 µ s) に増加します。書き込みレイテンシーは、両方のスループットレベルでミリ秒の 1 桁台に留まります。これは、書き込みを確認する前に 2 つのアベイラビリティーゾーンにデータを永続化するための予想されるトレードオフです。アプリケーションがデータ損失を一切許容できない場合は、同期書き込みを使用する必要があります。 ElastiCache の耐久性を使い始める 前提条件 始める前に、以下を確認してください。 アクティブな AWS アカウント AWS CLI バージョン 2.x 以降がインストールおよび設定されていること elasticache:CreateReplicationGroup と elasticache:ModifyReplicationGroup の IAM 権限 永続化クラスターの作成 耐久性を使い始めるには、新しい ElastiCache クラスターを作成し、 AWS Management Console 、AWS Software Development Kit (SDK)、または AWS Command Line Interface (CLI) を使用して、希望する耐久性オプションを選択する必要があります。 AWS マネジメントコンソールの使用 新しいクラスターを作成する際は、Valkey 9.0 以降を選択してください。クラスター設定で希望する耐久性オプションを選択します。 AWS CLI の使用 同期書き込みを使用する新しい耐久性のあるクラスターを作成するには： aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability sync \ --region us-east-1 非同期書き込みを使用するクラスターを作成するには、 --durability async を設定します。 aws elasticache create-replication-group \ --replication-group-id my-durable-cluster \ --replication-group-description "ElastiCache durable cluster" \ --engine valkey --engine-version 9.0 \ --num-node-groups 2 --replicas-per-node-group 1 \ --cache-node-type cache.r7g.large \ --multi-az-enabled \ --transit-encryption-enabled \ --durability async \ --region us-east-1 クラスターの検証 クラスターを作成した後、耐久性が有効になっている状態で実行されていることを確認できます。 aws elasticache describe-replication-groups \ --replication-group-id my-durable-cluster \ --query 'ReplicationGroups[0].[Status,Durability]' --region us-east-1 出力には、ステータスが available として、選択した耐久性オプションが表示されるはずです。 耐久性オプションの切り替え 既存のクラスターを同期書き込みと非同期書き込みの間で切り替えるには、 modify-replication-group を使用します。 aws elasticache modify-replication-group \ --replication-group-id my-durable-cluster \ --durability async クリーンアップ 継続的な料金が発生しないように、作成した ElastiCache クラスターを削除してください。 aws elasticache delete-replication-group \ --replication-group-id my-durable-cluster \ --region us-east-1 注意: この操作により、クラスターとすべてのデータが永久に削除されます。続行する前に、必要なデータをバックアップしていることを確認してください。 まとめ ElastiCache の耐久性により、ElastiCache をキャッシングと永続的なデータストアの両方のユースケースで使用できます。同期書き込みは、マイクロ秒の読み取りレイテンシーと 1 桁ミリ秒の書き込みレイテンシーでデータ損失ゼロを実現するように設計されており、データ損失を許容できないワークロードに適しています。非同期書き込みは、追加料金なしで耐久性のない ElastiCache と同等のパフォーマンスを提供し、まれに障害が発生した場合に最大 10 秒の潜在的なデータ損失を許容できるワークロードに適しています。耐久性のない ElastiCache は、データをオリジンソースから再構築でき、書き込みの完全な可用性が最重要な従来のキャッシングワークロードに適した選択肢です。 ElastiCache の耐久性は、Valkey 9.0 から、すべての AWS 商用リージョン、AWS 中国リージョン、および AWS GovCloud (US) リージョンでご利用いただけます。料金の詳細については、 Amazon ElastiCache 料金ページ をご覧ください。詳細については、 ElastiCache ドキュメント をご覧ください。 著者について Jules Lasarte Jules は Amazon インメモリデータベースチームのソフトウェア開発エンジニアです。ElastiCache の耐久性に関するエンジニアリング活動を主導し、高性能分散システムとインメモリワークロードのデータ保護に注力しています。カナダのバンクーバーを拠点としています。 Karthik Konaparthi Karthik は Amazon インメモリデータベースチームのプリンシパルプロダクトマネージャーで、ワシントン州シアトルを拠点としています。データに関するあらゆることに情熱を持ち、お客様の課題を彼らが愛する製品に変えることを楽しんでいます。仕事以外では、家族と新しい場所を探索することを楽しみ、常に次の素晴らしいレストランを探しています。 本記事は、 Announcing durability for Amazon ElastiCache for Valkey を翻訳したものです。翻訳は Solutions Architect の Hayato Tsutsumi が担当しました。

ニフティ社内で従業員が使う社内メールや予定表、カレンダー。さらには、SlackやGoogle Workspaceといった外部ツールまで、数多くのプロダクトの運用を担うのが、プラットフォームチーム（以下、PFチーム）です。従業員を「ユーザー」と呼び、日々みんなが滞りなく業務を行えるよう、縁の下で支えています。 既存ツールの運用だけでなく、新規の外部サービスの導入検討や、時にはツールの開発までを担うというPFチーム。その詳しい業務内容や印象的だったプロジェクト、また、仕事のやりがいについて、メンバーに話を聞きました。 自己紹介 D.Kさん 2020年4月に新卒入社。業務内容はID基盤システム、コラボレーションツールの保守・運用。趣味はコーヒー。最近はハイカカオチョコにハマって自席に常備。 Y.Kさん 2019年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味は散歩と、温泉でゆっくりすること。 K.Gさん 2024年4月に新卒入社。業務内容は社内システムの運用・保守・刷新。趣味はゲーム、サッカー観戦、音楽を聴くこと。 「使えて当たり前」を担保しつつ、ユーザーの利便性を高めていく みなさんはニフティの「プラットフォームチーム（以下、PFチーム）」のメンバーということですが、具体的な業務内容を教えてください。 D.Kさん PFチームでは、ニフティの従業員（以下、ユーザー）が使う全ての社内システムの運用・保守・刷新を担っています。社内メールや予定表、カレンダーのほか、SlackやGoogle Workspaceなどの外部ツールまで、管理しているプロダクトは25程度。そのほか、他部署のシステムの管理のみを委託のような形で請け負ったりと、社内で使うツール関係については、大半を私たちのチームで取り扱っています。 具体的な仕事内容ですが、メインの業務は運用です。社内システムは「使えて当たり前」であり、トラブルが起こった瞬間に業務に支障が出てしまいます。ユーザーに滞りなく業務にあたってもらうため、問題が生じた場合でも影響を最小限に抑えながら運用する必要があります。 また、既存のツールの運用だけでなく、外部ツールの新しい機能を取り入れたり、新規サービスの導入を検討したりと、現在の水準は保ちつつユーザーさんがより便利に仕事ができるようサポートするのも、私たちの重要な業務ですね。 現在、PFチームは何名体制で業務にあたっていますか？ D.Kさん 現在は8名です。チームは大きくアカウント系、コラボレーションツール系に分かれていて、K.Gさんには主にアカウント系のプロダクトを、Y.Kさんは主にコラボレーションツール系のプロダクトを担当してもらっています。 では、それぞれご担当されている領域やプロダクトの詳細について、お二人からご説明いただけますか？ K.Gさん 私はアカウント系のチームで、主にユーザーのIDやパスワードの管理を担当しています。新たに入社された人が初出勤して仕事をスタートする前日までには、アカウントを付与して使える状態にしておかなければいけません。他にも、会社から支給されるパソコンのクラウド上での通信の管理や、セキュリティファイルの管理なども行なっています。後者で言うと、たとえばファイルのなかに個人情報が入っていないかをチェックするなど、幅広い業務がありますね。私はこの部署に来てまだ日が浅いのですが、かなり幅広い知識を求められる仕事だと感じています。 Y.Kさん 私はコラボレーションツール、分かりやすいところではSlackやGoogle Workspaceなどですが、その他にもさまざまな外部ツールをユーザーが「普通に使える状態」にするというのが大きな役割です。仮に不具合などがあって使用できない時に対応にあたったり、ユーザーからの問い合わせにも回答したりしています。 そうした運用以外に、「刷新」の役割も担っています。いま使用しているツールよりも便利なもの、新しいものが出てきた時に導入を検討したり、実際に置き換えを推進したりする仕事ですね。今もちょうど、RPAツールを別のものに置き換えるプロジェクトが動いています。 新しいツールに置き換える判断は、ある程度チームに委ねられているのでしょうか？ Y.Kさん そうですね。基本的にはプラットフォームチームのメンバーで検討し、上長のOKが出れば導入を推進できます。その後、セキュリティの要件を満たしているかどうかなどのチェックを経て、最終的に判断をするという流れですね。 ただ、もちろん刷新前のツールのほうが使い慣れていたり、愛着を持たれているユーザーもいるので、いきなりガラっと変えるのではなく、従業員と対話をして新しいツールの情報を伝えたり、利点をアピールしたりといったコミュニケーションは大事にしています。 外部サービスの利用から「自社開発」に切り替え、業務効率化を実現 これまでに担当したプロジェクトのなかで、特に印象深いものを教えてください。 Y.Kさん 私は、アルバイトや派遣社員用ID作成システムの刷新プロジェクトが印象に残っています。新しく入ったアルバイトの方の情報を入力するとアカウントが自動発行されるというシステムなのですが、もともとはかなり昔に外部のパートナー企業に作成してもらったもので、当時の仕様書も実際のソースコードも確認できないような状態。半ばブラックボックス化していたんです。 しかも、古いシステムなので頻繁にエラーが起こるような状態になっていて、その度にサーバーを再起動していたのですが、そうした運用を続けていくといつかシステム自体が使えなくなってしまう可能性もある。そこで、システム自体を刷新することになりました。 既存システムの運用だけでなく、そうした、いわば「古い遺産」を刷新するような業務もあるということですね。K.Gさんはいかがですか？ K.Gさん 私が担当した印象深いプロジェクトは、社内セキュリティレベル間のファイル移行ツールを刷新するというものです。もともとは外部提供を受けていたSaaSのシステムを社内で開発し直し、さらに改良を行いました。最も大きな改良点としては、それまではファイルを移行する際に、外部への不正なデータ持ち出しがないかどうかを目視でチェックしてから承認していたのですが、一部にAIを導入して自動で検知できるようにしたこと。いわゆる、DLPのシステムを導入しました。これにより、コスト削減とセキュリティレベルの向上につながり、ファイル移行ツールを使う業務の効率化につながったと思います。 そもそも、外部サービスから自社開発に切り替えた理由は何だったのでしょうか？ D.Kさん 一番は自社開発であれば、色んな機能を追加したり、使いやすくシステムを改良したりと、カスタマイズがしやすいことです。ファイル移行ツールに関しては、先ほどK.Gさんが言ったように、それまでのツールでは目視で一つひとつチェックしていたため、膨大な人的リソースが割かれていました。DLPを導入しようにも、既存のサービスの仕組みではなかなか組み込むことが難しい。また、DLP以外にも、今後ユーザーからの要望に応じてカスタマイズしやすいものにしたほうがいいだろうということで、自社開発に舵を切りました。 プラットフォームチームというと「既存システムをいかに滞りなく動かすか」がメインの業務というイメージですが、開発寄りのプロジェクトも結構あるのですね。 D.Kさん 最近はちょこちょこありますね。プラットフォームチームは企画から開発、さらには運用までを担うほか、レイヤーもインフラのサーバーからネットワーク、アプリケーションに至るまで、本当に「何でもやります」という感じのチームなので、活躍の幅が広い部署と言えるかもしれません。 ユーザーの「顔が見えること」が一番のやりがい みなさんは現在のプラットフォームチームの業務において、どんなところに楽しさ、やりがいを感じていますか？ Y.Kさん 一番はユーザーが社内という、最も身近な場所に存在していること。問い合わせに対して回答や解決をした時にも、すぐに「助かりました。ありがとうございます」と反応をもらえるのは嬉しいですし、やりがいにつながっていますね。 K.Gさん 私も似た答えになってしまいますが、ユーザーさんと直接やりとりできる点ですね。「こういう機能があるといい」といった要望も直で伝えてもらえるので、とても取り組み甲斐があると感じています。時には難しい要望もありますが、どれだけユーザーに寄り添えるか、実現に向けて努力できるかが自分の仕事だと考えていますので、そこはこれからも大事にしていきたいです。 ちなみに、K.Gさんは3人のなかでは最も若手ですが、プラットフォームチームのように色んなことができる現場だと、幅広い知見やスキルを獲得するという点でも大きいのではないでしょうか。 K.Gさん それはありますね。どちらかというとニフティには開発がメインのチームが多いと思います。そのなかで、システムの運用だったり、ユーザーさんと直接コミュニケーションできたりするのは貴重な機会。なおかつ、開発の案件もたまにあるので、おっしゃる通り色んな経験を積むことができるチームですね。 D.Kさん 私自身もわりと何でもやりたいタイプなので、今のチームはとてもフィットしていると感じます。あとは、二人が言ってくれたように、ユーザーと直に話ができるのは大きなやりがいにつながっていて。ユーザーと対話をして、トラブルシュートをして、その後のリアクションまでもらえる。そういう体験ができるチームって、ニフティのなかでもあまりないと思いますので、そこは大きな喜びですね。 後編に続きます！ 今回はニフティの社内プラットフォームチームのインタビュー（前編）の様子をお届けしました。 続きは近日公開予定の後編の記事をご覧ください。 このインタビューに関する求人情報 /ブログ記事 ニフティ株式会社 求人情報

本ブログは 2026 年 4 月 3 日に公開された AWS Blog “ How AWS KMS and AWS Encryption SDK overcome symmetric encryption bounds ” を翻訳したものです。 大量のデータを暗号化する大規模なアプリケーションを運用している場合、暗号化限界の追跡や鍵のローテーションが課題になることがあります。この記事では、 AWS Key Management Service (AWS KMS) と AWS Encryption SDK が、派生鍵方式を用いて Galois Counter Mode の Advanced Encryption Standard (AES-GCM) の encryption limits (暗号化限界) や bounds (境界) を自動的に処理し、手動での管理を不要にする仕組みを説明します。これらの方式では、ランダムなノンスを使って、メインキー K から新しい派生鍵 K d を生成します。これにより、暗号化のたびに一意の鍵が使われるため、 K をはるかに長く使い続けられます。同様の派生鍵モードは、 (KC-)XAES 、 DNDK v2 、 ia.cr/2020/1153 など、最近のさまざまなスキームでも提案されています。 対称暗号化の境界 対称暗号化アルゴリズムは、転送中のデータと保管中のデータを大量に暗号化します。最新の暗号は、認証タグを使ってデータの認証も行います。これらは追加データ付き認証暗号 (AEAD) と呼ばれます。AEAD 暗号の例としては、AES-GCM や ChaCha20/Poly1305 があります。 AES-GCM は最も広く使われている暗号化アルゴリズムで、NIST によって SP 800-38D として標準化されました。AES-GCM は、128 ビットまたは 256 ビットの鍵 K と、初期化ベクトル ( IV 。通常は 96 ビット) を使って、平文 P を暗号化し認証します。また、追加認証データ ( AAD ) も認証します。出力は暗号文 C と認証タグ T です。 (C, T) = AES-GCM(K, IV, AAD, P ) 復号時には、受信者は K 、 IV 、 AAD を使って C を復号し、タグ T を検証します。タグの認証が成功すれば、元の平文 P が得られます。 暗号化呼び出し限界 データを暗号化するときには、鍵 K の使用期間中、 K, IV のタプルが繰り返されないことが極めて重要です。繰り返されると、AES-GCM のセキュリティ特性が失われてしまうためです。 SP 800-38D では、実装において鍵と IV が再利用される確率を 42.9 億分の 1 未満 (<2 -32 ) にすることが求められています。これは、繰り返されない決定論的な IV を使うか、ランダムな IV を使うことで達成できます。ランダムな IV を使う場合は、2 32 回の暗号化後に鍵を再生成する必要があります。たとえば、TLS や IKEv2/IPsec のような一般的なプロトコルでは、接続ごとに決定論的な (つまりランダムな値から始めてインクリメントする) IV を使うことで、( K, IV ) の衝突を防いでいます。 データ境界 ( K, IV ) の衝突確率が統計的に無視できる (<2 -32 ) と仮定しても、同じ鍵 K で大量の平文を暗号化するときには、依然としてデータ境界が存在します。AES-GCM のブロックカウンターは 32 ビットであるため、1 回の暗号化操作 (( K, IV ) のペアごと) あたり 2 32 -2 ブロック (68.72 GB) という限界が生じます。さらに、データの総量を制限しないと、攻撃者が 2 つの異なる平文を識別できる、つまり 2 つのメッセージのうちどちらが暗号文に暗号化されているかを判別できるようになり、セキュリティ保証が低下します。識別不可能性の保護を高めるほど、暗号化できるバイト総数は少なくなります。NIST の仕様 SP 800-38D では、単一の鍵 K で保護するデータの限界を 2 68 バイトと示しており、これは識別不可能性の確率 50% に相当します。さまざまな分析 ( ia.cr/2024/051 、 10.1145/3243734.3243816 ) に基づいて、より保守的なセキュリティマージンが使われることもあります。AWS もより保守的なマージンを設定しており、デフォルトでは無視できる程度の識別不可能性の確率 (<2 -32 ) を強制しています。 あるセキュリティマージンにおける AES-GCM のデータ境界に達したら、対称鍵をローテーションする必要があります。こうした限界 (たとえば、ランダムな IV を使った鍵あたり 2 32 回の暗号化や、鍵あたりの最大データ総量) には、最新の大規模な暗号化ユースケースで到達する可能性があります。多数の同時セッションを持つ分散システム全体でこれらの限界を追跡すると、運用上の複雑さが増します。AWS では、AWS の規模で AES-GCM を使う際のこうした課題を、 2023 年に開催された NIST の第 3 回 Workshop on Block Cipher Modes of Operation での 解説資料 と プレゼンテーション で共有しました。 AWS KMS が派生鍵を使う仕組み AWS KMS は、データの暗号化と署名に使う鍵を作成し制御できるマネージドサービスです。AWS KMS Encrypt API は、対称暗号化と非対称暗号化をサポートしています。対称鍵暗号化の場合、AWS KMS は 256 ビットの鍵を使った AES-GCM を用いて、最大 4 KB のサイズの平文を暗号化します。AWS KMS リクエストには、平文と、KMS に保管されている対称カスタマーマネージドキー (CMK) の対称鍵識別子 ( KeyId ) が含まれます。 AWS KMS への対称鍵 Encrypt API コールでは、平文を暗号化する前に CMK を使って対称暗号化鍵を派生させます。AWS KMS は、ランダムな 128 ビットのノンス N を生成し、鍵導出関数 (KDF) を使って、 KeyId で指定されたメインキー K から 256 ビットの対称鍵を生成します。KDF は、鍵、ラベルとコンテキスト、呼び出し固有のノンス N 、そしてバイト単位の出力長 L Km を入力として受け取り、その長さの鍵マテリアルを K mat = KDF(K, <label>, <context>, N, L Km ) として生成します。 <label> は通常、アプリケーション固有または呼び出し固有の値です。 <context> には呼び出し固有の入力が含まれます。AWS KMS の場合、KDF 関数は NIST SP 800-108r1 Counter Mode KDF で、擬似ランダム関数として HMAC-SHA256 を使って 256 ビットの鍵マテリアルを生成します。 K d は基本的に、鍵 K を使った 1 回の HMAC-SHA256 呼び出しで次のように生成されます。 K d = HMAC-SHA256(K, <ctx>) ここで <ctx> は、カウンター値と定数および N を連結したものです。 続いて、AWS KMS は 96 ビットのランダムな IV を生成し、入力された平文 P を AES-GCM で (C, T) = AES-GCM(K d , IV, AAD, P) として暗号化します。 AWS KMS は、 IV 、ノンス N 、暗号文、タグ ( C,T ) を含む CiphertextBlob を返します。これにより、後続の Decrypt API への呼び出しで CiphertextBlob を復号できます。 直感的に言うと、CMK のもとで暗号化鍵を派生させるために使われる 128 ビットのランダムなノンスにより、呼び出し元は CMK のもとで実行できる暗号化回数の 2 32 限界をはるかに超えられます。さらに、AWS Encrypt 呼び出しのペイロードサイズに対する 4 KB の限界により、暗号化鍵のもとで暗号化されるデータの総量は、NIST やその他のより保守的な暗号化データ総量の上限（境界）をはるかに下回るよう保たれます。このスキームのセキュリティ基盤に関する詳細と数学的な背景については、 Key Management Systems at the Cloud Scale を参照してください。 AWS Encryption SDK が呼び出しごとに派生鍵モードを適用する仕組み AWS Encryption SDK は、データの暗号化と復号に使われるクライアント側の暗号化ライブラリです。複数のペイロードを暗号化するときに API コールを減らすため、データキーキャッシュを使うように設定できます。AES-GCM の暗号化呼び出しごとにノンスベースの派生鍵を使うことで、単一のデータキーのもとで暗号化するデータの総量を追跡する必要がなくなります。 AWS Encryption SDK は多くの暗号化シナリオに対応する柔軟性を備えていますが、デフォルト設定では鍵導出とフレームサイズの設定を自動的に処理するため、ほとんどのユースケースでこれらの設定を調整する必要はありません。AWS KMS と同様に、呼び出しごとに異なる鍵を派生させるために、ランダムに生成された値 N 、メインキー K 、そして KDF 内の呼び出し固有のコンテキストを使います。 N はデフォルト設定では 256 ビットです。基盤となる KDF は、デフォルトのハッシュとして SHA512 を使う HMAC ベースの抽出展開鍵導出関数 (HKDF) です。 K d は基本的に、鍵 K を使った 1 回の HKDF 呼び出しで次のように生成されます。 K d = HKDF(K, salt=<lbl>, info=<ctx>, 32) ここで <lbl> は定数であり、 <ctx> はデフォルト設定では定数とランダムな 256 ビットの値を連結したものです。 続いて、AWS Encryption SDK は派生鍵 K d を使って、デフォルトでは 4 KB のフレームに分割されたユーザーコンテンツを暗号化します。各フレームの平文 Pf は、決定論的な IV を使った AES-GCM で (C, T) = AES-GCM(Kd, IV, AAD, Pf) として暗号化されます。 96 ビットの決定論的な IV は、フレームカウンター frameID で構成され、 frameID <2 32 です。追加認証データ AAD は Encryption SDK のデータフレームに固有 です。復号時には、受信者は同じ方法で K から K d を派生させ、暗号文 C を復号してフレームの平文 Pf を生成し、認証タグ T を検証します。 4 KB のフレームサイズにより、デフォルトでは単一の暗号化鍵のもとで暗号化できるデータは 2 44 バイト (各 4 K バイトの 2 32 フレーム) を超えないことが保証されます。これは、データキーキャッシュを使った場合でも、NIST が示す境界 (2 68 ) をはるかに下回ります。また、AWS の保守的な要件である <2 -32 の識別不可能性の確率もはるかに下回ります。鍵あたりの呼び出し回数の限界は、データキーキャッシュを使った場合でも、ほとんどの大規模アプリケーションの暗号化回数を上回ります。 注: AWS Encryption SDK はデフォルト設定で保守的な選択をしていますが、 レガシーのバージョン 1.0 を使っている場合や設定を変更している場合は、セキュリティ保証が低くなる可能性があります。たとえば、2 32 -1 バイトというカスタムで最大化したフレームサイズを使うと、平文の合計サイズが大きくなります。これは NIST が示す限界 2 68 は下回りますが、その他の保守的な境界は下回りません。 なお、デフォルトの AWS Encryption SDK 設定は、 鍵コミットメント のような、あまり知られていないセキュリティ特性も提供します。 コミットメント文字列 は、 K と HKDF を使って、派生鍵と同様に生成されます。 まとめ 暗号化呼び出しごとに一意の鍵を派生させることで、AWS KMS と AWS Encryption SDK は、AES-GCM の限界を手動で追跡する必要をなくします。 AES-GCM の境界に関する学術的な根拠については、 SP 800-38D と draft-irtf-cfrg-aead-limits を参照してください。KMS で使われる鍵導出スキームの暗号解析についてさらに詳しく知りたい場合は、 Key Management Systems at the Cloud Scale を参照してください。Encryption SDK の AES-GCM 鍵導出の詳細については、 AWS Encryption SDK algorithms reference を参照してください。 この記事に関するご質問がある場合は、 AWS Security, Identity, & Compliance re:Post で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。   Panos Kampanakis Panos は AWS の Principal Security Engineer です。サイバーセキュリティ、応用暗号、セキュリティ自動化、脆弱性管理の経験があります。サイバーセキュリティに関する出版物を共著し、セキュリティ情報共有、暗号、公開鍵基盤のための共通かつ相互運用可能なプロトコルや言語を提供すべく、さまざまなセキュリティ標準化団体に参加してきました。現在は、エンジニアや業界パートナーと協力して、暗号学的に安全なツール、プロトコル、標準の提供に取り組んでいます。 Matt Campagna Matthew は Amazon Web Services の Cryptographer 兼 Sr. Principal Engineer です。社内全体の暗号ソリューションの設計とレビューを管理し、ポスト量子暗号への移行を主導しています。余暇には、シアトルで完璧なコリアンフライドチキンを探し求めています。 Patrick Palmer Patrick は AWS の Principal Security Specialist Solutions Architect です。世界中のお客様が AWS サービスを安全に使えるよう支援しており、暗号を専門としています。仕事以外では、増えつつある家族と過ごしたり、ビデオゲームをプレイしたりすることを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。