投稿

GPUワークロード向けのOKEとSlurmの比較: OCIでの適切なデプロイメント・モデルの選択 (2026/08/14)

イメージ
GPUワークロード向けのOKEとSlurmの比較: OCIでの適切なデプロイメント・モデルの選択 (2026/08/14) https://blogs.oracle.com/cloud-infrastructure/oke_slurm_gpu_workloads_choose_right_deployment 投稿者： Diego Abelar Morales   Thiago Pereira  |  Manager, Cloud Engineering (Noth America & LATAM OCI GPU Infrastructure) はじめに GPUワークロードは、現代のAI、機械学習、および高性能コンピューティング環境において中心的な役割を担うようになっています。チームがトレーニング、推論、シミュレーション、および共有GPUプラットフォームを拡張するにつれて、オーケストレーションレイヤーは重要な設計上の決定事項となります。 Oracle Cloud Infrastructureでは、組織はしばしば次の2つのアプローチを検討します。 Oracle Kubernetes Engine (OKE) は、KubernetesネイティブのAIプラットフォームおよびアプリケーション中心のGPUワークロード向けです。 Slurmは 、HPCスタイルのスケジューリング、バッチジョブ、共有キュー、および研究主導型のGPUクラスタのためのソフトウェアです。 なぜこのトピックが重要なのか GPUインフラストラクチャは高価で、利用頻度が高く、複数のチームで共有されることが多い。適切なオーケストレーションモデルを選択することで、以下の点に影響が生じる。 GPU利用率とプラットフォームのスケーラビリティ  開発者および研究者の生産性  運用上の複雑性  ジョブのスケジュール設定と優先順位付け  既存のクラウドサービスとの統合  実稼働AIワークロードのサポート  この決定は、コンテナの実行やジョブの投入といったことだけにとどまりません。組織のAIおよびHPC戦略を最も効果的にサポートする運用モデルを選択することなのです。 OKEの概要 Oracle Kubernetes Engin...
コメントを投稿
続きを読む

OCI Device Data FHIRサービスの概要 (2026/08/14)

イメージ
OCI Device Data FHIRサービスの概要 (2026/08/14) https://blogs.oracle.com/cloud-infrastructure/introducing-oci-device-data-fhir-service 投稿者： Jason Savage  | Lead Architect 接続機器向け標準規格準拠のヘルスケアアプリケーションを構築する 医療機器メーカーやデジタルヘルス開発者は、医療機器、遠隔モニタリングシステム、コンパニオンアプリケーションなどを含む、コネクテッドデバイスのエコシステムを拡大しています。しかし、これらの多様なソースからのデータを相互運用可能な医療情報に変換するには、チームが独自の統合レイヤー、FHIR（Fast Healthcare Interoperability Resources）サーバー、およびサポートインフラストラクチャを構築・維持する必要があり、その後で初めて、差別化されたデバイスやソフトウェア体験の提供に集中できるようになります。 本日、Oracle Cloud Infrastructure (OCI) Device Data FHIR Serviceを発表いたします。これは、バージョン管理されたFHIR R4およびFHIR R6 REST APIを使用して、接続された医療機器やAI対応のヘルスケアワークフロー向けの標準ベースのアプリケーションを開発者が構築できるよう支援する、フルマネージドのFHIRサービスです。OCIとOracle Autonomous AI Database上に構築されたこのサービスは、サポートされているヘルスケアリソースの保存、検索、管理のためのマネージド基盤を提供すると同時に、OCIのセキュリティ、ネットワーク、監視、運用サービスと統合します。 遠隔患者モニタリングソリューション、デバイス接続プラットフォーム、医療機器ゲートウェイ、デジタルヘルスアプリケーションなど、どのようなソリューションを開発する場合でも、OCI Device Data FHIR Serviceはインフラストラクチャ管理にかかる時間を短縮し、コネクテッドヘルスケアソリューションの構築に集中できるよう支援します。 医療機器の相互運用性を簡素化する コネクテッドデバイスのエコシステム...
コメントを投稿
続きを読む

OCI Internet of Thingsプラットフォームでのデジタル・ツイン・アダプタの操作 (2026/08/13)

イメージ
OCI Internet of Thingsプラットフォームでのデジタル・ツイン・アダプタの操作 (2026/08/13) https://blogs.oracle.com/cloud-infrastructure/working-with-iot-digital-twin-adapters 投稿者： Pete St. Pierre  | Director, Product Management デジタルツインアプリケーションでは、各アセットの一貫したビューが必要ですが、デバイスのテレメトリデータはさまざまな形式で届くことがよくあります。あるデバイスは motorTemperature という名前の属性を送信し、別のデバイスは mtrTempを 送信するかもしれません。また、別のデバイスはpsi単位で圧力値を報告する一方で、モデルは圧力をbar単位で保存しているかもしれません。OCI IoT Platform (OCI IoT Platform) のデジタルツインアダプタは、これらのデバイス固有のペイロードを、アプリケーションが使用する標準的なモデル構造に変換します。 WaterPump モデルを使用して 、アダプタがタイムスタンプ、ネストされたコンポーネント、属性名、単位変換、エンドポイントベースのルーティング、および選択されたJQ式をどのように処理して、異種テレメトリストリームを標準モデルにマッピングするかを示します。 はじめに デジタルツインアダプタは、直接接続されたデバイスと間接接続されたデバイスの両方に適用されます。どちらの場合も、アダプタは受信したペイロードをデジタルツインモデルにマッピングし、アプリケーションが一貫性のある資産表現を読み取れるようにします。 これらの例は、デバイステレメトリにおけるアダプタの動作に焦点を当てています。ゲートウェイ構成、ゲートウェイルーティング、およびゲートウェイテレメトリ設定は、これらの例の範囲外です。 例：ウォーターポンプモデル この例では、 ポンプレベルのテレメトリと再利用可能な ElectricMotor コンポーネントを備えた WaterPumpモデルを使用します 。WaterPumpモデルは、関連記事 「OCI IoTプラットフォームにおけるデジタルツインモデルの理解」 で説明されている形式に従います ...
コメントを投稿
続きを読む