12要素アーキテクチャ

1 Twelve-Factorアプリの方法論とは何ですか？

厳密には一連のアーキテクチャの原則ではありませんが、Twelve-Factor App手法は、クラウドネイティブアプリケーションの一連のベストプラクティスです。

2 Mendixランタイムは12要素のクラウドネイティブアプリをどのようにサポートしますか？

以下のセクションでは、MendixがTwelve-Factor Appの方法論の要件にどのように準拠するかについて説明します。

1.1 コードベース

デフォルトでは、Mendixで作成するすべてのアプリケーションのソースコードは、Mendix Team Serverコードリポジトリに格納されます。アプリをデプロイすると、Team Serverに保存されているモデルに基づいてパッケージが作成されます。次に、このパッケージは、受け入れや本番などのさまざまな環境にデプロイされます。

1.2 依存関係

アプリのモジュールで使用されるすべての依存関係（モジュールやライブラリなど）は、アプリモデルの一部です。これは、環境にツールへの暗黙の依存関係が存在しないことを意味します。これにより、信頼性の高い展開が保証されます。

1.3 構成

構成のニーズは、定数を通じてアプリケーションモデルで定義されます。これらの値は、環境へのデプロイ時に指定するか、CI / CDパイプラインで呼び出されるAPIを介して指定できます。実際の構成値がモデルの一部になることはありません。つまり、アプリモデルを変更せずに、どの環境にも同じ展開パッケージを展開できます。

1.4 バッキングサービス

すべての外部要件（アプリケーションデータを格納するデータベースなど）およびアプリケーションから呼び出されるサービスは、デプロイメント時に構成できます。以前の要件と同様に、これにより、モデルを変更せずに、同じテスト済みデプロイメントパッケージを、あらゆるバッキングサービスであらゆる状況で使用できることが保証されます。

1.5 ビルド、リリース、実行

本番環境でコードを変更することが可能である場合、アプリケーションのスケーリングは予測不可能で信頼できなくなります。また、デバッグと問題解決が難しくなります。この問題を回避するために、Mendixプラットフォームはビルドと実行のステージを明確に分離しています。

Mendix開発者ポータルでは、まずモデルからパッケージをビルドする必要があります。次に、パッケージを環境にデプロイできます。本番環境でコードを変更する場合は、モデルを変更してから新しいパッケージをビルドする必要があります。 Mendixは、アプリケーションをビルドおよびデプロイするためのAPIも提供しているため、このアプローチをカスタムCI / CDパイプラインに組み込むことができます。

1.6 プロセス

Mendixランタイムは完全にステートレスになるように設計されています。データベースを介してデータを共有し、容易なスケーラビリティと復元力を保証します。

1.7 ポートのバインド

異なる環境での同じアプリのスケーリングと実行を容易にするために、アプリは自己完結型である必要があります（つまり、クライアント要求をリッスンする場所を構成可能にする必要があります）。 Mendixアプリはこのように構成できるため、Cloud Foundryなどの基盤となるサービスとしてのプラットフォーム（PaaS）を使用して、アプリをホストするコンテナーの数を簡単にスケーリングできます。

1.8 並行性

Mendixは、Javaスレッドとプロセスの組み合わせを使用して、エンドユーザーの要求に合わせて拡張します。 Twelve-Factor App方法論は、プロセスを介してスケーリングする必要性を強調しています。そうしないと、スケーリング要件が1つのJava仮想マシン（JVM）がサポートできる最大（垂直スケーリング）に制限されます。プロセススケーリングもサポートすることで、追加のリソースをいつでも簡単に追加できます（水平スケーリング）。

1.9 使い捨て

Mendix Runtimeインスタンスは、必要に応じて停止および開始できます。マルチインスタンス環境では、ユーザーは通常、1つのランタイムインスタンスが再起動されても気付かないでしょう。これの利点は、水平方向のスケーラビリティがよりシンプルで高速になり、新しいバージョンまたは新しい構成の展開がより速くなることです。

1.10開発/生産パリティ

品質を保証するために、テスト環境にデプロイされたアプリは、本番環境でも同様に動作する必要があります。 Mendix Cloudでは、すべての環境が同じ方法でプロビジョニングされます。唯一の違いは、構成、データ、およびアプリケーションです。代表的なデータでのテストを確実にするために、バックアップと復元を通じてデータを環境間で移動できます。

1.11 ログ

Mendix CloudはCloud Foundryファイアホースを使用して、すべてのアプリケーションからすべてのログイベントを収集します。これは、Mendix開発者ポータルで表示およびフィルタリングできます。

1.12 管理プロセス

同期の問題を回避するために、Twelve-Factor App手法では、管理コードとアプリケーションコードを同梱することを推奨しています。 Mendixはこの慣行を実施するため、アプリ環境で実行される唯一のコードはアプリの一部であるコードです。つまり、管理コードをモデルの一部にする必要があります。ユーザーは多くの場合、アプリの起動後に実行するマイクロフローを実装するか、管理アクションをトリガーするAPIを作成することにより、管理ページで管理ロジックを使用してこれを実装します。