OutSystemsのSelf-Managed環境構築時におけるネットワーク構成／設定の注意点

はじめに

ご挨拶

はじめまして、オカハナと申します。
BIPROGYという会社でSEとして働いており、ここ数年は、OutSystemsというアプリケーション開発プラットフォーム¹の導入・開発・教育などに携わっております。

今回、このOutSystemsに関しての記事を投稿させていただきました。

本題に入る前に

QiitaでもOutSystemsの記事は多数あり、2025年8月現在で480件ほど投稿されているようです。
Qiitaの記事やインターネット上のブログを見てみたところ、開発ノウハウの類は多く見られますが、環境構築の話はあまりなさそうです。
本記事ではOutSystemsを自分たちの管理するクラウド上でSelf-Managed環境²を構築した際に気づいたノウハウを書いてみたいと思います。

内容としては、インストール時の細かい手順の解説ではなく 「OutSystems社のインストールチェックリストでは分かりづらいネットワークの構成やLifeTimeの設定の注意点」 を説明していきたいと思います。

本題（環境構築に関して）

前提条件

構築した環境の目的

ここで例として提示する環境は、特定のお客様に向けて構築した環境ではなく、我々BIPROGYのOutSystems技術部隊が各種技術検証のために使用する目的で構築したものになります。

構築先

検証の際に自分たちで自由に触れる範囲を増やしたかったので、OutSystems CloudではなくSelf-Managed環境を選択しています。
オンプレミスではなくクラウド上に構成しており、クラウドとしてはAWSを使用しました。

環境構築のゴール

社内検証用ということで、最低限OutSystemsのアプリケーションの作成・配置・実行が可能な構成を目指しました。
具体的には、本番（Production）環境は設けず、開発（Development）・検証（Non-Production）の2環境とそれらの環境を管理するための環境（Lifetime環境）を設けました。

環境構築

サーバー／ネットワーク設計

まず、サーバーを何台用意して、どのようなネットワーク構成にするか考えます。
インストールドキュメント類はこれらに関して特に触れておらず、いきなりのつまづきポイントかと思います。

我々は以下のOutSystems Cloudのネットワークアーキテクチャーに関する以下のリンク先のドキュメントを参考に決定しました。

（画像はOutSystems社サイト OutSystems Cloud network architectureより引用、2025/1/6）

OutSystems CloudはDevelopment／Non-Production／LifeTimeのデータベースは1台で共有しており、今回ゴールとしている最低限の構成という考えとも合うため、OutSystemsの各環境をインストールするサーバー3台 + RDS 1台の構成としました。

また、せっかく環境構築しても自分たちが普段開発に使っているマシンからアクセスできなければ価値は激減してしまいます。
AWSのApplication Load Balancerを1つ構築して、各OutSystemsのサーバーの前に配置し、HTTPSの通信が各OutSystemsまで届くようにします。
そして、Windows Serverのメンテナンス時にはデスクトップ画面で操作したいところです。
しかし、リモートデスクトップのプロトコルまで通すのはさすがにセキュリティ的には恐ろしいので、Fleet Manager経由でブラウザからデスクトップ操作ができるようにしておきました。
あとは、自分たちだけがアクセスできるように、セキュリティグループ設定などを適宜行います。

作成した環境の構成は以下のようになりました。

仮想マシンの準備

必要なサーバー数が割り出せたので、続いてOutSystemsをインストールするためのWindows Serverを用意していきます。
ここで仮想マシンのスペックをどれくらいにするかがポイントになるかと思います。
我々はOutSystems社のOutSystems Cloudの拡張性に関するページを参考にしてスペックを決めました。

Resource Capacity Sizesのところにデータベース／フロントエンドサーバーのクラス別のスペックが書かれており、これを参考にしています。
OutSystems CloudではClass 5から有料オプションとなることから、一般的な用途ではClass 3～4くらいを目安にするのがよいかと³。
我々の構築した環境でもフロントエンドサーバーはClass 3相当の仮想マシンを使用しています（vCPU 4コア、メモリ 8GB）。データベースサーバーもフロントエンドサーバーと同等のスペック（vCPU 4コア、メモリ 8GB）としており、データベースのClass 3よりはメモリを少し落としてあります。普段使っている分にはこれでも支障はない状況です。

