AzureAppServiceのJava TomcatのDB ConnectionPool設定に関するメモ
AzureAppServiceのJava TomcatのDB ConnectionPoolの設定に苦戦したので、設定方法をメモしておく。
TomcatではDB ConnectionPoolを$TOMCAT_HOME/conf/context.xmlに設定するケースが多い。しかし、AzureAppServiceでは$TOMCAT_HOME/conf/context.xmlは自動生成されるため、修正することができない。
デフォルトのデータソース定義は自動生成時に作成されるため、DB接続は可能になるが、コネクションプール数がTomcatのデフォルト値となり、初期0本、最大8本となるため、最適とは言い難い。
Tomcatのデフォルト値
https://tomcat.apache.org/tomcat-9.0-doc/jndi-resources-howto.html#JDBC_Data_Sources
ConnectionPoolの設定をしたい場合は、warファイル内のMETA-INFディレクトリ内にcontext.xmlを配置すればよい。
$TOMCAT_HOME/webapps/[app名]/META-INF/context.xml
データソース定義が複数あることになり、$TOMCAT_HOME/conf/context.xmlの定義は使われていないことになる。しかし、デフォルト設定ではプール数が初期0本となり、DB接続を行わないため、リソースが無駄になることはない。
サブシステム分割・マイクロサービス・「残」
ふと気になった『データモデリングでドメインを駆動する』という本を読んでみた。
主な主張は以下の通りである。
- SoR(System of Record)はSoA(System of Activities)とSoM(System of Management)に分類できる
- SoAはいわゆる基幹システムであって、実績を記録する「活動のシステム」である。SoMは経営管理のシステムであって、会計システムも含む。
- 「活動のシステム」は「残」の概念をベースに構築される
- SoAに会計系の処理が浸潤する等、SoAにSoMの要素が混入することがよくみられるが、本来はSoAとSoMは疎結合になっているべきである。
- ドメイン駆動設計にはドメインの一部を成すデータモデリングがほとんど含まれておらず、データモデリングをもっと考慮すべきである。
著者は業務機能の分割は「残」に基づいて行われるべきであると主張する。この考え方をサブシステム分割・マイクロサービスの分割を検討する際に適用可能と思われた。どちらも分割のお作法に決まったものはないが、「残」に着目することでサブシステム・マイクロサービス間の独立性を高めた分割を実現できる。本著書にも何回か登場する渡辺幸三氏は『データモデル大全』内でCRUD操作の跨りが最小になるようなサブシステム分割の方法を主張されているが、この主張と「残」の概念による分割は通ずるものがあるように思われる。
