ドキュメントCommerceCommerce on Cloud

サービスの設定

最終更新日： 2026年9月1日

作成対象：

  • 管理
  • 開発者

services.yaml ファイルは、MySQL、RedisまたはValkey、ElasticsearchまたはOpenSearchなど、Adobe Commerceがクラウドインフラストラクチャ上でサポートおよび使用するサービスを定義します。 外部サービスプロバイダーに加入する必要はありません。

NOTE
.magento/services.yaml ファイルは、プロジェクトの.magento ディレクトリ内でローカルに管理されます。 デプロイメント時に、Adobe Commerce オンクラウドインフラストラクチャは、この設定を使用して、ターゲット環境でサポートされているサービスをプロビジョニングします。 .magento ディレクトリはデプロイ後にリモート サーバーから削除されるので、services.yamlはデプロイされた環境には存在しません。

デプロイ スクリプトは、.magento ディレクトリの設定ファイルを使用して、設定されたサービスを使用して環境をプロビジョニングします。 サービスは、.magento.app.yaml ファイルのrelationships プロパティに含まれている場合、アプリケーションで利用できるようになります。 services.yaml ファイルには、type​と​ disk ​の値が含まれています。 サービスの種類は、サービス name​および​ version ​を定義します。

.magento/services.yamlのサービス設定は、composer.jsonで定義され、composer.lockでロックされているPHPおよびComposer パッケージの依存関係とは別になっています。

サービスの変更が適用される場所

サービス設定を変更すると、更新されたサービスを使用して環境をプロビジョニングするデプロイメントが発生します。これは、次の環境に影響します。

  • 実稼動環境masterを含むすべてのスターター環境
  • Pro統合環境

プロサービスのサポート

ステージングまたは実稼動環境でPro サービスのアップグレードをリクエストして完了するには、次の手順に従います。

  1. 環境StagingおよびProduction環境のみ​で​ サービス ​をインストールまたは更新するには、Adobe Commerce サポートチケット ​を送信します。

    チケットで、必要なサービス変更を指定し、更新された.magento.app.yamlおよび.magento/services.yaml ファイルを含め、対象のPHP バージョンをメモします。

    PHPのバージョン、Composerのアップデート、拡張機能、環境設定は、セルフサービスの変更です。 Adobeでは、PHPのバージョンに対応するようにNew Relic agentをアップデートする必要がある場合があります。 アプリケーション設定​のPHP設定を参照してください。

    note important
    IMPORTANT
    チケットフォームで「Environment」フィールドを選択する場合は、Adobeの環境命名を使用します。 例えば、その環境​ Dev ​を内部的に呼び出す場合でも、「ステージング」を選択します。 説明に内部名を記載できますが、Environment フィールドにはAdobeの命名規則を使用する必要があります。

  2. Adobeの2部構成のプロセスを通じてアップグレードスケジュール​を確認します。最初にリクエストされた日時を確認してから、サポートがインフラストラクチャチームに最終確認のために送信します。

    プロダクションの変更（Proのみ）には、週末を除く少なくとも2営業日前の通知が必要です。 例えば、クラウドインフラチームは、水曜日までに月曜日のアップグレードを承認する必要があります。 ピーク時の需要に対応し、リードタイムを向上できます。 遅延を回避するには、最初のリクエストに対して、少なくとも48時間前に応答する必要があります。 アップグレードは、最終確認を受け取るまでスケジュールされたとは見なされません。

    note
    NOTE
    UTCでメンテナンスウィンドウを提供します。 ステージングのアップグレードは事前にスケジュールされておらず、通常はリクエストと同じ日に完了します。
    RabbitMQのアップグレード後、環境を再デプロイしてメッセージキューを再初期化します。

  3. 実稼動環境でアップグレードをスケジュールする前に、ステージング環境または統合環境で​アップグレードを検証します。

    サードパーティモジュール、カスタムコード、依存関係の互換性による問題は、サービスのアップグレードに続く再展開中に頻繁に発生します。 複数のサービスのアップグレードを一度に1つずつ検証するには、ValkeyまたはRedis、RabbitMQ、OpenSearch、MariaDBを順番に順番に実行します。 これは必要な順序ではありません。 データベースのアップグレードは、最も高い運用上の影響を及ぼし、最も注意を払う必要があります。

    Adobeでは、タイミングは環境と関連するサービスによって異なるため、実稼動メンテナンスウィンドウの正確な期間を事前に保証しません。 実稼動ウィンドウを計画する際に、ステージングのアップグレードにかかる時間を実用的な見積もりとして使用します。

  4. Adobe Commerce アプリケーションのバージョンが変更されない場合でも、Adobeがサービスのアップグレードを完了した後に環境​を再デプロイします。

    アップグレードにOpenSearchが含まれる場合は、完全なインデックス再作成も計画します。 Adobeでは、サービスのアップグレードに対してダウンタイムがゼロになることを保証できないため、再デプロイし、必要に応じてインデックスを再作成し、ストアフロントと管理者がサイトを再開する前に検証できるようにするメンテナンスウィンドウを計画します。

