投稿

Oracle Cloud Infrastructure(OCI)HPCスタック – リリース(3.0.0) (2026/04/10)

イメージ
Oracle Cloud Infrastructure(OCI)HPCスタック – リリース(3.0.0) (2026/04/10) https://blogs.oracle.com/cloud-infrastructure/oci-infrastructure-oci-hpc-stack-release-3 投稿者： Irshad Buchh | AI/ML Solutions Engineer Arnaud Froidmont | HPC Solution Architect Mac Stephen | Principal Cloud Engineer | HPC/AI/ML はじめに Oracle Cloud Infrastructure (OCI) は、過去数年間にわたり高性能コンピューティングに多大な投資を行ってきました。OCI HPC スタックは、5年以上前に誕生して以来、大きく成熟してきました。リリースごとに、スタックはますます複雑なワークロードとデプロイメントパターンをサポートするように進化してきました。このブログでは、HPC/GPU クラスタのデプロイメント、構成、ライフサイクル管理を簡素化する新しいパラダイムをもたらすメジャーアップデートである OCI HPC Cluster Stack 3.0.0 を紹介します。リリース 3.0.0 では、新しい自動化、アーキテクチャの改善、よりモジュール化された設計が組み込まれており、大規模クラスタの運用がこれまで以上に容易になります。 大規模なAIトレーニングおよび推論ワークロードが拡大し続けるにつれ、顧客はRDMA対応ネットワークによって実現される高速かつ低遅延のノード間通信を備えた、緊密に連携したGPUクラスタを必要としています。OCIのHPCクラスタスタックは、OCI HPCチームが設計および検証したTerraformおよびAnsibleアーティファクトを使用して、このようなクラスタを効率的にデプロイするための手段を提供します。 単一のデプロイメントで、スタックは以下を含む完全なクラウドネイティブHPC/GPU環境をプロビジョニングします。 パブリックサブネット、プライベートサブネット、クラスタネットワーク、および制御された安全なアクセスを確保するために必要なすべてのゲートウェイ（IGW、NAT...
コメントを投稿
続きを読む

Autonomous AI Database Serverlessでのデータ損失ゼロ保護の発表 (2026/04/09)

イメージ
Autonomous AI Database Serverlessでのデータ損失ゼロ保護の発表 (2026/04/09) https://blogs.oracle.com/autonomous-ai-database/announcing-zero-data-loss-protection-on-autonomous-ai-database 投稿者： Nilay Panchal  | Principal Product Manager 顧客にとって、システムの回復力は単なる技術的な議論ではなく、ビジネス上の要件です。 システム障害が発生した場合、コミット済みのトランザクションのデータは失われるのか？どの程度復旧できるのか？ 「ほぼすべて」では決して十分ではありません。 Autonomous AI Database Serverless では 、追加の労力、コスト、パフォーマンスへの影響なしに、ローカルの Autonomous Data Guard スタンバイを有効にすることで、 データ損失ゼロの保護が実現します。つまり、リカバリポイント目標 (RPO) = 0 となります 。これは、データベースで既にローカルの Autonomous Data Guard スタンバイを使用している場合、ユーザーによる操作は不要で、データベースが保護されることを意味します。 サーバーレスにおいてこれが今魅力的な理由：運用上の負担なしに保護を実現できる RPO = 0 を実現するには、高帯域幅ネットワーク、同期リドゥとバックアップ、低遅延フラッシュストレージ、高スループットディスクストレージ、対称的に高性能なリソース、理解して有効化するためのパラメータとオプションなど、高可用性に関する数々のベストプラクティスが必要です。Autonomous AI Database は、これらの複雑さをすべて抽象化し、ローカルスタンバイによるゼロデータ損失保護を提供します。ローカルスタンバイは、従来どおり、ボタンをクリックするだけ（または API 呼び出し）で有効化できます。 基盤となるインフラストラクチャ構成に加えて、ローカルのAutonomous Data Guardスタンバイは、 同期リドゥ 構成を使用してデータ損失ゼロを実現できます。 アプリケーションがプライマリに対してコミットを発行する...
コメントを投稿
続きを読む

KarpenterプロバイダーによるOCI上のよりスマートなKubernetes自動スケーリングがGAに (2026/04/09)

イメージ
KarpenterプロバイダーによるOCI上のよりスマートなKubernetes自動スケーリングがGAに (2026/04/09) https://blogs.oracle.com/cloud-infrastructure/smarter-kubernetes-autoscaling-with-karpenter 投稿者： Kay Singh  | Principal Product Manager 本日、OCI 向け Karpenter Provider の一般提供開始と、GitHub でのオープンソース版の公開を発表いたします。OCI Kubernetes Engine OKE でワークロードを実行している場合、このリリースにより、事前に固定形状の管理対象ノードプールを定義することなく、より高速で柔軟かつ管理しやすいオートスケーリングが可能になります。 課題 Kubernetesの現在のノードレベルのオートスケーリングモデル（つまり、クラスタオートスケーラー）は、単一のコンピューティングシェイプを使用するマネージドノードプールを中心に構築されています。これは機能しますが、本番ワークロードを実行する顧客にとって、実際的な制約も生み出します。 チームがワークロードごとに異なる構成を必要とする場合、多数のノードプールを作成および管理する必要があります。優先する構成の容量が不足すると、別の有効な構成が利用可能であっても、スケーリングが停止する可能性があります。これを回避するため、チームは事前に予備のプールを作成し、実際に必要な容量よりも多くの容量を確保します。しかし、これは長期的にはコストと運用作業の増加につながります。 顧客は、プラットフォームチームがすべてのノードプール、構成、フォールバックパスを事前に計画する必要なく、アプリケーションの需要に応じて自動的にスケーリングする機能を求めている。 ソリューション OCI 用 Karpenter Provider は、Karpenter の柔軟なオートスケーリング モデルを OKE にもたらします。 Karpenterは、事前に定義されたノードプールをスケーリングするのではなく、スケジュールされていないPodを監視し、ワークロード要件と管理者が許可するOCI容量オプションに基づいて、適切なコンピューティング構成をリ...
コメントを投稿
続きを読む