12 要素アーキテクチャ

12 要素アプリ方法論とは何ですか?

厳密には建築原則の集合ではありませんが、 12 要素アプリ 方法論は、クラウド ネイティブ アプリケーションのためのベスト プラクティスのセットです。

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

以下のセクションでは、 Mendix Twelve-Factor App の方法論要件に準拠しています。

• コードベース

  デフォルトでは、作成したすべてのアプリケーションのソースコードは Mendix に保存されます Mendix Team Server コード リポジトリ。アプリをデプロイすると、Team Server に保存されているモデルに基づいてパッケージが作成されます。その後、このパッケージは、承認や運用などのさまざまな環境にデプロイされます。

• 依存関係

  アプリのモジュールで使用されるすべての依存関係 (モジュールやライブラリなど) は、アプリ モデルの一部です。つまり、環境内にツールへの暗黙的な依存関係は存在しません。これにより、信頼性の高いデプロイメントが保証されます。

• 　

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

• バックアップサービス

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

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

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

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

• プロセス

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

• ポートバインディング

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

• 並行性

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

• 使い捨て

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

• 開発/生産の均衡

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

• ログ

  Mendix クラウドはCloud FoundryのFirehoseを使用して、すべてのアプリケーションからすべてのログイベントを収集します。これは、 Mendix ポータル。

• 管理プロセス

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