本記事は 2026 年 2 月 23 日に公開された “ Resilience testing on Amazon ElastiCache with AWS Fault Injection Service ” を翻訳したものです。 Amazon ElastiCache は、Valkey、Memcached、Redis OSS をサポートするフルマネージドのインメモリキャッシングサービスで、99.99% の可用性を提供しながら、コスト効率の良い価格でアプリケーションのパフォーマンスをリアルタイムに向上させます。 頻繁にアクセスされるデータに対してサブミリ秒のレスポンスタイムを提供するため、データベースクエリのキャッシング、Web セッション状態の管理、ゲームのリアルタイムリーダーボードの実現などに広く使用されています。 多くのアプリケーションは、キャッシュが常に利用可能であることを前提に構築されています。 耐障害性テストを行わないと、Amazon ElastiCache へのアクセスが失われた際にアプリケーションで問題が発生することがよくあります。 アプリケーションがデータベースへ適切にフォールバックせずにクラッシュすることに気づくかもしれませんが、それは本番環境でのインシデント発生時、つまり手遅れになってからのことです。 そのため、キャッシュが利用できなくなるイベントに備えて構築し、アプリケーションが期待どおりにそれらの障害ケースを処理することをテストする必要があります。 この投稿では、 AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実行する方法と、アプリケーションの耐障害戦略を強化するためにAWS FISをどのように活用できるかをご紹介します。 ソリューションの概要 このソリューションでは、AWS FIS を使用しています。 これは、AWS ワークロードに対して制御された障害注入実験を実施するためのフルマネージドな耐障害性テストサービスです。 メンテナンスや特権を必要とするカスタムスクリプトやサードパーティツールに頼る代わりに、AWS FIS はシステムの耐障害性をテストするための安全でスケーラブル、かつ高可用性のプラットフォームを提供します。 AWS FIS は、システムにストレスがかかった際の応答を観察するために、意図的に障害を発生させるという手法に基づいて動作します。 これらの実験により、弱点を特定し、システムの動作に関する仮定を検証し、実際の障害に耐えるアプリケーションの能力に対する信頼を高めることができます。 AWS FIS を使用すると、テスト環境または本番環境で耐障害性テストを実施できます。 例えば、ピークトラフィック時の Amazon ElastiCache ノード障害のような現実的なシナリオをテストし、最も重要な場面でフェイルオーバーの仕組みが機能することを確認できます。 この記事では、耐障害性テスト用の ElastiCache クラスターのセットアップ方法、AWS FIS 実験テンプレートの作成方法、制御されたフェイルオーバーテストの実行方法、および結果のモニタリングと解釈方法について説明します。 前提条件 このソリューションを実装する前に、以下を確認してください： アクティブな AWS アカウント テスト用の非本番環境 Amazon ElastiCache サービスの基本的な理解 このソリューションでは、新しい AWS リソースの作成と利用が必要です。 そのため、アカウントに費用が発生します。 詳細については、 AWS Pricing を参照してください。 本番環境に実装する前に、非本番環境でセットアップし、エンドツーエンドの検証を実行することを強くお勧めします。 方法論 この実験では、Amazon ElastiCache が自動フェイルオーバーを使用してノード障害時に高可用性を維持する方法を示します。 Multi-AZ が有効でクラスターモードが無効な Amazon ElastiCache for Valkey クラスターでノード障害を発生させ、アプリケーションが手動介入なしで復旧できることを確認します。 フェイルオーバー中は、以下のアクションが実行されます。 障害検出 : ElastiCache がプライマリノードの障害を検出します。 レプリカの昇格 : レプリケーションラグが最も小さいレプリカがプライマリに昇格します。 DNS 更新 : プライマリエンドポイントが自動的に新しいプライマリを指すようになるため、アプリケーションは同じ接続文字列を引き続き使用できます。 ノードの復旧 : 障害が発生したノードは、復旧後にリードレプリカとして再参加します。 クラスターモード無効の構成を使用しているのは、フェイルオーバープロセスをコンソールで観察しやすくするためです。個々のノードの役割がプライマリからレプリカに変わる様子を明確に確認できます。 ただし、これらのテスト原則はクラスターモード有効のデプロイメントにも適用されます。クラスターモード有効の場合、設定エンドポイントがすべてのシャード間のルーティングを自動的に管理します。 この実験は実は ElastiCache Serverless では意味がありません。ElastiCache Serverless はマネージドプロキシの背後で Multi-AZ フェイルオーバーを処理するため、アプリケーションは中断の影響を受けません。 ElastiCache Serverless の仕組みについては、 ドキュメント を参照してください。 耐障害性の高いアプリケーションでは、接続の中断は短時間にとどまり、自動的に再接続し、データベースに過負荷をかけることなく一時的にフォールバックできる必要があります。 ウォークスルー Valkey クラスターの作成 既存の Amazon ElastiCache for Valkey クラスターモード無効クラスターを使用するか、 Valkey (クラスターモードが無効) クラスターの作成 (コンソール) の手順に従って新しいクラスターを起動できます。 このテストでは、Amazon ElastiCache の汎用バースト可能な T4g または T3-Standard microキャッシュノードを使用することで、コストを抑えることができます。 次のスクリーンショットは、プライマリノードと 3 つのレプリカノードを持つクラスターを示しています： また、クラスターにキー名と値を持つタグを作成します。 以下のスクリーンショットでは、キーを fis-testing 、値を yes としています。 このタグは、AWS FIS 実験テンプレートでターゲットの詳細を編集する際に使用します。 AWS FIS テンプレートのセットアップ Amazon ElastiCache クラスターの準備が整い利用可能になったら、以下のような AWS FIS テンプレートを作成します。このテンプレートでは、注入する障害の種類と対象となるリソースを定義します。 AWS FIS を使用するには、AWS リソースで実験を実行して、障害条件下でアプリケーションやシステムがどのように動作するかという仮説をテストします。 実験を実行するには、まず実験テンプレートを作成します。 テンプレートの詳細については、 ドキュメント を参照してください。 AWS FIS コンソールを開きます。 ナビゲーションペインで、 Experiment templates を選択します。 Create experiment template を選択します。 最初のステップ Specify template details で、テンプレートの詳細に関連する説明と名前を入力し、 Account targeting はこのアカウントのままにしておきます。 Next を選択します。Actions と Targets コンポーネントを設定する前に、それらの用途を理解しておく必要があります。 アクションは、ターゲットに対して実行される障害注入アクティビティです。 AWS FIS は、さまざまな AWS サービス向けのアクションを提供しています。 実験テンプレートにアクションを追加すると、AWS FIS はそれを使用して実験を実行します。 ターゲットは、実験中に AWS FIS がアクションを実行する AWS リソースです。 実験テンプレートを作成するときにターゲットを定義し、複数のアクションで使用できます。 AWS FIS は、アクションを開始する前にターゲットを特定し、実験全体を通じてそれらを使用します。 Add Action を選択します。 Action Type で、 aws:elasticache:replicationgroup-interrupt-az-power を選択して、Multi-AZ が有効になっているターゲット ElastiCache レプリケーショングループの指定されたアベイラビリティーゾーン内のノードへの電源を中断します。レプリケーショングループごとに一度に影響を受けるアベイラビリティーゾーンは 1 つだけです。 プライマリノードがターゲットになると、レプリケーションラグが最も少ない対応するリードレプリカがプライマリに昇格します。 指定されたアベイラビリティーゾーン内のリードレプリカの置き換えは、このアクションの期間中ブロックされます。 つまり、ターゲットのレプリケーショングループは容量が減少した状態で動作します。 詳細については、 ドキュメント を参照してください。 必要に応じて関連する Name を入力します。 Target には、 Targets セクションで定義したターゲットを選択します。 このアクションのターゲットをまだ定義していない場合、AWS FIS が新しいターゲットを作成します。 Action parameters で、アクションのパラメータを指定します。 テスト要件に応じて duration を設定してください。 これは、ターゲットノードで障害アクションが継続する時間の長さです。 Save を選択します。 アクションを保存すると、次のスクリーンショットに示すようにターゲットが自動的に作成されます。 aws:elasticache:replicationgroup を選択して Edit Target ページを開きます。 Target method では、 Resource tags, filters and parameters ラジオボタンがすでに選択されています。 Amazon ElastiCache をターゲットにするには、 resourceTags 要素でタグのみを指定できます。 Add new tag ボタンを選択してリソースタグを追加します。 ここでは、キーを fis-testing 、値を yes として使用しています。 Availability Zone identifier ドロップダウンで、このテストで障害を発生させたいノードのアベイラビリティーゾーンを選択する必要があります。 プライマリノードを含むアベイラビリティーゾーンを選択すると、その AZ が影響を受けたときにフェイルオーバーがトリガーされます。 Selection mode では、識別されたすべてのターゲットで実行するデフォルトオプションの ALL を選択します。 Save を選択します。 Next を選択します。 Service access セクションで、デフォルトの選択である Create a new role for the experiment template のままにします。 コンソールに表示されているサービスロール名をコピーしてください。後で使用します。 このステップが完了すると、コンソールに表示されている名前で IAM ロールが作成されます。 Next を選択します。 Send to CloudWatch Logs チェックボックスを選択します。 ロギングは、実験のタイミングとアプリケーションの動作を関連付けるのに役立つため、Amazon CloudWatch 統合を設定しましょう。 そのためには、まず CloudWatch にロググループを作成する必要があります。 ロググループを作成するには、 CloudWatch ドキュメント の手順に従ってください。 テンプレート作成の AWS FIS タブで、Logs セクションの Browse オプションを選択し、右側の Refresh ボタンを使用します。 作成したロググループ名を検索します。 Log version として Version 2 を選択します。 次のスクリーンショットでは、ロググループ名として aws-fis-elasticache を使用しています。 View Permission details ボタンを選択し、Amazon CloudWatch ロギングに必要な権限ポリシーをコピーしてメモ帳に貼り付けます。 後のセクションで、ステップ 19 で作成されたロールを更新するために使用します。 Next を選択します。 テンプレートを確認し、 Create experiment template を選択します。 Amazon CloudWatch 用の AWS IAM ロールの編集 テンプレートが作成されたら、CloudWatch ロギングに必要な権限を持つように、作成した IAM ロールを編集する必要があります。 IAM コンソールを開き、IAM ロールを選択すると、このロールに 2 つのポリシーがアタッチされていることがわかります。 FIS-Console-CWLogging-XXXX という名前で作成されたポリシーを編集し、前述のポリシー JSON ドキュメントをコピーして、ポリシーを保存します。 AWS FIS 実験の実行 AWS FIS コンソールページで、ステップ 2 で作成したテンプレートの右上にある Start experiment を選択し、開始操作を続行します。 モニタリングとログの確認 実験の状態が Running 状態になることを確認できます。 CloudWatch ログの送信先リンクを選択して、先ほど作成したロググループ aws-fis-elasticache の CloudWatch ログを開きます。 ログイベントには、 log_type:action-start のログエントリが 1 つ表示されます。 これは、実験が実際にアクションを実行している、または有効になっている時刻を示しています。 Amazon ElastiCache コンソールに移動すると、クラスターのステータスとノードが以下のように Modifying 状態になっていることが確認できます: また、ノード elasticache-chaos-test-cluster-001 のロールが primary から replica に変更されていることにも気づくでしょう。 これは、以下に示すように Amazon ElastiCache で公開されたイベントからも確認できます: フェイルオーバーは、ロググループ aws-fis-elasticache の AWS FIS ログによると、アクション開始時刻から数秒以内に完了しました。 Amazon ElastiCache クラスターのログを有効にしている場合、他のノードがプライマリノードとの接続の問題を示すログも確認できます。 5 分間 (テンプレートの Action ページのデフォルト設定) が経過すると、AWS FIS ログに log_type:action-end が表示されます: Amazon ElastiCache コンソールでは、ノードとクラスターのステータスが Available と表示されます。 耐障害性の検証: 確認すべきポイントと対応方法 耐障害性テストの実行は最初のステップに過ぎません。 本当の価値は、フェイルオーバー中に何が起こったかを理解し、アプリケーションがそれを適切に処理できることを確認することにあります。 ElastiCache イベントの理解 ElastiCache イベントは、フェイルオーバー中のクラスターの健全性を可視化します。 確認すべき主要なイベントは以下の通りです: Recovering cache nodes は、影響を受けたノードが復元中であることを示します Finished recovery for cache nodes は、元のノードがレプリカとしてクラスターに再参加したことを確認します フェイルオーバープロセス全体は、Multi-AZ 構成の場合、通常数秒以内に完了します クラスターログの分析 ElastiCache クラスターでエンジンログを有効にしている場合、フェイルオーバー中の詳細な接続動作を確認できます: レプリカがプライマリノードの障害を検出した正確なタイミング 「Connecting to MASTER」や「Replica has started synchronizing with the primary」などのメッセージは、リカバリプロセスを示しています 同期成功のメッセージは、データの一貫性が維持されたことを確認しています アプリケーションの耐障害性テスト ElastiCache はフェイルオーバーを自動的に処理しますが、この期間中のアプリケーションの動作が重要です。 接続処理: 適切に設計されたアプリケーションでは、短時間の接続エラー (5 〜 15 秒) の後に自動的に再接続されるはずです。より長い停止時間は、接続プールの設定やリトライロジックに問題があることを示しています。 キャッシュミス時の動作: アプリケーションがデータベースに過負荷をかけることなく、適切にフォールバックすることを確認してください。データベースのクエリレートは一時的に増加しますが、管理可能な範囲に収まるべきです。 パフォーマンスの低下: フェイルオーバーの前、最中、後のレスポンスタイムを測定してください。耐障害性のあるアプリケーションでは、フェイルオーバー中にレイテンシーが 50ms から 200ms に増加し、その後正常に戻ることがあります。1 秒を超えるスパイクが発生した場合は、接続タイムアウトとリトライの設定を調査する必要があります。 Amazon ElastiCache でのアプリケーション動作の監視の詳細については、 Monitoring best practices with Amazon ElastiCache for Redis using Amazon CloudWatch を参照してください。 まとめ この記事では、AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実装する方法を学びました。 このテストにより、キャッシュ戦略の弱点を事前に特定し、フェイルオーバーメカニズムを検証し、実際のインシデントが発生する前に適切な縮退動作を確保できます。 これらの実験を実行することで、チームはインシデント対応手順を練習し、キャッシュ障害がシステムアーキテクチャ全体に与える連鎖的な影響を理解できるようになります。 Amazon ElastiCache 全般のベストプラクティスについては、 ElastiCache のベストプラクティスとキャッシュ戦略 を参照してください。 クリーンアップ このウォークスルーのために新しい Amazon ElastiCache クラスターを作成した場合は、 ElastiCache でのクラスターの削除 ドキュメントの手順に従ってクラスターを終了し、コストを最適化できます。 また、 実験テンプレートを削除する ドキュメントの手順に従って AWS FIS 実験テンプレートを削除することもできます。 IAM ロールの削除と CloudWatch ロググループの削除については、それぞれ IAM ロールの削除 (コンソール) と CloudWatch Logs の削除 のドキュメントを参照してください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Raunak Gupta Raunak は AWS のシニアデータベースソリューションアーキテクトです。AWS に 6 年以上在籍しており、Aurora と RDS オープンソースの専門家でもあります。17 年以上の実務経験を持ち、エンタープライズのお客様にデータベースの運用パフォーマンスとデータベースのベストプラクティスに関する技術支援を提供しています。