OutSystems Platform Server／LifeTime インストール

OutSystems社のダウンロードサイトにインストーラーとともに配置されているチェックリストを参考にしながらインストールしていくだけになります。
我々が実施した際には、冒頭でも書いた通り、インストール自体はエラーもなく無事完了しました。

LifeTimeへのサーバー登録

各環境のインストール完了後、LifeTimeには各OutSystems Platform Serverのアドレスを登録します。
ここが最大のつまづきポイントでした。
OutSystems社のサイトでも詳細は触れられていないところです。

LifeTimeにどのように登録すればよいか自体は、以下のドキュメントに記載があります⁴。
https://success.outsystems.com/documentation/11/setup_outsystems_infrastructure_and_platform/setting_up_outsystems/possible_setups_for_an_outsystems_infrastructure/

ただ、細かいところまでは書いておらず、OutSystemsのセキュリティ設定などとも関わってくるので頭を悩ませました。

ここでポイントを二つ説明したいと思います。
「(1)LifeTimeと各OutSystems Platform Serverの環境をどのような経路でアクセスさせるか」と「(2)HTTPS通信の範囲」です。

(1)LifeTimeと各OutSystems Platform Serverの環境をどのような経路でアクセスさせるか

LifeTimeから登録したサーバーに向けて通信が行われます。我々の構築した環境では当初SSLオフローディングを設定しており、その場合、先に紹介したドキュメントにもあるように、LifeTimeにはAWSの外からアクセスする場合と同じサーバー名で登録する必要がありました。
しかし、AWSの外からアクセスするのと同じサーバー名でLifeTimeに登録してしまうと、LifeTimeから各環境にアクセスする際、何も設定しないままでは通信が一度インターネットに出てしまいます。

これはさすがに嫌だということで、LifeTimeをインストールしているマシンを名前解決する際には内部ネットワークのIPが返るように構成しました⁵。

(2)HTTPS通信の範囲

ここは非常に頭を悩ませました。
結論から先に書いてしまうと、我々が構成した環境では外部からの通信だけでなくAWS内部のLifeTime/OutSystems Platform Server間の通信すべてをHTTPS通信必須として構成しました。
（先ほど、「当初」SSLオフローディングを設定したと書いたのですが、最終的にはSSLオフローディングを諦めました）

細かい理由は省きますが……
・LifeTimeと各Platform Server間はHTTPS通信が必須である
・Platform Serverで外部IdP認証などを有効にするためには「アプリケーション間のSSO」機能の有効化が必要
　→「アプリケーション間のSSO」にはHTTPS通信が必須である
というように、SSLオフローディングしてもHTTPS通信必須な場所が多く存在する実状を考えると、エンドツーエンドでHTTPS通信を行うように構成したほうがシンプルで分かりやすい構成になると考えたからです。

各環境にサーバー・クライアント間でHTTPS通信が可能となるような証明書を配置する手間はありますが、環境構築をスムーズに行うという目的ではこの構成の方が早いのではないかと思います。

構築完了

ここまで完了すれば、AWS上のOutSystems環境に自分の開発PCからアクセスできるようになるかと思います。

終わりに

本記事ではOutSystems環境の構築の流れと、その中で我々が気づいたノウハウを簡単に説明させていただきました。
OutSystems環境の構築をこれから実施しようとしている方がもしいれば、参考になれば幸いです。

1. ノーコード・ローコード開発ツール等とも呼ばれる、アプリケーションを開発する際にコードを書くのではなくGUIによる操作などでアプリケーションの開発ができるツール・環境のこと ↩

2. オンプレミス環境やプライベートクラウド環境に構築する形態。相対する概念としては、OutSystemsが管理するクラウド上に構築されるOutSystems Cloud環境があります。 ↩

3. OutSystemsはその仕組み上、パブリッシュやデプロイの際にコンパイルなどでメモリを消費します。このため、メモリは多いに越したことはないです。特にモジュールサイズが大きくなってくると、影響が大きいです。 ↩

4. 我々が環境を構成していた時には、このドキュメントを見つけられていなかったか公開されていなかったか、で、手探りで頑張った記憶があります…… ↩

5. 当初はHostsファイルで構成、後ほどには内部ネットワーク用のDNSを用意してそちらで内部ネットワークのIPに解決されるように構成しました。 ↩