アップグレード中の顧客の可用性

スケジュールされた実稼動アップグレード ウィンドウの期間中、チームまたは実装パートナーの担当者がオンラインで利用できる必要があります。 トラフィックが少ない期間にスケジュールを設定しても、アップグレードのハンドオフにはなりません。 Adobeは、クラウドインフラストラクチャのアップグレードを管理しますが、アプリケーションの動作、統合、カスタムコード、ビジネスワークフローを検証することはできません。

使用可能な担当者は、次の操作を行う必要があります。

  • アップグレード中およびアップグレード後のストアフロントと重要なビジネス トランザクションを監視​します。
  • Adobe サポートまたはCloud Infrastructure チームからの質問に​回回答します。
  • 統合、拡張機能、カスタマイズ、cron ジョブ、キュー、およびその他の顧客固有の機能が期待どおりに機能していることを確認してください。
  • チェックアウト、カタログビュー、検索、ログイン、注文処理など、 ビジネスに不可欠なワークフローを検証します。
  • アップグレードのコンテキストとログは引き続き利用可能ですが、レポート​の予期しない動作が速やかに発生しました。
TIP
Pro プロジェクトの場合、本番環境でのサービスのアップグレードには、事前のスケジュール設定と、Adobeサポートによる2部構成の確認プロセスも必要です。 Pro サービスのサポート ​を参照してください。

メンテナンスモード

メンテナンスモードは、お客様の可用性の代わりにはなりません。 メンテナンスモードは、ストアフロントへのアクセスをブロックしますが、アプリケーションサービス、統合、キュー、cron ジョブ、チェックアウトなどの顧客固有の機能は検証しません。

計画作業にメンテナンスモードが必要な場合は、Adobe サポートと連携して使用し、そのアップグレードの手順に従います。 その後、作業の完了を検討する前に、ストアフロントとクリティカルワークフローが正常に動作していることを確認します。

デフォルトサービスとサポート対象サービス

Adobe Commerce on cloud infrastructureでは、プロジェクトに設定できる次のサービスがサポートされています。

NOTE
使用可能なバージョン間でRabbitMQを順次アップグレード ​。 例えば、3.9から4.1に直接アップグレードしないでください。
新しいバージョンにアップグレードした後、カスタムメッセージキューがRabbitMQで再作成されるようにするには、完全なデプロイメントをトリガーします。

設定済みのサービスとバージョンの表示

現在のテンプレート services.yaml ファイル ​のサービス定義とディスク値の例を表示できます。 実際のデフォルトバージョンとサポートされているサービスバージョンは、Adobe Commerceのバージョンと現在のクラウドテンプレートによって異なります。

次の例は、services.yaml設定ファイルのサービス定義を示しています。

mysql:
    type: mysql:11.8
    disk: 5120

cache:
    type: valkey:9.0

opensearch:
    type: opensearch:3  # minor version not required; uses latest
    disk: 1024

rabbitmq:
    type: rabbitmq:4.3
    disk: 1024

activemq-artemis:
    type: activemq-artemis:2.42
    disk: 1024

サービス値

サービス IDとサービス タイプ設定type: <name>:<version>を指定してください。 サービスで永続ストレージを使用する場合は、ディスク値を指定する必要があります。