本記事は 2026 年 2 月 26 日 に公開された「 Optimize data management on S3 Tables with Intelligent-Tiering 」を翻訳したものです。 多くの組織が、ペタバイト規模の成長とパフォーマンスに対応でき、コストのかかるリライトなしにスキーマやパーティションを柔軟に変更できる Apache Iceberg をデータレイクに採用しています。タイムトラベルやインクリメンタル処理といった機能により、最新のデータレイク管理が可能になります。しかし、データが増大するにつれ、Iceberg データセットの効率的な管理は難しくなります。規制要件や長期的な分析ニーズから数か月〜数年にわたりデータを保持する組織も多く、パフォーマンスやアクセス性とコストのバランスに苦慮しています。テーブルのメンテナンス、ファイルレイアウトの最適化、コスト効率の高いリテンションポリシー（維持期間）の実装は、継続的にリソースを消費し、コスト増加につながります。 Amazon S3 Tables は、Iceberg テーブル向けに設計されたテーブルストレージと新しいバケットタイプを導入し、 Amazon S3 に構造化データを簡単に保存できるようにしました。S3 Tables はコンパクション、スナップショット管理、参照されていないファイルの削除といったメンテナンスタスクを自動的に処理します。さらに、 Intelligent-Tiering ストレージクラス のサポートが追加されました。アクセスパターンに基づいてデータをストレージ階層間で自動的に移動し、ストレージコストを最適化します。データレイクの規模が拡大しデータが古くなっても、パフォーマンスに影響を与えることなくコスト効率を継続的に最適化できます。 本記事では、Intelligent-Tiering をコンパクションやスナップショット管理などの メンテナンス機能 と組み合わせて、長期的な総所有コスト (TCO) を削減する方法を詳しく解説します。 S3 Tables でのデータ管理の最適化 S3 Tables にデータが到着した時点では、最適な状態ではない場合があります。たとえば、分析効率よりも取り込みスループットや柔軟性を優先してデータが取り込まれることがあります。ストリーミング更新で頻繁にテーブルへの変更がコミットされ小さなファイルが生成されるケースや、merge-on-read パターンでテーブル更新時にインクリメンタルな差分ファイル/deleteファイルが追加されるケースが典型的です。このような場合、クエリパフォーマンスの向上と長期的なストレージの最適化にメンテナンス操作が必要になります。S3 Tables は長期的なデータ最適化のために以下の手法をサポートしています。 スナップショット管理 – 必要な履歴データのみを保持し、冗長な情報を体系的に廃止・削除して、参照されていないファイルを完全に除去します コンパクション (Binpack、Sort、Z-order) – 小さなファイルを統合してより大きく効率的なファイルを作成します。Sort や Z-order を使ってデータを並べ替え、より高速でコスト効率の高いクエリを実現したり、delete ファイルをデータファイルにマージしたりできます ストレージ階層の最適化 – Intelligent-Tiering ストレージクラスを活用し、規制やビジネスニーズによる長期データ保持のストレージコストを削減します S3 Tables のスナップショット管理 Iceberg のスナップショットは、テーブルの完全な状態を記録した不変のポイントインタイムレコードです。既存のコンテンツを変更せずに、すべてのデータファイルとメタデータをキャプチャします。タイムトラベルクエリ、同時操作中の一貫した読み取り、運用復旧やリストアのための以前のテーブルバージョンへのロールバックといった機能を実現します。 S3 Tables は、リテンションポリシーの設定やライフサイクル管理の自動化のための コンソールコントロールと API 操作 でスナップショット管理を効率化します。 S3 Tables は、履歴データのニーズとストレージ最適化のバランスをとるための調整可能な有効期限ルールを提供し、ガバナンス要件に対応するスナップショットメトリクスと監査証跡も備えています。保持するスナップショットの最小数、スナップショットの最大保持期間、参照されていないファイルの削除などのプロパティが含まれます。スナップショット管理の詳細は こちらの動画 で解説しています。 nonCurrentDays 、 unreferencedDays 、 maximumSnapshotAge 、 minimumSnapshots などのチューニングパラメータについては、 考慮事項と制限 を慎重に評価することをお勧めします。リテンション要件に合わせて適切に値を調整してください。 S3 Tables のコンパクション Apache Iceberg のコンパクションは、複数の戦略でテーブルパフォーマンスを最適化します。小さなファイルを大きなファイルに統合してメタデータの負荷と I/O リクエスト料金を削減し、delete ファイルをマージし、ソート順でデータをリライトしてパーティション述語を高速化し、多次元クラスタリングで関連データを近接配置して複数カラムでのスキャン効率を向上させます。Amazon S3 Tables は適切なポリシーでコンパクションを自動化し、テーブルのファイルレイアウトを継続的に最適化し、クエリパフォーマンスの向上とコスト削減を実現します。コンパクションのスケジューリング、リソース割り当て、実行を自動的に処理するため、運用負荷がなくなります。S3 Tables は以下のコンパクション手法をサポートしています。 Binpack コンパクション – 多数の小さなデータファイルを少数の最適なサイズのファイルに統合し、メタデータの負荷を削減して、分散処理フレームワークでクエリパフォーマンスを低下させる「スモールファイル問題」を最小化します Sort コンパクション – 1 つ以上の指定カラムに従ってレコードを物理的に並べ替えるようにデータファイルをリライトし、メタデータベースのフィルタリングによる効率的なデータスキッピングを可能にして、ソートカラムに一致する述語でのクエリパフォーマンスを大幅に向上させます Z-order コンパクション – 空間充填曲線(space-filling curve)アルゴリズムで多次元データを 1 次元空間にマッピングし、複数カラムにわたって類似するレコードを近接配置して、Z-order 対象次元の任意のサブセットに対する述語を持つクエリを最適化します Auto (デフォルト) – Amazon S3 Tables がテーブルのソート順に基づいて最適なコンパクション戦略を選択します。すべてのテーブルのデフォルトのコンパクション戦略です。メタデータにソート順が定義されているテーブルには Sort コンパクションが自動的に適用されます。ソート順が定義されていないテーブルには Binpack コンパクションがデフォルトで使用されます 詳細は S3 Tables メンテナンスドキュメント と、AWS での Apache Iceberg 利用に関する規範的ガイダンスの コンパクションセクション をご覧ください。 適切なコンパクションの実施は、持続可能なデータレイク管理に不可欠です。最適化されていないテーブルは、時間の経過とともにパフォーマンスが低下しコストが増加します。定期的なコンパクションにより、小さなファイルの蓄積を防ぎ、最適なデータ構成を維持し、テーブルがペタバイト規模に成長してもクエリ効率を確保できます。パフォーマンス面の直接的なメリットに加え、適切に実行されたコンパクションは圧縮率とファイルレイアウトの改善によりストレージ効率を向上させます。より安定したクエリパフォーマンス、予測可能なコスト、そしてリアクティブなテーブルメンテナンスではなく価値を生み出す活動にエンジニアリングリソースを集中できるようになります。 S3 Tables の Intelligent-Tiering 前述のスナップショットとコンパクション機能に加え、S3 Tables は re:Invent 2025 で S3 Intelligent-Tiering によるストレージ最適化を提供開始しました。このストレージクラスは、アクセスパターンの変化に基づいてコスト効率の高いアクセス階層間でデータを自動的に移動します。データ取得にかかる費用、パフォーマンスへの影響、可用性の変化はありません。 S3 Intelligent-Tiering は個々のデータファイルレベルで動作するため、1 つのテーブル内のファイルが異なる階層に同時に存在できます。データは以下の 3 つのアクセス階層で自動的に管理されます。 高頻度アクセス (FA) – すべてのファイルのデフォルト階層。他の階層のファイルもアクセスされるとここに戻ります 低頻度アクセス (IA) – 30 日間連続してアクセスがないファイルがここに移動します アーカイブインスタントアクセス (AIA) – 90 日間連続してアクセスがないファイルがここに移動します すべての階層でミリ秒レイテンシー、高スループットパフォーマンス、99.9% の可用性、99.999999999% の耐久性が維持されます。オブジェクトは Get API 呼び出しでアクセスされると高頻度アクセス (FA) 階層に遷移します。テーブル内のデータファイルが読み取られるたびに、読み取りをトリガーした操作に関係なく発生します。データファイルの読み取り (FA 階層への遷移) をトリガーする操作は以下のとおりです。 テーブルへの直接アクセス – データファイルを読み取るクエリやスキャン テーブル管理操作 – 既存のデータファイルの読み取りを必要とする LoadTable や UpdateTable などの REST API 呼び出し レプリケーション – テーブルがレプリケートされる際、コンテンツを転送先に転送するためにソースデータファイルを読み取る必要があり、IA/AIA 階層のファイルに対して Get 呼び出しがトリガーされます 重要なポイントとして、階層の遷移はデータファイルが読み取られたときにファイルレベルで発生し、テーブルが参照されたときではありません。基盤となる S3 オブジェクトの読み取りを伴う操作はすべて、オブジェクトを IA/AIA から FA 階層に移動させます。なお、128 KB 未満のファイルは高頻度アクセス階層に留まりますが、コンパクションでより大きなファイルに統合されると階層移動の対象になります。 S3 Tables の Intelligent-Tiering とメンテナンスタスクの連携 スナップショット管理やファイルクリーンアップなどのテーブルメンテナンス操作は、すべての階層で引き続き実行されます。コンパクションについては、S3 Tables は独自のアプローチをとります。コンパクションタスクの開始時に、コンパクションの種類 (Binpack、Sort、Z-order) に関係なく、S3 Tables はコンパクション候補のデータファイルの階層を確認します。この確認自体は階層の変更に影響しません。S3 Tables は FA 階層にあるファイルのみにコンパクションを実行し、30 日以上アクセスしていないデータやファイルが昇格されないようにします。FA 階層のファイルのみを対象とすることで、頻繁にアクセスされるデータのパフォーマンスを最適化しつつ、コールドデータのメンテナンスコストを削減できます。低い階層のデータファイルがアクセスされると FA 階層に戻り、コンパクションの対象になります。 コンパクションは高頻度アクセス階層のファイルのみを処理するため、低コスト階層のデータに対する削除操作では、自動的にコンパクションされない delete ファイルが生成されます。関連するデータファイルがアクセスされて高頻度アクセス階層に戻ると、delete ファイルもコンパクションの対象になります。この動作の詳細は ドキュメント をご覧ください。 以下に、この動作を示す 2 つの例を紹介します。 Binpack コンパクションの例 シンプルな Binpack コンパクションのプロセスを見てみましょう。あるお客様が、当初有効にしていなかったコンパクションを有効にすることにしました。パーティション内の一部のデータファイルは頻繁にアクセスされていましたが、一部はアクセスされておらず、30 日後に自動的に IA 階層に遷移しています。 S3 Tables のコンパクションエンジンが起動すると、コンパクション候補のデータファイルの階層を検証します。FA 階層にあるデータファイルのみにコンパクションを実行し、アクセスされていないファイルはそのまま残します。IA や AIA 階層のファイルを確認しても、階層ステータスには影響しません。結果として、頻繁にアクセスされたデータはより効率的なファイルになり、アクセスされていないファイルのコスト削減は維持されます。2 週間後、残りの 2 つのファイルのデータにクエリがアクセスし、FA 階層に戻りました。 すべてのファイルが FA 階層にある状態で、次のコンパクションエンジンのイテレーションでは、S3 Tables のコンパクションエンジンが追加のコンパクションを実行し、2 つの小さなファイルを大きなファイルにマージします。 Delete ファイルの例 Apache Iceberg の equality delete、positional delete、 deletion vector (v3) などの delete ファイルタイプは、個別の delete 参照ファイルを生成します。これらのファイルは merge-on-read で使用されるか、メンテナンス操作中にデータファイルにマージされます。ここでは equality delete を使って、コンパクションエンジンと S3 Tables Intelligent-Tiering の連携を説明し、delete ファイル管理とデータファイルのストレージ階層のライフサイクルを示します。 Apache Iceberg の equality delete は、位置ベースのメタデータを必要とせずに特定のフィルター条件に一致するレコードを削除できるデータ変更操作で、大規模データセットでの効率的かつ正確なデータ削除を可能にします。テーブル更新の merge-on-read 方式です。 上の図の例では、クエリ時に Iceberg が delete ファイルの述語をデータファイルに動的に適用します。id=2、name=Brad の行はストレージに残りますが、クエリからは見えなくなります。Iceberg は元のデータファイルを変更せずに、読み取り操作中に削除情報を「マージ」します。この 2 つのファイルに対してコンパクションが実行されると、以下の処理が行われます。 データファイルと delete ファイルの両方を読み取る id=2、name=Brad に一致する行をデータから物理的に削除する 削除された行を含まない新しい統合データファイルを作成する 条件が適用済みのため、個別の delete ファイルを除去する テーブルデータへのアクセスを最適化し、読み取り操作中の処理負荷を削減するために一般的に有効な操作ですが、データファイルが IA や AIA 階層にある場合、S3 Tables はコンパクションを実行しません。ただし、ファイルが再度読み取られて高頻度アクセス階層に戻ると、コンパクションが新しいサイクルを開始する際にデータファイルの階層を評価し、FA 階層にあることを確認してメンテナンスタスクを実行します。不要な行を削除し、読み取りに最適化されたファイルを作成します。 S3 Tables でコンパクションを手動実行して delete ファイルの統合やレコードの完全削除を行うことも可能ですが、外部コンパクションジョブは Intelligent-Tiering ストレージクラスの認識とは独立して動作します。S3 Tables は外部コンパクションジョブの実行タイミングを予測できないため、Intelligent-Tiering の最適化はテーブルの自然なアクセスパターンのみに基づきます。手動コンパクションを実行すると、IA や AIA 階層に遷移したファイルを含むデータファイルが統合のために読み取られ、FA 階層に戻ります。その結果、ストレージコストが増加する可能性があります。 まとめ データ駆動型の環境において、効果的なテーブルメンテナンスは大規模データレイクを管理する組織にとって不可欠です。 S3 Tables は、スナップショット管理、コンパクション戦略、Intelligent-Tiering を統合したデータライフサイクル管理ソリューションを提供します。スナップショットで重要な履歴データを保持し、アクセスパターンを考慮したコンパクションでファイルレイアウトを最適化し、コールドデータをコスト効率の高いストレージ階層に自動的に移動します。 スナップショット管理、コンパクション、Intelligent-Tiering の連携により、日常的にアクセスされるデータも長期保存されるデータも、ライフサイクル全体を通じてパフォーマンスとコスト効率の両方が維持されます。組織は複雑なメンテナンスワークフローからデータからの価値ある洞察の抽出へと注力を移すことができ、安定したパフォーマンス、最適化されたストレージコスト、ビジネスニーズの変化に対応するスケーラブルなデータレイクの恩恵を受けられます。本ブログをお読みいただきありがとうございます。ご質問やコメントがありましたら、コメントセクションにお気軽にお寄せください。 著者について Ran Pergamin ストレージ担当のシニアスペシャリストソリューションアーキテクトです。大規模なストレージの課題解決に取り組んでいます。最近はコンテナ、オープンテーブルフォーマット、データレイク、ベクトルに注力しています。プライベートでは CrossFit を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の Akira Shimosako がレビューしました。

