はじめに

株式会社ＫＹＯＳＯで、SAP社のエンタープライズPaaS「SAP Business Technology Platform（SAP BTP）」のアプリケーション開発を担当している房です。入社以来、複数のプロジェクトを通じてSAP BTPに触れてきましたが、その機能の多様さと奥深さには日々驚かされています。今回は進行中のプロジェクトで直面した、SAP Integration Suiteのプラン移行（「Starter Edition」から「Basic Edition」へ）に関するリアルな実体験をお届けします。開発の途中で想定外の仕様制限に直面した経緯から、インプレースでのアップデートができないという挙動、そして再作成時の具体的なエラー対処法まで、今後同じ道を歩む方の参考になるようまとめました。

SAP Integration Suiteのプラン選定とBasic Editionを

選んだ理由

SAP Integration Suiteとは

SAP Integration Suiteは、SAP BTPが提供する強力な統合プラットフォーム（iPaaS）であり、SAPシステムと各種外部SaaSをAPIやファイルで繋ぐ中核サービスです。Integration Suiteにはいくつかの料金プラン（エディション）が存在し、予算や要件に合わせて選択可能です。

SAP Integration Suite の価格設定
⇒概要レベルでのプラン比較や価格感を把握できます。

SAP Discovery Center – SAP Integration Suite
⇒各プランのより詳細なスペックや制限事項を確認可能です。

Discovery Center等の記載では、例えば「Basic Editionは特定の地域（リージョン）しか利用できない」といった文言が見受けられる場合があります。これは一般的な案内ですが、記載されている内容が基本前提となります。しかしながら、個別の契約条件や利用状況によって取り扱いが異なる場合もありますので、詳細な利用可否については、本記事の記載のみで判断せず、SAP社へ直接お問い合わせのうえ確認されることをお勧めします。

Starter Editionで直面した壁とBasic Edition採用の背景

当初は有料版の「Starter Edition」を利用して開発を進めていましたが、実装が本格化するにつれてクリティカルな制約に直面しました。iFlow（統合フロー）内に配置する「Timer（定期実行タイマー）」や「Integration Process（統合プロセス）」といった主要コンポーネントを、同一環境内に複数配置できず、さらにデプロイ可能な本数にも制限（15本以上は不可）があったのです。プロジェクト共通で利用する共通iFlowを含めると、この本数の枠はすぐに埋まってしまいました。

ここでお客様にて上位プランへの変更を検討されましたが、一般的な上位プランの「Standard Edition」にすると、「Basic Edition」と比較して年間で約800万円もの追加コストが発生することが判明しました。今回のプロジェクト規模や要件において、この莫大な差額をペイできる明確な根拠を見出すことが難しかったため、コストと機能のバランスが最適な「Basic Edition」を契約する方針へ舵が切られました。

Starter EditionからBasic Editionへの移行時の注意点

インプレースアップデートの対象外

SAP BTP Cockpitのインスタンス画面には「Update」ボタンが表示されるため、既存環境を維持したままプランを変更できる（インプレースアップデート）ように見えます。

しかし、実際にPlanを「basic_edition」に指定して「Update」を試みると、画面上に以下のようなポップアップエラーが表示されて弾かれてしまいます。

Couldn't update the plan. The 'Integration Suite' application doesn't support the transition from the starter_edition plan to the basic_edition plan.
（プランを更新できませんでした。’Integration Suite’ アプリケーションは、starter_editionプランからbasic_editionプランへの移行をサポートしていません。）

SAPの公式ドキュメント「SAP Note 2903776 」（※閲覧にはSユーザーIDが必要）を確認すると、「Starter Edition」から「Basic Edition」への直接的なアップグレードパス（組合せ）は想定されていないという旨が明記されています。UI上は変更できそうに見えるものの、アプリケーションの仕様上不可避であるため、移行を完了させるには「既存のStarter環境を一度完全に削除（Delete）し、Basic環境を新規に再サブスクライブする」という手順を踏む必要があります。

移行時の注意点

事前のバックアップ取得

環境を削除すると中のデータは完全に消滅するため、開発中であった既存資産（iFlowのPackageなど）は事前にすべて手動でローカルへダウンロードし、バックアップを確実に控えておきました。

削除直後のサブスクライブエラー（Decommissioning）

Starter環境を「Delete」した直後、間髪入れずにBasicのサブスクライブを実行したところ、以下のエラーコード400が発生しました。

> You can't subscribe to the service as decommissioning is in progress. Please try again after decommissioning is completed. Error Code: 400 Failing subscription request because decommissioning is in progress for appPlan: [starter_edition]…

これは、SAPのバックエンド側で旧環境の完全消去処理（プロビジョニング解除）が非同期で動いているために発生する一時的なエラーです。削除後、1時間強ほど時間を置いてから再試行したところ、裏側のクリーンアップが完了し無事にサブスクライブが成功しました。

移行完了の結果

「Basic Edition」への移行後は、SAP Integration Suiteの管理画面から無事に「Cloud Integration」を立ち上げることが可能となりました。「Starter Edition」で頭を悩ませていた配置コンポーネント数・デプロイ本数の制約からも解放され、スムーズに実装を進めることができました。また、「Starter Edition」ではできなかった「他のユーザーによってロックされたiFlowの解除」が本人以外でも可能になるなど、SAP Integration Suite自体の管理機能も利用できるようになりました。

Basic Editionの注意点：メモリ枯渇とデプロイ遅延

