2021 年に AWS に入社して以来、私は Amazon Elastic Compute Cloud (Amazon EC2) インスタンスファミリーが成長するのを見てきました。そのペースは今でも驚きを隠せません。AWS Graviton 搭載のインスタンスから、特殊な高速コンピューティングオプションまで、パフォーマンスの限界をさらに押し上げる新しいインスタンスタイプが数か月ごとにリリースされているように感じられます。2026 年 2 月の時点で、AWS は 1,160 を超える Amazon EC2 インスタンスタイプを提供しており、その数は今も増え続けています。 2026 年 2 月 16 日週最初のニュースである Amazon EC2 M8azn インスタンスの一般提供はその良い例です。M8azn インスタンスは、第 5 世代 AMD EPYC プロセッサを搭載した高周波で高ネットワークの汎用インスタンスであり、クラウド内で最も高い 5 GHz の最大 CPU 周波数を提供しています。前世代の M5zn インスタンスと比較した場合、M8azn インスタンスは最大 2 倍優れたコンピューティングパフォーマンス、4.3 倍広いメモリ帯域幅、10 倍大きい L3 キャッシュを提供します。また、M5zn より最大 2 倍のネットワークスループット、最大 3 倍の Amazon Elastic Block Store (Amazon EBS) スループットも提供します。 第 6 世代の Nitro Card を使用して AWS Nitro System 上に構築された M8azn インスタンスは、自動車、航空宇宙、エネルギー、電気通信分野におけるリアルタイム財務分析、ハイパフォーマンスコンピューティング、高頻度取引、CI/CD パイプライン、ゲーム、シミュレーションモデリングなどのワークロード向けです。このインスタンスでは、メモリと vCPU の比率が 4:1 になっており、2 個から 96 個の vCPU 数、最大 384 GiB のメモリを搭載した 9 種類のサイズ (2 種類のベアメタルタイプを含む) で利用できます。詳細については、 Amazon EC2 M8azn インスタンスページ をご覧ください。 2026 年 2 月 9 日週のリリース 以下は、2026 年 2 月 9 日週に行われたその他の発表の一部です。 Amazon Bedrock が 6 つのフルマネージドオープンウェイトモデルのサポートを追加 – Amazon Bedrock が、DeepSeek V3.2、MiniMax M2.1、GLM 4.7、GLM 4.7 Flash、Kimi K2.5、Qwen3 Coder Next のサポートを開始しました。これらのモデルは、フロンティア推論とエージェンティックコーディングのワークロードに対応します。DeepSeek V3.2 と Kimi K2.5 は推論とエージェンティックインテリジェンスを対象としており、GLM 4.7 と MiniMax M2.1 は大規模な出力ウィンドウでの自律コーディングをサポートし、Qwen3 Coder Next と GLM 4.7 Flash は本番環境デプロイ用のコスト効率に優れた代替手段を提供します。Project Mantle を活用するこれらのモデルは、OpenAI API 仕様との設定不要の互換性を提供します。 このリリースにより、仕様主導型の AI 開発ツールである Kiro での DeepSeek v3.2、MiniMax 2.1、Qwen3 Coder Next といった新しいオープンウェイトモデルの使用も可能になります。 Amazon Bedrock が AWS PrivateLink のサポートを拡大 – Amazon Bedrock が、 bedrock-runtime エンドポイントの既存サポートに加えて、 bedrock-mantle エンドポイントでも AWS PrivateLink をサポートするようになりました。bedrock-mantle エンドポイントは、Amazon Bedrock で提供される大規模な機械学習モデル用の分散型推論エンジンである Project Mantle を活用しています。Project Mantle は、サービス品質制御を備えたサーバーレス推論、自動化されたキャパシティ管理によって引き上げられたデフォルトカスタマークォータ、OpenAI API 仕様との設定不要の互換性を提供します。OpenAI API 互換エンドポイントの AWS PrivateLink サポートは、14 の AWS リージョンでご利用いただけます。使用を開始するには、Amazon Bedrock コンソールにアクセスするか、OpenAI API 互換性ドキュメントを参照してください。 Amazon EKS Auto Mode がマネージド Kubernetes 機能のための強化されたロギング機能を発表 – Amazon EKS Auto Mode で Amazon CloudWatch Vended Logs を使用するログ配信ソースを設定できるようになりました。これは、Auto Mode のマネージド Kubernetes 機能からコンピューティングの自動スケーリング、ブロックストレージ、負荷分散、ポッドネットワーキングに関するログを収集するために役立ちます。各 Auto Mode 機能は、AWS 認証と承認が組み込まれた CloudWatch Vended Logs 配信ソースとして、標準の CloudWatch Logs よりも低い料金で設定できます。ログは、CloudWatch Logs、Amazon S3、または Amazon Data Firehose を宛先として配信できます。この機能は、EKS Auto Mode が提供されているすべてのリージョンでご利用いただけます。 Amazon OpenSearch Serverless がコレクショングループのサポートを開始 – 新しいコレクショングループを使用して、異なる AWS Key Management Service (AWS KMS) キーを持つコレクションの全体で OCU (OpenSearch Compute Unit) を共有できるようになりました。コレクショングループは、コレクションレベルのセキュリティとアクセス制御を維持しながら、共有コンピューティングモデルを通じて全体的な OCU コストを削減します。また、最大 OCU 制限に加えて最小 OCU 割り当てを指定することも可能になったため、遅延の影響を受けやすいアプリケーションの起動時におけるベースラインキャパシティが保証されます。コレクショングループは、現在 Amazon OpenSearch Serverless が提供されているすべてのリージョンでご利用いただけます。 Amazon RDS がスナップショットの復元時におけるバックアップ設定のサポートを開始 – スナップショット復元操作の実行前と実行中にバックアップ保持期間と希望するバックアップウィンドウを表示し、変更できるようになりました。これまで、復元されたデータベースインスタンスとクラスターはスナップショットメタデータからのバックアップパラメータ値を継承し、変更できるのは復元完了後のみでした。これからは、自動バックアップとスナップショットの一部としてバックアップ設定を表示し、復元時にこれらの値を指定または変更できるようになるため、復元後に変更する必要がなくなります。この機能は、すべての AWS 商用リージョンと AWS GovCloud (米国) リージョンにあるすべての Amazon RDS データベースエンジン (MySQL、PostgreSQL、MariaDB、Oracle、SQL Server、Db2) と Amazon Aurora (MySQL 互換および PostgreSQL 互換エディション) で利用でき、追加料金はかかりません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – 2026 年の AWS Summit に参加しましょう。AWS Summit は、クラウドおよび AI 関連の新興テクノロジーを探求し、ベストプラクティスについて学び、業界の同業者や専門家とつながることができる無料の対面イベントです。Summit は、 パリ (4 月 1 日)、 ロンドン (4 月 22 日)、 バンガロール (4 月 23〜24 日) で開催される予定です。 AWS AI and Data Conference 2026 – 3 月 12 日にアイルランドの Lyrath Convention Centre で開催される、1 日限りの無料対面イベントです。このカンファレンスでは、Amazon Bedrock、Amazon SageMaker、QuickSight を用いたエージェントの設計、トレーニング、およびデプロイの他、エージェントの AWS データサービスとの統合、エージェントを大規模に運用するためのガバナンスプラクティスの適用といったトピックを取り上げます。アジェンダには、アーキテクト、開発者、ビジネスリーダー向けの戦略的ガイダンスとハンズオンラボが含まれています。 AWS Community Day – コミュニティリーダーたちがコンテンツを計画、調達、提供するコミュニティ主導のカンファレンスであり、テクニカルディスカッション、ワークショップ、ハンズオンラボが行われます。このイベントは、 アーメダバード (2 月 28 日)、 スロバキア (3 月 11 日)、 プネー (3 月 21 日) で開催される予定です。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。こちらのリンクから、今後開催されるすべての AWS 主導の対面イベントおよび仮想イベント と デベロッパー向けのイベント をご覧ください。 2026 年 2 月 16 日週のニュースは以上です。2026 年 2 月 23 日週の Weekly Roundup もお楽しみに! – Esra この記事は、Weekly Roundup シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