はじめに｜なぜ“AI × DesignOps”なのか？ プロダクトが成長すればするほど、ビジュアルアセットの需要は指数関数的に増えていきます。しかし、デザイナーの数は（悲しいことに）指数関数的には増えません。 従来のイラスト制作は個人のスキルに依存しやすく、結果として品質のバラツキや制作スピードが開発ベロシティを阻害する「 デザイン負債（Design Debt） 」を生み出していました。DesignOps の本質は、デザインを「一点物のマニュアルアート」から「再現可能なシステム」へと昇華させることにあります。 私たちは今回、AI を単なる「便利な魔法の筆」ではなく、一貫性のあるデザインシステムを支える「 レンダリングエンジン 」として再定義する検証を行いました。 DesignOpsとは？ 「DesignOps（デザインオプス）」という言葉、デザイナー以外にはまだ少し耳慣れないかもしれません。 簡単に言うと、 DesignOps は 「 デザイン版の DevOps 」です。 属人的になりがちなデザイン業務をプロセスとして整理し、担当者が変わってもチームとして一定の品質をデプロイできる状態を目指す考え方です。 今回の取り組みでは、生成 AI を「クリエイティブな遊び」としてではなく、プロダクトのコードベースの一部のように運用できるかを検証しました。特にエンジニア主体の組織においては、デザインも「 ロジックとして扱えるか 」が、持続可能な運用の鍵になります。 プロジェクトの背景：Unlimited App で直面した「成長の痛み」 Unlimited App ではこれまで、プロダクトデザイナーがイラストの世界観設計から品質の最終調整まで、いわば「職人のこだわり」をもって一貫して担ってきました。しかし、プロダクトが成長し、機能追加やコンテンツ拡張が加速するなか、必要とされるイラストの量と展開範囲は、私たちの想像を超えるスピードで拡大していきました。 https://kinto-jp.com/unlimited/app/ その過程で、個人の努力だけではカバーしきれない「 構造的なボトルネック 」が浮き彫りになってきたのです。 工数の比例増加 ：表現を都度最適化する運用では、制作アセット数に比例して工数も積み上がっていく（まさに O(n) の世界です）。 再現性の設計難度 ：クオリティの判断が個人の経験値に依存しやすく、「なぜこれが正解なのか」という基準を仕組みとして残しづらい。 属人的なバランス調整 ：スピードと完成度のトレードオフを、常に個人の「さじ加減」で調整し続けなければならない。 これらは決して個人のスキルの問題ではなく、プロダクトが次のステージへ進むために解決すべき「 システム上の課題 」でした。 そこで生まれたのが、「 イラスト制作を個のスキルに依存する形から、再現性のある設計へとリファクタリングできないか？ 」という問いです。私たちはこの問いに対し、生成 AI という強力なエンジンを DesignOps のプロセスに組み込むことで、持続可能な制作体制の構築に挑みました。 ※ [ ちょこっと技術解説 ]： O(n) とは？ エンジニアがよく使う「計算量」を測る指標です。ここでは「描くイラストの枚数（ n ）」が増える分だけ、「制作時間」も正直に増えていくという 線形の現実 を指しています。 つまり、「 単なる「魔法」ではなく、10 倍の依頼が来たら 10 倍の工数が必要になる 」という、デザイナーにとっては少し切ない、そしてエンジニアにとっては「今すぐ最適化（リファクタリング）したい！」と血が騒ぐ状態のことです。 今回の検証アプローチ｜“AIに寄せる” vs “AIを寄せる” AI を活用する際、戦略は大きく 2 つに分かれます： AI に寄せる（AI-Native Approach） AI が得意な表現（原生スタイル）をそのまま受け入れ、効率を最大化する。「AI っぽさ」を味方につける手法です。 AI を寄せる（Brand-Centric Approach） 独自のブランドアイデンティティに基づき、AI の出力を厳格に制御する。 Unlimited App はすでに確立された世界観を持つプロダクトです。そのため、前提条件として「AI を寄せる」 アプローチを選択しました。これは、プロンプトを単なる命令文ではなく、ブランドの 「デザイン・トークン（Design Tokens）」 として定義し、AI という不確実な実行環境において 「決定論的な出力（Deterministic Output）」を目指す、エンジニアリング的な挑戦でもあります。 イラスト標準化の設計思想とプロンプトアーキテクチャ 「AI なら、プロンプトひとつで何でも描いてくれるのでは？」——そんな期待は、運用フェーズに入った瞬間に崩れ去ります。実用的な DesignOps において、プロンプトは単なる「魔法の呪文」ではありません。明確な設計意図を AI へ伝えるための、厳密な「 インターフェース 」であるべきです。 標準化プロセスの構築にあたり、筆者は下図のような 7つのステップ を策定しました。ビジュアル定義の抽出（Step 1）からリファレンスの整理（Step 4）までは、いわば「 視覚的な仕様書 （ Visual Spec ）」を書き上げる、設計の根幹を支えるフェーズです。 Step 1〜4：プロンプトを「エンジニアリング」するための前処理 Step 1｜ビジュアル定義の抽出（Extracting Visual Tokens） 最初に取り組んだのは、デザインシステムとの整合性チェックです。2.5D の立体感、余白の持たせ方、低コントラストな配色……。これらを言語化する工程は、後に解説する 「 Style Tokens （ スタイル定数 ）」 の基盤となります。 Step 2｜イラスト用途の分類（Defining the Scope） 生成 AI の活用範囲を「クリエイティブな表現」ではなく、「 UX を補助するインフォグラフィック 」 と定義しました。目的を限定することで、維持すべき「再現性」と、AI に任せるべき「表現幅」の境界線が明確になります。 Step 3 & 4｜リファレンスの構造解体（Deconstructing References） 大量のリファレンスを収集し、「好き嫌い」という感性ではなく、構図や影の強度といった「 Visual Spec（視覚仕様） 」として分解・整理しました。「なんとなく似ている」を「仕様通りである」に変えるための、最も泥臭く、かつ重要なリサーチ工程です。 この Step 1〜4 の本質は、「 AI に依存しない設計構造を人間側で作る 」 ことにあります。 このプロセスで最もエキサイティングであり、かつ重要なのが Step 5 の「プロンプト作成」 です。ここを単なる「作文」にせず、 エンジニアリング的に構造化された工程 として設計しました。 具体的には、プロンプトを以下の 2 層構造（Layered Architecture） として定義しています： Part 1：Style Tokens（スタイル定数層） 線画の太さ、立体感、陰影のルール、配色など、プロダクトの DNA を定義します。「何を描くか」に依存しない、 再利用可能な Constant（定数）レイヤー です。 Part 2：Content Variables（コンテンツ変数層） 「車」「人物」「スマホを持つ手」など、画面ごとに差し替え可能な Dynamic Variable（動的変数）レイヤー です。 この 「 スタイルとコンテンツの解耦（Decoupling） 」 こそが、DesignOps 視点での解決策です。これにより、「何を描いても同じトーンで出力される」という、デザイナーにとっての聖杯（Holy Grail）を目指しました。 ツールごとに異なる「Prompt の最適解」 検証を進める中で面白いことが分かりました。AI ツールごとに「プロンプトの癖」が全く違うのです。以前は同一のプロンプトで比較していましたが、現在は「構造（Part 1 / Part 2）は共通、実装（実際の記述）は各ツールに最適化」 という方針に切り替えました。 「プロンプトを共有する」のではなく、 「プロンプトを設計するインターフェース（ルール）を共有する」。この方が、ツールの進化に柔軟に対応できる持続可能な仕組みになります。 徹底検証：生成 AI 3 社の「性格診断」—— イラスト標準化の最適解を探る 2025年10月時点の Midjourney 検証 まずは、2025年10月に行った Midjourney（V7）での検証結果です。 当時の出力は、視覚的な完成度が非常に高く、一枚絵としての魅力は群を抜いていました。 しかし、標準化という観点では、いくつかの課題が見えてきました。 装飾的な要素が多く、情報量がやや過剰 構図がダイナミックで、並べた際の統一感が出にくい ブランドトーンよりも「生成AIらしさ」が前面に出る傾向 つまり、 創造性は高いが、制御性が低い。 この特性はクリエイティブ用途には適していますが、UI内で量産・運用するインフォグラフィック用途には不向きであると判断しました。 ChatGPT / Gemini へのシフト Midjourney との比較を経て、検証の軸を「表現力」から「再現性」へとシフトしました。 同一のビジュアルリファレンスと構造化プロンプトを用い、ChatGPT および Gemini で出力を比較しました。 この時点で明確になったのは、 ChatGPT は構図の安定性が高い Gemini はクリーンだが、再解釈が入る傾向がある という違いでした。 最新検証：観点別比較 プロンプトの構造を定義したところで、次なるステップは「どの実行エンジン（AI モデル）が最も安定して仕様通りに動くか」のベンチマークテストです。私たちは、構図・人物・色彩・命令遵守性の 4 つの観点から、プロダクト運用への適性を評価しました。 ① 構図の安定性—— UI に馴染むか？ インフォグラフィックにおいて、余白と主体のサイズ感は「UI の整合性」に直結します。 ChatGPT は視点・余白・被写体のバランスが安定しており、複数枚を並べた際の一貫性が高い結果となりました。 一方 Gemini は、微妙な視点変更や背景処理の差異が発生しやすく、量産時の揺らぎがやや大きい傾向が見られました。 ② 人物表現の精度—— 意図が伝わるか？ 「シートベルトを締める」「スマホを見る」といった具体的な動作の正確さを検証しました。 人物の顔パーツ・視線・身体バランスにおいて、ChatGPT は安定したクオリティを維持しました。 Gemini は柔らかいトーンで描写される一方、表情や骨格の一貫性に若干のばらつきが見られました。 ③ 用色とブランド整合性 ChatGPT は指定した色調レンジを忠実に守る傾向が強く、ブランドトーンとの整合性が高い結果となりました。 Gemini は自然なグラデーション処理を行う反面、色相・彩度が微妙に変化するケースがあり、厳密なトーン統制には追加調整が必要でした。 ④ 命令遵守性（Instruction Following）—— 仕様書通りに動くか？ 最も大きな差はここでした。 ChatGPT はプロンプト構造（Part 1 / Part 2）をほぼそのまま出力に反映する傾向が強く、設計思想と出力結果の対応関係が明確でした。 Gemini は意図を解釈し、最適解を“再構成”する挙動が見られ、創造性は高いものの、決定論的制御はやや難しいという印象です。 ※ 正密に Gemini が過度な再解釈を試みるからこそ、私たちは Part 1（定数層）において、より厳密なビジュアルのガードレールを定義し、封鎖（Lockdown）する必要があるのです。 各ツールの本性：創作のパートナーか、信頼の実行エンジンか Midjourney：気分屋な天才アーティスト 2025 年 10 月時点の検証では、Midjourney は 圧倒的な 「 映え 」を誇りました。一枚絵としての完成度は素晴らしいのですが、標準化という観点では少し「個性が強すぎ」ました。 情報量が多すぎて UI の邪魔をしてしまう。 構図がダイナミックすぎて、並べた時に統一感が出にくい。 つまり、「 クリエイティブな爆発力はあるが、規律を守るのが苦手なタイプ 」です。 Gemini：再解釈を試みるクリエイティブ・ディレクター Gemini 3 Flash などの最新検証では、非常にクリーンな UI イラストを生成してくれますが、時折「自分の色」を出したがる傾向があります。 構図や余白が毎回少しずつズレる「自由奔放さ」。 プロンプトを忠実に守るというより、「 意図を汲み取ってリミックスしてしまう 」挙動が見られました。これは創作には良いですが、量産プロセスでは「予測可能性」を下げる要因になります。 ChatGPT (DALL-E)：仕様書通りに動くシニアエンジニア 対照的に ChatGPT は、 プロンプトの構造をそのまま出力に反映する能力 （ Instruction Following ）が極めて高いことが分かりました。 構図が安定し、用色も保守的でルール化しやすい。 まさに DesignOps における 「 信頼できる実行エンジン 」 です。 「イラストを作る（Make）」ツールではなく、「運用する（Ops）」ツール としての適性が最も高いと判断し、現在は ChatGPT を中心に検証を進めています。 ※ もちろん、表現の幅や偶発的なひらめきという点では、Midjourney や Gemini に軍配が上がる場面もあります。 実装結果：Unlimited App で何が変わったのか？ 確立した標準スタイルは、現在 Unlimited App 内の「車種別イラスト」や「レベル選択カード」などで試験的に運用されています。「 AI で 8 割のベースを生成し、人間が最後の 2 割を整える 」というフローにより、制作スピードと一貫性が（ついに！）両立し始めました。 しかし、この取り組みは Unlimited App という「実験場」だけで完結するものではありません。私たちが構築したプロンプトの 2 層構造は、いわばデザインの「共通プロトコル」です。将来的には、「スタイル定数（Part 1）」というコンフィグを各ブランドの DNA に合わせて差し替えるだけで、社内のあらゆるプロダクトやサービスへこの仕組みを横展開（スケール）させていくことを目見据えています。プロダクトを跨いで「一貫性のあるビジュアルを即座にデプロイできる」状態——これこそが、私たちが目指す真の DesignOps の姿です。 やってみて分かった課題 数ヶ月の検証で分かったのは、プロンプトには「 賞味期限（Prompt Rot） 」があるということです。ツールのアップデートにより、昨日まで動いていた魔法の言葉が、今日には効かなくなる。 そのため、プロンプトを一度作って終わりにするのではなく、 継続的にリファクタリングしていく前提の設計 が必要です。今後は、これらのメンテナンスを自動化する「AI Agent 的なアプローチ」も視野に入れています。 まとめ：AI × DesignOps は何を変えうるのか 今回の検証を通じて確信したのは、生成 AI は単なる「魔法」ではなく、 DesignOps を再設計するための強力なトリガー であるということです。 標準化とは、自由を奪うことではありません。むしろ、「 どこを固定し（Constants）、どこを柔軟にするか（Variables） 」を定義することで、変化の激しいプロダクト開発においてクリエイティブな安定走行を可能にする行為です。 DesignOps は、デザインを「属人的な手癖」から「再現可能なプロセス」へと拡張します。この取り組みが、皆さんのプロダクトにおけるクリエイティブ運用のヒントになれば幸いです。