「Starter Edition」から「Basic Edition」への移行後は、順調にiFlowの開発を進めていました。しかし、実装後のテストにおいて予期せぬトラブルが発生しました。対向システムの運用上限や挙動を確認する限界値テストとして、約70MBデータの連携処理を実行したところ、SAP BTP内部でメモリ枯渇が発生しました。さらにデプロイ画面のAdditional Informationに「NoWorkerInstanceAvailable（一時的に利用可能なワーカーノードがない）」というエラーが表示され、ステータスが「Starting」のままiFlowのデプロイが完了しなくなる現象に見舞われました。

発生した現象と原因の分析

具体的には、SAP Integration Suiteの「Memory Usage」が枯渇した状態から復旧しなくなりました。約70MBデータのテストを停止した後もステータスが改善されず、iFlowの動作やキャッシュクリア等の挙動が不安定な状態が続きました。

エラーメッセージ（NoWorkerInstanceAvailable）から、SAP BTPがデータを受信した際のマッピングやデータ展開処理により、ワーカーノードのメモリ上限に達したことが確認されました。また、今回利用している環境の仕様上、高負荷発生時に自動でのスケールアウト（ノード追加）が行われず、1つのノードで発生した処理詰まりがデプロイ機能やメモリ管理まで波及して不安定化したと考えられます。

なお、こうしたリソース不足や処理の停滞は、「Basic Edition」に限らず「Starter Edition」やその他の環境であっても同様に発生し得る問題と考えられます。SAP公式ドキュメントによると、インフラのリソース状態はSAP側で常時モニタリングされており、スケーリングや調整はSAP側の介入によって行われる運用となっています（顧客側で設定・操作できる自動スケールアウト機能はありません）。そのため、リソース不足が発生した場合はSAPへ直接問い合わせて調整を依頼する必要があります。

SAP社への問い合わせと復旧対応

本番運用で想定される最大件数での連携テストは事前に成功しており、今回の事象は限界値を測る特殊な負荷テスト環境で発生したものでした。しかし、開発環境の復旧および運用の安全性を確認するため、インシデント（SAP for Me）を通じてSAP社へ調査と復旧を依頼しました。

SAP社からは「対象テナントへサーバー処理能力（リソース）の追加割り当てを実施するため、再起動を行いたい」旨の回答を得ました。テナントのリソース調整と聞くと、「SAP HANA CloudのCapacity Unitsのような容量追加に伴う課金が発生するのではないか？」と思われるかもしれません。

しかし、SAP Integration Suiteにおいて、テナント内のメモリ（RAM）やCPU、ワーカーノード数といったインフラリソースは、購入したライセンス/プランに含まれる「SAP側の運用管理範囲（SAP Service Responsibility）」として定義されています。そのため、SAP側の介入によるサーバー能力の引き上げやリソース調整に対して、個別・直接的な追加料金が請求される構造はありません。実際、今回のトラブルに伴う調整についても、インシデント問い合わせに対する「初期割り当て調整」として、SAP社側に対応していただくことができました。

再起動作業は、開発・テスト作業への影響がない業務時間外（夜間・休日帯）に実施されました。翌営業日の開始時点ではすでに環境復旧と再起動が完了しており、既存の作成済みiFlowや設定資産への影響もなく、実質的な開発遅延やダウンタイム被害はゼロで無事にテストを再開できました。

では、「インフラの増強のコストは気にする必要はないのか」というと、決してそうではありません。SAP Integration Suiteでは、物理的なリソースサイズそのものに課金はされませんが、契約プラン（固定費）とデータ処理実績（従量費）でコストが変動する仕組みになっています。SAP社によるインフラ側のパフォーマンス調整はあくまで救済措置であるため、不要なデータ量課金（メッセージ従量課金）を防ぎ、システムを根本から安定させるためには、やはりiFlow側でのリソース最適化設計が重要になります。

得られた知見

今回の対応を通じて、以下の重要な知見を得ることができました。

1. 公式の動作保証値が存在しない前提での事前検証
   SAP社の公式ドキュメント（Discovery Center等）には、スループット件数やデータ容量に関する明確な動作保証値（パフォーマンス目安）は定義されていません。そのため、プロジェクトごとに限界値テストを実施し、実効許容値をあらかじめ検証・把握しておくことが不可欠です。
   
2. インフラ管理責任とサポート連携
   万が一ノードが処理詰まりを起こして動作が不安定になった場合でも、インフラ管理責任を持つSAPサポートへ迅速に問い合わせることで、既存資産を保持したまま安全にリソースの調整・復旧が行えることが確認できました。

開発途中のプラン変更がもたらすリスクと教訓

今回の取り組みを通じて、SAP BTPのプラン変更において「インプレースアップデートが効かないケースがある」というインフラ運用上の注意点に加え、非機能面（リソース制御や自動スケーリングの仕様）における実務的な挙動への理解を深めることができました。

今回は幸いにも開発の初期〜中期段階であり、移行対象の資産（iFlow等）が少なかったこと、また限界値テストの段階で早期に現象を捉え、SAPサポートとの連携により安全に環境調整を行えたことで、プロジェクトへの影響を最小限に抑えることができました。しかし、もしこれが開発終盤や本番運用直前であった場合、資産の再設定や移行漏れによる手戻り、あるいはパフォーマンス不全による開発ストップなど、非常に大きなリスクにつながっていた可能性があります。

プラットフォームの仕様制限やリソースの上限によって開発を停滞させないためにも、単にデプロイするフロー数やコンポーネント数といった機能要件だけでなく、以下のような非機能要件も含めて初期段階で見極めることが極めて重要です。

• 想定データ量や高負荷時の挙動の把握
• 公式の動作保証値が存在しない前提での限界値テスト（事前検証）の実施
• 契約プランのリソース制限とSAPサポートへの問い合わせ手順の確認

プロジェクト初期にこれらを総合的に評価し、最適なプラン選定およびリスク対策を講じることの重要性を、今回の実体験から改めて実感しました。