こんにちは。SCSKの池田です。 2025年11月12日にLifeKeeperが10年ぶりのメジャーバージョンアップを果たしました。これまでOS毎に異なっていたライセンス体系やサポート期間の考え方が統一されるなど、「全てをシンプルに、より分かりやすく、より使いやすく」をコンセプトに改変が行われました。 具体的な内容は以前の記事をご確認ください。 LifeKeeper v10リリース記念　これまでと何が変ったか！？ 今回は、LifeKeeper v10のライセンスについて解説したいと思います。 LifeKeeper for Windows版のライセンス体系 まず、LifeKeeper for Windowsの旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。 ※LifeKeeper for Windowsのライセンス体系の一部となります 上の図のように、「LifeKeeper for Windows」には、v8の時と同様にLifeKeeper Coreと呼ばれるLifeKeeper本体とIIS ARK(Internet Information Services)、そしてRecovery Kit for PostgreSQLが含まれますが、さらに、ここに以下のデータベース用Recovery KitがLifeKeeper本体に含まれるようになっている点が大きな変更点となります。 ◆LifeKeeper本体に含まれるようになったRecovery Kit ・Recovery Kit for SQL Server ・Recovery Kit for Oracle Database またv8の時は、JP1/AJS Manager、Agent、HULFTとミドルウェアごとにARKが用意されていましたが、v10では 「Recovery Kit for Enterprise Application」に集約されている点も大きな変更点になります。 データベース用のARKが本体に統合されて、 その他のミドルウェアがRecovery Kit for Enterprise Applicationに集約されたのね LifeKeeper for Linux版のライセンス体系 今度は、LifeKeeper for Linuxの旧バージョンと新バージョンのライセンス体系の変更点についてみていきたいと思います。   Windows版よりも、新旧の関係が若干複雑になっていますね。 「LifeKeeper for Linux」には、v9の時と同様にLifeKeeper Coreと呼ばれるLifeKeeper本体とRecovery Kit for LVMが含まれますが、さらにこれまで単体のARKとして提供されていたRecovery Kit for Apacheが含まれるようになっている点が大きな変更点となります。 またv9の時は、JP1/AJS Manager、Agent、HULFT、IBM WebSphere MQはミドルウェアごとにARKが用意されていましたが、v10では 「Recovery Kit for Enterprise Application」に集約されています。 これまで物理サーバ構成で頻繁に使われてきたDMMPなどのマルチパス用ARKは パブリッククラウドでは使わないから、Recovery Kit for Basicとして別れたんだね   まとめ このように「v10はライセンスが統一された」といっても、OSごとのこれまでの利便性を追求しつつ、ライセンス体系が見直されています。 ライセンス購入時は、できるだけサイオステクノロジー社から認定されたSI&サポートパートナーに確認をしたり、サイオステクノロジー社の公式ページを確認しながら必要なライセンスを選択するように注意が必要です。 サイオステクノロジー認定のSI&Supportパートナー （サイオステクノロジー公式サイト） Lifekeeperの製品体系 （サイオステクノロジー公式サイト） 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