次の形式を使用します。

<service-id>:
    type: <name>:<version>
    disk: <value-MB>

service-id

service-id値は、プロジェクト内のサービスを識別します。 小文字の英数字のみを使用できます：a ～ z、および0 ～ 9 （例：valkey）。

この​ service-id ​値は、.magento.app.yaml設定ファイルのrelationships プロパティで使用されます。

relationships:
    valkey: "valkey:valkey"

各サービスタイプの複数のインスタンスに名前を付けることができます。 例えば、複数のValkey インスタンスを使用できます。1つはセッション用、1つはキャッシュ用です。

valkey:
    type: valkey:<version>

valkey2:
    type: valkey:<version>

services.yaml ファイル内のサービスの名前を変更します。

  • 指定した新しい名前のサービスを作成する前の既存のサービス。
  • サービスの既存のデータはすべて削除されます。 Adobeでは、既存のサービスの名前を変更する前に、Starter環境をバックアップすることをお勧めします。

type

type値は、サービス名とバージョンを指定します。 例：

mysql:
    type: mysql:10.4

disk

disk値は、サービスに割り当てる永続的なディスク ストレージのサイズ （MB）を指定します。 MySQLなどの永続ストレージを使用するサービスでは、ディスク値を提供する必要があります。 Valkeyなどの永続ストレージの代わりにメモリを使用するサービスでは、ディスク値は必要ありません。

mysql:
    type: mysql:10.4
    disk: 5120

プロジェクトごとの現在のデフォルトのストレージ容量は5 GB、つまり5120 MBです。 この金額は、アプリケーションとその各サービスの間で配布できます。

サービスとの関係

クラウドインフラストラクチャプロジェクト上のAdobe Commerceで、.magento.app.yaml ファイルで設定されたサービス relationshipsによって、アプリケーションで使用できるサービスが決まります。

すべてのサービス関係の設定データは、$MAGENTO_CLOUD_RELATIONSHIPS環境変数から取得できます。 設定データには、サービス名、タイプ、バージョンと、ポート番号やログイン資格情報などの必要な接続の詳細が含まれます。

ローカル開発環境からの関係を確認する

  1. ローカル開発環境から、アクティブな環境のリレーションシップを表示します。

    code language-bash 
    magento-cloud relationships

  2. 応答からserviceとtypeを確認してください。 応答は、IP アドレスやポート番号などの接続情報を提供します。

    簡略化されたサンプル応答

    code language-yaml 
    valkey:
    -
...
        type: 'valkey:8.0'
        port: 6379
opensearch:
    -
...
        type: 'opensearch:3'
        port: 9200
database:
    -
...
        type: 'mysql:11.8'
        port: 3306

リモート環境での関係の確認

  1. SSHを使用してリモート環境にログインします。

  2. 環境内で設定されたすべてのサービスの関係設定データを一覧表示します。

    code language-bash 
    echo $MAGENTO_CLOUD_RELATIONSHIPS | base64 -d | json_pp

    または、次のece-tools コマンドを使用して関係を表示します。

    code language-bash 
    php ./vendor/bin/ece-tools env:config:show services

  3. 応答からserviceとtypeを確認してください。 応答は、IP アドレス、ポート番号、必要なユーザー名およびパスワード資格情報などの接続情報を提供します。

サービスバージョン

クラウドインフラストラクチャにデプロイおよびテストされたバージョンによって、Adobe Commerce オンプレミスのデプロイメントでサポートされているバージョンと異なる場合がある、クラウドインフラストラクチャ上のAdobe Commerceのサービスバージョンと互換性のサポートが判断されます。 Adobeが特定のAdobe CommerceおよびMagento Open Source リリースでテストしたサードパーティ製ソフトウェアの依存関係の一覧については、インストール ガイドの必要システム構成を参照してください。

ソフトウェアのEOL チェック

デプロイメントプロセス中、ece-tools パッケージは、各サービスの提供終了（EOL）日に対して、インストールされたサービスのバージョンを確認します。

  • サービスのバージョンがEOL日から3か月以内の場合、デプロイログに通知が表示されます。
  • EOL日が過去の場合は、警告通知が表示されます。