本記事は 2026/02/04に投稿された Auto Analyze in Aurora DSQL: Managed optimizer statistics in a multi-Region database を翻訳した記事です。 Amazon Aurora DSQL  および他の最新のリレーショナルデータベースシステムにおいて、正確な統計情報はクエリプランにおける最も重要な要因の一つです。悪いクエリプランを良いクエリプランの代わりに誤って選択してしまうと、100倍の性能低下を引き起こす可能性があります。プランのリグレッションが発生するリスクを最小化するために、最新の統計情報が重要です。この投稿では、DSQL オプティマイザー統計を自動的に計算する確率的かつ事実上ステートレスな手法である Aurora DSQL Auto Analyze について解説します。PostgreSQL に精通しているユーザーは、 autovacuum analyze  との類似性を理解していただけるでしょう。 クエリパフォーマンスにおける統計情報の重要性 統計情報がクエリパフォーマンスに与える影響を説明するために、オプティマイザーがフルテーブルスキャンまたはインデックススキャンを使用してデータにアクセスするかを選択できる基本的な例を見てみましょう。統計情報の効果を説明するために、内部パラメータを使用してAuto Analyzeを無効にしました。お客様にとって、Auto Analyze は常に有効になっており、無効にするオプションはありません。 まず、int 型の列 A とtext 型の列 B を持つテーブルを生成します。また、列 A にインデックスを作成します。次に、このテーブルに 600,000 行を挿入します。この例では、列 A に注目します。300,000 行は 0 から 299,999 までの A 値を含みます。残りの 300,000 行は A 値が 42 です。 create table mytable (A int, B text); create index async mytableidx on mytable(A); SELECT 'INSERT INTO mytable SELECT generate_series(3000 * ' || i-1 || ', 3000 * ' || i || ' - 1), ''AWS Aurora DSQL is great'';' FROM generate_series(1, 100) i; \gexec SELECT 'INSERT INTO mytable SELECT 42, ''AWS Aurora DSQL is great'' FROM generate_series(1, 3000);' FROM generate_series(1, 100); \gexec 以下のクエリを使用して、 A 値が 42 の行が 300,001 行あることを確認します。したがって、 A 値が 42 の行は全体の半分以上を占めています。 SELECT count(*) FROM mytable GROUP BY GROUPING SETS (A = 42); count -------- 299999 300001 (2 rows) 以下のコマンドを実行して、 A 値が 42 の全ての行を選択する場合に、オプティマイザーがどのプランを選択するかを観察してみましょう。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------ Index Scan using mytableidx on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual time=15.926..5217.368 rows=300001 loops=1) Index Cond: (a = 42) -> Storage Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) -> B-Tree Scan on mytableidx (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Index Cond: (a = 42) -> Storage Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Projections: a, b -> B-Tree Lookup on mytable (cost=23193.32..34868.97 rows=92373 width=32) (actual rows=300001 loops=1) Planning Time: 3.367 ms Execution Time: 5228.314 ms (10 rows) 選択されたプランにはインデックススキャンが含まれていることがわかります。 A = 42 が半数を占めることから、明らかにインデックスからの間接参照のコストを避けて、フルテーブルスキャンを選択することが期待されます。 オプティマイザーが最適なプランを見つけるのを助けるために、テーブルで ANALYZE を実行します。 ANALYZE mytable; 今度は選択されたプランにフルテーブルスキャンが含まれています。クエリは半分以下の時間で完了するようになりました。 EXPLAIN ANALYZE SELECT * FROM mytable WHERE A = 42; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------- Full Scan (btree-table) on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual time=1.179..1977.851 rows=300001 loops=1) -> Storage Scan on mytable (cost=74756.80..87915.45 rows=296975 width=32) (actual rows=300001 loops=1) Projections: a, b Filters: (a = 42) Rows Filtered: 299999 -> B-Tree Scan on mytable (cost=74756.80..87915.45 rows=597254 width=32) (actual rows=600000 loops=1) Planning Time: 5.055 ms Execution Time: 1989.230 ms (8 rows) Aurora DSQL クラスターでこの例を再現すると、手動で analyze を実行する前でも、フルテーブルスキャンを使用する高速なクエリプランが得られることがわかります。Auto Analyze がバックグラウンドで自動的に統計情報を計算し、このパフォーマンス向上を提供してくれます。 Aurora DSQL における Auto Analyze このセクションでは、まず PostgreSQL の autovacuuming について再確認します。次に、Aurora DSQL が マルチAWSリージョン 環境において、事実上無制限のスケールで2つの構成要素を通じて PostgreSQL の動作を模倣する方法を説明します。 PostgreSQL では、 ANALYZE は autovacuum デーモン ( AUTOVACUUM ) を通じて自動的にトリガーされます。これはテーブルの変更を継続的に監視し、事前定義された閾値に達した時（通常はテーブルの行の 10% が挿入、更新、または削除された後）に統計情報を更新します。詳細については、 autovacuumデーモン のPostgreSQL ドキュメントを参照してください。 Aurora DSQL において、Auto Analyze 機能は PostgreSQL の autovacuum による ANALYZE 処理プロセスに相当し、クエリプランニングに不可欠なテーブル統計情報を自動的に維持します。PostgreSQL の決定論的な閾値ベースのアプローチとは異なり、DSQL は 2 つの主要な構成要素に基づいたマルチリージョン対応のソリューションを実装しています： 確率的トリガー がトリガーメカニズムとして機能します。テーブルの変更を監視・追跡する代わりに、各トランザクションは、テーブルサイズに対して変更する行数に基づいて ANALYZE をトリガーする確率を計算します。この確率的アプローチにより、セッション間の調整の必要性がなくなり、テーブルの進化に応じて統計情報が更新されることを保証します。 サンプリングベースの analyze 手法 が実際の統計計算を処理します。トリガーされると、ANALYZE はサンプリング技術を使用して、大規模なマルチテラバイトテーブルであっても効率的に正確な統計情報を計算し、Aurora DSQL が事実上無制限のテーブルサイズにスケールできるようにします。 確率的トリガー Aurora DSQL は、テーブル統計情報をいつ更新するかを決定するために、Auto Analyze の確率的トリガーを使用します。コミットする各トランザクションは、テーブルサイズと挿入、更新、削除操作を通じて行う変更数に依存する ANALYZE をトリガーする確率を持ちます。 ANALYZE のトリガーはトランザクションのパフォーマンスに大きな影響を与えないことに注意してください。このセクションでは、トランザクションの ANALYZE 確率がどのように決定されるかを説明します。 Aurora DSQL は各トランザクション内でテーブルごとの変更を追跡します。トランザクションがコミットされると、変更された各テーブルが 10% の閾値比に対して評価されます。トランザクションがテーブルの行の 10% 以上を変更する場合、 ANALYZE は常にトリガーされます。より小さな変更の場合、 ANALYZE をトリガーする確率は変更された行の割合に比例します。 Let threshold_ratio = 0.1 for each modified table R: change_count = num_inserts + num_updates + num_deletes threshold_count = threshold_ratio * pg_class.reltuples(R) probability = change_count / threshold_count if random_number(0,1) <= probability: submit_job("ANALYZE R") この説明は現在、100万行以上のテーブルについてのみ正確です。より小さなテーブルについては、Aurora DSQLの別のクエリプロセッサで実行される ANALYZE のセットアップコストを考慮した減衰係数があります。 この確率的アプローチは、データベースセッション間の調整を必要とせずに、平均してテーブルの 10% が変更された後に ANALYZE をトリガーします。システムは、確率を計算するために pg_class.reltuples (以前の ANALYZE 実行によって設定される) からの行数推定値を使用し、分析されていないテーブルについてはデフォルトで1行とします。 確率的メカニズムはワークロードパターンに自然に適応します。頻繁に変更されるテーブルでは、統計情報がより頻繁に更新されます。逆に、静的なテーブルでは不要な ANALYZE オーバーヘッドを回避します。 サンプリングベースの ANALYZE Aurora DSQL が ANALYZE 操作をトリガーすると、テーブル全体をスキャンすることなく効率的に正確な統計情報を計算するためにサンプリングを使用します。システムは最低30,000行のサンプルを収集するように設計されたサンプリング率を計算し、大きなテーブルではさらに多くの行を収集します。このサンプルは pg_class のテーブル全体の統計情報を計算するために使用されます。その後、PostgreSQLと同様に、厳密な30,000行のサブセットが列固有の統計情報を生成するために使用されます。 私たちの手法は、計算された確率に基づいてストレージから行をランダムに選択することで機能します。このアプローチは PostgreSQL のサンプリング手法を反映しながら、Aurora DSQL の分散アーキテクチャに適応しています。サンプリング率は、以前の統計情報から推定されるテーブルサイズに対する目標行数によって決定されます。 前述したように、収集されたサンプルは2種類の統計情報を生成します： pg_class に格納されるテーブル全体の統計情報と、pg_stats の列固有の統計情報です。テーブル全体の推定値は行数とページ数の推定値です。 pg_stats の列固有の統計情報には、null値の割合、個別値の比率、ヒストグラム、最頻値が含まれます。これらの統計情報は、効率的な実行プランを生成するために必要な情報をクエリオプティマイザーに提供します。 Aurora DSQLが使用するサンプリングベースの Analyze 手法は、テーブルの成長に関係なく一貫したサンプルサイズを提供することで、マルチテラバイトのテーブルであっても効率的な計算を保証します。実験では、最大240TBまでのあらゆるサイズのテーブルで ANALYZE が数分で完了することがわかりました。 まとめ この投稿では、Aurora DSQL の Auto Analyze 機能について学びました。Auto Analyze は、分散マルチリージョンデータベースシステム特有の課題に対処しながら、PostgreSQL の autovacuum による ANALYZE の信頼性を提供します。確率的トリガーと効率的なサンプリングベースの計算を組み合わせることで、手動介入なしにクエリが適切に維持された統計情報から一貫して恩恵を受けることができます。確率的アプローチは、従来の閾値ベースのシステムが必要とする調整オーバーヘッドの多くを排除し、分散アーキテクチャに自然に適しています。一方、サンプリングベースの分析は、小さなテーブルから大規模な 240TB のデータセットまでスケールします。Aurora DSQL Auto Analyze は、バックグラウンドで透過的に動作しながら、適切に維持されたオプティマイザー統計情報の利点を提供し、開発者がテーブル統計の管理ではなくアプリケーションの構築に集中できるようにします。 Aurora DSQL Auto Analyze は、 Aurora DSQLが利用可能なすべてのリージョン で利用できます。Aurora DSQL の詳細については、 ウェブページ と ドキュメント をご覧ください。 Magnus Mueller Magnus  は AWS の応用科学者で、カーディナリティ推定、クエリ最適化、システム向け機械学習を専門としています。カーディナリティ推定の博士号を取得し、主要なデータベース会議で研究を発表しています。 James Morle James  はプリンシパルエンジニア兼分散データベースアーキテクトで、ハイパースケールでの大規模トランザクショナル・分析システムの設計・実装において 20 年以上の経験を持ちます。 Matthys Strydom Matthys  は AWS のプリンシパルエンジニアで、分散データベースクエリ処理、AWS クラウドサービスコントロールプレーン、高スループット電話網統合、デスクトップCADプログラムなど、幅広いソフトウェアシステムにおいて 20 年以上の経験を持ちます。 Vishwas Karthiveerya Vishwas  は AWS のシニアソフトウェア開発・データベースシステムエンジニアで、大規模分散データベースのクエリプランニング、コストベース最適化、実行性能を専門としています。 Raluca Constantin Raluca  は AWSのシニアデータベースエンジニアで、Amazon Aurora DSQL を専門としています。Oracle、MySQL、PostgreSQL およびクラウドネイティブソリューションにわたる 18年のデータベース専門知識を持ち、データベースのスケーラビリティ、性能、リアルタイムデータ処理に焦点を当てています。 翻訳はソリューションアーキテクトの伊津野安梨沙が担当しました。原文は こちら です。