ストアのセキュリティを維持するには、インストール済みのソフトウェアのバージョンがEOLに達する前に更新する必要があります。 ece-tools’ eol.yaml ファイル ​でEOLの日付を確認できます。

OpenSearchに移行

WARNING
Elasticsearch 7以降は、Adobe Commerce オンクラウドインフラストラクチャではサポートされていません。 Adobe Commerce 2.4.4以降では、OpenSearch サービスをサポートしています。

Adobe Commerce バージョン 2.4.4以降については、OpenSearch サービスの設定を参照してください。

サービスのバージョンを変更

インストール済みのサービスのバージョンは、Cloud環境にデプロイされているAdobe Commerceのバージョンと互換性を保つためにアップグレードできます。

インストール済みサービスのサービス バージョンを直接ダウンロードすることはできません。 ただし、必要なバージョンのサービスを作成できます。 ​ ダウングレードサービスバージョン ​を参照してください。

インストール済みサービスのバージョンのアップグレード

インストールされているサービスのバージョンは、services.yaml ファイルのサービス設定を更新することでアップグレードできます。

  1. .magento/services.yaml ファイルのサービスのtype値を変更します。

    元のサービス定義

    code language-yaml 
    mysql:
    type: mysql:11.8
    disk: 2048

    サービス定義を更新しました

    code language-yaml 
    mysql:
    type: mysql:12.3
    disk: 5120

  2. コード変更を追加、コミット、プッシュします。

    code language-bash 
    git add .magento/services.yaml
    code language-bash 
    git commit -m "Upgrade MySQL from MariaDB 11.8 to 12.3."
    code language-bash 
    git push origin <branch-name>

ダウングレードバージョン

インストール済みのサービスを直接ダウングレードすることはできません。 選択肢は次の2つです。

  1. 既存のサービスの名前を新しいバージョンに変更し、既存のサービスとデータを削除して新しいサービスを追加します。

  2. サービスを作成し、既存のサービスからデータを保存します。

サービスのバージョンを変更する場合は、services.yaml ファイルのサービス設定を更新し、.magento.app.yaml ファイルの関係を更新する必要があります。

既存のサービスの名前を変更して、サービスのバージョンをダウングレード

  1. .magento/services.yaml ファイル内の既存のサービスの名前を変更し、バージョンを変更します。

    note warning
    WARNING
    既存のサービスの名前を変更すると、既存のサービスに置き換わり、すべてのデータが削除されます。 データを保持する必要がある場合は、既存の名前を変更する代わりにサービスを作成します。

    例えば、mysql サービスのMariaDB バージョンをバージョン 10.4から10.3にダウングレードするには、既存の​ service-id ​および​ type ​設定を変更します。

    元のservices.yaml定義

    code language-yaml 
    mysql:
    type: mysql:10.4
    disk: 5120

    新しいservices.yaml定義

    code language-yaml 
    mysql2:
     type: mysql:10.3
     disk: 5120

  2. .magento.app.yaml ファイルの関係を更新します。

    元の.magento.app.yaml設定

    code language-yaml 
    relationships:
    database: "mysql:mysql"

    更新された.magento.app.yaml設定

    code language-yaml 
    relationships:
    database: "mysql2:mysql"

  3. コード変更を追加、コミット、プッシュします。

サービスの作成によるサービスのダウングレード

  1. ダウングレードされたバージョン仕様を使用して、プロジェクトのservices.yaml ファイルにサービス定義を追加します。 次の例の​ mysql2 ​を参照してください。

    services.yaml

    code language-yaml 
    mysql:
    type: mysql:10.4
    disk: 5120
mysql2:
    type: mysql:10.3
    disk: 5120

  2. 新しいサービスを使用するには、.magento.app.yaml ファイルの関係設定を変更します。

    元の.magento.app.yaml設定

    code language-yaml 
    relationships:
    database: "mysql:mysql"

    新しい.magento.app.yaml設定

    code language-yaml 
    relationships:
    database: "mysql2:mysql"

  3. コード変更を追加、コミット、プッシュします。

recommendation-more-help
commerce-on-cloud-help-cloud-guide